Slides for RailsConf 2014 talk "Ruby on Rails Reading Guide" http://www.railsconf.com/
find_or_create的なやつは大体どんなORMでも レコードを探す 無かったらINSERT みたいに実装することになると思う。ただこれだと、1と2の間でレースコンディションでエラー起きることがある。他のプロセスがINSERTしてしまうとかそういうやつ。 それを防ぎたい場合に、1の時点でFOR UPDATEするのはすごくダメで、空行にFOR UPDATEしたりするとMySQLだと盛大に乙るのは有名な話。 エラーを起こさないで、確実にレコードを取りたい場合にはどうすればよいかというと、以下のようにするのが良いと思っている。UNIQUEキー制約なりがちゃんと付いている前提。サンプルコードはTengの場合。 sub find_or_create_surely { my ($self, $table, $where, $opt) = @_; my $row; my $txn = $self-
YAPC::Asia 2014 ボランティアスタッフとLTを終えて #yapcasiaAugust 30, 2014 by Yudai Suzuki YAPC::Asia 2014、特別大きなトラブルは無く無事に終えることができました。 大勢の方に楽しんでいただけたようで何よりです。 長くなったので、4部に分けます。 1部 ボランティアスタッフの話 前夜祭を除く1日目、2日目にスタッフとして参加した。担当は多目的ホール2。 @uzullaさんのブログ見ると、前夜祭の日がボランティアスタッフ的の体力的に一番大変らしい。参加できなくて申し訳ない。 参加人数に対して席数が足りなかった多目的2で立ち見が発生しなかったトークが記憶に無い。来年もさらに増えそうな雰囲気。 感想ブログを色々見るとやはり不満に思ってる人が多かったので、非常に申し訳なく思った。 多目的2は扉が2カ所あったから入口出口をわけよ
Spurred by recent events (https://news.ycombinator.com/item?id=8244700), this is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it. For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release
Goで複数の仕事があるとして、goroutineを新たに作成してそれに1つ1つの仕事を任せるのは普通のやり方だと思う。たとえばクライアントからの接続を待っているサーバをGoで書いているとして、クライアントからのリクエストごとにgoroutineを起動してその後のやりとりを任せるといったようなパターンは普通だ。 そういったパターンでリクエストが多いと、どんどんgoroutineが起動してしまってメモリが足りなくなることがある。そういった場合に、goroutineの起動を待たせて、最大でもある一定数以上はgoroutineが並行して走っていないようにしたいことはよくあるのだが、そのためにはどうしたらよいだろうか? 一般的なやり方はチャネルを「残りいくつのgoroutineを起動してよいか」という値(セマフォ)として使う方法である。 チャネルを作成するときにチャネルのバッファサイズを決めることが
CやC++ではatexit関数で関数を登録しておくと、プログラムの終了時にその関数を自動的に走らせることができる。そういう機能はRubyやPythonにもある。 Goにはそういう機能はない。実装を忘れているのではなくて、意図的にそういう機能を持たせていないのだ。これについてIan Lance Taylorさんが大変説得力のある説明をしていた。 まず第一に、どんなプログラムでも任意の箇所でクラッシュしうるし、まったくバグのないプログラムでもいきなりkillで殺されたりマシンが電源断で落ちるということがある。従ってどんなプログラムも、突然終了させられたあとに、もう一度きちんと動くことができなければならない。つまりatexitはきれいに終了するための機能ということで、atexitが呼び出されないとうまく動かないプログラムというのはそもそも間違っているということになる。 大きなC++プログラムでは
今年のYAPC::Asia Tokyo 2014は海外ゲストの方々と色々話す機会があったのでかなりの時間彼らと話していた。 特にスピーカーの方々とは「日本人に受けるためにはどういうアプローチがいいんだ」という相談をYAPC期間中に(今更!)聞かれて 「日本人は証拠として数値の提示を求める傾向があるから、数値をもっと盛り込め」とか「おまえらの会社日本だと全然知られてないんだからまずそこから変えろ」とか等々の助言をして大分彼らのトークの内容を微調整する業務があった。特にDBICのトークは(見てないけど)YAPC::EUでやったものと全く内容が違う、という報告をスピーカー本人にもらった。ははは、通訳の人たちに迷惑かけたかなーw ともあれ、その流れで海外のYAPCの話。今回話した人たち全員から 「なんでYAPC::Asiaはこんなに人が集まるんだ?」「どうしたら俺たちのYAPC(EUにしろNAにし
数千万から数億のソリューションを買うのかオープンソースをハックできる人を育てるのか。もちろんそんなに単純な問題ではないが、じっくり考えてみるに値する。 企業にとっては、何らかの経営的課題が解決できれば別に自社で内製しようが、他社のプロプライエタリなソリューションを購入しようが、それこそオープンソースであれやこれやしようが単に手段が違うだけである。リスク、コスト、時間などを天秤にかけて決定すればいい。 わたしなんかは、オープンソース原理主義者的なレッテルを世間からは貼られているので、なんでもかんでもオープンソース(OSS)を推進しているように思われているが、理念としてのフリーソフトウェア運動に深く敬意を抱きつつも、ま、安ければなんでもいいんじゃない、という日和見主義者なので、商用製品を使うことになんら躊躇はない。 例えば、EMCのご大層なストレージを1TB用意するのと、ローカルストレージで1
TL;DR - 最初の一人はつらいけど後続はそうでもないので先駆者は自覚と誇りを持ってオールグリーンを維持しよう このエントリはMarionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogというエントリの続きにあたります。未読の方は先にそちらを一読されることをおすすめします。 Marionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogの結論で触れたように、今回テストを書くことにこだわったのは、「クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか?」という問いに対する自分なりの回答を実践して検証してみたかったという理由があったからだ。 以前から「クライアント JavaScript (CoffeeScript や他の AltJS を
クレジットカードやキャッシュカード等の暗証番号を、簡単にしかも気付かれずに盗みとれる方法が紹介され、海外で話題となっているようです。 その方法は、YouTuberのMark Rober氏によって動画(上)で公開され、わずか3日ほどで再生回数が200万回を超えるほど注目されています。 Rober氏はまず、実際に暗証番号を盗む「デモ」を行っています。 下のシーンは、よくあるドラッグストアのレジで、被害者役の女性(中央)がカードを使い、暗証番号を入力して支払いを済ませているところ。 犯罪者役のRober氏は、少し離れた場所でレジの順番を待っています。 支払を済ませた女性が立ち去ったあとのシーン。 Rober氏はiPhoneを片手に音楽を聴きながら自分の会計を済ませます。 一見すると何も怪しい様子はありませんが、この時点で既に、先ほどの女性の暗証番号を入手することに成功しています。 では、一体どう
YAPC::Asia 2014でコマンドラインツールについて語ってきた コマンドラインツールについて語るときに僕の語ること #yapcasia 語ってきました.言いたいことはすべてスライドに詰め込んだし,参考文献もまとめておいたので興味のあるひとは参考にしてください.また,gihyo.jpさんに素晴らしいレポートを書いて頂いたのでそちらもご覧下さい. コマンドラインツールを作るときに参考にしている資料 YAPC:: Asia 2014 1日目レポート 以下,簡単に雑感を書いておきます. YAPC初参加・初トーク 自分は去年東京に来たばかりです.YAPCの盛り上がりは毎年インターネット越しに眺めており,自分もいつか参加したいなと憧れていました. 初めは参加さえできれば良いと思っていたのですが,インターネットのすごい方々と肩を並べて話す機会が誰にでも開かれてるならぶっ込むぞ!と思いトークに応募
例外を利用して実装すると便利な場合が多い この投稿では、HTTP経由でJSONを返すようなWeb APIをRailsを利用して実装するとき、エラーレスポンスを返す場合の処理をどう実装するとやりやすいのか、というニッチな話題に触れる。APIでエラーを返したいとき、即ち400以上のステータスコードと共にレスポンスを返したいような場合、どう実装するのが良いか。もしリクエストの処理中にエラーが検出された場合、それ以降の処理を行わずに直ちに中断してエラーレスポンスを返したいという場合が多いため、例外を利用して実装すると便利な場合が多い。 例外を利用しない方が良い場合もある 1つのリクエストに複数の問題が含まれている場合、先に見つけた問題だけを報告するようなエラーレスポンスを返すのか、それとも問題を抱えながらも進めるところまで処理を進めて報告可能な情報を全て含むようなエラーレスポンスを返すのか、という
YAPC::Asia Tokyo 2014が無事終了しました。みなさんお疲れ様でした。 今回私はコアスタッフとして関わらせて頂き、イベントホール(コーヒーが出ていた部屋)のリーダーを担当しつつ、YAPCに参加しました。その思い出のエントリです。 YAPCでの私のトーク、「半端なPHPDisでPHPerに陰で笑われないためのPerl Monger向け最新PHP事情(5.6対応)」についての話は、また後日、別にエントリをポストしたいと思います。 TL;DR 色々あったけど、事故はなくYAPCを終えることができ、スタッフとしてうれしい。 (トークはほぼみれなかったけど)楽しいという意見をいただくとこちらも楽しい。 貴重なフィードバックありがとうございます。 YAPC::Asiaに参加する方法は、「来た、見た、しゃべった*1」、だけでなくスタッフという手段もあるので是非。 他の方のレポート(感想エ
クックパッドが主要出版社13社と提携、新課金サービス「プロのレシピ」を開始〜月額360円で、料理雑誌やレシピ本のレシピ約1万品が定額見放題〜 2014年9月1日 クックパッド株式会社 クックパッドが主要出版社13社と提携、新課金サービス「プロのレシピ」を開始 〜月額360円で、料理雑誌やレシピ本のレシピ約1万品が定額見放題〜 クックパッド株式会社は、主要出版社及び個人料理家(以下「提携パートナー」とします)と提携し、『オレンジページ』『レタスクラブ』『ESSE』等の料理・生活雑誌やレシピ本のレシピ約1万品が月額360円(税抜)で見放題になる新しいサービス「プロのレシピ」(http://cookpad.com/pro)を9月1日(月)より開始いたします。生活者(ユーザー)からの投稿を主体とした料理レシピサイトを運営しているクックパッドが、料理・生活雑誌やレシピ本の領域においても新しいプラット
本日は9月1日。エイプリルフールではなくて、防災の日です。 勤務地は東京の表参道ですが、今日から2週間だけ京都で働くので、新幹線の中でこのエントリを書いています。YAPCのトークでも話しましたが、東京で僕と一緒に働いてくれるエンジニアを絶賛募集中です。 長くなるのでとりあえずwishlistを置いておきますね。 http://www.amazon.co.jp/gp/registry/wishlist/3L07LJZVYI89C/ FA宣言したら20数社から連絡を頂いたんですが、その中からはてなを選ぶことにしました。はい。Perlの会社ですね。とは言えPerlは書かない予定です。とか言いつつちょいちょい書いてしまうことでしょう。 「Perlで、日本語の会社じゃねーか!」というツッコミが飛んできそうですが、はてなが一番自分を必要としてくれたと感じたので、入社させてもらうことにしました。こういう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く