View waffle-recipe.md

Waffle Making for Engineering Teams

ricardo team waffles

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

View why-not-to-cache.md

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

View domain-driven-desire-resources.md

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

View ricardo-learning.md
View tamedia-freelance.md

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

View interview-engineers.md

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

View why_utc.md
  • 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 :)
View music-dsl.rb
# song definition
tempo 120
# bassline
instrument :bass, channel: 2 do
preset 'bass/fender_jazz_clean'
end
View osx-setup.sh
#!/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
View presenters.md

Thoughts about Rails Presenters

This is a collection of links, examples and rants about Presenters/Decorators in Rails.


The "Decorator" pattern slowly started gaining popularity in Rails several years ago. It is not part of core Rails, and there's many different interpretations about how it should work in practice.

Jay Fields wrote about it in 2007 (before he switched back to Java and then Clojure): http://blog.jayfields.com/2007/03/rails-presenter-pattern.html