2020-07-04 6月のにっき

数字

  • Slack: 2513発言
    • コード書いてるのか〜〜〜?
  • merged pull request 22つ、1,344 ++ 432 --
  • unmerged 1つ
    • 数え方がわからない
    • とにかく巨大に育てたという事実だけある (4桁変更in3桁ファイル)

リリース所感

私の仕事として、いい感じのドアを作って関係者以外立ち入り禁止からみんなが入れるようにするまでは気にかけるけど、誰か入ってくるまでの間をどうこうしようみたいなところに行けていない気がする。中に入るときのワクワク的な...(知らんけど)。 産地直送便利機能紹介記事みたいなのを一度書いてみるといいのかもしれない。

f:id:h6n:20200701094821p:plain

RSpec

わりともりもり書いた

64GBメモリ

快適になった。

画面が固まる

カーソルだけはうごくが全体の画面が固まるみたいな現象が起こるようになった。 モニターアーム導入のせいなのかHDMIケーブルが抜けかかっているのが原因で抜き差しすると直る。

趣味

reference tableをやっていた

qiita.com

サンプルリポジトリ

github.com

ghコマンドでリポジトリ作る時明示的に --public つけないと公開されてないのしらなくて公開した

github.com

github.com

型付け関連でPRをいくつか出していた

github.com

他るりま2つ

github.com

github.com

設計

reference tableとか消さない、とかもそうだけどその辺に凝りだしている。

  • Railsがリソース結構大事にしているのでフォームみたいなものを生やすよりApplicationModel的な感じのものをサブリソースとして生やしてCRUDのほうが相性が良さそう
  • 動詞的な操作も名詞にすると名詞へのCRUDでかなり単純化
  • なんとか_at みたいなカラム、現実社会だと「2020年6月29日の夜、肉を焼いた」みたいなのを1回しか肉焼きの記録を持たない、ということにして肉焼きイベントテーブルではなく 焼いた_at で肉テーブルに持っているが実はこれは肉焼きリソースなのでは、と気づく

例えば

resources :肉

class 肉Controller < AC
  def update
    @肉.update!(bbq_at: Time.zone.now) if params[:bbq]
  end
end

とか

resources :肉 do
  post :bbq, on: :member
end

class 肉Controller < AC
  def bbq
    @肉.update!(bbq_at: Time.zone.now)
  end
end

はこうなんじゃないか

resources :肉 do
  resource :焼き肉
end

class 焼き肉Controller < AC
  def create
    @肉.焼き用.save
  end
end

class 焼き肉 < Struct.new(:肉)
  def save
    肉.update!(bbq_at: Time.zone.now)
  end
end

class 肉 < AR
  def 焼き用
    焼き肉.new(self) unless bbq_at?
  end
end

みたいなことを考えていた

Railsはroutesからviewまでリソース指向だからリソースを中心に据えている限りはレールから外れることはなさそう。

ここでいうリソースとはなんですか、という感じ。

やはりデータベース設計の本を読むか、ということでT字形ERの本を読んでいた。 _at 的なやつはT字形ERだとみなしエンティティとかイベント的な奴で、Railsの場合はT字形ERでいうリソースに戻した状態でテーブルに実装されることが多そう。 T字形ERでいうみなしエンティティを戻してデータベースを実装した場合にもそのエンティティの読み書き自体は別のモデルとして切り出しておいたほうがリソースがroutesからviewまで貫いているRailsでは便利そう、という感じの立ち位置なんだな、自分は。という感じ。

まだよく分かっていないのでfukabori.fmの論理削除回を聞いたりしている

fukabori.fm

引っ越し

引越し先を決めた、引っ越しする。入居予定まで日にちがあると思ったらなくなっていて慌てて各種の申し込みをしている。 電気水道ガスインターネットの順に着弾する予定

反省

この辺の設計の話を共有してもよさそうな場所があったんだけど共有できなかった、主にプログラマーがしゃべる共通言語が通じなさそうなので面倒という点で、それでも伝える努力をするべきだったと思うので猛省している。 具体的には、SQLってプログラマーだけが書くものではなく、データベースに対して様々な立場の方々が問い合わせるので、自分の説明力のなさと向き合わずに説明を避けるのはよくなかったかな、という。 こういうデータ構造で持っているのです、というのがふんわり分かっているだけで多分書きやすさが違うと思うので...

酒

飲んだ、うまいやつを。クラフト麦酒最高。

ギャル

ギャルさとは一体なんなのか、妻に私はギャルかと聞いたらは？何いってんの、おじさんだよおじさん、という手厳しい答えがかえってきた。

ピアス

肉体への不可逆的な操作を避ける保守的な価値観の持ち主というのを自覚している。ヒゲ脱毛も恐らく便利になるだろうけど、ヒゲ脱毛をした場合に子どもが髭こくなって悩んできたときに「そのままでよいです」と自信を持って言えなくなるんじゃないか、という不安（自分は脱毛しておいて説得力を出せるのか、という不安）、あとひょんなことで中東などの髭を大事にする文化圏にいったときに大人とみなされないんじゃないか、とか、ひょんなことで刑務所に入ったら不利益に働くことはないだろうか、という。いやまあ中東に行くことも監獄に行くことも日本以外の監獄に入ることもないとは思って入るけど人生は何があるかわからないからな...。

その辺の保守的な価値観を破壊するために雑に可逆ないし簡単なところからはじめるとよいのでは、ということでピアッサーをかった。まだ穴はあけていない。ピアスホールは傷と同じでほうっておくと塞がるので実質可逆であろう。

タトゥー、あるいはヘナタトゥーは....わからん

調光機能つきの度付きサングラスを買った

紫外線に反応するタイプの度付きサングラスをかってみた。調光機能がついたレンズははじめてだけど結構よさそう。眩しくない。紫外線に反応するタイプなので車の中など紫外線が既に遮られている場合にはきかないらしいが車のらないのでよしとする。

異文化コミュニケーションみ

同じ日本語を喋っているとはいえ文化的背景には違いがあり、様々な文化がある、文化があるなーーーというのを感じる会話等を見聞きしたりするのが多い1ヶ月だった気がする。

推しの概念

社内に推しの概念が持ち込まれた結果 :penra: とか :oseru: が生えた。なんかこう、自分が推せるかどうか判断はかなりわかるようになってきた一方、推しではない判断がいい感じに出来ているかというとわからないのがわかる

ラップトップ

どこでも仕事可能状態たもてていない気がする、まったく持ち運ばなくなったThinkPadの電源いれて久々になんか書こうとしたらdocker-composeのバージョンが古くてうまく動かないみたいな事件があった。 コア数のあるマシン欲しい or コア数はないが快適に開発できる環境を整えるのにチャレンジしたい。

オフライン会話

楽しい、もっとしたい

オンライン会話

楽しい、もっとしたい

所感

いい同僚が多い

結婚所感

どうして結婚したんですか、と聞かれたときにちゃんと答えられていない気がする

交際から12年たったので雑につらつらと書いていく（許可はとっていないのであとで怒られたら消すかもしれない）

まずはじめに

実態として結婚してるのと変わらないならそれは結婚

戸籍法で定めた感じの手続きをしてるかしてないかが違うだけ

法定婚とか事実婚とかいう

現代社会は婚姻の届け出をしているほうがより公的に夫婦と認められてさまざまな利益が得られるように社会制度がつくられている

公的に認められなかったとしても当事者同士が結婚しているというのであればそれは結婚

さまざまな事情で結婚の届け出ができない人というのはいます

さまざまな事情により離婚が出来ていないので重婚
同性同士なので受け付けてもらえない
戸籍がない
3人以上で婚姻を結んでいる
続柄的に受け付けてもらえない
姓を変えたくない

ぱっと思いつくだけでもこれぐらいある

一方逆で公的には事実婚と認定されるんだけど当人同士は結婚してないと主張する関係もあると思う

あと結婚すると一生婚姻関係を続けるという圧を感じる

なぜ結婚したのか、と聞かれたとき

届け出を出すのに締め切りが設定された

と答えてしまう

届け出を出していなくても、結婚はしていたはずである。事実として。

実際に結婚してるんだから届け出を出すのは当然であろう

先に結婚の事実があり、後に届け出がある

その考えに届け出を出していなかった当時は至らなかった

いわゆる結婚は、男女間で、自由恋愛から始まり、婚約をし、婚約指輪や結婚指輪もつくり、入籍を届け出、その日を結婚記念日とし、結婚式を挙げ、結婚披露宴を開く、そして一生婚姻関係を維持する

これに縛られているとなかなか結婚はできない

知らんけど。自分はそうだった。

日本国憲法にはそんなことは書いていない
https://ja.wikipedia.org/wiki/%E6%97%A5%E6%9C%AC%E5%9B%BD%E6%86%B2%E6%B3%95%E7%AC%AC24%E6%9D%A1

両性の合意のみに基づいて成立するはずだが、なかなか結婚を届け出ることはできない

さまざまなことを気にしてしまい届け出はできていなかった

なんというか、そういうものです。
理念は素晴らしいけど実践するのは難しい。

届け出をするとどうなるのかも知らなかった

例えば婚姻していると条件はあるが遺族年金が受け取れるなどのちがいや税の控除やなんかほかにも色々ある

そういうのをまともに話したい関係にある既婚者が周りにいなかった（周りに素晴らしい既婚者が大勢いるので単に聞かなかった私の問題という説もある）

どうして結婚を届け出できたのかというと、締め切りが設定されたことにより、なぜ指輪を買うのか、本当に必要なのか、指輪に結婚記念日を刻むのは妥当なのか、そういったことを延々とクソめんどくさく話していてもお前はクソめんどくさい、と言いつつもこたえてくれて受け入れてくれるから、というのが大きいです

こんなことを話してこいつクソ面倒だなと思われたくなくて（あるいは単に話すのが面倒で）雑に届け出に締め切りが設定されたから。みたいなことを返してしまう。

結婚にあたり私のほうの姓を変えたんだけど、それも根底にはほとんどの女性が姓を変えさせられている、という現実があるのにおかしさを感じているというのが一つ、姓を変える手続きというのは結婚するだけでできる、比較的簡単な手続きで姓を変える、はあんまり行わないことなのでやってみたいが一つ、もとの名字にすごく思い入れがあるわけではないが一つ

婿養子なのか、とか、家を継ぐのか、みたいなことを聞かれることも多い

これは前時代的な価値観であって悪である

という主張をするのも、なんだこいつ、と思われたくなくて、雑にハハッと流してしまう

あと単純にこの話いつまでするの？みたいな長さで喋ってしまいそうだし面白いのかわからない
そしてつい悪とか言い出すので揉めそう

会話をする気持ちの筋肉がたぶんない、書くのはある

締め切りを逃した場合、そういうタイプの面倒くさい話に延々と付き合いつづけてくれる人と今後出会う可能性は…あるにせよ現実的にかなり苦労するor無理なので締め切りまでに届け出るのがよい

そういう

感じです

プロポーズにあたってはこれからも楽しい思い出を作りましょうという話をした。結婚してからも、もうやだ面倒くさいと言われ続けていて、私の性格が多分本当に面倒なタイプなんだろう、というのを日々自覚しながら生きています。

2020-06-21 政治的にっき

OSSで開発されている製品があり その製品を他者へ提供している組織Aがあり、 元々のOSSの開発者にその製品から得られる利益が還元されているかというとそうではなく、 組織Aのユーザーから元々の開発者に要望が来て疲弊する。

いつもの構図では。

その中で製品の質についてはOSSであろうがなかろうが評価されてしかるべきだとは思う。 これが自由ソフトウェアであれば利用者が直して使えばよい、で終わる話。

しかしそのソフトウェアは組織Aの提供しているAPIを使わないと動作しない。 結局直したところでみんなが使えるようにできるのは組織Aだけ。 クローズドなAPIが組織Aにしか提供されていないから (完)

なにをどう頑張ってOSSで開発してもつらいエンドになりそうな構図という感想。

2020-06-11 にっき

雑に掲示板を書いたのでQiitaにあげておいた

qiita.com

べんりだなー

最近はこの日記を書く前に力づきていた。 今日はPersonal Insightsを久々にやった。 自由主義98%ではなく調和2%を出してくるあたりさすがだ

引っ越すのでDNSの情報を更新しないといけない、忘れそう マイナンバーカードの証明書が無効になるので更新が必要、忘れそう クレジットカードの、銀行の、各種契約の届け出が必要、絶対漏れる

新しい家は買い物で絶対に今より歩くようになるしマクドナルドを食べるために死ぬほど歩くので絶対にやせる、やせる。そう信じている。

理想のプログラマー難しいですね

アヒルのように振る舞えたらアヒルという話がありますが、理想のプログラマーのように振る舞えたら…それはもう理想のプログラマーですよね:) https://fjord.jp/articles/2020-05-18.html

自分でMBTI診断テスト的なのをやるとINTP-Tなんですが

自分が頭痛のときや体調悪い時に妻に「助けてー」と言うと「医者じゃないから助けられない、病院へ」という正しいが無慈悲な答えが返ってくるのすごい好きなんですけど、妻が体調悪い時に自分が妻にそう言ってたのを真似しているだけだと発覚したことがあります。 なるほどー、自分は「助けられない」と言われると納得するけどそういうことか〜、なんせ自分の言ったことだからな〜。忘れてたけどw 妻によると「私の家族にそんなこと言う人居ないよー！」とのこと

いや、うちの家族にも多分居ないぞ...

2020-06-07 週末

沖縄県議会選挙へ行った。選挙はマイノリティにいれるで決めれば雑に入れられるので便利。具体的には男女比がおかしかったら女性にいれる、健常者と障害者であれば障害者にいれる、という感じです。

削除について考えていた、編集リクエストがscrapboxにないと思うのでQiitaにのせようかなあ。フォーマット変換大変だなあ。

scrapbox.io

絶対削除だめNOT NULLしかできませんのエクストリームな技を開発できる気がする

削除のやつは1日、2日かけて子をいい感じにいなしながら書けた

子の日中の睡眠を防ぐと21時以降の時間がつくれるがそれをすると私の体力もなくなるので、体力づくりが必要そう

やはり物理強いエンジニアは強いエンジニア...

次やりたいネタはこのへん

これに加えて weak_parameters 的なゆるい型の検査もできたらちょっと便利だろうなあ

別に action_args をいれる必要はなく params をwrapした別の CreateParams みたいなのを雑にコントローラの下に定義してそこで型つけてもいいかもしれない

はい

2020-06-05 rbsでRailsのアクションの型を付けたい、純粋関数的な指向の権限管理ライブラリが欲しい

REST麻疹 近況

仕事のAPIでRESTしたい熱が熱くなりすぎてしまった。 が同僚各位のおかげでいい感じに熱取れてきた気がする。なんでもリソース熱がまだある。直らない後遺症かもしれない。

自分の人間性についてつい考えてしまう

最近はやだやだRESTがいい〜。State全部返したいよ〜〜〜〜。全部リソースを表す名詞のURLがいい〜〜〜〜。というのをやっていた。（こんなに可愛いものではない）

他、神速さんのNULL嫌いのUPDATEしないDB設計を見て「エクストリームな矯正ギプスとしてマイグレーション以外ではARつなぐときにdelete/updateできない権限のユーザーを当てるとよさそう」と放言したり

speakerdeck.com

他、以前書いたActiveRecordのモデルが1つだとつらい の記事が言及されていた。(されてるよね?)

blog.toshimaru.net

他「はなちんさんにめっちゃ煽られて翌日買ったけど、煽った当人躊躇してるから刺しに行きたい」とメモリ32GB煽り事件の被害者の声を聞いたこともある。 あ、あと43インチ4kすごい! 便利! 端っこの方の通知見逃すけど! みたいな件もあったな...。

これらの事案を勘案すると、自分は過激な方に思想を倒して煽るが実際は堅実に進めるという人間性なのかもしれない。

  • 過激に煽る
  • しかし周りに止めてくれるよき隣人がいる
  • 私も最終的に日和るというか「まあそうだよね」と納得する

ここで納得するのは実装力が足りないのか、実効力がないのか、周りの人間のちからで正気に戻るのか...。 ううううう（プログラミング以外でもそういうことが多々あったのを思い出さないように頑張っている稼働音）

マイクアーム

届いたが結局同じ机につけている限り打鍵音などの振動は拾うのであった。 机の上は広く使えるようになったのでよいものとする

最近考えていること (あんまり過激ではないつもりです)

これが一番お得感が出るのではないかなあ。クライアントの生成のことを考えると全てがリソースで出来てるほうが何かと都合がよい気がする。

それの他にこれも気になっている。多分うまく動くと思う。

全うなHTTPを喋っている限りGETリクエスト中の権限は全てキャッシュして良いはず。 ただしGET以外の場合のことも考えると

  • 必要のない書き換えはしないはずなので readonly か何かで親のアソシエーションを取得
  • readonly? なオブジェクトを権限管理の関数に渡すとリクエスト中はキャッシュされる

こういう権限管理ライブラリがあるとうまくいくんじゃないかと思う

オブジェクト単位で権限を管理するつらみがあり、スコープで範囲を絞ったり、アクションごとにしぼる手法が開発されていそうな印象。 ちゃんと設計思想しらべてないから間違ってるかもしれないけど。

これもリソースを意識するとよさそうな気がしている。知らんけど。 リクエスト中にリソースは書き換わらない、readonly? ならば。 current_user もリクエスト中に書き換わることはない、readonly?で取得していれば。 であればそのリクエスト中リソースから current_user に与えられた権限は常に変わらないと仮定できる。 readonly? なオブジェクトを引数に取り認可を返す権限管理関数を定義すると、その関数はメモ化できる。

わいわい

決して過激派ではござません。

このあたりちゃんと動くのかを確認するサンプルを実装したい気持ちはあるけど、時間と実装力が足りない。誰か〜

いいなと思ったらKyashでお金を下さい
20191128011151
GitHubスポンサーも受け付けています
https://github.com/sponsors/hanachin/