今時builderライブラリも無いだろという感じですが，書いたのです． github.com Motivationにも書いているのですが，普通に作ったJavaのbuilderは不完全なインスタンスを作成できる可能性を孕んでいます．注意深くコードを書けば問題ないかもしれませんが，えてして我々 (主語が大きい) はミスを犯しがちです．そしてNPEがやってきて……我々はしぬ． というわけで今回作ったのがarnoldです． 端的にいうと「必要なすべての要素を取りこぼさないbuilder」であり，「そのジェネレータ (annotation processor)」でもあります．Basic usageにあるように， import net.moznion.arnold.annotation.ArnoldBuilder; import net.moznion.arnold.annotation.Requir

生きているとOSSのライブラリを使ったり，OSSのソフトウェアを使用することになるでしょう． そうなってくると内部実装や変更点を逐一知りたくなるというのが人情というものです． GitHubでコードが公開されているのであれば，「リポジトリをwatchする」というのは有効な方法に思えますが，しかしwatchしているリポジトリが増えてくると現状のGitHubのタイムラインは即座に崩壊し，容易に取りこぼしが生じてしまうでしょう．これはGitHubのタイムラインの問題の一つだと思っていて，なんとかなって欲しい点はあります (例えばタイムラインを分割できるとか……)． というわけでどうするか．もちろんAtomフィードです． https://github.com/{author}/{repos}/releases.atom と指定してやると当該repositoryのGitHub releasesをAto

表題のとおりです．話しました． これは僕が普段の開発中にエラーメッセージと触れあう時に気にしていたり，考えていることを上手いこと言語化したいという試みから始まったものです． speakerdeck.com 発表中にdan kogaiさんから「『間違えたことを言っているエラーメッセージ』も悪いエラーメッセージじゃないのか」というフィードバックを頂いて，確かに！！　と思いました．すっかり抜けていました．おっしゃる通りです． 発表後頂いた質問としては「(セキュリティ的な観点から) エンドユーザ (非開発者) に詳細なエラーメッセージを表示しては駄目な場合とかがあると思うんだけど，そこらへんどうしてるのか」というものがあったんですが，回答としましては: 技術的に詳細なエラーメッセージはエンドユーザに提供しない エラーが出ている場合，エンドユーザに技術的詳細を提供しても基本的に対処不可能 (多くの場

最近のgitを使ったWebアプリケーションのプロジェクトの開発フロー (主にブランチ運用) について記すものです． なお前提としてGitHub Enterpriseを利用しています． git-flow 大上段に構えたもののあまり特殊なことはしていなくて，基本的にgit-flowをそのまま踏襲しています． git-flowについてはしっかりした解説記事がインターネット上に数多く存在しますからそれらを参考にしていただければと思いますが，ざっくり説明すると masterブランチ，developブランチ，releaseブランチ，featureブランチ及びhotfixブランチがある masterブランチは常にリリース可能な状態になっている (すなわち現在本番で稼働しているアプリケーションのコードと等しい) developブランチは開発中の状態で，ステージング環境等に上がっている releaseブラン

まず以下の様なシェルスクリプトを用意する． #!/bin/bash # ここで依存しているパッケージを go get する # 例えば以下の様な感じ # go get -v gopkg.in/yaml.v2 # go get -v gopkg.in/redis.v3 for GOOS in darwin linux; do for GOARCH in 386 amd64; do export GOOS export GOARCH go build -v -o bin/tool-$GOOS-$GOARCH main.go done done darwin と linux について，それぞれ i386 と amd64 アーキテクチャ向けのバイナリを作るようなスクリプト．main.go はビルド対象のファイル．成果物はカレントディレクトリの bin 以下に生成されるので，あらかじめ mkdir

まあ当たり前の話なんですが，ブログなんかで GitHub (とかそれに準ずるサービス) に置いてあるソースコードをURLで示す時に https://github.com/git/git/blob/master/connect.c#L105 みたいな風に指定してしまうと，master 上の実装が変わった時にトンチンカンなところを指し示してしまい，意味不明な感じになって涙ということがままあります． https://github.com/git/git/blob/7a4f891329527826e6f1c80be2b77cfbfee06190/connect.c#L105 のように指定したほうが良い (ブログのようなストック型の情報の場合は特に) と思った次第．頼む！！！！！！ まさに今涙したのだ— 無金利 (@moznion) 2015, 8月 12 得情報 git-browse-remote

命名の話をしました．1時間位でなんとか間に合わせで書いた資料です． よろしくお願いします． 命名の話 from moznion www.slideshare.net あと，例えばメソッド名で"get"と"retrieve"と"fetch"をどう使い分けるか，みたいな話題が出て， 僕あたりは getは単純なゲッター的なものに使う retrieve は DB にアクセスして値を取ってくるものに使う fetch は何らかごちゃごちゃ処理をして (API 叩くとか) 所望の値を取ってくるものに使う という風な使い分けの話をしました．そういったルールが各々の人の中にはあります． ここらへんのルールというのは個人が好き放題やっても無力なので (というかノイズたりえるので) プロジェクトの人間たちが話し合ってすり合わせる必要があります． とは言え，いちいち些細な命名の問題について話し合っていくのはだるい

:= をなんと発音していいか分からないのでずっとち◯こ演算子って読んでる。— Tomohiro Nishimura (@tomohi_ro) 2015, 2月 25 :=，個人的に「定義氏」って読んでる— 初回 (@moznion) 2015, 2月 25 定義氏ではない，定義子— 初回 (@moznion) 2015, 2月 25 定義子，Pascalかなんかの教科書に載ってた用語だった気がする— 初回 (@moznion) 2015, 2月 25 「定義ちゃん」とか呼びやすい上に可愛らしくて良いかもしれない— 初回 (@moznion) 2015, 2月 25 普通にコロンイコールって呼んでた— 辛子明太子 (@pastak) 2015, 2月 25 本当はなんて読むのが正しいんですか． [追記] 今Pascalの本を確認したら「定義子」ではなくて「代入演算子」と書いてあった……これを

git grepが便利なので，同じ感覚でag (The Silver Searcher)を使ってみたいという話です．何事も速いほうが良い． 前提 ぶっちゃけagは，デフォの状態で.git/以下の内容や.gitignoreに書かれてるファイルやディレクトリなんかを検索の対象から排除するのであんま旨味は無い． 方法 以下のエイリアスを張る *1．もちろんconfigファイルを直で編集しても良いです． $ git config alias.ag '!git ls-files | xargs ag'git ls-filesを使って，gitで管理されているファイルの一覧を持ってきて，xargsを使ってagに渡してやるという感じ． 実際僕はこれで十分なんですが，表示と挙動をgit grep(1)っぽくしたい場合は以下のようになるでしょう． $ git config alias.ag '!git ls-

そういえば昨日「ピクシブ株式会社」って言おうとして3回くらい噛んだ気がする— プリントゴッコ (@moznion) 2014, 7月 5 ページャNight，僕が当初想定していたよりも1000倍位有益な会になって本当に嬉しかったです．あとで記事等書きます．— プリントゴッコ (@moznion) 2014, 7月 5 録画したustの様子はこちら http://www.ustream.tv/recorded/49544381 ページャNight <[1]> on Zusaarというイベントを開催致しました． 実に冗談みたいな理由から興ったイベントでしたが，ページャ (ページネーション) というWebサービスの1コンポーネントに焦点を絞った非常に濃厚かつ興味深いトークの数々を聞くことができて，非常に良い勉強会になったと思います． 以下，発表の一覧です． 15分トーク @mizchiさん お前

これはポエムです (It's just like a unko)． ■ 「なぜコードレビューをするのか」という問いに対する答えは様々だ．コードの品質を上げるため，コードレビュー自体が楽しいから，あるいはコードレビューやってる俺たちって恰好良いじゃん，などなど色々ある． これらは全部正しいと思う．コードレビューをすればコードの品質が高くなる可能性は強まるだろうし，「コードレビューが楽しい」という感情がコードを書くための原動力になるのであればそれは良いだろうし (なぜならコードレビューをするにはレビュー対象たりえるコードが必要だ)，「コードレビューやってる俺たちって恰好良いじゃん！」というのも結構だ．貴方がたは本当に恰好良いヨ！ さて，コードレビューという話題に必ずついて回る尤もらしい理由の1つである「コードの品質向上」について考えたい． なぜコードレビューがコードの品質を上げるための手段とし

去る2014年1月27日にNHK番組表APIが公開され，これが中々良い感じだったので，PerlからそのAPIを触れるクライアントであるWWW::NHKProgram::APIを書きました． https://metacpan.org/release/WWW-NHKProgram-API https://github.com/moznion/WWW-NHKProgram-API このモジュールを使うと，NHK番組表APIが提供している 地域，サービス (いわゆるチャンネル)，日付の指定による該当する条件の番組リストの取得 地域，番組のジャンル，日付の指定による該当する条件の番組リストの取得 番組IDの指定による該当する番組情報の取得 地域，サービスの指定による，現在放送中の番組情報の取得 の機能を利用することが可能となります．APIの詳細に関しては以下を参照してください． http://api

幸運にもはてなインターン2013に参加する機会に恵まれましたので、謹んで参加して参りました。 「参りました」っていうのは、「精神的に参ってしまいました」とかそういう意味合いではありません。謙譲語です。 (非常に遺憾な事に、他のインターン参加者のブログを見ると、僕が精神的に参っている人のように描かれているので) さて、本エントリの前半でははてなインターンの全般の話を取り上げます。が、このへんは他のインターン参加者のブログの方が詳しいし丁寧だと思うので、そちらを読むと良いでしょう。本エントリではできるだけ技術的な部分 (というか、開発プロセスのあたり) に触れて行きたいと現時点では考えていますが、スピリッチャルな内容になるかもわかりません。 エントリの後半は与太話です。それは例えばソフトウェアエンジニアの話かもしれないし、漫画家の話かもしれないし、サラリーマンの話かもしれないし、あるいはそう、

Vim (ビムとも言う) の話です。 さて複数人で Git を使いながら開発していると、ファイルの conflict って頻繁に起きるので、もう皆さん conflict とは仲良しこよしのことと存じます。 大体のひとは、conflict してしまったファイルをエディタで開いて修正すると思うんですが、*1 いちいちターミナルで git statusとか実行して、その結果を見ながら「どのファイルが conflict しているか」を確認して、 エディタで該当するファイルを開いて *2 修正するのってちょっと面倒臭い感じがしますよね。 やはり開発するひとも人間ですから、 「どうせだったら、エディタが conflict しているファイルをピックアップしてきてくれれば良いのに……」 「そうすれば、いちいち git のコマンドをタイプする必要がなくなって、エディタから直接ファイルを開けるのに……」 とい