My Development Philosophy Or Something…
I’ve had a few emails asking me what my development environment is like and what IDE I use and whatnot. Here’s a screenshot of what things tend to look like on my desktop when I’m working on iApp-a-Day apps: (click for a bigger pic)
Yes, that’s the super-simple UNIX text editor nano there in the foreground window… without color syntax highlighting or anything remotely fancy (it’s all defaults). The background window shows some recent output from make.
What I do is I write code in one window and tend to only have one source file from my project open at a time. (I’ll open other windows to reference past projects or sample code or some other stuff like that if I need to.) When I’m ready to compile, I switch to the build window and run make and scp which builds and then copies the binary to my iPhone. Often I have an additional window with an ssh connection to my phone so I can quickly launch the app and not waste time picking up my phone and tapping on the icon. 
That’s it. Very simple. I’m one of those developers that does not believe highly in syntax highlighting of code while coding. (I love it when looking over other people’s code or when I just want a high level view of it.) I think that using it while writing the code itself causes people to lose sight of what their own code is doing. After awhile you recognize color patterns as being “right” and I think you mentally skip over whole sections of text without trying to understand it - often only to discover (hours later) that some bug was right there in front of you in the “correct” code that your brain was sure was okay simply because it had some specific color pattern. IMO, not using syntax highlighting has caused me to get a whole lot better at spotting where errors are because I’m actually looking at the code and the meaning.
Another thing that I do is I rebuild and test-run constantly - even after some really minor changes. That does kill some production time now and then, but it also helps me avoid the classic problem of changing too many things at once and then not being able to track down where some new behavior was introduced. Obviously this doesn’t always scale, though… I’ve worked on larger projects where doing a build took a long time and running the app to test every little thing was downright impossible - but personally, I think that whole model is just plain wrong anyway. Applications should be built from components that are independent as much as possible and therefore easy to develop standalone and only later integrated into the final whole once the parts are known to work.
So that’s a brief look into how I develop all the apps you’ve been enjoying (or hating, as the case may be). It feels like I’ve skimmed over a bunch of details I’ve wanted to share - but since I can’t think of them right now, I guess I’ll end it here.
November 26th, 2007 at 7:31 pm
Cool! Keep up the good work mate.
November 26th, 2007 at 8:39 pm
Part of that may be true, in that I sometimes skip over sections of my own code while debugging. But, I believe that wasted time is offset by the time saved by the coloring of the code, and how fast I can find something by just scanning for what I am looking for.
As for the constant test-runs, I do that as well because trying to find in an error when you just added multiple changes to your code.
But either way, it’s really just to differences of programing style but hey, thanks for the nice read and outlook on things.
November 27th, 2007 at 9:47 am
I wonder how Leopard’s time machine might change incremental programming style. Just backtrack in time to a working version and see deltas.
I’ve been playing with how Vizster may be applied to writing programs. About as different from your approach as it gets.
BTW, this is my first post, so many redundant thanks for you work!
November 27th, 2007 at 10:16 am
@warren:
(Not any iappaday projects so far, though…) It may possibly help with some code rollback, but certainly it wouldn’t be ideal as it takes snapshots only every hour or so.
I expect time machine to help a lot with certain classes of problems. I’ve actually lost whole projects because of my own stupidity that time machine would have been able to recover for me.
I googled Vizster and saw a cool screen with a bunch of interconnecting lines.
I’d love to see code that way at times. Not all the time, maybe, but I’d love to see a breakdown of how modules/functions/objects interconnect and what their relationships are. I’m not entirely certain any of the mainstream languages expose enough meta information to build an accurate map like that. I haven’t studied it, though. 
I’m not claiming my coding approach is all that efficient - but it works in the context of the languages I’m using and the style of coding I’m doing. Personally, I keep longing for something Smalltalk-ish in terms of development - but every-time I’ve tried to actually do anything using a Smalltalk, I tend to get hung up on the overly complex or ugly GUI. (*cough* Squeak… *cough*)
December 5th, 2007 at 9:47 am
Hey Sean, a slow reply this is (anyone out there?)
Here’s a link to a Vizster approach applied to code: http://muse.com/tr3/viz.html - the first link downloads a Java jar file and then wait for the 3 meg XML before it starts up. Playing with the sliders expands out the degree of interest and clustering.
I don’t actually *develop* with this yet as an IDE. It still needs some work to be both interactive and simple. But, I’m inspired by pluggable modules, like MAX and Quartz Composer - and by patchbay GUIs like Propellerhead’s Reason.
I like the idea of experimental coding: take a piece of code, plug it in and see what happens. This is what is so appealing with the iAppaDay approach. Lots of small self contained examples to play with.
December 15th, 2007 at 6:17 am
very interesting, but I don’t agree with you
Idetrorce
December 16th, 2007 at 6:34 am
@warren
I’m pretty sure it won’t change incremental programming too much, as most people are already using some form of version control (cvs, svn, bitkeeper, etc). There’s nothing new about the concept, it’s just applying version control to the an entire filesystem.
That still means it’s wise to not change too much without testing, because even with diffs (deltas), it can be lot of work to find the cause of a bug.