(Database) Transactions should be used modestly

It is good practice to leave your database in a consistent state. There are different ways to do this. Foreign key constraints, indexes, typing of columns, are all strategies to keep your database in a consistent state. Transactions are another way providing you a tool to keep the database consistent: if one of the inserts or updates fail, your database will rollback to the state before the first in the series of inserts and updates within that transaction.

Some languages make it really simple to create a transaction. In Ruby on Rails it is simply opening a block:

User.transaction do
  ## ... all db operations are now in a transaction
end

But be cautious; transactions don't come for free: they lock the table or row, which is bad for performance. It can, by design, stop other processes from updating the same rows. And all this gets worse when transactions take longer, when for example they contain request to remote resources.

Hence, my approach to transact…

Bad CSS in JS

I tried to understand the argument made for styled components vs. ‘traditional’ CSS. But when reviewing these arguments I found out that they typically use bad code as proof for their point.

See e.g. the following SCSS code:

$blue = #5DBCD2;

@mixin button-styles($bg-color, $color) {
  background: $bg-color;
  color: $color;
  border: none;
  border-radius: 0.20em;
  &:hover{
      background: darken($bg-color, 6%);
      cursor: pointer;
  }
}

.button {
  @include button-styles(#ddd, black)
}

.button--primary {
  @include button-styles($blue, white)
}

To pair with a simple component along the lines of:

const Buttons = props => (
  
    Default
    Primary
  
)
export default Buttons

The suggested alternative is:

import themeVars from "myTheme"
import styled from "styled-components"
import { darken } from "polished"

const B...

“If something is too complex to understand, it must be wrong”

While looking for the source of another quote (something along the lines of “If it takes you too long, you're probably doing it wrong”, which I recall having picked up in the Rails community (if you recognize it, please let me know)) I found the following bold statement. We're not talking science here, we're talking software development (actually this guy is talking Java Spring development):

> “If something is too complex to understand, it must be wrong”

from Arjen Poutsma

Some background on this quote can be found on this Xebia website.

Yep, I'm working on a project that seems to have grown way too complex for what it actually should have been.

Happy coding ;)

Why I stopped using OpenOffice.org

As promised. There was a time when I was a true OpenOffice.org fanatic. I even helped actively promoting it by redesigning the homepage . Although I'm still a fan of opensource and open document
storage which ideally should lead to a world in which anyone can use
open software and exchange documents freely without any barriers. Still, I'm no longer typing this in opensource software. I'm typing this in Google -how evil- Docs (update may 2017: Google Docs has been replaced by Apple's notes and iAWriter / Notational Velocity, the latter being markdown based).

It's not that I'm a big fan of Google Docs, but it makes a difference that OpenOffice.org, and other Office systems for that matter, aren't able to make. Not stand alone, nor in a usable way in combination with a proper operating system:

• Relieving me from worrying about storage
• Boot insanely fast (…