Closer look at the ruby scopes.

In any programming language understanding scopes is very important. Scope defines visibility for variables, methods, classes, objects, constants. I’m going to discuss how ruby defines scopes for methods. Most of the OO programming languages have three scopes for methods public, private and protected. Ruby also has public, private and protected scopes. I’m not going into the details of each scope. I’ll be discussing about how scope is defined for a method in ruby. 

Let’s take a look at the above code, looks simple enough to understand right. Good, now let’s see the following code.

Some of you must have left wondering What changed? Why private_method is accessible for Foo class? Looking at the code, for those whom ruby is not first OO programming language above behavior of ruby must be weird.

Most of the ruby developers comes from different OO programming language background, so they tend to ignore most of details about ruby language. We will see closely at ruby source code to understand how ruby defines scopes for methods. Let's start with what is private in ruby, is it a method or keyword or something else?

Let’s see.

private is a method defined on Module class which is super class of class Class. When you write private inside body of class(Most of know body of class is a executable code in ruby) ruby calls rb_mod_private method. Which internally calls following two methods if you call private without any parameters then vm_cref_set_visibility is called to set the visibility of rb_vm_cref(we'll discuss in detail). otherwise METHOD_ENTRY_VISI_SET this macro will be called to set the visibility of the method.

Let's follow the code for vm_cref_set_visibility method.

vm_cref_set_visibility function sets the scope visibility for rb_vm_cref(). rb_vm_cref() returns reference to the current object from the current control frame(we will discuss in detail about this in next blogpost).

Now we will see how ruby defines a method and sets the scope of the method.

When you define method in ruby with def keyword, vm_define_method is called. If you look at the signature of this method.

vm_define_method accepts a flag called is_singleton which decides whether to add method on signleton class of a class(often called eigenclass or virtual class) or add instance level methods.

When you define method in following way.

Ruby calls vm_define_method with is_singleton = false, which means define instance level method. Now in that case visibility of the method is retrieved from rb_scope_visibility_get function. rb_scope_visibility_get function which retrieves visibility from rb_vm_cref() which is a reference to the current object in current control frame as we discussed earlier.

But in case of of following code.

Ruby calls vm_define_method with is_singleton = true, which means add method on signleton class of a class(often called eigenclass or virtual class). Now in that case visibility of the method is set to METHOD_VISI_PUBLIC.

Now I hope you understand it better how ruby defines visibility for methods. Let's understand if you want to define visibility for eigenclass methods.

In above example of code, ruby will set scope in context of eigenclass which will be used to set visibility on methods defined for eigenclass.

Sumit is an engineer at C42 Engineering. If you liked this post, please consider...

/

Story Points: When Not To Use Them?

I am a big fan of points based estimates. I have learnt a lot about what processes, tools and practices work or don't work for my team using story points. Whether it's test coverage for a project, designer-developer overlap or just the number of times we have calls between teams every day; points based estimates gave us the insights to take informed decisions. I have been using it for the last 5 years and I still can't say that I have leveraged it's full potential. But would I suggest this to everyone in every possible scenario?

As it turns out, No. There are a lot of valid reasons why it may not work for your project. Let’s say you are a tech lead or a product owner about to start a project; how do you know if the points based estimates is best suited for your project? In this blogpost I will focus on the reasons why you should NOT use story points. You are better off with time based estimates, if any of the following is true.

You expect the project to get over in less than 2 to 3 months

Insights into your project's processes are gained by reflecting on the fluctuations in your weekly velocity. For a fluctuation to be meaningful, you first need to have consistent velocity over a statistically significant number of weeks; say 3. In my experience, for consistent velocity your team dynamics, testing processes, technology stack as well as product management need to be stable. None of this is going to happen in less than two months.

Also, the only way to learn something new about your product development processes is by conducting experiments. You need to change one aspect of how you execute your project and see the impact of that on velocity over another statistically significant time period; say another two weeks. If your project is going to get over in three months or less, you just don't have enough time to conduct even a single experiment, let alone benefit from it. You are better off estimating in chunks of half a day; it’s simple, faster and much less likely to confuse your business owner.

Your team is going through churn

A points based estimate is a function of how much complexity, effort and uncertainty your team perceives in a story (this statement alone deserves a blog post of it's own, but let's leave it for some other time). Any time a new person joins or an old one leaves or even when someone is replaced; your velocity is going change. If you are running any experiments in between, there is no way to tell how much of this change is due to the team's churn or due to the experiment. If your team is constantly going through churn, stick to time based estimate and get estimates from the people who are going to work on the stories.

Your team is going to have feature owners

If a developer is never exposed to a technology stack or a module, her estimates around that module or tech stack can't be used. If your project is going to have a developer who maintains the reporting module or have a developer that maintains the site's CSS; nobody else can estimate stories on those units. Now you don't have "a project's velocity", as you actually have multiple projects running in silos. Unless your modules are large enough to have their own teams and project management, you are better off with time based estimates.

You are always fire fighting

In fire fighting mode, people tend to work as much as they can rather than for consistent hours. The work gets done in spurts, often by cutting corners, rather than in a predictable routine. As we have no way of knowing how much of a velocity fluctuation was caused due to all nighters vs a process change, getting dependable data in such an environment is really difficult. Product owners/managers are also in constant pressure to exceed the developers' estimates, which means nobody really has the time or the inclination to reflect over processes.

Summary

Points based estimation requires time and patience  to slowly and steadily experiment over various aspects of your project's execution. Track data around story sizes, team compositions, QA cycles, defect rates, pair-programming, code quality, feature specifications details and endless other parameters. Reflect over the fluctuations every two weeks to understand which of these aspects changed and how it impacted your velocity. That is how we can improve the delivery throughput by 2% here and 5% there. Going for points based estimation without committing time for such activities is, in simple words, a sheer waste of time.

/

why choose AsciiDoc to write documentation

AsciiDoc is a human readable document format created using only plain text markup conventions. With the AsciiDoc tool chain, one can convert the document to any other famous representation format. These include - HTML5, PDF, DocBook, eBook, man page and even custom backends.

Why AsciiDoc?

  • With just AsciiDoc(no extra plugins), one can write a complete technical book as mentioned in the references section.
  • AsciiDoc supports some complex data representations. These include graphs and trees.

Live examples

Future
GitHub supports AsciiDoc and the Ruby implementation of the AsciiDoc called Asciidoctor is in use by the GitHub and is in constant development.

Conclusion
In simple terms, AsciiDoc is readable, concise, comprehensive, extensible and produces beautiful output.

I see no reason why one should not give AsciiDoc a try. On-boarding from markdown is very easy too.

References

/

Decoupling Software Components with Orthogonality

As a Software Developer, you need to add a new feature into a Web App you have been working on for quite a time now. To add that one feature, at how many places will you be required to make a change?

If the answer is more than one, Orthogonality is your solution.

So what is Orthogonality?

In mathematics, Orthogonality is the relation of two lines meeting at right angles to one another. For vectors, it means that they are independent. Moving along either of the two does not change your position projected onto the other.

In computing, Orthogonality is defined as software features which are mutually exclusive to one another.

Okay, can you give me some examples?

A database layer completely independent from the user interface of a Web Application is an example of an orthogonal system.

More so, your computer monitor has orthogonal controls. You can change the brightness independently of the contrast level, and (if the monitor has one) the color balance control will be independent of both. Imagine how much more difficult it would be to adjust a monitor on which the brightness knob affected the color balance: you’d have to compensate by tweaking the color balance every time after you changed the brightness.

How is this idea helpful in software?

Orthogonality lets you make complex programs manageable. When you need to make a change in a software program, it helps you to not be forced to keep the entire program in your head, but that one module or the class where the change needs to be made. After the change is made, the rest of the program just works fine. In a purely orthogonal design, each change in the program causes no ripple effects onto the other parts.

With the localization of changes, the code is easier to understand, document and reuse thus reducing the time for other developers to be able to contribute to the project.

I have a Big Codebase, how do I identify if it’s Orthogonal?

If you have the following in your project, it is highly likely to not be Orthogonal:

  • Thousands of classes where classes do more than they are meant to and the responsibilities of a class don't have a strong justification

  • Changes in one logically separate part of the codebase breaks something elsewhere

  • Same constants defined at multiple places

  • A lot of effort is involved in order to make a small change in the codebase

  • Lots of global data

  • Coupled code - modules share a lot of information with other modules

  • Similar functions

How to make Software Modules Orthogonal?

There is no one-shot answer, but if some design practices could be followed religiously, a codebase could be make orthogonal. To start with, one needs to make sure that there is no duplication in the system, and all modules expose data no more than that is required, hence ensuring that there is strictly one authoritative source of information. One must avoid the use of global data, since their values could be changed from any part of the system, hence increasing the the cohesion among multiple modules. Also, one of the best ways to improve orthogonality is to reduce software entropy as soon as any code smell is encountered.

/

Naming the return parameters!

Moving to Golang after using Ruby came with a host of surprises for me and one of them was the way you could return values from the functions. Multiple return values was definitely one of those wonders but here I will talk about named return parameters for the functions -yes, there is such a thing.

In Golang, we can explicitly state the name of the return object along with its type in the following way and just have a naked return that will automatically return this named-parameter: 

In the above example, we have not just specified that the function will return an int type but also that only the variable named nextPos is going to be returned - note that any named return parameter will be initialised to its zero-value automatically. We will discuss the merits of using named returned parameters in a while but first I want to point out something that might appear confusing.

What do you reckon the above function to return? Well, the answer is 5 because as long as the actual return value is of the same type as the named-return-parameter it becomes the value of the named-return-parameter nextPos. So then what is the point of naming the return types in advance?

One of the foremost uses is to assist in readability and documentation which all developers will swear by as one of the most essential features especially in a large codebase. Also, since functions in Golang can have multiple return and defer statements, if we use named return parameters, we won't have to change the return statements everywhere.

Interestingly, GNU C++ (one of the inspirations of Golang) also has this feature and using it actually results in performance improvements, for example:

The first function causes implicit call to copy constructor of MyClass (a constructor of the form MyClass(MyClass&)') is applied to obj which is causing unnecessary overheads. The call to a copy constructor is avoided in the second case and will be particularly useful if the classes are large. More can be read on the GNU C++ docs.

One cannot not overshadow the occurrence of shadowing (pun intended :P) when talking about returning named parameters. According to Godocs -

Shadowing: the result variable has been shadowed by another variable with the same name declared in an inner scope

Shadowing can be demonstrated with a trivial example: 

To avoid buggy code, the rejection will take place in the form of the compiler throwing an error and will have to be fixed manually.

What we can take away from this is that Golang gives us features to make our code better and more efficient but using them without a deep understanding of the edge cases could lead to some head-scratching surprises!

/