petrjanda-blog

[petrjanda-blog]

Very nice insight into the Google way to embrace ambitious goals and ambitious employees.

[petrjanda-blog]

This is a challenge. You have one per position. List of assessments is chosen for a specific job, so once the candidate is ready, you know he is ready for the job. Invite as many as you can and compare their progress.

[petrjanda-blog]

First pieces of a dashboard for Tryve. Check it out http://www.tryveapp.com.

[petrjanda-blog]

4 Ways to get your Rails app slim and outsourceable - 1. part

Rails are great! They give you powerful tools to keep high productivity, which is so important for every startup competing with massive amount of other companies. Engineers have to hurry to build comprehensive feature sets to satisfy all the stakeholders which often ends up with pretty complex monolithic application.

Its valid way.

You have to hurry and there is no time for crafting perfect code as we dont know yet it would pay of. Things would change when your product gets stable, team grows and you search for ways to keep that high speed of development.

Natural outcome might be decision to split development into multiple projects in dev team, or even outsource specific components offshore.

Convey's law

Melvin Conway in 1968 introduced the idea of so called "Conway law":

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

This basically tells that architecture of your team correlates with architecture of your software. If you would like to split your team, you have to split your software as well.

Luckily, there is quite a few ways how to do it, each offering a different separation with its pros and cons. Lets take a look on 4 ways how to factor out code from your monolithic Rails:

4 Ways to extract

Gem

Gems are great mechanism to extract features for your overloaded Rails app in case you have cohesive set of objects, which are or could be separated from the rest of the application (and framework).

What works really well is to start gathering the classes, minimize their interaction with objects within your Rails app and gather them under a common namespace - you can get those files into lib/ folder (temporarily!). Once you're done with separation, create new gem and pull the code out of the Rails. This would force future developers to think in separated concerns, greater reducing the dependancies among system componets.

Start small, make sure creating, releasing gems and updating your bundles is really cheap (=automated) and bite one thing at a time from your app.

Start with logger, background jobs, email notifications - simple things, which can be abstracted and closed in a gem. Imagine the case you wanna switch the background jobs from delayed job to sidekiq. Team working on Rails app wouldn't even have to know (and adjust any code) when background jobs gem is updated.

Gems are perfect to separate your core domain model as well. At the end your domain should be framework agnostic, right?

Rails Engines

Rails engine can be understood as the plugin to your Rails application.

They are best suitable if you intend to slice piece of your application (or build new slice) from the database to UI. They contain its own models, views, controllers and also routes and dependancies.

There are two types of engine: full and mountable.

If you are building new cluster of features, which should integrate with rest of your application I would recommend to directly start a mountable engine. One of its benefits is that its better separated, which is enforced by its own namespace. It gets integrated to your Rails app as any other gem.

The full engine is not separated by a namespace (by default) so its more suitable in case you wanna extract existing feature set out of a monolithic app. I believe the extraction of code is already very challenging task, so less extra gymnastics you have to do is better. You can basically start by moving code around with minimum changes (ofc you first need to decouple cohesive set of code to pull).

Conclusions

Ok, i said 4 ways, but the post would be rather long. Let me sum up here and introduce the rest in follow up blog post, where we would discuss even further separation when application runs on its own server.

I didn't really find magical way how to make the Rails app smaller, but one thing is clear - it would pay off if you do it at the right time.

Monitor your process and find a good timing for it. Separation would bring certain level of overhead (releasing gems, managing versions, integration, ...), but at the same time more cohesive design where each system component limit interaction with others and therefore offer greater independence of your teams, which can then go faster.

[petrjanda-blog]

Ruby’s Functions

Ruby has four flavors of function, each with various nuances: methods, blocks, Procs, and lambdas.

A Simple Example

The object Array has a bunch of methods on it that take blocks. Normally, you write these blocks inline:

[1,2,3].map{|x| x+1} # → [2,3,4]

But what if you...

[petrjanda-blog]

We're in a world where hip creative directors are being positioned against ad monitoring technology that is able to create and serve the best-performing ad... regardless of how lacking it may be of creativity and a big idea.

http://www.twistimage.com/blog/archives/do-robots-make-better-marketers-than-humans/

[petrjanda-blog]

Code smells: Control couple

Detecting smells is just a first step. We can help with that in Sniffer. Taking an action is although your turn, because at the end its your code and you wanna get it cleaner and nicer. This is the first post in serie about code smells. I would like to reason about how they look like and how to clean them. Lets get started. First one is Control Couple. ### How does it look like > Control couple happens if your method code, check for a parameter value to decide the execution path. Lets take a look at very simple example. class PersonGreeting def initialize(name) @name = name end def greet(shout = false) if shout puts "Hi, #{@name.upcase}!" else puts "Hi, #{@name}!" end end end PersonGreeting.new('Petr').greet(false) #= "Hi, Petr!" PersonGreeting.new('Petr').greet(true) #= "Hi, PETR!" Its obvious that client code already knows if he wanna shout or not. Passing the controlling parameter makes your code less flexible and more complex. Complexity grows because you have code branching with *if* statement. In more complex examples and in cases when even more control couple variables are passed it might lead to *if/else* maze. Its basically violation of SRP (Single Responsibility Principle) because your code would do more then one thing. Flexibility is lost, because any change in control couple parameter needs to be reflected on both sides of the call. Not an ideal case at all. Lets get rid of it. ### Cleaning up Lets continue with our simple example and refactor code to: class PersonGreeting def initialize(name) @name = name end def greet "Hi, #{@name}!" end def greet_shouting "Hi, #{@name.upcase}!" end end PersonGreeting.new('Petr').greet #= "Hi, Petr!" PersonGreeting.new('Petr').greet_shouting #= "Hi, PETR!" Well thats better. You can see PersonGreeting methods got simple and none of them does two different things. In this case it might be enough, but I would like to consider one further refactor: class PersonGreeting def initialize(name) @name = name end def greet "Hi, #{@name}!" end end class PersonShoutGreeting < PersonGreeting def greet "Hi, #{@name.upcase}!" end end PersonGreeting.new('Petr').greet #= "Hi, Petr!" PersonShoutGreeting.new('Petr').greet #= "Hi, PETR!" This is a simple example of strategy pattern. We have created base class with default behavior and inherited the concrete shouting implementation. In this case we even leveraged SRP from method level to class level, which means, each class is really doing just a single thing. In this stage we got a way better flexibility. We can introduce all bunch of new *Greeting* objects like *PersonPoliteGreeting* or *PersonFriendlyGreeting*. Each of them become just another strategy to our greeting mechanism. Their implementation would be very simple and client code can directly choose one of them to be used. ### Conclusion Keep your objects simple. Take care each method does just a single thing. Same applies to classes. Each class should have just single responsibility. Of course, definition of responsibility should be flexible to your project. Using the *if/else* statements might be the good lead. Its sign that your code is starting to do two different things. As responsibility of that object grows, it would be probably good idea to split it. Strategy pattern might do the best job for you, in case different if branches choose different ways to handle the similar thing.

[petrjanda-blog]

Good (Rails) architecture

I clearly remember my first Rails application years ago. Plenty of scaffolding, bunch of methods in models and tuned HTML templates. It worked. Of course, for building something real and complex it wouldn't work at all. If you grow such a project, you would end up with highly coupled domain logic and framework specific code. As side effect complexity of objects is high, tests are very slow and domain code is unclear as a result of many compromises done to "fit" domain model to the framework code. That all slows project down and ultimately kills productivity. ### Coupling domain and web framework code Rails MVC is just a basic layering. On top of that, having "fat models and thin controllers" was the first step, which allowed the controller to become clear (handle request, call some models methods, prepare and render views). Models became too "fat", though. At start I approached this situation by extracting models from the class and including those back. Its of course false refactoring and only outcome is that all the mess is splited in multiple pieces. One of the biggest problems is the lack of clear [separation of major concerns](http://en.wikipedia.org/wiki/Separation_of_concerns) in the application. Typical complex system has plenty of domain objects and many use cases, which manipulate objects in a given workflow. At the end results are stored in the database. Most of this responsibility gathers in models and violates [SRP (Single Responsibility Principle)](http://en.wikipedia.org/wiki/Single_responsibility_principle). Processes are not clear, because they are not explicit. Such an app had well normalized database tables and correct set of primary and foreign keys in database, although the domain code just roughly represented the real world model. A lot of key details and objects were missing. Its price of designing the code around Rails models. Extracting bunch of modules would barely help. ###The right way When I started to build Sniffer I wanted to do things right so I wouldn't get into troubles in later stage when project grows. I did 3 major decisions about system code: * Domain would be written in plain ruby * Focus on domain code, having all the other concerns as secondary * Minimize the interaction between domain and database or web framework The high level view would look like this:  Domain is clearly separated from the rest of codebase. All the services (use cases), domain models, value objects and any other domain specific code is there. Rails models are left with just single responsibility. Persist data into database. Those turned out to be incredibly important. Lets discuss couple of benefits I got from it and a bit insight why. **Low coupling**. Object oriented programming was invented to represent user mental model of the problem. It can barely be done though, if you need to do compromises here and there about how to write a code. Having your domain in pure Ruby allows you do it right. The outcome is minimal coupling between domain code and web framework / database system. All the domain concerns are explicit, thus code is better readable. **Flexibility**. As you develop your code without any concrete framework in mind, you are free to choose any of them later. Even if you go for one and wanna switch to other, it should be possible without affecting your domain code at all. The same goes for the database system. If you have clear abstraction and API between domain and ORM or database driver, it becomes fairly trivial to switch. In case of sniffer I did try CouchBase, Redis, Riak and ended up with CouchDB. I had pretty simple persistency abstraction with bunch of functions to store hash or array. Implementing it in different databases was matter of hours. It can barely be done in case domain would contain ORM code directly. *Note: You can say well this is not really performant. Thats true. Although plenty of optimizations can be done in any stage of project. But I can decide that later comfortably.* **Fast spec suite**. Domain specs are blazingly fast. Because of persistancy abstraction I was able to create in memory database storage, which is used for most of the specs - I dont really wanna test that database works for each domain spec. There is special test for that. Instead I have few hundreds of specs running in seconds. No database is started, no framework is started, just plain Ruby. **Clear domain model**. One of the biggest benefit I see is that domain model really closely represents the real world. Having the domain as the primary focus in code allowed me to create right classes, more naturally. As outcome, if the model represents world precisely it fits into user head, so implementing new features would be way easier. You would see new features can be done easier without need for significant refactoring. Using rails scaffolding, which heavily focuses on persistency it would be way harder to have a right domain model. Keep in mind that domain model and Rails model are not the same thing. ### Conclusion In last year I’ve studies a lot about software systems architecture, mainly from guys like Martin Fowler, James Coplien, Uncle Bob Martin or Erich Evans. They talk about separating changing things code from stable one. Separating behaviour of application from the domain itself. To separate domain from the frameworks and database or to let domain be the core of your codebase. Each has a bit different way to say a very common thing: > Focus on your use cases and craft them explicitly in domain code. Keep the domain code as most important and well separated from the rest of the world. Everything else is secondary. After coding few months, following this way I really believe its the way to craft stable and maintainable code.

[petrjanda-blog]

Code reviews and analysers

I am very happy that most of the Ruby programmers are used to write tests for their code. As Ruby is very dynamic language having tests is crucial to be sure code works. For me it was a good start although I wanted to get other techniques working to get code even better. ### Introducing code reviews In our team after making sure everyone writes the tests, we started to do a code reviews. Idea is simple. Each new code going to be released is reviewed at least by one more person before it ever get to production. Using Github, we leveraged its pull requests. Each new feature is branched aside and when the code is ready we pull request back to main stream. In a review we go through the code scouting for mistakes, code smells and possible improvements. We reason about code until author and reviewer agree. It was a great step for us, which improved quality significantly. When searching the code I have found two major kind of problems: conceptual and technical. *Conceptual problem* is in my eyes about inaccurate design. It might be some class having too much responsibility, some object not being really clear in purpose or too complex solution for something what could have been done easier way. Those are the major issues and need a tight cooperation and redesign by author and reviewer. Ideally those problems would be revealed as soon as possible. For that reason we open pull requests very soon. Even after few commits. Team can already see how the development goes and feedback loop gets way shorter. *Technical problems* are minor compared with conceptual ones. Its for instance using the controller instance variable in Rails partial or having some duplicate code which can be dried. In general many OOP smells falls to this category as well - data clumps, control variables, complex methods etc. Those are relatively easy to fix as soon as author is aware of them. ### Automating reviews? As I did many code reviews in last years I saw that quite a lot of problems were repetitive, done by overlooking something more then on purpose. In some cases they were overlooked by reviewer too and had to be cleaned later. I thought about ways how this can be automated. In the summer I got pretty clear idea of what we want to detect and how it should be presented. Thats when [Sniffer](http://sniffer.io), ruby code analyser was born. In today version, it detects many code smells and is useful helper in the code review process. So when I do the code review it let me focus on conceptual problems and detects the simple smells and problems easily. ### Why should I care? I think fixing conceptual problems is not arguable. Everyone should do that so the code is well crafted, clean and readable. Fixing minor issues might look unimportant, something what can be deferred for later. Instead I believe you should be fixing them as soon as possible. Because they are small they tend to gather and slowly poison your codebase. Fixing them right at the inception would help your codebase significantly in long run. Each cleared smell improves the code and allows you to see even more possible optimizations which can be done. Its like a chain where the clean and nice code is at the end. Thats worth the caring.

[petrjanda-blog]

In a good company, best ideas have to win. Disregarding the speaker position and rest of politics.

[petrjanda-blog]

First draft of the history chart for your project. Now you can easily see, how is your project doing in long run. Each red point represents commit which got things worse, each green point is commit which got code better. Commits not affecting your total severity are not displayed at all. Bellow graph there is list of appropriate commits. Newest is on top.

[petrjanda-blog]

If you know GitHub you probably know they do great products. Currently you are able to find best people around the world grouped under their roof. You might be asking how did they manage that?

Reading blog post about their hiring process, I got just little bit of insight into GitHub, yet convincing me they truly have to be amazing company, where people are valued more then products as the core of the company culture. I am not surprised they attract best of the best. Respectful way.

[petrjanda-blog]

Sniffer analyse itself again (muhehe). Improving the project dashboard, so it would be clear how each commit affected the score. _See the cleanup commit did pretty good job._ We have a nice plans with this screen. Think about branch graph (as git or github have) where you see your branches and score for each. You can easily follow if branch gets code better or worse, so no surprises when its back in master! :) https://sniffer.io/

[petrjanda-blog]

Awesome! Facebook made a great job, designing Claspin, their server monitoring tool. On one screen they are able to see status of thousands servers, which allowed them to quicker spot the problems and fix the real problems in inception phase. Imagine, if we do this with your code base. Lets say there is a "map" showing you how your compliexity / smells evolve in time for your project, for any of its module, for any of its class. Would that allow you, to find out something is going wrong and fix it? We plan to introduce this in Sniffer.

[petrjanda-blog]

Behavior-oriented Rails (architecture)

Rails is super awesome for project bootstrapping. Everything goes fast, new resources are added in a glance and project grows. This might work through the lifetime of many projects, especially if domain is not really complex. ### Processes would get things messy If you see though, your app runs a lot of processes (process = sequence of tasks to be executed together. "Start a project" might create project itself, owner, notify admins, send email to owner, etc.). You can either put processes logic to controller (which would place too much responsibility there) or perhaps use active record callbacks where create of one resource trigger creation of other. Something like: class Project < ActiveRecord::Base after_create :create_user, :notify_administrators ... def create_owner User.create!(...) end def notify_administrators CustomNotifier.project_created_notification(...).deliver end end class User < ActiveRecord::Base after_create :send_confirmation_email ... def send_confirmation_email CustomNotifier.user_created_notification(...).deliver end end You've probably see such a code before. This might look innocent at start, although can grow into nightmare. Problem is it would get extremely hard to follow how the process looks like if it gets complex. It just grows into huge hunting problem. ### Bring in the services Whatever you would call it, either service, use case or any other, you would need a new first class cititzen in your codebase. Service defines the process as its single responsibility. It wouldn't do anything else, just make it explicit. Code might look like this: class CreateProjectService def initialize(dto) create_project create_owner notify_owner notify_administrators end private ... end So initializer very cleanly describe the process where each line call its private method implementing piece of it. So you create project, then owner, then send notification. Pretty easy to read. You might be wondering what the dto is here. ### DTO - concept helping separating views and models In my opinion one of the big problems is that Rails forms use model validations. It's again very helpful for beginners and for prototyping, although it couple your forms to the models structure, so if you want form to be more use case oriented, you would end up hacking your code. So thats why I introduced DTO (data transfer object). It is designed for specific form, responsible to collect and validate the data (includes the ActiveSupport::Validations module). class DTO include ActiveModel::Validations def initialize(attributes = {}) attributes.each_pair do |key, value| self.send("#{key.to_sym}=", value) end end end class CreateProjectDTO < DTO attr_accessor :project_name, :owner_name, :owner_email validates :project_name, :owner_name, :owner_email, :presence => true end DTO is created in controller and filled in from params. If its valid it calls the service, else form is rendered again with errors (from DTO): class ProjectsController < ApplicationController ... def create dto = CreateProjectDTO.new(params[:project]) if dto.valid? CreateProjectService.new(dto) redirect projects_path else render :new end end end ### Architecture So here is how it looks like from architecture point.  1. HTTP request comes to your server, ending in controller 2. Controller instantiate DTO and validas it. Render form with errors if any or call service if DTO is valid 3. Service instantiate domain entities (models) calls their methods accordingly (as defined in process) 4. Each entity persists its own status 5. Service doesn't return any value, it just throws an exception in case of error. Remember the error shouldn't happen here since controller already validated the user input. The exception here might mean some more serious issue (or concurrency problem). Return-less services are something very important. If you do this, nothing prevents you to plugin the queue between controller and service, which mean service can be executed inside a worker, thus separated from your webserver. Reading is quite ok to be done the standard way. ### Conclusion This is not for everyone. Small (maybe medium) sized projects would be pretty good with standard Rails way, without any detour. I think though, Rails doesn't support you in case you wanna build enterprise process oriented application and I've learned architecture above can be the way forward.

[petrjanda-blog]

Ideas have *no* value

Garett Dimon's presentation on "Bootstrapping a software product" has plenty of brilliant points. I would recommend going through to anyone starting / running product-based business. One of slides, to dont worry about sharing ideas, I've found especially good. I talk with people openly about the ideas I have. Its fastest way to get the feedback. Yet many people ask me the question "Aren't you affraid some guy will steal it?". I always answer "no". Ideas are over-valuated. There are trillions of ideas yet way less running businesses. Turns out the skill to turn idea to running business is extremely hard. You will need skills, lot of passion, focus and plenty of other things, nobody can steal from you. So don't be afraid to share.

[petrjanda-blog]

Do you love what you do as we do? Steve Jobs explains why you should.