For the past week I’ve been looking at Google AppEngine for a project I have to complete in 2 months. The appeal of AppEngine is considerable. Look at the infrastructure you get for free:
Up to 1,300,000 requests per day
Up to 7,400 requests per minute
1 Gigabyte bandwidth per day
6.5 CPU hours per day
500 MB Storage
Scaling (for when you get Slashdotted) is handled by Google.
What’s the catch?
None really, except that you have to program your site in Python or Java. And that is a catch for me, because I really hate Java. And Python leaves me cold with it’s “There’s one right way to do everything” dogma. Both programming languages are a monumentally bad fit for a free spirit like me. I’ve always subscriped to the Perl motto: “There’s more than one way.”
Python is Cool, Sort of
I really don’t hate Python. I programmed some Zope back in the early days at CareGuide.com (now defunct). I don’t mind Python’s enforced indentation, but really, what’s to love here?
Ruby, of Course
Since time is short, and Ruby fits the Right Side of my brain, I’m going to build the site with Ruby. I may use Rails; I may use Sinatra; I may roll my own. It really doesn’t matter, but the faster I get the framework up, the more time I can devote to the really hard part: the Javascript.
I keep coming back to PHP for my projects. I’m not talking about anything Industrial Strength like the Wikipedia or Facebook. I’m talking about the web sites I use to teach my courses. For the last 4 years I’ve had my PHP course content on a custom Rails site that I built when I was crazy about Ruby. It has languished recently, as the chore of reinventing every wheel (CMS, user authentication, etc) has taken its toll.
So this week I installed Moodle, a fiendishly complex bit of PHP that contains everything I need to run all of my courses online. In the domain of online course management, it’s the top dog. And because it’s written in PHP, I feel right at home.
Oops. My bad. Sorry about that, Rails.
Don’t bother to tell me that comparing Rails and PHP is a lousy comparison. PHP and Rails are both DSLs (Domain Specific Languages) written in general purpose languages: PHP is to C as Rails is to Ruby (not mention that Ruby is written in C, too). If you think about it, PHP and Rails really kissing cousins.
When duty calls and there’s work to be done, PHP is my preferred vehicle to get from point A to point B. Here’s how I spend my online/programming time these days.
5% Lastly, Rails for my course web sites: programmer.
I’ll be the first to tell you that PHP has many, many frustrating design oddities, but once you “get it”, you’ll have more time to kick back, drink some brews, and watch a little b-ball.
This semester I’m going to have my Ruby and PHP classes build a form driven, AJAX-y web application as the final project. This is a bread-and-butter assignment that performs the basic task of storing form data in a database then displaying it. We’ll deal with the ever present Persistence Problem by using a SQLite3 database to store user input, and the AJAX/Javascript layer will be all JQuery.
A classroom project of this size can be completed in four to six weeks, depending on the programming and web skills a student brings to the class. More is always better.
The PHP course will be starting from scratch (no cakePHP, no Drupal, no Joomla), while my Ruby course will be using Rails. I’ll be doing the project in Seaside. When all is said and done, we will count the lines of PHP, Ruby, and Smalltalk to see who get bragging rights for writing the fewest lines of code.
If you want to work along wtih us, your project should have these features:
An HTML form.
JQuery form manipulation.
AJAX via JQuery.
Validated form input.
Form data stored in a SQLite database.
A Recaptcha form.
User data safely displayed (potentially harmful characters sanitized).
There are dozens of features we could hang on this skeleton: pagination, search, social features (Twitter, Facebook, Buzz, etc), as well as polls, voting, thumbs-up/down, email, XML export, RSS feeds, Section 508 compliance, and more. I’ll be satisfied if most of my students can achieve basic functionality before semester burnout sets in.
And about that Seaside course—there isn’t one yet. But it is on my TODO list for future courses at CCSF. For the time being, as part of my own Smalltalk education, I’ll take this opportunity to complete the class project using Seaside. Since Smalltalk and Seaside are new to me, I’ll be starting on the same page as my PHP and Ruby students. This will be fun. I’ll be doing this project with Cincom Visualworks Non-Commercial which is free for non-commercial use on Windows, Linux, and Mac OS X.
OK. I’d better get to work on the Ruby part of this project before the Rails team unleashes another new product release just to confuse me.
A reserved word in a programming language is a word that is off limits to the programmer. For example, in PHP print is a reserved word. This means that you, as the programmer, cannot create a function named print because PHP owns that word.
Most languages have reserved words, some a few, and some very, very many. Usually the fewer reserved words a language has, the more flexible it is. For example, in the list below, you will see that Lisp has no reserved words. We all know that Lisp is very flexible and powerful.
As you look at the table below, do not think unkind thoughts about PHP—it’s different from the other languages. It is not designed to be a general purpose programming language, though it can certainly do almost anything you want it to do. It is intended for web programming, which explains the existence of so many of the predefined functions and constants. Those are exactly the kinds of items that other languages must implement individually if they want to be as handy with web development as PHP. This is no small task, kids. Just take a look around try to find a web site implemented in C++.
Reserved Words
Language
Count
Reserved Words
Lisp
0
Lisp has no reserved words. Lisp is written in Lisp. Alan Kay, the creator of Smalltalk, said: “Lisp isn’t a language, it’s a building material.”
Smalltalk
5
self super nil true false
C
32
auto break case chart const continue default do double else enum extern float for goto if int long register return short signed sizeof static struct switch typedef union unsigned void volatile while
C++
~62
and and_eq asm auto bitand bitor bool break case catch char class compl const const_cast continue default delete do double dynamic_cast else enum explicit export extern false float for friend goto if inline int long mutable namespace new not not_eq operator or or_eq private protected public register reinterpret_cast return short signed sizeof static static_cast struct switch template this throw true try typedef typeid typename union unsigned using virtual void volatile wchar_t while xor xor_eq
Ruby
38
alias and BEGIN begin break case class def defined? do else elsif END end ensure false for if in module next nil not or redo rescue retry return self super then true undef unless until when while yield
Python
31
and del from not while as elif global or with assert else if pass yield break except import print class exec in raise continue finally is return def for lambda try
Java
47
abstract do if package synchronized boolean double implements private this break else import protected throw byte extends instanceof public throws case false int return transient catch final interface short true char finally long static try class float native strictfp void const for new super volatile continue goto null switch while default assert
If you need to see irb in action, check out this screencast.
Whenever I see a smooth, well-written, organized screencast I have a deep sense of appreciation. That’s my goal: be smooth, well-spoken, and organized.
I spend most of my time with PHP and Ruby because I teach classes in these languages at CCSF and CSM. After years of teaching both beginning students and experienced professionals I have an accurate sense of what they need to get off to a good start. I’ve written a ton of content for these courses—screencasts, pdfs, projects, exercises, etc. I plan to use the PHP and Ruby blogs to share some of the material I’ve created for my courses.
Smalltalk is a different matter: I’m a complete newbie and I’m climbing the same learning curve that my PHP and Ruby students climb. As I learn Smalltalk I’ll use the blog to document the process. My plan is to turn my experience (blood, sweat, and tears) into a Smalltalk course. I’ve seen Smalltalk in action, and now I want to do it for myself, then show others how insanely great it is.
I’ll be adding content to the blogs as I as fast as I can proof read it and test the code. If you are on the front end of your PHP career, you will find some pearls of wisdom here. I suggest that you subscribe to these blogs to keep informed of new posts as I update these blogs.
It’s going to take time to fill in these pages, and I expect that I’ll make many errors along the way. I appreciate all feedback; if you see something that needs fixing—code errors, spelling errors, or something that’s just plain wrong—please let me know. Feedback is golden.
Keep hacking…
Respect
My good parts blogs are inspired by Javascript: The Good Parts by Douglas Crockford. His cogent little book has taught me to scrutinize programming languages with a pragmatic eye: embrace what works and find a way to deal with the rest.
I recently rented a 256MB slice from Slicehost for my SmalltalkTheGoodParts.com work. I have a WordPress blog running there, and I’ll be installing Smalltalk and Seaside as part of my self-taught Smalltalk course.
Bad-mouthing Dreamhost
I hear a lot of bad-mouthing about Dreamhost. I have several domains on DH, and I’ve done some of that bad-mouthing myself. However, I’m here to tell you that all is not gloom and doom at Dreamhost. Nor is Slicehost always perfect.
Server Down at Slicehost
Slicehost is subject to the same laws of physics as Dreamhost. Within 24 hours of starting my slice I got an email informing me my server would be out of action for an hour or two. The Slice guys gave me a specific time and did their thing at the appointed hour. Sure, the server was down, but the nice thing about this “negative” experieince was that Slicehost noticed the problem before I did and let me know in advance that things were going South.
Server Down at Dreamhost
That same week my Dreamhost server was out of action every morning at 1AM and had to be rebooted by the Dreamhost sys admins. I noticed this because I work late. The cause of the problem, I am told, was a faulty RAID subsytem. The unannounced outages were so common that I became discouraged and decided to move the newest of my domains (my Smalltalk site) to Slicehost. To Dreamhost’s credit the faulty hardware was replaced and I haven’t had any further problems.
My main gripe with Dreamhost is the poor communication when these problems arise. When I’m warned in advance, I’m quite tolerant. I’ve worked on large systems and I understand that things break. Just let me know that your team is on top of it, and don’t try to BS me.
A 256MB Slicehost Slice vs Dreamhost Shared Host
Now that all of my servers are running fine and dandy, I ran a few tests to get a general idea of the relative speeds of my Dreamhost shared host and my Slicehost slice. To make it more interesting, I ran the same test on my i7 iMac.
The Test
I usually run a Ruby Fibonacci generator to see what level of processing speed I’m dealing with. This test puts a 100% load on the CPU, so it’s a good idea to keep it brief. On a shared host it’s a good idea to fly under the radar.
# fib.rb require ‘profile’ def fib(n) return n if n < 2 return fib(n-2)+fib(n-1) end
Dreamhost Edges out the Little Slice You can see that Dreamhost runs this test a little quicker than the Slice. This jibes with my gut feeling that the little slice is slightly underpowered. The Really Nice Thing thing about Slicehost is that I can turn up the juice if I need it. I can’t do that at Dreamhost. Where Slicehost really wins is that I can run my own Linux box for cheap.
Conclusion
If I could have only one account I would probably stick with Dreamhost. I’m lazy enough to appreciate all the goodies DH provides, along with infinite bandwidth and storage. However, I’d rather not choose. Dreamhost and the Tiny Slice are affordable enough that I can have Dreamhost for the cheap goodies, and Slicehost for the complete freedom to do whatever I want with my Linux server, including running Smalltalk.
PHP and Ruby are where the job action is, especially in the Bay Area, where startups are using lots of PHP and Rails. You can see in this table from the Tiobe Index that PHP and Ruby are high on the jobs list.
But they are obviously not at the top of the list. You might think “Why bother with PHP or Ruby? Why not go directly to Java or C/C++, since those languages comprise almost 43% of the job market? The answer is that there is a higher demand for PHP and Ruby programmers than for Java programmers.
The oDesk.com Blog discusses the supply and demand effect. When looking at this chart, keep in mind that a low fill rate means a higher demand for qualified applicants, and a high fill rate means a higher supply of qualified applicants.
Today’s Jobs with the Least Competition and Greatest Opportunity
PHP resides in the sweet spot: lots of jobs with a low fill rate; out of 731 jobs, only 33.8% (248) were filled.
I should point out that there were not enough Ruby jobs to break in oDesks Top 25 list. And notice that oDesk lists only 75 Java jobs, which indicates few opportunities.
If you are a PHP programmer, don’t think these jobs will just fall into your lap. The bar is set high these days. The PHP jobs in question are not entry level jobs. Employers are looking for experienced programmers (also called “PHP rock star ninjas” in Silicon Valley). My advice to all of you looking for PHP work is that you build a PHP and MySQL driven MVC web application to show as a resume project. If you go into an interview without your own PHP/MySQL web site, you are dead in the water.
Conclusion: PHP is a good place to be. There are PHP jobs out there and not nearly enough good PHP programmers to fill them. In fact, several of my students have taken PHP positions with companies who are willing to train them on the job.
As for Ruby, it’s all about Rails. San Francisco is the Rails Hub of the Universe and there are great Rails jobs with great companies…if your programming chops are awesome. By awesome I mean comprehensive, deep, and mature. Though Rails is this week’s flavor, real Rails programming is a high art. Rails programmers are self-taught, and many of the best have moved from productive (if unfulfilling) Java or PHP careers to Rails. If you are a good programmer, and you’re also a Ruby programmer, your future is bright.
If you’re a Ruby Newbie, I suggest you put your shoulder to the wheel and push—hard. And lest you be discouraged, take heart because there is hope. In fact there is a well known algorithm for turning a mere mortal into a fabulous programmer, and I’ll give it to you for free. Check out Teach Yourself Programming in Ten Years.
Welcome to Ruby The Good Parts. This blog is part of the HackingtheValley.com empire of Good Parts blogs for PHP, Ruby, and Smalltalk. As we create Ruby content, we will post it here.
