Pull Request のレビューを促す ruboty プラグイン
Pull Request 、レビューしないといけないものが貯まってしまってつらいと感じることが多かった。そういうつらみを解消するための ruboty プラグイン作った。 GitHub - morygonzalez/ruboty-check_pr_please: make ruboty beg pull request review make ruboty beg pull request review. Contribute to morygonzalez/ruboty-check_pr_please development by creating an account on GitHub. github.com ruboty-cron と組み合わせて @ruboty [GitHub の Issue のラベル名]のPull Request という感じで job 登録しておくと、毎時決まった
Clean Ruby を読んでいる
CleanRuby を途中まで読んだ。一年半前に DCI 流行って、その後会社（東京の方）でも流行ってたので、「乗るしかない、このビッグウェーブに」と思って買うだけ買って積ん読してた。正月くらいから本気出して読み始めた。まだ全部読み終わってないんだけど、 Day One にメモ走り書きしてあって良い話っぽいのが書いてあったのでメモする。 2014/01/23 Clean Ruby 読んでる。まだ最初の方だけど何となく DCI についてつかめてきた。 DCI 、つまるところ RSpec みたいな BDD の考え方を製品コードにも持ってきたものだと思う。「テストコードだけ実際にプログラムが利用されるときの文脈（ context ）とか反映してるのもったいなくね？ これプロダクトコードにも反映させるべきでは？」みたいなノリだと思う。 2014/01/26 Clean Ruby、3章くらいまで来た
IRC クライアントを Linkinus から Textual に乗り換えた
46dd7418f43fe24786c47fada3fe4916.png (975×595) 会社は IRC を多用してて、入社してすぐに横の席の人が使ってた Linkinus を真似して入れて使ってた。なんで LimeChat を使わないのかというと、LimeChat だと Growl とかの通知がメッセージ全体ではなく冒頭の数文字だけだから。これでは LimeChat のウィンドウにフォーカスを移さないと続きを読むことが出来ない。Linkinus の通知は全文表示されるので、ちょっとしたメッセージなら Growl 通知だけで内容を把握できる。そいうわけで Linkinus を使っていた。 しかし Linkinus にも問題があって、最近は全然メンテされてないし、ときどきテキストフィールドがどんどん狭くなっていく現象に遭遇するようになって、自分の人間の器がテキストフィールドの大きさに反映
『男の本格節約術 — 5年で1000万円貯める52のノウハウ』を読んだ
最近、蓄財意欲が高まっているので『男の本格節約術 — 5年で1000万円貯める52のノウハウ』を買って読んだ。 著者は元メガバンク勤務のエリートサラリーマンなので、「そりゃ年収1000万円以上あれば5年で1000万貯まるだろうよ」と思いながら読み始めたんだけど、中身を読んでみると読者の年収はあまり関係ない内容になっている。とにかく節約が大切だ、ということが書いてあった。 以下、気になった点の要約。 資産を形成するために やること 銀行口座残高と総資産残高を月次管理する Excel に毎月の資産の変動を記録する 毎月、資産増加額の目標を設定し、目標と実績の乖離を検証する Excel でグラフを作成する 毎月、手取り給料の25%を積み立てる やらないこと 家計簿はつけない 週五日働いているサラリーマンが家計簿をつけることは事実上無理。 こづかい額は設定しない 「使う額」のことを気にするのではな
コメントが多いコードはダメなコードだと思う - portal shit!
最近、会社でリーダブルコードを輪読したり、Fukuoka.rb で Eloquent Ruby を読んだりしていて、メソッドや変数名の長さやコメントについての議論を読む機会があった。 昨日、たまたま 37signals のブログを読んでいたら、Rails の作者である David Heinemeier Hansson もこのトピックについて書いていた。 自分は WEB+DB PRESS で ukstudio さんの書いた RSpec についての記事を読んで感化されて以来、ソースコード中のコメントはすべて悪で、はっきりしたメソッド名、変数名を使えばコメントはいらないという考え方を持っている。DHH もそのような考え方のようだ。 要点をかいつまむ。 多くのプログラマーは短い変数名やメソッド名を好む。短い命名は明確性や簡潔性を犠牲にしているとみんな気づいてるんじゃないかと疑ってるんだけど、実際の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MacPortsからHomebrewに移行しつつある