Archive

Archive for July, 2005

Harry Potter - the weekend’s biggest entertainment

July 16th, 2005

Two years ago, I wrote about how Harry Potter and the Order of the Phoenix’s $90 million haul was bigger than that of Hollywood’s biggest movie of the week. With reports of Harry Potter and the Half-Blood Prince selling through more than 10 million copies *today*, this book is debuting bigger than any movie has ever debuted. If Amazon’s $17 price is at all representative, that means that Half-Blood Prince will have a $170 million day.

Oh, and if the spolier Stallman posted a couple days ago turns out to be accurate, this is going to be a helluva story.

Money

Shortcut to Stronger Writing

July 16th, 2005

Sci-Fi author C.J. Cherryh offers tips on improving your writing. With so many people writing so many blogs, good writing tips are a welcome thing. Many blogs use “conversational” writing… but, if you’re interested in the tips, here they are: Writerisms and other Sins: A Writer’s Shortcut to Stronger Writing.

Random

Personal offshoring

July 16th, 2005

For a large software development project, the risks of offshoring development can potentially be huge. For small, specific parts of a project, farming that piece out to someone else can be fairly low risk. This can also apply to very small project, like one you might want done yourself. Ben Hammersley gives a tiny taste of personal offshoring. The internet really does change things.

Money

Configuration management for non-Java apps

July 15th, 2005

Patrick Peak seemed to have misinterpreted no deployment means for a Rails app. I’m certain that we’re talking about “no deployment” during development. Compared to *some* Java environments, it is a big win to be able to just try something and refresh the page. However, especially for folks doing test-driven development, I think this is definitely not the biggest win from Rails.

In Java, it is pretty well standardized that folks bundle up a war file, which they then toss onto their production app server at the right time. Patrick points out that you can change JSPs and even .java files on some app servers, if you wish. But, people certainly don’t do that on production servers.

And the same is true of anyone who’s been doing software for a while, regardless of language. You only need to be bitten once to learn that having a solid production deployment plan and tools is critical.

James Duncan Davidson describes exactly how he deploys Rails apps: Rails: Sandbox, Develop, and Deploy. For anyone who hasn’t been bitten by a bad change on a production server, I’d recommend reading that. He describes a very solid way of going from rapid development to trouble-free deployment.

From Patrick’s article, regarding deployment of a Rails app:

Developers deploy to a testing or production by manually zipping up the project and copying to the server. (Since there is no Ant to do it for you). Anything I’m missing here?

The answer is “yes”. What Patrick is missing is that Perl, Python and Ruby are all excellent “scripting languages” (some are more excellent than others, but I won’t go there…) I know firsthand that moving files around to get just the right subset and zipping up those files is a nice, short script in Python thanks to modules like shutil and zipfile.

My process for Zesty News is similar to what James talks about in his article. Getting a new machine up and running to do development on Zesty News is easy:

1. Install Subversion
2. Check out the project
3. Install a few pre-reqs (Python 2.4.1 primarily. On Windows, there are a couple other things needed to get a sane build environment. That will go away before too long, though.) All of the pre-reqs are right there in the project.
4. In the top directory of the project, python build.py modules. This builds additional components used by Zesty News.
5. At this point, the unit tests and the app are ready to run.

To create an executable, I just run “python build.py app”.

There are all kinds of things that need to happen to pull all of the pieces together. There’s no way I would do that stuff by hand. My “build.py” script and the various commands for it are one of the first things that I did. It’s not a lot of code, and I really don’t miss ant.

Just using agile languages does not imply a lack of good configuration management.

Software Development

Schmozilla!

July 15th, 2005

A short time ago, this site (and my other sites) were all unavailable. And, of course, I couldn’t get on the box to figure out what was going on. When I finally got on there, everything *looked* pretty normal… except for the fact that the load average had climbed to more than 100! Sadly, my server doesn’t have 100 processors and so it was completely hosed until the problem stopped.

It turns out that the problem was someone at 192.114.144.12 (you know who you are!) was running some bot that identified itself as Schmozilla. Apparently, the Perl Cookbook shows you how to do HTTP requests and gives that user agent. Ugh.

Anyhow, one way of dealing with this is detailed here: Blocking Apache Attacks.

Technology

Ruby on Rails and scaling

July 13th, 2005

David Heinemeier Hansson has written a rebuttal to the “it doesn’t scale” argument in defense of Ruby on Rails. It’s a good, concise article that applies equally well to all of the variants of LAMP. If someone is giving you grief about scaling something in Python/Ruby/PHP/Perl or Java without EJB, David’s article and Ryan Tomayko’s earlier article provide good counters so you don’t have to write your own.

Software Development

A Sparklines web service in Python

July 13th, 2005

Here’s a handy article that takes you through designing a convenient web service *and* provides a nice introduction to sparklines, if you’ve never seen them before. XML.com: A Bright, Shiny Service: Sparklines

Software Development

CSS3 Columns

July 13th, 2005

Since I’m running Deer Park, I thought I’d see what CSS3 columns actually look like. Being too lazy to type a few lines into a text file, I googled and found this: Well, I’m Back: Gecko 1.8 For Web Developers: Columns. Lo and behold, that very blog entry uses two columns.

Multiple columns are nice, because you can use the full width of your media without your lines being obnoxiously long and painful to read. However, for reading on the screen I think I’d prefer to waste screen real estate and keep scrolling down vertically. It’s rather annoying to hit the end of the column and then have to scroll back up to the top to continue.

For printing, however, having multiple columns is great. For your eye to jump from the bottom of one column to the top of the next on the same page is very quick and painless.

Sure, when viewing on screen, you can get back to the top just by hitting the home key. But, on screen there is no vertical limit. Why interrupt the flow of reading for no appreciable gain?

Software Development

Attention to detail in Help Spot

July 13th, 2005

I’ve been following Ian Landsman’s development of HelpSpot since the beginning, and it is very interesting to observe his attention to detail. Check out his latest preview. I worked in a network operations center some years back (and developed tools for them as well), so I have an idea about “trouble ticket” systems.

Ian is building software that is “subtly innovative”. If you’re entering an established market and produce something that is wildly different from everything else out there, you’ll have an uphill battle getting people to use it. What I see in Ian’s preview is that he’s providing some new ways of doing things and thinking about things that are unsurprising and natural.

Seems like a great software design strategy: unless you’re in some brand new market and you’re inventing the rules, make the overall experience follow what the user expects, but pay attention to the details because that’s where you can really improve the experience.

Software Business

Trying out Firefox 1.1 (Deer Park)

July 13th, 2005

Since I’m primarily a Mac user these days, I was interested to learn that Firefox 1.1 has improved the user experience for Macs. Things like middle-clicking to open a link in a tab and making the preferences work more like Mac preferences do. So far, after a short time using it, Deer Park seems mighty fast. It also supports interesting things like CSS3 columns. Of course, you can’t use them because no one else in the world is running a browser that supports it, but it’s nice to see the standards support growing.

Deer Park is an alpha, though, so we’ll see if I end up running into stability problems. If I do, Firefox 1.0.5 is out and that reportedly includes stability fixes and whatnot.

Technology