Serious Technobabble

Implementation Inheritance Last

Tue, 24 May 2016 00:00:00 -0500

TL;DR:

When designing, consider class composition and delegation BEFORE extending or designing classes for extension. Extension is less reusable and less maintainable. Don’t be very “clever”.

A bit longer:

Implementation inheritance is often not the best pattern to reuse code or make code reusable.

Implementation inheritance breaks encapsulation and forces us to peek at the parent implementation to be able to inherit from it safely, the interface of the base class is not a safe contract to extend on.

Inheritance is the tightest form of code coupling. It is especially dangerous in Ruby when mixed with concerns out of sight, mixins, and the fact that Ruby does not have a ‘final’ or ‘sealed’ mechanism to prevent unsafe inheritance.

More often than not, it is better to compose or delegate rather to extend, especially when there is no clear and orthodox inheritance pattern (template method, strategy, etc.) It is often impossible to get inheritance right when adding features to existing code that does not follow OCP, not to mention trying to reuse these bits afterwards! Impossible.

Composition is normally accomplished by DI through the constructor in the object that needs the behavior. DI in the Ruby world is kind of a controversial thing, mainly because of people misread and missquote @dhh. That aside, let’s just refrain from further designing “clever” inheritance-first designs. Even hardcoding dependencies in a service is a better way! (but you better not http://goo.gl/tLMGGb)

The Shapes of Bad Code, Part 2

Wed, 28 Jan 2015 00:00:00 -0600

I have noticed that when looking at some not-so-awesome piece of code for the first time, I can tell many things about it even before putting my glasses on, and while scrolling at a speed at which it is actually impossible to read anything at all.

This is Part 2, check out Part 1!

The Shape of Bad Code, Part 2

Abuse of vertical spaces

The single-responsibility principle applies at many levels, and it definitely does at a method level. When a method does more than one thing but has not been split in separated methods, it is common to see vertical spaces separating this different functions. If you need to add vertical space to understand the body of a method, wouldn’t it be better to extract that second section as a separated method and give it a good name?

Comment-delimited sections

This is a somewhat improved version of the previous shape. Each section is separated by vertical space, but comments have been added at the start of each section to try to make the reader’s life easier.

Again, more often than not, this sections can be extracted into several methods, and those comments can be transformed into the names of the extracted methods. If there where many sections to extract, it is also probable that these methods actually belong to a new class!

Stay tuned for the last ugly code shapes!

I will never work for you

Fri, 02 Jan 2015 00:00:00 -0600

There are a couple of industry sectors that I would rather not write software for, ever. The most important ones are:

Weapons, Military & Defense
Most Coal, Oil & Gas
Financial Services
High Speed Trading
Investment Banking
Most Adult Entertainment
Casinos & Gambling
Most Health Insurance
Digital Rights Management
Religious Organizations

There are many others, the common denominator being that I do not believe these activities have a positive impact in our society.

Invitation

I make this list public as an invitation to you, software developer, to examine the social and ethical consequences of our professional activity.

It is undeniable that programmers have an increasing impact in our world through the software we write. If our only concern is doing our job right but we not mind about the consequences of what do, we risk becoming mercenaries.

At any point I suggest that my list is universal, different persons have different thresholds and sensibilities. It is nonetheless important that you ask yourself whether you are being consistent with your own values and principles, and perhaps, make your own list.

Dear recruiter

Wed, 31 Dec 2014 00:00:00 -0600

I am not actively looking for a new job at the moment. Nonetheless, thank you very much for thinking about me for a position, or offering your help with my professional career.

I am always open for new opportunities, and it is always good to keep an eye on our industry’s needs. I receive many requests or proposals like yours every week. Unfortunately, I could not possibly answer them all personally. That is why I have created this page on my site, I hope you do not mind.

Even if I were actively searching for a new challenge, there are a couple of things I need to know upfront, before actually considering it. Because this is non-negotiable, I do not deal with external recruiters, headhunters or employment agencies of any sort. Understandably, they cannot provide this information. I am sorry if that is your case.

The list may seem a bit extensive, but after all, these are basic things I would look for if I was applying for a position myself.

Basic company details

Mission, vision, purpose, market/customers.
The company founders, key people, who they are & what drives them.

Is there a dev team already?

Who are the key team members
What have they done?
What are their team practices and values?

Furthermore, if you are an internal recruiter or HR person and can actually point or link to this essential information, note that there are a couple of industries and markets I rather not write software for, ever. See the list in this post.

Thanks for understanding!

My CV

My LinkedIn profile is complete and updated. You can easily export a PDF from it if you need it. There is also more information about me in this page

Contact me

If you have further questions, you can mail me at istepaniuk@ Google’s well known free email service.

The Shapes of Bad Code, Part 1

Mon, 29 Dec 2014 00:00:00 -0600

– “Oh my god, look at this code!”

The Shape of Bad Code

So what is that I see? The only thing you can see while scrolling that fast and squinting is shapes, the shapes formed by different blocks of text filling the screen, plus the colors of your syntax highlighting.

So I decided to make some screenshots of my text editor to illustrate some of these bad code shapes, and I will write a post for two of these at a time. I also distorted the images to make sure we are not actually reading this code.

Code Duplication

This is probably the best example so it goes first. This is JavaScript, but that is completely irrelevant in this case. This image shows two near-identical functions, both fit the screen and what’s going on is quite obvious. Sometimes a few scroll up & down movements are required to reveal a block of code that has been mercilessly copy-pasted, even more than once. I will not tell you why having duplicated code is bad, you probably learned that the first time you write a program with more than 30 lines.

This duplication was probably introduced because it would have taken 120 more seconds to understand the original functionality and modify the existing code accordingly. Of course, it will now take 10 minutes to revert the damage, or even more if the different copies started to diverge.

Too Many Dependencies

This is Python code, but the same shape is valid for any other language that requires you to declare the dependencies before using them, and that would be most of them.

We do not know what is that this piece of code does, but there is something I can be sure of; There is practically no way that a this file/module/class is doing only one thing.

If it needs this all these import statements, the single responsibility principle is clearly not being observed. If the file/module had many smaller classes with different dependencies each, it’s also time to split this file into smaller ones, as almost every reason to observe SRP in classes and methods also applies for entities at the file (or module, package, assembly, etc.) level.

More ugly code shapes!

Check out Part 2, and also Part 3

Something Is Terribly Wrong with Wordpress

Sun, 28 Dec 2014 00:00:00 -0600

WARNING: This is just a rant, probably you should not read it.

This 2014 was a year of many changes, new company, new country, new house, all excellent excuses to stop writting posts! Lately, for these and other reasons I was not finding a lot of oportunities to write here. To make it even worse, every time I logged into my wordpress admin interface to write a draft or post, I remembered how hard Wordpress sucks. Really.

Some years ago I decided to start blogging and went with Wordpress. It was the obvious choice, popular, and very easy to install and use. The problem is that what you get from Wordpress out of the box is not good enough, at least if you are anywhere close to serious about it.

As soon as you go online the spam will start pouring down. The built-in comment system can drive you crazy when you have 1 real comment for every 5000, but that’s easy, just spend half a day trying plugins until you find the one that does not cost you an eye and actually filters something.

The same goes for social buttons, analytics, your twitter card, ~~google authorship~~,… Plugin magic!. Do you want to add some code snippets to your posts? No problem, 3 or 4 plugins latter you will find something that does not completely destroy the theme or brings the whole server down.

Wordpress releases updates quite often, but many of those installed plugins will start failing with even minor version upgrades, not only because they are hacky (some really are, even the popular ones) but because everything seems to be so tightly coupled to the Wordpress core that they shouldn’t be called plugins but grafts. Good luck trying to keep all those updated. 17 in my case.

All these hacks slow down your site, but don’t worry, there is a cache plugin to solve that! there is even a plugin to make Wordpress secure enough (WTF!) so your hosting provider does not shut you down when some script tries to brute-force your admin credentials, or when spammers bring your site to it’s knees.

Back to square one

With all those hacks, the site can respond reasonably fast for the public, but that doesn’t make the admin interface any faster, specially if you are on a cheap hosting provider. Bet your bottom dollar that any support ticket about Wordpress performance is going to contain “disable all the plugins” in the very first answer.

Questions

Given that:

I have less than 200KB of written content.
I have less than 4MB of pictures.
The site gets an average of 100 daily sessions with only 1.2 views per sessions.
It has very, very ocasional traffic bursts.

Then:

Why do I need all these plugins?
A cache plugin? Why isn’t it just fast enough for this?
A security plugin? Why isn’t it secure enough?
Why is that the built-in comment system is not practical, even for a small site?
Why do I need a full-fledged RDBMS to power a simple blog?

I just want to write some stuff, it shouldn’t be so damn complicated.

The solution

If you are not a developer or sysadmin or you would rather spend your time blogging and not dealing with this nightmare, get somebody to manage your Wordpress for you, or get a paid wordpress.com account, or a ghost.org one, etc. Running it yourself is an incredible waste of time.

If you ARE a developer or sysadmin wanting to run a tech blog, there is a solution! it’s called Jekyll and I will tell about it very soon!

Linux Counter

Sat, 15 Feb 2014 00:00:00 -0600

I just remembered I have one of these, and look! It still works!

Soon it’s going to be 15 years since I started using Linux, time flies.

Just installed Ghost on Heroku!

Sun, 17 Nov 2013 00:00:00 -0600

Check it out! (And you can continue reading there, it is a copy of this post)

I was looking for alternatives to WordPress for my blog, I wanted it to be:

Opengraph compatible
Good SEO support
Markdown based
Fast

In my search, I’ve found Ghost, it was REALLY fast on my old laptop and It seemed like a nice oportunity to give Heroku a try.

I always liked the heroku concept, and my current hosting does not support Node.JS anyway (though it does suport Python and Ruby!)

Editing text on Ghost is just awesome! Writting in markdown with side-by-side instant preview, is just awesome. Check it out at their site, or watch the video.

Ghost is free and open source, they also plan to have their own hosting service, similar to wordpress.org, I guess.

Asking for trouble

I had to crazy-patch Ghost to make it work on Postgres as this database is not yet supported. It comes with SQLite as default and besides that, it only supports MySQL officially.

It is not a good idea to run Ghost on a free Heroku account, as MySQL is not available and your uploaded images will be erased by the Heroku’s ephimerous filesystem.

In any case, Ghost is probably my next blogging platform.

What Is Enterprise Software?

Sun, 29 Sep 2013 00:00:00 -0500

Big IT vendors market their products as “enterprise ready”, basically meaning “ready to rip you off”. This, and other misuses of the term explain why using the word “enterprise” to describe a piece of software triggers horrified looks and trying-not-to-vomit faces. The intertubes have excellent definitions for what Enterprise Software is, but it seems there is place for yet another answer to this question.

Not so surprisingly, in the first pages of Martin Fowler’s Patterns of Enterprise Application Architecture, there is a good definition of what Enterprise Software is, and what isn’t.

“Enterprise applications are about the display, manipulation, and storage of large amounts of often complex data and the support or automation of business processes with that data.” -Martin Fowler

Fowler’s book also gives some examples of what is not Enterprise Software:* “Automobile fuel injection, word processors, elevator controllers, chemical plant controllers, telephone switches, operating systems, compilers and games”*

The English Wikipedia has a fairly good article on what Enterprise Software means:

“Enterprise software, is purposed-designed computer software used in the furtherance of the needs and objectives of the organizations; such purposes can vary widely as in a business, schools, interest-based user groups and clubs, retailers, or government, as opposed to software used by individuals.” (from the English Wikipedia)

So, next time you hear “Enterprise Software”, try not to think about the dark side, let’s recover the term.

This image copyright is owned by ThinkGeek, it is used here to represent and link to their product.
This site has no affiliation with ThinkGeek whatsoever.

Conferencia Agile Spain 2013

Mon, 09 Sep 2013 00:00:00 -0500

I will be speaking at this year’s CAS, the most important Agile conference in Spain, held yearly in a different city each time: http://conferencia2013.agile-spain.org/

My talk title will be “Effective Pair Programming“. The idea with the title (besides not being very original) is to emphasize that it won’t be yet another pair programming evangelism talk, but rather a talk about improving the way developers pair, targeted at those who failed, are struggling with, or want to improve their pair programming skills.

Below is the talk abstract/proposal. See you in Bilbao!

Effective Pair Programming

Pair programming is a central element in Extreme Programming (XP) and its correct practice dramatically improves software quality. The technique is however quite difficult to master, and not doing it properly will not only be frustrating for the developers but also a waste of the company resources. This talk introduces different approaches to the technique and shows the audience how to avoid the common pitfalls that developers will encounter in their path to effective pair programming.

In this presentation, I will cover the principles underneath the technique’s productivity gains and why it increases the amount of error-free code over solo programming without spending more resources. I will also show how its practice reduces the team bus factor, and how pair rotation distributes information, effectively eliminating knowledge islands in the team.

Different developers have different experience levels and personalities. I will talk about different combinations and how to overcome these mismatches to enable the pair to become greater than the sum of its parts, thus producing software of greater quality and maintainability. I will cover the classical XP driver/navigator roles but also tag-teams and less formal approaches.

Pair programming is a challenging practice, and though it is not a novelty, it is still surrounded by many misconceptions. I will step through DO’s and DON’ts based on both documented and my own grounded experience on the topic, how it tightly fits other agile development practices such as Test Driven Development, and what to expect when introducing this technique in a team.

Link to the proposal on IdeaScale