Wag of the finger

How’s this for test output:

1
2
3
4

>grails test-app -functional
Tests passed: 3
Tests failed: 55
{% endhighlight %}

Whoops! Well, those are functional tests, and this was a UI overhaul, so that’s to be expected. Let’s try integration tests:

1
2
3
4

>grails test-app -integration
Running 69 <Beavis Laugh> integration tests...
Tests passed: 56
Tests failed: 13

Meh. I can’t deploy at this point. I didn’t write those tests just to ignore them.

What did I do wrong?

Let’s identify some of the mistakes I made. Since I’m under the bus already, let’s not stop after the first axle.

1. Too many things going on. UI Upgrade + New Screens + Navigation Overhaul = TOO BIG!-
2. I should have used a prototype for the UI changes. A bunch of HTML/CSS files would have been perfect. I could’ve concentrated on look/feel and Jquery without messing with Grails code. It would have been easier to demo a prototype to the users, also. I could have cleaned everything up when integrating the prototype into Enrollio. Lesson learned.
3. Not much refactoring. I would fix up a screen’s UI, then add functionality and never bother to refactor or run tests. Gack!
4. Never thought about merge path. These changes have to go back into the main branch /sometime/. I should have gotten “Done Done” with smallish tasks, and merged quickly / often.

What’s Next?

I don’t want to compound/repeat my mistakes and blaze through this. The new functionality still doesn’t have any tests. Bad Monkey!! I want to identify small tasks, complete them, and merge them back to the master branch. The benefit is that Enrollio will see steady improvement, and not a giant leap with a bunch of bugs and ugly / half broken code and tests.

Rules for integrating new stuff into Enrollio:

• Tests should stay at 100%
• Keep merges simple and small
• Merge changes into master branch ASAP

Plan

1. Go back to the main branch of Enrollio. With Git this is very simple, and I can easily pull changes from the branch where this train-wreck started.
2. Upgrade the UI first. Limit to just the CSS and /maybe/ navigation improvements. Don’t remove any functionality.
3. Identify the new features that I put into Enrollio and do Test-Driven development.

I’ll post an update next week. May the Force be with me.

I spent (quite) some time last week working on Enrollio. Enrollio tracks enrollment and attendance for students at Byteworks. It’s written using the Grails framework by yours truly, and it’s open source.

My main goals were:

1. Improve navigation around Enrollio
2. Simplify the enrollment process
3. Update the look and feel to Web 2.0, just in time for Booboobaba 3.0 or whatever the new webapp buzzword is.

Want to see Enrollio? Both Old Enrollio and New Enrollio are online. You can take the tour by logging in with username admin and password admin0.

Things I Call “Improvements”

• The student search bar is always visible for logged-in users.

• You can resize Enrollio and still see menus and data. I want to make Enrollio usable on any smart phone except the iPhone. But don’t worry iPhone users – the iPhone Enrollio App will be available soon, for the low price of $300 bones.

• Courses are now listed side-by-side under the “Courses” tab, so it only takes one click to jump between the courses. Old Courses versus New Courses

• Enrolling students is much simpler now. You only need to click on the enrollment button and select the classes to enroll the student in. Previously, it wasn’t that simple. Trust me.

• The new Enrollio is less cluttered with lines, color shades and blocks. It also has the cutesy-pootsey rounded corners that everyone goes monkey-nuts for.

Technical stuff

I apologize for going light on the tech/geek stuff, but I plan to dedicate one or two articles about /just/ the technical stuff I learned along the way. Stay tuned!

This year at Byteworks we’ve been fortunate enough to acquire four or five more instructors for our Earn-A-Computer program.

This means that I’ll have enough time to start a Mentorship project with several students from previous Earn-A-Computer classes who showed willingness to learn new technologies and to work as a team.

The purpose of Byteworks’ Mentorship program is to further students’ technical knowledge and teach basic project management skills. I promise to blog about Byteworks’ Mentorship program at a later time. For now, I want to tell everyone about the awesomeness that is Fecba.

What is Fecba?

In case you couldn’t tell from the title, Fecba is a time-tracking system that will eventually replace Byteworks’ pen-and-paper approach to tracking volunteer hours. Currently, all Byteworks volunteers write down their hours on a clipboard in the shop. It’s a big chore at the end of the year when we total the amount of hours that volunteers spend at Byteworks.

In addition, there’s more than enough volunteers who do not track their time. If we make this app more available than the clipboard at Byteworks, hopefully more volunteers will report their hours. This will benefit us when applying for grants and spreading the word about our organization.

This is a classic “Scratch your own itch” problem. Students who contribute to the Fecba project will see our volunteers use their program every day and hopefully gain inspiration and motivation from peoples’ feedback. ‘Nuff said.

Planning, Design and Coding

There’s two main goals for this project: Learn and Accomplish. This means several things:

• We will take time to learn how fundamental things work. In this case, Fecba will be a Web application that sits on top of a database. So we will learn things like HTTP, HTML and <gasp> SQL. It’s difficult to teach the new and awesome programming tools/techniques if students don’t know the old way of doing things and what makes the new stuff better. Therefore, we’ll code it the “old way” then make improvements using “the new way”.

• We will have fun and enjoy working on the project. It’s much easier to stick to something if you enjoy doing it and have some skin in the game. The students picked the name “Fecba” and came up with the idea of using a command-line interface to enter hours. This is a cool twist and gives the application some personality.

• We will get frequent feedback from users, and put the app into production with the minimal set of features needed. When students see their project being used, they will get a sense of accomplishment, and hopefully be inspired with more ideas for the app.

In the upcoming week, I’ll post more details about Fecba – stay tuned!

See Also

• Fecba Source Code
• Fecba Staging / Demo Site

Well, here it is!! I finally got this blog started. I’ve wanted a blog for a long time, having “failed” several times before. This blog could also fail with a resounding “pfft”, along with the likes of GeoCities, MySpace, and Facebook for Smart People, but I’m optimistic that this will be my best attempt so far.

The main goal for this blog is to exercise my brain when I’m trying to learn something or get some ideas straight. I find it much easier to learn something if I write down ideas and questions while I’m trying to learn. I hope that my experiences will help other people who are also interested in whatever I’m posting about.

Here’s a list of things that you won’t see here:

• Reviews (ex: “Look at Apple’s new iWTF! It’s only $400 bones!”)
• Tweety stuff (e.g. “I’m tweeting now – look at me!”)
• Politics, religion and rants (well, maybe some rants :-)
• Emoticons (the emoticon on the line above will be the last one)

Here’s what you will see here:

• Code - I enjoy programming and do it for a living. You will see posts about Grails, Groovy, Vim and even more geeky stuff, if that’s possible
• News and articles about Byteworks. I am an instructor for Byteworks’ Earn-A-Computer class and enjoy volunteering there.
• Work/productivity tips - However, I will try to avoid feel-good “Look at me, I saved my company, rescued a drowning mule and made my boss warm in the loins” posts
• News about my band, Rusty Nail
• I quit typing things here

Enjoy!

–Nate

Make your tests more readable

Code can be made easier to read by leaving things broken up.

    assert ("a" + "foo" + "snarf").size() == 9
  

    assert ("a" + "foo" + "snarf").size() == 1 + 3 + 5
  

Another example

    def fmt = "MM/dd/yyyy"
def d1 = Date.parse(fmt, "11/12/2010")
def d2 = Date.parse(fmt, "10/29/2009")
assert d1 - d2 == 365 + 2 + 12
assert d1 - d2 == 379
  

Failed assertion

    Assertion failed: 

assert ("foo" + "Bar" + "Bazzoo").size() == 3 + 3 + 7
              |       |           |      |    |   |
              fooBar  |           12     |    6   13
                      fooBarBazzoo       false