Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.
Wow. Stripped-down, reading-ready summary follows below, but here's the original link:
https://twitter.com/sarahmei/status/783340259073335296
The author, Sarah Mei (@sarahmei) has also registered liveablecode.com (no content yet).
[begin summary]
| git remote prune origin | |
| git branch -r --merged master | egrep -iv '(master|develop)' | sed 's/origin\///g' | xargs -n 1 git push --delete origin |
When using react-rails for an internationalized app it makes a lot of sense to use i18n-js for translations, so that you can reuse the the strings from your rails app's .yml files (and all the tooling & services that exist around that).
When you use the prerender feature of react-rails you face 2 problems:
translation.js & i18n.js from i18n-js need to be loaded inside the server-side JS prerendering processes, which is achieved by loading them inside the components.js.locale of each HTTP request. This is done by adding a custom renderer and using the before_render hook to configure i18n-js accordingly for each render call.I became interested in string clustering through developing fpos, a set of Python scripts for graphing my spending habits. In a clear failure of research I missed the existance of libraries like:
Hi Nicholas,
I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:
The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't
| #!/bin/sh | |
| # To the extent possible under law, Viktor Szakats | |
| # has waived all copyright and related or neighboring rights to this | |
| # script. | |
| # CC0 - https://creativecommons.org/publicdomain/zero/1.0/ | |
| # SPDX-License-Identifier: CC0-1.0 | |
| # THIS SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR | |
| # IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, |
Method lookup is a simple affair in most languages without multiple inheritance. You start from the receiver and move up the ancestors chain until you locate the method. Because Ruby allows you to mix in modules and extend singleton classes at runtime, this is an entirely different affair.
I will not build contrived code to exemplify the more complicated aspects of Ruby method lookup, as this will only serve to confuse the matter.
When you pass a message to an object, here is how Ruby finds what method to call:
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!
\
The purpose of design is to allow you to do design later, and it's primary goal is to reduce the cost of change.
