Developers, developers, developers

Anyone should remember the stellar actuation of Steve Ballmer reciting these words.
Developers were important for microsoft. Having developers tied to their platform meant software being written for it.
Well, now Microsoft is losing developers, while Apple is always winning more of them (I won't talk about GNU/Linux which is king supreme on the server side, but not yet on desktop).
Why is that? Well, many thing must be taken into account. The iDevices for example. There are many developers writing iPhhone, iPod touch and iPad applications. You only can do that from a mac, and once you have learned that (as officially most software must be written in objective-c using xcode) you are ready to easily write mac applications too.
Switching to intel architecture was a very very clever thing for Apple to do, because people have the possibility to run Windows on their macs too, either native via BootCamp or on a virtual machine. Many people were afraid of switching to a mac because they were relying on some windows software, which now they can use without problems.
But, the best... any developer who now uses a mac has their development environment ready, and free of cost. And when start to use it and step the learning curve of a new language, because objective-c isn't used much outside of the mac world, they start to appreciate the beauties of Cocoa, the heir of Next.
Let's be clear, Microsoft has done some wonderful things too, but when you have to deal with the absurd complexities of a system which was, in theory, designed to hide them... you find that something isn't working as it should.
If microsoft is losing developers which are going to other platforms, there's noone to blame more than the own Microsoft. They are doing things difficult for their own developers, while others have been trying sine years to make averything easier, more clear and more confortable for them.
Microsoft, you are slowly but steadily loosing points there. If you want to rise again, you know what you need: Developers, developers, developers...

Tips: Adjusting your webApp to iPhone screen size.

On mobile webApps, we should care a lot about screen space, because it's very limited.
My test app consisted on a fixed positioned header, an optional fixed positioned footer, and a scrollable content. I wanted it to fill the whole screen space, of course, both in portrait and landscape mode.
As anyone knows, it's possible to hide the navigation bar on iPhones's safari, and that gives us 60 extra pixels. That's a lot. But there's one thing... the navigation bar can only be hidden (it's really scrolled up) when the content is larger than the available screen space.
I thought... on orientationchange event I must only read window.innerHeight to get the total window height, adjust my div sizes, and hide the navigation bar. Fail
window.innerHeight reported the available window height considering the navigation bar was there...
Easy then, first I hide the navigation bar, and then read window.innerHeight. Results?
When switching from portrait to landscape mode everything was right. But when switching from landscape to portrait it wasn't.
Of course, when switching, the content height was the total height in landscape mode, 300px (the always present top status bar is 20 pixels height), and of course it wasn't enough to scroll the navigation bar up. What to do?
Easy. First, set the content height to screen.height (which is always 480 in the iphone) so it is high enough. Then, hide the address bar, and once hidden, set the right height depending on the window.innerHeight (which will be 460 in portrait mode when the navigation bar is hidden, the whole screen.size minus the 20 pixels of the status bar which is always visible).

Don't fear reinventing the wheel.

It's considered one of the most popular mistakes between programmers. Reinvent the wheel. Again and again programmers are constantly reinventing things. It's a big waste of time, and usually the resulting code is of a much lower quality than "wheels" which have existed for a long time, which had most of their bugs solved, which have been used and abused for all kinds of things...
But there are exceptions. Some times, reinventing the wheel is useful. Sometimes we don't need an overengineered wheel. We don't need the fast wheel for a formel-1 car, we don't need the strong wheel of a  big transport device, we need a simple, small wheel which just can carry our luggage. In that case, simplicity over all, our own wheel, although technically worse in many aspects, can be good for our project.
And of course, there is a time where reinventing the wheel has a clear advantage: learning. There is no better way to ler how a wheel works than reinventing it (even though after doing that we can see that existing wheels are better than our, but then we can use them with knowledge of doing the right thing).

More experiences on mobile(r) webApp development

Any mobile webApp should be simple, and if it is mobiler, it should be simpler.
I really like iScroll, it provides native app like scrolling, it's really easy to use, and customizable enough, so after (well, while) using it for the iPad framework, I've decided to go mobiler. What's mobiler than the iPad? iPhone (and iPod), of course. Using it on a real device is always much better than on the simulator (as I don't have a real iPad).
I like it so much that I'll probably start writing my own real iDevices framework (with the experience obtained with the iPad one). If everything is well deigned, minimal code changes will be needed to support the diferent optimal layouts for iPad and iPhone (which includes iPod and android devices too).
If added to the home screen (on iPhone at least, don't know about iPad or android) and given the good performance of iScroll (which is no so good on android due to the lack of hardware acceleration) any webApp designed to take advantage of offline operation and local databases can be made indistinguishable from a native application.

Experiences on mobile webApp development

So, I've started with the development of a webApp for the iPad. Well, it's more like a framework fora split-view like webApp.
Of course, I'm using the great iScroll library. It's very easy to use, and although it has a big ammount of complexity inside, successfully succeeds in removing it from the developer by providing a very easy interface.
Of course, every abstraction leaks, and iScroll is no exception, but if you stick to what it's designed for, it's great!. For anything else, if it doesn't work right, consider it a leak and attach the problem from a different angle. You can either read the sources from iScroll (it's clean and easy to read and understand) to see where your problem comes from, and either fix your concrete case or think of some useful modification for everyone (which doesn't add complexity, of course) and submit it, or you can attack your problem in a different way (that's what I did, making it do something a bit different from what I had in mind at the beginning).
This framework I'm doing leaks like mad too, but if you restrict yourselve to the "documented" behaviours, everything should be ok (it's done so that eveyrone can write an iPad split-view like informational app completely in html. All javascript code will be self-contained, inside its limits, of course).

What about mobile webApp development?

Well, of course we must talk about Apple here. The iPhone revolucionized the mobile phone world, and was the firstsmartphone with a real browser which everyone could use. The iPad was the first succesfull tablet device, and their additions to safari, even when they could be considered the "browser wars" of the XXI century, are really useful and powerful for web developers.
When the first iPhone came, there was no SDK for it. WebApps would be the iPhone apps, but at that moment it was not enough. Even forgetting the limitations of the original iPhone, there were many thing that couln't be done in a web browser... or could they?
When the SDK came, everyone started developing for it and forgot the webApps, but safari has continued improving. Now, webApps can be stored and used offline, with the hardware acceleration for the CSS transforms you can attach fast and interesting visual effects. WebApps can store data locally, access the GPS device, the accelerometers, etc. WebApp developing for mobile devices is getting more interesting every day, again.

And... which other big benefit does it have? in my opinion, two big ones:

• Availability. Everyone can use your webApp now, you don't have to submit it to an AppStore, it doesn't have to be approved, people don't have to download and install it. When they find it, it's already there, ready to use. This includes automatic updates too :-)
• Availability. Yes, it's the same as the first one. Your app will be availabe for everyone, independent of the device they have. They have an iPhone? the app will be there. They have an iPad? the app will be there. They have an Android phone? the app will be there. They don't have any smartphone or tablet but have a computer with a web browser? you already know the answer.

Of course, always keep in mind your possibilities and limitations. an FPS shooter would be too slow (today) as a webApp, but many other things implemented as a webApp can be just like native apps, or even better (you can access always the same data from every device or computer you like).

Which javascript framework should I use?

The answer, of course, is: It depends.
It depends on many many things. From the complexity of your application to the deployment platform. Will it be an iPhone or iPad only webapp? will it have to support IE6? Which other constraints do you have?
If your app is simple enough, the best framework will probably be... none. Using standard javascript, standard DOM methods, etc, will be probably faster and smaller. Even if you must take into account all possible weirdness (different event model in IE and the rest of the world for example). If you are constrained to a sane subset (no IE < IE9, only safari because it's for iPad, etc) then it becomes even easier to program without any framework or library.
For a medium size app which needs to run on a variety of different browsers, a framework which supports all needed browsers will help a lot, as we won't have to reinvent the wheel for solving many browser inconsistencies. In this case the developer should be consistent on using always the framework methods when existing, and not mixing them with native javascript or DOM methods, as that could led us to difficult to find, subtle bugs.
For a big thing, the use of a framework can always help, as many needed things will be already implemented and tested, and it will provide a lot of higher level functionality missing on the javascript core language.

About which one to use... I would say it depends on what you have to do as well as your personal taste. All frameworks have their own pros and cons, and some of them are better adapted to some kind of work than others.
Personally, I really like the Google Closure Library as it's the one which more closely resembles my style of work, and what I would like a good javascript framework to provide. For different styles of working, different frameworks can be better, of course.
If you want to try the closure library (which works better in its own environment, specially regarding the Closure Compiler), I really recomend reading closure the definitive guide from Michael Bolin. It really gives a ton of good information about the Closure Tools.

claim verification

HRNSQ9S49DRY

Sleep is a symptom of caffeine deprivation

And every developer proud of being should know.
Anyway, everyone should know too that some quality of sleep is important too. It will make you feel better and your code will be better too. But it's hard to get. There are many parameters which prevent us of getting a good sleep, from personal preferences (late nights of coding), social events (late night parties), family (those with children at least don't have to worry much about late night parties), etc.
Well, seems that most problems can be solved with some training and self discipline. I've just found a free ebook called "40 sleep hacks. The geek's guide to optimizing sleep". I already knew/had read about most of them, but having them toghether in the form of a book is always good. It's free, and was made by SleepWarrior.com (which is currently in maintenance mode).
Oh, f.lux is an interesting utility (free as in beer, for Mac OS, GNU/Linux and Windows) which changes the color temperature of your monitor relative to the sun position (sun lighting is much different from artificial light, and your monitor color temperature regulates to the type of light used). Interesting idea.

So, you need a good and simple editor?

Sometimes those big IDEs are great, but sometimes they are... too much.
I've been a happy user of aptana for a long time, and I like it very much, but sometimes it gets being painfully slow (due to its huge memory usage).
A popular editor for those using Mac OS is Textmate. I've tried it and I really like it. It's fast and thanks to its plugins system (called Bundles), extremely customisable. You can usually find a bundle for what you want, reduce your more common things to do to a single keypress, etc.
On the Windows side, the E Text Editor claims to have "The power of Textmate on Windows" (it's compatible with Textmate bundles).
But... what if you use GNU/Linux? well, you happen to have a great editor already there (if you use Gnome at least), Gedit. It has plugins too! I have some installed, and have just discovered the Gedit Developer Plugins. Now I'll have to try them. What, word and python symbol completion? word completion like Textmate? symbol completion only for Python? well, I already have symbol completion on my gedit via another plugin... and it works for almost all languages (thanks to exuberant ctags). At least, works wonderfully for javascript, which is what I need. Anyway, good idea to have some developer plugins all together.

Perfection kills

Well, that's a goog name for a Javascript blag (which I have discovered btw searching on Google for the title of the post).
If you are writing a framework, a library, or just any kind of abstraction, don't pretend it to be perfect, it won't be (by law). The closests you can get to perfection will be by means of finding and documenting its imperfections. That means that whenever someone using your framework must do something which it doesn't support, they'll know and they'll be able to work around it instead of spending time trying to use your framework for (or trying to adapt it to) something which isn't (good) handled by it.
Yes, when you find some of these cases you'll be often tempted to solve it in your framework. You can try, of course, but if it does add some complexity (whatever small it could be), please forget it and document it clearly. Everyone wins!

Keeping it stupidly simple

Oh, why is it so difficult to keep something stupidly simple?

Well, probably The Law of Leaky Abtractions has an important part of it. Or better thought, a misunderstanding of it. The most basic premise of the law is: "All non-trivial abstractions, to some degree, are leaky."

Which relation does it have with not keeping it simple? Well, the problem, IMHO, is that many people are trying to prevent the abstraction leaks from occurring. And that usually leads to an over-engineered mess, no kidding!

What should be done about these leaks? Nothing more than acknowledging them! If abstractions are good 98% of the time and bring problems on 2% of cases (real world problems could be much lower if the abstraction is good enough), acknowledging these leaks should be enough. What happens if you need the special case where the abstraction leaks? you go to a lower level and don't use the abstraction for the concrete problematic case. Period. (Well, sometimes something sinply stupid can be added to the abstraction, and if it's simple enough it should be done).

The moment you start adding complexity to the abstraction to solve one of its leaks, you are ruining it. Even if the complexity added is really low, you are adding it always, thus degrading the usage in practically all cases, just to improve some exceptional ones...

And as the abstraction will always be leaky, new exceptions will continue appearing, thus degrading the experience further and further, until you end with some monstrosity (and I'm thinking on a particular framework) where the complexity inherent to the abstraction is so high that it ends being much more difficult to use it "correctly" (pun intended) that to bypass it completely and doing all the work "the old way".