"社内SEのお仕事" の一覧

VisualStudioでの社内向けシステム開発手法について

VisualStudioでの社内向けシステム開発手法について検討してみましたが・・・こんな感じになりました。

5点満点でまだ実装経験が無く不明な部分は3点にしてあります。ASP.NET MVCはユーザーに対して大きな変化は無いと思い今回除きました。

【大人の判断版】

architecture1

今回検討していたシステム要件としては上に記載したもの程、優先順位が高い。やはり3層アーキテクチャにすると開発の負荷が高い。新しい技術という事もあるし。

といって、新しい技術の習得を避けると関連する技術(SilverlightでいうならWCFサービスとか)も触れる機会が無くなるわけで、どんどん遅れていってる感が強くなる。そこで、開発者の学習意欲や満足度、社内だけではなく一般的な動作環境での評価も加味した場合が下記です。

【開発者のエゴ版】

architecture2

ということで、今ココです。Webサービス(ASMX)でDataTableを返してそのXMLを直接Silverlightへ持っていければまだ、まだ逆転できるかも?

エンティティフレームワークを使わない場合、テーブルをクラス化して、一覧画面や外部結合したクエリのシリアライズ用にクラス用意して・・・というのがツライです。

エンティティフレームワークは一度VS2008で試したのですがブラックボックス過ぎて、全く理解できてません。今は書籍が充実するのを待つかなーという消極的スタンス。

社内SEがするべきこと

  1. 最新技術や凝った作りこみをしない
    • 同じ事ができるレベルまで部下を育てるのはコスト?
    • それをメンテする人間も大変だ。
  2. 外部へ頼めない事をする
    • 予算があったらその仕事は社外に出せるのでは?
    • どんなシステムにして欲しいと思っているかを汲み取るべき。
    • 運用開始してから、要望を聞いているか?
  3. 社内の調整はシステムの設計よりも重要。
    • 利用する部署の和を持ってよしとする
    • 利用できないシステムは作る必要も無い。
    • 多くの部署で利用されるシステムほど調整も大変だが、メリットも大きい。
  4. 技術的な観点から、断らない事
    • ユーザーの要望はあくまで理想。
    • どこまで理想に近づけるかがポイント。

偉そうな事を書いてますが、残念ながら最近の反省です・・・。

PC・サーバー名の管理手法

大量のPCやサーバーがあると、名称を決めるのに困る。もともとDSP01,DSP02・・・とコンピュータ名が付けられていたが、100台を超えて桁数がズレてきて見栄えが悪い事からDSPXYYYという表記に変えた。Xがセグメントを表してYYYがIPアドレスの末尾。PCの管理についてはこの手法で特に不自由は無い。

 

ところが、サーバーになるとIPを名称に加えると困ったことになる。仮にServerYYというWebサーバーが稼動しているとするとIPがZZ変わるとhttp://ServerYY/でアクセスできなくなる。

しかも、同一IPを維持するには導入時にServerYYを落としておかなくてはならず、もう名称だけの問題ではなくなってしまう。

 

で、解消する案としては

を使うとか。いま本気でどうするか悩んでます。お勧めの方法があれば教えてください。(本気)