This post summarizes months of real-world testing across multiple tools, runtimes, and models. The conclusion surprised me.

The Goal​

Build a local, subscription-free AI development environment that can support:

• Architecture discussions and documentation
• Repository exploration and planning
• Code modifications, refactoring, and bug fixes
• ADRs and Obsidian notes
• Angular, NestJS, .NET, Docker, and Kubernetes projects

The setup should run entirely locally on a MacBook Pro with 16 GB RAM.

The Biggest Discovery​

Before getting into tool comparisons and benchmarks, the most important finding was this:

Agent capability > Coding benchmark score

A model that can find files, edit code, use tools, and execute multi-step workflows is often more useful than a model with a higher coding benchmark score that cannot reliably do those things.

This single insight changed which models and tools came out on top.

Tools Evaluated​

Three coding agent frameworks were tested in depth:

Two local model runtimes were compared:

Tool Comparison Results​

OpenCode​

OpenCode won as the primary workspace because it is built for agentic workflows. It plans, explores repositories, generates documents, and writes long-form content reliably.

Strengths: Planning, architecture analysis, documentation, repository exploration, long-form content
Weaknesses: Requires a larger context window; performance depends heavily on model tool-use capability

Aider: The Surprise Disappointment​

Aider has a good reputation for code editing, and that reputation may be deserved in other setups. In this workflow it underperformed significantly.

During testing, a simple prompt like Create a file containing one line: hello caused Aider to generate unrelated JavaScript instead of creating the file. It also failed at file discovery and documentation generation.

In this workflow it was not recommended.

Continue.dev​

The simplest of the three. Install the VSCode extension, point it at a local model, and it works. Great for IDE chat, quick explanations, and autocomplete. Not the right tool for architecture work or anything requiring multi-step reasoning.

Runtime Comparison​

The runtime turned out to matter more than expected.

What went wrong with Ollama and OpenCode​

When connecting OpenCode to local models through Ollama, several problems appeared:

• Some models returned no answer at all
• Some responses were truncated mid-output
• Context handling was opaque — hard to know what was actually loaded
• OpenCode's agent prompt was too heavy for small contexts
• The experience was inconsistent across sessions

Why LM Studio worked better​

After switching OpenCode to LM Studio, the problems mostly disappeared:

• The exact loaded model ID was visible via /v1/models
• Context length was visible and configurable in the UI
• The OpenAI-compatible API made troubleshooting straightforward
• Models that failed through Ollama worked correctly through LM Studio

Key observation: The models themselves were not the main problem. The Ollama + OpenCode combination was less reliable on this machine. LM Studio + OpenCode behaved better with the same models.

You can verify what LM Studio is serving at any time:

curl http://localhost:1234/v1/models

Model Comparison​

Real-world tool use test results​

One of the most revealing tests was simply asking each model to create and edit files using OpenCode's tools:

gemma4 refused editing tasks despite seeing the available tools. llama3.1:8b worked but delivered poor value for its resource cost.

qwen2.5-coder:7b scores well on coding benchmarks but has mixed tool use in practice — it underperformed as an OpenCode agent compared to expectations. This is the core finding: benchmark scores do not predict agent capability.

qwen3.5:9b is the main model: strong reasoning, reliable tool use, excellent for architecture and documentation work. qwen3.5:2b is the fast companion for quick tasks and notes.

The Context Window Problem​

This was one of the most important — and most surprising — findings.

OpenCode needs more context than you expect​

When OpenCode was connected to a model with 8k context, this error appeared immediately:

n_keep: 26460 >= n_ctx: 8192

Then later, after attempts to reduce it:

n_keep: 8232 >= n_ctx: 8192

OpenCode's initial system prompt alone exceeds 8k tokens. This means the model never even received the user's first message — the context was already full before the conversation started.

The fix: set LM Studio context to 32,768 tokens and match that in the OpenCode model configuration.

Recommended context sizes​

The Final Stack​

After all this testing, the recommended setup has three modes:

Primary: Architecture & Documentation Work​

OpenCode + LM Studio + qwen3.5:9b
Context: 32,768

Use for: architecture reviews, documentation, ADRs, planning, repository exploration, Obsidian notes

Fast Mode: Quick Tasks​

OpenCode + LM Studio + qwen3.5:2b
Context: 32,768

Use for: quick questions, notes, summaries, repository exploration

IDE Companion​

Continue.dev + LM Studio or Ollama + qwen3.5:2b
Context: 8,192

Use for: IDE chat, code explanations, autocomplete, small edits

Quick Decision Table​

Installation​

Ollama (for Continue.dev)​

curl -fsSL https://ollama.com/install.sh | sh
ollama pull qwen3.5:2b

LM Studio (for OpenCode)​

Download from the official LM Studio website. Load qwen3.5:9b for primary work or qwen3.5:2b for fast mode, set context to 32,768, and start the local server.

Tip: LM Studio's Zen models are particularly effective on machines with limited RAM. They are well-optimized for Apple Silicon and worth trying if you want good performance without pushing memory limits.

Verify the server is running:

curl http://localhost:1234/v1/models

OpenCode​

curl -fsSL https://opencode.ai/install | bash

Configure ~/.config/opencode/opencode.json to point at LM Studio. The model name in the config must match the exact id returned by /v1/models:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "lmstudio": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LM Studio Local",
      "options": {
        "baseURL": "http://localhost:1234/v1"
      },
      "models": {
        "qwen/qwen3.5-9b": {
          "name": "Qwen 3.5 9B (Main)",
          "limit": {
            "context": 32768,
            "output": 2048
          }
        },
        "qwen/qwen3.5-2b": {
          "name": "Qwen 3.5 2B (Fast)",
          "limit": {
            "context": 32768,
            "output": 2048
          }
        }
      }
    }
  }
}

Continue.dev​

Install the Continue extension in VSCode and point it at LM Studio or Ollama with qwen3.5:2b.

Lessons Learned​

Future Upgrade Path​

If upgrading to 32 GB RAM: evaluate larger models and bigger contexts.

If upgrading to 64 GB RAM: re-evaluate 32B-class models and 64k contexts.

On 16 GB RAM, avoid running memory-heavy apps (Docker Desktop, multiple browser windows, IDE indexing) at the same time as a loaded 9B model.

Conclusion​

The biggest discovery was not a model — it was a combination:

OpenCode + LM Studio delivered a substantially better experience than any other setup tested.

The setup that works on a 16 GB MacBook Pro M1:

• OpenCode for thinking, planning, and writing
• Continue.dev for IDE support and autocomplete
• LM Studio as the OpenCode runtime
• 32k context for OpenCode, 8k for Continue.dev
• qwen3.5:9b as the main model, qwen3.5:2b for fast tasks

The principle that guided every decision: agent capability matters more than benchmark scores.

Tools at a Glance​

Detailed Tool Breakdown​

Command Line Essentials​

atuin​

Atuin revolutionizes shell history management. Instead of the basic up-arrow history search, Atuin provides a searchable, syncable database of your shell commands across all your machines. It captures context like the directory you were in and exit codes, making it easy to find that command you ran three weeks ago.

Key Features:

• Full-text search through your entire shell history
• Sync history across multiple machines (end-to-end encrypted)
• Context-aware search (filter by directory, exit status, time)
• Import existing shell history from bash, zsh, fish

Installation:

brew install atuin

fd​

fd is a modern replacement for the classic find command. It's faster, more intuitive, and uses sensible defaults like ignoring .gitignore patterns automatically.

Why I use it:

• Simpler syntax than find: fd pattern vs find . -name '*pattern*'
• Colored output for better readability
• Respects .gitignore by default
• Blazingly fast parallel directory traversal

Installation:

brew install fd

fzf​

fzf is an interactive fuzzy finder that integrates beautifully with the shell, vim, and other tools. It transforms how you search for files, navigate directories, and search command history.

Common use cases:

• Ctrl+R for fuzzy command history search
• Ctrl+T for fuzzy file search
• Integration with vim/neovim for file navigation
• Custom scripts for searching anything (git branches, processes, etc.)

Installation:

brew install fzf

ripgrep​

ripgrep (rg) is hands-down the fastest way to search through code. It automatically respects .gitignore, searches recursively, and provides colorized output with context.

Performance highlights:

• Faster than grep, ag, ack, and others
• Respects .gitignore and hidden files by default
• Supports multiple search patterns and file type filtering
• Essential for large codebases

Installation:

brew install ripgrep

tmux​

tmux is a terminal multiplexer that lets you manage multiple terminal sessions from a single window. It's invaluable for remote work, long-running processes, and organizing your workspace.

Why it's essential:

• Persistent sessions that survive disconnections
• Split panes and windows for multitasking
• Session management for different projects
• Scriptable and highly customizable

Installation:

brew install tmux

Version Control & Git Tools​

git​

Git is the backbone of modern software development. The distributed version control system that powers collaboration across teams and projects worldwide.

Installation:

brew install git

git-delta​

Delta transforms git diffs into beautiful, syntax-highlighted output with side-by-side comparisons. It makes code review and understanding changes much easier.

Visual improvements:

• Syntax highlighting in diffs
• Side-by-side diff view
• Line numbering and git blame integration
• Configurable themes and styles

Installation:

brew install git-delta

gh​

GitHub CLI brings GitHub functionality to your terminal. Create PRs, review issues, manage repos, and automate workflows without leaving the command line.

Favorite features:

• gh pr create - Create pull requests from the terminal
• gh pr checkout - Check out PRs by number
• gh repo clone - Quickly clone repos
• gh run view - Monitor GitHub Actions workflows

Installation:

brew install gh

Container & Kubernetes Tools​

colima​

Colima is a lightweight container runtime for macOS that provides Docker and Kubernetes support with minimal resource usage. It's an excellent free alternative to Docker Desktop.

Benefits:

• Low memory footprint compared to Docker Desktop
• Simple CLI interface: colima start, colima stop
• Supports both Docker and Kubernetes
• Configurable CPU, memory, and disk allocation

Installation:

brew install colima

kubernetes-cli​

kubectl is the official Kubernetes command-line tool for deploying applications, inspecting resources, and managing cluster operations.

Installation:

brew install kubernetes-cli

helm​

Helm is the package manager for Kubernetes, making it easy to define, install, and upgrade complex Kubernetes applications using charts.

Installation:

brew install helm

k9s​

k9s provides a terminal UI for Kubernetes that makes cluster management visual and interactive. It's like having a dashboard in your terminal.

Productivity boost:

• Real-time cluster monitoring
• Navigate pods, services, deployments with keyboard shortcuts
• View logs, describe resources, port-forward with ease
• Vim-like keybindings for efficiency

Installation:

brew install derailed/k9s/k9s

Development Tools​

mise​

mise (formerly rtx) is a polyglot runtime manager that handles multiple language versions seamlessly. It replaces tools like nvm, rbenv, pyenv, and asdf with a single, fast tool written in Rust.

Language support:

• Node.js, Python, Ruby, Go, Java, and more
• Per-project version configuration with .mise.toml
• Faster than asdf (written in Rust)
• Compatible with asdf plugins

Installation:

brew install mise

uv​

uv is a blazingly fast Python package installer and resolver written in Rust. It's 10-100x faster than pip and provides a better dependency resolution experience.

Speed improvements:

• Parallel downloads and installs
• Global cache for packages
• Better dependency conflict resolution
• Drop-in replacement for pip commands

Installation:

brew install uv

neovim​

Neovim is a modern, extensible fork of Vim with better defaults, Lua scripting support, and built-in LSP (Language Server Protocol) support. It's my primary editor for all development work.

Modern features:

• Native LSP support for IDE-like features
• Lua configuration (more powerful than VimScript)
• Treesitter for better syntax highlighting
• Extensive plugin ecosystem

Installation:

brew install neovim

Data & Visualization Tools​

jq​

jq is a lightweight command-line JSON processor. It's indispensable for working with APIs, parsing JSON logs, and transforming data.

Common uses:

• Parse API responses: curl api.example.com | jq '.data'
• Filter arrays: jq '.[] | select(.status == "active")'
• Transform JSON structure
• Pretty-print JSON

Installation:

brew install jq

graphviz​

Graphviz generates graphs and diagrams from text descriptions using the DOT language. It's perfect for visualizing system architecture, data structures, and relationships.

Installation:

brew install graphviz

AWS Tools​

awscli​

AWS CLI is the official command-line interface for Amazon Web Services. It provides direct access to AWS services and is essential for automation and infrastructure management.

Key operations:

• Manage EC2 instances, S3 buckets, Lambda functions
• Automate deployments and infrastructure changes
• Query and filter resources with JMESPath
• Profile management for multiple AWS accounts

Installation:

brew install awscli

Desktop Applications​

Claude Code​

Claude Code is an AI-powered coding assistant that runs in your terminal. It helps with code generation, refactoring, debugging, and understanding complex codebases.

Capabilities:

• Intelligent code generation and completion
• Context-aware suggestions
• Code explanation and documentation
• Debugging assistance

Installation:

brew install --cask claude-code

Warp​

Warp is a modern, Rust-based terminal that reimagines the terminal experience with AI features, collaborative tools, and a more intuitive interface.

Standout features:

• AI command suggestions
• Block-based output for easy copying
• Command palette and searchable history
• Collaborative terminal sharing
• Built-in workflows and command templates

Installation:

brew install --cask warp

Maccy​

Maccy is a lightweight, open-source clipboard manager for macOS. It keeps a history of everything you copy, making it easy to access previous clipboard contents.

Simple but powerful:

• Keyboard-driven interface
• Search clipboard history
• Pin frequently used items
• Privacy-focused (no cloud sync)

Installation:

brew install --cask maccy

Obsidian​

Obsidian is a powerful knowledge base and note-taking application that works with local Markdown files. It's excellent for personal knowledge management and linking ideas together.

Why I love it:

• Local-first (your data stays on your machine)
• Graph view for visualizing connections
• Extensive plugin ecosystem
• Markdown-based for portability
• Backlinking and bi-directional links

Installation:

brew install --cask obsidian

MacTeX​

MacTeX is a complete TeX distribution for macOS, essential for creating professional documents, academic papers, and technical documentation with LaTeX.

Installation:

brew install --cask mactex

Managing This Setup​

To replicate this setup on a new machine, I use Homebrew Bundle. You can download my Brewfile and install all tools at once:

# Install Homebrew (if not already installed)
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# Download the Brewfile and install all tools
curl -O https://raw.githubusercontent.com/ammarnajjar/ammarnajjar.github.io/main/blog/2026-02-23-essential-dev-tools/Brewfile
brew bundle install --file=Brewfile

# Or to create a Brewfile from your current setup
brew bundle dump --file=Brewfile

Conclusion​

These tools form the foundation of my development environment. Each one solves a specific problem and integrates well with the others. The key is finding tools that match your workflow and actually using them consistently.

What tools are essential in your setup? I'm always interested in discovering new productivity boosters and improvements to existing workflows.

Goals and requirements​

I collected these goals before coding:

• Privacy-first: keep user data local by default; no server-side storage unless the user opts in.
• Low network usage: avoid redundant requests; be friendly to metered or slow connections.
• Responsive UI: range selections and interactions should feel immediate, even when network calls are needed in the background.
• Robustness: accept imported or hand-edited JSON and avoid re-fetching data unnecessarily.
• Testable: core behaviors must have unit tests to prevent regressions.

Implementation challenges​

Several practical issues emerged while building the app:

1. Range caching vs. freshness

   • Problem: caching prevents redundant requests, but users expect recent short-term data to be fresh (e.g. 1 month view where today's price matters).

   • Trade-offs explored:

     • Always fetch 1M (fresh) but cache longer ranges — simpler for correctness, but noisy for users who import histories.
     • Never fetch on range change (UI-only) — efficient but risks displaying stale data.

   • Solution chosen: cache all ranges explicitly, but store 1M as a persisted fetched-range so imported data that already covers 1M won't cause a fetch; additionally keep a history-based check (earliest candle <= cutoff) to treat imported history as covering a range.

2. Hand-edited or unsorted history arrays

   • Problem: imported JSON may contain history arrays that are not sorted or that start later than the cutoff; naive checks that look at history[0] can be wrong.

   • Solution: compute the earliest timestamp across a history array (min) and compare normalized UTC dates to decide coverage.

3. Per-item state persistence and migrations

   • Problem: changing what is persisted (e.g., switching from implicit 1M to explicit fetchedRanges) requires handling existing localStorage states.

   • Solution: make persisted metadata explicit (write 1M into fetchedRanges when appropriate) and optionally provide a migration/backfill path that populates fetchedRanges for existing users based on current history.

Add-stock form​

The Add-stock form is a compact flow that lets users add a new symbol to their portfolio. It validates symbols client-side, shows recent quotes for confirmation, and writes the new item into the store. Newly added symbols are picked up by the auto-refresh loop after the first cycle.

The Add-stock Form with symbol validation

How state is organized​

• The app stores the entire application state under a single root key in localStorage (via a small helper) to keep reads/writes simple and make export/import predictable.
• The store (StoreProvider) keeps the portfolio array in React state and writes it to localStorage on every change. Each PortfolioItem has fields like:

type PortfolioItem = {
	id: string;
	symbol: string;
	qty: number;
	avgPrice?: number;
	currentPrice?: number;
	history?: { time: string; value: number }[];
	fetchedRanges?: Range[]; // e.g. ['1D','1W','1M']
	lastUpdated?: string;
}

Key helpers:

1. storage helper (simple JSON wrapper around localStorage)

export const readState = () => {
	try { return JSON.parse(localStorage.getItem(ROOT_KEY) || '{}'); } catch (_) { return {}; }
};

export const set = (key: string, value: unknown) => {
	const s = readState(); s[key] = value; localStorage.setItem(ROOT_KEY, JSON.stringify(s));
};

export const get = (key: string, defaultValue?: any) => {
	const s = readState(); return s[key] === undefined ? defaultValue : s[key];
};

2. StoreProvider persistence and fetched-range writes

// persist portfolio whenever it changes
useEffect(() => { storage.set('portfolio', portfolio); }, [portfolio]);

// on successful fetch for an item:
setPortfolio(current => current.map(p => p.id === item.id ? ({
	...p,
	history: mergeHistories(p.history, history),
	lastUpdated: new Date().toISOString(),
	fetchedRanges: Array.from(new Set([...(p.fetchedRanges || []), fetchRange])),
}) : p));

mergeHistories is a small utility that merges two arrays of dated candles, preserving order and avoiding duplicates.

Chart interaction and fetch policy​

When a user clicks a range button (e.g. 1D, 1W, 1M), the UI should update immediately and decide whether a network refresh is needed. The decision algorithm in handleRangeChange is:

Interactive chart showing selected range and per-stock breakdown; this view updates when ranges change.

1. Update local range state and call setSelectedRange in the store so the global selection reflects the UI.
2. If the store's refreshPortfolioRange is available, check whether any PortfolioItem already has the targetRange recorded in fetchedRanges.
3. For 1M additionally check whether the item's history earliest date is at-or-before the 1M cutoff (UTC-normalized); if yes treat it as covered.
4. If none of the items cover the range, call refreshPortfolioRange(targetRange) which will fetch missing history and update fetchedRanges.

const handleRangeChange = async (targetRange: Range) => {
	setRange(targetRange); setSelectedRange?.(targetRange);
	if (!refreshPortfolioRange) return;

	const anyHave = portfolio.some(p => {
		if (Array.isArray(p.fetchedRanges) && p.fetchedRanges.includes(targetRange)) return true;
		if (targetRange === '1M' && Array.isArray(p.history) && p.history.length > 0) {
			// compute earliest timestamp robustly
			const earliestTs = Math.min(...p.history.map(h => Date.parse(h.time + 'T00:00:00')));
			const cutoff = getRangeCutoff('1M');
			return Date.UTC(new Date(earliestTs).getFullYear(), new Date(earliestTs).getMonth(), new Date(earliestTs).getDate())
				<= Date.UTC(cutoff.getFullYear(), cutoff.getMonth(), cutoff.getDate());
		}
		return false;
	});

	if (!anyHave) await refreshPortfolioRange(targetRange);
}

Merge Histories​

The function below ensures merging two history arrays yields a sorted array without duplicate date entries:

function mergeHistories(oldH?: Candle[], newH?: Candle[]): Candle[] {
	const map = new Map<string, number>();
	(oldH || []).forEach(c => map.set(c.time, c.value));
	(newH || []).forEach(c => map.set(c.time, c.value));
	return Array.from(map.entries()).map(([time, value]) => ({ time, value })).sort((a,b) => a.time.localeCompare(b.time));
}

The table view shows merged history rows (per-day candles) for each item. mergeHistories ensures rows are unique by date and sorted chronologically; this table is used both for exports and for quick manual inspection when users import JSON.

Merged history table used for export/import and quick inspection.

Auto-refresh and background updates​

The app includes an optional auto-refresh feature that updates quotes and short-range history in the background. Goals for this feature were:

• Keep UI responsive: update data in the background without blocking user interactions.
• Minimize network usage: only fetch updates for ranges that are considered "fresh" (short ranges like 1D/1W) or when items explicitly need a refresh.
• Avoid redundant requests: respect fetchedRanges and the history-based coverage check described earlier.

App header and controls — range buttons, add-stock and status indicators (responsive).

Design notes:

• A lightweight polling loop runs when the app has focus and the user has enabled auto-refresh. It calls a refreshPortfolio() function periodically (configurable interval, e.g. 60s).
• refreshPortfolio() fetches quotes for all items and optionally fetches short-range history (for example 1D) only if the item does not already have a recent timestamp or if fetchedRanges does not include that range.
• The UI shows a subtle status indicator while background refreshes are in progress; individual components update when the store writes new data.

Simplified code snippet (store polling + guarded refresh):

// in StoreProvider
useEffect(() => {
	if (!autoRefreshEnabled) return;
	let cancelled = false;
	const tick = async () => {
		if (cancelled) return;
		try {
			await refreshPortfolio({ onlyShortRanges: true });
		} catch (e) { /* swallow non-fatal errors */ }
		if (!cancelled) setTimeout(tick, AUTO_REFRESH_INTERVAL_MS);
	};
	tick();
	return () => { cancelled = true; };
}, [autoRefreshEnabled]);

// refreshPortfolio guarded by fetchedRanges
export async function refreshPortfolio(opts?: { onlyShortRanges?: boolean }) {
	const rangesToRefresh = opts?.onlyShortRanges ? ['1D'] : ALL_RANGES;
	for (const p of portfolio) {
		for (const r of rangesToRefresh) {
			if (Array.isArray(p.fetchedRanges) && p.fetchedRanges.includes(r)) continue;
			await refreshStock(p.id, r);
		}
	}
}

Notes:

• The polling loop is intentionally conservative: it only requests short-range data by default to keep bandwidth low.
• refreshStock and refreshPortfolio append the fetched range to fetchedRanges so subsequent cycles skip already-covered ranges.
• Errors in background refreshes are logged and do not interrupt the UI; a user-facing error flow is only triggered for foreground actions initiated by the user.

Testing and verification​

• The repo uses Vitest + Testing Library for unit tests. Important tests include verifying importPortfolio behavior, refreshPortfolio caching logic, and the updated fetchedRanges persistence for 1M.

How to run locally​

git clone https://github.com/ammarnajjar/portfolio.git
cd portfolio
npm ci
npm run dev

1. Configuration Commands​

Setting up your Git environment correctly is the first step. These commands help you define your identity and preferences.

• git config --global user.name "Your Name"

  • What it does: Sets the global username for your Git commits. This name will appear in the commit history for all repositories on your system.
  • When to use: Typically, this is one of the first commands you run after installing Git. It ensures your commits are attributed to you.
  • How to use:

    git config --global user.name "Ammar Najjar"
    

• git config --local user.email <email>

  • What it does: Sets the email address for commits specific to the current repository. This overrides the global email setting.
  • When to use: When you need to use a different email address for a particular project (e.g., a work email for a company project, and a personal email for open-source contributions).
  • How to use:

    git config --local user.email your.email@example.com
    

• git config --local user.signingkey <key>

  • What it does: Configures the GPG key to be used for signing commits locally within a specific repository.
  • When to use: If your project or organization requires signed commits for verification and integrity, and you need to use a specific key for that repository.
  • How to use:

    git config --local user.signingkey YOUR_GPG_KEY_ID
    

Understanding and Using user.signingkey​

Commit signing with GPG (GNU Privacy Guard) adds a layer of security and trust to your Git history. When you sign a commit, you cryptographically prove that you are the author of that commit and that the commit's content has not been tampered with since it was signed.

1. Generate a GPG Key (if you don't have one): If you don't already have a GPG key, you'll need to generate one. This is a one-time setup.

gpg --full-generate-key

Follow the prompts to choose the key type, key size, expiration date, and set a passphrase.

2. Get Your GPG Key ID: Once you have a GPG key, you need its ID to tell Git which key to use.

gpg --list-secret-keys --keyid-format LONG

Look for a line similar to sec rsa4096/YOUR_KEY_ID 2023-01-01 [SC] where YOUR_KEY_ID is the 16-character hexadecimal string. This is the ID you'll use.

3. Configure Git to Use Your GPG Key: You can configure Git globally or locally for a specific repository.

• Global Configuration (for all repositories):

  git config --global user.signingkey YOUR_KEY_ID
  

• Local Configuration (for the current repository only):

  git config --local user.signingkey YOUR_KEY_ID
  

4. Enable Automatic Commit Signing (Optional but Recommended): To automatically sign all your commits, you can set a global configuration:

git config --global commit.gpgsign true

If you don't set this, you'll need to manually sign each commit using git commit -S.

5. Sign a Commit:

• If commit.gpgsign is true, simply run:

  git commit -m "Your commit message"
  

  You will be prompted for your GPG passphrase.
• If commit.gpgsign is false, manually sign with:

  git commit -S -m "Your commit message"
  

6. Verify a Signed Commit: To see if a commit is signed and by whom, use:

git log --show-signature

You will see a "Good signature from..." message if the signature is valid and the key is trusted.

• git config --global push.default current
  • What it does: Sets the default behavior for git push. With current, git push will push the current branch to its upstream branch (a branch on the remote repository that it tracks).
  • When to use: To simplify your push workflow. Instead of always typing git push origin <branch-name>, you can just type git push and Git will know which remote branch to push to.
  • How to use:

    git config --global push.default current
    

2. Branching and Navigation​

Branches are fundamental to Git, allowing parallel development. These commands help you manage and navigate them.

• git rev-parse --abbrev-ref HEAD

  • What it does: Displays the name of the current branch. HEAD refers to the current commit, and --abbrev-ref shows its symbolic name (the branch name) rather than the full SHA-1 hash.
  • When to use: To quickly check which branch you are currently on, especially useful in scripts or when you need to confirm your context.
  • How to use:

    git rev-parse --abbrev-ref HEAD
    

• git rev-parse --abbrev-ref HEAD | sed 's/.*\(PATTERN-HERE\).*/\1/'

  • What it does: Extracts a specific pattern from the current branch name using sed. This is useful for parsing structured branch names (e.g., feature/JIRA-123-description).
  • When to use: In scripting or automation where you need to extract specific identifiers (like a ticket number) from your branch name.
  • How to use: Replace PATTERN-HERE with your desired regular expression. For example, to extract "JIRA-123" from "feature/JIRA-123-add-feature":

    git rev-parse --abbrev-ref HEAD | sed 's/.*\(JIRA-[0-9]*\).*/\1/'
    

• git config --global alias.gco = "!f() { git branch -a | grep -e $1 -m 1 | sed 's/remotes\\/origin\\///' | xargs git checkout; }; f"

  • What it does: Creates a global Git alias named gco that allows you to checkout a branch by providing a partial pattern. It searches all local and remote branches, picks the first match, and checks it out.
  • When to use: When you frequently switch between branches and only remember a part of the branch name, or when branch names are long and complex.
  • How to use: After setting the alias, you can use it like this:

    git gco PATTERN-HERE
    # Example: git gco feature/my-new-feature (if your branch is feature/my-new-feature-branch)
    

• git stash branch <branch-name>

  • What it does: Creates a new branch from the commit that was current when the stash was created, and then applies the stashed changes to this new branch. The stash entry is then dropped.
  • When to use: When you've stashed some work, and later decide that those changes should form the basis of a new feature branch, rather than being applied to the current branch.
  • How to use:

    git stash branch new-feature-branch
    

3. Committing and History Inspection​

Understanding your project's history and making changes are core Git operations.

• git commit --no-verify

  • What it does: Creates a commit, but bypasses any pre-commit hooks configured for the repository.
  • When to use: Use with caution. This is typically used when a pre-commit hook is temporarily failing or when you know the changes you are committing are intentionally bypassing a specific check (e.g., committing work-in-progress that doesn't yet pass linting).
  • How to use:

    git commit --no-verify -m "WIP: Bypassing hooks for now"
    

• git diff --name-only

  • What it does: Shows only the names of files that have been changed (staged or unstaged) since the last commit.
  • When to use: To quickly get an overview of which files you've modified without seeing the actual content changes.
  • How to use:

    git diff --name-only
    

• git log --follow <file>

  • What it does: Displays the commit history for a specific file, including commits where the file was renamed or moved. Without --follow, git log would stop tracking the file's history if it was renamed.
  • When to use: To understand the complete evolution of a file, even if its path has changed over time.
  • How to use:

    git log --follow src/main.js
    

• git log -p --follow <file>

  • What it does: Similar to git log --follow, but also shows the patch (diff) for each commit, detailing the exact changes made to the file.
  • When to use: When you need to see not just when a file changed, but what changed in each commit throughout its history, including renames.
  • How to use:

    git log -p --follow src/main.js
    

• git show --remerge-diff

  • What it does: (Available in Git 2.36.0 and later) When applied to a merge commit, this command shows the diff with merge conflicts and how they were resolved.
  • When to use: After a merge, to review the specific changes made to resolve conflicts, providing clarity on the merge strategy.
  • How to use:

    git show --remerge-diff <merge-commit-hash>
    

• git log -p -Gword

  • What it does: Finds commits where the specified "word" (or regular expression) appears in the diff (the actual changes made to the code).
  • When to use: To pinpoint commits that introduced or modified a specific piece of code, a variable name, or a function call.
  • How to use:

    git log -p -G"my_function_name"
    

• git log --grep=word

  • What it does: Finds all commits where the commit message contains the specified "word" (or regular expression).
  • When to use: To search for commits related to a specific feature, bug fix, or topic based on keywords in their commit messages.
  • How to use:

    git log --grep="bugfix"
    

4. Tagging and Utilities​

Tags are used to mark specific points in history, typically for releases.

• git tag -l | rg -e "2\d.\d.\d$" | sort | tail -n 10
  • What it does: This is a pipeline of commands:
    • git tag -l: Lists all tags in the repository.
    • rg -e "2\d.\d.\d$": Filters the tags using ripgrep (an external tool) to find those matching a pattern like "2.x.x" (e.g., 2.1.0, 2.36.0).
    • sort: Sorts the filtered tags alphabetically.
    • tail -n 10: Shows the last 10 entries, effectively giving you the 10 most recent "stable" looking tags based on the pattern.
  • When to use: To quickly identify recent stable release tags in a repository that follows a semantic versioning scheme.
  • How to use: Ensure you have ripgrep installed.

    git tag -l | rg -e "2\d.\d.\d$" | sort | tail -n 10
    

5. Essential Daily Workflow Commands​

These commands are the bread and butter of a software developer's interaction with Git, covering everything from checking status to pushing changes.

• git status

  • What it does: Shows the status of your working directory and staging area. It tells you which changes have been staged, which haven't, and which files aren't being tracked by Git.
  • When to use: Constantly! This is your primary way to understand the current state of your repository before committing or performing other operations.
  • How to use:

    git status
    

• git add <file> / git add . / git add -p

  • What it does: Adds changes from the working directory to the staging area, preparing them for the next commit.
    • <file>: Stages specific file(s).
    • .: Stages all changes in the current directory and its subdirectories.
    • -p (patch): Allows you to interactively select specific hunks (parts) of changes within files to stage.
  • When to use: Before every commit, to select exactly what changes you want to include. -p is invaluable for crafting clean, focused commits.
  • How to use:

    git add my_feature.js
    git add .
    git add -p
    

• git commit -m "Your message" / git commit --amend

  • What it does: Records the staged changes into the repository as a new commit.
    • -m: Provides a commit message directly on the command line.
    • --amend: Allows you to modify the most recent commit. You can change its message, add/remove files, or modify existing changes.
  • When to use:
    • -m: After staging changes, to finalize a logical unit of work.
    • --amend: To fix a typo in the last commit message, or to add a forgotten file/change to the last commit before pushing it to a shared remote.
  • How to use:

    git commit -m "Add user authentication feature"
    git commit --amend -m "Fix typo in auth feature commit message"
    

• git branch <new-branch-name>

  • What it does: Creates a new branch pointing to the current commit.
  • When to use: To start working on a new feature, bug fix, or experiment without affecting the main codebase.
  • How to use:

    git branch feature/new-dashboard
    

• git switch <branch-name> / git checkout <branch-name>

  • What it does: Switches your working directory to the specified branch. git switch is the newer, safer command for changing branches, while git checkout is more versatile (can also restore files).
  • When to use: To move between different lines of development.
  • How to use:

    git switch main
    git checkout feature/new-dashboard # Older but still common
    

• git checkout -b <new-branch-name>

  • What it does: A convenient shortcut that creates a new branch and immediately switches to it.
  • When to use: When you want to start a new feature branch and jump right into it.
  • How to use:

    git checkout -b bugfix/login-issue
    

• git pull

  • What it does: Fetches changes from the remote repository and automatically merges them into your current branch. It's a shortcut for git fetch followed by git merge.
  • When to use: To synchronize your local branch with its upstream remote counterpart, pulling down the latest changes from collaborators.
  • How to use:

    git pull origin main
    # Or simply: git pull (if upstream is set)
    

• git fetch

  • What it does: Downloads objects and refs from another repository (the remote) into your local repository. It does not merge or modify your local working files.
  • When to use: To see what changes have occurred on the remote without integrating them into your current work. Useful for reviewing remote branches or preparing for a merge/rebase.
  • How to use:

    git fetch origin
    

• git push

  • What it does: Uploads your local commits to the remote repository.
  • When to use: To share your completed work with others or to back up your changes.
  • How to use:

    git push origin feature/my-new-feature
    # Or simply: git push (if upstream is set)
    

• git merge <branch>

  • What it does: Integrates changes from the specified branch into your current branch.
  • When to use: To combine completed feature branches into a main development branch, or to pull changes from a shared branch into your own.
  • How to use:

    git switch main
    git merge feature/my-new-feature
    

• git rebase <branch>

  • What it does: Reapplies your current branch's commits on top of another base branch. This rewrites your branch's history, creating a linear history.
  • When to use: To keep your feature branch up-to-date with the main branch without creating merge commits, resulting in a cleaner, linear history. Use with caution on branches that have already been pushed and shared.
  • How to use:

    git switch feature/my-new-feature
    git rebase main
    

• git reset --hard HEAD~1 / git revert HEAD

  • What it does: Both undo changes, but in different ways:
    • git reset --hard HEAD~1: Moves the current branch pointer back one commit, discarding any changes in the working directory and staging area. This rewrites history.
    • git revert HEAD: Creates a new commit that undoes the changes introduced by the specified commit. This preserves history.
  • When to use:
    • git reset --hard: To completely discard the last commit (and any uncommitted changes) locally, especially if you haven't pushed it yet. Use with extreme caution as it loses data.
    • git revert: To undo a commit that has already been pushed to a shared remote, as it creates a new commit that explicitly reverses the changes, maintaining a clear history.
  • How to use:

    git reset --hard HEAD~1 # Discard last commit
    git revert HEAD         # Create a new commit that undoes the last one
    

• .gitignore file

  • What it does: A plain text file in your repository's root directory that tells Git which files or directories to ignore. Git will not track these files, nor will it show them as untracked.
  • When to use: To prevent unnecessary files (like build artifacts, temporary files, IDE configuration, or sensitive credentials) from being committed to the repository.
  • How to use: Create a file named .gitignore in your project root and list patterns for files/folders to ignore.

    # Example .gitignore content
    /node_modules/
    .env
    *.log
    build/
    

These commands represent a powerful subset of Git's capabilities. By understanding their purpose and knowing when to apply them, you can navigate your project's history, manage branches, and collaborate more efficiently. Regular practice with these commands will solidify your Git proficiency and enhance your development workflow.

Summery:​

The central theme revolves around the idea that "success is the product of daily habits—not once-in-a-lifetime transformations". It emphasizes the compounding effects of small, consistent improvements and the importance of systemic thinking over goal-setting.

I. The Power of "Atomic Habits": Compounding Small Improvements​

The fundamental premise of "Atomic Habits" is that minuscule, consistent changes, referred to as "atomic habits," accumulate over time to produce significant, even "remarkable," results.

• Compound Interest of Self-Improvement: Habits are likened to "the compound interest of self-improvement". Just as money multiplies with compound interest, "the effects of your habits multiply as you repeat them".
• The 1% Rule: Getting "just 1 percent better each day, you’ll end up with results that are nearly 37 times better after one year". Conversely, being 1% worse leads to a near-zero outcome (0.99^365 = 0.03). This small difference "can make over time is astounding".

• Delayed Outcomes: The impact of small habits is often not immediately apparent. "It is only when looking back two, five, or perhaps ten years later that the value of good habits and the cost of bad ones becomes strikingly apparent". This requires patience, as "Change can take years—before it happens all at once," echoing the stonecutter analogy: "Yet at the hundred and first blow it will split in two, and I know it was not that last blow that did it—but all that had gone before". This period of unnoticeable progress before breakthroughs is called the "Plateau of Latent Potential". People often stop making changes because they don't see immediate tangible results, not realizing their work is being stored.
• Trajectory Over Current Results: What truly matters is the "current trajectory" set by your habits, rather than "current results". Your "outcomes are a lagging measure of your habits". For example, your net worth is a lagging measure of your financial habits, and your weight is a lagging measure of your eating habits. Tiny daily choices "will compound ten or twenty years down the line". Good habits make time your ally, while bad habits make time your enemy.
• Double-Edged Sword: Habits are a "double-edged sword". They can either compound for you or against you. For instance, productivity and knowledge compound positively, as does being nicer in interactions leading to stronger relationships. Conversely, stress and negative thoughts can compound into serious issues.
• Atomic Habit Defined: An "atomic habit" refers to a tiny change, a marginal gain, or a 1 percent improvement, and they are "little habits that are part of a larger system". Just as atoms are the building blocks of molecules, "atomic habits are the building blocks of remarkable results". They are small and easy to do, yet also "the source of incredible power".

II. Systems Over Goals: The Foundation for Lasting Change​

A pivotal concept introduced is the distinction between goals and systems, advocating for a focus on the latter for sustained progress.

• Goals vs. Systems: "Goals are about the results you want to achieve. Systems are about the processes that lead to those results". The author argues that focusing solely on goals often leads to failure because the underlying "system" for change is flawed.
• Falling to the Level of Your Systems: "You do not rise to the level of your goals. You fall to the level of your systems". This highlights that consistent behavior is a direct output of the established processes, not merely aspirations.
• Goal-less Thinking: True long-term thinking is described as "goal-less thinking". It's about "the cycle of endless refinement and continuous improvement," and "your commitment to the process that will determine your progress".

III. Identity-Based Habits: Changing Who You Are​

Beyond merely changing behaviors, "Atomic Habits" emphasizes that true, lasting habit change stems from a shift in identity.

• Behavior Change as Identity Change: "True behavior change is identity change". Instead of focusing on what you want to achieve (outcome-based goals) or what you need to do (process-based habits), the most profound change comes from focusing on "who you wish to become".
• "Repeated Beingness": Your identity is literally your "repeated beingness," formed by the actions you consistently take. Every action is a "vote for the type of person you wish to become".
• Proof Through Small Wins: To build a new identity, one must "Prove it to yourself with small wins". For instance, "Each time you write a page, you are a writer. Each time you practice the violin, you are a musician".
• Pride and Motivation: "The more pride you have in a particular aspect of your identity, the more motivated you will be to maintain the habits associated with it". The example of Clark stopping nail-biting after taking pride in his manicured nails illustrates this point.

IV. The Four Laws of Behavior Change​

The author presents four fundamental laws for building good habits and breaking bad ones. These laws offer a framework for designing an environment conducive to desired behaviors.

1. Make it Obvious (1st Law):​

• Awareness is Key: Habits are often "nonconscious and automatic". To improve them, you must first become aware of them. "Until you make the unconscious conscious, it will direct your life and you will call it fate".
• The Habits Scorecard: A practical tool to identify and categorize existing habits (+ for good, – for bad, = for neutral) by listing daily behaviors and assessing their long-term impact. The goal is to "simply notice what is actually going on" without judgment.
• Implementation Intentions: Clearly defining when and where a habit will occur: "I will [BEHAVIOR] at [TIME] in [LOCATION]". This specificity helps in saying "no to things that derail progress".
• Habit Stacking: Linking a new habit to an existing one: "After [CURRENT HABIT], I will [NEW HABIT]". This leverages established routines as cues.
• Environmental Design: Make cues for good habits visible and accessible (e.g., placing workout clothes out). Conversely, make cues for bad habits invisible (e.g., removing junk food from sight). "We like to think that we are in control... but the truth... is that many of the actions we take each day are shaped... by the most obvious option".
• Priming the Environment: "Resetting the room" (e.g., cleaning up after an activity) prepares the environment for the next desired action, making it easy to start.

2. Make it Attractive (2nd Law):​

• Dopamine-Driven Feedback Loop: Habits are deeply tied to dopamine, a neurotransmitter associated with craving and desire. "When dopamine rises, so does our motivation to act". It's the "anticipation of a reward—not the fulfillment of it—that gets us to take action".
• Supernormal Stimuli: Humans are naturally drawn to "heightened versions of reality" (like hyper-palatable processed foods) that amplify desire.
• Temptation Bundling: Pair an action you need to do with an action you want to do. Formula: "After [HABIT I NEED], I will [HABIT I WANT]" (e.g., Ronan Byrne connecting Netflix to his stationary bike).
• Social Influence: We are heavily influenced by the habits of those around us, especially "the close, the many, and the powerful". "One of the most effective things you can do to build better habits is to join a culture where your desired behavior is the normal behavior".
• Reframing: Change your mindset about habits by highlighting their benefits or reframing negative associations. "You don’t 'have' to. You 'get' to" (e.g., "I get to run in the morning" instead of "I have to run"). This relates to the inverse: "make it unattractive" (e.g., Allen Carr's reframing of smoking).
• Underlying Motives: Cravings are specific manifestations of deeper, underlying human motives (e.g., to conserve energy, obtain food, connect with others, reduce uncertainty, gain status). Understanding these deeper desires can help in making habits attractive.

3. Make it Easy (3rd Law):​

• Reduce Friction: Make good habits effortless and bad habits difficult. "The greater the friction, the less likely the habit".
• The Law of Least Effort: Human nature seeks the path of least resistance. Design your environment to make desired actions the easiest option.
• "Master the Habit of Showing Up": Don't focus on perfecting a habit from the start; instead, "do the easy thing on a more consistent basis". "A habit must be established before it can be improved".
• The Two-Minute Rule: "When you start a new habit, it should take less than two minutes to do". This minimizes the initial barrier to action, ensuring you "master the habit of showing up".
• Commitment Devices: Make choices in the present that control your future actions, binding you to good habits and restricting bad ones (e.g., Victor Hugo locking away his clothes to write, Nir Eyal's internet router timer). These devices "enable you to take advantage of good intentions before you can fall victim to temptation".

4. Make it Satisfying (4th Law):​

• Immediate Gratification: The brain prioritizes immediate pleasure. Behaviors followed by "feelings of pleasure" are signals to the brain to "Do this again, next time".
• The Cardinal Rule of Behavior Change: "What is rewarded is repeated. What is punished is avoided".
• Instant vs. Delayed Rewards: Many good habits have delayed rewards, while bad habits often provide instant gratification. This is known as "time inconsistency" or "hyperbolic discounting". "The more immediate pleasure you get from an action, the more strongly you should question whether it aligns with your long-term goals".
• Habit Tracking: A simple way to make the progress of good habits visible and satisfying. Tools like the "Paper Clip Strategy" or crossing off a calendar day provide immediate visual proof of progress, creating a "habit streak" that motivates continued action.
• Never Miss Twice: The critical rule for maintaining streaks: "If I miss one day, I try to get back into it as quickly as possible. Missing once is an accident. Missing twice is the start of a new habit".
• Habit Contracts: Formal agreements with accountability partners that outline a commitment to a habit and specify punishments for non-adherence, leveraging the desire for social approval and avoiding negative consequences.

V. Additional Insights​

• Genetic Predisposition: Genes influence nearly "every behavior". While they don't dictate destiny, they "predispose you to a unique cluster of genetic traits" that can make certain habits naturally easier or harder. The goal is to "identify the opportunities and habits that are right for you" based on your personality.
• The Plateau of Latent Potential: There's often a period of unnoticeable progress before breakthroughs occur. Patience is crucial to overcome this "Valley of Disappointment".

• The Role of Emotion and Desire: "Desire is the difference between where you are now and where you want to be in the future". Conversely, "Happiness is simply the absence of desire... It arrives when you have no urge to feel differently". This suggests that observing actions without craving a change in state leads to contentment.
• Brain Plasticity: Repetition of habits leads to "clear physical changes in the brain," akin to muscles adapting to training. "Neurons that fire together wire together".

Highlights​

• ➕ Small Habits Compound
  A 1% improvement every day leads to 37x improvement in a year. Bad habits compound negatively in the same way.

• 🛠️ Systems vs. Goals
  Don’t just set goals—build systems that get you there. Winners and losers often have the same goals. Systems make the difference.

• 🧩 Identity-Based Habits
  Focus on who you want to become, not just what you want to achieve. “The goal is not to read a book, but to become a reader.” Every action is a vote for the kind of person you want to be.

• 🔁 Cue → Craving → Response → Reward
  This habit loop explains how behaviors are formed and maintained.

• ⚖️ Good vs. Bad Habit Loop
  Good habits: usually feel bad now but benefit long-term. Bad habits: feel good now but harm long-term. Key insight: align short-term satisfaction with long-term benefits.

• 🎯 Motivation ≠ Discipline
  It’s not about willpower. It's about environment and design. People with strong self-control are better at avoiding temptation, not resisting it.

• 📈 Mastery through Deliberate Practice
  Combine automaticity (via habits) with intentional improvement. Use reflection and review to maintain self-awareness and avoid complacency.

Opinion​

In essence, "Atomic Habits" provides a systematic framework for understanding and manipulating the forces that drive human behavior, enabling individuals to cultivate habits that align with their long-term aspirations by making them obvious, attractive, easy, and satisfying.

I really liked this book, read it multiple times.

Conclusion​

• Success = Systems + Tiny Improvements ✅
• I would recommend it to everyone 👍

This post explains the different types of content projection, where to use each of them, with an example project. All the code can be found on github.(LINK)

Types of Content projection:

Single-slot Content Projection​

In this type, only one slot is avaiable for a component to be inserted in the container component.

For example, let's assume that you have a footer component, which has to include some sort of content (child) component. There are many scenarios where using content projection here right from the start:

• The content component is not yet defined. It could be a button, a text label, a select, a link, an icon or an image.
• You work in a team, where you split the job, and you implement the footer component, meanwhile another developer will implement the content component.
• The content component is defined, and you work on the footer alone, but you want to make sure that these two components are not tightly coupled, so it is possible to switch either one of them without the need to re-implement or modify any of them.

The footer component is given a slot where a content component can be inserted using ng-content:

import { Component } from '@angular/core';

@Component({
  selector: 'app-footer',
  template: `
  <div class="footer">
    <ng-content></ng-content>   // content slot
  </div>
`
})
export class FooterComponent {}

The content component can be any thing, and for the sake of keeping the focus on the content projectoin theme here, let's assume that it is just an "about" button:

import { Component } from '@angular/core';

@Component({
  selector: 'app-button',
  template: `
    <button>about</button>
  `
})
export class ButtonComponent {}

The footer component can be used now inside the app component, and the button component can be inserted/projected in place:

import { Component } from '@angular/core';

@Component({
  selector: 'app-root',
  template: `
    <app-footer>
      <app-button></app-button>
    </app-footer>
  `
})
export class AppComponent {}

That's it.

If the requirements changes, and the footer is needed to have a link text instead of the button, all what needs to be done is to implement the new content component, then project it in place in the footer component instead of the button component.

Multi-slot content projection:​

This type of projection allows the insertion of multiple content components in the container component. That means that there are more than one ng-content slot.

Let's continue with the previous footer example, and assume that the requirements changed again, and the footer is required to have both a button on the left and a text link on the right at the same time. Footer component, a button coponent and a link text component are already there.

In order to project multiple contents, the footer component needs to be updated, and let it accept two slots in this case, and each slot takes a selelct attribute which determine which content to be rendered in which slot:

import { Component } from '@angular/core';

@Component({
  selector: 'app-footer',
  style: `
    .footer {
      display: flex;
      justify-content: space-between;
    }
  `,
  template: `
  <div class="footer">
    <ng-content select=[left]></ng-content>
    <ng-content select=[right]></ng-content>
  </div>
`
})
export class FooterComponent {}

These attributes (left, right) define which content where to render, so to meet the requirement, the button should be given the left attribute, and the link component should be given the right attribute.

import { Component } from '@angular/core';

@Component({
  selector: 'app-button',
  template: `
    <button>about</button>
  `
})
export class ButtonComponent {}

@Component({
  selector: 'app-link',
  template: `
    <a href="#">about</a>
  `
})
export class LinkComponent {}

@Component({
  selector: 'app-root',
  template: `
    <app-footer>
      <app-button left></app-button>
      <app-link right></app-link>
    </app-footer>
  `
})
export class AppComponent {}

This implementation gives a huge felxibility and decoupling of components. For example it is very easy to switch the content components places, or even replace any of the content components without the need to re-implement the whole structure.

Conditional content projection:​

In this type of projection, a condition coverns which content to be rendered in the container component slot. This condition can be made using an ngIf statement.

In order to use conditional content projection, ng-container and ng-template must be used.

By using ng-content, angular will always initialize the content component even if it was inside an ngIf statement.

By using ng-container or ng-template, angular will only render the content component only if it is explicitly asked to render.

Let's go again to the footer compoennt example, and modify the requirement this time so that only one content must be show at a time, depending on some condition.

To apply these requirements, the change needs to happens

@HostListener('window:resize', ['$event'])
onResize(event) {
  this.innerWidth = window.innerWidth;
}

From the fist look I did not like the repetition, even for a beginner in React, javascript basic array operations should be a familiar topic.

So I refactored that section using the map operation:

I do not think that this is so complecated to be understood for any React beginner, and I would recommend using similar concise code instead of repeating the same function calls or elements over and over again.

What do you think?

I have just came back from PyConDe & PyData-2019, and I would like to share/document my experience there. This is more like a diary than a blog, where I talk about:

• Arriving
• First Day
• Second Day
• Third Day
• Sprint Days

Arriving:​

I drove about five hours on the 8th of October 2019, a day before the event, to get a hotel in the neighborhood of the event venue Kosmos Berlin. It is always good to stay near the conference venue, trust me, it is worth it to pay extra just for this reason alone.

I arrived in the evening, head the shower, then prepared the schedule for talks/tutorials I want to attend to, then went to sleep realy excited for the next day.

First Day​

Doors were supposed to open at 9 am. I walked to the venue (about 5 minutes) to arrive few minute before the openning. They openend on time, and people started comming in. Directly after the main door, there were tables labeled with letters, and one must pick up the enterance padge from there acourding to thier first name letter. I found this nice and well organized. Thumbs up PyConDe!

After the main door, is a hall, with an open coffee bar in the center, and sponsers booth all around. Also +1 for the decoration.

Wifi was available for all, and there were a separate wifi for tutorials, where people could pip install stuff easily.

I attended:

Talks:​

• Keynote: Ethics with coding: Avery interesting talk about decision making systems, and highly recommended to watch for both technical and non-technical people.
• Developers vs Enterprise: Nice overview about what roles are really involved in big projects, how they affect the project goal. If you are already working in a big company/project, this talk would be old news, but if you are not, and want to change jobs to a big company, this is worth watching.
• Running an Open source project: Nice experience overview for a joung maintainer, who started a python library on github, and how she was managing/marketing/developing all at the same time. Recommended if you intend to start something similar. Actually I kinda did similar thigs, except I don't have an idea for a general purpose library.. yet.
• Migrating CPython to github: very interesting to see the challenges of migrating the core development of CPython from whatever they are currently using to github. I would never imagine that there were a core python developer who is not familiar with working with github! I was surprised.

Tutorials:​

• Pandas: little nice intro to pandas, nothing that I don't already know, but it was nice to work in a small group on the same task. I have never done that since college.
• Decorators: also the basics about writing decorators. It was well organized, and the tutor was open to all questions which were really varying from entry to advanced python experience levels. This gives a very nice example on how one should do a tutorial. Well done!

Second Day​

I noticed that there are many cancelled talks this day. Too bad for people applied and didn't get accepted due to amount of applications. Well they mentioned the reasons behind that the very next morning, and it was mainly due to last minute illness (flu) or hardware breakdown.

I had a very interesting talk with Łukasz Langa, the original author of Black, and he handed me over some black stickers in person.

Also Hynek Schlawack was there, and got to give him my feedback related to attrs.

I attended:

Talks:​

• Keynote: Python 2020+: very interesting points on how the release manager of CPython 3.8 thinks the development direction should be.
• Docker 101: These were two docker introductory talks, If I knew what was in there, I would not have attended. They coverd the very basics of docker.
• Python panel: alwys very interesting to talk to the core developer, and see how things are seen from the other side of the beloved CPython interpreter development cycle. They encourage and inspire people to contribute to the project.
• Static Typing in Python: nothing really new here, but nice to encourage more people to use type hints.
• The GIL: every now and then the GIL limitation problem rises, and this talk was a very nice investication process by the speaker on how they inspected their multi-threded python code and found out the origin of the problem lying in the GIL.

Tutorials:​

• Introduction to parallelism and concurrency: nice, but the tutor made it to the third slide only 15 min before the end of the session.

Third Day​

I attended:

Talks:​

• Keynote: Rethinking open source: very interesting, I might refer to it when arguing about beinging open source into the interprise someday.
• Pytest: a very basic introduction.
• Pytest: a very instructive talk to show how to try and mimic pytest itself, interesting talk!
• What's new in Python 3.8: self explainatory.
• Your name is invalid: talks about the difficulties people face when interacting with forign systems when it comes to unicode, insightful.
• Python vs R: a nice basic comparision, actually I only attended it for the lack of an interesting talk at that time slot.
• Data visualization: nice intro to two visualization libraries in python.

Sprint Days​

At the night before I checked some of the suggested sprint topics, such as scikit-learn and Bokeh, so I cloned the repos and looked at the open issues.

Sprints started at about 10:00.

At first I met Stefan Behnel, the cython maintainer, and after a small talk I was curious to see stuff inside cython, then I remembered the famous saying for cython developers: "We write C so you don't have to". So as I am in noway a C fan, I wanted to look into some other stuff.

So I participated in the Bokeh sprint, and for two days, opened two issues, and submitted one PR which got merged fast. We started during the sprint with adding static-typing for the python part, but I didn't make a real deal, so I didn't submit a PR for that change, and just consider it as a training! I learned a lot talking to Mateusz Paprocki about Bokeh and its infrastructure.

That's how Bokeh sticker made its way to the back of my laptop, in addition to Black!

• Author: David Thomas, Andrew Hunt
• ISBN: 978-0-1359-5705-9
• Official website: https://pragprog.com/book/tpp20/the-pragmatic-programmer-20th-anniversary-edition

Summery:​

This book gives a definition for being a pragmatic programmer, then talks about some of the basic principles to being one. It take a theoretical approach, with examples in the form of stories, to explain a specific problem, and how should one approach it, and solve it.

Highlights:​

What I take with me from it:

• 1-3: Software Entropy:

  Tip 3: Don't live with broken windows

• 1-7: Communicate:

  Tip 13: Build documentation in, don't bolt it on

• 6-36: Blackboards:

  Tip 60: Use blackboards to coordinate workflow

• 7-42: Property-Based Testing:

  Tip 71: Use property-based tests to validate your assumptions

Opinion​

For someone, like me, who already has experience with more than one programming language, prioritise testing, and familiar with the agile development methods, this book looks some kind of repetition or an emphasise for the information one already know.

Conclusion:​

• I recommend it if you don't appreciate testing, or early refactoring, or want to know more about agile development methods, ways to better architect your projects. It is a good read after all.
• Level: Beginner to Intermediate

• Author: David J. Pine
• ISBN: 978-1-138-58389-4 (Paperback)
• ISBN: 978-1-138-58390-0 (Hardback)

Summery:​

This book gives an introduction to python as a language, then dives into some engineering problems and how they can be solved using python:

• Plotting (matplotlib)
• Curve Fitting (linear regression and nonlinear least squares)
• Numerical Routines (SciPy and Numpy)
• Data manipulation (Pandas)
• Animation (matplotlib)
• Intro to Python GUI (PyQt)

Opinion​

I skipped the first few chapters and read only the chapters which introduce numpy, matplotlib, scipy and pandas. I found it nice to read, and had a jupyter notebook open on the side, to try some examples. The examples were clear and easy to understand. I enjoyed reading it.

Conclusion:​

• Level: Intermediate
• I recommend it for students of information engineering, and who finished their degree.

• Author: Jacob Zimmerman
• ISBN (pbk): 978-1-4842-3726-7
• ISBN (electronic): 978-1-4842-3727-4
• URL: https://link.springer.com/book/10.1007%2F978-1-4842-3727-4

Summery:​

This book has two parts:

• First on explaining what descriptors are, data vs non-data ones, and basic implementation of the built in classmethod, staticmethod and property descriptors.

• Second on showing how to implement your custom descriptors.

Highlights:​

Chapter 4: Descriptors in the Standard Library

• The property Class

class property:
    def __init__(self, fget=None, fset=None, fdel=None):
        self.fget = fget
        self.fset = fset
        self.fdel = fdel
    def __get__(self, instance, owner):
        if instance is None:
            return self
        elif self.fget is None:
            raise AttributeError("unreadable attribute")
        else:
            return self.fget(instance)
    def __set__(self, instance, value):
        if self.fset is None:
            raise AttributeError("can't set attribute")
        else:
            self.fset(instance, value)
    def __delete__(self, instance):
        if self.fdel is None:
            raise AttributeError("can't delete attribute")
        else:
            self.fdel(instance)
    def getter(self, fget):
        return type(self)(fget, self.fset, self.fdel)
    def setter(self, fset):
        return type(self)(self.fget, fset, self.fdel)
    def deleter(self, fdel):
        return type(self)(self.fget, self.fset, fdel)

• The classmethod descriptor

class classmethod:
    def __init__(self, func):
        self.func = func
    def __get__(self, instance, owner):
        return functools.partial(self.func, owner)

• The staticmethod descriptor

class staticmethod:
    def __init__(self, func):
        self.func = func
    def __get__(self, instance, owner):
        return self.func

Opinion​

I enjoyed reading this book, especially the first part, it shows a view port of a developer who is not involved in the core development of python itself. He sometimes also says, ask a core developer if you wanna get the exact reasoning behind it 😄

You don't need an editor open deside you while reading, so I pretty much read it on the bus.

Conclusion:​

• Level: Advanced
• I recommend this book for python developer who like to know what is going under the hood, twinkle with the interiors functionality of python, and curious how every thing works.

• Author: Dan Bader
• ISBN: 9781775093305 (paperback)
• ISBN: 9781775093312 (electronic)

Summery:​

This book gives some basic tips for python beginners, so like a flower from each field. Actually not each field, but the very basic very well known fields: assert, dunders, args & kwargs, data structures, loops.

Highlights:​

7.4 The Craziest Dict Expression in the West

    >>> {True: 'yes', 1: 'no', 1.0: 'maybe'}
    {True: 'maybe'}

Opinion​

I found myself just flipping through pages rather than reading the book, all seemed very basic and shallow. Don't get me wrong, it is well organizsed and formatted, but targeted for people who just started doing python, maybe followed the first tutorial, or had their first week playing with the language.

Conclusion:​

• Level: Entry
• I would never recommend it for anyone who had even one month doing python.

I use gitlab, and I have many repos that I need to track on daily basis, or even more than once per day. I found it so tyring first of all to clone all those repos when I change my working machine, and then to keep all these repos up to date. For that reason I began to write an automation script to do the boring tasks of my shoulders.

Process​

I started with a simple bash script, which go through a for-loop and do the stuff, where the paths of the repos must be hard-coded.

This was fast and worked for a while, but when I got to work with multiple projects, and my co-workers added/removed/renamed a repo, it was sill manual work to update the script, and as boring as I am, I did not like it, and looked for a lazy way to automate the process, and opened the Gitlab API-Documentation, where the fun started.

Solution Idea​

A python script to talk to the gitlab API, and use the /projects end point to access the repos.

Requirements:​

• Gtilab Token: create a private token first to use it accessing the API as explained in the docs.
• Virtual access to the repos (e.g.: gitlab.com)

Optional:​

• Pipenv to install the dev-dependencies:

brew install pipenv

First Try: argparse​

The first try was to pass the options as arguments to the script:

Usage:​

usage: main.py [-h] [--token TOKEN] [--url URL]

optional arguments:
  -h, --help            show this help message and exit
  --token TOKEN, -t TOKEN
                        Gitlab private Token
  --url URL, -u URL     Gitlab URL<Paste>

Second Try: JSON​

Then I thought that the configurations must be more flexible, so the use of a separate config file make sense.

Full project repository can be found here

Usage​

python main.py

From Wikipedia:

In computing, reactive programming is a declarative programming paradigm concerned with data streams and the propagation of change. With this paradigm it is possible to express static (e.g., arrays) or dynamic (e.g., event emitters) data streams with ease, and also communicate that an inferred dependency within the associated execution model exists, which facilitates the automatic propagation of the changed data flow.

From Angular Docs:

Reactive programming is an asynchronous programming paradigm concerned with data streams and the propagation of change. RxJS (Reactive Extensions for JavaScript) is a library for reactive programming using observables that makes it easier to compose asynchronous or callback-based code.

I will take first the basic building blocks then the most commonly used operators.

Building Blocks​

Observable & Observer & Subscriber​

The concept of observers and observables are connected to each other, for there is no functioning observable without an observer.

Let's check the docs first:

Observer is (from Docs):

An interface for a consumer of push-based notifications delivered by an Observable.

Subscriber is (from Docs):

Implements the Observer interface and extends the Subscription class. While the Observer is the public API for consuming the values of an Observable, all Observers get converted to a Subscriber, in order to provide Subscription-like capabilities such as unsubscribe.

Observable is (from Docs):

A representation of any set of values over any amount of time. This is the most basic building block of RxJS.

So the subscriber is an observer, and all observers gets converted to subscribers to support the subscribe/unsubscribe functionality.

From Scratch​

The source code of an Observer look like this:

It implements three methods:

• next: a callback to receive notifications of type next
• error: a callback to receive notifications of type error
• complete: a callback to receive notifications of type complete

The observable can just push notifications to the observer on every occasion it desires, i.e one could implement a function that does that:

So if we call our customObservable with an observer as a parameter:

The output will look like:

This is a basic form of observable, but if it was that simple, why to need a whole framework around it? The answer is simple, try to call next after complete:

The output will look like:

This does not really work the way wanted.

(Try on StackBlitz)

Let's take a more complex example, where the observable wraps a stream of numbers over interval:

The output will appear one value every second, like:

(Try on StackBlitz)

So an observable is basically a wrapper over stream or set of values, it presents it in the way required. A stream is a sequence of ongoing events ordered in time.

The relation between an observer and an observable is shown in the following animation:

The observable can emit either a value, an error or a complete notification signal, which indicate that the stream is over. The observer captures these emitted events by defining functions to react on each event. The way an observer listens with it to an observable is called "Subscription"

So by defining an observer, the stream is defined, and by subscribing to it, actions for the emitted events are defined. So logically, for every observable, a subscription is needed to create actions, and that will be clear in the examples following.

As long as you have more than one set or stream of values, you can imagine how many operations one might need to apply on them. RxJS provide many ways to create an observable with all the safety and asynchronous features that one would desire.

Create Observable using RxJS Static Methods​

- of:​

By wrapping a sequence of values with of returns an observable with those values where it emits the values in the sequence as given, then completes.

Go to Top (Try on StackBlitz)

- range:​

This reminds me with python's range function, it emits a sequence of numbers determined with the range parameters (start, count).

Go to Top (Try on StackBlitz)

- interval:​

This takes a parameter as time in milliseconds and generates a sequence of numbers every time interval. That way one gets infinite time series of numbers.

Go to Top (Try on StackBlitz)

- timer:​

This takes two parameters (initialDelay, period). The initial delay could be a numbers representing time in milliseconds, or a date object. The observable waits for the initial delay value, then it starts emitting numbers starting with 0 every period of time.

Go to Top (Try on StackBlitz)

- from:​

This is a magical method, which converts so many data types into observables: Array, Array-like, Promise, iterable object, string (as an array of chars).

Go to Top (Try on StackBlitz) >> take operator is used here to show the first 5 values of the infinite stream, it will be discussed later in detail

- fromEvent:​

This method is useful wile working with the DOM, for it creates observable from DOM events or Node.js EventEmitter events. It takes two parameters (element: EventTarget, eventName: string)

Go to Top (Try on StackBlitz)

- create:​

This creates a custom observable which will execute the specified function when an observer subscribes to it, it also can return a function which will be executed when the observer unsubscribes. This is the most flexible way of creating an observable.

In the following example a counter is set to count once every second, and this counter is an observable which return the function which will be executed when the observer unsubscribes.

Go to Top (Try on StackBlitz)

Conclusion​

By now, the most common ways of creating an observable in RxJS should be clear, and I can move to the next step in the building blocks of RxJS, which are the most used operators on observables.

Until next blog post!

More References to Observables:

• ReactiveX Docs
• ReactiveX API

How to create custom selenium webdriver classes dynamically with a parametrized browser binary path?

The motivation:​

Working on website functional testing using selenium webdriver, generates the urge to run tests using different versions of the most commonly used browsers these days, in parallel on the same machine.

Tests can use parametrized where the parameter can be the driver class itself, and here comes the need to generate drivers classes dynamically and pass them as parameters to the tests.

The idea:​

In order to be able to use more than one version of a browser, first of all one needs to install these versions locally, then create a custom webdriver class generator with a custom binary path and use these generated classes in the tests wihtout being initialized.

The procedure:​

I am going to explain the steps I followed regarding the most pobular browsers these days: Mozilla Firefox and Google Chrome.

• Download Firefox versions you want to use in testing from Mozilla releases archive.

• For Chrome it might take some effort, by the instructions are clear on the Chromium project site, I am going to list them here just in case they got missing:

  • Look in googlechromereleases.blogspot.com for the last time the wanted version was mentioned.
  • Loop up that version history (e.g.: "44.0.2403.157") in the Position Lookup
  • In this case it returns a base position of "330231". This is the commit of where the 44 release was branched, back in May 2015.*
  • Open the continuous builds archive
  • Click through on your platform (Linux/Mac/Win)
  • Paste "330231" into the filter field at the top and wait for all the results to XHR in.
  • Eventually I get a perfect hit: commondatastorage.googleapis.com/chromium-browser-snapshots
  • Sometimes you may have to decrement the commit number until you find one.
  • Download and run!

• Now you have all your versions ready and able to run, there are many options where you can save them where they can be accessable system wide. One option would be to save them in an environment variables.

• Write a custom webdriver class generator, where the binary path is a parameter and can be dynamically changed in selenium tests. But the first problem I faced here was to be able to change the __init__ method for our custom class and pass the custom binary path to it. I found out that it can be done by deriving from the class type:

binary = FirefoxBinary(bin_path)
def __init__(self, firefox_binary=binary):
    webdriver.Firefox.__init__(self, firefox_binary=firefox_binary)

Firefox = type('Firefox', (webdriver.Firefox, ), {'__init__': __init__})

• For google chrome, changing the binary path is done a little bit differently:

chrome_options = Options()
chrome_options.binary_location = bin_path

def __init__(self, chrome_options=chrome_options):
    webdriver.Chrome.__init__(self, chrome_options=chrome_options)

Chrome = type('Chrome', (webdriver.Chrome, ), {'__init__': __init__})

• It would be more practical to put these functionality into decorators. For this purpose I wrote two decorators one to generate Firefox webdriver objects:

class CustomFirefox:

    def __init__(self, bin_path):
        self.bin_path = bin_path

    def __call__(self, cls):
        binary = FirefoxBinary(self.bin_path)

        def __init__(self, firefox_binary=binary):
            webdriver.Firefox.__init__(self, firefox_binary=firefox_binary)

        Firefox = type('Firefox', (webdriver.Firefox, ), {'__init__': __init__})
        return Firefox

and the other for Chrome webdriver objects:

class CustomChrome:

    def __init__(self, bin_path):
        self.bin_path = bin_path

    def __call__(self, cls):
        chrome_options = Options()
        chrome_options.binary_location = self.bin_path

        def __init__(self, chrome_options=chrome_options):
            webdriver.Chrome.__init__(self, chrome_options=chrome_options)

        Chrome = type('Chrome', (webdriver.Chrome, ), {'__init__': __init__})
        return Chrome

• Now all what one needs to do is to cast the appropriate decorator onto a class, pass the path to the custom binary. For example:

@CustomFirefox('<path_to_firefox_binary>')
class Driver: pass
    print(Driver)

The output would look like:

<class '__main__.Firefox'>

To open the browser, just call the newly created webdriver object:

Driver()

• This works fine, except that the original meta-data from webdriver class are gone, so in order to keep the meta-data from the parent class webdriver.Firefox or webdriver.Chrom we need to save that data first before changeing the __init__ method, and then restore them afterwards, for example for Firefox decorator:

meta_data = dict(webdriver.Firefox.__dict__)
meta_data['__init__'] = __init__
Firefox = type('Firefox', (webdriver.Firefox, ), meta_data)

Now whe we check the returned class, we get:

<class 'selenium.webdriver.firefox.webdriver.WebDriver'>
``¨

- A little tweek might be helpful to include the default case where no path is passed as a parameter, so that the decorator generate the default webdriver with the default browser version installed on the system.

- Now it is possible to create a drivers factory to generate custom webdrivers from a list of binary paths, where the parameters to that factory are the decorator and the list of binary paths:

```python
def driver_factory(decorator, bin_paths):
    drivers = []
    for bin_path in bin_paths:
        @decorator(bin_path)
        class CustomDriver: pass
        drivers.append(CustomDriver)
return drivers

• Voala! The webdriver is ready to be used in tests!

• The complete script would look like:

It might be possible to do the same functionality using a meta class. I will look into that later. If you have any comments or suggestions please share it with me.

> ls -lZ /home/
drwxr-x---. 83 username username system_u:object_r:unlabeled_t:s0   4096 Jun 22 14:55 username
drwx------.  2 root     root     system_u:object_r:lost_found_t:s0  16384 Sep 30 2015 lost+found
drwx------.  5 root     root     system_u:object_r:unlabeled_t:s0   4096 Jan 13 11:48 testuser

And the issue prevents the user username from logging in to its home directory, instead it directs the user to the root directory with an error message regarding permission issues.

I searched for the solution and found it here in this helpful answer.

The command to re-label the directory is:

sudo restorecon -R /home

After that everythig went ok and logging is back to normal:

> ls -lZ /home/
drwxr-x---. 83 username username system_u:object_r:user_home_dir_t:s0  4096 Jun 22 14:55 username
drwx------.  2 root     root     system_u:object_r:lost_found_t:s0     16384 Sep 30 2015 lost+found
drwx------.  5 root     root     system_u:object_r:user_home_dir_t:s0  4096 Jan 13 11:48 testuser

In this post, I show the steps to do that on fedora, as it is my current distro. I had to collect the steps from many resources including vimdoc, vim-wiki and many stackoverflow answers and blogs. So I wanted to blog these steps to come back to them anytime I need to build vim from source with:

• Python3 support.
• Ruby support.
• Lua support.
• Perl support.

In case python-2.7 is needed instead of python3, just replace them in the config lines:

	--enable-pythoninterp                               \
	--with-python-config-dir=/usr/lib/python2.7/config  \

I collected all the steps needed in one bash script, and here I am going to go into the details of the process that I followed.

Choosing CAN Card/Driver​

As lwa4p robot arm uses CAN-bus communication protocol, a CAN card is needed to connect to the arm. In another project, Bryant Pong used Peak pcan card from Peak which is not available to me, and according to sockercan interface wiki-page I could also use the esd CAN cards with the Kernel driver, and that is what I used.

Choosing Software Version​

First off, is to choose the operating system that I was going to work on. The other project uses ros-hydro, which supports only Precise, Quantal, and Raring for debian packages as stated in the wiki-page. So the first idea was to do similar to the mentioned project. Of course dealing with old software draws a lot of troubles, such as the need to install some packages from source as they are not supported in the main software repositories, and one would have to deal with dependencies.

Long story short, it did not work. So I contacted one of the authors of ipa320/ipa_canopen, Mr. Mathias Luedtke @ipa-mdl, who kindly gave me some useful guidelines.

It was suggested to use ros-industrial/ros_canopen for it supports ros-indigo on Ubuntu-14.04. So I ended up with:

• Ubuntu-14.04-64bit
• ROS-Indigo (the most recent update)
• Socketcan (ESD CAN card (PLX90xx), sja1000 kernel driver)
• Bash shell.

Installing ROS Packages​

To install ROS, I followed the instructions for the installation mentioned in the wiki-page.

• As an administrator or a sudo user, add ROS repositories to the sourcelist and import the appropriate key:

sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list'
sudo apt-key adv --keyserver hkp://ha.pool.sks-keyservers.net --recv-key 0xB01FA116

• Update the cache for packages on the system:

sudo apt-get update

• Install ROS desktop:

sudo apt-get install -y ros-indigo-desktop

• Install other complementary packages:

sudo apt-get install -y git ros-indigo-libntcan ros-indigo-libpcan       \
        ros-indigo-controller-manager ros-indigo-controller-manager-msgs \
        ros-indigo-joint-limits-interface ros-indigo-cob-srvs            \
        ros-indigo-cob-control-mode-adapter ros-indigo-cob-dashboard     \
        ros-indigo-cob-command-gui libmuparser-dev python-rosinstall     \
        python-wstool

rosdep Initialization​

rosdep enables you to easily install system dependencies for source you want to compile and is required to run some core components in ROS.

To initialize it:

sudo rosdep init
rosdep update

Note that the second command should be run as a normal user.

Environment Setup​

In order to run any ROS command, ROS environment variables should be available, and this can be done by sourcing specific files:

echo "source /opt/ros/indigo/setup.bash" >> ~/.bashrc
source ~/.bashrc

Be careful to have that setup file sourced on every terminal you use for ROS, and if you are using screen or tmux, make sure that in every pane you open, every setup file is sourced, else you might get un-expected errors.

Catkin Workspace​

• Create a directory for catkin workspace. Usually I just call it catkin_ws and place it in my home directory:

mkdir -p $HOME/catkin_ws/src
cd $HOME/catkin_ws/src
catkin_init_workspace

• Clone the needed packages from github source:

git clone https://github.com/ammarnajjar/ros_canopen.git -b no-lost-arbitration-handling
git clone https://github.com/ipa320/schunk_robots.git -b indigo_dev
cd ..

Notice that I forked the original ros-industrial/ros_canopen and applied a patch to it, as I kept getting an error:internal_error: 2 (lost arbitration;) when I try to initialize the robot arm. If you are curious, have a look at the complete logs for the mentioned error.
The patch is displayed here to show where I commented out handling that error. Do this only if you have to and as a last resort.

• Install the dependencies for those packages using:

rosdep install --from-paths src --ignore-src --rosdistro indigo -y

• Build catkin workspace:

catkin_make
echo "source $HOME/catkin_ws/devel/setup.bash" >> $HOME/.bashrc
source $HOME/catkin_ws/devel/setup.bash

CAN Interface​

Setting up the CAN interface correctly came after some research in ros/socket_interface and with some instructions mentioned in ipa320/schunk_robots opened Bug #59.

I connect the robot arm to can0 so the steps can be summarized in the following:

• Set the bitrate to 500k. This has to be done while the interface is down, so first turn it down, set the bitrate value, then turn it up again:

sudo ip link set dev can0 down
sudo ip link set can0 type can bitrate 500000
sudo ip link set dev can0 up

• Set the txqueue length to be between (15-20):

sudo ifconfig can0 txqueuelen 20

Notice that schunk_robots package uses can0 by default, so if you use a different interface such as can1 or can2, make sure to modify the configuration file lwa4p.yml in your schunk_robots package to make it use the matching CAN interface.

Moveit​

To use moveit, I followed the steps mentioned in the docs. I chose the catkin workspace to be in my home directory:

mkdir -p $HOME/moveit/src
cd $HOME/moveit/src
wstool init .
wstool merge https://raw.github.com/ros-planning/moveit_docs/indigo-devel/moveit.rosinstall
wstool update
cd ..
rosdep install --from-paths src --ignore-src --rosdistro indigo -y
catkin_make
echo "source $HOME/moveit/devel/setup.bash" >> $HOME/.bashrc
source $HOME/moveit/devel/setup.bash

At the time when I was using moveit, I faced some compilation errors, but I figured out the problem and made a pull request with a suggested solution, and it was merged in no time to ros-planning/moveit-ros indigo-devel branch, and the issue is solved.

After the installation is complete, I used MoveIt Setup Assistant to generate the moveit configurations. I did it already myself and put it on github, with all its tweaks.

If you don't want to do it yourself, go to your src directory in catkin workspace and clone it:

git clone https://github.com/ammarnajjar/lwa4p_moveit_config.git

Then re-build again to be able to use it.

Initializing the Robot Arm​

To initialize the robot arm, I launch the controller first

roslaunch schunk_lwa4p robot.launch

then call the init service:

rosservice call /arm/driver/init

This should give the following output:

success: True
message: ''

Moving the Robot Arm​

Launch rviz and use it to control the robot arm:

roslaunch lwa4p_movit_config moveit_planning_execution.launch

The following images show the robot arm in two different positions:

home position

random valid position

This might not always be up to date, for I keep changing these configurations when I feel like it.

General Configurations (neovim)​

The very first section is for the general settings which I think that they should be set up in vim by default, as some of them already are default in neovim, which include:

• Use incremental search: this feature enables vim from highlighting the search pattern while it is being typed.

set incsearch

• Use fast terminal connection, this feature improves smoothness of redrawing when there are multiple windows.

set ttyfast

• When a file has been detected to have been changed outside of vim and it has not been changed inside of vim, automatically read it again.

set autoread

• Activate the wild menu for command line completion using the TAB key.

set wildmenu
set wildmode=longest:list,full

• Highlight all matches for the search pattern.

set hlsearch

• Vim uses history to remember command line commands that a user enters in either on of these command-lines:
  • : commands
  • search strings
  • expressions
  • input lines, typed for the input() function.
  • debug mode commands I like to make vim remember a lot (1000) of my command history.

set history=1000

• Make vim behave in a more useful way (this literally exactly what is written in vim docs). It is optional to include this in one's vimrc, for when a vimrc or gvimrc file is found while Vim is starting up, this option is enabled.

set nocompatible

• Make backspace erase character as other editors do.

set backspace=2

• When a tab character is inserted using pressing the <TAB> key, backspace is used to delete what was inserted, it depends on other configurations parameters shiftwidth. tabstop and softtabstop.

set smarttab

• When starting a new line, use the same indentation from previous line. This is a very useful feature when one is coding, especially in an indent sensitive language such as python or yaml.

set autoindent

• Live substitution (neovim only), when replacing a pattern.

set inccommand=nosplit

General Configurations (vim)​

Another set of general configurations which are not included in neovim by default. I still find them very useful.

• I don't like to use the mouse while I'm editing, still I like to enable it.

set mouse=a

• Show (partial) command in the last line of the screen. The docs explain this very well so I copied that from there: In Visual mode the size of the selected area is shown:
  • When selecting characters within a line, the number of characters. If the number of bytes is different it is also displayed: "2-6" means two characters and six bytes.
  • When selecting more than one line, the number of lines.
  • When selecting a block, the size in screen characters: {lines}x{columns}.

set showcmd

• Show the matching of a bracket when inserted, this looks like as if the cursor moved to the matching one for a small period of time to highlight it. matchtime is to control that time period.

set showmatch
set matchtime=2

• Use case insensitive when searching for a match.

set ignorecase

• If the search pattern contains upper case characters, override the ignorecase option and use case sensitive search.

set smartcase

• Automatically save before executing commands like :next and :make. I do use make a lot, so this is very efficient.

set autowrite

• Hide buffers when they are abandoned, if they do not show in other windows of course. This is useful when I deal with many buffers at a time, and I don't have to worry about saving before switching.

set hidden

• I find modeline very useful, when I get other's code, or when I want to give others my code, I set specific settings inside the modeline to be set automatically for any other user who usees vim, the most important ones are tabstop and expandtab.

setglobal modeline
set modelines=3

• I like to have a minimal number of screen lines to keep above and below the cursor.

set scrolloff=3

• Show the mode that I am using as a message on the last line, weather it is insert, visual or replace mode.

set showmode

• Wrap text and show long lines on multiple lines without inserting line breaks.

set wrap
set linebreak

• Set the title of the window to the value of 'titlestring', and if empty to: filename [+==] path - vim-server-name.

set title

• Show line number on the left side of the document on the active line, and activate relative numbers on the rest of the lines.

set number
set relativenumber

• set the path to the shell to use 'bash'

set shell=/bin/bash

• Ignore temporary and complied files for c++, Java and Python as well as the configurations folders for the version control systems that I might use.

set wildignore=*.o,*~,*.pyc,*.class
set wildignore+=*/.git/*,*/.hg/*,*/.svn/*

• When joining lines, don't insert two spaces after punctuation.

set nojoinspaces

• Don't redraw while executing macros, this is a good performance configuration.

set lazyredraw

• Turn backup off. Since most stuff are within version control, I feel that these backup and swap files are just annoying so I disable them all.

set nobackup
set nowritebackup
set noswapfile

• Set default 1 tab == 4 spaces

set shiftwidth=4
set tabstop=4
set softtabstop=4
set smartindent

• Create undo file to keep history after closing the file.

set undofile
set undolevels=100
set undodir=~/.vim/undo//

• Remember info about open buffers on close.

set viminfo^=%

• Sometimes I lose track of the line that I am on, so enabling cursorline make it much much easier.

set cursorline

• Enable Omni completion.

set omnifunc=syntaxcomplete#Complete

• Disable the visual bell.

set t_vb=

• Set number of colours to be used to 256, as I like it so.

set t_Co=256

• Clearing uses the current background colour.

set t_ut=

• Set vertical Cursor in insert mode.

set guicursor=n-v-c:block,i-ci-ve:ver25,r-cr:hor20,o:hor50
  \,a:blinkwait700-blinkoff400-blinkon250-Cursor/lCursor
  \,sm:block-blinkwait175-blinkoff150-blinkon175

Plugins Manager​

For plugins, I tried many plugins managers, I used to use vundle, and the set it up in my vimrc should have been looking like:

filetype off
set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()

Plugin 'VundleVim/Vundle.vim'
" add other plugins here

call vundle#end()
filetype plugin indent on
syntax on

Then I switched to another plugin manager called vim-plug which is faster and do asynchronous updating for the plugins. The setup is also simpler, and works fine with both vim/neovim:

call plug#begin(s:editor_root."/plugged/")

" add plugins here
" Plug 'dev-name/repo-name'

call plug#end()

I am not going to discuss my favorite plugins and their configurations here, as it differs from time to time, and depends on the use of vim and the working environment. I also moved all the plugins related stuff into another file plugs.vim, so I don't get so distracted with them and their settings.

Mappings​

• Neovim terminal mode mappings, to act on terminal buffer similar to a normal vim buffer.

tnoremap <Esc> <C-\><C-n>
tnoremap <C-h> <C-\><C-n><C-w>h
tnoremap <C-j> <C-\><C-n><C-w>j
tnoremap <C-k> <C-\><C-n><C-w>k
tnoremap <C-l> <C-\><C-n><C-w>l
noremap <leader>s :split term://bash<CR><C-w><S-j><S-a>
noremap <leader>t :tabedit term://bash<CR><S-a>

• Many times I want to stay in visual mode when I do a shifting for a block of code, so I remapped the original keys to do the trick.

vnoremap < <gv
vnoremap > >gv

• Move a line of text up and down using leader + [jk] in both normal and visual mode.

nmap <leader>j mz:m+<cr>'z
nmap <leader>k mz:m-2<cr>'z
vmap <leader>j :m'>+<cr>`<my`>mzgv`yo`z
vmap <leader>k :m'<-2<cr>`>my`<mzgv`yo`z

• Switch between characters next to each other using leader + [hl] for I use it a lot to fix some hastly typos in normal mode.

nmap <leader>l xp
nmap <leader>h xhhp

• Disable highlighted matches from previous search when leader + ENTER is pressed.

map <silent> <leader><CR> :noh<CR>

• I use windows quite often, so this is a smart way to move between windows, using the ctrl with combination of the original vim movement keys [hjkl].

map <C-j> <C-W>j
map <C-k> <C-W>k
map <C-h> <C-W>h
map <C-l> <C-W>l

• Open a new tab with the current buffer's path. Super useful when editing files in the same directory

map <leader>te :tabedit <c-r>=expand("%:p:h")<CR>/

• Switch cwd to the directory of the open buffer. Coupled with the previous mapping, I get a very pleasant behaviour.

map <leader>cd :cd %:p:h<CR>:pwd<CR>

• Open vimrc file in a new tabe mapping.

nmap <leader>ev :tabe $MYVIMRC<CR>

• Toggle spell checking on and off, when I am writing a paper.

map <leader>ss :setlocal spell!<cr>

Status Line​

I have a very nice status line, which I am proud of, and prefer it over status line fancy plugins. It contains some helper functions and plugins status, so if you don't use those plugins, just comment the lines for those, Fugitive and Syntastic.

set statusline=
set statusline=[%n]\                                            " buffer number
set statusline+=%<%.99f                                         " File name, F for full path
set statusline+=%#warningmsg#                                   " display a warning if
set statusline+=%{HasPaste()}                                   " File name, F for full path
set statusline+=%*                                              " tab chars
set statusline+=%m%r%h%w                                        " status flags
set statusline+=%#question#                                     " Display a warning if
set statusline+=%{(&fenc!='utf-8'&&&fenc!='')?'['.&fenc.']':''} " file encoding isnt
set statusline+=%*                                              " utf-8
set statusline+=%#warningmsg#                                   " display a warning if
set statusline+=%{StatuslineTabWarning()}                       " files contains
set statusline+=%*                                              " tab chars
set statusline+=%#question#                                     " Display a warning if
set statusline+=%{fugitive#statusline()}                        " Fugitive
set statusline+=%*                                              " tab chars
set statusline+=%=                                              " right align remainder
set statusline+=%{SyntasticStatuslineFlag()}                    " Syntastic
set statusline+=%y                                              " buffer file type
set statusline+=%#directory#                                    " display a warning if
set statusline+=%{&ff!='unix'?'['.&ff.']':''}                   " fileformat isnt
set statusline+=%*                                              " unix
set statusline+=%c%V,%l/                                        " column and row Number
set statusline+=%L\ %P                                          " total lines, position in file
set laststatus=2

I like to change the color of the statusline to blue when I go insert mode, and this is done by the following lines:

autocmd InsertEnter * highlight StatusLine term=reverse ctermbg=Blue gui=bold guifg=White guibg=Blue
autocmd InsertLeave * highlight StatusLine term=reverse ctermfg=254 ctermbg=238 gui=bold guifg=White guibg=Black

Useful Functions​

• Delete trailing white space on save, for all filetypes except markdown, for sometimes, I need to leave two spaces at the end of the line to make a soft line break.

func! DeleteTrailingWS()
    " Don't strip on these filetypes
    if &ft =~ 'markdown'
        return
    endif
    exe "normal mz"
    %s/\s\+$//ge
    exe "normal `z"
endfunc
autocmd BufWrite *.* :call DeleteTrailingWS()

• Convenient command to see the difference between the current buffer and the file it was loaded from, thus the changes you made.

if !exists(":Diff")
    command DiffOrig vert new | set bt=nofile | r ++edit # | 0d_ | diffthis
                \ | wincmd p | diffthis
endif

• Return to last edit position when opening files (You want this!)

autocmd BufReadPost *
            \ if line("'\"") > 0 && line("'\"") <= line("$") |
            \   exe "normal! g`\"" |
            \ endif

• Visual mode pressing * or # searches for the current selection.

vnoremap <silent> * :call VisualSelection('f')<CR>
vnoremap <silent> # :call VisualSelection('b')<CR>

function! CmdLine(str)
    exe "menu Foo.Bar :" . a:str
    emenu Foo.Bar
    unmenu Foo
endfunction

function! VisualSelection(direction) range
    let l:saved_reg = @"
    execute "normal! vgvy"

    let l:pattern = escape(@", '\\/.*$^~[]')
    let l:pattern = substitute(l:pattern, "\n$", "", "")

    if a:direction == 'b'
        execute "normal ?" . l:pattern . "^M"
    elseif a:direction == 'gv'
        call CmdLine("vimgrep " . '/'. l:pattern . '/' . ' **/*.')
    elseif a:direction == 'replace'
        call CmdLine("%s" . '/'. l:pattern . '/')
    elseif a:direction == 'f'
        execute "normal /" . l:pattern . "^M"
    endif

    let @/ = l:pattern
    let @" = l:saved_reg
endfunction

• Java compile using javac and run using java applied on the current buffer. Useful for small java programs to run on the fly.

function! CompileAndRunJava()
    :w!
    setlocal makeprg=javac\ %
    setlocal errorformat=%A%f:%l:\ %m,%-Z%p^,%-C%.%#
    :make
    " split source filename by . and pass the first part to java
    :!i=%; echo ${i//.*/}|xargs java
endfunction

• In my status line, I use some functions. One is to get the state of the current buffer, weather it uses tabs or spaces.

function! StatuslineTabWarning()
    if !exists("b:statusline_tab_warning")
        let tabs = search('^\t', 'nw') != 0
        if tabs
            let b:statusline_tab_warning = '[tabs]'
        else
            let b:statusline_tab_warning = ''
        endif
    endif
    return b:statusline_tab_warning
endfunction
autocmd cursorhold,bufwritepost * unlet! b:statusline_tab_warning

• This is to checks if paste mode is enabled, I like to see that in my statusline as well.

function! HasPaste()
    if &paste
        return '[PASTE]'
    else
        return ''
    endif
endfunction

• Don't close window, when deleting a buffer.

command! Bclose call <SID>BufcloseCloseIt()
function! <SID>BufcloseCloseIt()
    let l:currentBufNum = bufnr("%")
    let l:alternateBufNum = bufnr("#")

    if buflisted(l:alternateBufNum)
        buffer #
    else
        bnext
    endif

    if bufnr("%") == l:currentBufNum
        new
    endif

    if buflisted(l:currentBufNum)
        execute("bdelete! ".l:currentBufNum)
    endif
endfunction

• As everyone has his own standards for using either tabs or spaces, this function allow toggling between tabs and spaces, so ease the hussle.

function! TabToggle()
    if &expandtab
        set noexpandtab
        retab!
    else
        set expandtab
        retab
    endif
endfunction

• Show red highlighting on ColumnColor 80.

function! g:ToggleColorColumn()
  if &colorcolumn != ''
    setlocal colorcolumn&
  else
    setlocal colorcolumn=80
  endif
endfunction
nnoremap <silent> <leader>cc :call g:ToggleColorColumn()<CR>

• Many times when I search for a regex, I wanted to copy all the existing matches and paste them somewhere else, that's why I use this function.
  • :CopyMatches to copy all matches to the clipboard.
  • :CopyMatches x where x is any register to hold the result.
  • paste from register x with "xp or "xP.

function! CopyMatches(reg)
    let hits = []
    %s//\=len(add(hits, submatch(0))) ? submatch(0) : ''/ge
    let reg = empty(a:reg) ? '+' : a:reg
    execute 'let @'.reg.' = join(hits, "\n") . "\n"'
endfunction
command! -register CopyMatches call CopyMatches(<q-reg>)

• Append modeline after last line in buffer.

function! AppendModeline()
  let l:modeline = printf(" vim: set ft=%s ts=%d sw=%d %set %sai : ",
        \ &filetype, &tabstop, &shiftwidth, &expandtab ? '' : 'no', &autoindent ? '' : 'no')
  let l:modeline = substitute(&commentstring, "%s", l:modeline, "")
  call append(line("$"), l:modeline)
endfunction
nnoremap <silent> <Leader>ml :call AppendModeline()<CR>

• Realign buffers when iterm goes fullscreen

augroup FixProportionsOnResize
  au!
  au VimResized * exe "normal! \<c-w>="
augroup END

• Highlight all instances of word under cursor, when idle. Useful when studying strange source code. Type z/ to toggle highlighting on/off.

nnoremap z/ :if AutoHighlightToggle()<Bar>set hls<Bar>endif<CR>
function! AutoHighlightToggle()
  let @/ = ''
  if exists('#auto_highlight')
    au! auto_highlight
    augroup! auto_highlight
    setl updatetime=100
    echo 'Highlight current word: off'
    return 0
  else
    augroup auto_highlight
      au!
      au CursorHold * let @/ = '\V\<'.escape(expand('<cword>'), '\').'\>'
    augroup end
    setl updatetime=100
    echo 'Highlight current word: ON'
    return 1
  endif
endfunction

All information for vim commands can be found using the help system in vim by typing :help command or look at the online docs for they are very plain and clear. The complete set of my vimrc is on my github. There I use one repo for all my dotfiles, bash and tmux configutaions.

Feel free to suggest improvements.

I found this blog post by Stephen Nneji discussed how to use DIY cartridge and install python and opencv manually. Another blog post by Nikhil Kumar used the Python-2.7 cartridge template to reduce the size of compiled opencv.

I collected the complete steps and put them in a single bash script.

To run this script in your openshift Python-2.7 cartridge, run the following command:

$ wget https://raw.githubusercontent.com/ammarnajjar/opencv_on_openshift_online/master/install.sh && bash install.sh

Then test importing opencv:

> python
Python 2.7.11 (default, Mar 31 2016, 20:46:51) 
[GCC 5.3.1 20151207 (Red Hat 5.3.1-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import cv2
>>>