ときどきの雑記帖 2012

最新ページへのリンク
目次ページへのリンク

一つ前へ 2012年6月(下旬)
一つ後へ 2012年7月(中旬)

ホームへ

2012年07月10日

■_

今日のオススメ Hacker Monthly - Print Magazine of Hacker News

昨年末くらいに(その時点での)バックナンバーのフリーダウンロードとか大盤振る舞いやってまして、 そのときにいくつか頂戴してたのだけどやっと読んだw んで、読んでみて結構いいんじゃないかと思いました。 電書 (pdf, mobi, epub) 版のコースなら年間で $29 ということなので、悪くないんじゃないでしょうか。 って今はお試し読みもできないのかな。これ。

■_ loop

西亭新九郎さんの力によって(謎)、タイミングよくこんなエントリが。 

Who created the idea(s) of the first loop constructs? : programming

Who created the idea(s) of the first loop constructs? (programmers.stackexchange.com)



Knuth's paper Structured Programming With GOTO Statements has a fascinating survey of various control
loops being played with in the early 70's, including the roots of C style for loops, exceptions, and
so on. It's a good read.



I would think the basic idea would be directly derived from integrals in calculus.



The question is fully dependent on what is meant by a loop construct. In the widest sense, loops has
been used long before computers, with Euclid's algorithm as one of the oldest examples. Later Ada
Lovelace used a loop in the algorithm for Bernoulli numbers. Konrad Zuse's Plankalkül had a loop but
he never implemented it. Most likely Grace Hopper's A-0 (of 1952) had it (I could not find
information of it), but certanly FORTRAN , made in the 1954-57 timeframe had loops. Arguably even the
branching of machine code can be considered loops. Thus loops have been there since the very
beginning. Loops or recursion is generally required to make a machine Turing complete, and since
recursion is harder to implement directly in hardware than loops, practically all computers has
something that can be used for looping at the lowest level.



Back in 1945 Konrad Zuse designed the Plankalkül programming and it had programming constructs like
functions, variables, while loops, arithmetical and logical operations.



Dear lord, is this what they teach these days?

Dijkstra co-authored with Tony Hoare, they were both preceded by Christopher Strachey who was
writing about structured programming and functional programming long before them - he was the chap
that coined the term "Currying" although the idea goes back to Moses Schönfinkel (~ 1924 )
& Haskell Curry.



That's irrelevant. The question was "who created the ideas of loop constructs", and the
answer is Dijkstra (with help from Wirth). Even though Dijkstra didn't invent the concept, he made it
mandatory in programming. Purely a feat of social engineering, not a technical achievement, of course.


    The question was "who created the ideas of loop constructs", and the answer is Dijkstra

This is false. Untrue. Unbacked by any factual link to an original paper.

Your argument has more holes than a machined gunned crumpet with stigmata and you are both a
steaming fuckwit and somewhat deluded.

    Before them people programmed with goto statements even if the idea of repetition was known.

Still repeating this patent bullshit

For a single counter example, see: FORTRAN - Backus et al - Preliminary Report (1954) pages 11 & 12

Also, Dijkstra didn't stigmatize the use of goto (or the broader goto family), he stigmatized the obscene use of goto.

If you read all the papers of the period there was quite the lively debate.

で、その元のエントリがこちら。 

history - Who created the idea(s) of the first loop constructs? - Programmers

  while (1) {
        if (1+1==2) {
               print "Yes, you paid attention in Preschool!";
        } else {
               print "Wait... I thought 1+1=2";
        }
   }

As a developer, we all have to use loops very frequently. We know that. What I was wondering was, who
thought of the idea to have loops? What language introduced loops? What was the first loop construct?
Was it a while loop? A for loop? etc?

わたしたち開発者はみな頻繁にループを使っています。
ここでわたしが疑問に思っているのは、ループというアイデアを考えだしたのは誰か? ということです。
そして、ループを最初に持ち込んだプログラミング言語はなんでしょうか?
最初のループ構造とはどういったものだったのでしょうか?
while ループ、for ループ、それとも?


As mouviciel and Emilio Garavaglia noted, the concept predates computing. However, the first instance
of a software loop was the loop Ada Lovelace used to calculate Bernoulli numbers, as described in
Note G of her translation of the Sketch of the Analytical Engine Invented by Charles Babbage, by L.
F. Menabrea. The Analytical Engine's ability to loop is noted early on by Menabrea:

(長いので略)

However I think that in context of computing (and not calculating or anything else), the Analytical
Engine and Ada's Bernoulli numbers calculating algorithm can be credited for introducing loops,
sharing at least some of the credit with Jacquard's loom, having directly adapted the concept from it.


Assuming you mean modern text computer programming languages.

Algol60 has "FOR", "DO", "UNTIL" and "WHILE", so it was before 1960.

The Retro Computing Museum has a few languages pre 1960.

Kvikkalkul, the language from the '50s for programming Swedish nuclear subs only has GOTO. (However,
Kvikkalkul is almost certainly a hoax from the '90s, not a real historical language.)

Plankalkül by Konrad Zuse is the earliest I could find. It has a "für" construct.

ご存知の通り、FORTRAN ではループは DO ～ という形式ですが、 FORTRAN 以前に for を予約語に使った (という表現が正しいのかどうか) 言語があって、 FORTRAN にも影響を及ぼした云々てなスライドを最近見たんですが あれはどこで見たのだっけ(^^;

ということで、ループの話はまだ続くのであった。

■_ The Ten Commandments of Egoless Programming

誰か訳し(ry 

Dad and The Ten Commandments of Egoless Programming - Stephen Wyatt Bush's Blog

Dad and the Ten Commandments of Egoless Programming
Apr 7th, 2012

Dad and I got to talk about programming for two weeks before he died.

I was 22, a senior in college completing a BFA in graphic design. Dad was 62, an older dad than most.
When he started programming at Tennessee Tech back in the 60s, he wrote FORTRAN on punch cards. He
was a wealth of knowledge.

I had just been introduced to code that semester, and it was already consuming my thoughts. It felt
magical and powerful, in many ways a more fulfilling creative practice than visual design (but
that's for another post).

When I came home for the holidays, Dad shared The Ten Commandments of Egoless Programming with me.
He printed them and we discussed each point. It was one of the few programming related things we
were able to discuss before he unexpectedly passed; perhaps that's why it sticks with me.

From The Psychology of Computer Programming, written in 1971, here are The Ten Commandments of
Egoless Programming:

略
Posted by Stephen Wyatt Bush Apr 7th, 2012 dad, programming

Copyright © 2012 - Stephen Wyatt Bush - Powered by Octopress

■_

■_ 素数夜曲

以前のが図書館にあった(ただし保存庫)ので借りてみた。

2012年07月09日

■_

｢コードの未来、エンジニアの未来｣まつもとゆきひろが語る、明暗2つのシナリオ 【キーパーソンインタビュー】 ｜エンジニアtype（1/3） 文中に レンタルビデオ屋さんにDVDがぽつぽつ並び始めたと思っていたら、すぐにVHSが棚からなくなっていったように、変化とは突然、一気に起きるものです。 というのがあるんですが、 自分の場合これは DVDが出回り始めたなーと思ったら あっという間にレーザーディスクのソフトがリリースされなくなった。ですね。 あああれだけ買い集めるのに幾らかかったんだ…＞レーザーディスクのソフト

「本音を言えば、この本が売りたかった！」を全国で　ジュンク堂40店舗で“魂のPOP”フェア - ITmedia ニュース で作られたポップなどを集めたこれ、面白かったです。 → 書店員が本当に売りたかった本 (あとで書き足す)

(あとで書く) ループ 前判定 後判定 中判定 VB Loop

オススメ Coding Bibliography - O'Reilly Media

■_

■_

ぐだぐだ

2012年07月08日

■_

とあるTV番組で。 土用の丑の日に向けて出荷作業している鰻に対して 「おいしそうな旬の鰻～」 あれ? 鰻の旬て(ry

■_ eero

つづき。

なかなか面白いものが(といっても他から拝借したのが大半?) 

the eero programming language - documentation

General code structure
一般的なコード構造

Optional semicolons
省略可能なセミコロン

Semicolons serve the same general purpose in Eero as they do in C/Objective-C. That is, they
terminate and separate statements and declarations. However, with rare exception, they're optional
in Eero. As in Python and Ruby, statements generally end with newlines, but the parser will also
handle unambiguous statement continuations, such as dangling commas or arithmetic operators, onto
subsequent lines. The parser handles other situations as well.

Motivation: readability, DRY

Off-side rule (indentation indicates block scope)
オフサイドルール (ブロックのスコープを示すインデント)

Like Python (and various other languages), Eero adheres to the off-side rule for block scope. The
compiler doesn't dictate the level of indentation, but it must remain consistent for consecutive
lines in a particular block. This mechanism completely supplants the use of curly braces as block
delimiters.

Motivation: readability, safety, DRY, WYSIWYG

(略)

Object declarations are assumed to be pointers
オブジェクトの宣言はポインターと仮定される

Since Objective-C objects are always references (pointers to objects), it is never valid to define
object variables as anything but pointers. Instead of issuing an error, Eero implicitly treats all
declarations of a class type as a pointer to that type. This means that no associated asterisk is
needed.

  NSString mystring = myobject description

Motivation: readability, DRY

Local type inference
local な型の推論

You can declare and initialize local variables using the Eero-specific ”:=” operator. 
For example, the following code declares an integer initialized with a value:

  i := 100

The const specifier also works with this operator:

  const name := "Danielle"

You can still declare variables in the standard C/Objective-C way, using explicit types:
explicit に型を使って C や Objective-C の標準的な方式で変数の宣言をするのも可能です

int i = 100

Motivation: readability, DRY, safety (reduces temptation to use types like id)

No variable shadowing
変数の shadowing がない

Partly due to the type inference feature, and partly as a general code safety and readability
improvement, the compiler does not permit variable shadowing. Attempting to re-declare a variable of
the same name in an inner scope will result in a compilation error.

型推論機能やコードの安全性、readbility の向上を理由として、コンパイラーは
変数の shadowing を許していません。

  counter := 0
  if isReady
      counter := 0 // compiler error

Motivation: safety, readability

(略)

Method parameter type names are not enclosed in parentheses
メソッドのパラメーター型の名前はカッコで囲まない

In Eero, you do not enclose method parameter types in parentheses. However, like their message-sending
counterparts, you do separate parameters with commas.

  initWithBytes: const void* bytes,
         length: UInteger length,
       encoding: StringEncoding encoding

Motivation: readability

Method parameters have default variable names
メソッドパラメーターはデフォルト変数名を持っている

If omitted, Eero generates argument variable names derived from their selectors. They're determined
by the following rules, listed by most to least commonly encountered:

Eero は変数名が省略されたときにセレクターから名前を生成します。
その名前は以下に挙げた規則によって決定されます

    If the method or parameter name contains words separated by camel case, then the last word
    (scanning left to right), converted entirely to lowercase, is used. For example, method name
    “initWithString” results in variable name “string.”

    The first camel-case word encountered that contains two consecutive uppercase characters
    (scanning left to right) is used, along with all subsequent words, and no character cases are
    modified. For example, method name “initWithUTF8String” results in variable name “UTF8String.”

    If no uppercase characters are encountered, the entire method or parameter name is used. For
    example, parameter name “encoding” results in variable name “encoding.”

    If the first character in the method or parameter name is uppercase, the entire name is used. For
    example, method name “CreateNewString” results in variable name “CreateNewString”

  initWithBytes: const void*,
         length: UInteger,
       encoding: StringEncoding

Motivation: readability, DRY

(略)

There are no implicit conversions from primitive to object.
プリミティブからオブジェクトへの暗黙の変換がありません

Motivation: readability, DRY

(略)


Nested functions (const blocks)
ネストした関数

Eero supports constructions that look and act like nested functions but are semantically const
blocks. These can be defined in methods, functions, or other blocks, and the normal block-closure
rules apply. They can also be defined within if, else, while, for, etc. indented bodies. It is
possible to call them directly, like a normal function, or pass them as block arguments.

  implementation MyClass
      processMutableStrings: Array
      void addPositionSuffix( id obj,  UInteger idx, BOOL* stop )
         if obj == ''
            *stop = YES
         else
            obj appendFormat '%u', idx
      strings enumerateObjectsUsingBlock: addPositionSuffix
      addPositionSuffix = nil  // generates a compiler error: addPositionSuffix is a const
  end

Motivation: readability

■_

2012年07月07日

■_

面白そう(翻訳本でるだろうからそれまでに読めるか勝負?)。 The Pragmatic Bookshelf | The ThoughtWorks Anthology

へえ。 ネットで本を取り置き、店頭で試し読み　丸善＆ジュンク堂が新サービス - ITmedia ニュース ネットストアで品切れの書籍を店頭在庫から取り寄せ、発送をする「トコトンお探しサービス」も始めた。出版社取り寄せと同様、1～2週間で届ける。ネットストアで品切れしている書籍の半数以上が、全国の店頭に在庫があるという「類をみないロングテール在庫を活用すべく」展開。

またぞろ夏休みに向けて「夏休みに向けてプログラマーが読んでおくべき」とかいった感じの 売れ線のタイトルばかり並べたようなエントリがそこかしこに書かれるのでしょうが そんなことにはおかまいなしに一冊紹介 (そういやこの趣旨で何回かやったけど途中で投げてたっけか)
1+2=3―足し算に潜む迷宮

んでまあ、すぐにも使うような急ぎで必要になるのとは別に 「先行投資」ってのも欠かせないだろうと思うのですよ （「投資」なので回収できるとは限らない :）。 人それぞれですが、とりあえず 数学、 特に統計学や代数はやっといたほうがいいんじゃないですかねえ (独学でどのくらいう役に立つのという意見はまああるでしょうが)。 統計学の必要性については Zed も言ってたよ!

■_

■_ リーダブルコード

そりゃねーだろ! と突っ込みたくなったサンプルコード片編 

p90

public boolean ListHashNode(Node bode, String name, int max_length) {
    do {
        if (node.name().equals(name))
            return true;
        node = node.next();
    while (node != null && --max_length > 0);

    return false;
}

do ～ while のような後判定型のループはあまり良くないよね ということで前判定型に書き換えるのだけどその結果がこう 

public boolean ListHashNode(Node bode, String name, int max_length) {
    while (node != null && max_length-- > 0) {
        if (node.name().equals(name)) return true;
        node = node.next();
    }

    return false;
}

もう少し変わり具合がわかりやすいとか、 書き換えの効果がわかる例にしたほうがいいんじゃないかなあ。 そういう例を出してみろと云われると悩むけど。

■_ 新言語

今日も今日とて The eero programming language - a dialect of Objective-C | Hacker News

the eero programming language 
what is eero? 

Eero is a fully binary- and header-compatible dialect of Objective-C, implemented with a modified
version of the Apple-sponsored LLVM/clang open-source compiler. It features a streamlined syntax,
Python-like indentation, and other features that improve readability and code safety. It is
inspired by languages such as Smalltalk, Python, and Ruby. 

Eero は Apple-sponsored な LLVM/clang オープンソースコンパイラーの修正バージョンを使って
実装された、 Objective-C との完全なバイナリ互換とヘッダー互換を有する
Objective-C の方言 (dialect) です。
streamlined な構文、Python のようなインデントづけ、そして
readbility やコードの安全性を向上させる機能があります。
これらの機能は Smalltalk や Python、Ruby のような言語に inspire されたものです。

"Eero" is pronounced [ˈe-rō]‚ and is similar to the English word "aero".

2012年07月06日

■_

歴史群像 2012年 08月号 [雑誌]
買った。読んだ。「信長の独断フルスロットル!」の最後の一文にちょっと考え込んだ。
お、こんなのが 歴史群像―学研デジタル歴史館－｢信長の独断｣　by大野信長

読書会
TaPL読書会 第1回 - [PARTAKE] 以前行われていた東京のTAPL読書会のWiki。 なぜ過去形…まだだ。まだ終わらんよ ○|￣|＿ ってまあ6、7、8とお休みなので。はい。

連想
転職して一番最初に質問されたこと 【 マインドマップ１年生 plus ライフハック！ 】 「ゼロからモノを作るのと、形のあるものに手を加えていくの、どっちが好き？」 でこれを連想したり → 《貞観政要・その一》　君道第一／創業と守成いずれが難きや

■_ Loop

新言語。InfoQ なんで以下略 

Loop: A Compact JVM Language for Multi-Core

Loop: A Compact JVM Language for Multi-Core

Posted by Dio Synodinos on Jul 05, 2012

As a programming language, Loop is compact JVM language influenced by Haskell, Scheme, Ruby and
Erlang. It also tries to bring together the best features of functional programming  and OO
languages, in a consistent and pragmatic manner.

Loop は Haskell や Scheme、Ruby、Erlang に影響を受けた compact な JVM 言語です。
この言語はまた、関数プログラミングの機能とオブジェクト指向プログラミングとの
一貫性を持った pragmatic なやり方でもって最善の組み合わせを目指したものでもあります。

Programs are compiled on-the-fly to optimized JVM bytecode and therefore suffer no performance
penalty to interpretation; all while maintaining the quick, edit-and-run responsiveness of
interpreted code.

(Lopp の)プログラムは on-the-fly で最適化された JVM バイトコードへとコンパイルされるので
interpreration にもパフォーマンス上のペナルティはありません。
edit-and-run の反応はインタプリターのそれのようになります。

The Loop file structure is:
Loop のファイルは次のような構造です

module declaration

import declarations

functions & type definitions

free expressions

Here's an example of a loop program:
loop プログラムの例を挙げましょう

module mymodule

require othermod
require yet.another

class Pair ->
  left: 0
  right: 0

main ->
  new Pair()   # comments may appear anywhere


# free expressions must appear last
print('mymodule is go!')

InfoQ had a small Q&A with the creator of loop, Dhanji R. Prasanna, who's an ex-Google,
co-author of the JAX-RS spec and author of  “Dependency Injection: Design Patterns” by Manning:

InfoQ は loop の creator とちょっとした Q&A を行ないました。

InfoQ: How does loop compare with the rest of the JVM languages?
       loop をほかの JVM 言語と比べるとどういったものなのでしょうか?

    Dhanji: I don't want to do a nitty-gritty feature comparison, but I would say the philosophy of
    Loop is about providing a consistent, simple and joyful experience in coding. All features are
    designed with this comprehensive outlook in mind and a care for how features interact with each
    other, both syntactically and semantically. In other languages you sometimes have multiple ways
    to do the same thing, almost as a feature of the language, and many of these feel bolted-on.
    Whereas in Loop I've tried to narrow down the canonical ways of doing things so that they are
    concise and simple, and result in an attractive, comfortable syntax. It should be as easy to
    read code as to write it, and just as much fun.

    nifty-gritty な機能比較をしたくはありません。わたしが主張しておきたいのは
    Loop の哲学 (philosophy) がコーディングにおける一貫性ある単純で joyful な経験を
    提供するというものだということです。Loop のすべての機能はこの comprehensive outlook を
    念頭において設計されていて、機能がほかの機能と構文的や意味論的にどのように互いに interact
    するかに注意が払われています。
    他の言語では、同じことをするのに複数のやり方を見つけることもあるでしょう。
    almost as a feature of the language, and many of these feel bolted-on.
    Loop ではあることを行なう canonical なやり方を narrow down することを試みたので
    それらは一貫性がありかつ単純なものであり、構文が attractive で comfortable なものとなりました。
    Loop で書かれたプログラムは読みやすく書きやすいものであり、とても楽しいものとなるでしょう。
    #かなり超訳


(略)

コメント欄のやりとりも読むとよいかも (ここは翻訳されることはないだろうし)

■_

2012年07月05日

■_

以前にも少し書いたことですが。 信頼度成長曲線 - Wikipedia と呼ばれるものがあります。 ソフトウェアの開発の進み具合を表すことなどに使われているようですが、 なんで横軸に日付、テスト時間、またはテストケース数、縦軸に累積バグ発見数をとったグラフ で「信頼性」の向上具合を示すことになるのかと。 いやまあバグがそれだけ潰されてきたという見方をすればそうなんでしょうけれども なんとも納得がいかない。 納得がいかないといえばもうひとつあって、 S字の成長曲線を描くことが多い ということを良く目にするのですが、これってどこまで信じていいものなんでしょうか? どうもしっかりとした理論的根拠はないようだし、 そのような曲線になることが多いというのも、 全体のどれくらいの割合なのかとかそれは対象となるソフトウェアの性質やら規模に関係するのかとか 調べてみても良くわからない(まあ調べ方が悪いというのはあるでしょうけど)。

で、誰がいつ頃言い出したことなんでしょうか? ＞「ゴンペルツ曲線」やら「ロジスティック曲線」で近似できる(ことが多い)

海外でも、発見&修正したバグの数をプロットして…というのはやってなくもないようなのですが、 それを「信頼度～」という呼び方はしてる気配がないのですよね。

山浦恒央の“くみこみ”な話（15）：最もタチの悪いバグが潜むテストフェイズとは？ - ＠IT MONOist 山浦恒央の“くみこみ”な話（16）：テスト消化曲線とバグ発生曲線の7パターン診断 - ＠IT MONOist ソフトウェアの品質を学びまくる:「信頼度成長曲線」を信頼しない勉強会 つれづれなる技術屋日記: バグカーブ　対数曲線や二次曲線での近似のお勧め

■_

Mapping How Programming Languages Influenced Each Other According to Wikipedia « OUseful.Info, the blog… Programming Language's Influences « Griff's Graphs

■_

■_

2012年07月04日

■_

行ってきました。 感想は…前回とほぼ同じかなあ。 なんというか色々細かいところに手が入ってはいるんだけど、 それがどうもオリジナルのヤマト以後に発表された作品を想起させるようなものばかり (とはさすがに言い過ぎかもしれない)で、なんだかなあと。 自分がすれているだけなのかもしれないw

予告で気になったのでダークナイト～ とスターシップトゥルーパーズ～ は 観に行こうかという気になってます。

■_

間に合わなかった

■_

2012年07月03日

■_

作り込み 摘出

【レポート】自転車駐輪場 "Win-Win-Win"のビジネス - 日本コンピュータ・ダイナミクス | 経営 | マイナビニュース

■_

■_ R

広く使われているということで。 

A big list of the things R can do | (R news & tutorials)


As a result, trying to make a list of everything R can do is a difficult task. But we've made an
effort in this list of R Language Features, a new section on the Revolution Analytics website. It's
broken up into four main sections (analytics, graphics and visualization, R applications and
extensions, and programming language features), each with their own subsections:

ANALYTICS

    Basic Mathematics
    Basic Statistics
    Probability Distributions
    Big Data Analytics *
    Machine Learning
    Optimization and Mathematical Programming
    Signal Processing
    Simulation and Random Number Generation
    Statistical Modeling
    Statistical Tests

GRAPHICS AND VISUALIZATION

    Static Graphics
    Dynamic Graphics
    Devices and Formats

R APPLICATIONS and EXTENSIONS***

    Applications
    Data Mining and Machine Learning
    Statistical Methodology
    Other Distributions Available in Third-Party Packages ***

PROGRAMMING LANGUAGE FEATURES

    Input / Output
    Object-oriented programming
    Distributed Computing
    Included R Packages

The asterisks indicate features not part of the standard R distribution, as follows:

    * Requires Revolution R Enterprise
    ** Requires Revolution R Enterprise for IBM Netezza
    *** Requires additional open-source community packages from CRAN

■_ with

with という語の選択自体はともかくとして、 アンダーバー二個つきとかもいまいちな気がしていたのでこの提案はいいなあ。 Feature #6687: Enumerable#with - ruby-trunk - Ruby Issue Tracking System 

Feature #6687: Enumerable#with - ruby-trunk - Ruby Issue Tracking System

説明

Let me propose `Enumerable#with` for an alias of `Enumerable#each_with_object` or replace of it.

`Enumerable#each_with_object`のエイリアス、またはその置き換えとして、`Enumerable#with`を提案します。

When you create a hash using `Enumerable#inject`, you should ensure that the block return the hash.

(略)

最後に、`Enumerable#with`を使った例を示します。

Enumerable.send(:alias_method, :with, :each_with_object)

words.with(Hash.new(0)) { | word, h| h[word] += 1 } # => {"You"=>3, "say"=>10, "Yes"=>1, "I"=>7, "No"=>1, "Stop"=>1, "and"=>2, "Go"=>1, "go"=>2, "Oh"=>1, "no"=>1, "Goodbye"=>2, "Hello"=>2, "hello"=>5, "don"=>2, "t"=>2, "know"=>2, "why"=>2, "you"=>2, "goodbye"=>1}

[*1..10].with(5).map(&:*) # => [5, 10, 15, 20, 25, 30, 35, 40, 45, 50]

['ruby', 'python', 'haskell'].with('ist').map(&:+) # => ["rubyist", "pythonist", "haskellist"]

Thank you for your consideration.

ご検討の程よろしくお願い致します。

2012年07月02日

■_

訳して欲しい本 driving technical change

んーむ、もったいないなあ＞二冊

■_

■_ コードレビュー

コードレビューネタでいくつかあるんだよなー 

The stages of code review - Jake Goulding

The Stages of Code Review

Jul 1st, 2012

We recently started using gerrit to perform code reviews for a legacy C codebase that I work on. I
also help out on a couple of newer Java and Ruby projects that have had the benefit of having code
reviews and testing infrastructure from day one.

Starting to use gerrit on our C code has led me to think about how we approach code reviews, and
I've identified some stages that we have gone through. It's loosely sorted by the order in which we
adopted each check. While not every commit needs each point, this is a general idea of what might be
required.

    Functionality (機能性)

    This was what started us on the code review path - sometimes we would commit something that just
    didn't work right. Occasionally, the code wouldn't even compile! To try and address these
    problems, we would have a coworker give the code a once-over before pushing it. We actually
    started doing this long before gerrit by walking over to another desk.

    ときとして、そのコードがコンパイルすらできないこともあるのです!
     こういった問題に対処するために


    Function names (関数名)

    One of our explicit coding conventions is that non-static functions must be prefixed with the
    module name they belong to. This keeps us sane and helps prevent name collisions. We also have a
    few conventions for constructors, destructors and other common patterns. These are all easy to
    check for and was something we started doing almost immediately.

    わたしたちの explicit なコーディング規約の一つは
    non-static な関数にはそれが属しているモジュールの名前を前置しなければならないというものです。
    これは関数名の衝突を防ぐのに役立ちます。
    わたしたちはまた、コンストラクターやデストラクター、その他一般的なパターンに対して
    いくつかの規約を持っています。
    これらの規約はすべてチェックするのが簡単だったので、
    最初に手をつけたところがここです。


    Resource leaks (リソースリーク)

    After a few annoying memory leaks got committed, we started looking at the code with a critical
    eye for all kinds of leaks. Resource leaks are easy enough to add and subsequently miss,
    especially in C. Leaks are really just a special type of non-functioning code, but one that bites
    you days/weeks/years later instead of immediately.

    Sometimes we use a tool such as valgrind to test for leaks, but in many cases we just inspect the
    code visually. We check to see if resources are handled consistently and pay special attention to
    various error conditions.

    わたしたちはリークの検査のために valgrind のようなツールを使うこともありましたが
    多くのケースではコードを visually に inspect しただけでした。
    わたしたちはリソースが一貫性を持って扱われているかどうかを確かめ、
    エラー条件に対しては特に注意を払いました


    Efficiency (効率性)

    For better or worse, we almost always worry about how optimized our code is. Sometimes this is
    can be a valuable exercise, but in most situations it was probably overkill. There's just a warm
    fuzzy feeling when you catch an O(n2) algorithm that could be O(n log n), even if you spend more
    time coming up with the faster algorithm than will ever be saved in runtime. Since this focus on
    optimization is part of our culture, it has found it's way into our reviews.

    良くも悪くも、わたしたちは自分たちのコードをどのように最適化するかを常に心配していました
    これは valuable exercise となることもありますが大抵は overkill なものでした。


    Tests (テスト)

    Tests fall lower on this list than I would prefer. Unit testing C code is, at best, hard and/or
    annoying. Add the fact that trying to test code that was never designed to be tested is painful,
    and you can easily see why we tend to turn a blind eye when a commit doesn't add any new tests.


    Documentation (ドキュメント)

    Code written in C should probably have more documentation than most other languages, simply due
    to all the ways you can shoot yourself in the foot. For example, you can't tell if any given
    function will take ownership of the pointer you pass it, that information has to be documented
    somewhere. When we prefix our function names with the module name, the descriptive part of the
    name is often shortened to prevent extremely long function names. This means the function
    documentation is vital to understand what the function does.

    C で書かれたコードはおそらくは他の言語で書かれたものよりもよりドキュメントをしっかりさせるべきでしょう。
    それは単に、自分の足を容易に打ち抜くことができるからです。
    たとえば、何かの関数がその引数として渡されたポインターの ownership を得るかどうかを
    示すことはできません。そのような情報はどこかにドキュメントとして書いておかなければならないのです。
    わたしたちが関数名の前にそのモジュール名を置いたとき、その名前の descriptive part は
    (長い関数名は嫌われるので)省略されたものとなっていました。
    このことは関数のドキュメントがその関数の動作を理解するためにとても重要であることを示しています。


    Reviewing documentation often comes down to checking that it makes sense and is proper English.
    It's impressive how mangled a sentence can get when you refactor the code it is trying to
    describe.

    ドキュメントのレビューはしばしば英語として適切なものであるかどうかのチェックになります。


    Coding style (コーディングスタイル)

    Many different aspects of code fall into “style”: the contents, formatting and spelling of
    comments; the names of variables, static functions, and structures; the size and complexity of
    functions; the contents of structures.

    多くの aspects of code が 『スタイル』へ帰着しています
    それは contents であったり、フォーマッティングやコメントのスペリングといったものです。
    あるいは変数の名前、static 関数の名前、構造体の名前であるとか
    関数の長さや複雑さの度合いといった場合もありますし、
    構造体の内容ということもあります。

    These stylistic issues can be difficult to talk about in a code review, since sometimes it comes
    down to personal preference. The best you can do is express your preference and try to sway the
    other developer to your line of thinking. It helps if both people realize that the code has to be
    read and maintained by the entire development group.

    これらの stylistic な issues はコードレビューで話題にすることが難しくなる場合があります。
    それは個人的な好み (preference) に影響されることがあるからです。
    あなたができる最善のことはあなたの好みを説明  (express) して、


    Test style (テストスタイル)

    Test code style is an entirely different kettle of fish from production code style. A test needs
    to focus on how a user would want to use the code. It should minimize the clutter required to
    perform the test so as to make the test as readable as possible, while still highlighting the
    interesting part under test.

    テストコードのスタイルは、production コードのスタイルとはまったく異なるものです。
    テストではユーザーにどのようにそのコードを使って欲しいのかということに焦点を当てる必要があります。
    テストの対象となっている部分にハイライトをおきつつも
    テストを可能な限り readable なものにするために
    clutter は最小限にすべきです。

    Similar to code style, the difficulty reviewing tests comes from differences in personal
    preference. This is compounded by the fact that we are not as experienced with writing great
    tests yet.

    コードのスタイルと同じく、テストのレビューも個人的な好みの相違のために難しくなっています。
    これはわたしたちがまだ great なテストを書いたことがないということと複合します。

    Commit message (コミットメッセージ)

    Right now, this is my holy grail of code reviews. I once spent 15 minutes skimming through the
    git log to determine if we had a preferred verb tense in our commit messages (we did). More
    reasonably, this can involve ensuring that commit messages are capitalized consistently and that
    they describe why a change is being made, not just what or how.

Where we are now

The C project is currently somewhere around the “Tests” or “Documentation” stages. The Java and
Ruby projects expect tests and documentation, so they hover around the “Code style” and
“Test style” stages; I've only had one or two opportunities to correct someones verb tense :-).

Posted by Jake Goulding Jul 1st, 2012

Copyright © 2012 - Jake Goulding - Powered by Octopress

2012年07月01日

■_

L'eclat des jours(2012-07-01) 単純な教えは悪 arton さんによる「リーダブルコード」の書評。 ■_ 書評のようなナニカ で書き残してる部分あるんだけどもう放置で良いかなあ。

盛り上がっている Worst C++ tutorial ever! : programming

■_ Python 3

2から3への移行でいろいろ。 

Python 3 Q & A — Nick Coghlan's Python Notes 1.0 documentation

Python 3 Q & A

Last Updated: 30th June, 2012

With the recent release of Python 3.3 beta 1, some questions are once again being asked as to the
sanity of the core Python developers. A few years ago, we embarked down the path of asking the entire
language ecosystem to migrate to a new version that introduces backwards incompatible changes that
more obviously benefit future users of the language than they do current users.

I've seen variants of these questions several times of the years, and figured I'd finally record my
thoughts on the topic in a single location.

The views expressed below are my own. While many of them are shared by other core developers, and I
use “we” in several places where I believe that to be the case, I don't claim to be writing on the
behalf of every core developer on every point.

I am also not writing on behalf of the Python Software Foundation (of which I am a nominated member)
nor on behalf of Red Hat (my current employer).

TL;DR Version

    Yes, we know this migration is disruptive.
         わたしたちはこの (2から3への) migration が混乱を招いたと理解しています

    Yes, we know that some sections of the community have never personally experienced the problems
    with the Python 2 Unicode model that this migration is designed to eliminate
         コミュニティの一部には、今回の migration が取り除こうとしていた Python 2 のUnicode
         問題を経験したことがない人たちがいることを知っています

    Yes, we know that many of those problems had already been solved by some sections of the
    community to their own satisfaction.
         (解決しようとした)その問題がすでにコミュニティの一部では(独自の基準でもって)
         すでに解決されていたということを知っています

    Yes, we know that by attempting to fix these problems in the core Unicode model we have broken
    many of the workarounds that had been put in place to deal with the limitations of the old model
         問題をコアのUnicodeモデルを修正することによって解決しようとしたことが
         古いモデルの制限の中で解決しようとしていた
         多くのワークアラウンドを破壊してしまったことを知っています

    Yes, we are trying to ensure there is a smooth migration path from Python 2 to Python 3 to
    minimise the inevitable disruption
        Python 2 から Python 3 への smmoth な migration path を保証しようとしています

    No, we did not do this lightly

    No, we do not see any other way to ensure Python remains a viable development platform as
    developer communities grow in locations where English is not the primary spoken language.

        #英語圏以外にいる開発者たちを放置しないよ。くらい?

It is my perspective that the web and GUI developers have the right idea: dealing with Unicode text
correctly is not optional in the modern world. In large part, the Python 3 redesign involved taking
Unicode handling principles elaborated in other parts of the community and building them into the
core design of the language.

Why was Python 3 made incompatible with Python 2?
なぜ Python 3 は Python 2 と非互換になったのか?

To the best of my knowledge, the initial decision to make Python 3 incompatible with the Python 2
series arose from Guido's desire to solve one core problem: helping all Python applications to handle
Unicode text in a more consistent and reliable fashion without needing to rely on third party
libraries and frameworks. Even if that wasn't Guido's original motivation, it's the rationale that I
find most persuasive.

わたしの知る限り、Python 2 系列と Python 3 を非互換にしようという initial decision は
Guido のあるひとつの core problem を解決しようという希望からきたものです。
その希望とは、すべての Python アプリケーションが Unicode テキストを、
より一貫性があって、サードパーティのライブラリやフレームワークを必要としない信頼性のある
方法でもって取り扱うのを助けるというものです。
それが Guido の元々の motivation でなかったとしても、
最も妥当なものであろうとわたしは考えています。

(略)

© Copyright 2011, Nick Coghlan. Created using Sphinx 1.1.3.

■_ 1/3

結構なページ数じゃなかろかw 

Lisp Scheme Part34

641 デフォルトの名無しさん [sage] 2012/06/30(土) 18:29:14.09 ID: Be:
    素数夜曲いい本だな 

642 デフォルトの名無しさん [sage] 2012/06/30(土) 18:57:20.87 ID: Be:
    生協で見かけて、余りの厚さと価格で買いそうになったが、
    1/3くらい立ち読みして、初歩的な内容ばっかりで買うの止めた。

    5,6年前なら喜んで買って読んだんだろうけど。

■_ 定義済みシンボル

うるりっひはもう関係ないんじゃなかったっけ? 

C言語なら俺に聞け（入門編）Part 102

984 デフォルトの名無しさん [sage] 2012/06/30(土) 21:00:42.95 ID: Be:
    struct A {int a};

    main()
    {
    struct A __i686;
    __i686.a = 686;
    }

    上記のようなコードがgccだとエラーになる場合があるので困る。
    glibcのソースコード中にもこれ由来の問題が昔からあるのだが、いまだに治ってない。gcc,glibcどちらの問題なのか？そんなウルリッヒドレッパー。 

985 デフォルトの名無しさん [sage] 2012/06/30(土) 21:04:39.16 ID: Be:
    boke.c:1:16: 警告: 構造体または共用体の最後にセミコロンがありません [デフォルトで有効] 

986 ◆QZaw55cn4c [sage] 2012/06/30(土) 21:08:33.17 ID: Be:
    >>984
    http://codepad.org/hGhMhuxO
    __686 ってgcc特有のキーワードっぽいね、よくわからないけど。 

987 デフォルトの名無しさん [sage] 2012/06/30(土) 21:13:54.07 ID: Be:
    いや、ふつーこうじゃね？
    >ttp://www.pro.or.jp/~fuji/mybooks/cdiag/cdiag.5.4.html 

988 デフォルトの名無しさん [sage] 2012/06/30(土) 21:15:53.50 ID: Be:
    最近のgccをi686以降のみ対応で決め打ちビルドすると、組み込みマクロに #define __i686 1 などがずらっと追加される。
    普通にコンパイルするだけでも、ソースコードに #define __i686 1 が頭に追加されてる状態。このマクロを利用してCPU最適化コードへの#ifdef分岐に使ったりできるのだが、
    弊害として変数名などに__i686を使った場合に、マクロで1に置き換えられてしまうので、当然エラーとなる。

    これが原因で最新のglibcがビルドできない。
    しかも昔からある問題らしいhttp://www.gcd.org/blog/2009/10/179/
    __i686なんてよくある名前を組み込みマクロにしてるgccはどうかしてる。 

989 デフォルトの名無しさん [sage] 2012/06/30(土) 21:17:53.44 ID: Be:
    >>986
    gccのverが古くねえか？ 

990 デフォルトの名無しさん [sage] 2012/06/30(土) 21:18:43.80 ID: Be:
    >>988
    glibcのverが古くねえか？ 

991 デフォルトの名無しさん [sage] 2012/06/30(土) 21:20:08.57 ID: Be:
    つかglibcがgccでビルドできないって… 

992 ◆QZaw55cn4c [sage] 2012/06/30(土) 21:22:07.25 ID: Be:
    >>988
    プリプロセッサ制御用コマンドラインオプション -U ではだめなのでしょうか？めんどくさそう。 

993 デフォルトの名無しさん [sage] 2012/06/30(土) 21:23:39.42 ID: Be:
    >>991
    どちらも協調性に難ありまくりな作者が書いてるコードだからな 

994 デフォルトの名無しさん [sage] 2012/06/30(土) 21:24:07.18 ID: Be:
    おみゃがビルドしてる（使ってる）gccとglibcのver晒せや

■_

■_

■_

さてイカサマータイム。

一つ前へ 2012年6月(下旬)
一つ後へ 2012年7月(中旬)

ホームへ

リンクはご自由にどうぞ

メールの宛先はこちらkbk AT kt DOT rim DOT or DOT jp