Blog


    Denver Startup Weekend 2013

    This past weekend I attended my first Startup Weekend event, here in Denver. I had never been to a group hacking event before, so I didn’t know what to expect. As it turned out, any apprehension I felt was totally unnecessary. The event had a very inclusive feeling, and people seemed to go out of their way to ensure that others were having a good time.

    On Friday evening, projects and teams were chosen. There were two ideas that I was particularly interested in, but I chose a team led by the founder of Sparkrelief, a disaster relief coordination nonprofit. Over the following two days, our team built Sparktext, a service designed to pair individuals needing relief assistance with local volunteers. A person in need of assistance sends an email or text (via SMS) describing their needs to Sparktext. Volunteers visiting the sparktext.org site can view needs, and contact the person who submitted the need in order to coordinate assistance. It’s not currently live, but there are some screenshots on my projects page.

    Due to the wide variety of skills on our team, we ended up incorporating various technologies in order to get the application working as quickly as possible. The backend was built with Rails::API (using the rails-api gem) and Postgres, while the front end comprised JavaScript and Bootstrap. The SMS integration was handled by a Node.js app using Twilio’s SMS service, which then communicated with the Rails backend. I worked primarily with the Rails bits, but later added some minor features to the front end.

    As much as I enjoyed the actual building of the project, it was the people that really make the weekend enjoyable. The whole process of deciding what to build, how to build it, and then solving the necessary problems to get there is much more fun when you’re doing it with others. Even things that can be frustrating when done alone, like chasing down the cause of an error that persists even after all the usual suspects have been ruled out, are better once there are other people involved. Along the way, you start to learn more about the people you’re working with. Our team was pretty diverse in terms of background, experience, and interests, which made the process of getting to know each other all the more interesting.

    Despite feeling a bit uneasy going into the weekend, it ended up being a great experience. I gained some technical experience, and I had a fantastic time working with my teammates and getting to know them. I’ll certainly be attending future Startup Weekends, and I’m also on the lookout for similar hackathon-type events in the Denver/Boulder area.


    Wed 25 Sep 2013

    Learning how to slow down and think

    When I first started working with Rails, the problems I encountered were often so simple that I could find a solution within a minute or two. Rarely did I need to read more than two or three Stack Overflow questions or blog posts before I would find my answer and be on my way. This is no longer the case, and that’s both good and bad. It’s good because it means that I understand more than I used to, but when I encounter a problem now, I know there’s a good chance that it will take me a while to solve.

    When I was brand new, and I needed to remember how to render a partial for an array of objects, I could simply refer back to the Rails Tutorial or I could do a search for ‘rails 3 render partial’ and click the first link, which would almost always give me the syntax I needed. I became quite accustomed to finding immediate answers to things that were holding my progress up.

    Gradually, this process began to slow down. I started having to do several searches with different terms before finding something that applied directly to my situation. I would skim the questions and threads I found, hoping to quickly detect whether I was on the right track or not. This process continued to devolve, and I began to feel frustrated with how long it took.

    Eventually, I realized that trying to find the answer as quickly as possible was a false economy. I needed to slow down, read links carefully (even if they were only 70 or 80 percent relevant to my issue), and absorb what I was reading. I needed to stop copy-pasting errors into Google, and take the time to understand what the error was trying to tell me. I needed to read the logs, install the Better Errors gem, and approach problems with the goal of understanding them, rather than simply fixing them.

    I still encounter plenty of simple bugs, but I’ve found that the slow and considerate approach is often faster in these cases as well. I’m less likely to overlook smaller clues, and it’s these clues that often lead me to a solution. As a bonus, it’s also a lot less stressful. Rather than clicking through ten links and feeling frustrated that I haven’t made any progress after half an hour, I use that same half hour to go through a handful of links, and develop a much better understanding of both the problem and the pieces of Rails I’m dealing with.

    While the slow approach is counterintuitive and, consequently, took me a little while to get used to, it’s starting to become the default. I feel that both my projects and my skills are progressing faster because of it.


    Thu 12 Sep 2013

    Pricing Software UI Project Update

    It’s been a while since I’ve posted any updates, but a lot has been going on, and unsurprisingly, the more I have to write about, the less time I have to actually do the writing.

    The pricing software UI project (briefly introduced in this post) is moving along. The database schema was stripped down so that just the core functionality remained, but at 25 tables, it’s the largest model layer I’ve worked with in Rails. Although I’m sure I’ll need to add a few things here and there, the model layer is largely complete, and now I’m focused on creating the controllers and views.

    I’ve encountered quite a number of new things along the way, but I plan to address the more important ones in their own posts, and save the more general stuff for these update-style posts.


    Mon 29 Jul 2013

    New Project!

    Earlier this week, I was talking with a friend at work, and the conversation drifted towards a pricing application he had written several years ago. He had sold licenses to a few customers, but he wasn't actively trying to find more. He had been thinking about writing a new web-based UI to replace the aging desktop UI, and trying to find more customers. I offered to take a shot at building a UI, and he agreed.

    This project has a few twists that'll make it a challenge. Currently, it uses PowerBuilder for the UI, Java for the engine, and Microsoft SQL Server for the database. There will be minimal interaction between the front end and the engine, but I’ll need to do some research on deploying Java and Ruby together.

    Today was spend getting familiar with the current application and the data model. First, I set up SQL Server and the UI pieces, and imported a test database. Then, I spent a while putting together a printable database diagram that I can use as a reference.

    I’m really excited to be working on a refresh of a product that has a good sales history. It's going to be an adventure, for sure. I'll keep this updated.


    Sat 15 Jun 2013

    Ruby Koans- Completed (#280/280)

    I'm surprised by how much I think I've learned from the Koans. Even though a lot of the method names essentially tell you what to expect, the act of filling in the missing pieces and running the tests give the concepts a foothold in my memory. Engagement is a huge help to me for both learning and memory.

    I did run into some trouble near the end, though. Once I got to the about_proxy_object_project, I felt like I had hit a wall. I had a general idea of what I needed to do, mostly based on the about_message_passing Koan, but I couldn't quite conceive of how the pieces would all go together. So, I ended up messing around with defining individual proxy functions at first. Even though I knew my approach wasn't the intended one, I was learning a decent amount. Eventually, I was ready to solve it and move on, but I still didn't know to proceed.

    I looked at a few different solutions other people had done, and saw what I wasn't getting. I didn't realize that method_missing could be used for methods missing from the proxy class itself- I thought they had to be missing from the Television class as well. Once I set method_missing up to handle both the Television and super methods directly, everything worked.

    Some of the Koans are fairly simple, isolated concepts that would be good to memorize. For these, I'll probably make flashcards. Other Koans, such as the ones dealing with classes, inheritance, scope, etc, don't lend themselves to memorization. For these, I think I would be better off just practicing them, so I'll wait a while, download a fresh copy of the Koans, and go through them again.


    Sun 26 May 2013