ブラウザでDB設計
MySQLユーザーなら
を設計によく使っているかもしれないが、自分にとっては結構レガシー感があって触るのには結構抵抗があった。
最近SqlDBMというのを見つけて、これは結構いい感じ。
ブラウザでこちょこちょするとスキーマの図が出来上がる。
SQLというかDDLも吐いてくれるので設計結果を実際にMySQLに流し込むのもそれほど抵抗はなさそうに見える
ちなみにRailsなら
rails db:schema:dumpで流し込んだMySQLのschemaをRailsのschema.rbにdump出来る。
といってもmigration fileつくらないのでrollbackできなそうだし、ARを継承したmodelクラスを作ってくれたりはしないし、データもseeds.rbとかFactoryBotとかでよしなに準備しないと試しにデータ扱ってみたり、クエリ検証してみたりする上では話にならない感じがする。
でもdumpコマンドの存在にはちょっと夢を感じた。
データの用意とかもSQLの世界に閉じるなら不便はしないと思う。
もともとはMSのSQL Server向けだったらしいが、MySQL対応もされたらしい。
ここで知った
gitにはauthorとcommiterという設定があるらしい。え？
.gitconfigと言われて、ああそういえば確かにそんなのあったな・・・ハッ
として、普段何気なくコミットしていた自分のリポジトリを開いてgit log見ると、ばっこり本名コミットしておる・・・という過ちを発見してしまい、のたうち回った。
くそう、くそっ、、こんなはずでは、、と思いつつとりあえず公開リポジトリを全部privateにしたので、過去の記事のrepositoryリンクとか全部死んだ。はあ。
とりあえず過去改変する方法が上の記事にかかれているのでそれを試してみる。
大事なのはlocalの.gitconfigのuserとemailの変更と、過去改変の部分。
前者は
git config --local user.name sea_mountain
git config --local user.email valid_email@example.com
後者は
git filter-branch -f --env-filter "GIT_AUTHOR_NAME='sea_mountain'; GIT_AUTHOR_EMAIL='valid_email@example.com'; GIT_COMMITTER_NAME='sea_mountain'; GIT_COMMITTER_EMAIL='valid_email@example.com';" HEAD
で可能。
（本当に出来て感動した。）
（死んだいくつかのrepositoryリンクは復活。）
常識について学び、言語化して説明力を得る
前述のように、正規化理論は基本的に常識にすぎないという理由で批判されてきた。優秀な設計者であれば、たとえBCNFの予備知識がなかったとしても、この関係変数を射影SPとSSに「自然に」分解するだろう。だが、「自然に」とはどういう意味なのか。設計者は「自然な」設計を選ぶうえで、どのような「原理」を用いているのだろうか。
答えは、正規化の原理とまったく同じである。つまり、優秀な設計者は、そうした原理を正式に学んだことがなくても、その名前を言い当てることができなくても、そうした原理がすでに頭の中にある。したがって、原理は確かに常識だが、それらは正規化された常識なのである。正規化を批判する人は、だいたいこの点を見逃している。それらの概念が実は常識にすぎないことを（実にもっともらしく）主張するが、総じて、常識の意味を正確かつ形式的に述べることが偉業であることに気づいていない。
達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ
- 作者: ミック
- 出版社/メーカー: 翔泳社
- 発売日: 2012/03/16
- メディア: 単行本（ソフトカバー）
- 購入: 21人 クリック: 316回
- この商品を含むブログ (24件) を見る
設計の話を見てると、安定的に稼働するわかりやすいシステムを常識的に考えれば毎度そう結論づけるようなことに対して、あたかも価値ある知識であるようにひけらかしてるように見える。見えるが、設計していく過程において重要なのは、そういったぼんやり考えればそうなりそうなことに対してきちんと理由を説明して、言葉と論理を残していって、周りを納得させていくことなんだと思う。まあこういうのは人によって常識的に捉えられる範囲が異なってしまうからこうなる。これは仕方ない。自分を納得させてきた人たちは総じてこういった説明力が高い人達で、同時にちゃんとその知識をどこから得たのかを整理出来ている人だったように思う。
体調がいい日々は、思ってたより将来そんなに訪れない
風邪ひいてるかもしれなくて、ここ数週間とてもだるいながらも、休むほど体調不良でもないので、仕事してる。マスク着用。
いま20代なので若くて、体力や抵抗力あるらしいのだが、普通に具合は悪くなるし、土日よく寝込むし、24時間平等に生きれてる気があんまりしない。
なんかぼんやりと毎日規則的に起きて規則的に勉強したり遊んだりして充実した生活を想像してたけど、あり得ない気がしてきた。これないわ。不可能だわ。ぼんやりと描かれた夢物語だった。というか過去のどこにもそんな日々ない。
こっから意識が跳ね上がってスポーツマンにでもならない限り、体力は下降しかしていかない。たぶんもっと太ったりしてフットワーク鈍くなるだろうし、疲れたりしやすくなるし、眠くもなりやすくなる。
スポーツマンとかそういう高い理想はいいから今日から走り始めようとかそういう話よりも、これからより悪くなっていく普段の体調をどう受け入れていくかを考えたほうがいい気がしている。
今この時点でのやばいコンディションが、今後当たり前になる。今後の体調がいい日々が今味わってるこれになる。そうなった時に、こんな状態で自分がどうすればもっと楽になれるかを考える。こう、精神的とか体力的に乗り越えるみたいなマッチョな感じじゃなくて、だるいなりにでも、頭を使えばなんとか・・・少しずつでも・・・という考え方でなんとかならんか。
あー。もう寝たい。でもこの調子で寝てたら、一生寝たままで過ごすんだろうなあ。
抽象的な話は具体的な話が無いと成立しないんじゃないか、という抽象的な話
話が抽象的になってくるとなんでも正しそうに見えてしまう
うまいたとえが浮かばないが、たとえば
- 仕事した後は十分に休んだほうがいいよ
- 仕事した後にも将来に向けて勉強したほうがいいよ
みたいな話を聞いた時に、どっちも正しそうに見えてしまう問題がある気がしている。
この例だとひとつひとつ別々にみるとどっちも正しそうに見えるんだけど、両立するのは難しそうに見える。
でも自分に対してどっちを適用したらいいのかよくわからない。なぜなら両方とも自分にとっては同じレベルで大事そうに見えてしまうから。
多分両者とも掘り下げが足りてないんだと思う。もしかしたら
- （普段からとても気を使う仕事で、なによりも気力がある状態でいることが大事だから）仕事した後は十分に休んだほうがいいよ
- （必要になった時に勉強し始めると間に合わないような知識を使う仕事だから、今時間があるうちに）仕事した後にも将来に向けて勉強したほうがいいよ
としてあげると、さっきよりは自分にとってどっちが大事なのかより評価しやすくなったかもしれない。
おそらく、あるやったほうがいいことを示すための隠れ条件みたいなことがたくさんあるんだけど、それが無くても意見は正しそうに見えてしまう。そこには気をつけたほうがいいと思う。
現実はよりケースバイケースなはずで、もしかしたら隠れている条件も含めて正しそうな意見を判断していけるような知識を集めることが大切なのかもしれない。
こういったことを最近よく考えるけど、なかなかうまく説明できなくてもやもやしている。
1年半くらい英語を勉強してみて現在の気持ち
ポエムチックになってしまったのでこちらに投稿。
下記タイトルとは関係ないが思ったこと。
mediumははてなブログに比べてこういう文章を書かせて投稿させる吸引力があり、気づいたら投稿してしまっていた。
どんなブログサービスも大差ないと思っていたが、どうやらそんなことはないらしいということに今更ながら気づく。mediumならどうしてもmediumらしい雰囲気を醸し出そうとしてしまうし、こちらは全部下書きみたいな気持ちで投下してしまう。
用途が違うのでどちらも成立していて、優劣はないと思う。圧倒的に書きやすいのはこちらだと思うし。
マルチスレッドことはじめ
CPUはコア数ひとつにつきひとつの処理しか扱えない
ひとつの処理の単位はスレッド
- スレッドがたくさんあれば、それぞれのスレッドを並行に処理出来る
- 処理の文脈での並行(Parallelism)と並列(Concurrency)は厳密には違うらしいので注意
- ただ、文脈によっては違わないこともあるようなので警察にはならないように。
- 同じ時系列で同じ種類の処理を行うのが並行で、短時間で切り替えながら2個の処理を終えるのが並列という理解。
- すなわちCPUのコアひとつひとつにスレッドを割り当てて並行処理ができてかっこいい。
スレッドの元にはプロセスがおり、プロセスにはたくさんスレッドがぶら下がる
- プロセス
- スレッド
- スレッド
- スレッド
- みたいな感じ
- ただしこういう状態になるのはマルチスレッド対応のアプリケーションのみで、大体はシングルスレッドで動く。
プロセスを起動する時には、メモリの確保が必要
- OSがプロセスを起動するタイミングで割り当ててくれる
- すなわちCPUが処理していたプロセスをやめて、新たなプロセスを開始するにはコストがかかる
複数のプロセスでメモリを共有することはない
- OSはプロセス別にメモリを割り当てる
一つのプロセス上にぶら下がるスレッド達には、同じメモリ空間が見えている
- マルチコアのCPUはそれぞれを並行に処理できる
- 同じメモリ空間の上に居るのでスレッド同士でデータを共有することもできる
- 互いに影響を及ぼし合わないプロセスはスレッドセーフであるといえる
- （意図せず？）影響を及ぼし合うプロセスはスレッドセーフでない
- もうプロセスにメモリが割り当てられた後なので、同じプロセス下に居るスレッドが新たに開始するぶんにはメモリ確保のコストはプロセスを用意するのに比べるとかからない
参考
（こういうことわかりやすく解説してくれる方々本当にすくないので超たすかります）
絵で見てわかるOS/ストレージ/ネットワーク~データベースはこう使っている (DB Magazine Selection)
- 作者: 小田圭二
- 出版社/メーカー: 翔泳社
- 発売日: 2008/04/22
- メディア: 単行本（ソフトカバー）
- 購入: 22人 クリック: 303回
- この商品を含むブログ (36件) を見る
そしてこういうことがわかってくると、各言語の並列処理対応度や、アプローチの良さ悪さがだんだん評価できるようになってくる。
