iPhone Development using the web.

iPhone development has really been the buzz as of late. Apple is boasting 100,000 apps (unfortunately - 99,900 of them really suck -- or to use Internet speak: "they are the FAILS").

I've fallen pray for this scam... I probably have 50 apps on my iPhone (and the ones I care about most is under 10).

I feel like I am living in circa 1995 when everyone discovered the Internet and saw that they could download all sorts of crap on their computer! Come on... we all remember Elf Bowling!

I don't have anything against iPhone apps -- I think there are always going to be times when I really want to play Madden Football, rock it out on iTunes, compulsively check my Twitter account, or check my work calendar. But, it just seems more and more silly that I keep downloading apps.

What ever happened to the true mobile web? Luckily for the iPhone, it is really still alive! I can't believe I never checked out GMail on my iPhone until last month.. and you know what? It ROCKS. And it even allows me to properly archive my mail (unlike the stupid iPhone mail client). And there's no client to download!

It's amazing what you can do with Javascript and a little bit of CSS.

O'Reilly has a great online tutorial so that you can start iPhone enabling your site today.

Check it out today.

Podcasts

I am still listening to a lot of podcasts. My 35 minute drive to work gives me a solid 1 hour a day of solid listening time.

What am I listening to? Here's the list! (my top podcasts are at the top of the list):

1. This Week in Tech - Let's face it. Leo is a fantastic facilitator, and it's a nice brainless podcast to listen to. Without Leo, this should would probably be further down my list. But with Leo in charge, and a revolving cast of characters on the panel, this podcast gives me a nice light view of consumer and end-user technology.

2. Security Now - Steve Gibson is just fantastic. This show goes from light and fluffy news about the latest security patches on Windoze to hard-core bit twiddling and crypto. Honestly... anyone even remotely interested in security should just start listening at Episode 1.

3. Blue White Podcast - This gives me my fall fix of PSU football.

4. Penn State Football Podcast - I like this podcast as well because it's done by two former PSU football players (that quite often give an interesting different perspective on the game and team).

5. Stuff You Should Know - It's kinda like listening to Wikipedia for 20 minutes. Great all-purpose knowledge podcast.

6. FLOSS Weekly - Leo's a great facilitator, and Randal and the Ubuntu guy are really enthusiastic. It's great hearing from a lot of folks in the open source community talk about their projects.

7. 60 Second Science - These are quick fillers when I have a few free minutes int the car. At 1 minute a piece, it's hard to turn this down.

8. LostCasts - These guys are *really* annoying, but they do a great job on keeping up with all of the latest theories on the message boards.


Stuff on my iPod that Used to be higher on my list that I don't have the time to listen to:

1. This Week in Google - I liked the two episodes, but then I found it was just taking too long to listen to. I wish truly more about cloud computing and more technical content rather than "this is how you use this google product". I hope to give this one another try in a few weeks.

2. Diggnation - I used to *really* like this podcast. And then there were the live shows that were unfunny. And then there were more advertisements. And then there was listener feedback. It seems like every Diggnation show only covers only 5 top stories. I've gone 2 months without listening to Diggnation.. It will probably leave my rotation.

3. Java Posse - As a Java developer, I *really* wanted to like this podcast. And I think that I really used to like this podcast, but I'm not sure why I drifted away. Was it the fact that I do so much Java programming during the day and I really don't need another dose of Java during my commute? Was it the bland banter of the hosts? Was it the sickening way these guys seem to get along? Was it Joe Nuxoll? Was it the fact these guys are a little too obsessed with language design? Was it the crappy audio from their open space conferences? I suspect all of the above. Don't get me wrong -- these guys are doing a great service, and I think I'll try listening to them again over the holidays (when my other podcasts run dry).

4. Windows Weekly - Boy the Windows world is really in a world of hurt when the key content contributor for this podcasts feels like he's continually beaten-down about Windows and he's more excited talking about Apple products. I like Paul, but he's really losing my interest.

Here Cometh the Cloud.

I am a big fan of cloud computing. It is a giant trend that was very easy to spot from a long time ago, but I was never quite sure exactly "when it's here".


For me, I think that day is today.


I just got done trying out SpringSource's Cloud Foundry. It's basically a way to easily deploy web applications on a Spring/Java/Tomcat/Apache/MySQL platform on Amazon EC2. And you know what? It freaking works!


As a Java developer, this is what I wanted -- a really easy point-and-click web interface to deploy a distributed Java application on the cloud. I don't have to worry about all of the boring systems plumbing. (and this comes from a guy who kinda likes the boring systems plumbing!). As a developer, I just want a platform that can scale effortlessly and cheaply.


Sure... Cloud Foundry has all sorts of issues: limited DB support, limited configuration, no elastic block storage, etc. But for a first release, I think the Spring Source folks shows what the future could be like for developers.


Cloud Foundry isn't the only cloud solution out there, but it's the one I care about as a Java developer, since java/tomcat/spring apps are what I write. And let's face it: Google's App Engine for Java just sucked.


I really do see computing as a utility. And I really hope to see scalable computing systems with full software stacks to become a utility as well. I think it could usher in a whole new wave of developer innovation. When you lower the bar for the deployment of scalable applications (and you make it really cheap), you start to invite a whole new segment of developers with interesting ideas and interesting solutions.


The next 10 years are going to be cool.

Bucket List 3: Work with Someone Great (and then impress them!)

I am a big believer that only true way to get better is to surround yourself by great people. I believe this works in sports, business, the economy, and just about everything.


I think it's really true for a developer. Want to write better code? Work with someone that really really really knows their craft. You'll learn a thing (or 10). Try to keep up with them -- try taking your craft to the next level!


You'll know you've succeeded when you come up with an idea that will impress the heck out of them.


Don't work with smart people? Get on a new team or a new project!


You're the smartest guy in the company? Find a new job!


Can't find a new job with smart people? Find an open source project with smart people. There are tons of them out there! Get on the forums for a software project and contribute! Impress the experts!


You'll never get any better if your the sharpest programmer in the shed!

I Heart RAID

On Thursday afternoon, we had a critical situation in the Kratzer Household.


The computer was having problems and wouldn't start up. Jenn called me while I was out at lunch. I decided to leave work early because what she was describing didn't sound good.


I came home to find out that one of my disk drives was complete toast. Luckily, I made the decision to purchase a computer with a RAID controller on the motherboard. For those non-techies out there, a RAID controller allows me to make two disks look like one disk (among other configurations). This is called RAID 1 - or mirroring. Every time a piece of data is written to the disk drive, it is actually written to two disk drives. The beauty of this is that I always have a working image of my computer system (even if a drive dies).


This problem was easily fixed. I went to Best Buy (10 minute drive down the road), and found a similar disk drive (same size, same speed, same vendor even!). I installed the mounting kit and slid the new drive into the computer, removing the old drive.


When I booted the computer, the system told me that the RAID array was rebuilding itself and that it would start booting a while. After a slower boot into Windows, I was able to watch the drives "rebuild". Basically, the one good drive needed to copy all of its data to my new drive (to keep the system back in sync). This took about an hour and a half. After that, I was in tip-top shape.


When I purchased my computer three years ago, I made three conscious decisions:

+ I got the maximum amount of memory I could put in the computer at the time (4 GB). This has had a very good pay off for me in terms of performance.

+ I got a premium XPS system from Dell. Wow. I actually never opened up my computer until Thursday (I'm a software guy.. not a hardware guy). The case system was designed to open very easily (no screw drivers needed) and every component was easy to access. Thank you, Dell.

+ I invested some extra money for a RAID controller. I always knew this was a good decision. The events on Thursday proved it.


Someone once said "There are two types of disk drives. Those that have failed and those that are going to fail.". I can testify to this. I've had many computers over my time and I have had many disk failures. I knew that having RAID would "save my bacon".


And while I certainly have back-ups of everything, I am glad that this problem was fixed (with zero data loss) in a couple of hours. A re-installation and a copy of my data down from Amazon S3 would likely have taken days. And I'm sure that I would have forgotten to back up something.


Thank you, RAID.

Bucket List 2: Implementing Encrypting and Compression

Every developer should have the pleasure of implementing an encryption and compression algorithm.


Why?


Why not!


There are many good reasons that every developer should have this experience:


1. Encryption and Compression are very fundamental technologies that have broad-reaching impact in much of what we do as software developers. Getting some hands-on experience with both of these subject areas only helps the developer to really understand and internalize some of this knowledge.


2. The theory behind both compression and crypto is downright fascinating.


3. It's a great opportunity to take a very solid specification, and take your hand at implementing it. This is also a great way to learn a new langauge!


4. It's a great opportunity to work with data at a byte-level and bit-level. Sometimes you just realize how one of your favorite programming platforms (Java) really sucks at byte manipulation and bit-twiddling.


5. Implementing compression algorithms is also a good opportunity to dust off your data structure skills sets. (note: implementing run-length encoding does not count) :-)


6. It's pretty darn satisfying to use your software at for one operation (like compression or encryption) and see it inter-operate with another software tool for the other operation (like decryption or uncompressing data).


So, go ahead and implement LZW or DES today!

Bucket List 1: Write Code Down at the Bare Metal.

I think every developer should experience the joy, frustration, and shear thrill of programming in assembly (machine) language. While maybe not a critical day-to-day skill for many software developers, Assembly Language programming still educates the software developer in many ways.


I first started programming 6502 Assembly back in 1985. I had an 8-bit Atari computer, and I was doing a lot of programming BASIC. The problem with this platform is that the computer only had a clock speed of 1.44 Mhz, and BASIC was interpreted. This wasn't exactly the speediest platform. :-)


I soon learned that the Atari platform had some very simple hooks to allow your BASIC program to jump to a user machine language program loaded into "page 6". Each "page" on the Atari computer had 256-bytes of memory. Page 0 started at memory location 0, Page 1 started at memory location 256. Page 6 started at memory address 1536.


I remember hand-translating the assembly opcodes to machine language, and then using BASIC's DATA statements to load them into memory, starting at location 1536. If my assembly language program when awry, the computer would lock up and I'd reboot. I was in heaven a year later when I found an Assembler written in BASIC that would do the translating for me. :-)


I used 6502 Assembler to quickly redefine character sets, wipe out memory, animate graphics, mix colors, break the 4-Player limit in Player-Missile-Graphics (there were some gnarly things you could do when the screen was redrawing itself mid-screen).


6502 Assembly was a great assembly language to learn. There were only three registers (A, X, and Y). The instruction set was small. I learned a lot about the computer - everything from interfacing with external devices to programming the graphics and sound chips.



My later experience was in college. I picked up 80x86 assembly language to do some hi-performance 3D graphics. The 80x86 had more sophisticated memory management and more registers to work with, but the experience was just as invaluable. I learned the art of really fast integer math (both fixed point math and all of the neat tricks with rotates/adds that could be done to speed up calculations). I counted clock cycles. I precalculated values to make math even faster. I unrolled loops to prevent the penalty of having to branch/jump.


I haven't done any assembler since college (well over 15 years now!). But I still look back at those times very fondly. They gave me a great appreciation for how computers really work, how memory is managed, and how devices really work. You get great insights into code optimization. Finally, there was always a huge pay check at the end of the day - A HUGE performance pay off in speed.


I remember learning C and remembering how simple it was. Everyone in myu college class was having a hard time understanding pointers and memory allocation. But after programming in assembly, it was really easy to understand the abstractions that C was providing the programmer and what the programmer needed to do in order to clean up after himself.


With today's multi-core, multi-language, multi-system architectures, it's easy to see how Assembly language programming is becoming a lost art. With C/C++ compilers that produce super optimized machine code and JVM's that perform run-time analysis before compiling to machine code, I cannot see myself ever dipping back into assembly language again. But the time spent their was a fascinating part of my experience as a software developer. And I still wish every developer gets a chance to talk to the machine using its own native language.