グーグルのソフトウェア特許攻勢 - カレーなる辛口Javaな加齢日記
http://blogs.itmedia.co.jp/kurikiyo/2006/03/post_9254.html グーグルのソフトウェア特許攻勢はかなり強力なものがあります。(中略)漏れのない強力な出願という印象を受けました。 べつに驚くことはあるまい？ 米国のザルみたいな特許審査の実状の前では，どんな企業でも防衛特許を出すのは当然だ*1．IBMだろうとIntelだろうと，巨大企業なら数多くの特許を出願している．今や巨大企業の仲間入りしたGoogleなら当然だろう．*2 出願する明細書についても漏れのない強力なものとなるように，専任の弁護士がチェックくらいするだろう．裁判で争っても負けないように過去の判例も考慮して明細書を記述するのは，素人には案外難しい． ソフトウェア特許反対論（松下の特許が無効だ云々ではなく、ソフトウェア特許制度そのものがおかしい）を主張していた人たちが結構いいたと
「ITは文系領域も多いからコンピュータサイエンスなんて知らなくていいんだよ」的な言説が蔓延ることが業界の現状を招いているのだが - novtan別館
今年最後の殴り書き。 ITに向いている人材が文系か理系かなんていう議論にはまったく意味がない。ものづくりには沢山のステップがあり、また各ステップの仕事には様々なタスクがあり、それぞれがいわゆる文系的タスクであったり理系的タスクであったりする。ITという名のつく職業における仕事は多くの部分で事務作業化が目指され、また、実現されてきているけれども、設計は決して事務作業ではない。設計がいらない建物はプレハブくらいだろう。プレハブを売るのがITの仕事の全てである、という話であれば、あるいは正しいのかもしれないが。 私がここで主に想定し、前提にしていた「ITのスキル」は、SEやプロジェクト・マネージャーのように対人スキルを要求される職務ではなく、純粋に「プログラミング」や「設計」のスキルだった。 ITエンジニアにコンピュータ・サイエンスは必須か - モジログ コンピュータ・サイエンスの知識は、もちろ
Internet Week 2008 IT Community Impact! ～世界を変える新たな潮流～ | gihyo.jp
Internet Week 2008 IT Community Impact! ～世界を変える新たな潮流～ 11月25日、Internet Week 2008にて、コミュニティ活動や勉強会をテーマとしたトラック「IT Community Impact! ～世界を変える新たな潮流～」が開催されました。 内容は、最近のIT系のコミュニティ活動やイベントに関するソフト、ハード両面での変化や最新事情を、実際に活動に深く関わっているキーパーソンに語っていただき、また相互に議論することで、これからの方向性を探るというもの。全体が四部構成になっており、1日かけて「(1)ITコミュニティイベントの概要」「(2)パネルディスカッション『地域コミュニティ』」「(3)運営をサポートするツール紹介」「(4)パネルディスカッション『コミュニティの未来を語る』」の4つのセッションが行われました。 例年
「バックアップすればよかった」という指摘に「だろバカ」は余計 - @katzchang.contexts
上から目線の人達は失敗を隠蔽する社会を作っている - 未来のいつか/hyoshiokの日記のコメント欄より。ブコメにも書いたけど、大切なことなので何回でも書きます。 id:otsune だからなんで「svn repoのバックアップをとって無くて破損した失敗」を「バカだなぁ。まともな技術者はやらないだろ」と正しく正確に評価することが「切り捨てる」になるのでしょうか？ それっと「正しい事をいわれると萎縮するから言うな」ってことですよね。どこの昭和の風習ですか 上から目線の人達は失敗を隠蔽する社会を作っている - 未来のいつか/hyoshiokの日記 「バックアップをとるべき」という指摘に「だろバカ」は余計という意味において、id:hyoshiokの主張は全く正しい。 指摘する側は指摘される側の感情を特別にケアしろとは言わないけど、他人を馬鹿呼ばわりしないように気を付けるのは、なにも「特別なケア
上から目線の人達は失敗を隠蔽する社会を作っている - 未来のいつか/hyoshiokの日記
はてぶとか見ていると、すげー上から目線の人がいて、あああ、こーゆー人達って、何様？とか思ってしまう。あ、俺様かあ、なるほど。 デブサミのコミュニティLTの裏番組で、株式会社はてなの開発戦略*1というのがあって、わたしも司会なんかしていなかったら、聞きにいきたかったセッションなのだけど、それが予想にたがわず、素晴しいものだったということは、皆さんのブログの感想戦などを拝見していると思ったりする。 gitいいよねgitという内容なのか、そうでないかは現場にいなかったので微妙な空気まではわからない。git移行のきっかけが、SVNのリポジトリの崩壊、瓦解、というのがほほえましくもあり、ツッコミどころでもあり。 はてぶのコメントで http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/rx7/20090212/p1 なんかで、エラソーに言っている人がいる
Linus「C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが 簡単に生産されるようになってる」
/15 [4] (21:54) 原文: http://lwn.net/Articles/249460/ From: xxx To: xxx Subject: Re: [RFC] builin-mailinfo.c をマシな文字列ライブラリを使うようにすること Date: Thu, 6 Sep 2007 18:50:28 +0100 (BST) Message-ID: <alpine.LFD.0.999.0709061839510.5626@evo.linux-foundation.org> On Wed, 5 Sep 2007, Dmitry Kakurin wrote: > > Git のソースコードを最初に見たとき、ヘンだと思ったこと: > 1. C++ じゃなくてただの C を使ってる。理由は謎。移植性がどうとか言わないで、 > そんなのウソに決まってるから。 *あんた* のほうこそ
「無駄」とは何なのか - u_1rohのカタチ
「無駄」の意味が変わってきたのかもしれないなー、などと思った。 「私がこんな設計をしたら，社内で絶対通らないですよ」（技術者の一人）。「技術的にすごいと感じるところは一つもない。我々ならもっと安く作れる」（ある技術者）。MacBook Airの内部構成は，設計の未熟さを表しているのだろうか。 【MacBook Air分解その5】「外は無駄なし，中身は無駄だらけ」 | 日経 xTECH（クロステック） 最大の無駄は「売れないものを作ること」という考え方もあるのではないか。 まだ売れるかどうか分からないものの品質を作りこむことは、徒労に終わる可能性がある。つまり「無駄」になる可能性がある。品質を高く、製造コストを低く設計するのが、設計の真骨頂だとは思うのだけれど、そもそもその商品が売れなければ、その努力が無駄になってしまう。 だから、まずリリースする。 コンセプトを市場にアウトプットする。 そ
SI業界を目指す君達へ贈る「何故システム開発はテンパるのか」 - novtan別館
先日学生に聞かれたんですよ。 「下流工程は大変って聞きますが、上流は楽なんですよね？」 よろしい、君はよく勉強している。でも根本的に間違っている。下流工程が辛いのは、上流工程でちゃんと仕事ができなかったからだ*1。 というわけで、主に学生向きに話を単純化して語ってみます。これが普通だとか、一般的だとか言うつもりはなく、違う視点もあるかと思いますが、一つの考え方として。 SIでのシステム開発は、建設業にたとえられます。が。 顧客の希望を聞き、設計し、施工し、引き渡す。こういった工程を踏む仕事ということで、システム開発はよく建設業にたとえられます。実際に工程管理の手法なども似通っています。ところが、大抵の場合、耐震偽造をした建築物よりもシステムのほうが脆弱に仕上がります。何故でしょうか。 一つには、建物の図面を引くには建築士の資格が必要ですが、システムの設計に資格は必要ありません。 もう一つ、
2008-09-02
出産以来感じてきたが、ずっと書くのをためらっていた。夫ともども、いいかげん腹に据えかねたのと、同じような思いをしている人が少なくないことを知ったので、書くことにする。 ワークライフバランスという点から見れば、私の勤務先は完璧である。職場の上司や同僚はこちらの状況を慮って親切な言葉をかけてくれるし、人事の担当者は産休にあたり、使える制度についてものすごく丁寧に教えてくれた。夫の勤務先の環境も大変良い。生後数ヶ月の子どもを連れて行った時は育児経験を持つ教授たちが色々なアドバイスをしてくれたし、直属の上司は出産祝に育児百科をプレゼントしてくれた。現在、夫は家事の7割、育児のほぼ半分をやってくれるので、サポート体制は120点である。 思わぬ落とし穴は親族にあった。彼ら（というより、彼女ら）は、私たちがどのように育児をしているのか、知りもせず、また尋ねもせずに、口出ししてくる。曰く「おっぱいの方が（
エドワード・ヨードン、デスマーチを成功に導く対症療法を説く
ソフトウェアシンポジウム「JaSST'07 Tokyo」の基調講演を務めたエドワード・ヨードン氏は、デスマーチに見られる問題点には、きわめて人間くさい部分が大きく影響していると述べた。 「デスマーチは人や予算を増やせば解決するという短絡的な問題ではない」――ソフトウェアテスト技術振興協会（ASTER）が開催したソフトウェアシンポジウム「JaSST'07 Tokyo」のオープニングキーノートを務めたのは、エドワード・ヨードン氏。失敗プロジェクトの代名詞となった「デスマーチ」という問題を取り上げた「デスマーチ」の著者である同氏が、「デスマーチ――ソフトウエア開発プロジェクトはなぜ混乱するのか」と題し、デスマーチの原因や対策について語った。 冒頭、同氏はデスマーチとは何かを再度定義した。いわく、「スケジュール（納期）のプレッシャーが強く、人員も予算もそれに見合ったものでなく、さらに高い確率で失敗
プロジェクト失敗率とリスク - masayang's diary
DDJにてScott Ambler氏がThe Distributed Agile Teamという記事を発表している。大規模分散Agile開発に関するお話。 詳しくはそちらを読んでもらうことにして、ここでは大規模Agileのプロジェクト成功率に関してちょいとコメント。記事にもあるけど 大規模Agile全体での成功率...78% 開発チームが一カ所に集まっている場合の成功率...83% 開発チームが近距離分散している場合の成功率...72% 開発チームが遠距離分散している場合の成功率...60% という統計が出ている。 この数字をみて「失敗率が20%以上もあるのなら、Agileはダメだな」と思った人は...考え直してほしい。 優先度の高いフィーチャから開発していくAgileでは、プロジェクトの成否が比較的早い段階で判明する。場合によっては一ヶ月で「だめだこりゃ」となるかもしれない。 早期に失敗
ソフトウェア開発を理解していない人々(2) - 酔狂人の異説(新館)
ソフトウェアの開発プロセスの標準化はあきらめきれないものらしく、13日のエントリの後も開発プロセスの標準化の話が続いている。 http://d.hatena.ne.jp/masanobuimai/20050613#1118653419 http://d.hatena.ne.jp/m_pixy/20050614 http://d.hatena.ne.jp/taichitaichi/20050614#1118747337 http://d.hatena.ne.jp/JavaBlack/20050619#p2 開発プロセスの標準化がうまくいかない大きな理由は、開発プロセスの標準化の基となっているソフトウェア工学に大きな欠陥があるためである。その欠陥を認識し、対処しないかぎり、開発プロセスの標準化は逆効果になるのがおちである。 ソフトウェアの規模はソフトウェアの生産量をあらわさない ソフトウェア工
ソフトウェア開発を理解していない人々 - 酔狂人の異説(新館)
ソフトウェアの開発プロセスが一部で話題になっている。 http://d.hatena.ne.jp/JavaBlack/20050602#p1 http://d.hatena.ne.jp/JavaBlack/20050605#p2 http://www.programmers-paradise.com/tdiary/?date=20050607#p02 http://d.hatena.ne.jp/masanobuimai/20050611#1118460560 http://blog.uzushio.org/?date=20050611#p03 http://d.hatena.ne.jp/JavaBlack/20050613 ソフトウェアを開発する以上、結果として、何らかのプロセスを経て開発が行われる。そのプロセスを標準化すべきか否かという点で意見の相違が生じる。 開発プロセスの標準化は逆効
僕がTDDをやめた理由 - カタチづくり
タイトルは、まあ、半分釣り。TDDな人もそうでない人も、肩の力を抜いてお気楽にどうぞ。 本題に入る前に まずお礼 ここで書くことは、前の記事 TDDはYAGNIに矛盾する？ - カタチづくり から派生して色んな方と意見を交わした経験が元になっています。この場を借りて、色々とアドバイスを頂いた方に心から感謝の意を表します。 特にコメント欄にお寄せいただいた きしだ さんのコメントは、コメントと言うよりももはや一つの素晴らしい記事となっていて、もう必読といってもいいレベルじゃないでしょうか。本当にありがとうございます。特にBDDについて大きなヒントを頂きました。 押し付けではなく、交換 タイトルから想像がつくとおり、ここにはどうしてもTDDに対して否定的な意見ばかりが並んでしまう。でも、だからといって僕がTDDを完全に否定しているとは思わないで欲しい。 僕が今一番恐れていることは、TDDに対し
酔狂人の異説(新館)
『平気で夏に｢缶コーヒー｣｢スポドリ｣飲む危うさ』という記事がかなり酷いので、コメントしておきます。 以下のような問題があります 摂取量等を無視して害は語れない 天然か合成は害の強弱とは別 天然甘味料にもリスクがある 摂取量等を無視して害は語れない 以下のような有害性の記述がありますが、摂取量等を無視して害は語れません。 アセスルファムKはイヌを使った実験で、肝臓にダメージを与えたり、免疫細胞の1種のリンパ球を減らすことがわかっています。 「水中毒」とか「酸素中毒」といった言葉があります。水や酸素ですら、過剰に摂取すると命にかかわります。一般に、ほぼ全ての物質が摂取しすぎると有害です。上記のように量的な記述無く有害と言っても意味はありません。「水を過剰に摂取すると死ぬ」ということは、「水を摂取してはいけない」ということを意味しません。 天然か合成は害の強弱とは別 天然か合成は害の強弱とは別
「2億円が820万」 | おごちゃんの雑文
高橋さんの記事がばずってた。 見積もり2億円のIP電話を820万円で構築した秋田県大館市から学べること これをネタにしたエントリにどんなことが書かれているかは、まぁ読むまでもないなーと感じるのは「この記事に対する読者コメント」を見たらわかる。 わりと冷静に、 1人月（ではなく2人月！）300万〜400万の価値は？ 2億円の見積もりされたのを820万でできたのはすばらしいと思う とかあるけど、ちょっとポイント違うんじゃないかな。 「ポイント違う」というのは、どちらも「SIer視点」だからだ。それぞれを要約したら、 素人としてはよくやったよね ベンダの見積り根拠ってのは… 「安全率」入ってないよ に要約されるように思うし(と読めるんだけど)、そこで書かれている他のエントリの空気とかもその辺に集中してるようだけど、この記事でのポイントはそこじゃない。 この事例での一番のポイントは、実はFLOSS
Developer Testing and the Importance of Context
How is it we keep falling for the same trick? Why is it so hard to remember: there is no silver bullet. I've spent a significant amount of my time for the past 3 years focusing on testing. I've learned several lessons.Setup methods are evilOne assertion or expectation per testDuplicate code in tests can be a good thingTest names aren't always requiredReplacing mocks with stubs can improve essence
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
