Incremental development–grow, don’t build, software. I still remember the jolt I felt in 1958 when I first heard a friend talk about building a program, as opposed to writing one. In a flash he broadened my whole view of the software process. The metaphor shift was powerful, and accurate. Today we understand how like other building processes the construction of software is, and we freely use other elements of the metaphor, such as specifications, assembly of components, and scaffolding.

The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be specified accurately in advance, and too complex to be built faultlessly, then we must take a radically different approach.

Let us turn nature and study complexity in living things, instead of just the dead works of man. Here we find constructs whose complexities thrill us with awe. The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and selfrenewing. The secret is that it is grown, not built.

So it must be with our software-systems. Some years ago Harlan Mills proposed that any software system should be grown by incremental development. That is, the system should first be made to run, even if it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit, it should be fleshed out, with the subprograms in turn being developed–into actions or calls to empty stubs in the level below.

I have seen most dramatic results since I began urging this technique on the project builders in my Software Engineering Laboratory class. Nothing in the past decade has so radically changed my own practice, or its effectiveness. The approach necessitates top-down design, for it is a top-down growing of the software. It allows easy backtracking. It lends itself to early prototypes. Each added function and new provision for more complex data or circumstances grows organically out of what is already there.

The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen, even if it is only a rectangle. One always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build.

(The above is, of course, excerpted from Brooks’s essay.)

Iterative development that delivers frequent releases of working software, and uses feedback to determine the direction of growth for the next increment? And a report of empirical (if decidedly anecdotal) support for the notion?

Sounds pretty Agile to me.

(The full essay is available in The Mythical Man-Month: Essays on Software Engineering, which I recommend to anyone who writes, builds, grows, or otherwise makes software.)

http://stackoverflow.com/questions/1197746/uiactionsheet-cancel-button-strange-behaviour

Long story short, if your launch an action sheet in a view that lives in a UITabBarController, the “hit” box for the cancel button gets shifted in a VERY STUPID WAY!

The solution is to reference the view you’re displaying in by the UITabBarController like this:

[sheet showInView:self.parentViewController.tabBarController.view];

Freaking WOW! Thanks a heap, Apple!

*grumble grumble*

private int MyAwesomeFunction(int pVar)
{
// coding magic
return pVar++;
}

…where pVar = 10, the returned value will NOT be 11!  The returned value will still be 10.  If you want to return an incremented value for pVar, do the following:

private int MyAwesomeFunction(int pVar)
{
// coding magic
return ++pVar; // or return pVar+1;
}

Just a case of postfix vs prefix.  In the previous example, the variable never gets incremented because the postfix operator would get evaluated after the line is processed, but that never happens because we’re returning the pVar.  By flipping to a prefix operator, we guarantee that we evaluate the opperator against the variable before we return it.

It’s also worth mentioning that being a little verbose here is also good.  Explicitly stating that you’re adding 1 to the variable (as displayed in the commented code) is the same number of characters and we eliminate the confusion over what’s getting returned.

Happy Coding!

body
  line-height:1.2em

h1
  color:red

This would render a blank document for /public/stylesheets/foo.css.  You won’t get an error about it, you’ll just get a blank document.  Here’s the thing, when you’re declaring a CSS property, you MUST put a space after the colon.  Failing to do so will just wind up in parsing errors on the sass side.

I hope I’ve saved you some head scratching.

Deploying iPhone Apps to Real Devices

Happy hacking!

He’s made a video answering “10,000 ft view” questions about iPhone game development that people who are new to the platform should hear.  What he’s saying isn’t revolutionary, but it’s a lot of very good advice in 1 spot.

Enjoy and happy hacking!

/Users/[yourname]/[your-app]/vendor/gems: gem unpack [gem name]

It isn’t the end of the world if you don’t do it ahead of time, but it does make life slightly easier.

(2) Remember that when you find a bug, you should write a test for the expected behavior BEFORE fixing the bug.  “The Rails Way” has a great quote about testing:

“It’s not that Rails encourages you to do test-driven development, it’s that it makes it difficult for you not to do test-driven development.” ~Brian Eng

I’ve interpreted this quote into the following mantra:

“It’s not that rails makes it easy to test, it that it makes you pay when you don’t”.

Finding a bug after creating your test suite just means that you missed a test.  Take the opportunity to correct that.

Happy hacking.

Thing 1: FasterCSV is really cool!  It’s easy to use and does exactly what it should.  Here’s Scott Becker’s exporting tutorial.  For importing, i’ve hacked together bits from Peter Larkmund’s travels and the FasterCSV documentation.  Thanks to these tutorials, AMB will give users the ability to upload and export CSVs.

Thing 2: Default values for the win!  If you have a table that has a column for an amount, feel free to set the default value to 0.00.  Otherwise you won’t be able to do the following:

a = Account.new
a.amount += 20

…because a.amount will be nil.  You’ll throw an error and if you just updated a bunch of code, you might waste an hour trying to figure out why you’re throwing an exception.  However, if you declare a default value, you’ll be able to avoid any issues.

If you want me to go into further detail on either thing, just leave a comment.

Thanks for reading and happy hacking.