Reddit - Dive into anythingHaskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment in Software Prototyping Productivity [PDF]
ソフトウェア開発技術者が知っておくべき５つの法則 - スタジオ・アルカナ技術ブログ
はいどうも～。 本日はhidetarouの番ですが休業中のため代打でしゃしゃり出たエンジニア吉田です。 「○○○な●●つの○○○」なんて感じのタイトルを付けると、 なんだか興味が惹かれるというのを目にしたので活用してみました。 ※個人的にはそうでもない気がしている。 というわけで、今回はソフトウェアに関係しそうな「法則」を５つほど紹介し、 それをソフトウェア開発業務にどう生かしていくかを考えてみます。 本日ご紹介する法則は以下の5つです。 ブルックスの法則コンウェイの法則パーキンソンの法則マーフィーの法則ハインリッヒの法則 でわでわ、早速。 ブルックスの法則 「遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ」 これは、IBMのOS/360（メインフレームOS）の開発者であるフレデリック・ブルックスが 名著「人月の神話」で提唱したプロジェクトマネジメントに関する法則です
OS & システムソフトウェアの一流国際会議 - 品川高廣（東京大学）のブログ
OSやシステムソフトウェアをメイントピックとする著名な国際会議を４つ紹介します。 SOSP OSDI EuroSys USENIX ATC SOSP (ACM Symposium on Operating Systems Principles) 概要 OSやシステムソフトウェアの分野における世界最高峰の国際会議。名称は "Operating Systems" だが、分散システム、ネットワーク、ストレージ、セキュリティ、組み込み等に関するシステムソフトウェア全般を幅広く扱う。 2年に1回しか開催されない（下記のOSDIと交互に開催） 第1回は1967年、2011年に第23回 最近7回（1999年〜2011年）の平均採択率は 17% (154本/885本) 1999 2001 2003 2005 2007 2009 2011 計 投稿 90 85 128 155 131 139 157 885
誤発注裁判が改めて問う「バグは重過失か」
「東京証券取引所に重大な落ち度があることは、火を見るより明らかです」。2013年3月18日、東京高等裁判所での第一回口頭弁論。みずほ証券の代理人である岩倉正和弁護士は、東証の株式売買システムに潜んでいた誤発注を取り消せないバグの概要を説明する大型パネルを法廷内に持ち込み、25分にわたって熱弁を振るった。 対する東証代理人の山田和彦弁護士は終始落ち着いた口調で「合理的信頼性を有するシステムを提供できていれば、たとえバグが一つあったとしても、債務不履行には当たりません」と述べ、13分ほどで弁論を終えた。同日、裁判は結審した。 みずほ証券と東証による株誤発注裁判の控訴審は、両社がソフトウエア工学上の論争を戦わせる異例の展開になった（図1）。
チーム開発レトロスペクティブ
大学の講義の関係で、4月から12月まで7人のチームで開発を行いました。自分の役割はチームリーダーでした。これはある種残念なことかもしれませんが、いろいろやりたいことができる立場であったので、やってみたいことを出来る範囲で盛り込んでいきました。この記事では、このチーム開発における制約条件を述べた後に、その制約下でできそうだと考えたことをまとめます。そして実際に行ったことについて、その意図と実際の運用結果、反省点をまとめます。最後に適当に雑感など述べます。 制約条件 このチーム開発を行うプロジェクトでは次のような制約条件がありました: 開発期間は5月から11月まで 給与は出ない チーム人数は6人から7人 開発するアプリケーションは「大学生の学びを楽しくするアプリケーション」 Android上で動作するアプリケーションであること これらの制約条件のうち最もきついのは最初の開発期間です。一見開発期
こんなプログラマはアジャイル出来ますって言ったらアカンやろ - メソッド屋のブログ
最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい！どの口がアジャイル出来るって言ってるねん！」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを１０年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか？」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ
例外設計における大罪 - 契約
unassert - encourage reliable programming by writing assertions in productionTakuto Wada
スレッドの(というか並行処理の)歴史 - 西尾泰和のはてなダイアリー
Twitterから転載 ふとスレッドっていつ発明されたんだろうと調べてみたけどよくわからない。Linuxがカーネルスレッドをサポートしたのが2.6からで2003年とか意外と新しい？？もちろんユーザレベルのスレッドはもっと古いんだろうけど、いつからだろう。 hideaki_t: NeXTSTEP(Mach 2.0?)にはcthreadがありました。 atsuoishimoto: 私がスレッドって用語初めて聞いたのは、たしか'90年代初頭のOS/2だったかなぁ？ これが2004年の話か＞NetBSD 2.x+, and DragonFly BSD implement LWPs as kernel threads (1:1 model) shidocchi: 私は院の研究室でMachのソースリーディングをやってた頃知った。 これが2001年 ＞ October 2, 2001 Mac OS X
新しいソフトウエア開発手法
マーチン・フォウラー チーフサイエンティスト , ThoughtWorks 過去数年にわたり、「ライトな」ソフトウエア開発手法が急速に関心を集めつつある。それらは、官僚制に対する解毒剤とも、ハッキングのライセンスとも見なされているが、ソフトウエア関係者全ての興味をかきたてている。このエッセイで、私は「ライトな」開発手法の単に「軽い」側面だけでなく適応的な性質や人間中心主義に着目しながら、それらが流行る理由について掘り下げてみたい。また、この系統のプロセスに対してサマリーとリファレンスを提供し、この踏み出されてまもない道を行くべきかどうかを選択するために、考慮すべき要因について考えてみたい。 開発手法ゼロから、重量級の手法へ、そして「ライトな」手法へ 予見的手法 対 適応的手法 デザインとモノ作りを分割する だいたい仕様を予見できたことがない 予測は絶対に不可能なんだろうか? 予見不可能なプ
The Joel Test: 12 Steps to Better Code
Have you ever heard of SEMA? It’s a fairly esoteric system for measuring how good a software team is. No, wait! Don’t follow that link! It will take you about six years just to understand that stuff. So I’ve come up with my own, highly irresponsible, sloppy test to rate the quality of a software team. The great part about it is that it takes about 3 minutes. With all the time you save, you can go
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
人名を冠したソフトウェア開発の19の法則
達人プログラマーとわたし/PragProg and Me
History of WaterFall
Software Engineering Is Engineering
Thinking Objectively: Software Engineering in the Small | March 2000 | Communications of the ACM
Software Engineering Considered Harmful | November 2002 | Communications of the ACM
Software Engineering and Formal Methods | September 2008 | Communications of the ACM
Ubiquity: What is software engineering?
Will Software Engineering Ever Be Engineering?
Agile in a Nutshell | Calgary Agile Project Leadership Network