| // Just before switching jobs: | |
| // Add one of these. | |
| // Preferably into the same commit where you do a large merge. | |
| // | |
| // This started as a tweet with a joke of "C++ pro-tip: #define private public", | |
| // and then it quickly escalated into more and more evil suggestions. | |
| // I've tried to capture interesting suggestions here. | |
| // | |
| // Contributors: @r2d2rigo, @joeldevahl, @msinilo, @_Humus_, | |
| // @YuriyODonnell, @rygorous, @cmuratori, @mike_acton, @grumpygiant, |
No need for homebrew or anything like that. Works with https://www.git-tower.com and the command line.
gpg --list-secret-keys and look for sec, use the key ID for the next stepgit to use GPG -- replace the key with the one from gpg --list-secret-keys
| package main | |
| import ( | |
| "crypto/tls" | |
| "crypto/x509" | |
| "flag" | |
| "io/ioutil" | |
| "log" | |
| "net/http" | |
| ) |
When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:
const Article = require('../../../../app/models/article');Those suck for maintenance and they're ugly.
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
| # | |
| # Wide-open CORS config for nginx | |
| # | |
| location / { | |
| if ($request_method = 'OPTIONS') { | |
| add_header 'Access-Control-Allow-Origin' '*'; | |
| # |
| # use ImageMagick convert | |
| # the order is important. the density argument applies to input.pdf and resize and rotate to output.pdf | |
| convert -density 90 input.pdf -rotate 0.5 -attenuate 0.2 +noise Multiplicative -colorspace Gray output.pdf |
| if _, err := os.Stat("/path/to/whatever"); os.IsNotExist(err) { | |
| // path/to/whatever does not exist | |
| } | |
| if _, err := os.Stat("/path/to/whatever"); !os.IsNotExist(err) { | |
| // path/to/whatever exists | |
| } |
This document was originally written several years ago. At the time I was working as an execution core verification engineer at Arm. The following points are coloured heavily by working in and around the execution cores of various processors. Apply a pinch of salt; points contain varying degrees of opinion.
It is still my opinion that RISC-V could be much better designed; though I will also say that if I was building a 32 or 64-bit CPU today I'd likely implement the architecture to benefit from the existing tooling.
Mostly based upon the RISC-V ISA spec v2.0. Some updates have been made for v2.2
The RISC-V ISA has pursued minimalism to a fault. There is a large emphasis on minimizing instruction count, normalizing encoding, etc. This pursuit of minimalism has resulted in false orthogonalities (such as reusing the same instruction for branches, calls and returns) and a requirement for superfluous instructions which impacts code density both in terms of size and
Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.
Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.
