自分を退職に追い込む動きをすると良い - hitode909の日記
去年，いまのチームに来たときは僕がフロントエンドのリファクタリングを進めたり面倒を見たりしていた．JS得意な友達がバイトに来てくれるようになり，今はその人がBabelを入れたりしてくれている．彼がバイトに来てくれなかったら，いまだになんとなく興味があるので見ますみたいな感じで一人で面倒見ていた気もする． よくある話で，属人性を高めないように自分の知識を展開しましょうという話があるけど，具体的にアクションプランを考えてもどれが一番良いのかわからない．抽象的に考えると，自分の仕事をなくして退職に追い込むような動きをすると良い．周りのレベルが上がったり移譲されたりしてその分野で価値を発揮できなくなってれば自分じゃなくてもできるようになっている 自分でなくても実装できるようになって，作戦の相談に乗ったりとかしていると，次はそこの属人性が上がってきて，自分のバリューを再びなくすには，誰でも計画を立て
KAOSS DJで姉を出したり朝ご飯を選んだり絵文字を高速入力したりgit pushもできる - hitode909の日記
最近KAOSS DJで遊んでて，きのうMIDIイベントを受け取るところまでできたので，もうちょっと知的なことをやってみる． フェーダーに応じて姉を出す クロスフェーダーの値に応じて文字を出してみる．UniMIDIでイベントを受け取って，182番のときだけ値を見てなんかする．182番はクロスフェーダの操作で，3番目にフェーダーの位置が入ってる． require 'bundler' Bundler.require input = UniMIDI::Input.first.open loop { events = input.gets events.each{|event| data = event[:data] next unless data[0] == 182 size = data[2] / 127.0 * 30 puts '姉' * size } } sketch-midi/ane.r
気が狂った設計 - hitode909の日記
大きめのこととか，自信のないところを触るときは，コード書く前に，こういう作戦考えてみたけどどうですかって聞いてみたり，こういうことやりたいんだけど一緒に考えませんかって，いっしょに話して設計考えたりするとよいと思う． 一緒に考えたすぐあとに気が狂った設計とか言い出したらおかしいので，未然に変な設計のままコード書いてしまうのを防げる． 特に辛い気持ちになるのが、「気が狂った設計」「クソコード」「（こんな実装は）有り得ない」といった言葉だ。 Pull Requestのレビューが辛くて会社をやめたい 単に言葉が強いのはよくないと思う．我が社にはそんな強い言葉でレビュー書く人はいない． 我が社には，普段から強い言葉を発する人もいなくて，みんな物腰柔らかな変な言葉を話している． 言葉使いや文体は，ずっと過ごしてると同僚から移ったりするので，普段からそういう言葉を話していると，全体の雰囲気も悪くなりそ
プログラミングとは何なのか - hitode909の日記
会社でボードゲームしてる人たちがいる。 僕はボードゲーム苦手で、たまにやっても全然勝てない。 将棋とかイメージすると、こっちがこういう手を出すと相手はどうするか、そしてその次は、というのを予測すればよいのだけど、なんかそれがめんどうで、なんでこんなこと考えないといけないのか、とか考えだしてくたびれてしまう。 ずっと論理的に考えるのが苦手で、すぐめんどうになってやめてしまう。 普段、仕事や遊びでソフトウェア作ってるのだけど、よく考えると、ソフトウェアの動作が論理的なだけで、ソフトウェア作るのは勘でできる。 ソフトウェアが正しく動くかどうかは論理的に決められて、電卓アプリなら計算結果が狂ってたら間違っているけど、その電卓アプリがどのように作られたか、には正しさはない。逆立ちして作っても、猿にタイプライターを渡して作っても、計算結果合ってれば良い。 過去のデータとか経験によると猿に書かせるのは効
テスト先に書きたい若者よ - hitode909の日記
弊社では毎年インターンを受け入れているのだけど，いまもインターンが来てて，テスト先に書きたいけど油断すると先に実装を書いてしまう，とか話してた． 個人的には，テスト先に書くのが大事というよりかは，意識して仕様を先に考えるのが大事だと思っている．テストを先に書くと，先に仕様を考えざるを得ないので，良いスタイルが身につく． 僕がよくやるのは，関連しそうなクラスの絵をひと通りノートに書いてみて，その図だけで，うまく動くことを説明できるくらい考えてみる．その時点でおかしかったら，コード書いてもおかしくなる．ノートに方眼ついてるとクラス図書きやすい．UMLとかじゃなくても，自分で見て分かるくらいでもいいと思う． 紙でうまくいったら，外部仕様だけソースコードに書いてみる．クラス名と，メソッドの定義と，メソッドの上くらいに，ひと通りコメントでも書いてみて，この関数はこういうことをするんです，こういう引数
設定のクラスを作るとすっきりしそう - hitode909の日記
設定のテストを書くとよいって言ってる人がいた． 設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog; テストされてるのはよいと思う．名前のついてないデータ構造をがんばってテストするよりは，設定のクラスを作るとすっきりしそうと思った． こういう構造のHash，として見るよりかは，設定クラスのインスタンスとして見るほうがイメージしやすい． 個々のブログの設定のURLはユニークであるというのを，どこかのクラスの責任にする．BlogConfigRepositoryというクラスのインスタンスが，設定の集合を持ってるとか． like exception { BlogConfigRepository->new([ { "url" : "http://blog.example.com/", "permission" : "public", "members"
Perlリファクタリングツール作ってる - hitode909の日記
こんにちは，まずはこのGIFをご覧ください． Perlのソースコードをリファクタリングするツールまともなのがないから自作することにした．perl-refactoring-toolsっていうそのままの名前． GitHub - hitode909/App-PRT: Command line tool for Perl code refactoring いろいろあってApp::PRTになった GitHub - hitode909/App-PRT: Command line tool for Perl code refactoring いまのところ，トークンの置き換えと，クラスのリネームができる． テストのカバレッジ100%で意識高い． hitode909/App-PRT | Coveralls - Test Coverage History & Statistics トークンの置き換え トークン
コードレビュー - hitode909の日記
コードレビュー，慣れるとできるけど，いきなりdiffを渡されて，どうぞ見てくださいと言われてもよくわからないと思う． やりましょうというのはいいけど，ただむやみに読んでもうまくいかない．変更がある程度大きくなるとdiffだけ見てもよくわからないので，いろいろ見ることになる． 僕はいつも以下のようなことを無意識にやってて，うまくいってる気がしてる．GitHubのPull Requestの仕組みを使ってる前提で． Discussionをさらっと眺めてどういう問題を解決したいのか見る Commit Statusを見て，テスト通ってることを確認する Commitsタブで1コミットずつブラウザの新しいタブに開く 全部クリックし終わったら古い順に1コミットずつ読む 気になる点があったらエディタとかにメモしておく．あとで書き直されるかもしれないので，まだコメントしない 全コミット見終わったらFiles
Perlのソースコードから文単位でトークンをgit grepするやつ - hitode909の日記
Perlのソースコードから，文単位でトークンをgit grepするのを作った． 普通のgrepは行単位の検索なので，これまでgit grepするとき， メソッドの呼び出しが複数行に渡ることが予想されるとき，勘で-A 5 とかやって，後ろ5行も表示，とかやってたけど，勘に頼っていて，不便だった．ソースコードはトークン単位とか文単位なので，行単位で扱ってもあまり意味がない． GitHubに，git-grep-perl-statementというのを置いてある． hitode909/git-grep-perl-statement · GitHub 例 git-grep-perl-statementのソースコードから，coloredというトークンを探してみる． % git grep-perl-statement colored git-grep-perl-statement:61 colored($
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
YAPC::Asia Tokyo 2014でPerlの静的解析やリファクタリングについて喋りました - hitode909の日記