ときどきの雑記帖 2012


一つ前へ 2012年8月(上旬)
一つ後へ 2012年8月(下旬)




Access も便利なんだか使えねーんだか。


Zed のおことば

Learn Code The Hard Way -- Books And Courses To Learn To Code

Can't Code? Learn Design

This was originally a comment on a blog post but I thought it'd be a good blog post here too. That
other blog post basically is lamenting the fact that it's difficult to learn programming ending
with the question, "I want to learn to code. But what if I'm not built to be a coder? Guys,
am I missing the point here?"

Dear Crranky,

I feel for you. I'm currently trying to learn to sing because I want to sing songs I want to
write. I could go find a singer, but I have a particular vision in my head for what I want to
say and how I want to say it. So, I'm going to learn to sing and I spend every day doing about
an hour of singing practice if I can. It's fun to keep trying, and I do see improvements in many
other things in my life. If it's important to you then spending at least 2 hours every day on
learning to code is a minimum effort requirement.


So, if you can't get through programming courses, then try your hand at design.

Copyright 2011 Zed A. Shaw. All Rights Reserved. Powered By Software He Wrote.


Zed のおことばその2

Learn Code The Hard Way -- Books And Courses To Learn To Code

Programming Languages Have Social Mores Not Idioms

I'm currently editing my Learn Ruby The Hard Way book and cleaning some things up here and there.
In the process I've stumbled on what Rubyists call an "idiom", the use of .each to do
loops instead of a for-loop. To them this is one of the most important signs that you are a real
Ruby programmer. They look at this usage of one looping construct over another as some sign that
you are incompetent, and haven't been properly indoctrinated into the Ruby community's ways. It's
not just Ruby. Python, Java, every language has these weird "idioms" that denote your
acceptance of their community standards. I'm just using Ruby's .each since it seems to be one of
the most arbitrary yet vehemently demanded code constructs out there.

However, these are not idioms. An idiom is some little catch phrase that has meaning really only to
people who grew up using it, and for everyone else it's some weird statement. An example is,
"the whole ball of wax" to mean "the whole thing". Another is, "piece of cake"
to mean "something really easy to do". These idioms are also not language dependent, but
actually locality and culturally dependent. I could move to England, the home of English, and they'd
use many new and different idioms.

Copyright 2011 Zed A. Shaw. All Rights Reserved. Powered By Software He Wrote.

Learn Ruby The Hard Way now for sale in PDF and ePub format for $2.99 だそうな。

■_ advice

"The Best Programming Advice I Ever Got" with Rob Pike | | InformIT


A year or two after I'd joined the Labs, I was pair programming with Ken Thompson on an on-the-fly
compiler for a little interactive graphics language designed by Gerard Holzmann. I was the faster
typist, so I was at the keyboard and Ken was standing behind me as we programmed. We were working
fast, and things broke, often visibly—it was a graphics language, after all. When something went
wrong, I'd reflexively start to dig in to the problem, examining stack traces, sticking in print
statements, invoking a debugger, and so on. But Ken would just stand and think, ignoring me and the
code we'd just written. After a while I noticed a pattern: Ken would often understand the problem
before I would, and would suddenly announce, "I know what's wrong." He was usually correct.
I realized that Ken was building a mental model of the code and when something broke it was an error
in the model. By thinking about *how* that problem could happen, he'd intuit where the model was
wrong or where our code must not be satisfying the model.

Ken はしばしばわたしが理解するより先に問題を理解し、とつぜん "I know what's wrong."
わたしは Ken がコードのメンタルモデルを構築していて

Ken taught me that thinking before debugging is extremely important. If you dive into the bug, you
tend to fix the local issue in the code, but if you think about the bug first, how the bug came to
be, you often find and correct a higher-level problem in the code that will improve the design and
prevent further bugs.

Ken はわたしにデバッグの前に考えることは非常に重要なことであると教えてくれました。
もしあなたがバグを詳細に調べようとしたならばコードにある local issue を fix する
設計を改良しさらなるなバグを防止するであろう higher-level problem in the code を
見つけ出し correct することが頻繁になるでしょう。

I recognize this is largely a matter of style. Some people insist on line-by-line tool-driven
debugging for everything. But I now believe that thinking—without looking at the code—is the best
debugging tool of all, because it leads to better software.

わたしはこれが largely a matter of style であると認識しています。
一部の人は line-by-line な tool-driven なデバッグに固執しています。

© 2012 Pearson Education, Informit. All rights reserved.





この本、Amazonで予約しててちょっと前に発売が延期されたとか お知らせメールが来てたんだけど、 ふと気になってオライリーのページを見たら TopCoder Cookbook - O'Reilly Media This product has been canceled. ってなにこれ。

これもかなあ。amazon.com と amazon.co.jp からなくなってる。 Ceron.jp - Amazon.co.jp: Naked Code: The Ultimate Guide to Programming in Any Language: Eldad Eilam: 洋書






Software Design 2012年9月号|gihyo.jp … 技術評論社 第一特集が C のポインターて。いや、読んでみたら結構面白かったけど。 「ニートなphaのぶらぶら日記」 と 「Emacs 64bit化計画!」 もなかなか。後者の malloc (に限ったことではないのだけど)の話は知らなかったー。

Zed の今日のお言葉→ Learn Code The Hard Way -- Books And Courses To Learn To Code

一時間近いんだよなー。面白そうではあるんだけど How GitHub Works

■_ 学研のおばちゃんまだかなー♪



Software Design の9月号に(C の)ポインターの特集記事があったので

The 5-minute Guide to C Pointers

The 5-minute Guide to C Pointers
August 16, 2012 By Dennis Kubes

What is a pointer? What is a memory address? What does dereferencing a pointer mean?

ポインターとはなんでしょうか? メモリーアドレスとは?
ポインターの dereferencing とはどういう意味なのでしょうか?

A pointer is a variable that holds the location of, literally the address-of, a variable stored in
computer memory. An address is the actual address-of a variable in the computer memory.
Dereferencing a pointer means getting the value stored in the memory at the address which the
pointer “points” to.

ポインターとは、コンピューターのメモリーに格納されている変数の位置や literally なアドレス
を保持する変数です。アドレスとはコンピューターのメモリーにおける変数の actual address です。
ポインターの dereferencing とはポインターが“指し示している”アドレスにあるメモリーに

The * is the value-at-address operator, also called the indirection operator. It is used both when
declaring a pointer and when dereferencing a pointer. I will show why it is helpful to read it as
the value-at-address operator in the code below. When we talk about getting the value-at-addess of
the pointer we are talking about getting the value stored in the memory at the address which the
pointer “points” to.

* は value-at-address 演算子で、indirection 演算子とも呼ばれています。
これはポインターの宣言をするときとポインターの dereferencing をするときの

The & is the address-of operator and is used to reference the memory address of a variable.
When we declare a variable, three things happen. One, computer memory is set aside for the
variable. Two, The variable name is linked to that location in memory. And three, the value of the
variable is placed into the memory that was set aside. By using the & operator in front of a
variable name we can retrieve the memory address-of that variable. It is best to read this operator
as address-of and we will show why below.

& は address-of 演算子であり、変数のメモリーアドレスを参照するのに使われます。
& 演算子を変数名の前で使うことによってその変数の置かれているアドレス位置が取得できます。

Take the following code which shows some common notations for the value-at-address (*) and
adress-of (&) operators.

	// declare an variable ptr which holds the value-at-address of an int type
	int *ptr;
	// declare assign an int the literal value of 1
	int val = 1;
	// assign to ptr the address-of the val variable
	ptr = &val;
	// dereference and get the value-at-address stored in ptr
	int deref = *ptr;
	printf("%d\n", deref);



Hope this brief overview helps with some of the different types of pointers you will see. In a
later post I might go into another type of advanced pointer that is used, the function pointer.

Questions and comments are always welcome.

Update 1: Thanks to phao, mauchter and jorgem from hacker news for improvement suggestions. Made
some changes to make some explanations more clear.

Update 2: Fixed spelling errors. Fixed unclear wording. Tried to make NULL pointer explanations
more clear. Thanks to everybody for the comments and suggestions.

Update 3: Added a pointers to pointers section. Made descriptions of operators more clear.

Update 4: Thanks to JoachimS and Dinah for catching more spelling errors. I need to take a class
in proofreading. Thanks to Radu for helping to clarify the value-at-address operator.

Copyright © 2012 · Dennis Kubes, All Rights Reserved

Basics of Memory Addresses in C






とある書店で、ハヤカワのSF文庫にシュリンクラップかけているのに気がついて ここまで来たかとびっくりしたのだけど、 よく見ると最初に目に入ったタイトル以外は従来通りだった。 なんだったんだろうかあれ。

数学ガール ガロア理論 (数学ガールシリーズ 5)
数学ガール ガロア理論 (数学ガールシリーズ 5)
感想的ななにか。 実はひとつ前の巻の「乱択アルゴリズム」をまだ読んでいません (買っていはいる)が、それはおいといて。

この本を読み終えてみて改めて気になることがありました。 それは、このシリーズが小説の形をとった数学の本なのか、それとも数学を題材にした小説なのか。 ということです。 今回の取り上げられた群論やガロアについてはわたし自身 ちょっとした思い入れがあります(たいしたことではないので詳細は書きません)。 そういうこともあってとても楽しみだったのですが、 どうにも読後感にすっきりしたものがないのです。

そのほかにも「あれ、ミルカさんてこんな人だったっけ」と思うような描写もあったりしました。 それは「乱択アルゴリズム」を飛ばしたからかもしれないし、 わたしの勝手な思い込みによるものかもしれません。 アミダくじから始まる導入部はとても面白く読めたのですが、 中盤辺りからだんだん読み進めるのが辛くなってきて最後のほうはかなりきつかったです。 まあこれは数学の部分を理解しようとするのに苦戦したというところが大きいのでしょうけども。

巷間見かける書評なのではベタ褒めしてるものばかりがあるようで こういうこと書くのちと怖いのですけどね。

放課後のカリスマ 8 (IKKI COMIX) 放課後のかりちゅま (IKKI COMIX) メイプルさんの紅茶時間 2 (マッグガーデンコミックス EDENシリーズ) キャラソンCD付き夜桜四重奏~ヨザクラカルテット~(12)限定版 (シリウスコミックス) さよなら絶望先生(30)<完> (講談社コミックス)

なんだこれ → 21st Century C - O'Reilly Media


Excel で結合セルを駆使して作られているデータベースもどきがありまして。 それはいくらなんでも(ぴー)なので、(とりあえず) Access でデータベース作って… という流れにしようとしているのですがひとつひっかかっていることが。

たとえば機械の管理をするとします。 管理したい情報としては型番であるとか、購入時期、購入金額といったものです。 機械によってはオプションがついているものがあって、それは複数の場合があります (というかひとつのほうがまれ)。 んで、機械に一意に振っている管理番号が従来からあるので これを主キーとして 型番等をフィールドとして持ったデータベースと、 オプションをフィールドとしてもったデータベースを作りました。

で、一台一台の情報を表示するときには これら二つのデータベースをごにょごにょして…と思ったのですが、 オプションが複数あるというのがネックになって クエリがうまく書けないという。 オプションにあたるものに売り上げ金額みたいな数値が入っていて それの合計を求めるといったクエリなら例は結構見つかるんですが、 たとえば複数のオプションを一つ一つの名前がカンマで区切られた ひとつの文字列にしたいのですがこれがだめ。 聞いたところでは SQL の範囲ではできないっぽいですねえ… ということでどうしたものやら。




スライド http://research.microsoft.com/en-us/projects/koka/2012-overviewkoka.pdf を見たけどなにかこうピンとこない (見覚えのあるスタイルの式やらでてくるんだけど)

Koka a function oriented language with effect inference | Lambda the Ultimate

Koka a function oriented language with effect inference

    Koka is a function-oriented programming language that seperates pure values from side-effecting
    computations, where the effect of every function is automatically inferred. Koka has many
    features that help programmers to easily change their data types and code organization
    correctly, while having a small language core with a familiar JavaScript like syntax.

    Koka は関数指向のプログラミング言語で、
    純粋な値を (すべての関数が自動的に infer される effect である)
    side-effecting comptaions から切り離しています。
    Koka はプログラマーがデータ型や code orgranization を正しく容易に変更するのを
    慣れ親しんだ JavaScript に似た構文の小さなものとなっています。

Koka extends the idea of using row polymorphism to encode an effect system and the relations
between them. Daan Leijen is the primary researcher behind it and his research was featured
previously on LtU, mainly on row polymorphism in the Morrow Language.

So far there's no paper available on the language design, just the slides from a Lang.Next talk
(which doesn't seem to have video available at Channel 9), but it's in the program for HOPE 2012.





Diego Novillo - Merge C++ conversion into trunk (0/6 - Overview) GCC でコンパイラーをビルドするのに C++ を必須にするという話題でどこも大賑わいっぽく。 Hacker News。

GCC switches from C to C++ | Hacker News

>>we'd have to get used to using auto_ptr

>auto_ptr is broken. We should use shared_ptr instead

It has begun!

One of the most enjoyable features of C++ is the arguing over which parts of the language should
be allowed.

Just to be clear, the replacement for auto_ptr is unique_ptr, not shared_ptr.

The vast majority of allocated objects have unique ownership semantics, not shared. If you use
shared_ptr everywhere, it's far too easy for your design to degenerate into object soup.

Here's the rationale from that document:

* C++ is a standardized, well known, popular language.

* C++ is nearly a superset of C90 used in GCC.

* The C subset of C++ is just as efficient as C.

* C++ supports cleaner code in several significant cases.

* C++ makes it easier to write and enforce cleaner interfaces.

* C++ never requires uglier code.

* C++ is not a panacea but it is an improvement.

It's interesting to me how defensive many of those justifications are. "It's just as efficient!"
or "It's just a superset anyway!" Not until halfway through the list do we get any real
description of expected benefits: C++ makes it easier to write and enforce interfaces, and C++
supports cleaner code in several significant cases. The last item is the most telling though:
it's clear that these developers feel they've hit a point of crisis, and they are willing to take
risks like this in order to lift themselves out of the problem.

> * C++ never requires uglier code.

No... but it sure tends to encourage it.


reddit の方

GCC will now need C++ to build : programming

GCC will now need C++ to build (gcc.gnu.org)

This isn't a surprise announcement; development has been heading that way for a while. And as
complex as the C standard has become, it's a necessary thing to deal with that complexity.

Still, there's a part of me that still admires the elegance of a c-based, c-compiler like pcc.
Yes, I know pcc is basically dead and isn't feature complete. I'm just getting wistful for a
time of a simpler C compiler... a time that clearly doesn't exist any more.

Actually, Go ships with a simpler C compiler, which should be installed as [568]c. The source is
here: http://code.google.com/p/go/source/browse/src/cmd/6c/ and here http://code.google.com/p/go/source/browse/src/cmd/cc/

Everyone about to say that they should rewrite GCC using GHC, please queue up here.

スラド → GCC Switches From C to C++ - Slashdot

なんか否定的な意見が多いっぽいらしいのですが、 うまくいってもなにか引っかかって問題が出てもそれはそれでいいんじゃないですかねー と無責任なことを言ってみる。


■_ dot file

ファイル名の先頭が . なファイルの扱いの起源のはなし。

Rob Pike on the origin of dotfiles : programming
Rob Pike - Google+ - A lesson in shortcuts. Long ago, as the design of the Unix…

Rob Pike
Aug 3, 2012  -  Public

A lesson in shortcuts.

Long ago, as the design of the Unix file system was being worked out, the entries . and ..
appeared, to make navigation easier. I'm not sure but I believe .. went in during the Version 2
rewrite, when the file system became hierarchical (it had a very different structure early on).
When one typed ls, however, these files appeared, so either Ken or Dennis added a simple test to
the program. It was in assembler then, but the code in question was equivalent to something like

遙か昔、Unixのファイルシステムの設計において navigation を容易にするために . と .. というエントリ
が作られました。詳しくは覚えていないのですが、.. は Version 2 の rewrite 中にファイルシステムが
(それまでとは非常に異なる構造の) 階層的なものになったときに入ったと思います。ところが ls を実行
したときにこれらのファイルも表示されてしまうので、Ken か Dennis のどちらかがプログラムに簡単なテ

   if (name[0] == '.') continue;

This statement was a little shorter than what it should have been, which is


   if (strcmp(name, ".") == 0 || strcmp(name, "..") == 0) continue;

but hey, it was easy.

Two things resulted.

First, a bad precedent was set. A lot of other lazy programmers introduced bugs by making the
same simplification. Actual files beginning with periods are often skipped when they should be

第一に、悪い先例 (bad precedent) を残してしまったということです。
他の、非常に多くの怠惰なプログラマー (lazy programmer) たちが

Second, and much worse, the idea of a "hidden" or "dot" file was created. As
a consequence, more lazy programmers started dropping files into everyone's home directory. I
don't have all that much stuff installed on the machine I'm using to type this, but my home
directory has about a hundred dot files and I don't even know what most of them are or whether
they're still needed. Every file name evaluation that goes through my home directory is slowed
down by this accumulated sludge.

I don't have all that much stuff installed on the machine I'm using to type this,
しかしわたしのホームディレクトリは 100個近くのドットファイルがあって
その accumulated sludge が原因でスローダウンしていました。

I'm pretty sure the concept of a hidden file was an unintended consequence. It was certainly a

隠しファイルのコンセプトは unintended consequence (意図しなかった結末) であったと

How many bugs and wasted CPU cycles and instances of human frustration (not to mention bad design)
have resulted from that one small shortcut about 40 years ago?

おおよそ40年ほど前のたった一つのちょっとした shortcut が原因で、
どれほどのバグが産み出され、CPU サイクルが浪費され、
instances of human frustration が生じたのでしょうか?

Keep that in mind next time you want to cut a corner in your code.

(For those who object that dot files serve a purpose, I don't dispute that but counter 
that it's the files that serve the purpose, not the convention for their names. They 
could just as easily be in $HOME/cfg or $HOME/lib, which is what we did in Plan 9, 
which had no dot files. Lessons can be learned.)

©2012 Google - Terms - Map data © 2012




LLVM 本のはなし。 卜部さん会長に話を出してたんでしょうね。さすがだ。 C82:報告と感謝と謝罪とお願いと今後について - 餅ちゃんの備忘録 特に達人出版会さんについてはお待ちしていますとの言伝までいただいてあわわわ状態 んで 今回の本には説明が不十分な点や,曖昧な情報が含まれており,増刷や電子書籍は少なくともこういった点を取り除いてからと考えています. 特に,誤った情報が含まれているかもしれないという点を危惧しており,もう少し時間を貰いたいというのが今の心境です. とりあえずC83の申し込み手続きは進めているので,冬に加筆修正版を頒布する予定ではいます. その他の方向性についてもある程度目処が立った段階で報告しようと思っています. だそうです。

ややこしいルールのはなし。 【甲子園】済々黌vs鳴門でドカベンの『ルールブックの盲点の1点』が再現される : なんJ(まとめては)いかんのか? の話。コメントに わけのわからんルールばっかりで直すの面倒だし批判されそうだからそのままなんだろうね 日本はこんな国だよね というのがあるのを見つけたときはなんとも複雑な気分になった。

へー。 株式会社VOYAGE GROUP - VOYAGE GROUP、インターネット領域での勉強会やイベント向けに、無料シェア会議室「PORT」を開始


■_ Hate Java?


Hate Java? Maybe you should hate the industries stuck in the 50's. : programming

Hate Java? Maybe you should hate the industries stuck in the 50's. (blog.jelastic.com)

    Java doesn't suck that bad

    In fact it got a lot of things right

    COBOL sucks more right?

    You should be outraged at how many businesses are writing new code in COBOL; forget your Java hatred

    By the way if you're looking for "Rock-solid Java in the Cloud"... (You stopped
    hating Java, right?)

I agree that Java doesn't suck, but I don't like his argument that Java doesn't suck because
other legacy systems are even worse. In a way he admits that he thinks Java is a bad language.

The best way to not make Java suck is to stop over engineering.

Java isn't bad. It's the Java developer mentality. I've never found a web framework that is fun
to use.

So yeah if you want to do some hardcore stuff on the back-end that's fine but for developing a
front-end, it's sucks ass for the most part.

Java sucks relative to a very familiar yet more evolved language like C#. Anyone who's become
accustomed to C# wants nothing to do with Java.

I disagree because I don't want to be locked into Windows and despite C#'s advances they're still
close enough it doesn't matter if c# has some niceties when it's still primarily a windows

I dislike ("hate") Java but:

    1. It's popular to hate Java.

Well... That's not a reason.

    2. C-like syntax is no longer popular.

Not my reason. Nothing wrong with C-like syntax.

    3. Hate for Oracle is being leveraged to promote individual interests.

I actually like Oracle's database, as a technological product. PL/SQL is quite nice. I like Java
a lot less.

    4. People have been exposed to really bad code, that's been written in Java.

If so, I haven't seen it.

    5. … insert next hundred reasons here.

    Java is slow to start up.
    Java is heavy-weight. I've seen programs that complain about memory problems with 1GB at their disposal.
    Java is ugly and verbose, at least old-school Java. Anonymous classes to handle events for a button? Yuck!
    Etc. Too much to list them all. Besides I've got better things to do with my time than think about reasons why I don't like X.

必要以上に嫌われてるような気もするけど 自分もそんなにどっぷり浸かってるわけではないのでよくわからん。



Hate Java? « Jelastic — Rock-Solid Java in the Cloud, Java Server Hosting, Java Cloud Computing

Hate Java? You're fighting the wrong battle.

One of the most interesting trends I've seen lately is the unpopularity of Java around blogs,
DZone and others. It seems some people are even offended, some even on a personal level, by s
uggesting the Java is superior in any way to their favorite web2.0 language.

Java has been widely successful for a number of reasons:
Java が広く成功した理由

    It's widely accepted in the established companies.
    established companies に広く受け入れられた
    It's one of the fastest languages.

    It's one of the most secure languages.

    Synchronization primitives are built into the language.

    It's platform independent.

    Hotspot is open source.

    Thousands of vendors exist for a multitude of Java products.

    Thousands of open source libraries exist for Java.
    Java 向けの多数のオープンソースライブラリがあった

    Community governance via that JCP (pre-Oracle).

This is quite a resume for any language, and it shows, as Java has enjoyed a long streak as being
one of the most popular languages around.

So, why suddenly, in late 2010 and 2011, is Java suddenly the hated demon it is?

    It's popular to hate Java.
    C-like syntax is no longer popular.
    Hate for Oracle is being leveraged to promote individual interests.
    People have been exposed to really bad code, that's been written in Java.
    … insert next hundred reasons here.

Java, the actual language and API, does have quite a few real problems… too many to list here
(a mix of native and object types, an abundance of abandoned APIs, inconsistent use of checked
exceptions). But I'm offering an olive branch… Lets discuss the real problem and not throw
the baby out with the bath water.

So what is the real problem in the this industry?

■_ \s (と \S)

Emacs のそれは知ってたけど書いてなかったのよね (エディターだから)

正規表現 Part10

188 デフォルトの名無しさん [sage] 2012/08/15(水) 05:04:21.31 ID: Be:







189 デフォルトの名無しさん [sage] 2012/08/15(水) 07:43:45.93 ID: Be:
    もう emacs 使ってないので、はずしてるかもしれないけど



190 デフォルトの名無しさん [sage] 2012/08/15(水) 08:18:54.14 ID: Be:
    > >>188
    > もう emacs 使ってないので、はずしてるかもしれないけど
    > EmacsLispの正規表現「\s」は空白文字類じゃない。
    > http://d.hatena.ne.jp/holidays-l/20070602/p1
    > じゃないの?


しかしなぜ訊いた方も答えた方も Emacs のマニュアルにあたらないんだ(^^; 最新のでないにしても日本語になってるのがあるのに。

詳細は書かないにしても、\s (と \S) にちょっと書き足しておくか。


一か月以上池袋のジュンク堂に行ってないのだけど、 今行ったら緑のジュンク堂袋確定な気がする (ので行くに行けない)。




まとめて読んだ 泳ぐやる夫シアター AAで学ぶ南北戦争への道 第3回 帝国の逆襲 泳ぐやる夫シアター AAで学ぶ南北戦争への道 第4回 潮の変わり目 泳ぐやる夫シアター AAで学ぶ南北戦争への道 第五回 南部の死闘 泳ぐやる夫シアター AAで学ぶ南北戦争への道 第6回 勝利と危機

なんかコードレビューの話があちらこちらで コードレビューについて - Oh, you `re no (fun _ → more) はてなブックマーク - コードレビューについて - Oh, you `re no (fun _ → more)


NASA JPL C Coding Standard [pdf] | Hacker News に関連した話

Getting 2.5 Megalines of code to behave

Getting 2.5 Megalines of code to behave On Curiosity and its software

I cannot help but speculate on how the software on the Curiosity rover has been constructed. We
know that most of the code is written in C and that it comprises 2.5 Megalines of code,
roughly[1]. One may wonder why it is possible to write such a complex system and have it work.
This is the Erlang programmers view.

First some basics. The rover uses a radioactive power source which systematically delivers power
to it in a continuous fashion. The power source also provides some heating to the rover in general
- which is always nice given the extreme weather conditions present on Mars.


TL;DR - Some of the traits of the Curiosity Rovers software closely resembles the architecture of
Erlang. Are these traits basic for writing robust software?


[0] Wikipedia, the Curiosity rover page
[1] Havelund.pdf
[2] JPL coding standards.pdf
[3] Caltech 2010 Workshop on spacecraft flight software (Requires Silverlight :/)



というのを見て知ったのだけど しなの鉄道×なつまちラッピング列車とその反応(7月まで) - Togetter しなの鉄道×なつまちラッピング列車とその反応(8月以降) - Togetter 信毎おでかけガイド 信濃毎日新聞社


■_ Learning Perl 6

なんだこれ Learning Perl 6

■_ Cより高速Javaより安全*shより単純

anic - Faster than C, Safer than Java, Simpler than *sh - Google Project Hosting

anic - Faster than C, Safer than Java, Simpler than *sh - Google Project Hosting

anic is the reference implementation compiler for the experimental, high-performance, implicitly
parallel, deadlock-free general-purpose dataflow programming language ANI.

Portably written using the GNU toolchain, anic works on all of the popular operating systems,
including *nix, Mac OS X, and Windows (via Cygwin).




連続クイズ ホールドオン! : NHK を観てたら問題に「第六天魔王」が出てくるものがあって、 そのとき出題者がちゃんと「第六天」で一息入れて「魔王」と続けた読んだのでちょっと感心した。 天魔 - Wikipedia 第六天魔王・その1

ちょっと気になった本など (買ったわけではないのでアサマシリンクにするのはちと気が引けるけど :)
中継ぎ投手 ---荒れたマウンドのエースたち
中継ぎ投手 ---荒れたマウンドのエースたち

「中継ぎ投手」は元ベイスターズの五十嵐が入ってれば即買いだったのだけど…w とはいえ木田、河原、石井弘寿、福間、佐野(うーあと誰がいたっけなあ)とか 人選が渋くて良いなあ。いや中継ぎ投手を取りあげる時点で渋いか。 あとの二冊もちょっと読んだ限りでは面白そうだった。

買ってみた Functional Programming for… by Brian Marick [PDF/iPad/Kindle]


メモ http://archive.computerhistory.org/resources/text/Fortran/102653982.05.01.acc.pdf

Laning and Zierler system - Wikipedia, the free encyclopedia

The Laning and Zierler system (sometimes called "George" by its users) was one of the
first operating algebraic compilers, that is, a system capable of accepting mathematical formulae
in algebraic notation and producing equivalent machine code. It was implemented in 1954 for the
MIT WHIRLWIND by J. Halcombe Laning and Neal Zierler. It is preceded by the UNIVAC A-2, IBM
Speedcoding and a number of systems that were proposed but never implemented.
Sample Program

The following example, taken from page 11 of the system's manual, evaluates
cos x for x = 0, 0.1, ..., 1 using the Taylor series expansion. The implementation is not
terribly efficient, and the system already includes cos x in its subroutine library, but
the example serves to give a flavor of the system's syntax. Note that division in the system
is evaluated after multiplication:

 1 x = 0,
   z = 1 - x2/2 + x4/2·3·4 - x6/2·3·4·5·6
     + x8/2·3·4·5·6·7·8 - x10/2·3·4·5·6·7·8·9·10,
   PRINT x, z.
   e = x -  1.05,
   CP 1,



■_ コードの書きかえ

Is it OK to replace optimized code with readable code? | Ars Technica

Coder asks:

Sometimes you run into a situation where you have to extend/improve some existing code. You see
that the old code is very lean, but it's also difficult to extend, and takes time to read.

あなたにもあるでしょう。あなたはその古いコードが very lean なだけでなく、

Is it a good idea to replace it with modern code?
modern なコードで置き換えるということは良い考えなのでしょうか?

Some time ago I liked the lean approach, but now, it seems to me that it's better to sacrifice a
lot of optimizations in favor of higher abstractions, better interfaces, and more readable,
extendable code.

少し前にはわたしはこの lean approach が好きでしたが、現時点では
そのやり方は高度な抽象化やより良いインターフェース、より readable で extendable な

The compilers seem to be getting better as well, so things like struct abc = {} are silently
turned into memsets, shared_ptrs are pretty much producing the same code as raw pointer
twiddling, templates are working super good because they produce super lean code, and so on.

But still, sometimes you see stack based arrays and old C functions with some obscure logic, and
usually they are not on the critical path.

Is it a good idea to change such code if you have to touch a small piece of it either way?

See Also: "Clean readable code vs. fast hard-to-read code: When to cross the line?"

Answer: Depends... (91 Votes)

Code reviews are the development team's hallway testing: And I think the last part is key here:
do code reviews. You won't know the value of your improvements if you make them solo. Code
reviews are our "hallway testing:" follow Raymond's version of the Linus' Law both for
detecting bugs and detecting over-engineering and other anti-patterns, and to ensure that the
code is in line with your team's abilities. There's no point in having the "best" code
if nobody else but you can understand and maintain it, and that goes both for cryptic
optimizations and 6-layers deep architectural designs.

As closing words, remember:

    Everyone knows that debugging is twice as hard as writing a program in the first place. So if
    you're as clever as you can be when you write it, how will you ever debug it?

                                                                                 —Brian Kernighan

Think you know how best to prioritize readable vs. optimized code? Disagree with the opinions
expressed above? Downvote or upvote an answer, or leave your own answer at the original post at
Stack Exchange, a network of 80+ sites where you can trade expert knowledge on topics like web
apps, cycling, scientific skepticism, and (almost) everything in between.

■_ \zs \ze



Vimのニッチな正規表現で遊ぼう - Humanity

:help /\zs と :help /\ze



" 「bar」と表示
:echo matchstr('foobarbaz', 'bar')

のように、matchstr(対象文字列, パターン)といった風に使います。*3




:echo matchstr('foobarbaz', 'foo\zsbar\zebaz')


:echo matchstr('barbaz', 'foo\zsbar\zebaz')















print "match:$1" if "foobarbaz" =~ /foo(bar)baz/;












なるほどねえ。 記号類がごちゃごちゃあって読みづらい(理解しづらい)というのはわかるけど といって\zs \ze も(特に 's' と 'e' が)地の文字列に埋もれて目立たないんで ぱっと見把握しづらくないかなあ。

■_ コーディング規約

NASA JPL C Coding Standard [pdf] | Hacker News ものはこれ → http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf


LOC-1: Language Compliance

Rule 1 (language)
All C code shall conform to the ISO/IEC 9899-1999(E) standard for the C programming language,
with no reliance on undefined or unspecified behavior. [MISRA-C:2004 Rule 1.1, 1.2]

Rule 2 (routine checking)
All code shall always be compiled with all compiler warnings enabled at the highest warning level
available, with no errors or warnings resulting. All code shall further be verified with a JPL
approved state-of-the-art static source code analyzer, with no errors or warnings resulting.
[MISRA-C:2004 Rule 21.1]

LOC-2: Predictable Execution

Rule 3 (loop bounds)
All loops shall have a statically determinable upper-bound on the maximum number of loop iterations.

Rule 4 (recursion)
There shall be no direct or indirect use of recursive function calls. [MISRA-C:2004 Rule 16.2; Power of Ten Rule 1]

Rule 5 (heap memory)
There shall be no use of dynamic memory allocation after task initialization. [MISRA-C:2004 Rule 20.4; Power of Ten Rule 3]

Rule 6 (inter-process communication)
An IPC mechanism should be used for all task communication. Callbacks should be avoided. No task
should directly execute code or access data that belongs to a different task. All IPC messages
shall be received at a single point in a task.

Rule 7 (thread safety)
Task synchronization shall not be performed through the use of task delays.

Rule 8 (access to shared data)
Data objects in shared memory should have a single owning task. Only the owner of a data object
should be able to modify the object.

Rule 9 (semaphores and locking)
The use of semaphores or locks to access shared data should be avoided (cf. Rules 6 and 8). If
used, nested use of semaphores or locks should be avoided.

Rule 10 (memory protection)
Where available, i.e., when supported by the operating system, memory protection shall be used
to the maximum extent possible.

Rule 11 (simple control flow)
The goto statement shall not be used. There shall be no calls to the functions setjmp or longjmp.
[MISRA-C:2004, Rule 14.4, Power of Ten Rule 1]

Rule 12 (enum Initialization)
In an enumerator list, the "=" construct shall not be used to explicitly initialize members other
than the first, unless all items are explicitly initialized. [MISRA-C:2004, Rule 9.3]
LOC-3: Defensive Coding
Rule 13 (limited scope)
Data objects shall be declared at the smallest possible level of scope. No declaration in an
inner scope shall hide a declaration in an outer scope. [MISRA-C:2004 Rule 8.7, 8.10; Power of Ten Rule 6]

Rule 14 (checking return values)
The return value of non-void functions shall be checked or used by each calling function, or
explicitly cast to (void) if irrelevant. [MISRA-C:2004 Rule 16.10; Power of Ten Rule 7]

Rule 15 (checking parameter values)
The validity of function parameters shall be checked at the start of each public function.6 The
validity of function parameters to other functions shall be checked by either the function called
or by the calling function. [MISRA-C:2004 Rule 20.3; Power of Ten Rule 7]

Rule 16 (use of assertions)
Assertions shall be used to perform basic sanity checks throughout the code. All functions of
more than 10 lines should have at least one assertion. [Power of Ten Rule 5]

Rule 17 (types)
Typedefs that indicate size and signedness should be used in place of the basic types. [MISRA-C:2004 Rule 6.3]

Rule 18
In compound expressions with multiple sub-expressions the intended order of evaluation shall be
made explicit with parentheses. [cf. MISRA-C:2004 Rule 12.2]

Rule 19
The evaluation of a Boolean expression shall have no side effects. [MISRA-C:2004 Rule 13.1]

LOC-4: Code Clarity

Rule 20 (preprocessor use)
Use of the C preprocessor shall be limited to file inclusion and simple macros. [Power of Ten Rule 8]

Rule 21 (preprocessor use)
Macros shall not be #define'd within a function or a block. [MISRA-C:2004 Rule 19.5]

Rule 22 (preprocessor use)
#undef shall not be used. [MISRA-C:2004 Rule 19.6]

Rule 23 (preprocessor use)
All #else, #elif and #endif preprocessor directives shall reside in the same file as the #if
or #ifdef directive to which they are related. [MISRA-C:2004 Rule 19.17]

Rule 24
There should be no more than one statement or variable declaration per line. A single exception
is the C for-loop, where the three controlling expressions (initialization, loop bound, and
increment) can be placed on a single line.

Rule 25
Functions should be no longer than 60 lines of text and define no more than 6 parameters. [Power of Ten Rule 4]

Rule 26
The declaration of an object should contain no more than two levels of indirection. [MISRA-C:2004 Rule 17.5]

Rule 27
Statements should contain no more than two levels of dereferencing per object. [Power of Ten Rule 9]

Rule 28
Pointer dereference operations should not be hidden in macro definitions or inside typedef

Rule 29
Non-constant pointers to functions should not be used.

Rule 30 (type conversion)
Conversions shall not be performed between a pointer to a function and any type other than an
integral type. [MISRA-C:2004 Rule 11.1]







東館に入った直後に強い雨。というナイスなタイミング。 パラパラ来てるときはまだ外だったのですが。 企業ブースも行ってみたのですが、Googleのところで 45分待ちとか案内が出てたので早々に退散しましたとさ。

どういったものがでてたりするんだろうという人は この辺を参考にどうぞ UNIXユーザーのためのコミケット82情報ページ






行ってきました。 アレのためいつもより一時間以上出発時間を繰り上げました。 で、現地ではこんな状態でした。

ビッグサイトは右手奥ビルの向こうにあります。 9:30 くらいから列が動き出し、会場に入ったのが 10:30くらいだったかなあ (覚えてない) とはいえ

完売のツイートが11時ちょい過ぎだったのでちょっと危うかった感じ (ブースにたどり着いた時点では20はなかったかな?)。 しかし10:17になくなりそうツイートがでるとは、まあ エンジニア双六のときもそうだったけどサークル入場した人付近に配置されていたサークルの人たち(つまりはそういうネタが大好きな人たち)で捌けたんでしょうねえ。


わりと雲が出ていて去年よりも楽っちゃ楽だったんですが 開場までの待ち時間「それをお金で買いますか」の内容を思い出していたり。

■_ 達人出版会

自分も話を出してみようかとも思ったんですが、 達人出版会で出すときの具体的な手順(やらハードルになりそうなこと)を よく知らなかったこともあったし話し込む余裕もないので結局やらず。 先に高橋会長に訊いとくべきだったかしらん。


"The Best Programming Advice I Ever Got" with Russ Olsen | | InformIT http://www.informit.com/articles/article.aspx?p=1926692 Clojure is not Software Conservative http://blog.n01se.net/Clojure-is-not-Software-Conservative.html Codec Confusion in Python | Armin Ronacher's Thoughts and Writings http://lucumr.pocoo.org/2012/8/11/codec-confusion/




一つ前へ 2012年8月(上旬)
一つ後へ 2012年8月(下旬)



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