サイボーグ

がサイバネティックスと関連があるのを最近知った。

サイボーグ（cyborg）は、サイバネティック・オーガニズム（Cybernetic Organism）の略で、広義の意味では生命体（organ）と自動制御系の技術（cybernetic）を融合させたものを指す。

サイバネティックスの関連用語としては、自己組織化、フィードバック、自動制御（オートマチック、オートメーション）とある。

SFのコンテキストだと、個体レベルで機械による強化が印象深いが、ソフトウェアのコンテキストだと、リーンスタートアップのビルド・メジャー・ラーンや継続的デリバリーややTDDがやろうとしている世界観は、”生命体（organ）と自動制御系の技術（cybernetic）を融合”が妙にうまく説明できていると思う。

どうしても、継続デリバリーやTDDを聞くと、自動化（や活人化）の断片で認識されがちだが、要は、生命体（organ）と自動制御系を融合し、学習フィードバックループをどんだけ継続して素早くぶん回し続けられるシステム系が育てられるか、強化できるかが肝である。

Perl More でテストの書き方をスぶってた

参考

http://blog.ainam.me/2013/04/09/test-more-perl-testing/

use strict;
use warnings;

use Test::More 'no_plan';

subtest "array" => sub {
    my $subject;
    my $setup = sub { $subject = [1, 2, 3, 4] };
    my $teardown = sub { $subject = undef };

    subtest "pop" => sub {
        $setup->();

        my $actual1 = pop($subject);
        my $actual2 = pop($subject);
        is $actual1, 4, "配列の最後の要素がとれること";
        is $actual2, 3, "破壊メソッド";

        $teardown->();
    };


    subtest "shift" => sub {
        $setup->();

        my $actual1 = shift($subject);
        my $length = @$subject;

        is $actual1, 1, "配列の先頭要素がとれること";
        is $length, 3, "破壊メソッド";

        $teardown->();
    };
}

package FuzzBuzz;

use strict;
use warnings;
use Test::More 'no_plan';


sub fizzbuzz {
    my $array = [];
    for my $number (@_) {
        push($array, &convert($number));
    }
    return $array;
}

sub convert {
    my ($num) = @_;
    return "FizzBuzz" if($num % 15 == 0);
    return "Buzz" if($num % 5 == 0);
    return "Fizz" if($num % 3 == 0);
    return $num;
}

subtest "fizzbuzz" => sub{
    subtest "fizzbuzz配列に変換できること" => sub {
        is_deeply(&fizzbuzz(1..15),
                        [1, 2, "Fizz", 4, "Buzz",
                        "Fizz", 7, 8, "Fizz", "Buzz",
                        11, "Fizz", 13, 14, "FizzBuzz"]);
    };
};

subtest "convert" => sub {
    subtest "15の倍数はBuzzを返すこと" => sub {
        is &convert(15), 'FizzBuzz';
        is &convert(45), 'FizzBuzz';
    };

    subtest "5の倍数はBuzzを返すこと" => sub {
        is &convert(5), 'Buzz';
        is &convert(25), 'Buzz';
    };

    subtest "3の倍数はFizzを返すこと" => sub {
        is &convert(3), 'Fizz';
        is &convert(99), 'Fizz';
    };

    subtest "整数を返すこと" => sub {
        is &convert(1), 1;
        is &convert(2), 2;
        is &convert(4), 4;
    };
};

メモ

• Perl 、　参照、配列、スカラで、変数名の付け方の$, @とかで迷う。。。
• エラーレポートの視線の送り先のカラーリングが俺好みじゃないなぁ。
• Test::More だと、 setup , teardown テストフレームワーク側でサポートしてないよう。
• More以外の選択だと、Test::Classがあるもよう。

Perl めも

hhh
@rrr Perl を 一夜漬けで 学ぶお勧めサイトおしえて〜。 あとテスト

kkk 16:06
初めてのPerl

kkk 16:06
 http://www.amazon.co.jp/Perl-%E3%83%86%E3%82%B9%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0-%E3%83%8F%E3%83%B3%E3%83%89%E3%83%96%E3%83%83%E3%82%AF-tokuhirom-ebook/dp/B00A5Q6EM2/ref=sr_1_fkmr1_1?ie=UTF8&qid=1390460320&sr=8-1-fkmr1&keywords=Test+tokuhirom

rrr 16:09
なつかしのとほほ http://www.tohoho-web.com/wwwperl.htm

rrr 16:12
テストはTest::SimpleとかTest::Moreとか...

rrr 16:12
http://gihyo.jp/dev/serial/01/modern-perl/0027

rrr 16:20
後は日本語訳された公式ドキュメントとか

rrr 16:20
http://perldoc.jp/docs/perl/5.18.1/perlsyn.pod

rrr 16:20
http://perldoc.jp/docs/perl/5.18.1/perlref.pod

rrr 16:20
http://perldoc.jp/docs/perl/5.18.1/perlsub.pod

rrr 16:21
http://perldoc.jp/docs/perl/5.18.1/perldata.pod

rrr 16:21
http://perldoc.jp/docs/perl/5.14.1/perlobj.pod

rrr 16:21
ここら辺抑えておけば一通り書けるのでは

rrr 16:22
正直Perlは書き捨てばかりでテストはあまり書いたことがない...

ddd 16:22
ドットインストールとかそういうのは?

ddd 16:23
http://dotinstall.com/lessons/basic_perl

ddd 16:24
修論でperl使ったけどまったく憶えていない

sss 16:25
1997年頃はバリバリPerl書いてたのに全然覚えてない...

rrr 16:30
英語だけど http://learn.perl.org/tutorials/

rrr 16:32
http://perl-tutorial.org/

rrr 16:34
サンプルコードによるPerl入門 と 2時間半で学ぶPerl はなかなか良いのでは

rrr 16:35
一ページにみっしり詰まっててちょっとあれだけど http://qntm.org/files/perl/perl_jp.html

rrr 16:35
こっちの方が話題も広がってていいかも http://d.hatena.ne.jp/perlcodesample/30000101/1361667605

rrr 16:42
多少複雑なデータを扱うなら、スカラ、配列、ハッシュ、リファレンスについて理解を深める必要が

rrr 16:46
オブジェクト指向は昔ながらの書き方だとちょっとドロドロした感じになります

rrr 16:48
https://github.com/hatena/Hatena-Textbook/blob/master/oop-for-perl.md

rrr 16:49
ここに書いてあることが抑えられるようになれば良いような気がします

rrr 16:51
ドギャーン https://github.com/hatena/Hatena-Textbook/blob/master/test-for-perl.md

flickr で 6000views 越え写真が出ました！

短期間に３つも。

• http://www.flickr.com/photos/haru01/11645322756/
• http://www.flickr.com/photos/haru01/11772366635/
• http://www.flickr.com/photos/haru01/11686613164/

Explore に選ばれると急激に伸びるようです。
個人的には、「すごくいいね！！！」の写真ではないのだけれど。
それでもいいね。ボーナスを溶かした甲斐がありました。

最近の偶然の発見

最近の偶然の発見はこれかな

• 昨年のPO研修、年末のkkdとの飲み会、火曜の飲み会で妙に「価値」の言葉が気になっている。
• なんだけど僕が知りたい、（使い手、買い手にとっての価値ではなくて）、作り手、使い手、買い手、投資する人、。。。。にとっての「価値」を１つの土俵で語るにはどうするんだろうと (ダイアローグの読書の余韻、まちづくりのワークの余韻)
• ....
• 優先づけられたバックログの代わりに「優先づけられた要件定義書」ってあるかなーとぽけーと思って Google検索
  • 「超上流から攻める。。。」のリンクをクリック。（普段なら「超上流」なんてリンクはクリックしないな。）
• ファイルの連番で別のファイルをあさる。（適当やね）
• 【http://www.ipa.go.jp/files/000004482.pdf 9p】の絵を見た!!
• 直接　使えるとかじゃないけど、いろんなプレーヤーがいる中で 「価値」を１つの土俵 語る際、大きなヒントになるかもと思った。
  • （優先づけられた要件定義書は検索のきっかけ）

直感的には、2から3軸の価値基準の絵、経営目標の達成度合い、リーンキャンバスの海賊指標の推移、Code Climate の診断結果の推移が１つのダッシュボード上に表示されて、いろんなプレーヤーが色々意見を言って、ソフトウェアをつくっているんだと思う。

プレーヤーとして、
ビジネス上のアジリティとコードのシンプルさの相関関係性を表す何かが欲しい。
なぜなら、これが欠落すると

• コードのシンプルさを無視した、ビジネス上のアジリティの追求は、いずれスパゲティコードが制約となり、サービス(ビジネス)の成長の限界と縮小に向かってしまうから。（人員の追加は、コードをさらに複雑にして、中長期的には状況を悪化させる。）
• ビジネス上のアジリティを無視したコードのシンプルさの追求は、必要とされていないものをつくてしまうから。

セレンディピティと リーン・スタートアップ、TDD

kkd 紹介で、下記の記事だけ読んだ。本はまだ。

http://1000ya.isis.ne.jp/1304.html

何かを夢中に探していると、
新たな発見に出会うことがある。
偶然性と察知の能力がどこかで結びつくとき、
新たな創造性が発揮されることもある。
これがセレンディピティである。

セレンディピティ。自分が最近つくったコンテンツだと「予期せぬ驚きの発見」の言葉に近い。
人によっては、小さな失敗を繰り返す、トライ & エラーの言葉と近接するだろう。

セレンディピティと リーン・スタートアップやTDDとは近い用語だと予感はしている。
（セレンディピティは、不思議系とも近傍にあるので、積極的には使いづらいが）

リーンスタートアップ や TDDは、（予測可能性を高めることに価値を置く代わりに）
単位時間あたりの偶然の発見数（予期せぬ驚きの発見・学びの数）を高めることに価値を置いている。

単位時間あたりの偶然の発見数を増やすため、リーン・スタートアップやTDDでは、
学習フィードバックループを小さくするメカニズムを提示してくれている。
高速回転する学習フィードバックループ（何かを夢中に探している様）で、新たな創造性が発揮される（はず）。

本文では、ポランニーの暗黙知のも出ていたが、ポランニーの語る暗黙知には、
科学の未知のエリアを開拓していこうとするメカニズムもスコープ内で語られているためであろう。

パターン、パーマカルチャーとのつながりは、少々おまちを。

挨拶の問題をみた。

https://codeiq.jp/magazine/2013/11/1475/
を読んだ。

引数は好き。 GOOS目線だと, JMock を使って、（抽象度の低い「時間」自体をモックするじゃなくて（GOOSでは、基本ライブラリーをモック・スタブで差し替えることに否定的。））

「挨拶」と同じ抽象度／ドメイン目線に合わせて、時間をもう一段抽象度を上げて「朝／昼／夜」を判定するロール（名前はわからん！） 発見し、責務を分配しコラボレーションしてやりたいことを実現するのじゃー。これがメッセージ／ロールを中心に捉えるOO設計だーとか言いそう。
「朝／昼／夜」の概念が変われば、修正箇所は、新しく発見したロールで対処する。

実業務だと、たぶんやんないけど。 時間を差し替えて stub や timecop で済ませるんじゃなかろうか。
朝昼夜の判断・判定が複数箇所で出ると分かってからDRY原則で抽出するんじゃなかろうか。

• • -

朝の場合、「おはようございます」
昼の場合、「こんにちは」
夜の場合、「こんばんは」

• • -

が実ゴードレベルで出てほしい気分。

一般の時間の概念レベルじゃなくて、ドメインレベルの時間の概念に抽象度を上げてをつくったことはないなぁ

参加すれば良かった。