Posts Tagged rails
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.
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. 🙂
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.
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):
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:
- Write the features and store it in Evernote (tagging everything so I can group features based on specific user roles and things like that);
- Review stories with the client, rewrite pieces, split features up, move scenarios around, etc;
- Once it feels like a given feature is a little more stable, I put it on the Kanban board in AgileZen;
- Pick features that are on the board, and plan them accordingly;
- 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.
Only recently I’ve found out about this book:
|Rails for .NET Developers (Facets of Ruby)|
I’m not sure it’d have been more useful when I was just getting started on Rails, or now that I’ve had “some” experience with it (still long ways to go, though…). Regardless, this is a good read for .NET developers, no matter whether you’re looking into learning Rails, or whether you just want to see if there are ideas from Ruby or Rails that you’d like to incorporate into your .NET applications. Or, as mentioned in the book, it may also be useful for Rails developers who may need to teach .NET developers.
I’ve picked up this book mostly because I wanted to see what kinds of things I had not looked into it yet since I started messing with Rails. To my surprise, I’ve realized I have tried (or at least read about some place else…) most of the things covered by the book.
Throughout the book, the author shows .NET and Rails counterparts. At the time the book was written, the ASP.NET MVC wasn’t quite out yet, so the author covered mostly WebForms, and had just a small section on ASP.NET MVC. Not a lot of words had to be spent on the .NET samples, though; since the main target for this book is .NET developers, it’s assumed they’d have a good understanding of the .NET implementation.
With that said, it may not be a fair comparison, but my general perception is that the Rails implementations were much smaller and cleaner than their .NET counterparts.
I’m reading several other Rails/Ruby-related books, so you can expect some more reviews published here as I finish them off. You can also check out my list of resources I’m using to learn Rails.
I am very particular when it comes to the tools I use for software development. When doing .NET development, I do not use only Visual Studio; I use both CodeRush *and* Resharper, plus some other plug-ins, as well as tweaking VS a lot to bend it to my liking (color scheme, fonts, custom keyboard shortcuts, different window layouts based on single or dual monitor setups, etc.), besides having finally embraced PowerShell to run a couple of things, as opposed to waiting on Visual Studio to become “not busy”.
When I started messing with Ruby on Rails I decided to spend some time (ended up being two weeks) with no tools other than Notepad2 and PowerShell. I wanted feel the pain first, figure out what I missed from my regular .NET development environment, and then figure out what was available for Rails development.
Some of my buddies swear by Vim, which I know I’m going to like when I get to it, but I figured this wasn’t the time to look into it yet, as I was already too busy learning lots of other stuff, so I didn’t want to get stuck at every other keystroke.
Since a couple of people suggested RubyMine, I decided to give it a go; the same company makes Resharper, so I guessed it’d be the easiest choice for me. The guess was right, at least so far.
Getting used to RubyMine
I started off just by using it to open multiple files and work with them. In small steps, I started to learn a few things and configure the environment to my liking. As much as possible, I’m setting it up with the same keyboard shortcuts I have in VS for certain actions that I perform a lot (for instance, looking up files, classes, etc.).
Once in a while, I visit the training material for RubyMine: there’s the Quick Start, there are videos, there’s the default keymap binding (which I have a quick link to on my desktop!). Another nice way to learn RubyMine is by using the Productivity Guide (available in the Help menu):
The Productivity Guide lists features and how often I’ve used them. I then look for the ones I’ve never used, see what they’re used for and how they’re accessed (at the lower half of the screen), and then give it a shot.
The Key Promoter plug-in is also a neat way to learn RubyMine. After you do the same thing with the mouse for 3 times (this is configurable), the plug-in shows a title tooltip to tell you what keyboard shortcut you can use to execute that action.
Organizing the IDE based on tasks
This is a feature I started using recently and am enjoying: say I’m working on a given task (implement user story X), and I have several files open. Then, for whatever reason, I need to switch gears to work on a different task (fix bug related to Y), which will require me to open an entire different set of files. By creating “tasks” in RubyMine, I can easily adjust my workspace based on the files I need to work on for each task.
Integration with Git / Mercurial
RubyMine integrates very well with both Git and Mercurial for version source control. For the most part I use the command line for committing, pulling, and pushing changes, but there are quite a few occasions when I rather have some visual way to invoke commands and see results (such as when comparing changes, or seeing history).
It also does some nice things, such as when I add a new file to a project, it asks me whether I want to version it or not.
I haven’t fully explored this integration, mostly because I’m relatively new to Git/Mercurial, but I do like what I’ve seen so far.
Navigating through files
All the common options for navigating through files are there, such as “go to class” and “go to file”. A Resharper feature that I use a lot in Visual Studio is “Find in Solution Explorer” (Shift+Alt+L). What that does is to put the keyboard cursor in the file as it’s located in the Solution Explorer. I use that *all the time*! It allows me to quickly go to the same place where the current file is located, and then go to files in the same folder, or other folders in the surrounding area.
In RubyMine, I can use the “Show Navigation Bar” option (Alt+Home):
I like that even better, as it allows me to easily navigate through the project’s structure, without having to go through a project treeview (which means I can always have the project window hidden, and therefore get more real state on my screen).
Another way to navigate through a Rails application is by changing the Project window to “View as Rails”, which then allows easy navigation through controllers, actions, and views.
Running Rake Tasks
The output of tasks go to the “Run” window in RubyMine. There are special visualizations for the output of things such as Cucumber tests. The one I use the most, however, is Rake Routes, since I can hit Ctrl+F and search for something within my routes:
Working with Cucumber
RubyMine has nice features to work with Cucumber. Besides the already mentioned Cucumber test runner, it also allows from a step to its implementation by hitting Ctrl+B. And when defining scenarios, it also shows a list of available steps to re-use.
Compare with clipboard
This one I’ve learned just a few days ago: besides invoking a “compare” between different versions of a file, RubyMine also has a “Compare with Clipboard” feature. It comes I handy when I have two blocks of code that seem to look similar but I can’t quite put my finger on what the differences are. With this feature, I can put one of the code snippets in the clipboard, go to the other one, and invoke “Compare with Clipboard”:
Seems a lot faster than Visual Studio
As far as loading the first instance, it seems like the load times between RubyMine and Visual Studio are very similar. However, normal usage feels a lot faster in RubyMine. Also, once one instance of RubyMine is open, opening a second project in a separate window is almost immediate, which I can’t say the same thing about VS (it takes just as long to load a second instance of VS).
When doing Rails development, it’s convenient to have multiple command prompts open at the same time. I’m using Console2 for that, as it has tab support. I also like how you can set it up to load different types of console, such as PowerShell, git-bash, etc. I’ve configured mine so I have shortcuts to open the different types of console I use, as well as alternating between the tabs quickly.
I usually have at least four tabs open:
- Mongodb server
- Rails Server
- Rails Console
- My regular console for running Rake and other commands on the project I’m working on
I’m very happy with the tooling I have at hand at this point. I can’t really say, right now, that I’m missing anything from my .NET development environment. Quite the contrary, actually; not having to cope with the lockups of VS, the non-sense behavior of TFS, the testing-hostile tools and frameworks, has been a blessing.
Oh, and by the way, I’m doing development on Windows, since I don’t own a Mac. I’ve set up an Ubuntu virtual machine, but I don’t know much Linux yet, so I’m saving that for a later moment.
Last week I attended to the North Houston .NET User Group, where my buddy Ben delivered a great Intro to Rails session. The source code came out great in the video (just make sure to go full screen). Enjoy!
One of the main roadblocks I see for several .NET companies and developers to get into Rails is the matter mentality. For somebody who has been doing .NET development for several years only doing it “The Microsoft Way”, not looking outside of the box, getting into Rails can be a total nightmare.
Company-driven or Community-driven
.NET and Rails are produced by people with different goals in mind: the first comes from a company who wants developers to produce software for their operating system and devices, whereas the second comes from developers who need to ship software.
It doesn’t look like the people within Microsoft actually use their tools to build real world software, which causes tools and frameworks to not exactly address difficulties developers face out in the wild. Everything I’ve seen in Rails development has been quite the opposite: it’s all built because of a real world need.
Rails is totally open source: which means that if somebody finds a bug, a vulnerability, etc, the patches make into the framework as soon as possible. If somebody writes a nice feature, there’s a good chance it can make it into the official release of the framework.
As far as what I’ve heard, even though the source code for the ASP.NET MVC is available for whoever wants to get it, Microsoft does not accept community submissions. It is true that the product team seems to hear feedback from the community, but such feedback may or may not, one day, make it into the framework. Microsoft is too big of a company, and as such, even simple changes may take forever to be even considered.
Ah, the gems…
For several mundane things we need in applications, there must be a gem available out there (.NET developers can think of them as “components”). Authentication, authorization, avatars, image handling, you name it. As far as what I’ve seen, the Rails community doesn’t suffer with the NIH (not invented here) syndrome; these people embrace the idea of “let’s not reinvent the wheel every time”; if there’s an open source piece of code out there ready to rock, let’s use it.
In the .NET world, even though there’s quite a number of things available in open source, most people and companies just don’t embrace it. “We won’t use it if it doesn’t come from Microsoft“, is what you normally hear.
Testing is something that the Rails community just take for granted. It’s a no-brainer. The framework is built with testability in mind. Books are written the same way. Gems (provide either helpers or good documentation (or both!) so that developers can easily write tests for their applications that use these gems.
Because testing is such a first-class citizen, tools and frameworks make sure that writing tests is as frictionless as possible.
What’s the testing story coming out of Microsoft? MS-Test? Oh, please. What about all the sealed classes, and things that are nearly impossible to test (unless you use tools such as TypeMock)? We know of a couple very smart MS developers who are advocates of testing, but the company as a whole doesn’t send out a strong message about its importance.
A lot of people may think of tests as “oh, yeah, Assert.AreEqual(4, 2+2), big deal…“, but that’s not it. Behavior Driven Development helps a lot with understanding what’s valuable to the client, flushing out details of the requirements, planning how features are built, tracked, related… It helps with making sure that we only write enough code to deliver the features that are going to make the client happy. My perception is that a lot more Rails developers than .NET developers understand that. If there’s people who understand and follow these practices, as well as tools that remove any friction in doing so, the likelihood of success for a project is much higher.
Object-Relational Mapping (ORM)
ORM is a non-issue in Rails. If you are on a relational database, you use ActiveRecord, and if you are on document database, you use Mongoid or MongoMapper. The main point is: nobody goes off and creates their own ORM component. Regardless of whether you are on a relational or document database (or both), the object model of the ORM options is very similar, so there isn’t a big learning curve going from one to the other.
Also, I have seen some really clever and clean ways that the Ruby language allows for models to be written in such a way to really promote the idea of “thin controllers, fat models”.
In the .NET space, ask half a dozen developers what they use for data access, and you may hear 6 different responses, including Raw ADO.NET (connections, DataReaders, DataSets, etc.), Entity Framework, Linq to SQL, NHibernate, CSLA, home-grown framework, or a variety of other ORM frameworks out there. Don’t get me wrong: diversity is usually a good thing, but in this case, I believe it does more harm than good. The differences in how all these frameworks work are so big that a developer who knows one of them can’t really easily switch over to a project using a different one.
At this day and age, a source control system is a must for anybody doing software development, regardless whether it’s a company or an independent developer. The question then becomes: which one to use?
The default one in .NET is TFS. The default one in Rails is Git. I’ve seen few .NET shops use either Git or Mercurial, and I have seen Rails shops using either Git or Mercurial, but I’ve never seen them use TFS.
I’ve used TFS every since it first came out (5 or 6 years ago?). It’s been painful, every time I needed to install it, and it’s been painful every time I needed to work in a team of developers using it. Problems with files or changes getting lost, weird merge problems, weak support for “branch per feature”, etc.
I started using Mercurial about 8 months ago, and spent another 3 or so on Git, and for the time being I’m sticking with Mercurial (I’ll save the “why” for another post).
What I like about these Distributed Version Control Systems (DVCS) is the idea that I can install and have them up and running within 5 minutes. Using it on a daily basis for normal things (commiting changes, branching, merging, pushing to a remote server) is pretty much frictionless. The idea that I can do all of this locally, without having to deal with remote server all the time appeals to me. Also, being able to easily pull or push changesets between branches, remote servers, etc, is something I like a lot.
Notice I only refer to TFS’ source control features (or lack of) here. As a source control system, I’ve grown to dislike it very much (choosing words so this post can be rated PG-13 here…).
A common mindset in .NET development is: let’s use only tools that are fully integrated into Visual Studio. I personally think that’s a bad idea. The “Visual Studio is Busy” toast message that pops up quite often just reminds me of that. What’s the problem with switching over to a command prompt to execute some commands (build, run tests, create branch, commit, etc) and avoid being stuck just because pretty boy “is busy”? The more integration, the more likely the tool will be busy doing things you may not care about 80% of the time.
In Rails land, people seem very comfortable with using whatever tools make them feel more comfortable and productive doing their daily job.
I’m still very young into doing Rails development, so I may still not be ready to give educated, well-informed, point of view on this difference in mindset, so I reserve the right to change my opinion within just a couple of weeks or months from now. 🙂
My main point in this post is: this is the perception I have on this subject today, and it does look like the mentality is very different in these two camps.
One of my pleasant surprises in learning Rails is the plethora of great material available, either for free, or very inexpensive. I am keeping track of the resources that have been useful for me, and am making “The List” available as a shared note in Evernote, as I keep changing this list regularly.
But aren’t there already several “get started” pages and blog posts out there? Yup, you bet. So why am I creating another one? Well, this one only features the stuff that I have used myself, so it’s stuff that has worked for me, and I’d like to be able to come back to it and review things I know I’ve learned someplace before. By making it public, I’m hoping it may be useful to somebody else.
I’m organizing the list with my “getting started” recommendations at that top, and then everything else afterwards, organized by areas, such as “Rails”, “Ruby”, “Testing”, etc. Some things I’m listing there aren’t specific to Rails (such as RSpec, Cucumber, or even Ruby), but I’m putting them there because I’ve come to start using them because of Rails.
Because there is such a variety of resources available out there, I keep collecting all the things I come across and adding/tagging them in Evernote. Once I get around to trying out the resource, if I feel it’s been somewhat valuable to me, then I move it to The List.
Besides links and general notes, I also add e-books (in PDF format) to Evernote, where I can then run searches and find the stuff I’m looking for real quick.
Finally, since the public link to my shared note isn’t too friendly, I’ve created this short one: http://tinyurl.com/Lassala-TheList
If you have any resources that have really worked well for you, please let me know!
A couple of months back I mentioned that I’d be taking a break from speaking and would start focusing on learning. And that’s what I’ve been doing over the last couple of months.
For the record: in the last 8 years or so, I’ve done very little web development; and that little worked involved mostly working on middle tier components. I’ve done some work on WebForms, but not a lot. Before that, I had spent a couple of years doing “classic” ASP, with COM components providing all the middle tier and html generation.
With that said, I knew that catching up with web development wasn’t going to be easy.
At first, I started looking into ASP.NET MVC. Over the last three years I have read articles on it, I’ve seen presentations, videos, etc. I remember seeing it being unveiled at the ALT.NET Open Spaces conference in Austin, and thinking how that looked a LOT better than WebForms. I thought I’d be better off starting on that track, as at least I’d be working on a familiar environment (C#, Visual Studio, having “some” understanding of ASP.NET and MVC).
I decided to base my studies off the Test-Drive ASP.NET MVC book. I had heard good comments about this book, and I liked the approach of development the sample app from a TDD standpoint, as well as using NHibernate and some other solid Open Source frameworks. I did go through almost half of the book following along with the examples (I am planning on finishing it at some point, at least for completeness sake).
Eventually, due to peer pressure, I decided to start learning Ruby on Rails. And I have no regrets at all (can’t ever say that phrase without thinking of William Hung)!
Seriously, here’s a tag cloud of things I’m having to either learn from scratch, or relearn (after so many years of not using it):
I have been seeing quite a few people whose opinion I value jumping ship from .NET to Rails and saying many good things about it, so I figured I should check it out. Like I said, I’m enjoying what I’ve seen so far, so you can expect more blog posts with my findings in this area as time goes by.