• 1．逃げない
• 2. 武器を手に入れる
• 3．力を手に入れる
• 4．こだわる
• 5．トラブルに遭遇すること
• 6．投げださない
• 7．情報発信する

2011年9月27日

• カジュアル化するエンジニアイベント
• イベント開催の敷居が下がった2つの理由
• 私もやってみました
• イベントの企画から当日まで
• おわりに

2011年8月31日

• 「流行り」の法則
• メインストリームを見極めろ
• 時には乗り換えも必要
• エンジニアのための「乗り換え案内」

2011年8月1日

• シリコンバレーとベイエリア
• 「和訳モノ」からネイティブな情報交流に
• 「とにかく海外に行け」では通用しない
• 今こそベイエリアへ出て行こう！

2011年6月29日

• ハードウェアは進化しているのに，なぜパフォーマンスチューニングを続けるのか
• パフォーマンスチューニングの基本
• ディスクI/Oを制する者はチューニングを制する
• キャッシュも制する価値あり
• 「その設定がなぜ高速なのか」を理解しよう
• パフォーマンスチューニングにゴールは無い

2011年5月30日

• 「デカいRFC」の読み方
• HTTP/1.1の2大特徴
• 手で打って覚えるHTTP

2011年4月28日

• 「手動でプロトコルを送る道具」としてのtelnet
• プロトコルの原典「RFC」
• RFCの読み方
• 平文プロトコルを「手でしゃべる」

2011年3月29日

• 「時空を超える」コミュニケーションとは？
• 「問題の存在を知らせること」のすばらしさ
• なぜ情報発信できないのか？
• 情報発信が成長につながる4つの理由

2011年2月28日

• 「ラインに行ったら負け」なのか？
• 「正しいことをしたければ偉くなれ」
• エンジニアがマネジメントを厭うワケ
• エンジニアよ，上を目指せ！

2011年2月4日

• まずはシェルプログラミング
• 次にLL
• C／C++で差をつけろ

2010年12月27日

• 筆者の経験から
• ゴール設定とフローの確立
• 査定のポイントは「評価基準が共有できること」
• 栄光の？「第三小隊」
• 「どう確保するか」から「どう育てるか」へ

2010年12月1日

• 宣伝抜きにまずは「書籍と雑誌」
• 「環境」から何を，どのように得る？
• ネット情報は吟味が必要
• 最後は「人」
• 本当に重要なのは「情報を得るための情報」

2010年10月29日

• memcachedビフォー・アフター
• パフォーマンスへの要求がクロスオーバーを加速する
• クロスオーバー時代を生き抜くために

2010年9月29日

• 入門編
• Linuxサーバ編
• 「とりあえず使える」だけではダメ

2010年8月27日

• 金勘定が必要な理由（ワケ）
• 金勘定とかけ引き
• イノベーションをにらんだコスト把握
• 求められるのは「利益を生むエンジニア」

2010年7月30日

• ［Case1］ネットワーク機器差し押さえでルータ13台→4台に
• ［Case2］消えたエンジニア──パスワードはどこに？
• ［Case3］サーバ持ち出しシャットアウト！ネットワーク経由でデータ救出

2010年6月29日

• 誤操作アラカルト
• 特権モードで緊張感をもつ癖をつけよう
• 予防措置を取ろう

2010年5月27日

• 「資格否定派」の筆者がアリだと思う資格
• 資格と現実の「ギャップ」とは？
• 「Social Certification」が欲しい！

2010年4月27日

• ステップ1：OSインストール
• ステップ2：ネットワークの基礎
• ステップ3：OSSのインストール／セットアップ
• ステップ4：基本コマンドを実行する
• ステップ5：設定ファイルの探訪
• ステップ6：情報を集めるために押さえておきたいこと

2010年3月30日

• インフラエンジニア不足の原理
• 状況に任せるのは運次第
• 自分一人で解決できること
• 「人に任せられない」症候群
• 「エンジニアファーム」への道

2010年2月27日