Trippeo | |
Nicely animated website for a traveling expenses app. | |
User Flow Patterns | |
Collection of small videos of user interaction on mobile apps. |
Rspec website | |
New shiny design, for this champion of ruby testing. | |
Learn Ruby by Example | |
Learn or reference Ruby with example code and challenges. | |
Jekyll Cheat Sheet | |
Great supplement to the Jekyll documentation, this page has a lot of examples. | |
I Love Ruby | |
(book) 220 pages of ruby, this is a self-published free book. | |
Overapi | |
Collecting All Cheat Sheets. | |
iOS on Rails | |
(book) The reference for writing iOS apps with Ruby on Rails backends, by Thoughtbot. | |
InboxPixels | |
A weekly newsletter bringing design inspiration. |
Kleisli | |
Usable, idiomatic common monads in Ruby. | |
Dos-t | |
An opinionated helper for I18n. | |
Dockerb | |
Use ruby in your dynamic Dockerfile.erb. | |
Intercooler | |
Making AJAX as simple as anchor tags. | |
Spacebase | |
Sass-based responsive CSS framework. | |
Shipit | |
Universal automation and deployment tool written in JavaScript. | |
GitHooks | |
Framework for creating standard pre-commit and commit-msg hooks for your git repository. | |
Prometheus | |
An open-source service monitoring system and time series database. | |
Comcast | |
Simulating shitty network connections so you can build better systems. | |
Toxiproxy | |
A proxy to simulate network and system conditions. |
Game Development in Go | jan 25 |
Thoughts from a game developer about using golang for game dev (with example code). | |
Closures in Ruby | jan 26 |
Blocs, procs and lambdas, pros and cons, with examples. | |
Monitor Docker Containers with Prometheus | jan 26 |
Prometheus, used with a container-exporter, makes it easy to monitor many docker containers. | |
What the Flux? | jan 28 |
React.js and Flux architecture, hard to get around, but here are some concepts explained. | |
Ruby serialization formats | jan 28 |
There are many ways to serialize objects, here are 5 of them. | |
Non-Message Flash in Rails | jan 28 |
Messages aren’t the only reason to use flash. | |
Building and Testing Resilient Ruby on Rails Applications | jan 29 |
Pretty good description of a resilient architecture by shopify. | |
Replace CoffeeScript with ES6 | jan 29 |
Sprocket-es6 will transpile to es5 anyways. | |
How React.js Outperforms Angular.js | jan 29 |
Of course they are not same kind of beast, but they still can be compared, right? | |
Why JavaScript Needs Types | jan 29 |
Various reasons why js may need typing. | |
Sass Basics: The Function Directive | jan 29 |
What a @function does in Sass. | |
The Best Code is the Code Nobody Writes | jan 30 |
Adopt a minimalist approach when coding. | |
Require only what you require | jan 31 |
This may sound obvious, but actually many gems require everything by default. | |
10 easy-to-fix Ruby and Rails mistakes | jan 31 |
A short list of common mistakes found in ruby code. | |
When your Rails app slows to a crawl | feb 1 |
Some usual suspects that can slow down a rails app. |
Sysadmincast #44 (14m) | jan 28 |
Patching the GHOST glibc gethostbyname CVE-2015-0235 bug. |
Giant Robots 131 (32m) | jan 26 |
The Human-Computer Interaction Umbrella (Irene Ros). | |
Developer tea 11 (14m) | jan 26 |
Justin Weiss - choosing Rails, guest hosting on Ruby Tapas, and enjoying Ruby. | |
Ruby5 #523 (6m) | jan 27 |
Tail call optimization, single vs. double quotes, ActiveRecord SQLServer, Rbkit, Commander. | |
RubyRogues 192 (56m) | jan 28 |
Vagrant with Mitchell Hashimoto. | |
Web Platform Podcast #27 (1h06) | jan 28 |
Building Codepen. | |
Javascript Jabber 144 (38m) | jan 28 |
Marionette.js 2.0 with Sam Saccone. | |
Developer tea 12 (15m) | jan 28 |
Chris Coyier, Part One - The Lifecycle of the Web and the Non-Evil of Doing Business. | |
Adventure in angular #27 (45m) | jan 29 |
Accessibility with Marcy Sutton. | |
Food fight show 87 (1h04) | jan 29 |
Complexity Theory and Cynefin. | |
Ruby5 #524 (7m) | jan 30 |
Minitest and RSpec, Passenger-docker, Converting a large JRuby project to GoLang. | |
The Changelog 139 (1h02) | jan 30 |
Rocket, App Container Spec, and CoreOS with Alex Polvi. | |
The Bike Shed 7 (48m) | jan 30 |
At the Car Wash. | |
NodeUp 82 (57m) | jan 30 |
A 6to5 show. | |
The Cloudcast #178 (37m) | jan 30 |
DevOps Defined Networking with Socketplane. |
You certainly heard about it, this week there was a new huge Linux vulnerability on glibc revealed. Actually it was leaked by a stupid communication agency few hours before it should have been announced. When such big bug is discovered usually there is a small period of time where the news spread into some limited circles. They keep it embargoed until major distro vendors get patched packages ready. Well, it didn't go that well this time.
This vulnerability is pretty nasty even if less obvious to exploit than Heartbleed or shellshock, it's probably in the same category. If you manage servers that are vulnerable (LTS and stable, less up to date versions, mostly), you better upgrade asap. When a bug gets its own name (this one is called Ghost), it seems to be the sign it requires immediate attention. How long is this trick going to work?
And, as we talk about security, Hipchat users should read this (unnamed) security notice.
This edition is marking the 2 years anniversary of Green Ruby. For 104 weeks I've been sending out this newsletter every week. Last week I had a discussion with a friend, he was asking me what was my drive, and what was the reason of my consistency. Well, there are various reasons.
First there is the routine aspect. It's like practicing Taichi or some kind of exercise. It keeps the mind fresh, and in this context where things change pretty fast, enforcing a weekly review gave me an overall feeling of symbiosis with the wave of what's going on.
Second is the philosophy of it: this newsletter is a gift. The ruby world is very business oriented. There is a lot of open source in there but still the average spirit is based on a market economy. There are of course many exceptions, I wanted to be one of them, and I believe a gift economy would be more my thing. You get rich of what you give away, not always individually, but most definitely collectively. I like that feeling.
Third, this media keeps me in touch with a bunch of my friends. It's like a beacon that I send to the people I left behind when I left France to go live in Taiwan. Or people I worked with in my past jobs in Taiwan, even. They don't often respond to it but I know they can perceive me through this weekly proof of existence.
Also, there is the support from xenor and more recently from simon, which, by sending me a few links each weeks, validate the need to keep things going.
For as long as I remember, I always have been coding irc bots. In so many languages. I suspect there is some aspect of this that appeals to me. Maybe the creation of life-like pattern. Anyways, my last bot was of course in ruby, I called it cogbot, and is based on the great [cinch]2] framework. It has been sleepy for a while, since we were not using irc in Faria.
But Gandi is heavy irc user, and our recent experiments on trello gave me an occasion to get cogbot out of the dust. As a matter of fact Trello has a really great API, and also supports webhooks. So I added a trello listener to cogbot, and it was a lot of fun. Maybe next I will add some cards creation and update features in that bot, but it requires some kind of users management, which, on an irc bot, is not that trivial to implement.
Do you have a side project? You should! Maybe the code you produce at work can be generic enough? This is a call for you to consider freeing your code. Open source community is plentiful but I know as a fact that 90% of the code that could be shared is not shared.
There is something I noticed in my own code publication. Often in my work there are constraints of time that lead to trade-offs and code quality is never as good as I wish it was. By working on side projects, the pace is much more relaxed and I can spend hours focusing on non productive efforts to make my code better. Well, this is not to say that side project code is perfect, but the environment of producing it brings another mindset. And after a while, the code produced at work gets naturally more insightful because of this extra practice.
Give it a try, if you happen to have some free time. If you don't have free time, you're doing something wrong. But that's another story.