エンジニアと1on1をするときの事前面談シートテンプレート - $shibayu36->blog;
はてなのチーム横断のエンジニアメンター制度 - Hatena Developer Blog で紹介していますが、はてなにはチーム横断のエンジニアメンター制度があります。僕も最近までメンターとして5~6人ほどのメンティーを持っていました(今は事情があってメンターをやっていないのですが)。 メンターとして1on1をする時には1on1ミーティングに備えるアンケート - しるろぐを参考にし、事前にメンティーに面談シートを書いてきてもらうという工夫をしていました。その面談シートは改善を少しずつ加えながら運用していたのですが、一度知見共有も兼ねて最近使っていた面談シートテンプレートを公開してみようと思います。 面談シートテンプレート 以下のようなフォーマットで書いてもらっています。1on1の前にメンティーに1on1用Google Docsに追記していってもらっています。1on1用Google Docs
希薄化したTDD、プロダクトの成長のために必要なものは？〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 （６）
テスト書くのが当たり前、だけど・・・和田：次に意味の希薄化ですね。『Test-Driven Development by Example』の出版から15年経ち、テストコードを書く人はすごく増えました。15年前は啓蒙期で、テストコードを書きましょう、テストコードの書き方はこういう感じですというのを頑張って啓蒙する必要があった。 でも、例えば今の若手プログラマーは普通にテストコードを書く。なぜなら既存システムにはテストコードが書かれているから、開発の継続、不具合の修正とか機能追加を行う際にテストコードを書くのが普通だし、テストコードが無いとレビューは通らないしみたいな話になって、テストコードがあるという生活は普通のものになっている。そうすると、なぜテストコード書くのかとか、本来こういうテストコードを書きたかったんだけどとか、こういうテストを書くべきなんだけどみたいな議論はだいぶ土俵から外れてし
他システムとのデータベース連携について - Qiita
システムエンジニア Advent Calendar 2015 - Qiita 20日目の記事です。 システム開発をしていると、他システムのマスタやトランザクションデータが必要となる場合がよくありますね。 システム間のデータ連携としては、 リソース共有（データベース共有、ディスク共有） アプリケーション連携（RPC、Web API、MOM1） ファイル連携(CSV連携、etc) などの方法がありますが、ここではデータベース共有を実現するためのデータベース連携方式について考えてみたいと思います。 データベース連携方式について 既存システムがレガシーであったり、違うベンダーが構築したサーバーであるなどの理由で、新機能や拡張機能を別のサーバー上で新システムとして構築する場合があります。もちろん、データベースも新たに用意する場合が多いのですが、その場合は既存システムには極力修正をいれない方針でデータ
【上級】変化に強い情報システムを作る 第2回（後半） アプリケーション・ポートフォリオほか | 日経 xTECH（クロステック）
概念データモデル作成と並行して，アプリケーション・ポートフォリオを策定する。アプリケーション・ポートフォリオは，サブシステムの目的と役割を明確にし，サブシステムの独立性が高い構造を実現するために作る。 アプリケーション・ポートフォリオは，企業情報システムの構造をトップレベルで表したものである。企業が扱う情報の特性，役割などを分類し，それらの関連を示す。さらに情報システムの構成要素であるアプリケーションの特性も記述する。これによって，分類された各系は互いにどう関連するかが明確になり，次のアプリケーション・アーキテクチャ策定への指針となる。企業を新たに作るときに組織の構成を考えるように，システム全体に必要な要素をゼロからトップダウンで考えて作る。 例えば，次のようなサブスシステムを定める（図4[拡大表示]）。 ・中核業務用データベースを維持管理するサブシステム（基幹業務系） ・業務フローや画面
技術的な結合度と設計的な結合度 - arclamp
ささっとBlogを書く訓練。 エンタープライズシステムではシステム間を疎結合に保つことが重要とされます。結合度が下がっていれば両者の依存関係は弱くなります。システムAとBがあったとして、Aが停止した場合に、それによってBが停止しない（縮退はするかも）、あるいはAの内部仕様に変更があった場合に、それによってBが仕様変更を強制されることがない、という示しています。 結合度が低ければシステムのライフサイクルをずらすことができるため、運用上も保守上も大きなメリットになります。 とはいえ、結合度が高いことでのメリットもあります。主にはコストの低下や性能の向上が見込めます。 マスタデータを共有したい場合、ファイルによるデータ交換は結合度を下げることができます。ですが、双方がファイルを入出力する仕組みを作る必要があり、かつ、連携遅延が出てしまいます。そうではなくて、直接データベースを共有するようにすれば
エンタープライズ疎結合アプリＭＡＰ
今回は企業内アプリ”全体”を疎結合化した際に、どのような形になるかをご紹介するとともに、そのポイントがどこにあるかについてお話したい。小生、全社システムの絵を描くのは久しぶりである。今後何かに使えるかも知れないので、少し気合いを入れて書いてみたのでご覧いただきたい。 既にバックナンバー”2015.4.6“で、ER図を用いて疎結合化の勘所を説明したが、今一つ具体例が足りないという読者のために、局所的な例ではなく全社システムのいたる所に疎結合化を施したエンタープライズモデルを作成してみた。 ご紹介するモデルは架空の企業（業種はメーカー）であるが、各アプリケーションに登場するエンティティは定石通りに描いたつもりである。各アプリは独立して機能し、それらが緩やかにシンクロナイズしながら、全体で整合性を保って機能する自立分散型システムとなっている。 読者の方は既にお気付きと思われるが、同じ名前のエンテ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
