factory_boyについての現状の理解を吐き出す

ここ２日くらい、しばらくぶりにユニットテストを書いている。と言っても、そもそもユニットテストを書いた経験は少ないので、ユニットテストってどう書くんだっけ。と言うところからの再開だった。

開発は、いつものようにPythonとdjangoで、ユニットテストを書く中でfactory_boyを使っている。その中でfactory_boyってなんだっけ、となった。少し期間が空くと忘れてしまう。前も同じような疑問をもった記憶があるし、思い出すのに時間がかかったり、時間短縮のために再び人に聞いたり、と、なかなか効率が悪い感じがある。一回やったことは、二回目以降にサクッと思い出してサクサク進めたい。

と言うわけで、次に使うときにサクッと思い出せるように今の理解を書き出しておこうと思う。

• factory_boyは、ユニットテストを書くときに便利。
  • factory_boyは、factoryパターンのクラスを作るための抽象クラスのライブラリ
  • factory_boyを使うとdjangoのmodelにfactoryパターンを適用できる
    • factoryパターンを適用すると、インスタンスの生成とインスタンスの属性や振る舞いを切り離せる。
    • 要するに、インスタンスのテンプレが作れるような感じ。
  • factory_boyを使うと、ユニットテストがデータベースの変更に強くなる。
    • factory_boy（と言うかfactoryパターン）を使わずにユニットテストを書いていると、データベースのカラム追加の時とか辛くなる。
    • 例えば、djangoでデフォルト値の無い、nullが許可されてないカラムを追加すると、そのモデルを使ってテストしてる部分を全体的に修正することになる。辛い。
    • 事前に作ったテストデータを使ってる時はそのテストデータも修正が必要になって、さらに辛い。
  • factory_boyを使うと、楽にテストデータを作れる。
    • 例えば、別のテーブルと依存関係をもつデータを作るとき、依存先のテーブルに参照するデータがないと、データを作れない。ユニットテストのテストケース１つ１つに対して、毎回作るのはわかりと辛い。factory_boyで、依存先のデータを勝手に作るテンプレを書いておけば、あとは勝手にテンプレを作るようにできる。
    • あと、文字列を自動で生成して、レコードを増やすようなのも楽にできる。factory_boyで、ランダム文字列を生成して属性につめるように書いておけばよい。
    • 最新のドキュメントを読むと、build_batchというメソッドを使って、一括で大量のデータを作ることもできる様子
  • データベースの変化に強いユニットテストを作るためにfactory_boyは便利。
    • 逆にほとんどデータベースが変化しないようなシステムでfactory_boyは必要か？と言われると、別に必要ではない。
    • そもそもfactory_boyは、必要かどうかの話ではなくて、使っておくと便利になる。という話。
    • そして、factory_boyそのものを導入するのはそこまで難しくないし、システムがほとんど変化しないとしても、RDBを使ってリレーションが複雑になるならfactory_boyを使っておく方が開発の効率は上がる。今のところ、あんまりいれない理由は思い浮かんでいない。

今日のところの理解はこんな感じです。

Ansibleって結局なんなんや。と思ってた話

コードのインフラ化をあんまりよくわかっていない。もっと理解を深めたい。 それで、Ansibleって結局、何なの？って思ってた。 というか、Ansibleと同じ時期に、vagrant、Docker、docker-compose、fabric、terraformあたりを知ることになり、混乱が加速した。こいつら何が違うんだ！というのが僕の想いだった。

とりあえず、今日はAnsibleが何なのか、という部分の理解がだいぶ進んだ。というわけで、今のところの理解を書いておく。

• Ansibleは、サーバーの構築を支援してくれる何か。

  • Ansibleは、サーバーを構築するために使えるコマンドを冪等性を考えてモジュール化しようとしている何か。
  • 冪等性というのは、何回実行しても、同じ状態になる性質のこと。１回デプロイしても、２回デプロイしても、同じ状態になる、ということ。
  • Ansibleは、サーバーを構築する時に必要な情報を整理するためのフレームワークも含んでいる何か。
  • Ansibleは、Ansibleの書き方（yml）で書いている構築用のコマンドをシェルで実行していくだけ。
  • Ansibleは、サーバーの状態を定義しないこともできる。Ansibleを使ったから、必ずサーバーが同じ状態になるわけではない。Ansibleが触らないファイルや設定を手作業で修正したら、それはそのまま残る。
  • Ansibleでコード化した後に残るのは、デプロイの時に何をやるか、の流れ。

• Ansibleは、サーバーそのものの用意はできない。OSのインストールとかもできない。ハードウェアの設定もできない。

  • Ansibleでは、Vagrantのboxのようにサーバーのイメージがあるわけではない。VirtualboxのようにOSイメージがあるわけでもない。Ansibleは、構築（デプロイ）の時にやることを整理する環境とツールが用意されているだけ。イメージは何もない。
  • 例えば、AWSのEC2でアプリケーションサーバーを作る時には、Ansibleの活躍は、AWSのEC2インスタンスを作ってssh接続できるようにしてから。
  • Ansibleがインスタンスを作ることはできない。
  • Ansibleでは、sshで接続した後にやっていく作業を、手順にまとめていくことができる。それがプレイブックと呼ばれる。

• Ansibleは、インフラエンジニアが、インフラをコード化する時の障壁を軽減する。

  • おそらく、Ansibleがないときは、次のよう話があったと思う。

    • 「インフラの構築をスクリプト化したい」→「シェルスクリプトで書けば？」→「もっとモダンな言語で書きたい」
    • 「インフラの構築をモダンな言語でスクリプト化したい」→「Chefで書くぞお！」→「僕、RubyわからないしChef、よくわからないんですけど。（ChefはRubyライクな書き方をする）
    • 「インフラの構築をモダンな言語でスクリプト化したい」→「僕はfabricでデプロイするぞお！」→「僕、Pythonわからないしfabricもよくわからないんですけど。」

  • そんな中で、Ansibleが登場した。

    • なんかよくわからんけど、ymlっていう優しい書き方をしている。
    • インフラエンジニア的には、PythonでもRubyでもPHPでもないので平和だし、どれを使う会社にいってもスムーズに使えるから、楽。
    • 構築する時に実行可能な各モジュールのインターフェースがymlで記述するフォーマットに統制されていて、考えることが減った。
    • 各モジュールでインフラのコード化をする時に、障壁になる冪等性の考慮をしやすいインターフェースになっている様子。
    • バックグラウンドがPythonコミュニティだからか、ドキュメントがすごく豊富。
    • Ansibleいいじゃん！！

というわけで、Ansibleが普及した。

なおAnsibleが登場したに書いてあることは僕の予想です。

ボリュームがあって、やる気が出ない時にやる気を出す質問

Pythonの公式ドキュメントを読もうと思ってました。でもボリュームが多くて、なかなかやる気になりませんでした。

こないだ先輩に言われた質問をぶつけて考えて見たら、読む気になってきたのでその話を書きます。

概要

• 具体的なPythonの話は出てきません。
• こうやったら読む気になった話が書いてます。
• やりたいことはあるけど、実際にやる気にならないことがある人に役に立つ話です。

内容

以下のような流れで考えが進んだらやる気が出ました。

1. Python公式ドキュメント読もうと思った。
2. Python公式ドキュメントのトップページを見た。
3. 量が多くてやる気でないと思った。
4. どこを読んだ方がいいか考えたら、ほとんど全部読んだ方がいいと思った。
5. 正直、全部は読むのしんどいと思った。
6. 逆に１つしか読めないならどこを読むか考えてみた。
7. 個人的には言語リファレンスを読みたいと思った。
8. あとのやつは、言語リファレンスが読み終わった後に考えることにした。

太字の場所がポイントです。

まとめ

やりたいことがたくさんあったり、やろうとしてることが大きい場合、着手するにはエネルギーが必要です。

でも、そのたくさんのやる事のうち、１つしかできないならどれをやるか？と考えてみると、着手して前に進めることができます。

おそらくいろんなことにも応用できると思うので、応用していきたいと思います。

超スピード文章術と言う本を読んだ話

超スピード文章術って本を読みました。

10倍速く書ける 超スピード文章術

概要

本の概要は次のような感じです。

• この本は、わかりやすい文章を書くための本。
• 筆者はビジネス書を、たくさん書いている人。
• どういう考えで書いていくと、スムーズに出来上がるか、を書いてる。

内容

本を読んで、印象に残った話は次の話です。

• 具体的な話を書くと伝わりやすい。
• 素材を集めて並び替えれば文章はほぼできる。
• 書く前に文章の目的と読者を決めること。
• 素材は多く集めて後で削るのが楽。
• 書くことを目的にしないこと。
• 読者を決められないなら１人をイメージして書こう。

感想

この本に従って書くと、書きやすそうだと思いました。

この本に従って書いた本は、具体的な話が多そうだと思いました。

理論的な話より実践的な話の方が向いている印象でした。

文章を書く時間が長くなってしまう人は、これを使うと早く書けそうです。

僕はブログにそのまま使おうと思いました。

自分の１日を書くと情報の価値は高くなるの？

今日も雑な話をします。

とりあえず前置きすると、技術感は、ないに等しいです。

まあ暇つぶしになったら嬉しい、くらいです。

唐突ですが、昨日、聞いた話の中で印象に残ったことがあります。

それは、『事実は情報の価値が高い』と言う話です。

理科系の作文技術って本から得た情報です。

理科系の作文技術 (中公新書 (624))

それを聞いて、ブログには持論を書くよりも、自分の周りの事実を書く方が良さそうだと思いました。

と言うわけで、事実を書こうと思います。

で、事実って何を書いたらいいんでしょう？

んー、とりあえず書きやすいことを書きます。

自分のことが書きやすいので、僕の１日に関する事実を書きます。（誰が興味あるんや。という話はあります）

よし、書こう。

• 朝6時に起きた。
• 朝飯を食べたり、身支度を整えた。
• 今日の分のサプリメントを飲んだ。
• ユースケース駆動開発の本をチラ見した。
• 自分が欲しいアプリについて考えた。
• 簡単に要求を紙に書き出した。
• そして、ドメインモデルを紙に書いた。
• そのあと、ユースケース図を書いた。
• 知的生産の技術、と言う本を片手に持って家を出た。
• 電車の中で、今日の夜の予定の確認連絡をした。
• 電車が5分ほど遅れた。

よし、朝終わり。

そこから職場で働きました。

あと、今日の仕事が終わった後の話も書こう。

• 新宿のルノアールに行った。
• MyStatsに3日分のライフログを記録した。
• 最近、制作を一緒にしてるシンガーソングライターにあった。
• 昨日、聞いた最近の音楽業界の話をシェアした。
• ショールームってサービスが彼には向いてそうだ。という話をした。
• フリクルって音楽活動支援のサービスも紹介した。
• 音源制作中の曲のmidiを僕のStudio ONEに取り込んだ。
• 各種ソフト音源を僕の持ってる音源に差し替えた。
• 全体的な曲構成について話し合った。
• 今後の予定について話し合った。
• とりあえず、『ショボくても毎日ブログを書こう。』という話をした。
• 自宅にAmazonで買った特茶が届いていた。
• 自宅にAmazonで買った新しいタオルが届いていた。
• パスタ茹でた。
• パスタの味とか諸々の所感をEvernoteのパスタノートに書いた。
• 気になって、録画して録り溜めてたU-29って番組を見た。

はい。とりあえずここまで。

ふー、情報の価値はあがったんだろうか。

確かに、わざわざ人に言わないようなことも書いてるし、何故そうなった感のある話もあると思うので、中身は濃いような気がする。

中身があることと価値があることは、同じなのかな。

ふわっとしてますが、とりあえずここまで。

ゆるいコミュニティサービスください

人と話してるとほしいWebサービスの案がポンポン出てきて困る。

今日は、某スタートアップな会社の社長と飲んでいて、こういうサービス欲しいんだよね。って話をした。

今回はその話を書く。

それはまるっと言うと『mixiコミュニティ的なやつ』

共通の趣味でゆるく人が集まってオフ会ができるSNSが欲しい。

Twitterだと1:1、もしくは1:Nのコミュニケーションになってしまうので、それをN:Nにしたい。

Twitterで人に出会ったとしてもそれは1:1のコミュニケーションになる。

Facebookのコミュニティは？って話も出てきたけどねFacebookコミュニティは、なんかガチすぎると思ってる。

別にガチな話は好きだからいいんだけど、もっとゆるいつながりも欲しいよね、って話をした。

Twitterのリストは、共通のテーマで集められるのでは？って思ったけど、やっぱりN:Nのコミュニケーションにならないし、違う。

あと、個人的にはオフ会はなくてもいい。どっちかと言うとオフ会がメインではなく、あるテーマに対する話をN:Nでやるコミュニティ。

mixiコミュニティがあった時は、例えば好きなバンドのコミュニティがあって『このアーティストの曲で好きなのトップ3！』みたいな雑なスレッドがあって、適当には書き込みがあって、自分に近い人とSNSでだけ仲良くなったりした。

あと、そのSNSは、ただのオフ会企画サイトだと微妙。知らない人が30人集まったらだいたい変な人が、けっこう混ざる。

mixiコミュニティは、その点、アカウントをみてなんとなくの人なりがわかったのが良かった。

だから今だとTwitter連携必須にするといいのかなーって話した。あと、そのコミュニティの人のツイートを集めたタイムラインを見れて、スレッドにして話ができるUIがあったらいいなと個人的に思う。

そのSNSを軸にして、人が集まって、あとはTwitterでよろしく。というイメージでいい。

IT業界だと勉強会コミュニティが近い役割を担ってると思っていて、それがいいなーって思ってる。

ただ、僕が興味のあるのは、IT業界だけではないと言うのがある。

2chよりも、もう少し人物が特定できて、Facebookよりも、リアリティのないつながり。

ゆるいコミュニティ。

今はそういうゆるいコミュニティの時代だと思うので、ぼちぼちそういうゆるいコミュニティ支援サービスが出てくると思う。

ただ、僕はこのサービスを作らないと思う。 他にもやりたいことがたくさんあるし。

あと、今日飲みに行った社長も多分作らないと思う。あちらの会社は、けっこうビジョナリーな会社だし、このサービスを作るのはしっくりこないから。

そう言えば、サービス開発と使命感って大切なんだろうなって思ってる部分がある。スタートアップで頑張っている知り合いが何人かいるけど、みんな自分がやることに使命感を感じてるように思う。

使命感を感じるから今頑張ってるんだろうな〜 って話を聞いていて思ってる。僕もあの人も、このサービスに使命感を感じられないと思ってる。だから誰か作って欲しいな（ゆるぼ）

散文だけど、今日はこれで終わり。

最初はパスタに興味がある話

雑な話をします。

最近パスタに興味があります。

きっかけは、先日食べたパスタにあります。

その店のパスタがすごく美味しかったので興味が湧きました。

それで、あーこのパスタを家で食べたいなあ。

どうやったら作れるんだろう。と思いました。

よーし、研究するぞー！と思いパスタマシンを買おうとしたところ、落ち着け。と、ストップがかかりました。

パスタマシンを買って、本当に何回も作るのか、など話があがりました。

ふむ。

とりあえず、少し良いスーパーにいけば生パスタが売ってるからそこでパスタを買って、研究してはどうか。という話になりました。

なるほど。 とりあえず買えるもの買って、研究するのは良さそう。

と、いうわけでとりあえず成城石井に行きました。そして、とりあえず、僕が家で食べたいと思っているパスタの形状に近いパスタを全種類買いました。

例えば、これ。

とりあえず、市販のパスタを食べて、感想をメモしています。

まだソースは試行錯誤してなくて、パスタをどう作ると良いのかな〜と言うのを研究してます。

今のところ、この市販のパスタを、こうやって茹でたらこんな感じになった。と言うのを繰り返しています。

最初はパスタの種類で味が決まると思うんですが、茹でる時の時間や火の強さ、水の量、とかでも茹で加減が違うような気がするな〜とか思いながら黙々とパスタを食べてます。

まだいい感じのパスタに出会えていません。

もう少しパスタ探しをしようと思います。