Omer Wazir

Rust Ownership Exercises

2026-08-14T00:00:00+00:00

I asked Claude to spin up 12 examples of ownership for me to read through and figure out if they'd work or not. I added notes on what the problems were.

Ownership & Borrowing Exercises

For each example, decide: does this compile? If not, figure out why (which rule it violates) before checking with rustc or the playground.

Example 1

fn main() {
    let s1 = String::from("hello");
    let s2 = s1;
    println!("{}", s1);
}

This won't work because String doesn't implement Copy, so let s2 = s1; moves ownership from s1 to s2 instead of copying it. If you need a read-only borrow of s1 in s2 instead, use &, like let s2 = &s1.

Example 2

fn main() {
    let x = 5;
    let y = x;
    println!("{} {}", x, y);
}

This works because x is a primitive type, so it is copied by value.

Example 3

fn takes_ownership(s: String) {
    println!("{}", s);
}

fn main() {
    let s = String::from("hello");
    takes_ownership(s);
    println!("{}", s);
}

String doesn't implement Copy, and takes_ownership takes its parameter by value (s: String), so calling takes_ownership(s) moves ownership of s into the function, then s is no longer valid back in main.

To avoid the move, borrow instead so change the param to s: &str and call takes_ownership(&s).

Example 4

fn borrows(s: &String) {
    println!("{}", s);
}

fn main() {
    let s = String::from("hello");
    borrows(&s);
    println!("{}", s);
}

This works because a reference is used.

Example 5

fn main() {
    let mut s = String::from("hello");
    let r1 = &s;
    let r2 = &s;
    println!("{} {}", r1, r2);
}

Since the reference for r1 is immutable and r2 is immutable this is ok, but just remove the mut from s since no mutations are happening.

Example 6

fn main() {
    let mut s = String::from("hello");
    let r1 = &s;
    let r2 = &mut s;
    println!("{} {}", r1, r2);
}

Now the difference is one immutable reference is live in r1 and a mutable reference is live in r2, and can't have the mutable and immutable borrows alive at the same time.

Example 7

fn main() {
    let mut s = String::from("hello");
    let r1 = &s;
    println!("{}", r1);
    let r2 = &mut s;
    r2.push_str(" world");
    println!("{}", r2);
}

This is ok, the immutable reference is dropped before the mutable reference is alive.

Example 8

fn dangle() -> &String {
    let s = String::from("hello");
    &s
}

fn main() {
    let r = dangle();
    println!("{}", r);
}

dangle creates s and returns a reference to it, but s goes out of scope and is dropped when the function returns, so the reference would be dangling. Rust rejects this at compile time — with fn dangle() -> &String, there's no way to know what the returned reference would be borrowed from, so the compiler actually errors with missing lifetime specifier before it even gets to check whether the reference would dangle.

The way to fix this is to not return a reference &String and return the owned String instead, so return s and change the function signature to fn dangle() -> String.

Example 9

fn main() {
    let mut v: Vec<i32> = vec![1, 2, 3];
    let first = &v[0];
    v.push(4);
    println!("{}", first);
}

first holds an immutable reference to the first element of v, and v.push(4) needs a mutable borrow of v while first is still alive, which is an aliasing/mutability violation, the same rule as seen in Example 6. If first were last used before the push (or even created after it), this would be fine.

Example 10

fn main() {
    let mut s = String::from("hello world");
    let word = &s[0..5];
    s.clear();
    println!("{}", word);
}

Same aliasing/mutability violation as Example 9, word is an immutable borrow of s and s.clear() needs a mutable borrow of s while word is still alive.

Example 11

fn main() {
    let s1 = String::from("hello");
    let s2 = s1.clone();
    println!("{} {}", s1, s2);
}

This is ok.

Example 12

fn first_word(s: &str) -> &str {
    let bytes = s.as_bytes();
    for i in 0..bytes.len() {
        if bytes[i] == b' ' {
            return &s[0..i];
        }
    }
    &s[..]
}

fn main() {
    let mut s = String::from("hello world");
    let word = first_word(&s);
    s.push_str("!");
    println!("{}", word);
}

This is ok up until s.push_str("!"), which needs a mutable borrow of s while word (an immutable borrow of s) is still alive and used later in the println!, aliasing/mutability violation, same as Examples 6, 9, and 10.

14 days of Rust

2026-08-11T00:00:00+00:00

9 years 4 months 6 days since last time I wrote a post, a lot has happened in between but right now I'm writing Rust so that will be the focus for a while.

I told Claude I was coming from zero and wanted to be able to write CLI, TUI and a simple Markdown → HTML formatter by the end. I like to use Exercism to give me hands on experience, and I'm using the Rust-Book from Brown after I watched this Will Crichton: Rust for Everyone!. Specifically seeing the Aquascope Playground explain borrow checking was cool.

The following is Claude's plan for 14 days of Rust, you can tell right away it's Claude. I wonder in a few years if it will sound different. Some formatting had to be fixed to render correctly here, but nothing about the content was changed.

14 Days of Rust — from zero to a working SSG

Start: Tue 11 Aug 2026
End: Mon 24 Aug 2026 (14 consecutive days)
Budget: ~2 hours/day
Tools: RustRover, Exercism Rust track, The Rust Book

The deal

One project, three faces. You build a static site generator as a single crate:

Piece	What it is	Days
`lib.rs`	Markdown → HTML parser + site model	8–10
`src/main.rs`	`ssg build` / `ssg new` CLI	7, 13
`src/bin/tui.rs`	Browse pages, live-preview the render	11–12

Everything before Day 7 is loading the magazine. Days 7–14 are the project.

Daily shape (~2h)

Week 1 — ~40 min read + type along · ~40 min Exercism · ~40 min consolidating.
Week 2 — ~30 min reading · ~90 min project. Exercism is optional and marked as such.

Two rules that don't change:

Type the code, don't paste it. Typing is where the borrow checker teaches you.
After each Exercism exercise, read 2–3 community solutions for it. Single highest-leverage habit on the list.

Rust Book chapter numbers shifted in the 2024 edition. Titles are stable — go by title if a number looks off.

Day 0 — before you start (15 min, today)

rustup update && rustup component add clippy rustfmt rust-analyzer
rustup doc --book — offline copy of the Book
Install the Exercism CLI, exercism configure --token=..., join the Rust track
In RustRover: enable Clippy as the external linter (Settings → Rust → External Linters → Clippy, tick "Run on save")
Turn on Rustfmt on save (Settings → Rust → Rustfmt)
git init is already done — commit at the end of every single day, even broken code

Week 1 — the language

Day 1 (Tue 11 Aug) — Cargo, syntax, the shape of a program

Read: Book ch. 1–3 (Getting Started, Guessing Game, Common Programming Concepts)

Type out the guessing game by hand, end to end. Run it.
Know cold: cargo new, run, build, test, check, clippy, fmt, add
cargo check is your fast loop — bind it to a shortcut in RustRover
Variables vs. mutability, shadowing, scalar/compound types, if/loop/while/for, functions & expression-vs-statement

Exercism: hello-world, two-fer, reverse-string, gigasecond

Read the community solutions for reverse-string — note the .chars().rev() vs. bytes distinction. That's a UTF-8 lesson you'll need on Day 9.

Done when: you can explain why let x = 5; x = 6; fails and let x = 5; let x = 6; doesn't.

Day 2 (Wed 12 Aug) — Ownership, borrowing, slices

Read: Book ch. 4 (Understanding Ownership) — slowly. This is the chapter.

Move vs. copy vs. clone
&T vs. &mut T; the "one mutable XOR many immutable" rule
String vs. &str, and why &str is the right function parameter
Deliberately write 3 programs that fail to compile, and read each error out loud

Exercism: raindrops, acronym, pangram, scrabble-score

Force yourself to take &str and return String where appropriate

Done when: you can say what fn longest(a: &str, b: &str) -> &str is missing without looking it up. (You'll fix it on Day 6.)

Day 3 (Thu 13 Aug) — Structs, enums, pattern matching

Read: Book ch. 5–6 (Structs, Enums and Pattern Matching)

impl blocks, associated functions vs. methods, Self
#[derive(Debug, Clone, PartialEq)] and when each matters
Option<T>, match exhaustiveness, if let / let else
Sketch (don't build) an enum for a markdown block: Heading, Paragraph, CodeBlock, Rule

Exercism: space-age, high-scores, allergies

Nothing here needs a hand-written trait impl yet — traits are Day 6, and clock waits until then.

Done when: match on an enum feels better than a chain of ifs. Keep that enum sketch; it becomes Block on Day 8.

Day 4 (Fri 14 Aug) — Collections + module system

Read: Book ch. 7 (Managing Growing Projects) and ch. 8 (Common Collections)

Vec<T>, String, HashMap<K, V> — and the entry API
mod, pub, use, crate:: vs. super::, file-per-module layout
Split a toy project into src/lib.rs + src/main.rs and call the lib from the bin — you'll do exactly this for real on Day 7

Exercism: word-count, nucleotide-count, etl

word-count is a dry run for your tokenizer. Take it seriously.

Done when: you know why src/main.rs calls mycrate::foo() and not crate::foo().

Day 5 (Sat 15 Aug) — Error handling

Read: Book ch. 9 (Error Handling)

panic! vs. Result<T, E>; when unwrap is honestly fine (tests, prototypes, provable invariants)
The ? operator and what it desugars to (From::from on the error)
Write one custom error enum by hand implementing Display + std::error::Error
Then do it in 4 lines with thiserror and feel the difference

Crates: cargo add anyhow thiserror in a scratch project

Rule of thumb you'll use all fortnight: thiserror in the library, anyhow in the binaries

Exercism: luhn, matching-brackets, roman-numerals

Done when: you can convert a function from unwrap()-everywhere to ?-everywhere without thinking.

Day 6 (Sun 16 Aug) — Generics, traits, lifetimes, tests

Read: Book ch. 10 (Generic Types, Traits, Lifetimes) and ch. 11 (Writing Automated Tests)

Trait definitions, default methods, impl Trait in argument and return position
Trait bounds and where clauses
Lifetime annotations — go back and fix Day 2's longest
#[cfg(test)] mod tests, assert_eq!, #[should_panic], -> Result<(), E> tests
Table-driven tests: a &[(input, expected)] array in a loop. You'll use this for every parser rule.

Exercism: clock (this is your impl Display + operator-trait exercise), sublist (generics + bounds), triangle

Done when: you've written a generic function with a trait bound that compiles on first try.

Week 2 — the build

Week 2 is project-dominant: ~30 min reading, ~90 min building. Exercism entries below are optional — do them only if the project work finished early.

Day 7 (Mon 17 Aug) — CLI skeleton + pin the scope

Read: Book ch. 12 (An I/O Project: Building a Command Line Program) — build minigrep fully. Best 90 minutes in the Book. If time is tight, read it and build the argument-parsing half only.

Project — mdssg is born:

cargo new mdssg in this repo; add src/lib.rs alongside src/main.rs
cargo add clap --features derive · cargo add anyhow thiserror walkdir

Define the CLI with clap's derive API:

ssg build  --input <dir> --output <dir>   # default ./content -> ./public
ssg new    <title>                        # scaffold a content/*.md file

--verbose flag, -h output that reads well
build currently: walk --input for *.md, print each path, exit 0
main returns anyhow::Result<()>; every error path carries .context("...")
RustRover: create a run configuration for ssg build with args pre-filled

Write SPEC.md — this is the important half of today. Fifteen lines, no more, stating exactly what your markdown dialect supports and what it doesn't. Draft:

Supported:  ATX headings (# .. ######), paragraphs, fenced code (``` with optional lang),
            thematic breaks (---), unordered lists (- *), ordered lists (1.),
            blockquotes (>), inline: *em* **strong** `code` [link](href) ![img](src), \escapes
Not supported: setext headings, reference links, HTML passthrough, tables,
            nested lists, lazy continuation, autolinks, footnotes

Create tests/fixtures/<feature>.md + <feature>.html pairs for every "supported" line
Write the test harness that walks the fixture directory and asserts each pair — it fails everything today, and that's the point. Days 8–10 are "make the fixtures pass."

Done when: cargo run -- build --input content lists your markdown files, and SPEC.md has a line you can point at whenever you're tempted to add a feature.

Day 8 (Tue 18 Aug) — Iterators + block parser, part 1

Read: Book ch. 13 (Iterators and Closures)

map / filter / filter_map / fold / collect / take_while / peekable
Peekable<Lines> is the workhorse of a line-based block parser — get comfortable with it
Closures: Fn / FnMut / FnOnce, and why move exists

Project — the flat blocks only (src/parser/block.rs):

Define the AST, with list items deliberately flat for now:

pub enum Block {
    Heading { level: u8, inlines: Vec<Inline> },
    Paragraph(Vec<Inline>),
    CodeBlock { lang: Option<String>, code: String },
    Rule,
    // List and Quote land on Day 10
}

pub fn parse_blocks(src: &str) -> Vec<Block> driven by a Peekable line iterator
Support four things only: ATX headings, fenced code, --- rules, paragraphs as fallback
Inlines stay raw for now — Vec<Inline> holds a single Inline::Text placeholder
Table-driven tests including the ugly cases: empty file, no trailing newline, unterminated fence, #-with-no-space
Use the RustRover debugger. Breakpoint inside the parse loop, step through a 10-line document, watch the Peekable state. Twenty minutes here beats an hour of println!.

Exercism (optional): accumulate

Done when: those four block types parse correctly and their fixtures are the first ones passing.

Day 9 (Wed 19 Aug) — Inline parser + HTML renderer

Read: Rust By Example §"Strings", plus the std::str and char docs. Skim pulldown-cmark's docs to see how the pros model events — don't add it as a dependency; you're writing this one.

chars() vs. bytes() vs. char_indices(); why &s[0..1] can panic
String::push_str, and write! into a String via std::fmt::Write

Project — inlines and the first real HTML:

Define the inline enum:

pub enum Inline { Text(String), Emph(Vec<Inline>), Strong(Vec<Inline>), Code(String) }
// Link and Image land on Day 10

parse_inlines(&str) -> Vec<Inline> handling \ escapes, `code`, **strong**, *em*
Do escapes and code spans first — they're unambiguous. Emphasis is the fiddly one; get the simple non-nested case working and move on. Nested **a *b* c** is a stretch goal, not a today goal.
Wire it into Day 8's blocks (replace the placeholder)
render_html(&[Block]) -> String — recursive, writing into one String buffer
Escape & < > " in text and attributes. Write the test that proves <script> in a paragraph comes out inert.

Exercism (optional): anagram

Done when: md_to_html("# Hi\n\nsome **bold** text") produces exactly the HTML you'd hand-write.

Day 10 (Thu 20 Aug) — Recursive blocks + catch-up day

Read: Book ch. 15 (Smart Pointers)

Box<T> for recursion — the reason Block::Quote(Vec<Block>) compiles at all
Rc<T> / RefCell<T> and interior mutability; know when not to reach for them
Deref and Drop — the Drop half is what makes Day 11's terminal guard work

This is the slack day. If Days 8–9 overran, spend the whole session finishing them and skip everything below except the last two boxes. Nothing downstream depends on lists or links.

Project — the recursive cases:

Block::Quote(Vec<Block>) — strip the > prefix, recurse into parse_blocks
Block::List { ordered: bool, items: Vec<Vec<Inline>> } — flat items, one paragraph each. Nested lists are explicitly out of scope per SPEC.md.
Inline::Link { href, text } and Inline::Image { src, alt }, with attribute escaping
MdError enum via thiserror; the lib returns Result<_, MdError>, the bin wraps it with anyhow
cargo clippy -- -W clippy::pedantic — fix what you understand, note the rest

Done when: every fixture from Day 7's SPEC.md passes, or you've knowingly moved a line from "supported" to "not supported" and deleted its fixture.

Day 11 (Fri 21 Aug) — TUI: the event loop

Read: the ratatui book — Getting Started + the "Hello World" and "Counter" tutorials

cargo add ratatui crossterm
Install the panic hook first. Before anything else: a hook that restores the terminal on panic. Skip this and one crash leaves you in raw mode with no echo, typing blind.
Raw mode, alternate screen, and RAII teardown — a guard struct with a Drop impl (Day 10 pays off)
The immediate-mode idea: you redraw the whole frame every tick; no widget state persists

Project — src/bin/tui.rs:

App struct holding state: file list, selected index, scroll offset, mode
Event loop: poll crossterm events, q/Esc quits, j/k + arrows move
Two-pane Layout: left = list of content/*.md, right = placeholder
Status bar showing the selected filename and a keybinding hint

Done when: you can navigate the file list and quit cleanly, with your terminal intact.

Day 12 (Sat 22 Aug) — TUI preview, then earn the abstraction

Read: the trait-objects / OOP chapter (ch. 17 or 18 depending on edition) — dyn Trait vs. generics, static vs. dynamic dispatch

Project — build it concrete, then refactor:

Right pane renders the selected file's parsed content — walk Vec<Block> and map to ratatui Line/Span with styles (headings bold, code dimmed, links underlined). Write this as a plain function, duplicating the HTML renderer's traversal shape.
Scrolling in the preview pane (PageUp/PageDown, g/G); Tab switches focus, focused pane gets a highlighted border; r reloads from disk
Handle the sad paths: empty directory, unreadable file, file deleted while selected
Now look at the two renderers side by side. They walk the same AST with the same match arms and differ only in what they emit. Now extract a Renderer trait with HtmlRenderer and TuiRenderer impls — with two real implementors in front of you, you'll get the method signatures right.
Note what the trait can't cleanly express. That gap is the actual lesson about abstraction.

Done when: one parser feeds two renderers through one trait, and you can browse a folder of markdown rendered in your terminal.

Day 13 (Sun 23 Aug) — The full build pipeline

Read: Book ch. 14 (More About Cargo and Crates.io) — profiles, workspaces, features

cargo add serde --features derive · cargo add toml

Project — turn a parser into an SSG:

Frontmatter: strip a leading ---\n...\n--- block, parse as TOML into #[derive(Deserialize)] struct FrontMatter { title, date, tags, draft }
Templating: a templates/page.html with ${title} / ${content} placeholders. Write the 20-line substituter yourself — no template crate.
Build: content/**/*.md → public/**/*.html, preserving directory structure; copy static/ verbatim
Index: generate public/index.html listing every non-draft page, newest first
Error messages that name the offending file and line

ssg serve with file-watching is not in the 14 days — it's a whole evening of notify plus a socket server. It's first on the after-Day-14 list.

Done when: ssg build turns a folder of markdown into a site you can open in a browser.

Day 14 (Mon 24 Aug) — Ship it

Project:

Doc comments (///) on every public item; cargo test --doc passes; cargo doc --open looks like a library you'd publish
cargo fmt --all · cargo clippy --all-targets -- -D warnings — zero warnings
cargo test green, including the fixture harness; add an integration test in tests/ that runs the real binary
README.md: what it is, install, usage, and link SPEC.md for the supported subset
cargo build --release and time a build of 100 files
Dogfood: write the retro below as a markdown file in content/ and build it with your own tool
Tag it: git tag v0.1.0

Retro — write real answers:

Which compiler error did you hit most, and do you now understand it?
Where did you reach for .clone() because you couldn't see the borrow-checker-friendly design?
What's the ugliest function in the codebase, and what would fix it?

Done when: it's tagged, documented, and you'd show it to someone.

After Day 14 — where to go next

ssg serve — notify for file watching plus a small std::net::TcpListener server, then live reload. Cut from the fortnight on purpose; it's the natural next evening.
Parser depth: nested emphasis, nested lists, setext headings, reference links, autolinks
Spec compliance: run the CommonMark test suite against your parser and see how far off you are. Humbling and instructive.
Concurrency: Book ch. 16 → parallelise the build with rayon (one page per core), then Exercism's parallel-letter-frequency properly
Async: the async chapter → tokio + axum for a real dev server
Correctness: fuzz the parser with cargo-fuzz; property tests with proptest
Exercism hard mode: forth, poker, dominoes, xorcism

Reference

Crates you'll install

Crate	For	Day
`clap` (derive)	CLI args	7
`anyhow`	error handling in binaries	5, 7
`thiserror`	error types in the library	5, 10
`walkdir`	recursive file discovery	7
`ratatui` + `crossterm`	TUI	11
`serde` + `toml`	frontmatter	13

Deliberately not used: pulldown-cmark, comrak, any template engine. Writing those is the point.

The loop that matters

cargo check → fix → cargo test → cargo clippy → commit. Every day.

When you're stuck

Read the full error. Rust's errors are essays; the fix is usually in the help: line.
rustc --explain E0502 (or whatever the code is).
Draw the ownership on paper — who owns it, who borrowed it, when does each drop?
Ask "what would this look like with no references at all?" Get it compiling with .clone(), then remove clones one at a time.

Triage — when you fall behind

Days 8–10 are the parser and they will be the tight ones. In priority order:

Never cut Days 8–9. Headings, paragraphs, code blocks, and basic inlines are the whole spine.
Day 10 is the buffer. Spend all of it on unfinished Day 8–9 work if needed. Lists, quotes and links are optional — move them to "not supported" in SPEC.md and delete their fixtures.
Then cut Day 12's polish (scrolling, focus switching, reload) before cutting the trait extraction — the refactor is the lesson.
Last resort: ship the CLI and parser without the TUI. Two of three faces is a real result.

Cut the Exercism block before the project block, always.

Rules for this fortnight

Type the code, don't paste it.
Commit daily, even when it's broken.
Read other people's Exercism solutions after each exercise.
When tempted by a markdown feature, check SPEC.md. If it's not there, it's not today's problem.

Exercism note

Exercise names occasionally move or get retired on the Rust track. If one isn't there, pick the nearest equivalent from the same concept group — the concept is what matters, not the specific exercise.

Learning Elixir - things you can do in IEx

2017-04-05T00:00:00+00:00

If you don’t know what IEx is it’s the interactive elixir shell which is included when Elixir is installed on your computer. Since this post is based on a lightning talk I won’t cover every single feature but I will mention a few things that I think are good to know.

A few of the things IEx can do for you

IEx Helpers which are AMAZING!
Autocomplete with . (dot) lookup
Help break incomplete expressions
Shell Configuration
Pry into code

All of the features in IEx are detailed here

Start IEx

Open your terminal and launch iex by simply typing iex and then enter. This interactive mode evaluates any Elixir expression which makes it an excellent place to get comfortable with Elixir & OTP.

$ iex
Erlang/OTP 19 [erts-8.2] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false]

Interactive Elixir (1.4.1) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> person = %{name: "Remo Williams"}
%{name: "Remo Williams"}
iex(2)>

IEx.helpers

One of the most useful helpers is the h/1 function available from the IEx.Helpers module. To see everything that IEx.Helpers provides run h() inside IEx. To learn about IEx run h(IEx).

Some examples:

clear/0 - clear the screen
h/1 - get module docs
i/1 - print stuff about a type
respawn/0 - respawn shell
s/1 - print specs for a module or function
... 24 total helpers available

respawn() is another function which I use a lot to start a new shell process. Take the time to become familiar with the helpers available from IEx.Helpers.

Autocomplete

If you don't know what functions are available in a module, type the module name with a dot on the end and press tab to see a list of available functions. I have an example of using the autocomplete feature with the Map module, type Map. and make sure there is a dot after Map, then press tab and you should see a list of functions/arity pairs. Pretty neat!

iex(1)> Map.
delete/2             drop/2               equal?/2
fetch!/2             fetch/2              from_struct/1
get/2                get/3                get_and_update!/3
get_and_update/3     get_lazy/3           has_key?/2
keys/1               merge/2              merge/3
new/0                new/1                new/2
pop/2                pop/3                pop_lazy/3
put/3                put_new/3            put_new_lazy/3
split/2              take/2               to_list/1
update!/3            update/4             values/1

#iex:break

This is one of the best features.

In the example below a Map is not closed properly, leaving the expression open and creating chaos. Typing #iex:break will essentially break the expression and allow you to continue as if nothing happened. You will still need to type the expression in again and close it properly. This is probably my favorite feature and something I didn’t know until I started preparing for my talk.

iex(2)> %{user: "Artoo",
...(2)> name: "R2D2',
...(2)> type: 'robot'}
...(2)> .
...(2)> ;
...(2)> end
...(2)> %}
...(2)> #iex:break
** (TokenMissingError) iex:2: incomplete expression

Shell Configuration

Personally I have not configured my IEx shell and have left the default settings. It’s good to know what is configurable in case changes need to be made.

This is a list of what you can change as of Elixir 1.4:

:colors
:inspect
:width
:history_size
:default_prompt
:alive_prompt

:inspect

Inspect options used by the shell when printing results of expression evaluation. If you want to see everything during IO.inspect/1 then do this:

IEx.configure [inspect: [limit: :infinity]]

See more here Inspect.Opts.

Note: different kinds of inspects

inspect/1 and i/1 are different.

iex(2)> foo = %{ name: "Bruce Wayne", location: "Gotham"}
%{location: "Gotham", name: "Bruce Wayne"}
iex(3)> inspect(foo)
"%{location: \"Gotham\", name: \"Bruce Wayne\"}"
iex(4)> i(foo)
Term
  %{location: "Gotham", name: "Bruce Wayne"}
Data type
  Map
Reference modules
  Map
Implemented protocols
  IEx.Info, Collectable, Enumerable, Inspect

Pry into code

Debugging is entirely worthy of its own discussion but IEx.pry should be briefly mentioned here. You will need to require IEx in a module before you can use pry/0. Notice in the example below that require IEx and IEx.pry are both used together. pry/0 was new to me since I did not have a background in Ruby, it’s a lot like debugger; from JavaScript except when using pry “Setting variables or importing modules in IEx does not affect the caller the environment” (from the pry docs).

defmodule say do
 require IEx

 do something() do
  IEx.pry

  IO.puts("Hello, World")
 end
end

I hope you have learned a little bit more about what IEx offers to you, and you now know where to find out more. Things change with new releases so check with the latest documentation to know how a feature works. 😀

Installing Kismet on a Raspberry Pi

2017-01-04T00:00:00+00:00

Setup RPi

Download the latest version of Raspian from https://www.raspberrypi.org/downloads/raspbian/ and follow the instructions for burning the image to an SD card. You can find instructions here. I prefer to use the Raspbian Lite distrubution because I don’t use the desktop or any GUI applications.

Set a static IP

It's useful to have a static IP so you can easily remember where to ssh.

Open the /etc/dhcpcd.conf file and at the bottom of the file add the following settings:

interface eth0
static ip_address=<some ip address>
static routers=<router IP>
static domain_name_servers=8.8.8.8 8.8.4.4 <or your network dns ip>

Apply system updates

sudo apt-get update
sudo apt-get upgrade

Install dependencies

sudo apt-get install wget m4 vim libncurses5-dev libpcap-dev libpcre3-dev \
libnl-dev ethtool iw rfkill build-essential autoconf openssl libssl-dev \
fop xsltproc unixodbc-dev git screen

Increase the current on USB

In case your using an Alfa wireless antenna and you don't have a powered usb hub, you will need to increase the power output that the rpi is delivering over usb.

sudo cp /boot/config.txt /boot/config.txt.bak
sudo vim /boot/config.txt

# Find max_usb_current and set the value to 1 
max_usb_current=1

Setup Kismet

Compile & install Kismet

cd ~/
mkdir kismet
pushd ./kismet
wget https://kismetwireless.net/code/kismet-2016-07-R1.tar.xz
tar -xf ./kismet-2016-07-R1.tar.xz
rm kismet-2016-07-R1.tar.xz
cd ./kismet-2016-07-R1
./configure

After running ./configure you should see at the end of output a list similar to the one below.

Configuration complete:
         Compiling for: linux-gnueabihf (armv7l)
           C++ Library: stdc++
   Installing as group: root
    Man pages owned by: man
       Installing into: /usr/local
          Setuid group: kismet
      Terminal Control: ncurses
   Linux WEXT capture : yes
   OSX/Darwin capture : n/a (only OSX/Darwin)
   PCRE Regex Filters : yes
          pcap capture: yes
       airpcap control: n/a (only Cygwin/Win32)
        PPI log format: yes
   privilege dropping): no
         Linux Netlink: yes (mac80211 VAP creation) - libnl-1

Continue with the following commands:

make dep 
make
# you can walk away for now, make will take a few minutes
sudo make suidinstall
sudo adduser <user> kismet //add user that will run `kismet_server` to the `kismet` group

Edit kismet.conf

popd
rm -rf ./kismet
# Current directory should be your home folder i.e. ~/
mkdir kismet_logs
sudo cp /usr/local/etc/kismet.conf /usr/local/etc/kismet.conf.bak
sudo vim /usr/local/etc/kismet.conf

Change line #14 to ~/kismet_logs.

Enable line #20 and make sure it is set to hidedata=true.

Add ncsource=wlan1mon under line 32. wlan1mon will be configured with airmon-ng.

Save and exit the file.

Setup Aircrack-ng

Compile & install Aircrack-ng

mkdir aircrack
pushd ./aircrack
wget http://download.aircrack-ng.org/aircrack-ng-1.2-rc4.tar.gz
tar -zxf aircrack-ng-1.2-rc4.tar.gz
cd ./aircrack-ng-1.2-rc4
make
sudo make install
sudo airodump-ng-oui-update
popd
rm -rf ./aircrack

Switch wireless device to monitor mode

Run sudo airmon-ng to see a list of attached network devices.

You should hopefully see a wlan1 device which is the usb wireless device attached to the rpi. There should also be a driver listed as well. If you see ?????? listed as the driver it is likely that the wifi device can't be set to monitor mode.

Run

sudo airmon-ng check kill
sudo airmon-ng start wlan1

If successful the wlan1 interface will have changed to wlan1mon. Make sure the name of this interface matches the name set on line 33 in /usr/local/etc/kismet.conf.

Using Kismet_Server

For development I just run the kismet server inside a screen shell (or whatever the session is called).

screen
# follow prompts
kismet_server
# ctrl+a, d to exit

Now kismet_server should be running on the rpi.

Connecting to Kismet_Server with Netcat

netcat should already be installed on the rpi, to connect to the kismet_server run

nc localhost 2501

and you should start to see the output from the kismet_server.

You can also send commands to the kismet_server instructing it on the type of messages you want to see.

echo -e '\n!0 enable CLIENT mac,firsttime,lasttime,signal_dbm' | nc localhost 2501 -i 1

and this will output messages from kismet_server on a 1 second interval.

To understand all of the messages you can get from kismet you can query a protocol for its capabilities.

The structure of a capability inquiry message is

 CAPABILITY <protocol>

So in the example below we are asking for the capability of CLIENT:

echo -e '\n!2 CAPABILITY CLIENT' | nc localhost 2501

#response from kismet is below

*KISMET: 0.0.0 1483556987 pi101 pcapdump,netxml,nettxt,gpsxml,alert 1000
*PROTOCOLS: KISMET,ERROR,ACK,PROTOCOLS,CAPABILITY,TERMINATE,TIME,PACKET,STATUS,PLUGIN,SOURCE,ALERT,COMMON,
TRACKINFO,WEPKEY,STRING,GPS,BSSID,SSID,CLIENT,BSSIDSRC,CLISRC,NETTAG,CLITAG,REMOVE,CHANNEL,INFO,BATTERY,CRITFAIL
*CAPABILITY: CLIENT bssid,mac,type,firsttime,lasttime,manuf,llcpackets,datapackets,cryptpackets,gpsfixed,
minlat,minlon,minalt,minspd,maxlat,maxlon,maxalt,maxspd,agglat,agglon,aggalt,aggpoints,signal_dbm,noise_dbm,
minsignal_dbm,minnoise_dbm,maxsignal_dbm,maxnoise_dbm,signal_rssi,noise_rssi,minsignal_rssi,minnoise_rssi,
maxsignal_rssi,maxnoise_rssi,bestlat,bestlon,bestalt,atype,ip,gatewayip,datasize,maxseenrate,encodingset,
carrierset,decrypted,channel,fragments,retries,newpackets,freqmhz,cdpdevice,cdpport,dot11d,dhcphost,
dhcpvendor,datacryptset
*ACK: 2 OK

In the response above you can also see PROTOCOLS returned from kismet, any of those protocols can be queried for capabilities.

Now go build something 😀

How we built TwitBeat in 4 hours

2015-07-23T00:00:00+00:00

Cactus Hack took place in Tucson and there was a pretty good turnout. People started showing up around 9:00am, sometime between 10:00am or 10:30am the hosts started a presentation explaining the rules and awards of the hackathon. Teams had to build something that was a web-app, no console or desktop apps. And there had to be a cactus or cacti somewhere in the app. After the presentation people broke into self-made groups of 4 or 5 and started to brainstorm ideas. We were only allowed to code between 1:00pm and 5:00pm so there was quite a bit of time to plan, and eat. I partnered with my friends Charlie and Clay.

What should we build?

I had no ideas at all. Charlie had an idea of a heartbeat app, something that displayed a line like you see in an ECG chart or Oscilloscope.Charlie thought we could hook into the Github API and monitor the rate of stars on repos or something. There was some concern with rate limiting on the API so we turned towards Twitter. I’m not actually sure if the rate limiting would have been a problem, need to look into that later. There was concern again because the Twitter REST API has a rate limit on it, but I remembered from messing around with Storm that Twitter has a Streaming API.

What tools would we use?

We basically agreed that we would use the Twitter Streaming API to monitor tweets with “javascript” in them. Anytime the streaming API responded with a tweet, we'd send the text of the tweet and some data about the tweet to the client UI. All three of us were comfortable using React for the UI, and Node for the server. Since I had some prior experience with Socket.io it was decided that was how we’d get data from the server to the UI. I started to look around npm and searched duckduckgo for any modules that helped connect to the Twitter Streaming API. I found several modules and decided to use Twit based on absolutely nothing. Since we could not start coding until 1:00pm I didn’t really have a chance to evaluate modules.

We figured that the graph we were creating was going to be a SVG. I’ve worked with D3 and remembered that there are some excellent examples to look at. I didn’t really see anything there of what we wanted to build but I then remembered that Mike Bostock had written a blog post about path transitions and the graph looked pretty close to what we wanted to build. Meanwhile Charlie remembered that React Sparklines was mentioned on the Reactiflux Slack channel and the library provided all that we needed. So we started looking at how that component could be used. During all this time we just had to guess how everything was going to work, we couldn’t tinker and see how things were going to work.

How should it look?

I wish I took a picture of it, but we had sketched out a UI for the app and all we had was a squiggly line inside a rectangle. We also found some images like this that provided guidance on what we were to build.

Collaborating without destruction

Charlie had an existing React/Node project that had a gulpfile and package.json ready to go, so it made sense to just use whatever he had. We were going to use git/Github because there wasn’t enough time to stand up a Subversion server ☺. The plan was that at 1:00pm Charlie would build the file structure of our project, commit to Master and push to origin where everyone else could pull into their unique branches and start coding. Periodically we’d merge branches into Master and eventually end up with a working app inside Master ready to be presented.

Working on different pieces

Each of us had our own branch to work in and we just verbally decided who would work on what. We relied on Github as being our central location to push to. So we would work on our local branch, push to our branch on Github and when one of us reached a good stable point we’d let Charlie know to merge to Master. When one of us was done with a task we’d ask the others what they were working on and what we could help with. Having our own branches, making sure we were working on different tasks and frequently merging to Master were key to us finishing on time without failure. From what I understand some teams did not understand Git, or they didn’t branch/merge effectively and they were hindered by it.

There’s definitely something about hackathons and working with a group that each person already needs to know a few things to be effective. Distribute source control and branching/merging really stood out as things you need to already know.

We didn’t add features (besides one)

By about 4:30pm we were already done working on TwitBeat. At 5:00pm teams were to present what they worked on so we finished with a lot of time to spare. While we were coding sometimes we’d have ideas of a feature that might make the app better, but realistically we all agreed that adding some features would require more time. While coding an app you start to think of a few dozen little additions that can make your app better but each addition takes time to include. We focused on making sure we would have a functioning app once time was up. Keeping scope in check with time allowed was really important.

Presentation time

So we presented our app which you can see here. It worked and we were happy with it given the time alloted. And we won with a unanimous decision.

What I learned

Four hours to code an app is not a lot of time. There is no time to learn a new library or framework. So we had to use what we knew. I don’t really think there is any easier way to colloborate on a project without using distributed source control. Everyone has to agree with what they are going to build and communicate clearly who is working on what, and know what is still left to build. After merging branches to master it’s pretty important to make sure master works they way you all expect it to work. No broken changes should go into master. Hackathons don’t really prove much beyond which team can quickly put together something. TwitBeat is kind of a stupid little app that doesn’t do much itself but it does lead to other ideas.

Getting CoreOS to work properly with Vagrant and VirtualBox

2015-02-23T00:00:00+00:00

I read the instructions on setting up CoreOS on Vagrant. I followed the cloud config steps because I wanted to see what it was like to work with a cluster. Then I followed the steps on starting up CoreOS and I decided it was time to run vagrant up and get things going. Well I ended up with core-01 not being able to authenticate...huh.

vagrant up
...
==> core-01: Waiting for machine to boot. This may take a few minutes...
    core-01: SSH address: 127.0.0.1:2222
    core-01: SSH username: vagrant
    core-01: SSH auth method: private key
    core-01: Warning: Connection timeout. Retrying...
    core-01: Warning: Authentication failure. Retrying...

Of course I did what I always do and searched DuckDuckGo for “authentication failure retrying coreos” and found this Stack Overflow answer: CoreOS Authentication failure on vagrant up. The answer indicated that I should have read the quickstart part of the CoreOS documentation where it plainly states that if you were to use Vagrant you must do the following:

$ ssh-add ~/.vagrant.d/insecure_private_key

After doing that vagrant up worked correctly. I could ssh into any core using vagrant ssh core-<number> -- -A

Now that I can ssh into a core I tried to write to etcd following this example but I ended up with another problem.

curl -L http://127.0.0.1:4001/v1/keys/message -d value="Hello world"
Failed connect to 127.0.0.1:4001; Connection refused

Huh I missed something because this should be working. I searched issues on the CoreOS Github repo and found issue #21 where this comment illustrated to me that I should have adjusted the config.rb file before trying to test etcd. I needed to uncomment lines to allow the following code to become functional.


$new_discovery_url='https://discovery.etcd.io/new'

# To automatically replace the discovery token on 'vagrant up', uncomment
# the lines below:
#
if File.exists?('user-data') && ARGV[0].eql?('up')
 require 'open-uri'
 require 'yaml'

 token = open($new_discovery_url).read

 data = YAML.load(IO.readlines('user-data')[1..-1].join)
 data['coreos']['etcd']['discovery'] = token

 yaml = YAML.dump(data)
 File.open('user-data', 'w') { |file| file.write("#cloud-config\n\n#{yaml}") }
end
#

After fixing that I could run the following on core-01

curl -L http://127.0.0.1:4001/v1/keys/message -d value="Hello world"

and I could read the value of message across all of the cores. Pretty neat.

getDOMNode in React is deprecated and replaced with findDOMNode.

2015-02-04T00:00:00+00:00

React 0.13.0-beta.1 supports writing ES6 classes instead of calling React.createClass. See this React blog post for more details. I’ve been building a little app with 0.13.0-beta.1 and spent some time getting Jest to work with the components (or are they elements now?) I wrote. I was able to get my tests to pass but a warning kept popping up.

jest.dontMock('../build/PokemonRow.react');
describe('PokemonRow', function() {
  it('displays the name of the Pokemon', function() {
    var React = require('react/addons');
    var PokemonRow = require('../build/PokemonRow.react');
    var TestUtils = React.addons.TestUtils;

    // Render a paragraph element with the name of a fake pokemon
    var pokemon = {name:'Wuzzy'};
    var pokemonRow = TestUtils.renderIntoDocument(<PokemonRow pokemon={pokemon} key={pokemon.name}/>);

    // Verify that it actually was made.
    var name = TestUtils.findRenderedDOMComponentWithTag(pokemonRow,'p');
    expect(name.getDOMNode().textContent).toEqual(pokemon.name);
  });
});

Using Jest CLI v0.2.2
 PASS  __tests__/PokemonRow-test.js (2.105s)
Warning: getDOMNode(...) is deprecated in plain JavaScript React classes.
Warning: getDOMNode(...) is deprecated in plain JavaScript React classes.
1 test passed (1 total)
Run time: 2.29s

The online documentation for React didn't say anything about getDOMNode being deprecated. I figured that since I'm using a beta version the docs aren't online yet. So I went to the React repo on Github and searched for the warning string is deprecated in plain JavaScript React classes. I found the message in react/src/modern/class/ReactComponent.js but I still didn't understand what to use instead of getDOMNode. I searched for getDOMNode and found a pull request updating the documentation to replace getDOMNode with React.findDOMNode. I replaced getDOMNode and findRenderedDOMComponentWithTag with just React.findDOMNode and the warnings went away.

jest.dontMock('../build/PokemonRow.react');
describe('PokemonRow', function() {
  it('displays the name of the Pokemon', function() {
    var React = require('react/addons');
    var PokemonRow = require('../build/PokemonRow.react');
    var TestUtils = React.addons.TestUtils;

    // Render a paragraph element with the name of a fake pokemon
    var pokemon = {name:'Wuzzy'};
    var pokemonRow = TestUtils.renderIntoDocument(<PokemonRow pokemon={pokemon} key={pokemon.name}/>);

    // Verify that it actually was made with the right name.
    var name = React.findDOMNode(pokemonRow).textContent;
    expect(name).toEqual(pokemon.name);
  });
});

Using Jest CLI v0.2.2
 PASS  __tests__/PokemonRow-test.js (2.047s)
1 test passed (1 total)
Run time: 2.243s

NOTE: Initially I did a very dumb thing and forgot to run an ES6 to ES5 transpiler before running unit tests. I was running gulp-react to transform the JSX to Javascript but had a total brain fart about needing to convert the ES6 class definition. During my regular build process I use 6to5 during my Browserify packaging which happens after JSX. My unit tests just use the post-JSX files. I kept getting errors about and Unexpected reserved word and I thought something about the html markup in my component was off. I realised my mistake and have JSX and 6to5 happening during the same gulp task.

I started learning React and so far I like it.

2015-02-03T00:00:00+00:00

##I should have been building atomic pieces I’ve worked on projects in an environment where we are told on Monday what needs to be working on Friday. Tuesday, Wednesday and Thursday are spent rapidly getting something to work without taking any time to plan how we really want to build our app. Functions get tossed in a ViewModel. Templates are placed somewhere. On Friday during an internal demo the app does what it is expected to do. Whenever we get time to take a step back and look at what we built we see that the ViewModel has 60 functions in it. Some functions are near duplicates of each other and some functions belong in another place. There are other major mistakes made but the mistake I want to talk about is that we started putting the whole app together without building atomic pieces of it first.

##Sharing atomic pieces An atomic piece is just the smallest piece of UI that on its own can do something. Similar to a React component. I would imagine having an internal site like Bootstrap’s Components where team members can see the pieces that are already developed and from there they can build larger components from the smaller pieces. So I could have a component that takes Lat/Long values and converts to MGRS. That’s all it does and you can put it wherever you like. The conversion function and the UI are already put together just grab that component and place it wherever you want to. Don’t write a new UI for it. Just use what we have. The site would build off of existing code during CI so we could easily see if style sheets broke or if something doesn’t render correctly.

##I think React will help me break apps into pieces It’s pretty easy to see what an app needs to do and feel a little overwhelmed. It takes some practice to break the functionality of an app into the smallest piece that makes sense and build those pieces. So far with React it seems like I build the view into small components and let other components be composed of the little pieces. I haven’t spent any time with Flux yet so I’m not sure how well I’ll understand it. So far I’m liking React and I hope I can get to make some good use of it.

Adding custom icons to ionicons

2014-10-29T00:00:00+00:00

Download the ionicons source

The repo for ionicons is here. Fork or straight up download the repo. We’ll need it to generate the ionicons for ionic. I assume ionicons is an entity like Voltron. The next step assumes you are using OS X and have Homebrew installed.

Install some dependencies

Run the following commands to get Homebrew to install fontforge and ttfautohint.

brew install fontforge ttfautohint

On my personal computer I encountered the error below so I had to install XQuartz. I have another work computer which didn’t need XQuartz probably because it was already installed.

Homebrew does not package XQuartz. Installers may be found at:
  https://xquartz.macosforge.org
pango: Unsatisfied dependency: XQuartz 0.0.0
Homebrew does not package XQuartz. Installers may be found at:
  https://xquartz.macosforge.org
Error: Unsatisified requirements failed this build.

After XQuartz was installed it wanted me to logout. So I logged out and logged back in.

Run the command brew install fontforge ttfautohint again and wait since this could take a few minutes. Once that is over you will need to install Sass. You can run gem install sass if you have gem already working. If not then follow the Sass install instructions.

Add your custom icon

So with all of the above installed it’s time to add the custom icon to ionicons. Add your custom svg icon to the src directory in the ionicons repo. I’m taking a public domain icon from The Noun Project. Make sure you understand the conditions of usage for icons on The Noun Project before you add them to your app. I’m going to add the Informal-Learning icon. Rename the svg file to something meaningful. Right now the icon file is named icon_27471 but that won’t be as useful to use with ionicons, since the build process will use the file name as the name of the icon. I’ve renamed the svg file to informal-learning and have added it to the ionicons src directory. With the custom file added to the src directory it’s time to run ionicons build script.

Build ionicons

In the root of the ionicons directory run the following command python ./builder/generate.py. You should see output similar to this

Load Manifest, Icons: 601
New Icon: 
 - informal-learning
 - 0xf359
 - Standard Width: ios7-reload
 - Standard Width: load-a
 - Standard Width: load-b
 - Standard Width: load-c
 - Standard Width: load-d
 - Standard Width: loop
 - Standard Width: refresh
Save Manifest, Icons: 602
Save Build, Icons: 602
Generate SCSS
Generate CSS From SCSS
Generate Minified CSS From SCSS
Generate LESS
Generate Cheatsheet
Generate component.json
Generate composer.json
Generate bower.json

Add the new ionicons files to your ionic project

Now copy the files from these folders to the destination folders

ionicons\css    ->    <ionicApp>/www/lib/ionic/css/
ionicons\fonts  ->    <ionicApp>/www/lib/ionic/fonts/
ionicons\scss   ->    <ionicApp>/www/lib/ionic/scss/ionicons/

It might seem like you wouldn’t need to copy the scss files. I thougth the same thing too but my icon wouldn’t work. So just copy them because they matter.

Start your app with ionic serve add the new icon with icon="icon ion-informal-learning" and behold such magical wizardry.

If you encounter any problems just figure it out. These instructions worked for me on two different computers.

Problems running Homebrew on Yosemite

2014-10-24T00:00:00+00:00

My first problem was running `brew`

Just trying to run brew would cause this error to show up.

/usr/local/bin/brew: /usr/local/Library/brew.rb:
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby:
bad interpreter: No such file or directory

Easily enough I found how to fix the above error from John Assael. I had to change the first line in the /usr/local/Library/brew.rb file so that the path

#!/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby -W0

was changed to use the Current folder under Versions like this:

#!/System/Library/Frameworks/Ruby.framework/Versions/Current/usr/bin/ruby -W0

My next problem was running `brew update`

Now brew would run but I couldn’t run brew update because of this error:

brew update
error: Your local changes to the following files would be overwritten by merge:
  Library/brew.rb
Please, commit your changes or stash them before you can merge.
Aborting
Error: Failure while executing: git pull -q origin refs/heads/master:refs/remotes/origin/master

I found a way to fix this in Brew issue #11448. All I had to do is listed below.

cd `brew --prefix`
git remote add origin https://github.com/mxcl/homebrew.git
git fetch origin
git reset --hard origin/master

Hopefully that fixes some of your problems with Homebrew on Yosemite.

Notes on Reducing Complexity

2014-05-11T00:00:00+00:00

How to reduce code complexity

Command Query Separation

Start writing smaller functions by separating the actions that a method performs. Command query separation is about keeping command and query actions in different functions. Commands are functions that are similar to setters in that they do something. Queries then are similar to getters in that they return something. So you wouldn't want to combine getters and setters in one function. The benefit of this shows up once you try writing unit tests for functions where command query separation was maintained. You'll end up being able to write tests that are focused for each function.

Hinting and Linting

Keep your code sane. Run JSHint (or JSLint) on it. From the JSHint website

Any code base eventually becomes huge at some point, and simple mistakes—that would not show themselves when written—can become show stoppers and waste hours of debugging. And this is when static code analysis tools come into play and help developers to spot such problems. JSHint scans a program written in JavaScript and reports about commonly made mistakes and potential bugs. The potential problem could be a syntax error, a bug due to implicit type conversion, a leaking variable or something else.

Cyclomatic Complexity

The number of independent paths a piece of code can take. Cyclomatic complexity is calculated using numbers for each path, the higher the number the more complicated the code is. For each path you will need to write a test for it, so try not to have all of the tests just be for one function. Instead break up the function so that the tests are spread across functions. Maintaining the tests will then be simpler. Supposedly you should keep your cyclomatic complexity (sounds like a hair dryer) below 10. This is one thing that should never go to 11.

Browsing npm for ‘complexity’ resulted in these two popular tools.

complexity-report Software complexity analysis for JavaScript projects.
plato JavaScript source analysis and visualizer.

Pay attention to the issues on Github to see which tool is actively being maintained.

Reusability

Try to rely on a library or framework instead of writing code that does the same thing. jQuery, lo-dash, underscore,backbone,angular,knockout,node all do their job extremely well. Writing code to mimic what they do for your application is just a bad idea. You already have plenty to worry about in writing code for your project. So reuse what's already available.

Reusability also goes to your own code. You might have some code inside a function that converts GMT to Mountain Standard time. You might have another place in your code which converts Nepal Time to Tuvalu time. The code is probably nearly identical except for the timezones that are being converted from and to. Just write a timezone converter function that has it's logic in one place. And call that function from wherever you were converting time zones. That way if timezone calculations change you change the code in one place, not eleven different places.

Fan-Out

The number of dependencies your function directly and indirectly depends on or references. Dependencies are in the form of external modules or objects. Tight coupling can be seen in an object or function with high fan-out. To reduce tight coupling you can use dependency injection or eventing. To reduce fan-out you can use a facade pattern. Testing code with high fan-out is difficult since mocking and stubbing dependencies is required. Yes really when you spend more time writing mocks and stubs you'll soon be making changes in your code. It's that obvious of a problem.

Fan-In

Think of fan-in as the inverse of fan-out. It counts how many modules reference a function or object. I've taken the official definition of fan-in from the book Testable Javascript:

The fan-in of procedure A is the number of local flows into procedure A plus the number of data structures from which procedure A retrieves information.

High fan-in should exist for common or utility functions, think of something like authorization checks,logging, formatting, conversions etc... Those are tasks that can be called from anywhere or called frequently. They should have high fan-in. Code that isn't called frequently such as initialization code should have low fan-in. The idea being that code that isn't utilized frequently shouldn't be called or depended on a lot by other modules.

Coupling

So fan-out counts the number of dependencies a module has, coupling is the relationship between modules. From my experience tight coupling makes it really hard to edit code since changing one thing usually requires editing code in a bunch of other unrelated places too. At first you'll wonder why in the world is this piece of code referenced all the way in this other place. And hey it's referenced here too but in a different way and it's not even used the way it's supposed to. Then you cry for a day or two and swear you'll never write tightly coupled code. Of course you don't write tightly coupled code. It's always someone else who did it and left you with a maintenance nightmare.

The six levels of coupling in descending order of tightness

Content Coupling. When you call a method/function on an external object directly, or mutate the object by adding or editing it's properties.
Common Coupling. Your object is commonly coupled if it shares a global value with another object.
Control Coupling. The object changes behavior based on an external flag or condition.
Stamp Coupling. Passing an object to an external object, when the external object only utilizes a few properties but was sent properties it doesn't use.
Data Coupling. Objects pass messages to each other with no transfer of control to an external object. I didn't really understand this the first time I read it.
No Coupling. Easiest to understand.
Instantiation. Not exactly a form of coupling but it still does couple code to an object. Every time you instantiate and object your code is now responsible for the life cycle of that object. You should at least make sure it's capable of being garbage collected. Closures are important to watch out for since they make garbage collection difficult even if their parent object goes out of scope.

To move from tight coupling to loose coupling you can use dependency injection. You can also utilize the factory pattern (and abstract factory) to make it easier to just ask for an object.

Dependency Injection

Dependency injection helps release the coupling of an object from it's dependencies. An object is handed it's dependencies instead of needing to instantiate them locally. If you aren't familiar with dependency injection you can read the wikipedia article and another explanation of dependency injection at the AngularJS docs.

Comments

Commenting code is critical. Just because there is a test for the code that doesn't mean you are free from commenting your functions. You need to explain to other programmers what is going on. Testable Javascript mentions the following tools for converting comments to documents

YUIDoc
JSDoc
Docco
Rocco - Ruby port of Docco

Peer review

Finally have someone else review your code. If another programmer can't understand your code than there's a real obvious problem with complexity.

Naming your variables

I'd like to add my own little thing here for reducing complexity. Use proper naming conventions for variables, objects, functions. Please don't do this:

var c = SomeFunction();

I have no clue at all what kind of thing c is supposed to be. Will it be an object, a number, a boolean. What is it for? Also don't do this:

var value = AnotherFunction();

Seriously I know value is a value, it's a value for what?

I need to finish these books

2014-05-08T00:00:00+00:00

It's easy to buy a book but it's much harder for me to remember to finish reading it. I used to spend time after work reading literature and non-fiction but I never spent time with technical material. That changed in the past year since I started learning Javascript. Now I've acquired quite a few books on JS and a couple other interesting books. I'll stick with one book at a time and will take notes of what I've learned.

The Books I need to read

* Testable Javascript by Mark Ethan Trostler * CSS3 For Web Designers by Dan Cederholm * Javascript Allonge by Reginald Braithwaite * Mobile First by Luke Wroblewski * Responsive Web Design by Ethan Marcotte * JavaScript Enlightenment by Cody Lindley * Understanding Computation by Tom Stuart * Data Structures and Algorithms with JavaScript by Michael McMillan

I'm eager to finish Testable Javascript first. Becoming better at writing testable and maintainable code is a major goal for me. Understanding Computation and Javascript Allonge are two books I really want to read, but those are the books I need to take my time with. I started Data Structures and Algorithms with JavaScript and found some errors in the code which turned me off from the book. I submitted some errata for the book and I guess I can continue with the book just to find more bugs.

CSS Mistakes

2014-04-10T00:00:00+00:00

10 CSS mistakes every web designer must avoid

The problem with some CSS is that you can tell that it's written in the top-down style. It mimics the HTML layout rather than abstracting the design elements, often using ids for context, such as #header, #content. This usually results in long selectors (how many times have you seen .menu ul li a {} ?), and the code is going to be really rough to debug and do maintenance on. To fix this CSS, you'll need to work on abstracting design components from the page, which will also help you remove redundancy in your code.

Each of the 10 tips are great because they talk about mistakes that are so easy to make.

Coding after work

2014-04-01T00:00:00+00:00

My original answer

You will probably have a higher chance of developing technical skills if you take some time to study and code during your free time. You shouldn't depend on your job to train you on new languages or frameworks. There are a lot of things you and I don't know and we won't have time to learn about them while at work.

Also being a developer isnt just purely coding. There's the ability to write legible code, write tests, know what to use when, know how to read code that you didnt write (or even in a language you arent a master of), find the cause of a bug in an efficient way. You need to be able to talk effectively to non-technical people to figure out why they think X is a bug or how Y is really supposed to work. Those type of skills kinda evolve during your work hours but you have to be aware about improving on them.

I think if you don't spend some extra time programming you very well might grow stale. Years will pass by and youll realize you want to get a new job but you dont really know that much beyond what you did at work.

The first part of my answer I bring up the point of not relying on your employer to train you. There are mulitple ways an employer can train you, they can pay for tuition/conferences, hire talent to come in for training sessions, pay for books. I've come to believe that any of that is gravy and not something you are entitled to. Of course it benefits the employer to spend money training you but some places don't consider that factor at all. If you really want to get better at what you do then take the time to learn. Don't just sit around thinking:

“I need to learn what Verb.js is but I need my boss to setup a training session on that.”
“Nobody explained to me how to use Git. I won't use it until that really busy developer sits down and gives me a personal training session.”
“Linux is so confusing I can't use it until someone trains me.”

Assume a developer puts in about 40 hours a week. In most places those hours are spent fixing bugs in a legacy product. That's realistic because there is a ton of legacy code out there which works but needs some maintenance. If all you know are the patterns you've seen in the legacy code and the approaches it takes to solving problems than you probably know only one way to solve those problems. There are other platforms/patterns/tools you can use but you won't know about them unless you program/learn during your free time. Being a great developer or just a good developer doesn't mean you refuse to work on legacy code, it can mean that you know how to improve it and you know why it's rotting. Being a smart developer means you know how to successfully migrate that legacy code out to something more stable/usable/modifiable.

The second part of the question relates great development strictly to programming. Personally I think that development is more than just churning out lines of code. Not everyone can be the Michael Jordan of programming so you have to be a good teammate and make sure you work well with others. There's a kind of greatness that comes out of developers who can bring their whole team +1 a level.

The final point I want to raise is that for many people being a developer means being an employed developer. You might have a great time working on something right now but will you be able to find a good job doing that same thing in another city, or for better pay, or for a better employer? It's risky to assume that you'll always be able to get a job for that one thing you're midly good at. You don't need to jump on the next newest language or framework but you should be learning what everyone else is doing in case you need to make a move.

How to set your version of Visual Studio for npm

2014-03-27T00:00:00+00:00

When installing some npm modules on Windows an error may show up that says:

error MSB8020: The build tools for Visual Studio 2010 (Platform Toolset = 'v100') cannot be found.

What you can do is set your installed version of Visual Studio when running npm install.

To do that simply run:

npm install <module> -msvs_version=2013

where msvs_version is equal to the version of Visual Studio that you have.

Yay!

The Git Cheat Sheet

2014-03-04T00:00:00+00:00

I initially found this at Github and it's identical to cheat.errtheblog.

Setup

Clone the repository specified by <repo> this is similar to “checkout” in some other version control systems such as Subversion and CVS:

git clone <repo>

Add colors to your ~/.gitconfig file:

[color]
  ui = auto
[color "branch"]
  current = yellow reverse
  local = yellow
  remote = green
[color "diff"]
  meta = yellow bold
  frag = magenta bold
  old = red bold
  new = green bold
[color "status"]
  added = yellow
  changed = green
  untracked = cyan

Highlight whitespace in diffs:

[color]
  ui = true
[color "diff"]
  whitespace = red reverse
[core]
  whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol

Add aliases to your ~/.gitconfig file:

[alias]
  st = status
  ci = commit
  br = branch
  co = checkout
  df = diff
  dc = diff --cached
  lg = log -p
  lol = log --graph --decorate --pretty=oneline --abbrev-commit
  lola = log --graph --decorate --pretty=oneline --abbrev-commit --all
  ls = ls-files

  # Show files ignored by git:
  ign = ls-files -o -i --exclude-standard

Configuration

Edit the .git/config [or ~/.gitconfig] file in your $EDITOR:

git config -e [--global]

Sets your name and email for commit messages:

git config --global user.name ’John Doe'
git config --global user.email johndoe@example.com

Tells git branch and git checkout to setup new branches so that git pull will appropriately merge from that remote branch. Recommended. Without this you will have to add --track to your branch command or manually merge remote tracking branches with fetch and then merge:

git config branch.autosetupmerge true

This tells git to convert the newlines to the system's standard when checking out files, and to LF newlines when committing in:

git config core.autocrlf true

To view all options:

git config --list

To ignore whitespace:

git config apply.whitespace nowarn

You can add --global after git config to any of these commands to make it apply to all git repos (writes to ~/.gitconfig).

Info

Use this to recover from major mess ups! It's basically a log of the last few actions and you might have luck and find old commits that have been lost by doing a complex merge:

git reflog

Show a diff of the changes made since your last commit:

git diff

To diff against a particular file:

git diff -- <filename>

To show a diff between staging area and HEAD:

git diff --cached

Show files added to the staging area, files with changes, and untracked files:

git status

Show recent commits, most recent on top:

git log

Useful options:

--color with color
--graph with an ASCII-art commit graph on the left
--decorate with branch and tag names on appropriate commits
--stat with stats (files changed, insertions, and deletions)
-p with full diffs
--author=foo only by a certain author
--after="MMM DD YYYY" ex. ("Jun 20 2008") only commits after a certain date
--before="MMM DD YYYY" only commits that occur before a certain date
--merge only the commits involved in the current merge conflicts.

Show commits between the specified range:

git log <ref>..<ref>

Useful for seeing changes from remotes for example git log HEAD..origin/master (after git remote update)

Show the changeset (diff) of a commit specified by <rev>, which can be any SHA1 commit ID, branch name, or tag (shows the last commit (HEAD) by default) also to show the contents of a file at a specific revision, use git show <rev>:<filename> this is similar to cat-file but much simpler syntax:

git show <rev>

Show only the names of the files that changed, no diff information:

git show --name-only <rev>

Show who authored each line in <file>:

git blame <file>

Show who authored each line in <file> as of <rev> (allows blame to go back in time):

git blame <file> <rev>

Really nice GUI interface to git blame:

git gui blame

Show only the commits which affected listing the most recent first:

git whatchanged <file>

View all changes made to a file on a branch, this could be combined with git remote show <remote> to find all changes on all branches to a particular file:

git whatchanged <branch> <file>  | grep commit | \
     colrm 1 7 | xargs -I % git show % <file>

Show the diff between a file on the current branch and potentially another branch

git diff <commit> head path/to/fubar

Shows diff for staged (git-add'ed) files (which includes uncommitted git cherry-pick'ed files):

git diff --cached [<file>]

List all files in the index and under version control:

git ls-files

Show the current version on the remote repo. This can be used to check whether a local is required by comparing the local head revision:

git ls-remote <remote> [HEAD]

Adding / Deleting

Add <file1>, <file2>, etc... to the project

git add <file1> <file2> ...

Add all files under directory <dir> to the project, including subdirectories

git add <dir>

Add all files under the current directory to the project WARNING including untracked files:

git add .

Remove <file1>, <file2>, etc... from the project

git rm <file1> <file2> ...

Remove all deleted files from the project

git rm $(git ls-files --deleted)

Commits absence of <file1>, <file2>, etc... from the project

git rm --cached <file1> <file2> ...

Ignoring

####Option 1:

Edit $GIT_DIR/.git/info/exclude. See Environment Variables below for explanation on $GIT_DIR.

####Option 2:

Add a file .gitignore to the root of your project. This file will be checked in.

Either way you need to add patterns to exclude to these files.

Staging

Add changes in <file1>, <file2> ... to the staging area (to be included in the next commit):

git add <file1> <file2> ...

Interactively walk through the current changes (hunks) in the working tree, and decide which changes to add to the staging area:

git stage <file1> <file2> ...

git add -p

git stage --patch

Interactively add files/changes to the staging area. For a simpler mode (no menu), try git add --patch (above)

git add -i

git stage --interactive

Unstaging

Remove the specified files from the next commit:

git reset HEAD <file1> <file2> ...

Committing

Commit <file1>, <file2>, etc..., optionally using commit message <msg>, otherwise opening your editor to let you type a commit message

git commit <file1> <file2> ... [-m <msg>]

Commit all files changed since your last commit (does not include new untracked files):

git commit -a

Commit verbosely, i.e. includes the diff of the contents being committed in the commit message screen:

git commit -v

Edit the commit message of the most recent commit:

git commit --amend

Redo previous commit, including changes made to <file1>, <file2>, etc...

git commit --amend <file1> <file2> ...

Branching

List all local branches:

git branch

List all remote branches:

git branch -r

List all local and remote branches:

git branch -a

Create a new branch named <branch>, referencing the same point in history as the current branch

git branch <branch>

create a new branch named <branch>, referencing <start-point>, which may be specified any way you like, including using a branch name or a tag name:

git branch <branch> <start-point>

Create a new remote branch named <branch>, referencing <start-point> on the remote. Repo is the name of the remote.

    git push <repo> <start-point>:refs/heads/<branch>

Example:

git push origin origin:refs/heads/branch-1

git push origin origin/branch-1:refs/heads/branch-2

git push origin branch-1 ## shortcut

Create a tracking branch. Will push/pull changes to/from another repository.

git branch --track <branch> <remote-branch>

Example:

git branch --track experimental origin/experimental

Make an existing branch track a remote branch. (As of Git 1.7.0):

git branch --set-upstream <branch> <remote-branch>

Example:

git branch --set-upstream foo origin/foo

Delete the branch <branch> if the branch you are deleting points to a commit which is not reachable from the current branch, this command will fail with a warning:

git branch -d <branch>

Delete a remote-tracking branch.

git branch -r -d <remote-branch>

Example:

git branch -r -d wycats/master

Even if the branch points to a commit not reachable from the current branch, you may know that that commit is still reachable from some other branch or tag. In that case it is safe to use this command to force git to delete the branch.

git branch -D <branch>

Make the current branch <branch>, updating the working directory to reflect the version referenced by <branch>

git checkout <branch>

Create a new branch <new> referencing <start-point>, and check it out.

git checkout -b <new> <start-point>

Removes a branch from a remote repository:

git push <repository> :<branch>

Example:

git push origin :old_branch_to_be_deleted

Checkout a file from another branch and add it to this branch. File will still need to be added to the git branch, but it's present.

git co <branch> <path to new file>

Example:

git co remote_at_origin__tick702_antifraud_blocking ..../...nt_elements_for_iframe_blocked_page.rb

Show the contents of a file that was created on another branch and that does not exist on the current branch.

git show <branch> -- <path to file that does not exist>

Example:

git show remote_tick702 -- path/to/fubar.txt

Show the contents of a file at the specific revision. Note: path has to be absolute within the repo:

git show <rev>:<repo path to file>

Merging

Merge branch <branch> into the current branch; this command is idempotent and can be run as many times as needed to keep the current branch up-to-date with changes in <branch>:

git merge <branch>

Merge branch <branch> into the current branch, but do not autocommit the result; allows you to make further tweaks:

git merge <branch> --no-commit

Merge branch <branch> into the current branch, but drops any changes in <branch>, using the current tree as the new tree:

git merge <branch> -s ours

Cherry-Picking

Selectively merge a single commit from another local branch:

git cherry-pick [--edit] [-n] [-m parent-number] [-s] [-x] <commit>

Example:

git cherry-pick 7300a6130d9447e18a931e898b64eefedea19544

Get the blob of some file whether it is in a repository or not:

git hash-object <file-path>

Find the commit in the repository that contains the file blob:

obj_blob="$1"
git log --pretty=format:'%T %h %s' \
| while read tree commit subject ; do
    if git ls-tree -r $tree | grep -q "$obj_blob" ; then
        echo $commit "$subject"
    fi
done

Squashing

WARNING “git rebase” changes history. Be careful & Google it.

Change all but the first “pick” to “squash”. Squash the last 10 commits into one big commit:

git rebase --interactive HEAD~10

Conflicts

Work through conflicted files by opening them in your mergetool (opendiff, kdiff3, etc.) and choosing left/right chunks. The merged result is staged for commit:

git mergetool

For binary files or if mergetool won't do, resolve the conflict(s) manually and then do:

git add <file1> [<file2> ...]

Once all conflicts are resolved and staged, commit the pending merge with:

git commit

Update the remote-tracking branches for <remote> (defaults to “origin”). Does not initiate a merge into the current branch (see “git pull” below):

git fetch <remote>

Fetch changes from the server, and merge them into the current branch. Note: .git/config must have a [branch "some_name"] section for the current branch, to know which remote-tracking branch to merge into the current branch. Git 1.5.3 and above adds this automatically:

git pull

Update the server with your commits across all branches that are COMMON between your local copy and the server. Local branches that were never pushed to the server in the first place are not shared:

git push

Update the server with your commits made to <branch> since your last push. This is always required for new branches that you wish to share. After the first explicit push, git push by itself is sufficient:

git push origin <branch>

The same as git push origin <branch> but a little more obvious what is happening:

git push origin <branch>:refs/heads/<branch>

Example:

git push origin twitter-experiment:refs/heads/twitter-experiment

Reverting

Reverse commit specified by <rev> and commit the result. This does not do the same thing as similarly named commands in other version control systems such as svn revert:

git revert <rev>

Re-checkout <file>, overwriting any local changes:

git checkout <file>

Re-checkout all files, overwriting any local changes. This is most similar to svn revert if you are familiar with Subversion commands:

git checkout .

Fix mistakes / Undo

Abandon everything since your last commit; this command can be DANGEROUS. If merging has resulted in conflicts and you'd like to just forget about the merge, this command will do that.

git reset --hard

Undo your most recent successful merge and any changes that occurred after. Useful for forgetting about the merge you just did. If there are conflicts (the merge was not successful), use git reset --hard (above) instead.

git reset --hard ORIG_HEAD

git reset --hard origin/master

Forgot something in your last commit? That's easy to fix. Undo your last commit, but keep the changes in the staging area for editing:

git reset --soft HEAD^

Redo previous commit, including changes you've staged in the meantime. Also used to edit commit message of previous commit:

git commit --amend

Plumbing

Determine if merging sha1-B into sha1-A is achievable as a fast forward; non-zero exit status is false:

test <sha1-A> = $(git merge-base <sha1-A> <sha1-B>)

Stashing

Save your local modifications to a new stash.

git stash

git stash save <optional-name>

Example:

git svn rebase 

git pull

Restore the changes recorded in the stash on top of the current working tree state:

git stash apply

Restore the changes from the most recent stash, and remove it from the stack of stashed changes:

git stash pop

List all current stashes:

git stash list

Show the contents of a stash - accepts all diff args

git stash show <stash-name> -p

Delete the stash:

git stash drop [<stash-name>]

Delete all current stashes:

git stash clear

Remotes

Adds a remote repository to your git config. Can be then fetched locally.

git remote add <remote> <remote_URL>

Example:

git remote add coreteam git://github.com/wycats/merb-plugins.git

git fetch coreteam

Delete a branch in a remote repository:

git push <remote> :refs/heads/<branch>

Create a branch on a remote repository.

git push <remote> <remote>:refs/heads/<remote_branch>

Example:

git push origin origin:refs/heads/new_feature_name

Replace a <remote> branch with <new_remote> think twice before do this.

git push <repository> +<remote>:<new_remote>

Example:

git push origin +master:my_branch

Prune deleted remote-tracking branches from git branch -r listing

git remote prune <remote>

Add a remote and track its master:

git remote add -t master -m master origin git://example.com/git.git/

Show information about the remote server:

git remote show <remote>

Track a remote branch as a local branch. It seems that somtimes an extra 'remotes/' is required, to see the exact branch name, git branch -a.

git checkout -b <local branch> <remote>/<remote branch>

Example:

git checkout -b myfeature origin/myfeature 

git checkout -b myfeature remotes/<remote>/<branch>

For branches that are remotely tracked (via git push) but that complain about non-fast forward commits when doing a git push. The git pull synchronizes local and remote, and if all goes well, the result is pushable.

git pull <remote> <branch>

git push

Retrieves all branches from the remote repository. After this git branch --track ... can be used to track a branch from the new remote.

git fetch <remote>

Submodules

Add the given repository at the given path. The addition will be part of the next commit.

git submodule add <remote_repository> <path/to/submodule>

Update the registered submodules (clone missing submodules, and checkout the commit specified by the super-repo). --init is needed the first time.

git submodule update [--init]

Executes the given command within each checked out submodule.

git submodule foreach <command>

####Removing submodules:

Delete the relevant line from the .gitmodules file.
Delete the relevant section from .git/config.
Run
```
git rm --cached path_to_submodule
```

(no trailing slash).

Commit and delete the now untracked submodule files.

####Updating submodules To update a submodule to a new commit:

update submodule:
```
cd <path to submodule>

git pull
```

commit the new version of submodule:

cd <path to toplevel>

git commit -m "update submodule version"

check that the submodule has the correct version git submodule status If the update in the submodule is not committed in the main repository, it is lost and doing git submodule update will revert to the previous version.

Patches

Generate the last commit as a patch that can be applied on another clone (or branch) using git am. Format patch can also generate a patch for all commits using git format-patch HEAD^ HEAD. All page files will be enumerated with a prefix, e.g. 0001 is the first patch.

git format-patch HEAD^

Generate a patch for a single commit. Revision does not need to be fully specified:

git format-patch <Revision>^..<Revision>

Example:

git format-patch d8efce43099^..d8efce43099

Applies the patch file generated by format-patch.

git am <patch file>

Generates a patch file that can be applied using patch: patch -p0 < patchfile. Useful for sharing changes without generating a git commit:

git diff --no-prefix > patchfile

Git Instaweb

git instaweb --httpd=webrick [--start | --stop | --restart]

Environment Variables

Your full name to be recorded in any newly created commits. Overrides user.name in .git/config

GIT_AUTHOR_NAME, GIT_COMMITTER_NAME

Your email address to be recorded in any newly created commits. Overrides user.email in .git/config

GIT_AUTHOR_EMAIL, GIT_COMMITTER_EMAIL

Location of the repository to use (for out of working directory repositories):

GIT_DIR

Location of the Working Directory - use with GIT_DIR to specifiy the working directory root or to work without being in the working directory at all:

GIT_WORKING_TREE

Changing history

Change author for all commits with given name

git filter-branch --commit-filter '
        if [ "$GIT_COMMITTER_NAME" = "<Old Name>" ];
        then
                GIT_COMMITTER_NAME="<New Name>";
                GIT_AUTHOR_NAME="<New Name>";
                GIT_COMMITTER_EMAIL="<New Email>";
                GIT_AUTHOR_EMAIL="<New Email>";
                git commit-tree "$@";
        else
                git commit-tree "$@";
        fi' HEAD