- plan for code that is easy to delete/replace rather than code that is easy to extend or reuse. As needs change, you're more likely to change the assumptions about what the system should do than in how many ways it should do it. If the code needs extending, it's then easy to replace it with a bit that's easy to extend
- planning for code that is easy to throw away is the best way I've found to properly bake in abstraction and isolation. The question is always "if I take this shit out or change its implementation entirely, do I need to replace anything else?". If the answer is "yes", then you may be leaking into other components. Fix it. turns out when you have that, it's also suddenly easier to reuse code.
- write a prototype of whatever significant task you have to do, and consider it a draft. Use it to figure out requirements or to make your first mistakes in. Throw it away. Try again. As I gain more experience I find my prototypes smaller and individually more solid, but anything where I lack experience t
- plan for code that is easy to delete/replace rather than code that is easy to extend or reuse. As needs change, you're more likely to change the assumptions about what the system should do than in how many ways it should do it. If the code needs extending, it's then easy to replace it with a bit that's easy to extend
- planning for code that is easy to throw away is the best way I've found to properly bake in abstraction and isolation. The question is always "if I take this shit out or change its implementation entirely, do I need to replace anything else?". If the answer is "yes", then you may be leaking into other components. Fix it. turns out when you have that, it's also suddenly easier to reuse code.
- write a prototype of whatever significant task you have to do, and consider it a draft. Use it to figure out requirements or to make your first mistakes in. Throw it away. Try again. As I gain more experience I find my prototypes smaller and individually more solid, but anything where I lack experience t
I hereby claim:
- I am polymetis on github.
- I am polymetis (https://keybase.io/polymetis) on keybase.
- I have a public key ASD0Qbo3YuW-EftORHbsI7S_i4Ehzv7B1_TjZTPaRV6mmAo
To claim this, I am signing this object:
#Ratatouille
##Back story. I was watching the film and decided to attempt to play around as attempt to cook something fun for me and my friend that has seen the film.
##Shopping List - Gets complicated because I change it based on season
- A few (4)Red or Orange Bell peppers or any other sweet pepper but avoid the colour green. (it looks unpleasant)
- Garlic - Just get a whole bulb
- Some form of eggplant -- Japanese Eggplant makes ones life easier.
# Two things are important to note: | |
# | |
# 1) The code is fugly, because it was a JavaScript/iPad experiment. | |
# I know that it is ugly, so pretty please don't comment on that part. | |
# 2) I tried to use as many CoffeeScript features as possible, | |
# including but not limited to list comprehensions, | |
# heredocs, destructuring assignment and also the "do" operator | |
# | |
# I welcome comments about stuff that is not CoffeeScripty enough, or what I should | |
# write differently. |
defmodule Episode do | |
defstruct id: nil, name: nil, video: nil, markdown: nil, post: nil | |
def list do | |
[ | |
%Episode{id: "001", post: "271", name: "Introduction and Installing Elixir", video: "1366", markdown: "1382" }, | |
%Episode{id: "002", post: "275", name: "Basic Elixir", video: "1367", markdown: "1357" }, | |
%Episode{id: "003", post: "280", name: "Pattern Matching", video: "14879", markdown: "1413" }, | |
%Episode{id: "004", post: "284", name: "Functions", video: "5086", markdown: "1559" }, | |
%Episode{id: "005", post: "298", name: "Mix and Modules", video: "5087", markdown: "1654" }, |
#!/usr/bin/env bash | |
read -p "Enter the *email* that you use for GitHub: " email | |
ssh-keygen -t rsa -C "$email" <<! | |
id_rsa | |
! | |
key="$(cat ~/.ssh/id_rsa.pub)" |
#!/usr/bin/env bash | |
if [ -e .gitmodules ]; then | |
sed -i 's/https:\/\/github.com\//git@github.com:/g' .git/config | |
awk '/path =/ { print $3 }' .gitmodules | xargs -imetrasub -P10 bash -c "cd .git/modules/metrasub && sed -i 's/https:\/\/github.com\//git@github.com:/g' config" | |
else | |
echo "run this from the top" | |
exit 1 | |
fi |
git status -sb | grep '??' | awk '{ print $2 }' | xargs -I buildfile bash -c "echo "buildfile" >> .gitignore" |
Revised date: 07/11/2012
Between us [company name] and you [customer name]
We’ll always do our best to fulfil your needs and meet your expectations, but it’s important to have things written down so that we both know what’s what, who should do what and when, and what will happen if something goes wrong. In this contract you won’t find any complicated legal terms or long passages of unreadable text. We’ve no desire to trick you into signing something that you might later regret. What we do want is what’s best for both parties, now and in the future.