This blog is now hosted at consciou.us

Tuesday, March 31, 2009

Why can't we just have data types?

I'm not the biggest fan of object oriented programming. There, I said it.

Also, the world is round, and circles the sun. Regardless of obsoleted dogma.

I just wanted to cook up a hash, containing hashes as values (with a couple levels of nesting). So, what do I end up with, since I'm currently stuck with those, "I know, we'll make everything an object!" languages?

This:

((ArrayList)((HashMap)dicts.get(pattern.get("Dictionary"))).get("Elements")).add(pattern);

That really should have been simple, and it's a great argument for DATA TYPES. Not Objects, not Aspects, just data. Really.

Perl's been accused of being cryptic, but here's the equivalent:

push(@{ $dicts{Dictionary}->{Elements} }, $pattern);
Of course, you don't actually have to do it that way, since perl is actually quite flexible. It has a very limited range of actual data types, but then has many operators that can manipulate the data (in wondrous and fantastic ways!).
Read more...

Saturday, March 28, 2009

Computer Science/Engineering, an analogy



Computer science is to programming as pigmentation science is to painting.

I have asked the same question of people that I have worked with for the last 10-15 years (a long time). Here it is:

Is programming an art or a science?
Before I give you the answer, think about this: when you look at a beautiful building, there is a lot of science involved. But the thing that made it beautiful was not the science, it was the artistry that built on that science.

In case it's not immediately obvious, the near unanimous answer was: it is an art. Anecdotally, the better the person was at getting things done the more likely they were to answer "art", and quickly.

The sooner we get over the idea of programming as an "engineering discipline" or "science", the better.

Next time you hear someone going on about how we need "formal proofs" or "stronger engineering" for applications, ask them: "What have you actually built lately?"

(Image from user LukeGordon1 on Flickr, and is Creative Commons licensed)
Read more...

Wednesday, March 25, 2009

Covington Friday Night Car Shows Getting Ready to Start

It's almost time for the Friday night Covington Car shows to start!

The first Friday in May (May 1, 2009) through the last Friday in September, weather permitting, from 4PM - 8PM.

I have additional information (directions), and pictures, here.

The pictures should be convincing enough, but there are a lot of really nice cars there, the folks are friendly, and it's very family friendly. Take your kids. Read more...

Tuesday, March 24, 2009

The Hundredth Idiot (or, why not to read business books)

One hundred idiots make idiotic plans and carry them out. All but one justly fail. The hundredth idiot, whose plan succeeded through pure luck, is immediately convinced he's a genius.
--Iain M Banks, MATTER
Iain Banks makes one of the most astute observations I've ever read.

This is so applicable to:

  1. The business model de jour: How To Use Social Networks To Facilitate Enterprise Application Development!
  2. The development model de jour: Standing On Your Head To Increase Bloodflow and Facilitate New Development Methodologies!
Now, before you hie off on the "next big thing", remember that most of these "big things" are just hundredth idiots. Or, you can read a book like The Mythical Man Month by Fred Brooks and ask yourself: how is it that a book written 35 years ago, about a project completed 45 years ago is still 95% relevant?

Could it be that there's nothing new under the sun? Read more...

Monday, March 23, 2009

Frame-work (an oxymoron)

One of the most difficult things to learn about project management/development is the difference between adaptability and "does the work for you". People who have not worked with the latter might have a tendency to desire the latter (after all, who does not want less work?), but my experience has been that these types of systems always end up extracting their "pound of flesh". There Ain't No Such Thing As A Free Lunch.

The first time I used Struts, I was enamored of it for about a day. Then I realized what a pain it was to work with. It has been a while since I've used it, but my memory is primarily one of, "What magic incantation do I need to stuff in some random configuration file to actually make this page transition work?"

Another example, Ruby on Rails: I always thought this name apropos. You need to jump off and do some 4-wheeling? No dice, dude! You're on Rails!

How about this description of Cocoon:

Apache Cocoon is a web development framework built around the concepts of separation of concerns and component-based web development. Cocoon implements these concepts around the notion of 'component pipelines', each component on the pipeline specializing on a particular operation. This makes it possible to use a Lego(tm)-like approach in building web solutions, hooking together components into pipelines without any required programming. (emphasis mine)


Hint: anyone who suggests that you can program without programming is suffering from a logical fallacy. The Cocoon folks avoid this by offering that you can "hook together components into pipelines" without programming. How pipelines become applications, that I'm curious about.

I don't mean to pick on specific projects, but I'm just pointing out examples. There are certain advantages to having components, but the end goal should be adaptability and maintainability. Not the mess of an MBean talking to an EJB Session Bean that was looked up over JNDI that talks to a JMX Component that I have seen one too many times. ("See, we've got this framework, but it won't talk to this other framework, so now we're writing a Facade class (ooh! Design Patterns! It must be good!) to expose things to the other framework...")

For whatever reason, this appears to be largely a Java phenomenon. There are more Java frameworks than there are applications built on them!

...well over half of the time you spend working on a project (on the order of 70 percent) is spent thinking, and no tool, no matter how advanced, can think for you. Consequently, even if a tool did everything except the thinking for you -- if it wrote 100 percent of the code, wrote 100 percent of the documentation, did 100 percent of the testing, burned the CD-ROMs, put them in boxes, and mailed them to your customers -- the best you could hope for would be a 30 percent improvement in productivity. In order to do better than that, you have to change the way you think.

Fred Brooks [paraphrased] as quoted from Allen Holub's http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox.html


The main thing that a framework needs to do is stay out of your way. It should not be an impediment to future progress. You should be able to say, "I want to change the sorting algorithm for this list," and be able to accomplish it quickly without the framework getting in the way.

I'm not suggesting that you should go through "Not Invented Here" syndrome, and re-implement wheels, airbags, windshields and turn signals, but that understanding the balance between adaptability and the enforced consistency of a framework. After all:

A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines.

Ralph Waldo Emerson
Read more...

Thursday, March 12, 2009

Now you have two problems

This is a classic quote from Jamie Zawinski:

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

This has made me laugh many, many times over the years, as I've been trying to not weep over some dreadful regular expression. Read more...

Tuesday, March 10, 2009

Dear Mom...

My brother sent me this picture, and while I don't normally post "family" articles, this one will have to be the exception.



That's my mom, racing Purple Jeep. I'm guessing circa 1976-1978. I think she threw out the trophies, but she won races. Read more...

Thursday, February 26, 2009

Google blocking paid apps for Developer Phones

Apparently, if you paid the $425 to purchase an Android Developer Phone (ADP1), you are now a second class citizen. Google decided that you can't have paid applications.

Article here.

It's pretty surprising that they'd do this, since we're basically talking about alienating the most hardcore fans and the developers that make your platform worthwhile. There were a lot of areas where Google either just didn't think things through or rushed to market before things were ready (the Email app!).

Here is the rub, as far as I'm concerned:

Google depends on file permissions to control applications.
The developer phone has the ability to copy paid applications.
*All* rooted phones have the ability to copy paid applications (since using file permissions isn't very secure).

So, Google has decided to punish all users that have the ADP1 version of the operating system (all phones can currently be switched between all the different versions of the OS: US/UK/Europe/ADP). Note that this isn't the same set of users that have the ADP1 hardware; at least one person I know has an ADP1, but has a rooted version of RC33 (the US version).

If you took the time to put a rooted version of one of the consumer versions, then you are unaffected by this. And, since clearly all the people who spent $425 on the ADP1 are merely agents of software piracy, they will all be doing this so they can pirate all the paid applications in the Android Market.

Pirates! Arr.
Read more...

Wednesday, February 25, 2009

Duplicate message ids in the sendmail log

Here's a quick little perl script that can help you find duplicate message ids in your sendmail log. Script and explanation after the break.


#!perl

while (<>) {
($_ =~ /msgid=\<(.*?)\>?,/) && ($msgid = $1);
$ids{$msgid}++;
print $msgid . "\n" if ($ids{$msgid} == 2);
}


Where to use this script? Let's say, hypothetically, that you have email coming in that is causing the mail server to tempfail a message (over and over). Or you have a server that is sending a mail message over and over. This script can help you find those messages quickly.
Read more...

Stem Cell Research (what hill do you want to die on?)

I think that stem cell research is an important avenue of medical research.

Embryonic stem cell research (as opposed to adult stem cell) has ethical issues related to it. Read on, and I'll tell you why embryonic stem cell research might not be such a great idea, and maybe some insight into the organizational management issues related to it.

This post was triggered by an article on the Examiner.

Yet another breakthrough for stem cell research. Make sure you understand, though: that's adult stem cell research. All of the innovation in stem cell research (including actual medical treatments that are available today) is in adult stem cell research.

It makes no sense to me to spend money on embryonic stem cell research, when over ten years of research, and tens or (more likely) hundreds of millions of dollars have been poured into it, to the net result: zero innovation, zero breakthroughs, zero treatments based on it. What a waste of money and time.

Here's the thing though: once it became a political issue, there was a certain camp that demanded that it be pursued, simply because "the other guys" said that they didn't like it. This isn't a discussion of the politics of the issue, but the idea that people will do things that make no sense just because someone else tells them not to. Those of you with children understand what I'm saying.

Now, I've been a victim of this thinking. I even saw it coming, and it still happened.

I worked for someone who could always get me to take action just by saying, "well, if you think you can't do it...". I knew his strategy, but was still susceptible.

In life (and work) we have to be able to take an objective step back, and ask ourselves: is this the hill I want to die on? Is this actually productive, or am I just pursuing it for emotional reasons?
Read more...