I recently got into the beta of BumpTop – You may have heard about it: it’s a replacement for your Windows desktop.
BumpTop lets you use “real” actions such as tossing items around the desk, creating piles of items and such. Their site claims that BumpTop is “a fresh and engaging new way to interact with your computer desktop”…
So does all this actually work, and most important of all, is this a practical way to manage your computer desktop?
It seems as if the browser is becoming easier to understand than other applications for people who don’t know much about computers in general.
For example, if an application has a settings dialog and you ask the user to go back or close the dialog, they aren’t always sure what to do – should they press Cancel, OK or the X in the top corner? – On the other hand, in a browser it’s quite obvious: press the back button.
Should applications be built with interactions more like browsers, or should you simply build the application around a website?
I got a chance to play with Windows 7 earlier this week. In case you haven’t heard, Windows 7 is the next OS from Microsoft, following in Vista’s footsteps quite literally – it’s based on Vista, and it looks almost exactly like it.
I’ve skipped Vista myself. I’ve heard so many bad stories about it, and never got around to using it at work either. Frankly, the problems with Vista are probably a bit exaggerated, as you can for example disable the UAC system which causes all the annoying popups asking for permissions.
In an interesting decision, the PHP devs have decided to use a backslash, \, as the namespace separator. This is a bit… curious.. choice of a character.
They apparently had a long discussion about their choices, but really, couldn’t they just have used ::, as the manual showed for a while? It’s starting to feel like the fact that PHP was not designed with all these features in mind is starting to show more and more.
The argument that if you used :: as the separator would confuse between static calls is a bit weird, too. Python for example uses . for the namespace separator, method/property access and static method/property access and it works just fine. Now, I don’t know if PHP’s and Python’s internals differ greatly, but they’re both dynamic languages, so at least there shouldn’t be any implementation problems standing in the way for using the same character.
I’ve used languages with definitely weirder syntax than this, but it just seems weird, especially since PHP’s syntax is otherwise so similar to languages like C++. While some people seem to think this will make PHP much worse somehow, I think I’ll eventually get used to seeing the backslash in code, when we actually get 5.3 stable. It just seems really odd now.
I’ve often been asked whether my CMS is public, whether the code is available, etc. – the answer at the moment is no, but information about it is public… so for your reading pleasure, here’s some information on how I’ve handled the issue of different page types.
All pages share some details, such as name, id, location in the page tree and stuff like that. But what pages don’t share is their contents. Some pages might simply be content pages that display some text, others could be simply redirections. This presents some challenges, especially when designing the database structure.
Opera has launched another widget competition: The x-widget challenge. The goal is to make the best cross-device widget – this means the widget has to work on mobile phones running Opera Mobile 9.5, which supports widgets, and in Opera on your computer.
I’ve sometimes needed custom elements in forms – say two fields for inputting two numbers. For something simple like that, adding two separate elements usually suffice, but when one of my clients wanted a field with multiple checkboxes, but only specific pairs could be selected, it started getting too complex.
Until then, I had kind of avoided making those custom elements, as there didn’t seem to be much information on them in the Zend_Form documentation. I decided it was time to find out how to do it!
I’ve been reworking the ModelForm class for ZF a bit. Earlier this year, I discussed porting it to use Zend_Db_Table with Matthew Weier O’Phinney, for using it with Zend Framework. I initially had done some checking on Zend_Db_Table, and some small code changes to modify the class to use it instead of Doctrine, but I ran into some issues. Now, I’ve had some time to think about it, I’ve reworked the class slightly and added basic Zend_Db_Table support, too…
There’s an interesting project from Microsoft’s OfficeLabs: Touchless, a project which allows you to utilize a webcam to do multitouch style input on your PC.
The basic idea is something I’ve thought about as well – have a webcam track a colored object, and use that as a “cursor”. The touchless demo is very promising, although at this time it seems it’s a bit difficult to set up to recognize the objects well. It could be just my webcam too; it doesn’t exactly have a very good quality image. However, when set up properly, it does work surprisingly well.
Anyways, I definitely recommend checking out the project. The demos are fun to play with for a bit at least. If you’re familiar with C# or some other .NET framework language, you can even use the source code provided to develop your own multitouch apps. Note that it requires .NET Framework 3.0.
In case the OfficeLabs site is down, you can find the files from their CodePlex project page.
If you’re having problems getting the software to recognize your markers, you probably should try aligning the camera to face down to your desk so it provides a less colorful background. I also had to adjust my camera’s color balance, but that might not be an issue with a better webcam.
CSRF, or Cross-Site Request Forgery, is a vulnerability very common in websites. In short, it means that if you have your site at foo.com, and an attacker at badguy.com can display a form similar to one of your site’s, and make users on his site submit the forms on your site, possibly without their knowledge.
This can be dangerous, especially if your admin interface is compromised: There may be a button on the other site which goes to your admin interface and deletes the latest blogpost for example – and you wouldn’t want that!
Let’s look at a simple way to prevent CSRF attacks, and then how to apply it in Zend Framework apps to automatically secure all forms.