CSS リストを横並びにする

html 例

  <ul class="menu">
    <li>index</li>
    <li>images</li>
    <li>movies</li>
    <li>maps</li>
  </ul>

css

ul.menu {
  list-style: none;
}

ul.menu li {
  display: inline-block;
}

以前は float でブロック要素を並べていたけど、いまは inline-block
古いブラウザではうまくいかないかもしれないので注意

li 要素と li 要素の間に改行コードがあるので隙間ができる
この隙間を解消する方法もいろいろあるらしい

セカンドユーザーの zcompinit

Mac + Homebrew をマルチユーザーで使ってて、 セカンドユーザーでターミナル立ち上げたら zcompinit が insecure だ何だって警告してくるのがすごくイヤでちょっと調べてみた

警告が出る理由

  • brew がインストールしたファイルの owner は root ではなく brew したユーザー
  • つまり、brew でインストールされた補完関数の owner も root ではなく別ユーザー
  • compinit のセキュアチェックは root か自分自身以外が編集できる状態だと警告を出す

解決方法

解決方法は2つ

  1. compinit がロードする補完関数の owner を root に変更する
  2. セキュアチェックを無視(-u)、またはセキュアでないものはいれない(-i)

brew 管理下にあるファイルの owner を変更したら、今度は brew がごちゃごちゃしてくるので後者を選択

zplug で compinit されていたので $ZPLUG_HOME/repos/zplug/zplug/base/core/load.zsh を修正して compinit に -u オプションを追加

...
    # Plugins with defer-level set
    source "$_zplug_cache[defer_1_plugin]"
    compinit -u -d "$ZPLUG_HOME/zcompdump"
    if (( $_zplug_boolean_true[(I)$is_verbose] )); then
        __zplug::io::print::f \
            --zplug "$fg[yellow]Run compinit$reset_color\n"
    fi
    source "$_zplug_cache[defer_2_plugin]"
    source "$_zplug_cache[defer_3_plugin]"
...

ちとめんどう

補足

compinit のオプションに関しては以下を参考

# The -C flag bypasses both the check for rebuilding the dump file and the
# usual call to compaudit; the -i flag causes insecure directories found by
# compaudit to be ignored, and the -u flag causes all directories found by
# compaudit to be used (without security checking). Otherwise the user is
# queried for whether to use or ignore the insecure directories (which
# means compinit should not be called from non-interactive shells).

(引用) https://github.com/zsh-users/zsh/blob/master/Completion/compinit

zshrc ダイエット

zsh の設定とかに時間を食いつぶされたくなくて zshrc をスリムにしてみた

#
# zplug
#

export ZPLUG_HOME=~/.zplug
source $ZPLUG_HOME/init.zsh

# zplug self manage
zplug 'zplug/zplug', hook-build:'zplug --self-manage'

# history
zplug "zsh-users/zsh-history-substring-search"

# autocomplete
zplug "zsh-users/zsh-autosuggestions"
zplug "zsh-users/zsh-completions"

# syntax highlighting
zplug "chrissicool/zsh-256color"
zplug "zsh-users/zsh-syntax-highlighting", defer:2

# theme
zplug "mafredri/zsh-async", from:github
zplug "sindresorhus/pure", use:pure.zsh, from:github, as:theme

# install plugins
if ! zplug check --verbose; then
    printf "Install? [y/N]: "
    if read -q; then
        echo; zplug install
    fi
fi

# load plugins, and add commands to $PATH
zplug load --verbose


#
# zstyle
#

zstyle ':completion:*' menu select


#
# history settings
#

HISTFILE=$HOME/.zsh_history
HISTSIZE=1000
SAVEHIST=10000


#
# aliases
#

alias ls="ls -G"
alias la="ls -a"
alias ll="ls -lh"


#
# rbenv
#

if [ -e "$HOME/.rbenv" ]; then
  eval "$(rbenv init - zsh)"
fi

zplug は brew ではなく curl や git clone で ~/.zplug へインストールする
マルチユーザで Mac 使うと zplug の log ファイルのアクセス権でめんどうなことになったから

ボクノ Git チートシート

Git を使用していて「どうするんだっけ?」と思ったことをどんどん追記していく

リポジトリの状態に戻す (変更をなかったことにする)

% git checkout <filename>

ディレクトリを指定すると、まとめて戻せる

% git checkout .

ローカルで作ったブランチをリモートに push する

% git push --set-upstream origin <branchname>

削除されたリモートブランチをローカルに反映させる

% git fetch --prune

ローカルブランチは削除されないので、不要であればローカルブランチを削除する

ブランチの削除

% git branch --delete <branchname>

stash

% git stash

stash リスト

% git stash list

stash 適用

% git stash apply <stash>

stash 削除

% git stash drop <stash>

stash 適用 & 削除

% git stash pop <stash>

RSpec の基本的な使い方

最近、RSpec を学習していたので調べたことまとめ

まずは

おそらくここが正式なドキュメントサイト
(参考) RSpec: Behaviour Driven Development for Ruby

RSpec の初期設定


% bundle exec rspec --init
  create   spec/spec_helper.rb
  create   .rspec

テストプログラムは作成された spec ディレクトリに配置するのが基本

テストプログラム


テストプログラムのファイル名はテスト対象のファイル名に "_spec" をつけるのが慣例ぽい (例: hello.rb => hello_spec.rb)
テストプログラムは単に spec と表現されるのをよく見る
以下、簡単な spec の例

require 'hello'

describe 'Hello#message' do
  it 'returns hello message' do
    expect(Hello.new.message).to eq 'Hello World!'
  end
end

describe/context/example/it を利用してテストケースをグループ分けしていく
(参考) RSpecの(describe/context/example/it)の使い分け

テスト対象のロードについて

テスト対象の require をどこに記述すればよいのかしばらく悩んでいた

結論

各 spec ファイルに require 'spec_helper' は記述しない
各 spec ファイルの先頭でテスト対象モジュールを require する
モジュールのパスに変更があったときは -I オプションを指定して $LOAD_PATH を変更することで対応する

経緯

spec_helper.rb に記述して一括管理するのがよい?
こうすると、モジュールのディレクトリ変更でパスが変わり、全 spec ファイルを修正することになるリスクを減らせるかもしれない
しかし、この方法だと部分的なテストを行うときに全モジュールをロードするのが負担にならないか?

ちなみに RSpec はデフォルトで lib と spec を $LOAD_PATH に追加する
なので lib 配下のファイルはパスなしでよい (例: lib/hello.rb => require 'hello')
(参考) RSpecコードリーディング(第1部:RSpec)

各 spec に require 'spec_helper' を記述しない方がいいという意見も見かけた
その場合は、.spec ファイルに以下のデフォルトオプションを追加する

--require spec_helper

試してみようとしたら rspec --init で作成されたデフォルトの .spec にすでに記述されていた

http://rspec.info の Let's get started! を見ると、spec で require 'spec_helper' しないし、かわりにテスト対象モジュールを require してるから、それが想定している基本的な使い方なのだろう

いろいろあさっていたら、3.5 で config.when_first_matching_example_defined が追加されたから、一部の spec でしか使用しないセットアップロジックはこれ使うといいよ、という旨の記事をドキュメントサイトのブログで見つけた
(参考) RSpec 3.5 がリリースされました!

まだ勉強段階なので必要ないけど、今後必要になるかもしれない
頭の片隅に置いておこう

Bundler の基本的な使い方

Bundler のインストール

% rbenv exec gem install bundler
% rbenv rehash
% bunder -v

rbenv rehash はコマンドプログラムの更新
rbenv のヘルプには次のようにある

Rehash rbenv shims (run this after installing executables)

Bundler で gem をインストールする

Gemfile を作って編集し bundle install

% bundle init
% vi Gemfile
% rbenv exec bundler install

すると Gemfile.lock ファイルが作成される


注意!ここから先は未確認・未検証!

別環境で gem をインストールする

% rbenv exec bundler install

Gemfile.lock が存在し Gemfile が更新されていなければ Gemfile.lock に従う (Gemfile.lock は更新されない)
Gemfile.lock が存在し Gemfile が更新されている場合、更新された gem に対して依存性の再解決を行う

以下、bundler install のヘルプより引用

Install the gems specified in your Gemfile(5). If this is the first time you run bundle install (and a Gemfile.lock does not exist), Bundler will fetch all remote sources, resolve dependencies and install all needed gems.

If a Gemfile.lock does exist, and you have not updated your Gemfile(5), Bundler will fetch all remote sources, but use the dependencies specified in the Gemfile.lock instead of resolving dependencies.

If a Gemfile.lock does exist, and you have updated your Gemfile(5), Bundler will use the dependencies in the Gemfile.lock for all gems that you did not update, but will re-resolve the dependencies of gems that you did update. You can find more information about this update process below under CONSERVATIVE UPDATING.

インストールされている Gem を更新する (version up)

% rbenv exec bundler update

このとき Gem のバージョンが変わると Gemfile.lock が更新される