This gist is part of a blog post. Check it out at:
http://jasonrudolph.com/blog/2011/08/09/programming-achievements-how-to-level-up-as-a-developer
| ;1; | |
| (sort #(> %2 %1) '( 1 4 2 )) | |
| ;2; | |
| (def x 5 ) | |
| (let [x 2] (print x)) ; x 5 local scope | |
| (binding [ x 2] ( print x )) ; x=> global scope | |
| ;3; | |
| (defn makeaddr [n] #(+ % n)) |
| From: https://raw.github.com/gist/933cc4f7df97d553ed89/24386c6a79bb4b31fb818b70b34c5eab7f12e1ff/gistfile1.txt | |
| Stevey's Google Platforms Rant | |
| 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 effort |
This gist is part of a blog post. Check it out at:
http://jasonrudolph.com/blog/2011/08/09/programming-achievements-how-to-level-up-as-a-developer
Hi there!
The docker cheat sheet has moved to a Github project under https://github.com/wsargent/docker-cheat-sheet.
Please click on the link above to go to the cheat sheet.
I have moved this over to the Tech Interview Cheat Sheet Repo and has been expanded and even has code challenges you can run and practice against!
\
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
| . | |
| ├── actions | |
| ├── stores | |
| ├── views | |
| │ ├── Anonymous | |
| │ │ ├── __tests__ | |
| │ │ ├── views | |
| │ │ │ ├── Home | |
| │ │ │ │ ├── __tests__ | |
| │ │ │ │ └── Handler.js |
| package main | |
| import ( | |
| "fmt" | |
| "io" | |
| "io/ioutil" | |
| "net" | |
| "os" | |
| "strings" |
Max Goldstein | July 30, 2015 | Elm 0.15.1
In Elm, signals always have a data source associated with them. Window.dimensions is exactly what you think it is, and you can't send your own events on it. You can derive your own signals from these primitives using map, filter, and merge, but the timing of events is beyond your control.
This becomes a problem when you try to add UI elements. We want to be able to add checkboxes and dropdown menus, and to receive the current state of these elements as a signal. So how do we do that?