Tuesday, July 01, 2014

What can go wrong at a hackathon, or Jekyll and Mr. Hyde

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
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!

Monday, June 09, 2014

SheHacksATX: a hackathon done right

Hackathons can be a good change of pace for us developers because they force us to experience software development in a different way. At our day jobs we often work on a feature for weeks, because it needs to meet complex requirements that are often subject to many unknowns and last minute changes. But a hackathon can make it possible to implement not just one feature, but an entire prototype, or minimal viable product, in a day. It depends on how the hackathon is run, and just as much on preparation of the teams.

If your team has the right skills, or at least has researched in advance how to implement various moving pieces (for example, OAuth authentication using your chosen programming language), then a hackathon can give you a concentrated dose of accomplishment you often don't get at work. But if you approach a hackathon unprepared, and have to research those technologies as you're trying to use them, you will just spin your wheels. You might waste that day just scratching the surface of technologies you may or may not ever use. (I doubt that most projects started at hackathons ever get worked on again.)

Developers socialize in the morning before the coding starts. Left to right: Kathy, Stephanie, Ruby, Dallas, Nari
Developers socialize in the morning before the coding starts. Left to right: Kathy, Stephanie, Ruby, Dallas, Nari. More pictures from SheHacksATX are in my photo gallery.

At SheHackATX, a women-only hackathon that took place on April 26, 2014, teams had not been formed upfront. Developers were matched with projects at the beginning of the hackathon. Each project was a woman-run startup (most of them local to Austin) that needed programming help, such as to add some features to their app or website. In the morning, developers wrote down their preferences of apps to work on, and the owners picked programmers they wanted on their team. Hopefully everybody got at least their 2nd or 3rd wish.

Since the teams were formed on the spot, they could not coordinate and learn complementary skills in advance. So it was all the more impressive that half of the teams were able to accomplish the tasks that startup founders wanted in the the time provided (from around 12 to 7 pm of one day). Those startups were Girls Guild, Groove, Yoga Recipe, and Bound Round. In my opinion, they were successful because their founders were able to correctly estimate tasks that might take about a day, and went with small'ish, manageable enhancements for their applications; nothing grandiose.

An example of that would be Girls Guild, a website that matches girls who want to learn hands-on skills (e.g. chocolate making, jewelry making, leather working or photography) via apprenticeship, with "makers", i.e. experts in that area. Both the makers and the apprentices are girls or women. One of the features Girls Guild founders wanted to have added to their app had something to do with being able to delay a payment until another event occurs (the details escape me). They also wanted ability for a maker to schedule interviews with a prospective apprentice through the website, as opposed to a manually emailing back-and-forth. The Girls Guild team succeeded in implementing both features.

Girls Guild and Hearth teams at work
Girls Guild and Hearth teams at work. Sitting at the table, left-to-right: Bethany (developer), Diana and Cheyenne (Girls Guild founders). Standing behind them, the Hearth team: Nari and Monisha (developers) and Florence (founder). More pictures from SheHacksATX are in my photo gallery.

Bound Round coders didn't have time to implement a 3D spinning globe (in Javascript, I guess) that the owner wanted, but they implemented a zoomable map that shows different levels of info depending on the level of zoom. Quite impressive for such a short time. Yoga Recipe wanted to integrate their website with Facebook, Twitter, and Instagram; "integration" meant ability for yoga instructors to share the "recipes" (sets of instructions for yoga classes) on social media. They succeeded with Facebook and Twitter. They also implemented ability for yoga teachers to put together playlists for their classes using Spotify.

My team also did well with our application, Groove. More about it in the next blog post, where I'll talk about what we did and how we did it, highlighting the obstacles that a programmer might experience during a hackathon.

Some other startups set their deliverable for this hackathon to be not code, but ideas. The founders of Our Desired Future and Hearth came here with just some ideas for their websites -- some better hashed-out than others -- and asked for technical advice on how to best implement them. Our Desired Future wanted to put together a series of multimedia presentations to tell interactive stories about water usage and water resources of Texas; in case of Hearth, what the owner really needed was to winnow down a number of her eclectic ideas about promoting volunteering through gamification, to something that could serve as minimum viable product. The result of her brainstorming with her team was a landing page for the website. In the process, one of the people on her team concluded that her calling in life was product management. So in these two last cases the product wasn't tangible; the real product was refinement of initial notions into more concrete ideas.

Sunday, March 30, 2014

Michael Bishop "Close Encounters With The Deity": book review

Encounters with mystical, supernatural, or otherwise incomprehensible beings and forces are the topic of Michael Bishop's story collection "Close Encounters With The Deity". Some of those beings are gods, some are aliens, and some are not even creatures, but metaphysical notions. The results are... mixed. These stories might cause you feel a little let down by lack of satisfying endings, but they might also stay with you long after you finished them. They make a good case that a solid ending isn't necessary for a story to have lasting power.

These are not plot-driven stories: in many of them, the main thing that happens is the protagonist's inner transformation. An exception is the story about people who are forced to watch movies, which has a lively plot. Sometimes an inner transformation is accompanied by an outer one, like the story Dogs' Lives. The incomprehensible, mystifying being in it is the protagonist itself, or rather who/what he becomes in the course of his life. His life is shown through his memories of various dogs he shared it with; so in other words, it's about dogs' encounters with a (semi-)deity. Perhaps they were a thread connecting him to the humanity as he became transhuman.

But most commonly the characters do nothing but talk (or merely think) about inexplicable things that are happening to them. Yes, they feel profoundly affected, but they don't take any action. In fact, many times they let themselves be lead "off a cliff" by mysterious forces, at which point the story falls off the cliff as well. The protagonist does not understand, let alone accomplish, anything. Such are the stories Alien Graffiti, and A Spy in The Domain Of Arnheim. In the latter, a guy wakes up in a 19th century hotel room without knowing who he is, and starts taking orders from a voice coming from a gramophone. In some other stories, like Voices, the protagonist's adventure culminates in an encounter with a deity, but hardly anything changes for the protagonist. Well, he may become a tiny bit different inside. Maybe he wanted to meet a deity, and he got it. But what of it? No epiphany follows.

Yet even those stories are interesting in a way, because the characters are interesting people, and their adventures, though disappointing the end, can be intriguing while they last. Nevertheless, both I and the other person who attended the book club where we discussed this book (yes, this was a sparsely-attended meeting) thought the most enjoyable stories were those that delivered a payoff at the end. The examples are:

-- the puzzlingly titled Storming The Bijou, Mon Amour: a story about people who are forced to spend their own lives watching movies. If they dare not pay attention, their souls are erased when law enforcers take a picture of them. The protagonist sets out to investigate what or who is behind the movie projector.

-- A Gift From The Graylanders: a story revolving around childhood nightmares and a threat of nuclear annihilation. As a side note, nuclear annihilation or its possibility is a common thread in this whole collection. That's not surprising, considering the era they it was written in.

-- And The Marlin Spoke. The last one contains both a personal transformation AND a plot. The plot does not tell us what exactly happened, but the suspense in it is resolved so nicely, and the protagonist's quest is achieved in such a fulfilling way that I didn't feel let down.

The last story in the book, "The Gospel According to Gamaliel Crucis", deserves a separate mention -- we spent more time discussing it than any other story. It was singled out in the foreword as a kind of tale that might seem risky for an editor to publish, as it might alienate the audience; but that nevertheless needs to be published, because religion shouldn't be beyond criticism or examination. This novella mimics the Bible in its format, down to numbering of the verses; only the savior this time is an insectoid, female alien named Mantikhoras. She acquires four disciples, and they go about spreading her religious teachings much like Jesus and his apostles.

But... like many stories in this book, it leaves you wondering both what was the point of this particular messiah's coming, and of writing a "remake" of the Bible. It wasn't written for the shock value, because it's told in a sympathetic, non-parodying way. Nor does it say, here is how things would be different if a messiah were an insectoid and the event was set in modern times; nor does it make a compelling case that things would always play out the same. Basically, this story does not try to make any point. I'd say that if you are offering your take on a universally known story, you kind of need a point.

On the other hand, most of these stories are best enjoyed if you don't expect them to have a point. (Love's Heresy may be the only one with a clear message, and the only one that takes a clear stance on religious matters.) Mostly they just show humanity's wish for divine revelations as if in a warped mirror; humans assume that supernatural forces have certain agendas, perhaps to teach a moral lesson, to enact what their holy books say they should enact, but inevitably those forces act in ways that are often cruel, pointless, and incomprehensible to us -- perhaps because there is no secret meaning to comprehend.

I would recommend this collection to a reader who does not expect a plot, but enjoys a different, puzzlingly skewed view of religious and supernatural matters. The stories are highly atmospheric, and the characters really come to life. An example of that is Bob Dylan in The Bob Dylan Tambourine Software story. The image of Bob Dylan that comes through in this story is much like an image of Bob Dylan one can glimpse from his song lyrics (I never heard him speak, so I don't know if there is any correlation with the real person). In this imaginary, alternate-universe interview he explains his motivation for quitting music and instead writing software to facilitate people's religious experiences.

So: peculiar mood, bizarrely imagined situations, well-drawn characters, a view of religion that does not judge or take sides, but calmly observes how weird people's religious leanings can be, to what counterintuitive places they may lead -- all of those are reasons to read this book.

Friday, February 28, 2014

"Computer Chess" movie: come for the 80s tech nostalgia, stay for the weirdness

The movie "Computer Chess" passed largely unnoticed in the big theaters (it didn't even play in Austin), but I greatly enjoyed this mockumentary about a computer chess tournament in the early 1980s. At first I didn't think that it would have much value beyond nostalgic or historical. A nostalgia trip for those who were computer nerds in the eighties, I thought it might be educational for someone like me, who never saw a PC up close until the early 90s. It must have been harder to be passionate about computing in the days when computers didn't fit in your pocket; the really devoted computer scientists, such as the ones portrayed in this movie, put their machines on dollies and wheeled them from room to room when they wanted to play them against one another.

But what drew me in for historical value made me stay for the character study.

At first, the players seem pretty ordinary college students as they get together in a hotel room in the evening and "debate" big questions, such as plausibility of artificial intelligence, or the nature of consciousness, with all the banality of a young person discovering those questions for the first time and not yet having done their intellectual homework. But as the tournament progresses and their programs start to go astray, their personalities blossom into bouquets of quirks.

The movie juxtaposes the players with an "officially" weird group of people: the attendees of a wacky couples retreat that goes on in the hotel the same weekend. Barking at each other like dogs is just one of the ways the New Age'y couples attain some kind of transcendence and deepen their connection. Ostensibly, the computer chess tournament and the retreat could not be more different, but soon they become more similar than one could guess. As it turns out, smart people who are deeply absorbed in, even obsessed with their work, quickly veer into outlandish beliefs. A tired, overwhelmed, razor-focused-on-one-thing human mind is unwilling to accept natural explanations when things don't go the way it wants. The movie does not ridicule anyone: human weirdnesses are portrayed in a loving, non-judgmental manner. It merely observes as the two polar opposites -- computer geniuses and New Age'y quacks -- move closer together. It's fitting that the final match between a human chess master and the computer takes place side-by-side with the woo-woo practice in an accidentally double-booked conference room.

Speaking of conference rooms: this movie has a feel of the lowest-budget-movie-ever. It takes place entirely in a nondescript Ramada Inn. Who would have thought that you could shoot a movie in Austin, and not even have Austin cityscape anywhere in the backdrop? On behalf of my adopted city I might be a little offended. :-)

Friday, November 29, 2013

SXSW 2013: blending bendy materials and bendy life

A talk by Ping Fu at SXSW 2013 blended, in an odd way, self-help advice and 3D-printing technology. The only thing in common between the two may be her own personality, which, like those raw materials shaped into an infinite collection of shapes, succeeded by flexibility and adaptability.

Ping Fu at her SXSW 2013 speech 'Digital Reality: Life in Two Worlds'.

The title of her speech, "Digital Reality: Life in Two Worlds" ostensibly refers to the merge of physical and digital reality. She reviewed exciting things happening in three-dimensional scanning and printing technologies -- and her company, Geomagic, is among the players in the field. Standing on the stage in 3D-printed platform wedge shoes, she said you may be able to walk into a Nike store tomorrow, have their feet scanned, and pick up custom-made shoes tomorrow. You may also have custom-made prosthetics that would let artificial limbs look like real ones, "because currently they look like airplane landing gear". You just have to scan a soccer player's "good" leg, and print an artificial one based on that model. 3D-printing can produce filling for dental cavities, and repair tiles on NASA space shuttle -- two technologies that surprisingly (or not), are related. Preservation of historical artifacts is also a big application for 3D-scanning. Mount Rushmore took a hell of a long time to scan, but it was eventually done, and US Parks and Wildlife has a scan, said Ping Fu.

Ping Fu's 3D-printed shoes she wore at her SXSW 2013 speech 'Digital Reality: Life in Two Worlds'.
Ping Fu's 3D-printed shoes she wore at her SXSW 2013 speech 'Digital Reality: Life in Two Worlds'. More pictures from this speech and overall SXSW 2013 are in my photo gallery.

On the other hand, life in two worlds can be a metaphor for Ping Fu's own life, that has certainly spanned two vastly different worlds. As a young child she was taken from her loving family in Shanghai during the Cultural Revolution, and raised in a camp. She was put through communist brainwashing, being forced to go up on stage and scream "I am nobody!" So she has no stage fright, she jokes. If anything saved her, it was her father's advice to be like a bamboo, that bends but does not break in the wind. She even made it the title of her book, "Bend, not Break".

A soccer player's 3D-printed prostethic leg: a slide from Ping Fu SXSW 2013 speech 'Digital Reality: Life in Two Worlds'.
A soccer player's 3D-printed prostethic leg. More pictures from this speech and overall SXSW 2013 are in my photo gallery.

Looking up this book on amazon.com, I saw that many reviewers accuse her of fabricating her life story. They claim her actual life was not nearly as horrible as described in the book, and that she might not have lived in a labor camp. I have no way to verify the claims of either side, though there is no doubt that the horrors of Chinese labor camps, where middle class children were sent for "re-education", actually existed. There is also no doubt that Ping Fu at some point immigrated into the US, and went from a person who knew just 3 English words, to a tech entrepreneur. And though she chose a technical field, she credits her love of language for her design skills. She may have known little of English, but she had a love of language all her life.

In China, she went to graduate school for journalism around the time when China's one-child policy started. It made not just subsequent-child births, but also pregnancies, illegal. When Ping Fu heard rumors that baby girls were being killed in the countryside, she went there as a journalist to investigate. There she witnessed "abortions" done via C-section in 8th or 9th month of pregnancy. For writing publicly about these atrocities she was put in jail, and was certain she would die there. Luckily, Cultural Revolution soon ended -- this was a few years before the Tiananmen Square -- and Ping Fu was released. (Again, I have no way of verifying how much of it is true.) Then the government gave her a choice: quietly leave the country, or be exiled to a remote corner of China. She chose to go to America, and took a crash course in English on the plane. By the time she landed in San Francisco, en route to the University of New Mexico, she already knew a few English words. Not enough to be accepted into comparative literature program, which was her first choice, but enough for computer science.

Mobile 3D-printer demonstrated during Ping Fu SXSW 2013 speech 'Digital Reality: Life in Two Worlds'.
Mobile 3D-printer. This guy and another one with a similar printer walked up and down the aisles to let the audience take a look at the printers. They, however, did not demonstrate how it works. More pictures from this speech and overall SXSW 2013 are in my photo gallery.

Myself, as someone who had a love for languages all my life, but didn't go into linguistics because I didn't think there were any jobs in it beyond school teacher, felt vindicated. There are not many people (or perhaps we're just not visible) who come into computer science not because of fascination with technology, but because we enjoy teasing out complex logical structures from the code as we do from human languages. And so when Ping Fu said that somebody back in the day suggested to her that she check out this new field, computer science, because it's a "language" that lets you make stuff, I thought that it was the same kind of thing that attracted me to the field of computing. Her life tale of a foreign student turned tech entrepreneur also has a special resonance to me because I, too, initially came to the US to go to graduate school. She, however, did not think she was a good programmer, because she lacked a science background, so she became a designer and project manager. Her secret to working with programmers is to ply them with Coke to keep their juices flowing. It must have worked, because at some point she hired Marc Andreesen, who developed Mosaic, and eventually licensed it to Microsoft to become Internet Explorer.

For a long time she didn't consider becoming entrepreneur, and when she finally started her company, Geomagic, people were still skeptical. Of the first seven employees all but her had PhDs, and 4 of them were mathematicians. People said you can't start a company with a bunch of mathematicians, as math doesn't make money. But Ping Fu replied that she liked to do impossible things, so she did it. A win for language nerds and foreign students everywhere!

Thursday, October 10, 2013

Some hackathons result in demos, some in questions

After finding out that the Devstack server we created during the walkthrough is not suitable for hosting web applications, I created a "plain" Rackspace server, installed Apache on it, and we proceeded to create a barebones web application. One of my goals was to get a clear idea how much progress a group of people could make on an application in a hackathon. The answer is, since we only got started after lunch (the first half of the day was taken up by the Devstack tutorial), and had until 4 pm to go: not much. But we got a little done.

Rackspace's Dana Bauer, Developer and Community Advocate at Rackspace
Dana Bauer, Developer and Community Advocate at Rackspace, one of the organizers of the hackathon. She and another Rackspace employee helped us greatly with the registration glitches. At the end she encouraged people to give demos, or, lacking a demo, to stand up and speak about what they did, accomplished, or learned during the hackathon. Though Dana gave people Legos for speaking, very few people (including two from our team) came up to speak. Only one person (Kesten, see below) gave a demo. More pictures from the 2013 OpenStack Hackathon are in my photo gallery.

I am no front-end developer, but nobody else in our team clamored for that role. In a strange coincidence, the other 4 women on our team came either from PyLadies (Python was their language of choice) or from scientific computing background, or the intersection of both. So I assigned the front-end developer role to myself, fully realizing that a web-page hand-coded by me would look rather... homemade. I needed some HTML and CSS templates that would make my creation look at least somewhat professional. Specifically, I needed a web form. I spent a good couple of hours looking for HTML/CSS templates for forms, and most sites were misleading: either they promised free templates, but every template you picked required you to sign up for a fee; some websites promised form templates, but instead of providing the HTML/CSS code they let you create and host a form in their domain, which wasn't what I wanted. After a long search I was able to find a form where I could tease out its HTML/CSS code. Interestingly, throughout my numerous Google searches, Bootstrap didn't show up even once. But when I mentioned my predicament to the people at the hackathon and on Facebook, two of them recommended Bootstrap. Indeed, Bootstrap has form templates. Face-to-face interaction can still be more useful than Google.

Kesten Broughton gives a demo of Picycles
The one and only product demo at the hackathon was given by Kesten Broughton, who created a 2D altitude chart as an addon for Google Maps "get directions" service using the Python beta API. His program was called Picycle, and was intended as a service for bicyclists who want to choose an optimal route, either minimizing or maximizing (if they want a good workout) the hills along the route. More pictures from the 2013 OpenStack Hackathon are in my photo gallery.

It took me 3 hours to put together a basic -- extremely basic -- front end to our application. There was no even a question of hooking it up to the backend. There was no time to write even a primitive web service that the front-end could call and display some results. One person in our group, more experienced with Python, finally got Twitter authentication to work in Python. This allowed her to query Twitter API programmatically by making requests from her Python code. Other of our members were just starting out with programming in general (in some cases switching from other professions), so I don't know what they did during that time. Perhaps they were going through Codecademy courses.

To our credit, other teams did not seem to fare better. Only one of the hackathon attendees had even a minimal product at the end to give a demo of, and he admitted he had been working on that product for 2 weeks already. His name was Kesten Broughton, and he created a 2D altitude chart as an addon for Google Maps "get directions" service using the Python beta API. His program was called picycle, and was intended as a service for bicyclists who want to choose an optimal route, either minimizing or maximizing (if they want a good workout) the hills along the route.

The lesson to be learned here is that to participate meaningfully in a hackathon requires quite a bit of preparation. If All Girl Hack Night is going to have a hackathon (I've been threatening to organize one, but always felt woefully unprepared), we would need to prepare in advance. For example, some us will have to be team leads who will have studied the API's of our choice (the APIs will also have to be decided ahead of time), and will be able to guide the teams so they could make tangible progress. That's the main lesson. Lots of advance decisions, planning what to implement, what programming languages and APIs to use, and a critical number of people who are familiar with those technologies and can guide others.

Thursday, September 26, 2013

Build Something Awesome… but what?

"Build Something Awesome with OpenStack and the Open Cloud" hackathon could have lived up to its name, if only someone knew what kindof awesome things one could build with OpenStack. Or could explain it to developers. But I'm getting ahead of myself.

Maddy (left), our unofficial team lead and Python expert, and Anna
Maddy (left), our unofficial team lead and Python expert, and Anna. More pictures from the 2013 OpenStack Hackathon are in my photo gallery.

The September 14th, 2013 OpenStack hackathon was the first hackathon I ever attended. It was organized and sponsored by Rackspace, creator of the OpenStack project. I didn't know much about it, so I assumed that it was just yet another API that lets you build applications. The hackathon event page did not hint at what kinds of applications you could build with it. So I was surprised when it turned out that for the kind of application my team wanted to build, OpenStack kind of… got in the way.

The hackathon started with a 2-hour presentation by Rackspace’s developer advocate. He guided us through a tutorial on how to create a DevStack server on Rackspace. DevStack, by the way, he said, is not the same as OpenStack, but the distinction was lost on me. This was by far not the most subtle point that was lost on me.

Left to right: Paige, Jess, Maddy (our unofficial team lead and Python expert), and Christine
Left to right: Paige, Jess, Maddy (our unofficial team lead and Python expert), and Christine. More pictures from the 2013 OpenStack Hackathon are in my photo gallery.

After the presentation our team of five, all female developers, rolled up our sleeves to start building the application proposed by one of our members. I investigated the server created during the walkthrough, looking for the directory where Apache keeps HTML files and web scripts. That's where I thought I would place a web application (at the beginning, just a Python script) that we were writing. I saw there was an index.html in the /var/www directory, but its contents were not the one that were displayed when you pointed your browser to this server's root URL. So I went to the presenter and asked why that was. He said, better don't try to use Apache on that devstack server; it's configured in a special way, and if you want to run an ordinary Apache web server, you'd be fighting it all the way. You should create a basic Linux server on Rackspace, not a Devstack server, and install Apache on it. I tried asking him what could we do with this Devstack server, if not write web applications. He said it was mostly for learning. Learning OpenStack. Well, that still didn't answer my question what I could do with OpenStack, but oh well, maybe I should have found out beforehand? It's not like it was any secret that this hackathon was for building things with OpenStack: it was in the name of the hackathon. But I wasn't the only person who went there with assumptions that I could build web applications with it.

Other lessons from this hackathon were more interesting, and came from my attempt to find out what can be accomplished during a hackathon. More about it in the next blog post.