On git

You can have multiple persons involved in a single git commit: an author and a committer.

The difference is explained by Manuel Doninger ¹:

The author is the one who did the code change. The committer is the person who committed that change to a repository.

an example, by the same author:

Example: I’m not a committer in the EGit project, so i have no rights to push directly to the EGit repository at Eclipse. But i contribute to EGit, so my changes have the author set to my name and email. If my change gets reviewed by the EGit team, and submitted, the committer field contains the name and email of the person who submitted the change

On github

This is represented in github with this format:

One of them is “sharplet” and the other one is “gfontenot”. Both are github users that match a github-registered mail.

On a shallow inspection, the commit does not reveal anything special:

$ g log 17a96dba38479de78cdb3b3aae1c802f4d54f485 -n1 --full-diff
commit 17a96dba38479de78cdb3b3aae1c802f4d54f485
Author: XXXX <xxxx@example.com>
Date:   Wed Dec 2 14:44:52 2015 +1100

    Clarify specs by defining • as the composition operator

but looking a bit closer²,

$ g log 17a96dba38479de78cdb3b3aae1c802f4d54f485 -n1 --dense --full-diff --format="%H, %h, %T, %t, %P, %p, %an, %aN, %ae, %aE, %ad, %aD, %ar, %at, %ai, %cn, %cN, %ce, %cE, %cd, %cD, %cr, %ct, %ci, %cI, %d, %D, %e, %s, %f, %b, %B" | less
17a96dba38479de78cdb3b3aae1c802f4d54f485, 17a96db, 6bc2a33e3a069b78b9fd36124f5ed039a125303e, 6bc2a33, 29488bc0be27c5c03b6af7d115c7d45645382a7a, 29488bc, XXXX, XXXX, xxxx@example.com, xxxx@example.com, Wed Dec 2 14:44:52 2015 +1100, Wed, 2 Dec 2015 14:44:52 +1100, 3 months ago, 1449027892, 2015-12-02 14:44:52 +1100, YYYY, YYYY, yyyy@example.com, yyyy@example.com, Tue Dec 15 09:30:28 2015 -0800, Tue, 15 Dec 2015 09:30:28 -0800, 9 weeks ago, 1450200628, 2015-12-15 09:30:28 -0800, %cI, , %D, , Clarify specs by defining • as the composition operator, Clarify-specs-by-defining-as-the-composition-operator, , Clarify specs by defining • as the composition operator

or, just the emails:

$ g log 17a96dba38479de78cdb3b3aae1c802f4d54f485 -n1 --dense --full-diff --format='%ae %ce'
xxxx@example.com yyyy@example.com

Usage

For a single commit:

$ GIT_COMMITTER_NAME='John Doe' GIT_COMMITTER_EMAIL='john@example.com' git commit -m "..."

For a session:

export GIT_COMMITTER_NAME='John Doe'
export GIT_COMMITTER_EMAIL='john@example.com'

Taken from [this StackOverflow answer][how-to-use-it]

This can be useful for a pairing session or for some kinds of git history rewrite.

Update 2016-10: We have this script to make it easier to change.

Use pair_with to pair with someone and solo to work on your own.

Place this on your ~/.bashrc or ~/.zshrc or similar.

function solo {
  unset GIT_COMMITTER_NAME
  unset GIT_COMMITTER_EMAIL
}

function pair_with_ {
  export GIT_COMMITTER_NAME=$1
  export GIT_COMMITTER_EMAIL=$2
}

function pair_with_john {
    pair_with_ "John Doe" "jd@example.com"
}

...

Update 2, 2016-10: This script also helps with managing the variables: [git-duet][git-duet]. Thanks [David Hatanian][dhatanian] for the tip

Software and all that comes with it

I’ve read these slides about creating software and asking questions to deliver value, by Alberto Brandolini

Tags: alberto-brandolini, software, slide, team-management, agile

Driving your DBA crazy in 3 easy steps

I’ve read these slides about dealing with the knowledge that is present in the database, not expressed in ubiquitous language and cause of the low bus factor, by Alberto Brandolini

Analogy between the movie The Shining and a model / entities / aggregates.

Tags: ddd, model, entity, aggregate, team-management, dba, agile, ubiquitous-language, alberto-brandolini, bus-factor, slide

Shorter Feedback is not Always Bett

I’ve read this note from Kent Beck on why shorter feedback loops might not always be better. I.e., why some processes take time to set in and results are not observable until that time.

Tags: kent-beck, feedback-loops, open-question, analogy

La Regla del Triple Check para ir a eventos

I’ve read this article by David Bonilla about a rule to help you decide attendance to events, in Spanish

Tags: rule, time-management, david-bonilla, event, spanish, triple-check

An interview with Charles Wetherell

I’ve read this interview by Alexander Demin about the interviewee’s book “Etudes for Programmers”. In it, they talk about the origin of the études, the author’s research interests and activities. Also about the book (written in 1978) and how computer science has changed since then.

When asked about three things a programmer should know:

Some ability to do formal mathematics. The level necessary to understand Hopcroft and Ullman combined with a little graph theory is enough. Discrete mathematics is essential; calculus is only necessary for folks working in special application areas.

Some ability to write clearly in their native language. Dijkstra said that if a person couldn’t write their own language, they couldn’t write a correct program. (Well, that’s what I hope Dijkstra said!). Writing programs is essentially the same as writing a non-fiction essay. If you can’t make the step-by-step connections clearly in your own language, why would we think you could in C, for example?

Remember that a program is primarily for communication with humans, not computers. When you write a program, the computer will do whatever you say. You must convince the humans who read the program that what you have asked the computer to do is the correct thing to do. Remember, the computer doesn’t care about correctness.

The answer to the last question means that programs should always have the form of paragraphs of comments that describe the intention of the program followed by paragraphs of code that implement that intention. All of the formatting should be designed to make readers as able as possible to read the code easily; the compiler doesn’t care. In particular, follow conventions of mathematics and your native language, not those you found in some random language manual. Write the comments first and then write the code, not the other way around. If you don’t know what you want to achieve and why, any code you write is, by definition, incorrect.

Tags: charles-wetherell, alexander-demin, interview, book, etude, etudes-for-programmers, practice, ability, skill, list

How to fix Javascript… maybe

I’ve read this article by Drew Hamlett about the lack of style guide for javascript and how this affects the adoption of the language and the sprout of similar libraries.

Suggests the creation of a standard style guide for javascript.

Tags: drew-hamlett, javascript, style-guide, analysis

Isomorphic JavaScript: #DevBeat Master Class

I’ve read these slides by Spike Brehm on Isomorphic JavaScript and why it’s important: initial pageload and speed, reducing effort and duplication, SEO (crawlability).

Tags: isomorphic-javascript, isomorphism, javascript, seo, crawler, frontend, app, application, fat-client, fat-server, thin-client, thin-server, ria-spike-brehm, slide

Open-sourcing our docker images

I’ve read this article by Brandon Cannaday about the Docker images that they have.

Tags: docker, brandon-annaday, open-ource, image, container, modulus

growing up in an open source world

I’ve read this article by Matt Hernandez where he explains that fixing the style guide can limit your creativity and how the software is written in enterprise and open-source environments.

Also about how developers grow when exposed to different style guides.

Tags: style-guide, matt-hernandez, creativity, dreyfus-model, enterprise, open-source, programming

Hanlon’s Razor and working with young engineers

I’ve read this article by Matt Hernandez on the importance of understanding (and empathising) towards others' positions and worries.

Cites the Hanlon Razor:

Never attribute to malice that which is adequately explained by ignorance.

Tags: hanlon-razor, empathy, team-management, ignorance, malice, matt-hernandez

Intro to sails.js

I’ve watched this video, an introduction to the sails.js framework: a realtime nodejs server for creating REST APIs, inspired by Ruby on Rails.

Tags: sailsjs, ruby-on-rails, ror, framework, video, introduction, mvc, rest-api, realtime, nodejs,

Node.js and hapi - creating a rest api

I’ve read this article about creating a REST API using Hapi, a nodejs framework. Written by Matt Hernandez

Tags: matt-hernandez, rest-api, nodejs, hapi, framework

Introducing Pokedex.org: a progressive webapp for Pokémon fans

I’ve read this article by Nolan Lawson about the challenge of having a 60 fps application on a mobile device, making it offline.

Uses Angular 2, javascript 7, PouchDB as well as LocalForage for storage. All processing on WebWorkers, except for DOM manipulation.

Tags: angular-2, javascript-7, angular, javascript, pouchdb, localforage, cloudant, 60fps, mobile, app, offline-first, offline, pokemon, api, nolan-lawson, web-worker, flip-technique, css, progressive, pokedex, svgomg, frontend

LambdaConf 2015 - How to Learn Haskell in Less Than 5 Years Chris Allen

I’ve watched this video by Chris Allen on how to learn haskell, what are some common pitfalls while learning it and how learning and teaching (it) are different.

Talks about his (with a coauthor) book, focused on not reducing the readers that make it to the end and, finally, increasing the amount of haskell users.

References this talk by Kmett.

Tags: chris-allen, haskell, learning-to-learn, meta-learning, lambda-conf, talk

Extreme Continuous Delivery - at Unruly

I’ve read these slides about how the company Unruly does continuous delivery (CD), maximizing business value, minimizing time to market (TTM). Also describes how they do deployments and how to organize teams.

References: Extreme Programming Explained (Beck), Continuous Delivery (Humble & Farley)

Tags: silo, team-management, culture, continuous-delivery, tdd, nagdd, shared-infrastructure, acceptance-testing, module-testing, conway-law, cross-pollination, continuous-investment, slide

Building chat applications and robots for Skype

I’ve read this article on building robots for skype. By Mikko Ohtamaa

Tags: skype, robot, bot, mikko-ohtamaa, slack, integration, api

Why I never wrote down our company values

I’ve read this article by Mikael Cho on the subject of having company values, preaching or writing them down. Also, what happens when hard times come, regarding your values.

Tags: mikael-cho, value, company-value, analogy

Interview with Jesper Louis Andersen about Erlang, Haskell, OCaml, Go, Idris, the JVM, software and protocol design 

I’ve read this interview (part 1, part 2) to Jesper Louis Andersen, interviewed by Federico Carrone.

The first part is about a comparison of languages, what/why he uses them, and protocol design. The second is more about the Erlang language, the BEAM VM, and some experiences.

Tags: federico-carrone, erlang, interview, jesper-andersen, jesper-louis-andersen, haskell, ocaml, go, idris, the-jvm, protocol-design, software-design, language, functional-programming, protocol, land-of-lisp, northern-war

Migrating to Hugo From Octopress

I’ve read this guide by Nathan LeClaire on migrating the blog from Octopress to Hugo

Tags: static-site-generator, hugo, go, octopress, ruby, jekyll, nathan-leclaire, migration, blog, meta

Dynamic Static Site Generators strategies

I’ve read this article explaining what are static site generators, and an example with Jekyll. By Tim Nash

Tags: tim-nash, static-site-generator, jekyll, strategy, explanation, comparison

Blog like a confused hacker

I’ve read this article by Tim Nash on what tools he recomends for static site generation.

Tags: tim-nash, static-site-generator, jekyll, hide, strategy, explanation, comparison, sublime, wordpress, amazon-s3, cdn

Resolving the Frontend/Backend API Design Conflict

I’ve read this article that explains the “Backend for Frontend” (BFF) pattern, for solving the different needs of data depending on each device / client. By James Higginbotham

Tags: james-higginbotham, bff, pattern, backend-for-frontend, api, soa, microservice, frontend, backend, architecture

What If We Forget To Write The Tests?

I’ve read this article by J. B. Rainsberger on the trust issues related to starting to use a new methodology (TDD in this case) and how to see what impacts it might have in your day to day.

Tags: j-b-rainsberger, j-brains, rainsberger, tdd, motivation, team-management

API microservices, the Unix philosophy, and the Richardson Maturity Model - a practical perspective

I’ve read this article by Chris Hart on why startups and companies alike should be careful when choosing th latest technology and how this applies to microservices.

Tags: microservice, chris-hart, startup, analysis, company, technical-debt, bounded-context, ddd, rest-api

Effective programming

I’ve read this article by Sebastian Ferrari on the importance of clean code, systems thinking and functional programming.

Specifies the important difference between effectiveness and efficiency.

Links to this talk by Russ Ackoff. States the difference between “the right thing” and “the thing right”, by Drucker.

Tags: drucker, thing-right, right-thing, sebastian-ferrari, system-thinking, russ-ackoff, video, ted, difference, clean-code, functional-programming

Learning how to learn

I’ve read this article by James Kyle about the “how to learn” as one important skill for programmers and how having the solution at a few keystrokes limits / handicaps this ability.

Tags: programmer, learn-to-learn, james-kyle, stack-overflow, skill

Why do some functional programmers criticize design patterns in OOP languages as a sign of language deficiency, while Monad is also a design pattern?

I’ve read this answer by Edward Kmett comparing the design patterns in OOP to the design patterns in functional languages.

Tags: functional-language, object-oriented-language, edward-kmett, oop, pattern, monad, interface, quora, answer

Should We Even Debate Refactoring With Stakeholders?

I’ve read this article by J. B. Rainsberger on the power balance between stakeholders and programmers and how it can be inclined to a ‘more trust’ / ‘less trust’ by following some actions. The analogy is to a trade you cannot understand, therefore you have to hope that the taken decisions are in your best interest.

Tags: j-b-rainsberger, j-brains, rainsberger, refactor, business-need, communication, stakeholder

The Eternal Struggle Between Business and Programmers

I’ve read this article by J. B. Rainsberger on the discussion between business (‘we want more features, now’) and the programmers (‘we want more refactoring, now’). Concludes that both players need each other, in a symbiotic fashion, to keep their jobs at the company.

He suggests that Scrum cannot work without the XP practices and that we need to refactor aggressively after having finished our initial design, to keep the costs down. In fact, agreeing with both parts in this discussion.

References one of his own videos, at Oredev'13, “Fundamental Theorem of Agile Software Development”, where he describes the relationship between accidental / essential complexity in the cost of a feature, attributing most of it to accidental (‘we’re not good at our jobs’) and describing the need for more design / refactor after the initial design.

Tags: j-b-rainsberger, j-brains, rainsberger, refactor, business-need, design, oredev, talk, agile, xp, scrum, software-development, accidental-complexity, essential-complexity, mythical-man-month

Turning code to cash — How to make money as a Web Developer and live to tell the tale.

I’ve read this article by Kurt Rohlandt with a list of items to check while dealing with clients as a freelancer:

• Nothing is simple
• Know your skill set — and let your client know it
• Be clear about what they are buying
• Learn to use the best tool for the job
• To your client you’re more than just a developer
• Sign off your jobs

Tags: freelancer, kurt-rohlandt, list, tip, client

Test cases in inner classes with JUnit

I’ve read this answer in stackoverflow about nested test runners in JUnit

Tags: junit, stackoverflow, answer, nested-runner

Recording a Great Coding Screencast

I’ve read this article by John Lindquist where he explains how he sets up the recording environment for egghead.

Tags: john-lindquist, record, screencast, egghead, code-screencast, record-video, video

React Testing Course

I’ve watched the full course by Trevor D. Miller on how to test react components and the libraries to make it possible.

Tags: trevor-miller, online-course, screencast, mooc, react, flux, egghead

What Is Functional Programming?

I’ve read this article by Kris Jenkins where the author describes functional programming from an input & output point of view.

Describes state of the system (maybe global or local) is input & output of the function

Produced state changes are called side effects. the author calls the state inputs as “side causes”.

Side effects and causes are called complexity iceberg, as they are not visible under the water level (surface)

Also what a pure function is: one with no side causes or side effects; e.g., all its inputs are declared inputs (i.e., parameters) and all outputs are declared outputs (i.e., return value).

notes on jobbing programmer:

• at Becoming a Better Programmer, by Pete Goodliffe
• at Mastering Julia, by Malcolm Sherrington
• at What Makes a Good Programmer Good? by Josh Symonds

Tags: kris-jenkins, functional-programming, input, output, function, complexity-iceberg, pure-function, impure-function, side-effect, side-cause

Which Programming Languages Are Functional?

I’ve read this article by Kris Jenkins where the author analyses languages, determining whether they are functional or not.

Describes how functional languages deal with side effects and side causes, and to identify them (was also explained in part one¹).

Tags: kris-jenkins, functional-programming, side-effect, side-cause, comparison, haskell, clojure, python, perl, javascript, java, map, reduce, hof, scala, moc

Argument from the “Real World”

I’ve read this article by Ron Jeffries that dismantles the “real world”, as an excuse to use good practices: as in “we could use that, but we live in the real world”.

[…] our job is to create the “real world” and not to imagine that our present situation is the only situation there is

This is exactly our day to day task, to imagine a real world solution to present problems, maybe involving software in between.

Can’t we do this for product and team management?

Tags: ron-jeffries, agile, scrum, tdd, bdd, incremental-iterative-development, product-management, team-management

Self-Contained Systems

I’ve read these slides about a self-contained system (SCS), an architecture choice to split monolithic systems in parts. It includes the use of microservices in the business logic to solve domain specific problems. Written by Roman Stranghöner

development, operation and maintenance […] by a single team

Tags: big-bang-release, roman-stranghoner, self-contained-system, scs, microservice, monolith, monolithic-system, architecture

What Makes a Good Programmer Good?

I’ve read this article by Josh Symonds on the characteristics that differentiate a good programmer from the jobbing programmers, the list of skills to be a good programmer.

Explains what factors are related and not related to being a good one²:

• knowing that most programming problems have already been solved. You have to know where to look for the solution
• not to be afraid to dig deep into problems: detect a problem and be eager to solve it; figure out what is wrong
• go to the source: use the source as a fact, as analysis needs to be based on facts, not beliefs
• just do it: to be driven to act
• instinctively tackle problems head-on, grabbing the bull by the horns instead of waiting for it to be solved automagically; start solving the problem
• excited about grabbing problems, about facing the cutting edge
• taking the time to reflect and understand it before moving one to the next one
• communicate well: succintly and eloquently expressing your thoughts. The author thinks this might be the most important aspect of all.
• to be truly caring about what you do: not just a job, but a hobby, an interest, even a fascination; great programmers are always programming
• thinking of programming of a way to shape the world, not just a money-making activity

Tags: jobbing-programmer, good-programmer, career, career-management, skill, josh-symonds, quote

The Best Programming Language (or How to Stop Worrying and Love the Code)

I’ve read this article by Álvaro Castro-Castilla analysing different programming languages and what to choose each of them.

Tags: alvaro-castro-castilla, programming-language, language, analysis, comparison

Tomates en el campo

I’ve read this article by Ángel Medinilla, about how to cultivate teams, instead of creating or building them. Talks about the mandatory conditions, necessary factors and how to enable it, not guaranteeing success.

Tags: angel-medinilla, team-management, spanish, team, analogy

Default constructors in Java

I’ve read this answer in stackoverflow about extending a java class that has a private constructor.

Tags: stackoverflow, answer, java, constructor, syntax

What’s So Great About Reducers?

I’ve read this article by Guillermo Winkler explaining reducers, a type of divide and conquer strategy clojure.

Tags: guillermo-winkler, reducer, clojure, parallelism, concurrency

Don’t use Slack?

I’ve read this article by Christian Heilmann about the relation between open / closed software and accessibility.

Tags: slack, christian-heilmann, accessibility, open-source, propietary-software, closed-source

Towards an understanding of technical debt

I’ve read this article by Kellan Elliott-McCrea about some definitions of technical debt and why taking care of it matters for the future.

Talks about the way of inheriting projects by other teams and the paradox of “investing more time to fix the problem than originally invested in coding it.” Also about judgement.

I find it related to the “theory building” by Naur.

There are at least 5 distinct things we mean we say “technical debt”.

1. Maintenance work: buying breathing room
2. Features of the codebase that resist change
3. Operability choices that resist change
4. Code choices that suck the will to live
5. Dependencies that resist upgrading

Tags: kellan-elliott-mccrea, kellan, technical-debt, list, definition, quote

Lifetimes of cryptographic hash functions

I’ve read this article by Valerie Aurora where she explains the lifetimes of cryptographic hash functions up to 2012.

Tags: hash-function, valerie-aurora

Collisions for Hash Functions - MD4, MD5, HAVAL-128 and RIPEMD

I’ve read this paper that explains some collisions found for MD4, MD5, HAVAL-128 and RIPEMD. By Xiaoyun Wang, Dengguo Feng, Xuejia Lai, Hongbo Yu.

Tags: collision, hash-function, xiaoyun-wang, dengguo-feng, xuejia-lai, hongbo-yu, paper

The future is parallel: What’s a programmer to do?

I’ve read these slides by Guy Steele about the differences in linear vs parallel computing and about the old habits that we still have.

Some quotes:

Motivation

• Good sequential code minimizes total number of operations.
  • Clever tricks to reuse previously computed results.
  • Good parallel code often performs redundant operations to reduce communication.
• Good sequential algorithms minimize space usage.
  • Clever tricks to reuse storage.
  • Good parallel code often requires extra space to permit temporal decoupling.
• Sequential idioms stress linear problem decomposition.
  • Process one thing at a time and accumulate results.
  • Good parallel code usually requires multiway problem decomposition and multiway aggregation of results.

A New Mindset

• DO loops are so 1950s! (Literally: Fortran is now 50 years old.)
• So are linear linked lists! (Literally: Lisp is now 50 years old.)
• Java-style iterators are so last millennium!
• Even arrays are suspect!
• As soon as you say first, SUM = 0 you are hosed. Accumulators are BAD.
• If you say, “process subproblems in order,” you lose.
• The great tricks of the sequential past DON’T WORK.
• The programming idioms that have become second nature to us as everyday tools DON’T WORK.

The Parallel Future

• We need new strategies for problem decomposition.
• Data structure design/object relationships
• Algorithmic organization
• Don’t split a problem into “the first” and “the rest.”
• Do split a problem into roughly equal pieces. Then figure out how to combine general subsolutions.
• Often this makes combining the results a bit harder.
• We need programming languages and runtime implementations that support parallel strategies and hybrid sequential/parallel strategies.
• We must learn to manage new space-time tradeoffs

Conclusion

• A program organized according to linear problem decomposition principles can be really hard to parallelize.
• A program organized according to parallel problem decomposition principles is easily run either in parallel or sequentially, according to available resources.
• The new strategy has costs and overheads. They will be reduced over time but will not disappear.
• In a world of parallel computers of wildly varying sizes, this is our only hope for program portability in the future.
• Better language design can encourage better parallel programming.

Tags: representation, computation, catamorphism, list, associativity commutativity, idempotency, abstract-data-type, slide, operator, mapreduce, mindset, comparison, parallel, guy-steele, linear-computing, parallel-computing

Surviving being senior (tech) management.

I’ve read this article by Kellan Elliott-McCrea about the basic things to do as management to retain the best performance:

• exercise
• someone to talk to
• discuss with peers, in petit commité
• personal mastery project

Tags: kellan-elliott-mccrea, kellan, list, management, tip, exercise, pet-project

You Don’t Need More Free Time

I’ve read this article about the quality of life, work-life balance by Cristobal Young on why the time where we have more fun is spent together, in company.

Tags: cristobal-young, time-management, work-life-balance

Taking Longer to Reach the Top Has Its Benefits

​I’ve read this article that explains how having work life balance and preventing burn out syndrome, aided by a patient career, can help with reaching a higher destination on your career. By Karen Firestone

Tags: career-management, patience, burnout, burn-out, ceo, karen-firestone, professional-career, improvement

All bugs lead to Rome

I’ve read this article that explains how the author tracks down a bug present in mail communication, just for a handful of client. By Nick Baum

Tags: track-down, bug, defect, mailgun, rot13, nick-baum

Design Patterns — Coming Full Circle

I’ve read this article that explains what a design pattern is, where does it come from, the figure of Christopher Alexander and the architecture design patterns. By Jen Carlile

Tags: design-pattern, christopher-alexander, jen-carlile, comparison, example, proxy, command, observer

React + Performance = ?

I’ve read this article by Paul Lewis comparing the performance and developer experience of react.js and vanilla js.

Conclusion: under his measurements, react is too slow once the amount of elements is big on mobile devices

Tags: paul-lewis, comparison, javascript, react, mobile, perfomance, jsperf, js-perf, vanilla-javascript

Full speed, then stop, gracefully

I’ve read this article about how to end professional relationships with an employer or a team.

Makes an analogy to the hockey sport attitude: “full speed, then stop”

Tags: seth-godin, professional, employer, team-management, team, analogy

Por qué tendrás que facturar 55.000€ para cobrar una nómina de 26.000€

I’ve read this bonilista by David Bonilla on why freelancers need to bill more to clients to achieve the same (economic) results as being hired by a company.

Tags: david-bonilla, bonilista, freelancer, contractor, employee

Principles Of Microservices

I’ve watched this talk by Sam Newman on microservices at the NDC 2015 at Oslo

Describes a microservice as a small, autonomous services that work together, modelled around a business domain

Microservices can mix technology, persistence stack, idioms, options

reference to the twelve factors (by heroku).

At a client:

Design and delivery practices:

• standard http/rest
• encapsulate legacy
• eliminate integration databases
• consolidate and cleanse data
• published integration model
• small independent devices
• continous deployment
• minimal customization of COTS/SAAS

Architectural principles:

• reduce inertia
• eliminate accidential complexity
• consistent interfaces and data flows
• no silver bullets

Strategic goals:

• enable scalable businesses
• support entry into new markets
• support innovation in existing markets

Principles of microservices:

• modelled around a business domain
• culture of automation
• hide implementation details
• decentralise all the things
• deploy independently
• consumer first
• isolate failure
• highly observable

Notes

the business domain changes more slowly. find these boundaries (reference to IDDD)

bounded contexts is about concepts which are shared and others who are hidden

consumer driven contracts as a way to express to consumer expectations, written as tests. this is a high-trust pattern (requires it). reduces end to end testing, considerably. Using tools as pact

parallel change for endpoints (or APIs) for avoiding lock step release (expand contract pattern). high cost to change an API: apply upfront thought to it.

explains about a case writing a strangler application:

• circuit breakers
• one thread pool per application
• bulkhead downstream connections

references:

• the book “Release It!”
• the book “Implementing Domain-Driven Design (IDDD)”

Other

correlation ids, parent and child ids extracting information from logs (e.g., kibana, splunk, new relic) see how services connect to each other based on logs instead of based on documentation

Tags: lock-step-release, autonomy, sam-newman, consumer-driven-contract, team, zookeper, etcd, consul, service-discovery, distributed-consensus, talk, ndc, humane-registry, bulkhead-pattern, circuit-breaker

The Website Obesity Crisis

I’ve read this transcription of this presentation about the increase of weight of websites and how this connects with new needs for automation and other services. How the solution is to keep the pages lightweight and open for everybody to use and learn; without invading our privacy. By Maciej Ceglowski

Tags: obesity, fat-page, slide, transcription, slide-transcription, maciej-ceglowski, simplicity, speed

Command-line tools can be 235x faster than your Hadoop cluster

I’ve read this article on how using command-line based (find, grep, awk) can have a better performance as compared to Hadoop for a specific case, which is analyzing 2 million chess games. By Adam Drake

Tags: adam-drake, chess, comparison, performance, cli-commands, unix, nix, hadoop, awk

The Serializable Isolation Level

I’ve read this article by Paul White about the serializable isolation level and how it is implemented in some databases.

Tags: serializable, isolation level, paul-white, oracle, mssql, database, sql

Academic Writing With Markdown, Pandoc and Emacs

I’ve read this article by Milinda Pathirage that explains an alternative way of writing LaTeX in a user-friendly manner, writing markdown then converting it to the output format (he provides such a script).

Tags: latex, milinda-pathirage, academia, research, paper, markdown, script

Rest, DDD, layers, JSF, microservices sizing a Umejug conversation

I’ve watched this talk by Adam Bien on topics related to microservices and architecture. Discusses:

• What do you think a typical web application should look like? How should it be built?
• When using REST, which level of REST is appropriate when, is HATEOAS something to strive for, how to implement it?
• Which patterns do you recommend, hexagonal architecture, layers, …?
• What do you think of the DDD strategic and tactical patterns?
• Microservices vs right-sized services, is transactions over several services always a bad idea?
• When use JSF? Is it still useful?
• Entity-Control-Boundary Pattern (ECB) (around 16:37). More info on the pattern

Tags: hateoas, rest, microservice, pattern, architecture, umejug, hexagonal-architecture, ddd, adam-bien, ecb-pattern, mvc-pattern

How To Go Remote

I’ve read this article by Sebastian Kade that explains how to go remote: where the possibility of working anywhere is a luxury, even if it is in an office.

Explains the case of Automattic, some examples of communication, culture. Suggests using some tools to accomplish this cultural change.

Tags: remote-work, sebastian-kade, remote, work, asynchronous-communication, communication, automattic, tool, culture, team-management

Why Your Company Should Have a Creed

I’ve read this essay by Matt Mullenweg about the importance of having a company creed (a belief system, ethos), which ideally would be shared by the colleagues. These should be the values that help deciding, when in doubt, so everyone is aligned.

At Automattic, this is theirs (as of September 19th, 2011):

I will never stop learning. I won’t just work on things that are assigned to me. I know there’s no such thing as a status quo. I will build our business sustainably through passionate and loyal customers. I will never pass up an opportunity to help out a colleague, and I’ll remember the days before I knew everything. I am more motivated by impact than money, and I know that Open Source is one of the most powerful ideas of our generation. I will communicate as much as possible, because it’s the oxygen of a distributed company. I am in a marathon, not a sprint, and no matter how far away the goal is, the only way to get there is by putting one foot in front of another every day. Given time, there is no problem that’s insurmountable.

Tags: quote, matt-mullenweg, automattic, creed, ethos, learning, team-management, startup, communication, essay

Mob Programming: The Unruly Experience

I’ve read this article by Rebecca Wirfs-Brock on mob programming and the experience report (+ slides) at the company called Unruly.

She explains what works for them and what does not.

Also, she makes a difference on complex vs complicated work:

complex work (where there is the potential for errors) over complicated work (where the solution is known, but is merely time consuming)

Explains some characteristics of learning organizations:

Teams in learning organizations perform ongoing experiments. While they settle on a core set of practices, they also try to build upon them. They keep innovating, improving, and reflecting. And how they work continues to evolve.

Tags: learning, learning-organization, xp, rebecca-wirfs-brock, mob-programming, pair-programming, complex-work, complicated-work, experience-report, unruly, team-management, team-building, team-dysfunction, comparison

What You’re Hiding from When You Constantly Check Your Phone

I’ve read this article by Charlotte Lieberman where she explains the technology-stress paradox and the fact of replacing one addiction with another, as some addictions are more socially than others.

Explains that the constant connection to social media allow us to avoid ourselves, and the connection to mindfulness.

On the paradox:

technology-stress paradox: we share the desire for greater freedom from our devices, and yet that very freedom itself causes anxiety

On the work-life balance:

work-life balance [is] […] about noticing those moments in which you really don’t want to deal with yourself

Tags: charlotte-lieberman, paradox, quote, social-media, mindfulness, technology-stress-paradox, stress, addiction, time-management

Testing myth #1: Writing tests slows you down

I’ve read this article by Arho Huttunen on an excuse to not test: there is no time.

In the article, he explains the false assumptions based on that reason and the gains (short term and long term) from doing it.

Tags: arho-huttunen, test, excuse

BeCodeWeek by José Manuel Beas

I’ve read this category of posts by José Manuel Beas about his BeCodeWeek, a desk-surfing experience at BeCode.

Analyses facts and publishes one entry per day detailing his activities.

Tags: becodeweek, jmbeas, jose-manuel-beas, desk-surfing, experience, experience-report, analysis

Books I’ve read this quarter¹:

• Practical Object-Oriented Design in Ruby, An Agile Primer (POODR) by Sandi Metz, with the ‘@deAprendices’s reading club’. Blog posts under the tag poodr.

Books started, not yet finished (WIP):

• Haskell Programming, By Chris Allen and Julie Moronuki. This book is still in progress and I’m reviewing it
• Pragmatic Thinking and Learning: Refactor Your Wetware by Andy Hunt
• Structure and Interpretation of Computer Programs by Abelson, Sussman, and Sussman, with the ‘@deAprendices’s reading club’. Blog posts under the tag sicp.

Books I want to finish:

• The Leprechauns of Software Engineering by Laurent Bossavit, again. Gift
• Functional Programming Patterns in Scala and Clojure by Michael Bevilacqua-Linn

Books that have entered the queue:

• Programming Languages: Application and Interpretation by Shriram Krishnamurthi
• Doing Math with Python by Amit Saha. Gift from the PyConEs 2015
• Perfect Software: And Other Illusions about Testing by Gerald M. Weinberg
• Building Microservices, Designing Fine-Grained Systems by Sam Newman
• Computability and Complexity - From a Programming Perspective by Neil Deaton Jones
• Thinking Forth: a language and philosophy for solving problems by Leo Brodie
• Concepts, Techniques, and Models of Computer Programming by Peter Van Roy and Seif Haridi
• Bridging the Communication Gap by Gojko Adzic
• Specification by Example by Gojko Adzic
• The Cucumber book by Matt Wynne and Aslak Hellesøy
• Software Architecture for Developers by Simon Brown
• Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock and Alan McKean
• Readings in Database Systems, 5th Edition by Peter Bailis, Joseph M. Hellerstein, Michael Stonebraker, editors

At a client, we have CSVs of data that can be simplified to this ¹:

(def data [
           ["total" 6 8 13]
           ["0"     1 2 3]
           ["0"     2 0 4]
           ["0"     3 0 6]
          ])

In this case, some of the row named total is the sum of the rest of the rows, but only for some columns (second and fourth). We do not want to get rid of the columns, as they need to be printed at the end.

This is what we need to validate:

sum (rest [1]) = total [1]

sum (rest [3]) = total [3]

this could be written as a one-off program but a better alternative for us was to write a program and let users decide what columns to validate. In the future, power users will write their own validations ², thus creating an environment where users are no longer dependent on programmers as coupling business users to programmers does not scale.

Implementation

The full source code is here

(defn sum-eq-total [selector dataset]
  (letfn [(total-and-rest [coll]
             [(first coll) (rest coll)])]
  (let [[total rest-dataset] (total-and-rest dataset)
        selected-total (selector total)
        selected-column (map selector rest-dataset)
        sum-of-column (reduce + selected-column)]
        (= selected-total sum-of-column))))

(defn validate-columns [indices data]
  (let [generate-selector #(fn [dataset] (nth dataset %))
         selectors (map generate-selector indices)
         check-selector #(sum-eq-total % data)]
         (map check-selector selectors)))

We define the domain concept of selector for pointing to a dataset column

generate-selector #(fn [dataset] (nth dataset %))

This expression creates selectors based on a given index. It is a lambda that returns a function, thus being a HOF

Users can use the application in this fashion:

simple.core=> (validate-columns [1 3] data)
(true true)

The full source code is here

Conclusion

Working on the REPL for this problem has been a very good idea, but working in a spreadsheet software has been even better. Even faster feedback cycle ³.

The inclusion of the HOF for validating the data has paid its cost (good RoI)

Do not limit what your users can do, let them decide but do not complicate things unnecessarily. Know when to stop adding features and limit work to prevent YAGNI.

While on the REPL, I tried this:

simple.core=> (reduce and true [true])
CompilerException java.lang.RuntimeException: Can't take value of a macro: #'clojure.core/and, compiling:(form-init7116694665186998245.clj:1:1)

Reading the clojuredocs for and, you can find this:

Note add is a macro, so you cannot apply it. For example, there is a vector of some Boolean values [true true false true], which you want to test to see if they are all true. The code below will not work:

(apply add [true true false true]) ;won’t work

Instead, use this:

(every? identity [true true false true])

I tried it with success. Digging a bit deeper:

simple.core=> (defn all-truthy? [& elements] (every? identity elements))
#'simple.core/all-truthy?
simple.core=> (all-truthy? nil false)
false
simple.core=> (all-truthy? nil 0)
false
simple.core=> (all-truthy? nil 1)
false
simple.core=> (all-truthy? 2 1)
true
simple.core=> (all-truthy? [nil false])
true

Was also tempted to try this:

simple.core=> (reduce (fn [acc element] (and acc element)) true [true true false true])
false
simple.core=> (reduce (fn [acc element] (and acc element)) true [true true true true])
true

Encapsulate it into a function:

simple.core=> (defn all-true [& elements] (reduce (fn [acc element] (and acc element)) true elements))
#'simple.core/all-true
simple.core=> (all-true true)
true
simple.core=> (all-true true false)
false
simple.core=> (all-true true false true)
false

What happens with the non-boolean values?

simple.core=> (all-true 1 2 3)
3
simple.core=> (all-true 1 2 3 76)
76
simple.core=> (all-true 1 2 3 64)
64
simple.core=> (all-true 1 2 3 64)
64

This is because:

simple.core=> (and 64 3)
3
simple.core=> (and 3 64)
64

Conclusion

all-truthy? exploits the falsy values in clojure (nil, false), while all-true uses the true boolean values, although the function does not work properly with non-boolean values (i.e. its domain is the booleans)

Appendix A: Source code

and:

simple.core=> (source and)
(defmacro and
  "Evaluates exprs one at a time, from left to right. If a form
  returns logical false (nil or false), and returns that value and
  doesn't evaluate any of the other expressions, otherwise it returns
  the value of the last expr. (and) returns true."
  {:added "1.0"}
  ([] true)
  ([x] x)
  ([x & next]
   `(let [and# ~x]
      (if and# (and ~@next) and#))))

identity:

simple.core=> (source identity)
(defn identity
  "Returns its argument."
  {:added "1.0"
   :static true}
  [x] x)

every:

simple.core=> (source every?)
(defn every?
  "Returns true if (pred x) is logical true for every x in coll, else
  false."
  {:tag Boolean
   :added "1.0"
   :static true}
  [pred coll]
  (cond
   (nil? (seq coll)) true
   (pred (first coll)) (recur pred (next coll))
   :else false))

->:

simple.core=> (source ->)
(defmacro ->
  "Threads the expr through the forms. Inserts x as the
  second item in the first form, making a list of it if it is not a
  list already. If there are more forms, inserts the first form as the
  second item in second form, etc."
  {:added "1.0"}
  [x & forms]
  (loop [x x, forms forms]
    (if forms
      (let [form (first forms)
            threaded (if (seq? form)
                       (with-meta `(~(first form) ~x ~@(next form)) (meta form))
                       (list form x))]
        (recur threaded (next forms)))
      x)))