This describes how I setup Atom for an ideal Clojure development workflow. This fixes indentation on newlines, handles parentheses, etc. The keybinding settings for enter (in keymap.cson) are important to get proper newlines with indentation at the right level. There are other helpers in init.coffee and keymap.cson that are useful for cutting, copying, pasting, deleting, and indenting Lisp expressions.
The Atom documentation is excellent. It's highly worth reading the flight manual.
| /** | |
| * Cooperative tasks scheduler. | |
| * | |
| * by Dmitry Soshnikov <dmitry.soshnikov@gmail.com> | |
| * MIT Style License | |
| * | |
| * An educational implementation to show the work of a processes scheduler. | |
| * In practice you may find using a library like Task.js, or similar. | |
| * | |
| * Test, Node 4 or transformed with Babel: |
| /* | |
| For Fast Fourier Transformations an important step is the rearrangement of the | |
| data in a bit reversed order. | |
| The implemention below shows how to do this inplace or as copy in O(n) runtime. | |
| */ | |
| /* | |
| The MIT License (MIT) |
| * { | |
| font-size: 12pt; | |
| font-family: monospace; | |
| font-weight: normal; | |
| font-style: normal; | |
| text-decoration: none; | |
| color: black; | |
| cursor: default; | |
| } |
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?
Here are some general guidelines to consider when reviewing a pull request:
| <!DOCTYPE html> | |
| <html> | |
| <head> | |
| <meta charset="utf-8"> | |
| <meta name="keywords" lang="de" content="Zeitleiste, Zeitlinie, Zeitkarte, Geschichte, Chronologie"> | |
| <meta name="keywords" lang="en" content="Timeline, Timemap, History, Chronology"> | |
| <title>Timeline - Proof-of-concept</title> | |
| <!-- That's my local d3 path. When working locally, use your local path. --> |
| 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 |