Entries by Andy Koch

Recently I proposed running Nginx rather than Apache as the frontend web server for a soon to deployed Rails app that shall remain nameless. The response I received was that Nginx was unknown and likely introduced security risks. My response was, "maybe, but Nginx is faster and uses less server resources". To which I was ordered... "prove it".

And so I did, by setting up my Rails app on a local server with all things being the same but switching the frontend servers (Nginx, Apache) and running a set of performance tests. The results were interesting and I was able to create some pretty graphs of the results.

Why doesn't Mac OS have a standard package manager?

This was final thought Sunday night as I flipped my MacBook shut and stumbled off to bed. I finally got around to configuring my MacBook as my primary development machine this weekend. It's been 3-4 months since I got my MacBook and I've since converted the two other PC's in my house into Linux machine (Debian and Ubuntu). With that conversion mostly complete it was time to get cracking on making my MacBook into the web development powerhouse for which it was intended. OK, before anyone says anything - it took me 3 months because I had a Lego Star Wars addiction - Don't judge me!

So after installing Xcode, MacPorts and then Ruby, rubygems and postgresql - I then reconfigured my Eclipse to use the port installed version of Ruby and gems. Which is when I realized that the pre-installed Ruby and gems was not in any way connected to the Mac port installed version. Well, that's inefficient - I thought.

Why doesn't macports just link into what is already installed and go from there? In fact why isn't macports pre-installed so developers can hit the ground running?

I still think Mac OS is a great platform for development - particularly web apps - but if it came with an integrated package manager it would be awesome.

As the company Rails evangelist one of my challenges has been working out a consistent and understandable deployment strategy. One of the biggest challenges is that I may not have access to the root user acct. Additionally we are generally required to stay within the Etch distro, going with Lenny (testing) requires special approval. A final challenge is that compilers are not allowed on the production server.

The "Ruby gem problem" is the result of not having access to the root user acct. On development servers Ruby gems are easily managed using the root acct with the "gem" command. But without root on the production server, how do get our gems installed? Well, you might think we can just request the owner of the root acct to install gems, but not so fast - the gem command does not place files in accordance with the Linux FHS (see http://www.pathname.com/fhs/pub/fhs-2.3.html). And furthermore, the manager of the server has no interest in keeping track of Ruby gems and managing them seperately. If it's not related to "apt", you've got some explaining to do.

Last week I posted a question on the "Ruby on Rails: Spinoffs" group - generally a place for ProtoType/Scriptaculous discussions. My post was wondering how to do the InPlaceEditor of Scriptaculous using checkboxes for the form controls. This seems like it could be a derivative of the InPlaceCollectionEditor, after all I have a defined set of choices - some of which may be selected - only I don't want a drop-down for selecting. But as you can see from the post, only one person responded and while I didn't read his response in detail - it sure looks like a lot of code. There is also a Rails plugin, oh - this is for a Rails app - of course, "SuperInPlaceControls" but it's targeted to Rails 2.0, I'm on 1.2 still, and it employs classic Rails javascript helpers - and I'm not such a big fan of those. I prefer to manage, as much as possible, my on-page controls via LowPro behaviors in a standard application.js file.

Ah, how I love Rails. Everyday it makes me happier to be a web guy and not one of those stodgy ol' compiled code SE's that surround me.

Today I want to list out some the Rails blogs I've found that help me keep current with the Rails framework and it's related technologies. After all, Rails in itself doesn't make you a better web engineer, knowing how to use and leverage it effectively does.

1. http://errtheblog.com/ - a couple a CNET engineers who've started their Rails consultancy. They post short tutorials on various Rails techniques.


2. http://blog.hasmanythrough.com/- by Josh Susser, various Rails topics but I especially like the posts detailing new features in the Edge Rails.


3. http://nubyonrails.com/ - by Geoffrey Grosenbach, who does the PeepCode screencasts and the Rails podcast interviews. His posts don't go into much Rails details but he does have good posts on related technologies like Capistrano.


4. http://peepcode.com/ - not actually a blog, these are screencast training videos that are for sale ($9 each, or less by subscription) and they are really good stuff. I've watched 3 so far, they're usually over an hour in length so you'll need a chunk of time and if you're like me you'll want/need to watch some parts a few times. The newer screencasts are indexed so jumping to parts you want to watch again & again is easy.


5. http://railscasts.com/ - again, not actually a blog, these are short (10-20 minute) screencast videos going over a variety of Rails techniques. These are free, which makes it very nice and the short length and concise topic make it nice to watch as break from heavy coding.


6. http://agilewebdevelopment.com/plugins - by Benjamin Curtis, I subscribe the "plugins" feed, this is a place for people releasing new plugins to advertise them. This is much nicer than watching the high-traffic Rails newsgroup for ANN messages and lets me see how other people are using and extending the Rails framework. Of course, ideally you'll see something that fits a need you have and you can leverage your work by using someone else's free labor.


7. http://podcast.rubyonrails.org/ - also not actually a blog, these are podcasted interviews with a variety of people central to the Rails community. Different interviewers though Geoffrey Grosenbach seems to be doing the current releases. These are nice to listen to while coding.


8. http://ryandaigle.com/ - by Ryan (perhaps Daigle is his last name), nonetheless he has a really good theme of posts related to edge Rails topics.


9. http://www.softiesonrails.com/ - by Brian Enq and Jeff Cohen, they post some nice short on topic bits related to effective Rails usage.


10. http://www.therailsway.com/ - by Jamis Buck and Michael Koziarski, who are both Rails core members, they do serial posts related to best practices in Rails development.


11. http://weblog.jamisbuck.org/ - by Jamis Buck, core Rails member and developer of Capistrano among other ruby gems. Jamis knows his Ruby, inside out and backwards, his blog is a great place to keep up with Capistrano developments - which is one of the best Rails related technologies.

So that's all I've got. Let me know of any other worthy sites, I'm always looking for more sources to keep on that leading edge.

Here's an interesting article sent to me by my esteemed boss; but it doesn't precisely describe the Web 2.0 threat.

"http://sfgate.com/cgi-bin/article.cgi?f=/c/a/2007/07/30/BUUSR98VI2.DTL"

My thought is that the prime vulnerability in Web 2.0 (aka AJAX) is allowing AJAX calls to the server that change data without authenticating the request. Another vulnerability is if someone logs into the app, then leaves to a malicious site, and that mal-site (did I just make a new term there?) does an AJAX call to our server using the user's legitimate auth cookie.

What to do? Verify the request of course. If your user request came in from some IP, verify that IP the next request. If it changes raise an alert. But IPs can be spoofed. Next line of defense is the rest of the HTTP data. Did the agent change? Were they using FireFox, but suddenly your getting a "curl" request? Did the language change from 'en-US' to something else?

You can follow this "white rabbit" a fairly long way. Of course all this added security verification will come at a cost. Additional data stored in your sessions, which could be DB records, files or a caching server. Added latency to the calls while this security work is done. Thus I wouldn't bother with this security for internal applications sitting comfortably behind the lock-solid IT-managed firewall. But, engineers developing web apps that will live on the wild open-web should think long and hard about these issues, lest it be your paying customers whose credit cards are pilfered.

Before I go, I don't want to neglect the "GETs should be safe philosophy". Don't have an HTTP GET request doing data changing operations within your application. This is just bad design that mis-uses the HTTP protocol.

[display_podcast]

OK, this was supposed to be my first blog post, but then I wrote that bit about web 2.0 security. I almost dropped this post but I'm having so much fun engaging in flame wars with my co-workers I had to finish this one. Hopefully someone will take up the PHP banner and we can duke it out.

That said, here is my almost first post only slightly modified for completion of thought....

I've always thought blogging was for lonely people who spend too much time at their computer. But since becoming a Rails junkie I find that reading the blogs of Rails core members is a great way to keep up with new Rails techniques. Which leads me to the titled purpose of my first ever blog.

The Day PHP Died. For me that is, well you could alternatively title it "The Day I Discovered Rails" or maybe "The Day I watched that DHH video where he makes the blog-site in under 10 minutes".... well, those don't seem as catchy and hyperbole always generates more interest.

Now I won't get into my near zealot belief in Rails, that's for another post. The focus here is why PHP, as a language is a "has been" technology. It definitely had a good run, gajillions of lines of code have been written in PHP and thousands of web sites/apps are written in PHP. I myself was a PHP developer for years. In fact, it was my PHP knowledge that got me hired here to PC-Doctor.

However, scripting languages, like all technology, evolve and PHP is now face to face with Darwinian reality. Why do I forecast the slow inevitable decline of PHP?

In a word, consistency. PHP has got to be about the most inconsistent language I've used. The fundamental issue is that a language like Ruby is very true to the OOP paradigm. PHP is not. This means that in Ruby if you wanted the length of say a string you would do string.length. You have a similar named operation in Ruby for an array, like array.length. Therein lies a great strength of Ruby. Any object, for which a length makes sense, will simply implement the length method. Now, how does PHP handle this? If you want the length of a string you do strlen(string), if you have an array it's count(array). You see the problem? The real problem? Since the strlen and count functions are not connected to any object they must have distinct names to co-exist. Thus, PHP core is filled with a gajillion functions, some named so you know what they might do "array_keys()", others not so much "each()". This makes PHP code much more difficult to write and read. I spend far more time visiting the PHP manual web page than I do for Ruby. Often when I'm at the PHP manual it's because I can't remember the precise name of some function, or the order of it's parameters.

Another feature sorely deficient in PHP is a solid interactive console. There is some kind of console in PHP but I tried my best to make effective use of it and it just didn't work out. Contrast that with Ruby/Python where one can simple type on the cmd line ["irb","python"] and that's it, a nice interactive console shell opens and you can quickly work out an idea or test some curiosity.

A third feature where PHP leaves me wanting is in code organization. Ruby/Python are fundamentally OO languages. Thus everything is a object, and every bit of code you write is contained in an object or module. This makes building large applications much easier to organize and maintain since all your code has it's own place and namespace. PHP offers classes, but they're optional and you can include files but there are no namespaces.

Finally, there is one thing that PHP has where it outpaces Ruby and Python. The PHP documentation manual is world class. I find looking up a PHP function very easy to do either by scanning a list of function library or using the search feature. Of course, if you're using PHP your going to need that documentation every time you set to work.