2. ⾃自⼰己紹介 l 久保⽥田展⾏行行(@nobu_k) l 製品開発部 l Sedue/Bazil l (Jubatus) l ブル l 最近勉強してるもの l 開発⼿手法:要件定義・管理理 l 本 l Transactional Information Systems(@ノーチラス) ‒ 約1年年で念念願のリカバリーまで到達・・・! l 分散DB本 2 3. 今⽇日の話 l Paxos l Consensus algorithm(protocol)の1つ l ものすごく難しいことで有名(主に元論論⽂文が) l 流流れ l Consensus l 問題設定 l Paxos l (ちょびっとだけ)Multi-Paxos l 参考⽂文献紹介 l ⽇日本語の⽂文献が少なく、⽤用語が怪しいですすいません 3
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
なぜ Teng は良いものなのか、を YAPC で再考させられたのでここにメモしておく。 Teng は自社開発のウェブアプリケーションを作ってる人たちが作っていて、それがうちのニーズにあってるのでいいっていう話であって、どこでもすごい最高!! と主張したいわけではないです。まあ、個人の感想ですね。 ソースが読みやすい ソースがよくモジュール化されていて、読みやすい。自身で書いている部分が多いという贔屓目を抜きにしても読みやすいんじゃないかなーと。 僕らのような自社開発のウェブ屋では、なにか無茶な要望を受けた時にささっと対応するということが求められるシーンが多いので、ソースの読みやすさというのはかなり重要なファクターとなっています。 複雑な SQL を発行できないように機能が制限されている SQL ビルダーを使って JOIN やサブクエリを駆使したウェブアプリケーションを開発してしまうと、運
本日は9月1日。エイプリルフールではなくて、防災の日です。 勤務地は東京の表参道ですが、今日から2週間だけ京都で働くので、新幹線の中でこのエントリを書いています。YAPCのトークでも話しましたが、東京で僕と一緒に働いてくれるエンジニアを絶賛募集中です。 長くなるのでとりあえずwishlistを置いておきますね。 http://www.amazon.co.jp/gp/registry/wishlist/3L07LJZVYI89C/ FA宣言したら20数社から連絡を頂いたんですが、その中からはてなを選ぶことにしました。はい。Perlの会社ですね。とは言えPerlは書かない予定です。とか言いつつちょいちょい書いてしまうことでしょう。 「Perlで、日本語の会社じゃねーか!」というツッコミが飛んできそうですが、はてなが一番自分を必要としてくれたと感じたので、入社させてもらうことにしました。こういう
今年からWEBデザイン2年目に突入しました。Photoshopでバナー・ランディングページ・アプリ・コンパネまで色々作ってきましたが、初期の頃のデータを見返すとレイヤー分けがカオスで申し訳なくなります。 レイヤー分けがカオスだと、それを引き継いだ人の時間も奪いますし、自分でさえ分からなくなって非効率の悪循環に陥ります。レイヤーの乱れは心の乱れです。 …と言いつつ、レイヤー分けにこだわりすぎても現状の作業が遅くなりますよねー。僕は特に大雑把なので、単純な小技だけで実現できる整理術を考えました。プラグインもいりません。楽なのでオススメです☆ 1.「〜のコピー」を付けない設定 以前、レイヤー複製で「〜のコピー」を付けない方法:Photoshopという記事の書きました。まず、この設定をしましょう。 レイヤーウィンドウの右上からパネルオプションを選び「コピーしたレイヤーとグループにコピーを追加」とい
Goは言語機能として並列実行をサポートしているけど、Goで書いたからといって自動的にデータ構造がスレッドセーフになるわけではないので、スレッド安全性を気にしなければならないはこれまでの言語と変わらない。どういうケースが良くてどういうケースがダメなのかを理解していないと安全なプログラムは書けない。それについて説明をしよう。 まず第一にEffective Goのこの一文は覚えておこう。 Do not communicate by sharing memory; instead, share memory by communicating. メモリを共有することで通信しようとしないこと。代わりに通信することでメモリを共有すること。 変数の値を変更したあとにチャネルなどを使わずに、おもむろに別のgoroutineからその変数の値を読み書きしてはいけない。そういうやり方だと読み書き操作の前後関係がき
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
git は、コードベースの発展過程を記録し、開発者間の協同作業を効率化する強力なツールです。でも、記録対象のリポジトリがとてつもなく巨大なものになったときは何が起こるのでしょうか? この記事では、いくつかの異なる意味での巨大化に正しく対処するためのアイデアと手法を少し紹介してみたいと思います。 二種類の 巨大なリポジトリ よく考えてみると 巨大なリポジトリ が生ずる理由はおおまかに言って二つあります: 非常に長い期間にわたって履歴が積み上げられた (プロジェクトが非常に長い期間継続的に拡大を続けたために開発成果が積み重なった) 場合 巨大でしかも履歴の記録が必要なバイナリ データが存在し、それがコードに反映される場合 その両方の場合 即ち、リポジトリの巨大化は二つの異なる方向に向かって起こることになります。それは、作業ディレクトリのサイズ (即ち直近のコミットのサイズ) の問題と全体の履歴
うしろのばやしさんにラーメンと一緒に飲み込まれてしまった感がありますが、PSGI/Plackのパフォ厨としては、どうしても現状を報告しておきたい内容でありました。unicornに勝ちたい!! 2日目の朝イチというコマでありましたが、大勢の方に見に来て頂いて驚きました。前半の内容を盛り込みすぎて時間が足りなくなってしまい、すみませんでした。アンケートで既にDockerを使っている方が凄く多かったので、インストールの部分とかは飛ばしてもよかったんじゃないかと思いましたが、Dockerを使う上で少しでも役に立てば幸いです。 ベストトーク賞 うずらさんのPHP発表は内容面白かったし、喋りはうまいし、スライドも作り込んであってさすがという感じでした。ベンチマークで自分がLTで紹介したオプションを使って頂いて嬉しかった。時代はPHP その他のトークではgugodの「One layer down bel
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く