From the Make, Buy or Rent article:

[…] [T]he three main system options for organizations seeking to upgrade their systems [are :]

• Make
• Buy
• Rent

IT managers have different criteria for deciding which components to assign in each category.

Another criteria for deciding

At a client, they have taken the decision to split their core IT systems in to the three options: make, buy, rent.

• The business logic to handle the core business is ‘make’. These systems are completely stateless
• The persistance (or storage) for the core business is ‘rent’. These systems, by definition, are stateful
• Other parts of the system are ‘buy’. Not important for this article

The key concept for this separation is moving the responsibility for uptime and complex data management to a provider. The provider can take better care of those procedures and use economies of scale to provide a better service that we could do in-house (‘make’) (e.g., high availability, reliability and SLAs) at the cost of paying a price for that. This idea simplifies our components (e.g., services), making them stateless. Even if they cache any internal information, it is a ‘Read Through Cache’, meaning that in case the data is not available in the cache, the service will transparently fetch it from the underlying storage system.

This idea for separating components simplifies both development, testing and maintainance, therefore reducing the Total Cost of Ownership (TCO) of our services.

A teammate and I have created a small tool to modify the titles of the trello card in a trello board.

Technical description

It works by applying a function to the existing title (because we wanted to remove a prefix from the existing title).

The modification is done, not through the API, but simulating user interaction:

• Click to edit the card
• Input the new title
• Save

The full code is available here

Conclusion

This has been a great example of working with legacy code, as the tools to work with the existing product are not the ones you would like to have and an imaginative solution provides a way out of the tar pit.

At a client, we’re converting all projects (i.e., sites, services, libraries) from npm to yarn. Mostly for the speed (as it uses the internal cache).

Step by step guide

1. Install yarn in your local environment * https://yarnpkg.com/lang/en/docs/install/
2. Run yarn install * This will create a yarn.lock file * Add that file to the repo: git add yarn.lock
3. Modify Dockerfile * Install yarn (in the Dockerfile). Idea: shortcut this execution with yarn --version in case it is installed * Configure the PATH variable (ENV PATH …) * ADD yarn.lock * Replace npm install with yarn install
4. Modify pipeline * See example (below) * install_yarn. Idea: shortcut this execution with yarn --version in case it is installed * Replace npm install with yarn install
5. Test it

Jenkins

Build step: execute shell

function install_yarn {
  yarn --version || curl -o- -L https://yarnpkg.com/install.sh | bash
  export PATH="$HOME/.yarn/bin:$PATH"
}

install_yarn

yarn install

¿Volver?

I’ve read this article by Raul Avila comparing the options between working in the UK and in Spain (where he’s originally from). Inspired by other professionals (e.g., David Bonilla, Jerónimo Palacios).

Tags: spanish, jeronimo-palacios, david-bonilla, expat, comparison, raul-avila, united-kingdom, spain

Donkey code

I’ve read this article by Einar W. Høst in which he introduces the concept of a ‘missing domain term’ with the example of a donkey being ‘closely related to a horse, though not exactly the same’

Tags: einar-host, donkey-code, ddd, domain-driven-development, domain, abstraction, missing-abstraction, business-logic

10 Habits That Change Boys Into Men

I’ve read this article by Benjamin P. Hardy on why some men are still boys (e.g., expectations from society) and what can boys do to turn into men.

Tags: benjamin-hardy, psychology, learning, evolution

On Sabbaticals

I’ve read this article about sabbaticals by Ian Malpass. In it, he explains why we need sabbaticals, how to take them, and some details about them.

Some principles:

1. If you think you can’t take a sabbatical, you need to take your sabbatical.
2. Day-to-day work pushes us to think tactically; sabbaticals push us to think strategically. Both are valuable.
3. Do the work to gain confidence that you can be away, and then trust that that the mechanisms you put in place are good.
4. Just because your team can function without you, doesn’t mean they want to.
5. There is rarely a good time to leave work for an extended period of time - don’t let this stop you.
6. Allow room for serendipity, the unexpected, and exploration.
7. Plan for your return before you leave, to avoid worry.
8. The sabbatical process doesn’t end after six weeks.
9. You don’t have to be unhappy or frustrated in your work to go on sabbatical.

Tags: sabbatical, ian-malpass, team-management, career

My favorite command-line utilities

I’ve read this article by Vitaly Belman in which he explains his curated list of utilities for the terminal

Tags: vitaly-belman, terminal, cli, application, utility, tig, git

Three Common Mistakes of the First Time Tech Lead

I’ve read this article by Patrick Kua, in which he explains what are the anti-patterns (or mistakes) of a tech lead. They do not only apply to first timers, but more experienced ones as well.

I especially like a comment:

Take all blame and give all credit: I ensure I always take the blame from the stakeholders when something is broken but when they praise, I say its all my teams efforts and I am just guiding them.

ravensnowbird

Tags: patrick-kua, tech-lead, leadership, team-management, mistake

Sentimental Versioning

I’ve read this article (unknown author) on alternatives to semver (semantic versioning).

Tags: semver, semantic-versioning, sentimental-versioning, humor, parody

Devoxx 2015: How to Become a Java Champion

I’ve watched this interview to Arun Gupta in which he explains what is a Java champion and how to become one.

Tags: interview, arun-gupta, java-champion, devoxx

How Can I Become a Champion Programmer?

I’ve read this article by Heinz M. Kabutz on how to become a java champion

Tags: heinz-kabutz, java-champion

The myth of using Scala as a better Java

I’ve read this article by Denis Kalinin disproving ‘Java as a better Scala’. He covers dependency injection, database access, serialization.

Tags: scala, java, comparison, orm, denis-kalinin, macwire, dependency-injection, serialization, database, myth

The eigenvector of “Why we moved from language X to language Y”

I’ve read this article by Erik Bern on the statistical analysis (based on people writing blog posts) of moving from language X to language Y.

This can help predict which languages will be more prevalent in the future.

Tags: eigenvector, statistic, erik-bern, language, programming-language, java, c, cplusplus, go, python

Facebook’s code quality problem

I’ve read this article by Graham King on the problems that Facebook is facing, at the code level, and how they solve some of them

Tags: graham-king, facebook, quality, architecture, code-quality

The key lesson from our serverless migration

I’ve read this article by Gojko Adzic on serverless, a kind of lessons learned. Explains that their system can take 50% more users at 50% of the original cost.

Also explains three ways of authenticating users: use IAM users, use Cognito, pre-sign URLs

Tags: lessons-learned, gojko-adzic, serverless, paas, platform-as-a-service, retrospective, money, total-cost-of-ownership, tco,

When automation goes horribly wrong

I’ve read this article by Gojko Adzic on a story of a manual process that was automated.

Because it focused too much on replacing humans instead of assisting them, MiDAS actually made it more difficult for clerks to access the data they needed for review

This reminded me of the framework vs library discussion:

• in frameworks you relinquish the control, putting your code into the allocated holes.
• using the automated system, you can only check the claim at a certain spot, where the system lets you do.

The system and the framework have been designed to take control of the situation. Both successful at what they do

Tags: gojko-adzic, automation, framework, library, framework-vs-library, comparison, analogy

How I Store My 1’s and 0’s: ZFS Bargain HP Microserver = JOY

I’ve read this article on how Alex stores his backups, using a microserver

Tags: backup, microserver, raid, zfs, backup-strategy

Meeting policy

I’ve read this article by the Ueno team on how they handle meetings. Interesting that they require manager approval for meetings over a certain threshold (more than four people or more than half an hour).

Tags: ueno, meeting-policy, meeting, approval

A Brief History of Random Numbers

I’ve read this article by Carl Tashian on how random numbers have evolved (from dice to pseudo random number generator and random number generators). Explain how some companies that need true randomness (e.g., certificates company) generate them.

Tags: carl-tashian, dice, random-number, randomness, prng, pseudo-random-number-generator, random-number-generator, number-generator, true-random-number-generator

Unlock honest feedback with this one word

I’ve read this article by Claire Lew, in which she suggests to ask for ‘advice’ instead of asking for ‘feedback’ as a way of getting more honest and better responses.

Tags: claire-lew, advice, feedback, feedback-process, improvement

We explore how to use parametrized tests (example in java, example in c#)

The tests are written using mocha syntax: describe, it. Using chai for expectations: assert.

Note: the example used below (adding to an array) is simple enough to be understood by everybody, without having to explain the domain. The real tests can have a more complicated environment or domain. This is just an example.

Using a custom syntax

This is just an example of some possible syntax, not using any (currently) existing framework.

describe('adding to a list', ()=>{
  newTestCase({description: 'to an empty list',
               input: [],
               parameter: 2,
               expected: [2]})
  newTestCase({description: 'to a non-empty list',
               input: [1],
               parameter: 2,
               expected: [1, 2]})

  it(`${testCase.description}`, () => {
    testCase.input.push(testCase.parameter)
    expect(testCase.input).to.deep.equal(testCase.expected)
  })
})

Using an in-place executor

describe('adding to a list', ()=>{
  const runs = [{description: 'to an empty list',
               input: [],
               parameter: 2,
               expected: [2]},
               {description: 'to a non-empty list',
               input: [1],
               parameter: 2,
               expected: [1, 2]}]

  runs.forEach(testCase => {
    it(`${testCase.description}`, () => {
      testCase.input.push(testCase.parameter)
      expect(testCase.input).to.deep.equal(testCase.expected)
    })
  }
})

Using it, DAMP

describe('adding to a list', ()=>{
  it('to an empty list', () => {
    const input= [];
    const parameter= 2;
    const expected= [2];
    input.push(parameter);
    expect(input).to.deep.equal(expected);
  });

  it('to a non-empty list', () => {
    const input= [1];
    const parameter= 2;
    const expected= [1, 2];
    input.push(parameter);
    expect(input).to.deep.equal(expected);
  });
});

Using it, DRY

describe('adding to a list', ()=>{
  it('to an empty list', () => {
    const input= [];
    const parameter= 2;
    const expected= [2];
    // use explaining variables
    pushingToMatches(parameter, input, expected);
  });

  it('to a non-empty list', () => {
    // not using explaining variables
    pushingToMatches(2, [1], [1, 2]);
  });

  function pushingToMatches(parameter, input, expected) {
    input.push(parameter);
    expect(input).to.deep.equal(expected);
  }
});

Using it, DRY+Fluent

describe('adding to a list', ()=>{
  it('to an empty list', () => {
    const input= [];
    const parameter= 2;
    const expected= [2];
    // use explaining variables
    pushingTo(parameter, input).matches(expected);
  });

  it('to a non-empty list', () => {
    // not using explaining variables
    pushingTo(2, [1]).matches([1, 2]);
  });

  function pushingTo(parameter, input) {
    input.push(parameter);
    return {matches: expected => expect(input).to.deep.equal(expected)};
  }
});

Sources

• https://rjzaworski.com/2013/01/parameterized-testing-in-javascript
• http://www.adequatelygood.com/Writing-Testable-JavaScript.html
• Example in java: here
• Example in C#: here

(This post is a modified version of the session available here)

WhatsApp Security Vulnerability

I’ve read this article by Bruce Schneier on a security defect in whatsapp, where an ‘unconfirmed’ message can be re-encrypted (with a new key) and resent. This is a vector for some attacks.

Tags: bruce-schneier, security, whatsapp, encryption, attack-vector

Encrypted email service once used by Edward Snowden relaunches

I’ve read this article, by Kim Zetter, on Lavabit restablishing its service. Explains the company’s past and the new services they are offering

Tags: lavabit, kim-zetter, privacy, encryption, email, mail

What Happens When You Mix Java with a 1960 IBM Mainframe

I’ve read this article by David Cassel about the legacy infrastructure of hardware that the U.S. government agencies have. How old mainframes are still useful to web applications and how these mainframes can communicate with more modern systems, through APIs

Tags: mainframe, david-cassel, marianne-bellotti, legacy-hardware, legacy-software, legacy-system, legacy, api

Systems We Love: How the Past Informs Our Present

I’ve read this experience report by David Cassel about the conference “Systems we love”: a mix of papers we love and systems that happened at San Francisco in December 2016

Tags: david-cassel, systems-we-love, papers-we-love, system, conference, experience-report, joyent

The agonizing death of an astronaut

I’ve read this article by Daniel Dietrich on why the implementation of the Option in Javaslang seems to be broken but, in fact, follows the rules of the monads.

Explains why map should be used for non-changing contexts and flatmap should be used for changing it.

Tags: daniel-dietrich, monad, option, haskell, optional, maybe, scala, javaslang

We reverse engineered 16k apps, here’s what we found

I’ve read this article by Fallible team, in which they describe the analysis of apps. They discovered 2500 apps with key and secret on them.

[…] whenever you hardcode any API key/token in the app, think hard if you really need to hardcode this, understand the API usage and the read/write scope of the tokens before putting it in the apps.

Tags: analysis, security, app, key, token, api, fallible

Oh, the emails you’ll get…

I’ve read this article by Joel Spolsky, in which he explains how some companies focus on some metrics for measuring performance, how difficult it is to measure performance.

Tags: joel-spolsky, performance, management, consulting

2002/07/15 - Measurement

I’ve read this article by Joel Spolsky where he explains how measuring performance is difficult, according to Robert D. Austin in his book Measuring and Managing Performance in Organizations. He gives some examples of that, mainly about paying out bonuses for performance reasons.

Tags: joel-spolsky, robert-austin, measuring-performance, managing-performance, book, knowledge-worker, bonus, pay, performance, organization

The Purpose Of Life Is Not Happiness: It’s Usefulness

I’ve read this article by Darius Foroux on what the purpose of life is about: making a difference (even if small) in what you leave behind.

Tags: psychology, purpose-of-life, usefulness, happiness, darius-foroux

The Future of User Interfaces

I’ve read this article by Brandur on how interfaces are becoming more and more bloated, slow and ridden with animations. All of that is targeted to the beginner user, rather than the proficient one. He suggests some ideas on finding inspiration from the terminal applications

Tags: brandur, interface, interface-design, ux, ui

My Increasing Frustration With Clojure

I’ve read this article by Ashton Kemerling on the problems he has found working professionally with Clojure and some possible solutions.

Tags: clojure, language, ashton-kemerling, functional-programming, problem, frustration

Java Without If

I’ve read this article by Ashton Kemerling on how he is using a library called ‘lambda’, which brings some of the functional programming features to Java.

Tags: lambda, library, ashton-kemerling, functional-programming, java, palatable, john-napier

Top ten pull request review mistakes

I’ve read this article by Scott Nonnenberg on the most common mistakes while doing a code review in the context of a pull request.

Tags: scott-nonnenberg, pull-request, code-review, github, diff, listicle

Shutting down Simplicity Itself

I’ve read this article by David Dawson on why he’s shutting down his consultancy company, Simplicity Itself, which was mainly focused on microservices.

Tags: david-dawson, simplicity-itself, shut-down, company, consulting, post-mortem, postmortem

Turn Off Your Cellphone

I’ve read this article by Brandur on how to get more done by unplugging the notifications

Tags: brandur, time-management, interruption, phone, notification

The Dark Standup

I’ve read this article by Alan Brouilette on the steps they took to reduce the amount of hours worked. It started with a few extra questions during the daily standup:

• What didn’t you do today because you stopped working on time?
• What will the impact be on tomorrow because of it?
• How much more time would you have needed to get everything done today?
• What will you do with those hours tonight instead?

and what they realized after a two-week experiment:

• The costs of context switching are much higher than we realized.
• We were spending a lot of time doing things that were urgent but not important, or that didn’t need to have been urgent at all.
• We needed to be a lot more ruthless about saying “No.”
• Some Operations roles are legitimately shorthanded, some of us just needed to impose a little order.
• FOMO WIP (unnecessary work one takes on because one fears missing something) is a real problem, especially as regards to Slack and meetings.
• We worked better in the time we had to work, knowing it was finite.
• Work-life balance improves both work and life. People literally slept better when limiting after-hours exposure to Slack and email. […]

Tags: dark-standup, quote, limited-time, overtime, team-management, experiment, question, alan-brouilette

What it Means to be a Remote-First Company

I’ve read this article by Alyssa Mazzina on what Stack Overflow does to keep its remote employees happy, how they are a remote-first company and small practicalities like tools, holiday gifts and stipends.

Tags: alyssa-mazzina, team-management, remote, remote-work, stack-overflow, team

Google’s not-so-secret new OS

I’ve read this article describing the state of Google’s new operating system, Fuchsia or Andromeda (the final name is not final yet).

Tags: google, os, operating-system, daniel-matte, fuchsia, andromeda

Four Secrets Of People Who Finish Their Workweeks On Thursday

I’ve read this article by Kat Boogaard that includes four tips to finish your week early:

1. They Schedule Intentionally
2. They Focus On Priorities
3. They Tune Out Distractions
4. They Find Shortcuts

Tags: kat-boogaard, time-management, eisenhower-productivity-matrix, urgent-vs-important, important-vs-urgent, urgent, important, productivity

Reflecting On One Very, Very Strange Year At Uber

I’ve read this article by Susan J Fowler on some bad HR practices at Uber and how they are part of the reason their low percentage of women (3%) in the engineering team.

Tags: sexism, uber, susan-fowler, hr, human-resources, women, work-environment, review

Ni dioses ni reyes. Sólo el hombre.

I’ve read this bonilista (in Spanish) by David Bonilla on which he talks about the God Mode and how that is implemented in different applications.

I’ve also liked this:

Los desarrolladores sólo somos herreros que forjan ceros y unos. Construimos herramientas para satisfacer necesidades de nuestros usuarios, sin que eso nos haga mejores que ellos o nos dé el derecho de supervisar y juzgar sus actos. A la hora de diseñar nuevos sistemas y funcionalidades, lo único que nunca deberíamos olvidar es que no somos dioses ni reyes, sólo hombres.

Rough translation:

We, developers, we are only blacksmiths of the digital era. We build tools to satisfy our user’s need, without that fact making us better than they are or without the right to overview what they do or to judge their acts. When designing new systems and features, the only thing we must never forget is that we are neither gods nor kings, just humans.

Las tres erres

I’ve read this article (in Spanish) by David Bonilla in which he explains three necessary factors when considering a job offer:

• Referentes: es imposible conocer a toda la plantilla de una empresa, pero si conoces a dos o tres empleados clave, podrás hacerte una idea de cómo será el equipo que te vas a encontrar. La gente prefiere trabajar con compañeros que compartan su ética y valores. Yo conocía a casi toda la plantilla de Comalatech tras haber coincidido con unos y otros en distintos eventos… y aún hay gente que se pregunta para qué sirve ir a conferencias técnicas si en Internet “se puede encontrar todo”.
• Referencias: es complicado, pero en el día a día una persona puede ser completamente diferente a la imagen que proyecta públicamente. Me ha pasado. Por eso es importante contar con referencias, terceras personas –antiguos empleados, clientes o proveedores- con las que haya trabajado. Los españoles no solemos pedirlas, pero para los anglosajones son un requisito imprescindible. En el caso de Comala, conseguí las mejores de la mejor fuente posible.
• Retos: los profesionales trabajamos por dinero, pero a partir de cierto nivel de salario, podemos permitirnos el lujo de elegir un trabajo u otro según otros factores. En mi caso, siempre he priorizado por encima de todo el potencial de aprendizaje y, en ese sentido, Comalatech no tenía rival.

Tags: referent, reference, challenge, david-bonilla, bonilista, change-job, job-offer