Daily reads

This is how I keep myself informed.

I have a bookmark directory that contains sites that I read daily. It contains my RSS feed reader, a left wing site, a right wing newspaper, my stock broker site, and the main programming, computer science and Magic related subreddits. These are reads all year long.

Then, there are seasonal stuff. Currently, I have MTGSalvation deck creation forum bookmarked so I can read what other people are brewing for the next standard season. This will stay until the end of April, when it stop being relevant. I also usually include a site for something I’m trying to achieve: currently is stop smoking, which I regretfully do. It will stay until I stop smoking.

Random Spikes

Arlinn Kord was a card that I was really excited to see, because I though it would be great. Turns out it is amazing.

Magic’s storytelling has actually improved greatly from the “Ashaya” levels in Zendikar.

Password Hashing. Sometimes you need it!

Level One course by Reid Duke. One of the greatest Magic players, Reid teaches the basic concepts of the game.

At the end of this article, you’ll find Frank Harstem’s list of card clusters that may be a big deal after Khans rotation.

Evaluating FPGA able applications.

Dealing with the tilt.

Evaluating cards from Shadows Over Innistrad

Some general guidelines for evaluating them, with needed context to improve their value.

Double-faced cards. Depends on the transform condition, but are usually good when easy to transform, or you drafted a werewolf deck. In constructed, werewolves seem bad because they are usually not efficient until transformed, but some cards have decent conditions to transform.

Delirium. It’s easy in limited to get to three card types in the graveyard – creature, sorcery and instant. The fourth seems really hard, specially when the basic land fetcher costs two to activate. If there’s land sacrifice or good discard outlets, the mechanic gets good. It seems fit for constructed.

Madness. It’s generally mad, but also requires discard outlets. Maybe there’s a deck with discard, delirium and madness.

Skulk. It’s bad evasion unless there are pump effects at instant speed, that can be played after blocks are declared.

Random Spikes

BBD writes a compelling article on R/G Tokens (OGW). Going wide is one of the strategies I like the best; I’m on Abzan (WBG) Tokens for OGW, which is a bit less wide, but taller, and it’s doing great at FNM. Nissa is the real deal, and I should try her next week.

Sprints that don’t ship code. It’s hard to slice the project into shippable bunches when most of the code is not user facing (like embedded systems), so an architectural sprint can facilitate other sprints to deliver value to the user.

The financial struggles of a Magic player.

How to build stable systems has a lot of common sense, and is a very nice read.

Dealing with burnout.

Interested in Magic, but a $1k deck does not fit your budget? Here’s a primer on Pauper, a format where we play only common cards (and is usually very inexpensive to play). And here’s a curated list of Pauper decks.

Eerie Interlude is a very exciting card in a deck that abuses enter the battlefield effects. Brewing will start soon.

Unit testing and code coverage

Scenario 1. A developer writes the code and some unit tests, then submits it to integration and receives a report that the coverage of his tests is low. He writes code to fix it.

Scenario 2. A developer writes the code and some unit tests. The unit tests test the functionality as implemented. He receives the report that the coverage is low. He writes more tests cover some corner case he missed in the first place.

Scenario 3. The developer writes the unit tests to cover a given functionality, then writes the code to execute the functionality. He receives the same report as the others, and removes dead code from the functionality.


The stories above represent three scenarios in which unit testing production falls.

The first one is the weekend project: write the code and hope for the best. This is clearly bad, because it show a lack of planning, and a disregard for real quality.

The second is the post production test: the developer writes the functionality and then writes the test according to what he wrote. This a a pernicious pattern of work, because it assumes that the code implements the specification correctly. Sometimes it does, but the pattern will not find when it doesn’t.

The third pattern is correct. The tests form the semi-formal specification of the functionality, and the code is written to reflect it – the tests will detect if it doesn’t.


The stories above also show the way code coverage is seen in each tier. In the first scenario, the code coverage is seen as something to be achieved. It’s usually seen as a burden that the developer must endure, something that hinders his productivity but is required from his manager and comes from the developers overconfidence or immaturity (it’s fine to be immature if you’re just came out the university gates – senior developers exist to guide you).

The second and third see code coverage as a source of improvement. The second sees it as a way to improve the testing. The third sees it as way to improve what’s being produced.


Overall, the third mode leads to improvement in quality, the second guarantees that the functionality doesn’t change unexpectedly during maintenance, and the first one leads to none of those – to be fair, it at least  improves the chances that crashes don’t happen.