OscarGalindo

Building Evolutionary Architectures

Chapter 1 - Software Architecture

Architecture is 'the important stuff, whatever that is' or 'the parts that are hard to change later'. An architect analyzes business, domain, and other requirements to develop solutions that satisfy a list of prioritized architectural characteristics (-ilities). We should consider time and change with respect to architecture, or evolvability.

Software ecosystems are in a state of dynamic equilibrium. New languages, tools, methods constant force new equilibriums to emerge (free OS, linux, + free operations, puppet, led to the shift to containers). The pace of change in technology is constantly and rapidly changing in unexpected ways. We should architect systems knowing the landscape will change. Make ease of change a principal of architecture, remove the 'hard to change' definition of architecture.

An evolutionary architecture supports guided, incremental change across multiple dimensions. Evolvability is a meta characteristic that

OscarGalindo

Feedback Lightning Talks #1

• Dar una imagen mas personal a los developers de apiumhub de cara al público
• Tracción
  • Humaniza la empresa
  • La gente le tiene asco a las consultoras, esto ayuda a suavizar el asco
• Temática son interesnates, preparadas
• Movimiento dentro de la empresa
  • Compartir conocimiento de manera interna, hacer piña, comunidad, etc
• Ayudar al que no sabe algo, ayudar al que no sabe explicarlo en una zona segura que puede ser acogido

OscarGalindo

window:
  opacity: 0.965
  startup_mode: Maximized
  padding:
    x: 4
    y: 4
scrolling:
  history: 100000
shell:
  program: /bin/zsh

OscarGalindo

# Path to your oh-my-zsh configuration.
ZSH=$HOME/.oh-my-zsh

# Set name of the theme to load.
# Look in ~/.oh-my-zsh/themes/
# Optionally, if you set this to "random", it'll load a random theme each
# time that oh-my-zsh is loaded.
ZSH_THEME="lambda-inhji"

# Example aliases

OscarGalindo

function logClass(target: any) {
 
  // save a reference to the original constructor
  var original = target;
 
  // a utility function to generate instances of a class
  function construct(constructor, args) {
    var c : any = function () {
      return constructor.apply(this, args);
    }

OscarGalindo

Migrating to OS X Mavericks breaks the ngrep utility. Doing:

sudo ngrep -d lo0 -q -W byline port 8080

stopped working where the process exits immediately. I didn't dig into the ngrep code, but was able to find a simple workaround by doing

sudo ngrep -q -W byline -d lo0 '' 'port 8080'

You can call that a lazy hack, but it work!

OscarGalindo

#!/bin/bash
#####################################################
# Name: Bash CheatSheet for Mac OSX
# 
# A little overlook of the Bash basics
#
# Usage:
#
# Author: J. Le Coupanec
# Date: 2014/11/04

OscarGalindo

// Node.js CheatSheet.
// Download the Node.js source code or a pre-built installer for your platform, and start developing today.
// Download: http://nodejs.org/download/
// More: http://nodejs.org/api/all.html


// 0. Synopsis.
// http://nodejs.org/api/synopsis.html

OscarGalindo

I don't love the single responsibility principle

Did you ever happen to disagree with a colleague on the single responsibility principle and its application? Let's try to understand why that could be the case.

I once worked with a colleague, whom we shall call Stan, who had a very different understanding of the single responsibility principle than I had. During code reviews, his feedback would often be that my classes "tried to do too much" and broke the single responsibility principle. My feedback to his patches was often the opposite, that his classed did too little and lacked cohesion.

How can we explain this disagreement? Let's assume that we both know the SRP and try to apply it at the best of our abilities: I can only see two alternatives.

The first possibility is that the classes are actually the wrong size. People are wrong all the time: maybe I was wrong and he was right or vice versa. While this sometimes happens, I would expect any reasonably competent developer who is aware of the SRP to onl

OscarGalindo

Better local require() paths for Node.js

Problem

When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:

var Article = require('../../../models/article');

Those suck for maintenance and they're ugly.

Possible solutions