プレゼンツールをスマホ対応した | おそらくはそれさえも平凡な日々長らく色々言われてきたオレオレプレゼンツールを雑にスマホ対応した。スワイプでページ切り替えられるようにしたつもりだけどiPhoneでしか確認してない。 更に勢い余ってWebSocketでつないでスライドをiPhoneから操作できるようにした。WebSocketサーバー側は雑にPerlで書いた。これは元々やりたいと思ってた。Webとブラウザ技術だけでこういうのが手軽に作れるの大分アツい。 次にどこかでプレゼンするのが楽しみになっている。
ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
ISUCON4ダメでした | おそらくはそれさえも平凡な日々
まずは、ISUCON4の主催・協賛・運営の皆様、素晴らしいイベントをありがとうございました。 ISUCON4ダメでした。こんな悔しく終わると思ってなかった。一応予選通過してそれなりに手応えがあったので、本戦もそれなりに健闘して戦えるのではないかと思ってたけど、その辺完全に甘くて、本戦に出られたちょっとした喜びも吹き飛びました。競技に溺れて本来のサービス運用者視点が抜け落ちていた事に反省しきりです。 何をやったかは、motemenのエントリに書いてありますが、最初にRedisを1台に固めてログの書き込みをRedisのリストにしたのがそれなりに効いたくらいですかね。多分最初に8000点超えをして暫定トップを取ったと思います。ここがクライマックスでここから全く改善しなかった。 Redisはレプリケーション構成にしようかとか@y_uukiに言われたし、他のチームのレポートを見てもそうしていたところ
Perlベストプラクティスのベストプラクティスじゃないやつをまとめてみた | おそらくはそれさえも平凡な日々
Perlベストプラクティス Perlベストプラクティス(略してPBP)という良い本があります。僕自身もPerlを学ぶ過程で非常にお世話になった本なのですが、以下の様なことが度々指摘されています。 bestって書いてあるけど「著者の」bestプラクティスなので偏りがあることも 「決して」とか「必ず」とかが多いけどあんま真に受けてはいけない この本を書くために書かれたであろうCPANモジュールとかがあって、しかも公開されてないものまである 致し方ないけど現在の状況にマッチしない古い情報もある なので、PBPの何がベストじゃないのかについてまとめてみることにした。前からやりたかったんだけど、思い立ってやった。 まとめてみたら、思っていたほどには項目が上がってこなかったので、やっぱPBPは良い本だなと改めて思いました。なので、このエントリーがこれからPBPを読む人の助けになれば良いなと思います。
MySQL Casual Talks vol.6 でパーティション活用の話などをしました | おそらくはそれさえも平凡な日々
運営の方々いつもありがとうございます。Oracle様いつも快適な会場ありがとうございます。発表資料は以下。タイトル長い…。 MySQLゆるふわ運用のためのアグレッシブ開発 ～ データを増やさないための設計と運用方針について(主にパーティション活用の話) アプリケーションエンジニアの立場から「カジュアル」にパーティション活用法を含めて話をしてきました。大分カジュアルな話になったんじゃないかと思います。 パーティション便利って話です。もう大分枯れて安定もしていると思います。先人の後ろについて行って、枯れた技術をフルに活用してカジュアルに楽をしていきたい。 EXCHANGE PARTITION大分熱い感じなので、DROPせずにEXCHANGE PARTITIONがこれからの(僕の)トレンドになりそう。 大規模の話とか闇の話とかも面白いけど、こういう普通のMySQLの活用の話とかももっとみんなすれ
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初級者・中級者にとって、日々
俺がDHMOについて知ってること，またそれに対する所感 | おそらくはそれさえも平凡な日々
参考: http://moznion.hatenablog.com/entry/2014/06/17/223342 「わかりました。あなたは世界を革命するしかないでしょう」 浄水器 C1 スタンダードタイプ 去年買ったものの中で一番よかったなーとか思ってるのがこれ。そんなに舌の鋭くない僕でも明らかに分かるくらいにDHMOの味が変わった。家でいれるコーヒーが格段に美味くなったのがかなりの収穫。 場所もそんな取らない。洗い物ラックの隣においてある。取り付けも簡単だった。ウォーターサーバーほど場所取らないし、注文とかする必要もない。年に一回くらいカートリッジを買い換える必要があるくらい。 世界が変わった。
個人的な問題解決のためにGithubや周辺サービスを「あなた自身」が改善することができ、それが結果的に貢献になるという話 | おそらくはそれさえも平凡な日々
個人的な問題解決のためにGithubや周辺サービスを「あなた自身」が改善することができ、それが結果的に貢献になるという話 tl;dr GithubやTravisなどのサービスに対して、ものによっては直接p-rを送ることができる サービスを使ってみて個人的に不便さを感じたら、サービスがコードをオープンにしているか、p-rを送れないかを調べてみる価値がある それが結果的に貢献になるし、多くの場合OSS活動というのはそういうもの 本題 GitHub Kaigiで意識が高まったので、GitHubネタを1つ。 先日、前職の後輩がこういうツイートをしていた。 travis氏 perl 5.20に対応してないかなとドキュメントを見たけどそんなのなかった http://t.co/TvX85q6fmC こっそり対応してたりしないかな。 — Ichinose Shogo (@shogo82148) 2014,
退職とFA宣言のお知らせ | おそらくはそれさえも平凡な日々
所属的には5月いっぱいですが、5月12日(月)が最終出社で有給消化中です。理由はいろいろありますが、結婚や離婚がそうであるように、結局のところはタイミングの問題です。 一番大きな理由は家庭の都合です。家庭の都合というとネガティブに聞こえてしまうかも知れませんが、実際にはポジティブな挑戦です。 ただ、そのために会社を辞める必要は必ずしもなく、会社も引き止めの時にその事情を鑑みてバックアップしてくれる事は伝えてくれました。CTOに 「会社は社員の夢を実現する場所だと思っていて、だからといって全員が別の方向を向いているわけにもいかないので、誰かの夢に乗っかる形で事業を作っている。なので『こいつの夢に乗っかりたい』とか思わせたり、逆にそう思えるようなイイヤツを採用している。ただ、松木くんくらい会社に貢献してくれた人間だったら、自分の個人的な夢や目的のために会社を利用してくれて構わないし、むしろそう
Const::Commonというのを書いた | おそらくはそれさえも平凡な日々
https://metacpan.org/release/Const-Common プロジェクト共通の定数定義クラスを作ったりするときに、単にuse constantだと以下の様な不満点があった。 use MyApp::Const;とかしても定数をExportしてくれないので、MyApp::Const::CONST_HOGEとかかくのがタルいしExportの設定を書くのもタルい use constant CONST_HASH => +{BAR => 'BAZ'};とかできるけど、CONST_HASH->{BAR} = 'OVERWRITE'とかできてしまう その辺は各プロジェクトで個別に解決していたのだが、いい加減共通化したくなって書いた。以下の様な感じで使う。 package MyApp::Const; use Const::Common ( BAR => 'BAZ', HASH =>
MySQL::Partition has been released! | おそらくはそれさえも平凡な日々
MySQL::Partitionをリリースしていたのでお知らせです。パーティションを切る用のSQLを生成してくれるクエリビルダーです。 Webサービスでは如何にデータを増やさないか、DBを分割しないで一系統に抑えるか、DBをメモリに如何に載せきるかってのがゆるふわサービス運用をしていく上で重要です。MySQLを使っている場合、そのために非常に有用なのがパーティションで、適切にパーティションを切り、古いデータを随時Dropしていける運用に落としこむのが非常に大切なわけです。 社内のプロジェクトでもPartitionを活用しているわけですが、いまいち仕組み化されておらず、古いプロジェクトからコピペを重ねて秘伝のタレ化しており、例えばデイリーでパーティションを切る場合、MySQL5.5からはRANGE COLUMNSパーティションが使えるにも関わらず、TO_DAYS()とかを未だにコピペして使い
DBI->connectの第4引数の内容は設定ファイルに書かないほうが良い | おそらくはそれさえも平凡な日々
Perlでデータベースに接続する場合は以下の様な感じになります。どんなORMなりラッパーなりもDBIを利用しているモジュールは内部的にはこういうことをしているわけです。 DBI->connect($dsn, $user, $password, { mysql_enable_utf8 => 1, RaiseError => 1, PrintError => 0, ShowErrorStatement => 1, AutoInactiveDestroy => 1, }); 第1〜第3引数は環境によって差異があるので設定ファイルに情報を持たせると思います。ただ、それにつられて第4引数も設定ファイルに書いてしまうのが散見されますが、これは良くない。 第4引数の値はプロジェクトでは固定に決まっているので、設定ファイルによって自由度を持たせる必要性が全く無いというかむしろ悪。この人の環境ではテストに通
WEB+DB PRESS Vol.79 Perl Hackers Hubにcron関連の記事を寄稿しました | おそらくはそれさえも平凡な日々
本日見本誌を受け取りました。感激しております。ありがとうございます。 縁あって、2/22 発売の WEB+DB PRESS Vol.79 に記事を書かせてもらえることになり「cron周りのベストプラクティス」というPerlにあまり関係ない記事を書かせてもらいました。 WEB+DB PRESS Vol.79 安定しつつも扱いづらいcronをどのようにWebアプリケーションプロジェクトで安定的に利用・活用するかについて書いています。cronだけで9ページという驚きの充実の内容です。とは言え、まだ書き足りない部分もあり、例えば比較対象としてJenkinsについても取り上げたかったのですが、泣く泣く削っております。 個人的にイノベーティブなプロダクトである、App::RunCronについても2ページを割いて取り上げております。 これであなたも、cronのログを捨ててしまったり、逆に溢れさせてしまっ
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
おそらくはそれさえも平凡な日々: DBIx::FixtureLoaderってのを書きました
https://metacpan.org/module/DBIx::FixtureLoader これもまたどこも同じようなの作ってるんでしょうけど、テストとかでさくっとfixture 読み込んでInsertして欲しい的な要件で作りました。使い方は以下の様な感じ。 use DBI; use DBIx::FixtureLoader; my $dbh = DBI->connect(...); my $loader = DBIx::FixtureLoader->new(dbh => $dbh); $loader->load_fixture('item.csv'); $loader->load_fixture('item-2.yaml', update => 1); # ON DUPLICATE KEY UPDATE ORM非依存で$dbhを渡すだけで簡単にお使いいただけます。 CSV、YAML、J
OrePAN2サーバーの話 | おそらくはそれさえも平凡な日々
最近はArkもCPANに上げたし社内OrePAN運用やってないんですが、OrePAN2サーバー的なのをどうすればいいんだ的なことをhirobanexさんが言ってたのでこんなんでいいんじゃないかという話。 こんな感じのpsgiを作ってplackupで立てて、 こんなふうにリクエストでも送ってやれば良い。 curl --data-urlencode 'module=git@github.com:Songmu/p5-App-RunCron.git' --data-urlencode 'author=SONGMU' http://example.com:5000/ 実際使うとするとコミットフックとかでタグ打たれた時にリクエスト飛ばすとかそういう使い方になるでしょうか。 orepan2-injectはgit URLを直で指定できるのがcoolですね。 追記：ちょっと手を入れてtarを直接受け取ること
MySQL Casual Talks vol.5 でLTしてきました | おそらくはそれさえも平凡な日々
myfinder++ Oracle様いつも快適な会場ありがとうございます。発表資料は以下。 GitDDL::MigratorもしくはApp::RunCron 日本語LTとか初めてだから緊張したわー。したわー。 前の週にmyfinderに会った時に「SongmuさんLT登録しておきますから」って言われて急にアサインされたので、GitDDLの話かカジュアルに最近のテーブル設計のポリシーの話でもしようかなーと思っていたんだけど、その翌日くらいから作り始めたApp::RunCronがだいぶ強まってたので、MySQL関係ないけど勝手にアサインされたからこっちも勝手に話してもいいかとか思って話した次第。 runcronマジ便利。 僕にとってはだいぶガチュアルな内容でいつもながら楽しませてもらっておりますが、次回も機会があれば空気読まずゆるふわdeveloperとしてMySQLを絡めた開発の話などをして
Ukigumo::ServerがCPANに上がっていました | おそらくはそれさえも平凡な日々
https://metacpan.org/module/Ukigumo::Server CPANに上がっていない他の人のモジュールをあげる業をしている今日このごろ皆様如何お過ごしでしょうか。 さて、この度Ukigumo::ServerをやっとCPANに上げましたのでご報告です。 ukigumo-server起動スクリプト MySQL対応 辺りが大きなフィーチャーです。 % cpanm Ukigumo::Server % ukigumo-server --config=config.pl とかやればデフォルト2828ポートでサーバーが立ち上がります。「ふわふわ」なので2828なのですが、どう見ても「ニヤニヤ」でした。 configファイルにはDBの設定等を記載します。configファイルの指定は任意ですが、指定しない場合はdevelopment.dbというSQLiteのファイルがカレントディ
おそらくはそれさえも平凡な日々: サーバーマシンのコア数に応じてworker数を調整する方法
PSGI/Plackアプリケーションの起動方法いろいろと本番環境アレコレ 便乗ポスト。最近は、上記内の「シェルスクリプトでラップする方法」で運用していることが多いです。その場合のone more tips. appサーバーごとにマシンスペックが違う場合がたまにあって、その場合マシンごとに worker数を調整したいけど、deployの都合上サーバー起動スクリプトは同じやつを使いた いってことがあります。 そこでおすすめなのが、CPUコア数に応じてworker数を計算する方法です。 シェルスクリプトの場合、 % cat app.sh #/bin/sh NCPU=`getconf _NPROCESSORS_ONLN` WORKERS=$(expr $NCPU \* 5) exec plackup -E production -s Starlet --max-workers=$WORKERS と
おそらくはそれさえも平凡な日々: パスワードはサーバー側で生成したほうが良いんじゃないかという話
いつまで文字列ベースのパスワードを使うんだって話は置いておいて、Webサービスのパスワードはもはや、人間には覚え切れない領域に達しているわけです。 サービス毎に異なるパスワード 大小英数数字記号混じり12文字以上 みたいなのは必須で、それに加えて意味があるかどうかは甚だ不明ですが、定期的に変更必須みたいなポリシーがあるところもありますね。 言ってしまえば、もはや人間が覚えられる程度の強度のパスワードでは弱すぎるわけで、そうなるともう否応なしにパスワード管理ツールを使うしかありません。 そのような「パスワードは覚えきれない」という前提に立つと「もはや覚えやすいパスワードを使う必要がないという」逆説が生まれます。 となると、もう、パスワードはサービス側がランダムな文字列を発行してしまって、それを強制的に使わせる形で良いんじゃないかとふと思いました。以下の様な具合です。 大小半角英数数字記号混じ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
