That Puerto Rican Rubyist

I’ve been studying Japanese for quite some time now. The Japanese language, as you might expect, is pretty deep. Besides all the gairaigo (borrowed words from English and other languages), just about everything is different, from the grammar to the writing. As such, there are a ton of websites I go to just about every day to study different aspects of the language.

One of my current favorites is WaniKani, a web app that helps learning Japanese Kanji and vocabulary using spaced repetition. I’ve been using WaniKani for a handful of months, but it has already helped me in different aspects of the language, especially when I was in Japan on vacation a few months ago.

Recently, they released an API for accessing their content. I got a few ideas on some small projects to do, particularly with a spare Raspberry Pi I have (more on that some other time). Since I’m a Ruby developer, I thought this would be a perfect time to finally create my first publicly accessible RubyGem.

With that came the birth of the wanikani gem. It’s a small gem to make it easy to call WaniKani’s API functions in any Ruby project. I have a few private RubyGems in some of my work projects, but those have never seen the light of day as a public repo, so I wanted to share the love somehow. It also serves as a learning experience. Hopefully someone finds the project useful and helps out with pull requests or critiques so I can continue learning. I’ll definitely try to do more and share some more open-source to help others as many people have helped me with their projects.

The current laptop I use for work is a Macbook Pro I bought back in 2009. To be honest, I bought this laptop because I was insanely jealous of TextMate. Also, this was a period when it seemed all the cool Rubyists were developing on the Mac, and I sort of felt like I had to keep up with everyone else. But I haven’t regretted my purchase at all. I’ve never had a single problem with this laptop in the 3+ years I’ve owned it. As its age has been showing, I’ve tried to keep it running as smoothly as possible with a myriad of upgrades, from an SSD drive to adding the maximum of 8 GB of RAM, and even an additional hard drive with the excellent OptiBay drive kit. However, there’s just so much that I can do, and I think I’ve maxed out all the power I can out of this laptop.

I’ve been thinking for a while about getting a new Macbook Pro, and with last week’s announcement of a new lineup, including the sexy Macbook Pro with Retina display, I’ve been dangerously close to heading to the nearest Apple Store (and thanks to living in the Bay Area, I have about a billion stores in less than a 30-minute drive in any direction) and just blindly giving my credit card to whoever has a blue shirt. However, a recent purchase I made about a month ago has made me reconsider this option.

For a while now, I had the urge to tinker with Linux as a desktop again and had been looking for a low-cost way to do so. Fry’s Electronics had a sale on a cheap laptop last month – an Acer Aspire laptop for about $270 plus tax, so I decided to spring for it. As evidenced by the price, it’s a current low-end system (Dual-Core Pentium B940, 4 GB of RAM, slow 500 GB hard drive). For the time being, I also purchased 8 gigs of memory for $30, so it turned out to be a cheap investment in technology.

The last time I tinkered with Linux as a desktop system was when Ubuntu unveiled its Unity interface, and I didn’t have a good experience with it back then, particularly since I was testing it on an underpowered PC. Since the laptop I purchased was a low-end one, I decided to skip Ubuntu entirely and try something different. I almost decided on Linux Mint, since it’s already based on Ubuntu and Debian, which is what I was most comfortable with. But lately, I had been hearing quite a bit of fanfare about Arch Linux.

Arch Linux is touted as being one of the more flexible Linux distros out there. The secret of its flexibility is due to keeping everything very simple – installation only includes a minimal working system (essentially just the shell), giving you the choice to install whatever you’d like. The caveat is that this distribution is not for beginners. You’re expected to know a bit about Linux and the command line, and especially not be afraid of tinkering around with files in the /etc directory. Having very fond memories of playing around with Slackware back in my college days, I thought it would be fun to try it out.

After installing Arch Linux to my laptop, I was greeted with a command line prompt and not much else. I had no idea what to do next. Thankfully, there’s a rather large and active community for Arch Linux, and the wiki is full of useful information, especially for newbies to the Arch Linux world, like myself. After getting familiar with Pacman, the Arch Linux package manager, I was well on my way to getting my desktop environment installed. While I did stumble a bit along the way, especially with my wireless connection (which has always been one of the main issues with most Linux distributions anyway), I was able to get a shiny new Gnome 3.4 desktop set up. With very little tweaking all my hardware seemed to be up and running. I think it was a relatively smooth process to what I expected, since I read a lot of warnings about needing to spend some time tinkering around to get things right.

It’s been a few weeks since I’ve been using Linux as my after-work hacking environment. While it takes some time getting used to the new desktop environment, and I’m sort of missing some of the polish and small things from Mac OS X that I apparently take for granted, I’m liking the Linux setup a lot for my development work. Since I do mostly Ruby and Javascript work, this system handles it all perfectly. I honestly don’t think that I would miss the Mac development environment much if I had a full-time Linux machine. That’s what I think I’m going to do for my next laptop. Instead of spending at least $1500 on a Mac with decent specs, I’m sure I’d be able to get a high-end work laptop for about $1000, install Linux on it, and be perfectly happy with it. It’s good to be back where I was so many years ago.

I’ve been living in the Bay Area for two years now. One of the main reasons why I wanted to move over here is the large population of tech people that exist in this area. From Computer Science students in U.C. Berkeley, to developers in San Francisco who are working on the latest website / app that everyone will be using a year from now, to the super-smart engineers who work on some of the world’s largest companies in Silicon Valley, there’s a lot of people who are just like me.

Of course, it’s pretty cool to be able to meet people who are like-minded and enthusiastic (sometimes too enthusiastic, but that’s another story for another day), with a broad range of tech interests. It’s fun to hear what others do for a living, and most tech people just love to tell you all about what they’re working on. I have learned so much in my two years living in California than I had for the rest of my 29 years living elsewhere, which is pretty awesome.

However, something became apparent to me in my first few months living here – I really didn’t want to hang out with tech people all the time. Not that most of people I met were dull or socially awkward (usually, I always think that’s what people think about me when they meet me). But I’m the type of person who enjoys the company of people who think very differently than I do. It sort of gives me a chance to study others, if you will, and get a better sense of perspective in my life. Because of this, it had been quite a while since I hung out with others and talk tech, outside of work.

That brings me to a couple of weeks ago. A co-worker – who’s not a developer – told me that a few of his programmer buddies were getting together for a weekend of hacking up something in hopes of being able to get a working website or app out there in 48 hours. Although I’ve been in California for so long, I had never gotten together with anyone just to build something for fun. I wasn’t going to do anything that specific weekend, so I agreed. It was an interesting and really fun weekend, but since it was everyone’s first hackathon, there were a few things that we could have done better, which I wanted to write about.

Have an idea before the weekend

I was informed of the hackathon on the Sunday before we were going to build the app. The guys who were planning to participate had been shuffling emails back and forth with app ideas so we could decide on one to work on. By Friday evening, we had a list of a lot of solid ideas. So we decided to get together and pick one that was feasible to build in two days. We spent more than two hours on Friday night going through the ideas and by the end of it, we still had no idea. So on Saturday morning we went into the hackathon without knowing what to do.

I think this set us back at least 3-4 hours of real work that day. If we had picked an idea and decided to work on it before hand, we could have done a bit of work beforehand to get some stuff up and running, like setting up the services we were going to use and make sure everyone’s development environment was set up for whatever we were going to build (which surprisingly, for a few, it wasn’t).

Clearly define what needs to be done, who will do it, and make it visible

Because we had no idea what we were going to build going into the weekend, we didn’t really know what the scope of the project was going to be like. Our plan was to have a minimum viable product ready to go on Sunday evening. However, we only were able to define what would be the minimum amount of work on Saturday afternoon, so it was just a lot of broad strokes and nothing clearly defined. Everyone chose what they were most comfortable working on, or what they wanted to work on, and we took off.

The problem with this was that at any given point, I had no idea where everyone was at with their work, and that made it difficult to know what I should have been focusing on next. For example, I had been tasked with building classes on the back-end to connect to different APIs and pass that data on to the front-end. By the time I was done, I didn’t know if the front-end was ready to go or not. So I had to basically interrupt everyone and ask what they were doing and how far along they were, and also ask what needed to be done next. Had we defined our tasks earlier and more clearly, and people were good with updating the status of these tasks regularly, I think we could have wasted less time and done more.

Bring more variety to the team

At the end of Saturday night, I quickly realized what was going to be the part that held us back – the user interface. In our group, all of us were solid developers, but no one had any decent design chops. So that left us with one of the guys hacking together an interface that, in all honesty, didn’t look good at all. A lot of the back-end stuff that we planned to have was more or less wrapped up on Sunday, but the design was sorely lacking a ton of polish, meaning that we couldn’t release our app.

I thought that at least one person in the team would be able to slice and dice any layout into usable designs for development, but we didn’t have one. Next time, I’ll try to get a designer on board for this task only. And if not, there’s always places like Theme Forest where we could get up and running rather quickly with a template, which we thought about too late.

Have people who can be there

One thing that really killed us was the fact that out of seven people who had agreed to be part of the weekend hackathon, five showed up on Saturday morning. And on Sunday, one of the five had to bail, leaving us at four people – one of them being my non-developer co-worker who couldn’t really do much outside of doing wireframes and helping with project management. And to top it off, everyone called it an early night both days because of prior engagements. All of this set us back quite a bit, for obvious reasons. I think we could have finished our app in a usable state had we been at full strength for both days, and we had hacked until the wee hours of the morning, which is what I expected. I mean, come on – it’s a hackathon! I was fully expecting to barely sleep during those 48 hours, but it wasn’t to be.

Despite some things not going as smoothly as planned, and that we technically ‘failed’ reaching our goal, which was to release a working app by the time Sunday wrapped up, I personally considered it a success. Not only was I able to meet new people and expand my network (one of my goals in 2012), I also came out of that weekend reinvigorated, and with a very strong desire to spend more time developing and learning code in my spare time again. Since I had somewhat tired on tech and started filling my time with other non-technical interests, as I wrote a few months ago, I really hadn’t been doing any coding or learning more about the new hotness in my spare time. After the weekend hackathon, I’ve been wanting to code all night long after getting out of work. I even started planning another hackathon for another app I want to build, too.

It’s amazing how taking something you do on a daily basis and doing it in a different setting can reignite your passion once again.

For the past ten years or so, even before I graduated from college, a large chunk of my spare time has been dedicated to studying. More specifically, it’s been dedicated to studying technology. Everything from programming languages I’ve wanted to use to new frameworks that look shiny and new to electronics and Arduinos and everything in between. I’ve spent lots of time and money reading up on anything tech. It’s really my passion. That’s why I got into Computer Science to begin with. I love this.

But after all those years, I’ve been getting burned out doing this. There’s just a lot of little things that lead to me feeling this way. The biggest reason, however, is the following: I’ve read and studied about a lot of cool things that I never got to do at my current day job, making it impossible to retain anything long-term and making me eventually lose interest. This would then spiral into me feeling guilty on spending so much time on something and not use it. To compensate, I would jump to some other tech-related book or project that excited me, only to have the same thing happen again. It was a vicious cycle that I hated and was desperate to get out of. But I didn’t want to dump tech at all. I love this stuff.

Finally, I decided to just hold back on all the new learning. I stopped buying books and trying to jump on the bandwagon of the latest hotness out on the streets. But that made me even more miserable. I felt like I was getting left behind. Like a drug junkie, I yearned to get my fix, even though I knew it was slowly killing me inside. So I had to focus on something else, far away from the things I’ve been doing for the past ten years. And oddly enough, shifting my focus away from tech was just what I needed to get my focus back on tech.

First off, I finally decided to go to a gym. Before last year, I had never stepped into a gym before in my life. Outside of walking around town or visiting a new park from time to time, I never really made an attempt to make physical activity a part of my routine. So at age 29, my electronic scale at home read 298.8 pounds, and a recent blood test showed my cholesterol levels a bit on the high side. I knew I had to do something. Since my current office is located right next door, literally, to a gym, I signed up and started going.

Going to the gym and exercising regularly has been by far the best decision I’ve ever made in my life. Outside of weight loss and other physiological benefits, I never really believed the mental benefits of exercising, but they’re very, very true. I feel much more alert during the day, up to the point where I don’t need a caffeine boost during the day. I also got much better at retaining new things I’ve learned. Work seems to come out effortlessly, and I think the quality of my code has gone noticeably up in the last couple of months, since I’ve been g