orib

And who writes the libraries? I'd suggest that if you're only gluing together libraries, much of a rigorous CS training is wasted anyaways. You could do just fine with very little formal training on algorithm design and analysis, and a rather shaky understanding of the fundamentals of algorithms, if that's all the programming you do is. You're probably better off with a trade school.

If you're going to be doing anything challenging in the programming domain, you'll want a good grounding in concurrency.

I've seen projects with more tests than code, and I think that shows a problem with development methodologies. Simply reasoning about the flow through the code (and possibly using a powerful type system [think Ocaml] to help catch errors at compile time) would remove the need for many of these tests (not all tests should go, of course) and would result in tighter code.

I remember reading about a study about a very different style of development from years ago, where automated testing was NEVER done, but instead formalized models of the program were created and mathematically verified.

If I remember correctly, the final result was a similar level of quality to an extensively tested system developed today, and the code tended to be of somewhat higher quality thanks to the extra thought put into it. (But I'm only going off vague memories here... I might be misremembering)

I can't think of any consumers that want to upload as much as they download.

Well done.

edit: Ignore this post. I misread. I'm an idiot. Sorry about that

Add to that the slowdown of propagating in a fiber optic cable, and you've just increased the time to 150 ms.

So, for a server 1/4 of the way around the world, you're stuck with a minimum round trip time of 75 ms. This will be increased by switching times in repeaters, for example. And that's only for one data packet.

It gets massive number of page views, and is very popular, but business isn't a popularity contest. If you can't figure out how to make money, you're not a successful business.

I find a pinch of skepticism goes a long way.

As far as Ubuntu's update process, these updates were small point updates in the middle of the release cycle, which is why they were so disturbing; it seems that Debian's "constantly up-to-date" system works better for me, at least so far.

In one update, Ubuntu pretty much broke the PCI detection code in X, so that X always thought that there were no cards. Luckily, it was only a matter of waiting several hours for a fix, and updating from a text console.

In another update, the Canadian english localization completely broke KDE, making it segfault on startup. Again, wait a day or two and update from a text console.

Right now I'm on vanilla Debian (unstable branch) and I find that it has had less critical breakage than Ubuntu's mainline branch. I'm not sure how Ubuntu should update their QA process, though.

Part of being young is not listening and trying to find your own way.

For the free market economy to work, a number of assumptions are made in the model. For example, we assume that consumers are well informed, and make judgements on the product's attributes. We also assume that there are no significant externalities, and all costs are actually exposed to the companies.

Labelling the foods with their actual properties, testing them for safety, and other similar government intervention can actually bring things closer to the ideal free market economy where the consumers know what they're buying, and the costs of environmental cleanup are passed on to the companies causing the damage.

The 'em' unit is equal to the computed value of the 'font-size'...

Therefore, em is in units of font size, and is not independent of it. It's totally unrelated to 'px' values, except by luck. Not all browsers default to 16px text. (And yes, it's true that px are actually defined as the distance subtended by an angle of 0.0227 degrees at a typical viewing distance of the device, but they're typically used interchangably with screen pixels)

Actually, the size of an 'em' isn't even defined relative to the size of a pixel by the CSS spec, so the claim in the article is dead wrong about it helping you use em when you mean 10 pixels. 62.5% of an unknown value isn't 10 pixels.

If a website is properly designed, it should scale just fine no matter what the font size is. If you need a fixed pixel size for a font to make your design work, you're doing it wrong. And to top it off, a fixed pixel size requirement means it'll break anyways on different systems with different fonts, kerning and hinting options, and other settings.b

     My suggestion for you is to do the following: start
     your CSS stylesheet with

     html {
       font-size: 62.5%;
     }

Really, I'd be fine with any fast distributed VCS, which means nearly all of them these days. (sorry Darcs). The ease of setup ("If you have SSH you have a git server") feature is also very nice, but I don't think it's exclusive to git.

Did you realize that your master/ branch is just one such long-running branch, and one that's not special in any way other than being the default for some commands...

As far as multiple committers on one branch -- well, you can do it, but with 'git rebase' and friends, it's just easier to do your own work on a short lived branch off your primary branch, and just merge in stuff as you get it done.

It's not that git makes it difficult to do it compared to other version control systems; it's just that it's a nicer workflow if you use short-lived topic branches to do development because you don't to worry about what other people are doing until you decide you want to take a look at it and merge it in. The short-lived private branch + lots of merges workflow is just easier because it prevents interruptions in your workflow.

As far as emailing patches, it's a matter of taste. It's certainly easier to make sure all changes get reviewed if patches are mailed around, because people tend to read their mails. Personally, I just use a post-update hook to mail out a list of changes for each commit, and review them later, since it's always relatively easy to back out or fix a patch -- after all, it is a version control system.

And of course, this isn't the first time the cycle repeasts.