Posts Tagged rails

Blog series for RubySource

I have now officially started a blog series for RubySource. The first post came out today: Switching to Ruby From .NET!

I’ll be posting there regularly every other week for several months. I’ll continue posting here to my personal blog, too. The main difference is that at RubySource each post will be more polished, and there’s also people editing it, whereas here on my blog it’ll continue to be a place where I dump ideas as I sketch them out.  Smile

I hope to continue seeing you here, and start seeing you at RubySource as well!

,

Leave a comment

My first steps into Mac land

After two decades of working with PC’s, as I’m into this mood of trying out different things now, I’ve decided to get me a Mac a couple of weeks ago. I’ve been doing Rails development for a few months, and I kept hearing and seeing people say that the Mac is a much better platform for that, so I decided to give it a go, since now that’s what I’m doing fulltime.

Which Mac to get?

I have two big monitors hooked up to my PC, so getting a Mac Mini and hooking it up to one of my monitors was one of the options. But then what do I do when I have to go on trips, clients, conferences, etc.? I need a laptop. But then again, which one?

I friend of mine had just purchased a MacBook Air; the 13-inch screen one. At first I thought it’d be too small for me, but playing around with my friend’s it actually felt alright. The machine seemed really fast despite its size, the battery lasts for several hours, and a thought dawned on me: if I had one, I could hook it up to one of my big monitors when working from home, and I’d had a very portable laptop to take with me on trips.  So that’s what I did: 13-inch MacBook Air, with 4Gb of Ram.

How to get used to it?

My prior experience to using a Mac had been about 20 minutes playing with somebody else’s machine. Because of that, I decided to just set it up on the side initially, so I’d do most of my work on the PC where I’m 100% comfortable, and just go to the Mac in order to install programs, try small things out, get used to the keyboard and multi-touch trackpad, etc.

I have to say, several times, I feel totally useless. Main reason being just now knowing how to do the most simple things: for instance, where’s the context menu (right-click menu)? What’s with delete/backspace? Where’s home/insert/pageup/pagedown…? How do I work with the Terminal (console) window? Can’t tell you how frustrating it is to get stuck in those things when you’re trying to get something done.

In order to speed up me getting used to it, I had to quickly set it up to make it somehow feel like it does when I’m using Windows configured to my taste. I guess that takes me to what’s probably the single most important thing when using a computer…

An Application Launcher

A very long time ago I was already very particular about finding ways to quickly launch applications or navigate to places on computer. On Windows, for a while I’ve used “Start->Run…”, WinKey+R, the Address bar tweaked into the taskbar, etc. Then I’ve found SlickRun, which I’ve used for several years. Then, when showing and talking about SlickRun two years ago at a Virtual Brown Bag, somebody showed Executor, which I totally embraced every since. In fact, when I’m building a Windows machine, right after installing the Operating System, Executor is the very first application I install; this is, easily, the application I use the most on Windows (I should really write a post about how I use that tool…).

So, I needed something similar for the Mac… really bad! Alfred was it. I haven’t fully explored this tool yet, but it gives me 80% of the features I use most of the time in Executor. The free version has the “application launching” features, but I’ll be getting their PowerPack version soon, which adds the “folder navigation” features (which I use a lot on Windows), among other things. Ah, it also adds “clipboard history”, which on Windows I’ve been using ClipX for.

Another things that Alfred gave me is the ability to lock the screen (sort of like WinKey+L on Windows), which is another thing I use every time I walk away from my computer.

The Development IDE

Obviously, as I’m going to be primarily using my Mac for development, I needed an IDE. I understand people use TextMate, MacVim, etc., but I needed something that can get me productive as quickly as possible. Like I’ve mentioned a couple of weeks ago, I’m using RubyMine on Windows for Rails development. As it turns out, that tool also runs on Mac. Sweet. The main thing for me has been to just remap the keybindings so it somewhat resembles what I have it configured on Windows.

The Console

I’ve been using the command prompt (DOS) on the PC ever since I started working with computers, and then PowerShell in the last two years or so. I had never used Bash before (well, I did try it for 30 minutes a few months ago, got stuck, and gave up). Well, now I do need to learn it, since that’s what I get in the Mac’s Terminal window. I need to review Joshua’s presentation on Bash, as well as watch PeepCode’s Meet the Command Line and Advanced Command Line videos.

Source/Version Control

For source control, I’ve been using Mercurial. On Windows, TortoiseHG works really well for me. On the Mac, I’ve started to use MacHG; I can’t say I’m 100% happy with it, but it may still be just be been uncomfortable with the environment as a whole. One thing that got me at first is that I needed to install Mercurial in order to be able to access the “hg” command in the Terminal window. After I did that, things worked fine.

One more thing: when trying to open a project in RubyMine that has a Mercurial repository, we’re asked to provide the path to the hg executable, which I had no idea where that’d be. Found it here. One of my buddies pointed out I could also run “which hg” on the Terminal window, which tells me the path to the given executable.

Also, Mercurial only accepts commits if it can find a username. In order to do that, we need a global .hgrc file in the “home” directory containing those settings.

Diff Tool

BeyondCompare has been my Diff tool of choice for several years (for both files and folders). Unfortunately, it doesn’t run on Mac (as far as what I’ve read, it’s because it’s written in Delphi, which doesn’t run on Mac…). After asking for recommendations, I got to DeltaWalker, which seems very similar to BeyondCompare. I’m using its trial to see how it feels. It’s supposed to have easy integration with Mercurial and Git, so I’m hopeful, as BeyondCompare integrated really well with my workflow on Windows.

MongoDB

I’ve been using MongoDB on my Rails projects. In order to get it going, I’ve followed the instructions here. Which has led me to Homebrew. In order to get Homebrew going, I needed XCode (5 bucks). After that, all was good.

Where’s Bundle Install?

Source code in place, database, Ruby (already comes in the Mac), so I’m ready to do Rails development, right? Well, no. As soon as I try running bundle install, things don’t quite work like I expected. No biggie; followed instructions found here, and I was back in the business.

Text Editor

I have tried to use the text editor that came with the Mac, but didn’t like it. I then tried TextWrangler, which has been only frustration (seriously, I can’t find a way to open a file in the darn thing, for crying out loud!). I’ll be getting TextMate, as that seems to be everybody’s favorite. Also, eventually I’ll get into MacVim, which sounds like something I’d like very much.

More Tools

I’m also going down Ben’s Ultimate List of tools for Mac users. Lots of good stuff in there.

Performance

I’ve noticed that running RSpec/Cucumber tests on my Mac is a LOT faster than on my super powerful PC. I don’t know why that is, but I can easily perceive that.

Summary

I’ve made the decision to only use my Mac for Rails development moving forward. Things run faster, more smoothly, etc. I’ve been using it as my primary development machine for the whole last week, and am enjoying it.

,

5 Comments

RubyKoans: Great way to learn the Ruby language

Several people had mentioned the RubyKoans to me. It took me a while to get started on it, but I’m glad I did, and finally finished them just a few days ago!

finishedkoans.

All you need to do is to install Ruby (try RubyInstaller if you’re Windows), download RubyKoans (it’s just a bunch of text files zipped up), get on the command line, and go for it. You run “ruby path_to_enlightenment.rb”, and it’ll get you started. The Koans are just a bunch of unit tests that walk you through learning the core aspects of the Ruby language.

As I was going through the Koans, I pushed my progress to a Bitbucket repository.

koansbucket.

I hope to revisit this repository as I learn Ruby better am able to improve some of the code I wrote here. By the way, as you’re going through the Koans and either get stuck on a step or are wondering how other people have solved it, just search for it on the web; most often you’ll find blog posts, StackOverflow posts, or GitHub or BitBucket repositories where other people have shared their solutions.

,

Leave a comment

My Adventures in Rails Land

As I’ve been asked quite a few times by .NET developers what my experiences in Rails have been like, I’ve put together a simple Prezi presentation and made it available here. It contains a summary of some of my blog posts so far and a couple of other things. I plan on continue updating this as I keep blogging new things.

By the way, I think I’ve finally abandoned PowerPoint in favor of Prezi.

Leave a comment

My New Journey Begins…

As of today, I’m no longer an EPS employee. I have decided to go solo and take on an opportunity to work full time on a Rails project. It has been over 8 years and 7 months since I’ve joined the company (that’s my personal record!). It was by far the best company I’ve ever worked at. I will continue to have a professional relationship with the company, doing some contracting work as opportunities arise. But, above all of that, I definitely want to continue my friendship with everybody there.

With EPS, I have learned a ton, I’ve been encouraged to continue doing presentations, I’ve had the chance to teach and learn from my fellow co-workers, I’ve had lots of fun at “EPS Fun Days” and all other informal get-together.

I am very fortunate: other than the one time when I was still 14 years old, I have never had to search for work. I can trace every job I had back to somebody who came after me offering some sort of opportunity. Out of all these people, Markusand Ellen were the ones that offered me my biggest opportunity, and that will never be forgotten.

So what’s next?

If you’ve been following my blog, you have probably seen my postsabout Rails development, so you know I’ve been enjoying it a lot. Over the last couple of months I’ve been working nights and weekends on a Rails project, and I’ve been offered the opportunity to work on it full time, for at least one year. The project is fun, and the clients are great people to work with, so after putting a lot of thought into it, I decided I should go for it.

I’ll continue with the Virtual Brown Bag every Thursday, as well as writing this blog, so I won’t be dropping off the radar.  🙂

17 Comments

Book Review: The RSpec Book

I’ve just finished reading “The Rspec Book: Behaviour-Driven Development with RSpec, Cucumber, and Friends”, and I totally recommend it to anybody writing Ruby code. Being fairly new to Ruby, I had limited experience (still do) to RSpec and Cucumber, but despite plenty of literature available on the web, I was glad to find a book dedicated to this subject so I could absorb some structured information.

The RSpec Book: Behaviour Driven Development with Rspec, Cucumber, and Friends (The Facets of Ruby Series)

I like the way the book is organized and how it develops the idea of “outside-in” development; starting from writing features in Cucumber, writing “the code you wish you had”, and then going into RSpec to drive out the implementation of controllers and models.

The authors do a great job at explaining how RSpec works, and that was very useful as that had been kind of magical for me. I start to see more and more what people have been raving about regarding how Ruby is such an elegant language. The book also includes tips on how one can clean up tests by using built-in matcher, or creating custom matchers, and stuff like that.

I’m keeping this book handy so I can use it as a reference as I write my tests and look for ways to improve clarity.

, , ,

Leave a comment

Rails, Cucumber, RSpec, Testing, BDD, and all that stuff

Three years ago I blogged about my thoughts at time on the whole testing thing. I have stuck with the practices and really believe on it. I’ve tried different tools and approaches, and I keep trying different things as I go. Behavior-Driven Development (BDD) seemed like my next step, but it didn’t take me long to realize MS-Test didn’t give me what I needed in order to start to get into that practice. There wasn’t much I could do as I was stuck with it.

When C# 3.0 came out, I’ve learned how I could improve my tests using extension methods, building some sort of fluent DSL to test certain things. Eventually, I was able to migrate to xUnit, along with SubSpec, and then I was able to write tests a lot better, following the “given-when-then” style. Writing new features and certain components following that style has been great; I believe everything I wrote following that approach has a much better design and quality.

I had heard Rails developers gave a lot more importance to BDD and testability than .NET developers, so that was one of the driving factors that encouraged me to try Rails.

After getting a little more comfortable with Rails and Ruby, I started to devote more time to RSpec and Cucumber, without really understanding much what they were exactly. So far, I’m enjoying using both. I’m almost done reading the RSpec book (I’ll post a quick review once I’m done) and writing as many tests as I can, but I still have lots to learn; I’m still at that stage where I do know there must be a better way to write something, but I’m not to a point where I know how to do it.

I am writing lots of “features” formatted so that I can drop them into Cucumber .feature files, and then implementing them. I’m finally realizing some benefits of BDD that were apparent to me before. Up until recently, I was seeing BDD mostly as a way to write tests where the scenarios were described such as “given whatever, when something happens, then I should get x”. But those were described as strings surrounded by C# code, so the business value wasn’t immediately apparent.

Now, however, I’ve been sticking to this format (right off the official Cucumber site):

feature

This format makes it a lot easier to see the business value out of an atomic feature. It shows a short title for the feature, the ultimate value out of it (“in order to…”), who’s getting benefit from it (“as a…”), and what the person wants (“I want to…”). Then, it describes the different scenarios that exist for the given feature. I like the fact that there’s no specific programming language clutter mixed in with the description of the feature. 

If I’m the one writing those stories, as a developer, it forces me to be as clear and succinct with the English language as possible, so that it will make it easier for me to validate these with my clients and users; and as they get familiar with the format, they can start providing me the stories themselves.

Another advantage I’ve been noticing doing these is that by analyzing the number of steps within a given scenario I can identify whether the user experience is going to be good or not. The scenario unveils how hard it is for the user to access the feature (“user has to click this, select that, fill out the other, click this other thing, and only then get to what she needs…”), and how the user interacts with the system (what the user does, and how the application responds).

Breaking scenarios into small, concise units… doesn’t that sound similar to “breaking classes into smaller, concise classes, methods, etc.”? Putting some good thought into writing these stories can help out the developer later when actually implementing the feature.

And here’s another benefit of keeping scenarios small and concise: planning. When discussing the feature with the clients, I can get them a feel for the complexity on each scenario, and they can tell me which scenarios are must-to-have, and which ones could come at a later time. This way we can plan on which features and which specific scenarios are going to be implemented on a given iteration or release.

I’m also following the idea that “Cucumber tests cover the application’s behavior, and RSpec tests cover class’ behavior”. In other words, I write Cucumber tests to check a feature end-to-end, from the user’s point of view, and I use RSpec to test a class’ behavior.

Some people say one of the main advantages of Cucumber is that non-technical people can easily read, or even write, the tests, but some developers say “the non-technical people will never read anything anyways, so why bother?”. So far, I’m seeing the Cucumber tests as being very beneficial for myself, for the reasons listed above (like forcing me to think of the features in a cleaner and more concise way, etc.).

At the moment, I have the following workflow:

  1. Write the features and store it in Evernote (tagging everything so I can group features based on specific user roles and things like that);
  2. Review stories with the client, rewrite pieces, split features up, move scenarios around, etc;
  3. Once it feels like a given feature is a little more stable, I put it on the Kanban board in AgileZen;
  4. Pick features that are on the board, and plan them accordingly;
  5. Once I start working on a given feature, it’s just a matter of turning them into a Cucumber file, and go about implementing it.

This is not written in stone, and it’s just something I’m trying out. I have no idea whether that’d scale for large teams or whatever, but I’m being pragmatic and doing whatever it takes to be productive given what I have. It seems to be working. I’ll keep you posted. Smile

, , ,

4 Comments