Scalaで中規模のプロダクトで参考にしたいものを探したかったので抽出してみた

言語習得をしようとした場合、ある程度のところにきたら参考にしたほうがいいと思われる現実に動いているコードを見たくなります。ところが門外漢の場合はその分野はよく分からないので非常に探しづらいです。探せても、ものすごく規模の大きいコードだったりするので辛いです。そこで、

• 世の中の公開されていて有用なコードは大抵githubにある
• そういうコードは大量にstarがついている

この仮定に基づきgithub apiを使用して見た方が良さそうなプロダクトを出してみました。

• starの数でorderをかけて上位をもらってきました。
• さらにそこからsizeでorderをかけて表示しています

さすがにSparkは人気高すぎですね（sizeも大きすぎますが）。
単純にsizeで切り分けるとfpinscala当たりから下が割と見るのに楽そうかな
と思いました。

結果

size: 1301149 stars: 2975 url: https://github.com/apache/spark
size: 239164 stars: 3584 url: https://github.com/akka/akka
size: 184359 stars: 3696 url: https://github.com/scala/scala
size: 117478 stars: 5866 url: https://github.com/playframework/playframework
size: 117306 stars: 2580 url: https://github.com/twitter/kestrel
size: 104082 stars: 1725 url: https://github.com/scalaz/scalaz
size: 91885 stars: 1767 url: https://github.com/twitter/scala_school
size: 72924 stars: 1462 url: https://github.com/mesos/spark
size: 71091 stars: 1565 url: https://github.com/snowplow/snowplow
size: 48598 stars: 2097 url: https://github.com/sbt/sbt
size: 45302 stars: 1636 url: https://github.com/gatling/gatling
size: 33105 stars: 5941 url: https://github.com/PredictionIO/PredictionIO
size: 32448 stars: 1798 url: https://github.com/spray/spray
size: 32011 stars: 3226 url: https://github.com/twitter/finagle
size: 25413 stars: 3795 url: https://github.com/takezoe/gitbucket
size: 24529 stars: 1197 url: https://github.com/apache/kafka
size: 22289 stars: 1155 url: https://github.com/mesosphere/marathon
size: 20726 stars: 1962 url: https://github.com/twitter/scalding
size: 17587 stars: 2455 url: https://github.com/swagger-api/swagger-core
size: 13333 stars: 1508 url: https://github.com/scala-js/scala-js
size: 12360 stars: 1563 url: https://github.com/scalatra/scalatra
size: 11948 stars: 1430 url: https://github.com/twitter/summingbird
size: 6742 stars: 1152 url: https://github.com/fpinscala/fpinscala
size: 5850 stars: 1366 url: https://github.com/pocorall/scaloid
size: 5458 stars: 2432 url: https://github.com/twitter/flockdb
size: 5284 stars: 1951 url: https://github.com/twitter/gizzard
size: 5265 stars: 2032 url: https://github.com/twitter/snowflake
size: 4580 stars: 1157 url: https://github.com/GravityLabs/goose
size: 602 stars: 2947 url: https://github.com/lhartikk/ArnoldC
size: 494 stars: 1721 url: https://github.com/MojoJolo/textteaser

抽出用スクリプト

use strict;
use warnings;
use LWP::UserAgent;
use JSON;

my $url = 'https://api.github.com/search/repositories?q=language:scala&sort=stars&order=desc';
my $ua  = LWP::UserAgent->new;

my $response = $ua->get($url);

unless( $response->is_success ) {
    die $response->status_line;
}

my $json = $response->decoded_content;
my $data = decode_json($json);

for my $item ( sort { $b->{size} <=> $a->{size} }  @{ $data->{items} } ) {
    printf("size: %s stars: %s url: %s\n", $item->{size}, $item->{stargazers_count}, $item->{svn_url});
}

参考

• Search | GitHub API

Diagrammixを購入してみました

Diagrammixというフローチャート、ダイアグラム、そしてUMLを簡単に作成出来るツールを購入してみました。個人的にはUMLモデルを作成出来る点も大きかったです。使い方も割と直感的で使いやすいので今のところ好印象です。

Diagrammix

• Deep IT Pro
• グラフィック&デザイン
• ¥2,000
• 

短時間で人に認識を伝えるのが難しい

「コードがあれば」、「文章があれば」という方もいらっしゃられるし自身も昔はそう思っていたところがありました。しかし、ビジネスや発表などの要件で短時間で齟齬無く言葉だけで伝える、聞き取るのは割と高度な技術では無いかという（もちろんそれがすんなり出来る方もいらっしゃいます）と考えさせられることがたまにありましてこちらを補助としてうまく使えると思い購入してみました。

別途必要な物

ちゃんとした書き方を学ばないと宝の持ち腐れになりそうなのでその辺は別途書籍
を買って勉強したいと思います。

UML モデリングのエッセンス 第3版 (Object Oriented SELECTION)

参考

[Mac] ハイクオリティなダイアグラムが簡単に作成できるアプリ「Diagrammix」1700円が日曜日まで無料セール中。 | Appleちゃんねる

異常に首と肩がコル原因がリュックだった

首と肩のコリ解消のために新しいPCリュックを買いました。中身を古いリュックとすげ替えて背負っているのですが体感的に半分以下に感じるぐらい負担がへりました。

（カリマー） karrimor デイパック イクリプス 27 Eclipse 27 ブラック リュックサック

経過

最近、異常に肩と首が凝って仕方が無かった。姿勢も昔に比べると改善させたし、何でこんなに凝るのかさっぱりわからず、日常生活で負荷がかかってるシーンはどこだろうと考えた結果背中にしょってるリュックに行き当たった。元々、肩がけ鞄を使っていたのだがこれが体の一方に負荷がかかるということでリュックに変えた。そのときはPCリュックだった。しばらくしてこれは容量が酷く小さいという理由で、気に入ってはいたが泣く泣く容量の大きい普通のリュックに変えた。

要因

PCリュックから変えたのが失敗の元だった。参考のURLを見ていただけるとわかるのだがPCリュック以外でああいう重いものを持ち歩こうとすると首と肩に異常に負担をかけるのです。

参考

オシャレで肩こりしにくいリュックを探し求めて大正解だった話(っ´ω｀c) | ManiacPink-まにぴん-

空気を読むということについて考えてみた

もともと空気を読むということ自体が察するとか言外のものを読み取ることを言うとは思うのですが、たとえば武術であると師匠の意を察するということを生活や武術を通して知ることで物の真意を悟ったり考える力を養成することにより読む力を得たりします。これは言外のコミュニケーション能力を獲得することでとても便利なのですが、少ない情報と自ら何も発することなく意思決定をしてしまうというリスクも背負うことになります。達人ともなれば腕も違うしそもそも人生の経験値も違いますのでそのリスクも低くなりますが、そうでない人が言外のコミュニケーションと相手の行動を勝手に期待して空気を読んでしまうことは、双方プラスの方向で間違えてしまう分にはいいのですけどマイナス方向に働いたときにあまりよくない方向へ走って行ってしまうのではないかと思うのです、こういう風に考えたときに言語によるコミュニケーションは（こちらにもリスクはありますが）便利で積極的に使うべき代物なのだなと思いました。（自戒の念を込めて）

追記

何かで似たような感じの話が出てきた気がしてたんですがひょっとすると「7つの習慣」だったかも。あとで確認します。

7つの習慣-成功には原則があった!

「脳の強化書」を読んだ

タイトルの示す通り脳を強化するための指針を示した本です。脳を思考、感情、伝達、理解、運動、聴覚、視覚、記憶といったエリアに分けその部分を鍛えるためにどうすればいいのかいう方法を具体的に示しています。特殊な何かをしなければいけないわけではなく普段の生活の中にその鍛える要素はあり、自分が無意識に苦手としているところが弱いところに当たっているということを読んでいると気づかされます。改善したいんだけどどうしたらいいのかわからないという方は一度手に取ってみると
いいかもしれません。

アタマがみるみるシャープになる! 脳の強化書

アタマがみるみるシャープになる!! 脳の強化書 (あさ出版電子書籍)

記事と労力と当たり方についてかんがえてみた

労力をかけた割にまったく読まれない記事と手を抜いたのにやたら読まれる記事があります。起きている現象とどちらの記事もちゃんと読めるものだという前提に立った場合に何でそういうことが起きてるのかなと言うことを考えたんですが、おそらく記事の濃さによる読者の絞り込みの問題もかんけいあるのかなぁとは思っております。もちろんそこを関係なしに読む人はいるのですがそこは例外として扱います。

grep filter1 | grep filter2 ... grep filtern | wc -l

読者の知識に対してこんな感じにフィルターをかけていった結果、相当少ない人かかなり特殊な人しか引っかからない状態になっているのでは無いかという感じになるのかと思います。もちろんその界隈においてその知識を必要としてる人が少ないとかそういう可能性もあるし一概にこれだけが要因とはいえないのですが一因ではあるのかなとふと頭をよぎったのでメモしておきます。

参考

文章力を高めるキホンは「知識の弊害」を意識すること ｜ ライフハッカー［日本版］

open systemcallに対するメモ

open systemcallによって何がおきるのか？

open systemcallを発行すると、read(2),write(2),lseek(2),fcntl(2)などで使用されるファイルディスクリプタを返します。ファイルディスクリプタ自体は非負の整数で"その"プロセスが現在openしてない最小の値が返ります。これはプロセスごとに存在するファイルディスクリプタテーブルのidのようなものです。

memo

基本、こららのシステムコールはOSのバッファに対して実行を命令する物で物理媒体への書き込みを保証する物ではない。fsyncあたりがこれに当たるようだと現状の認識では考えている。この辺は確認しておきたい。

#include <fcntl.h>

int main()
{
	int fd;
	fd = open("test.txt", O_WRONLY);
	close(fd);
	return 0;
}

実際openだけを実行しようとすると、手元のgccではコンパイルが通り実行できます。
ただし、上記の場合はopenのオプションの関係で先にtouch test.txtでファイルを作成しておく必要があります。

引数に渡す物はなにか？

int open(const char *pathname, int flags);
int open(const char *pathname, int flags, mode_t mode);

第1引数でファイルパスを渡すのは割と明示的ですが、第2引数以降が割と曖昧でしたので纏めておこうかと

O_RDONLY, O_WRONLY, O_RDWR

この3つは必ずどれか一つを指定する必要があります。

O_CREAT

ファイルが存在しなかった場合において作成します。このオプションを指定することにより、事前にtouch hoge.txtなどする必要がなくなります。manを見る限りにおいて、O_CREATEが指定された場合は,第3引数のmodeを指定する必要があります。(ただ、彼方此方の動作させている例をみているとmodeを指定してこの引数を渡している物があんまり見受けられないようなので実は現在ではdefaultが効くのでいらないとか？)modeはこちらはsys/stat.hへ登録されているマクロを使用するとのこと。マクロはuser,group,othersでそれぞれ読み込み許可、書き込み許可、実行許可を設定する物がある。例えば、755だったら、S_IRWXU|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH となる。(see man 2 open)

#include <fcntl.h>

int main()
{
	int fd;
	fd = open("test.txt", O_CREAT|O_RDWR, S_IRWXU|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH);
	close(fd);
	return 0;
}

O_DIRECT

アプリケーションが独自にキャッシュ機能を持っている場合においてOSのキャッシュ機能が邪魔になるケースがある。そういう場合においてO_DIRECTを指定することにより性能が向上する。このオプションが指定されている場合はI/Oは同期で行われ、read(2),write(2)が終了した時点でデータ転送が完了したことが保証される。ただし、アプリケーションの独自キャッシュ等が無い場合は大幅に性能が劣化する。

解説等はこちら

http://d.hatena.ne.jp/takkan_m/20071008/1191850035

検証はこちらを参考に

http://ishwat.blogspot.jp/2011/12/direct-io-write.html

正直書き込みでO_DIRECTが必要になるケースがよくわからない。読み込みケースの場合はアプリケーション側のキャッシュが有効な場合はO_DIRECTが有効になっていた方が良いであろうというのは想像できるのだが。物理的に書き込む場合はfsync system callを発行しなければならない。

http://aoking.hatenablog.jp/entry/20120921/1348220615

#include <fcntl.h>

int main()
{
	int fd;
	fd = open("test.txt", O_CREAT|O_RDWR|O_DIRECT, S_IRWXU|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH);
	close(fd);
	return 0;
}

O_APPEND

ファイル追加モードでopenする。ファイルポインターをファイルの最後に移動させる。ファイルに対して追記をするときに使う複数のプロセスからO_APPENDで開いた場合でもwrite(2)をする直前にlseek(2)が走って末尾に行くことが保証されているのでファイルの末尾に書き込まれるようです。

memo

file pointerからKernelのファイルオブジェクトを調べる必要がある。

#include <fcntl.h>

int main()
{
	int fd;

	fd = open("test.txt", O_CREAT|O_RDWR|O_APPEND, S_IRWXU|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH);

	close(fd);

	return 0;
}

TODO

1. どれだけopenできるのか？
2. 制約はどこにあるのか？
3. 制約を自前で取るにはどこからとればいいのか？

参考文献

1. man 2 syscalls
2. man 2 open
3. man 2 stat
4. http://kotaroito.hatenablog.com/entry/20120108/1326030769
5. [ファイルディスクリプタについて（1）～ファイルディスクリプタの概要|http://codezine.jp/article/detail/4836]
6. [II-6-6. カーネルによるファイル操作|http://ossforum.jp/en/node/858]
7. [読書メモ / "Advanced UNIX Programming" | http://www.glamenv-septzen.net/view/842 ]
8. fsync http://aoking.hatenablog.jp/entry/20120921/1348220615

Linuxプログラミングインタフェース