#186 - aug 28th 2016


Examples of UI/UX, graphic performance, web design and flashy things.
Femme Fatale Studio design
french creative studio, somewhere between sophistication and simplicity


Web applications, resources and tools, available for making our life easier or funnier.
cube composer tool
Funny tiny game calling array manipulation logics.
Managing Operations in Group Chat ops
(book) ChatOps can increase your operational efficiency. Learn how in this free 75 page report from O'Reilly and VictorOps.
Essential Electron js
Quickstart your electron skills.
Itsy-bitsy-data-structures js
All the things you didn't know you wanted to know about data structures
Maintainers-wanted tool
List of projects looking for new lead maintainers, either abandoned or just looking for someone else to lead.


A selection of gems or applications updated during past week.
Client_side_validations rb
Client Side Validations made easy for Ruby on Rails
Vizceral ops
WebGL component for displaying animated traffic graphs


From the blogosphere or news feeds ...
Journey of a Trailblazer (1) aug 21 rb
Looking for some standards and conventions to refactor?
About Sinatra 2.0 aug 22 rb
Just released in beta, here is the huge list of changes.
Pure RSpec JSON API testing aug 22 rb
how to test JSON API in Ruby on Rails or in plain Ruby application with nothing more than RSpec 3.x
The Pure Function As An Object (PFAAO) Pattern aug 23 rb
In this article, I want to demonstrate a nice way to write functional-style code in Ruby.
10 reasons why you should give Elm a try aug 23 js
Totally subjective but convincing sales pitch for Elm.
Hunting for great names in programming aug 23 web
One of the real delights of programming is picking great variable, method, and class names.
Phoenix vs Rails: Views and helpers aug 24 el
Here's an overview, case study and comparison to Phoenix of the V part of Rails MVC as experienced across the years.
Document your Already Existing APIs with Swagger aug 25 rb
Document APIs by editing a config file that is either json or yaml.
The State Of JavaScript: Front-End Frameworks aug 25 js
A few preliminary results from a survey by Sacha Grief.
Building Rails API's with JSONAPI and JSONAPI-Resources aug 26 rb
JASONAPI is a fairly new protocol, but has been methodically designed to handle most use cases
Using WebP Images aug 26 web
WebP can yield a substantial reduction in the size of images on your website.
From monolithics to microservices aug 27 rb
A software design approach to microservice evolution.
Links curated by mose (publisher), tysliu (editors), nauman, michaelweigle (contributors) .


The random rant of the week by mose.

To be remote or not to be remote ...

Earlier this week I read an article on linkedin, deliberately anti-remote, and a bit later on another one very pro-remote on freecodecamp. I'm tempted to think one is the response to the other. But maybe not.

The fact is that switching to a remote organization is a tricky move. It feels like the move from monolith to micro-services, honestly. People that make decisions about it rarely envision the extent of the change. And those change look similar in nature. Team architecture and software design are not that foreign. More autonomy for services or people, self-contained activity, requirement for clear communication channels and protocols, extensive architecture for monitoring, reporting or just plain visibility, more debugging tools and processes, and much more.

The same way one will have to think about all those when switching to microservices, the one that thinks about making his team remote will also have to consider the exact same parameters. But that is all on the principles. About the implementation, remote teams really need a strong chat culture, an easy and transparent logging policy for all communication channels, various tooling similar to chatops tools for assisting communication activity. Remote organization also need to have all their processes online, and not need much (if at all) any synchronous meetings.

From my perspective there are various very beneficial side-effects to make a team remote. There is more traceability as everything is online and not in corridors anymore. In some cases that I experienced, it also leads to a less arbitrary perception on team members, because they can be judged more on results (if you have measure tools prepared accordingly) than on attitude and mouth-skills (did you noticed that irl meetings are sometimes just a mouth-o-cracy?). But it's accurate to say that on a short term, it is more time consuming. The real benefit rises on the long run.

What I didn't find in any articles on the matter, is the life-cycle dimension. A software project has a life expectancy, from a business point of view. It's the same game as with the technical debt. It is acceptable business-wise to live at credit for a time, until a certain milestone. A lot of projects are just extended MVPs intended to convince big money that they could deserve some attention. For such project, you want very fast paced environment. It's easier to coerce your slaves employees to go above and beyond the expectations, when in a physical environment. This is a disposable context, and you can skip team debt as much as technical debt. And you really need physicality for that purpose.

So, I would say, if a company is not making the move towards remote organization, maybe there are very good reasons for that. But I will be very cautious to understand what are the real reasons. They may stink. And if they are remote, but they just came to it recently, I would be careful about the tooling they prepared for it.

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