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

首と肩のコリ解消のために新しい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プログラミングインタフェース

電子書籍版がない場合の技術書の読み方

最近はオライリーや達人出版等、そしてKindleもかな。技術系の電子書籍が増えてきて読むのがたいへん楽になってきたんですけど、やはりまだまだ電子化されてないもので分厚くて重要な本が多くそれらを読むのは大変置き場に困ったり体力を無駄に消耗したりするのでどうしたものやらと思っていました。妥協案としてブックスタンドを使うべきじゃないかと思って探したらどうもこれがおすすめらしいので買ってみます。

actto BST-02 ブックスタンド(OEM品番:EDH-004)

参考

本を使った学習を超効率化するブックスタンド-独学!未経験からWebデザイナーになる!!

「オブジェクト指向プログラマが次に読む本 Scalaで学ぶ関数型入門」を読んだ

基本的に関数型言語もScalaもJVM言語も初心者なのでその前提で書かせていただきます。

Scala興味なくても関数型と並列に興味がある人なら必要最低限の情報がうまく俯瞰できるようになっていて非常にいいです。関数型プログラミングの基本概念の副作用、単一代入、参照透明性、カリー化、部分適用、遅延評価、クロージャー、再帰、周りが丁寧に解説されています。アクタープログラミングとパーサーコンビネーターのところもまとまっていてわかりやすかったです。

ただ、タイトルのつけ方で若干損をしている感じはした。

関数型やScalaやりたいんだけど若干敷居高いなと感じてる初心者にはおすすめかと思います。

オブジェクト指向プログラマが次に読む本　?Scalaで学ぶ関数脳入門

追記

Scala抑えたいなら通称コップ本である。「Scalaスケーラブルプログラミング第２版」や並列処理周りの「Effective Akka」とかもあるといいかもです。コップ本ないとつらいです。電子版早くでてください。

Scalaスケーラブルプログラミング第2版

Effective Akka