| I was drawn to programming, science, technology and science fiction | |
| ever since I was a little kid. I can't say it's because I wanted to | |
| make the world a better place. Not really. I was simply drawn to it | |
| because I was drawn to it. Writing programs was fun. Figuring out how | |
| nature works was fascinating. Science fiction felt like a grand | |
| adventure. | |
| Then I started a software company and poured every ounce of energy | |
| into it. It failed. That hurt, but that part is ok. I made a lot of | |
| mistakes and learned from them. This experience made me much, much |
| A lot of people have asked me for this information over time and I've realized that it's not really published anywhere (that I can find) so posting it here for posterity. Hope this is helpful to the Ricoh GR1-series users out there. These instructions work with my GR1v and to my knowledge should also work with other models. Users of any other models should post corrections, if any, for their models so that those are documented. | |
| Many people love the Ricoh GR1-series cameras but they are notorious for LCD failures. If your LCD goes out completely (or if you want to save some money by buying one with a dead LCD), the following steps describe how to always know what mode you're in so that you can continue to use the camera for the duration of it's life. Hopefully this'll help keep people using these cameras even if the LCD goes out. A dead LCD does not mean that you're Ricoh is useless and it probably still has a long life ahead of it. | |
| In case your LCD goes out completely: | |
| Resetting to Normal mode and accessi |
| console.log(1); | |
| (_ => console.log(2))(); | |
| eval('console.log(3);'); | |
| console.log.call(null, 4); | |
| console.log.apply(null, [5]); | |
| new Function('console.log(6)')(); | |
| Reflect.apply(console.log, null, [7]) | |
| Reflect.construct(function(){console.log(8)}, []); | |
| Function.prototype.apply.call(console.log, null, [9]); | |
| Function.prototype.call.call(console.log, null, 10); |
| javascript: | |
| document.querySelectorAll('.load-diff-button').forEach(node => node.click()) |
Disclaimer: This piece is written anonymously. The names of a few particular companies are mentioned, but as common examples only.
This is a short write-up on things that I wish I'd known and considered before joining a private company (aka startup, aka unicorn in some cases). I'm not trying to make the case that you should never join a private company, but the power imbalance between founder and employee is extreme, and that potential candidates would
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:
| #!/bin/bash | |
| case $# in | |
| 0) | |
| echo "Usage: $0 {start|stop}" | |
| exit 1 | |
| ;; | |
| 1) | |
| case $1 in | |
| start) |
My friend Michael Jackson turned off github issues on one of his smaller projects. It got me thinking...
Maintainers getting burned out is a problem. Not just for the users of a project but the mental health of the maintainer. It's a big deal for both parties. Consumers want great tools, maintainers want to create them, but maintainers don't want to be L1 tech support, that's why they
| const I = x => x | |
| const K = x => y => x | |
| const A = f => x => f (x) | |
| const T = x => f => f (x) | |
| const W = f => x => f (x) (x) | |
| const C = f => y => x => f (x) (y) | |
| const B = f => g => x => f (g (x)) | |
| const S = f => g => x => f (x) (g (x)) | |
| const S_ = f => g => x => f (g (x)) (x) | |
| const S2 = f => g => h => x => f (g (x)) (h (x)) |
