コミュ力が無いのはいつだって自分 | おそらくはそれさえも平凡な日々
突然何を言い出すのかという話ですが、対話相手にコミュニケーション能力を求める醜さについて書きたくなったので書きます。 僕はオタクだったしスクールカーストで言うと下の方を彷徨ってきた。地元でもいろいろあって浮いていた。新卒時の就活も散々だった。なので、コミュ力がないことは自覚しているし、だからこそ「コミュニケーション能力」という言葉には警戒心があります。 比較的マイノリティであったことが多かった経験上分かったのは、相手とコミュニケーションが取りづらいな、と思うときは、そもそもプロトコルが異なる、ということです。 これは、話している自然言語が違うようなものだと考えるとわかりやすい。例えば、自分が日本語しか話せず、相手がロシア語しか話せないのであれば、まともなコミュニケーションが成り立たないのは明らかです。そして、その時に、日本語が話せない相手にコミュ力がないと思うような人はいないでしょう。 そ
sh -cで呼び出したコマンドがbashだと孫プロセスにならないことがある | おそらくはそれさえも平凡な日々
前提として、/bin/sh は、デフォルトでは、RHEL系の場合bashシェル、Debian系の場合dashシェルへのsymlinkになっています。この2つのシェルの挙動は細かいところで結構異なります。そもそもの思想として、dashシェルはPOSIX互換を目指す軽量なシェルであり、bashは拡張された高機能なシェル。なのでbash前提で書かれたシェルスクリプトがdashでは動かない、みたいなことはよくあります。そういう感じで困ることがままありますが今回もそういう話。 例えば % sh -c "sleep 100" のようなコマンドを実行した場合、呼び出し元の子プロセスが sh になり、その更に子プロセスが sleep になると直感的には思うでしょう。つまり以下のような具合。 . \_ sh -c sleep 100 \_ sleep 100 しかし、 sh の実体が bash である場合な
ルーク！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がそこそこ書けると手応えを感じ始めているところだった。 ところが
ログからJSONぽい部分を検出して綺麗に出力してくれるやつ書いた | おそらくはそれさえも平凡な日々
https://github.com/Songmu/App-LJ ljというツールを書いた。標準入力を読んでJSONぽい文字列が含まれていたら色付きで綺麗に出してくれる。こんな感じ。 fluentdでstdoutで出したログとか、アプリケーションから雑にJSONで吐いたログを眺めるときとかに便利。 % cpanm App::LJ で入りますが、fatpackした単一ファイルも作ってあるので、以下のようにしても使えます。 % curl -L https://raw.githubusercontent.com/Songmu/App-LJ/master/lj > /usr/local/bin/lj; chmod +x /usr/local/bin/lj fatpackは @ks0608 さんのApp::Fatpack::Simpleを使った。便利。CPANにあげて欲しい。 実装だいぶ雑なので、だ
ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
New Class of Vulnerability in Perl Web Applicationsの`param`の挙動に関しての補足とか | おそらくはそれさえも平凡な日々
New Class of Vulnerability in Perl Web Applicationsの`param`の挙動に関しての補足とか New Class of Vulnerability in Perl Web Applicationsの紹介 つい最近のCGI.pmでは$cgi->param('foo')をリストコンテキストで受けると警告が出るようになっているのですが、その背景にこういう話があったことを知りました。ちなみに、$cgi->paramの挙動変更に関してはFormValidatro::Liteにp-rが来てたので把握してた次第。 CGI.pmは今後は複数の値を受け取る場合は$cgi->multi_param()を使うことが推奨される流れになっています。僕は元々のparamの挙動はそんなに嫌いじゃないのですが、とは言え意図せぬ脆弱性を起こしうる挙動はよろしくないのでインタ
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の味が変わった。家でいれるコーヒーが格段に美味くなったのがかなりの収穫。 場所もそんな取らない。洗い物ラックの隣においてある。取り付けも簡単だった。ウォーターサーバーほど場所取らないし、注文とかする必要もない。年に一回くらいカートリッジを買い換える必要があるくらい。 世界が変わった。
退職と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
最近のPerl例外厨事情 | おそらくはそれさえも平凡な日々
言及してくれていたのをずっと放置していた。 http://soh335.hatenablog.com/entry/2013/06/04/114954 最近結構例外厨で、事あるごとに例外投げたくなってる。結局エラー文字列を正規表現で引っ掛けるより、オブジェクトで引っ掛けたほうがエラーメッセージとかが変わった時に対応が少なくて楽だし、例外を階層化して置いたほうが色々捗る感じがしているので、丁寧に例外オブジェクト投げるように色々ラップしたほうが良いなーとか思ってる。 他言語の人にとっては何を今更みたいな話かもしれませんね。 例えば、Tengの場合だとこんな感じで、Tengはエラー投げるところがhandle_error()で一本化されているので、そこをオーバーライドすれば自分の好みの例外を投げ分けるとかができる。この場合だとユニークキー制約に引っかかった場合は異なる例外を投げるようにしてある。My
Songmu casualという出会い系 | おそらくはそれさえも平凡な日々
karupanerura君と飲みに行こうって話をしていたら、facebookのイベント作ってくれて"Songmu casual"って名前がついていてファッてなった。わざわざ横浜で設定してくれて感激だった。当日はなぜかyusukebeがいた。 かるぱ君とは共にPerlでゲーム開発をしているということで、問題領域が近い所にあるなーと勝手に共感している部分があったんだけど、かるぱ君も少なからずそう思ってくれていたようで、長らく話をしたいなーと思っていたんだけどやっと話を出来た感じ。少人数飲み良いですね。 かるぱ君が「僕myfinderさんと話したこと無いんですよねー」とか言ったら「へー意外」「今度紹介するよー」みたいな女同士の会話みたいな謎テンションになった。 そういうの結構あると思っていて「あの人のことがなんとなく気になるな、お話してみたいな」とかお互い思っててなかなか実現できてないこととかあ
Perlでコマンドラインモジュールを書くときのクラス設計 | おそらくはそれさえも平凡な日々
コマンドラインから引数が渡すようなモジュールでも以下のような要件があったりする。 コマンドラインからだけじゃなくて、コード内で直接オブジェクトをnewしたい場合もある 複数のコマンドラインツールを組み合わせて使うような場合に@ARGVを何度か渡すケースがある growthforecast.plみたいなサーバースクリプトだとよくあると思っていて、スクリプト単体で引数渡して起動できるけど、自分でGrowthForecast::Web->newしたくなることもある。これが前者。 growthforecast.plにPlackとGrowthForecastのオプションをコマンドラインから同時に渡したいみたいなのがある。これが後者。 GrowthForecastはあくまで例えです。念のため。 それに対しては以下のようにすればよいのかなーとなった。 parse_optionsというクラスメソッドで@A
そろそろText::Markdown::Discountについてひとこと言っておくか | おそらくはそれさえも平凡な日々
Text::Markdown::Discountってどうなの?って話があったりするわけですが、Perlの人は積極的に使ったほうが良いと思うし、Discount自体はPerlに限らずおすすめだよーっていうエントリです。 これはDiscountというCのMarkdownライブラリのバインディングです。Rubyにはrdiscountという、メジャーなMarkdownのgemがありますが、これもDiscountのバインディングです。Jekyllとかで利用している人も多いでしょう。 Rubyの世界だと他にもredcarpetというgithubが採用したことで一躍有名になったMarkdownライブラリがあります。これはsundownというCのMarkdownライブラリのバインディングです。 sundownは処理が高速なのがウリらしく、PerlでもText::Markdown::Sundownを書こうか
YAPC::Asia Tokyo 2013でカジュアルなデータベース関連開発についてトークします | おそらくはそれさえも平凡な日々
今年もYAPC::Asia Tokyoが開催されます。 僕も去年に引き続きトークを採択していただいたので、「今時のカジュアルなデータベース関連開発」というタイトルで発表する予定です。 プロポーザルにも書いてありますが、最近こんな感じでDB関連開発してるよーっていう内容を話す予定です。結構盛り盛りな内容になっているので、どこまで話せるかはわかりませんが…。初心者がちょっとしたアプリから一歩進んだアプリを作ろうとすると、どうしてもデータベースを使わざるを得なくなってくると思うので、そういった時にどういう風に開発を進めて行ったら良いのかとかそういう指針も示せれば良いかなーとも思っています。 チケットも8/11まで絶賛発売中なのでまだ購入していないかたはお早めに。 去年一昨年からすると運用寄りのトークの割合が減って、開発環境とかテストとかのトークが増えた印象です。トレンドに即しているのでしょう。あ
おそらくはそれさえも平凡な日々: 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
おそらくはそれさえも平凡な日々: Cache::Redisってのを書いたら意外と大変だった件
最近Redis使うのは当たり前で、開発とかテストでmemcachedすら立てるのめんどくさくて、なるべくRedisに寄せたいと思っている。 セッションストレージもRedisで良くねって思って、ArkだとCache::Cacheなインターフェースのモジュールがあれば簡単にセッションストレージを差し替えられるようになっているので、Cache::Redisってのを書いた。 先のエントリーでも書いたとおり データに対するメタ情報をRedisの場合もたせられないので、[$data, $flags] って データを作ってそれ毎まるっとシリアライズするという乱暴な作りになっている。 なので、ストアされているデータをredis-cliとかで読もうとしても読めないのが難点。 redis-cliで読めるように値をRedisのリスト型にして持たせることも検討したけど、普通に setする場合と比べて大分遅くなって
おそらくはそれさえも平凡な日々: 「仕事に対する愛と情熱とプライド」若しくは新卒に向けたスピリチュアルな話
そろそろ新卒研修とかどうしようかとかで、エンジニア陣でわたわたしたりしています。「Songmu先生にはスピリチュアルな話をしてもらわないといけませんね」みたいなことを言われてなんかスピリチュアルキャラとして定着しているのもどうかと思います。 去年も「『仕事に対する愛と情熱とプライド』ってお題でソーシャルゲームチームの新卒向けに話してください」とか研修担当の人に言われて、なんでそんな熱いキャラとして認知されてるか謎だったんだけど、それで30分くらい話しました。 それが結構評判良かったみたいで、直接はあまり言われなかったんだけど「研修の時の先輩の話の中で一番印象に残っている」って言ってくれている人が多いって話を2年目の人から又聞きで知って嬉しく思っていました。 とか思っていたら、hisaichi5518の人は「なんかすごくいい話してた覚えはあるんですけど内容全く覚えてません」とかsoh335の
おそらくはそれさえも平凡な日々: #isucon2 で連覇させてもらってきました
主催の皆様素晴らしいイベントの提供本当にありがとうございました。 まさかの2連覇ですが、@fujiwaraの恐ろしさを再認識するとともに、@typesterのチート性能を見せつけられた感があります。 まずは個人的な反省点から 去年よりかは大分成長しているつもりだったのに、@fujiwaraとの力関係が何もかわっていなかったことに衝撃 @typester(Redis期)がRedis使ってくることはわかっていたのに、競技中に brew install redisとかやってるのはダサすぎ ということで、isucon2を振り返ります。 事前準備 事前にIRCチャンネルを作っておいてnopate botを呼んでおいたくらい。カヤックから別チームも出ていたので、お互いのチャンネルには入らないという紳士協定。 去年の経験から、revサーバーに直接gitリポジトリを作れれば捗ることは分かっていたので、その
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
