ときどきの雑記帖 めぐりあい電脳空間編

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

一つ前へ 2010年7月(中旬)
一つ後へ 2010年8月(上旬)

ホームへ

2010年07月31日

■_

LL Tiger 行ってきました。速報はこのあと! (みねこあさんはスルーだったのかな)

unixコマンド0 true C 0以外 true

■_


LL Tiger » タイムスケジュール
タイムスケジュール

10:00       開場
10:25-10:30 開会宣言
10:30-11:50 Language Update
11:50-12:00 休憩
12:00-13:00 開発ライセンスとプログラマーの自由
13:00-14:30 昼休み
14:30-15:30 LTの虎・1回戦
15:30-16:30 LLと電子出版
16:30-17:00 夕休み
17:00-18:00 LLでフィジカルコンピューティング
18:00-18:30 LTの虎・準決勝
18:30-18:40 休憩
18:40-19:40 高速化虎の巻
19:40-20:00 LTの虎・決勝
20:00-20:10 抽選会+閉会宣言

わたしの TL 上でも同様の意見が多かったのですが、ここ数年(つーと幅があるな)で 一番面白かったのではないかという感じがしました。 ただまあ、

sodiumイオンにっき(2010-07-31)
ライセンスの話はGPL対BSDの不毛な戦いとかやるのかと思ったら全然違ったよ、とか。

わたしもこっち方面のライセンスと自由の話かと思っていました。 あれはあれで面白かったですが。

順番が前後しますが、Language Update。人数が多いせいもあるんでしょうが 時間押しすぎ。結局質問時間も省略されちゃいましたよね。 実際に機会があったとしてどの程度質問が出るかは疑問ですが、 にしたって「あとで発表者をつかまえて」はちと。 あらかじめリハーサルして、時間の見当つけるとはかできないのでしょうか。 LT みたいに強制終了は無粋でしょうし。

■_

プロジェクトの見積もり (Estimates) が失敗する十の理由


10 Reasons Why Software Project Estimates Fail

Think about the web and software projects you've completed. How many were delivered on 
time and on budget? How many estimates were accurate? IT projects are notorious for 
over-running, and here are several reasons why it occurs…

1. The project is poorly scoped
# 見通しが甘いってこと?

How can you estimate time on a project when you don't know what that project is? It's 
rare to find a client who appreciates exactly how their system should work.

Almost every large project I've undertaken has requested “flexibility”. In other 
words, the client wants the system to handle anything they want at any future point in 
time — even though they have no idea what those features might be. Flexibility is not 
a requirement!

2. Development time is estimated by non-programmers
   プログラマーでない人間が開発時間を見積もっている

If you're not a programmer, don't guess at development times. A project is doomed the 
moment a manager writes their own fictional estimate. At best, they'll be completely 
incorrect. At worst, the programmers will be tempted to prove them wrong.

もしあなたがプログラマーでないのなら、開発に要する時間を推測してはいけません。
プロジェクトとはマネージャの書いたでっちあげの見積もりによって運命づけられているのです(?)
良くてもその見積もりは完全に間違ったものであり、悪ければプログラマーたちは
それを間違って受け取ってしまいます。


3. Developer estimates are too optimistic
   開発者の見積もりが楽観的に過ぎる

Developers think in terms of coding hours. Time passes quickly when you're in the zone 
and it's difficult to assess your own speed. Appreciating the speed of other 
developers is impossible.

Many developers are over-optimistic. They tend to forget the softer side of the 
development process, such as project management, collating requirements, discussions 
with colleagues, absences, PC problems, etc.

多くの開発者は楽観的過ぎます。彼らはプロジェクトマネージメントや collating requirements,
同僚とのディスカッション、休暇、PCの問題などといった開発プロセスの softer side を
忘れてしまいがちです。

4. The project is not adequately dissected
  そのプロジェクトは dissected (解析) が不足している

Be wary if the development estimate for an individual feature exceeds a week. That 
chunk should be sub-divided further so the developer can analyze a complex problem in 
more detail.

5. Estimated time is used
   使われてしまっている見積もり時間

Give a programmer 5 days to complete a task and it'll take 5 days. Software 
development is infinitely variable and any code can be improved. If a developer takes 
3 days to finish the task, they'll spend the remaining time tweaking it or doing other 
activities.

プログラマーに、完了するのに5日かかる仕事を与えると、それには5日かかります。
ソフトウェア開発とはいくらでも改良できる無数の変数とコードなのです。
もし完了するのに三日かかるタスクを開発者が行ったなら、彼らは残った時間
(remaining time) をコードを tweaking したり doing other activities のために
費やすでしょう。

Unfortunately, this results in a situation where estimates become the minimum number 
of development days. The actual delivery time can only get worse.

6. More developers != quicker development
   より多くの開発者を投入しても開発を促進しない

A 100-day project will not be completed in 1 day by 100 developers. More people 
results in an exponential increase in complexity. See Why Larger Teams Do Not Result 
in Faster Development…

7. The project scope changes
   プロジェクトの scope の変更

This is perhaps the most irritating problem for a developer. A feature is changed or 
added because customer X has requested it or the CEO thinks it's a cool thing to do.

これはおそらく、開発者を最もいらだたせるものです。
顧客 X がそれをリクエストしたか、CEO が行うべきクールなことだと考えて
機能が変更されたり追加されたりします。

Is the impact of that new feature documented?…

8. Estimates are fixed
   見積もりが固定されている

Estimates should be continually assessed and updated as the system development 
progresses. Programmers often believe they can make up lost time — it rarely happens.

9. Testing time is forgotten
   テストの時間を忘れている

It's impossible for a developer to adequately test their own code. They know how it 
should work, so they consciously or sub-consciously test in a specific way. In general, 
you can expect to spend another 50% of the development time on testing and debugging.

10. Estimates are taken too literally
    見積もりを字面どおりに受け取りすぎ

Non-programmers rarely appreciate the complexity of software development yet few 
businesses plan for schedule slippages. The project often sits at the bottom of a huge 
unstable tower of other activities, such as literature printing, marketing, 
distribution, etc.

Development hold-ups can cause a costly chain reaction of delays. Unfortunately, it 
becomes easy to blame the programmer at the bottom of the pile. That's doesn't bode 
well for future projects — the programmer will either refuse to provide estimates or 
inflate them dramatically.

Have you encountered other reasons why project estimates fail?

■_
  It's JHC's turn « Mostly Code
http://mostlycode.wordpress.com/2010/07/28/its-jhcs-turn/

  [jhc] ANNOUNCE: jhc-0.7.6
http://www.haskell.org/pipermail/jhc/2010-July/000775.html
  

■_ そんな都合の良いものが

あってたまるかw

入門者向けのプログラミング言語と解説書 - Yahoo!知恵袋

入門者向けのプログラミング言語と解説書

プログラミングに関心がありますが、どこから手をつければいいか全くわかりません。入門者に
向いているプログラミング言語と、その解説書の中でおすすめがあったら教えてください。飽き
っぽくてちょっとつまずくとすぐ投げ出してしまうので、バカも分かるように書いてある方がい
いです。

無理してやるこたないと思うよ? 飽きるかどうかはともかくとして、躓きの種は山ほどあるから。

■_


当たりは遠かった…
電子出版の明日はどっちだ? TOTOとかOMRONは以下略 並列重要 LTの虎決勝

■_ 本日の巡回から

2010年07月30日

■_

いや、ほんとまとめる時間がないというか。

・今月の皇帝陛下
ひさびさに陛下の見せ所が。

・ダブルフェイス
新刊。

・Rakudo *
ビルドするのって、前と同じでいろいろ必要なのかしらん。 GHCとか gmp とか ICU とか。

Welcome Rakudo Star - Perl.com

Set aside your assumptions. Try Perl 6 yourself with Rakudo Star. Perl in every form 
is the work of a community willing to make amazing things happen. That task 
continues—help us make Perl more powerful, more flexible, more useful, and more fun.

■_ わけわからん

知恵袋で同様の質問を見たような覚えがあるのだけど、 いったい何が問題でどうしたいのか良くわからないと言う。

いや、OKWaveの別のカテゴリか?


perlのシングルクォートとダブルクォートの置き換えについて | OKWave

お世話になります。

現在、perlにて開発を行っているのですが、一つ問題に当たってしまいました。問題になってい
るのは、文字列を扱う部分です。perlにおいて文字列はシングルクォートに囲まれたものと、ダ
ブルクォートに囲まれたものがあると思うのですが、この両者の違いは、内部に書かれた変数等
を展開するか否かだったと思います。

実は開発の途中でこのシングルクォートで囲まれた文字列を、ダブルクォートに囲まれた文字列
に変更しなければいけなくなりました。つまり

$test = 'aaa';
 を 
$test = "aaa";

としたいのです。これってperlの仕様的に可能なのでしょうか? かなり悩んだのですが、どう
してもわかりませんでした。

ちなみに、なぜこの処理が必要なのかというと、HPの製作をしているのですが、設置したフォー
ムからその内容を得るというプログラムを書いた際に、そのフォームの内容がシングルクォート
でしか得られないからです。シングルだとそののちの処理に影響が出てしまうのです。

だれかご存じないでしょうか。よろしくおねがいします。


ANo.4


>先頭にある、$subject='<#001;絵文字入り題名<#002;';が問題になっている文字列で、
>れをデバッグで $subject="<#001;絵文字入り題名<#002;";にすると問題は
>決されます。
>だからシングルをダブルに置き換えたいのですが。。。駄目でしょうか。

???
引用符を「 " 」にすれば問題が起こらないんでしょ?
だったら「 " 」にすれば良いんじゃない?
なにを困っているのかが全く分かりません。

もしかしてプレフィクス($ や @ や %)を含まない値(展開する必要のないデータ)に「 
" 」を使用しても良いのか分からないよママンって事なのでしょうか?

そんなもんは試してみれば一発で分かる事で、悩むような事じゃないと思うのですが…

ANo.3

> これってperlの仕様的に可能なのでしょうか?

は、展開を除けば可能。
$とか@とかがあったら、\でクオートする必要あり

なのですが...

> ちなみに、なぜこの処理が必要なのかというと、HPの製作をしているのですが、設置した
>フォームからその内容を得るというプログラムを書いた際に、そのフォームの内容がシングルク
>ォートでしか得られないからです。シングルだとそののちの処理に影響が出てしまうのです

>変数展開はないのですが、フォーム内容をメールとして送信しているので、コード変換の際
>に文字化けが起きてしまうのです。それを防ぐ関数にフォーム内容を送って編集しているのです
>が、その段階でシングルだと文字列そのものが消されてしまうようなのです。ダブルだと問題な
>く動作します。

これが、何言ってるのかさっぱりわかりません。
>$test = 'aaa';
も
>$test = "aaa";
もPerlにとっては「aaa」という文字列です。
元がダブルだったかシングルだったかはわかりません。

その変換関数のロジックをよく確認してはどうでしょう?

「$test = 'aaa';」がヒアドキュメントの一部だとか、htmlの出力が value='text'だとだめで
value="text" だと大丈夫、とかいうオチじゃないですよね?

ANo.2

>これってperlの仕様的に可能なのでしょうか?

と訊かれれば、「可能です」。

でもプログラム的に影響があるかどうかはプログラム読まないとわかりません。
心配なら一通り動作検証すれば良いのではないでしょうか。
文面からするとさほど複雑なプログラムではないようですし。

補足

実はデコメを送信するページの作成で、かなり大きなプログラムとなっています。複雑化してき
て簡単には全部説明できそうにないので、問題になっている部分だけ書きます。

~~~~~~~ここから~~~~~~~~~~~

$subject='<#001;絵文字入り題名<#002;'; # <#は絵文字判別記号 実際にはフォームから受け取っている

$num = 0;
$ken = '<#';
#テーブルに沿って置き換え開始
while ($num != -1){
$num = index($cmp_subject, $ken);
if(-1 != $num){
$moji_num = substr($cmp_subject,$num,5);
$moji_cnv_tbl = &emoji_tbl;
substr($cmp_subject,$num,6) = $moji_cnv_tbl;
}
}
sub emoji_tbl {
if( $moji_num eq '<#001'){
if( $calia eq 'Docomo'){$moji_cnv = "\xF8\x9F";}
elsif( $calia eq 'EZweb'){$moji_cnv = 'EB60';}
elsif( $calia eq 'SoftBank'){$moji_cnv = "\x1b\$Gj\x0f";}
}elsif( $moji_num eq '<#002'){
if( $calia eq 'Docomo'){$moji_cnv = "\xF8\xA0";}
elsif( $calia eq 'EZweb'){$moji_cnv = 'EB65';}
elsif( $calia eq 'SoftBank'){$moji_cnv = "\x1b\$Gi\x0f";}
}elsif( $moji_num eq '<#003'){
~~~~~~~~~~~~~省略します~~~~~~~~~~~~
return $moji_cnv;
}

~~~~~~~~~ここまで~~~~~~~~

こんな感じです。
先頭にある、$subject='<#001;絵文字入り題名<#002;';が問題になっている文字列で、こ
れをデバッグで $subject="<#001;絵文字入り題名<#002;";にすると問題は解
決されます。

だからシングルをダブルに置き換えたいのですが。。。駄目でしょうか。
よろしくお願いします

ANo.1

変数展開がなければ・・・どちらも同じ結果になります。

投稿日時 - 2010-07-30 17:16:43
補足

変数展開はないのですが、フォーム内容をメールとして送信しているので、コード変換の際に文
字化けが起きてしまうのです。それを防ぐ関数にフォーム内容を送って編集しているのですが、
その段階でシングルだと文字列そのものが消されてしまうようなのです。ダブルだと問題なく動
作します。

■_ What is Gradual Typing?

ヤルキデナイズドさんのところで、この Gradual Typing のところを 「静的・動的型付け」とかって訳してたけどどうなんだろう。


What is Gradual Typing? by Jeremy Siek
What is Gradual Typing?
by Jeremy Siek

Gradual typing is a type system I developed with Walid Taha that allows parts of a 
program to be dynamically typed and other parts to be statically typed. The programmer 
controls which parts are which by either leaving out type annotations or by adding 
them in. This article gives a gentle introduction to gradual typing.

The following were our motivations for developing gradual typing:

    * Large software systems are often developed in multiple languages partly because 
      dynamically typed languages are better for some tasks and statically typed languages 
      are better for others. With a gradual type system, the programmer can choose between 
      static and dynamic typing without having to switch to a different language and without 
      having to deal with the pain of language interoperability. Hopefully this will 
      increase programmer productivity.

    * Several languages already have optional type annotations, but surprisingly, there
      had been little formal work on what a type checker should do with the optional 
      type annotations and what kind of guarantees the type system should provide.
      Languages with optional type annotations include Common LISP, Dylan, Cecil, Visual
      Basic.NET, Bigloo Scheme, Strongtalk. Gradual typing is meant to provide a
      foundation for what these languages do with their optional type annotations.
      There are several new languages in development that will also include optional
      type annotations such as Python 3k, the next version of Javascript (ECMAScript
      4), and Perl 6. Hopefully our work on gradual typing will influence these
      languages. 

(略)

Gradual type checking

A gradual type checker is a type checker that checks, at compile-time, for type errors 
in some parts of a program, but not others, as directed by which parts of the program 
have been annotated with types. For example, our prototype gradual type checker for 
Python does not give an error for the above program, reproduced again below.

# コンパイル時の型検査をするけどそれだけじゃなく…と。
# なんかいい訳語ないもんですかねえ。

(略)

■_ 本日の巡回から

■_ rakudo * for win

Perl6/Parrotスレ - Part2 
324 nobodyさん [sage] 2010/07/30(金) 01:27:16 ID:??? Be:
    Rakudo Starでた。
    ttp://rakudo.org/announce/rakudo-star/2010.07 

325 nobodyさん [sage] 2010/07/30(金) 05:59:11 ID:??? Be:
    Winマシンに入れてみようとしたが案の定makeでエラーがわんさか

    そんな俺が言うのもなんだが
    early adopter向けというわりにインストールは難しくなさそうだね

326 nobodyさん [sage] 2010/07/30(金) 10:59:20 ID:??? Be:
    試してないけど Windows 向けのインストーラあるよ
    ttp://www.jnthn.net/perl6/rakudo/Rakudo-Star-2010-07.msi 

327 nobodyさん [sage] 2010/07/30(金) 17:39:21 ID:??? Be:
    うほ
    DLしたら一瞬でインストールされたw
    これで遊びます。thx 

お、やっぱあるのか。

■_ さて

LL Tiger か。

2010年07月29日

■_

LL Tiger でどのくらい(ノベルティ目当てで)本を買ったものか。

rakudo * はどうなったんだろう

■_

つーことで Perl 6ネタ。


blog | Perlgeek.de :: Currying

NAME

"Perl 5 to 6" Lesson 28 - Currying

SYNOPSIS

  use v6;
  
  my &f := &substr.assuming('Hello, World');
  say f(0, 2);                # He
  say f(3, 2);                # lo
  say f(7);                   # World
  
  say <a b c&.map: * x 2;     # aabbcc
  say <a b c&.map: *.uc;      # ABC
  for ^10 {
      print <R G B&.[$_ % *]; # RGBRGBRGBR
  }

DESCRIPTION

Currying or partial application is the process of generating a function from another 
function or method by providing only some of the arguments. This is useful for saving 
typing, and when you want to pass a callback to another function.

カリー化もしくは部分適用は、ある関数からその引数の一部だけを与えられている別の関数や
メソッドを生成するプロセスです。これはタイピングをセーブし、別の関数にコールバックを
渡したいときに便利なものです。


Suppose you want a function that lets you extract substrings from "Hello, 
World" easily. The classical way of doing that is writing your own function:

  sub f(*@a) {
      substr('Hello, World', |@a)
  }

Currying with assuming

Perl 6 provides a method assuming on code objects, which applies the arguments passed 
to it to the invocant, and returns the partially applied function.

  my &f := &substr.assuming('Hello, World');

Now f(1, 2) is the same as substr('Hello, World', 1, 2).

assuming also works on operators, because operators are just subroutines with weird 
names. To get a subroutine that adds 2 to whatever number gets passed to it, you could 
write

  my &add_two := &infix:<+&.assuming(2);

But that's tedious to write, so there's another option.
Currying with the Whatever-Star

  my &add_two := * + 2;
  say add_two(4);         # 6

The asterisk, called Whatever, is a placeholder for an argument, so the whole 
expression returns a closure. Multiple Whatevers are allowed in a single expression, 
and create a closure that expects more arguments, by replacing each term * by a formal 
parameter. So * * 5 + * is equivalent to -& $a, $b { $a * 5 + $b }.

Whatever と呼ばれるこのアスタリスクは、引数のプレースホルダーであり、
式全体がクロージャを返します。複数の Whaterver をひとつの式に置くことは
許されていて、それぞれの * を仮引数 (formal paramter) と置き換えることによって
より多くの引数を期待してえるクロージャを生成します。ですから、
* * 5 + * は  -& $a, $b { $a * 5 + $b } と等価になります。

  my $c = * * 5 + *;
  say $c(10, 2);                # 52

Note that the second * is an infix operator, not a term, so it is not subject to 
Whatever-currying.

The process of lifting an expression with Whatever stars into a closure is driven by 
syntax, and done at compile time. This means that

  my $star = *;
  my $code = $star + 2

does not construct a closure, but instead dies with a message like

  Can't take numeric value for object of type Whatever

Whatever currying is more versatile than .assuming, because it allows to curry 
something else than the first argument very easily:

  say  ~(1, 3).map: 'hi' x *    # hi hihihi

This curries the second argument of the string repetition operator infix x, so it 
returns a closure that, when called with a numeric argument, produces the string hi as 
often as that argument specifies.

The invocant of a method call can also be Whatever star, so

  say <a b c&.map: *.uc;      # ABC

involves a closure that calls the uc method on its argument.

MOTIVATION

Perl 5 could be used for functional programming, which has been demonstrated in Mark 
Jason Dominus' book Higher Order Perl.

Perl 6 strives to make it even easier, and thus provides tools to make typical 
constructs in functional programming easily available. Currying and easy construction 
of closures is a key to functional programming, and makes it very easy to write 
transformation for your data, for example together with map or grep.

Whatever とかどう訳語をつけろというのか ○| ̄|_

■_

Windows用Pythonのつくりかた


Building Python Extensions in a Modern Windows Environment | Matt_ptr *

Building Python Extensions in a Modern Windows Environment

A few days ago I decided to upgrade to Python 2.7. I'm running Windows 7 64-bit — 
pretty sweet as far as Windows goes. ;) So, I'm thinking to myself, “I'm running a 
64-bit OS, why was I running a 32-bit Python?”

While the core Python distribution is available in 64-bit, many many packages that I 
depend on only supply precompiled binaries for the 32-bit Python distribution. Why? I 
have no idea. There are two things you can do.

   1. Use this site. There are a bunch of packages available with 64-bit in mind that 
      aren't available from the package's maintainers. MySQL-Python, for instance.

   2. Compile them yourself. The unofficial repository doesn't have all packages on 
      PyPI compiled for Windows. gevent is one I've come to depend on a lot, and it's not 
      available — so I had to find a way to build extensions myself. Here's how…

Install Microsoft Visual C++ 2008

Don't bother with MinGW. Let me say it again — DO NOT USE MINGW FOR THIS! For one, the 
standard mingw distro is 32-bit. I found a gcc toolchain for 64-bit Windows, but I 
couldn't get it to work. The Python import lib is made for Visual Studio. There are 
apparently ways to convert the file to something compatible, but I spent 4-5 hours 
trying to get this to work to absolutely no avail. Save yourself the trouble.

# MingGW を使ってはいかんとな。

Additionally, you can't use Visual C++ 2010. Python's distutils lib is not set up to 
handle it. Visual C++ express works, as long as it's 2008.

Note that if you have Visual Studio 2008 Professional, Team Studio or whatever, you 
should be able to stop here. The Express editions, however, don't have the 64-bit 
environment, so we need to do more stuff.

# Exrepress エディションかそうでないかで分岐

Install the Windows 7 Platform SDK
Windows 7 プラットフォームSDKをインストールする

Now just called the Windows SDK. You can get it here. It's pretty large, so be 
prepared. Obviously, make sure you install the 64-bit environment.

Trick distutils

distutils looks for a file called vcvarsall.bat, runs it, and gets the include and lib 
directories that the batch file sets up. The batch file sets up the environment based 
on what platform you supply to it — in this case, amd64. Unfortunately, Visual C++ 
Express does not have the proper files for 64-bit compilation, but you can set it up 
pretty easily.

vcvarsall.bat should be in a directory like: C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC

You need to create:

    * The directory — C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64\

    * The file — C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64\vcvarsamd64.bat

The Windows SDK comes with a fully working 64-bit environment, so we just need to 
point vcvarsamd64.bat to the new SDK — which distutils doesn't recognize.

So in vcvarsamd64.bat put:

call "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd" /x64 /Release

Assuming you let the Windows SDK install in the default location.

Still not done

We have to patch distutils now. Unfortunately, the new linker doesn't generate 
.manifest files by default, but distutils tries to embed a manifest file in the dll 
(pyd) that it just built, and *will fail* if it is unable to do so.

To fix this, add the follow line to distutils\msvc9compiler.py after line 648:

ld_args.append('/MANIFEST')

That's it!

You should now be able build your own extensions for 64-bit Python in Windows 7! You 
can have PyCrypto, gevent, ZODB, and so on.

(略
)

■_


パターンマッチが、ひっかかりません。ActivePerl のバグでしょ | OKWave

パターンマッチが、ひっかかりません。ActivePerl のバグでしょうか?

$doc =~ m%<SCRIPT language=javascript type=text/javascript>(.+?)</SCRIPT>%;

$1 に、何も入りません。
$doc は、複数行のデータです。(改行が、複数ある)
中身を検索すると、確かに、この文字列は、存在しています。
環境は、ActivePerl 5.12.1 Build 1201 です。
どなたか、助けてください。

質問者が選んだベストアンサー

>$doc は、複数行のデータです。(改行が、複数ある)

他の方の指摘の通りだと思いますが、ストレートに書いてないので、伝わってないかもしれませんね。
正規表現の . は、改行にはマッチしません。

お書きの正規表現だと、<SCRIPT>から</SCRIPT>までが同一行の時だけマッチします。

. を改行にもマッチさせたいときは、正規表現のオプションで s を指定します。

$doc =~ m%~~~%s;

お礼

ありがとうございます。
修飾子'm'については、やってみていたのですが、's'については、文字列を単一行として扱うと、
いうことなので、考えもしませんでした。今回は、複数行なので・・・
もう少し、深く意味を探らないと、いけませんね。

ANo.2


$doc =~ m%<SCRIPT language=javascript type=text/javascript>(.+?)</SCRIPT>%s;

としたらどうでしょう。
もしそれでもマッチしなければ正規表現が間違っている可能性があります。

お礼

ありがとうございます。うまくいきました。
修飾子'm'については、やってみていたのですが、's'については、文字列を単一行として扱うと、
いうことなので、考えもしませんでした。今回は、複数行なので・・・
もう少し、深く意味を探らないと、いけませんね。

まあ s 修飾子とか m 修飾子の効果はわかりにくいっちゃーわかりにくいかもしれない。 「単一行」とか「複数行」ってのに引っかかると。 . や ^ $ の動作を変えるといっちゃえば誤解は少なくなるのだろうけどいい名前がねえ。

■_ ちょっとだけ



InfoQ: オブジェクト指向プログラミングは間違いだったか?

オブジェクト指向プログラミングは間違いだったか?

「メッセージ送信を行うSmalltalk-80から生まれたオブジェクト指向を振り返って、継承などの
現在の状況を見てみれば、私たちは間違った道を下ってきたと言えるだろうか?」 これは、QCon 
London 2010 インタビュー の最初の質問だった。このインタビューを受けたのは、Erlangの最
初の開発者であるJoe Armstrong博士とSmalltalk、OOP、パターンに長い間関係しているRalph 
Johnson博士だ。私たちは「間違った道」を当てもなくさまよってきたが、これはオブジェクト
の考え方の実現方法に欠点があったためであり、この考え方自体の欠点ではないと2人は述べた。
実際に、Ralph Johnson博士は以下の点から始めた。

"If you look back at where object orientation came from with Smalltalk-80 with 
message passing, and look at the current state of inheritance and things like that, 
have we gone down the wrong path?" This is the opening question of a QCon London 
2010 interview with Joe Armstrong, the original developer of Erlang, and Ralph Johnson, 
long associated with Smalltalk, OOP, and Patterns. Both interviewees suggest that we 
have meandered down the "wrong path" but this is due to flaws in the 
implementation of object ideas and not the ideas themselves.  This is, in fact, Ralph 
Johnson's intial point:

have we gone down the wrong path? なのだから、「~と言えるだろうか?」 じゃなくて、「~ではないだろうか?」のほうがしっくりくるような気がする。

    あるアイデアを思いついて世の中に出すと、たいていの人にとって急進的過ぎるのはよくある
    ことです。大半の人はすべてのことを取り入れずに、一部だけ手に取ります。そして、あなた
    が手にするのはこの不完全なものなのです。

オブジェクト指向言語の見本として多くの人たちが支持したSmalltalkでさえ、オブジェクトの
典型に似たようなものとして考えられた。Johnson博士はSmalltalkに関するある2つのことを提
案した。
  
    ... Smalltalkは基本的な間違いを犯したと思います。Smalltalkは、Smalltalkプログラマでは
    ない人たちには評価できないことがあります。それは、Smalltalkでプログラミングしている場
    合、そして、Smalltalkでデバッグしている場合、システム全体をデバックしていることです。

  
    ... I think Smalltalk made a fundamental error. I think it's hard for people who 
    aren't Smalltalk programmers to appreciate this, but when you are programming in 
    Smalltalk, when you are debugging in Smalltalk, you are debugging the whole system.
  

この fundamental error は「根本的な間違い」じゃないかと。 というか「基本的な間違い」ってどゆこと? 基本的なところで間違いを犯した とかいう言い回しならわかるんですが。 その次の文も、“but”がどっかにいっちゃってるような。 訳文の「評価」って “appreciate”からきてんのかなあ? 「Smalltalkでデバッグをすることはシステム全体をデバッグしていることだとということを Smalltalk プログラマーでない人が理解するのは困難だろうとわたしは考えている」 とかそんな感じ?

  続けて

    なぜなら、Smalltalkではイメージの中にすべてのことがあります。古いものと新しいものの
    バージョンは追跡し続けられません。また、複雑さという問題もあります。システムを構築す
    ると、少数の人たちができることには制限があって、そこではSmalltalkはそれほどよく機能し
    ません。

    
    Because in Smalltalk you have everything in the image. You can't keep track of the 
    versions between the old and the new one ... and there is also the issue of complexity. 
    You build a system, so it gets to the limit of what a few people can do and there 
    Smalltalk doesn't work too well.
    

なぜなら~すべてのことがあります。というのがなんか妙な言い回しな気が。 なぜならすべてがイメージの中にあるからです。とかになるような。 んで、track ot the versions betweeen the old and new one の between が訳文から 抜け落ちているんじゃないでしょうか。 古いバージョンと新しいバージョンとの間の変更点を追いかけられないよ。とか いうニュアンスだと思うのですが。

  この言語のもっとも熱心なファンにとっても、アプリケーションクラス、開発とデバッグ用ツー
  ル、ライブラリなどすべてが「イメージ」の中にあるという事実は、常にSmalltalkの問題であ
  った。しかしながら、これは、Cargill Lynx Projectのような非常に大きくて重要なシステムを
  人々が構築するのを止めはしなかった。Lynxは、地球規模の穀物取引システムであり、アメリカ
  合衆国の150サイトの1,500以上のユーザをサポートし、ここ10年以上製作されている。その間、
  Lynxは100人以上のプログラマをうまく巻き込み、完全なバージョンコントロールと強固なテス
  トとデバッグの機能を持ち続けてきた。Lynx Projectのような成功した大規模システムが、
  Ralph Johnson博士の懸念を鎮めたり、Smalltalkがオブジェクトの考え方に関して欠点のある実
  装だったという前提に異議を唱えたりするものではない。単に見解を付け加えただけだ。
  
The fact that everything (your application classes, development and debugging tools, 
and libraries) is in the 'image,' has always been an issue with Smalltalk, even for 
the language's most ardent admirers.  However this did not stop people from building 
very large, mission critical, systems - like the Cargill Lynx Project.  Lynx is a 
global grain trading system that supports over 1,500 users at 150 sites around the U.S. 
and has been in production for over a decade.  During its existence, Lynx has involved 
well over a hundred programmers, with full version control, and rubust testing and 
debugging.  Successful large systems, like the Lynx Project, do not allay Ralph 
Johnson's concerns, nor do they refute the premise that Smalltalk was a flawed 
implementation of object ideas; they merely add additional perspective.
  

very large, mission critical, system → 非常に大きくて重要なシステム? 「懸念を鎮める」…んーー。

どのような特徴がこの言語をオブジェクト指向にしたかという質問は、1990年代に広範囲に渡り、
感情的に議論された。QCon Londonのインタビューにおいて、Joe Armstrong博士の論文のアドバ
イザが、まさに同様の議論をしたことを引用している。
  
The question of what set of characteristics made a language object-oriented was 
extensively, and emotionally, debated in the 1990's.  In the QCon London interview, 
Joe Armstrong's thesis advisor is quoted making a very similar argument:
  

この question を「質問」って訳しちゃおかしくなるような。

    私は、オブジェクト指向プログラミングというものに疑問を持ち始めました。Erlangはオブ
    ジェクト指向ではなく、関数型プログラミング言語だと考えました。そして、私の論文の指導教
    官が言いました。「だが、あなたは間違っている。Erlangはきわめてオブジェクト指向です。」 
    彼は、オブジェクト指向言語はオブジェクト指向ではないといいました。これを信じるかどうか
    は確かではありませんでしたが、Erlangは唯一のオブジェクト指向言語かもしれないと思いまし
    た。オブジェクト指向プログラミングの3つの主義は、メッセージ送信に基づいて、オブジェク
    ト間で分離し、ポリモーフィズムを持つものです。
  
    I started wondering about what object oriented programming was and I thought 
    Erlang wasn't object oriented, it was a functional programming language. Then, my 
    thesis supervisor said "But you're wrong, Erlang is extremely object oriented".
    He said object oriented languages aren't object oriented. I might think, though I'm
    not quite sure if I believe this or not, but Erlang might be the only object oriented
    language because the 3 tenets of object oriented programming are that it's based on
    message passing, that you have isolation between objects and have polymorphism.

  

オブジェクト指向プログラミングの三つの主義は、~持つものです。 って言い回しがおかしくないですか?

いい加減飽きた。やめ。

■_ 本日の巡回から

2010年07月28日

■_

昨日はくじけました

あれとあれとあれが重なって久しぶりにカードの引き落とし額が大台突破○| ̄|_

■_ 二日分

■_ UTF-8対応

どこかで見たようなリンク先が


Rubyについて Part 40 [chaika]
833 デフォルトの名無しさん [sage] 2010/07/24(土) 13:19:42  ID: Be:
    LinuxでRubyのなんちゃらを開発してる人ってさ、Gitのクライアント何使ってんの?
    まさかコマンドラインで頑張ってるの?

834 デフォルトの名無しさん [sage] 2010/07/24(土) 13:31:07 ID: Be:
    >>833
    俺はLinuxとcygwinでgitのコマンドラインとGUIの補助ツール使ってる
    さすがにgit log オプション色々とかだとツリー表示できてもつらいのでgitkも使う

    Windows環境も使っていて、TortoiseSVNとかTortoiseHgの便利さは知っているから
    gitにもちゃんとしたそういうのがあればいいんだけどね

    皮肉なことにそういうGUIが発達しているWindowsでは、
    hgやgitはマルチバイト対応が腐ってるし、結局cygwinなりで実質コマンドラインでしか使えない
    WindowsだとgitkなどのGUIツールも不安定だし、何故か文字化けするし
    UTF-8のLinuxなら大丈夫なんだけどね


    TortoiseSVNはマルチバイトがらみが安心して使えるようになるまで3年はかかった記憶あるけど
    gitや周辺GUIツールではどのくらいでなんとかなるものかねえ

    この辺の話はバージョン管理スレとかで聞いたほういいよ。
    あっちはコマンドラインで使っている人も多いだろうし、釣れると思う

    バージョン管理システムについて語るスレ6
    http://pc12.2ch.net/test/read.cgi/tech/1270640436/ 

835 デフォルトの名無しさん [sage] 2010/07/25(日) 23:21:55 ID: Be:
    >>833
    vc.el+自作のツールだな 

837 デフォルトの名無しさん [sage] 2010/07/26(月) 02:36:12 ID: Be:
    >>834
    あっちでは鬼子のbzrの話もしてあげるのがいいよ
    早期から日本語エンコーディング考慮済み言語のRubyには
    マルチバイト軽視はあんまり馴染まない気がする 

839 デフォルトの名無しさん [sage] 2010/07/26(月) 09:55:03 ID: Be:
    >>834
    TortoiseGit とかあるよ 

841 デフォルトの名無しさん [sage] 2010/07/26(月) 23:02:00 ID: Be:
    >>839
    TortoiseGitが推奨するmsysgitはマルチバイトがダメダメで、その辺なんとかなるCygwin gitには対応してない状況
    TortoiseGitのIssueでもその手の報告はけっこうされてて、msysgitの対応待ちという状況
    Cygwinのgitへの対応は今のところしないみたい

    ようするに日本語フォルダとか日本語ファイル名使わないなら、何とかなる
    多分Rubyだけで使う分には関係ないと思う
    日本語ファイル名のドキュメントやリソースをぽんぽん放り込んでたSubversionリポジトリをgitに変換したり、
    git-svnで使うとかしない限りは


842 841 [sage] 2010/07/27(火) 02:09:56 ID: Be:
    戯言を書いていたら、 >>834のスレにUTF-8対応版のパッチが来てたw 

843 デフォルトの名無しさん [sage] 2010/07/27(火) 06:46:04 ID: Be:
    比較的新しく生まれたソフトでマルチバイト対応がダメダメってどういうことなのよ。
    この世には英語しかないんだぜ!HAHA!て人が作り始めるとそうなるのかな? 

855 デフォルトの名無しさん [sage] 2010/07/28(水) 08:16:13 ID: Be:
    >>842
    現行実装を散々disってイチから作りなおすと宣言してたC++厨の連中涙目だな
    ttp://togetter.com/li/21696 

856 デフォルトの名無しさん [sage] 2010/07/28(水) 08:58:04 ID: Be:
    よーしパパ、夏休みの自由研究でGitをRubyで実装しちゃうぞ~ 

857 デフォルトの名無しさん [sage] 2010/07/28(水) 09:10:43 ID: Be:
    >>851
    日本語説明文を添付するんだ
    ja_JP.txt とかいう名前にしておけばたぶん大丈夫 

858 デフォルトの名無しさん [sage] 2010/07/28(水) 10:17:32 ID: Be:
    >>855
    こっちでいうのもなんなんだけど、彼らが真面目にgitのソース解読してる間に
    >>834 のパッチ作った方はcygwin 1.5のころのokiソフトがUTF-8に対応した実装を参考に
    アドホックに対応してて面白いw

これか。

バージョン管理システムについて語るスレ6 
695 デフォルトの名無しさん [] 2010/07/26(月) 20:38:49 ID: Be:
    msysGit の UTF-8ファイル名対応版を作りました。
    一応、TortoiseGit からきちんとUTF-8ファイル名を扱えることを確認済み。
    http://tmurakam.org/git/
    本家にもパッチ送っておいたけど、取り込まれるかな、、、? 

696 デフォルトの名無しさん [sage] 2010/07/26(月) 20:41:22 ID: Be:
    神じゃ
    神が降臨なされた 

697 デフォルトの名無しさん [sage] 2010/07/26(月) 21:14:59 ID: Be:
    hgのfixutf8の強力なライバル出現。
    fixutf8の場合リポジトリ毎に有効にするかしないか選択できるんだけど。 

698 デフォルトの名無しさん [sage] 2010/07/26(月) 22:51:48 ID: Be:
    素晴らしいね。早く分散バージョン管理御三家にもsvn並の
    マルチバイト対応がされる日が来ることを祈るよ。 

699 デフォルトの名無しさん [sage] 2010/07/26(月) 23:08:06 ID: Be:
    >>695
    神キターオワタ\(^o^)/

700 デフォルトの名無しさん [sage] 2010/07/26(月) 23:08:28 ID: Be:
    わるい、オワタ の文字消し忘れた 

701 デフォルトの名無しさん [sage] 2010/07/26(月) 23:51:29 ID: Be:
    ちょw 神は死んだwwww 

702 デフォルトの名無しさん [sage] 2010/07/27(火) 00:44:27 ID: Be:
    終わっちゃったよ・・・ 

703 デフォルトの名無しさん [sage] 2010/07/27(火) 01:14:07 ID: Be:
    >>695
    使ってみました。

    全体的にUTF-8のcygwin gitと問題になっている状況が改善しないところがあったので報告
    こちら側で何か変なところがあるのかもしれない

    ・TortoiseGitでそちらのmsysGitのgitパスを設定しmsysGitのバージョンが出ることを確認
    ・TortoiseGitのコミットダイアログでは、マルチバイトのファイル名は化けず、diffアプリもちゃんと呼べる
    ・コミット時のProgressウインドウではファイル名表示が化ける(コミット自体は成功)
    ・TortoiseGitのログ表示でマルチバイトのファイル名が文字化けした。コミットログは文字化けしない。
     文字化けファイル名はdiffアプリに正しく渡すことが出来ない
    ・そちらのmsysGit UTF-8付属のgitkは、同様にファイル名とdiff表示の中身がUTF-8のファイルが文字化け。
     コミットログはOK
    ・同じく付属のGit GUIは、マルチバイトファイル名の表示やindexに追加、コミットまでが無事に行けました

    捕捉
    ・msysGit UTF-8でコミットした日本語ログはcygwin gitでもちゃんと見られた
    ・cygwinのgitkではファイル名は化ける。diff表示ではファイルの中身がUTF-8のものは見られる。SJISは化ける


    gitkはcygwinのUTF-8でもおかしいのでtkの問題なのかな。
    ファイルの中身がUTF-8なものが化けてSJISは見られるのがよくわからないけど
    GitGUIの設定ウインドウ見る限り、.gitconfigは見てくれてるみたいのようだし 

704 703 [sage] 2010/07/27(火) 01:47:32 ID: Be:
    >>695
    ちょっと状況がよくわからないが少し追加

    ・msysGit UTF-8をファイラーのコンテキストメニューの"Git Commit Tool"もしくは、"Git GUI"からGit GUIを起動し、
     そこから、メニューのブランチの履歴を選んでgitkを起動した場合、
     ファイル名は文字化けするが、diff表示の中身がUTF-8のファイルは文字化けなし。SJISは文字化け
     オプションの設定を見るに、HOMEの.gitkをちゃんと読んでくれているよう
    ・逆にコンテキストメニューの"Git History"からgitkを立ち上げた場合は、
     HOMEの.gitkを読んでくれず >>703の通り、
     ファイル名は文字化けし、diff表示の中身がUTF-8のファイルは文字化けする。SJISは文字化けしない
     というdiffだけ逆の状態。
     gitkのオプションで設定を変えても、保存されない

     (一番目)Git GUIから立ち上げた場合はgitの子プロセスでgitkが起動していて、
     (二番目)gitkをそのまま立ち上げた場合はsh.exeから--login オプション起動している点も気になる


    cygwin 1.7とgitが既に入っていて、インストール時にshell extentionにGit Cheetah選んだんだけどそれのせいなのかな
    ただ、Process Explorerで見る限りはmsysGit側のexeが立ち上がっており、
    cygwinのexeが間違って起動されていることはないみたい 

705 695 [sage] 2010/07/27(火) 03:04:41 ID: Be:
    どうもありがとうございます。

    TortoiseGit 側は文字列が ANSI で出力されてくることを期待しているので、UTF-8 を ANSI に
    変換して出力するような修正をいれているんですが、ログが文字化けするということはまだ直しきれて
    ない箇所が残っているようです。もう少しソースを追ってみないといけないかな。
    gitk で文字化けするのも同じ理由のような気がします。 

706 703 [sage] 2010/07/27(火) 12:59:00 ID: Be:
    >>705
    こちらこそ助かります

    ちょっと長文で書いちゃってわかりにくくなっててすいません

    Cygwinの話もまざっているのでmsysGit UTF-8で整理すると

    ・Git Cheetahのファイラーからのコンテキストメニューから立ち上げた場合の話
    ・"Git Commit Tool"もしくは、"Git GUI"はコミットログやマルチバイトのファイル名の表示コミットも特に問題ない様子
    ・上記のGit GUIからgitkを起動した場合、
     ・ファイル名は文字化け
     ・diff表示がUTF-8のファイルは文字化けしない(SJISは文字化け)
     ・$HOME/.gtkなどの設定が反映されている様子
    ・"Git History"からgitkを立ち上げた場合、
     ・ファイル名は文字化け
     ・diff表示がUTF-8のファイルは文字化けする(SJISは文字化けしない)
     ・$HOME/.gtkなどは無視されている気がする?

    Cygwinも入れてある環境なため、環境依存の不具合もありそうです。

    ファイルの中身がSJISのものは文字化けするのは不便ですが、今回とは別件の話だと思います
    (diff表示に異なるエンコーディングが混ざっている場合の問題でもあるし)

    今後も長文になりそうだし、githubのissueに行った方がいいかも 

707 デフォルトの名無しさん [sage] 2010/07/27(火) 13:49:04 ID: Be:
    githubのissueトラッカーでやったら? 

708 デフォルトの名無しさん [sage] 2010/07/27(火) 13:50:18 ID: Be:
    >>707
    最後まで読まずに書いちゃった。>>706 の最後に書いたあった。

709 デフォルトの名無しさん [sage] 2010/07/27(火) 15:35:57 ID: Be:
    modern-gitってのもgithubにあるね。
    やはりMinGWでの日本語の扱いをどうにかするのが目的みたいで
    C++で実装しなおしてるみたい。
    どこまで実装できてるかはよく分からないんだけど(個人的にWindows使わないので) 

710 デフォルトの名無しさん [sage] 2010/07/27(火) 15:59:07 ID: Be:
    >>709
    mingw前提なので華麗にスルー 

711 デフォルトの名無しさん [sage] 2010/07/27(火) 16:01:50 ID: Be:
    bzr-git/hg-gitで使っているpythonのdulwich使えないのかな? 

■_ これって

表示をこのようにしろって問題ではなかろうか?

アセンブリ言語の質問です。8086アセンブラで「筆算的加減算」のプログ | OKWave

アセンブリ言語の質問です。8086アセンブラで「筆算的加減算」のプログラムを組むことになりました。

2個の整数(3桁)を入力し、入力エラーも処理する様にしなければなりません。また、


  123     234         1        100
+456    -123     +999       -200
ーーーー   ----    ----     ----
 579      111      1000       -100


のように表示する事が条件になっています。

プログラムを組む上で、何かアドバイスやヒント等、教えていただけないでしょうか・・?

投稿日時 - 2010-07-28 21:26:30
別に普通に加算命令(ADD,ADC)と減算命令(SUB,SBB)を使えば良いだけじゃないですか?

レジスタは16bitなので3桁の整数など余裕で扱えるし、他に二進化十進数やアンパック十進数
で計算する方法もあります、その為の命令もありますしね。

それよりも入力や出力で数値を変換する部分が大変ですね。

普通はBIOSやAPIなどで入出力の仕様が定義されていて、それに合わせて変換するサブルーチン
を作って呼び出しますね。

単に計算すればいいだけなら「筆算的加算」ってわけわからんもんなあ。 乗除算ならわからんでもないのだけど。

回答もなんか方向が違っているような…

2010年07月27日

■_

・今日のTLはこの話題で持ちきりでした
阿澄佳奈を中心とした超至近距離・声優ユニット「LISP」始動! | ホビー | マイコミジャーナル

■_

「メンテナンス可能な(メンテナンスしやすい?) Perlスクリプトを書くためのチェックリスト」


A Checklist for Writing Maintainable Perl - Modern Perl Books, a Modern Perl Blog


(さくっと略)

    * Do you know how to use the Perl documentation

    * Do you use CPAN modules?

    * Do you use the CPAN distribution layout for organizing your code?

    * Have you enabled strictusers and warnings? Is the resulting code clean of
      warnings and errors?

    * Are you using the standard Perl testing framework? (Did you write tests at all?)

    * Do you have an automated Perl configuration, build, dependency resolution,
      installation, and distribution mechanism?

    * Does your code conform to local Perl layout guidelines?

    * Does your code conform to Perl community standards for maintainability and correctness?

    * Are you familiar with the local Perl mongers group?

    * Are you using a recent version of Perl?

    * Are you familiar with writing secure Perl?

    * Do you use source control?

    * Do you use functions?

    * Do you use modules?

    * Do you use objects?

    * Do you use Moose or another abstraction mechanism from the CPAN?

    * Do you document your Perl code?

    * Do you use language constructs you don't understand, copied and pasted from elsewhere,
      smushed together into a hateful melange of barely-working confusion you occasionally
      tweak just to see what happens, and one afternoon you get sick of it and call it done?

You don't have to answer all of those questions in the correct way to write good and 
maintainable Perl, but if you answer most of those questions in the wrong way, of 
course you'll write bad code.

Perl allows people to accomplish their tasks without having to learn much, without 
having to participate in strange and unfamiliar ceremonies, and without even being 
much good at programming at all. That's by design, and that's a good thing for very 
specific circumstances. Yet if you approach programming as if it were merely typing 
and retyping until something barely working fell out of your typewriter, you're going 
to make lots of messes, and no language can save you from an unprofessional lack of 
discipline.

Writing good code requires discipline in any language.
良いコードを書くには何かの言語での discipline (鍛錬、訓練、修行) が必須のものだ。

■_

ボーイスカウトがどうのってどこかで読んだ覚えがあるんだけど思い出せない。


www.hans-eric.com » The Boy Scout Rule

The Boy Scout Rule

July 26th, 2010 Hans-Eric

You may have heard of The Boy Scout Rule. (I hadn't until I watched a recorded 
presentation by “Uncle Bob”.)

    You should always leave the camp ground cleaner than you found it.

Applied to programming, it means we should have the ambition of always leaving the 
code cleaner than we found it. Sounds great, but before we set ourselves to the 
mission we might benefit from asking a couple of questions.

ボーイスカウトルールをプログラミングに適用すると、自分がそれを目にしたときよりも
常にコードをきれいにしなさいということになります。これはとてもよい言葉のように
聞こえますが、わたしたちは自分をミッションにセットする前に二つの質問を発すること
から利益を得るかもしれません。
#ちょーやく

1. What is clean code?
2. When and what should we clean?


(略)

With all that said, I have never imposed “cleaning” restrictions on my teams. They 
are allowed to do whatever refactorings they find necessary. If they are actively
“cleaning” the code it means they care about quality, and that's the way I like it. 
In the rare cases excessive cleaning cause problems, most teams will handle it and 
change their processes accordingly.

Cheers!

■_

迷信 (or 神話)


C++ Urban Myths - Stack Overflow

I'm starting to write an article on what I'm calling "C++ Urban Myths" - 
that is, ideas and conceptions about C++ that are common but have no actual roots in 
reality. Some that I've come up with so far are:

TR1 is part of standard C++

    * TR1 (technical Report #1) proposed a whole bunch of changes to C++. 
      Unfortunately, it was never accepted.

It is faster to use iterators to access a vector than operator[]

    * Or vice versa. All tests I've carried out indicate the two are nearly identical 
      in performance.

The C++ Standard contains something called the STL

    * It doesn't - neither "STL" nor "Standard Template Library" 
      appear in the Standard.

I'm wondering if the SO C++ community can come up with any better ones? Ideally, they 
should be expressible in a single sentence, and not involve any code.

Edit: I guess I didn't make it clear enough that I was interested in myths believed by 
C++ developers, not misconceptions held by non-C++users. Oh well...
There is a language called C/C++.
(C/C++ と呼ばれるプログラミング言語が存在する)

There is common misconception that if you know C++ you can easily write C code and if 
you know C that you can easily start writing C++ code.

These languages are so different that I would never put them one near other.


C++ is slower than C.


The STL is slow is a myth. It's often faster than writing your own containers (except 
for highly specialist uses like EASTL, but you certainly need an uncommon level of 
expertese to beat the STL), and modern compilers optimise it excellently. Occasionally 
you can still come across people using fixed C arrays or reinventing containers 
"for efficiency", when their code may well be slower (not to mention more 
prone to errors than the well-tested STL).

You have to manage the memory manually

Ok, it's a bit tricky (and somewhat provocative point of view), but using RAII you can 
cover almost every situation. For some extreme cases, smart pointers do the work.


Old one, but still strong:

You need to learn C first.
(まず初めに C を学べ)


You have to choose a "safe subset" of C++. Don't use exceptions or templates 
or multiple inheritance or smart pointers or custom memory allocators, because they 
are too complicated for mere mortals to understand and use correctly.

C++ を使うには、そこから「安全なサブセット」を選び出す必要がある

Truth: The "complicated" parts of C++ are there because they can make 
programs simpler. Don't prohibit their use because you are not familiar with them or 
because you've seen them misused.

Calling virtual functions is extremely slow

I've heard it many times, including here, on StackOverflow. Modern virtual tables 
implementations dispatch virtual function calls quite fast, with small and 
predicatable overhead, compared to calling usual functions. In the simplest 
single-inheritance case it requires just an additional access to one memory cell. I 
started my blog with an "article" about it.

The Standard allows NULL to be something other than zero, so you should not use 0.

Urban Myth!

    * C++ is inefficient for embedded development
      C++ は組み込みに使うには効率が悪い

    * C++ is only C with Classes (see STL...)
      C++ はクラスのついた C に過ぎない


Modern C++ style is MFC style

Macros are easier to use than templates
マクロはテンプレートよりも簡単

Exceptions are a really bad idea, slow and complicated to understand and maintain

Exceptions are a really good idea, clean and elegant an make code easier to read

EDIT: I have heard both passionately expressed. Since both cannot be true and each 
camp is full of smart people who care then they both must be myths

For the record I fall into the pro-exception camp.

There are developers who understand C++
C++ を理解している開発者が存在する


C++ is a horrible language.

It's not the language that's horrible, its the programmers who use it in a naive way. 
And just as there are bad C++ programmers, you can hardly swing a dead cat without 
hitting bad programmers in [insert favorite language here].

C++ is an Object-Oriented language.

C++ is a multi-paradigm language. It's not object-oriented in the sense that 
"everything is an object" the way it is in Ruby or .NET languages. C++ 
supports object-oriented programming, but it also supports generic programming, 
functional programming, and just about any other programming paradigm you can imagine.

The STL is Object-Oriented.

According to A. Stepanov, no, it's not.


Myth: It is possible to use the STL correctly while in exception denial.

A few STL methods throw exceptions (e.g., std::vector::at). More importantly, the 
container classes expect the allocator to throw std::bad_alloc when an allocation 
cannot be satisfied.

If your local coding standard enforces exception denial and thus you disable 
exceptions in the compiler, these errors crash or corrupt data in STL calls, beyond 
the ability of the calling code to anticipate or handle the problem. You cannot even 
rely on RAII to clean up on the way out.

If you permit the compiler to generate exceptions, but disallow code from outside the 
STL from using try and catch, then you still cannot rely on stack-unwinding and RAII 
to clean up when an error is thrown from within STL. The unwinding only happens up to 
the highest point the exception is caught.

And, lastly, the STL containers expect the contained objects to be copyable. If you 
live in exception denial, what do you do if you can't guarantee success from a copy 
constructor? You can't throw an exception, and there's no way to signal a failure.

The design of the STL assumes the caller isn't in exception denial.

C++ Exception Handling Uses more Time & Space than C

This is one misconception that prevents C++ from being used on Embedded Systems. The 
fact is that the equivalent exception handling in C amounts to the same time and space 
(perhaps a little more). The issue is that people don't write the equivalent exception 
handling in C; exception handling is generally ignored by C programmers.

C++ Virtual Tables occupy more time & space than C

Again, most people haven't implemented polymorphism in C. Also, programs can be 
written in C++ that don't use virtual functions or polymorphism.

C++, in general, uses more space and time than C.

An equivalent program written in C would use the same space or more. It may use more 
because some of the issues already in the C++ language would have to be added to the C 
language program.

C++ is not the Best Language for XXXXX project.

This comes down to price, duration, and skill sets (at least). A language that is best 
suited for a project (due to language features) may not be the best fit for the shop, 
especially when few people have experience in that language. A small team of experts 
in FORTRAN can develop more correct and robust software than a large team of newbies 
using a popular language. C++ was designed to be a generic language: it covers a wide 
base of requirements for many projects.

The Size of a Structure (class, etc.) is the sum of the size of the members.

People forget that compilers can add padding between members.

Class Names must begin with 'C'.

Another thing started by the MFC...

Functional Code Must Be In A Class.

C++ still supports free standing functions. Often, free standing functions are a 
better solution than members in classes.

The inline keyword forces the compiler to inline code.

The register keyword forces the compiler to use a register for variable.

These are only suggestions to the compiler. The compiler can ignore your suggestions.

That it's just "c-with-classes" or "Complicated-Java-without-gc".
C++ とは、単なる「クラスつきの C」かさもなければ「ガーベジコレクション抜きの複雑な Java」である


Myth:

Everything is an object.

(I really wish it was sometimes)

2010年07月26日

■_

・接近遭遇
GNU Smalltalk の Traits をいじくり中(やや挫折ぎみ) - みねこあ 前回のSmalltalk勉強会のテーマは Traits でした。ふみー、Traits、興味津々ですなぁ。ヨダレガデマス! いくべきだったかも。 みねこあさんと遭遇する瞬間は訪れるのでしょうか (ってこの勉強会わたしも出席してなかったわけですが)

・ごるふ
コードゴルフ自体はとりたてて目新しいものではありませんが、 最近 stackoverflow でぽつぽつ見かけるようになってきていて、 面白いお題がたまにあったりします。 最近見かけたのはこんなの。 http://stackoverflow.com/questions/3324301/code-golf-digital-clock http://stackoverflow.com/questions/1407422/code-golf-seven-segments http://stackoverflow.com/questions/3169051/code-golf-word-frequency-chart http://stackoverflow.com/questions/3230978/code-golf-four-is-magic

■_ 次は?

C とか C++ の次に何をやったらいいのでしょうかというお悩み。


programming language after c/c++ - Stack Overflow

I'm currently in the final year of my b.tech . I'm quite comfortable with c/c++, now i 
want to learn some application oriented programming language which can be used to get 
things done. I tried java for few days, but it didn't seem to arouse any 
interest...need help from experts. thanks

edit::

sorry forgot to mention...i've been working on linux for 2 years , so i don't think c# 
will be a good option

edit :: Due to some technical problem i'm unable to post comments (P.S. .. using 
stackoverflow through proxy, can't use it direct coz it is blocked here) so posting 
them here --

You need expert help to arouse you? ;) 


Try Python.

Teach yourself python.

Edit:
Since you've been working in linux, python would be the best bet since it ships as a 
standard component in most linux distros.
Erlang or Haskell.

Learning a language from another 'paradigm' will teach you a new way of thinking about 
programming and make you a better C/C++ programmer too. Learning another imperative 
o-o language raises the risk that you will learn to write C/C++ programs in the new 
language.

Erlang and Haskell are ideal languages for learning about parallel programming too.

I'd like to suggest C# with the .net framework, since it's much, much, much less 
painful in user-interface design than the Windows API with c++.

Creating a window will no longer take 50 lines of code + callbacks...

Another + of c# is that there's a pretty large developer community, including a 
community part of Stack Overflow itself. In a large community of developers, most of 
the questions you'll have will have already been asked ;-)

A scripting language seems right. If not Python, maybe learn Ruby or Perl.

All three have been used to build great applications.
Depending on what you want to get...

Java, C# are the mainstream. Yes, you can use C# on your Gnu+Linux system (e.g. Novell 
Mono platform). Mono is very popular in Gnu+Linux world, but I am not sure if it is 
popular in industry.

Scala, Erlang, Haskell - very different approach than C. If you want to learn 
something new, I would give them a try. If you will feel comfortable in functional 
languages, you can plan your future in this area. There is quite good chance that they 
will be next big thing in IT.

Ruby, Python - object oriented dynamic languages. If you want to learn something 
really object oriented, they are very good choice. They are leveraging the Object 
Oriented concepts much better than Java or C#. I don't like the concepts of Python, I 
prefer Ruby (but many people do Python).

Getting things done... All the languages I mentioned are good for that... depending on 
what you want to get done:)
Delphi/Pascal are being promoted in the UK over languages like PHP and C# based on it 
being well suited for learning programming concepts. Delphi is also my primary choice 
for development in production.

There is no up to date free version of Delphi (hopefully soon), but Free Pascal is 
available, which supports Linux, among other platforms.

I'd suggest you go for F# - a functional language that runs on the .NET platform. As 
one other answer noted, It will teach you a different paradigm - a different way of 
thinking and solving the problems - and hence make you a better developer overall.

Besides, being hosted on .NET means you can use it for production code too! :)

Also see this thread: Should I learn F# or functional programming languages in general?
I think Tcl makes a perfect second language. Why? Because it challenges you to look at 
programming in a different way. In a sense, it is at the direct opposite of the 
spectrum from C-like languages. Plus, Tcl is very practical and functional. It has 
been my personal go-to language for getting things done for a decade (though 
admittedly, sometimes I choose Python because of it's large 
"batteries-included" library).

Back in 1997 Brian Kernighan declared Tcl one of the software industry's best kept 
secrets.

It's quite likely that sometime in your career you might want/need to implement an 
embedded language in your app (macro language, configuration language, DSL, etc) and 
Tcl is ideal for that -- powerful, yet easy for non-techies to learn.

Tcl is highly portable. It's available on more platforms than just about any other 
language out there, and comes with a cross-platform GUI toolkit that makes it 
remarkably easy to make quick GUI-based tools.

As an added benefit to learning Tcl/Tk, the Tk skills can transfer to Python since it 
includes Tkinter, a python-based implementation of Tk. Not only that but there are Tk 
implementations for Perl and Ruby and LISP.

Many might argue that no big corporations use it, but companies like Oracle, Cisco and 
IBM use it or have used it in their products. It's also been used for 24x7 television 
production, monitoring satellites, as a DSL in medical data systems, and it is my 
understanding pretty much all tools in the EDA world support Tcl.

見事に散らばった回答。

■_ なんだかよくわからない

たぶん何か勘違いしているんだろうけど


シングルコーテーションの入れ替え - Yahoo!知恵袋

お世話になります。

現在、Perlでフォーム内容をメール送信するプログラムを作成しているのですが、CGIのシング
ルクォーテーションとダブルクォーテーションの扱いに引っかかってしまいました。ちなみにシ
ングルとダブルの違い把握しているつもりです。

そこで質問なのですが、フォームの内容を

$text = $inp{'textform1'};

などで入手した場合、どうも$textの内容がシングルクォーテーション扱いになるらしく、この
ままだとこの先の処理に影響が出てしまいます。なんとかダブルクォーテーションの文字列に置
き換えたいのですが、方法がどうしてもわかりません。~ s/'/"/等も効果がありませんし、
変換のようなものも見当たりません。

問題が出るというのは、フォーム内容にソフトバンクの絵文字コードなど(\x1b\$Pe\x0f)が入
力されている場合、シングルだと、そののちのエンコーダーなどを通しても携帯電話で見られる
形式にならないからです(というよりも変数扱いにならないため)。なので、ダブルに置き換え
る必要があるのです。

シングルをダブルに置き換えられればいいのですが…そんな都合よくいかないのでしょうか。

だれかご教授願います。

補足
    言葉が足りていませんでした。申し訳ない。私がしようとしているのは、文字列中のシング
    ルを置き換えるのではなく、text='aaa'であるのを、text="aaa"にしたいという
    ことなのです。~ s/'/"/にオプションを書かなかった所為で誤解させてしまいました。
    もうしわけないです。

シングルクォーテーション扱い? 多分変数名をパラメータで渡してそれが展開されるとかされないとかいう 話だと思うけど。

■_


Top Reasons To Use Lisp

There several reasons to learn a new language. Lisp is on the languages that I like a 
lot, although I haven't been lucky to use it for work.

Here is what I believe are some good reasons to give Lisp a chance:

    * It has a very regular syntax: everything is an s-expression (expression with 
      parenthesis), so there is no surprises in terms of syntax. After you learn how
      to create functions and work with data types, there is not much to worry about.

    * It has a huge library: if you decide to use Common-Lisp, the languages comes 
      already with a ton of useful functions.

    * It is multi-paradigm: unlike Java that forces you to write OO code, Lisp 
      supports several paradigms: functional, OO, declarative (Prolog style), and
      even imperative.

    * Third-party libraries exist: different from a few years ago, libraries for Lisp 
      are available for most applications. There are a few web sites like clbuild that 
      provide all libraries you need in a simple-to-install package.

    * It is a compiled language: unlike languages such as Python and Ruby that are 
      interpreted, Lisp is compiled (to machine language, not to an intermediate
      language such as Java). This makes it extremely fast compared to other dynamic
      languages. Its compiler also has options to generate typed expressions, so that
      you can get the ultimate speed when working with integers and floating point
      numbers.

    * It is a modern language: implementations such as sbcl (available for Windows
      too), and clojure (for Java) make it possible to create modern applications
      that are just as fast as any other language (including C).

■_


The Most Common Debugging Styles

The Most Common Debugging Styles
最も一般的なデバッグスタイル

Debugging code is an activity that shows a lot of the developer's personality. It is a
process that looks a lot like an investigation, leading to the detection of a failure
in an application.

コードをデバッグすることは開発者のパーソナリティの多くをあらわにする activity です。デ
バッグとは investigation (検査、調査) によく似た、アプリケーションに存在する failure 
の検出につながるプロセスです


During the investigation, a programmer has to employ some techniques, like information
gathering, testing of hypothesis, performing quick instrumentation, etc.

調査 (investigation) の間、プログラマーは情報の gathering やhypothesis のテスト、
performing quick instrumentation などのいくつかのテクニックを employ しなければなりま
せん。

When it comes to learning how a program works, though, there are two main “schools”
of debugging: the ones that use print statements, and the ones that use a debugger.

とはいえどのようにプログラムが動作するのかを学ぶようになったときに、デバッグには主に二
つの“学校”があります:ひとつはprint 文を使うものであり、もうひとつはデバッガーを使う
ものです


Print Statements
(Print文)

From these two techniques, certainly printing is the most “primitive”, in the sense
that it is available in almost any programming environment. As long as there is an
output device (which doesn't need to be the screen/stdio), this technique might work.

これら二つのテクニックのうち print するものがもっとも“原始的”(primitive) なものであ
り、ほとんどすべてのプログラミング環境で利用可能です。出力デバイスが存在している限り
(そのデバイスはスクリーンやstdioである必要はありません)このテクニックは使えるでしょう。


The advantage of printing statements is that they are easy to use and program. They
also don't require the program to slow down in order to be used. For example, when
working with multithreaded code, printing may be more useful than debugging, because
it doesn't require one or more of the threads to slow down.

print 文を使うことのアドバンテージはそれを使うのもプログラムするのも簡単だということで
す。この手法はまた、使用する際にプログラムの性能低下を招きません。たとえばマルチスレッ
ドコードとともに動いている場合、print することはデバッギングよりも格段に有用かもしれま
せん。なぜなら、アプリケーションの性能を低下させるスレッドをこの手法は要求しないからで
す


Interactive Debuggers
(対話的デバッガー)

Using a debugger, on the other hand, is not a privilege for everyone. There are many
platforms these days with very decent debuggers; however there are still lots of
environment that don't have one.

一方、デバッガーを使うことはすべての人に対する privilege ではありません。今日では very 
decent なデバッガーを持ったプラットフォームがたくさんあります。とはいえ、そういったも
のを持っていない環境もまだまだたくさんあるのです。


For example, I remember reading somewhere that Linus doesn't create a debugger for the
Linux kernel because he thinks it is not important.

たとえばどこかで読んだ、Linus は Linux カーネル向けのデバッガーが重要なものではないと
考えているのでそれを作らなかったという話をを思い出します


Despite the rant, it is  nice to have a good debugger available. Depending on the
quality of the debugger, it can do some things that would be possible only on dynamic
languages. Things like changing the value of variables during a debug session, or
going up in the call stack and repeating some code path, can be very useful when
determining where a bug is hidden.

Despite the rant,
優れたデバッガーが使用可能であるのは良いことですデバッガーの質に依存することによって動
的言語上でのみ可能であるようなことを行えるようになります。デバッグセッションの間で変数
の値を変更するようなことや、呼び出しスタックの中で going up して一部のコードパスを繰り
返すといったことは、バグが潜んでいる箇所を決定するときに非常に便利な場合があります。


I personally like debuggers, but agree that they should not be an excuse for sloppy
thinking. Some programmers believe that is normal to use debuggers to poke at a
program, instead of stopping and thinking about what the application is doing.

わたし個人はデバッガーが好きですが、
they should not be an excuse for sloppy thinking 
#この“they” って?
には賛成です。一部のプログラマーはプログラムを止めてアプリケーションが行っていることを
考えるのではなく、プログラムに書き込むのにデバッガーを使うことが普通のことであると信じ
ています。


I like to keep in mind that debugging is a research exercise, and it works much better
when we use our head more than the debugger.

デバッグとは research exercise であり、デバッガーよりも自分たちの頭をより一層使ったと
きにより良く働く (works much better) であるということを心にとどめ続けることをわたしは
好みます。

■_ 本日の巡回から

2010年07月25日

■_

・ディスカバリー・チャンネル
BS フジで、ディスカバリーチャンネルセレクションとかいうタイトルで 毎週一本放映しているのですが、今週は 零戦 vs F4F というエピソードでした。 ガダルカナル攻防やらの時期の話がメインでしたが面白かった(内容は知っていることが ほとんどでしたけど)。 日本海軍は戦闘機が3機単位で行動するのに(小隊長機 + 2機)対して 米海軍は4機単位(2機 + 2機)。 あとまあいろいろあるんですが。

■_ ネタ

日付からすると一ヶ月以上前のものですが気がついたのが昨日でした。

【新人研修】プログラマ育成 2年目【社内教育】
904 仕様書無しさん [] 2010/06/17(木) 14:36:10 ID: Be:
    ゲーム系専卒他経験者20人に好きな言語でシンプルなFizzBuzzやらせてみた。
    昔ゲー専講師やってたので経験上まぁ30~50分はかかるだろうな
    こいつらバカだから、って思ってたら7時間後の定時間際に1人だけクリアした。
    でもなんか結果表示がおかしい、途中から素数にFizzが付いてたりとか、
    ソース見たらJavaだったが鬼のような力技コードで、流し読みしただけで2000行あった。
    他は全員リタイア。VSのプロジェクトの組み方が分からないとかいう人もいた。

    (´・ω・`) 俺、来週からこいつらにプログラム教えるんだ・・・ 

905 仕様書無しさん [sage] 2010/06/17(木) 14:53:21 ID: Be:
    なぜ経験者を雇わない・・・
    え?経験者をやとってそのレベル????どうして俺、無職なんだ? 

906 仕様書無しさん [sage] 2010/06/17(木) 15:39:39 ID: Be:
    FizzBuzzで2000行も書けるのはすごい。
    ソースコード水増しの才能がある。 

912 仕様書無しさん [sage] 2010/07/02(金) 01:44:33 ID: Be:
    >>904
    現役ゲー専講師です。副業だけどね。
    スレチかもしれないが、研修1年前の専門2年生はそのような次元じゃない。

    ・C#専攻のくせにConsole.WriteLine()を知らない。当然のようにprintf()?なにそれ食べ物状態
    ・2^nくらい覚えろと言ったらべき乗を誰も知らなかったどころか、3x3(掛け算)も知らん人がいた
    ・変数を過半数が知らない。ググレと言ったら検索ワード「助けてくださいわかりません」
    ・Stateパターンをガチャピンに例えて、中の人が変わることで空手もスノボもできると教えたら
     半数が中の人なんていない!で大騒ぎ、残り半数の人がガチャピンを知らなかった。

    2年生ということで、基本はわかるしサンプル程度の小さいコードは組めるが、
    それがどうゲームに結びつくのかわからん人向けにカリキュラム考えたのに……(´・ω・`) 

913 仕様書無しさん [sage] 2010/07/02(金) 02:36:19 ID: Be:
    >>912
    さすがにネタだよな 

914 仕様書無しさん [sage] 2010/07/02(金) 20:08:11 ID: Be:
    まぁゲーム専門学校なんてゲームで遊んで稼げるなら俺でもいけるんじゃね?みたいなアホが行くところだし 

915 仕様書無しさん [sage] 2010/07/02(金) 21:21:01 ID: Be:
    課題はこなせるのに、それをどう応用したらいいのか理解できない奴が多い 

916 仕様書無しさん [sage] 2010/07/03(土) 02:46:15 ID: Be:
    >>915
    そういうのは本当にこなせてるか怪しいんだけどな。 誰かの課題を写しただけとか、
    ググって適当にコピペしただけとか。 オフショアに出した中国人のソースとかが
    そんな感じだったな。 ちょっと賢いコピペソース製造機みたいな。 

917 仕様書無しさん [sage] 2010/07/03(土) 12:06:02 ID: Be:
    丸暗記は得意みたいだよ
    中身は理解してないけどね

918 仕様書無しさん [sage] 2010/07/07(水) 06:33:51 ID: Be:
    ここのレベル見たら、うちの会社は人選んでるんだなと思うわ
    新卒に200Pに及ぶツールの説明書を3冊渡して、課題与えたら3日足らずで課題に必要な仕様の8割は覚えて応用までしてやがる


    抜かれる…… 

919 緑蛇 [] 2010/07/23(金) 19:20:55 ID: Be:
    >>904
    7時間かかってFizzBuzzとかどんだけ?
    あんなの3分以内にかけるだろまじばかだろ頭湧いてんじゃね

    まじわらっちまうよwwwwwwwwwwww

    クソ企業って本当馬鹿だよなww実技テストとかねえのwwwwかすすぎわらっちまうよ 

■_ コメントの分類


5 Types of Comments to Avoid Making in Your Code

5 Types of Comments to Avoid Making in Your Code

By dhirschl | Published: July 24, 2010

Have you ever been reviewing code and come across a comment that you deemed was 
unnecessary? Commenting your code meant to improve the readability of your code and 
make it more understandable to someone other than the original developer.


I have identified 5 types of comments that really annoy me and the types of 
programmers who make them. I hope after reading this you won't be one who falls into 
one of these categories. As a challenge, you can try to match up these comment 
programmers with the 5 types of programmers.

1. The Proud Programmer

public class Program
{
    static void Main(string[] args)
    {
        string message = "Hello World!";  // 07/24/2010 Bob
        Console.WriteLine(message); // 07/24/2010 Bob
        message = "I am so proud of this code!"; // 07/24/2010 Bob
        Console.WriteLine(message); // 07/24/2010 Bob
    }
}

This programmer is so proud of his code that he feels the need to tag every line of 
code with his initials. Implementing a version control system (VCS) allows for 
accountability in code changes, but at first glance it won't be so obvious who is 
responsible.

#自分を誇るあまりに、自分のイニシャルを全部の行につけなければならないと考えていたり

2. The Obsolete Programmer
   時代遅れのプログラマー

public class Program
{
    static void Main(string[] args)
    {
        /* This block of code is no longer needed
         * because we found out that Y2K was a hoax
         * and our systems did not roll over to 1/1/1900 */
        //DateTime today = DateTime.Today;
        //if (today == new DateTime(1900, 1, 1))
        //{
        //    today = today.AddYears(100);
        //    string message = "The date has been fixed for Y2K.";
        //    Console.WriteLine(message);
        //}
    }
}

If a piece of code is no longer used (i.e. Obsolete), delete it – don't clutter your 
working code with several lines of unnecessary comments. Besides if you ever need to 
replicate this deleted code you have a version control system, so you can recover the 
code from an earlier revision.

#バージョン管理システムがあればこんなことせんでもいいよという話


3. The Obvious Programmer
   明白なプログラマー?

public class Program
{
    static void Main(string[] args)
    {
        /* This is a for loop that prints the
         * words "I Rule!" to the console screen
         * 1 million times, each on its own line. It
         * accomplishes this by starting at 0 and
         * incrementing by 1. If the value of the
         * counter equals 1 million the for loop
         * stops executing.*/
        for (int i = 0; i < 1000000; i++)
        {
            Console.WriteLine("I Rule!");
        }
    }
}

We all know how basic programming logic works – this is not “Introduction to 
Programming.” You don't need to waste time explaining how the obvious works, and
we're glad you can explain how your code functions – but it's a waste of space.

#プログラミングの入門書じゃないんだからこんな馬鹿丁寧なコメントは不要


4. The Life Story Programmer

public class Program
{
    static void Main(string[] args)
    {
       /* I discussed with Jim from Sales over coffee
        * at the Starbucks on main street one day and he
        * told me that Sales Reps receive commission
        * based upon the following structure.
        * Friday: 25%
        * Wednesday: 15%
        * All Other Days: 5%
        * Did I mention that I ordered the Caramel Latte with
        * a double shot of Espresso?
       */
        double price = 5.00;
        double commissionRate;
        double commission;
        if (DateTime.Today.DayOfWeek == DayOfWeek.Friday)
        {
            commissionRate = .25;
        }
        else if (DateTime.Today.DayOfWeek == DayOfWeek.Wednesday)
        {
            commissionRate = .15;
        }
        else
        {
            commissionRate = .05;
        }
        commission = price * commissionRate;
    }
}

If you have to mention requirements in your comments, don't mention peoples names. 
Jim from sales probably moved on from the company and most likely the programmers 
reading this won't know who he is. Not to mention the fact that it everything else in 
the comment is irrelevant.

#要求項目などに言及する必要があるのなら、個人名には触れないこと
#異動があったりするし

5. The Someday Programmer

public class Program
{
    static void Main(string[] args)
    {
       //TODO: I need to fix this someday – 07/24/1995 Bob
       /* I know this error message is hard coded and
        * I am relying on a Contains function, but
        * someday I will make this code print a
        * meaningful error message and exit gracefully.
        * I just don't have the time right now.
       */
       string message = "An error has occurred";
       if(message.Contains("error"))
       {
           throw new Exception(message);
       }
    }
}

This type of comment is sort of a catch-all it combines all the other types. The TODO 
comment can be very useful when you are in the initial development stages of your 
project, but if this appears several years later in your production code – it can 
spell problems. If something needs to be fixed, fix it now and do not put it off later.

# TODOコメントは開発の初期には有用かもしれないけれども、時間が経過したプロジェクト
# では問題になる可能性がある。

If you are one who makes these types of comments or would like to learn best practices 
in comment usage, I recommend reading a book like Code Complete by Steve McConnell. 
This is one of the books that I recommend all programmers should own.

もしこれまでに挙げたようなタイプのコメントをつけたくなったら、コメントの使い方の
best practices を学ぶとよいだろう。コードコンプリートなんかはオススメ。


Or Perhaps you can learn how to stop commenting your code altogether.

Do you see any other unnecessary or annoying comments in your code? Please feel free 
to share.


■_

ベストアンサーに選ぶのが違うんじゃないかと以下略


プログラマ、SE、ゲームプログラマについて - Yahoo!知恵袋

自分は小さいころからコンピュータが好きで、よく触っていました。
中学生のころに、ホームページを作ろうとおもってhtmlというものをはじめて知ったとき、
コンピュータに引き込まれるような衝動を覚え、JavaScriptを結構楽しんでやっていました。

受験と同時にPC禁になってしまったために、プログラミングには触れていたものの、
まだhtmlと出会って数ヶ月の厨房のまま、高校生を迎えました。

高校入学と同時にPCが戻ってきましたので、早速ホームページ(東方)のを作っていたのですが、
そこで、初めてプログラムというものを意識するようになりました。

この東方も、プログラムで動いているんだな・・・・・と感無量な気持ちになり、おれもやりたい!!と、プログラミングの
勉強に取り掛かったのですが・・・・

本当に何も知らなかったのです。無知でした。安易でした。

本屋につくと「Javaからはじめる・・・・」とかいう本があったので、即購入。
このとき自分はJavaというのはJavaScriptの略だと思い込んでいたのです・・・・(笑)

まあ、馬鹿な話はここまでで、きちんと調べてみると、C言語から学ぶのがよい、と知恵袋には書いてありました。
そこで猫プロを購入し、やり始めたのです。

自分は将来、プログラマ、いずれはSEになりたいと考えていましたが、
最近では3Dも学んで、ゲームも作ってみたいと思うようになりました。

長時間労働、低賃金といわれていますが、やってみたいんです。

そこで、本題なんですが、
上記の仕事で働くには、今、どんなことをすればいいんでしょうか。
プログラマとして、働けるのは短いとか、ゲーム業界は就職倍率高いとかは分かっています。

自分がやりたいのは、BGMとかグラフィックではなくて、企画、制作、プログラムという部門です。
多くの質問では、今はともかく旧帝大に入れるように、勉強せよと書いてあります。
学業に関しては、旧帝大狙える程度のものと自負しておりますので一層努力します。

軽音楽部で、勉強もせねば、体力も必要とトレーニング、でも直接プログラミング能力としては
C言語と、Javaをかじった程度です。

でも好きなんです。
考えが甘いのは分かっています。
今、どんなことを勉強すればいいんでしょうか。
ゲームクリエイター、企画制作部門で働きたいことを前提として、ご回答いただきたいです

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

zwigooさん

ゲームクリエーター(プログラマー)の仕事を勘違いしているといけないので、このサイトに目
を通しておいて下さい。

http://www.purplemoon.jp/game/

企画制作とゲームプログラマーを兼用しているのは、小規模な作品で、人も少ない小さな会社ぐ
らいです。今時は珍しい存在だと思います。普通は、完全に分業だと思ってください。

企画制作なら雑学レベルの高い人・人生経験の豊富な人・プレゼン力のある人目指してください。
プログラマならチームワーク力と技術力が必要です。

ここでは、主の技術面で必要な本を紹介します。

1.とりあえずC言語。ポインタや構造体は完璧に理解できないとだめです。
「新版 明解C言語入門編」。
http://www.bohyoh.com/Books/MeikaiC01/index.html
「Cの絵本」http://www.seshop.com/detail.asp?pid=1806
↓
1.5.DXライブラリの学習。ゲームプログラミングの楽しさを味わって下さい。
「DXライブラリ置き場 HOME」http://homepage2.nifty.com/natupaji/DxLib/
「ゲームプログラミングの館」http://dixq.net/g/
「ゲーム作りで学ぶ!実践的C言語プログラミング」http://karetta.jp/book-cover/game-programming
↓
2.基本的なアルゴリズムとデータ構造の学習やデバッグ技法など。DXライブラリと並行で進めて下さい。
「アルゴリズムの絵本」http://www.seshop.com/detail.asp?pid=4179
「新版 C言語によるアルゴリズムとデータ構造」http://www.bohyoh.com/Books/CAlgoData/index.html
「C言語による最新アルゴリズム事典」http://www.amazon.co.jp/dp/4874084141
「C言語 デバッグ完全解説」http://www.amazon.co.jp/dp/4774133620

ここまでが2D編です。プロを目指す人は下に続きます。

3.C++言語。最低限クラスは理解を。
「明解C++」http://www.bohyoh.com/Books/MeikaiCPP/index.html
「独習C++」http://www.amazon.co.jp/gp/product/4798103187/
「ロベールのC++入門」http://www.amazon.co.jp/dp/4839926050/
↓
4.WindowsAPI(OSの仕組み)の学習。途中までで良いですがWindowsのメモリ、プロセス/スレッドは理解してください。
「APIで学ぶWindows徹底理解」http://software.nikkeibp.co.jp/software/backno/04apimook2.html
「Windowsゲームプログラミング」http://wisdom.sakura.ne.jp/system/winapi/index.html
↓
5.DirectXの学習。色々ありますので必要そうなのを。
「ゲームプログラミング入門」http://www.amazon.co.jp/dp/499050061X
「ゲームプログラマになる前に覚えておきたい技術」http://www.amazon.co.jp/dp/4798021180
「DirectX ゲームグラフィックス プログラミング Ver. 2.1」http://www.amazon.co.jp/dp/4797341874
「DirectX9必携」http://www.amazon.co.jp/dp/4990500601
「逆引きゲームプログラミングfor Windows DirectX」http://www.amazon.co.jp/dp/479801169X
↓
6.ゲームアルゴリズム、数学、AIの学習。必要なものを自分でチョイスしてください。
「ゲーム開発のための数学・物理学入門」http://www.amazon.co.jp/dp/4797329076
「ゲームエンジンプログラミング」http://www.amazon.co.jp/dp/4797331976
「実例で学ぶゲーム3D数学」http://www.amazon.co.jp/dp/4873113776
「実例で学ぶゲームAIプログラミング」http://www.amazon.co.jp/dp/4873113393/
「ゲームプログラミングのためのリアルタイム衝突判定 」http://www.amazon.co.jp/dp/493900791X
「3D格闘ゲームプログラミング」http://www.amazon.co.jp/dp/4797341807
「3DRPGプログラミング」http://www.amazon.co.jp/dp/4797330465
「アクションゲームプログラミング」http://www.amazon.co.jp/dp/4797335971
「アクションゲームアルゴリズムマニアックス」http://www.amazon.co.jp/dp/4797338954
「パズルゲームアルゴリズムマニアックス」http://www.amazon.co.jp/dp/4797347090
「シューティングゲーム プログラミング http://www.amazon.co.jp/dp/4797337214/
「シューティングゲームアルゴリズムマニアックス」http://www.amazon.co.jp/dp/4797327316
「弾幕 最強のシューティングゲームを作る!」http://www.amazon.co.jp/dp/4797352299
↓
7.リアリティのための3Dシェーダの学習。必要に応じて。最初はいらないです。
「DirectX 9 シェーダプログラミングブック」http://www.amazon.co.jp/dp/4839912475
「DirectXシェーダプログラミング 仕組みからわかるゲームエフェクトテクニック 」http://www.amazon.co.jp/dp/4797344962
↓
オリジナルゲームの開発。会社によっては提出が必須です。

それとこちらのコラムもチェックしておくこと。
「3Dゲームファンのためのグラフィックス講座」
http://game.watch.impress.co.jp/docs/series/3dcg/
「3Dグラフィックス・マニアックス」
http://journal.mycom.co.jp/column/graphics/index.html


この質問は投票によってベストアンサーが選ばれました!
ベストアンサー以外の回答

「ゲームプログラマになる前に覚えておきたい技術」
http://d.hatena.ne.jp/asin/4798021180
を書いた者です。評判を検索していたところたまたま見つけたので、これも縁かと思い
書き込ませていただきます。これは私の主観ですので、「そういう意見もあるか」
程度に思ってください。

私はまずはC++を道具としてゲームを作ってみることが第一だと思います。
C++はCを含んでいますから、文法要素が多すぎて大変なら最初はCの範囲だけでもかまいません。
私が最初に参加したゲームはPS2のゲームでしたが、Cでした。
言語なんて道具なのでJAVAの方が良ければそれでもかまいませんが、
Cの方が「コンピュータってつまり何をする機械なの?」ということを体で理解しやすいと思います。

また、たくさんのことを覚えるよりも、やり方を自分で考える経験をたくさん積む方が大切です。
DirectXやOpenGLなどは所詮誰かが作ったプログラムにすぎません。
本質はそれによってどんな計算をどのような方法で行うかにあります。
Windowsだって誰かが作ったプログラムにすぎず、Windows上で動くプログラムを作るためには
「やむを得ず」覚えないといけないことがいろいろありますが、やはりそれは本質ではありません。
VisualStudioの使い方だって同じです。極端に言えばC言語の文法すらそうです。
本質は自分が作りたいゲームをどうコンピュータで動く形で表現するか、にあります。

だから、私はたくさんの本を読んで、たくさんのことを勉強することにあまり意味を感じていませんし、
そうした人ができる人だという印象も持っていません(物知りは所詮物知りです)。
「これが必要だからこれをまず勉強しないと」という考え方は、挫折を招きやすく、もともとの目標を忘れさせます。
人間は必要性が納得できないと本当の意味で勉強することはできません。
むしろ「どこまで勉強せずにゲームを作れるか」と逆に考えた方がいいと思います。
DirectXを勉強しないと3Dゲームは作れない、と言う人を私は疑います。
WiiやPS3はDirectXでは動いていません。あれは手段のひとつに過ぎず、
そもそもそんなものがなくても3Dのゲームは作れるのです。
その過程で「ああ、数学ってこういうふうに使うのか」とか、
「アルゴリズムってだから大切なんだ」ということが身に染みて理解できるはずです。
数学やアルゴリズムやDirectXの面白くない本を苦労して読むのはその後でも間に合いますし、
その時ならきっと楽しく読めると思います。
また、本の良し悪しもよくわかるようになって、ハズレな本に高い金を払わずに済むでしょう。
クイックソートで感動するには、クイックソートが必要な状況に出会った経験が必要なのです。
その順序が逆だから挫折する人が多いのだと思います(高校の勉強もそうですよね)。

あとは本の宣伝になってしまいますが、許してください。
私の本はそういった思いを本にしたものです。
DirectXもWindowsプログラミングも一切なしで、
可能な限り最短距離でゲームを作るための「計算の本体」を学べるようにしたつもりです。
中身はDirectXで動いているので、付録のソースコードを見ればDirectXの実際の使い方も
勉強できるかと思います。

以上です。がんばってください。

■_ どういう解釈だろう

ささださんからの挑戦


だいありー
Ruby検定1種:このプログラムの出力を答えなさい。

def foo
  (1 + 2
     + 3)
end

p foo

わざわざこういう問題にするからには、と踏んでそのとおりだったんだけど、 はてなぜそうなるか? 構文定義見るかー

■_ 本日の巡回から

2010年07月24日

■_

・ダムエー
表紙がジオング。オリジン本編にも登場。 シャアがジオング受領するまでの流れがTVやめぐりあい宇宙とは違うけど、 例のセリフは健在(笑) にしても、ドロス強すぎ。

・アフタヌーン
ヴィンサガは今月も以下略

・身分証明書
「公的機関が発行したもの」で「写真つき」で「現住所がわかるもの」 って、それほぼ運転免許証くらいしかないんじゃなかろか (パスポートやらはあれ自分で書き込みますよね?)。

■_ 正規表現の性能比較


Benchmark of Regex Libraries

Introduction

Regular expressions (regex) is often the most convinient approach for parsing text 
files. The performance of regex matching may be critical when the input files are huge, 
which is quite common in analyzing biological data. Most scripting languages support 
regex and there are various C/C++ libraries, too, but surprisingly few have evaluated 
their performance. This page aims to provide a preliminary benchmark on the 
performance of several regex libraries as well as scripting languages.

Design

Input text

The text file for this benchmark is a version of concatenated Linux howto document. 
This file has 39,422,105 bytes, 5,330,321 words and 1,086,077 lines (according to wc). 
The maximum line length is 533 and the median is 33.

Patterns

   1. URI (protocol://server/path): ([a-zA-Z][a-zA-Z0-9]*)://([^ /]+)(/[^ ]*)?
   2. Email (name@server): ([^ @]+)@([^ @]+)
   3. Date (month/day/year): ([0-9][0-9]?)/([0-9][0-9]?)/([0-9][0-9]([0-9][0-9])?)
   4. URI|Email: ([a-zA-Z][a-zA-Z0-9]*)://([^ /]+)(/[^ ]*)?|([^ @]+)@([^ @]+) 

It should be note that the above regular expressions may not be strictly correct or 
the optimal. We just need something to test the performance.

It is also worth noting that matching word boundaries is not required by POSIX regex. 
For the patterns above, we may simply check the character before and after the 
matching region to test if the entire match is a word.

Matching

The benchmarking program reads the file and tests matching line by line. The tailing 
new line character is trimmed as different libraries may treat it differently.

Results

All the benchmark programs or scripts are available at this page. The following table 
shows the performance on a 64-bit Macbook Pro clocked at 2.53GHz with Mac OS X 10.6.4 
and gcc-4.2.1 installed.

Library/program	Algo	UTF-8	Perl	Light	POSIX	URI	Email	Date	Sum3	URI|Email
boost::regex (1.42)	BT	?	Yes	No	No	5.44	1.82	1.15	8.41	9.84
boost::xpressive (1.42)	?	?	Yes	No	No	3.72	1.51	1.22	6.45	7.80
Glib (2.24.1)	?	?	Yes	No	No	1.08	0.84	0.79	2.35	18.02
onig-posix (5.9.2)	BT	Yes	Yes	No	Yes	0.34	0.44	0.41	1.19	10.89
PCRE-posix (8.10)	BT	Yes	Yes	No	Yes	0.67	0.39	0.54	1.60	13.48
RE2 (2010-07-19)	FSA	Yes	Yes	No	No	0.57	0.56	0.55	1.68	0.58
Regex (Mac, 10.6.4)	?	?	No	No	Yes	1.18	0.54	1.28	3.00	19.66
Regex (NCBI, ?)	BT	No	No	Yes	Yes	7.21	9.83	3.45	20.49	22.35
regexp9 (20100715)	FSA	Yes	No	Yes	Similar	1.90	2.12	0.95	4.97	4.55
Tcl (8.5)	?	Yes	No	No	Similar	2.17	1.73	1.52	5.42	3.66
TRE (0.8.0)	FSA	?	No	No	Similar	4.34	2.42	1.73	8.49	8.57
T-Rex (1.0)	?	No	No	Yes	No	4.39	6.45	2.45	13.29	9.35
egrep (GNU, 2.5.1)	?	Yes	No	NA	NA	0.07	0.08	0.10	0.25	0.16
gawk (3.1.8)	?	Yes	No	NA	NA	1.43	1.40	1.38	4.21	1.43
Javascript V8 (2.3.1)	?	?	?	NA	NA	2.30	2.57	1.17	6.04	3.70
nawk (20070501)	FSA	No	No	NA	NA	1.40	1.40	1.40	4.20	1.40
Perl (5.8.9)	BT	Yes	Yes	NA	NA	0.63	0.59	0.52	1.74	10.61
Python (2.6.1)	?	Yes	No	NA	NA	6.37	10.19	2.18	18.74	16.03

    * Column `Algo' indicates the algorithm for regex. `BT'=backtracking, and 
      `FSA'=finite state machine.

    * Column `UTF-8' indicates if the library explicitly supports UTF-8 encoding. See 
      also the Unicode section on wiki.

    * Column `Perl' denotes if the library supports advanced perl-compatible syntax, 
      such as word boundaries and back reference.

    * Column `Light' shows whether the library is implemented in two files: a header 
      and a source file. Such two-file libraries can be easily included in a 3rd-party 
      program at the source-code level, which makes the 3rd-party program less dependent
      on external APIs.

    * Column `URI', `Email' and `Date' give the CPU seconds for finding all matching 
      lines given the three regular expressions above, respectively. Column `Sum3'
      gives the sum of CPU seconds for `URI', `Email' and `Date'.

    * T-Rex gives additional matching lines for `URI', which is incorrect. 


Discussions

Note: boost::xpressive, Glib, Tcl and V8 were added later. The discussions below did 
not consider these implementations.
boost::xpressive や Glib, Tcl, V8 はあとから追加されたもので、このあとの disucussion
では触れられていない。

Backtracking vs. state machines

Regex libraries are typically implemented with backtracking (BT) or finite state 
machine (FSA). The former approach is more flexible but can be exponential in time 
given some regex. The latter guarantees polynomial time in searching, but usually less 
flexible. RE2 is believed to be the only library that uses FSA and supports Perl-like 
syntax at the same time.
#よくある NFA か DFA かとかいうあたりの話
# って RE2 が FSA 使いながら Perl-like syntax を同時にサポートしているって?

In practice, implementations based on BT and FSA seem to have similar performance on 
short regex. However, FSA may greatly outperform BT given the `|' operator in regex. 
This means for BT-based implementations, matching with multiple regex is preferred.

Speed of C/C++ regex libraries

For `|'-free regex, onig is the winner. PCRE and RE2 are similar in performance. The 
regex library from Mac OS X is comes in the next place. Of the three light-weight 
library, only regexp9 is close to the performance of matured libraries. TRE and 
boost::regex are nearly 8X slower than onig on `|'-free regex.. The T-Rex and NCBI 
port of regex are the slowest implementations.

For `|'-contained regex, the results are changed a lot. RE2 clearly beats all the rest. 
Regexp9 and TRE, the other two FSA based libraries come in the second and the third 
places, respectively. Several BT-based algorithms such as onig and PCRE are 10X slower 
than using two regex separately, although this is not true for all BT-based algorithms.

#あー、| が入ると、DFA構築するタイプのほうが早くなるだろうなあ。
#NFAのままでこの種の最適化できるのかな…できなかないか。Perl のモジュール
#みたいに(名前失念)与えられた正規表現の変形をすれば。

Speed of standalone programs and scripting languages

GNU's egrep is fast mainly because it hybridizes regex matching with Boyer-Moore 
search. I do not know how exactly this is done, but I do hope other regex may adopt 
this heuristics. On all the regex I have tried, egrep is the fastest. Another possible 
reason that egrep is fast may be because it does not keep track of grouping.

Perl is surprisingly fast as a scripting language. Python, on the contrary, is 
surprisingly slow. I heavily rely on regex for parsing huge text files. This benchmark 
tells me that python, although faster than perl in other applications, is not the 
right language for me.

#Perl最速と。

C vs. C++

I used PCRE's POSIX APIs in the table above. If I use its C++ APIs, PCRE becomes 10% 
slower. C++ interfaces incur minor overheads.

#C++インターフェースを使うとちょっとしたオーバーヘッドによって速度低下(10%?)と。

For boost::regex, I implemented two versions: one uses the fgets() libc API and the 
other uses std::getline() to read into a C++ string. The already-slow boost::regex 
becomes 50% slower, which means 50% CPU time goes to a function as simple as getline()! 
Why not implement getline() by calling fgets()?

#C++は入力でもオーバーヘッドがありましたよ。と。
# Why not implement getline() by calling fgets()? つーてもなあ

Alternative benchmarks

Russ Cox, the developer of the RE2 library, evaluated the performance of RE2 and PCRE. 
He seems to be using long texts, while my programs match line by line. The results may 
not be comparable.

Google search will bring us to this page. The conclusion broadly agrees with mine: 
PCRE is significantly faster than boost::regex. Nonetheless, that benchmark is not 
performed in a realistic context.

This page evaluates the performance of regex matching of several scripting languages. 
It also points out that python is slower in regex matching. Another interesting 
conclusion from that page is perl is efficient given `/FOO/ || /BAR/' but very 
inefficient given `/FOO|BAR/'. So I also added this type of regex to my benchmark.

The regex-dna benchmark from The Computer Language Benchmarks Game shows that Python 
is faster than Perl. This may be related to Perl's inefficiency given `/FOO|BAR/'. I 
have not tested this, though.

Conclusions

Before I did this benchmark, I thought all regex implementations are similar in 
performance, like what happens to the hash table libraries. To my big surprise, the 
fact is the contrary. The performance varies a lot between implementations and between 
regex. Most widely used implementations such as boost::regex, Python, Perl and gawk 
all have striking weakness.

(略)

これ、最初に見たときは gawk のデータがすっげー遅いもの(桁違いに)だったのだけど


Benchmark on C/C++ regex libraries and scripting languages : programming

Benchmark on C/C++ regex libraries and scripting languages (lh3lh3.users.sourceforge.net)


A Regex benchmark without Henry Spencers implementation aka the TCL Regex Engine is 
futile. Last time, the computer language shootout included it, it beat boost and pcre.

It would also be nice to include, that oniguruma is the regex engine powering ruby.

I have just added Tcl-8.5. That shootout C program is using regex like 
"[cgt]gggtaaa|tttaccc[acg]", while PCRE is very inefficient given the `|' 
operator. My guess is if the shootout implementation uses something like 
'/[cgt]gggtaaa/ || /tttaccc[acg]/', it will be much faster. Thanks for the suggestion.


Cool, thanks. You don't have to update that, but for the record:

    * TCLs regex is Unicode (you shouldn't call it UTF-8 since that is only an 
      encoding, true unicode support means much more than only matching wide characters)

    * uses a Hybrid approach (depending on the given regex, the "best" 
      approach is used)

    * and is somewhere on the net available as what you call "light".


It's a very poor point.

Some say Life is just a game, and who wins depends on how you define the rules.

The generality - who wins depends on how you define the rules - also applies to things 
not usually considered games.

Games can be just as serious as other forms of human activity - gladiatorial games, 
the Olympic games, El Copa Mundial, ...

And of course, games can be informative.

I am surprised to see Python re being so much slower than Perl.


Regexes are Perl's trademark, it isn't surprising they would optimize them more than 
Python's devs would.


V8-darwin-x86 added. For regex with the `|' operator, it is much faster than Perl/PCRE; 
otherwise it is slower. The Shootout is picking regex particularly bad for many 
implementations.

Apparently egrep is the fastest. Why isn't it pushed forward ? Are the sources 
available ? Does the linux version have the same results ?


I don't have the time to check right now, but since the userland of Mac OS X is taken 
from FreeBSD, the egrep implementation stems probably from there.


Actually Darwin uses GNU's grep-2.5.1. The source code is available here. But I have 
not read the source code, though.
Just like FreeBSD, now that I had some time to check it.

Some cites from the README that seem relevant to the topic:

    This is GNU grep, the "fastest grep in the west" (we hope).

    GNU grep is based on a fast lazy-state deterministic matcher (about twice as fast 
    as stock Unix egrep) hybridized with a Boyer-Moore-Gosper search for a fixed string 
    that eliminates impossible text from being considered by the full regexp matcher 
    without necessarily having to look at every character. The result is typically many 
    times faster than Unix grep or egrep. (Regular expressions containing backreferencing 
    will run more slowly, however.)

gawk is slowest because it uses an old version of its DFA matcher. With the latest 
changes that went into grep 2.6.3 it should be alright.

Gawk-3.1.8 is the latest, released on 05/07/2010. Perhaps I should try an older 
version?

EDIT: Mac is using nawk. It appears to me that it uses lex/flex to perform regex
matching. You may say the speed of nawk comes from flex which is based on FSA, I 
believe.

EDIT: I was wrong. I invoked gawk with LCALL=utf8 (or similar). If I use LCALL=C, it 
is must faster. Gawk is updated. Sorry.

Aha, I missed this release. Still, I expected gawk in UTF-8 mode to be faster.

LC_ALL= であんなに変わったっけ? grep ならよくレポートされていることだけど。

■_ なんで

「サイトを教えてください」なんでしょね。 回答する側が、回答欄では書ききれないからとかで例示するならわかるんだけど 最初からサイト教えろねえ。



プログラムに書かれる"%"記号の意味や使い方について、わかりやすい解説 | OKWave
プログラムに書かれる"%"記号の意味や使い方について、わかりやすい解説

プログラムに書かれる"%"記号の意味や使い方について、わかりやすい解説サイトが
あったら教えてください、よろしくお願いします。

■_ 月例リリース

29日のリリースとは別扱いなのか。


coke at blogs.perl.org: Announce: Rakudo Perl 6 development release #31 ("Atlanta")

Announce: Rakudo Perl 6 development release #31 ("Atlanta")
By coke on July 23, 2010 5:08 AM

Announce: Rakudo Perl 6 compiler development release #31 ("Atlanta")

On behalf of the Rakudo development team, I'm happy to announce the July 2010 
development release of Rakudo Perl #31 "Atlanta". Rakudo is an 
implementation of Perl 6 on the Parrot Virtual Machine (see http://www.parrot.org). 
The tarball for the July 2010 release is available from 
http://github.com/rakudo/rakudo/downloads.

Please note: This is not the Rakudo Star release, which is scheduled for July 29, 2010. 
The Star release will include the compiler, an installer, modules, a book (PDF), and 
more.

The Rakudo Perl compiler follows a monthly release cycle, with each release named 
after a Perl Mongers group. The July 2010 release is code named "Atlanta" in 
recognition of Atlanta.pm and their Perl 5 Phalanx project, which they selected for 
its benefits to Perl 6.

Some of the specific changes and improvements occurring with this release include:

    * Rakudo now properly constructs closures in most instances.

    * Undefined objects can now autovivify into arrays or hashes when subscripted with 
      .[ ] or .{ }.

    * Arrays can now handle infinite ranges.

    * Generic, multi-level Whatever-currying now works, e.g. (1, 1, *+* ... *).

    * The REPL shell now remembers lexical declarations in susbsequent lines.

    * The open()` subroutine now returns a Failure instead of throwing a fatal exception.

    * Rakudo now provides $*ARGFILES for reading from files specified on the command line.

    * Added $*PERL, moved %*VM to $*VM.

    * Simple binding operators := and ::= now work.

    *Simple feed operators <== and ==> now work.

For a more detailed list of changes see docs/ChangeLog.

(略)

The next release of Rakudo (#32) is scheduled for August 19, 2010. A list of the other 
planned release dates and code names for 2010 is available in the 
"docs/release_guide.pod" file. In general, Rakudo development releases are 
scheduled to occur two days after each Parrot monthly release. Parrot releases the 
third Tuesday of each month.

■_

いなばさんあたりにはまた~と云われるネタですがw 今月号の日経ソフトウエアから。

日経ソフトウエア2010年9月号 Google Goプログラミング入門
第3回 “Go流”オブジェクト指向とポインタ

p82
Goは基本的に「値渡し」

 ここで、「値渡し」と「参照渡し」の概念を確認しておきましょう。Go言語の
変数同士の代入や、関数間における値の受け渡し方は「値渡し」が基本です(図2)。
ただし、map型とchannel型の変数だけは参照渡しされます。

  

いやそれ違うでしょ>参照渡しされる 最初のページの著者紹介のところに http://golang.jp でGo言語のドキュメントを翻訳しています。 とかあるんだけど、


プログラミングFAQ - Google's Go Guide

関数パラメータは値渡しか?

Go言語では、すべて値渡しです。関数は常に、値をパラメータに代入する代入ステートメントが
あるかのように、渡されたもののコピーを受け取ります。たとえば、ポインタの値をコピーする
ことは、それが指し示すデータではなく、ポインタのコピーを製作します。

マップおよびスライスの値は、ポインタのように振舞います。これらは、内部のマップまたはス
ライスデータへのポインタを持つデスクプリタです。マップまたはスライスの値をコピーしても、
それが指し示すデータは複製しません。インタフェースの値をコピーすると、そのインタフェー
スの値に格納されているものをコピーします。インタフェースの値が構造体を格納しているとき
に、そのインタフェースの値をコピーすると構造体のコピーを製作します。インタフェースの値
がポインタを格納しているときに、そのインタフェースの値をコピーすると、これもまたポイン
タが指し示すデータではなく、ポインタのコピーを作成します。

分業しててほかの方が訳されたとかなんでしょうか?

参考までに原文。


Programming FAQ
Pointers and Allocation

When are function paramters passed by value?

Everything in Go is passed by value. A function always gets a copy of the thing being 
passed, as if there were an assignment statement assigning the value to the parameter. 
For instance, copying a pointer value makes a copy of the pointer, not the data it 
points to.

Map and slice values behave like pointers; they are descriptors that contain pointers 
to the underlying map or slice data. Copying a map or slice value doesn't copy the 
data it points to. Copying an interface value makes a copy of the thing stored in the 
interface value. If the interface value holds a struct, copying the interface value 
makes a copy of the struct. If the interface value holds a pointer, copying the 
interface value makes a copy of the pointer, but again not the data it points to.

Should I define methods on values or pointers?

slice と channel がどうなのかわからんけど、 少なくとも map については言及されてますし、 Everything in Go is passed by value. ってある。Javaでも同様なことが起きてますが、なんでこうなるんでしょうか? 教えていなばさん。

■_ 本日の巡回から

2010年07月23日

■_

・いろいろ
OVA BLACK LAGOON Roberta's Blood Trail Blu-ray001〈初回限定版〉[Blu-ray]
んー新アレンジのOP、やっぱ微妙な感じがする。 時間も短いので物足りないし。
白翼ノ誓約‾Pure Engagement‾/おんなじきもち 初回生産限定盤
好みで言えば、1期のOPの方が…
絵で見る十字軍物語
1巻は前振りで2~4がお話仕立て?
テルマエ・ロマエ I (BEAM COMIX)
ようやく読みました。蛮族(平たい顔族)からも学ぶ研究熱心な主人公えらい。

■_ Fun with series


Fun with series « Just Rakudo It 

Fun with series

By colomon

On #perl6 this morning, rokoteko was curious about doing Taylor series in Perl 6. This 
sort of thing fascinates me, so I quickly coded up this:

1	sub sine-power($x) {
2	    my $sign = 1;
3	    gather for 1, 3 ... * -> $n {
4	        take $sign * $x ** $n / [*] (1 ... $n);
5	        $sign *= -1;
6	    }
7	}

That works, and is pretty straightforward. However, it's got one big glitch in it, 
IMO. Even if you feed it a Rat input, it will always return a list of Nums, because $x 
** $n returns a Num. (Hmmm…. might that be worth changing?)

No problem, you just need to complicate the function a bit by keeping running products 
for the numerator and denominator:

01	sub sine-power($x) {
02	    my $sign = 1;
03	    my $x-part = $x;
04	    my $denom = 1;
05	    gather for 3, 5 ... * -> $n {
06	        take $sign * $x-part / $denom;
07	        $sign *= -1;
08	        $x-part *= $x * $x;
09	        $denom *= $n * ($n - 1);
10	    }
11	}

As a bonus, the new version should be faster.

Let's see if it works:

01	> say sine-power(0.1).munch(4).perl;
02	(1/10, -1/6000, 1/12000000, -1.98412698412698e-11)
03	 
04	> say ([+] sine-power(0.1).munch(3)).perl;
05	1198001/12000000
06	 
07	> say [+] sine-power(0.1).munch(3);
08	0.0998334166666667
09	 
10	say sin(0.1);
11	0.0998334166468282

As you can see, this generates a Rat approximation for sin(0.1) which is accurate to 
10 decimal places. Not bad!


範囲指定で終端を指定しなくても良い(無限ストリーム?)とか Inf があるとかいいなあ。 にしてもハイパー演算子はまだよくわからん。

■_ モナドと

関数型プログラミング言語Haskell Part12 
608 デフォルトの名無しさん [] 2010/07/22(木) 01:43:46 ID: Be:
    Haskellってオブジェクト指向プログラミングはどうなってるの? 

609 デフォルトの名無しさん [sage] 2010/07/22(木) 05:55:55 ID: Be:
    ポリモーフィズムもカプセル化もできるぞ 

610 デフォルトの名無しさん [sage] 2010/07/22(木) 06:40:56 ID: Be:
    >>608
    モナドやクロージャで代替できる 

611 デフォルトの名無しさん [sage] 2010/07/22(木) 08:08:51 ID: Be:
    モナドとモコナはどう違うのか
    永遠の謎 

612 デフォルトの名無しさん [sage] 2010/07/22(木) 08:11:58 ID: Be:
    モナドは「ぷぷぅ」って言わない 

613 デフォルトの名無しさん [sage] 2010/07/22(木) 12:43:26 ID: Be:
    しかし、モコナはモナドだ 

614 デフォルトの名無しさん [sage] 2010/07/22(木) 16:43:42 ID: Be:
    どう違うのかっていわれても、同じオブジェクトが見方によってモナドだったりそうでなかったりするんだよ 

615 デフォルトの名無しさん [sage] 2010/07/22(木) 16:55:24 ID: Be:
    モナド可愛いよね 

616 デフォルトの名無しさん [sage] 2010/07/22(木) 18:04:03 ID: Be:
    黒モナドモドキ
    白モナドモドキ 

617 デフォルトの名無しさん [sage] 2010/07/22(木) 18:34:07 ID: Be:
    ホワイトボックスとブラックボックスの違いみたいなもんか 

618 デフォルトの名無しさん [sage] 2010/07/22(木) 20:03:42 ID: Be:
    昔は白モナドが美味しそうだったが、
    最近はアルコール度数が高い黒モナドの方が美味しそうに思えてきた 

619 デフォルトの名無しさん [sage] 2010/07/22(木) 20:06:30 ID: Be:
    何の話だよ 

620 デフォルトの名無しさん [sage] 2010/07/22(木) 21:26:19  ID: Be:
    何の話って、モナドだろ? 

621 デフォルトの名無しさん [sage] 2010/07/22(木) 21:31:54 ID: Be:
    これはただのモナドではございません、山吹色のモナドでございます。 

622 デフォルトの名無しさん [sage] 2010/07/22(木) 21:38:54 ID: Be:
    >>611
    よかったな
    イレ食いだぞ 

■_ SAS

Oracle とどっちが金に…Oracle かなあ。


SAS、「SAS グローバル認定プログラム」の日本語版を提供開始 | 経営 | マイコミジャーナル

SAS Institute Japanは7月22日、SAS製品について深い知識を持つプロフェッショナルを認定す
る制度「SAS グローバル認定プログラム」の日本語版を9月より提供開始すると発表した。初め
に、SASプログラミングの試験をスタートし、順次、試験の種類を増やしていく。

(略)

SAS認定プロフェッショナルが1999年にスタートして以来、資格取得者は世界で2万8,000人を超
える。その数は2007年から急増しており、「分析に対するニーズの高まりとともに資格取得者も
増えてきている」と同氏。

米国ではSASプログラミングの資格を取得することで、給与水準が上がっているケースもあると
いう。

(略)

資格取得者は、認定証が発行されるほか、認定ロゴマークを名刺に印刷することができる。また、
同社が提供している有資格者のデータベースに登録される。同データベースは検索が可能なため、
有資格者とビジネスをしたいという企業とのマッチングにも対応している。

同試験では60~70の問題が出題され、選択方式で回答していく。試験の申し込みはプロメトリッ
クで行う。また12月末まで、研修の価格が10%引きで試験が無償のバリュー・パッケージが提供
される。「SAS認定プロフェッショナルSAS Base Programmer for SAS 9」向けのプランの価格は
31万1,850円、「同 Advanced Programmer for SAS 9」向けプランの価格は36万3,825円となって
いる(いずれも税込)。

すげー値段だ。 まあSASの個人ユーザーなんてほぼ皆無だろうしなあ。

■_ never


Journal of masak (6289)

6 built-ins in Perl 6 that you never knew you needed
(あなたが決して知る必要のなかった Perl 6の六つの組み込みメソッド)
[ #40459 ]

.pick

say @deck.pick();                   # pick a card, any card...

say @deck.pick(5);                  # poker hand

my @shuffled = @deck.pick(*);       # here, '*' means 'keep going'

my @urn = <black white white>;      # beads, 1/3 black, 2/3 white
.say for @urn.pick(50, :replace);   # put back after each pick

for @urn.pick(*, :replace) {
    .say;                           # infinite bead picker
}

say [+] (1..6).pick(4, :replace);   # 4d6

(略)

.classify

my @names = <Patrick Jonathan Larry Moritz Audrey>;
say .key, "\t", ~.values
    for @names.classify( *.chars );

# Output:
# 5       Larry
# 6       Moritz Audrey
# 7       Patrick
# 8       Jonathan

.say for slurp("README")\            # whole file into string
         .words()\                   # split into list of words
         .classify( *.Str )\         # group words w/ multiplicity
         .map({; .key => .value.elems })\
                                     # turn lists into lengths
         .sort( { -.value } )\       # sort descending
         .[ ^10 ];                   # 10 most common words

class Student {
    has Str $.name;
    has Int $.grade is rw;
}

my Student @students = get-students();
for @students.classify( *.grade ).sort -> $group {
    say "These students got grade $group.key():";
    say .name for $group.value.list;
}

.sort

# 1 if $a is higher, -1 if $b is higher, 0 if equal
$a <=> $b;

# sort students according to grade
@students.sort: -> $a, $b { $a.grade <=> $b.grade };

# same thing
@students.sort: { $^a.grade <=> $^b.grade };

# same thing
@students.sort: { .grade };

# same thing
@students.sort: *.grade;

# leg gives -1, 0 or 1 according to lexicographic ordering
# 'leg' is for Str, 'cmp' is now for type-agnostic sort
$a leg $b;

# sort students by name (Unicode order)
@students.sort: { $^a.name leg $^b.name };

# same thing
@students.sort: *.name;

# don't worry, things are properly cached; no re-evaluations
@items.sort: *.expensive-calculation();

# ...which means this works (and is a fair shuffle)
@deck.sort: { rand }

# ...but this is cuter :)
@deck.pick(*);
Operator overloading
演算子オーバーロード

sub infix:<±>($number, $fuzz) {
    $number - $fuzz + rand * 2 * $fuzz;
}
Mu()
say 15 ± 5;                          # somewhere between 10 and 20

(略)

sub postfix:<kg>(Numeric $payload) { Physical::Unit.new( :kg(1), :$payload ) }
sub postfix:<m>(Numeric $payload) { Physical::Unit.new( :m(1), :$payload ) }
sub postfix:<s>(Numeric $payload) { Physical::Unit.new( :s(1), :$payload ) }

# Note how we now use 'multi sub', so as not to shadow the original infix:<*>
multi sub infix:<*>(Physical::Unit $a, $b) {
    $a.clone( :payload($a.payload * $b) );
}

multi sub infix:<*>($a, Physical::Unit $b) {
    $b.clone( :payload($a * $b.payload) );
}

multi sub infix:<*>(Physical::Unit $a, Physical::Unit $b) {
    $a.multiply($b);
}

multi sub infix:</>(Physical::Unit $a, $b) {
    $a.clone( :payload($a.payload / $b) );
}

multi sub infix:</>($a, Physical::Unit $b) {
    $b.invert.clone( :payload($a / $b.payload) );
}

multi sub infix:</>(Physical::Unit $a, Physical::Unit $b) {
    $a.multiply($b.invert);
}

say 5m / 2s;                         # 2.5 m s**-1
say 100kg * 2m / 5s;                 # 40 kg m s**-1

infix:<Z>

# Z (the 'zip operator') means "mix these lists together"
my @tastes = <spicy sweet bland>;
my @foods = <soup potatoes tofu>;
@tastes Z @foods; # <spicy soup sweet potatoes bland tofu>

# » means "call the method for each element"
.say for @students».grade;                 # all the grades

for @students».name Z @students».grade -> $name, $grade {
    say "$name got a $grade this year";
}

# Note that the latter list is infinite -- it works anyway
for @students».name Z (1..6).pick(*, :replace) -> $name, $roll {
    say "$name rolls a $roll";
}

# you can also Z together two lists with an infix op
my @total-scores = @first-scores Z+ @second-scores;

# strings as keys, the appropriate number of 1s as values
my %hash = @names Z=> 1 xx *;              # xx is list repeat

# line people up with increasing numbers
my %people2numbers = @people Z=> 1..*;

# don't have a good op? roll your own!
sub infix:<likes>($liker, $likee) { "$liker is fond of $likee" }
# note how the op infix:<Zlikes> is automatically available
my @relations = @likers Zlikes @likees;

infix:<...>

1 ... $n                                    # integers 1 to $n
$n ... 1                                    # and backwards

1, 3 ... $n                                 # odd numbers to $n
1, 3, ... *                                 # odd numbers
1, 2, 4 ... *                               # powers of two
map { $_ * $_ }, (1 ... *)                  # squares

1, 1, -> $a, $b { $a + $b } ... *           # fibonacci
1, 1, { $^a + $^b } ... *                   # ditto
1, 1, *+* ... *                             # ditto

'Camelia', *.chop ... '';                     # all prefixes of 'Camelia'

# See http://blog.plover.com/CS/parentheses.html
# for the principle behind this
sub next-balanced-paren-string($s) {
    $s ~~ /^ ( '('+ ) ( ')'+ ) '(' /;
    [~] $s.substr(0, $/.from),
        "()" x ($1.chars - 1),
        "(" x ($0.chars - $1.chars + 2),
        ")",
        $s.substr($/.to);
}

my $N = 3;

my $start = "()" x $N;
my &step = &next-balanced-paren-string;
my $end = "(" x $N ~ ")" x $N;

for $start, &step ... $end -> $string {
    say $string;
}

# Output:
# ()()()
# (())()
# ()(())
# (()())
# ((()))

Rakudo Star releases in a week, July 29th.

pick が…

■_ 本日の巡回から

2010年07月22日

■_

まあ色々あってですね。

■_


Rubyについて Part 40 [chaika]
810 デフォルトの名無しさん [sage] 2010/07/22(木) 07:10:47 ID: Be:
    Rubyみたいな言語を1から作るまでを本にして出してくれないかな。
    入門書じゃなくてさ、本当にRubyみたいなのを作れるまでをかいてほしい。
    途中、他の分野の知識が要るときはリファレンスを示してくれるだけでもいい。
    3万円くらいまでなら出せる。 

811 デフォルトの名無しさん [sage] 2010/07/22(木) 07:39:34 ID: Be:
    Luaならそんな感じの本があったような 

812 デフォルトの名無しさん [sage] 2010/07/22(木) 08:00:59 ID: Be:
    lisp なら一冊か二冊。 

813 デフォルトの名無しさん [sage] 2010/07/22(木) 08:03:49 ID: Be:
    本気で現在のレベルのRubyを作れるまで、というのは少々無理な相談だぞ。
    前橋氏の本は見てみた? 

814 デフォルトの名無しさん [sage] 2010/07/22(木) 08:13:25 ID: Be:
    RubyとかGaucheとか実装できる人になりたひ 

815 デフォルトの名無しさん [sage] 2010/07/22(木) 08:16:06 ID: Be:
    >>810
    RHG 

RHG は完成しているものの解説であって、作っていく本じゃないからちょっと違うような気も。 って内容は被るか。

■_

本日の投げっぱなしじゃーまん


5 Reasons Why C++ Is Wrong For You

the guide to your digital life

5 Reasons Why C++ Is Wrong For You
(C++ があなたにとって適切なものでない五つの理由)

by Matt on June 2, 2010

DISCLAIMER: C++ is great. I mostly code in C++. This is not a post about bashing C++ 
in general. It's about dispelling some specific, ill-founded beliefs I've seen among 
new programmers as to why C++ is a good language with which to start as a developer.

おことわり: 
C++ は great です。わたしは大半のコーディングを C++ で行っています。本ポストは C++ 叩
きをしようというものではありません。ここで書こうとしているのは、わたしが新米プログラマ
ーたちの中で見てきたC++ が with which to start as a developer として優れた言語 (good 
language) であるというsome specific な ill-founded な迷信の dispelling です。


Let's face it: games are sexy. Games are, almost universally, written in C++.
Ergo, C++ is sexy.


This chain of logic begets many an expedition by bright-eyed programmers to sites like 
GameDev.net, where they seek out, with laser-beam focus, anything and everything C++. 
But is this the right way to approach the field of software development? Is C++ really 
the right the language for you?

この論理の連鎖 (chain of logic) は
GameDev.net のような bright-eyed programmers to sites  によって
多くの expedition (遠征?) を招きました。
where they seek out,
with laser-beam focus,
彼らが laser-beam focus を使って探し求めた anything and everything C++. 
しかしこれは、ソフトウェア開発のフィールドへのアプローチの方法として正しいものなのでしょうか?
C++ は本当にあなたにとって適切な言語なんでしょうか?



The surprising answer is, probably not. And here's 5 reasons why.

それに対する surprising な回答は、「おそらく違う」です。以下に五つの理由を挙げます。


1. It's hard! (that's what she said)
   難しい!

I know, dear reader, that you are an irrepressible overachiever. I understand that 
you've never gotten a B in your life. I empathize with your masochistic desire to do 
everything the hard way or no way at all.

親愛なる読者の皆様方が irrepressible overachiever であることはわたしも存じております。
あなた方がこれまでの人生の中で一度として B をとったことのないこともわかっています。
わたしはあなたがたの、do everything the hard way or no way at all のための
masochistic な desire に共感します。


But sometimes, it just makes you a prick.

しかしそれが時にはただ単にあなたがたを苦しめるだけのこともあります。


C++ is difficult, and its worth to you as a programmer is not necessarily commensurate 
with this difficulty. Its syntax can be unwieldy. It's got approximately 87 trillion 
nasty little quirks that you won't recognize until they crash your demo in front of 
the executive board. And if you plan to so much as glance towards template 
metaprogramming, be prepared for three quarters of your brain to ooze out through your 
nasal passages.

C++ は難しく、そして its worth to you as a programmer (プログラマーとしてのあなたに対する
価値?) はこの難しさと等価 (commensurate with this difficluty) である必要はないのです。
C++ の構文は unwieldy (非効率、不恰好) です。C++ には、
executive board の前であなたのデモがクラッシュでもしない限り認めたくはないような
おおよそ 87 兆 (87 trillion) の nasty little quirks があります。
そしてもしあなたがテンプレートメタプログラミングの glance towards (ざっと見る?) を
計画しているのなら、
be prepared for three quarters of your brain to ooze out through your nasal passages.
(nasal passages を通じてあなたの脳みその 3/4 が ooze oout してしまうことに備えてください)



And while difficult isn't necessarily equal to bad, it is equal to time-consuming. It 
will take you months to become familiar with the language, and years to master it. And 
with other, easier options available (like Python and C#), you should make sure, 
before diving headlong into development, that C++ is really the right choice for you.

難しいということは bad であることに等しい必要はありませんが、時間の浪費 
(time-consuming) であることには違いありません。この言語に慣れ親しむのに数ヶ月を要し、
マスターするのには数年かかります。
And with other,
頭から開発にどっぷりとつかってしまう前に、
(Python や C# のような) より簡単な選択肢がないか、
C++ が本当にあなたにとって正しい選択であることを確かめておくべきでしょう。


2. It's stagnant
#stagnat → 淀んだ、停滞している

The following chart is from Indeed.com, a popular job search website. It plots the 
number of job postings for a few programming languages over the last 5 or so years.

以下にあるチャートは人気のある仕事探しのサイトである Indeed.com にあったもので、
幾つかのプログラミング言語に対する過去五年ほどの求人の数をプロットしたものです。

jobgraph thumb 5

Reasons Why C++ Is Wrong For You 


First of all, if any of you have any clue what made HTML jobs jump like a flopping 
fish around Summer ‘08, I'd love to hear about it.

まず始めに、2008年の夏ごろに HTML jobs を flopping fish のようにジャンプさせた
なんらかの clue をあなたが持っていたら是非それについて聞きたいと思います。

But more importantly, take a look at the C++ line, in orange. Its trend is pretty much 
horizontal, meaning little to no growth. All the other lines are generally 
upward-sloping, indicating growing numbers of job offerings. The differences become 
startlingly clear when you plot each language in terms of its percentage growth over 
the same period:

しかしもっと重要な、C++ を示すオレンジ色のラインに注目してください。そのトレンドはとて
も水平に近いもの、すなわちほとんど成長していない (little to no growth) ことを意味して
います。そのほかの線はすべて右肩あがりになっていて (generally upward-sloping) 、求人の
数が増えていることを示しています。その違いは、同じ期間での成長率を言語ごとにプロットし
てみると startlingly に clear です


jobgraph 2


First of all, notice how quickly PHP is growing. It dwarfs everything else on the 
graph. But also notice which language is the clear loser. And if PHP wasn't screwing 
up the scale, the differences between C++ and Java or HTML would be even more 
pronounced.

まず、 PHP がどれほど急速に成長しているかに注目してください。PHP はグラフ上の自分以外
のものを小さく(dwarf) してしまっています。しかし同時にどの言語が clear loser (明白な敗者)
なのかを示しています。仮に PHP がこれほどの scale で成長していなければ、C++ と
Java や HTML との間の差違はよりわかりやすいものになっていたでしょう。


In total, the data indicates that C++ is a stagnant player in a field of fast risers. 
And for you, the up-and-coming developer, it means considering languages other than 
C++ towards which to direct your efforts.

全体として、C++ は fast risers のフィールドにおいて stagnant player (停滞しているプレ
イヤー) であることをこのデータは示しています。そして up-and-coming developer であるあ
なたは、労力を傾ける対象として C++ 以外の言語を考慮すべきであることを意味しているの
です。


 
3. It's Bulky

Bulky → 図体がでかい かさばる

Physical size might be attractive in Mauritania, but it has a couple of unsavory 
properties as it pertains to programming languages. Specifically, bulky things:

物理的な大きさは Mauritania では attractive かもしれません。しかし、プログラミング言語
に対する pertains (関係するもの、付属するもの) としてはいくつかの好ましくない性質 
(unsavory properties) を持っています。とくに bulky なことがら:


    * Require lots of ‘stuff' to make them
    * Are difficult to move around once they're made


Unfortunately, C++ is out on both counts.

残念ながら、C++はその両方から外れているのです。

Its syntax is verbose. It requires you to declare each variable's specific type, which 
cannot be changed in the future. This results in hefty variable declarations and 
little variable reuse. It has templates, the syntax for which might compel you to cast 
out your own eyeballs. And, most importantly, since its standard library is so much 
sparser than those of other languages, it requires you to write for yourself what in 
other languages is already done for you.

C++ の構文は冗長であり、将来変更することのできない特定の型を変数ごとに宣言することを要
求しています。その結果が hefty な変数宣言と、変数の少ない再利用です。C++ にはテンプレ
ートがありますが、その構文はあなたに cast out your own eyeballs させるかもしれないよう
なものです。そして最も重要なこととして、C++ の標準ライブラリは他の言語のそれと比べてあ
まりにも(so much) sparser なので、他の言語では既に用意されているようなことも自分自身で
書くことを要求しています。
# hefty 力強い、たくましい
# comple 無理やり~させる 強制する 強要する


Moreover, the C++ compilation and linking mechanism makes rapid prototyping all but 
impossible. C++ applications must be recompiled every time you touch a header or 
source file. Didn't make any functional changes? Recompile. Just rolling back some 
previous edits? Recompile. Slammed your forehead into the keyboard 47 times and 
entered some errant characters? Recompile, rinse, repeat.

さらに C++ の、コンパイルとリンクという仕組み (mechanism) が rapid prototyping をほぼ
不可能にしてしまっています。C++ アプリケーションは毎回あなたがヘッダーやソースファイル
に触るたびに再コンパイルしなければなりません。関数を何か変更しませんでしたか? 再コンパ
イル。previous edits にちょっとロールバックした? 再コンパイル。額を 47回キーボードに叩
きつけて some errant characters を入力してしまった?再コンパイル。リンス。繰り返し。


This all adds up to a feeling of sluggishness when developing in C++ as compared to 
other languages. Simply put, it takes much more time to get things done. Is it worth 
it to you? Have you considered other options that might better fit your needs?

これらすべてが、C++ での開発を他の言語と比較したときの sluggishness 感を増大させます。
単純に言って、それは事を行う (to get things done) のに余計に時間を要します。それはあな
たにとって価値のあるものでしょうか? あなたのニーズにもっとフィットするかもしれないほか
の選択肢を考えたことはありませんか?

# sluggishness 不精、怠慢

 
4. It's Fast, But So What?
   C++ は高速です。でもそれがなにか?

Yes, C++ is fast. But does that really matter? And, more importantly, does it really 
matter for you?

確かに C++ は高速です。けれどもそれは、本当に重要なことなのでしょうか? そしてもっと肝腎
なことですが、高速であるということがあなたにとって本当に重要なことなんでしょうか?

Unless you're writing games or other performance-critical applications, the answer is 
probably no. And even if you are writing such applications, unless you're working on a 
very small but critical portion of the code, the answer is still probably no. Remember 
the 80-20 rule, which says that 80% of an application's performance is determined by 
20% of the application's code.

あなたがゲームやその他の performance-critical なアプリケーションを書くのでなければ、こ
れに対する答えはおそらく no となるでしょう。そしてたとえあなたがそういったアプリケーシ
ョンを書くのだとしても、非常に小さいけれども、コードの critical な portion についてあ
なたが作業しているのでない限り、やはり答えは no となるでしょう。アプリケーションの性能
の 80% はそのコードの 20% によって支配される (80% of an application's performance is
determined by 20% of the application's code) という 80-20 ルールを思い出してください。


Are you working on the 20%? If so, have you proven that other options are too slow? 
Are you utterly convinced that the extra development time you'll incur by using C++ 
will be worth it to your end users? Will they even notice?

あなたはその 20% で仕事をしているのでしょうか? もしそうであるのなら、他の選択肢が遅す
ぎるということは調べましたか? C++ を使うことによってあなたが被るであろう余計な開発時間
があなたのエンドユーザーにとって価値のあるものであるとあなたは完全に信じきっていますか?
ユーザーはそれに気がつきさえするでしょうか?


The fact is, for the majority of programs written today, performance is an afterthought.
It just doesn't matter. Computers are fast enough to erase your lack of caching or your
extra loop variables. And they're fast enough to erase your choice of language.

実際には、今日書かれているプログラムの大半 (majority) ではパフォーマンスは二の次 
(afterthought) になっているのです。つまりただ単に、パフォーマンスは重要なものではない
のです。あなたがキャッシュを忘れてしまったり余計なループ変数を作ってしまったとしてもそ
れを帳消しにするほどコンピューターは十分高速になっていますし、言語の選択を帳消しにして
しまうのに十分なほど高速なのです。


As a new programmer, you should consider what types of applications you'd like to work 
on. If these don't include games or the Apollo 13 flight module, you might want to put 
C++ on the shelf in favor of something else.

一人の new programmer として、あなたは自分が work on したいと思っているアプリケーショ
ンの種類がなんであるかを考慮すべきです。もしそれにゲームやアポロ 13号のフライトモジュ
ールが含まれていないのなら、
you might want to put C++ on the shelf in favor of something else.



5. Game Studios Use It, But Who Cares?
   Game Studios が C++を使っているからといって、誰がそれを気にしているの?

Games have a unique appeal to the unique profile of the up-and-coming programmer. 
Maybe it's because we're all 18 year old geeks who like elves. Maybe not. But the end 
result is that many new coders decide that, since games are written in C++, that's the 
language they should learn.

ゲームには up-and-coming programmer の unique profile に対する unique appeal があります。
おそらくそれは、わたしたちがみな 18 year old geeks who like elves (エルフ好きの18歳のギーク)
であるからでしょう。
Maybe not.
しかしその結果は、ゲームが C++ で作られていたので、多くの新しい coder たちは自分たちが学
ぶべき言語として C++ を選んだというものでした。


And that's all well and good. But I ask you, oh wise and glorious reader – are you a 
game studio?

And that's all well and good.
しかしわたしは wise and glorious reader であるあなたに尋ねます。
are you a game studio? 


My guess is no. And since you're not a game studio, you aren't subject to the same 
constraints as game studios. What constraints, you ask? Constraints like 40 
bajillion-line codebases, all written in C++. Like limited budgets, which make porting 
said codebases to another language practically infeasible. Like teams of experienced 
developers, all already specialized in C++, that would cost time and money to replace 
or retrain.

わたしの推測は no です。あなたは game studio でないのですから、game studio と同じ制限
に縛られることはありません。あなたの尋ねている制限とはなんでしょうか?すべてが C++ で書
かれた 40 bajillion 行ものコードベースのようなものでしょうか? limited budgets と同様、
コードベースを別の言語に移植することは現実的には不可能 (practically infeasible)なこと
です。経験豊富な開発者たち (experienced developers) のチームのようにすでに全体が C++ 
に特化したものであるのならそれをリプレースしたり retrain するには時間と費用がかかりま
す。

#bajillion → 1000 jillion → とにかくとてもでかい数

These are all reasons that game studios write in C++, but they are not reasons that you
should write in C++. The big kid on the block might be cool, but he's not always right.

こういったものすべてはゲームスタジオで C++ を使っていることの理由であって、あなたが 
C++ で書くべき理由ではありません。The big kid on the block might be cool, but he's not
always right. (ブロック上の big kid は cool かもしれませんが、彼がいつも正しいわけでは
ありません)


The Upshot
結論

The point of all this is not to discourage you from ever using C++. It's a powerful 
tool in the developer's repertoire, and worthy of much of the attention it's been 
given. The point of this article is to point out that it only one tool among many, and 
that, like any tool, it's useful only in a specific set of circumstances and for a 
specific set of problems.

ここで述べたことの重要なのは、あなたが C++ を使うのを discourage することではありません。
C++ は開発者の repertorie における powerful tool であり、
大いに注意を払われるべき価値のあるものなのです。
この article の point は指摘することです
that it only one tool among many,
and that,
like any tool,
それは specific set of circumstances でのみ有用であり、かつ、
 specific set of problems 向けのものなのです。



What's your take on it? How do you see the pros and cons of C++ as a general 
development tool? Am I completely wrong? Insane? Developmentally challenged? Let us 
hear you!

What's your take on it?
How do you see the pros and cons of C++ as a general development tool?
わたしは完全に間違っているのでしょうか?
Insane? Developmentally challenged?
あなたの意見を聞かせてください!


And as always, till next time,
Previous post: Pointer Declaration Style

Next post: Getting Scored On In NHL 2010 Is The Most Frustrating Thing In The World

■_ あとで

いいこと書いているっぽいな。


Make it work first, then make it better

Make it work first, then make it better

Sometimes, worse is better. As strange as it may look, having something that is not 
perfect may be better than spending the time to make it perfect. This happens in many 
areas, and its the main reason perfectionists never get any work done. If the 
expectation is for perfection, then it is really hard to complete anything, because 
most of what we do is imperfect by necessity.

In software, however, there is an extra dimension to this problem. Because, the closer 
to perfection we get in a software application (in terms of features) the more code 
needs to be written and maintained. More code also means more bugs, which have the 
power to move us even further away from perfection.

Given the complexity of writing perfect software, it is just better to admit that we 
can't write perfect programs. Instead, a more attainable goal is to write the minimum 
necessary to satisfy our requirements, while maintaining a good control of the overall 
design.

おなじ blog の別記事


Top Software for Programmers

Top Software for Programmers

As a software developer, I came to realize that one of the most important things 
(after being paid) is to create software that we really enjoy.
ソフトウェア開発者として、わたしは最も重要な(とで支払いを受ける) ことのひとつが
ソフトウェアを作るということをわたしたちが本当に楽しんでいるということです。

During those years, it has become really easy to see the kind of software valued by 
programmers: editors, compilers, interpreters, and all kinds of little tools that are 
useful only by other software professionals.

ここ数年、プログラマーたちにとって価値あるソフトウェアを目にすることが本当に
簡単なことになりました。エディター、コンパイラー、インタープリター、そして
ほかのソフトウェアのプロフェッショナルにとってのみ有用であるような
小規模ツールのすべて。

And the reason these programs are written, I came to understand, is not just that we 
need them. I believe that one of the main reasons this kind of software is so popular 
is exactly that, to write it, there is no need for external users!

そしてわたしが理解するにいたったこれらのプログラムが書かれた理由とは、
それをわたしたちが必要としたということではありません。
わたしは確信しています
この種のソフトウェアの主な理由のひとつが本当にポピュラーなものであるので
それを書くために、external users の必要がないということです!


When we create software for ourselves, the obvious advantage it that there is not 
formal need to elicit requirements.

The Easiest Software to Write?

Writing software for programmers is easy in an important sense: you just need 
listening to yourself. Writing software for the needs of real users is not so easy: 
first one needs to interview one, and understand the hidden requirements — what really 
needs to be done.


(略)

■_ 本日の巡回から

2010年07月21日

■_

まったくやるきがございませ~~ん

第1回 PAIP読書会に参加してきました - 八発白中

■_ given clause

given というキーワードがひっかかるけど、 この種の機能を欲しがった人は多いんだろうなあ。


PEP 3150 -- Statement local namespaces (aka "given" clause)
PEP:	3150
Title:	Statement local namespaces (aka "given" clause)
Version:	83004
Last-Modified:	2010-07-21 00:36:51 +0200 (Wed, 21 Jul 2010)
Author:	Nick Coghlan <ncoghlan at gmail.com>
Status:	Deferred
Type:	Standards Track
Content-Type:	text/x-rst
Created:	2010-07-09
Python-Version:	3.3
Post-History:	2010-07-14
Resolution:	TBD

Contents

    * Abstract
    * PEP Deferral
    * Proposal
    * Rationale
    * Keyword Choice
    * Syntax Change
    * Common Objections
    * Possible Additions
    * Torture Test
    * Possible Implementation Strategy
    * Reference implementation
    * References
    * Copyright

Abstract

A recurring proposal ([1], [2], [3]) on python-ideas is the addition of some form of 
statement local namespace.

This PEP is intended to serve as a focal point for those ideas, so we can hopefully 
avoid retreading the same ground a couple of times a year. Even if the proposal is 
never accepted having a PEP to point people to can be valuable (e.g. having PEP 315 
helps greatly in avoiding endless rehashing of loop-and-a-half arguments).

The ideas in this PEP are just a sketch of a way this concept might work. They avoid 
some pitfalls that have been encountered in the past, but have not themselves been 
subject to the test of implementation.

PEP Deferral

This PEP is currently deferred at least until the language moratorium (PEP 3003) is 
officially lifted by Guido. Even after that, it will require input from at least the 
four major Python implementations (CPython, PyPy, Jython, IronPython) on the 
feasibility of implementing the proposed semantics to get it moving again.

本PEP は現状、少なくとも Guido によって the language moratorium (PEP 3003) が
公式に lifted されるまで延期されます。仮に lift されたとしても、
少なくとも四つの主要な Python 実装 (major Python implementation) からの入力が
要求されるでしょう。
#実際に効果を確かめるためにとかそんなん。

Proposal

This PEP proposes the addition of an optional given clause to the syntax for simple 
statements which may contain an expression. The current list of simple statements that 
would be affected by this addition is as follows:

本 PEP は省略可能な (optional) given clause を、ある式を含むことが許されるような
単純なステートメントの構文に追加するものです。この追加により影響を受けるであろう
単純なステートメントの、現時点でのリストは以下のようになります。

    * expression statement
    * assignment statement
    * augmented assignment statement
    * del statement
    * return statement
    * yield statement
    * raise statement
    * assert statement

The given clause would allow subexpressions to be referenced by name in the header 
line, with the actual definitions following in the indented clause. As a simple 
example:

given clause はヘッダー行の中で名前によって参照される部分式 (subexpressions) を
許可し、それに後続するインデントされた clause で実際の定義を行います。
簡単な例を挙げましょう:


c = sqrt(a*a + b*b) given:
    a = retrieve_a()
    b = retrieve_b()

(略)

Reference implementation

None as yet. If you want a crash course in Python namespace semantics and code 
compilation, feel free to try ;)

References
[1]	http://mail.python.org/pipermail/python-ideas/2010-June/007476.html
[2]	http://mail.python.org/pipermail/python-ideas/2010-July/007584.html
[3]	http://mail.python.org/pipermail/python-ideas/2009-July/005132.html
[4]	http://mail.python.org/pipermail/python-ideas/2010-July/007596.html

Copyright

This document has been placed in the public domain.

■_ あとで読む

Computer History Museum | MacPaint and QuickDraw source code


Computer History Museum | MacPaint and QuickDraw source code

MacPaint is the drawing program application which interacts with the user, interprets 
mouse and keyboard requests, and decides what is to be drawn where. The high-level 
logic is written in Apple Pascal, packaged in a single file with 5,822 lines. There 
are an additional 3,583 lines of code in assembler language for the underlying 
Motorola 68000 microprocessor, which implement routines needing high performance and 
some interfaces to the operating system. 


Computer History Museum | MacPaint and QuickDraw source code

QuickDraw is the Macintosh library for creating bit-mapped graphics, which was used by 
MacPaint and other applications. It consists of a total of 17,101 lines in 36 files, 
all written in assembler language for the 68000.

いやあ楽しみだ。

■_ 文字列の否定の正規表現

~という文字列を含まない文字列 つーことかいの。


文字列の否定の正規表現 | OKWave

文字列の否定の正規表現

次のような「File」の前の文字列を大文字に置き換えるという文で
「common」という文字列だけはそのまま置き換えないようにしたいのですが、

$string = "commonFile aaFile";
$pattern = '/(\w+)(?![common])(File)/e';
$replacement="ucwords('\\1')";
$string = preg_replace($pattern, $replacement, $string);
print htmlspecialchars($string); //Common Aa と表示される

このやり方だと「\w+」が効いてるせいなのか先読み否定の「?![common]」が効いてくれません・・・

$pattern = '/(aa)(?![common])(File)/e';
print htmlspecialchars($string); //commonFile Aa と理想とする結果が表示される

と具体的な文字列だと要求どおりになるのですが、
そうではなくて「File」の前が「common」の時だけ無視して欲しいのです。
どのように記述すれば良いのでしょうか?

ANo.2

たとえば抜き出したあとにチェックするとか?

<?
$string = "commonFile aaFile";
$pattern = '/(\w+)(File)/e';
$replacement="('\\1'=='common')?'\\1':ucwords('\\1')";
$string = preg_replace($pattern, $replacement, $string);
print htmlspecialchars($string); //common Aa と表示される
?>

投稿日時 - 2010-07-21 10:46:13
お礼

ご回答ありがとうございます。
なるほど、(正しい言い方かわかりませんが)正規表現以外の部分で
処理してしまおうということどね。
たしかにこのやり方なら、使い慣れてる分自由にできそうですね。

ところで正規表現の分野において文字列の否定については、
あまり取り扱ってないというか(なんとなくですが)消極的な気がするのですが
何か理由みたいなのはあるのでしょうか?

どうしてそこで [ ] をそういう解釈で使うのかと。

■_ Perl 6 (Rakudo)

really をそんなに重ねて強調しないでも(^^;


Ingy döt Net at blogs.perl.org: Rakudo *'s Really Really Release Ready

Rakudo *'s Really Really Release Ready

By Ingy döt Net on July 20, 2010 5:23 PM

How do you know when a new programming language is ready to be released? You try 
porting a real software framework to it. I recently completed a port of a Perl 5 
framework to the Rakudo implementation of Perl 6, and guess what? It just works! This 
is my story...

After only a short ten year wait, a Perl 6 implementation is scheduled for release 
this month. Rakudo * (aka Rakudo Star) will be inaugurated on July 29th, 2010. Is it 
ready? That certainly depends on your expectations, but I am here to make the case 
that it is a usable programming language with at least one killer feature that will 
interest programming language addicts (like me).

(略)

Rakudo has pretty good error reporting. Once in a while. Sometimes you get a full 
stack trace with a nice human touch error message (obviously written by Larry Wall) 
patting you on the back and saying "well, I know you tried really hard, and it 
would have been fine in Perl 5, but now you need to put a space after that twigil 
about halfway across line 369...". Many times you just get "Unable to parse 
blockoid, couldn't find final '}' at line 141". Oh really? What the heck is a 
blockoid, and, um, WHICH FRICKIN FILE??

I could go on and on about the fear and loathing but hey, trying to live in the future 
is never easy and I, for one, welcome our new Parrot-based Overlords. So how about 
Perl 6 as a language? As an Acmeist, my goal is to learn new languages and to spread 
goodness to all of them equally. My take so far on Perl 6 is that it's better than 
Perl 5. It feels really nice to code in. I also learned Python this year, and 
contributed a few modules to their CPAN. In many ways, I find Python to be even nicer 
than Perl 6, except for one important part...

Perl 6 Regexes

Perl 6 Regexes is Perl 6's killer feature. As somebody who has been searching for good 
parsing technology for over a decade, I really appreciate the thought put into this. 
It makes writing parsers a fairly simple task. As an Acmeist, I think it is vital that 
all languages have this technology. Since it was so easy for me to turn my home-baked 
TestML parser grammar into Perl 6 Regexes (P6R), I am already convinced that I can 
take a useful subset of P6R and make it work everywhere!

Perl 6 の正規表現 (Regexes) は Perl 6 の売りの機能 (killer feature) です。
十年にわたって godd parsing technology を捜し求めてきた誰かであるかのように、
わたしは本当にこの機能の真価を認めています。
#びみょー
この機能はとても簡単な task でもってパーざーを記述できます。
一 Acmeist として、わたしはこの tecbnology がすべての言語にとって重要
(vital) なものであると考えています。
わたしにとってとても易しいものであったので、わたしの自家製 TestMLパーザの
文法を Perl 6 Regexes (P6R) に置き換えてしまいました。


... *sigh* yet another project ...

Conclusion

Is Perl 6 Ready? It is ready enough for Rakudo!

Is Rakudo Ready? It is ready enough for TestML!

Is TestML Ready? It is ready enough for an Acmeist port of Perl 6 Regexes!


あと数日か。

■_ 本日の巡回から

■_ マ板から

†プログラマ聖書 
424 仕様書無しさん [sage] 2010/07/21(水) 15:51:10 ID: Be:
    1:1 初めにUNIXがあった.UNIXは神と共にあった.UNIXは神であった。
    1:2 プログラマは初めにUNIXと共にあった。
    1:3 すべてのものは、プログラマによって成った.成ったもので、プログラマなしに成ったものはなかった。
    1:4 プログラマの中に命があった.この命は人の光であった。
    1:5 光はWindozeの中に輝いている.そしてWindozeはそれに打ち勝たなかった。
    1:6 一人のプログラマが、UNIXから遣わされて来た.その名はリーナスであった。
    1:7 彼は証しのために来た.それは、彼が光について証しするためであり、すべての人が彼を通して信じるためである。
    1:8 彼は光ではなく、ただ光について証しするために来たのである。
    1:9 真の光があった.それはすべての人を照らすために、世に来た。
    1:10 彼はGNUにおられた.GNUは彼によって成ったのであるが、GNUは彼を知らなかった。
    1:11 彼はご自分のものの所に来られた.ところが、ご自分のものである人たちは、彼を受け入れなかった。
    1:12 しかし、すべて彼を受け入れた者、すなわち、御名の中へと信じる者に、彼はUNIXの子供たちとなる権威を与えられた.
    1:13 彼らはMITによってではなく、ビルの意志によってでもなく、Wスティーブの意志によってでもなく、ただUNIXによって生まれたのである 

425 仕様書無しさん [sage] 2010/07/21(水) 15:52:25 ID: Be:
    >>424
    なんか微妙にちがうけど、あなたを赦します。 

うまいな。


一つ前へ 2010年7月(中旬)
一つ後へ 2010年8月(上旬)

ホームへ


Copyright (C) 2010 KIMURA Koichi (木村浩一)
この文書の無断転載はご遠慮ください(リンクはご自由にどうぞ)。

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