タグ

processに関するyuguiのブックマーク (173)

  • プログラマの心の健康

    目次 はじめに 情報不安について 人の話を聞くこと 寝てから考えよう わ・ざ・と、ゆ・っ・く・り・、や・っ・て・み・よ・う ロビンソン式悩み解決法 驚き、最小の法則 むしょうに腹が立つあいつのこと あなたは、そのままでいいんです はじめからやり直したい症候群 人から信頼されるためにはどうしたらよいか トラブルがチャンス あなたはひとりではありません あなたのための聖書の言葉 ぜひ、感想をお送りください リンク集 更新履歴 はじめに 私はプログラマです。 プログラムを書いて生活の糧を得ています。 プログラマというのは精神的にも肉体的にも過酷な仕事だと思われています。 夜遅くまでディスプレイに向かい、 キーボードを叩き、ジャンクフードをべながらバグをとる…そんな職業だと思われています。 確かにそういうところもありますが、プログラマも人間です。 不健康な生活を長いこと続けることはできません。

  • “あり得ない”開発スピード!顧客とのキョリ5mの職場|【Tech総研】

    yugui
    yugui 2006/06/21
    「電話のすぐ近くで、要望した機能を開発している」
  • ロングテール時代のSI

    not found

    yugui
    yugui 2006/06/19
    「現場のスキルが低いことについて、彼が一切愚痴らなかったこと」
  • Railsの生産性とそれで提供したい価値 - moroの日記

    昨晩の続き。じゃあ仕切り直してなんでRailsって生産性が高いっていうの?というお話です。 DB設計はやっぱり必要で、UIも考えなくちゃいけないうえ、自動生成は客寄せで、ワークフローエンジンもないけれども、Railsの強みって言うのは一つはまさにRubyで書けるということ。二つ目はシンプルな哲学に基づいたフルスタックなフレームワークがいまある、ということ。 言語重要 えっと、まず予防線を。JavaはダメでRuby最高、といいたいわけではなく。 Railsの強みはRubyのシンタックスの柔軟さから来るDSLっぽい記法や、Rubyの動的な側面から来る徹底的な(自動生成じゃない部分、手動で書くべきロジックの)コードの削減だったりするんじゃないかと。ブロックと遅延評価だったり、括弧が省略できることであったり、クラスがインスタンスであったり動的にメソッドが定義できたり、っていうのはすべて書きたいコー

    Railsの生産性とそれで提供したい価値 - moroの日記
  • EJB3時代のアーキテクチャパターン 業務ロジックType5について - t-wada の日記(旧)

    id:higayasuo:20060615#1150364455 ひがさんが説明しているType5のやりかたが、今の案件で行っている方法にえらく似ているのに驚きました。考えていることが似ていたのかな。私のところではMayaa+無設定S2Struts+S2Daoを使っているのですが、HTMLとMayaaとERD(から生成したファイル)を生成の入力ファイルとして使い、Service実装以外のクラスを全部自動生成しています。生成するクラス群はGoyaのレイヤモデルを採用しています。 開発していくときに実際に書くのは、生成されたServiceのサブクラス(Generation Gapパターンでやってます)と、自動生成では生成できない複雑なSQLを呼ぶためのDaoと、そのSQLファイルです。他のレイヤのクラスおよびインターフェイスは自動生成したものを使います。自動生成のためにMaven2のプラグイン

    EJB3時代のアーキテクチャパターン 業務ロジックType5について - t-wada の日記(旧)
  • 「営業の本音とSEの本音」の間にあるもの(エピソード3)

    とある請負型のSIer、というか普通のソフトハウスでのできごと。 下請仕事で成功し成長したこの会社、直接請負をはじめた。 時はあたかもオープン化の波がやってきた80年代の後半のこと。 メーカー系がハード価格の下落で提案力が弱まってきた頃、業を煮やしたユーザーが「御社、直で契約しようよ」ともちかけた。新しい提案がないなら高い値段で、ハードメーカー経由でSEを買う必要はない。 ソフトハウスは単価が上がり、ユーザーは下がる。いわゆる「なかぬき」でWin-Win。 うるさかったハードメーカーはオープン系なヤツラの襲来に伴い、売上げ下落で営業を削減。納期と価格しか説明出来なくなった彼らはもうそれどころではなくなってきて、「めんどくさいからソフトは直でやってください」となってきた。 最初はよかった。 昔ながらのユーザーだから黙って人出しをしてればよかった。 客もこっちの懐具合を知ってた。会社のレベルも

    「営業の本音とSEの本音」の間にあるもの(エピソード3)
    yugui
    yugui 2006/06/14
    つづきwktk
  • 中里一日記: 『Ajax イン アクション』は糞本だ

    『Ajax イン アクション』は糞だ Dave Craneほか著『Ajax イン アクション』(インプレスジャパン)を8割がた読んだ。 突然だが、戦場は4つの基的な要素でできている。 ・飢え ・埃 ・糞 ・シラミ これだけは絶対に忘れないでほしい。飢え、埃、糞、シラミだ。 これらの四大要素があまり目立たない戦場も、ごく一部にはある。米軍の力はあらゆる不可能を可能にするらしく、毎日シャワーを使うことさえあると聞く。だがそういう恵まれた環境は例外だ。戦場は四大要素でできている。四大要素があるのではなく、四大要素でできている。24時間、四大要素のなかで暮らすのだ。 さて私の経験によれば、Ajax開発は、戦場の暮らしに少しだけ似ている。こちらの四大要素は、多様性、非常識、情報不足、テスト困難だ。 現代のほとんどのプログラマは、こういう経験をしたことがないはずだ。匹敵するものがあるとしたら初期の

  • http://giantech.jp/log/940

    yugui
    yugui 2006/05/30
    継続的結合。Bitten = Tracプラグインとして組み込まれるCIツール。レポートをtrac上で閲覧可能。
  • プロジェクトリーダーは十二分な準備で自信を生み出せ

    プロジェクトリーダーは十二分な準備で自信を生み出せ:ユーザーサイド・プロジェクト推進ガイド(10)(1/2 ページ) 広く深い検討の仕方 前回「プロジェクトチームのリーダーに向く人、向かない人」で、リーダーには自信が必要であり、努力と十二分な準備によって獲得できると述べました。十二分な準備とは広く深く検討することです。 人類にとってまったく未知のプロジェクトであれば話は別ですが、世の中一般の“未経験プロジェクト”はたいてい、問題解決のヒントや解が手の届くところ──例えば担当部署などの相談相手、書籍・Web上のドキュメントなどで見つけることができるものです。要は、自分にとって未知であっても、ヒントや解を素早く見つけ無駄なく利用する方法を知ることです。 5W2Hと5times why 広く検討するということはさまざまな方面から検討するということであり、ケース・前提条件・制約条件の種類と程度を考

    プロジェクトリーダーは十二分な準備で自信を生み出せ
  • IT失敗学の研究

    2つの意味でたいへんタメになった。ひとつめは、破綻プロジェクト事例集として。ふたつめは、「くれない君」の言い訳の反面教師として。 「動かないコンピュータ」と不条理プロジェクト 日経コンピュータの「動かないコンピュータ」なら比較的単純なストーリーだ。さまざまな要因で初期の目的を達成できなかったプロジェクトだからだ。予期しない不具合や無謀な計画が原因なのだが、通常これらは事態を収拾するための「火消し」が続き、なんらかのエンディングがある。『IT失敗学の研究』は違う。曰く「最初から動かす気がなかったし、動くはずもなかった」「どうみても計画に合理性がなかった」「危ない危ないと思っているうちに破局を迎えた」…といった不条理プロジェクト集だからだ。 したがって、「動かないコンピュータ」というエンディングすら迎えない。どう見ても不可能なのに、予算がつくからとムリに存続させるプロジェクトや、検収・納品→動

    IT失敗学の研究
    yugui
    yugui 2006/05/29
    後半ワロタ。そして、考えさせられた。
  • 2006-05-25

    初稼働まであと少し。もうひと踏ん張り。がんばりましょう! 懸念したgrepだけでなく、他にも使うコマンドがそれぞれちょっと古かったのでその場でほとんど書き直すことになってしまいました。テストファーストもTDDもできたとは言えません。そのかわり副作用の無いスクリプト(クエリ系)と副作用のあるもの(更新系)に分けて、更新系をなるべく小さく、クエリ系の結果を元に動作するように設計し、クエリ系は目で確認しながら小さく始めて大きく育てるイメージで作業しました。動くところまで持っていけたのでまあ良かったかなと思います。

    2006-05-25
  • 現場の叫びで分かった嫌われるプロマネの正体 - @IT自分戦略研究所

    プロジェクトをマネジメントするどころか、メンバーを地獄に陥れるようなプロマネの正体を暴く。現場の悲痛な叫びはプロマネに届いているだろうか。(Tech総研/リクルートの記事を再編集して掲載) 複雑化・高度化した現代の技術。1人のエンジニアが、1つの案件を仕上げることができるケースなどほとんどない。そこで重要になってくるのが、メンバーを率い、プロジェクトをまとめ上げるプロジェクトマネージャ(プロマネ)の力量だ。しかし……。 Tech総研が、主にIT分野のエンジニア100人に行ったアンケート調査によれば、これまでにプロマネの下でスムーズに進めることができたプロジェクトは5割に満たないと答えたエンジニアが、何と88%にも上っている(図1)。しかも、そのうち79%が、別のプロマネであればうまくいったはずと答えているのである(図2)。

  • 「Notes見える化」のススメ ― @IT情報マネジメント

    今日、一定規模以上の企業でグループウェアを使っていないところは少ないかもしれない。では、それがどの程度利用され、どの程度役立っているのか把握しているだろうか? この連載では、Notesをベースに情報共有基盤の「見える化」と「再整理」について解説していく。 意外にできていないNotesの現状把握 グループウェアというソフトウェア分野を作り出したLotus Notes/Domino(以下、Notes)が、部門サーバとして爆発的に導入されたのがいまから約10年前。その後も業務に欠かせないツールとして現場で使い続けられ、何度かのサーバ統合を通じて全社情報共有基盤となっている企業も多い。 しかし、経営層の方々になぜNotesを使い続けているのか? という問いに対して納得のいく答えが返ってくることは少ない。ほかのオプションを検討しようにも、Notesの状況が正確に把握できていないのが実情であろう。 一

    「Notes見える化」のススメ ― @IT情報マネジメント
  • プロセス管理ツールで失敗する人しない人(1/3) ― @IT

    ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第6回は、開発方法の整備やスパイラルモデルなど、前回に続きさまざまな問題がある要求仕様フェーズの対処法について解説します。

  • mixi(ミクシィ)

    mixi(ミクシィ)は、友人・知人とのコミュニケーションをさらに便利に楽しくするSNSというサービスです。

    mixi(ミクシィ)
    yugui
    yugui 2006/05/20
    ニコカレアンチパターン
  • 2006-05-09

    HOT deployを試してみたい一心でブランチを切ったものの、S2Strutsがまだ2.4系に対応していないようだったので2.4系に対応する作業を行い、パッチを生成して中の人にメールしたところで一時休止。 S2Struts + HOT deploy構成を目指してちょっと触ってみた感じでは、DtoをContainerから取得するようにしないとHOT deployの旨味が無いかなというイメージを持ちました。どうやるんだろう。 そうこうしているうちにリリースされましたね。即日リリース。さすがです。 id:higayasuo:20060508#1147081800 早速試してみました。すばらしい。これでid:yuki_neko_nyanさんにJavaEE勉強会で教えてもらった開発方法がある程度再現できそうですね。 Addのサンプルで感じをつかんだので、早速現在のプロジェクトでもブランチを切って反

    2006-05-09
  • ソフトウェアプロダクトラインとXPは何が違うのか? - プログラマの思索

    細谷さん、トラックバックありがとう。 ソフトウェアプロダクトラインとXPの違いについて考えたことを記述しておく。 【それぞれの定義】 1.ソフトウェアプロダクトライン 2.XP 【1】ソフトウェアプロダクトライン 品質を保持するには、インフラに近いレイヤーはできるだけ変えず、アプリケーションやUIに近い部分は変更可能とするように設計する。 これはビジネスの要求に対し、コアとなる部分は再利用可能な資産とし、それぞれの顧客に対してカスタマイズする戦略を取る。 当然、変化しやすい部分と変化しにくい部分をアーキテクチャだけでなくビジネスドメインの観点からも切り分ける。 対象とするシステムの境界は、ソフトウェアやDBだけでなく、ネットワークインフラやハードウェアまで含む。 だからこそ、再利用できるものとそうでないもの区別が大切なのだろう。 また、ビジネス関係者だけでなく、ハード開発者、ソフト開発者な

    ソフトウェアプロダクトラインとXPは何が違うのか? - プログラマの思索
  • 2006年05月07日のブログ|渋谷ではたらく社長のアメブロ

    ・・・コホン。 先日に引き続き、業務連絡その2!(社内向け)。 2ヶ月ほど前の話。 アメリカで急速に利用者が伸びているとあるサービスを 見つけたアメーバ事業部の2年目の若手社員が、 「社長、これうちでやりましょう!」 「いいねぇ。やろう。頼むよ」 (こういう感度の良く、ベンチャー精神をもった社員が いる限り当社は安泰だなぁ・・・) このインターネットサービス(詳しくは書けないですが)は、うちが やらなくても他のネットベンチャーが間違いなく手がけるだろう。 うちもスピードで負けていない。 ・・・そして2ヶ月後。つい先週のミーティング。 綺麗にカラーコピーされた企画書を持って、再度 プレゼンテーションされた。 その社員に。 「え?これだけ」 「はい」 「システム会社に発注してないの?」 「まだです」 「見積もりは?」 「まだです」 ・・・・・・・。 ・・・・・・・。 ・・・・・・・・・・・・・

  • andore.com

    This domain may be for sale!

  • qwik.jp - qwik リソースおよび情報

    This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.