What made you look into RoR?

I kept hearing buzz around 2005 about Rails. I looked into it but initially didn’t get it. I didn’t understand MVC (I was a WebForms guy at the time) and Ruby was totally different than C#. I couldn’t imagine it taking off like it did.

Fast forward 3 years later, after watching more & more people start using it, I decided to start giving it a serious try.

Why did you switch over to RoR?

I found that I was able to build applications very quickly and host them just as easily (on Heroku). When projects came up at work that needed similar agility, I recommended Rails.

What do you like about it? What don’t you?

I like command-line driven stuff. I type pretty fast and it fits in with my workflow. I literally *love* Ruby. It’s crazy, flexible, concise, and beautiful. Gems make application componentization not only possible, but so easy that EVERYONE does it. Usually when you have a problem there is somebody that has already had that problem, solved it, and packaged it in a gem for you to use.

Sometimes it’s hard to see where something went wrong, because there’s a lot of convention & magic going on. Especially when living on the edge. Gems don’t always stay in sync, Rails is changing constantly, so you have to have a lot of patience if you’re going to be working on the latest & greatest.

What do you miss from .NET? What don’t you?

I miss the forward thinking .NET developers, mostly from the ALT.NET crowd. I still hang out with them on occasion, but unless they are at a Ruby or iOS conference, it’s doubtful I’ll get to interact much with them in the future. C# is still a pretty cool language, but I don’t miss the .NET framework really at all.

I don’t miss TFS, Architects who think you should pass around datasets, enterprises stuck on old technologies, Microsoft-slavery, developers who can’t be bothered to read a book & get a little outside their comfort zone to learn something new & amazing.

What made you look into RoR?

For me, it was a way to learn something new – to explore new communities and technologies – and hopefully learn something that I could bring back to my .net development (which I did).

A coworker first showed me the “build a blog in 15 minutes” video in 2007, and wanted to use rails on a client’s project. I had never heard of ruby or rails at the time, so I said no. Fast forward 2 years – we had Scott Bellware come in to do some training on automated web testing for my team. We decided to go ahead and have Scott teach a little ruby and rails in the process. I was amazed at how easy ruby was, during the training (this is also where the idea for ‘albacore’ was born).

At the time, I was a Webforms guy, still. I had looked at asp.net mvc beta and version 1, but didn’t understand it. But after the ruby training from Scott, I started looking more and more into ruby, including rails. I was immediately impressed with how quickly I could get a rails website up and running with basic CRUD screens, using the scaffolding. It wasn’t until I learned rails, that mvc in a web application made sense.

Why did you switch over to RoR?

The opportunity to do something new and exciting, with a fast paced and well organized community was exactly what I was looking for after 9+ years of .net development. I built several small sites to play with rails and learn, at first. The more I played with it, the more I wanted to play and learn and build something significant. In the 2nd half of 2010, I was given an opportunity to not only jump into rails work, full-time, but also go out on my own as an independent contractor/consultant.

What do you like about it? What don’t you?

Rails is generally wonderful to work with. It’s easy to get a site up and running and build real value into the site, quickly. More importantly, though, it gets out of my way. I don’t have time or patience to deal with tools and technology that continuously get in my way. Tools should not dictate how we work, but should be formed to work in a manner that supports us. Rails and the community around it, do exactly that. It’s very easy to change the way rails behaves and how you work with it. This points to the two things that I love the most: the ruby language and the ruby community. It’s the ruby language and the community surrounding it that really give rails it’s power.

It’s not all rainbows and unicorns, though. The rate of change in the ruby and rails communities is staggering, and there’s a very large “shiny new toy” syndrome in the community. People have a tendency to jump onto the latest flavor of the month simply because some celebrity rock star ruby developer said it’s the way to go, today. This has the benefit of constantly moving the technology forward, but often results in days of headache trying to figure out incompatibility issues between different versions of different gems. Even when you are keeping a project stable in terms of gems used, patches and fixes are released on such a frequent basis that the issue of incompatibility is still a problem. Tools like Bundler are meant to help address this issue, and largely do. However, the are often part of the problem, as well.

What do you miss from .NET? What don’t you?

I really miss the sense of architecture and best practices that abound in the forward thinking .net communities. There’s a fountain of knowledge – books, blog posts, videos, speakers at events, and more – all centered around good architectural practices and scaling from the “toy” apps out to the enterprise scale. While this information and knowledge exists in ruby and rails, it seems to be immature and closely guarded (contrary to the open nature of the community). Sites like Github and other large scale systems are the prime examples of how to do things right, but I don’t see the Github people out there talking about the architecture and scalability as much as in the .net world.

I don’t miss the boilerplate of everything that you have to know to even be considered an “intermedidate” developer in .net, these days. If you don’t know IoC, TDD, SOLID, and a dozen other principles and patterns, you’re not staying up to date with what it takes to create good architecture in .net. Many of these patterns and practices are still necessary in ruby and rails, but the language and the frameworks tend to bake this knowledge in as first class citizens instead of requiring you to bolt it on, as an after thought.

I don’t miss is the “Microsoft said …” mentality of most .net developers. I can’t stand it and I don’t understand it. It’s as if people are afraid to learn or question anything, which flies in the face of everything that I’ve ever been taught. People need to look outside of what they are currently doing to understand what else is out there, if for no other reason than to understand why they are doing what they are doing.

And lastly, I don’t miss the all-in-one tooling that Microsoft technologies and teams tend to gravitate towards. Tools like TFS and Visual Studio may have great business appeal because of the tight integration between them all, but the reality of day to day work is a different story. These tools lead to very rigid processes, where the tools are dictating how people work and interact. They solve larger business issues to an extent, but create significantly more issues than they solve by preventing change and hampering a team’s ability to handle special cases and needs that don’t fall within the standard guidelines of these tightly integrated tools.

What made you look into RoR?

As you start to push a statically typed language like C#, you start finding yourself writing more and more code that really has no purpose other than to support the type system.

To say this is frustrating is putting it mildly. Huge amounts of ‘redundant’ code like interfaces, casting, perverse dependency injection purely for testing

Ruby (and Rails) offered a chance to avoid writing all that code, and focus on real functionality.

Why did you switch over to RoR?

See above … although I haven’t switched – I just took a new position with a digital agency who are a strong .NET shop. I use Rails for my own stuff, and it is a welcome relief.

What do you like about it? What don’t you?

I love the simplicity. I love that convention over configuration is deeply ingrained into everything. I love that things ‘just work’. I love that it keeps out of my way, and lets me write code that has business value.

I love that testing is just what you do – not an optional afterthought.

I dislike, very little. The ‘worst’ part of Rails and Ruby generally is that without Intellisense you need good documentation or to know the conventions. Sometimes this documentation is weak or fragmented. Things like RelishApp make this a whole bunch simpler, and the community helps massively.

What do you miss from .NET? What don’t you?

What made you look into RoR?

Beyond the buzz, it was the migration of people whose opinions I respect telling me I needed to take a look. Having spent most of my career creating smart client applications I knew very little about web frameworks. The only web experience I had to speak of was WebForms and really that doesn’t count. So when I had a small volunteer web project for a local charity I decided to take a look at rails.

Why did you switch over to RoR?

My rails moment happened on the first night. I sat down to learn rails and in a few hours I created an application and had it hosted on Heroku for free. My mind was blown away. I didn’t need to spend time figuring out data migrations, test frameworks, hosting plans, etc. I immediately could focus on what I wanted to focus on… what I wanted my application to do.

What do you like about it? What don’t you?

Gems. I’ve saved hours of my time by searching for gems that can help deliver a feature before I just sat down and coded it myself. Why reinvent the wheel?

Another important part of the gems is they normally come with great documentation and cheat sheets. So I can gem install and in a short period of time get the gem performing the work I need. And if the documentation is lacking, I can just open the gem up and dive through the code myself.

What can be frustrating to others is the speed of upgrades with rails. Rails can move fast and if you have a Rails 2.0 application, finding help on the basics and tutorials can be difficult because the Internet has already moved on to Rails 3 or 3.1.

Although the speed is fast, the changes are great. When working with rails I often think, man why do I need to do X, shouldn’t rails do this for me? Then a few months later I see that the next version of rails will include those features.

This is a pleasant surprise from my .Net experience where often the upgrades would solve problems I wasn’t having. To quote Ricky Gervais, ‘the best non-solution to a problem that doesn’t exist’

What do you miss from .NET? What don’t you?

I loved C# so I miss that. I guess I should look into RubyMine more, but I do miss Resharper. I just need my refactoring goodness mixed into vim.

I don’t miss the culture. The never ending fights against architects and managers when trying to bring in tests, open-source tools, and agile practices. I lived with a crippling despair born from frustration. This lead to me being a complete ass. I didn’t like who I was and what I was doing.

Rails isn’t all rainbows and unicorns. I think the difference is the matching on culture and direction. Every new announcement from Microsoft always had me scratching my head going.. WTF?! I have more in common with the rails and ruby community. I understand the direction they are heading and feel the questions they are asking are the same questions I am asking myself. When is it right to test? When isn’t it? Where do we need opinions in our framework, and where don’t we?

And on that point, when I have a problem, I see people not only having the same problem but creating solutions! I can read their blogs, install gems, and find solutions. There is a contagious empowering culture of getting things done and continual self-improvement.

To me, the alt-net community always felt like a clique of people who didn’t feel at home in the normal Microsoft community. I don’t feel like I need to be in an alt-ruby community because I feel like I am part of the ruby community.

What made you look into RoR?

I had heard about both Ruby and Rails for a while before I decided to look into it more thoroughly. I had gone through the “Learn Ruby in 20 Minutes” that’s on the Ruby language’s homepage, and liked it. The conciseness of the language is what really got me excited. Still it took while (about a year or so) before I did anything in Ruby/Rails seriously.

Why did you switch over to RoR?

I switched over to Ruby on Rails because I had been doing .NET development in some form for close to a decade and I decided it was time to learn something new. The final leap was when my friend and I came up with the plan for Just for Bands. I didn’t really wanna do it in .NET (even using .NET MVC) mainly because I did .NET all day at work and really wanted to learn something new. The Just for Bands project gave me an excuse to build something from the ground up in a different language and framework, and let me bring my friend along for the ride.

What sold me on RoR was the community, gems, and the Ruby language itself.

What do you like about it? What don’t you?

I like the conciseness of Ruby. I like the “convention of configuration” aspect of Rails. It gives me less to think about when building applications. I also like how testing is so woven in to both the Ruby and Rails communities. Also, being a guy who likes Linux, Ruby and Rails work great in that environment. Using Linux tools to do my development, without having to install things like Cywin was huge. Using free and open source tools to me was just icing on the cake.

What I don’t like is the speed at which the community moves. As good a developer as I like to think I am, some things still take me a while to grasp and sometimes I feel that once I have a grasp on something it’s changed in the latest version. I also tend to dislike the egocentric stuff, more specifically the idea that if you’re not using a certain gem/tool/whatever that you’re doing it wrong (I saw a lot of this when interviewing for RoR jobs and using my JFB code as a “code resume”). That being said, it’s probably the tradeoff for being a part of a community that will actually try new things rather than stagnate.

What do you miss from .NET? What don’t you?

I don’t really miss anything, as I still do bits of .NET development at home and on my Mac using Mono. In fact, I’m giving a talk on cross platform development using Mono at Houston Techfest. While I do primarily Ruby, Objective-C (current employer wants an iPhone app), and non-.NET things I still like .NET.

Something that would be nice is a good IDE for doing Ruby/Rails development as that seems to be the biggest hurdle for .NET folks coming over to Ruby/Rails. The lack of a Visual Studio like IDE seems to case pain for some people, and as a dev tool Visual Studio is pretty good.

What made you look into RoR?

Working in a soul crushing corporate IT department really got me looking in a “less enterprisey” direction. Since I was enamored with the unit testing culture of software, Ruby and Rails seemed like the obvious direction to take.

Why did you switch over to RoR?

After attending my first Austin On Rails meeting I thought to myself, “These are my people; I have come home.” I mentally switched a year and a half ago when I thought about my future and realized that I could not think of a single .NET job that would have any appeal to me. I literally was able to switch because the job market is ridiculously good right now in Austin so the opportunities were available for developers with little or no Rails experience.

What do you like about it? What don’t you?

Switching from a GUI-centric development environment of Visual Studio tools to an extremely lightweight and mostly command-line focused environment has just been a breath of fresh air. Rails is truly is a framework that gets out of your way and allows you to get work done in a very low ceremony fashion. One difficult part is since getting a project going usually relies on a multitude of other “gems”, getting them all to work together is not always going to happen easily. I would also say that the culture of backwards comparability is definitely not as strong, which makes staying on an older version for too long a frightening prospect.

What do you miss from .NET? What don’t you?

I am a recent full-time convert so I am having great difficultly thinking of things that I miss. I obviously miss friends that I won’t be interacting with much anymore. I miss being able to show off techniques or .NET open source libraries to a crowd and see their minds get blown. I would also like to say that I really don’t miss intellisense and ReSharper as much as I anticipated. I don’t miss going to four user group meetings about Silverlight every year. I don’t miss being fed Microsoft’s new round of tools that look almost like the last round and are equally as unexciting. I don’t miss working with a technology where a majority of developers don’t think outside a tiny little box. I definitely do not missing working in Visual Studio or Windows on a daily basis.

What made you look into RoR?

From 2004, I started seeing a lot more Ruby showing up as the language of choice at the annual Agile conference, along with other smaller conferences. I would spend time pairing with people in it and really enjoyed it.

Why did you switch over to RoR?

In 2007, I was really getting fed up with the development experience in C#. I would spend time writing Ruby, then come back to C#, and it was like night and day with the flexibility. I had been doing pretty heavy test-driven development since 2004, and it felt like I was constantly fighting C#. I got tired of the compiler and the language screaming at me about things I would be getting to, such as unimplemented methods. Whenever I had a chance to work in Ruby, the experience was much more smooth. So, I decided to get out of that world. I was learning Ruby, so I took a few months and built a couple application in RoR. I then got approached to take a job at a startup doing RoR.

What do you like about it? What don’t you?

Among other things, I particularly like the innovation in the testing and tdd realms in the Ruby and Rails communities. There is a lot of discussion around different practices and techniques. I don’t really see the same level of discussion in other communities. I don’t agree with all the design idioms that are present in Ruby on Rails. However, I have recently started talking about alternate design approaches that are still compatible with using Rails and add more
maintainability options.

Power Developer – TestingUnit testing, Testing frameworks, Test Driven Development and Design and development considerations for testing.

Power Developer – SOLID PrinciplesIn this session, we break down the 5 principles of SOLID coding in terms of the code we’ve looked at this week and find out how these 5 principles can make you a better coder.

Power Developer – Patterns and PracticesInversion of Control, Containers, Composition and more Dependency injection, inversion of control containers and using them to improve the use of composition in our applications, as well as our testability story.

Power Developer – Presentation Patterns and Common Design PatternsIn addition to patterns like Model-View-ViewModel (MVVM) which we’ve already covered this week, we’ll look at how to recognize and implement other common patterns such as the factory, strategy, decorator, command, iterator, proxy and more, besides teaching Inversion of Control containers, as well as leveraging some C# features that facilitate the implementation of certain patterns.

Introduction to WPFThis session introduces the general concepts behind WPF and shows various examples that highlight the benefit of WPF over other UI approaches available. This session also introduces XAML (the markup language that drives most WPF and Silverlight UIs) and other core concepts.

Writing and Deploying WPF ApplicationsThis session shows how to build user interfaces “the right way”. This session starts with an introduction of various WPF UI Design tools (including Visual Studio and Expression Blend). The session then guides the attendee from a simplistic and conventional UI approach (as it is used by other UI environments, such as WinForms or HTML) to a more modern approach that takes advantage of the WPF paradigm.

WPF Layout and ControlsThis session continues the exploration of creating WPF UIs by taking a closer look at concepts such as data binding, automatic layout, view models, templates, and much more.

Fundamentals and New ConceptsThis session discusses various topics that have gone unexplained so far, including deployment options. This session also takes a look at topics such as 3D, graphics acceleration, graphics rendering (vector art), animations, a closer look at resource management, and much more.

WPF Business Applications – Parts 1 and 2Introducing general concepts for building business apps in WPF. This session provides a very brief review of WPF concepts and paradigms. However, the majority of this session is spent on creating a solution setup that works for real-world WPF projects. This includes not just the setup of the UI aspects, but also other elements such as view models and access to middle tiers or services. The session creates a real-world setup designed to accomodate business scenarios which involve typical data scenarios (handling of data in view models and also data binding in the UI). User interaction is discussed in detail as well.

Prototyping, Designing and Testing Business AppsShould we start developing from the database up, or from the user interface down? In this session we’ll tackle that question, and present an approach that works well when building business applications. We’ll go over prototyping, writing presentation logic from a TDD (Test-Driven Development) angle, waiting until the last responsible moment to implement a database, etc.

Rails enables developer to hit the ground running and create applications fast, even without knowing a lot of Rails or Ruby. We start the training by building a small application and get a quick feel for what’s coming.

Rails Overview

There are certain key aspects of Rails that developers need to know about, and this session covers most of them: Database Migrations, ActiveRecord, Routes, Models, Views, Controllers, etc.

Ruby Primer

After having experienced some Rails, it’s time to start understanding the language we use to build our applications, which is the same that the framework is built on: Ruby. Here we go over the language’s main constructs, as well as some of the features that enables some of the Rails magic.

Development Environment and setup

There isn’t a single ultimate setup for Rails development that everybody uses. There are certain common core things that need to be installed, and certain tools that are more popular than others. Here we learn how to get the minimal environment setup, and what a couple of the options available are.

Using Haml as the View Engine

The default view template system for Rails is Embedded Ruby (ERb). Other view engines can be used, though, and here we learn about one of them: Haml, which allows for cleaner views to be written.

Using a Document Database

Besides supporting relational databases, Rails also work well with document databases. Here we learn about one of them, Mongodb, and how to use it in a Rails application.

Automated Testing

Rails has been built from the ground up with testability in mind. It’s easy to test the code you write, and it’s easy to write tests that use Rails elements. Here we learn how to write our first tests for a Rails application, using two of the most popular “gems”: RSpec and Cucumber.

Behavior Driven Development

BDD is a development technique that improves the understand of the software being built by everybody involved. It improves planning of features and rids the project of unpleasant surprises due to erroneous expectations. Here we learn more about this practice and how certain tools used in Rails development can help us along the way.

Putting it all together – Parts I and II

We’ve seen an application quickly built on Rails, and covered several core aspects, tools, and practices of Rails development. Here we bring all this knowledge together into building another application, applying everything we’ve learned so far, and introducing a couple more things, such as user authentication and authorization, deploying the application to the cloud, and more.

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.

Open Source

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.

Gems

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

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.

SubSpec has certainly helped my experience with writing tests in .NET apps a lot. However, it is still running far behind Cucumber/RSpec.

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.

Source Control

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…).

Integrated Tooling

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.

Summing up

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.