Branching Out...

I have started a new blog, "Ruby Eye for the Java Guy" where I will put all my Ruby related content from now on.

I'll still post non-ruby related stuff here.

Read More

Web 2.0 Lessons Applied to Development?

I just read a blog post from RailsEnvy on some Web 2.0 Expo Wisdom and it got me thinking if some of the points listed couldn't just as easily apply to software development...

"7. The average user is typically below average. Anything you ask a user to do will require skill. Your typical user always feels like an idiot. In any design, you need to ensure users feel competent from the get go."

Now I'm not saying all your collagues are idiots, but they might not be a rocket scientist like you. Think about others when you code. Simple things like naming sensibly...

"8. Nobody reads the manual. Most console game controllers have 16-18 controls/buttons, but are so simple that you can play through the entire game without reading the manual at all. Games make heavy use of affordances, meaning that activities should do what you expect them to do. In other words, make sure things are intuitive."

Same as before. If it's intuitive, then it'll likely be less buggy. Noone likes "intuitive after a while..." type code

"10. Stay consistent. When users interact with software, they’re building a mental model of how it works. If you have a widget in two different places and it doesn’t do the same thing, it will get reported as a bug."

This is the argument for the ever unpopular coding conventions. No one likes something cramping their style, but if we all have an idea of what to expect, then we're all more productive...

"11. Allow people to show their personality. If someone is able to personalize their profile or avatar, they are going to be more emotionally connected to the website."

... and the converse to the point above. Don't go over the top. Developers aren't machines. Let us express themselves occasionally!

"12. If you have any sort of ranking system or ladder system on your website, be sure to reset it every month. No one likes systems where the “Rich get Richer.”"

Just as no one likes a smart ass. Sure, let the PM's get their complete stats, but share the love. We all like to be appreciated for what we're good at.

To sum up, as a wise man once said, "it all comes down to the people", and it does. Bear this in mind and make everyone's lives easier during development.

Read More

Instance Variables, Initialization and Class Hierarchies in Ruby

Perhaps it's because I come from a Java background but I've had a hard time over the last few weeks getting my head around instance variables in Ruby, especially their initialization and how they play in class hierarchies. Hopefully this quick overview of what I've learned saves someone else the pain I had.

I started with a simple hierarchy:

I ran this with the following test case:

And got the following:


Wait a moment, I thought, if ChildClass extends SuperClass, why doesn't it have an @foo instance variable? "It's because we haven't called the SuperClass initializer (with "super") within the ChildClass initializer" said Ruby; "If we do we get this":


This was hard to get my head around. I'd declared the @foo instance variable within the SuperClass so why wasn't it show by inspect? Even simply as having a nil value? "Get over it" Ruby says, "that's how it is. If you want to set the value of something, do it within a method", so I did:


And when I ran the extra bit of test:


I saw that all was well and good:


Two final things, I thought, if nothing happens when I declare the variables did I need them? Also, what if I added another method ("super_foo") to SuperClass which would set @foo to something new would it work from ChildClass? (I kind of knew the answer to this one but just wanted to check). My final version of my class hierarchy looked as follows:


I tested it with this code:


And got this result:


And so that's it, declaring variables is a waste of time outside of a method (let go Java, let go...), use initializers to "initialise" them and use methods to alter them.. All kinda makes sense when you write it out like this doesn't it? ;-)

Read More

Project: Acta Diurna - Update 2

Things have gone well on the project over Easter. I managed to seperately prove all the concepts I needed to get things up and running (and learnt a lot about Ruby in the process). What were the elements? Well at the Ruby end it was the WEBrick server as mentioned before, plus the generation of an RSS feed (done using the simple-rss and Hpricot to grab and munge the HTML source pages) and some very simple threading (again done natively with Ruby). Where did I get the info? Why here and here...

I also had a HTML / Javascript page to complete the picture. This was made a lot simpler by Firebug which helped me struggle to remember my rusty Javascript skills. Again, I managed to take a very simple example and fiddle with it to get it to do what I needed - this time this was the source.

Now I need to parcel it all together and get it looking pretty. One thing I'm looking forward to using is Nifty Corners Cube. It'll make it look like it had a close encounter with a graphic designer in no time!

Finally, a question:

• Why can't I use my own RSS reader? You can. But this solution is zero / minimal install, and is also managed by the project. It doesn't involve me as a user having to do anything I don't understand (i.e. not everyone knows what RSS is) or use elsewhere.

Powered by ScribeFire.

Read More

Project Acta Diurna - Investigation Pt. 1

In my last post where I introduced my plan to produce a simple RSS based project dashboard I mentioned a few things which I thought would work but needed investigation. Top of my list is WEBrick and the potential to use it as a HTTP server for the generated RSS feeds.

So I did some googling and came across Gnome's Guide to Webrick which seemsed as good a place to start as any... It turned out better than that. Within four pages I had an example which I could use for the HTTP server element. The code goes like this:

# Apologies to Gnome for knicking this lock-stock.
require 'webrick'

include WEBrick # lets import the namespace so that we
# don't need to keep typing ::WEBrick

def start_webrick( config = {} )
# always listen on port 8080
config.update( :Port => 8080 )
server = HTTPServer.new( config )

# trap signals to invoke the shutdown procedure cleanly
yield server if block_given?
['INT', 'TERM'].each { |signal|
trap(signal){ server.shutdown }
}

server.start

end

start_webrick(:DocumentRoot => './../www/gen/rss')

Why so simple? Well, it turns out that WEBrick is bundled with Ruby (think of the java.util packages for example) so it's all just there. Also, what this piece needs to do isn't rocket science - just listen on a port and serve up the RSS files; requested by the dasboard.

What's next?; Well, I've had some more thoughts on the ins and outs of this and realised I need to think about packaging. I know I can package and distribute the app with the JRuby jar. This will mean all you'll need to do to get things up and running will be a .bat/.sh script with something like:

java -jar jruby.jar actadiurna_server.rb

Simplicity itself. Might get more complex when I require external gems. I need to find out about packaging them I think...

I also had a think about a logo for the project at the weekend. I think I might change the name after looking at Why's project page; need to learn the Gimp first though. More on that when I have something to actually display...

Oh, one final thing; this project seems to be vaguely in line with Eric Gamma - I heard on the Java Posse (episode #110) about his Project Jazz. Apparently he says a software dev. team should be like a village. Anyone want a local paper? ;-)

UPDATE: I'm aware WEBrick is not meant for production, (you should use something like Mongrel) but for the moment WEBrick seems just fine.

Read More