子供のころ、質問をするという行為が恥ずかしかった
分からないことをクラスメイトや教師に把握されることが恥ずかしかったのだと思う。 「そんなことも知らねーの m9(^Д^)ﾌﾟｷﾞｬｰ」みたいに言われることを恐れていたのだと思う。
でも大人になるにつれて純粋な疑問があればいくらでも質問していいと気づいた。 Google できる状況にあるのに質問をするという行為は無礼だと思うけどそうでなければ質問していい。
もし笑ってくる人がいたらその人は単に学ぶことへの誠意が欠けている人だと思えばよい。
他者が知らないことを自分が知っているからといって笑う行為というのは 逆の立場になったときに質問しにくい空気の中に自らを放り込むようなものだ。
ところで書いていて思ったんだが、つまり子供のころの私は「そんなことも知らねーの m9(^Д^)ﾌﾟｷﾞｬｰ」 みたいな態度を取っていたから質問するのが恥ずかしいという状況になっていたのではという気になってきた。
git サブコマンドの作り方
gitlab で API 連携して MergeRequest 送りたいなあ。Webインタフェースから MergeRequest 投げるの面倒くさい。git lab mr とかで MergeRequest 送りたい。git のサブコマンドってどうやって作るのだろうか？
そうだ！ git flow のサブコマンドをインストールしてみてパスとか調べてみよう！！！
ということで調べてみた。
環境は自分の MacBook Air
git-flowのインストール
brew install git-flow
場所チェック
which git-flow
/usr/local/bin/git-flow
git hoge の作成
vim /usr/local/bin/git-hoge
#!/bin/bash echo "Hoge!";
使ってみる
git hoge Hoge!
出た！
所感
gitlab API と連携できるツールなんて自作しなくても github 上にありそう。
参考
強いチームはオフィスを捨てる
読了。良書だった。良かったところ3点。
- リモートワークは魔法じゃない
- 同じ画面を見る、同じソースコードを読む
- リモートワークができる優秀な人間を雇う
所感
本書の働き方を実践できる彼らのことの姿勢にすごく同意できるし羨望するし格好いいと思う。 でも彼らがそれを実践できるのは、彼らが優秀な人間を雇う努力をしているからなのだとも感じる。 現在の働き方はオフィスワークだけど機があればリモートワークにも挑戦していきたい。
強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」
- 作者: ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン,高橋璃子
- 出版社/メーカー: 早川書房
- 発売日: 2014/01/24
- メディア: 単行本
- この商品を含むブログを見る
Mac OSのbuilt-in vim(/usr/bin/vim) 使うのを辞めた
最近ホットな Vim Plugin ３つを読んでいてvim-over入れたくなったことがきっかけ
NeoBundleでインストールして使おうとしたらエラー
NeoBundleでvim-overのインストール。早速使おうと:OverCommandLineしたら以下のメッセージが出て手詰まり
Vim 7.3 or above. Need strchars() and +conceal.
ググったらgithubのissueがヒット
Vim 7.3 or above. とエラーが表示される · Issue #10 · osyo-manga/vim-over
vim --versionで確認したところ-concealとなっていたためbuilt-inのvim(/usr/bin/vim)使わないことを決意。
MacVimに移行
もともとMacVim入れていたので/Applications/MacVim.app/Contents/MacOS/Vim --versionしてみたところ+concealだったのでalias設定
alias vim="/Applications/MacVim.app/Contents/MacOS/Vim”
:OverCommandLineしたら使えた！
/Applications/MacVim.app以下にvimが入っていたことを知らなかった。 vim-overのインストールを機に知ることが出来たので良かった。
コードシンプリシティ
読了。良書だった。でも個人的にはリーダブルコードのほうが具体的で読みやすく、より多くの人が理解できるであろう良書だと感じた。
リーダブルコードは具体的なソースコードの書き方、例えば状況に応じた変数名の付け方などを解説しているため初学者でも読める。だがコードシンプリシティは良いコードと悪いコードの差はなにか？良いコードの利点と良いコードを書くための心構えはどうあるべきか？といった内容になっており具体的なソースコードはほとんど出てこない。ソフトウェアデザイン経験者であれば理解できる範囲は広そうだがそうでない人にとってはやや理解し難そうであると感じた。
ともあれ人に勧めたい良書ではある。
以下良いと感じた文章の引用。ちなみにコードシンプリシティ内でのデザインという単語はソフトウェアデザインのことのみを指している。
駄目な結果というものを、本書ではいっさい許容しない。コードの改善に焦点を当てるのは、結果をより良くするためには、まずコードを改善することが最優先であるからに過ぎない。
システムを扱う際、我々にできるのは、個別のパーツを完結にし、それぞれのパーツを見たときにそれがどんなものかをすぐに理解できるようにしておくことだ。プログラミングとはつまり、複雑性をそぎ落として簡潔性に導く作業でなければならない。
良い開発者はその能力の及ぶ限りコードを簡潔に書き、他の開発者が使いやすく理解しやすいようにしなければならない。
ソフトウェアを書く人は、誰でもデザイナーだ。
すべての開発者が、自分の受け持つ部分に対してデザインをより良くするための判断を独自にできるようにすべきだ。悪い判断や凡庸な判断がなされた場合には、開発リーダーやシニアプログラマーなど、部下の判断に拒否権を出せる上司が、それを取り消すようにすればよい。
ソフトウェアは人を助けるためにある。
ソフトウェアの管理が難しくなると（ソフトウェアデザインの目的の一つである）人を助けることを続けるのが困難になる。
総じて、デザインによって、物事が単純化される代わりに複雑化していたら、オーバーエンジニアリングが行われている。
コードに他のコードを「使わせ」て情報を集中させるように知恵を絞れば絞るほど、デザインは良くなる。これもまた、プログラミングで知性が本当に問われる場面の一つだ。
どのようなソフトウェアも、その管理のしやすさは個々の部分の簡潔性に比例する。つまり、部分それぞれを簡潔にできていれば、将来の変更がさらに容易になる。管理を完全に簡単にすることは不可能だが、それを目指して努力しなければならない。全体を変更するか、困難を取り除いた無限に新しいコードか、の選択だ。
平均的な規模のコンピュータプログラムも、また、どのような人間も、そのすべてを一度に把握することなどはできないほど複雑だ。人間は部分ごとに理解していくことしか出来ない。
プログラム全体は常に、巨大で複雑な構造をしている。そのため、それを見直す際には部分ごとに理解できるものであることが大事になってくる。部分が簡潔であればあるだけ、誰が見てもそれを理解できる可能性は高い。これは、コードを他の人間に託す場合や、しばらく離れていたコードを他の人間に託す場合や、しばらく離れていたコードの前に何年かぶりに戻ってきたとき、以前自分が何をしたのかを見直す場合に、特に重要となる。
長い目で見て効率的だと言えるのは、複雑なものではなく簡潔性を備えたものなのだ。
コードをシンプルにすることだ。これなら未来を予測しなくても可能だ。
事前に少々の時間を費やして簡潔にしておくことで、後で多くの時間が節約できる。
これ以上はないほど、アホでもわかるほど簡潔にすること。
簡潔性の大部分を占めるのは、一貫性だ。ある箇所で一つのやり方を採ったのであれば、そのやり方をコードのすべてに適用する。 もちろん一貫性と簡潔性があるに越したことはないが、完全に簡潔だとは言えないから、せめて一貫性は保つべきだ。
良いコメントをコードに入れるのは、読みやすさに大きく貢献する。しかし、一般的には、コードのある部分が何をしているかをコメントに入れる必要はない。それは、コードを読めば明白のはずだからだ。コードを読んでも明白でない場合、コードをより簡潔にすべきだ。コードを簡潔にできない場合にかぎり、コメントで動作を説明すればよい。
- コメントを挿入する本当の目的は、なぜそのようなことをしたのかを、理由が明白でない場合に説明することだ。
素人の開発者をたくさん集めるより、ベテランの開発者の小さなグループのほうが成功する可能性が高い。
自分の仕事を完全には理解していない開発者は、得てして複雑なシステムを開発しがちだ。
劣悪なデザインでは新機能を追加するごとに、コードの複雑性がその分だけ追加されるのでなく、倍加される
根本的な問題は、コードが散らかってしまっていることだ。だからそれを整理して既存のコードを簡潔にすれば、新機能の追加も同じくらい簡潔にできるようになるだろう。
実装にかかる作業量よりも管理にかかる作業量を減らすほうが重要だ
不具合発生率の法則：プログラムに不具合を作ってしまう確率は、そのプログラムに加える変更の大きさに比例する。
未来についての予言はまったくせずに、いますぐにわかる現在の情報を元にすべてのデザイン上の決定を行うのが最も安全だ。
O'Reillly Jenkins本に書かれていた「自分の組織への継続的インテグレーションの導入」に同意出来た
現在の職場でローカルVMにJenkins入れて自動ビルド＆自動テストを自分勝手に実装していたら評価されて会社のサーバにJenkinsのインストールとジョブ構築を依頼されたのでO'ReillyのJenkins（カエル本）買って読んでる。現在は5章あたりを読んでいる。
1章の「自分の組織への継続的インテグレーションの導入」を読んで、私自身が過去のCIツール構築の際に歩んできたことと同じことが書かれていて気持ちが回顧したので久しぶりにブログを書きたくなった。
継続的インテグレーションの導入は以下のような段階を経る。
- 第1段階−ビルドサーバーがない
- 第2段階−ナイトリービルド
- 第3段階−ナイトリービルドと基本的なテスト
- 第4段階−メトリクスの導入
- 第5段階−テストへのさらなる真剣な取り組み
- 第6段階−自動受け入れテストと、さらなる自動化デプロイメント
- 第7段階−継続的デプロイメント
私は第3段階までを実践したことがあって、第7段階まで実践しているチームを隣で見ていたことがある。
第1段階から第3段階までの実装は簡単
私の経験を書くと、2010年は第1段階のビルドサーバがない環境で開発を行なっており、2011年から第2段階のナイトリービルドを実践しはじめた。 また、このときからTDDを実践しはじめて、TDDによって作られたテストをbashとcronを使ってナイトリービルドしていた。結果はチームのMLに飛ばして毎朝結果をチェックして朝会でチームメンバーと議論していた。 ビルドサーバのない段階からナイトリービルドと基本的な自動テストの導入はTDDを実践していれば難しいことではないしOSのスケジューラを使えばすぐに導入できるお手軽な方法だと思っている。
第7段階まで実装していたチーム
第4段階以降は私自身に構築した経験はない。他のチームが実践していたそれを見たり聞いたりしていただけである。 第7段階までの実装は長い期間をかけており困難を極めていたようだが実装後はうまくいっているようには見えた。 実装以前は月に2度程度しかリリースしていなかったが実装後は毎日何かしらリリースをしていた。顧客やパートナーに素早く価値を提供できるというのはとても良いことだと思う。 そのチームは第4段階のメトリクスの導入は実践していなかったようだったが多分ソースコードが属人化しておりメトリクス自体に意味がなかったからだろう。何を重視するかによるがこれはあまり重要なことではない。
個人的に目指したいところ
- ブランチのコミットをポーリングして自動ビルド、ブランチ毎にDBを作成してテスト
- コードカバレッジの計測の自動化
- コーディング規約チェックの自動化
- 受け入れテストが自動化されておりコミュニケーションツールとなること
- ワンクリックデプロイ
- 複数台サーバを用いたテスト実施によるテスト結果の素早いフィードバック
- 作者: John Ferguson Smart,Sky株式会社玉川竜司
- 出版社/メーカー: オライリージャパン
- 発売日: 2012/02/22
- メディア: 大型本
- 購入: 12人 クリック: 345回
- この商品を含むブログ (35件) を見る
MySQLで月の差分を求める関数
ググっても見つからなかったがMySQLの日付時刻関数を調べていたら発見。 OracleのMONTHS_BETWEENのような感じで使える。ただし、違いがあって Oracleは小数点付きで返すがMySQLは整数で返す。
PERIOD_DIFF(P1,P2)
期間 P1 と P2 間の月の数を戻します。P1 および P2 は、YYMM または YYYYMM のフォーマットになります。期間引数 P1 および P2 は日付値ではありませんのでご注意ください。
http://dev.mysql.com/doc/refman/5.1/ja/date-and-time-functions.html#function_period-diff
MySQL 5.1で試してみた。
mysql> SELECT PERIOD_DIFF(201302, 201201); +-----------------------------+ | PERIOD_DIFF(201302, 201201) | +-----------------------------+ | 13 | +-----------------------------+
