For the past a week, to use musics as BGMs in my project, I have found cites distributing free music materials. Then I found http://ontama-m.com and some awesome musics.
Especially, I love hitori-bochi because of the meaning “lonely” which fit a theme of this project.
I have been motivated well. Finding great artworks is good to motivate, to create own works.
会社で使うことになったので elasticsearch、始めてみようかと思います。
raspberrypiの試運転がてら8GBのSDにpidora入れてelasticsearch+Kibanaのコードを入れて動くところまでは行きました。ノートのブラウザからも一応KibanaのUIが覗けるところまでは行きましたが、そこからは処理が追いつかなかったのか進まず。
本当はあんまりやりたくなかったのですがとりあえずさっさと試してみたかったのでノートで決行。ノートに色々突っ込んで環境設定をいじくるの苦手。
homebrewで落としてくるだけでできる、すばらしい。
これからいじり倒しそうなので brew install時に言われたコマンドを叩いてスタートアッププログラムにElasticsearchとKibanaを追加。
10 min walk throughを見ながらデータを突っ込んでみる。
curlってこう使うんだとか、これが会社で後輩が言ってたREST APIというものかとか、今更ながら今まで興味なかった基本的なところを「へぇ、これが」といちいち思いながら進めてく。
10 min walk through のシェイクスピアのデータでは正直データ解析をするというイメージがつかめなかったので、kibana test dataで検索して出てきた harukasan/kibana-testdata を使わせてもらう。
慣れないルビーの用語を調べつつ、この方法でなんでインポート出来るんだろうかと戸惑いながらもなんとかデータをインポート。
gem使うの久しぶりだとかbundlerなんてモノがあるんだとか、設定保存系とかバージョン切り替え系とか今まで苦手苦手でやってきたので読むの辛かった。
おお、できた。やっぱり時系列データって見やすいですね。
とりあえずハンズオンここまで。次は Basic Concepts 読みながら思想的なところを掴んで行こう
想像していたよりかなりお手軽だったので、お手軽ついでにWebフレームワークとして名高い Ruby on Rails も触ってみたい、と思いつつ自分って今まで本当cssにしか興味持ってこなかったんだなと若干ヘコむ。
OSX Yosemiteの赤/黄/緑ボタンの中の黒字のアイコンが、どうしてもずれて見える。
赤いボタンの中のバツは上にずれて見えるし、緑のボタンのプラスは下にずれて見える。
で、拡大してみると…
ずれてない。
目の錯覚か、そうだとしてもどうにも落ち着かない…
改善されるのか、そもそも問題として認識されるのか、更にそもそも、そう感じるのは自分だけなのか…
追記: 僕は度のかなり強いメガネを掛けていて、もしかしたらそのせいなのかもしれない。像の歪みが強い視界の端にあるときにこの錯覚が顕著な気がする。視力検査で赤と緑の違いのようなものをやった気がするけれど、まさかこういう形で支障を与えてくるものとは…
追記: 同じことを感じていた人がいたみたい。「yosemiteの閉じるボタン(Xボタン?)だけ赤丸の中のXの位置が微妙に左に寄って無いか？ これずっと気になってて気持ち悪いんだけど俺だけ？」http://2log.sc/r/2ch.sc/mac/1410520218/
Apple Time Capsule を購入していざ iPhoto Library を移そうと思ったらデータ移動が異様に遅かった。50GB のコピーが何度繰り返しても 300MBを超えた辺りで 0.1MByte/s 程度のスピードに。
estimate 1d ってはじめは何の事かわからなかった
原因は https://discussionsjapan.apple.com/thread/10134709 を見る限り iPhoto には細かいファイルが多いらしく、そのせいでコピーに時間がかかっているとの事。
リンク先で勧められていたのがdmgに変換して渡す方法だが、やり方を調べるのが面倒だったので terminal で tar を使ってやってみたらすんなり行けた。
$ tar cvf /Volume/Data/iPhoto /Users/****/Pictures/iPhoto Library
これで50GBのコピーも1時間足らずで完了。満足できそうなパフォーマンスにほっと一息
…と思ったら解凍に時間がかかるのを忘れていた。
1時間で2.5GB完了。終わるのはちょうど 1日後。さすがMac、良い estimate time を持っている。
第2報。3.5時間で30GB完了。どうやらはじめの方に細かいファイルが多い模様
tex wikiに書いてある通り
をプリアンブルに書いて画像の挿入を
includegraphics[width=120mm]{foo.png}
としたところ、エラーが出たので、エラーメッセージに従いtexのコマンドオプションに -shell-escape をつけて
platex -shell-escape foo.tex
と実行したところ、画像用の中間ファイルが自動で生成されながら処理は難なく終了した。
設定とか移行とか、隠されている割になにかと触る機会の多い Library フォルダ。移動するには command + shift + G で移動メニューを出して Library と打ち込んで…と、一手間必要でした。
その Library フォルダにアクセスする別の方法がadobeのヘルプに書いてありました。個人的には一番手軽な方法かな。
Finder の「移動」メニューを出した状態で option キーを押すと Library がしれっと項目に追加されます。
キーバインドの関係でoptionキーを押した状態のスクリーンショットはとれませんでした。残念
Oaoaな日々さんに Library フォルダを常に可視状態にする方法が紹介されていました。
texからpdfまでを一括で行うスクリプト。作ったけどtexbinの中に入ってそうだ。-bオプションを取得してBiBTeXの処理オプション、-cオプションを取得して中間ファイルの削除オプションもつけてみた。
function tex2pdf() {
# set options
BIBTEX=false
CLEANING=true
while getopts bc OPT; do
case $OPT in
b) BIBTEX=true;;
c) CLEANING=true;;
esac
done
shift $((OPTIND - 1))
# tex process
platex $1
if $BIBTEX; then
pbibtex $1
platex $1
fi
dvipdfmx $1
# cleaning
if $CLEANING; then
rm $1.{log,aux,dvi}
if $BIBTEX; then
rm $1.{bbl,blg,lof,lot,toc}
fi
fi
}
第一引数にターゲットのtexファイルを拡張子抜きで指定。
$ tex2pdf texfile
bibtexする場合
$ tex2pdf texfile -b
中間ファイルを削除する場合
$ tex2pdf texfile -c
はじめはplatexとdvipdf打つのが面倒だなと思って作り始めたこんなのだった。
function tex2pdf() {
platex $1
dvipdfmx $1
}
gnuplotでCSVファイルからデータを読み込んでプロットするときにフィールドをインデックス番号でなくフィールド名で指定する方法。
単純な方法だと
plot "filepath" using "time":"y"
数値を操作したい場合は
plot "filepath" using "time":(column("y") + 1)
文字列として操作したい場合は
plot "filepath" using "time":"y":("value: ".stringcolumn("label")) with labels
とかでできます。
データ処理のスクリプトを書いていると、開発の途中で新しいフィールドが追加されたり順番を変えたくなったりすることもありますが、はじめからフィールド名で指定しておけば、少なくともそういったときにフィールドの順序にとらわれることはなくなります。
何のデータを処理しているのか、コード的にもわかりやすくなりますね。
精神衛生的に、フィールド名が使える場合は使いたい。
Python歴は今の時点でだいたい1ヶ月くらい。
本当は1年くらい前に、PythonでCSV読み込んでタイムスタンプのフォーマットを変えて、みたいな簡単なスクリプトを組んでたんだけど、それはもうそれっきりで、文法とかももうすっかり忘れて、1ヶ月前くらいから、また一からリファレンス読みながらのスクリプティングをしてきた。
これまでにやってきた言語といえばC、Java，C++。スクリプト言語だとweb系でPHP、Perlくらいなので、Pythonはコマンドラインから動かすことを考えたら始めてのスクリプト言語。
あんまり大きな声じゃ言えないけど、try-catchとかのエラー処理とか、よくわからないレベルの超ライトユーザなので、突っ込んだ話はできないけど、ここまでPythonに触れてきて「いいな、Python」と思ったことをちらほらと書いていく。だいたいがC++に比べて、って感じだけど…
見返してみると、「いいなPython」って言うより「いいなスクリプト言語」って感じ
同じ働きをするコードを書くと、C++と比べてPythonは30%くらいの行数になるんじゃないか、ってくらいのイメージ。
コード量が少ないと読むのにかかる時間がだいぶ違ってくる。プログラムを読む時って「この変数がここで使われてて…」とコード内を何度も往復して読んでるから、読むのにかかる時間はきっとコード量の2乗くらいで効いてくる。コード量が2倍なら理解に掛かる時間は4倍。根拠はないけど。
これなら標準ライブラリの実装とかも眺められるんじゃないかと思ってスレッド周りのライブラリをチラ見してみたけど案の定のカオスっぷり＆英語コメント読めないで諦めた。
僕のスキルなんてまあ、こんなもの。
CSV読むのも標準ライブラリで一発だし、スレッドも簡単に使えるし。Cとかだとboostである程度標準化されてる気がするけど、でもこういうプログラムで一般的に使われる要素がPythonだと「標準」として組み込まれていて、この辺が強いんじゃないかなと。
C++11だとboostがsdtに組み込まれてsdt::threadとかで使えるんだっけ
「標準」の安心感って初心者にはとても心強い。リファレンスも多そうだし、なによりPythonの仕様とか実装を決めてるコミュニティの人たちが煮詰めて煮詰めて作ったんでしょ、みたいな根拠は薄いけどとりあえずいい感じのパフォーマンスを発揮してくれるんだろう、みたいな安心感がある。
もっと書こうと思ったけど書きづらい。Python、すごく使いやすいけど他の言語と比べて具体的にどうこう、とかは自分のレベルじゃあんまり具体的に思いつかない。
どういう要素が働いているか解らないけれど、なぜか作りたいものが作りたいときに「ぱっと」作れるようになってるんだな、ってことぐらいしか、今はまだ書けない。
よくわからないけど、Python、よくできてる気がする。
ねこと電球 