OSS Gate Workshop を開催するためにやったこと

先日 OSS GateWorkshop を懇意にしているスプーキーズという企業で社内向けに開催しました。 この記事では開催にあたり行った準備や参考にした情報などをまとめています。 OSS GateWorkshopに参加した人が、これから同じように社内向けに開催したり、 運営のメンバーになって進行役をやったりする時に役に立つと幸いです。

開催の様子についてはこちらを御覧ください。

labs.spookies.co.jp

筆者とOSS Gateとの関わり

私はOss Gate Workshopw@大坂(2017-02-25)にビギナーとして参加しました。 WorkshopでIssueを起票しOSS開発者の仲間入りをし、その後も継続してIssueの起票やPullRequestを行っています。 体験としてとても有意義なものとなったので、それをスプーキーズの勉強会にて発表しました。 ドキュメントをちょっと良くした程度のただのOSSの開発経験者です。 また、継続して交流を持つためにGitterに参加しています。

開催の日程

通常のWorkshopは5〜6時間のスケジュールで構成されています。 今回は社内向けの開催ということで就業後に自由参加で行っています。 そのため1度にそれだけの時間を確保するのは難しいため2回に分けて開催しました。

1日目では対象OSSを動かしてミニふりかえりを行ない、2日目ではそのOSSに対しフィードバックを行ないました。 タイムテーブルは以下のように構成しています。両日とも150分での構成です。

1日目

時刻	やること
19:00	開始
19:10	OSS Gate の紹介
19:20	アイスブレイク
19:35	OSS開発手順を説明
20:00	対象OSSを動かす
21:00	ミニふりかえり
21:30	終了

2日目

時刻	やること
19:00	開始 前回のおさらい
19:10	プロジェクトにフィードバックする
20:40	まとめ
20:50	アンケート記入
21:00	ワークショップのふりかえり
21:30	終了

進行するための準備

OSS Gate の目的を確認

OSS Gate を冠して開催するには本家の目的を理解しそれに沿った形で実施する必要があります。 これについてはオフィシャルサイトにOSS Gateへようこそ！というページがあるので熟読しました。 これにより自身の「Workshop楽しかったな、同じ思いをする人が増えるといいな」という思いも蘇ります。

過去のレポートを確認

Gitterで開催の旨を伝えたところこちらのレポートを紹介しもらいました。

oss-gate.github.io

同じように社内向けの開催でのレポートでした。こちらに目を通すことで全体の流れを再確認することができます。

進行の動画を確認

開催するためには自分が進行役を務める必要があります。 これが一番大変な部分ですし、成否がかかっているところでもあります。 なのでここに一番労力を使いました。

幸いYouTubeにOss Gate Workshopw@大坂(2017-02-25)の動画が公開されています。 今回はこちらの進行を真似しました。

www.youtube.com

動画をしっかり見ることも大事ですが、原稿があったほうが安心なので話していることを文字に書き起こしました。 10分の動画を書き起こすのに約1時間かかりましたが、そのおかげで話す内容が頭に入った感じがします。

書き起こしたテキストはこちらにあります。

使用するリポジトリ

本家のリポジトリをWorkshop参加時にクローンしているのでそれを使いました。 本家同様にIssueを起票するとデフォルトで入力されているので同じように使えます。 Workshopのふりかえりではアンケートを実施しますが、その結果を本家のリポジトリにPullRequestすることを想定していたので、それ用のブランチを用意しました。

使用するスライド

OSS Gate Workshopで使用するスライドは公開されておりいくつかの方法で利用できます。

• rabbit Slide Show
• gem

当日の進行はGemのスライドで行ないました。こちらのようなGemfileを用意してインストールして使用しました。 状況に合わせてrabbit Slide Showのスライドも使用しています。

読んでおけばよかったもの

本家のリポジトリで用意されているシナリオには開催・進行するためのいろいろな情報がまとめられています。 これを見落としていたのはもったいないことでした。

メンバー構成

ビギナーに対してサポーターが少ない状況での開催となってしまいました。 1日目は何もわからない状態のビギナーにいろいろと作業をしてもらう必要があります。 そのためサポーターの対応が不十分なためうまくいかないこともありました。 それについては後述します。

一方2日目は全員に慣れた感じもありビギナー、サポーター共に楽しめたようです。 初参加のビギナーもいましたが、うまくサポートをして後追いで作業をしてもらえました。

1日目

• 進行役(兼サポーター) 1名
• サポーター 1名
• ビギナー 6名

2日目

• 進行役(兼サポーター) 1名
• サポーター 1名
• ビギナー(連続参加) 2名
• ビギナー(初参加) 2名

Workshop のふりかえり

うまくいかなかったこと

OSS選定に時間がかかった、OSS選定がうまくいかなかたった

新卒社員のビギナーはまだOSSに馴染みが薄く「OSSってどんなもの？」という感じでした。 そのため選定に時間がかり、しかも動かしづらいOSSを選んでしまいました。 サポーターが少ないことが一因ではありますが事前に対策はできそうです。

ビギナーに合わせてサポートを優先的に行う

社内開催なので事前にだれにサポートが優先的に必要かが分かったように思います。

事前に OSS Gate の紹介だけを行う

事前に「対象OSSは何にしようかな」と考える時間を作ることもできそうです。

作業ログがうまく書けていない、少ない

通常のWorkshopのIssueとくらべて作業ログのコメント数が少なく感じました。 作業ログは多いほうが後のミニふりかえりがうまくいきやすいのでたくさん書いて欲しいです。 これも以下に対策。

デモの発表を充実させる

動画に倣い、ビギナーを指名して寸劇形式で作業ログの説明を行いましたが、うまくいきませんでした。 よく知っている間柄なので緊張感のないやりとりになり、うまく説明できません。 寸劇をするなら台本ありきでサポーターと演じたほうが良さそうです。 事前に伝えたいポイントを明確にしておかないと伝わらないと思いました。 下手な芝居よりきちんと説明を行ったほうが良かったです。

サポーターが少ない

アルバイトのメンバーがOSS開発者だったのでサポーターをしてもらえましたが、彼がいなければサポーター0名でした。 外部からサポーターを募っても良かったです。

座席がバラバラ

会議室などのスペースがないのでオフィススペースでの開催になりました。 そのためビギナーの横にサポーターが座るという体制は取れず、これもサポート不足の一因になっていたと思います。

途中で仕事をしてしまう

オフィススペースで行うと、周りには仕事中の人もいます。 プロジェクトの状態によってはWorkshopに集中できず仕事をしてしまう人もいました。 Workshopに集中できるように出来る限り隔離された空間で開催すべきだと思います。

仕事の都合で片方だけの参加になった

今回のケースでは1日目だけの参加者が不完全になってしまいました。 OSS開発参加へのハードルを下げることもできなかったような印象です。 一方で2日目だけの参加者はIssue起票までできたので、取り組みとしてはうまく行ったと思います。

社内開催なので今後はお互いにサポートしながらWorkshopの続きをできる可能性はありますが、本人たちの意志次第です。 事前に片方しか参加できないのが分かっているなら2日目を推したほうが良いかもしれません。

英語のサポートを強化したい

コミットメッセージの英語についてはこれとかこれのようなまとめがありますが、IssueやPullRequestの英語についてはあまりないようです。 人気リポジトリのIssueやPullRequestを巡回してまとめると人気者になれるチャンス!?

ビギナー同士のミニふりかえりは難しい

サポーターが少ないため、ミニふりかえりを1対1で行うことが難しいのは事前にわかっていました。 そこでビギナーをペアにしてそこにサポーターを付ける形でミニふりかえりを行いました。 サポーターがペアの1人とフィードバックポイントを探し、2人目はビギナー同士でフィードバックポイントを探す、というものです。 しかし、経験がないビギナー2人でフィードバックポイントを探すことは難しかったようです。

やはり最低限のサポートが必要だとわかりました。 なのでペアそれぞれのフィードバックポイントを1つずつ見つけるところまでをサポートし、それ以降はペアで議論しながらさらなるフィードバックポイントを見つける、という方法だとうまくいくかもしれません。 これは次回もチャレンジしたいことです。

うまくいったこと

普段とちがうコミュニケーションの形

サポーターがアルバイトメンバーということもあり、普段とは立場が逆転した光景がみられました。 アルバイトが役員に対しIssueの書き方をレクチャーするなど、新しいコミュニケーションが生まれていました。 後輩や新人が先輩をサポートする、というような光景は他の現場でも見られそうです。

社内のメンバーのことを知るきっかけの1つになった

OSSを選ぶところや作業ログの内容に個性がでるようで、普段とは違う面を見ることができました。 作業の合間の雑談で会話が弾んだりと、メンバー同士のことを知るいい機会になっていました。

継続したOSS開発参加ができそう

「OSSの日」というのを定期的に開催して、継続してOSSへ貢献しようという話が出ました。 こういう話題も社内開催だから出るのかな、と思います。今後にも期待したいところです。

GitHubを使うよい機会になった

普段はGitLabを使って開発を行っているので、ほとんどGitHubを使ったことのないメンバーもいました。 そのためGitHubを使う良い機会にもなりましたし、GitHubの使いやすさを肌身に感じたようです。

OSSに対する意識の変化

OSS開発への敷居は下げられたと同時に、OSSのIssueやPullRequestを見てみようという意識の変化も起こったようです。 こういう変化も今後のOSS開発参加への継続性には影響しそうです。

OSS開発参加者が増えた

これが一番の結果ですね。

個人的な感想・反省

進行で伝えるべき内容はもれなく話せたと思いますが、スライドの内容を全然把握してなかったので、話とスライドがズレズレだったところはだめだったところです。 サポーターからのアンケートではちゃんと指摘してくれていました。 とはいえアンケートでは皆さん満足してもらえたようで、開催してよかったなと思います。こういうフィードバックがあるから勉強会やコミュニティの運営ってできるのかなと思いました。

今後について募集

今回は社内開催でしたが今後はオープンなWorkshopとして京都で継続的に開催したいと思っています。 会場の提供やサポーターの参加など協力してくれる方を募集しています。 今回と同じように社内開催をしてほしいというご相談もあれば賜ります。

TwitterやBlogのコメントでご連絡ください！

twitter.com

スプーキーズの開発合宿に参加してきた

3月下旬に淡路島で行われたスプーキーズの開発合宿に参加してきました。 合宿所はこちらのLa Terrasse Awajiで、とても広くて美しい素晴らしい施設でした。

合宿の目的はこちらの2つ。

• メンバーと仲良くなる
• ボードゲームを作る

合宿を通じてメンバー同士が普段とは違ったコミュニケーションをとり親睦を深めること、その中で生まれる発想や試行錯誤をボードゲームという成果に落とし込むことの2つを目指しての2泊3日でした。

とまあ、合宿の詳しい内容はオフィシャルブログに譲るとして合宿の様子を写真中心で紹介しようと思います。

合宿所に到着。きれいなエントランスです。

早速メンバーが集まって今回の趣旨の説明。

自己紹介をして和やかなムード。

僕はガジェットが好きなんですよ。

僕はロクロを回すんですよ。

4人✕3チームに分かれてボードゲームを作りますよ！

さて、どうしようか。

コマ使うやつとか。

議論も白熱します。

とりあえずボードゲームで遊びますか。

えー、まじでー。

山盛りいちごで休憩。

薪がなくて使えなかった暖炉。

外はあいにくの雨模様。

廊下の奥には

きれいなベッドルーム。

ちょっと1人で考え中。

そろそろ夕食に行きますよ〜。

なんだか楽しそう。

淡路の海の幸、山の幸

夜が更けても煮詰まらない！

やっと形になってきたか！？

我々はもう出来たのでカタンで遊びますよ。

翌朝チームごとに制作したゲームを発表してテストプレイ。

プレゼンを聞く方も真剣。

コマを使ったパズルゲーム！！

頭をつかうゲームなのか！?

こちらのチームはアイドルがモチーフのよう。

次のチームはカードとチップを使ったゲーム

絵のクオリティが。

盛り上がってます！

ここで第一部が終了。 各人がおもしろいと思ったボードゲームに投票し、優勝チームにはご褒美となりました。

お昼休みを挟んでチーム替え。3人✕4チームに分かれて第二部の開始！

夜はデッキでバーベキュー！

食後に最後のプレゼンです！

盛り上がってますね。

第二部はカードゲームが多いようです。

優勝おめでとう！ このあと夜遅くまで宴会＆ボードゲームパーティーが続くのでした。

合宿おつかれさまでした！

Bash初心者から初級者へのステップアップするためのTips10選

CLIでいろいろとコマンドは使っているんだけど、bashスクリプトが書けるかというと・・・。 という人がbashの文法や機能を知って初級者へとレベルアップするためのTipsを紹介します。

1. ${変数}

シェルで変数を保持することができます。変数には文字列や数値を代入することができ、値を参照する場合は変数名の前に$を付けます。変数値は $VAL でも ${VAL} でも同じように参照出来ますが ${} の方が可読性も上がるのでおすすめです。

$ A=10
$ echo ${A}
10

変数に代入する時 = の前後にスペースを入れてはいけません。変数がコマンドとして解釈されてしまいます。

$ B = 10
bash: B: command not found

bashのバージョン4では ${VAL^} で単語の先頭を大文字に、 ${VAL^^} で単語全体を大文字に変換してくれます。

$ A='hello world'
$ echo ${A}
hello world
$ echo ${A^}
Hello world
$ echo ${A^^}
HELLO WORLD

変数の値は基本的にテキストとして扱われますので一般的なプログラミング言語のように四則演算はできません。

$ A=10
$ B=15
$ echo ${A} + ${B}
10 + 15

この様な場合は後述する算術式展開 $(( 計算式 )) を使います。

2. while read n; do [command] $n; done

パイプから受け取った標準入力を1つずつ変数に保持して引数として別のコマンドに渡したい。そんな時によく使う方法が while read ... のイディオムです。 X.txt Y.txt をそれぞれ X.txt.bak Y.txt.bak との差分をみたい場合、ワンライナー（1行スクリプト）で書くとこのようになります。

$ ls *.txt | while read f ; do diff ${f} ${f}.bak; done

# 通常の書き方
$ ls *.txt |
while read f
do
  diff ${f} ${f}.bak
done

ls の出力を1行ずつ読み込み変数 f に保持し diff コマンドの引数として与えています。 羊を100匹数える場合はこのようになります。

$ seq 100 | while read n; do sleep 1 ; echo "羊が${n}匹"; done

3. $(( 計算式 )) 算術式展開

$(( 計算式 )) は算術式展開と呼ばれるbashの機能でいろいろな計算ができます。四則演算はもちろんのこと論理積、論理和などのビット演算もできます。

#　四則演算
$ A=10
$ B=15
$ echo $(( ${A} + ${B} ))
25
$ echo $(( ${A} * ${B} ))
150

# べき乗
$ echo $(( ${A} ** ${B} ))
1000000000000000
$ echo $(( 2 ** 16 ))
65536

# modulo
$ M=$(( ${A} % ${B} ))
$ echo ${M}
10
$ echo $(( 13 % 8 ))
5

# 論理積
$ echo $(( 15 & 4 )) # 1111 と 0100 の論理積
4

# 論理和
$ echo $(( 10 | 5 ))　# 1010 と 0101 の論理和
15

# 排他的論理和
$ echo $(( 13 ^ 11 )) # 1101 と 1011 の排他的論理和
6

4. || && 終了ステータス判定

コマンドはその動作が成功すると「終了ステータス」として0を返します。失敗すると0以外の数字が返ります。直前のコマンドの終了のステータスは $? 変数に保持されます。

# wget コマンドの例
$ wget 'http://google.co.jp' 2> /dev/null
$ echo ${?}
0
$ wget 'http://foo.bar.baz.co.jp' 2> /dev/null
$ echo ${?}
4

0は成功のステータス、 4は失敗のステータスで Network failure. の意味です。 2> /dev/null で標準エラー出力を捨てて表示されないようにしています。

&& や || はこの終了ステータスを判定するbash演算子です。&& で成功した時の処理、|| で失敗した時の処理を書きます。

$ wget 'http://google.co.jp' 2> /dev/null && echo 'success!' || echo 'failure...'
success!
$ wget 'http://foo.bar.baz.co.jp' 2> /dev/null && echo 'success!' || echo 'failure...'
failure...

gerp は何かがパターンマッチすれば0を、何もマッチしなければ1を返します。そこで || 演算子を使うと処理を分岐することができます。

$ ls -aF | grep 'git' || echo 'no git file or dir'
no git file or dir


$  ls -aF | grep 'git' || echo 'no git file or dir'
.git/
.gitignore

5. -- オプションの打ち止め

-Rf や ~ というようなディレクトリが何かの拍子にできてしまいまった場合どうすればよいでしょうか。

$ ls -F
-Rf -f/ ~/

まちがっても $ rm -Rf ~ なんてコマンドを打ってはいけません。 -Rf はオプションとして解釈されてしまいます。このような場合は -- を使います。-- は特別な引数でそれ以降のオプションが打ち止めとなります。

$ rm -- -Rf
$ rmdif -- -f

~ は通常ホームディレクトリと解釈さるので、 -- を利用しても意味がありません。シングルクォートでくくる、\ でエスケープする、./ でカレントディレクトリを明示するなどが必要です。

$ rm '~'
$ rm \~
$ rm ./~

6. ヒアドキュメント

複数行のテキストをプロセスの入力にします。 << 終了文字列 を記述し複数行の文字列を入力後に 終了文字列 を記載すると入力終了の合図となります。

$ cat -n << EOF
I have a pen.
I have a apple.
EOF
     1 I have a pen.
     2 I have a apple.

標準入力に流し込むので echo ではなく cat で出力しています。この出力をリダイレクトやパイプに渡す場合は、1行目に書く必要があります。

# 出力をリダイレクト
$ cat << EOF > output.txt
I have a pen.
I have a apple.
EOF

$ cat output.txt 
I have a pen.
I have a apple.

# パイプで渡す
$ cat << EOF | jq
[{
"name":"Matz","age":51,"from":"Japan"},
{"name":"Dhh","age":36,"from":"Denmark"}
]
EOF
[
  {
    "name": "Matz",
    "age": 29,
    "from": "Japan"
  },
  {
    "name": "Dhh",
    "age": 36,
    "from": "Denmark"
  }
]

標準入力に流し込むので while イディオムの入力としても利用できます。

$ while read n; do echo $(( ${n} * 2 )); done << EOF
1
2
3
4
5
EOF
2
4
6
8
10

7. <<< ヒアストリング

<<< の右側に書いた文字列や変数の値をコマンドの標準入力に流し込みます。 ヒアドキュメントと同じように扱えます。パイプとリダイレクトも通常通り利用できます。

$ cat <<< 'Hello World!!'
Hello World!!

$ JSON='[{
"name":"Matz","age":51,"from":"Japan"},
{"name":"Dhh","age":36,"from":"Denmark"}
]'

# パイプ |
$ jq . <<< ${JSON}} | grep -i 'matz'
    "name": "Matz",

# リダイレクト >
$ jq .[].name <<< ${JSON} > name.txt
$ cat name.txt
"Matz"
"Dhh"

8. $( コマンド ) コマンド置換

コマンドの実行結果を文字列として利用するための機能です。 コマンドの引数として展開したり引数に保持したりします。

# dateコマンドの結果が文字列に展開される
$ JSON="{\"time\":\"$(date +%s)\"}"
$ echo $JSON
{"time":"1489992386"}

# yamlファイルだけを抽出して処理
$ for f in $( find . -type f | grep '\.yml$' )
do
    [command] ${f} # 何らかの処理
done

9. $(< ファイル )コマンド置換

コマンド置換の拡張的な機能でファイルの中身に置き換えられます。

# cpコマンドを使わずbashの機能だけでファイルをコピー
$ echo "$(< /tmp/foo )" > /tmp/foo.bak

コマンドの処理結果を一時ファイルに保持することで可読性が向上します。

$ find . -type f | grep '\.yml$' > /tmp/yaml.list.txt
$ for f in $(< /tmp/yaml.list.txt )
do
    [command] ${f} # 何らかの処理
done

10. <( コマンド ) プロセス置換

コマンドの入出力をファイルとして扱う機能です。引数にファイルを受け取るコマンドの入力として利用できます。

# cat は引数としてファイルを受け取る
$ cat -n <( echo 'Hello World' ) <( echo 'Dreams come true' )
     1 Hello World
     2 Dreams come true

# ファイルリストの差分を diff で得る
$ ls
a.txt      c.txt      e.txt      h.txt       j.txt      l.txt      o.txt      q.txt
a.txt.bak  c.txt.bak  f.txt      i.txt       j.txt.bak  m.txt      o.txt.bak  q.txt.bak
b.txt      d.txt      g.txt      i.txt.bak   k.txt      n.txt      p.txt      r.txt
b.txt.bak  d.txt.bak  g.txt.bak  index.html  k.txt.bak  n.txt.bak  p.txt.bak  r.txt.bak

$ diff <( ls | grep '.txt$' | cut -d. -f1 ) <( ls | grep '.txt.bak$' | cut -d. -f1 )
5,6d4
< e
< f
8d5
< h
12,13d8
< l
< m

シェルプログラミング実用テクニック 入門bash 第3版 ソフトウェアデザイン 2016年 06 月号 ソフトウェアデザイン 2017年 01 月号

2017年の目標

年始からいろいろと考えていたことをまとめるためにも今年の目標を書き出します。

セルフブランディング

Rubykaigi2016に参加したことで改めて個人として活躍するには必要なことだと感じた。 まずは情熱プログラマーにもあるように「Googleで検索し最初の4ページのリンクだけを見てどんな人物だと想像するだろうか」という部分に注視して見ようと思う。 情熱プログラマーは改めて読むとほんとに良い本だ。

コミュニティでの登壇

勉強会やカンファレンスで登壇する。 3年後にはRubykaigiに登壇することを目指す。 オリンピックイヤーか・・・。

ブログ

Qiitaも含めてアウトプットを増やす。 最低でも月1回は書く。

OSSにコミット

GitHubでPullRequestを送る。 今年こそ！！

シェルプログラミング

シェル芸から入って bash が面白くなってきたのでシェルプログラミングでいろいろ出来るようになる。

Elixir

途中で止まってしまったプログラミングElixirをちゃんと読む。 演習問題もちゃんとやって手を動かす。

運用・監視まわり

Mackerelで独自のメトリクスを取りたい、という課題があるのでちゃんと勉強して達成する。 あわせてFuluentdとか使ってログ解析も出来るような基盤を考える。

新春bash書き初めをやった

SoftwareDesignの2017/1号の第1特集である新春bash書き初め シェル30本ノックをやった。
結果は 19/30 でまぁまぁの出来だと思う。
コマンドやbashについていろいろと新しい発見があったのでまとめておく。

各問題の自分なりの回答は GitHub においてある。
雑誌はこちら

コマンドについて

sed awk

抽出や変換など知れば知るほどなんでもできそうなコマンド。

• sed -n '/開始パターン/,/終了パターン/p'
• sed 'p' | sed '1d;$d' | paste
• awk '{print}{fflush()}'

while read n; do [command] $n; done

繰り返しのイディオムで頻出。xargs とうまく使い分けよう。

openssl

暗号関連のいろんなことができるコマンド。使うことはほとんどなさそう。

crontab

コマンドというか @reboot コマンド で起動時に1度、指定のコマンドを実行するという設定ができることを知った。

grep

grep -q . とすると、マッチの有無で終了ステータスが変わるので処理を分岐できる。
$ (何らかの処理) | grep -q . && (出力がある場合の処理) || (出力がない場合の処理) と出来る。
-q は標準出力に何も出さないオプション。

paste

それぞれのファイルの行を並列に結合する。

$ paste file1 file2
file1の1行目 file2の1行目
file1の2行目 file2の2行目
...

標準入力も扱える。

$ seq 1 10 | paste - -
1   2
3   4
5   6
7   8
9   10

file

ファイルの種類を推定してくれるコマンド。

tee

標準出力に出力しつつ、内容をファイルに保存する。
リダイレクトでは特権(sudo)が必要なファイルは書き込めないためteeを使うとうまくいく。
$ echo 'foo bar' | sudo tee special_file.txt

rev

反転してくれる。

$ seq 1 10 | xargs
1 2 3 4 5 6 7 8 9 10
$ seq 1 10 | xargs | rev
01 9 8 7 6 5 4 3 2 1

[

test コマンドの別名。if [ xxxx ]; でよく使われるのでオプションを覚えたほうが良い。

set env

set は現在のシェル変数、 env は環境変数のみを出力する。

bashについて

${変数}

変数へ代入する時はスペースを入れてはいけない。
変数を使う時は$をつける。

$ n='hello world'
$ echo ${n}
hello world

|| && 終了ステータス判定

直前に実行したコマンド(処理)の終了ステータス($0)を判定するbash演算子。
$ コマンド && コマンドが成功した時の処理 || コマンドが失敗した時の処理

<<< 標準入力へ流し込む

<<< の右側に書いた文字列や変数の値を標準入力に流し込む。

$ cat <<< 'hello world'
hello world
$ cat < 'hello world'
bash: no such file or directory: hello world

$(( 計算式 )) 算術式展開

いろいろな計算ができる。四則演算はもちろんのこと、論理和、論理積、ビット演算も可能。

$ echo $(( 2 * 3 + 4 ))
10

$( コマンド ) コマンド置換

コマンドの実行結果を文字列として扱える。

$ for n in $( seq 1 5 ); do echo "羊が$n匹"; done
羊が1匹
羊が2匹
羊が3匹
羊が4匹
羊が5匹

:- 変数展開

難しいのでこちら。
デフォルト値への置換ができる。

--

オプションの打ち止め。 $ mkdir -- -RF で -RFというディレクトリが作成される。--以降はオプションと認識されなくなる。

$(<ファイル) コマンド置換2

コマンド置換の拡張的な機能で「ファイル」の中身に置き換えられる。

$ echo "$(<ファイル)" > foo は$ cp ファイル foo と同じ。

<( コマンド ) プロセス置換

コマンドの入出力をファイルとして扱うことが出来る。

$ cat < <(echo 'hello world')
hello world

さいごに

各コマンドやbashの詳しい使い方や実例は雑誌を読んでくれ。