subscribe via RSS
I'm still here, ok? There is just a bunch of stuff keeping me from doing the rest of the stuff that would be keeping me busy under normal circumstances. To cite a friend of mine ( in not so perfect english, though ) : such is life.
After having annoyed with may day-to-day pains ( I haven't, so be grateful ), let's get a bit productive here. First of all, I plan on releasing the authentication framework I talked about recently here on github or some other hypersocial site. I'm sure that some of you might find it interesting, while others are going to hate it. Such is life, cont'd.
Rails is still filling up most of my day, but after moving to Stuttgart last week, I finally managed to think of other, maybe somewhat more interesting stuff. A good exercise was certainly to return to some unsolved facebook puzzles ( read: all except one ) and to talk with some inspiring people about ... a lot of technical geek-o-rama.
I told you to be grateful for not having to skip over my boring stories, but here you go. I managed to bring up my IKEA-kitchen by myself, and I didn't die. And, more fascinating, I even destroyed the Harddisk of my EEEEEE Pc without any physical interaction required. I wasn't even using it. It was actually my girlfriend playing Tetris or something similar, when suddenly, the system froze. And the harddisk emitted a sound resembling a crashing airplane in small scale.
Have a nice night, I will.
Actually, two 24" displays are really big, especially if they are placed next to each other and providing you with a screen width of roughly 3840 pixels. And, honestly, there is no use for it, except you are doing some serious stuff like programming, video editing or hardcore browsing on your machine.
But there is nothing like an instant productivity boost. For me, it was the opposite: working around the big screen. So I invented a few rules to utilize the screen estate as useful as possible, and to minimize time needed to rearrange windows ( a tedious task one two screens ) and find lost ones. This is not a universal, scientific-proved guide on how to be more productive with two displays, it's just my experience!
Step 1: Drop the idea of a primary screen.
A primary display is the display that is used to display the task bar or the dock, menu bars ( OS X ) and so on. It's necessary unless your hardware automatically stretches your display across all of your displays, which is not the case here. A primary display is kind of a technical necessity, yet it's further use is quite ... limited.
In case you find yourself preferring one of your displays over the other, rethink your setup. Place your chair so that both screens take up equal portions of your view. And, of course, now is just the right time to minimize any offsets preventing you from treating them as one screen. Books placed under the screen etc. are handy :-)
2. Use both screens for all of your tasks
Just try to do all your tasks randomly on both displays. By doing so for a few days, I just managed to eventually use what i have, in terms of screen estate.
So that's the general part, applicable to all dual-head set-ups. But now for the work. This is just how I did it, once again. There are several approaches, and I use them as I need and like.
1. Approach: Logical Split
I named this because whenever I use this, mostly for general tasks such as reading mail and surfing, I place my browser in the right display, while putting all my itunes, im, music player in the left screen. So, I do have a more active screen, and that's okay, because I maintain quick access to all of the other stuff I need on the left screen.
2. Approach: Productive Split
The productive Split consists of having e.g. an IDE such as Eclipse running in one Display while Watching output, reading documentation or doing anything else task-related on another screen. Doing this minimized the number of window arrangements massively, speeding up development. Of course, this can also be applied to any other IDE concept, not Eclipse-bound ( using TextMate here too, just nice ).
That's it for now, just a few hints.
Yay. In case you're looking for a release, there is none. Not yet, we are maybe going to release one, but it's a question of time rather than a lack of good will.
Why. In my current position, I am building a set of applications ( most of them rails based ) communicating with each other in a RESTful manner. This is, well, just continue reading my ActiveResource rant here. It's not really nice to use the official ActiveResource thing. It's a lot of hardcoding ( e.g. you have to set the remote service' URL in the model, not in some kind of configuration file, which makes switching from development to testing and production a pain ) and other shortcomings. It's a good idea, yet far from being perfect. And the two things that bothered me most were service discovery, meaning, the easy ability to resolve a service by its name than by its url, and authentication. Both of them are crucial for a system exceeding the hello world boundaries. That is, what I'm doing. So, utilizing all of Ruby's beauty, a) a Rails plugin was developed and b) a standalone Server acting as a Central Authentication Service and Service Discovery instance. And from what I can tell, it's beautiful ( not the codebase, at the moment, but the functionality ).
What is this thing able to do? Well, for the simple parts, it handles all your authentication needs. No more password juggling, just do it in one place, and nowhere else. OpenID compatibility is on the way, both as consumer and provider. It's nice to have this kind of functionality by only installing a plugin and create a before_filter.
The next big thing is the service discovery. ActiveResource wasn't used as an entry point for customizations, it was HyperactiveResource. I extended it to provide the ability to connect to the above mentioned central instance ( the address of this instance is defined in a configuration file, by the way ) to retrieve a services' address. A simple thing, yet it makes life so much easier.
Is there a clue? Yes. Bundling the two features above, you are able to allow and disallow communication between two services at your will. Bidirectional, so assuming you do have an E-Mail-service and an AddressBook-service, you now can allow the E-Mail to access your AddressBook, without allowing the other direction. Authentication is handled completely transparent to the developer, and the rest of the usage is like HyperactiveResource. Just a charm.
And for me? Fun is back :-)
I'm like reading deutsche startups, a blog covering the first steps of upcoming german companies, everyday. And it's like reading a newspaper in the morning: you just expect something exciting to happen. Nada. It's just the regular suspects. I'm way to lazy to aggregate my readings into some stats, yet I estimate that at least 50% of all startups don't have a very unique idea not yet seen on the german or european market. They just modify a little detail ( let's say the pricing, the name, the color scheme, one tiny functionality ) and launch as the hot new shit.
And it's sad, it's really sad. There is nothing like real innovation. New ideas, experiments. Just boredom. And boredom isn't what I'm looking for, so the german internet seems like a one-way-street in terms of technology. Still usable, well, with IE6.
What is this post about? Frustration, a load of it. Stop copying, start innovating, fellows.
As of yesterday, there is a Native Developer Kit for Android available. This came as a surprise for me, as there were not many rumors covering that topic, but regarding the broad coverage on the iphone 3gs lately, and most of all it's amazing speed, Google certainly had to do something to keep Android in the game.
So this is, from my point of view, a very much strategic decision, placed just at the right time. Android's finally deployed to a number of new devices, not only by HTC, but also Samsung and other vendors are now adopting it. So after this first hurdle being taken, Google realized that there is more to mobile devices than PIM functionality and a browser, plus some location based gimmicks. Games are a massively growing market inside the mobile universe. And they want to have a part of that cake, but without a Native Development Kit and the ability to interface graphics directly from real machine code, the speed impacts induced by using a Virtual Machine to execute code are still too high for big games. Can I prove it? Well, no need to, to cite google here:
In a future release we hope to support linking with OpenGL ES and audio libraries, which should enable high-performance games.
By releasing this kit, Google finally opens Android to all those people not willing to write Java Code that perfoms well ( which is not the way Java is handled anywhere else ) and let's developers to the optimizing of raw code themselves. I'm really looking forward to seeing some of the results.