Filler

Okay, as I recently mentioned, I’m tired of Mongrel for my Rails apps, so I’m going with Phusion Passenger.

The install was actually tremendously more difficult than they claimed, but I attribute that to my own lack of smarts. I am running on Debian, and installed ruby via the source, but had another version of ruby I’d installed via apt-get (it’s over two years old, hence my desire to install from source), and libopenssl-ruby also installed via apt-get. Somehow or another the ruby I installed from source didn’t pick up openssl support, but debian thought it was there, so when Phusion Passenger’s install told me Just type ‘apt-get install libopenssl-ruby’, I got frustrated fast…. I removed the packages and reinstalled ruby from source and all seems to be well now.

Another minor issue, and one I still don’t fully get, is that while Passenger is supposedly running as my main user, it can’t seem to read things that aren’t world-readable, even if I am the file’s owner! A few permissions tweaks (chmod -R 755 app_dir did the trick, but I’m not sure it’s the best idea) fixed this, but it was still a small point of confusion.

The really interesting issue with Phusion Passenger is that if you’re security-minded like I am, it does not work. My base Apache config includes this:

# Tighten access to the file system.
<Directory />
  # Forbid default access to file system locations
  Order Deny,Allow
  Deny from all
  Options -Indexes
</Directory>

Well, I’m a dummy, so I don’t realize why my Passenger-driven apps are “running”, but unable to access their javascripts, style sheets, images, etc. After a long while of searching, I found that the errors were happening because my default behavior was to disallow everything from being viewed. The really bad part here? It’s clearly spelled out in the troubleshooting section of their guide….

Now, in a normal Rails app, the Rails code handles static files, so you can keep your blindingly-high security in place. But Passenger is meant to be speedy, and letting Apache just serve static content directly is way faster than letting Rails do it.

So to fix this, one just has to say that the given app’s directory is allowed to be viewed:

<Directory /path/to/rails/app/public>
  Options FollowSymLinks
  AllowOverride None
  Order allow,deny
  Allow from all
</Directory>

The following of symlinks and AllowOverride settings are of course a matter of personal preference and security, but you must have the other two lines to let Apache server your static content!

Okay, I’ve had things running for a few hours now, and I’m having a few weird issues. One time when I restarted apache, Passenger simply didn’t start up for some weird reason. A new Rails app I built kept thinking it had bad permissions - I reset the whole dir tree to 777, then 755, then all was well again for no obvious reason. (Yes, I had already set it to 755. I think. Maybe.)

So aside from these issues (which are hopefully just due to my almost nonexistent linux admin experience), so far I’m liking Passenger. I have no idea how it would handle a traffic spike or if it has issues with rarely-used apps, but its Rails-centric approach makes it much nicer for a dummy like me to use. Configuration is a breeze, it auto-spawns and auto-destroys Rails processes as necessary, keeping me from needing to manage memory, it spawns the Rails framework separately from the app, allowing a huge memory savings on multiple apps that use the same Rails version, and it has a really helpful memory stat tool to see how much my apps are really hurting things.

Only the coming months will tell if it’s as solid as Mongrel usually was, but even if it’s only as good (i.e., crashes for no obvious reasons once in a while), I’m sticking with it for its nice configuration options.

Typo seems cool to us Ruby on Rails jerks. Because it’s Ruby on Rails. It has sexy live searching. Um… and like… did I mention it’s Ruby on Rails?

So… yeah. After the thing sucking time and again, and eating too much memory and having funny stability problems, I’ve given up. I have enough annoyances with Ruby on Rails apps (I truly hope mod_rails helps here - stay tuned for my upcoming first impressions) that I wrote myself - no need to make things worse with badly-built open source.

So here I am on Wordpress. I’m willing to bet it’s just another badly-build open source app. The difference, though, is it’s been around the block, and seems to have some stability under the hood. It wasn’t written with the “do what’s cool right now!” approach - it has been more geared toward functionality. So as much as I despise PHP, I can’t deny that this app is much nicer to deal with than Typo ever was. Even the conversion of my old articles was about a 10 minute process, thanks to Will Bridges. And with some minor tweaks, I now have a (hopefully) nicer URL structure.

Yeah, I’ll lose some SEO in the mean time - major site change, loss of something like 50 old URLs, but hell, it’s time for something that isn’t a headache.

I can’t believe this. Simply amazing.

I really can’t.

I’m not even sure this is good enough to fall under my usual “Awesome Software Discovery” banner.

So I work at a place where we use Ruby and Perl a lot, right? The above site is supposedly a “conversion” of O’Rielly’s Perl Cookbook into Ruby. Good idea. But here’s the thing - if you don’t know your ass from a hole in the ground, maybe you shouldn’t be writing a programming guide. Maybe. I don’t know. Am I being too harsh?

The introduction shows this example:

# $defout (or its synonym '$>') is the destination of output
# for Kernel#print, Kernel#puts, and family functions
logfile = File.new("log.txt", "w")
old = $defout
$defout = logfile                 # switch to logfile for output
puts "Countdown initiated ..."
$defout = old                     # return to original output
puts "You have 30 seconds to reach minimum safety distance."

There is no fucking excuse for this kind of programming style. Even a total noob should look at this and say, “What the fuck?”

1. Yes, sometimes you need to redirect output or errors to a file… but the introduction doesn’t explain that this is an exception rather than a rule.
2. Redirecting $defout is very dangerous if the developer doesn’t fully understand 100% of what they’re writing, and the libraries they’re using. (And if they need a perl-to-ruby cookbook, chances are they don’t understand 100% of what they’re writing)
3. Maybe I’m misreading something, but isn’t it significantly safer in an app more than 3 lines long to call .dup on $stdout / $defout when saving the old value? (The answer is “yes,” for my less astute readers)

In any case, here’s how you write to a file in Ruby without making the guy who reviews your code cringe and then stab you in the fucking eye (note that it’s not only safer, but also easier to read and generally doesn’t make you look like a moron):

# $defout, $stdout, and other magic variables are NOT TOUCHED!
logfile = File.new("log.txt", "w")
logfile.puts "Countdown initiated..."
puts "You have 30 seconds blah blah I'm a monkey licker."

Neat!

As I previously mentioned, I like AutoIT a great deal, but I like decompiling other people’s stuff even better. Just a couple days ago, the genius who brought us the only 3.2.6 decompiler released a new version, 2.2. I haven’t kept up like I should, but if cw2k ever gives me the okay, I’d gladly keep up a mirror as he releases new versions. For now, at least, I’ll just try to remember to check back regularly and grab the latest versions.

So if you want my local copy of myAutToExe 2.2, it’s here. If you want to get it from the source, check out either the main forum thread or the actual angelfire site.

Enjoy!

I’ve been using Perl professionally for about four years now. I never really loved the language, but I certainly didn’t hate it quite so much before this job.

There are many obvious reasons to hate Perl: * The hacked-in OOP never impressed me much, but gets really old after working on a very large application for a while. * Exporter is evil - being able to pollute somebody else’s namespace just by their use of your module is truly horrific. Most modules are smart enough to only export things as requested, such as use Foo qw|cool_function|; or use Foo qw|:cool_functions|;. But the fact that you can choose to have your module muck up others’ namespaces is terrible. And the fact that there’s nothing akin to the C++ using namespace Foo; in Perl makes it highly annoying to do things the proper way and not pollute your namespace. * The lack of real exception handling is amazing. Look at how the Error module works sometime if you want to be disgusted. The way it works is so awful, and has some really nasty side effects if you’re not careful (like not being able to return from a try “block” because it’s really a function and not just a code block — or how a missing semicolon generates no errors, but can do some incredibly strange things).

But today a more insidious problem struck. I wanted to make a mock class based on the BerkeleyDB class. When we write a unit test, we need to test that our program logic works, not that the BDB class works, right? So I’ll just write a mock, right?

WRONG! The method we use the most is $bdb->db_get($key, $value), and due to the magic of XS bound to C, the second parameter, $value, gets set to the given key’s value. In a normal Perl function, you must send a value by reference in order to have it changed by a function: normal_method($key, \$value). But we can’t change the calling convention for this mock class to work - the point of the mock is to make it a drop-in replacement used just during testing!

So I looked into method prototypes to fix this for me. A method prototype in Perl is a powerful thing that can allow you to “convert” a normal argument into a reference, such that my mock BDB class would be able to keep the same calling conventions as the real one (which is kind of essential for a mock class). So I did something like this:

# db_get takes two or three arguments - the second is by-reference
sub db_get($\$;$) {
    my ($self, $key, $value, $flags) = @_;
    $value = $self->{$key};
    return 0;
}

Beautiful solution, considering how annoying Perl can be. Just one little problem: class methods can not use prototypes. There is no warning, no errors, no indication of what’s wrong whatsoever. The prototype is simply ignored. Silently. After reading the documentation a while, a coworker was able to point out the problem, and I was forced to use the real BDB class instead of a mock in order to complete my unit testing.

I could, of course, write some XS and C in order to get a mock class built, but that’s just an absurd solution to the problem.

I could also write a wrapper and retrofit all our current code to use the wrapper, such that I have complete control of the new API. The new API for the real and mock wrappers could easily be kept in sync. This, however, is even more absurd a solution, because it requires a lot of code to be changed.

That the inconsistent nature of Perl causes such headaches is just one more reason that Perl sucks. A whole lot.

Now to be fair, Perl wasn’t really meant for large-scale applications when first built. But instead of fixing things the proper way, new features seem to be done in a very band-aid sort of way, instead of fixed properly. Perl 6 will deal with a lot of this, but I suspect the conversion won’t be worth it, considering how many better options there are nowadays.

I’m a huge fan of AutoIt - I think the program is a wonderful tool for administrators as well as casual programmers who just like to mess with stuff. However, I recently discovered that the developer of AutoIt, in an ongoing quest for “security,” has disabled the ability to reverse-engineer autoit scripts!

Now, I’m all for security when people write software, but giving scripts this level of security actually introduces security risks! I just don’t like running some random AutoIt script without being able to look at the source code. If I run a “normal” compiled app, my virus scanner will generally let me know if it’s safe to run. But a script written in AutoIt can so easily be a trojan (or other destructive tool) and nothing can likely catch it because of the nature of scripted programs.

Yes, I’m aware somebody could write a C++ app that’s just as dangerous as AutoIt can produce, but this requires a lot more intelligence and effort than just writing an AutoIt script. AutoIt is made to be pretty friendly for non-programmers.

So to me, this is an absurd limitation - all scripts should be reversible for the sake of security! Luckily for the world, somebody has written a usable decompiler called myAutToExe, and I’m providing a local copy of 2.00 Alpha since the site is hard to find and hosted on Angelfire. For the original and latest versions, go to http://defcon5.biz/phpBB3/viewtopic.php?f=5&p=5735.

Note: I haven’t contacted the author of myAutToExe about this (the page has no contact information). I can’t imagine he’d complain, but if anybody knows a way in which I can contact him, I’m all ears. I’d love to set up a proper mirror.

UPDATE: I’ve updated the link to the latest version since being contacted by cw2k (the author of myAutToExe).

UPDATE UPDATE: Fixed the URL for getting the latest version - apparently the forum site moved.

I’m learning Flash right now. My next few games are going to be built in Flash in order to help me learn, and then hopefully build a nice PBBG using Flash and a dedicated C++ based network server. Should be highly exciting!

Anyway, after scouring the net for an amazing amount of time, I could not find a ToolTip component for ActionScript 3.0 (AS3). Tons for 2.0, but if I am going to be working with Flash, I have to go with 3.0. It’s much nicer for a serious programmer, as well as people who just want to be on the cutting edge.

I pretty much gave up after a few hours of digging, and decided it was time to rewrite somebody else’s code. So the one I found is apparently originally written by “Versus”, then modified by Joseph Poidevin. No idea who they are, no idea how to give them proper credit, because I honestly can’t remember where I found the original, and I changed about 80% of the code so hell, it really doesn’t much matter. The only thing that’s important is their work helped me to write a ToolTip that’s slightly customizable.

The class is fairly basic right now, but it does its job and does it well. You can customize opacity, text alignment, and delay (time before ToolTip shows up). I planned to add more customizations to the thing, but so far I really haven’t had a need, and I’m big on adding features only when you see a real-world use for said features. (Yes, I am aware font customizations will be very useful, but until I need them, I don’t write them)

If you find anything you’d like to add to this, please don’t hesitate to tell me. I may not incorporate all changes, because I want this thing to stay simple, but I’ll certainly consider anything I see.

Without further ado, here it is: ToolTip.as, or a tarball with the directory structure if you’re just too lazy to build it yourself: tooltip.tgz

Example usage:

This is actual code that yours truly is using in an exciting new game that may or may not ever be finished:

ToolTip.init(stage, {textalign: 'center', opacity: 85, defaultdelay: 500});
ToolTip.attach(btninstructions, 'Learn how to play\nScraboggle!');
ToolTip.attach(btnstart, "Begin a game of scraboggle.");
ToolTip.attach(btn_scores, "View the best scores and words, and who got 'em!");

No, children, this isn’t the unbelievable (and fictitious) story of a bad little nerd who finally finds redemption via some amazingly-selfless act. This is, instead, the true story of me, the very selfish nerd who offers something useful to the world in order to make himself (myself) feel superior.

I’ve been into statistics lately, and built a really slick hypergeometric distribution probability calculator. I offer the C++ and Ruby source for free, so if you’re interested in statistics and programming, check it out.

Why do I do this? Simple - for starters, I can always use the publicity. I linked to my page from wikipedia’s article. I never would have bothered to put my code up until I noticed that the only other link (here comes the superiority complex) was to a calculator that’s dog slow and gets odd values in some cases - if your desirables (white marbles) are set to 10 and your sample size (marbles drawn) are set to 20, it will actually show drawing 11 desirables as being possible! Plus it doesn’t show data in a very friendly way, doesn’t really explain the algorithm, and doesn’t offer source code. So I figured I could get some math nerds onto my site by throwing that link there, and more visitors is always good, even if they’re icky math nerds.

The other reason is to impress some C++ loving weirdos at Arena Net. I guess they think a client/server game with strict performance requirements should be written in C++ or something stupid like that. I tried to explain that VB is the only language for programming a serious game, but they just wouldn’t listen.

Anyway, enjoy the code. I licensed it as a “use however the frack you want” kind of license, so if it’s useful to you, just let me know you like it.

Sloccount is my newest Awesome Software Discovery. It’s a great idea, but is far too simple to do what it claims: estimate effort and expense of a product based on lines of code. And really, I wouldn’t expect it to be that great. The model used to estimate effort is certainly not the author’s fault, as it isn’t his model. But that idiot (David Wheeler) doesn’t just say it’s a neat idea - he actually uses this horrible parody of good software to “prove” that linux is worth a billion dollars. For the record, I prefer linux for doing any kind of development. I hate Windows for development that isn’t highly visual in nature (Flash, for instance kind or requires Win or Mac), and Macs are out of my price range for a computer that doesn’t do many games. So Linux and I are fairly good friends. I just happen to be sane about my liking of the OS. (Oh, and BSD is pretty fracking sweet, too, but Wheeler didn’t evaluate it, so neither will I)

The variables

To show the absurdity of sloccount, here’s a customized command line that is assuming pretty much the cheapest possible outcome for a realistic project. The project will be extremely easy for all factors that make sense in a small business environment. We assume an Organic model as it is low-effort and most likely situation for developing low-cost software.

Basically I’m assuming a very simple project with very capable developers. I’m not assuming the highest capabilities when it comes to the dev team because some of that stuff is just nuts - the whole team on a small project just isn’t likely to be having 12+ years experience, and at the top 10% of all developers. But the assumptions here are still extremely high - team is in the top 75% in all areas, and 6-12 years of experience, but pay is very low all the same. This should show a pretty much best-case scenario.

Also, I’m setting overhead to 1 to indicate that in our environment we have no additional costs - developers work from home on their own equipment, we market via a super-cheap internet site or something (or don’t market at all and let clients do our marketing for us), etc.

Other factors (from sloccount’s documentation ):

• RELY: Very Low, 0.75
  • We are a small shop, we can correct bugs quickly, our customers are very forgiving. Reliability is just not a priority.
• DATA: Low, 0.94
  • Little or no database to deal with. Not sure why 0.94 is the lowest value here, but it is so I’m using it.
• CPLX: Very Low, 0.70
  • Very simple code to write for the project in question. We’re a small shop, man, and we just write whatever works, not whatever is most efficient or “cool”.
• TIME: Nominal, 1.00
  • We don’t worry about execution time, so this isn’t a factor for us. Assume we’re writing a GUI app where most of the time, the app is idle.
• STOR: Nominal, 1.00
  • Same as time - we don’t worry about storage space or RAM. We let our users deal with it. Small shop, niche market software, if users can’t handle our pretty minimal requirements that’s their problem.
• VIRT: Low, 0.87
  • We don’t do much changing of our hardware or OS.
• TURN: Low, 0.87
  • I don’t know what this means, so I’m assuming the best value on the grid.
• ACAP: High, 0.86
  • Our analysts are good, so we save time here.
• AEXP: High, 0.91
  • Our app experience is 6-12 years. Our team just kicks a lot of ass for being so underpaid.
• PCAP: High, 0.86
  • Again, our team kicks ass. Programmers are very capable.
• VEXP: High, 0.90
  • Everybody kicks ass, so virtual machine experience is again at max, saving us lots of time and money.
• LEXP: High, 0.95
  • Again, great marks here - programmers have been using the language for 3+ years.
• MODP: Very High, 0.82
  • What can I say? Our team is very well-versed in programming practices, and make routine use of the best practices for maintainable code.
• TOOL: Very High, 0.83
  • I think this is kind of a BS category, as the “best” system includes requirements gathering and documentation tools. In a truly agile, organic environment, a lot of this can be skipped simply because the small team (like 2-3 people) is so close to the codebase that they don’t have any need for complexities like “proper” requirements gathering. Those things on a small team can really slow things down a lot. So I’m still giving a Very High rating here to reflect speedy development, not to reflect the grid’s specific toolset. For stupid people (who shouldn’t even be reading this article), this biases the results against my claim, not for it.
• SCED: Nominal, 1.00
  • Not sure why nominal is best here, but it’s the lowest-effort value so it’s what I’m choosing. Dev schedules in small shops are often very flexible, so it makes sense to choose the cheapest option here.

So our total effort will be:

0.75 * 0.94 * 0.70 * 1.00 * 1.00 *                # RELY - STOR
0.87 * 0.87 * 0.86 * 0.91 * 0.86 *                # VIRT - PCAP
0.90 * 0.95 * 0.82 * 0.83 * 1.00 *                # VEXP - SCED
2.3                                               # Base organic effort

= 0.33647 effort

We’re also going to assume a cheap shop that pays only $40k a year to programmers, because it’s a small company starting out. Or the idiot boss only pays his kids fair salaries. Or something.

Command line:

sloccount --overhead 1 --personcost 40000 --effort 0.33647 1.05

Bloodsport Colosseum

For something simple like Bloodsport Colosseum, this is an overly-high, but acceptable estimate. With HTML counted, the estimate is 5.72 man-months. Without, it’s 4.18 man-months. We’ll go with the average since my HTML counter doesn’t worry about comments, and even with rhtml having embedded ruby, the HTML was usually easier than the other parts of the game. So this comes to 4.95 months. That’s just about 21 weeks (4.95 months @ 30 days a month, divided by 7 days a week = just over 21). At 40 hours a week that would work out to 840 hours. I spent around 750 hours from start (design) to finish. I was very unskilled with Ruby and Rails, so this estimate being above my actual time is certainly off (remember I estimated for people who were highly skilled), and a lot of the time I spent on the project was replacing code, not just writing new code. But overall it’s definitely an okay ballpark figure.

When you start adding more realistic data, though, things get worse.

If you simply assume the team’s capabilities are average instead of high (which is about right for BC), things get significantly worse, even though the rest of the factors stay the same:

0.75 * 0.94 * 0.70 * 1.00 * 1.00 *                # RELY - STOR
0.87 * 0.87 * 1.00 * 1.00 * 1.00 *                # VIRT - PCAP
0.90 * 0.95 * 0.82 * 0.83 * 1.00 *                # VEXP - SCED
2.3                                               # Base organic effort

= 0.4999 effort

This changes our average from 4.95 man-months to 7.3 months, or about 31 weeks. That’s 1240 hours of work, well more than I actually spent. From design to final release, including the 1000-2000 of lines of code that were removed and replaced (ie, big effort for no increase in LoC), I spent about 40% less time than the estimate here.

…And for the skeptics, no, I’m not counting the rails-generated code, such as scripts/*. I only included app/, db/ (migration code), and test/.

However, this still is “close enough” for me to be willing to accept that it’s an okay estimate. No program can truly guess the effort involved in any given project just based on lines of code, so being even remotely close is probably good enough. The problem is when you look at less maintainable code.

Just for fun, you can look at the dev cost, which is $21k to $28k, depending on whether you count the HTML. I wish I could have been paid that kind of money for this code….

Murder Manor

This app took me far less time than BC (no more than 150-200 hours). I was more adept at writing PHP when I started this than I was at writing Ruby or using Rails when I started BC. But the overall code is still far worse because of my lack of proper OO and such. So I tweak the numbers again, to reflect a slightly skilled user of the language, but worse practices, software tools, and slightly more complex product (code was more complex even though BC as a project had more complex rules. Ever wonder why I switched from PHP for anything over a few hundred lines of code?):

0.75 * 0.94 * 0.85 * 1.00 * 1.00 *                # RELY - STOR
0.87 * 0.87 * 1.00 * 1.00 * 1.00 *                # VIRT - PCAP
0.90 * 0.95 * 1.00 * 1.00 * 1.00 *                # VEXP - SCED
2.3                                               # Base organic effort

WHOA. Effort jumps to 0.8919! New command line:

sloccount --overhead 1 --personcost 40000 --effort 0.8919 1.05

This puppy ends up being 3.4 months of work. That’s 14.5 weeks, or 580 hours of work — around triple my actual time spent!

Looking at salary info is something I tend to avoid because as projects get big, the numbers just get absurd. In this case, even with a mere 3500-line project, the estimate says that in the environment of cheap labor and no overhead multiplier, you’d need to pay somebody over $10k to rewrite that game. Good luck to whatever business actually takes these numbers at face value!

But these really aren’t the bad cases. Really large codebases are where sloccount gets absurd.

Big bad code

Slash ‘em is a great test case. It isn’t OO, is highly complex, and has enough areas of poor code that I feel comfortable using values for average- competency programmers. So here are my parameters, in depth:

• RELY: Very Low, 0.75
  • Free game, so not really any need to be highly-reliable.
• DATA: Nominal, 1.00
  • The amount of data, in the form of text-based maps, data files, oracle files, etc. is pretty big, so this is definitely 1.00 or higher.
• CPLX: Very High, 1.30
  • Complex as hell - the codebase supports dozens of operating systems, and has to keep track of a hell of a lot of data in a non-OO way. It’s very painful to read through and track things down.
• TIME: High, 1.11
  • Originally Nethack was built to be very speedy to run on extremely slow systems. There are tons of hacks in the code to allow for speeding up of execution even today, possibly to accomodate pocket PCs or something.
• STOR: Nominal, 1.00
  • I really can’t say for sure if Slash ‘Em is worried about storage space. It certainly isn’t worried about disk, as a lot of data files are stored in a text format. But I don’t know how optimized it is for RAM use - so I choose the lowest value here.
• VIRT: Nominal, 1.00
  • Since the app supports so many platforms, this is higher than before. I only chose Nominal because once a platform is supported it doesn’t appear its drivers change regularly if at all.
• TURN: Low, 0.87
  • Again, I don’t know what this means, so I’m assuming the best value on the grid.
• ACAP: Nominal, 1.00
  • Mediocre analysts
• AEXP: Nominal, 1.00
  • Mediocre experience
• PCAP: Nominal, 1.00
  • Mediocre programmers
• VEXP: Nominal, 1.00
  • Okay experience with the virtual machine support
• LEXP: Nominal, 1.00
  • Mediocre language experience
• MODP: Nominal, 1.00
  • The code isn’t OO, which for a game like this is unfortunate, but overall the code is using functions and structures well enough that I can’t really complain about a lot other than lack of OO.
• TOOL: Nominal, 1.00
  • Again, nominal here - the devs may have used tools for developing things, I really can’t be sure. I know there isn’t any testing going on, so I can be certain that 1.00 is the best they get.
• SCED: Nominal, 1.00
  • The nethack and slash ‘em projects are unfunded, and have never (as far as I can tell) worried about a release schedule. Gotta choose the cheapest value here.

Total:

0.75 * 1.00 * 1.30 * 1.11 * 1.00 *                # RELY - STOR
0.87 *                                            # TURN (the rest are 1.00)
2.3                                               # Base organic effort

Total is now 2.166 effort. New command line, still assuming cheap labor and no overhead:

sloccount --overhead 1 --personcost 40000 --effort 2.166 1.05

Slash ‘Em is a big project, no doubt about it. But the results here are laughable at best. The project has 250k lines of code, mostly ansi c. The estimate is that this code would take nearly 61 man-years of effort. The cost at $40k a year would be almost $2.5 million! With an average of just under 24 developers, the project could be done in two and a half years.

I worked for a company a while ago that built niche-market software for the daycare industry. They had an application that took 2-3 people around 5 years to build. It was Visual C code, very complex, needed a lot more reliability than Slash ‘Em, was similar in size (probably closer to 200k lines of code), and had a horrible design process in which the boss would change his mind about which features he wanted fairly regularly, sometimes scrapping large sections of code. That project took at most 15 man-years to produce. To me, the claim that Slash ‘Em was that much bigger is a great reason to make the argument that linux isn’t worth a tenth what Wheeler claims it is. Good OS? Sure. But worth a billion dollars??

Linux and the gigabuck

I’m just not sure how anybody could buy Wheeler’s absurd claim that Linux would cost over a billion dollars to produce. Sloccount is interesting for sure, particularly for getting an idea of one project’s complexity compared to another project. But using the time and dollar estimates is a joke.

Wheeler’s own BS writeup proves how absurd his claims are: Linux 6.2 would have taken 4500 man-years to build, while 7.1, released a year later, would have taken 8000 man-years. I’m aware that there was a lot of new open source in the project, and clearly a small team wasn’t building all the code. But to claim that the extra 13 million lines of code are worth 3500 years of effort, or 400 million dollars…. I dunno, to me that’s just a joke.

And here’s the other thing that one has to keep in mind: most projects are not written 100% in-house. So this perceived value of Linux due to the use of open source isn’t exclusive to Linux or open source. At every job I’ve had, we have used third-party code, both commercial and open source, to help us get a project done faster. At my previous job, about 75% of our code was third-party. And in one specific instance, we paid about a thousand dollars to get nearly 100,000 lines of C and Delphi code. The thing with licensing code like this is that the company doing the licensing isn’t charging every user the value of their code - they’re spreading out the cost to hundreds or even thousands of users so that even if their 100k lines are worth $50k, they can license the code to a hundred users at $1000 a pop. Each client pays 2% of the total costs - and the developmers make more money than the code is supposedly worth. And clearly this saves a ton of time for the developer paying for the code in question.

If you ignore the fact that big companies can use open source (or commercially-licensed code), you can conjure up some amazing numbers indeed.

I can claim that Bloodsport Colosseum is an additional 45 months of effort simply by counting just the ruby gems I used (action mailer, action pack, active record, active support, rails, rake, RedCloth, and sqlite3-ruby). Suddenly BC is worth over $175k (remember, labor is still $40k a year and I am still assuming a low-effort project) due to all the open source I used to build it.

Where exactly do we draw the line, then? Maybe I include all of Ruby’s source code since I used it and its modules to help me build BC. Can I now claim that BC is worth more than a million dollars?

Vista is twice as good as Linux!

As a final proof of absurdity, MS has a pretty bad track record for projects taking time, and the whole corporate design/development flow slowing things down. Vista is supposed to be in the realm of 50 million lines of code. Using the same methods Wheeler used to compute linux’s cost and effort, we get Vista being worth a whole hell of a lot more:

Total physical source lines of code:                    50,000,000
Estimated Development Effort in Man-Years:              17,177
Estimated cost (same salaries as linux estimate,        $2.3 billion
  $56,286/year, overhead=2.4)

To me these numbers look just as crazy as the ones in the Linux estimate, but MS being the behemoth it is, I’m not going to try and make a case either way. Just keep in mind that MS would have had to dedicate almost 3,000 employees to working on Vista full-time in order to get 17,177 years of development done in 6.

The important thing here is that by Wheeler’s logic, Vista is actually worth more than linux. By a lot.

Linux fanatics are raving idiots

So all you Linux zealots, I salute you for being so fiercely loyal to your favorite OS, but coming up with data like this (or simply believing in and quoting it) just makes linux users appear a ravenous pack of fools. Make your arguments, push your OS, show the masses how awesome Linux can be. But make sound arguments next time.

digg this!

Typo is my blogging software. Written in Ruby on Rails, it seemed like an ideal choice for me since I’m a big fan of the RoR movement. But like so many other open source applications, Typo has got some major problems. I’m not going to say another open source blog would have been better (though I suspect this is true from other pages I’ve found on the net), but Typo has been a major pain in the ass to upgrade.

For anybody who has to deal with this issue, I figure I’ll give a nice account here.

First, the upgrade tool is broken. If you have an old version of typo that has migrations numbered 1 through 9 instead of 001 through 009, you get conflicts during the attempt at migrating to the newest DB format. You must first delete the old migrations, then run the installer:

rm /home/user/blog_directory/db/migrations/*
typo install /home/user/blog_directory

Now you will (hopefully) get to the tests. These will probably fail if, like me, your config/database.yml file is old and doesn’t use sqlite. Or hell, if it does use sqlite but your host doesn’t support that. Anyway, so far as I’m concerned the tests should be unnecessary by the time the Typo team releases a version of Typo to the public.

Next, if you have a version of typo that uses the components directory (back before plugins were available in Rails, I’m guessing), the upgrade tool does not remove it. This is a big deal, because some of the components that are auto-loaded conflict with the plugins, causing all sorts of stupid errors. That directory has to be nuked:

rm -rf /home/username/blog_directory/components

This solves a lot of issues. I mean, a lot. If you’re getting errors about the “controller” method not being found for the CategorySidebar object, this is likely due to the components directory.

Another little quirk is that when Typo installs, it replaces the old vendor/rails directory with the newest Rails code. But it does not remove the old code! This is potentially problematic, as I ended up with a few dozen files in my vendor/rails tree that weren’t necessary, and may have caused some of my conflicts (I never was able to fully test this and now that I have things working, I’m just not interested). Very lame indeed. To fix this, kill your rails dir and re-checkout version 1.2.3:

rm -rf /home/username/blog_directory/vendor/rails
rake rails:freeze:edge TAG=rel_1-2-3

My final gripe was the lack of even a mention that older themes may not work. I had built a custom typo theme which used some custom views. But of course I didn’t know it was the theme until I spent a little time digging through the logs to figure out why things were still broken. Turned out my theme, based on the old Azure theme and some of the old view logic for displaying articles, was trying to hit code that no longer existed. Yes, my theme was using an old view and the old layout, both of which were hitting no-longer-existing code. But better API coding for backward compatibility would have made sense, since they did give you the option to use a theme to override views and layouts. Or at the very least, a warning would have been real nice. “Danger, danger, you aren’t using a built-in theme! Take the following precautions, blah blah blah, Jesus loves you.”

How do you fix the theme issue, though, if you can’t even log in to the blog to change it? Well, like all good programmers who are obsessively in love with databases, the typo team decided to store the config data in the database. And like all bad open-source programmers, they stored that data in an amazingly stupid way. I like yaml, don’t get me wrong - it’s amazingly superior to that XML crap everybody wants to believe is useful. But in a database, storing data in yaml format seems just silly.

<rant>

Sorry. Anyway, how to fix this - the database has a table called “blogs” that has a single record for my blog. This record stores the base url and a bunch of yaml for the site config. You edit the field “settings” in the blogs table, and change just the part that says “theme: blah” to “theme: azure”. If you don’t have access to a simple tool like phpmyadmin, then you’ll likely have to retrieve the value from your mysql prompt, edit it in the text editor of your choice, and then reset the whole thing, making sure to use newlines properly so as not to screw up the yaml format…. Then you are up and running and can worry about fixing the theme at your leisure.

Now, to be fair, I think I could have logged in to the admin area without fixing my theme, and then fixed it there. But with all the problems I was having, I thought it best to set the theme in the DB to see if that helped get the whole app up and running. Obviously it wasn’t the theme that was killing my admin abilities (and I can’t even remember anymore what it was). But once I hit that horrible config storage, my stupidity felt ever so much smarter compared to the person who designed typo’s DB.

Typo is pretty sweet when you don’t have to delve under the hood. But “little” things like that can make or break software, and I hope to <deity of your choice> that the next upgrade is a whole lot smoother.

UPDATE UPDATE HOORAY

One more awesome annoyance. It seems all my old blog articles are tagged as being formatted with “Markdown”. When I created them, I formatted them with “Textile”. If you’re not up on these two awesome formatting tools, take a look at a simple example (the first is how Textile appears when run through the Markdown formatter):

• This “website”:http://www.nerdbucket.com is really sweet, dude!
• This website is really sweet, dude!

I’ve been using Markdown lately as I kind of prefer it now. But my old articles are in Textile format. I don’t know why upgrading my fracking blog loses the chosen format, but boy is it fun going through old articles and fixing them!!

Digg this!