Injected all wrotenwrites.com content
This commit is contained in:
Joe Wroten
parent
2786d1a372
commit
7236d9c459
18 changed files with 1509 additions and 103 deletions
145
content/posts/a_modern_terminal_workflow_1.md
Normal file
145
content/posts/a_modern_terminal_workflow_1.md
Normal file
|
|
@ -0,0 +1,145 @@
|
|||
---
|
||||
title: A Modern Terminal Workflow — Part 1 / 5
|
||||
description: Conquer the CLI using the latest tools made by developers for developers.
|
||||
date: 2017-01-19
|
||||
tags:
|
||||
- Tech
|
||||
- Devtools
|
||||
---
|
||||
|
||||
Perhaps you’re a tinkerer, a javascript ninja, or something else entirely it’s essential to have tools that help you do what you do best and look good doing it.
|
||||
|
||||
This is an opinionated walkthrough using tools both new and old that are performant and work well together. Through a combination of Git, NeoVim, Zsh, Tmux and iTerm2 this article will take you step by step in writing a dotfiles repo to set up a MacOS programming environment.
|
||||
|
||||
Optionally, skip ahead and [see the final result](https://github.com/sharpshark28/modern-terminal-workflow).
|
||||
|
||||
## What is a Dotfile?
|
||||
|
||||
A dotfile is simply a file that begins with a `.` before the filename such as `.vimrc`. These are commonly program configurations and are _often times hidden by default on Unix filesystems._
|
||||
|
||||
## What is a Dotfiles repo?
|
||||
|
||||
Git can host dotfiles and setup scripts to set up a new machine with your tools configured exactly the way you want them. An ideal setup script can be run after a fresh clone of the git repo to symlink its configuration dotfiles with the host machine for a portable terminal workflow.
|
||||
|
||||
## Getting Started
|
||||
|
||||
### Updating Xcode
|
||||
|
||||
Before we get started, ensure Xcode is up to date. It’s an easy step to miss and takes some time but is *essential for NeoVim to build*.
|
||||
|
||||
1. Update Xcode to the latest version using the appstore.
|
||||
2. `xcode-select --install` to install xcode’s cli tools.
|
||||
|
||||
### Creating the local Git Repo
|
||||
|
||||
``` bash Terminal
|
||||
mkdir ~/dotfiles # make a new dotfiles directory
|
||||
cd ~/dotfiles # enter the new dotfiles directory
|
||||
git init # ready the directory for git version control
|
||||
touch init.sh zshrc tmux.conf vimrc # creating the config files
|
||||
```
|
||||
|
||||
## The Initialize Script
|
||||
|
||||
Like many Git projects a starting point is required. Through an init shell script a series of commands can be written in a way that can be reproduced on as many machines as desired.
|
||||
|
||||
``` bash Terminal
|
||||
vim init.sh
|
||||
```
|
||||
|
||||
### Bash Script
|
||||
|
||||
A shell script needs an interpreter. We will be installing Zsh later in this script, but MacOS will be running Bash out of the box and thus that is what we will set the interpreter as.
|
||||
|
||||
``` bash init.sh
|
||||
#!/bin/bash
|
||||
```
|
||||
|
||||
### Installing System Dependencies
|
||||
|
||||
Throughout this walkthrough we’ll be installing package managers of varying types. Luckily here we can leverage a MacOS built in tool called Brew which does just this. Brew knows how to find, download, and install CLI applications out of the box and with the addition of an additional tool called Cask it can install GUI applications as well.
|
||||
|
||||
``` bash init.sh
|
||||
brew install zsh tmux neovim/neovim/neovim python3 ag reattach-to-user-namespace
|
||||
brew tap caskroom/cask
|
||||
brew cask install iterm2
|
||||
```
|
||||
|
||||
* **Zsh** is a powerful shell and an alternative to MacOS’s default Bash. This will be covered in more detail in part 3.
|
||||
* **Tmux** is a terminal multiplexer. Using some keyboard hotkeys you can use tabs and split panes for better multitasking.
|
||||
* **NeoVim** is a modern alternative to Vim, a terminal based code editor with efficiency and code reading in mind. This will be covered in more detail in part 2. NeoVim has a strange path due to being in active development at the moment.
|
||||
* **Python** is installed to extend NeoVim’s plugin support.
|
||||
* **Ag** is a code-searching tool similar to Ack but faster. This will be covered more in part 2.
|
||||
* **Reattach-to-user-namespace** is a MacOS Sierra fix to ensure the workflow has access to the clipboard so share copy and paste functionality as one would expect in the correct namespace.
|
||||
* **iTerm2** is a terminal replacement with a great level of customizability and integration with Tmux.
|
||||
|
||||
### Upgrading NeoVim to Have Plugin and Python Support
|
||||
|
||||
To make NeoVim a powerful enough tool to be a primary code editor some additional functionality is needed.
|
||||
|
||||
[vim-plug](https://github.com/junegunn/vim-plug) is installed as a package manager which will be leveraged in Part 2 to pull down user made plugins like themes, new movements, and ways to navigate the entire project. Some plugins rely on Python to work so a `pip3` command is ran to upgrade NeoVim to support it.
|
||||
|
||||
``` bash init.sh
|
||||
curl -fLo ~/.local/share/nvim/site/autoload/plug.vim --create-dirs \
|
||||
https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim
|
||||
pip3 install neovim
|
||||
```
|
||||
|
||||
## Installing Fonts
|
||||
|
||||
Brew's Cask capability can be extended to allowing the installation of fonts to the filesystem.
|
||||
|
||||
There are many programmer fonts available to choose from, but _Fira Code has stolen my heart_ to the point of it being used on this very blog article. Monospaced fonts are ideal for programming because every character is the same width meaning code naturally aligns vertically. Fira Code is designed with programming ligatures making commonly used operators combine together into a single symbol. => <= `=> =<`
|
||||
|
||||
``` bash init.sh
|
||||
brew tap caskroom/fonts
|
||||
brew cask install font-fira-code
|
||||
```
|
||||
|
||||
## Setting ZSH as Default Shell
|
||||
|
||||
``` bash init.sh
|
||||
chsh -s /usr/local/bin/zsh
|
||||
```
|
||||
|
||||
## Setting Configs
|
||||
|
||||
### Removing Any Existing Configs
|
||||
|
||||
Some cleanup in case these files already exist.
|
||||
|
||||
``` bash init.sh
|
||||
rm -rf ~/.vim ~/.vimrc ~/.zshrc ~/.tmux ~/.tmux.conf ~/.config/nvim 2> /dev/null
|
||||
```
|
||||
|
||||
### Creating Necessary Directories
|
||||
|
||||
NeoVim expects a few directories to exist and so it’s best we add them now.
|
||||
|
||||
``` bash init.sh
|
||||
mkdir -p ~/.config ~/.config/nvim
|
||||
```
|
||||
|
||||
### Linking Configs
|
||||
|
||||
Symlinks can allow the file system point from where configs are expected to be to this repo.
|
||||
|
||||
``` bash init.sh
|
||||
ln -s ~/dotfiles/zshrc ~/.zshrc
|
||||
ln -s ~/dotfiles/tmux.conf ~/.tmux.conf
|
||||
ln -s ~/dotfiles/vimrc ~/.config/nvim/init.vim
|
||||
```
|
||||
|
||||
## Wrapping Up
|
||||
|
||||
1. Run your newly written init.sh with `bash init.sh` and then log out.
|
||||
2. Upon logging back in, launch iTerm2.
|
||||
|
||||
We’re now running in Zsh and instead of vim we can use `nvim`.
|
||||
|
||||
> Optionally `vim` can launch `nvim` if you add `alias vim="nvim"` to your init.sh
|
||||
|
||||
# What’s Next
|
||||
|
||||
[Part 2 covers configuring NeoVim](/a-modern-terminal-workflow-part-2-5)
|
||||
|
||||
297
content/posts/a_modern_terminal_workflow_2.md
Normal file
297
content/posts/a_modern_terminal_workflow_2.md
Normal file
|
|
@ -0,0 +1,297 @@
|
|||
---
|
||||
title: A Modern Terminal Workflow — Part 2 / 5
|
||||
description: Configuring Neovim
|
||||
date: 2017-01-24
|
||||
tags:
|
||||
- Tech
|
||||
- Devtools
|
||||
---
|
||||
|
||||
[Vim is about precision editing at the speed of thought](https://vimeo.com/53144573). Vim is also about quickly navigating a project to find and read old code.
|
||||
|
||||
> Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.
|
||||
> ― _Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship_
|
||||
|
||||
NeoVim is a modern drop-in replacement for Vim. In fact it is easy to share a Vim config with NeoVim via a symlink, but there are some caveats which are outside the scope of this article.
|
||||
|
||||
# Core Config
|
||||
|
||||
##### Note: Syntax highlighting and color may not work as expected within Tmux until it is configured in Part 4 correctly.
|
||||
|
||||
There’s a certain magic to writing your editor config with that very same editor. I suggest handwriting these configs so you can learn as you type.
|
||||
|
||||
`nvim vimrc`
|
||||
|
||||
## Setting Sensible Defaults
|
||||
|
||||
``` vim vimrc
|
||||
" Set standard file encoding
|
||||
set encoding=utf8
|
||||
" No special per file vim override configs
|
||||
set nomodeline
|
||||
" Stop word wrapping
|
||||
set nowrap
|
||||
" Except... on Markdown. That's good stuff.
|
||||
autocmd FileType markdown setlocal wrap
|
||||
" Adjust system undo levels
|
||||
set undolevels=100
|
||||
" Use system clipboard
|
||||
set clipboard=unnamed
|
||||
" Set tab width and convert tabs to spaces
|
||||
set tabstop=2
|
||||
set softtabstop=2
|
||||
set shiftwidth=2
|
||||
set expandtab
|
||||
" Don't let Vim hide characters or make loud dings
|
||||
set conceallevel=1
|
||||
set noerrorbells
|
||||
" Number gutter
|
||||
set number
|
||||
" Use search highlighting
|
||||
set hlsearch
|
||||
" Space above/beside cursor from screen edges
|
||||
set scrolloff=1
|
||||
set sidescrolloff=5
|
||||
```
|
||||
|
||||
## Opinionated Defaults
|
||||
|
||||
### Remapping `<Leader>` to `<Space>`
|
||||
|
||||
``` vim vimrc
|
||||
let mapleader="\<SPACE>"
|
||||
```
|
||||
|
||||
The `<Leader>` key is what is pressed before another key to activate some command via a shortcut. By default Vim uses the rather awkward key `\`. Many respected Vim users choose `<Space>` as their leader key instead and I agree with this change.
|
||||
|
||||
### Disable mouse support
|
||||
|
||||
``` vim vimrc
|
||||
set mouse=r
|
||||
let $NVIM_TUI_ENABLE_CURSOR_SHAPE=1
|
||||
```
|
||||
|
||||
These dotfiles are going to rock this world so hard we don't need mice where we're going. Keep those hands on the keyboard and power on.
|
||||
|
||||
### Setting Arrow Keys to Resize Panes
|
||||
|
||||
``` vim vimrc
|
||||
nnoremap <Left> :vertical resize -1<CR>
|
||||
nnoremap <Right> :vertical resize +1<CR>
|
||||
nnoremap <Up> :resize -1<CR>
|
||||
nnoremap <Down> :resize +1<CR>
|
||||
" Disable arrow keys completely in Insert Mode
|
||||
imap <up> <nop>
|
||||
imap <down> <nop>
|
||||
imap <left> <nop>
|
||||
imap <right> <nop>
|
||||
```
|
||||
|
||||
_This was the config best decision I ever made._ **Relying on arrow keys results in less efficient code editing.** Should you find this frustrating, turn those frustrations into learning experiences to find the quickest way to have the cursor reach the target.
|
||||
|
||||
## Dealing with Buffers / Tabs
|
||||
|
||||
### Return to the last file opened
|
||||
|
||||
``` vim vimrc
|
||||
nmap <Leader><Leader> <c-^>
|
||||
```
|
||||
|
||||
* `Space Space` to open previously opened file buffer
|
||||
|
||||
## Next / Previous Buffer (Tab)
|
||||
|
||||
``` vim vimrc
|
||||
nnoremap <Tab> :bnext!<CR>
|
||||
nnoremap <S-Tab> :bprev!<CR><Paste>
|
||||
```
|
||||
|
||||
* `Tab` to switch to next buffer
|
||||
* `Shift Tab` to switch to previous buffer
|
||||
|
||||
This keybinding becomes more intuitive after installing the plugin suggested below to convert buffers to onscreen tabs with vim-airline.
|
||||
|
||||
# Plugins to Enhance Functionality
|
||||
|
||||
## Plugin Manager
|
||||
|
||||
Stock, even heavily configured, Vim is lacking features offered by other GUI applications. While the objective is not to convert Vim into something it isn't it is essential to implement some missing functionality through plugins.
|
||||
|
||||
There are several plugin managers out there but vim-plug is the most minimal while being fast in uptime and concurrent plugin installation.
|
||||
|
||||
``` vim vimrc
|
||||
call plug#begin('~/.local/share/nvim/plugged')
|
||||
# PLUGINS GO HERE!!!
|
||||
call plug#end()
|
||||
```
|
||||
|
||||
### To Install Plugins
|
||||
|
||||
Between `call plug#begin` and `call plug#end` insert the keyword `Plug` followed by the path to the plugin in Github such as `Plug 'username/project`. See further examples in the suggested plugins below.
|
||||
|
||||
After adding a `Plug` and saving the vimrc file run the install command by hitting colon followed by `PlugInstall`.
|
||||
|
||||
``` vim
|
||||
:PlugInstall
|
||||
```
|
||||
|
||||
## Unite
|
||||
|
||||
As stated earlier, Vim is not a GUI. Unite is a commonly used resource for plugins to open panels and other temporary interfaces onscreen. **Unite is required for many plugins to work as expected.**
|
||||
|
||||
``` vim vimrc plugin path
|
||||
Plug 'Shougo/unite.vim'
|
||||
```
|
||||
|
||||
## Theme: Dracula
|
||||
|
||||
``` vim vimrc plugin path
|
||||
Plug 'dracula/vim'
|
||||
```
|
||||
|
||||
Dracula is dark yet vibrant, needs no additional configuration, and is supported in a [wide variety of apps](https://draculatheme.com/) for a consistent experience.
|
||||
|
||||
``` vim vimrc plugin settings
|
||||
color Dracula
|
||||
```
|
||||
|
||||
## Indent Guides
|
||||
|
||||
``` vim vimrc plugin path
|
||||
Plug 'Yggdroot/indentLine'
|
||||
```
|
||||
|
||||
Indentation guides provide a subconcious way of understanding how your code fits together horizontally as well as assuring that indentation is correct at a glance.
|
||||
|
||||
``` vim vimrc plugin settings
|
||||
let g:indentLine_enabled = 1
|
||||
let g:indentLine_char = "⟩"
|
||||
```
|
||||
|
||||
## Git Gutter
|
||||
|
||||
``` vim vimrc plugin path
|
||||
Plug 'airblade/vim-gitgutter'
|
||||
```
|
||||
|
||||
As code is added, modified, or removed a visual aid will be placed alongside the number gutter. gitgutter takes advantage of NeoVim's async capabilities to never slow you down.
|
||||
|
||||
## Tabs & a Status Bar
|
||||
|
||||
``` vim vimrc plugin path
|
||||
Plug 'vim-airline/vim-airline'
|
||||
Plug 'vim-airline/vim-airline-themes'
|
||||
```
|
||||
|
||||
Programming in vim can abstract away much of what's happening behind the scenes. In many ways, this is great — but visual reminders are useful for making day-to-day programming a nobrainer.
|
||||
|
||||
vim-airline is widely popular, and surprisingly beautiful, without making vim look too much like a GUI. This plugin and config will show **current mode, current file path, % scrolled through file, tabs for current buffers, and more.**
|
||||
|
||||
It automatically works with plugins it recognizes, such as CtrlP! _(Which we’ll install next…)_
|
||||
|
||||
``` vim vimrc plugin settings
|
||||
let g:airline#extensions#tabline#enabled=1let g:airline_powerline_fonts=1
|
||||
set laststatus=2
|
||||
```
|
||||
|
||||
## Fuzzy Finder
|
||||
|
||||
``` vim vimrc plugin path
|
||||
Plug 'ctrlpvim/ctrlp.vim', { 'on': 'CtrlP' }
|
||||
```
|
||||
|
||||
**The quickest way to jump to a file in your project is with a fuzzy finder.** Similar experiences can be found in popular code editors like Atom.io or Sublime. With vim the same experience can be achieved at _lightning speeds when paired with Ag and NeoVim._ I've tried other fuzzy finders like fzf, but have found ctrlp to have the best experience and most reliable.
|
||||
|
||||
``` vim vimrc plugin settings
|
||||
nnoremap <Leader>p :CtrlP<CR>
|
||||
nnoremap <Leader>t :CtrlP<CR>
|
||||
```
|
||||
|
||||
* `Space t` or `Space p` opens Fuzzy Finder
|
||||
|
||||
## Find in Files
|
||||
|
||||
``` vim vimrc plugin path
|
||||
Plug 'mhinz/vim-grepper'
|
||||
```
|
||||
|
||||
**Sometimes you just need to find some text somewhere in your project.** The Silver Searcher, also known as Ag does just this and it does so very quickly. Grepper uses Ag’s speed combined with NeoVim’s async abilities to provide a fast way to find code anywhere in your project or buffers.
|
||||
|
||||
``` vim vimrc plugin settings
|
||||
nnoremap <Leader>fp :Grepper<Space>-query<Space>
|
||||
nnoremap <Leader>fb :Grepper<Space>-buffers<Space>-query<Space>-<Space>
|
||||
```
|
||||
|
||||
* `Space f p` to type a search to find matches in entire **p**roject
|
||||
* `Space f b` to type a search to find matches in current **b**uffers
|
||||
|
||||
## Project as File Tree
|
||||
|
||||
``` vim vimrc plugin path
|
||||
Plug 'Shougo/vimfiler.vim', { 'on': 'VimFiler' }
|
||||
```
|
||||
|
||||
While _not_ my preferred way to navigate a project, it's handy to have a file tree to see directory structure and browse for a file manually.
|
||||
|
||||
``` vim vimrc plugin settings
|
||||
map ` :VimFiler -explorer<CR>
|
||||
map ~ :VimFilerCurrentDir -explorer -find<CR>
|
||||
```
|
||||
|
||||
* `Space backtick` to toggle File Tree
|
||||
* `Space ~` to open File Tree from current buffer’s directory
|
||||
|
||||
## Autocomplete
|
||||
|
||||
``` vim vimrc plugin path
|
||||
Plug 'Shougo/deoplete.nvim', { 'do': ':UpdateRemotePlugins' }
|
||||
```
|
||||
|
||||
A pretty standard feature of many code editors, an async dropdown tabbable suggestion menu as you type.
|
||||
|
||||
``` vim vimrc plugin settings
|
||||
let g:deoplete#enable_at_startup = 1
|
||||
inoremap <expr><tab> pumvisible() ? "\<c-n>" : "\<tab>"
|
||||
```
|
||||
|
||||
## Linting
|
||||
|
||||
``` vim vimrc plugin path
|
||||
Plug 'w0rp/ale'
|
||||
```
|
||||
|
||||
Async as you type code linting at its finest. Zero config needed.
|
||||
|
||||
## Sneaking — Efficient Moving
|
||||
|
||||
``` vim vimrc plugin path
|
||||
Plug 'justinmk/vim-sneak'
|
||||
```
|
||||
|
||||
The secret to never needing to `wwwww`, or worse `lllll` is learning how to Sneak around your code. Efficient targeting comes from understanding where you want to jump to and pressing the appropriate sneak keys to get there. Key bindings listed below.
|
||||
|
||||
``` vim vimrc plugin settings
|
||||
let g:sneak#s_next = 1
|
||||
nmap f <Plug>Sneak_f
|
||||
nmap F <Plug>Sneak_F
|
||||
xmap f <Plug>Sneak_f
|
||||
xmap F <Plug>Sneak_F
|
||||
omap f <Plug>Sneak_f
|
||||
omap F <Plug>Sneak_F
|
||||
```
|
||||
|
||||
* `f <key>` to jump to next `<key>`
|
||||
* `F <key>` to jump to previous `<key>`
|
||||
* `f` to following match
|
||||
* `s <key><key>` to jump to next `<key><key>`
|
||||
* `S <key><key>` to jump to previous `<key><key>`
|
||||
* `s` to following match
|
||||
|
||||
# Language Specific
|
||||
|
||||
The web is a very diverse space. I suggest searching [VimAwesome](http://vimawesome.com/) for the languages you program in most often to find what plugins may assist you personally.
|
||||
|
||||
# What’s Next
|
||||
|
||||
[Part 3 will cover configuring Zsh](/a-modern-terminal-workflow-part-3-5)
|
||||
|
||||
127
content/posts/a_modern_terminal_workflow_3.md
Normal file
127
content/posts/a_modern_terminal_workflow_3.md
Normal file
|
|
@ -0,0 +1,127 @@
|
|||
---
|
||||
title: A Modern Terminal Workflow — Part 3 / 5
|
||||
description: Configuring Zsh
|
||||
date: 2017-02-10
|
||||
tags:
|
||||
- Tech
|
||||
- Devtools
|
||||
---
|
||||
|
||||
Zsh is a UNIX command interpreter alternative to the default Mac OS shell Bash. Someone who knows Bash already knows the basics of Zsh.
|
||||
|
||||
**So then why?** Zsh is increasing in popularity with those who want more from their terminal. Zsh offers features like syntax highlighting, variables, history commands and other advanced features outside the scope of this article. I install it for the customization potential it offers and appreciate that I can grow to [learn new features over time](https://www-s.acm.illinois.edu/workshops/zsh/why.html).
|
||||
|
||||
# Config
|
||||
|
||||
In part 1 the init script set Zsh as the default shell by running `chsh -s /usr/local/bin/zsh`. The next time you log in Zsh is the new default. Or running `zsh` will launch the Zsh shell.
|
||||
|
||||
`nvim zshrc`
|
||||
|
||||
## Enabling Color Prompts
|
||||
|
||||
##### Note: Syntax highlighting and color may not work as expected within Tmux until it is configured in Part 4 correctly.
|
||||
|
||||
Enabling color is an important first step.
|
||||
|
||||
``` vim zshrc
|
||||
autoload colors zsh/terminfo
|
||||
colors
|
||||
```
|
||||
|
||||
## Minimal Prompt
|
||||
|
||||
> This is my [Prompt]. There are many like it but this one is mine.
|
||||
|
||||
Example:
|
||||
|
||||
|
||||
|
||||
``` vim zshrc
|
||||
precmd() { print "" }
|
||||
PS1="⟩"
|
||||
RPS1="%{$fg[magenta]%}%20<...<%~%<<%{$reset_color%}"
|
||||
```
|
||||
|
||||
A prompt can be a place to put a lot of information at a glance. I'm of the opinion that information belongs hidden behind commands and called upon as needed.
|
||||
|
||||
This prompt consists of an empty line placed above the prompt to separate it from finished commands. The left prompt (PS1) is simply a right arrow character showing where a command can be typed. The right prompt (RPS1) is an ellipsis shortened version showing up to 20 characters from the right of the current path.
|
||||
|
||||
## Autostart Tmux
|
||||
|
||||
The command below does a simple check to confirm Tmux is installed before attempting to run it automatically.
|
||||
|
||||
``` vim zshrc
|
||||
if [ "$TMUX" = "" ]; then tmux; fi
|
||||
```
|
||||
|
||||
In part 4 Tmux will be discussed in greater detail. For now, know that running it only enhances the possibilities so there is no reason not to autostart Zsh running with Tmux. iTerm2, which will be discused in Part 5, also plays explicitly supports Tmux.
|
||||
|
||||
|
||||
If you instead desire to run Tmux manually you may do so by running the `tmux` command at any point.
|
||||
|
||||
## Auto CD
|
||||
|
||||
``` vim zshrc
|
||||
setopt auto_cd
|
||||
```
|
||||
|
||||
A wise man once said, we only have so many keystrokes in our lives. With this simple command we can eliminate 3 of the most common ones, `cd<space>`. Now when you type a directory name or filepath and press enter the cd command is assumed.
|
||||
|
||||
## Spellcheck / Typo Correction
|
||||
|
||||
``` vim zshrc
|
||||
setopt correctall
|
||||
alias git status='nocorrect git status'
|
||||
```
|
||||
|
||||
Zsh has some powerful typo correction capabilities. This is less annoying than it sounds and I love the time it saves me when I mistype a long command.
|
||||
|
||||
It does, however, mistake `git status` as a typo. An alias is included above to correct this behavior.
|
||||
|
||||
# Plugins to Enhance Functionality
|
||||
|
||||
## Package Manager
|
||||
|
||||
Stock Zsh behaves as you'd expect it to. But why stop there? Installing plugins to Zsh can enhance its base functionality with very little overhead.
|
||||
|
||||
``` vim zshrc
|
||||
if [[ ! -f ~/.antigen.zsh ]]; then
|
||||
curl https://raw.githubusercontent.com/zsh-users/antigen/master/antigen.zsh > ~/.antigen.zsh
|
||||
fi
|
||||
source ~/.antigen.zsh
|
||||
```
|
||||
|
||||
Above is the configuration to `curl` the plugin manager antigen which will make installing plugins a breeze.
|
||||
|
||||
## Syntax Highlighting
|
||||
|
||||
``` vim zshrc
|
||||
antigen bundle zsh-users/zsh-syntax-highlighting
|
||||
```
|
||||
|
||||
Code has syntax highlighting, why doesnt the terminal prompt? This package highlights valid and invalid commands as one would expect. It’s amazing this isn’t built in functionality.
|
||||
|
||||
[Learn More](https://github.com/zsh-users/zsh-syntax-highlighting)
|
||||
|
||||
## Autocomplete
|
||||
|
||||
``` vim zshrc
|
||||
antigen bundle zsh-users/zsh-autosuggestions
|
||||
```
|
||||
|
||||
Once again, code has autocomplete, why not the terminal prompt? Allows for repeating previously typed commands with ease.
|
||||
|
||||
[Learn More](https://github.com/zsh-users/zsh-autosuggestions)
|
||||
|
||||
## Git Shorthand
|
||||
|
||||
``` vim zshrc
|
||||
antigen bundle git
|
||||
```
|
||||
|
||||
This plugin includes a lot of powerful shorthands for git. The easiest to remember and one I use most often is simply shortening `git` to `g`.
|
||||
|
||||
# What’s Next
|
||||
|
||||
[Part 4 will cover configuring Tmux](/a-modern-terminal-workflow-part-4-5)
|
||||
|
||||
124
content/posts/a_modern_terminal_workflow_4.md
Normal file
124
content/posts/a_modern_terminal_workflow_4.md
Normal file
|
|
@ -0,0 +1,124 @@
|
|||
---
|
||||
title: A Modern Terminal Workflow — Part 4 / 5
|
||||
description: Configuring Tmux
|
||||
date: 2017-02-20
|
||||
tags:
|
||||
- Tech
|
||||
- Devtools
|
||||
---
|
||||
|
||||
Multiplexing the terminal, huh? Tmux is a simple yet powerful way to work with multiple terminal based programs simultaniously. With Tmux one can ditch the mouse and use keyboard shortcuts to split panes and navigate between tabs of terminal workspaces making anyone a multitasking terminal master.
|
||||
|
||||
Tmux was installed in Part 1 of this guide and its dotfile config can be modified with NeoVim like so `nvim tmux.conf`.
|
||||
|
||||
# Config
|
||||
|
||||
## Fix Copy to Global Clipboard
|
||||
|
||||
_Bah! This article starts with a fix?_
|
||||
|
||||
On later versions of OSX accessing the system clipboard from within tmux became problematic. This command resolves that issue utilizing the `reattach-to-user-namespace` tool already installed in `init.sh`.
|
||||
|
||||
``` vim tmux.conf
|
||||
set -g default-shell $SHELL
|
||||
set -g default-command 'reattach-to-user-namespace -l ${SHELL}'
|
||||
```
|
||||
|
||||
## Tabs
|
||||
|
||||
The obvious way to multitask is with tabs. It's a great place to get started. These keybindings will make working with them more intuitive.
|
||||
|
||||
``` vim tmux.conf
|
||||
set -g status-position top
|
||||
set -g base-index 1
|
||||
set -g pane-base-index 1
|
||||
set -g renumber-windows on
|
||||
bind-key -n C-t new-window
|
||||
bind-key -n C-T new-window -c "#{pane_current_path}"
|
||||
bind-key -n C-w kill-pane
|
||||
```
|
||||
|
||||
* `Ctrl t` to open new tab
|
||||
* `Ctrl T` to open new tab in same directory
|
||||
* `Ctrl w` to close a pane (and tab if only one pane)
|
||||
|
||||
## Create Panes
|
||||
|
||||
A single tab can be split into multiple panes. Mastering panes not only makes the user look like a total terminal professional but can really boost efficiency. Combined with NeoVim this is as close as it gets to having your terminal act like the best parts of an IDE.
|
||||
|
||||
``` vim tmux.conf
|
||||
bind \ split-window -h
|
||||
bind | split-window -h -c '#{pane_current_path}'
|
||||
bind - split-window
|
||||
bind _ split-window -c '#{pane_current_path}'
|
||||
```
|
||||
|
||||
A small tweak on the community “standard” pane splitting hotkeys.
|
||||
|
||||
* `Ctrl b \` to open new vertical split
|
||||
* `Ctrl b |` to open new vertical split in current directory
|
||||
* `Ctrl b -` to open new horizontal split
|
||||
* `Ctrl b _` to open new horizontal split in current directory
|
||||
|
||||
# Plugins
|
||||
|
||||
## Plugin Manager
|
||||
|
||||
Unlike in previous parts of this series there isn't much to extend in terms of functionality for Tmux. However, to get the most out of Tmux it's ideal to install some well defined community made configurations.
|
||||
|
||||
Adding a plugin manager to Tmux is as easy as installing tpm (Tmux Package Manager) via the Terminal. This can be done with git subtrees so that when these dotfiles are cloned to other machines in the future tpm is ready to go.
|
||||
|
||||
``` bash Terminal
|
||||
git remote add -f tpm https://github.com/tmux-plugins/tpm.git
|
||||
git subtree add --prefix=tpm tpm master --squash
|
||||
```
|
||||
|
||||
With tpm installed we can now initialize it in our Tmux Config.
|
||||
|
||||
``` vim tmux.conf
|
||||
set -g @plugin 'tmux-plugins/tpm'
|
||||
# PLUGINS GO HERE!!!
|
||||
run '~/dotfiles/tpm/tpm'
|
||||
```
|
||||
|
||||
### To Install Plugins
|
||||
|
||||
``` bash Terminal
|
||||
tmux source ~/.tmux.conf
|
||||
```
|
||||
|
||||
`Ctrl b I` will install any newly added plugins. A prompt will appear at the top of the terminal to show installation progress.
|
||||
|
||||
## Sensible Defaults
|
||||
|
||||
``` vim tmux.conf plugin path
|
||||
set -g @plugin 'tmux-plugins/tmux-sensible
|
||||
```
|
||||
|
||||
This corrects rendering NeoVim in color through Tmux, removes the escape key delay, configures utf8, and more.
|
||||
|
||||
## Moving Panes
|
||||
|
||||
Splitting and removing panes is easy, but what about moving between them? What if there are NeoVim panes open as well as Tmux panes?
|
||||
|
||||
``` vim tmux.conf plugin path
|
||||
set -g @plugin 'christoomey/vim-tmux-navigator'
|
||||
```
|
||||
|
||||
With this simple plugin this new concern is no longer. Moving between NeoVim and Tmux panes now use the same shortcuts.
|
||||
|
||||
* `Ctrl h, j, k, or l` to switch to split left, down, up, right
|
||||
|
||||
## Theme: Powerline Yellow
|
||||
|
||||
``` vim tmux.conf plugin path
|
||||
set -g @themepack 'block/yellow'
|
||||
set -g @plugin 'jimeh/tmux-themepack'
|
||||
```
|
||||
|
||||
Much like vim-airline, this will give out lower tmux statusbar that powerline look. I've chosen gray but there are other [options](https://github.com/jimeh/tmux-themepack).
|
||||
|
||||
# What’s Next
|
||||
|
||||
[Part 5 will cover configuring iTerm2](/a-modern-terminal-workflow-part-5-5)
|
||||
|
||||
72
content/posts/a_modern_terminal_workflow_5.md
Normal file
72
content/posts/a_modern_terminal_workflow_5.md
Normal file
|
|
@ -0,0 +1,72 @@
|
|||
---
|
||||
title: A Modern Terminal Workflow — Part 5 / 5
|
||||
description: Configuring iTerm2
|
||||
date: 2017-02-21
|
||||
tags:
|
||||
- Tech
|
||||
- Devtools
|
||||
---
|
||||
|
||||
iTerm2 is a Terminal Replacement for Mac OS offering plenty of [customization and features](https://iterm2.com/features.html).
|
||||
|
||||
# Config
|
||||
|
||||
Open iTerm’s preferences with “⌘,” then tick the following settings:
|
||||
|
||||
1. “Load preferences from a custom folder or URL”
|
||||
2. Choose ~/dotfiles
|
||||
3. “Save changes to folder when iTerm2 quits”
|
||||
|
||||
## Theme: Dracula
|
||||
|
||||
Dracula is not only a Vim theme but also a theme for many other applications such as iTerm2. This can be added to the dotfiles just like tpm was in part 4 by using a git subtree.
|
||||
|
||||
``` bash Terminal
|
||||
git remote add -f iterm-dracula https://github.com/dracula/iterm.git
|
||||
git subtree add --prefix=iterm-dracula/ iterm-dracula master --squash
|
||||
```
|
||||
|
||||
1. Profiles tab
|
||||
2. Colors sub-tab
|
||||
3. Color Presets…
|
||||
4. Import…
|
||||
5. ~/dotfiles/iterm-dracula/Dracula.itermcolors
|
||||
|
||||
## Font: Fira Code
|
||||
|
||||
Designers have logos, programmers have... well, frameworks and languages I suppose — but visually a great way to build a brand are our tools and our style. Themes are a great start, but it doesn't have to stop there. Our entire terminal is made up of text, so make that text look beautiful.
|
||||
|
||||
> Put simply: Fira Code is a free monospaced font with programming ligatures.
|
||||
|
||||
What does any of that mean? It's what you want for highly legible code and looking badass in the process.
|
||||
|
||||
**NOTE** _Currently the Fira Code font is only supported in [iTerm's nightly builds](https://www.iterm2.com/downloads/nightly/#/section/home) at the time of writing. Eventually this will simply be part of the final release._
|
||||
|
||||
1. Profiles tab
|
||||
2. Text sub-tab
|
||||
3. Change Font
|
||||
4. Family: Fira Code (I enjoy size 18)
|
||||
|
||||
## Cursor Guide
|
||||
|
||||
Even self proclaimed terminal pro's who claim to never lose track of their cursor should do themselves a favor and enable iTerm2's cursor guide. Subconciously a gentle highlight of the current line will draw your eye right to where you need to be.
|
||||
|
||||
1. Profiles tab
|
||||
2. Colors sub-tab
|
||||
3. “Cursor Guide”
|
||||
4. Set color (I prefer 255, 255, 255, 35)
|
||||
|
||||
## Tmux Tab Switching
|
||||
|
||||
A clever hack to enable `Ctrl Tab` and `Ctrl Shift Tab` tmux tab switching is to let iTerm handle those shortcuts, then send the default `Ctrl B n` and `Ctrl b p` hex codes to the terminal. This pairs well with NeoVim’s tabbing being the same but without holding Ctrl. (Special Thanks to [Dan Lowe](http://tangledhelix.com/blog/2012/04/28/iterm2-keymaps-for-tmux/))
|
||||
|
||||
1. Keys
|
||||
2. New > “Ctrl Tab” > Send Hex Codes > 0x02 0x6E
|
||||
3. New > “Ctrl Tab” > Send Hex Codes > 0x02 0x70
|
||||
|
||||
* `Ctrl Tab` to switch to next tmux tab
|
||||
* `Ctrl Shift Tab` to switch to previous tmux tab
|
||||
|
||||
# Outro
|
||||
|
||||
That wraps up my opinionated guide to created a dotfiles repo for a modern terminal workflow. While it does make assumptions about some ideal tools, configurations, and plugins to use this guide has not assumed what programming languages you the reader may be using. Next steps would be to leverage the plugin managers and configuration files created during the guide to make developing with your favorite languages an even more pleasant experience.
|
||||
29
content/posts/bare-metal-tooling.md
Normal file
29
content/posts/bare-metal-tooling.md
Normal file
|
|
@ -0,0 +1,29 @@
|
|||
---
|
||||
title: Bare Metal Tooling
|
||||
description: Tooling comprehension over plugin reliance.
|
||||
date: 2019-01-30
|
||||
tags:
|
||||
- Tech
|
||||
- Devtools
|
||||
---
|
||||
|
||||
# Getting to Know Your Tools
|
||||
|
||||
I'm obsessive over my dotfiles. They're in such a constant state of flux I'm never sure how to self document them. This was a sign. This lead me down a path to better understanding the bare-metal of my chosen tooling to increase my tooling competence.
|
||||
|
||||
A sign that in my continous search for the best tooling plugins, perhaps _the core problem was I didn't know my tools well enough_. Ever struggled to remember what your custom Tmux bindings were? Why did I change them anyway... maybe the default `ctrl + b` bindings aren't so bad after all.
|
||||
|
||||
Recently I was looking to add a commenter plugin to Vim only to stumble across [this stack overflow result with nearly 2k upvotes](https://stackoverflow.com/questions/1676632/whats-a-quick-way-to-comment-uncomment-lines-in-vim/1676690#1676690<Paste>) using zero plugins or configuration.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
I'll say that again. _Zero plugins or configuration_, just knowing instead how to leverage `ctrl + v` to vertically select in Vim followed by a `shift + i` to insert or `x` to delete.
|
||||
|
||||
The same goes for navigation trees. Most new Vim users, including myself, immediately jump to [NERDtree](https://github.com/scrooloose/nerdtree) or similar plugins and then proceed to learn how they work. Instead, we could just [leverage netrw](https://blog.stevenocchipinti.com/2016/12/28/using-netrw-instead-of-nerdtree-for-vim/) or perhaps [use neither](https://shapeshed.com/vim-netrw/).
|
||||
|
||||
---
|
||||
|
||||
My dotfiles are still constantly in flux. Though, every iteration it manages to get smaller. I'm increasingly leveraging the raw power of the cores of my chosen tooling (Fish, Tmux and Vim) rather than stacking up a pile of new plugins every few weeks. Learning the bare-metal of your tools can drastically boost tooling competence.
|
||||
|
||||
40
content/posts/deving_on_linux_is_fun.md
Normal file
40
content/posts/deving_on_linux_is_fun.md
Normal file
|
|
@ -0,0 +1,40 @@
|
|||
---
|
||||
title: Dev'ing on Linux is Fun!
|
||||
description: Sometimes necessity gives you an excuse to learn some new fun stuff.
|
||||
date: 2018-04-12
|
||||
tags:
|
||||
- Tech
|
||||
---
|
||||
|
||||
I **love** playing with my dotfiles. No, really, I could have played video games before bed but here I am up late _again_ customizing my tooling stack. It's a weird passion I have. I blame my former mentor [Toran Billups](https://github.com/toranb), but I digress.
|
||||
|
||||
# Why Linux?
|
||||
|
||||
In the past six years I've bounced between being a web app developer on Windows and MacOS. It should go without saying that Windows has given me numerous struggles, especially in an enterprise software environment.
|
||||
|
||||
Recently we hit a wall. Ember would take over ten minutes to build and the more complicated apps were closer to twenty-five minutes. I've been not only throwing away countless development hours watching slow builds and build failures, but worse yet it's been causing burnout.
|
||||
|
||||
So we flipped the desk. I chose Linux over MacOS because, well, I'd hoped it would be fun and different... it has been!
|
||||
|
||||
## The Result
|
||||
|
||||
|
||||
|
||||
Put simply, I'm finally able to use the tools that even on MacOS didn't run well. I was able to refer back to [my previous articles on writing dotfiles](https://wrotenwrites.com/a_modern_terminal_workflow_1/) while making adjustments for the platform, the fact that it's 2018, and to change things up just a little. I find it beautiful and familiar.
|
||||
|
||||
### Terminal — Hyper
|
||||
|
||||
I push my terminal a little, but not too hard. As a visual person doing web development, [Hyper](https://wrotenwrites.com/a_modern_terminal_workflow_1/) is perfect for me.
|
||||
|
||||
It feels lightning quick on my linux box and is simply gorgeous with [dracula theme](https://draculatheme.com/hyper/) applied. I followed their "Install using config file" instructions while manually git cloning [the repo](https://github.com/dracula/hyper) for Hyper to find. The configuration is a `.js` file which is bonus points for me.
|
||||
|
||||
### Shell — Fish
|
||||
|
||||
[Previously I recommended using Zsh](https://wrotenwrites.com/a_modern_terminal_workflow_3/) with a bunch of customizations. Now, I just [install Fish](https://fishshell.com/) which is configured nicely right out of the box.
|
||||
|
||||
An [unofficial dracula theme](https://github.com/nesl247/fish-theme-dracula) is available as well! I kept the prompt it comes with too which is nice.
|
||||
|
||||
### NeoVim and Tmux
|
||||
|
||||
Overall I'm still rocking the same [NeoVim setup](https://wrotenwrites.com/a_modern_terminal_workflow_2/) and [Tmux setup](https://wrotenwrites.com/a_modern_terminal_workflow_4/) I've recommended in the past. Some personal minor adjustments like `number relativenumber` which is a new favorite vim config of mine, and I'm pretty satisfied with it.
|
||||
|
||||
50
content/posts/embers-app-import.md
Normal file
50
content/posts/embers-app-import.md
Normal file
|
|
@ -0,0 +1,50 @@
|
|||
---
|
||||
title: Non-Ember Things in Ember
|
||||
description: No `ember install`? No problem!
|
||||
date: 2018-04-26
|
||||
tags:
|
||||
- Tech
|
||||
- Ember
|
||||
---
|
||||
|
||||
The Ember community is great and [full of great ember-cli friendly addons](https://www.npmjs.com/search?q=ember) to add to your project. Using [Redux](https://github.com/reactjs/redux)? Check out [ember-redux](https://www.npmjs.com/package/ember-redux). Need [FastClick](https://github.com/ftlabs/fastclick)? Check out... well, actually your best bet is [ember-hammertime](https://www.npmjs.com/package/ember-hammertime) but you get the point.
|
||||
|
||||
But **sometimes you just _need_ to incorporate something that isn't Ember ready**. Today that's easier than ever!
|
||||
|
||||
## Show Me
|
||||
|
||||
In this example we'll be adding `url-polyfill` to our Ember app. _I know `ember-url` is out there but it lacks some of the functionality `url-polyfill` offers._
|
||||
|
||||
1. `yarn add url-polyfill` or `npm install --save url-polyfill`
|
||||
2. In your `ember-cli-build.js` within the `module.exports = function() {` add the following...
|
||||
```js
|
||||
app.import('node_modules/url-polyfill/url-polyfill.js');
|
||||
```
|
||||
|
||||
You're done!
|
||||
|
||||
For bonus points, you can even configure which import you use based on the environment...
|
||||
```js
|
||||
app.import({
|
||||
development: 'PATH/file.js',
|
||||
production: 'PATH/file.min.js',
|
||||
});
|
||||
```
|
||||
|
||||
This also works with css files to bring in your favorite CSS framework, animation library or other tool. If you're still using bower, simply point your import path to `bower_components/DEPENDENCY/FILE.EXT`.
|
||||
|
||||
### But, wait, I have some setup I need to do!
|
||||
|
||||
That's cool too! An initializer is likely what you'll want.
|
||||
```bash
|
||||
ember generate initializer myInitializer
|
||||
```
|
||||
|
||||
Then within there you can run any initialization code your heart desires and it'll run at app load.
|
||||
|
||||
## Want to go further?
|
||||
|
||||
Make an ember-addon for your favorite tool and publish it on npm! The community would appreciate it and love the easy of an `ember install`.
|
||||
|
||||
Go make great things. Or... combine great things into an even greater thing!
|
||||
|
||||
35
content/posts/getting_started_gets_better_with_you.md
Normal file
35
content/posts/getting_started_gets_better_with_you.md
Normal file
|
|
@ -0,0 +1,35 @@
|
|||
---
|
||||
title: Getting Started Gets Better With You
|
||||
description: Transform company culture by transforming a lesser onboarding experience into a great one for future hires.
|
||||
date: 2017-03-16
|
||||
tags:
|
||||
- Workplace
|
||||
---
|
||||
|
||||
**How was your onboarding experience?** How were your first moments of any development job in recent recollection?
|
||||
|
||||
If you recall it being a pleasant experience, then I'm glad for you. Generally, onboarding a new developer involves a process of awkwardly asking people you barely know what feel like stupid questions.
|
||||
|
||||
# Getting Started Gets Better With You
|
||||
|
||||
Write down your questions no matter how seemingly simple they may be. Then follow up on your notes with the answers.
|
||||
|
||||
> * Where is the app's repo?
|
||||
> * How do I install the app's dependencies?
|
||||
> * How do I launch the app?
|
||||
> * Where do I find work to do?
|
||||
|
||||
Suddenly you wind up with something akin to an _FAQ_ (Frequently Asked Questions). Passing along these questions and answers to the next new hire can make a dramatic impact on their **first impression** and ability to **ramp up quickly**.
|
||||
|
||||
## Making It Real
|
||||
|
||||
Asking for forgiveness rather than permission can be daunting when you're new. A safe way to spread and better your notes is sharing them with the next new hire. Be sure to gather any questions they have and improve your notes with each person you work with.
|
||||
|
||||
Ideally publishing these notes internally in an internal knowledge base, wiki, or the README.md of the project repo can be a great resource. I encourage
|
||||
anyone to submit a pull request to clean up the often neglected README's in repositories to answer the typical questions that currently may be answered by repetitive word of mouth.
|
||||
|
||||
# See a problem? Be the solution.
|
||||
|
||||
Anyone can make a positive impact on company culture by sharing what you've learned with others.
|
||||
|
||||
Take notes. Share them. Don't be afraid of taking initiative. Imagine the impact such an effort could've had on your first days and don't let the trend of ignoring onboarding continue.
|
||||
55
content/posts/git-commit-targeting.md
Normal file
55
content/posts/git-commit-targeting.md
Normal file
|
|
@ -0,0 +1,55 @@
|
|||
---
|
||||
title: Easy Git Commit Targeting
|
||||
description: Shortened SHA hashes and relative offsets
|
||||
date: 2017-04-21
|
||||
tags:
|
||||
- Tech
|
||||
---
|
||||
|
||||
A generally agreed upon goal of a developer is to use the mouse as little as possible. An often overlooked moment of touching the mouse is the seemingly inevitable moment of having to target a git commit via it's SHA hash. Truth is this doesn't need to be an ordeal.
|
||||
|
||||
**Let's look at some alternative ways to target commits**.
|
||||
|
||||
## By Shortened SHA Hash
|
||||
|
||||
Traditionally to find the `git diff 123abc456def789ghi` on a SHA you'd use the entire SHA hash. Instead, you can type just the first few characters and Git will figure out the rest.
|
||||
|
||||
``` bash
|
||||
git diff 123abc
|
||||
```
|
||||
|
||||
## Tilde
|
||||
|
||||
A common target is the previous commit from the HEAD. Using `HEAD~` will specify the intention of one commit before the HEAD.
|
||||
|
||||
``` bash
|
||||
git diff HEAD~
|
||||
```
|
||||
|
||||
### Past Tilde
|
||||
|
||||
Adding a number after the tilde `~` will target a commit prior to the head equal to the number specified.
|
||||
|
||||
``` bash
|
||||
git diff HEAD~3
|
||||
```
|
||||
|
||||
## Stacked Carets 🥕🥕🥕
|
||||
|
||||
Alternatively, the number of caret characters after HEAD will similarly target a commit prior to HEAD equal to the number of carets.
|
||||
|
||||
``` bash
|
||||
git diff HEAD^^^
|
||||
```
|
||||
|
||||
## Combine These Tricks
|
||||
|
||||
So close! Ever want to target the commit just previous to a SHA hash? It's easier than you think.
|
||||
|
||||
``` bash
|
||||
git diff 123abc~
|
||||
```
|
||||
|
||||
# Summary
|
||||
|
||||
Through a combination of shortened SHA hashes, HEAD, and relative tilde/caret characters anyone can fly through git history with confidence.
|
||||
20
content/posts/learning_on_rails.md
Normal file
20
content/posts/learning_on_rails.md
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: Learning on Rails
|
||||
description: Reflections on learning Rails.
|
||||
date: 2018-10-08
|
||||
tags:
|
||||
- Tech
|
||||
- Learning
|
||||
- Retrospective
|
||||
---
|
||||
|
||||
Learning is an interesting thing. As I grow older I find myself paying far more attention to how I learn. It's a journey that's different for everyone.
|
||||
|
||||
These past five years Ember has been my world. Seriously, I just got back from another conference and I'm to speak at a meetup this month on Ember. When I had heard Ember took a _lot_ of inspiration from Ruby on Rails I never paid it much mind. Now I wonder if learning Ember would have been easier after understanding [The Rails Doctrine](https://rubyonrails.org/doctrine/). In it are many familiar topics such as [Convention over Configuration](https://rubyonrails.org/doctrine/#convention-over-configuration), but also a familiar folder structure, CLI tool generators, and smart defaults for things that can be assumed.
|
||||
|
||||
Taking the time to learn Rails has better framed my understanding of the Javascript framework I love by backing up the things I've simply memorized with meaningful context. It makes sense that a Controller file in Ember is optional if you don't need to customize anything about it. Of course generators add to your routes config and automatically wire up some new tests as well. It all just clicks together now in my head.
|
||||
|
||||
I never felt a need to venture outside of my bubble before. But by intentionally doing so, I realized the bubble only harmed by ability to learn rather than protect me in some way. There's no need to be afraid of learning. You never know just how much it may help you.
|
||||
|
||||
Finally, I encourage you to document and share what you learn. I've published [my hello world's in both Ruby and Rails](https://github.com/sharpshark28/hello-ruby) and highly recommend [rubyonrail.org's Getting Started guide](https://guides.rubyonrails.org/getting_started.html#hello-rails-bang) if you'd like to get started with Rails and learn something fun.
|
||||
|
||||
58
content/posts/less_blue_light_better_sleep.md
Normal file
58
content/posts/less_blue_light_better_sleep.md
Normal file
|
|
@ -0,0 +1,58 @@
|
|||
---
|
||||
title: Less Blue Light, Better Sleep
|
||||
description: Limiting blue light and increasing sleep quality to live a more productive, healthier life.
|
||||
date: 2017-09-02
|
||||
tags:
|
||||
- Life
|
||||
- Health
|
||||
- Workplace
|
||||
---
|
||||
|
||||
Actively limiting blue light, both artificial and natural, can make you a healthier and happier person. No, really, it can.
|
||||
|
||||
|
||||
|
||||
<cite>Photo by [Juil Yoon](https://unsplash.com/photos/anhQGEYbnV4?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)</cite>
|
||||
|
||||
Imagine a workday without eye strain or grogginess. Regaining control over your ability to fall asleep comfortably. With some tweaks to daily habits and reducing blue light intake this can be a reality.
|
||||
|
||||
## What? Why blue light?
|
||||
|
||||
Briefly, the more harmful spectrum of light is within a band of blue light. This narrow band of harmful light contributes the most to eye strain and wakefulness. [Learn More](http://www.allaboutvision.com/cvs/blue-light.htm)
|
||||
|
||||
## On Eye Strain
|
||||
|
||||
Sitting for eight or more hours staring at a screen isn't what you're paid for - you're paid to produce results. You can only achieve that if you're healthy. Eye strain can lead to headaches and health problems resulting in your eyes degrading slowly over time.
|
||||
|
||||
### Get up. Move around.
|
||||
|
||||
**Take a break** from the computer screen. Converse with your colleagues. **Avoid eating lunch at your desk**. While we're reducing our blue, let's up our green - **go outside** and see some grass, trees, plants **to feel refreshed and revitalized**. Some time in the sun can help too.
|
||||
|
||||
### Filtering Blue Light
|
||||
|
||||
Just as there are glasses to protect from the sun, **some glasses filter out blue light**. Over the counter blue light filtering lenses are available or you may _speak with your eye doctor_ on **adding them to your next pair**. I personally use blue light filters in my primary pair of glasses and can happily say there is no color noticeable color distortion to disrupt my design work.
|
||||
|
||||
UPDATE: Some applications you already use such as Amazon's Kindle book reading service offers dark or sepia themes for reading with reduced eye strain.
|
||||
|
||||
Applications like [F.lux](https://justgetflux.com/) (or [iOS Night Shift](https://support.apple.com/en-us/HT207570), [Android Twilight](https://play.google.com/store/apps/details?id=com.urbandroid.lux), [Linux Redshift](http://jonls.dk/redshift/) and others) allow for removing or reducing _the output_ of blue light from your device. Some of these tools can intelligently fade the amount of blue light based on the time of day or be disabled based on a timer.
|
||||
|
||||
## On Sleep
|
||||
|
||||
Blue light activates "wake up" signals in our brain (what? this isn't a science blog). **Avoid these wake up signals 30-60 minutes before bed** and you'll not only _fall asleep more easily_, but you'll be _awaken more smoothly_ without that groggy sensation.
|
||||
|
||||
If you're unable to get 30-60 minutes away from a screen before bed then reconsider your nighttime habits. Worse yet, if you're coding late into the night then immediately attempt going to sleep your mind is at its most active state or you could burn yourself out. Instead, consider shutting off the screen a little early and let your mind problem solve during the downtime and while you're sleeping - you'll likely be more productive.
|
||||
|
||||
**Quality of sleep is far more important than the quantity of sleep you receive**. If you're not waking up feeling refreshed then you'll need to reconsider your sleep habits.
|
||||
|
||||
---
|
||||
|
||||
For bonus points, cut out caffeine from your diet some or entirely. Avoid eating just before bed and sleep in a dark room without interruptions whenever possible.
|
||||
|
||||
## Summary
|
||||
|
||||
To truly live a healthy work life balance we must take care of ourselves physically and mentally. The quality of sleep we receive drastically affects our moods and health in both the short and long term. Better managing the excess of blue light from our modern world into our lives can result in better sleep and longer lasting good eyesight with fewer health problems.
|
||||
|
||||
---
|
||||
|
||||
_Enjoy this article? I've also written about {% post_link polyphasic-sleep-and-passion %}_.
|
||||
|
||||
75
content/posts/performance_reviews.md
Normal file
75
content/posts/performance_reviews.md
Normal file
|
|
@ -0,0 +1,75 @@
|
|||
---
|
||||
title: Performance Reviews - You and Your Peers
|
||||
description: ...shouldn't feel daunting or boring. They're an opportunity to acknowledge the hard work of your peers.
|
||||
date: 2017-06-01
|
||||
tags:
|
||||
- Workplace
|
||||
---
|
||||
|
||||
You possess something invaluable. Management relies on you to give honest feedback of your coworkers when its time for peer performance reviews.
|
||||
|
||||
_Perhaps writing a performance review feels boring or mandatory._ An empty, white, often-too-small text box with the ask of summarizing a coworker's qualities as an employee can be daunting. Never underestimate its importance, however, just as we see importance in reviewing a peer's code before its added to the project we consider our own, we should equally consider our peers themselves at the company we associate with.
|
||||
|
||||
## Provide Feedback Often - Not Just On Judgment Day 🚫
|
||||
|
||||
Imagine you're in a college class. You feel you're doing well. You take your final. Suddenly you're given a failing grade for the course.
|
||||
|
||||
Being given poor marks when it's too late isn't fair and doesn't support a healthy culture. **Give feedback regularly throughout the year** to _avoid surprise criticism_ and _give time to improve_ and fix any critiques you may have.
|
||||
|
||||
Write any critique given as with an actionable solution. Instead of "they made me miss the deadline" perhaps "if we communicate better we should be able to make the next deadline as a team".
|
||||
|
||||
## Questions To Reflect Upon 💭
|
||||
|
||||
Below are the questions I consider when reflecting upon my experiences and understanding of a colleague I'm trying to qualify.
|
||||
|
||||
### Has This Person Ever Made Your Day Easier? 👍
|
||||
|
||||
* "Colleague pair programmed with me to solve a difficult problem while teaching me how to debug similar problems in the future."
|
||||
* "Colleague wrote a well documented component that solved my needs and saved me many hours of work."
|
||||
|
||||
Acknowledge when a coworker has saved you time, stress, or helped you learn a new skill. These are often selfless offerings from people just looking to help their fellow workers and make the company a better place to work.
|
||||
|
||||
Conversely, if an individual has made more days difficult than they have made easier that is an indicator of a problem worth speaking up about.
|
||||
|
||||
### Has This Person Helped You Grow? 🌱
|
||||
|
||||
* "Colleague made me rethink how I approach testing my code."
|
||||
* "Colleague provided a great example of how to reach a work-life balance."
|
||||
|
||||
Positive influences, critical thinkers, and industry leaders often surround us at work. It's easy to presume these are already known qualities to everyone. It's important to be explicit and state what may seem obvious to us, but may not be to others such as management.
|
||||
|
||||
If you've learned from those around you it's only fair to acknowledge the source of the growth for the teachers to be rewarded. This not only could lead to their promotion, but also to a positive feedback loop of them desiring to continue to help others.
|
||||
|
||||
### Has This Person Shown Any or All The Skills of a [Senior Engineer or Equivalent](http://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/)? 🍷
|
||||
|
||||
* "Colleague was very receptive to my code feedback despite it being my first few weeks on the job."
|
||||
* "Colleague was eager to help me learn an otherwise obscure skill."
|
||||
* "Colleague showed professionalism in their demeanor by addressing core problems while never making excuses. A real doer, not a complainer"
|
||||
|
||||
Potential promotions are a primary goal of peer reviews. [On Being a Senior Engineer](http://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/) offers a new perspective on what makes a mature engineer while dismissing false qualities like years of experience.
|
||||
|
||||
> * Mature engineers seek out constructive criticism of their designs.
|
||||
> * Mature engineers understand the non-technical areas of how they are perceived.
|
||||
> * Mature engineers do not shy away from making estimates, and are always trying to get better at it.
|
||||
> * Mature engineers have an innate sense of anticipation, even if they don't know they do.
|
||||
> * Mature engineers understand that not all of their projects are filled with rockstar-on-stage work.
|
||||
> * Mature engineers lift the skills and expertise of those around them.
|
||||
> * Mature engineers make their trade-offs explicit when making judgements and decisions.
|
||||
> * Mature engineers don't practice CYAE ("Cover Your Ass Engineering").
|
||||
> * Mature engineers are empathetic.
|
||||
> * Mature engineers are aware of cognitive biases.
|
||||
|
||||
Conversely, if an individual meets very few or none of the items on this list it may be an indicator of room for improvement.
|
||||
|
||||
### Has This Person Shown Healthy Levels of Involvement or [Desire to Job Craft](https://www.mindtools.com/pages/article/newCDV_36.htm)? 🍻
|
||||
|
||||
* "Despite colleague being from team X, they were passionate while collaborating on my project."
|
||||
* "Project lead improved the designs of their reports to help in understanding the data. Their background in design really shows through their work."
|
||||
|
||||
It's all too easy to sit at a desk and trudge through the _minimum amount of work_ assigned to earn a paycheck. It's also _all too common to overwork_ oneself accepting an ever increasing quantity of that same work.
|
||||
|
||||
[Job Crafting](https://www.mindtools.com/pages/article/newCDV_36.htm) shows a strive for **work-life balance** through utilizing one's own **unique set of skills**. A colleague who works on a **diverse range of projects** while **collaborating with multiple teams** is a great quality to acknowledge during a peer review. Your acknowledgment will help encourage management to consider what the individual is already doing in a more official capacity to assist in further developing their career.
|
||||
|
||||
## Start Writing
|
||||
|
||||
Extracting answers to these questions into their **qualities** is the last step in writing a quality peer review. As with any professional writing, be **concise**. Be **fair**. _Write about others as you wish they'd write about you._
|
||||
35
content/posts/polyphasic-sleep-and-passion.md
Normal file
35
content/posts/polyphasic-sleep-and-passion.md
Normal file
|
|
@ -0,0 +1,35 @@
|
|||
---
|
||||
title: What Polyphasic Sleep Taught Me About Passion
|
||||
description: Valuing your time. Growing with those who wish to grow with you.
|
||||
date: 2017-04-06
|
||||
tags:
|
||||
- Life
|
||||
- Retrospective
|
||||
---
|
||||
|
||||
Like many travelers I can at times suffer from jet lag, but this time I've turned the problem into an opportunity to begin a [polyphasic sleep schedule](https://www.polyphasicsociety.com/polyphasic-sleep/overviews/). There's no better time to start such a sleep schedule transition than when your schedule is already thrown out of wack.
|
||||
|
||||
> There's no better time than the present.
|
||||
> _~That's what "They" say._
|
||||
|
||||
Within just days of adopting polyphasic sleep I had learned a great deal. Beyond the obvious benefits of learning to manage my time better and regaining a sense of control in my life I discovered other things as well. Specifically, **I discovered surprising things about the people I surround myself with** in response to telling them about the new schedule. Additionally, I developed an **increasing awareness of my own mortality**.
|
||||
|
||||
## Surrounding Yourself With Passionate People
|
||||
|
||||
Initially the news of my adopting polyphasic sleep was met with _distain and shock_. Strong negative reactions such as "that sounds horrible" or "I'd just be bored more often" hit my psyche hard. This was a life change I truly believed in and I was **not** being met with support from those I considered close. **I was in disbelief in how uninterested others were** in what I believed to be an life altering topic.
|
||||
|
||||
However, **others perked their ears in interest** and asked great questions like "how does that work?", "is it healthy?", or "has it been going well?". **These were meaningful conversations precipitated by people desiring to live interesting lives**.
|
||||
|
||||
Discussing polyphasic sleep as a life style choice with individuals has revealed a surprising level of _insight into how others view the world_. **Having these conversations can identify people as apathetic or as passionate**.
|
||||
|
||||
## Making the Most Of Your Time
|
||||
|
||||
I desire to live a passionate life. To me that means **expressing love while creating and learning at all times**.
|
||||
|
||||
I view the world through the lens of existential realism. I'm quite aware of the limited time we live, how I'm living it and who I surround myself with. _Polyphasic sleep promises more awake hours and consequently more life to live_. My formative years should be spent growing my knowledge, relationships and passions.
|
||||
|
||||
**More hours are meaningless without intent**. Overscheduling isn't healthy either, but without passion and intent it's easy to ask "why bother?". This is true regardless of polyphasic sleep or not.
|
||||
|
||||
# Summary
|
||||
|
||||
Polyphasic sleep has given me the gift of more life. **I choose to use it to grow with those willing to grow alongside me in a world of passionate people and passionate actions**.
|
||||
70
content/posts/self-code-review-with-git-patch.md
Normal file
70
content/posts/self-code-review-with-git-patch.md
Normal file
|
|
@ -0,0 +1,70 @@
|
|||
---
|
||||
title: Self Code Review with Git Add Patch
|
||||
description: Reduce errors and typos while building confidence with every chunk you commit.
|
||||
date: 2017-05-04
|
||||
tags:
|
||||
- Tech
|
||||
- Workplace
|
||||
---
|
||||
|
||||
Code reviews reduce logical errors, call out typos, and prevents accidentally committing more code than intended ([1](https://www.atlassian.com/agile/code-reviews)). They're essential for _all sized teams_ pushing to the same code base while _maintaining sanity_.
|
||||
|
||||
Should a developer find themselves discovering any accidental "oops!" in their pull request it's a good indicator of a flaw in workflow. **Introducing the interactive self code review:**
|
||||
|
||||
``` bash
|
||||
git add --interactive
|
||||
```
|
||||
|
||||
Interactive adding in git offers a choose-your-own-adventure style "What Now>" series of options.
|
||||
|
||||
## The Useful Bit: _Git Patch_
|
||||
|
||||
Today let's look at the _**p**atch_ option. We can skip to the patch option in the future with this handy shortcut:
|
||||
|
||||
_Example pretends we have file.ext and have added a line that defines a version..._
|
||||
|
||||
``` bash
|
||||
git add -p
|
||||
|
||||
diff --git a/file.ext b/file.ext
|
||||
index sha1..sha2 sha3
|
||||
-- a/file.ext
|
||||
++ b/file.ext
|
||||
{
|
||||
"name": "example json",
|
||||
+"version": "1.0.0",
|
||||
"private": true,
|
||||
Stage this hunk [y,n,q,a,d,/,e,?]?
|
||||
```
|
||||
|
||||
Looks like a huge chunk of stuff! Broken down, the response describes what file was modified followed by a chunk of color coated git diff.
|
||||
|
||||
### Now What? Staging Hunks of Code
|
||||
|
||||
Many options are provided in the "Stage this hunk?" prompt following a git add patch.
|
||||
|
||||
Pressing `?` in response to the prompt explains each valid response. These are some essentials:
|
||||
|
||||
* **y** - stage this hunk
|
||||
* **n** - do _not_ stage this hunk
|
||||
* **q** - quit
|
||||
|
||||
You'll find that by going through this process you can read every line you'd like to add to a commit and make better choices about them.
|
||||
|
||||
### Splitting `s`
|
||||
|
||||
These "magical" feeling chunks aren't always smart enough. Sometimes there's a need to split (with the `s` response) a chunk into smaller chunks. This comes up more often than you'd think if you're developing empathetically.
|
||||
|
||||
### `a` Add or `d` Don't Add Entire File
|
||||
|
||||
An `a` response will stage the current hunk and all the following within the current file automatically. This is **_not_ recommended because you're opting to skip parts of your personal code review**.
|
||||
|
||||
However, `d` is a nice way to skip adding anything from an entire file and can save a lot of time.
|
||||
|
||||
### Manually Editing
|
||||
|
||||
Typos or "oops!" can be quickly corrected with the `e` response. This will open just the chunk for quick adjustments including line adding and removal.
|
||||
|
||||
# Summary
|
||||
|
||||
Git patch has become a core part of my workflow to **ensure quality** and boost **personal confidence in the code I ship**. Give it a try today!
|
||||
20
content/posts/separation-of-concerns-addon.md
Normal file
20
content/posts/separation-of-concerns-addon.md
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: Faster Test Suites, Less Code, Embracing Writing Addons.
|
||||
description: Less code, a faster test suite, and a tighter focus on core functionality can be achieved through embracing open source.
|
||||
date: 2017-11-17
|
||||
tags:
|
||||
- Tech
|
||||
- Testing
|
||||
---
|
||||
|
||||
Less code, a faster test suite, and a tighter focus on core functionality can be achieved through embracing open source. [Ember addons](https://www.emberaddons.com/) are on point in delivering such a promise as I've learned while open sourcing a widely used [component at work](https://github.com/q2ebanking/ember-select-light).
|
||||
|
||||
The key is a separation of concerns. Modifying code rebuilds the app and, before shipping, all tests must be verified again regardless of what the modifcations touch. Moving chunks of an app, such as a component, to an open source addon grants all the benefits that come with code isolation. Admittedly similar can be achieved with careful abstraction and no open source, but I feel it's the right direction for myself and likely others to aim for.
|
||||
|
||||
**Less code** a developer must retain in their heads the easier they may reason about the way an app flows. A well tested and well documented addon promises a level of functionality not often afforded by yet another file to be debugged within the app. While addon code eventually gets compiled into the final output, I've found the act of isolating code into an addon forces me to code more concisely and clearly for public consumption. Without the goal of open sourcing the addon I may cut corners thinking "it's just for me, no big deal" which can do more harm than good longterm.
|
||||
|
||||
**Faster test suite** runs, without the cost of coverage, comes isolating tests to separate addon projects. This goes both ways in fact. Tests get removed from the original app and an addon will have just the tests to cover itself resulting in a quick build and test time. Isolated testing concerns can lead to higher relative code coverage and a quicker feedback loop for [test-driven development](https://www.youtube.com/watch?v=2b1vcg_XSR8).
|
||||
|
||||
**Tighter focus on core functionality** arises from the need to isolate an addon's concern to a concise idea. Assigning a name and writing documentation for an addon is a healthy exercise in producing a highly intentional and hopefully valuable addon.
|
||||
|
||||
After becoming no longer afraid of the world of open source I've learned to embrace the advantages that come from creating a wide range of projects. Addons are a new and exciting world for me and hopefully for you as well.
|
||||
153
content/posts/the_great_app_store_trials.md
Normal file
153
content/posts/the_great_app_store_trials.md
Normal file
|
|
@ -0,0 +1,153 @@
|
|||
---
|
||||
title: The Great App Store Trials
|
||||
description: Becoming a Published Play Store Developer
|
||||
date: 2017-08-13
|
||||
tags:
|
||||
- App
|
||||
- Retrospective
|
||||
- Tech
|
||||
---
|
||||
|
||||
[Today marks my first day as a published app store developer](https://play.google.com/store/apps/details?id=io.cordova.myspells). It's been a dream of mine to release work I've done not just on the web, but as something native you can put in your pocket without needing a browser. Some stories are of great heroes who overcome dangerous challenges through incredible feats of might; this one is of the problems and solutions of releasing a web app to the Play Store.
|
||||
|
||||
## Act I: Building the App
|
||||
|
||||
I chose the [Quasar Framework](http://quasar-framework.org/) powered by [Vue.js](https://vuejs.org/) with [Cordova](https://cordova.apache.org/) mobile conversion built in. **Choosing tools that played well together** assured me that if I _read the documentation_ and put in the effort **I'd eventually succeed**.
|
||||
|
||||
**Release often**. Advice I give to anyone and even easier to follow for a hobbyist project. Hit your **minimum viable product then release** the app to the public.
|
||||
|
||||
### Problem: Releasing a Web App Cheaply and Easily
|
||||
|
||||
I'm no server admin. I've built my app and just wish to see it online for public consumption.
|
||||
|
||||
#### Solution: Netlify
|
||||
|
||||
Open Source projects can be automatically deployed and built directly from a Github repo for free to the [Netlify](https://www.netlify.com/) servers. Once hosted you get a simple URL to include in your project.
|
||||
|
||||
### Problem: Bugs
|
||||
|
||||
They happen, bugs are a natural part of application development. Keeping a todo list on your computer seems counter to the connected open source world we live in.
|
||||
|
||||
#### Solution: Github Issues
|
||||
|
||||
Being transparent in logging bugs has a number of benefits. [Github Issues](https://guides.github.com/features/issues/) is a great tool for this.
|
||||
|
||||
* As easy as a todo list.
|
||||
* Great practice, especially if you _follow [SemVer](http://semver.org/)_ and write _clean commits_.
|
||||
* Users know what's busted and have a window into helping to _fix the bugs themselves_.
|
||||
* **Forms a public history for the project** while _encouraging a changelog_ as the app evolves.
|
||||
|
||||
## Act II: Building for Android
|
||||
|
||||
Generally [Quasar makes compiling for Android easy](http://quasar-framework.org/guide/quasar-play-app.html) and enjoyable. Running their mobile dev tools unveiled several mobile specific bugs, which I logged then fixed.
|
||||
|
||||
Quasar's easy tools are great for quick feedback but are nothing compared to a real debugging APK running on your phone. Luckily there are docs for [wrapping your Quasar app in Cordova](http://quasar-framework.org/guide/cordova-wrapper.html).
|
||||
|
||||
### Problem: Running Cordova Built APK
|
||||
|
||||
The documentation drops off quickly after Cordova has done its job.
|
||||
|
||||
> You find yourself in a wolf's den of opinions and tools in a world of assumed knowledge.
|
||||
|
||||
Emulation through [Android Studio](https://developer.android.com/studio/index.html) is possible, but I could never get it to work with my non-Android-Studio app.
|
||||
|
||||
#### Solution: Cordova compile to device.
|
||||
|
||||
After some digging, the most successful way to compile to my Android device was:
|
||||
|
||||
1. `quasar build` from my **root**.
|
||||
2. `quasar run --device` from the **cordova directory** while my **phone was plugged** in with **USB Debugging** turned on.
|
||||
|
||||
This automatically compiles and opens the app on your connected Android device.
|
||||
|
||||
_P.S. Android Studio may still be required here._
|
||||
|
||||
##### Also... Overcoming USB Debugging
|
||||
|
||||
Enabling USB Debugging on modern Android phones is the opposite of obvious. Luckily, [this guide to Android USB debugging](https://www.kingoapp.com/root-tutorials/how-to-enable-usb-debugging-mode-on-android.htm) explains the process.
|
||||
|
||||
##### Also... Overcoming USB Cable Differences
|
||||
|
||||
I encountered times where USB debugging refused to work. Turns out _some usb cables only transfer power and not data_. Use the correct USB cable type to avoid wasted time for silly reasons.
|
||||
|
||||
#### Problem: Local Ajax Calls Don't Work
|
||||
|
||||
JSON cannot be fetched locally as we could on Netlify. I did not wish to bake in all of my data on the web app to slow down initial load.
|
||||
|
||||
#### Solution: Bake in data for the app build only.
|
||||
|
||||
For my web app, the only concern with baking in data was app size for first load. On mobile that's not a problem. In fact, baking in the data means an even easier offline solution.
|
||||
|
||||
I wrote a [data processor](https://github.com/sharpshark28/my_spells/blob/master/build/process_spells.js) node script that could either compile my data to a JSON file or to a JS importable module (with `export default ...`) along with some [package.json build scripts](https://github.com/sharpshark28/my_spells/blob/master/package.json) to simplify the process during development and releases. In the app, I always import the JS module and if there is `data.length > 0` I use it, else I attempt to fetch the JSON file.
|
||||
|
||||
It took effort, but assured that my both the web and android app were quick to launch.
|
||||
|
||||
## ACT III: Publishing
|
||||
|
||||
Congratulations! You have an app that runs on Android. Next, you must fumble through the _app publishing process_. I've done my best to list the steps, problems and solutions below.
|
||||
|
||||
### Step: You Want Money and My Soul?
|
||||
|
||||
First step is registering for a Publisher Account with your Google User. This involves agreeing to many terms of services and paying a **fee of $25** that separates you from the potential onslaught of crapware and spam that may otherwise reach the Play Store. Relatively straightforward and _a necessary evil_ to progress.
|
||||
|
||||
### Problem: Releasable APK file
|
||||
|
||||
Up until now _we've been using a debugging APK_ file. That's not good enough for release.
|
||||
|
||||
#### Solution: Cordova Build
|
||||
|
||||
`cordova build` will create an android-release-unsigned.apk that is, as the filename implies, an **unsigned but otherwise ready to release APK**.
|
||||
|
||||
### Problem: Signing the APK file
|
||||
|
||||
One of the least documented parts of the process is signing the APK outside of a completely Android Studio made app.
|
||||
|
||||
#### Solution: Android App Studio, Keystore, jarsigner
|
||||
|
||||
1. Install [Android Studio](https://developer.android.com/studio/index.html) and launch it
|
||||
2. Open an Existing Project... choose the cordova created project directory for the app
|
||||
3. Build -> Generate Signed APK
|
||||
4. Key Store Path: Create New (follow onscreen prompts)
|
||||
- Note the place you've saved it, and what the key alias is (key0 is fine)
|
||||
5. Close Android Studio, we'll instead use jarsigner to sign our apk:
|
||||
``` bash
|
||||
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore <~/path/to/keystore.jks> <~/path/to/android-release-unsigned.apk> <KEY ALIAS>
|
||||
```
|
||||
|
||||
### Problem: Installing onto Android Device
|
||||
|
||||
Let's get it running on our Android once again, signed and ready to release.
|
||||
|
||||
`adb install ~/path/to/android-release-signed.apk`
|
||||
|
||||
#### Solution: Installing `adb`
|
||||
|
||||
`adb` can be installed from the Android Studio Preferences screen:
|
||||
|
||||
1. Appearance & Behavior > System Settings > Android SDK > SDK Tools
|
||||
2. Check Android SDK Build-Tools, Android SDK Platform-Tools, Android SDK Tools
|
||||
3. If `adb` still isn't available, correct your path like so: https://stackoverflow.com/questions/10303639/adb-command-not-found
|
||||
|
||||
Now running `adb install` on your apk will install directly to your device.
|
||||
|
||||
### Problem: zipalign
|
||||
|
||||
While uploading to the Play Store you may see a notice that the apk is not zipaligned.
|
||||
|
||||
#### Solution: zipalign it
|
||||
|
||||
Unfortunately this is not a tool we can install by itself, but it does come with Android Studio.
|
||||
|
||||
The command we desire to run is something like:
|
||||
|
||||
`zipalign -v 4 ~/path/to/file.apk ~/path/to/newfile.apk`
|
||||
|
||||
Replace `zipalign` with the path to it on your machine, likely under your android studio sdk directory.
|
||||
|
||||
---
|
||||
|
||||
Finally we have a **signed, zipaligned, releasable APK file ready for the Play Store**. Follow the prompts on the site and your app will hopefully be published within a day.
|
||||
|
||||
I encourage others to write about their experiences building apps for the Play Store. I'm sure there are simpler ways to achieve the same result with fewer headaches. Ultimately, having a published app on the Play Store is a very satisfying experience and this document will serve as a reminder of the trials I've been through in an attempt to inform others of the problems that may be encountered along the way with some solutions that worked for me.
|
||||
|
||||
Stuck with a similar project? Reach out to me on Twitter @SharpShark28
|
||||
|
|
@ -1,12 +1,13 @@
|
|||
---
|
||||
title: On Web Components
|
||||
date: 2019-01-23T18:57:41.634Z
|
||||
description: They're ready for the mainstream. Automation testable. Even IE11 compatible, mostly.
|
||||
date: 2019-01-23
|
||||
tags:
|
||||
- Tech
|
||||
description: >-
|
||||
They're ready for the mainstream. Automation testable. Even IE11 compatible,
|
||||
mostly.
|
||||
- Testing
|
||||
- Retrospective
|
||||
---
|
||||
|
||||
Components were designed to share reusable code within a project. Sometimes between projects. But, what if a projects' base technology is fundamentally different (Ember, React, Vue)? **Luckily all web apps speak Javascript and the DOM which is where native web components come in.**
|
||||
|
||||
## Hybrids (Web Component Framework)
|
||||
Loading…
Add table
Reference in a new issue