Under the hood is nice... until the hood breaks.

So, rails. It's good. Really good. I've sung its praises before, but I do still find myself having troubles on occasion. Usually, when you have a problem with your code, it's easy enough to step through it and mentally envision the state of the code, effectively becoming a human compiler. In rails, though, that's just about impossible. I've always said my biggest gripe with Rails is it's abstraction. Basically, each object can have dozens of files in the file system determining it's code. Knowing what has scope where, which function call you're using, where the offending function is even defined is all difficult. I suppose using an IDE like Aptana would make things a bit easier, but it's still a bit difficult to get a cognitive map of the file system. Right now, I'm having trouble with some database entries, and I have no idea where. I can't seed the database, the seeds file is running completely fine (debug statement ahoy!) and the database is up and running, but one specific type of model is just not loading.

I'll probably ruminate on this for about an hour or so and realize a typo or something, but until then, I'm just left here cursing the abstraction layer for not giving me more information.

Presentational Responses

So, it's our second presentation today. And again, we're feeling the sting of no prep time. Last week, we were told we were presenting again, but not informed the week before. Our group has trouble meeting during the week due to work schedules, and this Sunday was Easter, so a group meeting was out. We did all we could during the week, and I feel like we definitely made improvements, but a bit more heads up would have been appreciated.

That being said, we are certainly better off than we were last week. A few improvements that were suggested were reducing the statistical overload, fixing the Facebook trouble (my bad), and a few other minor technical problems that will definitely be ironed out by the next presentation. I'm hoping there aren't any more before the final, though...

Easily doing things the hard way, or hardly doing things the easy way

A situation came up during a group coding meeting that brought up a design principle that I feel most of us are fairly conflicted on. When attempting to solve a problem, at what point have you spent more time trying to find an easier way to do something than you would have spent doing it the hard way?

The situation was simple, we needed to do a validates_presence_of field for one specific method, not the whole object. The User's avatar did not need to be there for any user page, but it did need to be there for the page we upload the photo on. The solutions we found were large, hack-ey, and difficult to implement, and we thought there had to be another way. There probably is another way, but at the same time, if we spend more time trying to find that way, are we really saving any time? I mean, the solutions we found weren't inefficient, they didn't make unnecessary database queries, or take up a lot of space, they were just difficult to code in and make the code look uglier. In a situation like this one, especially, it's hard to make a call. In production, you might just want to get the thing working and out the door, but in academia, you want to make the cleanest looking code you can since you'll have someone poring over it to find a way to make you lose a couple more points.

I don't really have a decision here, and I don't think there is a decision, really. Different situations warrant different calls.

Javascript, can't live with it, can't code without it

Javascript is such an interesting language, in that it's used practically everywhere, near limitless in potential, small filesize, very powerful, and yet still almost universally reviled.

Javascript code looks ugly. It is the exact opposite of "What You See is What You Get" coding. Everything in Javascript is arcane and convoluted. It's more like ancient runes than modern code. Single function calls can be lines upon lines of drilling down the right class. The tags are all over the place in the HTML and the functions like document.ready and all the dollar signs and curly braces everywhere.

And yet, it's absolutely vital for the glue that holds together the HTML, Ruby, and SQL. Without Javascript, web design would be a field reserved only for Spider-Man.

More blog posts from now on, also Haskell

I've been neglecting my blog posts for the first half of this semester, but I'm going to do my best to post a new blog post every day from here on out.

Lately, I've been doing research on Haskell libraries and Monads. Most recently, I've discovered the Haskell QuickCheck library which generates random input sets, tests functions, and outputs the results all in a single import and function call.

Needless to say, QuickCheck is incredibly small, easy to use, and powerful, as is the way with Haskell libraries. The library includes the Arbitrary data type, which has many different built-in data structures, as well as a simple API for defining more. The Arbitrary class allows for a set to draw a random sampling from, for example, Arbitrary Int defines a randomGen that returns only integer values, while Arbitrary [a] defines a randomGen that gets lists of any single consistent type of any length. Tests are made by defining a function that takes an Arbitrary and returns a boolean. Haskell's powerful type inference means that an average user doesn't even need to know about the Arbitrary class. If you make a function that takes something and returns a boolean, and feed it to the quickCheck method, it'll fill in that something with an Arbitrary version of it, if one is available.

Like most Haskell libraries, it's not without its headaches. It's a bit tough to install the right version for your purposes, since QuickCheck-2.0 and higher removed the "Batch" module from 1.0, which is very useful for running large number of test suites simultaneously and amalgamating their inputs into one simple line, so instead of "Test #1 succeeded on 100 inputs ... Test #500 succeeded on 100 inputs" you have one line that says "500 tests succeeded on 50000 inputs". Uninstalling the most recent version (which is easy enough to accidentally do, assuming it keeps the proper modules) was a hassle in and of itself, as Haskell's package manager, Cabal, has no way to uninstall packages. To remove the most recent QuickCheck, I had to track down the lib files it download to some random place on my file system, remove them, update Cabal so it forgets that the lib was there, then reinstall the older version with the module I needed.