亀岡的プログラマ日記

京都のベッドタウン、亀岡よりだらだらとお送りいたします。

【読書感想】『いちばんやさしいGit & Github の教本』を読みました

あけました。 お年玉的に本を一冊読ませていただいたので、読書感想書きます!

『いちばんやさしいGit & Github の教本』は骨太な本

というわけで、読ませていただきました。著者の @ihcomega さんと @shobochim さんのご厚意で、献本いただき楽しく拝見しました。

「いちばんやさしい」という額面からは想像できないくらいの骨太な内容に、まずびっくりした、というのが最初の感想です。 『教本』の名に恥じない、全く端折っていない説明なんですよね。

CLIについてもそうですが、私はGitの、ともすればややこしいファイル管理状態(untracked - unmodified - modified - staged)について、ほんの序盤で解説しているのはなかなかすごいことだと思います。

実際私もGitを初学者の方に説明することがあるのですが、このあたりは「とりあえず変更したいもの全部Addしたらいいんよ」と魔法の呪文( git add . )をとりあえず教えてしまうことが多いんですよね。 このあたり説明し始めると、あっという間に一時間くらい経ってしまいますし。

他にも、おそらく知らない人も多いGithubのPRマージのオプション(通常マージ / Squashマージ / Rebaseマージ)の話あり、これまたほとんどの人もインストールしているのに存在知らないであろう gitk の話あり、Gitを現役でバリバリ使っている方にも知らない情報はあるのではないでしょうか。

『いちばんやさしいGit & Github の教本』はやさしい本

とはいえ、この本は基本的にすごくやさしい本です。 この本、 行間がありません。 (褒めてます)

とっつきにくい内容も、インストールしないといけないソフトウェアも、gitとは関係ないCLIコマンドの使い方まで、説明の丁寧さが凄まじいです。

更にびっくりしたのは、 重要項目にすでにマーカーが引いてあるんです。

↑のサンプルなど見てもわかりますが、重要な箇所の線引が抜群に的を射ています。(最初、本気で「あれ?マーカー引きながら一回読んだんだっけ?」と思っちゃいました)

細かいところまで、非常に丁寧で、迷子にならないように作られています。

これは本当に、労力凄かったと思います。すごい。

(そして、じつはこのレベルをメンテナンスするのも大変な気はするんだよな・・・、サポートページをOSSで立ち上げる、とかするとコントリビュートしやすくなったりしないかな。)

『いちばんやさしいGit & Github の教本』に書いていないこと

2019年現在、普通に使う分には、全く問題ないんではないかと思います。

本当に、あえていうなら、 git stash については、書いていないコマンドの中では利用頻度が高いかも、、、とはおもいます。

backlog.com

でも本当は、ローカルコミット入れればいいだけの話だし、事故の元なので使わないほうがいいんだろうな。 そこまで考えてあえて省いている気がする。

あと、 git svn が完全に過去のものになっているのはいいですね。 知らない人は、知らないままできっといいはず。

『いちばんやさしいGit & Github の教本』読んでから遊ぶと良いもの

ブランチについても、いわゆるGithubフロー的なシンプルなユースケースは本書で十分に学べると思います。 ただ、Gitのブランチは奥が深くて、触れられていないマニアックな操作方法もあるので、ブランチ沼に浸かりたい方は、Learn Git Branching をやってみるとよいのではないでしょうか。

k.swd.cc

それでは。

みんなが違うチームは、難しいけど、力強い

この記事は、 The Agile Guild(TAG) Advent Calendar 2018 アドベントカレンダー 22日目の記事となります。

qiita.com

TAG については、下記のページから。またAdvent Calendar の皆さんのBlogにも、いろいろなものが現れていると思います。

theagileguild.org

今日はチームの話をします。

多様性は強さだ、というけれど

多様性は強さ、そう言う人は多いでしょう。そういう会社も多いでしょう。

しかし、本当に多様性のあるチームになってますか?

そもそもなぜ多様性があるチームが良い、とされるのでしょうか。

トラックナンバ−1 問題を解消できるから?

いやいや、それはタスクレベルの情報共有の話であって、言ってしまえばただのリスク管理の話です。

多様性、すなわち "diversity" を辞書で引いてみましょう。

the fact of including many different types of people or things

https://www.ldoceonline.com/jp/dictionary/diversity

いろいろな "タイプ" の人間がいること、です。

"タイプ" って何?と考えたときに、私はそれを "価値観" だと感じています。 自分は何を大切にしているのか、自分が譲れないものは何か。

ふむ、では「価値観に多様性があるチーム」、それって大変じゃないですか?

はい、大変です。

そして、 大変だけど、とても力強い と思っています。

TAG で感じた価値観の多様性の力

私がTAGの方々と一緒に仕事をして感じたのは、その価値観の多様さと、価値観を守ることに対する強さです。

TAGに集まっている人たちには、自分が「正しい」と考える仕事へのこだわりが非常に強くあります。

すごいのは、みんなが 自分の価値観をチームにインストールしようとするのです

これは大変です。ほんとうの意味でのチームビルドです。必然、時間がかかります。 なにかストーリーを進めようとするたびに、「これってこうあるべきでは」というチームへの動きも入ることになります。

時間が、かかります。

でも考えてみてください。

そうやって、いろんな人の価値観が合わさったチームが作られていくんです。

スピードを大切にする人の価値観と、作り込みを大切にする人の価値観と、使いやすさを大切にする人の価値観。

ともすれば、普通のチームビルドでは、それらの価値観を頭割りしてしまいがちです。

程々なスピードで、程々な作り込みで、程々な使いやすさで。

これは、悪いチームワークなんでしょう。

良いチームワークとは、それぞれの価値観を引っ込めずに主張しあい、頭割りされずに、それぞれの価値観が共存するチームなんだと思います。

それは、チーム全員が主役になろうとするチーム。

つまり、これです。

f:id:posaunehm:20181222183128p:plain
© 甲斐谷 忍, 集英社ONE OUTS より)

私も、そんな価値観を埋め込めるチームの一員でありたいな、と、改めて強く感じています。

【みんなで】Refactoring 2nd Edition【読もう】

なんか2chスレタイトルみたいになってしまった・・・。

というわけで、リファクタリング第二版です。当然皆さん買っていますよね? 買っていない人は今すぐ買おう!

とはいえ、第二版ったって何が変わっているのよ?と思う方もいるでしょう。

一番大きいのが、コード例がJavaからJavascriptになったというところではないでしょうか。 これにより、軽量言語向けの記述が強化されたとともに、Javascript をいかに読みやすく書くか、というノウハウが詰まった本になっています。

また、「不吉な臭い」にもいろいろとアップデートがかかっています。

これについては、増えた臭いについて、こちらに解説を書きました!

devtab.jp

というわけで、みんな買いましょう。

時代を越えて良い本が、時代を飛び越えてきてくれました。

Entityをめぐる冒険

これは、DDDアドベントカレンダー#1 8日目の記事となります。遅刻してすいません。。。

厄介な概念、Entity

さて、 Entity ですよみなさん。

ドメイン駆動設計のなかでも、屈指の誤解を招く言葉は Entity だと思います。 データベースの世界で一般的にすでになっている Entity という言葉なのですが、DDDにおいて指す意味は微妙に違う。 そんなイメージを持っていました。

では、改めて Entity がどういう意味合いのものなのかを改めて考えてみましょう。

DDDの文脈上での意味

DDDにおける EntityValue Object と対をなす、オブジェクトを表現する重要な塊です。 まずは日本語訳を引いてみましょう。

オブジェクトの中には、主要な定義が属性によってなされないものもある。そういうオブジェクトは同一性のつながりを表現するのであり、その同一性は、時間が経っても、異なるかたちで表現されても変わらない。そういうオブジェクトは属性が異なっていても、他のオブジェクトと一致しなければならないことがある。また、あるオブジェクトは、同じ属性を持っていたとしても、他のオブジェクトと区別しなければならない。同一性を取り違えるとデータの破損につながりかねない。

主として同一性によって定義されるオブジェクトはエンティティと呼ばれる

Eric Evans. エリック・エヴァンスのドメイン駆動設計

何度も繰り返されるように、「同一性」がキーポイントになっています。 エンティティとは、同一性(例えば ID など!)によってその存在を担保されたものです。 それに対して、その属性により同一性を担保するのが Value Object なわけですね。

ここまでは、まぁいいでしょう。

モデリング用語としての意味

データモデリングの用語としても、 Entity はでてきます。 そう、有名なER図で使われる、Entityですね。

どれを引用するべきか難しいのですが、 日本語版WikipediaにおいてERモデリングの起源の一つとされるPeter Pin-shan Chen 教授の論文から一部引用すると。

An enlity is a "thing" which can be distinctly identified

enitty とは明確に同一であると特定可能な"もの"である。」

なるほど、こちらでも identify すなわち同一性が大きなキーワードとなっています。 あれ、ほぼ意味合い一緒ですね…

データベース用語としての意味

問題はここからのように思います。 データベースの世界に来ると、Entity というのは、ほぼほぼ「テーブル」という意味になります。

これはデータモデリングの手法上、ER図を詳細化していくとほぼ物理DBとマッピング可能なレベルにまで Entity を分解していくからです。 いわゆる「概念 ⇒ 論理 ⇒ 物理」の3層モデルとなります。

その結果、個々の Entity は物理的には対応するテーブルへと変換されます。

ここに、 Entity = テーブル という誤解を招く真因があるような気がしますね。 少なくとも、論理データモデルを設計している間は、DDDとERモデリングにおいて、大きな差は無いように見えます。

そもそもの単語として意味

では、Longmanを引いてみましょう。

entity | ロングマン現代英英辞典でのentityの意味 | LDOCE

something that exists as a single and complete unit

直訳とすると「単一の、完全な単位として存在しているなにか」みたいな意味になります。

また、英語版Wikipediaも引いてみますと。

Entity - Wikipedia

In philosophy

Ontology is the study of being, existence and the recognition of entities. The words ontic and entity are derived respectively from the ancient Greek and Latin present participles that mean "being".

哲学用語でオントロジー、すなわち「何がそれを"それ"たらしめているのか」と関連する言葉として触れられていますね。 もともとは、ラテン語being すなわち「"それ"であること」にあたる単語から派生しています。

このように考えると、やはり Entity のポイントは「同一性」にあるという、Evansの主張はすんなりと入ります。 少なくとも、DDDの設計で Entity を考えるときには、そこに物理的なDBという概念は考えず、その一つ上の「同一性」に思いを馳せるのが良さそうだよな、と改めて感じた次第です。

SonarQubeで継続的インスペクションをはじめよう!

これはギルドワークスイベントカレンダー 6日目の記事となります。

SonarQubeとは

SonarQubeは皆さんご存知でしょうか? もちろんメジャーなソフトウェアではあるのですが、Jenkinsなどの継続的インテグレーションツールなどと比べると、まだそんなに知られていないのかなと思います。

SonarQubeは、そのホームページに解説されているように、"Continuous Inspeciton"、つまり「継続的コードインスペクション(検査)」ツールです。 コードインスペクションは、言ってしまえばコードレビューの一種です。一般的には、コーディング規約の遵守チェックなど、より詳細なチェックを行うものを指します。

f:id:posaunehm:20181207233452p:plain

そのような詳細なチェックを人手でするのはかなり大変で、コード全体に継続的に行うのはかなり大変です。 そういう大変な作業を行ってくれるのは、SonarQubeです。

SonarQubeの構築は大変(だった)

以前、私はBlogに以下のような記事を書きました。

posaune.hatenablog.com

四苦八苦して、WindowsにSonarQubeを設定していました。ほんとに大変でした・・・。

では2018年の今、どうなのか。

結論を言うと、とても簡単になりました。そう、 Dockerのおかげで

Dockerで5分で立ち上げるSonarQube

それでは、最速でSonarQubeを試してみましょう。 必要な環境は、Dockerが入っていること、それだけです。

環境としては、SonarQubeと、バックエンドDBとしてPostgresを利用する形になります。

まずは、以下のレポジトリをクローンします。

git clone https://github.com/SonarSource/docker-sonarqube

次に、以下のコマンドでreicipeのファイルをコピーします。

cp ./recipes/docker-compose-postgres-example.yml ./docker-compose.yml

あとは、Docker Compose を起動するだけです。

docker compose up

これで、localhost:9000 にSonarQube のServerが立ち上がります。

その後、 sonar-scanner をインストールします。Macだと、以下のコマンドでOKです。 これは、サーバーに解析してほしいソースを送信するためのものとなります。

brew install sonar-scanner

これですべての準備は完了です。あとは、 localhost:9000 に行き、プロジェクトの追加を行います。 そこで、プロジェクトを作成していくと、最後に以下のような画面が表示されます。

解析したいコードのディレクトリで、SonarQube Server に表示されているコマンドを入力しましょう。

f:id:posaunehm:20181208001205p:plain

これでインスペクションは完了しました! まずは、SonarQubeの解析結果を見て、どんなことをチェックしてくれているのか、確認してみてください。

まずは気軽な、SonarQubeの始め方でした。

CI/CDの話を書きました。

アドベントカレンダーの時期だけ活発になります(挨拶)

さて、12月ということで、多分3つくらい記事書く予定です。 まずは、CI/CDのモチベーションについての話。

devtab.jp

UserDefaultをアプリ外から読み書きする方法。

今回も小さめのネタを。

最近はRealmを使うきかも増えているのですが、やはりiOSのアプリでローカルにデータを保存するとなると、最初に上がる選択肢は UserDefault となりますよね。

USerDefault の値は、基本的にはアプリからしか読み書きできなくなっています。しかし例えば起動時の初期化フラグなどをUserDefaultに持っていたりすると、テストのたびにインストール / アンインストール を繰り返して、、、と結構面倒くさいものになります。

また特定の条件を再現したいときなども、結構もとに戻すのは大変で、アプリにデバッグコマンドを仕込んだり、、、なんてことも皆さんやってるんじゃないでしょうか。

しかし実はこのUserDefault、読み書きできるんですよね。

UserDefaultを読み書きする

UserDefault を読むのに必要なのは、XCode のみです。

まずは Window > Devices and Simulators をクリックします。

f:id:posaunehm:20180823222325p:plain

するとデバイスウィンドウが開きます。そこで利用しているDeveiceなりSimulatorなりを選択します。 f:id:posaunehm:20180824111612p:plain

そうするとそのデバイスデバッグ可能なアプリの一覧が出てくるので、UserDefaultを読みたいアプリを選び、 Download Container をクリックします。

f:id:posaunehm:20180823222317p:plain

そうすると、そのアプリのデータがまとめてダウンロードされます。それを「パッケージの内容を表示」で見てやると、、、

f:id:posaunehm:20180823222314p:plain

以下のようなディレクトリができます。 AppData > Library > Preferences と移動していくと、 %BundleID%.plist となっている plist が見つかります。 f:id:posaunehm:20180824111608p:plain

これをがUserDefaultの正体です。ダブルクリックでXCodeが開くので、好きな値に変更してみましょう。 f:id:posaunehm:20180824111605p:plain

これを Upload Container で再度アップロードすると、編集した UserDefault を利用することができます!

というわけで

細かい技ですが、知ってるとかなり便利です。お試しあれ。