「RSpecとMinitest、使うならどっち？」という発表をしてきました #kanrk06 - give IT a try
はじめに 去る2015年7月11日、関西Ruby会議06で「RSpecとMinitest、使うならどっち？」という発表をしてきました。 今回ではこの発表に関する情報と、参加した感想等をあれこれ書いてみます。 発表の前に客席の写真を撮らせてもらいました。会場でかい！ 発表のスライド 今回使ったスライドはこちらです。 RSpecとMinitest、使うならどっち？ / #kanrk06 - Speaker Deck 発表の動画（本当は練習風景） イベント当日の動画はありませんが、発表の前に練習用に撮ったスクリーンキャストがあります。（約25分） 発表内容はほとんど同じなので、当日イベントに参加していない人もこれを見ればだいたい内容がわかると思います。 RSpecとMinitest、使うならどっち？ #kanrk06 - YouTube 今回の発表で工夫した点や気をつけたポイントなど 事実と意見
『詳解Linuxカーネル』の輪読を始めました | BLOG - DeNA Engineering
初めまして！ IT基盤部の安武です。 本日は、社内で最近始めた『詳解Linuxカーネル』という書籍の輪読会について紹介します。 この本は文字通り、Linux カーネルの仕組みについて詳細に解説した、1000ページ超の大型本です。 O’Reilly Japan - 詳解 Linuxカーネル 第3版 Daniel P. Bovet, Marco Cesati 著、高橋 浩和 監訳 2007年2月発行 決して易しい本ではありませんが、カーネルのアーキテクチャを理解しておくことはアプリケーション開発者にとっても、運用担当のエンジニアにとっても、アドバンテージになる技術スキルだと思います。 私は 2〜3 年ほど前にこの本を購入しました。 しかし、ときどきリファレンス的にピンポイントで参照することはあったものの、実質ほぼ「積ん読」状態( *1 )になっていました。 「複数人で輪読( *2 )したら読み
輪読って何？
輪読とは、ある本を一人で読むのではなく、数人が順番に読んで解釈をし、問題点について論じ合ったりすることです。 輪読のやり方[] いろんなやり方がありますが、たとえば、 １．その本を読みたい人が何人か集まる。 ２．その本をいくつかの部分に分け、参加者にそれぞれ割り当てる。 ３．次回にとりあげる部分を割り当てられた人（担当者）は、その部分をなんとか全部読み、次回の集まりには要約（レジュメ）を作ってくる。分からなかったところや疑問点も、要約に入れておく。 ４．担当者でない他の人たちも、次回にとりあげられる同じ部分を読んでくる。分からなかったところや疑問点を、次の集まりに持ち寄る。 ５．集まりでは、担当者がじぶんがまとめた要約を参加者に配り、口頭でもその部分の概要を発表する。分からなかった部分や疑問点などについて各自の見解をぶつけ合う。指導者がいる場合は、議論された疑問点や、取り上げられなかった重
強固なデータ・インフラストラクチャを構築するためのログの活用（デュアル書き込みがダメな理由）PART 2 | POSTD
PART 1.はこちら : 強固なデータ・インフラストラクチャを構築するためのログの活用（デュアル書き込みがダメな理由）PART 1. ログが使われる場面について4つ説明したいと思います。まずデータベースストレージエンジンの内部です。 B-tree はアルゴリズムの授業で学びましたよね？ ストレージエンジンに広く使われているデータ構造です。ほぼ全てのリレーショナルデータベースと、多くの非リレーショナルデータベースで使われています。 B-treeについて簡単に説明しましょう。B-treeは、ディスク上で固定長のブロックとなる ページ から構成されており、通常、その固定長は4KBか8KBです。ある特定のキーを探したい時は、まずtreeのルートにあるページから探索を始めます。そのページは他のページへのポインタを内包していて、各ポインタはキーのレンジ（範囲）にタグ付けられています。例えば、もしキー
アジャイルの破綻―原因、そして新たな提案 | POSTD
2001年、17人のメンバーによって アジャイル宣言 が発表されました。私はその立案者そして著者の1人であることに誇りを感じます。この出来事は、何かをする上でより良い方法を導き出すことへの期待、そしてソフトウェアを開発することで世界をより良くするといった、私自身の活力の源となり、極めて重要なターニング・ポイントとなりました。 あれから14年が経ち、私たちは行き先を見失っています。”アジャイル”という言葉はスローガン化してしまいました。本来の意味をなさなくなっただけならまだいいですが、最悪に考えれば排外的な存在になってしまったとすら言えます。2～3のソフトウェア開発のプラクティスを、不十分に生半可に試みるといった”軟弱なアジャイル”を行う人が数多く存在します。本来の目的を忘れて努力を重ねるといった、口先だけのアジャイルの 狂信者 がたくさんいるのです。 更にひどいのは、アジャイル開発手法その
デザインの視覚調整 ― 人間の認知に適合するデザインのために | POSTD
理論対デザイナー 駆け出しのデザイナーの頃は、何が正しくて何が正しくないかということについて、PhotoshopやCSSを信じ切っていました。Photoshopで整列すればそろったことになるし、形の違う2つのオブジェクトが同サイズと言うならサイズは一緒。左右のオブジェクトが同じ16進数値を持っていれば同じ色に 見える 、とそんな具合です。 この考え方は理論的なように思えますが、作業の方法としては誤っています。 画像処理のソフトなどは合理的に計算することはできても、形や色やサイズに対する人間の知覚メカニズムを考慮に入れることはできません。つまり、全体の視覚言語的背景にある複数オブジェクトの配置といった 文脈 や、それらを人がどう視覚的に捉えるかということについて、ソフトは理解できないのです。 従って、対象が視覚的に正しく見えるように、人間の非合理的な感覚で調整をしてやる必要があります。コンピ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.asial.co.jp/1416