| Piaget Possession |
|
| Jewerly website with some advanced effects on video. | |
| Rails Karate |
|
| A website publishing resources to learn rails. | |
| The micro Gem principle |
|
| Manifesto for tiny gems. | |
| The art of monitoring |
|
| Graphs can be good looking, submit some there. | |
| Tractorbot |
|
| Code and files for TractorBot, the winner of the 2014 RobotWars competition, recently open sourced. | |
| Reform 2.0 |
|
| Form objects decoupled from your models. | |
| Action Cable |
|
| Action Cable seamlessly integrates websockets with Rails application. | |
| jQuery fontIconPicker |
|
| Elegant icon picker with categories, search and pagination inside administration forms. | |
| Cola.js |
|
| Arrange HTML5 documents and diagrams using constraint-based optimization techniques. | |
| Merge Conflicts |
|
| Resolve your git merge conflicts in Atom. | |
| SwiftypeMonitoring |
|
| Framework for building application-level monitoring checks. | |
| WebSockets in the Ruby Ecosystem |
jul 6
|
| How to use websoclet in a ruby app. | |
| Faking APIs in Development and Staging |
jul 6
|
| Fakes are great for testing an application that interacts with 3rd party APIs. | |
| Getting Started with Vim: An Interactive Guide |
jul 6
|
| Vim is not the easiest text editor, this should help breaking the ice. | |
| Cassandra, The Right Data Store |
jul 6
|
| For Scalability, Performance, Availability and Maintainability. Overview. | |
| Using Enumerable as testing abstraction |
jul 7
|
| Some neat usage of Enumerable. | |
| How to write Rails middleware |
jul 7
|
| Third article about rack and middlewares, with code examples. | |
| The Pathway for New Rubyists |
jul 8
|
| Suggested list of books, courses, blogs, and forums on Ruby. | |
| Ruby is defined by terrible tools |
jul 8
|
| Programming languages cannot be considered separately from their ecosystems. | |
| Nested errors in Ruby with Exception#cause |
jul 8
|
| How Exception#cause can help in Ruby 2.1. | |
| Managing Gluster Volume Snapshots using oVirt |
jul 9
|
| Gluster is a scale-out, software only, distributed file system which provides ability to store peta-bytes of data. | |
| Uploading Files with Paperclip |
jul 10
|
| Popular solution for integrating file uploading and management into a Rails app. | |
| Rails tricky timezones |
jul 12
|
| Clarify the confusion around timezones in rails. | |
| Pair Programming on Rails Scopes (1h03) |
jul 6
|
| Pair programming session on some common model scopes related to time. | |
| Simple And Clean RubyGem With Rails Engines (4m) |
jul 8
|
| Overview of rails engines. | |
| How to provision a complete Rails server in 2 minutes with Ansible (2m) |
jul 9
|
| Use ansible to easily provision an rails app server. | |
| Rails 5's ActionCable and Websockets Introduction (18m) |
jul 11
|
| Feels like it's the week of actioncable, right ? | |
Recently I've been playing with Hubot plugins code in coffeescript for our company. That's a while I didn't do much js but I used it for a long time and I didn't find it too difficult to catch up. But for some reason, it brought me the same feeling I have each time I get back to that language. I feel dirty. Still I can do what I need to do, for sure, but I don't feel like a builder, more like an acrobat. And I'm far from a purist.
Some people talk about javascript taking over the world. But that language imho just was there at the right place at the right time. By having a runtime embedded in browsers and browsers libraries, it has been used to hijack the most used software on our computers and mobile devices, to transform them into richer clients. Along the way various layers were added to fulfill the need of software design, because javascript initial goal was merely DOM manipulation.
The thing that always stroke me the most with javascript is that despite the efforts from ecmascript, it has no formal standard or documentation. It is pretty extensively documented, of course, but because the language is pushed forward by the implementations rather than from a standard body, it gets a bit messy.
I saw a drawing this week that illustrates the mess quite well. It feels like Javascript is waiting for something to come replace it.
But there is hope with ES6. Seems like in recent years the normative effort on the ecmascript standard got some more traction and some more press coverage. But I personally don't think it's going to bring the solution. I enjoyed reading the thoughts of Eric Elliot on that topic but I'm not sure he's right on everything. But what he's right about, is that there will be an after-javascript.
Unless that after javascript doesn't arrive fast enough and gets useless by some new programming paradigm that may appear one day soon. I mean, in the next 10 years. At some point, like big data is too complex to be handled by human, programming will also get too complex and will be handled by algorithms. We already see it coming. And all programmers will then become high end workflow designers or just play with antiquities.
In this perspective, I think javascript is a great intermediary technology for the time being, given its pervasive aspect. It's far from satisfying, but it does the job. But the younger generation should keep an eye on higher level abstract approaches, like systems architectures, workflow logics, organization patterns, because imho that will drive software design in the next 10-20 years.
