Mac上にGoの開発環境を構築する〜下準備編 | おそらくはそれさえも平凡な日々
同僚がGoを始める上で、案外まとまった資料が無さそうだったので書いてみることにしました。 Macでhomebrewが入っていることが前提です。事前に brew update をおこない formula を最新のものにしておくと躓くことが少ないでしょう。 Goのインストール % brew install go エントリ執筆時点では、1.6.2 が入ります。Goはメジャーバージョンが同じ場合は、後方互換が保たれているので、基本的に新しいやつを入れて問題ありません。 環境変数の設定 $GOPATH だけを決めればOKです。$GOPATH はどこでも良いのですが、ここでは $HOME/dev を $GOPATH に設定します。また、 $GOPATH/bin に $PATH も通しておきます。 export GOPATH=$HOME/dev export PATH=$GOPATH/bin:$PATH
より良い `go run` を実現する goshim | おそらくはそれさえも平凡な日々
https://github.com/Songmu/goshim プロジェクトでちょっとしたスクリプトを書いてリポジトリで共有したいとなった時に、スクリプト言語なら楽ですが、Goで書くのはやや面倒です。リポジトリを分けるようなものでもないし、わざわざ go install させるようなものでもないけど、ビルドしたバイナリをどこに置くのかなどが悩ましい問題です。macを使っている人もいればlinuxを使っている人もいるのでバイナリをリポジトリに配置するわけにもいきません。 go run でも良いかと思われるかもしれませんが、本当にちょっとしたものならよいいのですが、以下の様な問題があります。 複数ファイルになった時に go run main.go hoge.go とかやるのがダルい (% go run $(go list -f '{{join .GoFiles " "}}') [args..
ISUCON5で優勝してきました | おそらくはそれさえも平凡な日々
毎回素晴らしいイベントを主催されているLINE株式会社様、毎回ホスピタリティあふれる運営に尽力されている@941さん、出題の@tagomorisさん@kamipoさん、その他協賛企業や運営スタッフの皆様に感謝申し上げます。 ということで、ISUCON5に出場し、優勝してきました。 ISUCON1の優勝チームの再結成で @fujwiara, @sugyanと僕というメンバー構成です。4年前のISUCON1の時にチーム名を「fujiwara組にしよう」と強く言ったのは実は僕で、そのまま僕が代表者として申し込んだのですが、まさかここまでfujiwara組ブランド(?)が定着するとは思いませんでした。今年もfujiwaraさんの力が大きい勝利ですが、僕も大分貢献できたと思います。 ということで当日を振り返ります。 お題 外部APIを叩くネタで驚いた。可能性は考えていましたが、まさか来るとは思ってい
#ISUCON 5の予選をトップ通過してきました | おそらくはそれさえも平凡な日々
雑に稼ぐにはPerlはサイコーだぜ tokuhirom 主催のLINE様、毎年ありがとうございます。GCP使いやすかったです、Google様もありがとうございました。 さて、いつもながらfujiwaraさんと組んで1位を取ると、つい自分がすごいと錯覚してしまいそうになるのですが、すごいのはfujiwawaさんであって「僕ではない」ということを強く意識しないといけない。 とはいえ、久しぶりにfujiwaraさんと組んで、自分がどれくらい戦えるのか楽しみだったのですが、以前優勝させてもらった時よりも自分としては大きな手応えがあり、僕もfujiwaraさんと組ませてもらって恥ずかしくないくらいの実力はあるなと思いました。 今年のISUCON予選は、とにかくやることが尽きず、ずっと手を動かしながら改善を続けられる楽しさがあって、疲れましたが充実した時間を過ごすことができました。最近仕事でコード書く
ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
何故僕はエンジニアとして対外発表をするのか | おそらくはそれさえも平凡な日々
僕は本来、人前に出て積極的に話そうとは思わないし、目立たずにおとなしく引きこもっていたいみたいな気持ちがある。潔癖な部分もあるので、プレゼンスばかり高くて技術力がないような中身が無い人間になりたくないし、そうなったら死ぬしか無い、みたいな気持ちもある。それなのに何故、ものすごく技術力があるわけではない自分が対外発表をするのか。 それは元はと言えば対外発表をするような側に行かないとエンジニアとして生き残れないのではないかという危機感があったからです。 Shibuya.pmの衝撃 初めて参加したShibuya.pmは#10だった。その頃の僕は一企業のよくある何でも屋の1人システム担当であり、開発のメインは前担当者から引き継いだレガシーASPだった。そしてつぶしの効く技術を習得したいと思いPerlを学び始めた頃だった。そしてPerlがそこそこ書けると手応えを感じ始めているところだった。 ところが
コマンドラインツールを作るときに考えているちょっとした設計方針 | おそらくはそれさえも平凡な日々
個人的にPerlでもGoでもRubyでもコマンドラインツールを作るときに考えることの一つに以下がある。 その実装言語からライブラリとして直接呼べるインターフェースを作り、コマンドもそれを呼び出すようにする。 どういうことかというと、最近書いたgo-timeoutの場合、 % go-timeout --kill-after 5 --signal=HUP 10 perl -E "say 'Hello'" は、内部的に以下を呼び出している。 tio := &timeout.Timeout{ Cmd: exec.Command("perl", "-E", "say 'Hello'"), Duration: 10 * time.Second, KillAfter: 5 * time.Second, Signal: syscall.SIGHUP, } exitStatus := tio.RunSimp
Perl ORM ベンチマーク2014 | おそらくはそれさえも平凡な日々
この記事はPerlアドベントカレンダー2014の記事ではありません。 nihenさんのやつをベースに改変しました。 DBIx::Sunnyを加えてみた。DBIx::Sunny::Schemaという隠れた便利機能を使ってみた Skinnyは外そうかと思ったけどちょっと驚きの事実があったので残した https://gist.github.com/Songmu/989f10b2525523914de8 DBI: 1.631 DBIx::Class: 0.082810 DBIx::Skinny: 0.0742 Teng: 0.26 DBIx::Sunny: 0.22 --- insert --- Rate dbic teng skinny sunny dbi dbic 2983/s -- -16% -72% -78% -92% teng 3565/s 19% -- -67% -73% -91% s
ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
GithubのHookについてのまとめとソリューション | おそらくはそれさえも平凡な日々
Githubはpushだったり、pull-requestなりのイベントを通知してくれるHook機構がある。Travisとかもその一環。リポジトリのSettings -> Service Hooksで設定できる。 Hookのイベント設定 各Hookで受け取れるイベントの種類は増やしたり減らしたりすることができる。 例えば、IRC通知の場合だと受け取ることができるイベントは今のところ以下の6種類。 commit_comment issue_comment issues pull_request pull_request_review_comment push その中でデフォルトでONになっているのはpushとpull_requestの2種類。どのHookがどのイベントに対応しているかはhttps://api.github.com/hooksを見れば分かる。 どのようにイベントの追加設定をするか
おそらくはそれさえも平凡な日々: Perl製のWebアプリケーションをherokuで3分で動かすの法
PSGIアプリなら簡単にherokuで動かせます。 Miyagawaさんのbuildpack(https://github.com/miyagawa/heroku-buildpack-perl)を 使います。使い方もREADMEに書いてあったけど、以下にも書きます。 アプリ側の準備 deployしたいアプリケーションのgitリポジトリ上で以下をやります。 cpanm --installdeps . で依存モジュールがちゃんと入るようにする(cpanfile使うのがオススメ) アプリ起動用のapp.psgiを配置する herokuにアカウントを作る https://www.heroku.com/ toolbeltを入れる https://toolbelt.heroku.com/ インストールが終わるとherokuコマンドが使えるようになります。 % heroku login と打ってコマンド
最近のPerlのExporter事情とかExporter::Liteとか | おそらくはそれさえも平凡な日々
結論 use Exporter 'import' で充分 説明 今のはてなでは割と標準的にExporter::Liteが使われている。Liteの方があんま余計なことしないからとは聞いてはいたが、それで依存増やすのもどうなのかなーとか思っていたので個人的にはこれまでExporterしか使ってなかった。Exporterは標準モジュールだし。Exporterにしてもuse parent 'Exporter'なのかuse Exporter 'import'なのかという流儀の違いがあって、個人的にはuse parent 'Exporter'を使っていた。その辺りについて再考した。 ExporterかExporter::Liteか もうあまりExporter::Liteを使う理由はないように感じる。 Exporterの最近のソースを読むと、かなりシンプルになっていることがわかる。 Exporterの複
クソコードに対する怒りとコードレビューにおける人格攻撃について | おそらくはそれさえも平凡な日々
デキるプログラマだけが知っているコードレビュー7つの秘訣 7つの秘訣の1〜5は本当にそのとおりだと思います。 「怒り」って言葉を使っているところはなかなか画期的だと感じた。というのも僕は前から「人格攻撃に思われて」しまうような、コードで人を殴るようなことをしてしまう人が出てきてしまうのは何故かということを考えた時に、そこには「コードに対する怒り」があるからだろうなと思っていたからである。怒りがあるからこそ強く指摘しすぎてしまうことが起こりうる。 「怒り」というのはつまり「感情」である。であれば、「その『怒り』はコードに向けられたものであり、書いた人に対してのものではないので、その人に対しての攻撃ではない」というのは、理屈ではかろうじて通るかもしれないが、書いた人の「感情」的には通らないこともあることは理解したほうが良いと思う。 じゃあ怒らなければ良い、という話にはしたくなくて、どうしても怒
Perlで一枚岩のスクリプトをテスタブルにする | おそらくはそれさえも平凡な日々
Perlで単一ファイルのスクリプトを書くと、すぐに配置して動かせるので重宝しますが、テストを書きづらいのが難点です。 ちゃんとpmファイルに分割して云々とかやると単一ファイルで動かなくなるし、かと言ってfatpackするのもちょっとした用途だったらやり過ぎだしめんどくさい。 ということで以下のように書いてはどうか。 if ($0 eq __FILE__) { main(); } sub main { ... } $0に実行ファイル名が入っているので、それがスクリプトファイル名と一致していたらmainの処理を実行する。pythonのif __name__ == '__main__':みたいな感じ。 このスクリプトをテストしたいときは、普通にテストスクリプトを書いてrequire 'main.pl';とかやれば、plファイルの中で定義されている関数とかが個別に呼び出せるのでそれをテストしてやれ
おそらくはそれさえも平凡な日々: Config::PLというのを書きました
https://metacpan.org/module/Config::PL .plファイルを設定ファイルとして使う時のユーティリティです。以下の様な感じで使えます。 use Config::PL; my $config = config_do 'config.pl'; do 'config.pl'のハマりどころや不便な点を解消しています。doの問題点は具体的には以下の様な点。 config.plにsyntax errorがあってもエラーにならない 絶対パスで指定しないと危ない。doはモジュール読み込みと同じルールでファイルを探しに行くので、@INCを探しにいってしまう。config.plが@INCに置かれているとそっちが優先的に呼ばれる(!) config.plから他のファイルを相対パスで読み込めない これらに対してConfig::PLは、 syntax errorやhashrefを返し
Perlベストプラクティスのベストプラクティスじゃないやつをまとめてみた | おそらくはそれさえも平凡な日々
Perlベストプラクティス Perlベストプラクティス(略してPBP)という良い本があります。僕自身もPerlを学ぶ過程で非常にお世話になった本なのですが、以下の様なことが度々指摘されています。 bestって書いてあるけど「著者の」bestプラクティスなので偏りがあることも 「決して」とか「必ず」とかが多いけどあんま真に受けてはいけない この本を書くために書かれたであろうCPANモジュールとかがあって、しかも公開されてないものまである 致し方ないけど現在の状況にマッチしない古い情報もある なので、PBPの何がベストじゃないのかについてまとめてみることにした。前からやりたかったんだけど、思い立ってやった。 まとめてみたら、思っていたほどには項目が上がってこなかったので、やっぱPBPは良い本だなと改めて思いました。なので、このエントリーがこれからPBPを読む人の助けになれば良いなと思います。
Linuxサーバーのアカウント管理について | おそらくはそれさえも平凡な日々
少人数でサービス開発をしていると、サーバーのアカウント管理を疎かにしてしまいがちです。良くないことだとわかっていながらも、共用ユーザーのログイン情報を数人で共有していたりだとか、rootばかり使っているなんてこともあるのではないでしょうか。 それだとオペレーターが増えたり、退職者がでたりした時に困ることになるので、最初からルールと仕組みを決めておいた方がトータルで楽になります。 前提 パスワードやログイン鍵の共用、ダメ！絶対！ rootを常用するの(・A・)ｲｸﾅｲ!! パスワードやログイン鍵を共用していると、人数が増えた時に誰が作業しているのか把握するのが大変になりますし、退職者が出た時に一斉変更をせざるを得なくなって混乱してしまいます。逆に一部のスタッフを別扱いして権限を制限したユーザーをアドホックに作ったりしてしまうのも管理が煩雑になります。じゃあどうすればよいかというと、個人ごとに
YAPC::Asia Tokyo 2014 に「Perl」のトークを応募しています | おそらくはそれさえも平凡な日々
http://yapcasia.org/2014/talk/show/e10a7e62-01ba-11e4-b7e8-e4a96aeab6a4 今年のYAPCはPerl以外の言語に関するトークが多く応募されています。それ自体は多様性の観点から悪いことではないし、Perlを触っている側からしても、Perlと比較しながら他言語について知ることができるのは有意義だと感じています。 ただ、これはPerlを共通言語として他言語を理解しようという流れだと思います。つまり、Perlというコンテキストが共有されていることが前提になっているのです。 翻って、今年のYAPC::Asiaの様相を見てみると、実はそんな「コンテキスト」なんて共有されてないのではないかと感じられます。 今年のYAPCはPerlを使っていない人もたくさん来場されそうだし、それに、YAPCに来る大半のPerl初級者・中級者にとって、日々
退職とFA宣言のお知らせ | おそらくはそれさえも平凡な日々
所属的には5月いっぱいですが、5月12日(月)が最終出社で有給消化中です。理由はいろいろありますが、結婚や離婚がそうであるように、結局のところはタイミングの問題です。 一番大きな理由は家庭の都合です。家庭の都合というとネガティブに聞こえてしまうかも知れませんが、実際にはポジティブな挑戦です。 ただ、そのために会社を辞める必要は必ずしもなく、会社も引き止めの時にその事情を鑑みてバックアップしてくれる事は伝えてくれました。CTOに 「会社は社員の夢を実現する場所だと思っていて、だからといって全員が別の方向を向いているわけにもいかないので、誰かの夢に乗っかる形で事業を作っている。なので『こいつの夢に乗っかりたい』とか思わせたり、逆にそう思えるようなイイヤツを採用している。ただ、松木くんくらい会社に貢献してくれた人間だったら、自分の個人的な夢や目的のために会社を利用してくれて構わないし、むしろそう
RijiというBlogツールを書いた | おそらくはそれさえも平凡な日々
空前のオレオレBlog環境構築ブームなわけですが、僕もRijiというBlogツールを書いてこのブログもそれに乗り換えました。Puncheur使ってます。 % cpanm Riji 使えるようになる簡単具合です。Puncheur素晴らしい(ステマ)。あとは、 % riji setup とかやれば雛形作ってくれたりする感じ。チュートリアルもまじめに書いたので試してもらってフィードバックとかもらえると嬉しいです。 https://junkyard.song.mu/p5-Riji/blog/ 手元のエディタでMarkdownで書けて動的配信にも静的配信にも対応しているようなよくあるやつです。Gitで管理することが前提になっていて、コミットログを元にRSSが出力されるとかそういうところがちょっと特徴。 構想自体は2年くらい前からあって何度か書きかけたのですが、先日「やり残しハッカソン」と銘打たれた催
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
