Starting my journey with Volt

Let me start with a disclaimer that I'm new to the Volt framework. I probably get some things wrong. Don't rely on my opinions here :) The reason I'm blogging about it is to document my learning process. Also, by blogging I hope that dear readers will catch my mistakes and correct them in the comments. Thanks to that I'll learn more and can share a better knowledge in the future blog posts :)

I've played with Volt today. For those of you who don't know - Volt is a Ruby web framework. It's a bit unusual, as it's an isomorphic framework. The code is shared between the server and the client. It works in the browser thanks to the Opal - a ruby to javascript compiler (source to source). In a way, it's similar to Meteor.

Opal

I'm quite excited about Opal and the way it can influence the Ruby/Rails community. One year ago, I've recorded my suggestion/prediction that Opal can become the default JavaScript implementation in Rails apps. Here's the short (1 minutes) video of me science-fictioning about it, while walking in the forest near my home :)




I'm not following the Opal progress very closely, but from seeing what's possible in Volt, I feel quite confident about my last-year prediction.

I'll focus on Opal in another blog post. For now, let me come back to Volt.

The wow effect

I came to Rails very early, in 2004. It was due to the "wow effect". Being experienced with PHP, Java, ASP.NET it was amazing to see a result produced in such a short amount of time with so short codebase!

Over time, I learnt a lot about JavaScript frontends. Here is a 12-blog-posts summary of my lessons. I know what it takes to develop a nice Single Page Application (or however you prefer to call it).

This is the Volt wow effect. I'm old enough not be excited too easily with new shiny toys, but Volt does impress me. In almost no time, you've got a rich frontend, which works as you'd expect from a good JavaScript application - fast, interactive. You get the backend basically for free. It all autosyncs with the backend without any effort from your side. What's more, a new Volt app comes with authentication built-in for free.

Part of the wow effect is the fact that you don't need to run any database migrations to add new fields. It all relies on Mongo under the hood, so it's schema-less.

One of my roles is to be a Ruby/Rails teacher  / coach and I know how important it is to have a great "wow effect" for the students.

The developer happiness

Another thing that brought me to Rails was its developer oriented approach. The small things like console, like migrations (at that time it was huge), like seeing everything immediately on the screen without restarting the server. It was all there. It was all prepared to be very productive for the developer.

Volt is the same. There's lots of details that work very well. It's hard to mention them all. For me, it was great to see the browser with live reload out of the box. I change some Ruby code and it immediately pushes the code to the browser and the page is reloaded. I know there are more tools like that, but seeing it work with Ruby in the tool chain is just great.

The documentation

I followed the tutorial (try it, you'll get a better picture of it in 15 minutes, than from reading this post ;) ) and browsed through the documentation. All very precise, very simple. I didn't find any inconsistency with the actual behaviour.

The codebase

I only scanned some parts of the code and it seems like very well written code. I was curious how the "reactive DOM" thing works here. It was easy to find the right piece of code and understand how the "watching" works. When I browse the Rails codebase, I often feel lost as it depends on a lot of metaprogramming. I didn't feel the same here (yet).

BTW, yesterday I tried to run Opal with ReactJS but couldn't make it. There's probably no reason, why it wouldn't work, though, given more time. If you know anyone who did that successfully, I'd love to see the result :)

Components

I'm not experienced enough to see all the details, but I love the focus on components, from the beginning. Often, in Rails apps we think that some pieces may be extracted as an engine/component/module/gem *one day* and it rarely happens. Here, we're encouraged to do it from the beginning. The Volt components can be packaged as gems, which is quite interesting.

The architecture of a Volt app

As much as I'm impressed by Volt being a great framework for scaffolding/prototyping (maybe even better than Rails one day?), I also have some doubts.
A lot of my work in the last years was about decoupling legacy Rails applications. I wrote a book about Refactoring Rails apps and I keep collecting techniques which make it easier. Coupling is bad.

Is sharing the code between server and client a coupling? The answer to this question will be very important for me.

In a way, good decoupling may result in great reusability. There are applications, where the server role is simply to keep the data and to ensure basic authentication/authorisation rules. There are however also apps, where the server logic is much different from the client applications.

Is reusability the goal in itself? I don't think so. It's more of a nice side effect of good separation of concerns.

What's the Volt model of code reuse? At the moment, I'm not really prepared to answer this question easily. It seems to be, that at any moment, you can easily switch off the coupling, when required. That's a good sign. It's all Ruby under the hood, so we can do what we want.

Community

In case of frameworks, it's not always their authors vision, which drives how the apps are created. There's many good things in the Rails framework. Rails itself (nor the Rails core team) doesn't force you to write monolithic application - yet, that's what many people do. The main Volt author (Ryan Stout) seems to be very modularity-oriented. From what I see in the Gitter activities, this vision is shared by the early adopters. That's a good sign.

The future?

Arkency (my company) became experts in dealing with legacy Rails apps. We know how to decouple the app, step by step, in a safe manner. Are we going to become "legacy Volt apps experts" in 5 years from now? Time will tell... I have positive feelings about it. It's great to see new players in the Ruby community. There's no way it will become more popular than Rails, however competition is good. Volt is so different from Rails, that the Merb-case is not vere likely here ;)

I'm not recommending starting serious apps with Volt (yet). However, the framework is mature enough to be tried. In only 15 minutes you can build the Todo app from the tutorial. At least it will show you how the process of working can look, in the future and how different it is from your everyday flow.

As for me, I'm off to start another side-project with Volt now. Follow me on Twitter to see how it goes :)

From Rails to JavaScript frontends

I've collected a number of my blog posts, which together may help you in the transition from Rails to JavaScript (or CoffeeScript) frontends. Many of the posts are about the mental transition you need to make along the way, while other posts are more technical.

I think it's best to read them in the order I put it here, as they present the road I took over the last 5 years.

1. Rails is not MVC

2. Frontend is a separate application

3. From backend to frontend, a mental transition

4. Is CoffeeScript better than Ruby?

5. JavaScript frontends are like desktop applications

6. Frontend first

7. Non-framework approach to JavaScript applications

8. Angular or Ember? Congratulations, you've already won

9. Single Page Applications - fight

10. Turn a Rails controller into a Single Page Application

11. How can Rails react to the rise of JavaScript frameworks?

12. Which JavaScript framework should I choose? (video)

If you enjoyed reading the blog posts, you may consider following me on Twitter.

Which JavaScript framework should I use? (video)

Over the last 4-5 years, I keep being asked this question - Which JavaScript framework should I use?

2.5 years ago, I had a talk at the RuPy conference, where I'm trying to answer this question. I realised, I've never posted the video to my blog. 2.5 years is like a century in the IT world. Everything has changed, right? I believe that my answer is still correct and all what I said is still true.

Enjoy the 30 minutes of my lecture :)

Splitting a Rails controller

Splitting a controller into separate files may be a good idea in certain cases.

Let me start with the cases, when it's NOT a good idea. In case of a simple CRUD controller, this may be an overkill. The same applies to simple, scaffold-like controllers.

Some controllers are more resource-oriented - those may benefit from keeping the actions together in one file. People often use filters for reusing certain rules of accessing the resources here.

Other controllers may be more action-oriented (as opposed to resource-oriented). It's typical for the your-main-model-controllers. In those controllers, you will see more than the standard actions. They will contain interesting logic for 'update', 'create', 'destroy'. Those actions may have different logic. Often, they don't share that much.

The action-oriented controllers may benefit from splitting them into several files. I call them SingleActionControllers.

Please, note that the action-oriented controllers can contain a more complicated set of rules in the controller filters. Often, they create a full algebra of filters, where you need to find your way through the :except clauses and dependencies between filters. Refactoring those places requires a really precise way of working.

Apart from the filters problem, extracting a SingleActionController is easy and consists of the following steps:


1. A new route declaration above the previous (first wins)

post 'products' => 'create_product#create' 

resources :products, except: [:create]

2. Create an empty controller CreateProductController which inherits from the previous
3. Copy the action content to the new controller
4. Remove the action from the previous controller
5. Copy the filters/methods that are used by the action to the new controller
6. Make the new controller inherit from the ApplicationController
7. Change routes to add 'except: [:foo_action]'

You can also see a simple example of this refactoring here:

http://rails-refactoring.com/recipes/extract-single-action-controller-class/

TDDing a unit, not a class

Some time ago, I blogged about "Unit tests vs Class tests", where I described how it differs when you think of a unit more as a collection of classes instead of a single class.

How can we TDD such a unit?

This reddit thread triggered me to explain it a bit more. The title of the thread was interesting: "How does one TDD a user and session model?"

Such question is a good example, how the class tests seem to be the default in the "unit testing" thinking. Instead of asking how to TDD the Authentication unit, we're asked how to TDD some single classes - which often depend on each other.

Here is my response:

One way to do it is to think one level higher. Don't focus on the User and Session classes, but focus on the whole feature/module that you're building. In this case, that's probably Authentication, right?

Think of Authentication as a class, which is a facade. It's very likely, that you will come up with User and Session classes, sooner or later. They will be more like implementation details.

You probably need to implement functions like:

• register
• logging in
• logging out
• change_password
• change_email
• change_login
• remember_me
• delete_user

Together they can make nice stories. You can start with a simple test like:

def test_wrong_credentials_dont_authenticate 
  authentication = Authentication.new 
  authentication.register_user("user", "password") 
  assert_raises(WrongCredentials) { authentication.authenticate("user", "wrong password") } 
end 

(if you don't like exceptions, you can turn it into returning true/false instead)

One by one, you could build the whole feature this way, while being test-driven all the time.

In a Rails app, you will then use this Authentication object from the Rails controllers. This is also a good way of improving Rails controllers.

This approach is sometimes called top-down. You start with the expectation from the higher module (Authentication) and this drives you to implement the lower-level classes like User and Session.

Another approach is called bottom-up, where you start with the User and Session classes from the beginning and don't worry with the wrapping module, yet.

The different approaches may result in different tests. With the top-down approach you end up with module tests, while with bottom-up most likely you end up with a test per class.