kellyfelkins.org: software development

rav this!

Do you know about the Rails Application Visualizer.

RAV Visualization

This thing is about the easiest thing in the world to use. You got to love it when the instructions include:

3. Chuckle and execute rake visualize!

I keep the model view of my application on my desk. The text is getting so small I’ll soon have to either use a magnifying glass or at least print it on larger paper.

Share this article on

Comment

* * *

permalink

please don't feed the rails programmers

topicvote application screen grab

My friend Jane Macfarlane and I did a presentation at the East Bay Ruby Meetup on Thursday, December 14, 2006. After a brief introduction we created a Ruby on Rails application…live.

Writing code is challenging, but becomes truly sporting when you have 20 or 30 people watching you. When I told some developer friends that I was doing this, I got replies like “Oh, this should be exciting” — and I don’t think they meant that in a good way. Of course we rehearsed and scripted the event so it went smoothly, for the most part.

One exciting moment for me occurred when I was trying to install the acts_as_authenticated plugin. The command failed and I was briefly baffled, when an audience member asked if it required network access. Of course this was the issue, but the bigger question to me was whether I was going to bump into similar issues through out the presentation — thankfully, I didn’t.

The concept was to build an application from start to finish in the allotted time of 1.5 hours. I’ve done this before and knew the application had to be simple, but I also wanted something that was not a standard rails demo applications: blog, todo list, or recipes. I really wanted to show some key features of rails and I wanted the process to have at least 2 major phases in order to show incremental development. Jane and I settled on an application to allow people to submit and vote on future topics for East Bay Ruby Meetup meetings. We called the application TopicVote.

My thanks go to William Sobel for doing the normally thankless job of organizing this meetup and this particular event.

For those that asked for the presentation/demo material, here it is.

If you want to run the application, of course you will need to have:

mysql
ruby
rails

Then to install and run, you will need to:

untar and unzip the application archive (tgz) file
create the databases (topicvote_development and topicvote_test)
update the config/database.yml file with your specific database information
cd into the application directory, and …
run it (script/server)
Oh yeah, then visit the server with your favorite browser at http://localhost:3000

Here are the files:

Finally, during the Q&A we briefly discussed a program called DENIM. For information on DENIM, please check out my DENIM article.

If you’ve read this far, please consider rating me at Working With Rails.

Thank you.

Share this article on

Comment [319]

* * *

permalink

miguel's hell of gratuitous rewriting

Miguel de Icaza writes of trying to get work done and his hunt for a reasonable (in speed, memory footprint, and capability) terminal emulator.

Essentially, people rewrote some of Miguel’s work. They were making it better in some way, but to Miguel it became worse. Part of the irony is that Miguel’s version was also a rewrite. And it seems especially painful because this is a project that Miguel started and that many people attribute to him.

Share this article on

Comment [341]

* * *

permalink

installing ruby and rails on debian

Getting ruby installed on debian has been a challenge, but most of the issues seem to be worked out at this time. The challenges stem from the debian ruby package maintainers splitting the ruby standard library into multiple packages as is the practice on debian. This can cause ruby utilities, such as the ruby package management system, rubygems, to fail when items it depends upon are missing. These problems are worsened by some very, very poor error messages and some bugs in the ruby and utility software. Additional problems can be injected by the user (in this case, ah, me), by attempting to fix problems without fully understanding all of the components and their interactions¹.

The ruby on rails wiki has instructions for installing ruby and rails on ubuntu, debian testing and unstable (I think that last comma is in the right place). The gist of the instructions is:

if running unstable, just install the ruby on rails debian package
if running testing, install a specified list of packages to get ruby working, then install ruby gems in the standard ruby way, then use ruby gems in the standard way.

Just now checking the instructions on the wiki I expected them to be different—they have improved the instructions and they are almost exactly the instructions I planned to list here.

My only beef with the testing instructions is they use apt-get and not aptitude. Aptitude is the current prefered package manager on debian but debian gurus tend to use apt-get. Both will work but aptitude will keep track of packages that were installed in order to satisfy dependencies of other packages, and remove those automatically when the packages that caused them to be installed are removed. In the instructions, simply replace “apt-get” with “aptitude”.

I don’t like the unstable instructions either and here’s why: The concept is to use debian’s package management system to manage your ruby packages. In theory this is fine. In practice, so far, the debian packages have been trailing the rapidly moving ruby packages by a substantial amount. I doubt that debian will be able to keep up with ruby in the near term.

¹ I had a strange mix of most things worked, but some didn’t and nothing I did fixed it until I removed ruby and eveything that is related to or wants to someday be ruby from my system, and then hosed out the system at the local car wash. The problem was that I tried to install ruby on several occasions using every technique or trick I could think of short of switching to a new distro, and I was close to doing that. I lost track of these various ruby installs which compounded my problem. I discovered this by deciding once again to start from scratch and follow the directions of the experts from the page referenced above. So I used debian’s aptitude to completely remove ruby and rails—this alone is not easy since aptitude will not remove a package if there are any other packages dependent on it, and I have not discovered the trick to finding those dependencies. After thinking ruby was completely removed for some reason my fingers typed ‘ruby -v’ at a bash prompt and I got a very nice ruby version number as output! Ruby was indeed still alive on my system. So this time I did a find command from the root for anything ruby like, and found my other ruby installation. When I was satisfied that ruby was no longer on the system I proceeded with the expert instructions, and life has been good ever sense.

Share this article on

Comment [320]

* * *

permalink

why do Java developers like to make things so hard

In TURNER’S VIEWPOINT: Why Do Java Developers Like to Make Things So Hard?, James Turner takes a stab at what’s wrong with java.

The LunchWaitress takes your order, brings over your food, but there’s no plates to put it on because you forgot to get a CutleryFactory and invoke getPlates, so the Waitress throws a null pointer exception and you get thrown out of the place.