『アジャイルサムライ』を読んだ

アジャイルサムライ――達人開発者への道

アジャイル宣言の背後にある原則に沿う形で、実践的なアジャイル開発を学ぶことができる。

所感

まず、軽妙でユーモアたっぷりの語り口が読みやすかった。イラストも多く、ページ数の割にはさらっと読めた。

具体的な手法もたくさん紹介されているが、アジャイルで一番大事なことは、お客さんにとっての価値・満足を最優先し、チーム一丸となって動くソフトウェアを早く継続的に届けることだと思った。

わかったこと

アジャイルとは

アジャイルは、ソフトウェア開発の進め方のひとつであり、チームの力を最大限引き出すことでプロジェクトを成功に導く有用な手法である。ただし、実際に現場で実践するときには「アジャイルになっているかどうか」は重要ではない。

やり方はひとつではなく、チームやプロジェクトによって異なるものだ。大事なことは、顧客と誠実に話し、みんなで同じ方向を向いて協力すること。そして、毎週成果として動くソフトウェアを届けること。「やり方」の部分に Must はないので、日々のミーティングなどで率直に意見を出し合って試行錯誤しながら、チームに合ったやり方を見つけることが大切。

現実から目を背けず、顧客に誠実に向き合い、顧客を巻き込んでプロジェクトを進める。

アジャイルチーム

アジャイルチームのメンバーは、肩書きや役割分担にとらわれず、チームの役に立つことなら何でもやる。工程ごとに担当を分けたりせず、チーム一丸となって責任を果たす。

自己組織的なチームにするために、アジャイルプロジェクトを始める前にゴールやビジョンについてチームでよく話し合ったほうがよい。インセプションデッキは、プロジェクトについての考え方を共有するのに役立つ。

アジャイルな計画

プロジェクト開始前の見積もりは、当てずっぽうに過ぎない。顧客にも説明し、理解してもらう必要がある。計画と現実が離れていったときは、計画のほうを変更する。

タスクの大きさは、相対的な「ポイント」で見積もる。

「要件」を信用せず、プロジェクト後期に変更があっても歓迎する。ただし、期日や費用が変わらない限りにおいて、やることをひとつ増やしたら、ひとつ削除する。

プロジェクトが実際に始まってしばらくしたら、チームのベロシティ（1イテレーションでこなせる仕事量）がわかるので、バーンダウンチャートなどを用いてプロジェクト完了の見通しが立てられる。

アジャイルに不可欠なプラクティス

アジャイル開発では、ユニットテスト、リファクタリング、テスト駆動開発、継続的インテグレーションが欠かせない。技術的負債を減らし、シンプルで変更しやすいコードをいつでもリリース可能な状態にしておく。

ブログ連続投稿180日の記録

2020年4月14日から、1日1記事投稿を続けてきて、今日で180日。引っ越しのためネットが使えないことが事前に分かっていた日を除いて、基本的にその日に記事をひねり出してアップしていた。

4月から無職で、毎日長時間 Mac に向かっているので、ものすごく大変だったというわけではないが、ネタ探しに苦労したことは多かった。毎日勉強してはいるのだが、1日インプットした日や、ハマって何も解決できなかった日は、ブログに書けるようなことがないから。

ブログというより、プログラミングの勉強、180日間1日も休まずに続けてきたんだな〜

やっぱりプログラマになりたいからこれからも毎日やるだろう。

先日書いたとおりブログをやめるわけではないが、180日間続けた記録を残しておきたいと思ったので、ここに。

1記事当たり10人以上も見てくれたのか〜

最初の頃はアクセス数 0 の日も珍しくなかったことを思うとすごい。

読者登録してくれた方もいて、ありがとうございます。

特に誰からも聞かれたことはないが、ブログのタイトルは、「ロックっぽい」感じにしたくて、適当につけた。ロック好きなので。適当といっても数日考えたと思う。他人にダサいと言われても、自分ではかっこいいと思ってるからOK！

決める直前にググってみたら、似たようなタイトルのぶっそうな曲があることがわかったが、まぁいいか〜ということで。

今後しばらくは Scrapbox メインに試行錯誤していく予定。Scrapbox に書いたことをブログ記事としてまとめるのを何回か実践してみたら、いい感じだったので今後もやっていきたい。

scrapbox.io

Ruby paizaレベルアップ問題集（文字と整数の組のソート2-4）

paizaラーニング（初心者〜中級者向けのプログラミング学習サービス）の問題集をやってみる。

paiza.jp

共通ルール

入力

• 入力値最終行の末尾に改行が１つ入ります。
• 文字列は標準入力から渡されます。

出力

• 最後は改行し、余計な文字、空行を含んではいけません。

7. 文字と整数の組のソート2 (paizaランク C 相当)

1行目に行数を表す整数 n、続く n 行の各行で「文字」と「整数」の組が空白区切りで入力されます。
n 個の組について、「文字」の値が同じ組同士の数値を足しわせてまとめ、まとめた数値の降順で、文字とまとめた数値の組を出力してください。

入力される値
n
S_1 D_1
S_2 D_2
...
S_i D_i
...
S_n D_n

S_i は「文字」で、D_i は「整数」です。

期待する出力
文字とまとめた数値の組を各行で出力してください。

条件
・1 ≦ n ≦ 10,000
・-10,000 ≦ D_i ≦ 10,000 (ただし、1 ≦ i ≦ n)
・S_iは1つの半角英文字

入力例

7
A 1
D 6
C 2
G 4
B 70
A 10
B 5

出力例

B 75
A 11
D 6
G 4
C 2

自分の解答

n = gets.to_i
hash = {}
n.times do
  k, v = gets.split
  hash[k].nil? ? hash[k] = v.to_i : hash[k] += v.to_i
end
ary = hash.sort_by { |key, value| value }.reverse
ary.each do |k, v|
  puts "#{k} #{v}"
end

ハッシュのキーに重複がある場合、以下のように単純にハッシュを作ると上書きされていって思うような値にならない。

# 入力例が入力された場合
n = gets.to_i
hash = {}
n.times do
  k, v = gets.split
  hash[k] = v.to_i
end
p hash
#=> {"A"=>10, "D"=>6, "C"=>2, "G"=>4, "B"=>5}
# 上書きされている

そのため、キー（k）がない（nilである）ときはそのまま値（v）を代入し、キーがすでに存在する場合は値を足すようにした。

hash[k].nil? ? hash[k] = v.to_i : hash[k] += v.to_i

Enumerable#sort_by (Ruby 2.7.0 リファレンスマニュアル)

Ruby ハッシュのソート - masuyama's notes (Scrapbox)

Scrapbox の画面を黒くする

9月末から使い始めた Scrapbox。ターミナルとかエディタ（VSCode）をダークテーマにしているので、一緒に開くことが多い Scrapbox も黒っぽくしたくなった。（ブログだけはずっと白いのだけど…）

Scrapbox には、たくさんテーマが用意されている。

黒系は2種類。自分は緑色が好きなので、Hacker 2 にしてみた。

適用してみてわかったのだが、メモの中身は黒くならない…。

Hacker 2 デフォルト

うーん、悪いわけじゃないけど、黒くする方法はないのかと調べたら、UserCSS というのを使って、CSS をカスタマイズできることがわかった。

そして、Scrapbox の開発者の方が、ページ背景を黒くする UserCSS を公開してくれていた。

scrapbox.io

Hacker 2 に Dark Editor CSS を適用

CSS の中身としては、ページ部分の色を反転させて、文字の太さを太くしている。

これでよし！となりたかったが、カスタマイズできるとわかるとどうしてもカスタマイズしたくなってしまうもの。

オリジナル CSS 適用

CSS を見ればわかるが、主に以下のような点を変更した。

• 文字の太さを元（デフォルトと同じ）に戻す
• ページの背景色を若干明るくして、コードブロックとの差をわかりやすく
• コードブロックのファイル名やテーブルのタイトルの色を変更して読めるように
• 関連リンクのラベルが白のままだったので黒に変更

単純だけど、自分好みの色になっただけでテンション上がる〜！よければご自由にカスタマイズをどうぞ（また変更してるかもしれないのでその点はご了承ください）。

https://scrapbox.io/masuyama13/settings

命名規則（キャメルケースとかケバブケースとか）

Vue.js の勉強を始めたら、キャメルケースとスネークケース以外にもいろいろな表記ルールがあることを知ったのでまとめておく。

変数名などに複数の単語を組み合わせた名前をつけたいとき、変数名には基本的にスペースを入れられないので、単語の区切りを何で表現するかというルールがいくつかある。

hello world という名前をつけたい場合を考える。

キャメルケース

単語の頭の文字を大文字で表記。全体の先頭の文字は、大文字の場合と小文字の場合とがある。キャメル（camel）はラクダのこと。

HelloWorld, helloWorld

アッパーキャメルケース、パスカルケース

先頭が大文字のキャメルケース。Ruby のクラス名など。

HelloWorld

ローワーキャメルケース

先頭が小文字のキャメルケース。JavaScript の変数名など。

helloWorld

スネークケース

単語の区切りを_アンダースコアで表記。Ruby の変数名など。

hello_world

Ruby の定数のように全て大文字のものは、アッパースネークケースやスクリーミングスネークケース、コンスタントケースと呼ばれる。

HELLO_WORLD

ケバブケース、チェインケース

単語の区切りを-ハイフンで表記。HTML の class 名など。-で単語をつなぐのが、串に刺した肉の「ケバブ」のようだというのが由来らしい。

hello-world

詰まったときどうするか

今 Vue CLI で SPA（シングルページアプリケーション）を作る課題をやっていて、絶賛詰まり中。

勉強していると、「どこから手をつけたらいいかわからない」、「どんなプログラムを書いたらいいのか見当もつかない」ということがよくある。ググろうにも、どんな検索ワードが適当なのかわからない。

それで、自分よりもっと初心者の人に質問されたという状況を想像して「詰まったときどうするか？」を客観的に考えてみた。

そういう状況の脱出方法は人によってさまざまだと思うが、今の自分が手探りでやっていることを書き記しておく。数ヶ月前の自分が読んだら参考になると思う。そして数ヶ月後か数年後の自分が読み返したら面白いと思う。

大きい問題は小さく分割

とにかくまずはこれ。プログラマを目指して勉強を始めてから何度かそういう話を耳にしながらも、自分事として考えるようになったのは「角谷トーク」を聞いてから。今はこれを常に自分に言い聞かせている。

大きい問題をできる限り小さく分割して一つひとつクリアしていく

• 紙のノートにわかっていること、わからないことを書き出す
  • わからないことを小さく小さく分割して、どこがどうわからないか人に説明できるように考えてみる
  • 考えたら、調べてみる
  • 調べてもわからなかったりできなかったりしたら、人に聞く

違う視点から考えてみる

人に聞くことの効果の一つは、「違う視点」を得られることかもしれない。独学しているのだとしたら、以下のように考えてみるのもいいかも。

• 自分以外の他人になりきって問題を考えてみる
• 困っている自分にアドバイスする側になりきってみる
• 問題に対する知識を一旦リセットしてみる
  • 余計な知識が邪魔をしていることがある
  • 前提を勘違いしていることがある（自分の経験上、これが多い）
  • できていないと思い込んでいるだけで実はできていることがある

ベテランでも「何がわからないのかわからない」状況になることはあるので、それほど深刻に考えない。寝て起きたら前進することも。

「はいはい、わからないわからない、ワロスワロス」
わからないときの心持ちについて - komagataのブログ

komagata さんのブログに書いてあるが、「何がわからないのかわからない」ぐらいの状況だったら、「まず人に聞く」という選択肢を取れるなら取るべきかも。

ただ、質問するハードルが高かったりもする。質問できる時点で、「問題は半分解けている」。まさに今日、「できない人ほど聞けない」という話を聞いた。

今回の自分の場合は、昨日今日、頭をリセットしてゼロから考えるつもりで紙のノートに設計案やプログラムの流れを書いてみたら、できる気がしてきたので頑張ろう〜

ブログ毎日投稿をやめることにした

今日でブログ連続投稿175日目になった。

（公開前の画像だから174日）

昨日も書いたが、先週から使い始めた Scrapbox の調子がいいので、180日になったら毎日更新をやめることにした。180日の理由は、6ヶ月でキリがいいから。ただそれだけ。

scrapbox.io

Scrapbox

Scrapbox は、ブラウザ上で使えるメモツール。フォルダのような階層はなく、すべてのメモが1階層にまとまる。ハッシュタグなどでメモとメモをどんどんリンクさせることができる。

個人や非営利での利用は無料で、非公開プロジェクトも作ることができる。

プロジェクトを分ければカテゴリ分けのようなことができなくはないが、基本的にそういう使い方はしないようだ。プロジェクトごとに公開/非公開設定や編集できるメンバー追加が可能なので、「プロジェクト」単位で分けるのがよさそう。

メモの書き方

Scrapbox は、基本的に箇条書きのような書式で書いていく。行頭にスペースを入れると箇条書きになる。#か[]でリンクを作成できる。コードや引用、テーブルも使える。

詳しい書き方はヘルプに書いてある。その他の書き方 - Scrapbox ヘルプ

「見出し」の機能はない。

ブログ毎日更新をやめる理由

ブログを更新することにはメリットしかないということは前も書いたことがある。ではなぜやめるのか？

更新することが目的化してしまって内容が薄くなることが多々あり、これでは意味がないと思った。しかし、自分にとってハードルの高い「ブログを書く」という行為を当たり前のことにする効果はあった。せっかくここまで続けたし、やめる決定的な理由がない中、デメリットよりメリットがはるかに大きいので続けてきた。そんなモヤモヤを抱えているところに Scrapbox という最高のアウトプットツールに出会ったということになる。

検索しづらい

たとえば、競プロなどの問題を解いたというブログ記事の中に、新しく知ったメソッドの使い方などを書くことがよくある。後から、メソッド名を調べようとすると結構難しい。そういう点も克服できるのが Scrapbox だと思った。

Scrapbox のいいと思うところ

見出しが作れない

Scrapboxには見出しを作る機能はありません
見出しが作れるほど独立した内容であれば、別のページに切り出す方が良いです
見出し - Scrapbox ヘルプ

Scrapbox を使い始めたとき、まず調べたのが、「見出しの作り方」だった。それができないと知ってとても驚いた。上に引用したページを読むと、「切り出されたページは再利用性が高ま」ると書いてあって、半信半疑ながらそれに従ってしばらく使ってみた。実際にやってみて、納得！

書き出すまでの時間がほぼゼロ

今までは、まず、関連するメモを探して、その中でどのあたりに書いたらいいかを考えて、見出しをつけて…。関連するメモがないときは、ディレクトリを作るか既存のディレクトリに入れるか考えて（ここで結構ディレクトリ構成に悩み出す）、ファイル名を考えて…のように、意外と時間がかかっていたことに気づいた。

1つ1つのメモを見出しレベルにしておくと、何も考えずに書き出せる。書き出してから、自分の場合はカテゴリだけ#でつけているが、ここはまだ模索中。

細かいメモはどんどんリンクさせられるので、あとからまとめたくなったらまとめたページを作ってもいいし、作らなくてもいい。1つのメモがいろんなところから縦横無尽にリンクできるから内容が重複しないのもいい。

メモしたいと思ったことは、コードもコード以外もなんでもぶち込んでおけば、検索で1発で見つかるという安心感もある。

データのエクスポートOK

バックアップデータのダウンロードやエクスポートも可能。Markdown との変換ツールもあるらしい。

ページをインポート・エクスポートする - Scrapbox ヘルプ

アウトプットの敷居ゼロ

ほんと、これ。

構造がシンプルなScrapboxは書くことの敷居を極端に下げてくれます。

ブログって、大したこと書いてなくても結構時間がかかる。自分の場合、平均すると多分1記事2時間以上。毎日21時ぐらいになったら書き始めて、日付が変わる前になんとか公開というパターンが多いので、3時間ぐらいかかることが多いのか。

Scrapbox だと、1日何個も書けるしそれが全く苦しくない。esa みたいに、不完全でもいいというところがポイント。本当に書くことへの敷居がゼロになった感じ。とにかく書きやすい。

まだ1週間なのに気づいたら50ページ以上になってた（どうでもいいのも含まれているけど）。

https://scrapbox.io/masuyama13/

ページはたくさんあるけど、全部WIPですのであしからず。あ、間違いを見つけたときは教えてください。

Scrapbox にメモがたまったら、まとめてブログ記事にするとよさそうな内容が自然と出てくると思う。そんな感じでブログも続けていきたい。