誰でもアーキテクトになれるかもしれない48手 - レベルエンター山本大のブログ
アーキテクトへの道という講習会を依頼されている。 結構なお客さんが予約してくれているようだ。 最近のアーキテクト案件では上手く振る舞えなかっただけに恐縮だ。 ということでアーキテクトの特徴を考えてみる。 アーキテクトは、 実装と業務設計のクロスチェッカーである ルールとポリシーの番犬である ソフトウェアとミドルウェアのチューナーである 担当者の不在領域の掃除人である トラブル対応の生きたデータベースである 斥候（先回りする人）である 古い慣習を覆して、新しい慣習をつくる老害予備軍である 期待と失望を一番最初に受ける窓口である よくわからないことを、よくわからないと言っちゃえる特権階級である スポークスマンである 講師である 独裁者である 自動化ツールの製造工場である Google検索役である 環境構築のパシリである 本番環境バグが出た時のしかられ役である 常に被告人側（バグを埋め込む側）の
データベースパフォーマンスに関する、僕が知りうる限り最高の教科書 - レベルエンター山本大のブログ
データベースの醍醐味は、パフォーマンスチューニングにあります。 チューニングによっては、同じ処理でも1時間掛かる場合もあれば、 1秒で終わるということもあり得る世界です。 僕はDBの魅力に取り付かれた者の一人です。 DBという技術の奥深さが気に入っています。 DBを極めると、どこの現場に行っても絶対に必要とされます。 また、どこの現場に行っても正解を導く方程式は一緒なので応用が利くのです。 しかし、その基本原理を体系的に学べる手段はあまりありません。 OracleMasterやMCDBAといった資格試験でも学べることは限られていて あとはWebで調べるなりマニュアルを読むなりするしかありませんでした。 とくに肝であるパフォーマンスチューニングについては、 経験則でチューニングしている部分も多いです。 Oracle、SQLServer、MySQLと色々なDBのチューニングをしてきましたが、
DIxAOP時代のデザインパターンの検討 - レベルエンター山本大のブログ
DIxAOP時代のDesign Patternについて記事のためにアイデアを絞っている。 その中で浮かんだパターンの1つ 「Implicit Interface Injection」パターンというのをご紹介。 対象とする問題 DIコンテナを使う場合「インターフェイスベースのプログラミングを行う」ことは1つの原則のようになっている。 インターフェイスベースプログラミングによって疎結合なモデルになる。これにより、再利用性と拡張性が向上する。 しかし、部品の再利用が主目的ではない企業システムの開発では、インターフェイスベースにすることのメリットよりも、開発の効率低下や、コードの追跡のしやすさの面でのデメリットの方が大きいと感じることが多い。 Implicit Interface Injection（暗黙のインターフェイスへの注入）パターンによる解決策 「Implicit Interface In
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
