I hereby claim:
- I am simonpeterdebbarma on github.
 - I am simonpd (https://keybase.io/simonpd) on keybase.
 - I have a public key ASAmd2hA92583MsfOfh2utdLfpPdqhWyXgJComjPXC3x-Ao
 
To claim this, I am signing this object:
I hereby claim:
To claim this, I am signing this object:
I was at Amazon for about six and a half years, and now I've been at Google for that long. One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.
I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out. And their operations are a mess; they don't real
You're taking your first steps into Ruby
A good introduction to programming in general. Easy on newer programmers.
| <body> | |
| <div class="canvas"> | |
| <div class="whitey-beak"></div> | |
| <div class="yellow-beak"></div> | |
| <div class="whitey-tail one"></div> | |
| <div class="whitey-tail two"></div> | |
| <div class="yellow-tail"></div> | 
Design patterns are solutions to recurring problems; guidelines on how to tackle certain problems. They are not classes, packages or libraries that you can plug into your application and wait for the magic to happen. These are, rather, guidelines on how to tackle certain problems in certain situations.
Design patterns are solutions to recurring problems; guidelines on how to tackle certain problems
Wikipedia describes them as
In software engineering, a software design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations.
| class MultipleInstancesOfState | |
| attr_accessor :state | |
| def initialize(state:) | |
| @state = state | |
| end | |
| def foo | |
| @state.reverse! | |
| end | 
| /* Reset provided by https://github.com/gatsbyjs/gatsby-starter-blog via MIT license */ | |
| html { | |
| font-family: sans-serif; | |
| -ms-text-size-adjust: 100%; | |
| -webkit-text-size-adjust: 100%; | |
| } | |
| body { | |
| margin: 0; | |
| -webkit-font-smoothing: antialiased; | 
| Color: | |
| Used by item unboxe | |
| Light Blue: | |
| Blue: | |
| Purple: | |
| Pink: | |
| Red / knife: | |
| Others: | 
| import * as firebase from 'firebase/app'; | |
| import 'firebase/firestore'; | |
| var firebaseConfig = { | |
| // your firebase credentials | |
| }; | |
| // Initialize Firebase | |
| firebase.initializeApp(firebaseConfig); | 
| function bubbleSort(input){ | |
| let result = [] | |
| input.forEach((e,i,a)=>{ | |
| let cache = {}; | |
| cache["itemA"] = e | |
| cache["itemB"] = a[i + 1] | |
| if(cache.itemA > cache.itemB && i < a.length){ | |
| a[i] = cache["itemB"] | |
| a[i+1] = cache["itemA"] | |
| } |