Joho's | |
Full-page video and audacious navigation. | |
2015 year in review | |
A Collection of 2015 Year in Review pages from around the world. |
Ruby on Rails: Doctrine | |
Renewed Rails Manifesto by DHH. | |
ES6-cheatsheet | |
Cheatsheet containing tips, tricks, best practices and code snippets. | |
AirBNB JavaScript Style Guide | |
The AirBNB JavaScript Style Guide | |
CssFilters | |
Custom and Instagram like photo filters for CSS. |
Icersplicer | |
Manipulate text files with Ruby. | |
Solidus | |
Rails eCommerce System. | |
It_sorts | |
Tiny helper lib for understandable array sorting. | |
Chaltron | |
Template generator for rails 4 application with bootstrap, devise... | |
devise_invitations | |
Allow multiple invitations on top of devise_invitable. | |
torba | |
Bundler for Sprockets. | |
Apex | |
Minimal AWS Lambda function manager with Go support. | |
Kiex | |
Like rvm, but for elixir. | |
Objection.js | |
An SQL-friendly ORM for Node.js | |
Validator.js | |
String validation and sanitization. | |
Timelined | |
A customizable CSS-only vertical timeline. | |
Sqlpp | |
A simplistic SQL parser and pretty-printer. |
What's new in Ruby 2.3 Enumerable | jan 18 |
Two new Enumerable instance methods were added, grep_v and chunk_while. | |
11 Ruby Tricks You Haven’t Seen Before | jan 18 |
Well, maybe you knew about some of them, but maybe there is some easter egg here. | |
Implicit vs explicit type conversions in Ruby | jan 18 |
to_h/to_hash and others. | |
Building a web framework from scratch in Elixir | jan 18 |
Using Plug directly to build our own framework from scratch. | |
A Deep Dive into ES6 Classes | jan 18 |
Inheritance, encapsulation, polymorphism and much more. | |
Pointy Slider | jan 18 |
Creating a slideshow with sliding-in panels that unveil new, fixed background images. | |
Introducing Apex | jan 18 |
Serverless architecture with AWS Lambda. | |
Next generation configuration mgmt | jan 18 |
A next generation configuration management prototype. | |
Skinny controllers through refactoring | jan 19 |
Controllers can get out of control. Their job should generally be quite simple. | |
New Rails identity | jan 19 |
With Rails 5 just around the corner, we thought it was finally time for a fresh look for a new day. | |
The Beginner's Guide to Crafting Ruby Gems | jan 19 |
The simple steps of gems creation, in this example for a rails plugin. | |
The Easiest Way to Add Authentication to Any App | jan 19 |
Don't feel like implementing authentication yourself? Try Auth0. | |
Patch and Protect Linux Kernel Zero Day Vulnerability | jan 19 |
CVE-2016-0728, A local privilege escalation vulnerability has existed since 2012. | |
Trends in Ruby - analyzing rubygems stats for 2015 | jan 20 |
Rubygems is the official package manager for Ruby and we decided to crunch up some stats for 2015 and see what's what. | |
OAuth 2 All the Things with oPRO: Customization | jan 21 |
This is the third and the last part of this series of working with oPRO. |
Recently Marcelo told me, that's weird, how we do 10% research and specification, 40% implementation and 50% debugging in this industry. I'm more used to 70% research and specification, 20% implementation and 10% debugging. He was working in the hardhware industry for a while, and just came to a service-based company. This is actually a very interesting remark and it reminded me when I was in my twenties when I was working as a construction worker.
When I was young there was no internet and I had a 10 years break from computers. I had to take stupid jobs like working on construction sites for low wages. After that I went to art school and later on I worked on building sets for business shows. I have been shocked by the gap between those 2 worlds. When building a house, there is so much time spent writing plans, thinking things in advance. While in the show-business construction pattern, it was mostly about improvisation and managing inflexible time constraints, with one-time-use construction.
I feel there is the same gap in the software industry. Well it's not exactly the same for sure, but the paradigm feels alike. In service software production, SaaS or ISP businesses, we tend to under-engineer the production. There are perfectly legitimate reasons for that, the life-cycle of a platform of service is quick, volatile and the value is not in the software asset but in the customer-user experience.
The Agile organization model reinforces this pattern, by providing a substitute to the early specifications, in the form of user experiences description. All this is fine and good. For a time. But with years passing we can see so many occurrences of 'temporary' projects becoming indestructible legacy monsters. It's like there was some kind of tipping point where the development should shift from under-engineered to well-engineered but it's rarely anticipated properly enough.
But it's pretty hard to address that kind of problem. Throwing away the early instances is very costly, especially when the organization is shaped by a fast-paced reactive production model. Introducing proper engineering at early stages is also not a clever option, as the product has to adapt to the service, which depends on a constant feedback loop with the users.
I have the feeling that there is something missing. Like an evolution of agile that could include seeds of later engineering. Some way to make possible to start fast, and evolve in a solid and slower model later on without crisis or disruption. This is the perspective that I think was missing in that article I cited on green ruby 145. But I don't know the answer to that problem. I suspect it will emerge by itself in the few next years.