TipJoy Textpattern plugin

Feb 13, 01:08 PM by Eric Allen

Yesterday I quickly hacked TipJoy buttons into the articles on my site, but my solution was not very elegant or flexible. I have now gone back and put that code into a Textpattern plugin that can be downloaded here. All you have to do is install it like any other Textpattern plugin, and then drop a <txp:tj_button /> or <txp:tj_banner /> tag where you want them to show up.

My Computer Science Rant

Dec 28, 04:44 AM by Eric Allen

If you go to RPI, you’ve probably gotten my Comp Sci rant a few too many times. I was pretty convinced that computer science does not prepare programmers for software engineering before I got to college, but now I’m sure of it. Why don’t we have a software engineering major here?! Anyway, somebody else beat me to blogging about it.

Programming for fun

Dec 2, 04:36 PM by Eric Allen

I must admit I’m a bit of a Risk addict. When somebody had the idea of making it a Facebook app, I jumped on it. So, I’ve been playing a lot of Risk lately, but I’ve been plagued by a question: if you’ve two equally sized hordes against each other, is it better to attack or defend? The defender wins ties, but the attacker gets to roll more dice. I probably could have figured this out mathematically, but I’m a programmer. I chose Ruby because it’s fun and easy to use and whipped up a little program to calculate the odds by facing off two very large armies (100,000 in my version) and seeing who loses more. I was pleasantly surprised (yet again) at the clarity and simplicity of Ruby. I’ve made the source code available online. The project took me maybe half an hour, and it has answered the question conclusively: on average, the attacker will lose only 85 armies for every 100 the defender loses. Therefore it’s better to attack while you have the chance instead of waiting to be attacked if you ignore all other factors.

A Mac virus!

Jun 12, 09:35 PM by Eric Allen

A virus on a mac? No way! you say. Wrong. Microsoft has provided our friends the virus writers with a wonderful cross-platform virus environment: Word.

Read more...

Why Open Source Works

May 26, 08:21 PM by Eric Allen

When I look at the open-source movement, I see hundreds of hours of software development spent creating software that will earn no money. Yes, there is the Stallman model, but most normal users don’t pay for support and don’t expect to do so. I believe that I have finally come up with a conclusion as to why the open-source community is capable of sustaining itself.

I believe that the open-source community is, in essence, a communist community. I’m not trying to label them as commies in a demeaning way, I like the system.All members contribute to a common pool and all take from it. The pool is open-source software.

It may seem like this theory has an obvious hole. Why don’t average users just use the software created by the community? That way, the programmers would just be writing software that is used freely by everyone.The major reason is that most open-source software is hard to use. The programmers, writing software for themselves and other programmers, don’t bother to include a simple user interface. Because of this, most users, used to a simple GUI, can’t cope with the command-line options, scripting extensions, and other things that seem intuitive to a programmer but are indecipherable to many. this way, only other programmers, writing similar code, can easily use the software.

There are leaks from this community, as some more altruistic members try to make the software more usable to the normal user but it usually doesn’t work. There just isn’t the time and/or the funding that a normal software company has to make a stable, easy to use piece of software. I don’t want to give any specific examples because I may upset the programmers trying their best to be good digital citizens.

To sum it all up, the open-source community is a communist group that creates software for each other in their spare time. They maintain a partial lock on their software, to keep most users away, by making the interface intuitive only no the less than casually involved.