apostergiou

System Design Cheatsheet

Picking the right architecture = Picking the right battles + Managing trade-offs

Basic Steps

1. Clarify and agree on the scope of the system

• User cases (description of sequences of events that, taken together, lead to a system doing something useful)
  • Who is going to use it?
  • How are they going to use it?

apostergiou

require 'rack'

class HelloWorldApp
  def self.call(env)
    # 200 is the HTTP status code
    # the second element is the response HTTP header hash
    # finally the last element is the response body
    ['200', {'Content-Type' => 'text/html'}, ['A hello world rack app.']]
  end
end

apostergiou

Data from [https://snowflake.medium.com/]

Engineering growth: tracks

Table of Contents

• Mobile
  • Works effectively within established iOS or Android architectures, following current best practices
  • Develops new instances of existing architecture, or minor improvements to existing architecture
• Designs major new features and demonstrates a nuanced understanding of mobile platform constraints

apostergiou

Fixes T0001: link

Purpose

Manual testing

Notes for the reviewers

Background context

apostergiou

/*
********************************************************************************
Golang - Asterisk and Ampersand Cheatsheet
********************************************************************************

Also available at: https://play.golang.org/p/lNpnS9j1ma

Allowed:
--------
p := Person{"Steve", 28} 	stores the value

apostergiou

Project title

A little info about your project and/ or overview that explains what the project is about.

Motivation

A short description of the motivation behind the creation and maintenance of the project. This should explain why the project exists.

Build status

Build status of continus integration i.e. travis, appveyor etc. Ex. -

apostergiou

Pull Request Etiquette

Why do we use a Pull Request workflow?

PRs are a great way of sharing information, and can help us be aware of the changes that are occuring in our codebase. They are also an excellent way of getting peer review on the work that we do, without the cost of working in direct pairs.

Ultimately though, the primary reason we use PRs is to encourage quality in the commits that are made to our code repositories

Done well, the commits (and their attached messages) contained within tell a story to people examining the code at a later date. If we are not careful to ensure the quality of these commits, we silently lose this ability.

apostergiou

1. Install spf13-vim

sh <(curl https://j.mp/spf13-vim3 -L)

2. Install Go bundle

echo "let g:spf13_bundle_groups=['general', 'neocomplete', 'programming', 'ruby', 'python', 'go', 'javascript', 'html', 'misc', 'writing' ]" >> ~/.vimrc.before.local 

apostergiou

Originally published in June 2008

When hiring Ruby on Rails programmers, knowing the right questions to ask during an interview was a real challenge for me at first. In 30 minutes or less, it's difficult to get a solid read on a candidate's skill set without looking at code they've previously written. And in the corporate/enterprise world, I often don't have access to their previous work.

To ensure we hired competent ruby developers at my last job, I created a list of 15 ruby questions -- a ruby measuring stick if you will -- to select the cream of the crop that walked through our doors.

What to expect

Candidates will typically give you a range of responses based on their experience and personality. So it's up to you to decide the correctness of their answer.

apostergiou

Find out method definition

foo = Object.new
p foo.method(:bar).source_location

Bundle open