投稿

2016の投稿を表示しています

エンジニアの妻になってしまった我が妻には感謝している

この記事は妻・夫を愛してるITエンジニア Advent Calendar 2016の21日目です。

前日はtamootさんでした。

はじめに
パートナーを愛してる話ということですが、圧倒的感謝しかないです。死ぬ。感謝で死ぬ。ほんとに。

昨今のインターネッツは生きづらいので、本当は3倍量くらい書いてましたがシンプルな感謝状になりました。インターネット滅びろ。
感謝
そんなインターネットで出会い、それからお付き合いしたのが日韓ワールドカップ後くらいからなのでもう14年のおつきあいになりますか。出会った当初はお互い学生でしたし、今のような職業に就くとは思ってませんでしたね。
働き始めてからの二人の夕食については、基本的に僕が作るスタンスで生活してきました。これは妻が偏食であること、また食に対してもともとはあまり能動的でないことなどから生まれたスタイルで、かつてマウントレーニアのカフェラテを夕食と言い張り、キャベツしかまともに食べられる野菜がなかった妻が今ではある程度サラダやトマトソースなども口にできるようになったことを考えると大いなる進歩を感じます。これは逆に感謝されたい。されたい。してくれ!!!
とはいえ、いくぶんかの家事をこちらで引き取ってはいても、なにぶん僕が仕事でコード書くのに熱中したりしてて夜遅めの生活になっていて、妻には日々の生活において主に子供関連で負荷がかかっていて申し訳ないなぁと思っています。いつも苦労をかけています。ごめんなさい。本当にありがとう。

いつも夫婦ふたりともおふざけ野郎なので、とりとめなく延々とふざけているのですが、このやり取りに本当に癒やされています。最近は子供が輪をかけてふざけ野郎なので、その点は割りと心配していますが、避けられない運命ではあるので、彼がふざけを極めたければ極めれば良いなと思っていますし、それを二人で見守ることができれば最高ですね。僕だけかもしれませんが。
最後に
スイート10は難しいかと思いますが、来年も何度かネックレスをプレゼントできるようにがんばりますのでご容赦ください。温泉旅行にでも行きたいですね。ありがとう。

明日はsakanatechさんです。楽しみですね。

2016年にgoを使ったのでまとめ

あ、怖いな怖いな、穴埋めたいなーと思っていたのでつらつら書いて埋めたいと思います。

はじめに
この記事はGo Advent Calendar 2016の10日目であるべき投稿だったようです。

2015年からgoやりたいなーと思っていましたが、今年の4月に転職してから思いがけずgoでWebAPIなどを書く仕事を色々やらせていただけたので、良かったもの/こと、仕事をする上で自分でつくったもの、などについて書きます。


良かったもの
仕事で作ったものはWebのAPIだったり社内の他のシステムにキューイングするライブラリだったりと、そんな小難しいものは作っていないので箇条書きに
goaginkgogo-bindatazgok この辺のライブラリやWAFには非常に助けられました。最初はgojiを利用して、それをechoでまるっと書き直したりしていたのですが、ドキュメントを書くのが面倒なのがきっかけで今年後半に新しいものを作るときはgoaを利用してみて、非常に良かったです。最初にDSLで設計を書くのが大変ですが、慣れれば設計の楽しさみたいなものも感じられる良いフレームワークではないかと思います。
テストは最初conveyを使っていましたが、もうちょっとSpecに近いテスト記述をしたかったので途中からはginkgoに切り替えています。Ωは使わずに、Expectで書いています。conveyはブラウザでテストがグルグル回るので楽しいです。自動でぶん回してほしい人はconvey使ってみてください。
最後のgo-bindataとzgokは両方共静的ファイルをバイナリに含めるためのライブラリで、少しアプローチが違います。
go-bindata → 静的ファイル群を.goのファイルに変換するzgok → ビルド後のバイナリに静的ファイル群をZIPアーカイブとして追加する go-bindataだと変換後のファイルをcommit資材に入れるかどうか迷ったりして、ちょっと迷ったりするのですが、テスト用のファイルだけcommitしておいてその後はビルド直前に再度変換をかけたりするようにjenkinsなどでシェルを書くことで対応しています。 ビルド前後に何か書く前提であれば、zgokのほうがcommitとしては悩まなくて良いので個人的には好みです。

自分で作ったもの
github.com/deadcheat…

echoのロギングでlogrusを利用するための何かを更新した

主に社内の一部アプリケーションでechoを利用していて、内部のログ処理をすべてlogrusに移行したいなと思い、以前表題のミドルウェア?を作ったのですが、いつの間にか依存ライブラリに変更が入っていてコンパイルエラーを起こすようになっていたので修正しました。

github.com/deadcheat/echologruslogger

特にreadmeとかも整備してなくて、わかる人向けという感じです。
glide経由で落としてこられることは確認済みなので、echo使ってる人はどうぞ。

金曜に修正した内容は、gommon/logのエラーレベルの定数からFATALが消えたので、合わせて利用箇所を削除したのと、Conveyでテストを書いていたのをGinkgoに変更して、少しだけリファクタリングしたくらいです。

goは小難しいことを考えないほうがうまくいくような気がしていて、こういった修正は非常にスピードよく行えるように思います。

分かる人だけに向けた何かのサンプルを2つつくった

以下のものを作った


Sparkをスタンドアローンで立ち上げたときにSparkプロセスに食わせてウェブアプリを起動して、内部で検索を行うアプリケーションのサンプルみたいなものHadoopStreamingを想定したElixirでのMap/Reduceライブラリのサンプル実装
それぞれ
https://github.com/ginshari/firstsparkapp
https://github.com/ginshari/vessel_sample
にPUSHしてある。

雑兵MeetUpというコミュニティについて

コミュニティ界隈が無駄に被弾してざわざわしています。 今回のように、流れに乗っかって方向性をある程度示すのが本当に正しいことかはわかりません。 かと言ってCoCで縛ることはより一層したくないことですし、私見を述べる以上の意味は無い程度でブログに書いておきます。 はじめに 雑兵MeetUpの始まりに私の方から説明してる会の説明の資料はこちらです
雑兵MeetUpについて
まぁこの会自体が、「普通の勉強会に行くのいしんどい人でもゆるく参加できるようなコミュニティ」を目指しているのはこれだけで伝わってほしいんですが、一応そういう方向を目指してます。
雑兵MeetUpにおけるアウトプットに関する指針
アウトプットに関しての指針とかそういうのは今まで正直考えたこともなくて、そもそも僕自身が変なコンテキストのLTとかいろいろたくさんしてしまっているので、今更人にどうこう指針を示せるわけが無いですね。
あえて意識して言っておきたいなぁというのは
「雑兵MeetUpでは、どんなコンテキスト、どんな内容でも喋っていい」

ということです。
アウトプットされたもの、発表者について尊重したいと思っています。
詳細
ハラスメントポリシーに反しない限りは、スライドの内容がどういう内容であっても、公開資料をどうするかについては公開及び発表内容のシェアの可否も含めて個人の判断を尊重します。 すなわち、 発表スライドに対する撮影/シェアなどの行為の可否発表内容に闇成分(とよんでいます)が含まれる際の事前告知発表内容が含むコンテキストの内容 これらについて、ハラスメントポリシーに反しない限り全て発表者の裁量を尊重します。上記にすしる行為が参加者にて行われ、発表者が困った事態になるときに糾弾されるのは発表者ではなく上記に反した参加者となるべきと考えています。
また、 発表はこうあるべき○○するコンテキストは避けるべき というような、コミュニティ・アウトプットについての方式論、お作法についての指摘については、雑兵MeetUpでの発表においては以下を除き一切を拒絶します。 ハラスメントポリシーに抵触する内容であることの指摘 それらの意見については多大に理解を示しますが、そういった制約コンテキストから遮断された状態をよしとするのが雑兵MeetUpというコミュニティです。
参加者の方には、拙い発表でもいいので、そのと…

vue-bulmaと太陽と埃の中で

土日潰して謎を解決したので書いておこうと思います。

TL;DRvue.jsで使えるbulmaのコンポーネントをnpm installサンプルコード通りに入れたけど何も起きないnpm installだとpackage.jsonのバージョン指定が^1.0.0になっているけど、サンプルで使われてるリポジトリのpackage.jsonだとgithubの最新とるようになってるのに気づくそこ書き換えると\(^o^)/ウゴイタ!yarnめっちゃ早いやーん はじまりはいつも雨 個人でアプリケーション作ろうと思って、テキストエディタを入れようと思ったので、いい感じにごちゃごちゃ考えないで使えるBulmaを使ってるコンポーネントを使おうと思ったわけです。
github.com/vue-bulma
伝わりますか ギフハブに監視されてるかどうかはよくわかんないですけど、まずこいつを使い始めるにあたって、幾つか問題がありました。 普段vue-cliを使って最初の雛形を作成しているのですが、それを使っていると一部のコンポーネントがビルドできなかった見た感じwebpack2を使っているとうまくいきそう手元のvue-cliのwebpackテンプレートはvue2-webpack1なので上手くいっていないのかもしれないシンプルな形でvue2-webpack2を導入するためのテンプレートが見つからない ということで、まずはvue2-webpack2の組み合わせで開発が出来るように整えるひつようがありました。 vue-bulmaのコンポーネントのデモサイトを完全に参照して作業を行っています。 github.com/vue-bulma/vue-admin なぜに君は帰らない この作業自体はそれほど難しいものではなく、webpackが起動するときのチェックエラーが何が問題なのかよくわからないエラーを吐く以外は上記のvue-adminのビルドスクリプトを参考に手元で修正を行ったので問題なく終わりました。 そして、もともと利用しようとしていたvue-bulma-tabsを追加するタイミングに至るのです。
github.com/vue-bulma/tabs
readmeを見ると
npm install vue-bulma-tabs --save
を実行するようになっているので実行し、サンプルコードを動かしてみましたが、肝心…

思ってることを幾つか

書こうと思っていたんですが、結果1個になったブログ

長文を書くことに対して思ってること ブログとか長文ってめっちゃ書くのしんどいし、コメントとかつくとなんとも思ってなくても割りとメンタルには響くので、自分は大丈夫、自分は平気、そう思ってる人も、長文書いたら少しリアルワールドで気晴らししたほうが良いかもしれないなぁってずっと思ってる。長文とは関係ないけど個人的にもうTwitterワールドは地獄インターネットなので自分用のつぶやきSlackか自分用SNS作って引退したいと思ってます。ギフハブ。
やっぱあのクラウドソーシングで記事書くみたいなタスクも少しだけやったことあるんですけど、あれはウォッシュレット完備のトイレでうんこするだけなんですよ。ポチャンつって、お釣りも返ってこないくらいスッキリ、ダブルのトイレットティッシュも完備されてて。精神的な話ね。 で、自分のブログとかに長文書くのって、特に仕事以外で書いてる場合のほうがそうかもしれないですけど、路上でウンコを出そうとしてるときぐらい気を使うと思ってて。ただの例えですよ、ただの例え。でも想像してみてほしくて、路上でうんこしなきゃいけない、ってなったら、めっちゃ気をつけません?ズボンにウンコつくかもしれない。ズボン下げたときにポリスに声をかけられるかもしれない。ビチャビチャだったらどうしよう。そんな風に神経質に考えながら書かれてるのが長文のブログだと僕は思います。
現に、こんなウンコの話してる文章と、本来だったら前後に2倍位の分量で書いてた文章を、僕は3回全部消して書き直してるんです。残ったのがこのウンコですよ。ほんと馬鹿馬鹿しいと思いますよね。でも、長文書くのってそういうことなんだと思うんです。だからみんな気をつけて長文書いてください。自分を大事に。
何が言いたいかっていうとそういうこと。長文書くとき結構ダメージ負ってるから。無理せずに。心配してます。

人はいつまでもウンコを投げるのか

ウンコ投げは文化カレー、カレー味のウンコ、うんこ味のカレー、などなど、カレーにまつわる何かをお楽しみの途中でのご鑑賞はお控えください
IT業界に携わる人が発信する場(ブログ、Twitter、Facebook)では月に1回はウンコ投げ事件が発生しています。頻度についてはもっと多いかもしれません。週に1度くらいでしょうか。

例えば、もううんざりするほどSIerやエバンジェリストはウンコ投げられ続けますし、なんならちょっと変なスライドで発表しただけでもウンコまみれ。んでもってウンコ投げられた人たちも黙っていられずにウンコ投げ返してますので、右も左もウンコまみれ、上上下下右左右左便便みたいな状態です。

もはやウンコ地獄。
この辺もインターネットの地獄インターネット具合が顕著に出ていてこれはこれで趣深いのですが、ウンコの投げ合いは常に同じ構造で出来ているのがテンプレートなやり取りを愛する日本人としての文化性が非常に出ているのでとても美しいように思いました。
要するに 誰かがうさぎのウンコみたいな取るに足らないウンコを投げ始めるいのべーたー()の皆さんがうさぎのウンコを投げてるひとを目ざとく見つけるあーりーあだぷたー()の皆さんが「きったねー!みんなみんな見てみろよ!あいつウンコ投げてるぞーうぇえええーーーー」とか周りに触れ回るあーりーまじょりてー()の皆さんが 「うんこを投げつけることは一般的に考えてよくないことだ」「そもそも彼が投げつけているものはウンコではない、かりんとうだ」「ウンコを投げつけられたものがウンコを食べずに今まで生きてきたのが悪い」 といった、謎のオレオレ分析と批評などを展開し始める れいとまじょりてー()、らがーど()の皆さん(このブログも含む)が、 「この問題はそもそもウンコが投げられる形状であることに問題がある」「そもそもウンコなどドコにもなかった」 などのような、より俯瞰(≒上から目線)で見た()謎の分析と個人の感想レベルのまとめを書き始める 飽きて解散 このようなフローでいつもウンコの投げ合いは陽が登っては沈み、を繰り返している印象しかないですね。私も皆さんもどこかのタイミングに参加しては、一生懸命ウンコの伝搬をしていると思います。 ちなみに上記の箇条書きにおいてマーケティングの単語を使ってるのは適当になんとなくそうしただけなんですが、そういえば…

採用とは何か

予防線
以下の文章は、妄想と妄言です。感想を語りたい場合はご自由にどうぞ。
本題の前に 以下に該当する方はタブ閉じて寝てください、そこまでして読む価値はありませんし、本当にあなたとわたしの時間の無駄になります。今「予防線張るんじゃねえよ」って思った人採用なんか別に興味ない人現実と妄想の区別がつかない方インターネッツポエム耐性のない方結論がはっきりしてないと読む価値が無いとお考えの方 はい、皆さんそれではまず、「ctrl+w」か「⌘+w」を押してみましょう
はい。

はい。

はい。

まだ見てる人へ
なんて偏屈な人なんでしょう。僕は心配ですよ。 はい、僕に言われる筋合いないし大きなお世話ですね、はい。 「イタいな」とか思った時点ですぐ画面消して寝てくださいね。

【過去記事】求職者を背中から撃つ採用(「以前お勤めの企業にお話を伺ってみました」のアンフェア感)

はじめに もう一個過去記事を起こす
---

最近採用のことをよく考えるのでまたそれ系列。いい加減エンジニアリングのこと書いたほうが良いんだけど。
「以前お勤めの企業の方にお話を伺ってみましたところ、あまり評価が芳しくなかったので今回は貴意に添いかねる結果になりました」
世の中にはこういうパターンでお祈りされることがあるわけです。僕も1、2回。人から聞く話でもたまに出てきますね。
これこっそりやってる会社そもそも先に教えてほしい。場合によっては面接に行く時間と交通費が無駄になるのでこちらからお断りするし。
ヒアリングの持つ意味 主に採用企業側のメリットかな、
前の職場で事件・事故を起こしていたら分かるどういう人間だったかよく知る人に聞くことができれば、面接時にうかがい知れなかった人となりを知ることができる。 といったような、予防線のような部分。
反対にデメリットは、
聞いた相手がよく知らないのに適当な評価を答える場合がある聞いた相手との関係性などにより、最終的な判断にノイズが混ざる こんな感じ?
なんにせよ、こういったヒアリングを行う場合、以下のようにしないとフェアじゃないですよ。
誰に、どのようにヒアリングするかを求職者に伝えるあるいは、ヒアリングしてほしい人間を求職者から挙げてもらう単純にその企業に在籍している「知り合い」にヒアリングするのではなく、知り合いを経由して中立的な立場の方を紹介された上でヒアリングする 一番最初の誰に、どのようにヒアリングするかを求職者に伝えるということだけは絶対やってほしい。
これをやらずに「ちょっとあの会社知り合い居るわ^^聞いてみよ」みたいなことをやっちゃう奴が採用に絡んでる企業は採用失敗する。てか失敗しろ。
なぜヒアリングのことを求職者に伝えなくてはいけないか それを公表し、企業と求職者のお互いが把握することで、以下の効果を期待するからです
あらかじめヒアリングを行う企業であるということがわかっていることで、やましい部分のある人間が応募しなくなる やべえことやってる自覚があったら応募しなくなるし、手間が省ける可能性
ヒアリングの場を公式なものに変える 裏でこっそり聞いてみるというような場合、その場所はもしかしたら大衆居酒屋かもしれないですよね。
人の採用をそんなノリで決めるわけ無い?そんな風に思ってる人はちょっと考えなおしたほうが良い…

【過去記事】「採用力」への違和感

はじめに 採用側の話について、以前のブログに書いたこと。
---
以下は数値とか出せない完全に僕の肌感なので、異論は知らない。議論はいいんじゃない。
ここ最近、企業の「採用力」なるものが注目されているように思っていて、企業の採用力を高める手法だとか、面接をどのように進めていくかであるとか、そのような内容のセミナーも増えてきているなぁと感じます。
私は企業が採用に着目して力を入れている事自体は歓迎すべき事柄だと思うけれども、「採用力」という言葉自体には正直曖昧さがあるし、「採用力の高さ」を企業が大々的に言い出すこと自体には割りと違和感を感じる。
そもそも「採用力」ってなんだろう 「採用力」自体の意味を統一的に定義されているのを見かけないのでそれはそれで腹立つんですが、恐らく以下の様な点に集約されるのではないかと思う。
企業が求める人材を採用する力優秀な求職者を見極める力企業にフィットする人材を見極める力 ここまでは別にいい。わかる。
その一方で、
企業が優秀なスタッフを大量にかき集める力企業が設定した採用人数のKPIを達成する力 というふうな意味合いで捉えている会社さんも多い。
恐らく冒頭で述べた違和感を感じるのは、こちらの意味寄りに捉えている企業が増えてきているということなのではないかと思う。
更に前者と後者それぞれのパターンに、さらに各企業の採用への積極性も絡んで、一口に「採用力の高い企業」と言っても、求職者から見ると「なにがなんだかよくわからない」状況にあるように思うのですが、企業側はそれに気づいていないのでは、とか考えてもいる。議論自体に違和感があるのはその部分も大きいかもしれない。
この辺までまじめに書いたけど疲れた
意識高くするのに疲れた人から見て感じること「採用力」関連の話って、企業側の理屈でしか言ってないですよね。あくまでもいろいろ転職してる人の話聴いたり、僕自身割りと長く転職活動してる中での感覚ですけど、「少し時間を掛ければフィットしてバリューを発揮してくれるかもしれない」レベルの求職者はリスクとしてカットされるわけです。頑張りたいと思って面接を受けに来ていても入社できない。逆に採用人数にKPIを持ってめちゃくちゃ採用してるところは、「とりあえず採用して」頑張らせてみてダメなら捨てるみたいなマインドの会社さんも多いので、チャンスフルですがミスマッチも…

goaでgo-bindataを利用してバイナリ化した静的ファイルを表示させる

やりたかったこと タイトルママ。
goaでは静的ファイルをサーブするためにFilesというDSLが用意されているが、これを利用しても、自動的にgoaアプリケーションのバイナリに静的ファイルがビルドされるわけではないので、サーバープロセスにとしてバイナリを起動してもファイルへのアクセスは404となってしまう。これを解決したかった。
成果githubにサンプルリポジトリを作成済みです リポジトリ名:goabinsample やったこと ゴール:今回は、ひとまずSwaggerUIのファイルへのアクセスをさせるようにしてみます。通常通り、設計ファイルを作成する。goagen bootstrap -d goabinsample/design別途swaggeruiを取得し、適当なディレクトリに配置(サンプルでは、/swaggeruiディレクトリに配置)この時点で、swaggerのファイルへのパスに対してDSLを通してさえいれば、go run による確認は可能参照させたい静的ファイルをgo-bindataで.goファイルに変換5で作成したファイルを利用してファイルハンドリングを行うファイルハンドラを返却する関数を作成(サンプルではこのファイル)goagenから自動生成されたcontroller.goを参考に適当なファイル(今回は自動生成されたmain/swagger.goに追記した)に、Controllerをマウントする関数を作成する。(参考:このファイルのfunc MountSwaggerControllerのみ追記した)自動生成された状態では、mainはapp/controller.goに生成されたapp.MountSwaggerControllerをコールするので、それを7で作成したMountSwaggerControllerを呼ぶように 修正する。一通りの作業を終えていれば、これでもうgo-bindataのデータを表示しているはずである 以上!!!!! キレイにやろうとすると、色々手間も掛かりそうなので、一旦ここまで!!!!
サンプルリポジトリ

GoのWAF「goa」のCORSヘッダ処理用Middleware「goacors」を作った(パクった)

概要goaというフレームワークを直近利用しているがすごく良いが、CORSヘッダの処理をデプロイ環境ごとに変えようとすると手間がかかるMiddlwareをechoのMiddlewareからほぼコピーして作ったgithub.com/deadcheat/goacorsとして公開したのでエントリを書いた 構成 素のgoginkgoでテストtravis-ci, coveralls.io 感想 まぁgoagenにまかせて、毎回ビルド前にすべての変更不可リソースを生成し直すというのが本来のソリューションではないかと思うのでこのMiddlewareに意味はあるんだろうかという思い新しいWAFを使い始めるとだいたいミドルウェア開発おじさんになりがちgoaは、まずドキュメントの元、つまり設計コードをしっかりと書くことが必要となるので、大きな組織のAPIリプレースなどでは非常に力を発揮するのではないかと思います。Swagger用のドキュメントを自動生成してくれるし。作成にあたっては、echoのCORSミドルウェアをまんまパクったので、本当に有難うございましたとしか言えないし本当にすみません。 おわり

GoのWAF「echo」のMiddleware「echorequid」を作った

概要EchoフレームワークでX-Request-IDヘッダを付与するMiddlewareを作ろうと思った作って公開したechorequid構成Echoで動作する想定なので本体にはechoのものしか使っていない
テスト: goconvey + gomock処理の内容defaultの動きとしては以下すでにX-Request-IDがリクエストに付与されていれば何もしないリクエストヘッダのX-Real-IP、X-Forwarded-For、hostportをの順に確認しIPを取得取得したIPをヘッダに追加苦労した点開発自体は、全く苦労しなかったtravis-ciでテストを実行するのに躓いたのと、それをcoverall経由でバッジ表示するまでに無駄な時間を大変に割いた。つらい。 travisでテストするときの知見リポジトリ中の他パッケージを参照する場合、下手にディレクトリ名/パッケージ名でimportしていたりすると、ローカルのテストは通るのにTravisで回すときにImportPathが見つからないとか言われるので、./パッケージ名に修正した。正しいやり方がありそうだがよくわかってないし、そこまでの労力をつぎ込みたくはなかった。ひとまずパッケージを公開するところまで来たのでよしとする

[golang] 続・NullStringを綺麗にJSONエンコードするためのちょっとましになったやり方

前回の丁稚こちらの通り続・目的タイトルの通り。
sql.NullStringはNullableなカラムを引き受けてくれる型だが、そのままJSONに引き渡してもオブジェクトとして出力されてしまう。
これを綺麗にJSONとして出力したかった。綺麗でない例は以下のとおりbefore[{"id":1,"string":{"String":"aaa","Valid":true}},{"id":2,"string":{"String":"","Valid":false}}] after[{"id":1,"string":"aaa"},{"id":2,"string":""}] 方法Null*型をJSONに引き渡して好きなかたちで出力したい場合、MarshalJSONを自分で実装すれば良い。問題はSQL実行後のScanでアサインされないことだった。前回はここで糞長いコードを書いていた。よくわからなかったので、値をバインドする部分はコアのコードを丸コピして持ってきたfuncをコール。つまり手抜きである。今回は前回のコードを少し綺麗にした。実装ソース一旦ベタで貼る。短縮できる方法は試してみるが、考えるのが面倒だったのでconverterそのままコピペした。完全に良くない。// localtype パッケージ // アプリケーションローカルの型はここに格納したい package localtype import ( "database/sql" "database/sql/driver" "encoding/json" ) // type OptionalString // sql.NullStringのラッパー type OptionalString sql.NullString // func (o *OptionalString) Scan(value interface{}) error // …

golangでStatementのOpen/Closeについて軽く調べた

目的StatementはいつOpen/Closeすべきで、あるいはStatementをsql.Db.Prepareで生成せずにQueryを実行したほうが早かったりするのか、そのへんのことを計測してみようと思ったんだ。検証コード以下の様な感じ。もしかしたら変かもしれない。
ほんとはdeferでcloseする、とかそういうのは割愛ddlMySQLでやりましたCREATE TABLE `test`.`testtable` ( `id` INT NOT NULL AUTO_INCREMENT, `nullable` VARCHAR(45) NULL, PRIMARY KEY (`id`)); ソースコードpackage main import ( "database/sql" "log" "time" _ "github.com/go-sql-driver/mysql" "flag" ) const QUERY = ` SELECT t.id, t.nullable FROM test.testtable t WHERE nullable is not null AND nullable like ? ` func main() { var c = flag.Int("c", 1234, "help message for f") flag.Parse() db, err := sql.Open("mysql", "root:password@tcp(localhost:3306)/test") if err != nil { log.Fatalln(err) } defer db.Close() Exec(db, *c, "%") } func Exec(db *sql.DB, counts int, words string) { log.Printf("%d 回実行 開始", counts) st…

NullStringを綺麗にJSONエンコードするための稚拙なやり方

目的タイトルの通り。
sql.NullStringはNullableなカラムを引き受けてくれる型だが、そのままJSONに引き渡してもオブジェクトとして出力されてしまう。
これを綺麗にJSONとして出力したかった。綺麗でない例は以下のとおりbefore[{"id":1,"string":{"String":"aaa","Valid":true}},{"id":2,"string":{"String":"","Valid":false}}] after[{"id":1,"string":"aaa"},{"id":2,"string":""}] 方法Null*型をJSONに引き渡して好きなかたちで出力したい場合、MarshalJSONを自分で実装すれば良い。問題はSQL実行後のScanでアサインされないことだった。実装取得元テーブルサンプルなのでIDとNullableなカラムがあればよいCREATE TABLE `test`.`testtable` ( `id` INT NOT NULL AUTO_INCREMENT, `nullable` VARCHAR(45) NULL, PRIMARY KEY (`id`)) ソース一旦ベタで貼る。短縮できる方法は試してみるが、考えるのが面倒だったのでconverterそのままコピペした。完全に良くない。package main import ( "database/sql" "encoding/json" "os" "database/sql/driver" _ "github.com/go-sql-driver/mysql" log "github.com/Sirupsen/logrus" "fmt" &qu…

RustでTwitterAPIを叩く

目的Twitterを監視するバッチ、厳密に言うと「自分のツイートを監視して一定のフィルターに該当するものをすべて削除していくバッチ処理」を必要としており、せっかくなのでRustで構築しようと思った
今回のゴールTwitter-APIをコールするライブラリ自体はすでにCratesに存在している。目的を達成するには、APIが足りていないが、今回はまずこのライブラリをコールするところから始める。また、利用方法についても基本的にはGoogleでヒットするが、そのまま紹介してもつまらないので以下のような流れを実装する認証URLをブラウザで勝手に表示させるコールバックURLをローカルホストの指定ポートに向くようにしておき、そのURLを処理上で受けられるようにironでオープンしておく認証ページで認証したあとのコールバックを、認証URLを開いたプロセス自身で受け取り、取得したアクセストークンを利用してツイートを行うプロセス自身をすべて破棄して終了事前準備プログラム以外に準備するものは以下のとおりTwitter Application Managementでアプリケーションを登録、consumer_key及びconsumer_secretを取得しておくこと上記アプリケーション登録において、コールバックURLをローカルまたはRustプログラムを起動するサーバーのURLなど、コールバックを受けるURLに正しく設定すること。筆者は、http://127.0.0.1:8943/callbackとした。利用ライブラリCargo.tomlを参照したほうがわかりやすいように考えたので以下の通りとする[package] name = "tweet" version = "0.1.0" authors = ["deadcheat"] [dependencies] aurelius = "*" iron = "*" oauth-client = "0.1.2" twitter-api = "*" urlencoded="*" aureliusがURLをオープンするために利用するcrateこういうネーミングは正直好みだ。実装最新状態はGistに…

カレーを作りながらGitHubの使い方を考えた話

発端
ちょっと前にgit rebaseの話をする機会があった
僕がカレーを作った

つまりどういうことか

カレーを作る際の流れは、GitHubで開発するときの流れのExampleとして機能するのではないかと思った、ただそれだけのこと。

諸注意

雰囲気で楽しんでるだけなので野暮な突込みとかしないように

前提

curryリポジトリを作成し、以下の2ブランチが存在しているとする

master(食卓)
develop(キッチン)

ここから調理開始

キッチンでカレールーを作り始める

キッチン(developブランチ)でカレールー(ブランチ)を作ろう

git checkout -b curryroux

鍋にオイルを塗り、玉ねぎを炒める

issue #1 として起票したのち、 オイル、玉ねぎに相当するファイルを追加

git commit -m 'add oil and onion. close #1'

その他の野菜、肉を加え、水を入れ、煮込む

issue #2 として起票。
ISSUEをもとにファイルを追加、あるいは修正

git commit -m 'add carrots, pork, beans and some corns, then add water. close #2'

煮込んだらルーを溶かす

issue #3 として起票。
勝手なイメージ的にはテスト書いたり、リファクタリングする

git commit -m 'add roux and seasoning. close #3'

キッチンに皿を用意する

つまりキッチン(developブランチ)に皿(dishブランチ)を追加

git checkout develop && git checkout -b dish

皿にご飯を盛る

issue #4 として起票。
別ブランチでフィルタークラスとかその辺を準備してるのをイメージするといいかもね

git commit -m 'add rice to dish. close #4'

ご飯を持った皿をキッチンに用意

ここでキッチン(developブランチ)にご飯をもった皿を置く

git checkout develop && git merge dish

もしかしたら、お手伝いさんがいるかもしれ…