ターミナルから簡単に曲を聞けるbgm.rbというのを作った - hitode909の日記
bgm.rbは音楽プレイヤー．ターミナルから簡単に曲を聞ける． hitode909/bgm · GitHub 聞く 聞きたい曲のジャンルを入れたらおもむろに曲が流れる．終わったら次の曲．最大200曲聞ける． % bundle exec -- ruby bgm.rb hiphop ドクター・ドレー - The Next Episode https://itunes.apple.com/jp/album/the-next-episode/id14435051?i=14435093&uo=4 Run-DMC - Walk This Way https://itunes.apple.com/jp/album/walk-this-way/id255372435?i=255373524&uo=4 エミネム - Lose Yourself https://itunes.apple.com/jp/albu
テスト先に書きたい若者よ - hitode909の日記
弊社では毎年インターンを受け入れているのだけど，いまもインターンが来てて，テスト先に書きたいけど油断すると先に実装を書いてしまう，とか話してた． 個人的には，テスト先に書くのが大事というよりかは，意識して仕様を先に考えるのが大事だと思っている．テストを先に書くと，先に仕様を考えざるを得ないので，良いスタイルが身につく． 僕がよくやるのは，関連しそうなクラスの絵をひと通りノートに書いてみて，その図だけで，うまく動くことを説明できるくらい考えてみる．その時点でおかしかったら，コード書いてもおかしくなる．ノートに方眼ついてるとクラス図書きやすい．UMLとかじゃなくても，自分で見て分かるくらいでもいいと思う． 紙でうまくいったら，外部仕様だけソースコードに書いてみる．クラス名と，メソッドの定義と，メソッドの上くらいに，ひと通りコメントでも書いてみて，この関数はこういうことをするんです，こういう引数
プレゼンテーション - hitode909の日記
プレゼン自分ではすべったことないから得意だと思ってるのでいつも気をつけてることをシェアします。これさえ守ればすべらないのだから楽。 目次 目次 最初にめちゃくちゃおもしろい話をする 箇条書きせず一行ずつページを分ける 絵をでかくする 新しいページ作ったらデフォルトのパーツを全部消す 先に言う 意見や疑問を述べる スターウォーズエピソード4を見る 最初にめちゃくちゃおもしろい話をする 聴衆は懇親会のことしか考えてないので、とりあえず最初におもしろい話をして、注意を引きつけるとよい。つかみはこれでオッケーだって言えればよいくらいの面白い話をしましょう。よくある技術ブログとか、技術雑誌だと、こんにちは、最近温泉に行って心身共にリフレッシュしました、ヒトデです、とか書いてあるけど、そんなの読んで喜ぶ人が本人と家族と親類以外にこの世にいたらおかしいから、そういうのじゃないとよい。 箇条書きせず一行ず
コードレビュー - hitode909の日記
コードレビュー，慣れるとできるけど，いきなりdiffを渡されて，どうぞ見てくださいと言われてもよくわからないと思う． やりましょうというのはいいけど，ただむやみに読んでもうまくいかない．変更がある程度大きくなるとdiffだけ見てもよくわからないので，いろいろ見ることになる． 僕はいつも以下のようなことを無意識にやってて，うまくいってる気がしてる．GitHubのPull Requestの仕組みを使ってる前提で． Discussionをさらっと眺めてどういう問題を解決したいのか見る Commit Statusを見て，テスト通ってることを確認する Commitsタブで1コミットずつブラウザの新しいタブに開く 全部クリックし終わったら古い順に1コミットずつ読む 気になる点があったらエディタとかにメモしておく．あとで書き直されるかもしれないので，まだコメントしない 全コミット見終わったらFiles
失敗する前提でデプロイする - hitode909の日記
うちのチームでは，デプロイするたびに自動的にgitのtagを切るようにしてる．たとえば，いまデプロイしたら，deploy/2014-02-01-14-48とか． たまに，リリースした直後になんかミスってたことに気付いて，慌ててロールバックすることがある． tagを切ってるので，ひとつ前に戻せばいいのだけど，えっと，どれだっけとかいって探すので慌てるし，普段はタグ指定してデプロイしてないので，どうやって戻すか忘れる． デプロイ終わったときに，今回のデプロイを戻すには，これをしましょう，とか表示するようにした． デプロイ終わったらこんなのが出る．前回のデプロイが昨日だったら昨日くらいのタグが出る． ヒント：戻すときは以下のコマンドを実行しましょう cap -S revision=deploy/2014-01-31-15-17 deploy 実装方法としては，こんな感じに，デプロイ前に最新のタグ
編集距離が近いメソッドを勝手に呼ぶ - hitode909の日記
メソッド名を打ち間違えてメソッドを呼べないことがあって寂しかったので，呼ぼうとしたメソッドがないときは編集距離が近いメソッドを勝手に呼ぶのを作ってみた． module AutoCall def method_missing(method, *args) __send__(find_nearest_method(method), *args) end private def find_nearest_method(method) methods.sort_by{ |my_method| levenshtein_distance(my_method, method) }.first end # http://d.hatena.ne.jp/kenkitii/20090204/ruby_levenshtein_distance def levenshtein_distance(str1, str2
UI変更批判バトルと複数のバージョンのウェブサービスを同時に配信することについて - hitode909の日記
ウェブサービス，UI変えると，改悪とか，元に戻してとか，そういう意見が出る． サービス提供する側の立場では，新しいUIのほうが使いやすかったり，機能が増えたり，収益が増えたりするので，新しい方を多くの人に提供することに価値がある．使いやすいかとか，儲かるかとかは，リリースまでに調べておく必要があり，リリースの結果使いにくくなったり収益減ったりしたら，失敗ということになる． 一方で，ユーザーの立場からすると，前の方がずっと使ってて愛着があったとか，新しい方を覚えるのは手間とか，確かにという感じはする．また，ウェブサービスは最終的にユーザーの手元のブラウザで表示されて動くので，映画の結末が気に入らないから変えたいといった要望よりは，受け入れやすい．データ構造についての，サーバー側の処理についてのユーザーからの要望というのはあまりなくて，このボタンがどうみたいな，UIの要望が多いと思う． 全部置
テスト書きすぎ問題 - hitode909の日記
テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う
Emacsで1ファイルにしか出現していないシンボルをハイライトするやつ - hitode909の日記
前書き 革新的ソフトウェアを作った． 背景 近年，Eclipseやflymakeなど，ソースコード中のエラーを発見するツールの開発が進んでいる PerlやRubyのような言語では静的コード解析が難しく，メソッド名の間違いを実行時にしか発見できないことがあり，頻繁にテストを実行することなどで補っている 提案手法 リポジトリ内で1ファイルにしか出現しない色付けする シンボルの出現について ソースコード中のシンボルは他のファイルにも登場する場合が多い． たとえば，あるファイルで宣言されたメソッドを他のファイルから呼ぶと，そのメソッドは2箇所から出現する． 以下の例では，helloというシンボルはファイル1と2の両方に出現している． # file1 def hello puts "Hello, World!" end # file2 require './file1' hello() 以下の例では
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
YAPC::Asia Tokyo 2014でPerlの静的解析やリファクタリングについて喋りました - hitode909の日記
