昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
smtp4devはWindowsローカル上に立てるダミーのSMTPサーバです。 システム開発においてメール送信を行う時はよくあります。SMTPサーバを立てたとして、間違って送信してしまうと大変な事態につながるかも知れません。そこで使ってみたいのがローカルで使えるダミーのSMTPサーバ、smtp4devです。 起動しました。まずはセキュリティ警告が出ます。 メイン画面です。この時点でポートは開いています。 オプションです。UIに関する設定です。 サーバ設定です。ポート番号はデフォルトで25です。 アップデートチェッカーもあります。 こんな感じで常駐します。 こんな感じでPHPからメールを送ってみます。 送信しました。すぐに反映されます。 さらに日本語件名のメールを送ってみました。文字化けせずに送信されています。 メーラーでメールの内容を確認できます。 さらに詳細を確認できます。 メッセージソ
どこでも何回も何十回も言われているが、システムを経営の変化に対応させるにはある程度のシステムの開発を内製化すべきである、という論調が強い。この問題は、古くて新しい問題であり、と同時におそらく、いままでとは違うコンテクストで語られることになるような気がしている。ここ１０数年の流れを見れば、内製化の議論はアウトソーシングの流れとそのより戻りの反復運動の繰り返しだといっていても過言ではなかったと思う。近年はむしろ、SI屋さんの全体的な弱体（特に技能として）化とクラウド等によるインフラの導入しやすさと相まって別の背景で語られることが多くなってきている。また、見逃せない背景としては、そもそもの就労可能若年層の減少と、若年層の総体数減少による能力のばらつきの顕在化も強くあげられる。特にシステム開発の供給サイドの問題は、エンドユーザーの内製化の議論においては、今までのコンテクストでは語られることがなかっ
キャッシュ制御の方法 サーバサイドからキャッシュを制御するには、以下の2つの方法がある。 HTTPヘッダによる制御 METAタグによる制御 まずは、これらがどのようなものか、軽くおさらいしておく。 ■HTTPヘッダによる制御 HTTPプロトコルでは、HTTPヘッダにさまざまな情報を格納することができる。そのうちいくつかの情報は、キャッシュ制御のためのヘッダである。リクエスト（クライアント→サーバ）用のものと、レスポンス（サーバ→クライアント）用、リクエスト／レスポンス共通のものが存在する。 ■リクエスト用 If-Modified-Since 日時を指定する。指定した日時より新しいコンテンツの場合のみデータを返却するようにサーバに指示する。ローカルキャッシュの最新確認に使用される If-None-Match 指定したエンティティタグに一致しない場合のみコンテンツを返却するようにサーバに指示す
atsuizoさんのこのエントリを読んだ。 そろそろ内製回帰について一言いっておくか。 - なからなLife 同時期に内製派として出会い、立場は変われど目指す方向が同じの友人のエントリを読んで、歯がゆい気持ちになった。 上記エントリの骨子は｢プラスを広げる内製のメリットを引き出すためにも、「言われたからやる」じゃなくて「提案して、実行する」ことに価値がある、それをモチベーションにする組織作りをしなくてはならない｣ということにあり、その点については完全に同意です。 でも、現場じゃ忙殺されているうちにわかんなくなるんだ。何のために今この仕事をしているのか、が。それを伝えるのは、経営の仕事なんだ。 僕は中小企業に属しているから経営と実際の業務と情報システムの３つの軸を自分の中に立ててバランスを取ることができていますが、ほとんどは｢経営｣｢現場｣｢情シス｣に役割が別れているため、その調整コストたる
思いは言葉に。 はてなブログは、あなたの思いや考えを残したり、 さまざまな人が綴った多様な価値観に触れたりできる場所です。
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
アツいエントリなんで思わずTBうってみる。 この業界の問題、それはプログラムが、新人〜3年目の作業と位置づけられていることだ。 プログラマーの誇りを見せ付けろ - 山本大＠クロノスの日記 正確に言うと上級プログラマも初級プログラマも同じ値段で評価されるってことが弊害である、ってことだと思います。予めXXX万円で作ってねという予算が決まっていて、その予算をオーバーしないことだけが成果の基準にあることが問題だと考えます。このルールにおいては、極論ですがコード品質が高くても低くても大差が無くねっていう力学が働きます。 基本的にニッポンの受託開発のプロジェクトの場合は、大きく２つのプレイヤーがいます。 案件を立ち上げてお客さんへのコミット権限がある人・会社 立ち上げた案件をシステム化してデリバリする人・会社 ですが、今の流れでは工程が分断されちゃっているので、案件を立ち上げる人とシステム化してデリ
当方１年目の新人です。"デスマ"と言うのを最近知りました。 勉強になると思うので箇条書きかなんかで挙げていただけないでしょうか。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
