2019-03-28

【日記】twitter控える、息子ついに歩きそう、Djangoのモデルで逆参照のやり方

日記。

twitterをやめた

twitterをやめた。アカウントは消さないけど、基本的に勉強したことをブログにまとめて流すときに使うくらいで、あんまり日常的に使うのはやめた。理由はtwitter見てると底意地の悪い人が多すぎて疲れるから。情報収集にtwitterはかなり便利だったしそこでしか絡めない好きな人もいたけど、それ以上にtwitter見てると人の悪意を目にして疲れてしまう。自分自身もなんか無闇に攻撃的になるし、そんなところにリソース割くのは馬鹿らしいので、やめた。
ほんで、twitterが担ってた役割を何で代用しようかしらと考えている。twitterの用途は色々あるが、それぞれ代わりのものを下記の通り考えた。

情報収集 → podcast, Qiita(今回初めてQiita真面目に使ったけどめちゃくそ便利だった...）
リーディングリスト → リーディングリスト使え
アウトプットの放流先 → これはtwitterでもOK（タイムライン見ずに放流できるから）
考え事 → talkmemo（ラインみたいなUIのメモ帳）
呟きたいこと → talkmemo
人と交わる → slowly(文通アプリ。世界中の人と喋れる)
分からんことのメモ → talkmemo

こんなかんじ。
一点言うなら、以前はマジ四六時中twitter見てたから、絶対に日に一度はDjangoの情報に触れられた。けど、今後はそう言うのなくなるから、意識的にQiitaの好きなタグを見るとかしないとなって思う。

（いまQiita見ててモデルの逆参照ってのを知った。
related_nameの存在意義とは？ - Django2の実力をつけるチュートリアルサイトDjangoBrothers
具体的には、

# はてぶろ上で書いてるから色々文法がめちゃくちゃかも
class Parent(models.Model):
    name = models.TextField()


class Child(models.Model):
    name = models.TextField()
    parent = models.ForeignKey(Child, on_delete='CASCADE', null=False)

parentとchildってクラスがあったとして、参照ってのがchild.parent、逆参照がparent.child_set.all()。また、childにparentとstep_parentみたいな親を参照する項目が複数ある場合はモデルの定義時にrelated_nameというオプション引数を与える必要がある。

class Child(models.Model):
    name = models.TextField()
    parent = models.ForeignKey(Child, on_delete='CASCADE', null=False, related_name='who_is_parent_of')
    step_parent = models.ForeignKey(Child, on_delete='CASCADE', null=False, related_name='who_is_step_parent_of')

parent = Parent.objects.get(name='やっちゃん')
parent.who_is_parent_of.all()
# <QuerySet ["やっちゃん血縁上の娘", "やっちゃん血縁上の息子"]>
child.who_is_step_parent_of.all()
# <QuerySet ["やっちゃんの再婚相手の子ども、たかしくん"]>

こんな感じ。俺はrelated_nameを関係代名詞みたいにしてるんだけど、なんかそうすると逆参照だって直感的にわかると思う。俺はこうしたいんだ！！！

本題からずれたけど、とにかく、Qiitaってめっちゃ便利じゃんって思った。）

勉強

まあ何やるにしてもただの勉強は分かった気になるだけだな的なことをちょいちょい実感していて、Djangoでサービスを作ってみていた。小説を書くときのツールみたいなのを作るのが一番モチベーションが保てるなと思い、そのサービスの機能としてtrelloみたいなのをweb上で実現しようとしている。
ここ最近はそれを開発しつつ勉強して、責務の話とかはわりと切り分けてやれるようになった。そして一旦切りのいいところまで開発できたので、GitHubにKPTまとめつつアップロードして、今回の開発は終わりとした。

今後は機械学習とデータベースの設計について勉強したいなと思ってる。とりま仕事でイチからシステム構築することになりそうなので、データベース設計から。機械学習への道は長い…。

仕事

FileMakerっていうソフトを使った案件に参画する。昔すこしだけ使ったことがあるが、エクセルツール的な立ち位置のツールを作っただけで、今回のは基幹システム。イチから作るってのがちょっと分からんのだよな。
とりまデータベース設計について勉強して、teratail起票しようかと思ってる。

あと、今後の収入について、収入源を増やしたいと思ってる。去年フリーの仕事を一本入れて、それが良かった。確定申告も簡単だったし。広告収入とか、フリーランスの仕事をやるとかかな？　twitter経由で3つくらい仕事をもらえそうにもなってるんだけど、色々未確定なんだよな。

息子立つ

今一歳半くらいで、ついに立った。なんか平均的な子どもは一歳くらいで立つらしく、まあ周り見てても確かに立ってて、とはいえまあ彼には彼のペースがあるだろうし下心を言えば正直歩かない方が育児は楽なので特に何も考えずいたら、ついに立った。まだ立てて５秒が限度で普通に倒れ込むので、しばらくは目が離せないな〜〜と幸せな悩み。ちな、子どもが立つとめっちゃテンション上がってしまう。妻と一緒に絶叫する。立ってほしいと思ってたわけではないんだけど、目に見えて成長してるからつい叫んでしまう。うるさい親だな〜〜と妻と一緒に笑った。

英語

英語、そろそろ再開しなきゃなと思ってる。やるのは

Reading - slowlyで手紙を読む
Listening - 自宅で英語耳
Speaking - 自宅で英語耳、外で息子遊ばせつつ瞬間英作文
Writing - slowlyで手紙を書く
単語 - 単語帳かみかんかDrop。悩み中

こんな感じかなあ。英語はいつも不安。
まあでも、モントリオールでの俺の暮らしって、基本的には日々の買い物とか、役所での申請とかになるんだよな。んで、そういうときに一番必要なのってリスニングだと思う。読み書きはグーグル翻訳使えるし、話すのも俺が下手でも相手はネイティブだから問題ない、けどいきなり話しかけられたときは俺自身の力でどうにかするしかないじゃん？　あと単純に一番苦手意識あるし。
戦略としては、隙間時間を見つけて全部色々手を付けるとして、それに加えて毎日そこそこ時間をとってリスニングをやりたい。シャドーイングとか。Netflixで英語字幕つけてUmbrellaAcademy見直したりしようかな。うーむ。

まあそんな感じで、朝Qiita読んで、時間とってUmbrellaAcademyでシャドーイングして、文通しながら英語耳と瞬間英作文する。

以上！

2019-03-14

【FileMaker】FileMaker久しぶりに使うので思い出しついでに基本操作まとめる

おつです。久しぶりに触るので思い出しついでに操作まとめます。ちな、この記事は複数日使って更新予定です。。

一日目 - 基本操作

一日目 - 基本操作

FileMakerはDBソフト兼カスタムApp。まあ普通にWebApp作るときと同じで、DB（テーブル）構築、バックエンド、フロントエンドの３つが主な作業内容。
それぞれやり方としては、・DB構築 → 『ファイル → 管理 → データベース管理』でテーブルの作成画面に行ける。そこでテーブル切って論理設計して云々する。・バックエンド → ボタンとかにトリガー貼って色々スクリプトを走らせることができる（フロントでは？）。そういう意味では、画面遷移とかフォームとかそういうのはもうFileMaker側がやってくれてるんだよな。あと何かあるとすると、ビジネスロジックの実装をやるくらいだなあ。・フロントエンド → これはレイアウトモードでやる。テーブル作った後ならフィールドピッカーからフォームを作成したりできる。後はボタン置いたりか？

一日目はこんなもんー。

2019-03-14

【FileMaker】FileMakerについてのまとめ

おつです。むかしFileMakerについて勉強したことがあってインデックス記事作ってなかったので作る。

過去のFileMaker記事まとめ

以上！

2019-02-27

「Webを支える技術」読んだ

おつです。かんたんな感想。

Webを支える技術

読んだ。普段Djangoとかのフレームワーク使って開発してると、あんまり裏側まで意識してやることはない。俺みたいな趣味プログラマだとなおさら。こうやって勉強できたのは良かった。

特に良かったのはhttpの章。httpメッセージの構成とか、各種メソッドを知れた。ヘッダーを読んだりする気になったので、これは実際役立った。

また、ハイパーメディアフォーマットの章は、HTMLがなにものなのか分からなくなった。XHTML? とかが登場し、ここらへんの位置付けが分からない。今後勉強したい。

たぶんこれ読み返して都度学ぶ箇所のある本だと思うので、定期的に読み返して自分の成長を噛み締めたい。以上！

2019-02-02

【ご飯】海外行っても手軽に作れそうなメシ

おつです。海外行っても手軽に作れそうなメシレシピ、ストックしとかないと現地でヤバイことなりそうなので、記録。

##　うまごはん

麻婆(マーボー)なす by陳建太郎さんの料理レシピ - レタスクラブ

ひよこ豆の中近東スープ（ヴィーガン） by Maxerbear 【クックパッド】簡単おいしいみんなのレシピが308万品

ソーセージとざく切り野菜のポトフのレシピ・作り方・献立｜キャベツやじゃがいもを使った料理｜味の素パークの【レシピ大百科】

簡単ウマい☆アボカドとトマトのパスタ☆ by チロタンタン【クックパッド】簡単おいしいみんなのレシピが308万品

ラープ（パクチーとひき肉の炒め物） | つくおき | 作り置き・常備菜レシピサイト

基本のオムライス | 植松良枝さんのレシピ【オレンジページnet】プロに教わる簡単おいしい献立レシピ

・かぼちゃのサラダ

・じゃがいものピザ

じゃがいもを薄くスライスして敷き詰め、ピザソースを乗せて焼く。ピザソースは下記のレシピ。

https://www.google.com/amp/s/recipe.rakuten.co.jp/recipe/1760007609/amp/

（まあ言うて、玉ねぎとニンニク炒めてトマト煮詰めるだけ。お好みでキノコやピーマン、大豆ミンチなどを加える）

ふやしたい。以上！

2019-01-30

【Git】Gitマジ完全理解したから聞いて

おつです。もう半年くらいGitに苦しめられていたんですが、UdemyのGit講座（もう怖くないGit！チーム開発で必要なGitを完全マスター　https://www.udemy.com/share/1002Z8BEAdeF5RRHg=/ ）見たらスゲエ理解できました。熱の冷めないうちに何点か「なるほど！」となった点を書きます。対象読者はGit使ってるけど背景は押さえてない人、もしくはマサカリ投げたくてうずうずしている人です。

1. Gitのバージョン管理方法
2. コミットの中身
3. ブランチはただのポインタ
4. リモート周りがすごい混乱する
5. 特に分からんところ

1. Gitのバージョン管理方法

俺がこの三日くらい勉強して最も「Git、ありがて〜〜」と思ったのはバージョン管理の仕方にある。んで、Gitの方式について書く前に、Gitが存在しない世界での話を書いておくけど、そういう世界では「これが最新.txt」方式でバージョン管理をする。

f:id:MaximoNelson49:20190130134846p:plain — 「これが最新.txt」方式。最新のファイルがどれか分かるだろうか？ *1

「これが最新.txt」方式にはたくさんの問題がある。まずどれが最新のファイルか分からないし、複数人で作業するときにファイルの上書きが容易に起きる。そういう問題を避けるために、Gitではデータファイルだけを保存するのではなく、データファイルの管理情報をヘッダーとして一緒に保存している。
そのヘッダーを「コミットオブジェクト」と呼ぶ。コミットオブジェクトにはツリー情報（後述）のほか作成者や作成日時、なぜその修正が行われたのかを示すコミットメッセージ、そしてそのバージョンの修正前ファイルを示す親コミット情報が含まれる。
この親コミット情報のおかげでGitはバージョン管理ができている（んだと思ってる俺は）。今のバージョンがどのバージョンから作られたのかさえ分かれば、どれが最新なのか、そしてバージョンが枝分かれしていないかなどが分かる。

2. コミットの中身

git addをしてgit commitすると、Gitが管理する全ファイルのスナップショットを取得し、対象ファイルをステージングし、さらにリポジトリに登録することができる。このとき登録されたものをコミットと呼ぶ（と思ってる）。
このコミットには、

blobObject（データファイルの中身を圧縮したもの）
treeObject（データファイルのツリー情報）
commitObject（データの管理用ヘッダー情報）

の三つが含まれる。それぞれについてもう少し詳しく書くと、blobはデータの圧縮そのものを示し、treeはフォルダ構成と圧縮ファイルへのポインタを記録し、commitは（先ほども書いたが）ツリー情報や対象コミットの親コミット情報などが含まれる。
この三つはそれぞれ関連している。commitがtreeを含み、treeにはblobへのポインタが含まれている。スナップショットとして記録されたファイルの状態は、このようにしてリポジトリに登録される。

ちなみに、（ Git - Gitの基本 )とかにここら辺が詳しく書いてあるので読むといいと思う。

3. ブランチはただのポインタ

「1.Gitのバージョン情報」に書いたんだが、Gitは親コミット情報があるおかげで最新のファイルがどれだとか、バージョンが枝分かれしているかどうかが分かる。
んで、枝分かれって言ったらブランチのことを書かなきゃならんのだが、上で書いたように、枝分かれがどのように起きているのか管理すること自体はGitの親コミット情報によって管理できている。

ではブランチが何をやっているのかというと、ブランチってのはただのポインタだ。親コミット情報によってGitが管理している枝一つ一つに名前をつけ、人間が見たときわかりやすいように管理するタグみたいなものだ。だから特別なんかすごいことをしているわけではないらしい。

（愚痴なんだけど、俺はブランチがなんかすごいことをしてるんだと思っていてブランチの説明を聞いたときすごく混乱した。ブランチによって並行開発が可能になっている、って言われるたびにコミットが連なっているというだけでは実現できていない何かすごいことをブランチがしているんだ....と思って恐れおののいていた。けど実際、Gitはコミットデータを追うことによって枝分かれを管理しているし、ブランチの旨味は、その枝分かれしている状況においてそれぞれの枝の最新をポインタとして記録することで枝の切り替えを簡単にしたり、人間が見て一目で枝があるなと分かりやすくできていることだ。）

4. リモート周りがすごい混乱する

ここは半分わかったようなわかってないような感じなんだけど、リモートってのが、gitにはある。そのおかげで、複数人がオンライン上のリポジトリを介して一緒に開発できるようになる。
リモートリポジトリはリポジトリっていうくらいだからコミットデータがたくさん入っていて、コミットデータがたくさん入っているってことはそこで枝分かれがしたりもしているわけだ。
その枝をリモートブランチと呼ぶ。リモートブランチはもちろんローカルでは編集できない。できるのはgit fetchによってローカルにリモート（追跡）ブランチを作成し、それをgit mergeすることによってマージしてローカルブランチに取り込むことだ（もちろんgit pullしても良い）。

今リモート関連で疑問に思っているのは、git pushしたとき、リモートリポジトリではpush時の最新コミットデータが登録されるのか、それとも前回リモートからpullしたときからの差分が登録されるのかってことだ。前者だと親コミット情報の不整合が起きそうだし、後者だと差分を取ったときに別の人の修正分が差分に浮いてきてしまうんじゃないかってなって謎が深い。まあどうにかしてんだろうけど、どっちでやるのを正解にしたんだろうなって疑問に思ってる。

5. 特に分からんところ

ツイート貼り付ける。

Gitの話なんだけど、障害対応の修正をどういうブランチで管理すればいいのか悩んでる、MasterブランチからHotFix生やしたいんだけど、そうするとstagingにはデプロイできないんだよな。うーむ。
— 森田🐘（旧右肩ゲロまみれ） (@subwaypkpk) February 13, 2019

とりま以上！！

*1:最新のファイルはもう一階層上にある「はてな原稿_提出用.txt」です。

親です。

読んだ本とかについて書いてます