rc3.org

Strong opinions, weakly held

Month: July 2007 (page 3 of 4)

On the iPhone, you’re always root

iPhone hackers seem to have discovered that all of the applications run as root. In the world of Windows, that’s no big deal. In the world of Unix, it’s unheard of. As Andrew Shebanow points out, it also explains why third party developers aren’t yet allowed to publish iPhone applications.

Alberto Gonzales lies about everything

Remember when Alberto Gonzales said that there have been no cases of civil liberties abuse with National Security Letters? Turns out that’s not true, and Gonzales knew it wasn’t true. It’s pathetic that nearly all of federal law enforcement reports to this guy.

Israel is pondering Internet censorship

Shas, a far-right Israeli political party, is trying to pass legislation that would restrict access to certain content to adults who sign up for a special license. The content is the type of stuff that all politicians seem to want to censor. Needless to say, such a bill would require the implementation of a new identification system and a huge amount of networking hardware to provide the infrastructure for applying censorware to all of Israel’s Internet connections.

Of course such a law would be horrible for Israel, but it’s not good for anyone else either. The article mentions that Israel is trying to adopt laws from Australia and Europe, and there seems to be a global trend toward “harmonization” on issues like these. So the more countries that pass dumb laws, the more likely it is that other countries will do so as well.

Design documents for small teams

I read that at Google, engineers create a design document for just about every project they work on. It led me to think about how I might incorporate design documents into my usual work practices. I’m looking for processes for teams of one or a few people. Here’s what I hope to get out of a design document:

  • Describe the requirements for the feature (or set of features) described by the design document.
  • Enable the writer to clarify their own thinking on the design of the feature being described.
  • Enable the person who’s requested the feature to be able to review the design to make sure their requirements are being met.
  • Enable other developers to review the design document to find flaws and suggest improvements.
  • Enable anybody who’s going to be working on the product a year down the road to review the design document and figure out what the code they’re working on is actually supposed to do.

UML

So what goes into a design document and how do you structure it? For a bit of guidance, I looked at the types of UML diagrams that are available. I’m not a huge fan of UML, but the theory behind it is that a full suite of diagrams models a system in its entirety. Here’s how I rate the various diagrams in terms of their conceptual utility. There may be better ways to represent the concepts in the diagrams that UML.

Class diagram Describes the objects in an object-oriented system and their relationships to one another. Indispensable.
Component diagram Basically a higher level class diagram
Composite structure diagram Not even the guy who documented it found it useful
Deployment diagram Describes the actual deployment environment for an application. Useful if you are speccing out deployment (or recommended deployment).
Object diagram Basically a class diagram with actual data filled in. A fancy word for “example”.
Package diagram Shows the components of a system at a higher level than the class diagram. Utility is marginal at best.
Use case diagram I’m not in love with these diagrams, but the concept behind them is essential to design.
Activity diagram Some call it a flow chart. It’s hard to describe any complex design without something along these lines.
State Machine diagram More specific than an activity diagram, which is more specific than a use case diagram. Useful when you’re modeling something too complex to be captured in the activity diagram.
Sequence diagram Shows how messages are passed within a system. Only useful if generated from code. Too granular otherwise.
Communication diagram Describes relationships between objects in a system in terms of the messages they pass. Again, very granular, but a nice thing to have if you can generate it.

I don’t want to dig too deeply into UML, but I did want to bring it up because it’s somebody’s idea of how to describe a system. It’s important to remember that the ideal use case for UML is in a system where the diagrams are coupled with the code itself, so altering your code updates the diagrams and vice versa. No programmer has enough time to create all of those diagrams by hand and keep the diagrams in sync with code as the system evolves over time. That’s not how UML is used, ideally. Unfortunately, the UML tools that are out there have never been compelling enough to me to bother with them.

The Wikipedia Definition

Wikipedia’s page on design documents is short and nominated for deletion. It lists four sections for such a document:

  • Data design
  • Architecture design
  • Interface design
  • Procedural design

I don’t think that’s quite right either because it leaves out use cases, which are necessary if you are serious about user experience. If you don’t how who’s going to use your application and what they hope to accomplish, you’re never going to get the interface right. So here’s a stab at what I think a design document ought to contain.

A Rough Draft

So here are the elements that I think should appear in a design document, even for a relatively small project. I don’t care whether they are diagrams or narrative. Some things are better described in pictures, but at the same time, some of us are better writers than illustrators.

What’s the value? Persuade the reader that the feature is worth implementing in the first place. What’s the purpose? Why are you writing it instead of using something that already exists?

Use case analysis. Who will be using this feature and why? If you’re writing a library, the users will be developers who incorporate it into their own code. If you’re writing a Web application, the user may be a customer who wants to buy something, or a back office employee who’s fulfilling an order, or a writer who’s trying to publish an article. Will this application be used by the same people on a daily basis or will it be used only occasionally by a large group of people? How knowledgeable are these users? UML provides a use case diagram, but this is probably a section I’d prefer to write out.

How is it supposed to work? A high level technical overview of how the feature will be implemented. I’m not looking for extreme detail here, just a high level overview of how the feature will work in a technical sense. Are you writing this in Java, PHP, or Ruby on Rails? Will you be using a relational database or flat files for data storage? Are you going to integrate the components via a Web service or are they parts of a single application? If it’s a Web application, will you be using an MVC framework? Will you be using a library to handle the persistence layer? The purpose of this section is to give an idea of the scope of the project and what the risks are in terms of completing it successfully. I can also use it to figure out which members of the team might be able to apply their expertise to this problem.

What are the dependencies? You can figure out some of the dependencies from the technical overview, but this section makes the dependencies explicit. Is this project going to introduce a dependency that we can’t rely on in the future? Are we about to build something that the infrastructure people aren’t comfortable deploying? Does anyone in the office know anything about the tools you’ve chosen to implement this feature?

What will be affected? Closely related to the dependency question, this seeks to help everyone figure out what impact this feature will have. Are we going to need to add more RAM to the database server? Is it going to increase our bandwidth requirements? Does it make our reports obsolete? This is one of those questions with no authoritative answer, but the developer should try to anticipate the impact of the feature they want to implement.

Class diagram. If you’re not building an object-oriented system, then an entity-relationship diagram may make more sense. Either way, this diagram describes the structure of your system at a low level. It documents which classes you need to create, how they are represented in the database, and the relationships between them.

How does that sound for a first draft for a design document? What would you add? I expect to revisit this topic soon.

You never know who might be paying attention

One of the weird things about blogging is that while I would hope that the various criticisms (constructive and otherwise) that I post would someday be read by the subjects of criticism, I never actually expect that it will happen. Is Dick Cheney ever going to swing by and decide to quite promoting torture because some loud mouthed software developer takes him to task for it? Is the person responsible for the email application on the iPhone going to see that I, like Walt Mossberg, am in favor of adding a feature enabling users to delete multiple emails at once? Granted, some of my posts have reached the subjects of those posts, but I’m always surprised.

The reason I bring this up is that Dave Cameron at Seattle Mariner fan blog USS Mariner wrote an open letter to the Mariners’ pitching coach complaining about Felix Hernandez’ pitch selection. Lo and behold, the coach, Rafael Chaves, read the letter and passed it on to Hernandez, who went on to pitch eight scoreless innings a couple of days ago. Astounding. (via Tecosystems.)

An iPhone gripe

Walt Mossberg zeroes in on one of my iPhone gripes:

Unlike on a BlackBerry or Treo, the iPhone doesn’t allow you to delete whole groups of email en masse by date, or even to select large groups and then delete them en masse. This would be a good feature for Apple to add down the line.

Deleting every email individually is a big pain. I’d even be happy a “delete the whole inbox” button.

Testosterone makes you spiteful

An economic experiment confirms the effect of testosterone on decision making.

Terrorism doesn’t work

Bruce Schneier posts a link to a paper that shows that terrorists fail to achieve their political objectives almost entirely. Terrorists succeed in killing people, scaring people, and pissing people off, but they don’t succeed in achieving the political change that they hope for. Clausewitz famously said that war is politics by other means, and I’d add that terrorism is war by other means. The obvious joke is that terrorists should read academic papers concerning their field of endeavor, or at least read blogs on the same subject, but I suspect that for most terrorists the violence is more attractive than the achievement of political aims.

Google acquires GrandCentral

I’m not surprised to read that Google acquired GrandCentral. GrandCentral provides a single phone number that will reach you anywhere, and a single voice mail box to go with it. I haven’t used GrandCentral, but I did use a similar service from CallWave right up until my iPhone was activated. (I wonder who’s going to buy them?)

I think that companies like these represent one front on the assault on telcos and their customer-hostile policies. The first front is voice over IP. I have Time-Warner digital phone instead of a regular phone line. It saves me quite a bit of money on my phone bill, and the service is just as good as the rotten service I used to get from BellSouth.

The second is the iPhone. As many analysts are saying, Apple has siezed some power from the cellular carriers. That’s a good thing. Surely Nokia, Sony Ericsson, Motorola, and the other handset makers are going to demand the opportunity to innovate, and the carriers are going to have to grant it or the iPhone will eat their lunch.

GrandCentral and CallWave provide a way around some of the other telco stupidity that we all put up with. As far as the telcos are concerned, voice mail has hardly advanced in the past 20 years. CallWave’s service is an incredible improvement over plain old voice mail. When someone leaves you a voice mail you get a text message that contains actual information about the call, plus an email that provides a link to your voice mail so that you can listen to it on your computer. They’ve recently launched a voice mail to text service that converts the content of your voice mail to text and sends it to your phone. GrandCentral provides even more services, plus the single phone number that liberates you from all of the other phone numbers that you rent from the phone company.

It’s no surprise that Google is jumping into this market. Smart companies are seeing that the world of telephony is ripe for revolution.

eMusic/Internet radio mashup

eMusic Radio is a cool tool that enables you to listen to Internet radio and view the eMusic downloads associated with whatever’s playing on the radio at the same time.

Older posts Newer posts

© 2024 rc3.org

Theme by Anders NorenUp ↑