Posted by Kevin
Sun, 22 Apr 2007 18:04:00 GMT
As it turns out, it’s not the greatest idea to store your personal documents on a company computer. I was talking with some of my workmates over dinner the other day about what happens in the moments immediately after you get canned.
In many cases, there really isn’t any chance to salvage personal documents from your company computer, cover up frivolous instant messenger logs, or any of the other things that you would likely do given 15 minutes at your computer. I guess the reasoning is that fired (and therefore disgruntled) tech workers, rather than doing something useful, would prefer to delete all of the company’s code or bring down the corporate website for a while. No comment.
Now it’s not that I’m planning to get fired this week, but one may as well take any obvious precautions and follow standard best practices. So I rolled on over to lifehacker to find myself an online backup solution; I ended up settling on mozy.
It’s been a delight as I’ve gotten into it for the past 24 hours or so. This mozy link does include a referral code that will get you (and me, wink) an extra 256MB on top of the free 2GB.
It’s a bit ridiculous that this is the way I was finally convinced to back up my documents, but the end justifies the means I suppose. So if I do happen to get fired this week, I’ll now be happy as a clam, at least as far as having access to my personal documents is concerned.
Posted in Struggle, Software, Productivity | 2 comments | no trackbacks
Posted by Kevin
Mon, 29 Jan 2007 04:36:00 GMT
So I sat down to create a website today and, as one might expect someone who wanted to create a rails application to do, ran the command:
I knew I didn’t need a database for this particular application, so, as one might expect someone without a strong grasp of language to do, I googled for words that don’t exist: databaseless rails application.
The friendly people in the search results, who apparently also enjoy making up words, were busy discussing how to go about prying rails free from ActiveRecord’s evil clutches (ActiveRecord being the database layer built into rails). There was, however, a lone voice calling out, “maybe rails is overkill for your application if you don’t need a database.”
“A web application not built in rails?!?,” I thought, “That’s frickin’ ridiculous!”
Two hours later the job was done. The secret? Why the lucky stiff and his mini-framework, Camping. As it turns out, Camping is a neat little web framework. The best thing (I can’t believe I’m saying this) is that all of the code for the entire application can be, if you so choose, in one file. So when I went to archive away the code in subversion, I didn’t have to engage in witchcraft like setting up the svn ignore property on multiple files and directories, or pulling lots of libraries into the application by way of svn externals.
The flip side to all of this is that when I installed the recommended gem, it grabbed what seemed to be a heck of a lot of other gems as dependencies. Rails has moved away from this kind of server-dependent configuration by encouraging people to package all of their application’s dependencies into the application itself. But I still think it’s cool that the application is in one file. :)
So by all means, give camping a shot the next time you want to write an afternoon-sized web application.
Posted in Software, Experimentation | 2 comments | no trackbacks
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
Sun, 21 May 2006 23:33:00 GMT
I believe that releasing new software when it is done1, and immediately when it is done, is a tremendous boon to the developer (and by definition the customer, unless you happen to be adding features the customer doesn’t want). I’ve dreamed about this a lot, and advocated for daily web rollouts at work for months, so naturally I was pleased to find that Paul Graham has argued this point in his essay, The Other Road Ahead.
There seems to be much opposition to this idea in the software arena. Releases are often no fun, and many seem to think that releases are inherently difficult, time-intensive and error-prone – and should therefore be minimized. Some say that customers need to be conditioned not to expect what they want now. There is definitely truth in this. But for all of the reasons releases are tricky, I believe they should be done more and more incrementally.
Releases are difficult
Sure. Releases will be difficult as long as:
- People assume that they happen only infrequently
- There is a perception that it just isn’t worth the effort to make them work the way they should
If I used the vim text editor once a week, I wouldn’t bother creating/learning the cutesy shortcuts. Institute a continuous release policy and the process will improve guaranteed.
Releases are time-intensive
Yes, if there are many new features, QA can become a long and uncertain process. And when a bug is found, the amount of time that has passed since the code was written correlates fairly directly to the time that will be needed to fix the bug.
Releases are error-prone
Certainly, managing the complexities and anticipating the interactions between features of a large release is an unenviable task.
So if new code is ready, or if a feature the customer wants is finished to everyone’s satisfaction, I feel that there shouldn’t be a ton of hoops to jump through before the new software finds its way into production. Developers will ultimately be happier to see their creativity in finished form faster, customers will get their feature more rapidly, and potentially, delicious manna will pour down from heaven.
1 Done, in this case, means ready for release, including any necessary testing.
Posted in Software, Philosophy | 2 comments | no trackbacks
