justInCaseYouMissedIt

The new action is over here.

Please make a note of it.

movinThisParty

Cross town.

Sorry to do this already. I'll probably keep posting here as well, but I'm going to dive into WordPress now, and whatever I do eventually come up with developmentally will be hosted over here, too.

Chapter1b

Step 2. Learn to program

Here's the thing. Computers don't think like you and me. They think in 1s and 0s. Every programming language ever invented has basically been a way to translate what a human wants to have done into a stream of 1s and 0s to be read by the computer. The translation into binary can happen at a couple of different points along the way from programmers head to users computer screen, but there are basically two different methods for how different languages do this. Some languages, especially the older (pre-1990) ones are "compiled". That's a really byzantine process that basically involves taking the code that you have written, translating it into some 1s and os, linking it with other files in your code, and wrapping it up into an "executable" - a program that you can execute on your computer or whatever. The advantages of this method are thus:

Some larger applications can have bazillions of lines of code to execute (think about a Windows installer disk). If all of these lines of code were translated into binary at the time you run the application, the app would run so slowly that it'd be useless. This was obviously a big deal before CPU speeds got to be what they are now. Back in the day, the act of compiling was in itself a very time consuming procedure, and still can be today, so by doing it beforehand you save that much time and effort on the part of your computer. You also have the advantage of tuning your application on a lower level with regards to interaction with the Operating System (we'll get to that), thus making it possible for your app to perform much more nimbly. So basically, most of the benefits of compiled languages are in the performance arena.

The disadvantages of compiled languages have mostly to do with portability. Since the code has already been bundled into binary, the only machine on which the executable will run is the one for which it was written. That's why you have Mac and PC versions of the same software on the shelves. They had to be written and compiled separately since the two different computers have different methods of operating at the OS level and thus need different sets of instructions to accomplish the same task. C is the mother language from which virtually all other languages are descended, and the perfect example of a compiled language. iPhone apps are written in a language called Objective-C, descended from C with an OO twist. Since iPhone apps are written for one device and one device only, and since application performance on a phone really matters (think battery life), compilation makes perfect sense.

The other side of the coin, and I've been looking for this side for a while and have only recently found it, is an "interpreted" language. HTML is the perfect example of an interpreted language. HTML is only lines of code, just like an iPhone app or the Windows executable. The difference is that you leave the code alone and don't compile it. The code is instead "interpreted" at the time it's run, in the case of HTML by the browser that you're working in. The pros and cons of interpreted languages are exactly the opposite of compiled languages. You only write the code once and it works for every machine out there. It's left alone until that particular section of code is needed at "runtime", at which point whatever is doing the interpreting, be it the browser or the server on the other end, crunches your code into binary and spits it out into whatever the application needs at the time. As computers have gotten more and more powerful, this method seems to be gaining a lot of traction as the preferred method of writing new applications. Some examples are JavaScript, PHP, and Ruby - languages that get chewed up into something actionable at runtime. In the case of Ruby on Rails, which is the hot-shit dev platform at the time of this writing, the code actually gets interpreted twice - once on the server side where the code is translated into HTML, and again on the browser side when the HTML is translated into something that you can read and work with.

Twitter was originally written with Ruby on Rails. If you think about it, Twitter is just an application that communicates over the internet. It really only does that one thing. They don't even display advertising (yet). Many of the traditional features of a commercial website are not there, so why write it in HTML? Especially when you have this vast database of information that gets displayed uniquely on every different computer screen out there, it's a perfect solution. Parts of Facebook are written with PHP, another interpreted language. PHP is designed to interact with info in a database - users and their profiles, pictures, text, whatever - and to write the HTML to display that info on the fly at the time of the page request.

Pretty cool, huh? Comments? Suggestions?

chapter1a

Quick bio - The difference between

As in, the difference between your brain and your computers CPU. The difference between how you think and speak and interact, and how your computer does. The difference between languages, be they interpreted or compiled, object oriented or procedural. This first chapter will hopefully assist in the process of the first few days after the moment where it first occurs to you that you want to learn how to develop software, be they games or business or iPhone apps. The real difference for me was the the one between what I thought the process was going to be and what it's actually turned out to be.

The moment occurred for me in a car. I had bought an iPhone a few months after it first came out. It was the first such early adopter move that I'd made, technologically speaking. I knew as soon as I started screwing around with it that this was a tool that could really help you get your life organized, something that I'd managed to get around doing for the previous 30 years. All of the built in applications that Apple provided for their first tier of users were most helpful in that task - email everywhere, calendar, internet, maps, oh yeah, and a phone. The real fun didn't begin for me until they (Apple) released the 2.0 software update. This was the update that heralded the opening of the AppStore, where there were now hundreds of apps available from 3rd party developers that could extend the usefulness of your phone. Anyway, to make a long story no less long, the first long car ride I took after updating my phone was the one where the real potential of mobile computing dawned on me.

I came home that weekend determined to figure out what it would take to learn the art and craft of building my own applications, as this was clearly a vast and uncharted territory for creative people to make things that could affect the lives of huge numbers of people (and maybe even make a living doing it).

I got home that week and started Googling. A search on Computer Programming turned up a mountain of information that was so staggeringly huge as to be almost useless. I did learn a few things - Wikipedia can be your best friend; there are many different ways to program computers; there are endless amounts of information on programming computers, most of it written by computer programmers with no conversational or literary ability whatsoever.

I was able to discern a few important pieces, however. One was something called "compilation". I wasn't sure what this was or why it was important, but hey. Another was that if you're going to develop software, and you're used to working in a more or less standard Windows environment, you're in for a ride. Another was that there was something called Object Oriented programming, that supposedly is some kind of elevated way to program. iPhone apps are written in an OO manner. Oh, and if you really want to develop apps for the iPhone, you have to buy a Mac. That's some clever marketing, and the push over the cliff that I'd been waiting for for years. The bonus was that once you bought the Mac, all of the tools to develop apps, as well as an enormous user community was there to help, for free. Step 1.

preface

It occurred to me last night during the show (where I do all of my best thinking) that of all of the thousands of websites that I've pored over in this quest, of all the books that I've perused, of all the tutorials that I've read and followed through, the one thing that was missing was the square one explanation of what the hell we're doing here in the first place. Everything I've read so far assumes some sort of foreknowledge or education to prepare oneself for the task of learning software development. I have no such education. A few very basic concepts have to be put into place before one can train oneself to think like a computer (or more likely, to train your computer to think like you).

As I've said before, software dev is a new thing for me, so if anyone has any corrections or additions to anything I write, please send them to me. I am now attempting to write the complete and utter morons guide to learning software development. I want to be factually correct, of course. And without further adieu..

RoR

Oh, yeah... The Holy frickin Grail. The MVC framework that's sweeping the land fell under my text editor yesterday.

I hacked my way into Ruby on Rails.

I built a website yesterday in two hours that does more than anything I've done in the last nine months. Granted, it doesn't look that great, but it's functional. Also granted, it took me nine months to put the conceptual pieces together, and to find the technical resources to do something with the RoR framework that I downloaded 6 weeks ago, and to figure out how to install all manner of seriously deep Unix command line shit, but so help me, it's an exhilarating feeling.

Okay, so RoR isn't the Holy Grail, iPhone apps are, for me. iPhone apps are written in a language that's not Ruby, but the MVC architecture is the same. What I'm hoping that this means is that all this cool stuff that I'm learning about building Ruby stuff will translate nicely to building Obj-C stuff. The work that I've done over the past 2 weeks with PHP was heavily informed by the one class I took on straight C, so I'm optimistic.

I'm in Davenport IA right now. It's cold, but the sun is shining. Sorry I've been out of touch, but touring really does kinda wear you out. I'm not saying it's hard, but it does wear you out.

Peace...

standingWaves

Sitting here in the surprisingly nice Richmond VA airport, so I thought I'd check in. Cool cabby on the ride here. He saw my big PHP book and started asking me about what I was doing, so that pretty much filled up the 20 minute cab ride.

Last night's show was kinda just alright for me, personally. It's funny because Phil and Stacy both thought it was the best show of the weekend. It's just goes to show, you never know. I've learned through the years (you never let me down..) that I have absolutely the most subjective opinion about the quality of any given show of anyone in the listening world. It's the double edge sword that keeps us from putting out more LiveDownloads. Typically for me, the quality of the experience that I have on any given night is directly proportional to the frequency distribution between 40 and 150 Hz in the location on the stage at which I'm standing. That's a pretty specific requirement, but last night it just wasn't that happening. The theater we were playing in last night was Very Big. Very Big means a lot of air that you have to get moving before the entire room starts to feel right, which is what makes it sound good between 40-150 Hz wherever I am on stage.

I suppose that we probably wouldn't be as subject to the peculiarities of a given rooms acoustics if we were a more electric band. Let's just take my bass for example. My bass is a giant wood box that's designed to resonate. I stand next to a drum set. If you were to solo up the signal from my DI during a show and listen to what is making my bass resonate, you'd hear the notes I'm playing, but also the kick drum loud and clear. You hear a good bit of fiddle, or God forbid the electric guitar, and the rest of the stage, muffled. This makes my bass essentially the biggest microphone on the stage, with a frequency response that tapers off at about 100 Hz.

What this means to me is that if the room is shaped just so, and you never know until you start playing, there's the possibility of a 'standing wave' on certain notes. A standing wave is one that has a wavelength that's some multiple of the dimensions of the stage we're playing. Suppose I play an open D. Suppose that D vibrates at a frequency of 65 Hz. That means that 65 times every second that string is going to return to more or less the same place in space on my bass (nice). While that string is vibrating it's sending a signal to my amp and to Mikey out in front. That string is going to cause air to be pushed out of the speakers 65 times a second. The air being pushed out of those speakers is going to travel at the speed of sound and bounce off of hard surfaces and dancing bodies alike. The hard surfaces reflect the sound much better, and those soundwaves bounce off and travel back toward me. Meanwhile, other soundwaves have been continuing to come out of my amp and the PA. If the note that I'm playing at the time lines up in a certain reinforcing way with the note that's bouncing back toward me from the wall and the PA, you get a standing wave. That's when feedback begins, and my night starts to go downhill.

Other nights it's the exact opposite, and the note that's bouncing off the wall is totally out of sync with the note that I'm playing at the time. That's when you get 'phase cancellation', which means that the soundwaves are canceling each other out. That's even worse than a standing wave for me, because then there's really no balls to the sound. Phase cancellation is what makes outdoor concerts sound weird when the wind is blowing and you're about 100 yards away from the stage and the sound kinda shifts around and sounds, well, phasey..

And then some nights, the PA and the amp and my bass are all playing nice with each other and you get that nice even low end. A nice even low end means ceasing to consider the sound and actually listening to what my bandmates are playing. That's a good night.

And then some nights, the PA and the amp and my bass are all playing nice with each other, but we still can't get it sounding right. That was last night. It usually happens in a Big Room because the Big Room swallows sound waves and doesn't let them come back to you in time to be useful. It sends them back to you much later so that it sounds like a delay on your entire band being blasted back at you.

And then some nights the sound is so God awful that you just say fuck it, and those are usually really great nights. Blacksburg was one of those. It was in a tiny little basement of a club, my bass was acting up all night, but the crowd was blazing. You can't possibly have a bad time in that situation.

Now boarding. Later...