タグ

ブックマーク / kumagi.hatenablog.com (9)

  • Re: Re: Re: ドメイン固有型(値オブジェクト含む)を再考する - Software Transactional Memo

    blog.j5ik2o.me この記事は彼のブログ投稿への返信です。 彼とのtwitter上でのreplyの応酬スレッドが見返すと引くほど長くなっていたので僕の観点からの要約を纏める。予め断っておくとこれは当に自転車置き場の議論以外の何物でもなく、技術的な学びはどこにもない不毛なやりとりであって、苦労して理解する価値がなかったなどの苦情は受け付けない。 kumagi: 値オブジェクトはIDによらない等価比較をするオブジェクトの事であって、ドメイン固有の値オブジェクトもそうでない値オブジェクトもある。 かとじゅん: それはおかしい。全ての値オブジェクトは何らかのドメインオブジェクトの一部であって、Integerすらも整数ドメインの問題を解決するために設計されたドメインオブジェクトと言える。Evansも肯定しているはずだ。 kumagi: なるほど、その整理の中で逆にドメインオブジェクトでな

    Re: Re: Re: ドメイン固有型(値オブジェクト含む)を再考する - Software Transactional Memo
    you21979
    you21979 2022/08/10
  • NFTとメタバースについて思うこと - Software Transactional Memo

    TL;DR NFT投機界隈のデタラメに気をつけましょう ブロックチェーンはデータに価値をもたらすのか もたらさない。 NFT界隈がよく言う「希少性」自体には何の価値もない、部屋の隅に落ちている埃だって厳密には世界に全く同じ物は存在しないしデジタルデータのように完璧かつ無制限に複製することもできない、それでも価値はない。 ブロックチェーンのwalletを作成したら既にそのwalletは自分の唯一無二な所有物となるが作成時点でwallet自体の価値は空である。希少や有限であること自体を根拠に出資を迫ってきたらそれは詐欺である。 希少or有限な物にお金を払うモチベーションがあるとするならばそれは実需を除くとそういう信仰があるからに他ならない。伏見稲荷大社に21万円払えば5号の鳥居が奉納できるがやってる事はそれと変わらない。伏見稲荷大社に置ける鳥居の数は当然有限だが、有限であることだけを理由に奉納

    NFTとメタバースについて思うこと - Software Transactional Memo
    you21979
    you21979 2022/02/13
    無限に法定通貨の価値が下がり続けていると考えるとまた考え方が変わってくるとは思う。お金だって人が作ったものだし、ブロックチェーン、NFTだって人が作ったもの。ゲーム系は買わない方がいい。ナーフで暴落必須
  • ソフトウェアエンジニア、建売を買う - Software Transactional Memo

    買った戸建てに付けた表札、住所はぼかした プロローグ 新型コロナが世間を騒がせ始めて以来ずっと在宅勤務をしている。 転職に伴って会社近くに引っ越したので通勤のドアtoドアで30分台を叩き出していた好立地はその活躍の機会をすっかり失った一方で、妥協した40平米の部屋の狭さと1LDK+Sの間取りが巣ごもり子育て核家族を襲った。 外で遊び足りない娘は泣き、広がった活動範囲で家中の物を無秩序に引っ掻き回すので必然的に触られたくないものは高いところに置くことになり、立体的に活用される事になった1LDKの空間は生活の難度を高めジワジワと真綿で首を締めるような状況が続いた。 住んでいたマンションは駅に近いのは良いが作りは古く、冬には窓枠が結露しカビが発生する。窓から降りる冷気はそのまま壁や床にすら結露を起こし室内はカビに見舞われた。それとの因果関係は不明だが冬場の慢性的な体調不良が家庭内の治安を更に悪化

    ソフトウェアエンジニア、建売を買う - Software Transactional Memo
    you21979
    you21979 2021/08/07
    以前のように会社に勤務するならマンションも良かったと思うけど、自宅で仕事をするなら一軒家の方が自由度が高い分すごしやすい。金利に関してはそろそろ防衛したほうがいいと思うけど。
  • 6年勤めたNTTを退職しました - Software Transactional Memo

    最終退社時の自分の机 2012年に修士卒からの新卒でNTT研究所に入り、6年間お世話になりました。 研究所では同期や先輩や後輩や上司に恵まれ、存分に書籍や論文を読んで勉強して力を蓄えたり、対外的な発表の場にも恵まれ外ではできないような体験をすることができました。 ありがとうございました。 入社当時に作られたtogetterを見返すと togetter.com togetter.com まるで昨日のように感じられる。 NTT社内で僕が何をやっていたかについては言える物は軒並みアウトプットされているのでわざわざここでは触れない。 NTT研究所について NTT研究所を客観的に見た時にどうかを書いていく とにかく人に恵まれている。採用の倍率が高いのもあって潤沢な学生エントリーからよりすぐりのエリートが謎の力でポテンシャルを見極められて採用されている。同期を見てひと目ですごい奴も居れば、一見してわか

    6年勤めたNTTを退職しました - Software Transactional Memo
    you21979
    you21979 2018/11/26
  • NTTによるブロッキング論点の整理 - Software Transactional Memo

    NTTがブロッキングを発表してから様々な反響があったのでざっと眺めて反応を主観でカテゴライズしてみる。 TL;DR; NTTも政府もしっかりしろ。あと違法行為はやっぱりダメだ。 今回の措置に賛成だよ派 困ってる人がいるからしょうがないよ派 プロバイダ責任制限法を越えるから仕方ないよ派 やまもといちろうが気にわないよ派 他の国ではやってるよ派 反対派は漫画村ユーザだよ派 ブロッキングは合法だよ派(宛先は通信の秘密に当たらないよ派) 政府がそう言ったらしいよ派 緊急避難が適用されるから合法だよ派(児童ポルノと同じだよ派) なるべく速やかに立法すべきだよ派(結果整合派) 違法だからどうした派(アナーキー派) 今回の措置に反対だよ派 当に緊急回避が成り立つなら賛成だよ派(漫画村もうないじゃん派) 立法の後なら賛成だよ派 さっさと立法しろ派(法治重視派) 憲法21条も一緒に修正しろ派(整合性重視

    NTTによるブロッキング論点の整理 - Software Transactional Memo
    you21979
    you21979 2018/04/30
  • NTTによるブロッキングの何が許せないのか - Software Transactional Memo

    注意: この記事は私の所属する組織の意思も意見も絶対に断固として欠片すらも表明する事を意図して書いていません TL;DR;今回のサイトブロッキングは私見ではダメだと思ってるけど、国の言うロジックは一応わかるし勘違いベースで応援するのも叩くのも止めて欲しい 前提知識 まず大前提として、日には憲法というものがあり、その21条にはこのように明記されている。 憲法第二十一条 集会、結社及び言論、出版その他一切の表現の自由は、これを保障する。 検閲は、これをしてはならない。通信の秘密は、これを侵してはならない。 憲法に沿った国の運営をするためここから派生して制定されている法律のうち、今回の件に関係が深いのは電気通信事業法である。 電気通信事業法 (検閲の禁止)第三条電気通信事業者の取扱中に係る通信は、検閲してはならない。 (秘密の保護)第四条電気通信事業者の取扱中に係る通信の秘密は、侵してはならな

    you21979
    you21979 2018/04/24
    自衛権の解釈と同じで徐々にエスカレートすると思うけどな。
  • 分散ロックという名の過ち - Software Transactional Memo

     TL;DR; 「分散ロック」が分散システムの設計図に登場した時 だいたいその設計は間違っていて当に必要なものはトランザクションだ 並行システムを実装する際にロックを用いるのはとても自然なことだ。 僕も普段はロックフリー系のアルゴリズムに詳しいと言われがちだが知識量でいったら実はロック系の方が多く蓄えているかも知れない。 分散システムは並行システムであることが多いので、その中にロックが登場するのはとても自然な発想である。 よく「分散」「並行」「並列」の言葉の定義がごっちゃになっているケースがあり、この記事の主題にしたいわけではないので深くは言及しないが、分散システムは環境などの要因で突如として参加者が音信不通になったり復活したりする点で並行システムと大きく異なる。 並行システムと同じノリで分散システムを設計しようとした際に陥る頻出の過ちが「分散ロック」である。そのアイデアはとても簡単で

    分散ロックという名の過ち - Software Transactional Memo
  • 分散プログラミングモデルおよびデザインパターンの考察 その1 - Software Transactional Memo

    Yahoo技術者が書いたブログ techblog.yahoo.co.jp が悪い方向に期待を裏切ってくれたのに対し、 @kuenishi さんがまとまった文章 kuenishi.hatenadiary.jp を書いていたので、僕も2番煎じぐらいでまとまった文章を書く。 始めに断っておくと、分散システムというのはまだまだ事例を集めていくフェーズを抜けきっておらず、体系立った大統一理論的な分類法は確立していない。ここに書くのは、これまでの分散システム事例やこれからの分散システム事例を分類していく際にその性質をカテゴライズする一助となれば良いな、程度の文章なのであまり真に受けないで欲しい。 なぜYahooの記事が期待はずれなのか 人によって意見はあるとは思うが、個人的に感じたのは以下の3つ。 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじ

    分散プログラミングモデルおよびデザインパターンの考察 その1 - Software Transactional Memo
    you21979
    you21979 2016/02/24
    「小さなシステムでは達成不能なパフォーマンスを実現するため(性能) 個々のコンピュータで故障が発生しても動き続けて欲しいため(耐故障)」
  • 分散プログラミングモデルおよびデザインパターンの考察 その2 - Software Transactional Memo

    前回の記事では 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじつける事を「分散システム」と呼んだ事。 システム全体を決定づけるわけでもない通信パターン上の選択肢の一部を切り出してシステムの質のように呼んだ事。 プログラミングモデルと言いながらプログラミングモデルの話が一切出なかった事。 のうち一番上についてしか書かなかったので次に真ん中の項目についての話をする。物事を分類する際の一般論としては MECE であることが好まれるがYahoo!の記事はレイヤーも目的も様々な物を一緒くたに語っており、取り繕おうにも議論の空間があやふやなので何に対して網羅的なのかも議論ができない。「マスターやワーカーというのは役割の議論であり通信パターンの議論ではない」「Producer-Consumerはデータフローの一種と呼べないのか?」「データフローは

    分散プログラミングモデルおよびデザインパターンの考察 その2 - Software Transactional Memo
    you21979
    you21979 2016/02/22
  • 1