ときどきの雑記帖 2012 2012年7月(中旬)

ソフトウェアのテストについて検索すると、よく「山浦恒央」という名前がよく見かけられます。多くの訳書に翻訳者としてお名前がありますし「山浦恒央の“くみこみ”な話」最新記事一覧 - ITmedia Keywords のような連載もあります。が、なーーんかこうひっかかるものがありましてたとえば最近見かけたものだとこれ PDF版 - ソフトウェア・エンジニアリング - 情報処理推進機構 http://sec.ipa.go.jp/users/secjournal/SEC_journal_No5web.pdf

「第4世代のテストプロセス」という「論文」をお書きになっているのですが同格の「マネージャ」を二人置くというというのも納得しがたいものがありますし (わたしにはそう読めました)、テストプロセスの第4世代と第3世代の比較においても本文の記述と図表の記述がかみ合ってないところが何ヶ所もあってなんだかなあと。

たとえば、プロセスの比較として色々項目が載っている表があるのですが三つに項目を絞って抜き出したのが↓ですが

  開発規模 摘出バグ総数 摘出バグ密度
   (KLOC)
A  103.3        901       8.72
B    4.6         40       8.70
C    5.6         56      10.00
D    5.9         53       8.98
E    5.0         38       7.60
F   15.1        131       8.68
G   12.0        108       9.00
H   10.1         70       6.93
I   15.1        109       7.22
J    6.6         52       7.88
K    5.8         54       9.31
L    8.4         71       8.45
M    6.2         53       8.55

本文によれば「1KLOC あたりの不良の数」として第3世代 8.9個、第4世代 8.1個とあるのですが自分で計算してもその数字が出てこない…

A は理由があって集計の対象外です。 B～E が第3世代、F～M が第4世代のプロセスを採用したプロジェクトです。それらの平均を求めてみると第3世代は 8.82 (自分で開発規模とバグ数から計算すると 8.81…ですが)となります。これを切り上げて? 8.9 に丸めるのは疑問だし、第4世代 F～M の平均値は 8.25…となります。

数値の食い違いはさておいて、これだけのサンプルをもって第4世代の方が良い(平均値が下)と言えるのかというのも疑問だったので、平均値の差の検定をやってみると…

なんだかなー

■_

2012年07月18日

■_

うーむこれは読みたい。『失われた勝利上 -マンシュタイン回想録（エーリヒ・フォン・マンシュタイン著／本郷健訳）』販売ページ『失われた勝利下 -マンシュタイン回想録（エーリヒ・フォン・マンシュタイン著／本郷健訳）』販売ページこういう人です→ エーリッヒ・フォン・マンシュタイン - Wikipedia

式変形
複数の方からアドバイス、ヒント、解答をいただきました。

【2012年7月】IT技術書新刊・近刊まとめ－＠IT自分戦略研究所

■_ 表計算ソフト

表計算の歴史が、日本ではこうなった。 « debiancdn → Brief History of Spreadsheets, v. 3.6 でさらにたどってこれ。

Frankston Email 4-15-1999a

Comments in the following email refer to version 3.0 of Power, D. "A Brief History of Spreadsheets"

Date: Thu, 15 Apr 1999 16:04:51 -0400   
From: Bob Frankston 
To: "Daniel Power, UNI Management Dept."            
Subject: RE: VisiCalc history 

So far I've only glanced at the page. 

One observation is that Mattessich completely misses the point. I don't 
begrudge him his work in accounting in the 60's but it had not the slightest 
influence on VisiCalc. It was one of many online financial programs. 
I worked on some systems while at Interactive Data in the 60's and 70's. 
But VisiCalc was not an accounting program at all, it just made it possible 
for people to do accounting. Programs that were overly tuned for such 
function (Javelin, Lotus Improv, etc) completely failed. 

As you explain spreadsheet is a simply a piece of paper spread out to allow 
you to work on problems. But business transactions are not an important use 
-- production planning and other applications are more important.

What made VisiCalc novel was the ability to not only interact but have it learn by example. Again, VisiCalc
doesn't summarize or do anything, it is just a tool to allow others to work out
their ideas and reduce the tedium of repeating the same calculations.

(略)

なるほどねえ＞VisiCalc 以前にあった会計ソフト等との違い

新・電子立国でVisiCalcを取りあげた回をもう一度観たいもんだねえ。

■_ 字体

奥が深いなあ

ニコ動でアニメ「じょしらく」を観た。意外と面白かったのは良かったんだけど、かりにも落語アニメなのに使っているフォントがモリサワ勘亭流やDF勘亭流なのが頂けない。勘亭流は「歌舞伎」用の芝居文字であって、落語で使われる橘流などの寄席文字とは区別されるという。フォントとして存在しないが
— おたもんさん (@o_tamon) 7月 16, 2012

物凄い数のリツイートをいただいたので実際に比較画像を作ってみた。右側の行が落語で使われる寄席文字、左側の行が歌舞伎で使われる芝居文字。じょしらくで使われているのは何故か左の勘亭流なのである。 twitter.com/o_tamon/status…
— おたもんさん (@o_tamon) 7月 16, 2012

こういう意見も

寄席文字はフォントじゃない。職人による手書き。だから勘亭流使うのはしかたがないと思うの。
— iki_ossanさん (@iki_osu) 7月 18, 2012

■_

2012年07月17日

■_

NHK BS で放映中の「キングダム」、オープニングの最初の方で戦国七雄の旗がでてくるんだけど「斉」というのがひじょーに気になるw いや、「東周英雄伝」では確か「齋」を使ってたような覚えがあったので。

■_

Ruby、君のオブジェクトはなんて呼び出せばいいの？
ASCII.jp：おかげさまで大好評「忘れ去られたCPU黒歴史」の裏話その1
Why Ruby failed to parse a Hash literal with multiple here documents. ? Gist
Software Design 8月号「エンジニアのパワーアップ読書」特集連動フェアを11書店で実施！ - トピックス｜gihyo.jp … 技術評論社
『マンガでわかる統計学』のチロルチョコ（非売品） - オーム社開発部
ヤマトとスターデルタ: 楽只堂
いやはや大人になってから分かることがあるってのもヤマトの奥深いところ。
スターデルタ結線について | OKWave

■_

最近見つけたボトムズの次回予告をうまい具合に改変してついったで流してる人。『装甲騎兵ボトムズ』次回予告

修正のための設計。デバッグのための開発。プロジェクトの始まりから、連綿と続くこの愚かな行為。ある者は悩み、ある者は発狂し、ある者は自らのコードに絶望する。だが、営みは絶えることなく続き、また誰かが呟く。たまにはカプセルホテルも悪くない。次回「徹夜」。誰も、タイムカードを打たない。
— 手動人形さん (@Manualmaton) 7月 11, 2012

言うなれば運命共同体。互いに頼り、互いに教えあい、互いに助け合う。上流が下流のために、下流が上流のために。だからこそプロジェクトが遂行できる。嘘を言うな！　差異に歪んだ顧客がせせら笑う。お前も、お前も、お前も！　俺のために働け！次回、「分業」。こいつらは何のために集められたか…
— 手動人形さん (@Manualmaton) 7月 10, 2012

デスマーチを終わらせたPGを待っていたのは、また地獄だった。リリースの後に住み着いた不具合と要望。情報化社会が生み出したソドムの街。残業と休出、過労と鬱病とをコンクリートミキサーにかけてブチまけた、ここはIT業界のゴモラ。次回「改修」。来週もPGと地獄に付き合ってもらう。
— 手動人形さん (@Manualmaton) 7月 10, 2012

人月、設備、期間、機器。どれ一つ不足しても開発では命取りとなる。それらをまとめて無謀でくくる。変えられた仕様、仕組まれた地獄。設計も怖いが運用も怖い。脆弱なOS、狭隘な顧客、充満する不満。まさに破裂必死の大動脈流！　次回、「死の行軍」。怒涛のドミノ倒しが始まる。
— 手動人形さん (@Manualmaton) 7月 9, 2012

変わる、変わる、変わる。この世のPCをまわすOSが、奈落の底でまた動きはじめた。サーバが軋み、SEは呻く。舞台が回れば仕様も変わる。昨日も、今日も、明日も、不具合に閉ざされて見えない。だからこそ、切れぬ絆を求めて、褪せぬコードを信じて求めて。次回「急変」。変わらぬ職などあるのか。
— 手動人形さん (@Manualmaton) 7月 9, 2012

最も危険な罠、それは営業の安請け合い。たくまずして仕掛けられた業界の闇に眠る殺し屋。それは突然に目を覚まし、偽りの平穏を打ち破る。SIerは巨大な罠の街。そこかしこで、信管をくわえた不発弾が目を覚ます。次回「罠」。自社も、巨大な不発弾。自爆、誘爆、御用心。
— 手動人形さん (@Manualmaton) 7月 9, 2012

求めても、求め得ぬもの。望んでも、望み得ぬもの。狂おしいまでの疲れが、叶わぬ代休が、殺意と抑鬱を生む。心に地獄を持つ者同士の、不可思議なる合意が、壮絶なる対決を生む。次回、「有休届」。流される同僚の血潮で、疲れを癒す。
— 手動人形さん (@Manualmaton) 7月 16, 2012

昨年の後期、単位を失くして血の涙に濡れていた。今年の前期、出席日を的に取れそうな試験を追っていた。今年の後期、チンケなヤマとちっぽけな学習時間が、後輩のノートに金を蒔く。大学は先人が作ったモラトリアムの庭。質を問わなきゃ誰でもいる。次回、「試験」。来年、そんな先の事はわからない。
— 手動人形さん (@Manualmaton) 7月 17, 2012

まだあるかもしれないけど気がついたのはこんなもん。うまいなあ。こんなのもあったのねボトムズ次回予告のガイドライン

2012年07月16日

■_

今日の朝刊(夕刊ない日だけど)で見かけた話ＡＴＳ不要…無線での列車制御、ＪＲ東が導入へ : 社会 : YOMIURI ONLINE（読売新聞）大昔に山手線(だったと思う)の信号ケーブルが切断されて…とかいう事件(テロ?) があったような。無線だとそういう心配はないけど乗っ取られたりしないのかなあと要らぬ心配。これか国電同時多発ゲリラ事件 - Wikipedia

■_

『Scala逆引きレシピ』感想 - ((プログラミング | 形式) 言語) について書く日記
18～19世紀に起きた剣道のイノベーション : アゴラ - ライブドアブログ
なぜ効率ばかり追求すると利益が減るのか（プレジデント） - Yahoo!ニュース BUSINESS
福岡CSK : サービス : 軽量Ｒｕｂｙ
mruby（が使用するRAM）の半分は、ハッシュでできています。
hirax.net::「あるもの・買えるもの」に落とし込めるなら「お金があれば何でもできる」
全商プログラミング1級取得者のプログラマーの素質(1/2) | OKWave
私は将来プログラマーになりたいと思い始めた高校3年生の女子です。
私も若いころはその手のことで腕に覚えがあり、1万行位は軽く覚えてましたね。
佐藤さんに特化した佐藤さん向けアプリ「佐藤さんの萌え目覚まし時計」 - CNET Japan
どうしてもやめられない……こんな時の対処法を心理学者に聞いてみた！ | ホビー | マイナビニュース
MS-06ザクとうふ | プレミアムグッズキャンペーン
Ruby Kaja
LanManager MS-DOS ver 6.2(2/2) | OKWave
英語ができるようにならない理由
今後のIT業界を占う4つのトレンド
Twitter / takejune: 「君からはコード

■_ 式変形

スパコンとは何か  p157

1) 1 - 1/√1+x

2) (√1+x - 1) / √1+x

3) x / (1 + x + √1+x)

1) → 2) の変形はわかるんだけど (1 → √1+x / √1+x にして…) 3) へは?

■_ もしも

ぺちぺにリスト内包 (list comprehensions) やジェネレーター (generators) があったら

If PHP had list comprehensions and generators

If PHP had list comprehensions and generators

A couple of weeks ago an interesting proposal poped up on the PHP mailing list with a hack someone
made to introduce generators, generator expressions and list comprehensions. Unsurprisingly some
people wheren't trully convinced about the prospects of this feature; both from core developers and
language users. As such, I tought I'd share a few ideas and try to win these guys over.

Declarative XML parsing

The quickest example I could come up with, was a simpler interface to the recuring task of parsing
content from large XML files.

  <?php
  function *readXML($file) {
    $r = new XMLReader;
    $r->open($file);
  
    while($r->read()) {
      yield $r;
    }
  }
  
  function *filterNodes(callable $predicate, $nodes) {
    foreach($nodes as $node) if($predicate($node)) yield $node;
  }
  
  
  function matchName($name) {
    return function($node) use($name) {
      return $node->name === $name;
    };
  }
  
(略)

Testing it for yourself

If you've reached this far in the article without loosing interest, I recommend to switch on your
terminal and hit in the following commands before closing tabs.

  $ git clone -b addListComprehensions https://github.com/nikic/php-src.git
  $ cd php-src
  $ ./buildconf
  $ ./configure
  $ make cli
  $ ./sapi/cli/php some-example-file.php

■_

2012年07月15日

■_

読んだ
銀輪の巨人

日本の自転車業界の近況というのを知らなかったのでそれを知ってとても驚いた。 Amazon の書評のひとつにあるように、この本にある提言のようなことをやっていたとしてもうまく言っていたとは言い切れないのは確かではあるだろうけれども、現在の状況は「易きに流れた」末の結果ではないのかなあとは思う。

■_

Lecture notes About Laning and Zierler system

■_ Read the masters

訳そうかと思ったんですが “by studying the masters, not their pupils.” をどうしたものか悩んで進まず。これ、英語版 wikipedia のアーベルの項目には載ってるんですが日本語版にはないのですよね。ニールス・アーベル - Wikipedia Niels Henrik Abel - Wikipedia, the free encyclopedia そりゃえいやで直訳みたいにはできますが、それもどうかと。この「masters」って具体的には何を指してるんでしょうか? 師匠からの直接の教えとすると pupils (パピルス→紙→書物?)との対比ではいいのですが彼の経歴見るとそういう人がいたようには思えないし。最後のこれ読めってのを勘案すると「優れた論文」とかなのかなあ。

Master | Define Masters at Dictionary.com

Niels Henrik Abel - Wikipedia, the free encyclopedia

Mathematical work

Abel gave a proof of the binomial theorem valid for all numbers, extending Euler's result which had
held only for rationals. At age 19, he showed there is no general algebraic solution for the roots
of a quintic equation, or any general polynomial equation of degree greater than four, in terms of
explicit algebraic operations. To do this, he invented (independently of Galois) an extremely
important branch of mathematics known as group theory, which is invaluable not only in many areas of
mathematics, but for much of physics as well. Among his other accomplishments, Abel wrote a
monumental work on elliptic functions which, however, was not discovered until after his death. When
asked how he developed his mathematical abilities so rapidly, he replied "by studying the masters,
not their pupils."[4] Abel said famously of Carl Friedrich Gauss's writing style, “He is like
the fox, who effaces his tracks in the sand with his tail.”[5]

» Read the masters :federicopereiro.com

Read the masters

Some time ago, I came across the Wikipedia article of Niels Henrik Abel, and something there burnt
its way into my mind.

Abel changed the face of mathematics, despite dying at 27. And here comes the thing – I give the mic
to Wikipedia now:

    When asked how he developed his mathematical abilities so rapidly, he replied “by studying the
    masters, not their pupils.”

(略)

I've been reading the masters more and more. Usually it's like reading a foreign language. You don't
understand almost anything and you feel like a baby.

But if you don't mind too much feeling like a baby, and if you can create some space in your life
where you aren't forced to be an adult, then give the masters a try.

Below I put some links to works by masters of Computer Science – all the works below are available
to download for free.

Shannon, 1948 – A Mathematical Theory of Communication

Shannon, 1949 – Communication Theory of Secrecy Systems

Turing, 1936 – On Computable Numbers, with an Application to the Entscheidungsproblem

McCarthy, 1960 – Recursive Functions of Symbolic Expressions and their Computation by Machine (Part I)

MIT, 1962 – Lisp 1.5 Programmer's Manual

Ritchie, 1993 – The Development of the C Language

Thompson, 1984 – Reflections on Trusting Trust

Cerf et Dalal et Sunshine, 1974 – Specification of the Internet Transmission Control Program

Wu, 1997 – The Secure Remote Password Protocol

Strachey, 1967 – Fundamental Concepts in Programming Languages

Knuth, 1983 – Literate Programming

Posted: 07.14.2012

よくわからん。

2012年07月14日

■_

読んだ

オススメ。例の、「仕分け」の話から、なぜスーパーコンピューターに(国から)大金出して開発しなければならないのか。「京」の一位の意味あいについて等々。どなたかがブログで書いていたと思うのですが、京というのはある意味「力技」と「金」で性能を向上させた(うまい表現でないな)部分があると。

「なんのためにスーパーコンピューターを作るのか」、「これからも開発を継続させていくのか」ということを考えたときに実は一位になってしまったことは負の面が少なからずあるのではないかということなのですね。また、「ハードウェア偏重」の度合いが強いこともよくないだろうと。いちいち書き写すのも面倒なのでぜひご自分の目で確かめて欲しいのですが (気軽に置いているような本屋にいけねーよと言う人にはごめんなさい)、第4章「だから次世代スーパーコンピュータープロジェクトに異議あり」、第5章「日本がスーパーコンピューター王国であり続けるためには」を読んで、自分なりに考えてもらいたいです。

まあ考えたからといって何がどうなるわけでもないし、日々の「新技術」を追いかけるのに一生懸命な方はどうぞそちらへ。

Amazon.co.jp：速習C言語入門―脳に定着する新メソッドで必ず身につく: 菅原朋子: 本の現物をちょっと見てきました。とりあえず call by refence の勘違いなどのよくある間違いはなかったぽいですが、なんというか(ry

この辺も欲しかったんだけど金が(ry ソフトウェア工学のベストプラクティス ―ソフトウェア工学の真の工学への発展をめざして― / Capers Jones 　著富野壽　岩尾俊二　監修水野哲博　吉田善亮　監訳 | 共立出版情報理論 ―基礎と広がり― / Thomas M.Cover 　Joy A.Thomas 　著山本博資　古賀弘樹　有村光晴　岩本貢　訳 | 共立出版情報検索の基礎 / Christopher D.Manning 　Prabhakar Raghavan 　Hinrich Schütze 　著岩野和生　黒川利明　濱田誠司　村上明子　訳 | 共立出版情報推薦システム入門 ―理論と実践― / Dietmar Jannach 　Markus Zanker 　Alexander Felfernig 　Gerhard Friedrich 　著田中克己　角谷和俊　監訳 | 共立出版

で、買ったのはこれ
括弧の意味論

ジュンク堂のプログラミング本のところに置かれていたんですが、目次を見てもどうもプログラミングの本ではないっぽい感じがしたのですが λ計算が途中で出てきたのでえいやで買ってみたw が、すでに書評が着いてるなあ。それも結構前だ。お前ら「スイーツ（笑）」って言いたいだけだろ！　2011年上半期ベスト本『括弧の意味論』(エキサイトレビュー) - エキサイトニュース東京大学(英米文学)・阿部公彦の書評ブログ : 『括弧の意味論』木村大治(ＮＴＴ出版) 404 Blog Not Found:愛してると「愛してる」の違い - 書評 - 括弧の意味論

InfoQ
んーむ聴くのだけでも結構タイヘン…って後ろ二つは違うか。 The Algorithms Still Count Retrospectives: A Bit of Ceremony Can Be Useful Miles Sabin on Dependent Types with Scala, Shapeless, Scala Macros ReSharper 7 Adds Windows 8 Support, New Languages Scala Adding Macros to the Language

■_ FLOSS プロジェクト失敗の目安

How to tell if a FLOSS project is doomed to FAIL - The_Open_Source_Way

How to tell if a FLOSS project is doomed to FAIL

This was originally written by Tom 'spot' Callaway and is used here under the CC BY SA 3.0 license.
The work How you know your Free or Open Source Software Project is doomed to FAIL (or at least,
held back fro)m success) originally appeared on 2009-05-29 at this URL:'
http://spot.livejournal.com/308370.html

This was inspired by Spot's initial efforts to look at Chromium, but these are just some of the red
flags he generally has observed over the years, now written down.

There are obvious exceptions, such as the Linux kernel.

Linux のカーネルなんかは明確な例外 :)

Generally these exceptions work because they started out small and the community and code grew
together. Large complexity requires a large community. Starting a new project with lots of
complexity makes it exceedingly hard to build up a community.


    1 Size
    2 Source Control
    3 Building From Source
    4 Bundling
    5 Libraries
    6 System Install
    7 Code Oddities
    8 Communication
    9 Releases
    10 History
    11 Licensing
    12 Documentation
    13 FAIL METER

Size
大きさに関して

    The source code is more than 100 MB. [ +5 points of FAIL ]
    ソースコードが 100MB を超えている +5ポイント

    If the source code also exceeds 100 MB when it is compressed [ +5 points of FAIL ]
    ソースコードを圧縮してもまだ100MBを超えている +5ポイント

Source Control

    There is no publicly available source control (e.g. cvs, svn, bzr, git) [ +10 points of FAIL ]
    ソースのコントロールが public に可能になっていない +10 ポイント

    There is publicly available source control, but:
    public なソースコントロールが可能であっても

        There is no web viewer for it [ +5 points of FAIL ]
        ソースを見るための web ビュアーがない +5ポイント

        There is no documentation on how to use it for new users [ +5 points of FAIL ]
        新規ユーザーのための使い方のガイドがない +5 ポイント

        You've written your own source control for this code [ +30 points of FAIL ]
        そのコードのために自分で独自のソースコントロールを書いた +30 ポイント

        You don't actually use the existing source control [ +50 points of FAIL ]
        既存のソースコントロールを使っていない +50 ポイント

Building From Source
ソースからのビルドに関して

    There is no documentation on how to build from source [ +20 points of FAIL ]
    ソースからのビルド方法についてのドキュメントがない +20 ポイント

    Documentation exists on how to build from source, but it doesn't work [ +10 points of FAIL ]
    ビルドのためのドキュメントはあるが、役に立たない +10 ポイント

    The source is configured:
    ソースのコンフィグレーションが

        with a handwritten shell script [ +10 points of FAIL ]
        ハードコードされたシェルスクリプトである +10ポイント

        by editing flat text config files [ +20 points of FAIL]
        flat text なコンフィグレーションファイルを修正することで行なわれる +20ポイント

        by editing code header files manually [ +30 points of FAIL ]
        手作業でヘッダーファイルを修正することで行なわれる +30 ポイント

    The source isn't configurable [ +50 points of FAIL ]
    ソースが configurable でない +50 ポイント

    The source builds:
    ソースのビルドで

        using something that isn't GNU Make [ +10 points of FAIL ]
        GNU Make 以外のものを使っている +10 ポイント

        only with third-party proprietary build tools [ +50 points of FAIL ]
        サードパーティ製のプロプラなビルドツールだけを使う +50 ポイント

        with your own build tool for this code [ +100 points of FAIL ]
        ビルドツールを自作した +100 ポイント

    The build has no tests [ +5 points of FAIL ]
    ビルドにテストが含まれてない +5 ポイント

Java has some different rules, as the language capabilities are different than many other environments:
他の環境と違いや言語の能力などのため、Java の場合いくつかの異なったルールがあります

    The build process doesn't use a standard build tool like Ant, Maven, Gradle [ +10 points of FAIL ]
    ビルドプロセスで Ant や Maven、Gradel のような標準的なビルドツールを使っていない +10ポイント

    The runtime artifacts rely on native libraries [ +5 points of FAIL ]
    runtime artifacts (実行時生成物?) がネイティブライブラリに依存している +5 ポイント

    The build has no tests [ +20 points of FAIL ]
    ビルドにテストが含まれていない +20 ポイント

Bundling

    Your source only comes with other code projects that it depends on [ +20 points of FAIL ]

    If your source code cannot be built without first building the bundled code bits [ +10 points of FAIL ]
    最初に bundled code bits をビルドせずにビルドができない +10ポイント

    If you have modified those other bundled code bits [ +40 points of FAIL ]
    その bundled code bits に修正を加えていたら +40 ポイント

Libraries

    Your code only builds static libraries [ +20 points of FAIL ]
    スタティックライブラリしかビルドしない +20 ポイント

    Your code can build shared libraries, but only unversioned ones [ +20 points of FAIL ]
    シェアードライブラリをビルドできるが、version がついてないものひとつだけしかできない +20ポイント

    Your source does not try to use system libraries if present [ +20 points of FAIL ]
    システムライブラリがあるときにそれを使うことを試みない +20 ポイント

For Java:

    Your code builds native deliverables [ +5 points of FAIL ] 

System Install

    Your code tries to install into /opt or /usr/local [ +10 points of FAIL ]
    /opt もしくは /usr/local へのインストールを試みる +10ポイント

    Your code has no "make install" [ +20 points of FAIL ]
    "make install" がない +20 ポイント

    Your code doesn't work outside of the source directory [ +30 points of FAIL ]
    ソースディレクトリ以外ではうまくビルドできない +30 ポイント

Code Oddities

    Your code uses Windows line breaks ("DOS format" files) [ +5 points of FAIL ]
    Windows (DOS フォーマット) の改行を使っている +5 ポイント

    Your code depends on specific compiler feature functionality [ +20 points of FAIL ]
    特定のコンパイラーの機能に依存している +20 ポイント

    Your code depends on specific compiler bugs [ +50 points of FAIL ]
    特定のコンパイラーのバグに依存している +50 ポイント

    Your code depends on Microsoft Visual Anything [ +100 points of FAIL ]
    Microsoft の Visual なんとかに依存している +100 ポイント

Communication

    Your project does not announce releases on a mailing list [ +5 points of FAIL ]
    メーリングリストでリリースをアナウンスしない +5 ポイント

    Your project does not have a mailing list [ +10 points of FAIL ]
    メーリングリストがない +10 ポイント

    Your project does not have a bug tracker [ +20 points of FAIL ]
    バグトラッカーがない +20 ポイント

    Your project does not have a website [ +50 points of FAIL]
    web サイトがない +50 ポイント

    Your project is sourceforge vaporware [ +100 points of FAIL ]
    あなたのプロジェクトは sourceforge vaporware である +100 ポイント

Releases

    Your project does not do sanely versioned releases (Major, Minor) [ +10 points of FAIL ]
    きちんとしたバージョン付けをせずにリリースを行なっている +10 ポイント

    Your project does not do versioned releases [ +20 points of FAIL ]
    バージョンをつけていない +20 ポイント

    Your project does not do releases [ +50 points of FAIL ]
    リリースしていない +50 ポイント

    Your project only does releases as attachments in web forum posts [ +100 points of FAIL ]
    web フォーラムでのポストのアタッチメントとしてのみリリースしている +100 ポイント

    Your releases are only in .zip format [ +5 points of FAIL ]
    .zip 形式でのみリリースしている +5 ポイント

    Your releases are only in OSX .zip format [ +10 points of FAIL ]
    OSX の .zip 形式でのみリリースしている +10 ポイント

    Your releases are only in .rar format [ +20 points of FAIL ]
    .rar 形式でのみリリースしている +20 ポイント

    Your releases are only in .arj format [ +50 points of FAIL ]
    .arj 形式でのみリリースしている +50 ポイント

    Your releases are only in an encapsulation format that you invented. [ +100 points of FAIL ]
    自分が開発した encapsulation 形式でのみリリースしている +100 ポイント

    Your release does not unpack into a versioned top-level directory (e.g. glibc-2.4.2/ ) [ +10 points of FAIL ]

    Your release does not unpack into a top-level directory (e.g. glibc/ ) [ +25 points of FAIL ]

    Your release unpacks into an absurd number of directories (e.g. home/johndoe/glibc-svn/tarball/glibc/src/) [ +50 points of FAIL ] 

History

    Your code is a fork of another project [ +10 points of FAIL ]
    別のプロジェクトからの fork である +10ポイント

    Your primary developers were not involved with the parent project [ +50 points of FAIL ]
    primary developer は親プロジェクトに深くかかわっていなかった

    Until open sourcing it, your code was proprietary for:
    オープンソースにするまでのプロプラだった期間

        1-2  years [ +10 points of FAIL ]
        3-5  years [ +20 points of FAIL ]
        6-10 years [ +30 points of FAIL ]
        10+  years [ +50 points of FAIL ] 

Licensing

    Your code does not have per-file licensing [ +10 points of FAIL ]
    ファイル毎にライセンス表記がない +10ポイント

    Your code contains inherent license incompatibilities [ +20 points of FAIL ]
    コードにライセンス非互換な部分がある +20 ポイント

    Your code does not have any notice of licensing intent [ +30 points of FAIL ]
    notice of licensing intent (ライセンスで意図していることのお知らせ?) がない +30ポイント

    Your code doesn't include a copy of the license text [ +50 points of FAIL ]
    コードにライセンスのテキストの写しがない +50ポイント

    Your code doesn't have a license [ +100 points of FAIL ]
    ライセンスがない +100 ポイント

Documentation

    Your code doesn't have a changelog [+10 points of FAIL]
    changelog がない +10ポイント

    Your code doesn't have any documentation [ +20 points of FAIL ]
    コードにドキュメントがない (コメントがない?) +20ポイント

    Your website has no examples of use [ +20 points of FAIL ]
    web サイトに使い方の例がない +20 ポイント

    Your website doesn't have any documentation [ +30 points of FAIL ]
    web サイトにドキュメントがない

FAIL METER

     0 points of FAIL: Perfect! All signs point to success!
  5-25 points of FAIL: You're probably doing okay, but you could be better.
 30-60 points of FAIL: Babies cry when your code is downloaded
 65-90 points of FAIL: Kittens die when your code is downloaded
95-130 points of FAIL: HONK HONK. THE FAILBOAT HAS ARRIVED!
 135+  points of FAIL: So much fail, your code should have its own reality TV show.
Category: The Open Source Way book

■_

レポート：「PyCon Taiwan 2012」参加レポート｜gihyo.jp … 技術評論社
常用対数使わないって言う人は2進数使ってればいいと思う - プログラムモグモグ
PHPはバグレポートがバグッてる。だがそれがいい。 | 高橋文樹.com
Software Eats Software Development // Peter Levine
C99の配列初期化に潜む罠 | monoの開発ブログ
Island Life - Unbounded spigot algorithm
legoboku.jp: 組み込みTDDにおける関数ポインタ置換とモックオブジェクトの導入について
幼女のためのFortran入門 - fortran66の日記
最近、幼女の間で Ruby が大人気と耳にしました。そこで、Fortran でも幼女向けの入門書が必要なのではないかと思い構想を練り始めましたが、ネットを検索していたところすでに1972年にアメリカで同趣旨の本が出版されていることを知りました。
JSON
Amazon.co.jp： 103系物語 (キャンブックス): 毛呂信昭: 本
「サーバーサイドの知識の無さに全俺が泣いた」レベルの入社当時の人に読ませたら少しはアドバイスになったであろうPythonとDjangoの前提知識メモ - AtAsAtAmAtArA
JavaScript勉強会の本を検討する | 水無月ばけらのえび日記
Pythonのwith文とJava7のtry-with-resourceとC#のusingの比較 - 西尾泰和のはてなダイアリー
【レポート】これから行く人必見!!「館長庵野秀明特撮博物館」鑑賞ガイド (後編) | クリエイティブ | マイナビニュース
PyPy Status Blog: Prototype PHP interpreter using the PyPy toolchain - Hippy VM
さらば蒙古の怪人！！新宿・歌舞伎町にあるキラー・カーンのお店が閉店 - 見えない道場本舗

■_

» Read the masters :federicopereiro.com

2012年07月13日

■_

Amazon.co.jp：「ジャイアントロボ THE ANIMATION ~ 地球が静止する日 ~」アルティメットBlu-ray BOX [期間限定生産]: 今川泰宏, 山口勝平, 島本須美, 若本規夫, 飯塚昭三: DVD

よんまんえん… しかし、これ LD 時代から追っかけてる人は大変だなあ (わたしは LD のは買っていない)。

■_ powershell

■_

Embedded in Academia : Contest: Craziest Compiler Output due to Undefined Behavior

■_

2012年07月12日

■_

数学セミナー、通勤経路にある本屋ではあつかってないんだよなー

■_

■_ 引継ぎ

ぐだぐだなコードを引き継ぐ羽目になったら

project management - I've inherited 200K lines of spaghetti code -- what now? - Programmers

I've inherited 200K lines of spaghetti code — what now?

I hope this isn't too general of a question; I could really use some seasoned advice.

I am newly employed as the sole "SW Engineer" in a fairly small shop of scientists who have
spent the last 10-20 years cobbling together a vast code base. (It was written in a virtually
obsolete language: G2 -- think Pascal with graphics). The program itself is a physical model of a
complex chemical processing plant; the team that wrote it have incredibly deep domain knowledge but
little or no formal training in programming fundamentals. They've recently learned some hard lessons
about the consequences of non-existant configuration management. Their maintenance efforts are also
greatly hampered by the vast accumulation of undocumented "sludge" in the code itself. I will
spare you the "politics" of the situation (there's always politics!), but suffice to say,
there is not a consensus of opinion about what is needed for the path ahead.

They have asked me to begin presenting to the team some of the principles of modern software
development. They want me to introduce some of the industry-standard practices and strategies
regarding coding conventions, lifecycle management, high-level design patterns, and source control.
Frankly, it's a fairly daunting task and I'm not sure where to begin.

Initially, I'm inclined to tutor them in some of the central concepts of The Pragmatic Programmer, or
Fowler's Refactoring ("Code Smells", etc). I also hope to introduce a number of Agile
methodologies. But ultimately, to be effective, I think I'm going to need to hone in on 5-7 core
fundamentals; in other words, what are the most important principles or practices that they can
realistically start implementing that will give them the most "bang for the buck".

So that's my question: What would you include in your list of the most effective strategies to help
straighten out the spaghetti (and prevent it in the future)?

Update: I just returned (after a vacation) to check this post and ... WOW! I am overwhelmed by the
responses! I want to genuinely thank everyone for putting so much time into this and providing such
thoughtful and insightful answers -- particularly @Haylem for his incredible opus. I have learned so
much from all of you, so THANK YOU!

Foreword

This is a daunting task indeed, and there's a lot of ground to cover. So I'm humbly suggesting this
as somewhat comprehensive guide for your team, with pointers to appropriate tools and educational
material.

Remember: These are guidelines, and that as such are meant to adopted, adapted, or dropped based on
circumstances.

Beware: Dumping all this on a team at once would most likely fail. You should try to cherry-pick
elements that would give you the best bang-for-sweat, and introduce them slowly, one at a time.

Note: not all of this applies directly to Visual Programming Systems like G2. For more specific
details on how to deal with these, see the Addendum section at the end.

Executive Summary for the Impatient

    Define a rigid project structure, with:
        project templates,
        coding conventions,
        familiar build systems,
        and sets of usage guidelines for your infrastructure and tools.
    Install a good SCM and make sure they know how to use it.
    Point them to good IDEs for their technology, and make sure they know how to use them.
    Implement code quality checkers and automatic reporting in the build system.
    Couple the build system to continuous integration and continuous inspection systems.
    With the help of the above, identify code quality "hotspots" and refactor.

Now for the long version... Caution, brace yourselves!
(略)

■_ 何たら曲線

検索してたらこういうのを発見つれづれなる技術屋日記: バグカーブ　対数曲線や二次曲線での近似のお勧め

つれづれなる技術屋日記: バグカーブ　対数曲線や二次曲線での近似のお勧め

バグカーブ/バグ曲線とかソフトウェアの信頼度成長曲線って、ソフトウェア工学での大きなテーマである。
ちょっとした会合や講演会の題材、あるいは学術論文でのネタになることも少なくない。

代表的な曲線は、ゴンペルツ曲線とかロジスティック曲線とかだろう。ただし、ソフトウェアテスト（具体
的にはシステムテストであるケースが多い）の初期に無理に曲線を当てはめてみて想定と大きく違ったり、
測定値と予想との乖離が気になることがある。前者はある意味仕方ないが、後者はもっといい近似曲線がな
いだろうかと考えてしまう。（ちなみに、ここでは、バグ発生のモデルではなく、あくまで曲線近似の世界
のことを扱う。そのことや、近似が成長曲線でないので、ここでは”バグカーブ”と呼ぶことにする。）

ここ1，2年前くらいから、少し”もやっと”したものがあったが、 Day2の本を読んで納得した。
以下の左が、Day2の統合テストでのバグカーブ。

ということで図書館で Day2 の本とやらを借りてみたつれづれなる技術屋日記: Day2プロジェクトの本システム統合の「正攻法」

■_ 入門書

まだ出るのねえ Amazon.co.jp：速習C言語入門[第2版] ~脳に定着する新メソッドで必ず身につく~: 菅原朋子: 本

Amazon.co.jp： 速習C言語入門[第2版] ~脳に定着する新メソッドで必ず身につく~: 菅原 朋子: 本

内容紹介

必ずC言語が身につく入門書!

第2版となる本書では開発環境の話も盛り込み、さらに見やすく・分かりやすく構成しました。

本書は、はじめてプログラミングを学ぶ方に向けたC言語の入門書です。最後まで読み通せるように、やさしいサン
プルプログラムを使い、図解しながらていねいにわかりやすく解説しています。

そして、今までの入門書にはない工夫がたくさんあります。
略

ニーズがある。ってことなんすかねえ。第二版ということは旧版は今見つけられるかな

Amazon.co.jp：速習C言語入門―脳に定着する新メソッドで必ず身につく: 菅原朋子: 本レビューが好意的だ


CiNii 論文 -  残存エラー数の推定が可能なプログラムの試験法(4) : エラー数推定のための前提条件
http://ci.nii.ac.jp/naid/110003298934

CiNii 論文 -  フローの分析によるプログラム残存エラー数の推定
http://ci.nii.ac.jp/naid/110002911423

CiNii 論文 -  残存エラー数の推定が可能なソフトウェア試験法について
http://ci.nii.ac.jp/naid/110002931642

CiNii 論文 -  残存エラー数の推定が可能なプログラム試験法 : その実施例と分析
http://ci.nii.ac.jp/naid/110002931929

■_ じゃばすく

parseInt(1 / 0, 19) の結果がどうなるか。という話。

javascript - Why does parseInt(1/0, 19) return 18? - Stack Overflow

I've an annoying problem in JavaScript.

parseInt(1 / 0, 19)
18

Why does parseInt return 18?


The result of 1/0 is Infinity.

parseInt treats its first argument as a string which means first of all Infinity.toString() is
called, producing the string "Infinity". So it works the same as if you asked it to convert
"Infinity" in base 19 to decimal.

Here are the digits in base 19 along with their decimal values:

Base 19   Base 10 (decimal)
---------------------------
   0            0
   1            1
   2            2
   3            3
   4            4
   5            5
   6            6
   7            7
   8            8
   9            9
   a            10
   b            11
   c            12
   d            13
   e            14
   f            15
   g            16
   h            17
   i            18

What happens next is that parseInt scans the input "Infinity" to find which part of it can be
parsed and stops after accepting the first I (because n is not a valid digit in base 19).

Therefore it behaves as if you called parseInt("I", 19), which converts to decimal 18 by the
table above.


Here's the sequence of events:

    1/0 evaluates to Infinity
    parseInt reads Infinity and happily notes that I is 18 in base 19
    parseInt ignores the remainder of the string, since it can't be converted.

Note that you'd get a result for any base >= 19, but not for bases below that.

算術式を parseInt に食わせるのはどーよ。という気が。あーでも、計算結果がそうなったのが入っている変数を渡すというパターンがあるか。

■_

そして redditで盛り上がるといういつものパターン

Stack Overflow: Why does parseInt(1/0, 19) return 18 in JavaScript? : programming

And people wonder why I prefer strong type systems...


Thank you for correctly pointing out that this is a question of strong vs. weak typing, not one of
static vs. dynamic typing. E.g. Python handles this more sanely, while remaining completely dynamic.

© 2012 reddit inc. All rights reserved.

■_

ときどきの雑記帖 編

ときどきの雑記帖編