Archives

#178 - jul 3rd 2016

Look

Examples of UI/UX, graphic performance, web design and flashy things.
Love filia design
Good demonstration of fast graphical animation with sound.

Use

Web applications, resources and tools, available for making our life easier or funnier.
HumanOps ops
HumanOps is a set of principles which focus on the human aspects of running infrastructure.

Install

A selection of gems or applications updated during past week.
Rails 5.0 jun 30 rb
Action Cable, API mode, and so much more. After six months of polish, four betas, and two release candidates, Rails 5.0 is finally done!
cells rb
View components for Ruby and Rails.
resugan rb
Simple event driven architecture framework.
income-tax rb
Ruby library to calculate the income tax for any country.
active_params rb
Automatic strong parameters by JSON config.
vsafe-ruby rb
Ruby API Library for Vesta's vSafe Payment Gateway.
Go kit go
A toolkit for microservices

Read

From the blogosphere or news feeds ...
Why is a BasicObject a Range? jun 26 rb
Fun with a ruby bug.
Automatically fetch your project’s dependencies with gb jun 26 go
Dependencies management is still a work in progress in Go.
A History of CSS Image Replacement jun 27 css3
Explore various image replacement techniques.
Blockchain’s Future after Bitcoin jun 27 web
Blockchain can be used for far more things than cash.
Add to Cart Interaction in CSS and jQuery jun 28 css3
A floating cart that slides in when the user decides to buy an item.
VersionEye goes open source jun 28 ops
VersionEye is a popular platform for software developers, which notifies you about out-dated dependencies.
Introducing the CSS text-align-last Property jun 29 css3
The text-align-last property specifies how either the last line of a block or the line right before a forced line break will be aligned.
Elixir’s Ecto Querying DSL: Beyond the Basics jun 29 el
Query composition, joins and associations, SQL fragment injection, explicit casting, and dynamic field access.
RSpec be_within matcher jun 29 rb
Explaination of less used be_within matcher in RSpec.
JavaScript Design Patterns: The Singleton jun 30 js
Write singletons by leveraging ES6 features, mainly modules and the new const variable declaration.
Browser Trends July 2016: Is a Chrome Monoculture Harmless? jul 1 web
Another update in browser trends from May to June.
Avoid Mutation – Functional Style In Ruby jul 3 rb
Incorporate functional programming concepts into Ruby code
Links curated by mose (publisher), xenor, tysliu (editors), xenor, nauman, mose, hsatac, james (contributors) .

Rant

The random rant of the week by mose.

Open code, a chance for improvement

Since I'm writing code I try to publish as much as I can as open source components. But I had occasion to work in situations where it was not possible. And I noticed some serious differences in the result.

When you publish some code on, say, Github, you can just throw it as is and be done with it. Then you merely use github as a repository provider and don't care much about anything else. But when you begin to spend some time doing it, you notice that external contributor can bring great fixes, help detect bugs, and generally speaking make your code more valuable in itself.

But this is a two-ways road. To invite people to collaborate you need to address a certain amount of little details. Writing a decently clear README is a demonstration of politeness for any passing guest. It's just more inviting. Making sure you have a complete enough test suite guarantees you can be sure external contributions won't mess up existing code (if writing tests in itself was not motivating enough). Refactoring your code by following codeclimate advises will break huge methods in small pieces, making things easier to be improved. Enforcing some kind of style guide will avoid people to get confused by a non-standard code-art. (that person could be you in one year).

All those aspects, when you work at a company as the only coder on one piece of code, you don't have that much incentive to enforce them. And I know about it because I have seen a huge lot of legacy code that was written that way. With lame tests that only purpose was to enforce code coverage without really testing much, weird code style, epic methods, no instructions. If it's just you and a couple of friends that you see every day, it's fine, you can deal with it. For a time.

The fact is that exposing your code brings an incentive to work on the (apparently) non-essential aspects of your code. But those aspects really bring a huge improvement on the long term. Which leads me to consider that opening source code is a way that can lead to make it better.

An usually, I noticed that the bosses don't care if it's open or not, as far as there is no trade secrets revealed. But well we write so much code that if business-neutral for many things. At the end of the day, it's only the matter of asking the boss if you can free this or that code, and then it's on its way. Even more if the code is published under an organization on github, there is even more incentive to make it clean, and it will also help possible candidates to understand what kind of stack you are dealing with, and what kind of principle you try to enforce. Even if it's actually only enforced in your open source code and the hidden code is messy. Haha.

So, I ask you now, what in your current codebase could you extract as an open source gem? or node package?

Green Ruby News is a feed of fresh links of the week about ruby, javascript, webdev, devops, collected by mose, xenor and tysliu every sunday.

Subscribe
to the
Green Ruby Weekly Newsletter

Email distribution is powered by mailchimp.