Love filia | |
Good demonstration of fast graphical animation with sound. |
HumanOps | |
HumanOps is a set of principles which focus on the human aspects of running infrastructure. |
Rails 5.0 | jun 30 |
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 | |
View components for Ruby and Rails. | |
resugan | |
Simple event driven architecture framework. | |
income-tax | |
Ruby library to calculate the income tax for any country. | |
active_params | |
Automatic strong parameters by JSON config. | |
vsafe-ruby | |
Ruby API Library for Vesta's vSafe Payment Gateway. | |
Go kit | |
A toolkit for microservices |
Why is a BasicObject a Range? | jun 26 |
Fun with a ruby bug. | |
Automatically fetch your project’s dependencies with gb | jun 26 |
Dependencies management is still a work in progress in Go. | |
A History of CSS Image Replacement | jun 27 |
Explore various image replacement techniques. | |
Blockchain’s Future after Bitcoin | jun 27 |
Blockchain can be used for far more things than cash. | |
Add to Cart Interaction in CSS and jQuery | jun 28 |
A floating cart that slides in when the user decides to buy an item. | |
VersionEye goes open source | jun 28 |
VersionEye is a popular platform for software developers, which notifies you about out-dated dependencies. | |
Introducing the CSS text-align-last Property | jun 29 |
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 |
Query composition, joins and associations, SQL fragment injection, explicit casting, and dynamic field access. | |
RSpec be_within matcher | jun 29 |
Explaination of less used be_within matcher in RSpec. | |
JavaScript Design Patterns: The Singleton | jun 30 |
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 |
Another update in browser trends from May to June. | |
Avoid Mutation – Functional Style In Ruby | jul 3 |
Incorporate functional programming concepts into Ruby code |
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?