FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.
It's now here, in The Programmer's Compendium. The content is the same as before, but being part of the compendium means that it's actively maintained.
Testing React components seems simple at first. Then you need to test something that isn't a pure interaction and things seem to break down. These 4 patterns should help you write readable, flexible tests for the type of component you are testing.
I recommend doing all setup in the most functional way possible. If you can avoid it, don't set variables in a
beforeEach. This will help ensure tests are isolated and make things a bit easier to reason about. I use a pattern
that gives great defaults for each test example but allows every example to override props when needed:
Hello, visitors! If you want an updated version of this styleguide in repo form with tons of real-life examples… check out Trellisheets! https://github.com/trello/trellisheets
“I perfectly understand our CSS. I never have any issues with cascading rules. I never have to use !important or inline styles. Even though somebody else wrote this bit of CSS, I know exactly how it works and how to extend it. Fixes are easy! I have a hard time breaking our CSS. I know exactly where to put new CSS. We use all of our CSS and it’s pretty small overall. When I delete a template, I know the exact corresponding CSS file and I can delete it all at once. Nothing gets left behind.”
You often hear updog saying stuff like this. Who’s updog? Not much, who is up with you?
| #!/usr/bin/env bash | |
| # | |
| # Get the value of a tag for a running EC2 instance. | |
| # | |
| # This can be useful within bootstrapping scripts ("user-data"). | |
| # | |
| # Note the EC3 instance needs to have an IAM role that lets it read tags. The policy | |
| # JSON for this looks like: | |
| # | |
| # { |
| /* | |
| Swift Programming Language Guide | |
| "A Swift Tour" Solutions | |
| https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/GuidedTour.html#//apple_ref/doc/uid/TP40014097-CH2-XID_1 | |
| These are the solutions to all the "experiments" in the pre-release Swift Programming Guide | |
| (released on the same day Apple announced Swift). A couple of things worth noting: | |
| 1. Swift syntax, e.g. array declarations, has changed since I releasd these. So this code will | |
| probably cause some errors when you paste it into a playground. Should be easy enough to fix |
| Mac OS X 10.9.2, Vagrant 1.5.1, VMWare Fusion 6.0.2 | |
| I had some intense difficulties getting this all to work. The VMs would boot | |
| fine with gui=true, but then would fail as soon as I turned that off. Yet when | |
| they failed, they were actually running just fine! I could ssh in, but neither | |
| vagrant nor vmrun could find the running VMs! You would think that it would | |
| give better errors, but no. | |
| First off, most boxes you find online will be using the VMWare configuration 9, | |
| which will only boot if you have gui=true the first boot, so you can upgrade it |
| Latency Comparison Numbers (~2012) | |
| ---------------------------------- | |
| L1 cache reference 0.5 ns | |
| Branch mispredict 5 ns | |
| L2 cache reference 7 ns 14x L1 cache | |
| Mutex lock/unlock 25 ns | |
| Main memory reference 100 ns 20x L2 cache, 200x L1 cache | |
| Compress 1K bytes with Zippy 3,000 ns 3 us | |
| Send 1K bytes over 1 Gbps network 10,000 ns 10 us | |
| Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD |
