def euler(x); cos(x) + i*sin(x); end

Maybe it’s all the rain during this season. I sure look forward to those dry, maybe sunny days when I notice them on my dashboard weather widget. Alas, I’m often disappointed. A nice, bright sun a few days away mysteriously turns into a cloud or rain drops. It’s a big disappointment. Often I call up the weather station and complain. Why can’t they be more accurate? Why don’t they develop better processes? Sometimes it gets nasty and I threaten to sue them. I mean, if I’ve planned my picnic because Saturday is forecasted to be sunny, shouldn’t somebody have to pay to clean my soggy picnic blanket?

Actually, that doesn’t happen. In fact, we’d consider somebody a tad looney if they asserted that somehow the weather forecast should be guaranteed. We know that science is always advancing but weather forecasting is imprecise because the complexity of the “weather system” ensures it is affected by processes described by chaos and complexity theory. There is an inherent limit on precision.

The most common analogy for software development is some form of construction. In fact, we talk about system architecture, building components, software construction. Creating software is less like building and more like weather forecasting.

Methods and processes for constructing buildings are quite well established. And all buildings share far more commonalities than differences. Most importantly, interacting with buildings involves human cognition in extremely limited ways. Software, on the other hand, involves a tremendous amount of human cognition and social effects. There is conceptualization, definition, communication, attitudes, opinions, assumptions, the entire spectrum of human complexity. Given this, we might be advised to study meteorology as much as architecture.

We might as well accept it now: global warming is real. We live in a finite world with finite resources. Given that, why would we want to expend time and effort building fences. They just sit there. Maybe they contribute to the aesthetic but they won’t help the wheat grow any better in the field. Building them diverts productive capacity from planting, tending, harvesting. Be that as it may, long ago folks realized that good fences serve a purpose.

Fences create boundaries and boundaries define areas. And that’s the value: this is my area, that is yours. Positive relationships also depend on boundaries: this is my responsibility, that is yours. Contracts are like fences: they describe boundaries that define areas. We may be tempted to think that nice, intelligent, professional people can work out differences of understanding without the need for lawyers and contracts. But be not tempted. The jury may still be out on the question of whether there exist nice, intelligent, professional people. But the lawyers are here to stay.

Good neighbors build and maintain fences together. They share the responsibility and share the benefits. Contracts are necessary; collaboration is necessary. Contracts through collaboration. It’s less of a prioritization of values and more a matter that good collaboration generates good contracts, and good contracts support good collaboration. Good!

Warning. Long quote to follow. There, I’ve warned you.

The most useful products are those where the developers have understood what the product is intended to accomplish for its users and how it must accomplish that purpose. To understand these things, you must understand what kind of work the users want to do and how the product will affect that work and fit into the organization’s goals. What the product does for its users and which constraints it must satisfy in this context are the product’s requirements. Apart from a few fortuitous accidents, no product has ever succeeded without prior understanding of its requirements. It does not matter what kind of work the user wishes to do, be it scientific, commercial, e-commerce, or word processing. Nor does it matter which programming language or development tools are used to construct the product. The development process—whether agile, eXtreme Programming, prototyping, the Rational Unified Process, or any other method—is irrelevant to the need for understanding the requirements. One fact always emerges: You must come to the correct understanding of the requirements, and have your client understand them, or your product or project will fail.

Emphasis added. Quoted from Mastering the Requirements Process, 2nd Ed.

To paraphrase: Knowing what you are doing is an absolute prerequisite to successfully doing it. It’s not a guarantee you’ll be successful, but there’s no substitute for it.

Agile means different things to different people. At times, responding to change over following a plan is translated by someone into planning is not agile; just jump in and see what happens because you won’t know until you get there anyway. There’s also the agile concept of not doing more than necessary at each point. So, there’s a tension set up between looking forward to where you’re going and looking down at what you’re doing. Overdoing either get’s you in trouble. Like reading a newspaper while walking through a crowd. Pay too much attention to the people and you don’t get reading done. Read too much and you’ll bump into people.

A few months ago, when Rails was really new, there was this idea circulating that Rails made it so easy, one didn’t even really have to know Ruby to program with Rails. Yeah, uh, right. Unfortunately, claiming to be agile is also often substituted for knowing what you’re doing. It takes a lot of knowledge and experience to balance the tension described above. It takes a lot of judgment to know how much do I need to do right now? Agile is not a substitute for knowledge and experience, although it may guide you to better apply those.

One of the more amazing and wonderful things about the internet is the sheer volume of information available for free. And just like going to a friend’s party, one way to show appreciation is to partake of the feast prepared in honor of the guests. But a lot of the time it’s more like a grocery store than a nice restaurant. Lots of food but not the place to savor the cooking. Once in a while, though, you happen across a gem.

Since everyone has a different background, we’re all learning at our own rates. If you’ve always wanted to understand more about declarative versus imperative languages, syntactic sugar, dynamic versus static typing, tail recursion, lazy evaluation, currying, concurrency, exceptions, computation models, polymorphism, etc. and you’d like to learn about it in a comprehensive, integrated fashion, then definitely grab a copy of Concepts, Techniques, and Models of Computer Programming, here’s a direct link to the pdf. The book teaches the main concepts of computer science using the Mozart Programming System based on the Oz programming language.

Now, for the fun part. If you’re using OS X and have ports installed, getting the Mozart system is as easy as:

sudo port install mozart

There, you’re ready to dive right in. However, one thing will make your experience much easier. Install Aquamacs: Emacs for OS X. Mozart will use it if it finds it, and for me it’s a nicer experience than Emacs in iTerm.

PLANET ARGON’s office is a hop, skip, and a jump (about 3 city blocks) from Portland’s Pearl District, which is a really nice thing for lunch with one’s girlfriend. Everyone knows that girls love to shop, right? Gross over-generalization or not, it’s true. Anyway, while browsing through Anthropologie, I’m of course drawn to any stack of books I see. On a nice diagonal book shelf, I located two quite interesting books: Modern Glamour: The Art of Unexpected Style and China Chic.

Yeah, both a little different than typical books I read, but they got me thinking. First, they have lots of interesting compositions; colors, shapes, arrangements that are a pleasure to look at. Second, the compositions are, of course, much more than just collections of colors and shapes. It’s the arrangement part, the whole design, that got me thinking.

With software, we’re often confronted with a level of granularity that isn’t very useful. If an application has some sort of access control, we may be required to twiddle read/write/execute-type permissions for each object. That’s just an example, but one that is particularly problematic for non-savvy users. The implementation model is bleeding through worse than a horror-flick bloody corpse. At that level of granularity, it’s like all the fabrics, wall-hangings, window-treatments, and furniture are arranged in a nice matrix of boxes in the middle of the room instead of making up the room as a whole.

For one of our projects, we’re exploring how we can create idioms that allow the user to manipulate objects at a much higher level. For example, adding someone as a co-worker to a project allows them to make changes, while sharing the project with a friend allows the friend to leave comments but not make changes.

So, are you creating stylish, integrated, holistic rooms in your software? And where do you find odd inspiration in your everyday life?

One Mephisto feature I really like is saving an article as a draft. Unfortunately, I’m more likely to start an article than finish it. So, I’m looking forward to that auto-write feature that maybe Rick is working on. Until then, I’ll just have to continue finishing them on my own, even if it takes a few weeks. Ahem, like this one.

Inspired by Octopod yet again, I’ve got the best of worlds: Mephisto edge at my chosen version mirrored to my own svn repository for my own hacking, all cap deploy‘d to my VPS.

I decided to put my svn repository on my VPS and develop in that. Basically, I use svk as a fancy adapter with the added advantage that I can update from Mephisto edge whenever it’s convenient for me. Installing svk on Ubuntu 6.06 was a breeze. From there, I mostly followed Octopod’s recipe: First, I create a mirror for Mephisto in my svk repository, then pull in Mephisto.

svk mkdir //mirror
svk mkdir //mirror/mephisto
svk mirror http://svn.techno-weenie.net/projects/mephisto/trunk //mirror/mephisto/trunk
svk sync //mirror/mephisto/trunk

That’s the Mephisto side of the cable. Now, for my local svn side.

svk mkdir //svn
svk mkdir //svn/mephisto
svk mirror svn://svn.brightredglow.com/mephisto/trunk //svn/mephisto/trunk
svk smerge --baseless //mirror/mephisto/trunk //svn/mephisto/trunk

Now, I simply use the sync command above to pull new Mephisto changes to my svk repository and the following command to push those changes to my svn repository:

svk smerge --incremental --log //mirror/mephisto/trunk //svn/mephisto/trunk

From here, it’s pretty simple. I check out a working copy of my svn Mephisto trunk and work normally. Using Capistrano, I can cap deploy or cap rollback to my heart’s content.

Finally, Mongrel + Nginx + Mephisto are working flawlessly. My mongrel processes never get over about 35MB and they hum along day after day, week after week. Sometimes load gets too high for my VPS, but I can live with that. Speaking of VPS, Quantact has recently added OpenVZ options. They’re quiet but dependable. And recently I logged in to my control panel to find that I had 33% more RAM and another gig of disk space. I’m not saying they do this all the time, but for whatever reason they did it, I appreciate it.