タグ

システム開発に関するbeneluxのブックマーク (10)

  • ソフトウェア開発プロセス残酷物語 - give IT a try

    昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや人が直接手を動かすことはありませ

  • 開発時に。送信内容が確認できるダミーのSMTPサーバ·smtp4dev MOONGIFT

    smtp4devはWindowsローカル上に立てるダミーのSMTPサーバです。 システム開発においてメール送信を行う時はよくあります。SMTPサーバを立てたとして、間違って送信してしまうと大変な事態につながるかも知れません。そこで使ってみたいのがローカルで使えるダミーのSMTPサーバ、smtp4devです。 起動しました。まずはセキュリティ警告が出ます。 メイン画面です。この時点でポートは開いています。 オプションです。UIに関する設定です。 サーバ設定です。ポート番号はデフォルトで25です。 アップデートチェッカーもあります。 こんな感じで常駐します。 こんな感じでPHPからメールを送ってみます。 送信しました。すぐに反映されます。 さらに日語件名のメールを送ってみました。文字化けせずに送信されています。 メーラーでメールの内容を確認できます。 さらに詳細を確認できます。 メッセージソ

    開発時に。送信内容が確認できるダミーのSMTPサーバ·smtp4dev MOONGIFT
  • システムはどこまで内製化できるか - 急がば回れ、選ぶなら近道

    どこでも何回も何十回も言われているが、システムを経営の変化に対応させるにはある程度のシステムの開発を内製化すべきである、という論調が強い。この問題は、古くて新しい問題であり、と同時におそらく、いままでとは違うコンテクストで語られることになるような気がしている。ここ10数年の流れを見れば、内製化の議論はアウトソーシングの流れとそのより戻りの反復運動の繰り返しだといっていても過言ではなかったと思う。近年はむしろ、SI屋さんの全体的な弱体(特に技能として)化とクラウド等によるインフラの導入しやすさと相まって別の背景で語られることが多くなってきている。また、見逃せない背景としては、そもそもの就労可能若年層の減少と、若年層の総体数減少による能力のばらつきの顕在化も強くあげられる。特にシステム開発の供給サイドの問題は、エンドユーザーの内製化の議論においては、今までのコンテクストでは語られることがなかっ

    システムはどこまで内製化できるか - 急がば回れ、選ぶなら近道
  • ブラウザキャッシュでパフォーマンス向上

    キャッシュ制御の方法 サーバサイドからキャッシュを制御するには、以下の2つの方法がある。 HTTPヘッダによる制御 METAタグによる制御 まずは、これらがどのようなものか、軽くおさらいしておく。 ■HTTPヘッダによる制御 HTTPプロトコルでは、HTTPヘッダにさまざまな情報を格納することができる。そのうちいくつかの情報は、キャッシュ制御のためのヘッダである。リクエスト(クライアント→サーバ)用のものと、レスポンス(サーバ→クライアント)用、リクエスト/レスポンス共通のものが存在する。 ■リクエスト用 If-Modified-Since 日時を指定する。指定した日時より新しいコンテンツの場合のみデータを返却するようにサーバに指示する。ローカルキャッシュの最新確認に使用される If-None-Match 指定したエンティティタグに一致しない場合のみコンテンツを返却するようにサーバに指示す

    ブラウザキャッシュでパフォーマンス向上
  • 「できるからやる」から脱却しよう - GoTheDistance

    atsuizoさんのこのエントリを読んだ。 そろそろ内製回帰について一言いっておくか。 - なからなLife 同時期に内製派として出会い、立場は変われど目指す方向が同じの友人のエントリを読んで、歯がゆい気持ちになった。 上記エントリの骨子は「プラスを広げる内製のメリットを引き出すためにも、「言われたからやる」じゃなくて「提案して、実行する」ことに価値がある、それをモチベーションにする組織作りをしなくてはならない」ということにあり、その点については完全に同意です。 でも、現場じゃ忙殺されているうちにわかんなくなるんだ。何のために今この仕事をしているのか、が。それを伝えるのは、経営の仕事なんだ。 僕は中小企業に属しているから経営と実際の業務と情報システムの3つの軸を自分の中に立ててバランスを取ることができていますが、ほとんどは「経営」「現場」「情シス」に役割が別れているため、その調整コストたる

    「できるからやる」から脱却しよう - GoTheDistance
  • はてなブログ | 無料ブログを作成しよう

    氷見に行ってきたよ 旅行はどちらかというと結構苦手。旅行だけじゃなくて、イレギュラーなことが基的には苦手なのだ。とたんに不安になってしまうし、不安が行動にそのまま表れて失敗した(涙)と思ってしまうことが多い。だから旅行はあんまり行かない方だと思う。 いつも同じ生活を送…

    はてなブログ | 無料ブログを作成しよう
  • システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance

    先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵「基契約」と「個別覚書」ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 「仕様策定〜開発まで」と「保守運用」で別契約にすることが多い。 「仕様策定フェーズ」で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は「事務作業の代行」という意味合い。委任は「法的効力がある作業」の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で「僕らのコンサル案を僕らが実施し成果が出

    システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
  • プログラマの誇りを減衰しないビジネスモデルを - GoTheDistance

    アツいエントリなんで思わずTBうってみる。 この業界の問題、それはプログラムが、新人〜3年目の作業と位置づけられていることだ。 プログラマーの誇りを見せ付けろ - 山大@クロノスの日記 正確に言うと上級プログラマも初級プログラマも同じ値段で評価されるってことが弊害である、ってことだと思います。予めXXX万円で作ってねという予算が決まっていて、その予算をオーバーしないことだけが成果の基準にあることが問題だと考えます。このルールにおいては、極論ですがコード品質が高くても低くても大差が無くねっていう力学が働きます。 基的にニッポンの受託開発のプロジェクトの場合は、大きく2つのプレイヤーがいます。 案件を立ち上げてお客さんへのコミット権限がある人・会社 立ち上げた案件をシステム化してデリバリする人・会社 ですが、今の流れでは工程が分断されちゃっているので、案件を立ち上げる人とシステム化してデリ

    プログラマの誇りを減衰しないビジネスモデルを - GoTheDistance
  • IDEA * IDEA

    ドットインストール代表のライフハックブログ

    IDEA * IDEA
  • 現場のSE, PGが考えるデスマる条件とは:アルファルファモザイク

    当方1年目の新人です。"デスマ"と言うのを最近知りました。 勉強になると思うので箇条書きかなんかで挙げていただけないでしょうか。

  • 1