| Big Omaha |
|
| A conference website with very clear and nice layout. | |
| Ruby Conference Calendar |
|
| Auto-generated calendar for ruby conferences. | |
| Meta Ruby |
|
| A discourse forum about Ruby. | |
| Daily JavaScript community news and chat |
|
| A RubyFlow-inspired community news site for JavaScript and related technologies. | |
| SVG on the web |
|
| A full practical guide for using SVG on websites. | |
| TalentBoard |
|
| Subscribe to receive free CVs of the best specialists for remote work in your company. | |
| Own mailbox |
|
| Plug at your home, read and write emails privately from anywhere in the world. | |
| Rails 3.2.22, 4.1.11 and 4.2.2 have been released and more |
jun 16
|
| These releases contain security fixes, so please upgrade as soon as possible! | |
| dokaz |
|
| Parse your ruby code written in markdown | |
| derailed_benchmarks |
|
| Checking memory usage of your rails app in several ways. | |
| Filterable Product Grid |
|
| A responsive product grid layout with touch-friendly Flickity galleries and Isotope-powered filter functionality. | |
| Page Scroll Effects |
|
| Fancy effects that take place while the user is surfing through the sections of a web page. | |
| material-theme |
|
| Bring Google material design to Sublime Text 3. | |
| Flocker |
|
| Container Data Management for Docker. | |
| Auto-squashing Git Commits |
jun 15
|
| The fixup and autosquash command | |
| Rack: First Principles |
jun 16
|
| What Rack is and what it's used for. | |
| Ruby Error Handling, Beyond the Basics |
jun 16
|
| More ways to handle ruby errors besides raise and rescue. | |
| Avoid race conditions in Rails with Postgres locks |
jun 16
|
| Rails provides a great API in ActiveRecord for dealing with DB level locks. This works for both MySQL and Postgres. | |
| Using Lambdas in Ruby |
jun 16
|
| Lambdas have some interesting tricks up their sleeves once you investigate them a little. | |
| Understanding the rails-jquery CSRF vulnerability (CVE-2015-1840) |
jun 17
|
| What's CVE-2015-1840 about (one of the vulnerabilities fixed in the last rails update). | |
| Naming is the key |
jun 17
|
| Naming guideline for method and class. | |
| Nokogiri Fundamentals: Extract HTML from the Web |
jun 18
|
| The most common use for a parser like Nokogiri is to extract data from structured documents. | |
| Useful Flexbox Technique: Alignment Shifting Wrapping |
jun 19
|
| Text is always changing and the space you have available is variable. | |
| The Future of Software Engineering |
jun 16
|
| ICSE 2015 - Grady Booch Keynote. | |
The topic I talked about last week led me to think about it more widely. And I ended up with the thinking that many problems in software companies are a clear problem of balance between their yin and their yang.
This old chinese principle is documented in a very old-fashioned way, opposing genders and principles. But actually it sums up in the fact that many dynamics are to be based in a balance between two opposing principles. Otherwise they fail.
The way I see it, software developers are a nurturing kind. This profile has to consider long term. It decides actions for later outcomes. It's about giving life and growing it. It feels closer to the Yin principle.
On another hand, the business people are bound to a shorter time frame. And I don't talk about the entrepreneurs and the rare visionary people, but the real business work force. They are competitive, aggressive, fighters. That really feels to me like the Yang concept.
And all occurrences where I saw software companies failing, I think it was because there was a lack of balance between those 2 principles. Either the management was too soft and not aggressive enough towards its market, either it was too aggressive and nurturing was not considered enough in their equation.
I don't think that this balance requirement applies to everything, to be honest. But in a constituted body of a software organization, considering the current (questionable) market economy, it feels that the Yin and the Yang have to be in balance to grant a chance of survival to the organization.
One may have the feeling that the dominant Yang (business side) is the more common case. But they are just more noisy. Many projects stay silently in the darkness just because there was no real business consideration (or even refusal of it).
The keynote of Grady Booch (linked in the video section) confirmed me in various ways in this opinion. Engineers have the duty to fight for the balance when they can. They have to understand that it's not a one-way deal, as well. If you want to exercise programming in a nurturing-only context, win a lottery and dedicate your time writing free software (where market requirements don't apply). But in the usual case, you may have to consider if you are in a balanced context, and if not, try to work on balancing it.
