富士通で個人情報漏洩の恐れ、業務PCのマルウエア感染で「ファイル持ち出せる状態」 2024.03.15
皆はどんな現場で,どんな仕事をしているのだろう。何に悩み,どうやって乗り越えているのだろう。プロの仕事とそうでない仕事の境目はどこにあるのだろう。システム開発や運用の現場を歩き,そこで見聞きした面白い話,感動的な話,すごい話を紹介します。 ・大企業からベンチャーまで ぼくはこんな現場を歩いてきた ・SEを潰した値引き 信頼も連帯感も消えた ・期限は明日――若手SEの気迫を見た ・寝不足のプレゼン ドリンク剤も効かず ・中国の開発現場もすごい 若き社長が率いる修羅場 ・オンラインダウン発生! あの日,何もできなかった ・建築設計事務所で見た 巨匠のすごいレビュー ・コンサル泣かせの現場 “小さな王国”の弊害 ・逝去した巨匠への追悼 感激したあの言葉 ・人の話を聞かない40代 あるコンサルの失敗 ・過ぎたるは及ばざるがごとし 作りすぎたRFPの悲劇 ・人間万事塞翁が馬 得難いレクチャーの裏事情
写真●「X-over Development Conference 2007」で講演する,まつもとゆきひろ氏 「結局のところ,顧客に何が必要かは,顧客にも開発者にも理解は不可能だ。そうならば,まずアプリケーションを作って,それを使ってもらい,顧客に合うように直すしかない。これからのエンタープライズ開発も,とにかく速く安く作って,直すことが重要になる」--。プログラム言語「Ruby」の開発者であるまつもとゆきひろ氏は9月7日,ソフト開発をテーマにしたイベント「X-over Development Conference 2007」の講演でこう主張した。 まつもとゆきひろ氏の講演テーマは「Web 2.0時代のエンタープライズ開発」というもの。Web 2.0時代のアプリケーションは,「YouTube」に代表されるように,「仕組みそのものよりも,データがどれだけ集まっているかが生死を分けている」(ま
育成というのはコストがかかる。わかってるんだけどうまくいかない。今回は夏休みなのでその辺を考察。 自分なら1日でできることを部下にやらせてみると・・・ 3日も4日もかかる。修正してあげてまた3日かかる。時間がかかってしょうがない。 でも自分でやってはいけない。そんなことやってたら、いつまでたっても部下は自分で「仕事」ができるようにならない。作業はできても仕事ができない人間になってしまう。 ところで仕事には納期がある。 自分でやれば納期に間に合うのに部下にやらせて納期遅れを起こす。 ここに「つい、自分でやっちゃう」ロジックが起動する 「今回は間に合わせるために仕方なく私が」「任せられる人材がいなくて」 これはよくできた隠れ蓑だ。いいわけにしかすぎない。 ここは逆転の発想が必要。 部下に任せた結果、納期が間に合わない仕事なんてやらなければいい。 それを場当たり的な仕事というのだ。いまは凌げても
図7 Mix-inによるStreamクラスの構築例<BR>クラス階層はツリー構造を保ちつつ,コードのコピーも避けている。 継承には2つの意味がある Javaのような静的型のオブジェクト指向言語の変数には,変数を介して呼び出されるメソッドを制限する働きがありました。ただし,制限がかかるのは「どのようなメソッドを持っているか」であって,「どのように実装されているか」ではありません。 今まで一まとめにして継承と呼んできましたが,実は継承には2つの異なる概念が含まれています。一つは,「どのようなメソッドを持っているか」あるいは「どのように振る舞うか」ということに着目した「仕様の継承」です。 もう一つは「どのようなデータ構造を使い,どのようなアルゴリズムで処理するか」ということに着目した「実装の継承」です。 静的型言語では両者の区別が重要になります*4。Javaでもこの2つを明確に区別しており,実装
かつては“常識”だったのに,今ではそうでなくなっている――ソフトウエア開発の世界では,そんな知識や習慣がめずらしくない。10年以上のキャリアを持つ開発者の方なら,思い当たるものがきっとあるはずだ。 例えば,昔は「すでに動作しているコードに変更を加えてはいけない」というのが常識だった。汚いコードに手を入れようとして先輩にしかられた経験のある方もいらっしゃるだろう。ところが今では,「リファクタリング」の名のもとに将来問題が発生しそうなコードを修正する作業がむしろ推奨されている。EclipseやJBuilderなどのリファクタリング支援機能を搭載した開発環境も増えており,今やリファクタリングは完全に市民権を得たと言ってよいだろう。 オブジェクト指向技術の浸透,変化が大きな要因 もちろん,常識が変わった背景にはオブジェクト指向開発の浸透といった開発手法の変化があることは間違いない。あらかじめアプリ
これまで2回続けてデザイン・パターンについて学んできました。今回は,重要なソフトウエア開発原理として知られるオープン・クローズ原則(OCP)の観点からデザイン・パターンを眺めてみましょう。単なる流用可能なソフトウエア・パターン以上の価値がデザイン・パターンに隠れていることが発見できるでしょう。 昔々,技術者たちは計算機などの機械を「金物」という意味でハードウエアと呼びました。さらに実体のないプログラムのことをソフトウエアと呼ぶようになりました。今ではハードウエアもソフトウエアもすっかりコンピュータ関連用語として定着してしまいましたが,元々は技術者間の俗語のようなものだったのです。 ソフトウエアと呼ぶからには「柔らかい」かというと,実際には柔軟性に乏しいものが多いです。規模の小さなものであれば,変更は簡単で柔らかい感じがありますが,ビジネスに用いられるような大規模ソフトウエアでは各部分の依存
■今回から週1回の連載で、中小ソフトハウスの経営者の方を対象に、伸びるソフト会社が共通して持っている条件についてお話させていただきます。 「長島さん、どうしてもこれ以上、売り上げが伸びないんです」 経営相談を受けていると、なぜか共通して停滞する“いわゆる”壁があります。 【年商3億円 ⇒ 年商7億円 ⇒ 年商10億円 ⇒ 年商30億円】 実は、この年商規模の前後で、なぜか成長が鈍化したり、売り上げが戻ってしまったりと不思議な現象が起きています。特に年商3億円の壁は、ソフトハウスが最初にぶち当たる大きな壁となります。 経営者は、年商3億円の分岐点を知らずに、さらに上を目指して努力を重ねます。年商3億円企業が次に目指すのは年商10億円です。ところが、そんな目標を立てたのにもかかわらず、3億円前後でうろうろします。さらに、社内外においていろんな問題が発生してきます。例えば、こんな感じです。 -赤
「Code Reading―オープンソースから学ぶソフトウェア開発技法」(毎日コミュニケーションズ発行,写真1)という本があります。私はこの本の監訳者ですから,やや自画自賛になってしまいますが,ソースコードの読み方を主題にした本はほかにはあまりありません。技法からツール,データ構造,アーキテクチャ,さらには実際にコードを読んで利用する実例まで紹介している網羅的で良い本だと思います。 この本の「はじめに」で「達人プログラマー」として知られるDave Thomas氏は以下のように書いています。 他人の作品を読まなかった偉大な作家,他人の筆づかいを研究しなかった偉大な画家,同僚の肩越しに技を盗まなかった腕のよい外科医,副操縦席で実地の経験を積まなかった767機長――果たして,そんな人たちが本当にいるのでしょうか? たしかにその通りです。ソフトウエア以外の領域では修行することとはすなわち,他の人の
結城浩 (ゆうき ひろし) Java,Perlなどの書籍でおなじみの著者。 最新刊は「数学ガール」。 このイラストは結城浩さん書き下ろしのもの。 http://www.hyuki.com/ 日経ソフトウエア2007年8月号,特集のテーマはプログラミング言語のRubyです。「Ruby大作戦」と題した本特集の中で,Ruby作者のまつもとゆきひろ氏と,JavaやPerlの書籍や本誌連載の執筆,Web上での活動で著名な結城浩氏の対談を設けました。以下は,日経ソフトウエア2007年8月号に掲載した対談の全内容です。ぜひお楽しみください。なお,この対談では,お二人のファンで日経ソフトウエア特集「Ruby大作戦」のPart5にも寄稿いただいた松岡浩平氏にも同席していただきました。この対談でRubyに興味を持たれた方は,ぜひ日経ソフトウエア2007年8月号をお読みください。 はじめてのRuby ――結城さ
第0回 あらためてRuby入門 まつもとゆきひろ氏自身による「Ruby入門」をお届けします。日経Linuxの連載開始前の特別企画(2005年4月号)として,Rubyが他のスクリプト言語やオブジェクト指向言語とどこが違うのか,なぜ便利なのかを中心に解説してもらったものです。 ● 基本と他言語との違い ● 実装とRuby誕生の秘密 第1回 プログラミングとオブジェクト指向の関係 プログラマを目指す人々の中にも,「オブジェクト指向は難しい」とか,「なかなか分からない」という印象を持つ方が多いようです。そこで,Rubyを題材にオブジェクト指向という考え方について説明していきます。 ● その1 ● その2 ● その3 第2回 抽象データと継承 オブジェクト指向プログラミングを構成する3原則のうち,前回は「ポリモーフィズム」を学びました。今回はオブジェクト指向の歴史を復習した後,残りの「データ抽象」と
コンピュータを使って久しいなら,5.25インチ・フロッピ・ディスク(FD)を覚えているだろう。5.25インチFDは容量も少なく,動きも遅く,信頼性も低くかったが,当時はハードディスクよりもずいぶん安かったので,筆者は5.25インチFDを使わざるを得なかった。ハードディスクが安価になることで「信頼性の高い」ハードディスクに移行できたわけだが,本当にハードディスクの信頼性は5.25インチFDより高いのだろうか? 米カーネギーメロン大学のBianca Schroeder氏とGarth A. Gibson氏が2007年初めに発表したレポート「Disk failures in the real world: What does an MTTF of 1,000,000 hours mean to you?(ディスク故障の現実:100万時間のMTTFの意味)」で,Schroeder氏とGarth氏は,
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く