Kindle Voyage買って電子書籍読むの全部寄せた | おそらくはそれさえも平凡な日々
2013年の頭に買ったNexus7をずっと電子書籍リーダーとして使っててKindleとHimawari Readerで読んでたんだけど、元々色々ストレスがあったんだけど、Lollipopに上げたらもうどうしようもなく遅くなって使い物にならなくなったので、カッとなってKindle Voyageを買った。広告なしの3G付いてるやつ。 Kindle Voyage 保護フィルムと純正カバーも合わせて買った。純正カバーはさすがに出来が良くて満足。合わせて買うべき。保護フィルムは貼りやすくてよかったんだけど、説明書に書いてある貼り付け方向が間違ってて見事に逆に貼った。同じ指摘はレビューでたくさんされてるので注意。まあ気にせずすそのまま使ってる。 文字が読みやすくてとにかく満足。ページ送りは少し難あり。概ね快適なのでePubとかもKindleで読むことにした。手順は以下のとおり。 ePubをcalibr
ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
株式会社はてなに入社しました | おそらくはそれさえも平凡な日々
本日は9月1日。エイプリルフールではなくて、防災の日です。 勤務地は東京の表参道ですが、今日から2週間だけ京都で働くので、新幹線の中でこのエントリを書いています。YAPCのトークでも話しましたが、東京で僕と一緒に働いてくれるエンジニアを絶賛募集中です。 長くなるのでとりあえずwishlistを置いておきますね。 http://www.amazon.co.jp/gp/registry/wishlist/3L07LJZVYI89C/ FA宣言したら20数社から連絡を頂いたんですが、その中からはてなを選ぶことにしました。はい。Perlの会社ですね。とは言えPerlは書かない予定です。とか言いつつちょいちょい書いてしまうことでしょう。 「Perlで、日本語の会社じゃねーか！」というツッコミが飛んできそうですが、はてなが一番自分を必要としてくれたと感じたので、入社させてもらうことにしました。こういう
退職とFA宣言のお知らせ | おそらくはそれさえも平凡な日々
所属的には5月いっぱいですが、5月12日(月)が最終出社で有給消化中です。理由はいろいろありますが、結婚や離婚がそうであるように、結局のところはタイミングの問題です。 一番大きな理由は家庭の都合です。家庭の都合というとネガティブに聞こえてしまうかも知れませんが、実際にはポジティブな挑戦です。 ただ、そのために会社を辞める必要は必ずしもなく、会社も引き止めの時にその事情を鑑みてバックアップしてくれる事は伝えてくれました。CTOに 「会社は社員の夢を実現する場所だと思っていて、だからといって全員が別の方向を向いているわけにもいかないので、誰かの夢に乗っかる形で事業を作っている。なので『こいつの夢に乗っかりたい』とか思わせたり、逆にそう思えるようなイイヤツを採用している。ただ、松木くんくらい会社に貢献してくれた人間だったら、自分の個人的な夢や目的のために会社を利用してくれて構わないし、むしろそう
Carton考2014 | おそらくはそれさえも平凡な日々
こうするのがいいかなーと思ってる。経緯は端折って大枠だけ。Webアプリケーションプロジェクトの場合です。 cpanfileちゃんと書いてコミット 今やどこでもやってますね。scan-prereqs-cpanfileも便利です。 開発者は各自carton installでモジュールをインストール。プロジェクトごとにPerlをビルドしたりしてる場合は、cpanm --installdeps .でも別に良い。 CI環境でcpanfile.snapshotを作る CI環境は必ず以下のとおりとする。 本番環境と同じアーキテクチャ 本番環境と同じバージョンのPerl まっさらな状態(Globalに何のモジュールも入っていない) CIにcarton installもさせて、必要なモジュールをlocal/に入れてテストさせる。毎回サラからcarton installしてたら時間かかるので、git pull
俺のオレオレgit-flow | おそらくはそれさえも平凡な日々
背景 一昨年末くらいにgit-flowを採用していた 良いんだけど、結構めんどくさいなーと思うところがあった 去年頭の新規開発からはgithub-flowを採用(と言うかごく普通のGit運用) masterのテスト通ったらjenkinsさんが開発サーバー反映してくれて捗る ただ本番をそれで運用するわけにもいかない リリースタイミングとかある masterはデザイナーやME(=gitに不慣れな人たち)がカジュアルに画像やテンプレをpushできる(それで構わない) git-flowとgithub-flowの中間くらいのフローで運用することに git-flowの気に入ってる点とそうじゃない点 気に入っている点 並列ブランチを走らせるというのは良い(git-flowの場合、masterとdevelop) hotfixが便利 めんどくさい所 releaseブランチ毎回作る必要性をあまり感じない バー
CPANモジュールは依存モジュールのバージョンを固定しない方がいい | おそらくはそれさえも平凡な日々
Perl界隈ではCarton周りのtoolchainが整ってきて「これからはsemantic versioningやー」みたいな意識が高まりそうですが、そういうルールに則ってバージョニングをするのは大いに結構だとは思うのですが、バージョン違いのモジュールを同一プロセスで共有するとかそういうことはPerlではできないのでどちらにせよ注意が必要です。 まあ、バージョン違いのモジュールを共有できたところで、バージョン違いのオブジェクトが変なところに渡って死ぬみたいな話もあったりなかったりするらしいので夢を見過ぎるのも良くないですね。 それとタイトルのとおりですが、CPANに上げるモジュールの場合はバージョンは固定したり最大バージョンを決めない方が良いでしょう。 例えば、 Super::ORM が Mouse 2.0に固定依存 Hyper::WAF が Mouse 3.0に固定依存 だったりすると
おそらくはそれさえも平凡な日々: Redis::LeaderBoardっての書いてた
https://github.com/Songmu/p5-Redis-LeaderBoard https://metacpan.org/module/Redis::LeaderBoard RedisのSorted Setがランキング作るのとかに便利だよーってのは今や多くの人に知られるところですが、 同率問題とかがめんどくさかったりするので、その辺解決したやつを書いてみました。 というか、このへんみなさん個別に書いてると思うんですけど、色々めんどくさくなってカッと なってCPANに上げました。Synopsis丸コピですが、以下のような感じで使います。 use Redis; use Redis::LeaderBoard; my $redis = Redis->new; my $lb = Redis::LeaderBoard->new( redis => $redis, key => 'lead
おそらくはそれさえも平凡な日々: 3分でpull request
サクッとpull requestを送るために。 tl;dr % git config —global push.default simple しておく ブラウザでfork押して、そのリポジトリをcloneする % git checkout -b feature/hogehoge ってやってbranch作る 変更してコミットする % git push —set-upstream origin feature/hogehoge として修正をpushする ブラウザからpull request あらすじ ikachanを導入しようとした所、AnySanがssl未対応だったのでpullreq送ろうとしたらすでに同僚のmix3先生がpullreqしていて、mix3++であった。しかし、masterブランチからpullreq送るのは良くないよねってことで練習のためにtopicブランチを切ってpullre
おそらくはそれさえも平凡な日々: 「仕事に対する愛と情熱とプライド」若しくは新卒に向けたスピリチュアルな話
そろそろ新卒研修とかどうしようかとかで、エンジニア陣でわたわたしたりしています。「Songmu先生にはスピリチュアルな話をしてもらわないといけませんね」みたいなことを言われてなんかスピリチュアルキャラとして定着しているのもどうかと思います。 去年も「『仕事に対する愛と情熱とプライド』ってお題でソーシャルゲームチームの新卒向けに話してください」とか研修担当の人に言われて、なんでそんな熱いキャラとして認知されてるか謎だったんだけど、それで30分くらい話しました。 それが結構評判良かったみたいで、直接はあまり言われなかったんだけど「研修の時の先輩の話の中で一番印象に残っている」って言ってくれている人が多いって話を2年目の人から又聞きで知って嬉しく思っていました。 とか思っていたら、hisaichi5518の人は「なんかすごくいい話してた覚えはあるんですけど内容全く覚えてません」とかsoh335の
おそらくはそれさえも平凡な日々: CPANモジュールのパッケージングの歴史
最近同僚が次々とCPAN Authorになってて良い流れだなーとか思っています。 ただ、CPANへのモジュールの上げ方がわからないとか、M::Iを使えばいいのか M::Bを使えばいいのか、それらがそもそも何やってるのか分からないという話も 聞くので、僕自身もその辺の知識を整理してアップデートしました。 とりあえず、今はModule::Buildを使っておけば良いんじゃないかと 思っていますが、そこに至る歴史的経緯をまとめてみます。 大体、以下に書いてあることに加えて、最近の動きを書いています。 Module::Build：MakeMakerの後継者を目指して PerlでCPAN形式のモジュールを配布する場合は、Makefile.PLなりBuild.PLなりを モジュール作者が用意して、それがインストールに必要なファイル類を自動生成 するという流れになっています。 既存の雛形を使うと色々ファ
おそらくはそれさえも平凡な日々: shipped Plack::Middleware::Auth::OAuth
Plack::Middleware::Auth::OAuthをリリースしたのでお知らせします。 https://metacpan.org/release/Plack-Middleware-Auth-OAuth ソーシャルゲーム開発等、OAuthの署名検証が必要な場面では必須のモジュールかと思います。ご活用ください。 いきなりバージョンが0.03になっているのはこれまでCPANに上がっていなかった中で変更が加えられてきたからです。そもそもこれは@hidekさんがgithubにあげているもので、僕は一回pull reqを送ったくらいです。それを@hidekさんの許可を得て僕が代理でCPANに上げました。 このモジュールは社内で活用していたので、CPANにあげて欲しいなーと思っていたのですが、YAPCの前夜祭後の飲み会で@hidekさんに「上げてもらえませんか？」みたいな話をしたら「あれ、まだ上
おそらくはそれさえも平凡な日々: Jenkinsをカジュアルに5分で立てる
プロジェクトの共同開発サーバー兼CIサーバーみたいなところにJenkinsを立てることが多い。その場合、Jenkinsを立てるのはwarを起動するコマンドをdaemontoolsなりで管理するのがベタープラクティスかなーと思っている。 事前にやることはjavaを入れるのと、jenkins.warをwgetしておくだけ。 runスクリプトはこんな感じ。 #!/bin/sh JENKINS_USER=app JENKINS_HOME=/home/$JENKINS_USER/jenkins exec 2>&1 exec setuidgid $JENKINS_USER \ env JENKINS_USER=$JENKINS_USER env JENKINS_HOME=$JENKINS_HOME \ java -jar $JENKINS_HOME/jenkins.war --httpPort=300
おそらくはそれさえも平凡な日々: 面白法人カヤックで働いています
ご存知のとおり1月からカヤックで働いています。なんとなく会社にも慣れてきたので、その辺の報告等を。 業務としては現状、ソーシャルゲームのサーバーサイドの開発をしています。毎日Perlを書けるので非常にハッピーです。でももっとバリバリ新しいことも出来るようになりたいですね。 入社した頃は、エンジニアのほとんどがMac Book ProにHHKBとドデカイディスプレイをつなげてザザーっと開発しているのを見て、覚悟はしていたけど、とんでもないところに来てしまったなと思ったものです。 自分がマウスとGUIに頼りっきりのゆとりだったことを改めて思い知りましたが、なんとかシェルとvimでひと通り開発できています。vimとかzshはもっと使いこなしたいですけどね。gitを本格的にコマンドラインで使うのもブランチを切ったりするのも初めて(!)でしたが、今やgitが無いと生きていけませんね。 社員も増えてい
おそらくはそれさえも平凡な日々: Kamakura.pm Tech Talk #1でSpiritual Talk(?)をしてきました
先週の金曜日にKamakura.pmで話してきました。Tech Talkというよりかは思想的な話でした。まあ、Tech Talkは他の方におまかせという感じで。 yusukebeにスピリチュアルとかやたら言われましたが、割と反応をいただけたようでよかったです。モダンPerlの裏側で有名なkoba04さんも丁度いらしていて、僕も割とモダンPerlの裏側に居た人間なので、お話ができて良かったです。 スライドは以下。 Perlの地位を上げる方法 基本的には、Perlって必須スキルだよね、誤解されてるよね、どうすればユーザーを増やせるんだろうとか、前の会社での経験も踏まえて話した感じです。 そういやスライドにちょろっと書いているように、今年から面白法人カヤックで楽しく働いています。その辺の話はまたそのうち。 PerlがロードレーサーでPHPがクロスバイクって話は個人的にはナイス例えだったんだけど、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
