ときどきの雑記帖 濫觴編

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

一つ前へ 2011年11月(中旬)
一つ後へ 2011年12月(上旬)

ホームへ

2011年11月30日

■_

・最先鋒? ついったで「最先鋒」という言葉を使っているのを見かけて、 そりゃ「急先鋒」の間違いじゃないのか? と思いつつぐぐる先生に訊いてみたら結構使用例がある… いやいやいや、辞書にもないし。 ってまあ新しい単語作っちゃいかんとは言わんけども、どうにもこう釈然としないものが。

せんぽう【先鋒】の意味 - 国語辞書 - goo辞書
1 戦闘の際、部隊の先頭に立って進むもの。さきて。「―隊」
2 運動・主張などの先頭に立つもの。「革新派の―となる」「急―」
3 剣道や柔道などの団体戦で、最初に戦う人。→次鋒 →中堅 →副将 →大将

んーむ。

【人生第二幕】プロ野球界から教師の道へ!将来は野球指導者の夢も - スポーツ - ZAKZAK 染田の入団した年のドラフトはいろいろあったんだよねえ。

Twitter / @m_kawaguchi: 【募集】ソフトウェア技術者が読むべきだという本を教え ...

【募集】ソフトウェア技術者が読むべきだという本を教えてください。
年末年始に1冊でも読み切れるようなものが良く10個まで募集したいです。
→現在おすすめして頂いた本のタイトルは「プログラミングの基礎」「7つの言語7つの世界」「アジャイルサムライ」の3つです。

もうちょっと前提条件が欲しいかなあ。 例によって「プログラミング作法」を出したいところだけど(分量的には)、 レベル的に物足りないかもしれないとか。

プログラミングからはちょっと離れてこんなのとか
思考の整理学 (ちくま文庫)

ついでだから、 別に読んでもためになるとは限らないけどプログラマーに勧める十冊(そのに)
韓非子 (第1冊) (岩波文庫) 韓非子 (第2冊) (岩波文庫) 韓非子 (第3冊) (岩波文庫) 韓非子〈第4冊〉 (岩波文庫) [新訳]韓非子
[新訳]韓非子

■_ 11

Computer Science Geeks が知っておくべき十一の公式とか。

Elegant Coding: Eleven Equations True Computer Science Geeks Should (at Least Pretend to) Know


This idea is a complete rip off an article that appeared in Wired a little while ago and it
got me thinking what would my list for Computer Science look like?  Plus I thought it might
be a fun post and unlike the Wired list this one goes to eleven.  So here they are in no
particular order:
.
  1. Binomial Coefficient
  2. Demorgan's Laws
  3. Eigenvector and Eigenvalue
  4. Pumping Lemma for Regular Languages
  5. Information Entropy
  6. Bayes' Theorem
  7. Fermat's Little Theorem
  8. Natural Join
  9. The Fixed-Point (Y) Combinator
  10. O(n)
  11. Euler's Identity

うは、知ってるほうが少ない。 が、scientist ぢゃないからいーやw Eleven equations every Computer Science geeks should know : programming

■_

Elegant Coding: Math for Programmers TNG

■_ Dart

Seth Ladd's Blog: Why Dart Excites Me


Why Dart Excites Me

Intro

Dart, the new open source structured web programming language currently in technology 
preview, is making me excited about web programming again. I'm watching it closely, 
fully understanding it's extremely early in the game to make any predictions. However, 
at least I can say I'm hopeful that there's a team out there attacking the very real 
problem of "not enough complex and full featured web apps" by working on an 
a language/libraries/VM option for modern web apps.

現在テクノロジープレビュー段階にある新しいオープンソースの
構造化 webプ ログラミング言語 Dart は
わたしを再度 web プログラミングで興奮させました。
Dart をじっくり調べてみて、
この言語が extremely early in the game to make any predictions であると理解しました。
とはいえ、少なくともわたしは言えるでしょう
I'm hopeful that there's a team out there attacking the very real problem of
"not enough complex and full featured web apps"
な非常に現実的な問題に挑戦しているチームが存在している
by working on an a language/libraries/VM option for modern web apps.


(略)

How does Dart help?

Dart has a familiar syntax to any Java or JavaScript developer.
Dart はすべての Java developer や JavaScript developer が親しみやすい構文を持っている

(略)

Dart is a class based, single inheritance, language with interfaces and libraries.
Dart はクラスベースで、単一継承の。インターフェースライブラリを持った言語である
(略)

Dart is single threaded, but supports concurrency through isolates.
Dart はシングルスレッドであるが、isolates を通じて concurrency をサポートしている

(略)

Dartis optionally typed, perhaps the most contentious design decision.
Dart は optionally typed であり、おそらくもっとも contentious な設計上の決定をしている

(略)

Dart can start fast, due to snapshots.
(略)

Dart is batteries included, delivering much more than just a language.
Dart は「電池内蔵」であり、単なる言語を遙かに超えたものである
(略)

Dart is novel, introduces fun concepts like "classes are interfaces", isolate
based concurrency, named constructors, factory constructors, and of course optional types.
Dart は novel で、「クラスがインターフェースである」とか、isolate ベースの concurrency、
名前つきコンストラクター、ファクトリーコンストラクター、そして optional types
といった楽しいコンセプトを持ち込んでいる。


(略)

Dart fixes the DOM with a Dart friendly DOM library that feels natural and refreshing. 

(略)

Dart is built by smart people.
Dart は賢い人たちによって作られた

■_ 反動

かと思ったらいろいろ事情があるようで。 wrong, rogue and booklog - Right now at Yammer we’re moving our basic... Stephen Colebourne's blog: Real life Scala feedback from Yammer Yammer moving from Scala to Java : programming

プログラミング言語 Scala 7冊目 

589 デフォルトの名無しさん [sage] 2011/11/30(水) 16:28:59.72 ID: Be:
    Yammer.comがScalaからJavaに戻したそうな。
    理由とかはまだ調べられてないけど。 

590 デフォルトの名無しさん [sage] 2011/11/30(水) 16:41:26.98 ID: Be:
    http://codahale.com/downloads/email-to-donald.txt 

591 ◆CgacaMDhSQ [sage] 2011/11/30(水) 18:32:48.66 ID: Be:
    >>589
    >>590のURLと一緒に、その背景
    http://codahale.com/the-rest-of-the-story/
    も読むといいかもです。わかりやすいように時系列で整理すると、
    (1) Yammerのエンジニアの人(@coda)が、昔の同僚(Twitter時代)に、Scalaの一部をJavaに置き換えてるとメンション飛ばす
    (2) それを見た Donald Fischer (現Typesafe CEO。 Odersky先生は現在チーフアーキテクト) が、数日語、@codaに、詳細を聞きたい
    旨のメール出す(CCにOdersky先生が入っていた)
    (3) @codaは、Scalaの改善に関われる中心的な人物がそういうメールを送ってきた、ということで、Scalaの経験からどんな問題があった
    かを Donald Fischer にリプライ(CC: Odersky)。このやり取りはprivateなものだった。
    (4) @codaは、e-mailのドラフトをgistに置いていたので、それがHacker NewsやTwitterに流出
    (5) しまった、と気づいた@codaがあわててgistを削除するも時既に遅く、publicに
    (6) @jodastephen はそれが流出したものだという事を知らずにYammerが公式にアナウンスしたとブログに掲載
    (7) @coda -> @jodastephen 「ちょw それ、Yammerの公式アナウンスじゃなくて、それ、俺の個人的見解だから」
    (8) @jodastephen のポストの影響でTwitterなどあちこちでその話が飛び交う
    (9) @code が http://codahale.com/downloads/email-to-donald.txt のコンテキストを釈明 (イマココ) 

592 ◆CgacaMDhSQ [sage] 2011/11/30(水) 18:46:29.97 ID: Be:
    まあ、流出情報ということはともかく、 http://codahale.com/downloads/email-to-donald.txt
    に書かれている事自体は(書かれたコンテキストを踏まえる必要があるにせよ) @jodastephen
    の記事とは異なり、読む価値があると思います。私が彼のメールで特に重要だと思ったのは

    (a) Scalaの学習曲線の問題(特に、チームメンバにどうやってScalaのコンセプトを教育するか)
    (b) sbt 0.7系 -> sbt 0.10移行に伴う問題
    (b) Scalaのバージョン間のバイナリ非互換性問題

    辺りでしょうか。彼自身がそれほど重要な問題ではない、と書いている通り、scala.collection.{mutable, immutable}
    がどうとかの話は、まあパフォーマンス特性を踏まえてコレクションを使いましょうね、という話で、場合によっては
    彼の書いたような指針に従ってチューニングするのもありかもしれませんが、Scalaに関する一般論としてはあまり
    重要ではないでしょう。

    ただ、私も原文読んだ中から、特に重要だと思った部分を抜き出しただけなので、実際の所は原文読んだ方がよかろうと思います。 

593 デフォルトの名無しさん [sage] 2011/11/30(水) 22:14:03.98 ID: Be:
    技術的な問題もあるが、In addition toからの3パラグラフもなぁ 

■_

■_

TIOBE index よりは需要に直結した結果になっていそう? Monthly programming language trends | Jobs Tractor

2011年11月29日

■_

村田のFAについては好きなようにしてくれ。なんですが、 村田にしても、昨年の内川にしても、 「優勝争いできるチームで云々」というのにはちょっと引っかかるものが。 いや、そういう状況でプレイしたいという気持ちは十分にわかる(つもりな)のですが、 どうにもすっきりしないんですよねえ。 これ以上は細かく書きませんけど。

■_

どうもよくわからん

flexやbisonを使わずに、プログラミング言語を作る方法。 今までflexや、bison使っ... - Yahoo!知恵袋

flexやbisonを使わずに、プログラミング言語を作る方法。
今までflexや、bison使ってプログラミング言語を作ってきた者です。

そろそろ、flexや、bisonを使ったプログラミング言語作りは慣れてきたので、
一歩ステップアップしたいと思います。

先日まつもとゆきひろ氏の講演で聞いた情報によると、
大学などで習う専門的な知識が必要らしいです。
プログラミング言語を作る上で、どのような知識が必要でしょうか?
また、どのような本、サイトなどで勉強する事ができるでしょうか?

よろしくお願いします。

補足
    文章がおかしいので訂正。
    先日まつもとゆきひろ氏の講演で聞いた情報によると、
    プログラミング言語を作るには、大学などで習う専門的な知識が必要らしいです。

    追加で質問です。
    アセンブラ言語を学ぶ事は、プログラミング言語を作る事の利益になりますか?

ベストアンサーに選ばれた回答

*** ツールを変更すべきかどうか
flex bisonをある程度使えるだけでも凄いと思います。

今rubyの最新版をダウンロードしてソースにgrepかけたのですが、bisonを使ってる様に思います。


*** 教材
rubyや他のオープンソース言語のソースも良い教材だと思います。


*** 他のコンパイラコンパイラ
他のパーサーとしてはC++のboost::spiritが使いやすそうに思います。
電卓などを見るとbison,flexに比べて格段に行数が少なくなってます。
速度面その他については良くわかりません。

http://www.kmonos.net/alang/boost/classes/spirit.html


よろしくお願い致します。
質問した人からのコメント

    * 成功ありがとうございました。boost::spiritなど知らない事がたくさんありました。
      ものすごく助かったです。
      教材の面でもアドバイスをくださったので感謝しています。
      本当にありがとうございました。
Copyright (C) 2011 Yahoo Japan Corporation. All Rights Reserved.

flex, bison を使わないで~というからその辺を手書きにするとか言う話かと思えば 別のツールを聞いて満足してたり、 どんな言語(処理系)作ったのかも良くわからない。 ってまあネイティブコードを吐くコンパイラーではなさそうですね。

なんで bison 使っているかを確かめるのに grep かけるんだろう…

■_

■_

c - SIGSEGV in optimized version of code - Stack Overflow
When the andpd instruction takes a memory operand, it's required to be aligned to a 
16-byte boundary.

For %rip-relative addressing, the offset is applied to the address of the following instruction.
So, here, the memory operand is at 0x4263ff + 0x169529 = 0x58f928, which is not 16-byte aligned.
Hence the segfault.

68000 では良くこの種のエラーで止まったなあ。 ワード(16ビット)境界にそろってないと、ワードアクセスやロングワードアクセスでどかーん。と。 X68000 だとあの白い窓がスクリーン中央に登場

■_ Perl 6

あ、そういえば最近 Rakudo の方をまともに見ていないような。

Announce: Niecza Perl 6 v12 - nntp.perl.org

    Announce: Niecza Perl 6 v12

This is the twelth release of Niecza Perl 6, as usual scheduled on
the last Monday of the month.  I've not had very much time for Niecza
this month.  This release marks one year since the first public release,
and about a year and a half since the project began.  It's hard to
believe I've been at it this long.

(略)

:BASE<DIGITS> literals are now supported.  (Solomon Foster)

(略)

    Future directions

My current priorities are:
 1. Make regexes much more feature-complete, including general Unicode
    properties and grapheme mode
 2. Prototype the debugger
 3. 6model convergence work, including roles/native types
 4. Figure out how modules and S11 stuff should work in Niecza.  Do it.

1. に期待。

2011年11月28日

■_

・今日の気になる 「ディレクトリ配下」

・#cybermonday でがしがしとeBookを買い込んでしまったw

Dodgy Coder: "Yoda Conditions", "Pokémon Exception Handling" and other programming classics これ、日付が11月27日になってるけど、「Egyptian brackets」 にはとても見覚えがあるぞw

■_ 比較

面白い。

■_ math guy

御年14歳の「math guy」による抽象代数の入門記事…らしい?

Computer Science, Math and Clever Dolphins: Abstract Algebra presented in a non-intimidating way (esp. for developers)

I think math is really cool, but, most people (sadly) don't think so. This includes 
many programmers who in fact enjoy many of the same things that mathematicians do, but, 
are more practical for most of the time.

I'll show you why abstract algebra (in particular, group theory) is really cool, and 
why you don't have to be a freaking genius to get it.

■_ 秘伝のソース(コード)

というのは FORTRAN とか COBOL で書かれたものにはきっとある。

NSA guide to Writing Efficient Fortran (1972) [PDF] : programming

While this sort of thinking may have been a good idea 40 years ago, and this paper is 
a great look at the past, keep in mind the modern rules of efficient programming:

話題の元になっているPDFを読むと結構面白い(かなり読みづらい状態だけど)

■_

この blog はどの記事も結構面白いので読んでない人は読むといいよ :)

The Codist

Programming is complicated stuff, but a lot of what makes a good programmer isn't all 
that different from the earliest learning we did in school.

The inspiration for this list came from the essay "All I Really Need to Know I 
Learned in Kindergarten" by Robert Fulghum at http://www.robertfulghum.com/.

■_

Haskell でプログラミングに入門した人がいろいろ。

The Clojure Community and Me - Bathroom Reading Material

I always say that Haskell was my first language. That is not entirely true. I played with
many languages in the beginning. Haskell was, however, my first real introduction to
programming. It was the first language that made sense. It was through Haskell that I was
able to make sense of programming as a whole, including Object Oriented programming.

■_ dying

タイトルにある通り、「死にゆくプラットフォーム」として Flash、Sliverlight、Win32 を挙げていて、最後にこれから伸びるであろうものの名前を挙げています。

Three dying platforms: Flash, Silverlight, Win32 - ITJOBLOG

It is a little early for a review of the year, but not too early to state that 2011 
has brought profound changes to the software development world. Although I am thinking 
mainly of the client, I would also argue that client and server are so intertwined 
that both are affected. As an example, I have heard developers moving away from SOAP 
web services not because of any conviction that REST is a better approach, but because 
the move away from Windows and towards HTML clients makes SOAP web services more 
difficult to consume.

So what's changed? Simply put, three platforms which once seemed strategic are now in 
obvious decline. Getting the nuance right for these platforms is tricky. Lots of 
software still runs and is still widely used long after it has ceased to be strategic 
for the company which supports it. All the platforms mentioned negatively below are 
still in active development; they are not going away and will still be running ten 
years and more from today. They come with health warnings though: depending on these 
platforms means that your software will gradually become more difficult for users to 
run and will be left behind by new technologies.

(略)

Platforms ascendant

If these platforms are in decline, what the ones that are rising fast? That is simple 
to answer. Apple iOS, Google Android, and HTML5 in general. Are these good for the 
next two decades as in Win32, or will be on the deprecated list in a few years? That 
is hard to say; if I had to rate them in order of likely longevity I would guess this:

以上のプラットフォームが退潮にあるとして、隆盛するものはなんでしょうか?
それに対して回答するのはとても単純で、一般的には iOS、Google Androild、HTML5 です。
これらは、次の二十年において Win32 のように勢力を広げるでしょうか?
あるいは数年のうちに時代遅れのリストに載ってしまうでしょうか?
それに答えるのは非常に難しいことです。
わたしがそれらを長生きする順で並べなければならないのなら、次のようになるでしょう


1. HTML, JavaScript and CSS

2. Apple iOS

3. Google Android

Predictions though are a dangerous game, and I would be interested in other opinions.

とはいえ予知は危険なゲームであり、ほかの選択肢を探すほうに興味があります。

■_

2011年11月27日

■_

・コスパ
「コストパフォーマンス」をコスパと略されるとこうむず痒いものが (そもそもコストパフォーマンスと表現していいのかそれをと言う(ry )

・買った
Switch On!(DVD付) Light My Fire(初回限定盤)(DVD付) 空想メソロギヰ【初回限定盤】(DVD付) TVアニメ「ベン・トー」オープニングテーマ LIVE for LIFE ~狼たちの夜~
ジャケット写真見ても、これらが特撮やアニメの主題歌のものだというのが知らん人にはわからんだろうなあ。 などと考えたり。

■_

「さよならジュピター」が入手困難な状態だというのを今日の新聞のコラム記事で知ったわけなんですが 技術書と小説という違いはあるにせよ、 向こうの人はなぜこうも気軽に(そう見える)公開できるのでしょうか? あるいはその裏返しとして、日本でできないのはなぜ?

さいとの備忘録 : 『省メモリプログラミング』 - livedoor Blog(ブログ) の日付を見るに割と以前からこの状態で公開されていたようですが、 例によって reddit 効果により数日前に知りました http://www.reddit.com/r/programming/comments/miw3t/small_memory_software_patterns_for_systems_with/ 本題の URL はこっち http://www.smallmemory.com/book.html

日本語訳はこの本。 省メモリプログラミング―メモリ制限のあるシステムのためのソフトウェアパターン集 (Software patterns series)

■_

ジョブスの失われたインタビュー - karasuyamatenguの日記 やらで知ったのですが、抜き出された発言の中でこれが印象に残りました。 Learning to program teaches you how to think. Computer science is a liberal art.

そしてその発言が元で盛り上がってたり。

Quotes from 1995 Steve Jobs 
Interview | Hacker News

The one I found most interesting is:

  "Learning to program teaches you how to think. Computer science is a liberal art."

It's clear that Jobs had viewed the iPad as being a way to help change education. 
Though you can't program on the iPad currently, I have no doubt that it will 
eventually come in the future.

Jobs also shared the same belief as Alan Kay. Kay was angered that Scratch wasn't 
currently possible under Apple's rules and viewed the Dynabook as a way to teach 
children how to code. A comment like this shows that Jobs probably had this in his 
mind but wanted to take baby steps with what he probably viewed as the future of Apple. 
It could also be that he wanted to get the foundation of iOS correct before moving 
into something more complicated as programming.

I wonder if Jobs felt the same way in his later years. I'm guessing he did. With 
traditional blue collar jobs disappearing, computer science is becoming an 
ever-increasing necessity for the future workforce.


You should read his biography (by Walter Isaacson). The intersection between arts and 
technology was a huge point of focus with Jobs.

I'm tempted to generalize this sentence to "Learning (anything) teaches you how to think".

Computing certainly conveys a stronger worldview than, say, skateboarding, but I 
really think mastering any activity can be a valuable and profound lesson.


The thing about computer programming is it is unforgiving - your program works or it 
doesn't. You cannot talk it, fool it, force it, etc., into working. Learning 
programming forces a certain reality check into your learning that is absent from many 
other disciplines.

I think it's less about the unforgiving nature of programming and much more about the 
immediate and (usually) precise feedback that you get when you fail that makes it so 
good at teaching you how to think. I wish every skill I wanted to learn came with a 
compiler and a debugger.


One of the differences between computer science and other fields is that, in a sense, 
computer science is a meta-field: it's the study of information. You learn how to 
solve problems from the very foundation, empirically. In that way it's probably akin 
to philosophy, although I don't know enough philosophy to be sure. Basically, instead 
of solving problems you're solving the problem of how to solve problems.

This is what makes computer science, along with a few similar fields (mathematics 
comes to mind) very special.

Quotes from 1995 Steve Jobs Interview | Hacker News

  "Learning to program teaches you how to think. Computer science is a liberal art."

Imagine all the hate the source of this quotation would receive on here if this didn't come from The Steve.

Three of the traditional seven liberal arts (grammar, logic, rhetoric, arithmetic, 
geometry, music, astronomy) are today considered branches of mathematics - is it 
really so hard to imagine computer science taking a place among these?


And only two of them are today considered humanities, which is what a lot of 
non-humanities people seem to be thinking when they say liberal arts.

As someone who briefly attended a liberal arts college, when I hear liberal arts I 
understand it to mean something that encourages dance majors to take materials science 
courses just as much as vice-versa.

liberal 「art」といってもいわゆる「げーじゅつ」とは違いますよね。と。

■_ The Heroes of Java

とある blog でインタビュー記事が。 インタビューイをぜんぜん知らんのですが(^^; 面白い質問があったりしたので抜き出し。

Enterprise Software Development with Java: The Heroes of Java

The Heroes of Java

There are Rockstars out there. Ninjas or some other kind of guys been given or given 
themselves titles like famous and successful members of well know communities.
(略)
I want to read about Heroes rather than agents, fighters or solo artists. This is why I
started interviewing Java people. Some I know. Some you might know. With this first
post in a new series called "The Heroes of Java" I kick off the publishing. New
interviews will appear on an irregular basis and I don't have a final list of people to
ask for answering my questions. But I hope: Some will jump in. A big thanks to those
who already did!

1st Part: Marcus Lagergren
2nd Part: Charles Oliver Nutter
3rd Part: Martijn Verburg
4th Part: Fabiane Bizinella Nardon
5th Part: Cay Horstmann
6th Part: Michael Hüttermann
7th Part: Andrew Lee Rubinger

Enterprise Software Development with Java: The Heroes of Java: Marcus Lagergren

You're still programming in Java. Why?
あなたは Java でプログラミングしていますよね? なぜですか?

"I'm not just programming in Java. I'm programming in everything. I use the most 
appropriate tools that get the job done for any given situation. Why am I still 
programming in C? Because it gets the job done for certain problem sets. Why am I 
still programming in Haskell? OK - that one has more to do with personal sexual 
deviancy I guess.

Java でだけプログラミングするわけではありません。なんででもプログラミングします。
わたしは与えられたシチュエーションで仕事を果たすもっとも適切なツールを使います。
なぜわたしは今でも C でプログラミングするのでしょうか?
それは特定の問題の集合に対しては仕事を果たすからです。
なぜわたしは今でも Haskell でプログラミングするのでしょうか?


When it comes to Java as a language it is not going to go away. It is ingrained in a 
lot of critical infrastructure in the world. The runtime is also definitely not going 
to go away - quite the opposite. If I may inject a blatant commercial plug here, my 
book "Oracle JRockit the definitive guide" talks a bit about how Java and 
the JVM became such a ubiquitous platform, and what the intrinsics of any such 
platform should be."

What's least fun with Java?
Java で一番楽しくないことはなんですか?

"Java code is extremely voluminous - it takes up so much space compared to Scala 
or Ruby or Clojure. Any line of Java that I write seems to want to break the 80 character
boundary. Really simple things are missing as well, for example, there are no implicit
ways of initializing a map or a collection, boilerplate getter and setter code for every
field needs to be in place and so on.

Java のコードはとても大きいもので、Scala や Ruby、Clojure と比べてとても多くのスペースを占めます。
わたしの書いた Java の行すべてが 80桁で改行することを望んでいるように思えます。
本当に単純なものが欠けていて、たとえば map や collection を暗黙に初期化する方法だとか
すべてのフィールドに対する getter や setter の boilerplate のコードを置く方法といった
ものがありません。

My main language feature frustration is lack of lambdas. Also, religiously, I've 
always been strictly against camel case in any setting. This goes back to Smalltalk ;)

言語機能についてわたしが主に感じる不満は、lambda の欠如です。
また、すべての設定において常に strict に camel case であることも不満です。

Type erasure can also be irritating. I guess one of the design rationales behind 
generics was that the implementation only needed to change the compiler. Surprisingly 
enough it also turns out that compiling certain type relationships in Java is 
undecidable. As someone who majored in theoretical computer science this is sort of 
like an itch in my brain that won't go away."


If you could change one thing with Java, what would that be?
もし Java に関して何かひとつ変えることができるとしたら、何を変えますか?

"For the language: lambdas and more compactness a la project Coin. We are on the 
way there and I think Java 8 will get rid of a significant part of the frustrations.

For the JVM specification: replace bytecode with something that works better as a generic
intermediate language for a multi language JVM. I think bytecode will, even despite
invokedynamic, soon turn out to be a bottleneck between the program and the runtime.
I rant a bit about it in my book. "

What's your personal favorite in dynamic languages?
あなたが個人的に好きな動的言語はなんですか?

"I like Ruby and Clojure lot. As I'm going to start contributing to Oracle's Nashorn
project now, I guess I'll have to teach myself to like Javascript as well. I will put
myself through the same proven brainwashing process as when I taught myself to appreciate
country music, a skill that was necessary to acquire after marrying my wife."

Which programming technique has moved you forwards most and why?
あなたをもっとも前進させたプログラミング技法はなんですか? またそれはなぜですか?

"Being the nightmare of anyone who wants to define a "process" or 
"technique" in software, I must ask you to define "programming 
technique" better.

I'll give it a shot anyway - how do I quickly write code that works and is robust?

Any code that contains sanity checks turns out to be good code: get into the habit of 
doing things like putting assertions absolutely everywhere without thinking about it.

Make sure new features have tests. If you consider something "untestable" 
you are doing it wrong. Make it testable! You might even have to write some kind of 
whitebox API that exposes system internals for the test framework to get a test 
written. In that case, so be it. Do it!

If you fix a bug by painstakingly whittling a reproducer down to a small deterministic 
bit of code - make sure to turn it into a unit test, tag it with a bug number and get 
it into the test suite so you'll never have to do this again.

When programming, avoid explicit parallelism. Things like actors, the fork/join 
framework or NSOperationQueue:s in Cocoa help out.

Understand memory management.

Measure and understand where your application spends its time and why.

Finally, whenever you can: be stateless or use functional programming. This saves 
debugging time and produces fewer bugs."

Enterprise Software Development with Java: The Heroes of Java: Charles Oliver Nutter

Java
You're programming in Java? Why?

"Java is the best language for the work I'm doing. I define the work I'm doing as 
"bending the JVM to Ruby's whim's." I also freqently write in Ruby, and we 
have started transitioning more JRuby code from Java to Ruby recently."

What's least fun with Java?

"The amount of typing required to do pretty much everything. It could certainly 
be worse, though...it could be C/++."

何をするにもたくさんタイプすることを要求されること。

If you could change one thing with Java, what would that be? "My two top features 
for the Java language would be closures and type inference. We should get the former 
in Java 8, but for the latter I will probably need a different language (like Mirah, 
my other language project)."

You might say that I want C# but with a Java sensibility (virtual-by-default, for example).

What's your personal favorite in dynamic languages?

"Ruby is my favorite dynamic langage. I also like Clojure from a design perspective, but
I find the language itself (mostly the syntax) to be uglier than I would like."


Which programming technique has moved you forwards most and why?

"If I had to pick one I'd say "refactoring." Few problems I run into 
can't be solved by doing an in-place refactoring. That's one reason I use less Ruby 
than Java...all but the most trivial refactorings in Ruby are very difficult to do 
safely...or at least very difficult compared to pressing a button in a Java IDE."

Which was the worst programming mistake you did?

"For a short time I was the lead developer of LiteStep (desktop replacement for 
Windows' "Explorer" environment), and helped orchestrate a large-scale 
refactoring and rewrite of its C codebase to be more modular and easier to extend. I 
made a good decision in pushing toward a set of pure-virtual C++ interfaces for key 
pluggable aspects, but I was wrong to try to go all the way to a COM-based solution 
with a team that barely understood C++ in the first place. Subsequent leads backed 
down that bad decision, but kept the overall structure...so I'm satisfied it worked 
out ok."


Copyright © 2007-2011 by Markus Eisele.. Powered by Blogger.

Enterprise Software Development with Java: The Heroes of Java: Martijn Verburg

Java

You're programming in Java. Why?

"I started out with it because I had to teach it at university to the year below 
me. I was mainly doing C++ at the time and Java quickly convinced me that it was a 
more productive language due to its memory management. I've stuck with it because of 
the incredible ecosystem that's sprung up around it and the fact that it's easy to 
read (most developers spend more of their time reading code than writing it). I've 
recently picked up smatterings of Scala, Groovy and Clojure - I see some exciting 
trends in polyglot programming coming up."

What's least fun with Java?

"Some of its verbosity could be reduced whilst still maintaining readability and 
of course functional programming is difficult, but hey - it's an OO language :-). It's 
nice to see the language moving forwards again and hopefully Project Coin can bring 
about more reduced syntax and the lambda JSR can open up some limited but useful 
functional aspects to it.

Oh yeah, and XML processing is still pretty annoying."

If you could change one thing with Java, what would that be?

"Modularisation (which is actually going to happen in Java 8 in one shape or 
another) - the CLASSPATH is less than ideal and constantly trips up people trying to 
learn the language. It would also give developers more freedom and more choice and be 
a huge boost for 'Java everywhere' - the possibilities are endless!"

What's your personal favorite in dynamic languages?

"Groovy - I love it's implicit goal of making life easier for the developer and 
it's interop with Java combined with features like it's XML processing, make it a 
great instant productivity tool."

Which programming technique has moved you forwards most and why?

"KISS - having small, tested units/modules of code has saved me time and time 
again. Also naming things properly."


Which was the worst programming mistake you did?

"It's rumoured that I took down all of the Comp Sci servers at my university when 
a networking/hard disk re-writing bot of mine went astray - I was _not_ a popular 
student that day.

I've made plenty of other mistakes, even self submitted to the dailywtf on one 
occasion! My motto is to have no fear when coding and to simply strive to improve 
every time you set down in front of your IDE."

Copyright © 2007-2011 by Markus Eisele.. Powered by Blogger.

Enterprise Software Development with Java: The Heroes of Java: Fabiane Bizinella Nardon

Java

You're programming in Java. Why?

I like the language and all the possibilities it brings. I love how many open source 
tools and frameworks are available in the Java universe. Java has also an awesome 
ecosystem, with JUGs, communities, multiple languages, conferences and so on. It is a 
very collaborative environment and I always felt welcome in the Java community.

What's least fun with Java?

Compiling and redeploying applications :-) . If you worked with dynamic languages, you 
realize how more productive you can be if you can skip these steps. Of course, there 
are frameworks and tools that allow you to do this with Java, but these are not always 
available.

If you could change one thing with Java, what would that be?

I would remove the need for getters and setters and make the language less verbose.

What's your personal favorite in dynamic languages?

Groovy.

Which programming technique has moved you forwards most and why?

If I think about my whole career, I have to say "Object Oriented Programming", 
for the obvious reasons. But the technique that I think made me a better programmer 
was defensive programming. My software is a lot more reliable because of it.


Which was the worst programming mistake you did?

There were so many... hard to choose :-) But I remember one situation that was kind of 
embarrassing. I was creating a software to visualize medical images for a large 
hospital. After finishing my code, I was over confident and decided to test it 
directly against the production database. Of course, there was a memory leak and I 
took the whole hospital down for about half an hour. This was a long time ago and I 
learned my lesson.


Copyright © 2007-2011 by Markus Eisele.. Powered by Blogger.

Enterprise Software Development with Java: The Heroes of Java: Cay Horstmann

Java

You're programming in Java. Why?

I used to program in C and C++, and when Java came along, I thought "No garbage 
collection? cross-platform libraries that actually do stuff (i.e. GUIs, database)? 
Where do I sign?"

わたしが C や C++ でプログラムしていていました。そして Java が世に出たとき
こう考えたのです
「ガーベジコレクションがない? GUI やデータベースのように actuall do stuff な
クロスプラットフォームライブラリ? わたしがサインするのはどこ?」

That was in 1996. It's hard to remember how far ahead of its time Java was of its 
commercial rivals.


Then Java became open-sourced, which it means that it will live forever once those 
wretched patents expire.

To make me move off the JVM, you'd have to offer me an open-source cross-platform 
alternative with more/better libraries than in the Java universe. Let me know if you 
find one.

As for the Java language, I use Scala for new projects when I can. It's more fun. 
What's important is that it runs on the JVM and interoperates with Java libraries.


What's least fun with Java?
The "stack trace from hell" in Java EE.

If you could change one thing with Java, what would that be?
もし Java に関して何かひとつ変えることができるとしたら、何を変えたいですか?

Properties


Which programming technique has moved you forwards most and why?
I'd like to say "functional programming" because it is fun to build very 
generic and reusable mechanisms, but the truth is much more boring.

「関数プログラミング」ですね。
なぜなら、非常に generic で reusable な機構を構築するのが楽しいからです。
しかし真実はもっと退屈です。

1) Strong typing. 強い型付け
In the bad old days of pre-ANSI C, I wasted an enormous amount of time with runtime errors.
You could call fread with the parameters in the wrong order, and it compiled, ran, and
flaked out. If you were lucky, you got a core dump. C++ changed my life. It took forever to
shut up the compiler, but when a program ran, it actually had a fair chance of doing the
right thing. My productivity multiplied.

2) VM bounds checks and garbage collection. VM による境界検査とガーベジコレクション
In the bad old days of C and C++, I wasted an enormous amount of time with memory 
allocation bugs. In Java, all that went away in an instant. My productivity multiplied.

I am lucky to have had this effect twice in my lifetime. Note that it came from 
changing from "really bad" to "ok", not from "good" to 
"great".

Where could similar improvements come from in the future? Here are a few suggestions.
- Get rid of the stack trace from hell
- Get rid of callbacks/event driven programming in client-side UIs and web apps
- Make concurrency less painful

Which was the worst programming mistake you did?
To follow the official specifications when trying to port that word processor to Windows.
I should have reverse engineered Word to find the undocumented OS calls that were
necessary to get continuous line breaking at an acceptable speed. That mistake taught me
something about the value of open specifications and open source.


Copyright © 2007-2011 by Markus Eisele.. Powered by Blogger.

Enterprise Software Development with Java: The Heroes of Java: Michael Hüttermann

Java
You're programming in Java. Why?
Java is an all-purpose business language but also a platform and a set of APIs. This 
makes up a great ecosystem and a great, mature infrastructure. The language Java is
powerful and innovative, and thanks to Oracle, it's developed further in an attractive way.

Java は all-purpose business な言語であるだけでなく、プラットフォームでもAPIの集合でもあるからです。
このことは Java を great なエコシステムと、great かつ重要なインフラにしています。
言語としての Java は強力であり、innovative です。
また、Oracle のおかげで開発が attractive way で進められています。

What's least fun with Java?
Java is slow. Stop, that was a joke, sorry about that, although I still hear this 
statement from time to time. Honestly: the bootstrapping process is sometimes 
suboptimal meaning achieving first good solutions while starting from scratch. Here I 
don't mean to hack together some HelloWorld classes to show that an API works, rather 
to design and code enterprise-ready solutions in a real- world project context.

If you could change one thing with Java, what would that be?
Java is moving forward, that's good. Instead of dreaming of new specific features for 
next Java versions, I more prefer improvements in the process itself that should result
in transparent, collaborative and frequent new Java versions. JCP.next/JSR348 is a very
good step in this direction, and Oracle does a great job in bringing Java to the next
level. What I’d like to add regarding specific new future Java features: as a matter
of fact, having Java on the market for so many years now, any new language feature can't
be that killer feature that would save the world. Additionally, using other languages on
the JVM already enables us to use other features and other styles without using the
language Java itself.


What's your personal favorite in dynamic languages?
First answer is Groovy because of it's powerful adoption level and ecosystem, for instance
the build system Gradle. Abstracting away from the typing system, also Scala is a
"dynamic language" for me in its classic sense. That's the reason why I cover
these two languages, Groovy and Scala, in my book "Agile ALM". I find it helpful
to develop solutions in a collaborative, dynamic way, and to set up a mash-up of tools
and languages that best fit to a given task. That's what makes up an Agile AlM.


Which programming technique has moved you forwards most and why?
It's more a zoo of many different complement techniques instead of the one that rules 
them all. Many agile practices influenced me including TDD and pair programming. On a 
meta level, the technique of "continuous improvement" adds much value by 
reviewing what you and the team have done continuously. Of course there are many other 
influencing aspects. One crucial aspect is experience.


Which was the worst programming mistake you did?
Generally, the next one is always the most annoying. :-) Hopefully many of the defects 
are identified early by the respective process, thus a mistake should never become 
"the worst one", rather just a learning opportunity. You should also keep in 
mind that a “mistake” is often just the result of a wrong or incomplete 
understanding, of requirements for example, or a defect in the development process. 
The worst case that can happen with mistakes is that you and the team repeat them: 
repeating mistakes is really something that you should avoid.

Copyright © 2007-2011 by Markus Eisele.. Powered by Blogger.

Enterprise Software Development with Java: The Heroes of Java: Andrew Lee Rubinger

Java
You're programming in Java. Why?
I started in Java, and it hasn't lost its relevance.
わたしは Java から始めましたし、Java はその妥当性を失っていないからです。


What's least fun with Java?
Java the language is verbose by today's standards, and lacking some key properties 
we've seen in newer stabs. Reified generics, immutability by default, and compiler 
support for hierarchical metadata are exciting concepts.

Java は今日の標準からすると冗長です。また、わたしたちが newer stabs でみるような
いくつかのキーとなる属性に欠けています。
ジェネリクスの具体化、デフォルトとしての immutability、
階層的なメタデータに対するコンパイラーのサポートといったものは exciting concepts です。

Java the standard library is riddled with complex or unintuitive APIs which we cannot 
ditch due to backwards-compatibility constraints. I also tend to dislike mechanisms 
which rely upon command-line options, one-time-only initialization, or other aspects 
which tie into the environment too tightly and make testing difficult.

Java the runtime, however, is just now beginning to stretch its wings.

If you could change one thing with Java, what would that be?
I honestly wouldn't seek to change the language too much. It's important that Java 
remain a nice common denominator that's familiar to all, while at the same time we 
expand upon the support for other JVM languages.


What's your personal favorite in dynamic languages?
I don't have one. Rather, if there are things I like about dynamic languages, the lack 
of static typing is not one of them. Passing functions as arguments is something I've 
always liked, however.


Copyright © 2007-2011 by Markus Eisele.. Powered by Blogger.

かなり削っても量的にきつかった ○| ̄|_

■_ みすしまさん言語

Twitter / @kmizu: #toys_lang にヒアドキュメントを実装してみ ... というツイートがあったので見てみると

examples/hereexp.toys at master from kmizu/Toys - GitHub

println(<<$EXP1 * <<$EXP2);
1 + 2;
EXP1
3 + 4;
EXP2

うはっw

■_

■_

2011年11月26日

■_

・Kindle
いろいろとわかってきました。 これはこれで使いどころがあるけど、やっぱりもうちょっと大きい画面のが欲しいですね。 iPad…?

・アントニヌス勅令とオープンソースというお題でつらつら考えているのだけど 多分まとめて文章にはしないw アントニヌス勅令 - Wikipedia

■_ Things Everyone Should Do:

毎度大雑把な訳ですが。

Things Everyone Should Do: Code Review | Good Math, Bad Math

Things Everyone Should Do: Code Review
誰もが行うべきこと: コードレビュー

Jul 06 2011 Published by MarkCC under Programming	

As I alluded to in my last post (which I will be correcting shortly), I no longer work
for Google. I still haven't decided quite where I'm going to wind up - I've got a
couple of excellent offers to choose between. But in the interim, since I'm not
technically employed by anyone, I thought I'd do a bit of writing about some
professional things that are interesting, but that might have caused tension with
coworkers or management.

前回のポスでわたしが述べていたように、わたしはもう Google で働いてはいません。
I still haven't decided quite where I'm going to wind up
- I've got a couple of excellent offers to choose between.
わたしはまだ決めていません
二、三の素晴らしいオファーをいただきました。
とは言えしばらくの間技術的にはわたしは誰からも雇われていない身であるので、
interesting ではあるけれども coworkers や management との tension を引き起こすかもしれない
professional things についていくつか書こうと考えています。


Google is a really cool company. And they've done some really amazing things - both
outside the company, where users can see it, and inside the company. There are a
couple of things about the inside that aren't confidential, but which also haven't
been discussed all that widely on the outside. That's what I want to talk about.

Google は本当に cool な企業です。そして彼らは、ユーザーが目にすることのできる会社の
外側とそうではない内側との両方で really amazing things を幾つか行ってきました。
会社内部のことでも機密でないものはいくつかありますが、
会社の外部でそれらが広く語られたことはありませんでした。
そういったことこそがわたしが述べたいことです。


The biggest thing that makes Google's code so good is simple: code review. That's not
specific to Google - it's widely recognized as a good idea, and a lot of people do it.
But I've never seen another large company where it was such a universal. At Google, no
code, for any product, for any project, gets checked in until it gets a positive review.

Google のコードをこれほどまでに良くしている最大のものは単純なもので、それはコードレビ
ューです。コードレビューは Google にしかないものではありません。コードレビューは良いア
イデアであると広く認識されていて、多くの人が実践しています。しかしわたしは同じように広
く使われている他の大きな企業を見たことがありません。Google では全てのプロダクト全ての
プロジェクトにおいて positive な review を受けない限り checked int されるコードは存在し
ていません。


Everyone should do this. And I don't just mean informally: this should really be a
universal rule of serious software development. Not just product code - everything.
It's not that much work, and it makes a huge difference.

すべての人がこれを行うべきです。わたしはこれを単に informally (非公式?) に言っている
のではありません。serious なソフトウェア開発における普遍的 (universal) なルールである
べきなのです。product code に限った話ではありません。すべてにおいてです。
It's not that much work, and it makes a huge difference.
#大したことはしないが大きな違いを生んだ?

What do you get out of code review?
コードレビューで得られるものとは何か?

There's the obvious: having a second set of eyes look over code before it gets checked
in catches bugs. This is the most widely cited, widely recognized benefit of code
review. But in my experience, it's the least valuable one. People do find bugs in code
review. But the overwhelming majority of bugs that are caught in code review are,
frankly, trivial bugs which would have taken the author a couple of minutes to find.
The bugs that actually take time to find don't get caught in review.

There's the obvious:
バグを捕捉するためにチェックされる前にコードを look over する second set of eyes を持つこと。
これが最も広く引用されているものであり、コードレビューの benefit として広く認識されているものです。
しかしわたしの経験から言えば、それは (コードレビューの benefit としては)
さほど価値のないものです。人々はコードレビューにおいてバグを発見します。
しかしコードレビューで捕捉されたバグの圧倒的大多数は、
率直に言ってプログラムの書き手が数分あれば見つけ出すような些細なバグです。
見つけ出すのに時間を要するバグはレビューでは見つけ出されないのです。


The biggest advantage of code review is purely social. If you're programming and you
know that your coworkers are going to look at your code, you program differently.
You'll write code that's neater, better documented, and better organized -- because
you'll know that people who's opinions you care about will be looking at your code.
Without review, you know that people will look at code eventually. But because it's
not immediate, it doesn't have the same sense of urgency, and it doesn't have the same
feeling of personal judgement.

コードレビューの最大のアドバンテージは純粋に social です。あなたがプログラミングをし
ていて、かつ、同僚があなたのコードを見ようとすることをあなたが理解しているのなら、
違ったプログラミングをあなたはして、もっと冴えたきちんとドキュメントが書かれている
より良く orgnize されたコードを書くことでしょう。
なぜなら、
you'll know that people who's opinions you care about will be looking at your code.
レビューがなければ人はコードを eventually に見るだろうことをあなたは知っていますが、
それは immediate ではないので
it doesn't have the same sense of urgency,
and it doesn't have the same feeling of personal judgement.


There's one more big benefit. Code reviews spread knowledge. In a lot of development
groups, each person has a core component that they're responsible for, and each person
is very focused on their own component. As long as their coworkers components don't
break their code, they don't look at it. The effect of this is that for each component,
only one person has any familiarity with the code. If that person takes time off or -
god forbid - leaves the company, no one knows anything about it. With code review, you
have at least two people who are familiar with code - the author, and the reviewer.
The reviewer doesn't know as much about the code as the author - but they're familiar
with the design and the structure of it, which is incredibly valuable.

もっと大きな利益があります。コードレビューは知識を広めるのです。開発グループの大多数に
おいては自分たちが responsible な core component をグループの各人が持っています。そし
て、各々が自分の component に強く結びついています、同僚のコンポーネントが彼らのコード
を壊さないのと同じように、コードを見ないのです。このやり方の効果はそれぞれのコンポーネ
ントについて、そのコードに精通している人が一人だけいるというものです。もし精通している
その人が休みをとったり(起きて欲しくはないですが) 会社を辞めてしまうとそのコードについ
て知る人は一人もいなくなります。コードレビューによって、少なくともあなたはコードを良く
知る書き手とレビュアーという二人の人間を得ますレビュアーは書き手ほどにはコードのことを
理解していませんが、その設計や構造について馴染んでいますこれは incredibly valuable な
ことです。


Of course, nothing is every completely simple. From my experience, it takes some time
before you get good at reviewing code. There are some pitfalls that I've seen that
cause a lot of trouble - and since they come up particularly frequently among
inexperienced reviewers, they give people trying code reviews a bad experience, and so
become a major barrier to adopting code review as a practice.

もちろんすべてのことが根本的に単純になるわけではありません。
わたしの経験ではコードのレビューに熟達するまでには多少の時間を要します。
多くのトラブルを引き起こしたのをわたしが見たことのある落とし穴がいくつかあります。
またそれは、とくに経験の浅い (inexperienced) なレビュアーたちが頻繁にはまるものであり、
コードレビューを試すことを bad experience と思わせ、そしてpractice として
コードレビューを適用するときの大きな障害 (major barrier) となってしまうのです。


The biggest rule is that the point of code review is to find problems in code before
it gets committed - what you're looking for is correctness. The most common mistake in
code review - the mistake that everyone makes when they're new to it - is judging code
by whether it's what the reviewer would have written.

最も大きなルールは、コードレビューのポイントがコミットされる前にコードに存在している問
題を見つけ出すことだとということです。コードレビューにおいて最もありがちな間違いは不慣
れなときに誰もがやってしまうもので、レビュアーが書いたことのある類のものかどうかでコー
ドを判定することです。


Given a problem, there are usually a dozen different ways to solve it. And given a
solution, there's a million ways to render it as code. As a reviewer, your job isn't
to make sure that the code is what you would have written - because it won't be. Your
job as a reviewer of a piece of code is to make sure that the code as written by its
author is correct. When this rule gets broken, you end up with hard feelings and
frustration all around - which isn't a good thing.

ある問題が与えられたとき、それを解決する幾通りものやり方が存在します。また、それを実際
にコードにする何百万通りの方法が存在します。レビュアーとしてのあなたの仕事は、レビュー
対象のコードを自分が書いたことのあるもののようにすることではありません。なぜならそうは
ならないからです。あなたの reviewer of a piece of code としての仕事は (author による)
そのコードを確実に正しいもの (correct) にすることです。このルールが破られたとき、
あなたはそれを悪く思い、そして欲求不満となってしまうでしょう、
それはよいこと (good thing) ではありません。


The thing is, this is such a thoroughly natural mistake to make. If you're a programmer,
when you look at a problem, you can see a solution - and you think of what you've seen
as the solution. But it isn't - and to be a good reviewer, you need to get that.

The thing is, this is such a thoroughly natural mistake to make.
ある問題に直面しているときに、もしあなたがプログラマーであるのなら解決策を見つけられて、
そして、あなたが解決したものを考えてしまうかもしれません。
しかし良いレビュアーになるためにはそれではいけないことをあなたは理解する必要があるのです。


The second major pitfall of review is that people feel obligated to say something. You
know that the author spent a lot of time and effort working on the code - shouldn't
you say something?

review に関する 二番目の major pitfall は、皆が何か言わなければならない義務があると
感じることです。author がそのコードに関してたくさんの時間と手間をかけたことを
あなたが理解しているとして、なにか言った方が良いのでしょうか?


No, you shouldn't.

いいえ、言うべきではありません。


There is never anything wrong with just saying "Yup, looks good". If you
constantly go hunting to try to find something to criticize, then all that you
accomplish is to wreck your own credibility. When you repeatedly make things to
criticize just to find something to say, then the people who's code you review will
learn that when you say something, that you're just saying it to fill the silence.
Your comments won't be taken seriously.

ただ単に "Yup, looks good" とだけ言うほど間違ったことはありません。
もしあなたが constantly にあら捜しをするために何かを見つけ出そうとやっきになっているのなら、
その結果としてあなたが得られるものと言えばあなた自身の信頼性の毀損です。
あなたが単に言うべきことを見つけるために繰り返し make things to criticize したならば、
あなたがなにかを言ったときはただ単に沈黙を避けるためだけなのだと
あなたにレビューしてもらうコードを書いた人は学ぶでしょうし、
あなたのコメントはまじめに受け取られることはないでしょう。


Third is speed. You shouldn't rush through a code review - but also, you need to do it
promptly. Your coworkers are waiting for you. If you and your coworkers aren't willing
to take the time to get reviews done, and done quickly, then people are going to get
frustrated, and code review is just going to cause frustration. It may seem like it's
an interruption to drop things to do a review. It shouldn't be. You don't need to drop
everything the moment someone asks you to do a review. But within a couple of hours,
you will take a break from what you're doing - to get a drink, to go to the bathroom,
to talk a walk. When you get back from that, you can do the review and get it done. If
you do, then no one will every be left hanging for a long time waiting on you.

三番目はスピードです。コードレビューを rush through すべきではありません。しかし同時に、
あなたにはレビューを promptly に行う必要もあります。あなたの同僚はあなたを待っているの
です。あなたとあなたの同僚がレビューを行うために時間を確保しようとしなくなったりあるい
はさっさと済ませてしまおうとしたら、みな不満を感じるようになり、コードレビューは単なる
欲求不満の源となってしまうでしょう。
レビューを行うために何かを犠牲にする必要があるのではないかと思われるかもしれませんが、
そうすべきではありません。レビューをするためにあなたはなにも犠牲にする必要はありません。
しかし数時間もすれば飲み物を飲むためとか風呂に入るためとか talk a walk のために
自分がやっているところから離れて休みたくなるでしょう


When you get back from that, you can do the review and get it done.
そういったことから戻ってくれば、レビューをきちんと終えられるでしょう。

If you do, then no one will every be left hanging for a long time waiting on you.


Site Admin | Theme by Niyaz Good Math, Bad Math Copyright c 2011 All Rights Reserved

■_ The Clean Coder

結局買ってしまった。Amazonさんからではなく。 1500円ほど高くついたけどまあいいんだ、うん。

The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series)

blog.christoffer.me: 9 things I learned from reading The Clean Coder by Robert C. Martin, on how professional developers conduct themselves

Hi, my name is Christoffer and I am an Internet addict.

Saturday, November 26, 2011

9 things I learned from reading The Clean Coder by Robert C. Martin, on how professional developers conduct themselves

Recently I finished reading Robert C. Martins' latest book The Clean Coder: A Code of 
Conduct for Professional Programmers (ISBN 0-13-708107-3).

Without hesitation, I can honestly say that this book has literally changed my view 
and thoughts on professional software developers.

この本はわたしの、professional software developers についてののものの見方や考え方を
文字通り変えたのだと躊躇なく言えます。

While reading this book, I have been writing notes in a scrap book on things I learned 
and things that turned on a light switch in my head. This entry is a compilation of 
those notes.

I strongly suggest that any, old or new, software developer that hasn't gotten the 
chance to read this book yet, should take the time and do it. It provides worthwhile 
and interesting information on what it means to be a professional software developer.

この本をまだ読む機会を得ていないすべてのソフトウェア開発者に、時間を作って読むべき
であるとわたしは強くお勧めする。この本には professional softwre developer である
ことが意味することの価値があり興味深い情報があります。

Disclaimer; Please note that this is also my interpretation of the book, which might 
not be according to the book or Robert C. Martin. As always different people interpret 
things differently.

9 things I learned

    * A professional developer knows the domain of their project
    * A professional developer is a team player
    * A professional software developer takes responsibility
    * A professional developer knows patterns and disciplines
    * A professional developer remains calm during hectic situations
    * A professional developer keeps practicing their profession
    * A professional developer rests
    * A professional developer knows the value of time
    * A professional developer is never afraid to say no

(以下略)

さて読むか。

■_ The price of a messy codebase:

すでに shiro さんが言及されてますが Island Life - 多段ビルド文化

The price of a messy codebase: No LaTeX for the iPad - Valletta Ventures

The price of a messy codebase: No LaTeX for the iPad

Any LaTeX user with an iPad has had the same thought: I want to use my favourite 
document creation system on my favourite device. Despite everything I am about to say 
about the LaTeX codebase, there is nothing like it for composing beautiful documents, 
and the iPad is the most beautiful platform out there, so it is natural to try and 
combine the two. This is the story of our failure to do so, and inside is a cautionary 
tale of the consequences of a messy codebase, the moral being that fourty years of 
work on TeX will most likely not make it into the tablet era due to the chaotic nature 
of the resulting codebase.

iPad を持つすべての LaTeX ユーザーは同じ思いを抱いているでしょう:
わたしは自分の好きなデバイスで自分の好きなドキュメント生成システムを使いたいのです。


(略)

LaTeX needs a scratch rewrite. The speed, bloat, and complexity cannot be solved with 
the current uneasy mix of C, WEB, and Bash. If translating the code to C and 
refactoring/commenting was practical it would leave a 4GB distribution, much of which 
is obsolete and unnecessary, especially metafont. Now that Operating Systems ship with 
a range of standard fonts, LaTeX has no need for its custom font package. XeLaTeX has 
made great progress in using native system fonts, adding full unicode support as a 
side effect, but for the most part it shares the TeX's codebase and its maladies. I 
can see no choice other than starting from scratch.

LaTeX は根本から書き直す必要があります。そのスピード、bloat (はどう訳すべきか
規模が膨れ上がりすぎってことですよね)、複雑さは現状の C と WEB と Bash の
uneasy mix によっては解決できないものです。
もしコードを C に変換 (translate) していれば、4GB distribution の時代遅れで
不要なものの多く、特に metafont を切り離すようなリファクタリングや commenting が
現実的なものであったでしょう
#だいぶ苦しい
今日、オペレーティングシステムは幅広い標準的なフォントを備えた状態で出荷されており、
LaTeX が自分でカスタムフォントパッケージを持つ必要はありません。
XeLaTeX はシステムのフォントを使う点で大きい進歩をもたらし、
副作用として Unicode のフルサポートを追加しています。
しかし、その大部分は TeX のコードベースおよびその maladies (病気) を共有しているのです。
わたしは根本から書き直す以外の選択肢を思いつきません。


At the risk of inflaming GPL advocates I hope that the LaTeX of the future will be 
under the LGPL. Aside from better compatibility with the App Store guidelines, it has 
been in the community's best interests for commercial products to interact with LaTeX 
on desktop systems, and with the restriction that iPad software must consist of a 
single binary, if the commercial sector is not going to be shutout on tablet systems, 
the LGPL is a must.


I have to admit I'm not volunteering to begin the Great LaTeX Rewrite; I don't think I 
am the hero to lead the LaTeX faithful into the tablet era, but I hope that someone 
reading this is. I love LaTeX, and I love my iPad, but for now I can only love one at 
a time.



Copyright © 2011 Valletta Ventures. Powered by Tumblr. Simple Things theme by Dan Hauk.

う、この辺はビルドシステムそのものはあまり関係してなかった。 single binary がどうこうはあるけど。 なんというか、全部を自前でどうこうというのは Apple の製品の作り方を思わせるところがあるなあとなんとなく感じた次第 (だからどうたという話には広げません :)

そしてアサマシ。
スティーブ・ジョブズ I スティーブ・ジョブズ II

■_

2011年11月25日

■_

読み終わった
スティーブ・ジョブズ I スティーブ・ジョブズ II

さかのぼり日本史
織田信長の辺りまで遡った>TV 放送
NHK さかのぼり日本史(1)―戦後 経済大国の“漂流” NHK さかのぼり日本史(2)―昭和 とめられなかった戦争 NHK さかのぼり日本史(3)―昭和~明治 挫折した政党政治 NHK さかのぼり日本史(4)―明治 「官僚国家」への道
この辺は放送では観ていないんだよなあ。 次の巻の幕末辺りからは観てる。

Twitter / @pragprog: 40% Off everything, today ...
今回は逃さずに。

■_ ポインターの宣言

これができたから偉いってもんでもありませんが。まあ。

Clumsy pointers - Susam Pal

Monday, November 29, 2010
Clumsy pointers

Here is a silly puzzle I solved exactly one month ago.

Without using typedef, declare a pointer to a function which has an array of 10 pointers
to functions which have int * argument and return type void as argument, and returns a
pointer to a function which has int * argument and return type void.

typedef を使わずに、
int * を引数に取り void を返す関数へのポインター十個を要素に持つ配列を引数とし、
int * を引数に取り void を返す関数へのポインターを返す関数へのポインターを宣言せよ。

If the above problem statement is difficult to understand, here is the same problem 
expressed in terms of typedef.

Without using typedef, declare a pointer that is equivalent to the following declaration of x.

typedef を使わずに以下の宣言と等価なポインター x を宣言せよ。

  typedef void (*func_t)(int *);
  func_t (*x)(func_t [10]);

I'll describe how I solve such problems. I start from the right end of the problem and 
work my way to the left most end defining each part one by one.

この問題をどのように解いたかを説明しましょう。
まず問題の右端から始め、左端へと向かってパーツをひとつずつ定義していきます。

Let me start.

  void x(int *)

A function which has int * argument and return type void.

int * を引数に取り戻り値の型が void である関数です。

  void (*x)(int *)

Pointer to a function which has int * argument and return type void.

int * を引数に取り戻り値の型が void な関数へのポインターです

  void (*x())(int *)

A function that returns a pointer to a function which has int * argument and return 
type void.

int * を引数に取り戻り値の型が void である関数へのポインターを返す関数です

  void (*x(void (*)(int *)))(int *)

A function which has a pointer to a function that has int * argument and return type 
void as argument, and returns a pointer to a function which has int * argument and 
return type void.

int * を引数に取り戻り値の型が void ある関数へのポインターを引数に取り、
int * を引数に取り戻り値の型が void ある関数へのポインターを返す関数です。


  void (*x(void (*[10])(int *)))(int *)

A function which has an array of 10 pointers to functions that has int * argument and 
return type void as argument, and returns a pointer to a function which has int * 
argument and return type void.

戻り値の型が void である関数へのポインター十個の配列を引数に取り、
int * を引数に取り戻り値の型が void である関数へのポインターを返す関数です


  void (*(*x)(void (*[10])(int *)))(int *)

A pointer to a function which has an array of 10 pointers to functions that has int * 
argument and return type void as argument, and returns a pointer to a function which 
has int * argument and return type void.

int * を引数に取り戻り値の型が void である関数へのポインター十個の配列を引数に取り
int * を引数に取り戻り値の型が void である関数へのポインターを返す関数へのポインターです

I verified the declaration with a short code.

この宣言を短いコードで検証しました。

  #include <stdio.h>

  /* A function which has int * argument and return type void. */
  void g(int *a)
  {
      printf("g(): a = %d\n", *a);
  }

  /* A function which has an array of 10 pointers to functions that has
   * int * argument and return type void as argument, and returns a
   * pointer to a function which has int * argument and return type void.
   */
  void (*f(void (*a[10])(int *)))(int *)
  {
      int i;
      for (i = 0; i < 10; i++)
          a[i](&i);
      return g;
  }

  int main()
  {
      /* An array of 10 pointers to functions that has int * argument and
       * return type void. */
      void (*a[10])(int *) = {g, g, g, g, g, g, g, g, g, g};

      /* A pointer to the function which has an array of 10 pointers to
       * functions that has int * argument and return type void as
       * argument, and returns a pointer to a function which has int *
       * argument and return type void. */
      void (*(*x)(void (*[10])(int *)))(int *) = f;

      /* A pointer to a function that has int * argument and return type
       * void. */
      void (*y)(int *a) = x(a);

      int i = 10;
      y(&i);
      return 0;
 }


Copyright © 2006–2011 Susam Pal

■_ ナポレオンと曹操

【ナポレオン】長谷川哲也34【陣借り平助】 

198 名無しんぼ@お腹いっぱい [sage] 2011/11/23(水) 21:41:18.13 ID:4gQp/L/k0 Be:
    結局ナポを裏切らなかった女は
    ポーリーヌとカーチャンだけか 

199 名無しんぼ@お腹いっぱい [sage] 2011/11/23(水) 21:54:59.93 ID:ibbztWj70 Be:
    >>198
    マリア・ヴァレフスカさんも 

200 名無しんぼ@お腹いっぱい [sage] 2011/11/24(木) 13:48:31.78 ID:Dfgg7wQK0 Be:
    まあナポも婚約ぶっちして離婚してだからなぁ
    裏切るってより、お互いを切らなかった関係はというか… 

201 名無しんぼ@お腹いっぱい [sage] 2011/11/25(金) 01:46:21.45 ID:teNfW7oc0 Be:
    ナポ「俺が天下の人間を裏切ろうとも、他人が俺を裏切るのは許さん。」 

202 名無しんぼ@お腹いっぱい [sage] 2011/11/25(金) 07:19:45.59 ID:GY7HTlYJ0 Be:
    孫子好きは曹操と共通するな。 

203 名無しんぼ@お腹いっぱい [sage] 2011/11/25(金) 09:48:26.69 ID:Z+oDEE2q0 Be:
    共通するつか世間一般で「孫子」と呼ばれてる本(ナポレオンが読んでた物も)の著者が曹操なんだが 

204 名無しんぼ@お腹いっぱい [sage] 2011/11/25(金) 09:54:21.80 ID:GnyABI390 Be:
    そう・・・(無関心) 

205 名無しんぼ@お腹いっぱい [sage] 2011/11/25(金) 14:19:40.48 ID:SbD0L4le0 Be:
    そうそう 

208 名無しんぼ@お腹いっぱい [sage] 2011/11/25(金) 18:09:14.87 ID:5/HxljYZ0 Be:
    >>203
    著者じゃないだろw
    注釈者だ 

210 名無しんぼ@お腹いっぱい [sage] 2011/11/25(金) 20:25:43.03 ID:Z+oDEE2q0 Be:
    >>208
    実質著者だろ。孫武なり孫〔月賓〕なりが著作したとされる孫子は漢代には全く原典の内容がわからなくなり、
    曹操は注釈を施すとしながらも実質はほとんど一から著述したようなもんなんだから。 

211 名無しんぼ@お腹いっぱい [sage] 2011/11/25(金) 20:36:31.14 ID:xRSSHDaL0 Be:
    原典は内容は不明でも存在したことは確かだし、
    曹操自身が明確に注釈者としての立場から叙述しているのだから、それはないわ 

212 名無しんぼ@お腹いっぱい [sage] 2011/11/25(金) 21:27:42.92 ID:BaJ2ibHG0 Be:
    ここは「そうそう」と同意しておくべきですか? 

213 名無しんぼ@お腹いっぱい [sage] 2011/11/25(金) 22:31:51.46 ID:beYVYRUz0 Be:
    >>212
    結論は「もうとっく」に出ている 

ダジャレネタ採用。

■_

KishoreLive » ECMAScript 6 looks promising

22 Nov 2011

ECMAScript 6 looks promising

I am quite excited about ECMAScript 6, after watching David Herman's talk at YUIConf 2011.
I am especially looking forward to seeing some of these features landing up on V8 soon,
so that I can use it on node.js. These additions will solve many common sources of
frustration that newcomers face when working with JavaScript. Although the spec is not
expected to be finalized till 2013 (so says David in the video), a lot of these features
are expected to hit Chrome and Firefox much before that.

I am personally looking forward to the following:
わたし個人は以下のような機能が欲しいと思っています:

let keyword
予約語 let

The let keyword has a block scope. Since var has a function scope, it sometimes leads 
to unintended bugs. Going forward, we can completely replace usages of var with let to 
avoid such bugs.

let はブロックスコープを持ちます。
var は関数スコープを持っているので意図せずバグを呼び込んでしまうことがあります。
そういったバグを排除するために、var を使っているところを完全に let で置き換えられます。


Default arguments
デフォルト引数

  function foo(bar="baz") {
     console.log(bar);
  }

With default arguments, we don't need the convoluted options object pattern.
デフォルト引数によって、 convoluted options object pattern の必要がなくなります。

Non-strict destructuring

Looks Pythonic, except that it's not as strict.
strict でないことを除けば Python 的なものです

  let [x,y] = [3,4,5];   // x=3, y = 4

Multi-line strings
複数行に渡る文字列

You can simply use the ` (backtick) operator to denote multi-line strings.
backtick 演算子を使って複数行に渡る文字列を簡単に表記できます。

  var htmlString = `Say hello to 
  multi-line
  strings!`

Templating
テンプレート

You can also embed JavaScript variables amidst your strings this way:

  var firstName = "Jack";
  var message = `Hello ${firstName}!`; // "Hello Jack!"

List comprehension
リスト内包

Again, a very pythonic construct:
再び非常に python 的な construct

  let even = [ x for (x in values([1,2,3,4,5,6])) if (x %2 === 0) ];

The use of values() allows x to denote the element values, rather than the element 
indices. This could also be written using the new for of construct:

valuse() を使うことによって、x を要素の添え字ではなく要素の値を表すのに使えます。
これはまた新しい for  of construct を使っても書けます

  let even = [ x for(x of [1,2,3,4,5,6]) if (x%2 === 0) ];

Apart from these, map, filter, reduce and so on will be part of the gang (some of 
these are already implemented in Chrome, Firefox, and (gasp) IE9).

このほかにも、map、filter、reduce といったものが part of the gang となるでしょう
(一部のものはすでに Chrome や Firefox、そして (gasp) IE9 で実装されています)。

UPDATE:

Noticing that this post has hit the frontpage on HN, I must add that I left out the 
proposed module system. Examples from the talk:

  import { $ } from "jquery.js"
  import { map, each } from "underscore.js"

Once again, it's all Python! The referred JavaScript files will actually be loaded by 
your browser before the code is executed.


© Copyright 2011 KishoreLive.

YUI Theater ― Dave Herman: “The Future of JavaScript” (48 min.) ≫ Yahoo! User Interface Blog (YUIBlog)

■_

Podcats.in temporary accommodation.: Testing for the end of a for(each) loop

Podcats.in temporary accommodation.: Testing for the end of a for(each) loop

Testing for the end of a for(each) loop

One sign of a good templating language is that you can test for the last iteration of 
a loop without having to count the iterations. PHP is no exception! Assuming you're 
quite happy with hacky syntax (you have to be if you're using PHP) then you can do 
this:

優れたテンプレート言語のひとつの印が、ループの繰り返しのカウントを行う必要なく
ループの最後の検査ができるというものです。PHP もその例外ではありません!
hacky な構文であなたがとてもシアワセだと仮定すれば、次のように書けます:


  foreach ($array as $item) {
    if (each($array) === false) {
      # last iteration
    }
  }


本題はどうでも良くて、この部分だけ気にいったw

■_

2011年11月24日

■_

物は言い様。

■_ ありがちな

なんでもかんでも正規表現で片付けるなと言う話題。

html - RegEx match open tags except XHTML self-contained tags - Stack Overflow

I need to match all of these opening tags:

<p>
<a href="foo">

But not these:

<br />
<hr class="foo" />

I came up with this and wanted to make sure I've got it right. I am only capturing the a-z.

<([a-z]+) *[^/]*?>

I believe it says:

    * Find a less-than, then
    * Find (and capture) a-z one or more times, then
    * Find zero or more spaces, then
    * Find any character zero or more times, greedy, except /, then
    * Find a greater-than

Do I have that right? And more importantly, what do you think? =)
You can't parse [X]HTML with regex. Because HTML can't be parsed by regex. Regex is 
not a tool that can be used to correctly parse HTML. As I have answered in 
HTML-and-regex questions here so many times before, the use of regex will not allow 
you to consume HTML. Regular expressions are a tool that is insufficiently 
sophisticated to understand the constructs employed by HTML. HTML is not a regular 
language and hence cannot be parsed by regular expressions. (以下長いので略)

Shortly after attempting to parse HTML using RegEx I found this : programming

If you want to know the science behind the reason, look up: Context-Free Grammers (CFG) 
and Regular Expressions.

From http://www.cs.rochester.edu/~nelson/courses/csc_173/grammars/cfg.html

Context-free grammars are strictly more powerful than regular expressions.

    Any language that can be generated using regular expressions can be generated by a 
    context-free grammar.

    There are languages that can be generated by a context-free grammar that cannot be 
    generated by any regular expression.

HTML is a context-free grammar which falls into the second point above.

■_ Forthの作者健在

ぶれないと言うかなんというか。

GreenArrays, Inc.
Parallel Processing for Embedded Systems

Multi-computer chips from GreenArrays offer an unrivaled combination of great 
computing power, small size, low energy consumption, and high value. They are simple, 
practical, versatile, and affordable. These chips change the game, enabling new 
embedded applications in a massively parallel world.

parallel processors for embedded systems

We are here to help you develop products that leverage this ground-breaking technology 
into a commanding position in your market.

multi-computer vs. multi-core architecture

■_

■_ PCRE

JIT コンパイルのあたり

/*************************************************
*         Execute a Regular Expression           *
*************************************************/

/* This function applies a compiled re to a subject string and picks out
portions of the string if it matches. Two elements in the vector are set for
each substring: the offsets to the start and end of the substring.

Arguments:
  argument_re     points to the compiled expression
  extra_data      points to extra data or is NULL
  subject         points to the subject string
  length          length of subject string (may contain binary zeros)
  start_offset    where to start in the subject string
  options         option bits
  offsets         points to a vector of ints to be filled in with offsets
  offsetcount     the number of elements in the vector

Returns:          > 0 => success; value is the number of elements filled in
                  = 0 => success, but offsets is not big enough
                   -1 => failed to match
                 < -1 => some kind of unexpected problem
*/

PCRE_EXP_DEFN int PCRE_CALL_CONVENTION
pcre_exec(const pcre *argument_re, const pcre_extra *extra_data,
  PCRE_SPTR subject, int length, int start_offset, int options, int *offsets,
  int offsetcount)
{
int rc, ocount, arg_offset_max;
int first_byte = -1;
int req_byte = -1;
int req_byte2 = -1;
int newline;
BOOL using_temporary_offsets = FALSE;
BOOL anchored;
BOOL startline;
BOOL firstline;
BOOL first_byte_caseless = FALSE;
BOOL req_byte_caseless = FALSE;
BOOL utf8;
match_data match_block;
match_data *md = &match_block;
const uschar *tables;
const uschar *start_bits = NULL;
USPTR start_match = (USPTR)subject + start_offset;
USPTR end_subject;
USPTR start_partial = NULL;
USPTR req_byte_ptr = start_match - 1;

pcre_study_data internal_study;
const pcre_study_data *study;

real_pcre internal_re;
const real_pcre *external_re = (const real_pcre *)argument_re;
const real_pcre *re = external_re;

/* Plausibility checks */

if ((options & ~PUBLIC_EXEC_OPTIONS) != 0) return PCRE_ERROR_BADOPTION;
if (re == NULL || subject == NULL ||
   (offsets == NULL && offsetcount > 0)) return PCRE_ERROR_NULL;
if (offsetcount < 0) return PCRE_ERROR_BADCOUNT;
if (start_offset < 0 || start_offset > length) return PCRE_ERROR_BADOFFSET;

/* These two settings are used in the code for checking a UTF-8 string that
follows immediately afterwards. Other values in the md block are used only
during "normal" pcre_exec() processing, not when the JIT support is in use,
so they are set up later. */

utf8 = md->utf8 = (re->options & PCRE_UTF8) != 0;
md->partial = ((options & PCRE_PARTIAL_HARD) != 0)? 2 :
              ((options & PCRE_PARTIAL_SOFT) != 0)? 1 : 0;

/* Check a UTF-8 string if required. Pass back the character offset and error
code for an invalid string if a results vector is available. */

#ifdef SUPPORT_UTF8
if (utf8 && (options & PCRE_NO_UTF8_CHECK) == 0)
  {
  int erroroffset;
  int errorcode = _pcre_valid_utf8((USPTR)subject, length, &erroroffset);
  if (errorcode != 0)
    {
    if (offsetcount >= 2)
      {
      offsets[0] = erroroffset;
      offsets[1] = errorcode;
      }
    return (errorcode <= PCRE_UTF8_ERR5 &.& md->partial > 1)?
      PCRE_ERROR_SHORTUTF8 : PCRE_ERROR_BADUTF8;
    }

  /* Check that a start_offset points to the start of a UTF-8 character. */
  if (start_offset > 0 && start_offset < length &&
      (((USPTR)subject)[start_offset] & 0xc0) == 0x80)
    return PCRE_ERROR_BADUTF8_OFFSET;
  }
#endif

/* If the pattern was successfully studied with JIT support, run the JIT
executable instead of the rest of this function. Most options must be set at
compile time for the JIT code to be usable. Fallback to the normal code path if
an unsupported flag is set. In particular, JIT does not support partial
matching. */

#ifdef SUPPORT_JIT
if (extra_data != NULL
    && (extra_data->flags & PCRE_EXTRA_EXECUTABLE_JIT) != 0
    && extra_data->executable_jit != NULL
    && (options & ~(PCRE_NO_UTF8_CHECK | PCRE_NOTBOL | PCRE_NOTEOL |
                    PCRE_NOTEMPTY | PCRE_NOTEMPTY_ATSTART)) == 0)
  return _pcre_jit_exec(re, extra_data->executable_jit, subject, length,
    start_offset, options, ((extra_data->flags & PCRE_EXTRA_MATCH_LIMIT) == 0)
    ? MATCH_LIMIT : extra_data->match_limit, offsets, offsetcount);
#endif

/* Carry on with non-JIT matching. This information is for finding all the
numbers associated with a given name, for condition testing. */

で、JIT コンパイルしない場合はこの続きのルーチンを実行すると。 _pcre_jit_exec の中身はこれから。


 pcre-8.20\sljit

2011/08/20  23:58             3,689 sljitConfig.h
2011/09/22  01:18            11,521 sljitConfigInternal.h
2011/10/05  01:36             9,057 sljitExecAllocator.c
2011/10/08  23:02            43,423 sljitLir.c
2011/10/08  23:02            28,801 sljitLir.h
2011/10/08  23:02            55,362 sljitNativeARM_Thumb2.c
2011/10/08  23:02            71,258 sljitNativeARM_v5.c
2011/09/30  18:29            16,218 sljitNativeMIPS_32.c
2011/10/08  23:02            56,407 sljitNativeMIPS_common.c
2011/08/20  23:58             9,036 sljitNativePPC_32.c
2011/08/20  23:58            14,780 sljitNativePPC_64.c
2011/10/08  23:02            58,214 sljitNativePPC_common.c
2011/10/08  23:02            14,765 sljitNativeX86_32.c
2011/10/08  23:02            21,688 sljitNativeX86_64.c
2011/10/08  23:02            74,298 sljitNativeX86_common.c
2011/10/05  01:36             6,956 sljitUtils.c

サポートしているCPUが一目瞭然すな。

2011年11月23日

■_

ベイスターズ関連で三つほど
スポーツナビ | 野球|プロ野球|横浜ベイスターズ|ニュース|真田、横浜に感謝=プロ野球 工藤、引退へ「投げるたび肩壊れる」プロ30年で区切り:プロ野球:野球:スポーツ報知 横浜ベイスターズ - 選手/チームに関するニュース 尾花髙夫監督 解任記者会見について
また二年で監督交代と。成績を見れば仕方がないのだけどなんというか、ねえ。

Amazon.co.jp: APL-プログラミング言語 (1975年): イバーソン, 内山 昭, 長田 純一: 本

■_ 迷信

Quora ってのはどういうサイトだったけか。 What are some popular myths in software development? と言うことでいろいろ。

What are some popular myths in software development? - Quora

Mythology
Software Engineering
Computer Programming
What are some popular myths in software development?
Why are they myths, and how did they become popular?


Some of the most prevalent myths are:

    * The Waterfall Method of design, the idea that it is both possible, efficient and good
      practice to completely specify a system before building it, and to execute the steps
      of a software project sequentially rather than iteratively. This was popularized by a
      paper that described the method as an example of poor development practices, but which
      people took as an example of good practice: http://en.wikipedia.org/wiki/Wat...

    * That customers or end users will know what they want and will be able to articulate it.

    * That some language, technology, or popular method, other than the one you are currently
      using, is a silver bullet that will magically solve your problems.

      あなたがいま使っていないようなプログラミング言語、技術、よく使われる手法は
      あなたの問題を魔法のように解決する銀の弾丸である

    * The Mythical Man Month, the idea that adding people to a development team makes it
      more efficient in a linear fashion. http://en.wikipedia.org/wiki/The...

    * That coming to agreement on a specification means agreeing on the actual features,
      even though specifications are fuzzy and subject to different interpretations.
      http://gettingreal.37signals.com...

    * That development works best when there is just one way to do it, where programmers
      freedom is severely restricted by the language.

      開発作業は、プログラマーの自由が言語によって制限されていて
      開発を行う手法がただ一つであるのが最善である。

    * That development works best when there more than one way to accomplish a task, where
      programmers have complete freedom.

      開発作業は、プログラマーが完全な自由を持ち、taskを完了する手法が複数あるのが最善である

    * That design patterns are universal, rather than examples of limitations in the 
      expressiveness of particular programming languages.

      デザインパターンは普遍的なものであり、特定のプログラミング言語の表現力における制限の例ではない

    * That the best technical solution wins.

      最善の technical solution が勝利する

    * That you can parse HTML with a regular expression: 
      http://stackoverflow.com/questio...

      HTML は正規表現で解析できる

    * That marketing doesn't matter, and is best left to "suits".

      マーケティングは重要ではない

    * That software can be estimated accurately.

    * That software development can be effectively and profitably sold as fixed cost, 
      fixed timeframe projects.

    * That objects are the best way to model anything in the real world.  That modeling
      real-world entities is the way objects are most commonly used.

      オブジェクトは現実世界にあるものすべてをモデル化する最善の方法である。
      現実世界の entities のモデリングとは最も一般的に使われている手法である。

    * That data should always be hidden within objects, and the object should provide all
      the operations necessary to work with that data.

      データはいつもオブジェクトの中に隠されていなければならないし、そのオブジェクトは
      そのデータを使うのに必要な操作のすべてを提供すべきである

    * That JavaScript has something to do with Java.

    * That logic can and should always be completely separated from presentation.

    * That software development is mostly about having good math skills, is best taught by
      studying theoretical computer science, and is best done by people who are highly
      mathematical.  That solving logic puzzles is the best way to gauge a software 
      engineer's ability.

    * The idea that software is mostly about what's visible on the surface, and that what
      is happening underneath the design isn't worth paying attention to or understanding—
      a belief especially held by nontechnical managers and clients.

    * That writing software is a good profession for people who lack people skills.

      ソフトウェアを書くことは people skills を書いた人にとっての good profession である

    * That software can be effectively mocked up or designed in some other medium, such
      as wireframes or Photoshop comps, because designing in the actual medium (such as 
      HTML and CSS) is too hard and expensive.

    * That designers can't or won't learn any coding, and must be protected from real code.

    * That design is just a layer of decoration applied on the surface, and is much less
      important than good engineering.

    * The idea that software can be reliably built up on a stack of abstractions, and that
      you only need to understand the topmost, abstract layers, rather than the underlying
      implementations.  See Joel Spolsky's Law of Leaky Abstractions for a discussion of
      why this is a myth: http://www.joelonsoftware.com/ar...

    * That when you finally release your new app or website, you're done.

This answer .
Please specify the necessary improvements.

■_ 値引き

知るのが一日遅かった! ○| ̄|_

【Lisp】プログラミング言語 Clojure #2【JVM】

155 デフォルトの名無しさん [sage] 2011/11/22(火) 18:05:38.78 ID: Be:
    http://vimeo.com/channels/fulldisclojure
    このビデオキャストイイね。advanced course だけど、プログラミングclojure
    を読み終わって更に力を付けたいという人には向いてる。
    ただし、英語の放送ですが。 

156 デフォルトの名無しさん [sage] 2011/11/22(火) 18:55:25.38 ID: Be:
    おまえら予約した?

    Amit Rathore "Clojure in Action"

157 デフォルトの名無しさん [sage] 2011/11/22(火) 20:26:31.69 ID: Be:
    >>156
    ebook版なら先週くらいに買ったよ

158 デフォルトの名無しさん [sage] 2011/11/22(火) 21:09:21.64 ID: Be:
    >>152さん、ありがとうです。やっぱり難しいですよね。
    labreplは>>154さんのいうとおり、テンプレのお勧め見て
    試して見ました。・・・が、>>153さんの言われている単語すら
    よくわからない状態で。精進します。 

159 デフォルトの名無しさん [sage] 2011/11/22(火) 22:12:48.46 ID: Be:
    >>155
    まだ2つしか見てないけどいいわこれ
    教えてくれてありがと

160 デフォルトの名無しさん [sage] 2011/11/22(火) 22:59:16.34 ID: Be:
    joy of clojure買ったのに読んでなかったわ 

161 デフォルトの名無しさん [sage] 2011/11/22(火) 23:55:04.58 ID: Be:
    http://media.pragprog.com/newsletters/2011-11-21.html
    どこ標準時か判らないけれど、11/25(金)だけ40%オフだそうで。
    pragmatic bookshelf
    http://pragprog.com/titles
    プログラミングClojure第二版
    翻訳されるなら英語版買わんでも、と思うがどうなんだろう。 

162 デフォルトの名無しさん [sage] 2011/11/23(水) 01:16:19.86 ID: Be:
    in actionのmanningは感謝祭の前日50%引きセールだそうで。
    西海岸は、22日の午前8時過ぎだから日本時間だと今日17時までかなあ。 

163 157 [sage] 2011/11/23(水) 04:03:33.67 ID: Be:
    くぅ、まだ100ページ(四分の一)しか読んでないのに半額セールとか涙出そうだ
    ショボーン
    木曜休みとってあるからこの連休で全部読むしか orz

164 デフォルトの名無しさん [sage] 2011/11/23(水) 04:33:38.69 ID: Be:
    感謝祭前後には毎年なにか割引があること覚えておかないとなあ。
    apressの場合、去年は12中旬ぐらいに25%セールがあったけど今年はどうだろ。 

165 デフォルトの名無しさん [sage] 2011/11/23(水) 14:44:07.82 ID: Be:
    clojureスレにきてるやつって
    なにげに英語余裕で読み書きできそうなやつがそろってそうな
    気がしてならない。 

166 デフォルトの名無しさん [sage] 2011/11/23(水) 16:07:52.55 ID: Be:
    >>165
    まだ裾野が狭いからね。日本語のリソースをもっと増やさないといけ
    ないのはわかってんだが。手が回らない。 

pragmatic bookshelf のは忘れないようにしよう (いくつか興味をひくものがあったし)。 40% Off Black Friday Celebration One-Day Sale

■_ Doom 3

reddit でも hacker news でも盛り上がってましたね。 /. でもそうなんだろうなあ(見てない)。

Doom 3 GPL source release : programming

Interesting comment from dgallagher at HackerNews:

$ sudo perl cloc-1.55.pl --unicode doom3.gpl/ 2014 text files. 1907 unique files.
476 files ignored.

http://cloc.sourceforge.net v 1.55  T=40.0 s (36.6 files/s, 22123.3 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
C++                            517          87051         113094         366423
C/C++ Header                   615          29640          26891         110991
C                              170          11407          15566          53520
Bourne Shell                    36           4529           5476          33717
m4                              10           1079            232           9025
HTML                            55            391             76           4142
Objective C++                    6            709            654           2605
Perl                            10            523            411           2380
yacc                             1             95             97            912
Python                          10            108            182            895
Objective C                      1            145             20            768
make                            22            160            253            579
DOS Batch                        5              0              0             61
Teamcenter def                   4              3              0             51
Lisp                             1              5             20             25
awk                              1              2              1             17
-------------------------------------------------------------------------------
SUM:                          1464         135847         162973         586111
-------------------------------------------------------------------------------

なんで Objective-C があるんだろう?

■_

ボツ

■_

「Scala嫌い。EJB2みたい」 - karasuyamatenguの日記

Github 革命が気になったので訳してみる。

Apache considered harmful

Apache considered harmful

Nov 22 2011

   "Institutions will try to preserve the problem to which they are the solution." -- Clay Shirky

(略)

The GitHub Revolution

For a moment, let's put the git part of GitHub on the back burner and talk about the hub.

On GitHub the language is not code, as it is often characterized, it is contribution. 
GitHub presents a person to person communication system for contributions. Documentation,
issues, and of course code, travel between personal repositories.

The communication medium is the contribution itself. Its value, its merit, its intentions,
all laid naked for the world to see. There is no hierarchy or politic embedded in the
system. The creator of a project has a clear first mover advantage but the possibility
is always there for its position to be supplanted by a fork, creating a social imperative
to manage contributions in a satisfactory manor to her community.

GitHub is truly a system of anarchism, in the most classic sense of the term. It is a 
system of communication and contribution that is without a central organization or 
institution of governance. Sure, it is hosted, developed, and maintained by someone 
but they do not enforce any set of governance or process over the users of the system.

It is my belief that we are, right now, in the middle of a very large evolution in the 
ecology of open source. The language of contribution has infected a new generation of 
open source contributors. Much of the potential first imagined by open source pioneers 
is being realized by high school kids on a daily basis who contribute effectively with 
less effort than has ever been required.

The reason I am so convinced of the importance of this change is so simple it took me 
nearly a year to identify it. While the ethos of Apache may have been "Community 
over Code" it required those in the community to understand and internalize that 
ethos for it to be fully realized. Social problems became political problems because 
the ethos had to be enforced by the institution.

The new era, the "GitHub Era", requires no such internalization of ethos. 
People and their contributions are as transparent as we can imagine and the direct 
connection of these people to each other turn social problems back in to social 
problems rather than political problems. The barrier to getting a contribution 
somewhere meaningful has become entirely social, in other words it is now the 
responsibility of the community, whether that community is 2 or 2000 people.

A system that enforces its principles without intervention is a tremendous achievement 
and GitHub's adoption trend should not be a surprise to anyone.

GitHub 革命

For a moment, let's put the git part of GitHub on the back burner and talk about the hub.

Github 上にある言語とはコードではなく、characterize された contribution (貢献) です。
Github は contribution のための人と人とのコミュニケーションシステムを提供しています。
ドキュメントと issues と、そしてもちろんコードが個人のリポジトリの間を巡るのです。


(GitHub 上で行われている) コミュニケーションのメディアは contribution それ自身です。
contribution の価値、メリット、意図といったものすべてが世界に対して開けっぴろげになっています。
そのシステムには階級も politic embedded (政治的に埋め込まれたもの?) もありません。
プロジェクトの creator は明白な first mover advantage (先行者優位)を持ちますが、
常に fork によって取って代わられる可能性があり、creator のコミュニティにとって十分に
manor な状況での contributions を manage するための social imperative を create していました。

# supplant 取って代わる


GitHub は本当に anarchism のシステムです。most classic sence of the term において GitHub は
コミュニケーションのシステムであり、contribution のシステムです。中心となる組織 (central
organization) も 統治のための制度や慣習 (insutitution of governance) もありません。
もちろん誰かの手によって host され、開発 (develope) され保守 (maintain) されてはいますが、
その人たちはシステムのユーザーの上になんらかの管理 (governance) や手続き (process) 
があることを enforce しません。


わたしたちはまさに今、オープンソースの生態系における非常に大きな進化の只中にいるのだという
ことがわたしの見解 (my belief) です。language of contribution はオープンソース contributors
の新しい世代に影響を及ぼしました。オープンソースの pioneer たちによる potential first imagined
の大半は、かつて要求されていたよりも少ない労力でもって効率的に contribute する
high school kids on a daily basis によって現実のものとなりました


わたしがその変化の重要性をそれほどに信じている (convinced) 理由はとても単純で、それ(変化の
重要性)を identify するまでに一年近くかかったからです。Apache の ethos が
"Community over Code" (コミュニケーションはコミュニティに優る) となった一方で、
それはコミュニティにおける ethos for it to be fully realized に対する理解と internalize
とを要求していました。その ethos は institution によって enforce しなければならなかったので、
social な問題は political な問題になったのでした。


新しい era である "GitHub Era" ではそのような ethos の internalization は要求され
ません。People と その contributions は as transparent as we can imagine で、そういった人た
ち同士の direct connection は socail problems を political problems から social problems に
戻しました。どこであれ meaningful な contribution を得るための barrier は完全に social なも
のとなったのです。言葉を換えれば、その規模が二人であれ二千人であれコミュニティの
responsibility が障壁となるようになったということです。


その principles (原理・原則) を intervention (介在、干渉) 抜きに enforce するシステムは
tremendous な achievement であり、GitHub の adoption trend は誰も驚かせません。

■_

2011年11月22日

■_

パンドラ
最近、連続して「パンドラの箱」という意味合いで「パンドラ」と言っている人を見かけて少々もにょる。 パンドラの箱 ギリシアの昔話 <福娘童話集 きょうの世界昔話>

マネーボール/FA/村田/菅野/ドラフト
とメモ書きがあるのだけど、 はてこれを元に何を書こうとしていたんだろう?w

■_ R

outer の使い方よくわからんがすごい。

【R言語】統計解析フリーソフトR 第4章【GNU R】 

234 132人目の素数さん [sage] 2011/11/15(火) 11:15:58.60 ID: Be:
    1.i行j列成分がi^2+j^3で与えられる10行10列の行列をfor文を用いて作りなさい。
    2.a=1000:1を作成してこれを昇順に並び替えなさい。
    3.A=matrix(400:1,20,20)を作成し、この行列を第1列の値が昇順に並ぶように行を並び替えなさい 

235 132人目の素数さん [sage] 2011/11/15(火) 11:16:21.60 ID: Be:
    ↑の回答わかる方お願いします。 

236 132人目の素数さん [sage] 2011/11/15(火) 14:26:46.90 ID: Be:
    >>234
    また宿題か。
    まさか試験中に書き込んでる? 

237 132人目の素数さん [sage] 2011/11/15(火) 22:14:50.47 ID: Be:
    >>234
    > 1.i行j列成分がi^2+j^3で与えられる10行10列の行列をfor文を用いて作りなさい。

    しかし、Rでfor文ってその教授はバカじゃないの?

    常識的に
    outer((1:10)^2,(1:10)^3,'+')
    ってやるものじゃないのか? 

238 132人目の素数さん [sage] 2011/11/16(水) 00:17:57.03 ID: Be:
    >>234
    1. a <- matrix(0, 10, 10); for (i in 1:10) {for (j in 1:10) {a[i, j]=i^2+j^3}}
    2. rev(a)
    3. A[20:1,]

R -- プログラミングの定石 R-Source outer関数便利だお - Seeking for my unique color.

> 1:10
 [1]  1  2  3  4  5  6  7  8  9 10
> (1:10)^2
 [1]   1   4   9  16  25  36  49  64  81 100
> (1:10)^3
 [1]    1    8   27   64  125  216  343  512  729 1000
> outer((1:10)^2,(1:10)^3,'+')
      [,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8] [,9] [,10]
 [1,]    2    9   28   65  126  217  344  513  730  1001
 [2,]    5   12   31   68  129  220  347  516  733  1004
 [3,]   10   17   36   73  134  225  352  521  738  1009
 [4,]   17   24   43   80  141  232  359  528  745  1016
 [5,]   26   33   52   89  150  241  368  537  754  1025
 [6,]   37   44   63  100  161  252  379  548  765  1036
 [7,]   50   57   76  113  174  265  392  561  778  1049
 [8,]   65   72   91  128  189  280  407  576  793  1064
 [9,]   82   89  108  145  206  297  424  593  810  1081
[10,]  101  108  127  164  225  316  443  612  829  1100
> 

なぜこうなるのかよくわからん ○| ̄|_

■_ ものまね鳥をまねる

数学パズル ものまね鳥をまねる POD版 ―愉快なパズルと結合子論理の夢の鳥物語

2011/11/mockingbirds.md at master from raganwald/homoiconic - GitHub

Mockingbirds and Simple Recursive Combinators in Ruby

In Raymond Smullyan's delightful book on Combinatory logic, To Mock a Mockingbird, 
Smullyan explains combinatory logic and derives a number of important results by 
presenting the various combinators as songbirds in a forest. As you can guess from the 
title, one such bird, the Mockingbird, plays a central role in combinatory logic.

    What is a Combinator? One definition of a combinator is a function with no free variables.
    Another way to put it is that a combinator is a function that takes one or more arguments
    and produces a result without introducing anything new. In Ruby terms, we are talking
    about blocks, lambdas or methods that do not call anything except what has been passed in.

    コンビネーターとはなにか? その定義のひとつは、自由変数を持たない関数であるというものです。
    もうひとつは、ひとつ以上の引数を取り、かつ新しいものを一切導入せずに結果を生成するという
    ものです。わたしたちは Ruby 用語で、渡されたもの以外は何も呼び出さない ブロック、lambda、
    メソッドについて述べます。

                                                                --Finding Joy in Combinators

Duplicative Combinators


(以下略)

■_

ボツ。

■_

2011年11月21日

■_

翔泳社の、大きくて高くて厚い本と言えばこれがあったじゃなイカ。 Amazon.co.jp: 実用 Common Lisp (IT Architects'Archive CLASSIC MODER): ピーター・ノーヴィグ, 杉本 宣男: 本

■_ R

本日の丸投げ。

プログラミングの問題で分からないものがあります。 | OKWave

プログラミングの問題で分からないものがあります。


m人のグループに同じ誕生日の人が二人以上いる確率Pはどのような式で表されるか?
ただし、誕生日は1年365年に渡ってランダムに分布すると仮定する。(まず、同じ誕生日の人が一人もいない確率を考えるとよい。)

グループ人数mの入力に対しPを計算するプログラムを作りなさい。
Pが初めて1/2を超えるmの値を求めよ。(そのようなmの値を求めるプログラムを作りなさい。)


回答お願いします。
> d <- 365:1 / 365
> for (i in 1:length(d)) {v<-1-prod(d[0:i]); cat(paste(i, v, "\n")); if (v > 0.5) break;}
1 0 
2 0.00273972602739725 
3 0.00820416588478134 
4 0.0163559124665502 
5 0.0271355736997935 
6 0.0404624836491114 
7 0.0562357030959754 
8 0.074335292351669 
9 0.0946238338891667 
10 0.116948177711078 
11 0.141141378321733 
12 0.167024788838064 
13 0.194410275232429 
14 0.223102512004973 
15 0.252901319763686 
16 0.28360400525285 
17 0.315007665296561 
18 0.346911417871789 
19 0.379118526031537 
20 0.41143838358058 
21 0.443688335165206 
22 0.47569530766255 
23 0.507297234323985 

ふむ。 もうちょっと関数型言語っぽく(ってどういうの)書こうと思ったけどくじけた。

あと、最初 Haskell でやろうとしたのはナイショだ。

効率が悪いのも見逃してね :) あ、無名関数を使えば、変数への代入を(見かけ上)しないでもいいのか。 引数で受け取ってごにょごにょ。

> (function(d) {for (i in 1:length(d)) {v<-1-prod(d[0:i]); cat(paste(i, v, "\n")); if (v > 0.5) break;}})(365:1 / 365)
1 0 
2 0.00273972602739725 
3 0.00820416588478134 
4 0.0163559124665502 
5 0.0271355736997935 
6 0.0404624836491114 
7 0.0562357030959754 
8 0.074335292351669 
9 0.0946238338891667 
10 0.116948177711078 
11 0.141141378321733 
12 0.167024788838064 
13 0.194410275232429 
14 0.223102512004973 
15 0.252901319763686 
16 0.28360400525285 
17 0.315007665296561 
18 0.346911417871789 
19 0.379118526031537 
20 0.41143838358058 
21 0.443688335165206 
22 0.47569530766255 
23 0.507297234323985 

おー。

■_ Rakudo

なんか気になるものが。

Rakudo: this week's release, and the next Rakudo Star | 6guts

Rakudo: this week's release, and the next Rakudo Star
Posted on November 20, 2011

On Thursday, tadzik++ cut release #46 of Rakudo. This time, we named it for the London 
Perl Mongers, organizers of this year's outstanding and very well attended London 
Perl Workshop. I'd not been to one for a couple of years, and I'd forgotten what a 
fun event it is. This one felt better than ever. So, thanks folks! :-)

So, what was in the Thursday release?

    * Big Integer Support: the Int and Rat type now support very large values without loss
      of precision/coercing to floating point. This means you can do such things as compute
      factorial to 1000 (which stringifies to 2568 characters, by the way :-)). You don't
      need to get any libraries set up for this – we bundle a slightly extended libtommath
      with NQP, and it's exposed by some ops and an extra 6model representation, which the
      Int type inlines into its body (so Int is still a single garbage collectable object
      at the VM level). Thanks go to moritz++ for doing much of the work on this.

    * Protoregexes with LTM: it's taken us a lot longer to get protoregexes back into the
      nom development branch than we'd initially hoped. Here's the story. A while ago, 
      pmichaud++ worked on real Longest Token Matching support – driven by an NFA – in a 
      re-development of the regex engine. We'd only ever had “cheating” protoregexes in 
      Rakudo before – ones that could work on literal prefixes, but nothing more. The 
      improved engine is a really nice piece of work – amazingly little code for what it 
      does, and very elegant. Sadly, pmichaud has not been able to work so much on Rakudo of 
      late, so the work lay not-quite-done and unmerged for a while. Just ahead of the 
      release, I picked it up, and found it was far enough along and sufficiently easy to 
      get in to that I could get a first cut integrated in time for this month's release. 
      Since the release, along with diakopter++, I've been hacking away at regexy bits, so 
      there'll be many improvements in this area in next month's release. It was nice to 
      get something in place for this month's, though.

(略)

And, of course, the usual round of feature addition, bug fixing and performance work.

protoregexes ってなにー。

■_

あとで読む。 泳ぐやる夫シアター やる夫で学ぶ第一次世界大戦  第二十三夜「カポレット突破戦」

■_

■_

PCRE 結構知らない機能が増えてた。


一つ前へ 2011年11月(中旬)
一つ後へ 2011年9月(上旬)

ホームへ


リンクはご自由にどうぞ

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