horrorcheck

Last week, I was feeling sort of frustrated and stuck. This week, I was volunteering at a summer camp, so I didn't have time to be stuck! I taught kids Scratch and pretended Minecraft is educational. It was fun. :D

I'm writing this from Hac Boston, a Haskell hackathon. I didn't realize that the hackathon would be more about hacking ON Haskell libraries, rather than making stuff WITH Haskell/Haskell libraries. It says "you don't even need any Haskell experience at all" on the event page but I should know by now that is always misleading. "You don't need any Haskell experience to attend -- but count on sitting at a table alone feeling dumb because you don't understand even the explanations that other attendees make obvious are super dumbed-down" would be more accurate.

So this weekend I learned that all the stereotypes about Haskell users are totally true, I was just protected from reality by the cool people at #nothaskell, Lambda Ladies, Recurse Center, and now TLC. :)

Despite this, this hackathon has helped me get unstuck on my KiSS set viewer project! I mentioned that I was trying to use Snap for my web framework, and several people noted that Snap was "over-engineered", so that made me feel better about not understanding it. I switched to Scotty and made immediate progress!

The website I'm making will to allow users to upload a KiSS set and play with it in the browser. Here's a sample set. KiSS sets are image files called "cels", color palettes, and a configuration file, all bundled into a compressed archive. So, my app needs to decompress the files, convert the cels with a palette, and parse the configuration file. Then it needs to serve up the set as HTML, CSS, and JavaScript.

I already had the conversion and parsing completed, so I just needed put it all on the web. That's what I'm working on this weekend!( I'm going to try to explain what I have so far so I can understand it. )

(blogging from Write/Speak/Code)

A few months ago I started talking to other developers about something super exciting and wonderful I had just learned about. It had totally changed how I thought about writing code, so I was excited to learn what others thought about this super interesting thing. “I just learned about test-driven development guys! How cool is that!?”

*crickets*

Apparently I'm a bit behind the TDD times. A lot of people seem to think it's pretty boring and old-hat. It's too slow and dogmatic. It's something you have to do for work, not something you would worry about with a personal project. Also, why am I bothering anyway, when I'm writing in Haskell? A statically-typed immutable language doesn't need tests. “The types are your tests.”

I learned about TDD by attending Code Retreat, which is a day-long event during which you partner with other programmers in an attempt to implement Conway's Game of Life in a single hour, *while* writing passing tests. Some people who attended –like myself – weren't comfortable with TDD, and some pairs kinda fudged the requirements in order to get closer to a working product. But a working product wasn't the point. It was about learning to work with others – and learning to test. I paired with other beginners as well as senior developers.

I was amazed how the red-green-refactor process clarified and structured the process of making the game. The game is pretty simple, but not trivial. Different teams came up with different places to start. But I noticed, the teams who started with tests and didn't try to fudge that aspect, they were able to find a small, manageable place to start and work from. Teams that didn't would often bite off more than they could chew. Then at the end of the hour, their code wouldn't run at all, while the TDD pairs could at least say, "It's not done, but we implemented cells and a grid, and we have a solid base to work from."

I took that approach into Haskell, and decided to use TDD while making a text adventure game engine. There's not a lot of good how-tos on getting started with TDD in Haskell and some of it is outdated. Still, I found the process very worthwhile. Using TDD helped me choose what parts of the engine to work on first (“well, what would be easy to test?”). It also helped when I made big refactoring changes. Haskell is great because the compiler will yell at you if the types don't match up, but unfortunately, even in Haskell types aren't always perfectly expressive. The tests sometimes caught problems that the compiler missed and often helped me pinpoint places where my logic wasn't sound.

When I started studying Python recently, I found the increased expressiveness and flexibility of the language both exhilarating and a bit scary. I was amazed how I could come up with a function, just off the top of my head, and it would run! The only problem is when a function runs, but doesn't do what I thought it would do. I feel very insecure compared to Haskell. How do I know if what I'm doing is the RIGHT way to do it? One solution has been to learn more about design patterns and Python conventions, but TDD is what really gives me a security blanket. Even when my code is ugly or un-Pythonic, with tests I can feel more certain it will at least do what I expect.

In anything, fresh eyes can cause you to appreciate something that more experienced people just take for granted. Testing is not just something boring that has to be done for boring work projects. It's a whole way to think about writing programs! I'm really glad I went to Code Retreat and learned how even my small personal projects and learning exercises can benefit from tests.

In my text exploration game project, I'm using HSpec to test my game. Why test? I first learned about test-driven development a couple months ago during Code Retreat in Pittsburgh. I'd never done any TDD before that. But over the course of the day, I found I really enjoyed process of writing small tests and making them pass. Most of the day, I was working with people who were very experienced with testing, but in other languages like Java, Scala, Clojure, or Python. The last session was the only time I worked with another Haskeller, and neither of us new how to test Haskell with anything but types and visually checking output. He was satisfied with that, but I really wanted to to fully learn TDD. That's why I added it to my project.

Adding tests to my code helped me reason through a lot of problems. I realized that a lot of the way that I had structured my program at first didn't make much sense and was really hard to test. For example, putting too much in one IO function. Now I think my code is more modular.

I still have a lot to learn about TDD in Haskell. I have a really hard time keeping to the red -> green -> refactor thing. I tend to either forget about the refactor part or go from refactoring to writing a bunch of new stuff without testing first.