Monday, November 29, 2010
Sleep is a symptom of caffeine deprivation
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?
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
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!
Friday, November 26, 2010
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".
Subscribe to:
Posts (Atom)