2020-07-14 にっき
自分はアヒルのように動けばアヒル、Arrayを拡張して回転寿司のように動くArrayは回転寿司、そういう雑な気持ちでRefinementsを使っているんだなあ。べんりなので...。
これは雑すぎですがこういう感じ
Refinementsたぶん今だけ男みたいな気持ちと相性よさそう
— はなちん (@hanachin_) 2020年7月14日
「こうでもかけるんだけど〜」とクラスを定義しだすと「クラスでいいじゃん」になるかと思いますがクラスを定義しなくていいというのが便利ポイントなのでその辺の音楽性の違いっぽい。 あとは同じことをやるならメソッドにしなくてもよくて結果を説明的な名前の変数名に入れればいいのでは、とかもありそうだけど、それもやはりすごく特定のユースケースに合わせたメソッドをその場だけで使うことが出来る、というところに価値を見出しているんですよね。 一般的なメソッドを組み合わせて呼びたいわけじゃなくて特定のユースケースに合わせて作ったメソッドが生えているのがよい。 そういう意味でいうと自分はやはり語彙を再定義しているRSpecみたいなところをRubyの書きはじめの最初にガツンとうけてしまったので文化的な背景がやはり違いそう。
色々と話していてrefine(Array)
よりも refine(sushi.singleton_class)
のほうがより範囲が狭くなって Module.new
との相性がよいことに気がついた。
これの感想にリプ返していた
雑ではない仲間
rake タスクを refinements でなんかきれいにやりたいやつは普通にクラス定義してそっちに渡せばいいのでは……
— はくどー (@HKDnet) 2020年7月14日
そうなりますよね(テストできるし)
— はなちん (@hanachin_) 2020年7月14日
一時的にしか使わないタスクを未来永劫メンテし続けたくはなく、そういう終わったクラスをどうマネージするかみたいな問題があると思うんですが、それを解決できるかもって一瞬思ったけどやっぱテストしにくいし微妙かと思いました
— はくどー (@HKDnet) 2020年7月14日
雑仲間
https://t.co/ulkFjgBv2O
— Tsuyoshi Hoshino (@hoppiestar) 2020年7月14日
> rakeタスク中の処理を読みやすくメソッドにわけたいときもRefinementsは便利
これ! これ以外は なんとかなってしまう人生だった気がする
絶妙な雑さのときに便利なんですよね
— はなちん (@hanachin_) 2020年7月14日
名前つけたくないときとか
わりと書捨てに近いときとか
アプリケーションの中でライブラリみたいなことをやるときに補助的なAPIを完全にprivateなものとしてはやせるのはやはり便利そう
アプリケーション側だと『その場でのみ呼び出せるメソッド』を定義する時に使うなーより厳密な private メソッドを定義する場合とか / Refinementsの用法用量わからない日記 - hanachin temporary - https://t.co/H0oyDzyTDs
— バンビちゃん@実際クソザコメンタル (@pink_bangbi) 2020年7月14日
よく使うのが module を定義する場合に『その module 内でしか使わないメソッド』を Refinements として定義する。普通は private メソッドにすることが多いと思うけど private メソッドは外からも呼び出せてしまうので危険
— バンビちゃん@実際クソザコメンタル (@pink_bangbi) 2020年7月14日
こういう感じ
— バンビちゃん@実際クソザコメンタル (@pink_bangbi) 2020年7月14日
module M
using Module\.new {
refine M do
# M 内でのみ呼び出したい
def bar
"refinem M#bar"
end
end
}
def foo
# OK
bar
end
end
class X
include M
def hoge
# OK
foo
# NG
bar
end
end
これの何が便利かっていうと通常 module は『mixin された側でどういうメソッドが必要なのか』を考えて書く必要がある。
— バンビちゃん@実際クソザコメンタル (@pink_bangbi) 2020年7月14日
なので雑にメソッドなどを生やす事がむずかしい
けど、Refinements を使うと本当の意味で「M でしか参照できない」メソッドを定義することができるので雑にメソッドが定義できる
このような事がこの記事に書いてあるぞ! / 【Ruby Advent Calendar 2018】あなたのしらない Refinements の世界【3日目】 - Secret Garden(Instrumental) - https://t.co/vhKChdJxWd
— バンビちゃん@実際クソザコメンタル (@pink_bangbi) 2020年7月14日
補助的なメソッドを衝突気にせずバンバンかけるの便利そう
— はなちん (@hanachin_) 2020年7月14日
モジュール関数を使えば Benri.hoge(obj, a, b) みたいに書くこともできますが、Refinements だと obj.hoge(a, b) みたいによりオブジェクト指向っぽくかけるので便利ですねー
— バンビちゃん@実際クソザコメンタル (@pink_bangbi) 2020年7月14日
これもそうかな
Refinementsの用法でふと思ったけど、concerns のモジュール内でApplicationRecordやApplicationControllerを拡張するのは便利かも?privateメソッドでメソッド名の衝突を気にしなくて済むかも。
— 神速 (@sinsoku_listy) 2020年7月14日
いい話!なので特にリプをしていなかった
アプリケーションコードでrefinementsを使うことが全然ない
— Pocke(ぽっけ) (@p_ck_) 2020年7月14日
雑仲間だ
使い捨てメソッドを Refinements を定義することはよくある
— バンビちゃん@実際クソザコメンタル (@pink_bangbi) 2020年7月14日
なんでなんだろうなあ
Refinementsはそれを使うのが目的化しやすいような?
— カルパス🦜 (@yoshi_hirano) 2020年7月14日
他の言語にはない機能なのでなくてもだいたいのことは書けるんだけど、みんな実際使っていったら気に入ったりブロックの中だけでRefinementsを有効にしたりしたくなると思うんですよね、便利なので。
— はなちん (@hanachin_) 2020年7月15日
便利というのは使わないとわからないので使うことを目的にはじめるのもよいんじゃないかな派です。
いいと思います。アプリケーションコードの文脈だと他のアプローチを提案しそうですが。
— カルパス🦜 (@yoshi_hirano) 2020年7月15日
わ、わかるが...!w
— はなちん (@hanachin_) 2020年7月15日
アプリケーションコードだとなんでそうなってしまうのかわからないのがわかる(言語化できていない)
この辺を読み直しているけど使ってみるとやっぱり削がれてしまった機能をもとめてブロック単位のRefinementsとかを作り出してしまうので使い勝手がよくないだけなんだろうか
magazine.rubyist.net rubykaigi.org github.com
組み込みを拡張したいとなるとそうですよね、という感じ
標準ライブラリを拡張するときだけ使ってる / 1件のコメント https://t.co/7iSPYgSQna “Refinementsの用法用量わからない日記 - hanachin temporary” https://t.co/jWJhJf3F7C
— 神速 (@sinsoku_listy) 2020年7月14日
それRefinementsじゃなくても出来るよ、みたいな感じになりません? (ならない場面だけで使う?)
— はなちん (@hanachin_) 2020年7月14日
StringやArrayなどを拡張するときしか私はRefinementsを使っていないですね...。他はprependで事足りることが多いです。
— 神速 (@sinsoku_listy) 2020年7月14日
はい
人生で唯一真面目に書いたRefinements、1.secondをactivesupportなしでやるやつだけだわ
— wata (@wata727_) 2020年7月14日
activesupportを依存に追加すると死ぬ病
— wata (@wata727_) 2020年7月14日
— wata (@wata727_) 2020年7月14日
Refinementsの用法用量わからない日記
自分はわりとカジュアルにRefinementsを使うけど基準はどこにあるのだろう。と今日考えていた。
RefinementsSpecを読んでみる
はい
Monkey patching is a powerful feature of Ruby.However, it affects globally in a program. Therefore, a monkey patch might break code which doesn't expect the extended behavior, and multiple monkey patches for the same class might cause conflicts.To solve these problems, Refinements provide a way to extend classes locally. https://bugs.ruby-lang.org/projects/ruby-master/wiki/RefinementsSpec
モンキーパッチはRubyの強力な機能の1つ。しかしながら、モンキーパッチはプログラムにグローバルに影響を与える。したがって、モンキーパッチはモンキーパッチにより拡張された振る舞いを予期していないコードを壊す可能性があり、また一つのクラスに対して複数のモンキーパッチを当てるとコンフリクトを引き起こすかもしれない。これらの問題を解決するため、Refinementsはクラスを局所的に拡張する方法を提供する。
みたいな感じ?
局所的に、というのがキモっぽい
クラスの動作を拡張したいが局所的にしたい、というのが大事っぽい。 具体的にはどういうときなのか判断はわりとグラデーションがあると思う。
アプリケーションコードにおいて局所的に拡張する必要性
実はほとんどないのでは、と思う。
例えばアプリケーションのコードの動作を拡張したい場合
「アプリケーションコードの動作を拡張したい!」 「じゃあアプリケーションコードを書き換えようか (完)」
はい。
「局所的にアプリケーションの動作を拡張したい!」 「じゃあそういう設計でアプリケーションコードを書き換えようか (完)」
はい。
となりますよね。
現代のモンキーパッチはオープンクラスをせずにできる
モンキーパッチをどういうときに用いるかというと
- 組み込みライブラリの動作を変更したい
- gemで導入したライブラリの動作を変更したい
などアプリケーションコードとは違う自らが書き換えできないコードをダイナミックに書き換えるときだと思う。 じゃあそれモンキーパッチじゃないとできないの?というと現代だとそんなことはない。 例えば書き換えたgemをGitHubに置いてGemfileでgitリポジトリを指定すれば済む。
だがそれだともちろん局所性はない。
オープンクラスが必要な場面
やっぱり自分の手が届かないところのコードの動作を書き換えるときかなあ。(自分が書いてるのはだいたいそう)
局所性が必要な場面とは
例えば同じ名前のメソッドが被ると困るだろう。 でも現実問題アプリケーションコードのためにモンキーパッチで拡張したときに困るのって、既にあるメソッドの名前と同じ名前で書き換えたときぐらいしかなさそう。 別の名前のメソッドを追加して動作を拡張するのはまあ、名前がかぶれば変えればいいだけなので。
多分ライブラリを書いている場合は、ライブラリが使われる場面には手が届かないのでより局所性に気を使う必要がありそう、なのでRefinementsの使いどころはアプリケーションコードよりはありそう。
局所性を求めるとやっぱりRefinements、だが真に必要な場面は
局所性を求めるとRefinements、これは多分異論ないと思う。
だけど真にRefinementsでしか実現しないような使いどころとなるとかなり限られてしまいそう。
- アプリケーションコードではないライブラリの動作を拡張している
- アプリケーションコードの方の設計を変えられない
- ライブラリの方で定義されているメソッドの動作を変えるので局所性が必要
- 自分のコードがどこで使われるか分からないので自分のコード内だけで使う動作に局所性が必要
アプリケーションからは変更出来ないコードを変更したいが影響範囲を狭めたい、そのぐらいしかなさそうで。ほかはアプリケーションコード変えればいいだけだから。
アプリケーションのコードなのかライブラリのコードなのかの境界はどこにあるのか
例えばDeviseのモジュールを例にすると、Deviseのモジュールを使っているクラスにはDeviseのモジュール由来のメソッドがいくつか生える。
このときDeviseによって生えたメソッドを利用し、アプリケーション固有のユースケースを実現するコードはアプリケーションコードだと思える。 一方「この機能はDeviseの方でも持っていてほしいなあ、わりと特殊なユースケースかもしれないけど」と思うコードや「これはDeviseと組み合わせて使えるライブラリに出来るコードかもしれないなあ」というコードもあると思う。 それはアプリケーション固有の事情を表していないので純粋に単なるアプリケーションコードとしてしまうにはもったいない。
十分一般的な目的に抽象化されたアプリケーションコードはそれはもうライブラリなのでは、と思ってしまう。
Refinementsの使いどころにアプリケーションコードとライブラリの境目も含めてしまってよいのでは
そういう本来ならこのメソッドはライブラリに置かれててくれどうぞ、みたいな気持ちとRefinementsは相性いいと思うんですよね。
特定の場面でしか発生しないようなユースケースも十分抽象化されていたら実質ライブラリなのでは
例えば大クラス主義的にArray
に色々生えてて日常生活ではことたりるんだけど、たまーに「アプリケーション固有かもしれないけど each_with_いろは
がほしい」とかあると思うんですよ。
それもわりとアプリケーション固有なのかライブラリなのか微妙な立ち位置で、Refinementsがはまると思うんですよね。
関連レコードを引くとかscope使いたいとかそういうActiveRecordの機能によるのはactive_typeのようなgemを使ってやると思うけど、 単純にこの場面でだけだけメソッド生やしたいとかならRefinementsで生やすだけでも十分みたいなの結構あると思うんですよね。
Refinements使うのを気をつけたほうがよい場合
めちゃくちゃパフォーマンス気にする場合はRefinements使わない方がいいのかなあというふわっとした感想です。(要出典、ここはFUDになりそうなので書かないほうがよかったかもしれない)
動的にメソッドの動作を切り替えたい場合にもRefinementsは便利
無名クラスでもできるかもしれませんが #to_refinements
メソッドでRefinementsのモジュールを生成するようなコードを書くと using object.to_refinements
で動的に動作を切り替えられて便利そうです。
rakeタスク中の処理を読みやすくメソッドにわけたいときもRefinementsは便利
これに関してはモデルにうつしたほうがテストしやすいのでいい派が多分いると思います
これも特定のユースケースの場合のみ機能を拡張したい場合の1つかなあ 通常のアプリケーションコードの中では使われてほしくないけどrakeタスクの中だけではメソッドであってほしい、そういう気持ち。
何かを受け流すときにもRefinementsを使うと便利
例えばRuboCopで定数のfreezeを呼びたいけどどうしてもテストではfreezeされてると都合が悪いとき、とか。
以外と真に必要そうなケースあるな
用法用量所感
どうしてもRefinementsじゃないとダメ!となる前にアプリケーションコードの変更でどうにかなってしまう場合が多い。 なのでそういうどうしようもない場合にのみRefinementsの処方を限定するとRefinementsを使う機会がかなり減ってしまうと思う。
アプリケーションコードなのかライブラリなのか曖昧な、アプリケーション固有のユースケースのようなそうでないような、ライブラリに置かれててくれどうぞ、みたいな気持ちとRefinementsは相性がいいと思う。
まとめ
ハチャメチャにRefinementsキメましょう
2020-07-12
生活を整えるためにカーテンとワードロープと姿見と床マットなどなどを見ていた
カーテンはとりあえず窓が増えた分を買わねばなない。 あまっているカーテン情報があったので、あまってるカーテン情報を貰ってから買う。 サイズ的には既成品で足りそうな見通しなので、サイズが合わなかったらポンとかえばよさそうな感じ。 遮音遮熱遮光防炎を選ぶとぐっと選択肢が狭まって便利。
ワードロープは鏡がついているしっかりしたタイプだと鏡が割れたときに補修が面倒そうということで安いパイプ + カバーみたいなタイプのと姿見を別で買うことにする。 しかし鏡の店頭在庫が全然なくて厳しい気持ち。
床マットに関してはニトリの店頭でクッションマットを見ていたけど結局マットを敷いて変わるか変わらないかは下に知り合いでも住んでいない限りわからない、二階ある家に自分たちで住んでみると実験できるかもしれないが。 そして店頭で防音と書かれていても商品の説明に防音と書いてある種類は結構少ない。 クッションマットに関しては水こぼすとつるっとすべってコケリスクが++みたいな説明があった。
クッションマット: 安い、広範囲をカバー出来る、すべる、ださい、あつそう、取り替えが省スペースだけ出来る 防音ラグ: クッションまっとよりは高い、広範囲をカバーできる、すべらない、ださくない、あつそう、取り替えが一部だけはできない(小便耐性が低い) フロアに敷くウッドカーペット的なもの: 防音なさそう、多分一番高い、取り替え一部一応できそう、小便耐性はわりと高そう
みたいな感想で、まあ敷くならラグかな...という感じがする
rbsからtsはくやつの雑なgem化していた
がrbs 0.6.0にあげたりしていたら動かなくなっていた
typing_options :strict
つけているときのリレーション周りの型がうまく通し方がわからない
このへんはこうでよさそう
module ActiveRecord::AttributeMethods::PrimaryKey attr_accessor id (): Integer end class ActiveRecord::Base extend ActiveRecord::AttributeMethods::PrimaryKey end class ActiveRecord::AttributeMethods::GeneratedAttributeMethods end class Board < Board::GeneratedAttributeMethods end class Board < Board::GeneratedAttributeMethods class GeneratedAttributeMethods < ApplicationRecord end end
interface _ActiveRecord_Relation_ClassMethods[Model, Relation]
が難しいきがする
class Board < Board::GeneratedAttributeMethods extend _ActiveRecord_Relation_ClassMethods[Board, Board::ActiveRecord_Relation] end
するとこうなる
app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.all (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.ids (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.none (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.pluck (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.where (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.exists? (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.order (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.group (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.distinct (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.or (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.merge (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.joins (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.left_joins (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.left_outer_joins (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.includes (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.eager_load (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.preload (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.find_by (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.find_by! (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.find (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.first (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.last (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.find_each (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.find_in_batches (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.destroy_all (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.delete_all (class Board < ApplicationRecord) app/models/board.rb:1:0: MethodDefinitionMissing: module=::Board, method=self.update_all (class Board < ApplicationRecord)
どうしたらいいんだろ
2020-07-11
転居に向けて整えていた。三ツ口コンロが待ち遠しい。
カーテンレール、シングルの物件にいまだ住んだことがなかったが、どうしよう。 レースカーテンって結局レース部分をあけることがほぼないので突っ張り棒とかで布でも垂らそうかな。
生活をしていると様々な物事を考えなくてよくなるのでべんり。暮らしは大事。
YubiKeyが届いたけど耳から垂らすには結構なでかさであり、及び腰になる
ピアッサーでついたファーストピアス、前後への移動がかなりスルスルいくようになっていて内部で何かしらの変化が起きていそうなのを感じる。
新居のベランダについて隙間から子どもがはみ出ないか調べていた。結論はみ出る。 どうやって防御するといいのだろうか、ベランダって自分の敷地じゃなくて共用スペースだからあんまりものとかを設置したくないではある。 網かけるぐらいかなあ。
久しぶりに県立図書館へ行って鉄道の本を借りてきた。子が真の踏切を見たがる頃までLCC続いてコロナ終わっててほしい。
2020-07-08
ピアッサーで左耳たぶに穴をあけた
開通した pic.twitter.com/3YFaK70uaj
— はなちん (@hanachin_) 2020年7月8日
初ピアスです、まだ0x20歳じゃない、若者だから……
YubiKeyぶらさげたい(?)
2020-07-04 6月のにっき
数字
- Slack: 2513発言
- コード書いてるのか〜〜〜?
- merged pull request 22つ、1,344 ++ 432 --
- unmerged 1つ
- 数え方がわからない
- とにかく巨大に育てたという事実だけある (4桁変更in3桁ファイル)
リリース所感
私の仕事として、いい感じのドアを作って関係者以外立ち入り禁止からみんなが入れるようにするまでは気にかけるけど、誰か入ってくるまでの間をどうこうしようみたいなところに行けていない気がする。中に入るときのワクワク的な...(知らんけど)。 産地直送便利機能紹介記事みたいなのを一度書いてみるといいのかもしれない。
RSpec
わりともりもり書いた
64GBメモリ
快適になった。
画面が固まる
カーソルだけはうごくが全体の画面が固まるみたいな現象が起こるようになった。 モニターアーム導入のせいなのかHDMIケーブルが抜けかかっているのが原因で抜き差しすると直る。
趣味
reference tableをやっていた
サンプルリポジトリ
ghコマンドでリポジトリ作る時明示的に --public
つけないと公開されてないのしらなくて公開した
型付け関連でPRをいくつか出していた
他るりま2つ
設計
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の論理削除回を聞いたりしている
引っ越し
引越し先を決めた、引っ越しする。入居予定まで日にちがあると思ったらなくなっていて慌てて各種の申し込みをしている。 電気水道ガスインターネットの順に着弾する予定
反省
この辺の設計の話を共有してもよさそうな場所があったんだけど共有できなかった、主にプログラマーがしゃべる共通言語が通じなさそうなので面倒という点で、それでも伝える努力をするべきだったと思うので猛省している。 具体的には、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無理なので締め切りまでに届け出るのがよい
そういう
感じです
プロポーズにあたってはこれからも楽しい思い出を作りましょうという話をした。結婚してからも、もうやだ面倒くさいと言われ続けていて、私の性格が多分本当に面倒なタイプなんだろう、というのを日々自覚しながら生きています。