I'm 30+ and when I was young, I was really really skinny. Then I started working in the very unhealthy IT business.
Long hours. No exercise whatsoever. Lotsa carbs to please the brain. I got very fat, very quickly.
I still work in the IT business.
Long hours. No exercise whatsoever. A lot of fat. And I'm quite thin and I have more energy than ever.
Cut the sugar, eat fat, get skinny. It works.
Friday, February 4, 2011
Tuesday, February 1, 2011
The number one non-genetical reason I'm one hell of a productive programmer
Water.
It's in abundance. Tastes great. Makes my brain work optimally.
Water. Lots of it.
It's in abundance. Tastes great. Makes my brain work optimally.
Water. Lots of it.
Sunday, January 23, 2011
Top 5 Computer Scientists With Balls And Brains
5: Donald Knuth for giving his middle finger to the entire digital typesetting community by making his own superior system, eons ahead of everyone else. It took balls and skills, man. His TAOCP volumes should cover the brain part, if you feel TeX doesn't cut it.
4: Dijkstra for considering goto harmful. Many a coder disagreed vocally, calling it a neat construct for error handling (the Linux monkeys still do.) It surely took balls to oppose the longjmp mafia, and brains to convince 96% of the coding population.
3: Alan Kay for inventing a measure of arrogance in computer science: nano-Dijkstras. And it took a big brain to get small talk out of an eight bit computer.
2: Bjarne Stroustrup for deluding millions of people into thinking that slapping OO constructs on top of a portable assembly language (C) was a good idea. It most definitely took brains to implement the shit in a preprocessor.
1: John Backus for having the audacity to believe, in the 19-friggin-50s, that high-level language source could be compiled into efficient machine code. No doubt does it take a well-massaged brain to punch an optimizing compiler into a bunch of paper cards.
4: Dijkstra for considering goto harmful. Many a coder disagreed vocally, calling it a neat construct for error handling (the Linux monkeys still do.) It surely took balls to oppose the longjmp mafia, and brains to convince 96% of the coding population.
3: Alan Kay for inventing a measure of arrogance in computer science: nano-Dijkstras. And it took a big brain to get small talk out of an eight bit computer.
2: Bjarne Stroustrup for deluding millions of people into thinking that slapping OO constructs on top of a portable assembly language (C) was a good idea. It most definitely took brains to implement the shit in a preprocessor.
1: John Backus for having the audacity to believe, in the 19-friggin-50s, that high-level language source could be compiled into efficient machine code. No doubt does it take a well-massaged brain to punch an optimizing compiler into a bunch of paper cards.
Thursday, January 20, 2011
Debuggability
Once in a while, you encounter a bug that's really, really hard to track down. The hardness depends on a lot of factors, such as the number of committers, complexity of the source base, number of temporal dependencies and the size of the changesets (here loosly defined as a commit.) How do you deal with these? The first step is to find the commit that brings disharmony to your project. If you don't use an SCM, you're basically FUBAR anyway and should leave this blog post immediately in order to get a clue.
One project that routinely faces all of these factors (and more) is the Linux project. It's a large project with fast-paced development, fairly complex code and a huge number of interactions and temporal dependencies. Because of this, the core developers have gotten really good a tracking down hard bugs (they tend to have a couple of super-hard-to-find bugs every other month or so.)
The awesome thing is that the techniques they've developed are equally useful for small projects, even one-person projects, as long as you have the discipline to maintain a debuggable project.
The magic words here are frequent commits, focused commits and bisection.
First of all, the best general technique to actually find the faulting commit is by bisection. Every modern source code management system supports it, either directly (such as git and mercurial) or by means of a third-party addon (such as Subversion.) Go Google it if you don't know what it is.
Frequent and focused commits means that, once you've found the commit that screws up your precious system, you'll have a fairly small change set to study and debug, and it will contain changes for a focused feature set with few interactions.
One project that routinely faces all of these factors (and more) is the Linux project. It's a large project with fast-paced development, fairly complex code and a huge number of interactions and temporal dependencies. Because of this, the core developers have gotten really good a tracking down hard bugs (they tend to have a couple of super-hard-to-find bugs every other month or so.)
The awesome thing is that the techniques they've developed are equally useful for small projects, even one-person projects, as long as you have the discipline to maintain a debuggable project.
The magic words here are frequent commits, focused commits and bisection.
First of all, the best general technique to actually find the faulting commit is by bisection. Every modern source code management system supports it, either directly (such as git and mercurial) or by means of a third-party addon (such as Subversion.) Go Google it if you don't know what it is.
Frequent and focused commits means that, once you've found the commit that screws up your precious system, you'll have a fairly small change set to study and debug, and it will contain changes for a focused feature set with few interactions.
Wednesday, January 19, 2011
The idiocy of domain specific languages
I consider domain specific languages (DSLs) to be harmful. It's harmful in the way aspect oriented programming is harmful, only twice as grave.
Why?
1. If they get popular, they'll lead to language proliferation within each industry, because - let's face it - nobody waits for language design committees anymore.
2. The point of a DSL is to raise the level of abstraction, and introduce language-level constructs, applicable for the domain at hand. But every application has non-domain parts (generic logic, architectural stuff, technical glue and whatnot), and these are usually not possible to factor out without things getting really messy.
3. Designing a language, DSL or not, is very difficult to get right. Any DSL attempts within the average company is bound to be lame in the long run.
4. I'm getting tired about talking about DSLs.
Just use a general-purpose programming language and learn how to find and implement the proper abstractions.
Why?
1. If they get popular, they'll lead to language proliferation within each industry, because - let's face it - nobody waits for language design committees anymore.
2. The point of a DSL is to raise the level of abstraction, and introduce language-level constructs, applicable for the domain at hand. But every application has non-domain parts (generic logic, architectural stuff, technical glue and whatnot), and these are usually not possible to factor out without things getting really messy.
3. Designing a language, DSL or not, is very difficult to get right. Any DSL attempts within the average company is bound to be lame in the long run.
4. I'm getting tired about talking about DSLs.
Just use a general-purpose programming language and learn how to find and implement the proper abstractions.
Don't get screwed by online casinos
I love casinos. Both real ones and the their equally flashy and noisy online equivalents. Since I have disposable income, I'm known to play them from time to time, though I'm anything but addicted.
One thing I always do before playing any game, real or virtual, is figure out the odds and the payout ratios. Turns out that some of the games have really lousy ratios, others have pretty decent ratios. The next thing I do is figuring out the rules. The ones you find on the casino web site more often than not leaves a lot in the open. One such crucial piece of information often missing is whether or not you are eligible for Jackpot if you don't play with a maximum bet. Other games claim that "the more you bet, the higher the chance of winning". While true, the difference is so small that it really doesn't matter most of the time. A ten-fold increase in your betting amount will have a minuscule impact on the probability of winning.
A bunch of people out there play certain online games for one reason only: they're hoping to bring home the big prize. The jackpot. The life-changer.
I'm not going to discuss the probability of actually winning these random drawings (they're insanely low), but I will tell you this: don't pay up until you know the rules. Online casinos are experts in luring you into playing more, and paying more. For instance, the best way to hunt the big price on Mega Fortune (which routinely pays out 3-4 million euros) is to use the minimum bet, but bet on all the lines. A maximum bet all the time will most likely ruin you rather quickly, with absolutely no impact on the probability of winning. Lowest bet, then put the "autoplay" feature to good use and hope for the best.
So in the example of Mega Fortune, some sites state that you have to employ a maximum bet, others says you don't. The game providers (NetEnt) says you don't, so don't...
Morale: if in doubt, send a mail to the game supplier - not the casino company.
One thing I always do before playing any game, real or virtual, is figure out the odds and the payout ratios. Turns out that some of the games have really lousy ratios, others have pretty decent ratios. The next thing I do is figuring out the rules. The ones you find on the casino web site more often than not leaves a lot in the open. One such crucial piece of information often missing is whether or not you are eligible for Jackpot if you don't play with a maximum bet. Other games claim that "the more you bet, the higher the chance of winning". While true, the difference is so small that it really doesn't matter most of the time. A ten-fold increase in your betting amount will have a minuscule impact on the probability of winning.
A bunch of people out there play certain online games for one reason only: they're hoping to bring home the big prize. The jackpot. The life-changer.
I'm not going to discuss the probability of actually winning these random drawings (they're insanely low), but I will tell you this: don't pay up until you know the rules. Online casinos are experts in luring you into playing more, and paying more. For instance, the best way to hunt the big price on Mega Fortune (which routinely pays out 3-4 million euros) is to use the minimum bet, but bet on all the lines. A maximum bet all the time will most likely ruin you rather quickly, with absolutely no impact on the probability of winning. Lowest bet, then put the "autoplay" feature to good use and hope for the best.
So in the example of Mega Fortune, some sites state that you have to employ a maximum bet, others says you don't. The game providers (NetEnt) says you don't, so don't...
Morale: if in doubt, send a mail to the game supplier - not the casino company.
OSNews and the day it died
Back in the day, I spent most nights building operating systems for fun, and a fair amount of time helping other OS hobbyist. In fact, once I got good "osdev-ing", helping others was the real kick.
The old mega tokyo (now osdever) forum was the primary place to hang out, along with the insanely troll-infested #osdev channel over at Freenode.
But the place to look for news, in-depth interviews and interesting articles was OSNews.com. The reason it was a great site, despite its narrow focus, was good editors. Some of the interviews are in my view an important part of computer history. Some of the obscure operating systems discussed actually became useful and are still under development (Haiku, Syllable, amiga os variants, etc.) Others are just obscure, but open sourced and thus useful for others. Some of the interview objects have gone to other interesting ventures.
Unfortunately, at some point a new editor came along. Thom Holwerda. With his dutch arrogance and not-so-great insight into operating systems, he slowly began to tear down the original concept and basically started a personal blog with the occasional guest contribution. He has been quite frank about it too, through comments ("I don't care what our readers think") and pretty clueless posts explaining how the site is no longer about alternative operating systems.
In fact, the only contributions he have made in that area is whining about SkyOS's slow development, and "explaining" how non-mainstream OS's are irrelevant. Let's just face it. OSNews is now just another generic technology blog (with high volume on uninteresting comments, and low volume on actual original articles.)
The point of this post? If anyone wants to start up a new "alternative OS" site, there's at least one avid reader awaiting the announcement. Alternatively, Thom will go bark up some other wrong tree.
The old mega tokyo (now osdever) forum was the primary place to hang out, along with the insanely troll-infested #osdev channel over at Freenode.
But the place to look for news, in-depth interviews and interesting articles was OSNews.com. The reason it was a great site, despite its narrow focus, was good editors. Some of the interviews are in my view an important part of computer history. Some of the obscure operating systems discussed actually became useful and are still under development (Haiku, Syllable, amiga os variants, etc.) Others are just obscure, but open sourced and thus useful for others. Some of the interview objects have gone to other interesting ventures.
Unfortunately, at some point a new editor came along. Thom Holwerda. With his dutch arrogance and not-so-great insight into operating systems, he slowly began to tear down the original concept and basically started a personal blog with the occasional guest contribution. He has been quite frank about it too, through comments ("I don't care what our readers think") and pretty clueless posts explaining how the site is no longer about alternative operating systems.
In fact, the only contributions he have made in that area is whining about SkyOS's slow development, and "explaining" how non-mainstream OS's are irrelevant. Let's just face it. OSNews is now just another generic technology blog (with high volume on uninteresting comments, and low volume on actual original articles.)
The point of this post? If anyone wants to start up a new "alternative OS" site, there's at least one avid reader awaiting the announcement. Alternatively, Thom will go bark up some other wrong tree.
Subscribe to:
Posts (Atom)