somebox

#include <Arduino.h>
#include "ESP8266WiFi.h"
#include "SPI.h"
#include <NTPClient.h>
#include <WiFiUdp.h>

/*

A large four digit 7-segment LED clock, controlled by an ESP8266. 
The LED modules are quite large, 5" tall, and require high voltage to drive the many

somebox

Waffle Making for Engineering Teams

The art of making waffles is very similar to the challenges in team software development. Things have to be prepared on time, and instructions have to be followed. The mixing and cooking seem fairly simple, but it's a repetative and unforgiving task, and in the end you have to ship.

As a one-person exercise, it's fairly easy. But when you scale things up, it gets complicated. Several people working together cannot simply "make waffles". They have to coordinate and divide up the work. And to make waffles for a lot of people, you need multiple waffle irons, mixing stations, and serving.

The challenge for a team is how to organize themselves into assembly steps. At one station, some engineers melt the butter, crack eggs, and mix things. At the same time, another group prepares the dry ingredients, measuring properly. The output of the two streams mus

somebox

Why NOT to Cache

I’ve worked over the years on a lot of projects, with many teams. Frontend, backend, mobile, and so forth. One topic that always comes up - caching. Developers love to talk about the topic, and are excited to add seemingly low-cost performance enhancers to their architecture and code base. However, as Martin Fowler and many others have pointed out, caching is evil. It’s one of the hardest problems in computer science to solve.

The typical pattern is to take a slow request - say, an API response - and store it in a local cache (perhaps to disk, or Redis). The implementation goes like this: the simple approach is to do a get/set cache lookup. When the user needs the data, check if it’s in the cache. If it’s not, or it has expired, then fetch the latest value and store it in the cache.

For apps, one side effect of this approach is degraded experience for some small group of users. For example, a web app needs to access a slow resource that takes 2 seconds to respond. With caching used, tha

somebox

Domain-Driven Desire: The Talk from Øredev 2016

🎥 https://vimeo.com/191051851

Links and References

Thanks for watching my talk, Domain-Driven Desire at Øredev 2016. Here's a list of resources that inspired me, and will hopefully inspire you:

Videos

somebox

Links and References

... my shameless comments added, make up your own mind :)

Videos

• 🎥 Agile 2016 (Dan North) - Where we are today with agile, where we can from, cross-functional, organizing, and getting it right.
• 🎥 Fred George on Microservices - rants, rants, rants
• 🎥 Microservices at NetFlix Scale - great talk
• 🎥 Domain-Driven Design: The Good Parts - a bit slow but good overview of DDD in practice

somebox

Tamedia Digital - Freelance Opportunities

Jeremy Seitz, Tamedia Core Engineering, Oct 2016

About Tamedia Digital and Core Engineering

Tamedia is the company behind many well-known online Swiss brands, such as 20min, Starticket, Ricardo, Doodle, Homegate, and many others. Core Engineering is a small expert tech consulting group that serves these companies, working closely with engineering teams across the company. Through project work, architecture, training, events, and providing resources, we help the companies of Tamedia bring speed and agility to their engineering efforts.

A Growing Freelance Network

One of the functions of Core Engineering is to build relationships with freelancers and tech agencies in Switzerland. We make it easier for freelancers to work with the different companies in Tamedia, through close collaboration, simplifying contract and billing processes, more flexible placement, access to services and resources, and communication with key contacts across the organizatio

somebox

Note: This is an opinionated guide. While it is most effective for on-site, the same pattern can work with remote candidates.

How To Interview Engineers

Interviewing is hard. It's not easy to find good people, and once you do, it's often difficult to find out what they can do and how they work. A badly-run interview can pass over a great engineer. Conversely, some engineers are good at passing traditional tech interviews, but bring major problems with work habits or team fit.

The first priority of any manager is to hire the best people. Everything else must wait.

Screening

somebox

• UTC is best practice http://stackoverflow.com/questions/2532729/daylight-saving-time-and-time-zone-best-practices
• DST changes can causes issues with things like opening hours, publication dates on contracts, etc... UTC helps avoid this
• embrace the pattern: UTC on systems and APIs, TZ display in UI/UX and outputs
• integrations with partners, 3rd-party services (think Amazon, Google Cloud computing, pub/sub services, filepicker... all will use UTC)
• you trade "easier to think about" for "subtle bugs and weird test fails" in the future
• people assuming we're standard UTC like the rest of the world might set up servers/services in CEST and be off by an hour (past example: localina!)
• someday you will work for a company that does things outside of Switzerland. You should learn this :)

somebox

# song definition

tempo 120

# bassline

instrument :bass, channel: 2 do
  preset 'bass/fender_jazz_clean'
end

somebox

#!/bin/bash

# A script to set up a new mac. Uses bash, homebrew, etc.

# Focused for ruby/rails development. Includes many utilities and apps:
# - homebrew, rvm, node
# - quicklook plugins, terminal fonts
# - browsers: chrome, firefox
# - dev: iterm2, sublime text, postgres, chrome devtools, etc.
# - team: slack, dropbox, google drive, skype, etc