Posted by Kevin
Thu, 18 Jan 2007 03:18:00 GMT
So two people, which in the world of the readers of this blog, corresponds to about the size of the Northern Hemisphere, have read and been confused about this rails thing. They and I know that the internet is out there to help, but it’s probably expecting a lot for people to leave the comfort of their source for news on everything. It’s time to set the record straight and clarify what exactly it is that I keep going on and on about.
Rails, short for Ruby on Rails, is, as it turns out, a web development framework. It was created in 2004 or thereabouts by a person who talks funny. Rails was built using a programming language called (surprise) Ruby, which has incidentally been around for much longer (publicly released in 1995).
The great thing about web development is that you can write programs that are available on any reasonable computer on the planet. One unfortunate characteristic of software development in general – and web development in particular – is that easy things often turn out to be pretty damn hard. Web development frameworks try to help us avoid this unfortunate state of affairs. The great thing about rails is that it actually makes web development a pretty good time for developers. Rails attempts, with a fair degree of success in my mind, to make the easy things easy and the hard things attainable. Ruby (that’s the language, remember) is also not to be neglected any time “programming” and “fun” happen to be used in the same breath, since rails obviously wouldn’t have been possible without it.
And now that our ducks are in a row, go enjoy rails!
Posted in Rails, Struggle, Software | 2 comments | 1 trackback
Posted by Kevin
Sun, 07 Jan 2007 22:00:00 GMT
Working with ruby on rails for a while has made me curious about django, the web development framework written in ruby’s buddy language, python. The tipping point for actually checking it out came after my friend Matt Langeman told me about the django beta book.
So I’m rocking along with the book, which is luckily very hands-on. The good stuff begins in chapter two, where they go over how to set up your system to actually run django.
I’ve already got python:
> python
Python 2.4.3 (#2, Oct 6 2006, 07:52:30)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
So on to this django framework itself. Somewhere near the beginning of chapter two, the authors say that “Most people will want to install the latest official release.” I will soon begin to doubt this when I see the number of errors that can be produced by simply following along with the examples in the book (granted, some of these struggles certainly have to do with my specific environment). Anyway, onwards:
> wget http://www.djangoproject.com/download/0.95/tarball/
I unpack the app, create a project and run: “python manage.py runserver” and I’m off to the races and … no wait, I can’t hit anything on 127.0.0.1 since I’m not running locally.
How about “python manage.py runserver 0.0.0.0:8000” ... much better. I manage to arrive at the welcome page in my browser: “It worked! Congratulations on your first Django-powered page.”
While moving through chapter three and setting up urls.py (some sort of distant relative of rails routes), I’m slapped with the error: “ImportError at /now/ No module named mysite.views”.
Damn, I didn’t call my project “mysite” like a good tutorial-follower. I change “mysite to “survey” in urls.py and I’m golden again for a minute…
After a very short minute, I get “AttributeError at /now/ ‘function’ object has no attribute ‘rindex’”.
Someone from django-users@googlegroups has apparently had this issue before, and I get referred to the django docs. I discover that the cool kids (or maybe just the kids that aren’t using django edge) use a string for the second argument of the so-called “tuple.”
Bad:
(r'^now/$', current_datetime),
Good:
(r'^now/$', 'survey.views.current_datetime'),
The page loads, displaying the current time. The book reminds me that I have just created my first dynamic page with django. Fair enough.
So I’m rolling along in
chapter four by now, and the authors are wanting me to start up the interactive python interpreter by typing “python,” which I do. I also type: “from django.template import Template”, but am greeted with an error:
raise EnvironmentError, "Environment variable %s is undefined." % ENVIRONMENT_VARIABLE
EnvironmentError: Environment variable DJANGO_SETTINGS_MODULE is undefined.
Apparently i was supposed to set up this environment variable before firing up my interactive python client. After running: “export DJANGO_SETTINGS_MODULE=survey.settings” on the command line (where survey is the name of the project I created), I try to import Template again. ERROR: “EnvironmentError: Could not import settings ‘survey.settings’ (Is it on sys.path? Does it have syntax errors?): No module named survey.settings”. So at this point I’m wondering why God doesn’t love me. Someone with a searchable chat archive, however, does love me. I’m told to run:
export PYTHONPATH=~
This apparently worked because my django project was one level below my home directory. I finally get the simple interactive python example to work.
Chapter four is all about django’s templating system. One distinguishing feature of django templates is that they are limited. Rails templates allow arbitrary ruby code, whereas their django counterparts allow variable injection, looping, and other assorted goodies, but do not evaluate just any python code you throw between {% %} tags.
So as I’m getting ready to use my first real template in a separate file, I need to set up the path to my templates. I try to do it the cool-guy way:
TEMPLATE_DIRS = (
os.path.join(os.path.basename(__file__), 'templates'),
)
And I get an error when I try to hit a page: “NameError: name ‘os’ is not defined”. Not cool. Luckily the fix is simple. I add the line “import os” before setting up TEMPLATE_DIRS in the settings.py file. No more errors, so I throw the sample template current_datetime.html into the templates directory and try to fire up the page in my browser:
TemplateDoesNotExist at /now/
current_datetime.html
The “Template-loader postmortem” that comes up in my browser seems to be telling me that it’s trying the find the file under settings.pyc/templates/, which seems wrong. So hell, I want to get back to the book, and I don’t have to be a cool-kid at the moment – I’ve probably got some time here before rolling out my first production django site – I hardcode the absolute path for TEMPLATE_DIRS. Bingo: fixed.
In talking about templates, the authors make a statement that sounds slightly more than controversial for someone coming from a rails worldview: “Because that’s business logic, it belongs in the view.” This highlights a major difference in language between the rails and django clans. The authors really wanted to make the point that business logic does not belong in the template (which is basically what rails folks would call a “view”). The way django relates to MVC (or MTV as they sometimes seem to call it) is clarified a bit more in chapter five.
As I’m reading along, I learn that “python manage.py shell” is the equivalent of rails’ ”./script/console”. I’m also able to connect to the MySQL database on my box successfully from the python prompt with the django settings on my first try. Sweet. I’m patting myself on the back when the book blindsides me with a note that I have not yet created a django app. Mutter … I could have sworn that I ... . The authors patiently explain to me that an “app” is a portable set of django functionality, and that I must create an app in order to make use of django’s models. I’m right about at the point where’s I’m ready to go create an app on the command line when I realize that, ohmygod, the funny things in the left margin of this book are comments! Man I bet that would have been useful. :) It seems like the authors probably could have said one or two things about the comments on the first page of the book – or maybe they assumed that people were paying attention…
In any case, this django stuff is a good time. I will likely continue on with creating an app, connecting to a database, and all sorts of delightful things in chapter five and beyond, but I’ll try to keep my two cents contained to the comments in the book. Your two cents can go in the comments below.
Posted in Django, Software, Rails, Experimentation | no comments | no trackbacks
Posted by Kevin
Sun, 05 Nov 2006 00:18:00 GMT
So I got around to reading Waltzing with Bears: Managing Risk On Software Projects by Tom DeMarco and Timothy Lister. They wrote Peopleware, my favorite software-related book ever, so I was bound to get around to it eventually.
They’ve got a whole chapter dedicated to risk discovery – the process whereby you turn your project upset down and shake until all of the risks are on the table. This process can get off to a (good?) start with a group session where participants imagine catastrophic outcomes for the project. You have to get into your nightmare frame of mind. If you’d wake up in a pool of sweat thinking about your project, what the hell would the dream have been about? Once you’ve got a catastrophic outcome, think of scenarios that could make it materialize. The root causes of these scenarios are great inputs into your project’s risk list. Additionally, DeMarco and Lister posit that the following risks belong in the risk list of every new project:
- Problems that have arisen on past projects
- The five fundamental risks of all software projects – schedule flaws, requirements inflation, turnover, specification breakdown and under-performance
And best of all, the authors push the blame for late software projects slightly away from developers and just a bit closer to the project managers who feel like the schedule (read deadline) should be based on the most optimistic release date. They call out project managers for keeping good tabs on the small risks – those risks that are easily managed – and neglecting completely the unfortuitous oncoming train. If “It’s okay to to be wrong, but not okay to be uncertain” sounds like the way your shop deals with schedules, you’d do well to pass around some copies of the book .
See also their cutesy uncertainty graphing tool.
Posted in Software | no comments | no trackbacks
Posted by Kevin
Mon, 26 Jun 2006 10:20:00 GMT
When’s rails 2.0 coming out?
We’ve got to clean some stuff up first. The API will break some old stuff, and rails will lose its backwards compatibility for the first time. We’re pretty focused on 1.2 for now. There’s no rush for 2.0.
What are the strengths and weaknesses of rails in the corporate environment?
Don’t change rails for the corporate environment; fix the corporate environment to work with rails.
Coke or Pepsi?
Coke.
Do you guys hate database fixtures as much as me?
Yes. (The guy from cd baby doesn’t use them)
These guys got a lot of love from the audience, gave a lot of love back back to the audience, and gave a lot of love to each other as well. It was a neat way to end the conference. And the standing ovation at the end: well-deserved.
Posted in Railsconf | no comments | no trackbacks
Posted by Kevin
Mon, 26 Jun 2006 09:56:00 GMT
Update: After wondering for a while why my stupid notes from railsconf were getting top results for google searches on “Selenium”, i realized that I had mispelled Selenium (yeah, some other folks apparently thought there was another “i” in there as well). Whew, lucky I spotted that – now notkeepingitreal.com can get back to its relative anonymity.
Now, back to your regularly scheduled post:
Acceptance testing seems to be all about verifying that you can manipulate the interface to provoke the expected behavior from your application.
Watir
- Browser specific acceptance testing utility
- Uses push mentality
- Has IE and firefox browser compatibility, Firewater – nice name
Selenium
- Works across pretty much all browsers
- Uses pull mentality
Sahi
- Smaller acceptance test utility
- Tests are written in a variant of javascript. You start up a java virtual machine and hit the page in a browser through a proxy.
Things we want in an acceptance test utility
- Watir-like API
- Compatibility of Selinium
- ActiveRecord integration
Thoughtworks has been working with Selinium and is in fact actively developing and hacking on Selinium to try to make it work better for their situation and for the community at large. Awesome, our quality assurance folks will appreciate.
Posted in Railsconf | no comments | no trackbacks
