The application I worked on at SheHacksATX was called Groove. It is a fertility tracking app that's primarily mobile, but its owner Jennifer wanted a few features to be added to the Groove website. One of the features was an image with clickable parts, each of which produced a different text explanation; another was a rotating image slider with captions for each slide, that would pause when a mouse hovers over it, and resume when the mouse is moved off of it. I took the task of creating the slider, and the other developer in our team took the image. Of course, I didn't create the slider completely on my own: similar Javascript widgets already exist out there on the web. I found one on Github, and adapted it to our application's needs. But even that wasn't trivial. I had to find ways to customize the layout of the captions, and to implement the pause-on-mouseover / resume-on-mouseout functionality. It may sound like a piece of cake to you front-end gurus, but I'm a backend developer after all. I have to spend precious minutes or hours brushing the rust off of such bits of knowledge like how do I make two <div> tags to appear side-by-side, or to climb out of the rabbit hole of nested callbacks in asynchronous function calls.
But programming challenges wasn't what posed a threat to our team's chance of accomplishing our tasks. It was development environment incompatibilities. It turned out that certain technologies are difficult to get working on Windows. I'm looking at you, Jekyll. Jekyll, a website generator, lets you write HTML pages using a certain system of shorthand tags, as opposed to actual HTML tags; Jekyll runs on the server, parses those template files and turns them into HTML.
Well, it turns out that Jekyll on Windows is more like Mr. Hyde. Trying to run it I got an uninformative error, and a cursory Google search made me think that perhaps I need to run it on a higher version of Ruby than the one on my laptop. (Jekyll is written in Ruby.) Jennifer was running Jekyll on her machine with Ruby 2.0, whereas I had Ruby 1.9. So I decided to see if upgrading Ruby fixes the problem. Except there turned out to be no quick way to upgrade Ruby on a Windows machine. On a UNIX-based operating system you would do it with various package managers; on Windows, Google suggested to use this package manager or that, some of which were reported to work on Windows with a few tweaks; just trying to install those package managers caused a cascade of incomprehensible errors. I could see that if I continued down this route, I would spend all day just trying to upgrade Ruby on Windows.
I consulted with Jennifer (Groove founder), and the other developer, and we decided that I won't try to run Jekyll. Indeed, all that Jekyll did in this application was to insert some common HTML sections into HTML pages. I could simply insert those sections myself. So I did. I made a copy of the original file for myself, and replaced Jekyll tags with HTML that was generated from them.
The Groove team at work: Jennifer (left), the founder of the Groove app, and the other developer in our team. More pictures from SheHacksATX are in my photo gallery.
At the end of the day we, the two developers, finished our parts. There came the moment of truth when we each had to push our code to the Groove Github repository. I copy-and-pasted my code changes into the original page (the one with Jekyll tags), and pushed it to Github. My push triggered a build, which Jennifer had set up on Github to run automatically when new code is committed. That's when Mr. Hyde struck again. It said the build failed because the file I committed wasn't in the right encoding. It was already 6 pm in the evening, only 1-1.5 hours until the demos where all the hackathon teams were supposed to demonstrate what they had accomplished, and way too late to figure out why it was complaining about encoding. (I suspected that it was the Windows-style line endings in my file, while Jekyll might have expected Unix-style line endings, but I really don't know.) What to do?
So I committed my code "by proxy", i.e. via the other developer's laptop. She had a Mac, a Unix-based system, and I was pretty sure that a file committed by her would not be corrupted. I emailed her my files, she copied-and-pasted the changes into her file, and pushed it to Github. That's cutting a long story short. The long version of this story involves dancing the Github "dance" two people have to do when the other person's Git branch has fallen one or more commits behind the Github repository. It was also complicated by the fact that the other developer had made her own code changes to the same files. But after just an hour of copy-pasting and white-knuckled Githubbing, we fixed the build, and successfully pushed our changes to the repository. The day was saved, just in time to the pre-demo sushi and cheese snacks.
I have been primarily a Windows developer for a long time, and never understood why someone would need a Mac, except people who find Windows computers too difficult to use -- but surely that's not the case with developers. But this hackathon made me seriously consider that if I want to program outside of Windows stack, I need a Unix-based system. Ruby and Jekyll were just two examples; my earlier failure of getting Python to interoperate with Heroku toolbelt on Windows was another. Yes, I know, I can run UNIX on a virtual machine, but my Windows computer is already too slow even with what few programs I'm running on it. It's food for thought for the future.
But yes. This last part yet again highlights the importance of preparing for a hackathon -- at least setting up development environment for your project ahead of time, and testing it. But that's not possible not knowing what project you'll be working on. Perhaps it would be better if team / project assignments were determined at least a day or two before the hackathon, although that's not practical for every hackathon. I don't know of a good solution that would both preserve spontaneity, and allow people to prepare. Myself, I would err on the side of preparedness, because your day as a developer could be otherwise completely ruined if you waste it to find workarounds for configuration problems instead of coding.
It's a good thing that my years of programming experience enabled me to find those workarounds. Which brings me to my final observation. It's been observed time and time again, and this hackathon was no exception, that many women developers underestimate their skills. Some women who have been programming in the industry for 2+ years had wanted to sign up as beginners (the hackathon had separate pools of beginner coder and experienced coder tickets, so that every team could have a balance of both), but signed up as experienced because the newbie ticket pool drained faster. And that turned out to be the appropriate designation for them. At the end Girls Guild founder Diana remarked: many of you ladies signed up as newbies, but you are not new!
Posts
