Its back to programming lately at my job. I have taken it upon myself to reinvent SWAN Manager (yet again). This is its third iteration, and has come a LONG ways since 1.0. I love the satisfaction in figuring something out, and then implementing the logic in code. It is creating something from nothing. Today I finished working on the audience builder for our Portal. The layout on the Portal side is terrible, spanning across an LDAP branch, and five different database tables. The logic cannot be inferred from the tables, and of course no source code or documentation is ever is provided on our Portal platform. The beauty is, now that is is done (100% mapped to our functions), I can determine whether any user can access any part of a channel, or announcement in Ruby.
In a (sparse) 150 lines of code, I have done what I would imagine has taken thousands of lines of fragmented thoughts stemming from many programmers in all written in Java code. There is a simplicity, and a poetry that I enjoy when writing in Ruby. Maybe someday, folks will see the light.
For this version of our management website, I had the idea while driving home from work, of making the interface for the Portal totally web service driven, and using sparse templates, and making the whole damn thing run in a few “administrative” channels inside the Portal. It seems like a perfect fit. To start with, how can I expect other departments, and other applications to integrate with the Portal if I am the administrator, and I don’t even do it? Besides, it is a management application for the Portal, so what better place? Also, I can verify that the web services are operating as expected, by having a living proof-of-concept.
Also, new in this version, I have reimplemented the way Targeted Announcements are sent. Before we had a Java class (that I threw a fit about until a certain company gave me the source code), that we modified to accept switches when called for the parameters. This class (and its 10MB of dependencies were “jarred up” (fuck you to Java), and placed in our management website. When someone filled out the nice announcement form, I would take all the parameters, and build the switches on the fly, scp the jar files over to the server, and run a Java command from the bash shell. Needless to say, this sucked. Ruby and Java should never mingle. If I wanted to change the way the class was implemented, it was back to Java, and mucking around with an API I didn’t understand (once again because the company is TERRIBLE at documentation).
I finally got smart, and decided to use Wireshark (thanks James!) and “listen” to the mysterious SOAP traffic occurring from my machine to the server and back. After a few minutes of isolating the traffic, the mystery was revealed as little more than a few dozen lines of XML. A lightbulb went off in my head, and I decided to use Ruby’s REXML library to construct this procedurally based on the form (from earlier) the user fills out and submits. The end result is a cleaner interface, no Java, no scp, or Bash environment, and best of all 9.99MB less space. Hold your applause.
I also decided to really take a good, hard look at all of my models and associations and made the startling discovery that the first significant portion of your project should be ironing out these associations. If you skimp here, your entire application will suffer. Badly. That is because you are laying the foundation here, and if you do it wrong, or half-assed you have really missed the power of Rails.
After a few wonderful hours at home, self-medicated on NyQuil, I managed to get a “user” to be created with just a username. For instance, “User.create(:username => ‘bsimpson’)”. This in turn, spawned off a frenzy of associated activities, including building roles the user belongs to, checking community groups the user is a member of, and building a list announcements the user has authored. It is nice to build an application, thinking about the associations between models first and foremost. The semantics pay off quick, with actions such as “user.groups”, “user.announcement_authorships”, “user.channels”, etc.
Hopefully in a few more weeks, we will have the version 3.0 in production, and in use by a few of our channels.