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.
Friday, August 21, 2009
Thursday, August 20, 2009
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 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!
Saturday, August 1, 2009
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.
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.
Sunday, July 26, 2009
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!
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!
Thursday, July 23, 2009
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.
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.
A Software Developer's Bucket List.
About 6 months ago, my wife and I watched the movie The Bucket List. The movie is about a guy that makes a list of Things to Do before he Kicks the Bucket.
This got me to thinking about my career as a software developer, and I thought I should put together a Software Developer's Bucket List. Everything a software developer should do during their career.
I'll start off with things that I've done and end with things that I have yet to do.
This should be an interesting exercise for me.
This got me to thinking about my career as a software developer, and I thought I should put together a Software Developer's Bucket List. Everything a software developer should do during their career.
I'll start off with things that I've done and end with things that I have yet to do.
This should be an interesting exercise for me.
Friday, June 12, 2009
Debugging Certs using OpenSSL
Sometimes, I could just kick myself. I know OpenSSL has a lot of great features, but I never spend any time learning the myriad of command line options.
Today, Matt showed me some really useful ones at work:
To print out a certificate in human-readable format:
openssl x509 -in certfile.crt -text
To print out hash fingerprint of a cert:
openssl x509 -in certfile.crt -fingerprint
To show the certs being served up by an SSL/TLS endpoint:
openssl s_client -connect hostname:443 -showcerts
I'm making a resolution that I'm going to spend a few hours going over the OpenSSL docs to learn more!
Today, Matt showed me some really useful ones at work:
To print out a certificate in human-readable format:
openssl x509 -in certfile.crt -text
To print out hash fingerprint of a cert:
openssl x509 -in certfile.crt -fingerprint
To show the certs being served up by an SSL/TLS endpoint:
openssl s_client -connect hostname:443 -showcerts
I'm making a resolution that I'm going to spend a few hours going over the OpenSSL docs to learn more!
Subscribe to:
Posts (Atom)
