ド・ゴール伝 第１部その１
シャルル・ド・ゴールは１８９０年１１月２２日、北フランスのリール市に生まれた。先祖は１３世紀に遡る下級貴族（註1）といい、父アンリは医学・理学・文学の３つの博士号をもつ碩学、熱心なカトリック教徒で、イエズス会系の中学校で歴史を教えていた。祖父ジュリアンもまた著名な歴史学者であり、シャルルは幼時から歴史に興味をおぼえ、祖国フランスの名誉と伝統に誇りを抱くようになった。１４歳にして戯曲を創作、長じてもフランス・ドイツの文学・哲学書を愛好した。 註１ 祖先ジャン・ド・ゴールは百年戦争の「アジャンクールの戦い」の際、イングランドの長弓隊に対抗して機動戦術をとるべきことを進言したが容れられなかったという。また、ド・ゴールの曾祖父はルイ１６世の法律顧問をつとめていてフランス革命の時に投獄されたことがあるともいう。 ド・ゴールは最初は伝道師を目指していたともいうが、それよりも自身の身長２mという立派な体
『ひどい体制ひどいPMひどい営業』
不遇なソフト屋の長い転職日記ソフトウエア企業を数社経て、今は社内SEとして働いております。ソフト業界の事やこれから業界を志望する人向けに書いてますが、どうでも言いことまで書いてます。このブログは3世代目。 あまり大きくも無く、かと言って1・2名くらいで出来るものでもない依頼ってのが結構多い。 大きいとなると10名くらいになるし、ソフト会社が何社も入っているという事もあれば、何年も開発が続いているものになる。 大抵これくらいの仕事だと長くて3ヵ月（要件定義から納品まで）。 でも、実際はもっと時間が必要と言うことが多いと感じますが、そういう作業を取ってきてしまうのは営業の責任であり、管理者層や会社の責任でもあります。本来はSEが場に出て、会社の予算とアサイン状況を元に考えながら、本当に請けて良いかの結果を出した後、本格的に開発が実施されるのが「筋」です。 ところが、そうも言っていられないソフト
岡崎市の被害届，学力崩壊，悪夢を形に，石原都知事 - カレーなる辛口Javaな加齢日記
岡崎市の被害届 このまま放置すると，日本のIT業界の黒歴史に岡崎市の名を再び刻むことになると，岡崎市民の皆さんは理解しているんだろうか． 「大学でアルファベットを教えて何が悪い」 http://hamusoku.com/archives/4123267.html http://d.hatena.ne.jp/gorotaku/20110219/1298093855 http://togetter.com/li/102569 キッチリと悪いですねえ， 大学は高等教育機関であり研究機関．そんな落ちこぼれ中学生むけ学習塾みたいなもののために存在しているわけじゃない． ある段階で何らかの理由によりつまづいたら、よっぽど幸運にすばらしい教師に巡り合う場合を除いて、その後ずっと落ちこぼれ続ける。積み上がらない。 んなわけない．努力すればそのくらい挽回できる．TOEIC 700点くらいは独学で十分到達可能
「Redmineによるタスクマネジメント実践技法」を読んだ
創薬研究というのは細かな作業が沢山あり、変化の激しいテスト工程なのに、そのインフラにはBTSとかITSとかないのが不自然だと思っていて、この前寄稿したときにちと触れといた。僕はソフトウェア業界にいるわけじゃないけど、問題解決の方法論としては似たような部分があるから参考になるんじゃないかと常々思っていたら、ズバリな本が出ることを知ってすぐに予約しといた。 で、一昨日届いたので今日の移動時に一気に読んだ。 チケット駆動開発的なアプローチは自分の仕事管理では既に取り入れていたのであった。自分では文書駆動開発だと思っていたけど本書を読んだら、これは明らかにチケット駆動開発のコンテクストだよなと。 個人的には第一部の技法は非常に勉強になった。第二部は実際にRedmineをどう使うかという話はソフトウェア開発としては色々面白かったが、自分ではRedmine使ったことがないので、ピンと来ない話も幾つかあ
Rails3.1の初期化プロセスを細かく追いかけたRailsGuidesの記事を和訳したよ:ミームの死骸を越えてゆけ
This domain may be for sale!
定量的なソフトウェア品質管理（pdf)
日科技連とSQiPの取り組み 1980年、日科技連では、日本におけるソフトウェア製品の品質向上と効果的開発の方法論の確立を目指して、「ソフトウェア生産管理研究委員会」（SPC, Software Production Control）を設置しました。 以来、「TQMとソフトウェア工学の結婚」を標榜し、日本的品質管理をソフトウェア生産に適用するための調査・研究・普及を行ってまいりました。 2007年に、この活動が「ソフトウェア品質に関する活動」であると分かりやすくすることと、ソフトウェア技術職という専門的職業の矜持を大事にしたいという思いから、SQiP(Software Quality Profession)に改称しました。 1980年の設立当初は、メインフレーマーで培われたソフトウェア品質技術・施策を議論する場でしたが、現在はソフトウェア産業に関わるすべての方々が議論できる場になっています
入門Mercurialの感想 - プログラマの思索
Mercurial本「入門Mercurial Linux/Windows対応」の著者フジワラさんから献本して頂いたので感想をメモ。 【元ネタ】 Mercurial の利用 特集：Mercurialではじめる分散構成管理｜gihyo.jp … 技術評論社 スィンプロ (sinproject) Windows Vista 環境で TortoiseHG（Mercurial）を利用してバージョン管理とバックアップを行う (3) ダウンロード - TortoiseHg - SourceForge.JP 「入門Mercurial Linux/Windows対応」は分散バージョン管理Mercurialの入門本。 平易に書かれていてとても読みやすい。 また、Mercurialのコマンド一覧が付録にあるので、リファレンスとしても使える。 エピローグに「あ！構成管理って楽しいんだ？！」という節がある。 Mer
Redmineによるタスクマネジメント実践技法 - Architect's Log
ブログ（プログラマの思索）で日々質の高いエントリを投稿しているあきぴーさんの執筆ということで心待ちにしていたが、期待を裏切らない内容だった。やはり実践を伴った主張には説得力がある。 プログラマの思索 IT業界に身をおいて、1日の労働後、心に溜まった疑問を一つずつ点検してみる。 ... チケット駆動開発の効用は、何といってもトレーサビリティ（追跡可能性）の確保だろう。 ソースの変更と変更理由の結束の保証。一度でも開発を経験した人なら、これがどれだけ大きな価値をもつか説明は不要だろう。顧客の「いつどんな理由でこの変更をしたのですか？」という問い合わせにマネージャは即答でき、開発者はコメントが書かれていることを祈りながら過去のソースコードを追う必要がなくなるわけだから。 問題は導入コストだろう。この書籍で実現されていることには憧憬すら覚えたが、アプリケーションは無償でも学習コストは非常に高いと感
Redmineのトラッカーやステータスの付け方 - プログラマの思索
Redmineのトラッカーやステータスの付け方の記事があったのでメモ。 【元ネタ】 Redmine チケットのトラッカーとステータス項目の意味と設定 - developer (引用) * トラッカー o ドキュメント + ドキュメント書き。 o 調査・検証 + 調査、検証、研究など。 o 機能 + 機能の追加や変更など。 o 不具合／バグ + バグや不具合登録する。 o 要望 + ユーザーからの要望。 + 後で「機能」や「バグ」に変化する可能性がある。 o サポート + ユーザーからの問い合わせは、とりあえず登録。 + 後で「要望」や「バグ」に変化する可能性がある。 o 障害 + なんらかの障害が発生したら、とりあえず登録。 + このチケットに関連した「不具合／バグ」のチケットが後から追加される可能性あり。 o 環境 + 環境構築・環境整備や設定変更など。 o アイデア + アイデアを登録
Red Apple and Black Cat::Redmine ガントチャートに日付を表示してみた。
10月にはいって、下期に入ったので上期を反省して Redmineをもっと積極的に使おうとしています。 で、ついつい遠ざかってしまうのは使いづらい点があるからだと いうことでちょっとずつ不満な点はできる範囲でなおそうかと。 そのうちのひとつは ガントチャートの表示。 あれ、何もしてないと、週と曜日がでるんですが、日付がないので戸惑うんです。 週を意識して生活している人ってそんなにいるのかなぁ。 『あ、そろそろ42週目だからあの件を連絡しないと』 という使い方は自分の人生のなかでは経験ありません。 ということで、日付表示の方法を模索してたらやってるかたがいました。 半年前に調べたときは見つからなかったのですが さがしかたがわるかったのか？ 参考HPは こちら。 実は、ここで書かれている参考ソースの修正点が172行目当たりの表記が崩れていて よく分からなかったので
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 問題プロジェクトの火消し術: 長尾清一: 本