ビジュアライジングデータがイマイチ糞の役にもたたない理由
これ、はじめはわくわくしました。O'Reillyから出ているprossesingで書くやつ。
でも、どれも実用できないレベルの視覚化サンプルばっかりで、ぼーっと眺めて
何の役にもたたないから仕事で使えないなーって思っていました。
それから5年(笑
あの本が出てから、たまーに目にする程度で、こりゃどうしようもないなって
思っていたんですが、あるとき「こういうのがビジュアライジングデータじゃね？」
って思う出来事がありました。
多分、そういう使い方を気にせず利用している人もいるかもしれませんが、こういう
サンプルがあればアイディアの連鎖がおこるんじゃないかと思った次第です。
例えば、学生名簿なんですが、1年、2年、3年がいますよね。
で、これを一般的なデータとすると、学年毎に分けて且つ、クラスで分けて
生年月日順かあいうえお順に表示しますよね。これはデータを整理して表示した
結果で視覚要素はありません。視覚ってカタチや色で大凡雰囲気をつかむことなので、
こうやってしっかりデータの表示分けをしちゃうと多分出番無いと思います。
そこで、どのように差し込むかというと、一例ですが、
まず学年で分けるのをやめて、全生徒を一覧にします。それをあいうえお順にでも
並べます。そして、その生徒毎に学年で色分けをします。で、あいうえお順なのですが、
「あ行の1年、2年、3年、か行の...」といった順番にします。すると、どうでしょう。
あいうえお順に、ざっくり学年の人数が色彩感覚で分かります。これで3年の色の分だけ
来年は卒業する訳です。これぞビジュアライジングデータじゃないですかね。
一例なんで、分け方の例はいろいろ作れますが、学校やクラス、性別などなど...
これがなぜ、役にたたないものが役に立つかというと、ポイントはこれに限ると思います。
まずデータのリストであることを維持している。
だいたいのビジュアライジングデータのサンプルは視覚化に特化しすぎて、普通に
データ化としての基礎をひっくり返しています。そのためお役にたたない惨状に
なっているわけです。
どうでしょう。上記をベースに、ビジュアライジングデータの良いアイディアは
浮かびませんか？
svnのE200031エラー
svn: E155004: Commit failed (details follow):
svn: E155004: Working copy '**************************************' locked
svn: E200031: sqlite: attempt to write a readonly database
svn: E200031: sqlite: attempt to write a readonly database
前にちょろっと書いたけど、macさんがrootでないとチェックアウトできなくて、素直にsudo使ったら
普段からcommitする際にもsudoが必要で面倒になって、無視してsudo辞めても以下のようなエラーになった話。
該当ディレクトリに移動して、以下を叩いてユーザを変えてしまうのがとりあえず楽
sudo chown -R ****** ./
svnのE205007エラー
svn: E205007: Commit failed (details follow):
svn: E205007: Could not use external editor to fetch log message; consider setting the $SVN_EDITOR environment variable or using the --message (-m) or --file (-F) options
svn: E205007: None of the environment variables SVN_EDITOR, VISUAL or EDITOR are set, and no 'editor-cmd' run-time configuration option was found
おかしいな。なぜかこのmac airだけこのエラーでた。いや、記憶を失っているだけか。英語はとりあえず読まないで、検索バーに託した。すると、エディタ設定しろよってことらしい。そんなこと書いてある気がするね！
自分のアカウントのホームディレクトリで.bash_profile開いて、以下を記述すればOK。自分は買ったばっかりだからか.bash_profile自体なかったわ。
finderで画像選択したときとか、
macのfinderで画像サイズ見たいときは、多々あったんだけど一度表示して他の画像選択してしまうと、
「-」とかになって画像サイズがわからなくなってしまう。微妙な仕様？だった。バグがあった。
でもマーベリックスになってからは、そういうショボい事も解消されてて、じわじわ良かった良かったと
思うのです。※正確に言うと「大きさ」ね。
OS X Mavericks現状
満足しているのですが、急にフリーズしたり落ちたりします。
もちろん頻発して話にならないとかはないですけども...
そしてそのおかげで、日々ファームウェア・アップデート
githubで何故かパーミッションエラーになったよ。
$ git push -u origin master
Permission denied (publickey).
fatal: Could not read from remote repository.Please make sure you have the correct access rights
こんな感じ、先日までできてたのに謎でした。で、ネットで検索すると事例は多く、色々設定方法があって各々解決の仕方が違った。で、私も片っ端から真似したけど解決できず。
解決方法は、鍵の作り直しをしたこと。
本家のこのままですね。
https://help.github.com/articles/generating-ssh-keys
Account SettingsのSSH Keysに、いつのまにか二つ鍵が登録されてたので、それをクリアして改めて登録した。
そしたら↑の公式通りの流れになって、
$ git push -u origin master
が、できました。
githubに作ったモノを公開した話。macだよ。
そんな日が来るとか思わなかったんですが、githubにソースを公開しようと思い立ちました。
1. githubにアカウントを作る。で、ここなんですが、過去に仕事でアカウントだけは設定したことがあり、細かい事は覚えていない。なので、ネットで調べたけど、そんなことやったのかな？みたいな記憶しかない。
2. githubのweb上でレポジトリを作る。これはボタンとかピンと来ないインタフェースだけど、探せばまぁ見つかる。
3. 自身のパソコン上にクローンを作って、落としてきたりアップしたりする環境を作る。この部分を理解するために、いくつかのインターネッツを徘徊した(笑)
3-1. とりあえず、設置したいところにディレクトリを作るよね。
$ cd ***** $ mkdir github(みたいな)
3-2. 初回ならgit config --globalとかで設定をしておく。アカウントを切り替える場合は、都度叩くみたい。
$ git config --global user.name "githubアカウント名"
$ git config --global user.email "githubアカウントメールアドレス"
3-3. レポジトリ作ると、強制的にreademe.mdとかできるよね。まずそれを落としてみる。といいますか。レポジトリ一つまるっと落ちてきた。（落ちてきたと言う表現はsvn的でgitは違うけど）
$ git init
すると、以下のような感じになるわなぁ
***/github/レポジトリ名/.git
LICENSE
README.md
3-4. で、reademe.mdを編集してみる
これはもうエディタでやろうがviでやろうが適当にテスト的なコメントを入れてみた。
3-5. 新規ファイルをアップする。
作ったソースを置いてみる。これはfinderとかでコピペするだけ
3-6. svnと同じ概念で新規はaddしてからcommitする
$ git add *
3-7. commitする
$ git commit
これはコメント入れる。svnをターミナルでやんのと同じ容量。気のせいかもしれないけど、コメントいれないとコミットできない気がする。わかったらここ更新しとくかも。以下みたいに、何変えて、何新規か分る。
[master num] firest
2 files changed, num insertions(+)
create mode num 追加したファイル
3-8. ここからsvnと違うとこだわな
svnは集約型だけどgitは分散型？だからコミットといっても自分のPC内だけなんで、マスターとかブランチに共有させる必要がある。pushね。
$ git push -u origin master
Counting objects: 6, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), num KiB | 0 bytes/s, done.
Total 4 (delta 1), reused 0 (delta 0)
To git@github.com:あなたのアカウント名でしょ/あなたのレポジトリ名でしょ
num..num master -> master
Branch master set up to track remote branch master from origin.
フォーク？でもしない限りアカウント名と、レポジトリ名は自分のとこだよね。
4. githubのweb上で、更新したレポジトリを見てみると、編集や新規追加が行なわれている。
5. もしweb上で更新したりしたら、最新の情報を取ってくるよね。
$ git fetch origin
$ git diff origin/master
これでマスターとの差分が見れる。fetchは必要みたい。他にも方法はあるみたいだけど、文字列として記憶しやすいのはこれかな。
んで、問題なければ
$ git pull
マージする場合は...自分一人なんでまずそんな経験しないかな。
こんな感じでした。
で、作り終わりかけたところで分りやすいサイト見つけました。
人の事言えないけど、本当に分りやすく書く人と、それ書いて意味あるの？って人いるよね。
