Internet Marketing Strategy
CodeMash Jam Session on Vimeo « SazbeanBefore there was Rock Band, people spent time playing actual instruments. This pickup band were amazing musicians independently, but riffing off each other they were just outstanding.
CodeMash Jam Session from Sazbean on Vimeo.
The guy who wrote Rails was clearly brilliant. He just didn’t have alot of real world experience ~ Joe O’Brien, talking about the limitations of testing within Rails
So Joe O’Brien, from EdgeCase, is one of those really exciting presenters to watch because it is a certainty that both you and him are both going to learn something within 30 minutes. Throwing the presentation safety net away and going off the map, Joe tackled the tangled subject of testing in rails by the only way that makes sense, actually doing it. Here is a bit of what you missed:
This was a great way to see they subject matter come alive, warts and all. If Joe had the courage to start hacking away at a program’s test code in front of 30 people, maybe it wont be so scary when you try it in the comfort and protection of your cube next week. So here are some of the things we all learned from this demonstration:
Look to March for the marriage of Merb and Rails for an alternative to the ActiveRecord ORM. Also, learn to love mocking in test and find a moching library that you like, be it RSpec or Mocha or FlexMock (which they use in EdgeRails because it WAS actually invented there). Also, look to the Pragmatic Programmers for a screencast on testing from Joe and Jim sometime soon.
The two afternoon sessions, Erlang the Basics and Functional Concepts for OOP Developers, were one – two punches to the gut, in a good way. If you tried to read a Functional Programming tutorial, maybe waded into the Lamda Calculus pool and found it didn’t have a bottom, you’re not alone. I remember just innocently hitting Wikipedia for a definition of Functional Programming only to be turned back by the first sentence comprised entirely of mathematical symbols and polysyllabic words without definitions that didn’t also have mathematical symbols and polysyllabic words.
Thankfully, for the cost of gas, a room and a cheap ticket to this conference, I got the opportunity to let real functional programming masters explain it to me in English.
Kevin Smith, of EngineYard, does Erlang for a living. That kind of makes him a grand pooba of Functional Languages in my book since OOP just about buries the list of code written today. Still, as Kevin noted in his talk, there are high profile sites using Erlang today – Facebook is using it for chat, Amazon uses it as does CouchDB. Unlike Haskell with its academic background, Erlang is the programmers functional programming languages ‘to make hard things eas(ier)’. So what are those really hard things? Well concurrency is the big one.
Not long ago, programmers had a one-machine-one-CPU view of the world that served them well in the Object Oriented Programming universe. Software was rarely written to work as a unit over more than one CPU at a time because it was 1) very very hard and 2) impractical and unneeded for most cases. Today, however, programmers are realizing that the multi-core growth path of hardware manufacturers has hijacked the stage, forcing us all to become concurrency experts. While OOP languages are saddled with the baggage of supporting shared memory and mutable variables, reducing them to a one legged man in a ass kicking contest, their distant cousin Functional Programming Languages aren’t feeling the same strain. FP’s have immutable ‘variables’ (really they are unchanging pointers, so more like constants) and a very low cost for spinning up processes. This frees them to run in a highly distributed way on many cores and many machines collaboratively. Erlang, written by the team at Computer Science Labs at Ericisson, had a real world need for a highly concurrent language to write their phone system on. Its design works wonderfully to harness that 8 core desktop you have sitting under your desk.
Bryan Weber was kind enough to expond on this foundation talk by exploring Functional Concepts for OOP Developers. My take home from this talk was the message model used by most Erlang programmers to achieve concurrency. Like Scala, Erlang uses a mailbox with a send and receive paring to smoothly weave a web of interconnected processes that can be located anywhere on the network. Simply spawn a process, which gives you a pid in response. Now send a message to the pid. The spawned process does a recieve to check the mailbox for the message. Want to send a response, no problem. Have the spawned process send to the parent and have the parent check the mailbock. Done, you just did concurrent work. This little scene is played out using Actors, which naturally, is an apt analogy.
I don’t know yet if FP will make it into my world any time soon. Our concurrency neeeds are small so far. I would say that Functional Programming isn’t the solution to all problems, but it just may be the answer to that tricky problem defying all other solutions.
Travel issues prevented me from seeing the very early sessions of CodeMash, which was a shame because I was very interested in Eric Meyer’s talk on how JavaScript Will Save Us All! (I added the exclamation marks because I think that’s what he really intended). Still, I made it early enough to sit through a couple very good presentations before lunch, both of which followed a bit of a theme. One was a love fest for Dynamic Languages as a persecuted, second class citizen given expertly by Nathaniel Schutta. His message is simple, programmers need to be Polyglots and if you can’t handle learning different languages than you should get out of the business. Harsh, but dead on accurate. One of the languages you should have in your tool belt, Nathaniel tells us, is a Dynamic Language and that you can do a whole lot worse than Ruby. I am already sold on this idea, or was years ago when I was nearly alone in lecture rooms during similar presentations. Since then the crowd has gotten bigger but the message is still the same. Most of this revolves around dismantling the arguments for the need of static typing to prevent errors from bad programmers. Truth is, bad programmers don’t get better when they have a wet nurse hand out brainless advice through compiler warnings or errors. Take off the training wheels already and let’s get some code written already.
You go though more hoops to do it, but you can do it ~ Venkat Subramanian Mads Torgersen talking about Dynamic languages on C#
Venkat Mads works for Microsoft on the C# language. Now I am not genetically predispositioned towards this kind of talk, but since it was while I ate my ham on marbled rye, I felt no great persuasion to not hearing the good gentleman out. Glad I did, though, because there were some interesting things going on in the CLR camp. CLR itself was a happening idea, a VM that was designed from the beginning to be a shared platform (Common Language Runtime) so the pieces where already there to do something interesting. However, it seems that early decisions were made to optimise speed for the C# type base on the CLR, leaving non-microsoft languages somewhat at a disadvantage and me somewhat bewildered by the earlier statements. Dynamic languages, for example, run though a DLR library to get to the CLR. This Dynamic Language Runtime handles the bindings to Ruby and Python, so IronRuby and IronPython handle the mappings between DLR and CLR maybe? I was somewhat confused. If you type something in your code as ‘Dynamic’ it is a Dynamic type in the compiler but then reverts to its true type in runtime to allow for the dynamic langages to duck type the thing. For a complacated problem, the fact that this solution made perfect sense to someone as slow as me is a good sign that they might be on to something.
So I will be attending the 2009 CodeMash conference in wintery Sandusky Ohio (no more wintery than Ann Arbor Michigan I suppose). If any of our readers will be in attendance, send me a ping via email (aaron@sazbean.com) or twitter (aaronworsham)
I will be on the clock for another company, so I can’t update the blog in real time, but look for my posts on the conference after work hours.
I’m tired of talking about how great I am. What about you, what do you think of me?
There may have been a point in time when someone understood all that there was to understand about computers. Early on there may have been one person who could stand above his fellow scientists and claim to be the authority on everything in this young field. Where wizards stay up late makes a good case for a few individuals who may have filled that natural desire we have for an overall authority on a subject. Yet those men, great scientists and tremendous minds in an unproven field of study, were some of the most humble ambassadors of technology we will likely ever see.
Today we have no overall authorities. No normal person can hope to represent enough deep expertise to be considered an expert in more than one specialty. Exceptional people may be able to handle two or three fields before being overwhelmed by the fire hose of information needed to keep up. Hollywood has it wrong, again, about smart people in technology because there are no generalists out there that know everything. Computers is similar to any other complex system like medicine, law, scientific research and finance. It demands that you specialize to do be considered an expert. (This may also be why I like House as a show but have problems with a plot device that pretends there are doctors that can ever know everything.) Anyone who either pretends to be an expert on the whole of technology or really has convinced themselves that they are will be doomed to huge management failures.
Pete Johnson Chief Architect at HP and a guy who clearly knows what he is doing around a computer wrote up good article on Dzone about why programmers hate working for Software Architects. Pete’s experiences run parallel to my own as a manager of programmers and his first point sums up my advice to anyone who wants to lead a programmer.
What’s on your list?
Photo attributed to SuperFantastic on Flickr CC
I got the change to talk with James Lindenbaum, CEO of Heroku. Heroku is looking to eliminate all the reasons companies have for not doing software projects. This interview comes at an interesting time; companies are finding it difficult to justify spending money on software projects that have any risk associated with them (which are all projects, frankly). Heroku is here to remind those companies that when the barriers are low, so are the risks. James was kind enough to take a few minutes for this interview right before getting on a plane for RailsConf. I want to thank him again for that.
Sazbean: So is Heroku a new kind of hosting company, a SaaS provider, or something wholly different?
James: I think it’s something wholly different. We tend to think of it as a new kind of platform. Software as a Service is an interesting thing, but we’re not really providing the software, you are. So it is really more of a Platform as a Service. We follow a very different model from hosting. The end point that we are after is that you can come and say ‘Hey, I need to build something’ and then just have it run. There are a bunch of things we need to have in place to make that happen, and hosting infrastructure is just one of them.
Sazbean: How is Heroku helping businesses that use your platform?
James: The failure rate for software projects is astonishing, somewhere around 80%. People spend a lot of time wondering why that is. Our feeling is that almost all of the cause has to do with barriers. Large capital expenditures mean people have to make tough decisions about whether not to do something, and the cost of these projects is then totally decoupled from the value. You are committing to a set of costs, and those are going to be your costs whether or not your application ends up providing value. So it becomes a risk management game. We think that is a problem. Cost and value should be coupled. An on-demand pricing model is interesting for a number of reasons from an economics perspective, but we think it’s interesting solely because it fixes this problem. If an application is valuable you use it, and if you use it you are paying for it. If it’s not valuable you don’t use it, and if you don’t use it you aren’t paying for it. This removes that risk management aspect. So now you can think about what you want to build and not whether or not it’s worth building. That’s really the difference between us and a more traditional hosting company. Even with someone who is really quick, you have to call them. You have to cut a deal with them and get your servers provisioned, and that can take hours or days. We strongly feel that if you have to pick up a phone and call someone it’s a deal breaker. You have to be able to have an idea, go click a button, and be up and running. We think that is just vital.
Sazbean: Why Ruby on Rails for this Platform as a Service?
James: We’ve seen over time that Rails is extremely accessible, there are a lot of people that are able to build software with Rails that might not have been able to previously, and we think that is a really good thing. We think that it’s great that all these well rounded people are coming in. We disagree that those new to Ruby and Rails should have to go learn all the hard stuff. It is the frameworks and the platforms that need to shape up and make themselves easier and more accessible. Basically if you have an idea for an application and you have to stop and think about whether it’s worth building or not, then we have not done our job.
Sazbean: There can be a perception that user friendliness equates with limited options. Does it in this case?
James: No, and that’s a really interesting thing. One of the reasons why we think Ruby is interesting is because it has a very unique bipolar thing going on. On the one hand, it is one of the most advanced languages available. From a computer science standpoint, it has all the really fancy stuff; meta-programming, fully dynamic typing, reflection, self-introspection, so on. On the other hand, it’s really accessible. It reads like English, the syntax is really clean, and a lot of people who don’t really have programming experience seem to understand it fairly intuitively. Rails took that and advanced it into the web space, where you can do really advanced stuff with a web application but it’s also super easy to use, super easy to approach, and for 90% of the cases, you don’t have to do that much work. We love that idea and we want to extend that even further, up into the tools and down into the underlying infrastructure. It is a difficult line to walk. You have to think about your choices so that you are making everything easy and accessible, but you are not limiting the power and the expressiveness. That’s one of the main things we are keeping in mind when we’re making decisions about what to do and how to do it.
Sazbean: So who is using Heroku today? Is it the Ruby enthusiast, the professional programmer or is it both?
James: It’s a mixture. So far that mixture is in even thirds. A third are people who really haven’t done a lot of development before. They’re coming in enthusiastic about Rails. They just want to build a site, that is their end goal. The next third are fairly serious Rails developers. They know Ruby and are capable of doing all the sticky bits themselves, but they just don’t want to. The last third are really serious Rails developers. They are trying to do really difficult things and they care very much about the details of how our stack is implemented. These guys are willing to take a hands off approach if they trust you are doing it well, and they can get all that time back to spend on the more differentiated stuff like the actual application code.
Sazbean: Heroku is currently free to use. Are there any plans to change this once you leave beta?
James: We are always going to offer free accounts pretty equivalent to what we offer now, with enough resources to do something interesting. We will always offer that, but we will, at some point soon, be opening up a full on-demand pricing model.
Sazbean: And the closed beta, how is that going?
James: It’s going really well. It has been interesting. There is a huge amount of traction there and a really large amount of activity now. We’re up to about 12,000 developers and 14,000 applications. That’s been great because these guys are really hammering on the system and they’re really helping us to smooth it out and make sure it’s an easy process. It’s nice that we have this mix of users too, because we have the hard-core guys saying ‘Hey, what about this advanced feature?’ and then we have the beginners saying ‘Hey, I can’t seem to get this very simple part to work’. They are helping us maintain that balance. We are looking to come out of beta as soon as possible, but we are providing infrastructure and we’re pretty conservative about reliability, so we won’t lift that label until we feel really comfortable about stability.
UPDATE: I posted my technical notes on Heroku that didn’t make it into this profile interview.
The guys over at Rails Envy, a Ruby on Rails enthusiast podcast, have a running joke. Their catch phrase? – ‘Rails can’t scale.’ Yeah, I wasn’t too sure I got the joke either. Then I heard it myself in CIO level discussions from smart business people parroting things they didn’t understand and read somewhere once in an article in a magazine bylined by a guy in a suit who looked corporate and trustworthy. Rational reasoning and discourse can sometimes be co opted by bumper-sticker wisdom even at the highest levels.
Here is the thing about corporations; enterprises are in the business of managing calculated risk within the market or industry they operate. They do this by forcing non-core operations to be conservative, risk-adverse and predictable. It’s a bit like hedging your business’s bet in the junk bond market (core business) by backing it with rock solid, non sexy T-Bills (non-core like software development). Sure, the return on the T-Bills is lousy but you know in three years you won’t be out that investment. Java, backed by Sun Microsystems, and .Net, backed by Microsoft, are some of the blue chip securities of the programming world. Enterprises trust them. One-liners like ‘Rails can’t scale’ are the one-handed brushoff of entrenched corporate IT’ers to the mere idea of using something new like Ruby or Rails.
Still, Ruby is a persistent pitch man, especially in the web technologies.
Corporate IT: Ruby uses green threads and Rails is single threaded, why are we even talking?
Ruby: Ruby’s MRI is green threaded, but the JRuby interpreter uses native threads in the JVM, just like Java. Also, Rails 2.2 just released 2.2 RC1 that is thread safe. Merb was thread safe from the start and just released 1.0 RC2.
Corporate IT: There aren’t enough ruby programmers to staff a project.
Ruby: The Rails Rumble contest didn’t have any problems finding entrants. Five hundred programmers just gave up a weekend to write 248,000 lines of code. Teams up to four completed 131 different Rails projects in under 48 hours, so you can see just how productive a small group can be in Ruby.
Corporate IT: Sorry but we need dependable database connectivity, not this serial locking business.
Ruby: So pooled connections in jruby and Rails 2.2 scratch that itch?
Corporate IT: There still isn’t a big company backing it so no support. No support, no chance bub!
Ruby: Have you ever actually called Microsoft about a .Net problem? Or maybe Sun to support your Java app? Maybe you have, or at the very least arranged a support contract with a .Net or Java consulting company. Try instead one of the fine Ruby consulting companies like EdgeCase, HashRocket or ThoughtWorks. Sun already bankrolls the JRuby guys and for the Softies out there, Microsoft is putting its wallet behind Ruby on the CLR.
Corporate IT: Books?
Ruby: New one every day.
Corporate IT: You’ll get me to use some text editor in place of my IDE when Heck freezes over.
Ruby: Not a problem. NetBeans guy, Eclipse, or IntelliJ?
Corporate IT: Yeah, okay, you win. Now can I have that stack of waterfall project specs back, they were holding up the table at that end.
Ruby: Have you ever considered Agile?
Photo attributed to Megyarsh @ Flickr CC
The guys over at Rails Envy, a Ruby on Rails enthusiast podcast, have a running joke. Their catch phrase? – ‘Rails can’t scale.’ Yeah, I wasn’t too sure I got the joke either. Then I heard it myself in CIO level discussions from smart business people parroting things they didn’t understand and read somewhere once in an article in a magazine bylined by a guy in a suit who looked corporate and trustworthy. Rational reasoning and discourse can sometimes be co opted by bumper-sticker wisdom even at the highest levels.
Here is the thing about corporations; enterprises are in the business of managing calculated risk within the market or industry they operate. They do this by forcing non-core operations to be conservative, risk-adverse and predictable. It’s a bit like hedging your business’s bet in the junk bond market (core business) by backing it with rock solid, non sexy T-Bills (non-core like software development). Sure, the return on the T-Bills is lousy but you know in three years you won’t be out that investment. Java, backed by Sun Microsystems, and .Net, backed by Microsoft, are some of the blue chip securities of the programming world. Enterprises trust them. One-liners like ‘Rails can’t scale’ are the one-handed brushoff of entrenched corporate IT’ers to the mere idea of using something new like Ruby or Rails.
Still, Ruby is a persistent pitch man, especially in the web technologies.
Corporate IT: Ruby uses green threads and Rails is single threaded, why are we even talking?
Ruby: Ruby’s MRI is green threaded, but the JRuby interpreter uses native threads in the JVM, just like Java. Also, Rails 2.2 just released 2.2 RC1 that is thread safe. Merb was thread safe from the start and just released 1.0 RC2.
Corporate IT: There aren’t enough ruby programmers to staff a project.
Ruby: The Rails Rumble contest didn’t have any problems finding entrants. Five hundred programmers just gave up a weekend to write 248,000 lines of code. Teams up to four completed 131 different Rails projects in under 48 hours, so you can see just how productive a small group can be in Ruby.
Corporate IT: Sorry but we need dependable database connectivity, not this serial locking business.
Ruby: So pooled connections in jruby and Rails 2.2 scratch that itch?
Corporate IT: There still isn’t a big company backing it so no support. No support, no chance bub!
Ruby: Have you ever actually called Microsoft about a .Net problem? Or maybe Sun to support your Java app? Maybe you have, or at the very least arranged a support contract with a .Net or Java consulting company. Try instead one of the fine Ruby consulting companies like EdgeCase, HashRocket or ThoughtWorks. Sun already bankrolls the JRuby guys and for the Softies out there, Microsoft is putting its wallet behind Ruby on the CLR.
Corporate IT: Books?
Ruby: New one every day.
Corporate IT: You’ll get me to use some text editor in place of my IDE when Heck freezes over.
Ruby: Not a problem. NetBeans guy, Eclipse, or IntelliJ?
Corporate IT: Yeah, okay, you win. Now can I have that stack of waterfall project specs back, they were holding up the table at that end.
Ruby: Have you ever considered Agile?
If you liked this article, consider subscribing to this blog via email or RSS. Also, consider subscribing to have our free weekly newsletter sent to your email inbox.
Photo attributed to Megyarsh @ Flickr CC
I’m tired of talking about how great I am. What about you, what do you think of me?
There may have been a point in time when someone understood all that there was to understand about computers. Early on there may have been one person who could stand above his fellow scientists and claim to be the authority on everything in this young field. Where wizards stay up late makes a good case for a few individuals who may have filled that natural desire we have for an overall authority on a subject. Yet those men, great scientists and tremendous minds in an unproven field of study, were some of the most humble ambassadors of technology we will likely ever see.
Today we have no overall authorities. No normal person can hope to represent enough deep expertise to be considered an expert in more than one specialty. Exceptional people may be able to handle two or three fields before being overwhelmed by the fire hose of information needed to keep up. Hollywood has it wrong, again, about smart people in technology because there are no generalists out there that know everything. Computers is similar to any other complex system like medicine, law, scientific research and finance. It demands that you specialize to do be considered an expert. (This may also be why I like House as a show but have problems with a plot device that pretends there are doctors that can ever know everything.) Anyone who either pretends to be an expert on the whole of technology or really has convinced themselves that they are will be doomed to huge management failures.
Pete Johnson Chief Architect at HP and a guy who clearly knows what he is doing around a computer wrote up good article on Dzone about why programmers hate working for Software Architects. Pete’s experiences run parallel to my own as a manager of programmers and his first point sums up my advice to anyone who wants to lead a programmer.
What’s on your list?
If you liked this article, consider subscribing to this blog via email or RSS. Also, consider subscribing to have our free weekly newsletter sent to your email inbox.
Photo attributed to SuperFantastic on Flickr CC
Digital Marketing & Strategy
Connect with Sazbean