grantmichaels'blog

wordle.net

I’m about 8-9 months into studying web development technologies, which more candidly means that I have been doing a lot more researching, reading, and talking to people in the web development scene than actually coding at length on any particular application.  I’d like to very quickly thank Giles Bowkett for giving me the single most important piece of advice to date – which was to diversify and learn multiple languages – at a time when I was racking my skull over choosing between Ruby and Python.  I’ve exponentially increased my osmotic comprehension rate since using the compare and contrast method to learn programming languages.  The additional benefit is obvious in that you end up knowing multiple languages, which can only pan out positively in the end.  It also makes possible the “using the right tool for the job” concept.  Ezra Zygmuntowicz has also taken a few moments to be helpful on a couple of occasions, but I’m mostly thankful for his Rails deployment book which was very helpful during it’s period as a beta PDF.  Unfortunately, the book was outdated in a lot of ways by the time the print edition arrived to my house, but it’s not Ezra’s fault, it’s the plight of ever-evolving Rails deployment technologies at the heart of the problem.  Duncan McGreggor, aka Oubiwan from the Divmod team, has also been helpful as of late, although I think he could be more helpful yet (nudge: create a step-by-step to get from a fresh ubuntu server instance to a working nevow development stack).  Mike Pence, whom I live near, and am in regular communication with, has also been helpful in sorting out the strengths and weaknesses of the many options available at present for delivering web content.  Lastly, I’d like to thank Monty Williams (from Gemstone) for taking time to communicate twice regarding MagLev and the Gemstone/64 VM.

So, I’ve become efficient at deploying Rails, but only to at once realize that I don’t want to have to perform that function with any regularity if I can help it.  There are a lot of technologies involved in getting dynamic content to render in the collective browsers, all technologies which are rapidly evolving, and it’s really quite time consuming to stay up-to-date on all of the varied tools used in the different web production development chains.  Backwards compatibility is given a very different perspective in the open source community than what I’ve experienced previously in programming computers on the whole, and I’m not sure that I’ve enjoyed having to micromanage the interaction amongst the gems, eggs, plug-ins, scripts, virtual machines, Rails version deprecations, proxies, caches, packages, dependencies, and all of their obtuse interactions and collective version-related crisis.  I think it would be prudent if more things that are created as plug-ins for Rails were instead created as libraries and packages for Ruby.  This would ultimately serve Ruby as a language and at once create a healthier competition amongst the frameworks where they could better specialize and take care of their smaller communities of dedicated users.  It’s not usually a winning approach to try to be all things to all people, but Rails is certainly trying to fill that role in the MVC web framework category.  Rails feels like a porker right from the outset in my opinion, and you don’t have to be sensitive or knowledgeable to get that sensation.  Load up Rails and then load up web2py, make something simple, and then compare the speed.  It’s right there in your face.

With Rails, you know you really want Merb from day one, but the Merb community isn’t providing an obvious point of entry for entry/intermediate level coders.  I’ve recently come across this with regard to the aforementioned Divmod suite on the Python side as well.  I had some misunderstandings about the nature of Mantissa and it’s relation to the rest of the Divmod suite, and have been mistakenly thinking it to be an abstraction layer on top of Nevow / Twisted.Web / Axiom – and doing so in a fashion similar to how an ORM abstracts away SQL as in the case of ActiveRecord, DataMapper, or SQLAlchemy.  Clearly, in this instance I was confused and this has probably contributed greatly to my inability to get going and find an entry point into socket programming in Twisted to date.  The end of the grantmichaels vs mantissa saga is actually going to be a segue into the beginning of the grantmichaels vs nevow journey based upon this afternoons time in the Divmod channel on freenode.  Oubiwan and dash were friendly and helpful in righting my ship, but it didn’t make a tutorial on getting from a fresh ubuntu server instance to a working Nevow stack appear magically in the blogosphere – and that is really what I’m looking for, but will apparently have to make.  I think it would be wise of them to produce one, that is, if they want to attract entry-level and intermediate cross-over coders to their product, especially given the WSGI commonality that has formed between Ruby and Python with the creation of, and perhaps more importantly the widespread adoption of, the Phusion Passenger product for Apache2.

There are things I like about Ruby, and there are things I like about Python, and best of all, there isn’t a great deal of overlap in those sets of things.  I want my web server to be ubuntu, apache2, and the WSGI gateway and I don’t see any reason why I can’t use both Ruby and Python in that case, each for what it handles best.  It should be simple enough to hit shared databases and content, and route to both frameworks if desired.

I think that specialization is definitely a good thing for a framework, and when it is the driving principle behind future design-work, it brings with it attention to optimizations and other forms of quality improvements in the spirit of competition against other competing frameworks.  I think as a goal in creating a framework that you want to make it easy to do something specific – and then to ensure execution is carried out predictably well.  If that were to be accomplished via slower evolving, better tested Ruby libraries instead of Rails plug-ins, I think the net effect would be an improvement in the longevity potential of Ruby as a useful programming language in all arenas.  In that scenario, the libraries would be more worthwhile to take the time to master, since they would also work for creating desktop applications, network/socket programming, and well, everything.  I think it is safe to say that we’re seeing the melding of desktop and browser based applications on the whole.

For everything Rails gives me in terms of up-front productivity, there have been multitudes more additional processes to have to learn to get myself from prototype to becoming a deployed rails application for the public.  As I began to tinker with Rails, Mongrel was settling in as “the thing,” and then soon thereafter it shifted to the clustering and pooling of them.  This was only 8-9 months ago give or take, and since that time there have been a plethora of newer contenders to de-throne Mongrel, each bringing something new and evolved to try to solve the problem that is Rails deployment.  Perhaps this is partially due to Zed Shaw’s decision to leave the developing of Mongrel to the rest of the Rails community.  He seems to be pretty competent and I’m sure Mongrel would be somewhat better off if it had been receiving the continued attention of it’s creator for the past months.  I think though, that it’s pretty safe to assume that we’re really talking about water under the bridge at this point.

I can’t stop reading Python books for improving my generalized computer science knowledge.  The book authors for Python are very different in nature and presentation style than the Ruby authors, and they seem to spend a lot more time presenting Python as it fits into the larger constellation of programming language options.  Rubyists, on the other hand, are typically very busy talking up how getting to code in Ruby is some form of pleasantry to them.  Another major fault of Ruby book authors is a need to show how “cool” refactored Ruby code can be, which isn’t as useful when you are learning as showing code which better follows the thought process.  Refactoring Ruby into DRY’d code is the process I believe, but the book authors make it seem like they are so slick and that they produce this final product on the fly.  I find this hard to believe in many instances.  Presenting elegantly re-factored code kind of flies in the face of creating maintainable code over it’s lifetime of use.  These book authors would be doing the community a service to stop spending 3-4 chapters per book extolling how Ruby on Rails has single handedly improved their satisfaction with working in general, unless of course, these authors never actually have the responsibility of deploying any any of the code.  Surprisingly, I’m actually quite fond of Ruby coding, and it has become my second favorite syntax, yielding only to Smalltalk in my opinion.  Rails just hasn’t done it for me, on the other hand.

I’ve been particularly enjoying Ruby By Example and Practical Scripting with Ruby, and would consider these two books to be those which have helped me to learn Ruby more so than all of the other more frequently suggested books – including the ever-revered “pick-axe book.“  While I’m sort of doling out praise, however, it is a very direct matter to begin to develop in Python, perhaps aided by the fact that it ships with Ubuntu in a well-performing state right out of the box.  This is a hugely important feature, and I was able to start producing a lot more quantity of – and more varied applications of – code in Python that I had prior in Ruby.  It is amazing to see just how quickly you can be off and running and developing and deploying production use code in some of the Python frameworks.  I thought web2py to be a great little framework, and developing for the web in the browser is all too sensible.  I’ve not been following the Google group discussion for the past month or so regarding web2py, but it was working nicely with Google App Engine prior to losing my focus, so I’m sure things are continuing to move forward on that front.  It’s a real treat to have a crafty, self-contained stack as is packaged for you in web2py, and I was surprised at how well it performed when I gave it a go for a few weeks.

Literally just moments ago I tried (once again) to find a point of entry into starting to tinker with the Divmod suite/stack.  Between the preceeding paragraph and this, I spoke to oubiwan and dash in the divmod channel on freenode and it is my understanding that they are still working to have their product become available in an easily consumable state.  There is still a need for a good Rails-scene type blog post or wiki entry on how-to get from a fresh Ubuntu server on a SliceHost or linode VPS to a properly built Nevow (or better yet, Mantissa) stack.  It seems as if someone who does this at work everyday could easily just cut and paste their terminal window content from the next time they set up a box over at Divmod, right?  <nudge x2>  If I can’t manage to get a stab at using the Twisted library, I might just return 80% of the books on all of my shelves to Amazon and take a dedicated stab at learning Erlang and Erlyweb and enjoy the coziness of a really eccentric community with a really powerful product.  I was hoping to use Python instead, as I felt it wise to learn a language with such a broad scope and the “batteries included” impetus buffers changes of heart about what type of products you might want to create.  Time will tell if I ever find the elusive entry point into the Divmod stack, be it Nevow or Twisted.Web2, and begin developing in a Python framework and picking up Python along the way, much like I’ve been able to pick up Ruby while learning Rails.  I’m extremely hopeful Divmod takes a few moments to create a wiki entry on the Nevow and/or Twisted.Web2 and/or Mantissa pages to help people who have little experience with setting up a Python web development environment use their framework as their starting point into web programming with Python.  That seems like a wise move in a marketing sense, regardless of my self-serving intention to have it for my own utility.

It’s been quite an adventure, and I’ve just barely scratched the surface!

grantmichaels

P.S. I’ll have to make this entry’s wordle art from another box, since apparently this ubuntu box isn’t playing nicely w/ the Java applet that is needed …