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.

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.

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.

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 going to the gym more often. Finally, I’ve noticed myself in a much better mood every single day, with rarely any “bad hair days”, as I used to have periodically. Seeing the benefits of the hard work put at the gym helps with that a lot: Yesterday I weighed myself using the same scale that mockingly showed 298.8 over a year ago, and now it ready ’258.8′. Suck it, electronic scale.

Besides the gym, I wanted something else to focus on, but nothing related to technology. So I decided to take up learning a new language – a natural language, in particular, Japanese. I’m already fluent in English and Spanish, so I wanted to take something that was totally different, something not a Germanic or Romance language. I thought that Japanese was one of the most difficult languages outside of those groups, so I signed up for a class to feel challenged by something new. I’m about to finish my introductory class next week, and I loved it so much that I’m planning to stay at the language school for at least a full year, and then I’ll be taking a few weeks to actually visit Japan.

The thing is, since I’ve been spending a noticeable chunk of time with the gym and learning Japanese, I’ve noticed a surprising side-effect – I’ve been doing much better in the tech department. Taking time to study Japanese clears my mind and really energizes me, so when I go back to coding I put in a much better effort than I did before. And the physical and mental energy boost that the gym has given me helps me be able to learn and retain more than I ever did. It’s an awesome feeling, and I’m loving studying all over again.

As developers and engineers, our passion leads us to spend too much time on technology, but in the long haul that’s not sustainable. I’ve heard the phrase “sometimes we need to step back to be able to move forward” many, many times before. It’s totally true. Believe it.

There were multiple tracks in this conference, and unfortunately I still can’t clone myself in this day and age, so I’ll just briefly touch on those sessions that I was able to attend.

Monitoring & Queuing MongoDB: This talk, given by David Mytton from Server Density touched on some of the integrated monitoring tools and commands that MongoDB has baked in. He also showed a bit of Server Density’s MongoDB monitoring system, which looks to be incredibly useful. Overall, the talk was decent, but anyone who has MongoDB running in production should know most of this stuff already.

Evolving from relational to document store: Graham Tackley, lead for the web development team over at the U.K.’s Guardian news site, gave an interesting talk on how the site has evolved over time since the mid-90s (Lots of Perl / CGI goodness). Currently they are in the process of moving certain parts of the site to use MongoDB. Besides the history lesson on the site, he also mentioned how they are dealing with possible future changes in architecture, notably by building APIs around the site functionality. This talk got my gears running about some of my own projects, and how I might build any new projects I have in my mind.

MongoDB Profiling and Tuning: This talk was given by Kenny Gorman, who works as a data architect at Shutterfly. Kenny went through some of the steps used to profile MongoDB, like using explain() on your queries, and how to make things faster, not only on the software side, but also on hardware. He brought up Facebook’s Flashcache, and how it makes MongoDB speed up. I particularly enjoyed hearing the hardware side of things, as I feel like hardware is mostly overlooked by developers.

MongoDB’s New Aggregation Features – A Sneak Peek: Chris Westin is a core MongoDB contributor, and he gave us a sneak peek at a new framework for aggregating records in MongoDB. This framework is really not meant to replace Map/Reduce, which will still serve very well for massive data. But for people like me, who need to aggregate smaller amounts of data (thousands of documents instead of millions), this will be much easier and faster to deal with. Very cool stuff, and I can’t wait to use it.

Lessons Learned from Migrating 2+ Billion Documents at Craigslist: Former Yahoo! and current Craigslist employee Jeremy Zawodny spoke about how Craigslist is using MongoDB for their posting archive, and the lessons learned along the way, like the usage of replica sets even in development, document encoding, and how important data types are when migrating collections. He had a similar talk at MongoSV a few months ago, so I didn’t feel like there wasn’t much new information here. Still, a good talk about migrating a large amount of data from MySQL to MongoDB – it can be done.

Practical Scaling and Sharding: Eliot Horowitz is one of the main MongoDB contributors, and the CTO of the company that backs MongoDB, 10gen. He went through the features and usage of Replica Sets and Sharding, with a few use cases and live examples. This seemed more like an introductory talk more than anything else, so there was nothing groundbreaking here.

MongoDB at Foursquare: This talk was given by Jorge Ortiz, an engineer at Foursquare, who proceeded to mention briefly how MongoDB was being used at Foursquare, some of the lessons they’ve learned throughout the years with MongoDB, and talked about their Scala library for querying MongoDB called Rogue. Frankly, I was disappointed with this talk, as Jorge didn’t give much insight outside of a few numbers and oft-repeated tips. I was expecting a more informative talk here.

Indexing & Query Optimization: Alvin Richards, a West Coast 10gen employee, gave an in-depth talk about indexes in MongoDB. He went through everything, from basic indexes, to indexing order, to new indexing options in MongoDB 1.8 (sparse indexes and covered indexes), to even showing representations of the internal B-Tree implementation. Very informative.

Lightning Talks: This was divided in three shorter talks. First up was Michael Goff, who spoke about how his company, Cocoafish uses MongoDB to serve up data to mobile apps. Next was Chris Carrier (Is he on Twitter? I couldn’t find an account to link here) from Zuberance, speaking about how to create a reporting backend using MongoDB. Last, but not least, was Chad Arimura, who went through SimpleWorker, a cloud-based job scheduling service that uses MongoDB. These talks were short – which you might have figured out with ‘Lightning’ in the title – and seemed to be mostly about the speakers’ particular sites more than anything else.

At the end, Eliot Horowitz gave a quick rundown on the upcoming features for MongoDB 2.0, like TTL collections, online data compaction, faster Map/Reduce, etc. Surprisingly, this 2.0 release is scheduled for June 2011, as in next month. Seems like they’re going to be doing quicker iterations and getting new stuff out there as soon as possible, which can only lead to good stuff for users. There was an after-party, but when I swung by the place there was a massive line outside to get in, so I decided to head home instead. Unfortunately, this is the third time in as many conference after-parties that I’ve had to do this, so it seems like these after-parties don’t scale well.

Overall, while the conference was pretty good, and everything was organized very well, most of the times I felt like I was out of place or at the wrong talk. Judging from the few people I spoke to, and those that I overheard, it seems like most people at the conference hadn’t used MongoDB much (or at all), and many talked I went to touched on what I consider some of the basics of MongoDB. Even if they weren’t basic topics, like Replica Sets or Sharding, if you have read a recent MongoDB book, you knew what most of the speakers were talking about. Also, there was plenty of repeating of the same tips over and over again in a lot of the talks. For example, in the nine talks I went to, the speaker mentioned the “always keep indexes in memory” rule of thumb in at least five of those talks. Truth be told, MongoDB isn’t really a super-deep technology (even the aforementioned O’Reilly book clocks in at a bit north of 200 pages), so this can be the reason why. But I wanted to know more on the upcoming features in MongoDB (I only really saw one talk in the schedule like this, which was the new aggregation framework), and some more in-depth views of how companies are leveraging MongoDB in their technology stack instead of just pointing out how awesome MongoDB is – which we already know.

In any case, I had tons of fun, learned some new tips and tricks, and got some fresh inspiration to use in my own work soon. The best thing about these conferences is knowing that what you’re learning and using is valuable not just to you, but to many out there, and it just gives you motivation to keep on using those tools in familiar and new ways. Much props go out to 10gen for making this conference go smoothly, and hopefully there’s another one of these sometime next year.

I finally decided to put my foot down and do whatever it takes it finally get a grasp of iOS development. And the dedication is finally paying off. I finally feel like I’m getting used to the development environment and most of the basics to actually get something done. It’s not like I have a million-dollar app I want to develop or anything, but seeing that mobile development is one of the hottest trends out there and will most likely be for the foreseeable future, I want to be a part of that wave while it’s still peaking.

I wanted to share some of the material that has been greatly helping me out during this journey. Note that there isn’t a lot of material updated with info on iOS 4 or Xcode 4, and although there are minor changes, like slightly different method names, for the most part the material is still very much useful.

Beginning iPhone 4 Development: Exploring the iOS SDK by Apress

Of all the books I’ve read on iPhone development, this seems to be the one that made it all click in my head. The writing feels a bit on the simplified side, which really made my brain be able to grasp and retain the concepts presented in it. The way the chapters progress is smooth, and doesn’t really overwhelm you with a lot of new concepts. I’ve noticed that a lot of books give you examples with a lot of new stuff that they haven’t covered yet, then proceed to say something like “trust us, ignore this for now and we’ll explain later”. This book doesn’t really do that much, besides when it’s apparently necessary to hold off.

This book also contains probably the most updated print material I’ve seen anywhere, as of this writing. If you were only to get a single book on iOS development, I would highly recommend this book above anything else.

Peepcode Screencasts – iPhone View Controllers, Part I, iPhone View Controllers, Part II and iPhone Views I

One of the most confusing things for me with iPhone development is the concept of view controllers. It was the one thing that tripped me up, despite trying to find as much info about it as possible. Although the previously mentioned book helped me the most to clarify a lot of these concepts, these Peepcode screencasts are also great for understanding how views work on iOS. It took me a couple of viewings of the first two parts (I haven’t purchased the most recent screencast) to really understand things like table views and cells and the different types of views available (Tab Bar, Navigation, etc.)

Programming in Objective-C 2.0 (2nd Edition) by Stephen Kochan

One of the mistakes I made early on in my Ruby career was the fact that I took the time to learn Ruby on Rails, but not the underlying language which is, of course, Ruby. Looking back now, that hindered my progress early on, since I knew the basics, but couldn’t really fully understand the real power behind Ruby, like metaprogramming. It limited what I could do. So instead of following that same path again with the Cocoa Touch framework, I decided to take the time to get deeper into its underlying language, Objective-C.

This book is definitely the definitive guide to Objective-C. It covers just about everything in the language – clocking in at almost 600 pages worth of material. While I don’t know if Objective-C should be someone’s very first programming language, it’s actually starts of with basic programming concepts like methods, classes, variables, looping, etc. But it gets deep pretty quickly, covering plenty of Apple’s Foundation Framework. It’s an excellent reference, and one I keep by my desk at all times.

Apple’s iOS Developer Library

I was pleasantly surprised to see that Apple’s online documentation is really well put-together. It covers everything from basic Objective-C to more specific iOS functionality, like Push Notifications or the iAd Framework. A lot of the basics are available for free, but I believe there’s a lot more documentation for users that have registered to their $99-a-year iOS Developer Program.

These have been the top resources I’ve been using these past couple of weeks to get up to speed with my iOS development. With these resources, I’m getting very close to feeling confident enough to put together a simplistic app, maybe even publish it in the App Store for the hell of it.

If you’re curious to want to start iOS development, these books, videos and online documentation will help you a lot. Don’t feel overwhelmed by the amount of material out there. Just dive into it! There’s a ton of things that iOS devices can do. It’s just a matter of digging in and exploring further those parts that interest you, whether it’s a simple app with a table view or a full-blown OpenGL ES video game. Happy hacking!

In the spirit of getting feedback as quickly as possible after we commit our code changes, we have a continuous integration server (running Hudson, which is very awesome). This, of course, will pull our code changes and run all tests we’ve written so far, letting us know when something failed along the way. But instead of being notified by emails, we decided to make things a bit more fun. We plugged in a pair of speakers to the CI server, and using the text-to-speech tool Festival, we’ll get a nice voice notification of who broke the build when tests fail. It’s a great way to get the instant feedback needed to fix things when they’re most fresh in our minds. The only drawback is the fact that one of our developers is in Romania, so he doesn’t get to hear our Hudson box yell at him. He does get notified via Campfire, though.

However, the fun doesn’t end there. I bought a cheap piggy bank that looks like a big keyboard key with the word ‘Save’ on it:

Whenever someone commits code that breaks our test suite, not only do they have to suffer the embarrassment of having Hudson bark at them, but they also have to pay a dollar to our ‘Broken Tests’ fund, and have the dreaded ‘Save’ button sit at their desk as a reminder to save things before committing. The ‘Broken Tests’ fund goes towards the bar downstairs, where us local developers spend the cash on beers for the team. Thankfully we don’t break the test suite often enough to get beer often. It’s a punishment, but it leads to a good thing, eventually.

Does your team have any sort of ‘punishments’ when one of the developers breaks the build? We’re constantly thinking about different things to add to our little routine, just to keep things light around here.

As any software engineer is prone to do, I wanted to build something a bit more cool. That’s when I figured out that this would be the perfect chance to finally do something useful with Notifo. Notifo is an awesome service that provides real-time notifications to a number of devices, in particular to iPhones (although their list of supported devices seems to be rapidly expanding). I’ve been using Notifo just for setting up simple timed reminders and to get notified of replies and mentions from Twitter using push.ly. Getting notifications in real-time of failures would be something great to have.

Using Ruby,, Sinatra and the Notifo gem, I quickly whipped up a small app called Fail Notifier. Basically it’s a service where any application / server can make a simple HTTP POST to where Fail Notifier is running, and it will relay the message to the user in real-time using Notifo. Simple, but very useful. The best thing is that you can use it anywhere to notify you about anything from any app, programming language, server, or anything else that can make a simple HTTP request. For example, I have Fail Notifier installed on my VPS (nginx and the recently-released cURL about some failures, and I also have some notifications for very important background tasks in a Rails app.

Of course, Fail Notifier is entirely open-source for you to do with it as you please. Feel free to fork the code on Github and hack away to your hearts content.

This post, however, is not about the adventures of a Puerto Rican being thousands of miles from home (although it could certainly make for an interesting story for another day). This post is about me pulling the trigger on something I’ve wanted to do for a long time – switch my VPS (which is where this very blog is running) from Slicehost to Linode.

To begin, I wanted to state that Slicehost is very, very awesome. I’ve been a customer of theirs for more than two years, and never had any major issues with them. With the exception of some outages, their service ran smoothly for the most part. This is more than anyone can ask for. So, if Slicehost is so awesome, why didn’t I marry them? I was perfectly content in staying with them.

However, as I was experimenting more and more with Ruby, Rails, Python and other languages / frameworks, my VPS – which was the smallest slice available at 256 MB – was obviously starting to suffer under the memory constraints. Since these were mostly experiments, I didn’t want to splurge and pay almost double for a 512 MB slice. That’s when Linode announced that they would be increasing the RAM sizes of all their slices. So it was either to stay with Slicehost and have my VPS struggle to keep up with my experiments (or pay more per month), or switch VPS providers. After reading all around the Internet about how good Linode was, I decided to go for it.

I opened an account with Linode and instantly had my sparkling new VPS running. I transferred all my files from the old Slicehost VPS and just had to point my domain names to the new Linode VPS. My main concern initially was that Slicehost had really spoiled me with their control panel, especially for DNS management. It was what had initially drawn me into their service to begin with, so leaving that behind was a bit scary. Thankfully, Linode has their own control panel that’s equally great to use. I was able to configure and point my domain names to the Linode VPS, and had everything working quickly.

As far as performance, I had been reading for years how Linode has faster I/O performance than Slicehost. Turns out that those tests seem to be true – The VPS as a whole feels much snappier, from logging in via SSH to serving up this very blog.

One of the major issues people had against Linode in the past was that they lacked any integrated backup system, a la Slicehost. They actually introduced backups a few months ago. This wasn’t a major concern for me (I’m using Tarsnap, which deserves a blog post of its own), but for those who need this sort of service, know that they have you covered.

Like I mentioned, Slicehost is great, and I wouldn’t encourage people to not use their services. I just had different needs that Linode seems to be handling as well as I expected. It’s only been a couple of days, but I think I’ll be shutting down my Slicehost VPS for good.

Tomorrow will officially be my first day as a Rails developer for RepairPal. I was in their offices last week to meet them personally, and everyone seemed very friendly and the company seems to be doing some cool stuff, so I hope I’ll be a part of all the awesome stuff that’s to come. It’s really a dream come true for me to be where I’m at right now, at this very moment. It’s proof that if you really want something bad enough, and you work hard for it, whatever you want will come true.