  |
はてなキーワード: ユースケースとは
以下の記事、内容がひどくて空いた口が塞がらなかったのだが、
（はてブで）ブックマークして下手にホッテントリにでもなったら嫌だなと思いそっとブラウザのタブ閉じた。
が、しばらくすると残念ながらホッテントリ入りしてしまったので、はてブにコメントを軽く書こうとしたが100文字に収まらなかったので増田にした。
技術選定の失敗 2年間を振り返る TypeScript,Hono,Nest.js,React,GraphQL
まず、「特定条件下では MySQL は我々のプロダクトには不向き」を「MySQLを使うと会社は潰れる」なんて表現するのおかしいでしょ。
以下の記事からの引用だが Uber のエンジニアは「PostgreSQLではアーキテクチャに制限がありすぎてUberのシステムを支えきれない、MySQL＋InnoDBに変えたら全部解決した」と主張している。
UberエンジニアがブログでPostgreSQLにダメ出し、PostgreSQLコミッター石井達夫氏に反論を聞く
RDMS（に限らずライブラリやミドルウェア一般）の評価は採用する開発プロダクトの要件とユースケース次第。
Not for me/us. を「これを使うと会社が潰れる」って……MySQL開発チームから名誉毀損で訴えられろと思う次第。
(サーバサイド開発の言語は）TypeScriptでいい。と言いつつ、結論はこれ
| TypeScriptで書いたサーバーサイドのコードの半分ぐらいも属人化している。なぜかメンバーのキャッチアップが進まない。
ん？？？？
こんな評価眼で開発力で文章力の人を「厭味が無くて楽しめた」だの「公開してくれてありがとうございます」とか言うブクマカにもそれにスターをつける人にも衝撃だよ。
ちゃんと読んでくれよ。それから、ブックマークするか判断してほしい。あーあ
---
| 逆に、Uberエンジニアに対して、PostgreSQL開発チームから名誉毀損で訴えられろと思わないのは何故？
という言及への返信。
Uber に関しては。
自分たちが扱う規模のデータを捌ききれないという問題を、その原因が利用者（Uber）側ではなくデータ永続化におけるPostgreSQLのアーキテクチャが原因だと思われるということをきちんと測定して結論してるからかな？
さらにUberはそのことを安易に「PostgreSQLを使うと会社が潰れる」というような煽り口調の一般化をせずに自社には不向きだったということをブログに載せているため議論の土台が開けていることが重要だと思う。
今回の問題の記事はRLSとID採番というデータベースの根幹機能ではない付加機能で自分たちのプロダクトとミスマッチしているだけで一般化して罵ってるのが悪質だと思うんよなぁ
学がない旅行は悲しいという趣旨のXの投稿を見た。旅先で見たものに思いを馳せずにただキレイだと思うしかできないからという理由らしい。
たしかに言っていることは尤もに見える。
たとえば学がある人にとって姫路城は見た目の美しさのみならず、城が辿ってきた歴史の面でも格別である。他の城にも物語があり、それぞれが持つ物語が城を特別で代替不可能なものに変える。一方で学がない人にとっては城なんて全部一緒に見える。木造か鉄筋コンクリかなんて知らないし、関ヶ原以前に建てられた城も昭和に建てられた城もいわれなきゃ気づかないし、わざわざ調べない。学がない姫路旅行は2つの観点から悲しい。姫路城が数百年の間に経験した災難を乗り越えていま自分の目の前に建っている。この感動を抜きにして姫路城をただのランドマークとして消費してしまうのは悲しいことこのうえない。それに、都内に住んでいる人がわざわざ、1時間に1本しかない東京駅発姫路駅停車の「のぞみ号」を調べたり、日帰りで行くのは勿体ないから...とホテルを複数のサイトで比較して安くて良いホテルを探したり、といったことをしても得られる喜びは東海道本線での日帰り旅行で行く熱海城と同程度だとしたら時間とお金の無駄である。
まず第一の観点は今回無視する。絵具をチューブから直接キャンバスの上に出したような現代の抽象画について、どんなに説明を聞いても良いと思わない人がいるのと同じで、学と旅行を結びつけることに根本的に喜びを感じない人もいるからである。そのような人の存在を疑うなら修学旅行を思い出してみてほしい。団体行動の時間にはたいていの場合、歴史の授業で最近習った場所に連れていかれる。それに、ツアーガイドさんの補足説明もある。しかし、帰りの新幹線の中で学がある旅行の感動について語り合っている人はいなかっただろう。
第二の観点についてもう少し拡大して考えたい。すなわち、同じに見えるのにわざわざ遠くの有名な観光地に行くことは時間とお金の無駄だ、という着眼点で「よく分からないけどキレイな観光地」にわざわざお金と時間を余分にかけて行く人がそれなりにいるのはなぜか、ということを考察する。
グループ旅行について考えるほうが簡単なので先にグループ旅行から考える。家族や友人と行く旅行は仲を深めたいだとか、近場での遊びよりも長く一緒に過ごしたいだとか、いろいろな理由があるが、そこの違いは無視する。身も蓋もない言い方で結論をまとめると、みんなでわざわざ遠くまで行くのは共通の思い出作りだ、ということになる。しかし、これでは「なぜ熱海城ではなくて姫路城でなければダメか」の答えになっていないので旅行でよく起こるイベントを丁寧に見ながら先の論題への回答とする。
旅行に関する出来事を時系列でたどると初めには誰かが「旅行に行かないか」と言い出すことから始まる。旅行先は旅行の幹事が勝手に決めることもあれば、みんなが納得するように話し合いで決めることもある。「もしダーツで旅行先を選んだら、旅行先は決めたのではなくて勝手に決まったのではないか？」」という奇異な意見もあるかもしれないが、そのケースでも「ダーツで旅行先を決める」ということを決めている。そして、それぞれの決断にはなんらかの共通認識が必ずある。「みんな社会人になったからスケジュールをコンパクトにしよう。で、その分ちょっと予算多めにしよう」だとか、「卒業旅行だからせっかくだし海外に行こう」だとか、なんでもいいが何かしらの理由がある。そして、行きの新幹線(もちろん飛行機でもなんでも良い)に乗るタイミングでは必ずドラマが発生する。誰かが乗り遅れたらそれはずっと話のネタになる。誰も乗り遅れなかった場合、もし全員が旅慣れしてれば「みんなの深い知識と経験のおかげで誰も遅れることがなかった。」と言えるし、旅慣れていない人がいれば「旅に慣れてないのに複雑な東京駅で迷子にならなかったのは奇跡だ。旅行が楽しみだからみんな早めに家を出たのかもね。」とかなんらかの会話が生まれる。そして、目的地に着いたときに旅行に関する過去の出来事がある特定の景色やランドマークと結びつく。「新幹線に乗り遅れて一時はどうなるかと思ったけど、全員で一緒にこれが見れて良かったね。」とか、「幹事やっぱセンス良いわ～」とかといった具合だ。この瞬間に、「他の城との違いはわからないけど有名らしい姫路城」は「みんなで行った姫路城」になる。冒頭で言及したＸの投稿では学がないと何を見ても同じようにキレイとしか思えないとされていたが、自分はエモいという言葉で表現することを提言したい。エモいという言葉はキレイという言葉よりも、汎用的でなんにでも使える。その言葉の広さがもつ暴力性から、攻撃の的とされている言葉だが、この広範さが旅行では逆に良い。旅行に行っていない人に「エモかった」と言っても旅先で見聞きした素晴らしいものは1mmも伝わらないが、むしろそのほうが旅行の当事者だけにしかわからない秘密の合言葉のような効力をもつ。誰かといった旅行で、ここぞというタイミングで「エモいね」と言ってみてほしい。言われたほうは初めは意味がわからなくて首を傾げるかもしれないが、意図がわかれば「そうだね、エモいね。」と返してくれるだろう。もちろんどれだけ待っても意図が理解されない可能性もあるのでタイミングと使う相手には注意していただきたい。「学がある旅行」は旅行の中にぽつりぽつりと学と実物が交差する点があって、そこに感動を覚えるといったニュアンスであると自分は解釈したが、タイトルで先に出していた「エモい旅行」のエモい、は形容詞であるため、旅行の全体にかかる。
学がある旅行以外での一人旅行も実はほぼ同じである。何かしらの理由があって旅行先を決めるし、旅行先に行くまでに何かしらのドラマがある。ひとつだけ違うと感じるのは、一人旅では共通の思い出を作る相手がいない代わり、その時の感情の一部をスナップショットのように観光地に釘付けして保存しておける点だ。たとえば、自分は大学受験の直前にモチベーションを完全に失って、いつも通学に使っている電車の先の海が近い駅に行った。あの海を見ると受験のプレッシャーから一周回って解放されて、燃え尽きるまで頑張った自分を全肯定した清々しさを今でも思い出す。あの頃にはエモいという単語すらなかったが、思い返すとあれもやはりエモい旅行だった。
## 概要
提示された文章は、機械学習モデルの評価方法に関する重要な指摘を含んでおり、おおむね正しい内容だと言えます。
## 詳細
### 精度基準の設定
## 総括
提示された文章は、機械学習モデルの評価における重要な原則を適切に指摘しており、おおむね正しい内容であると言えます。モデル評価の際には、これらの点に留意する必要があります。
それで、上司にデモを見せる。上司がモデルが失敗する細かい条件を見つけ出し「ダメだよ君ぃ、こんなものをTrueにしちゃうようじゃ」と言う。
これは不毛なやり方である。いつまで経ってもモデルにOKサインが出なくなる。
バッテリーがいくら巨大になっても、一晩で安定して充電できる電力がせいぜい80km分ぐらいなので（気温などの条件もあるので）長距離の選択肢にはなっていかないんよ。
ルート配送の車も、郵便局の一日30kmとかはユースケースとしてはあるんだけど、増田が言ってるガススタが消えていくような集落だと平気で一日100kmとか走る事になる。すると急速充電施設がないと駄目なんだけど、そういった所は変電所の容量の問題から急速充電もかなり厳しい。
バッテリー容量が大きくなっても、田舎の町一戸分が使うぐらいの専用変電所を備えた急速充電施設なんて作れないので、現在よりも大容量の急速充電施設を増やすのは難しい。だから1回30分の充電で100km分ぐらいしか充電できない。
日常的な長距離移動は、家で充電、よくて到着地点での充電で帰ってこれるぐらい限度になっていくと思われ、手段が目的かしても大丈夫な趣味用途ならともかく、実用だと厳しい。
ある日の同僚との会話
同僚「〇〇（弊社で展開しているサービス。開発は他社）を分かる為にどんな資料が必要？」
増田「誰に見せる為ですか？」
同僚「誰にとかじゃなくて資料を作りたいんだけどどんな資料？」
増田「何を理解するための資料ですか？サービス全体？インフラ？ソース？」
同僚「だからさ～（キレ気味）」
上司「〇〇の開発を自社でやりたいけど○○の動きとか機能が分からないんだけどどうすればいい？」
増田「ならユースケースやインフラ構成くらい作って、そこからは実際にテスト環境叩きながら開発している他社と連携すれば良いんじゃないんですか？」
へそ曲げて自席に帰る同僚
自分より年上だけど、ほんとどうやって仕事してきたのか分からない。お膳立てされた上で仕事してきたのだろうか。調査とかそういうのとは無縁だったのかもしれない。
だからアバウトな依頼を咀嚼してタスクに分解して相手に分かりやすく伝えることが出来ず、アバウトな依頼をそのまま伝えてきて返事が期待通りじゃないと相手のせいだと思って機嫌が悪くなる。
20代なら分かるけどこんな50代とか安月給でも無駄だしほんと日本の産み出した廃棄物だわ。一番怖いのが何回も同じような事があっても考えを改めない事。
俺がシステム屋として見てきた限りでは、デザイン屋とシステム屋が別々で
UI/UX何それおいしいの、というシステムが量産されているように思う。
システム屋はプロジェクト初期、まだデータ構造やアプリのユースケースの詰めが甘い段階でデザイン屋に依頼する。
プロジェクトが進むと、システム屋は開発中の様々な問題に対応するために、もうデザインどころではなくなる。
デザインを修正するとしても、ビジネスロジックの深い所にも影響が出る実装を〝やらかして〟しまっており、デザイン修正に対しては激しい倦怠感・嫌悪感。
プロマネは「動くアプリが納期までに完成するか」を祈る事しかできない。トラブル続きで、UXに気を配る心の余裕などない。
https://anond.hatelabo.jp/20230611160913
のつづき
解答「ガチャをはじめ、ゲーム性に不可欠な乱数を扱うのはブロックチェーンではそもそも困難です。乱数を得るのに、乱数オラクルと呼ばれる外部サービスに依存しなければならず、しかもそれが高価だからです。ゲームのような頻繁に乱数を要するようなユースケースには耐えられません。それを嫌って、乱数オラクルを自社運用したとすれば、ソシャゲのガチャと何も変わりません。むしろ金銭的利益と直結するBCGにおいては、運営側に乱数を操作するインセンティブが生まれるので、運営の不正が蔓延するでしょう。」
※別解「ゲームロジックのようなデータ量が多くて複雑な計算は、手数料が高すぎてスマートコントラクトでは実行できません。結局、重い処理は今まで通りブロックチェーンの外で行わなければいけないので、フェアなロジック実行、チート対策などが、ブロックチェーンだからできるということにはなりません。」
解答「ゲーム内資産を金融商品化するせいで、ゲームがギャンブルになってつまらなくなるのです。GameFiは本来のゲーム性を破壊する悪の根源です。出てってください。」
解答「全く関係ありません。VR界隈から嫌われているので、はやく片思いだと気づきましょう。」
解答「全く関係ありません。AI界隈から嫌われているので、はやく片思いだと気づきましょう。」
解答「Rollupによるスケールはシステミックリスクを増大させる恐れがあり、銀の弾丸とは呼べません。複雑なインセンティブ設計で維持されている流動性ブリッジで接続し合うRollupの網の目は、マネーレゴの一部品のハッキングやラグプル、ブラックスワンイベントをきっかけに、悪影響が波及して全体として崩壊しかねません。WEBがスケールしたのは、一部の障害が全体に無影響であるからです。トークンを触媒にして密結合するRollup網は、大きくなればなるほどシステミックリスクが高まり、むしろ脆くなっていくのは想像に難くありません。」
※別解「スケールすればするほど、Time-bandits攻撃と呼ばれる攻撃のリスクが高まるでしょう。子レイヤーで発生するMEVの合計が、親レイヤーのバリデータのペナルティを差し引いても十分に余るようになれば、親レイヤーの安定したコンセンサスを守るためのインセンティブ設計が成立しなくなります。」
解答「Web3といいながら政府発行の法定通貨に依存するのですか？恥を知りましょう。それはプロダクトキラーの間違いです。Web3がこのような新しい用語を頻繁に発明するのは、矛盾を巧妙に隠蔽するためです。ステーブルコインはそれに最も成功したバズワードの一つです。」
解答「善悪を恣意的に定義し、経済的インセンティブで善に誘導するのは新しい共産主義です。」
解答「ブロックチェーンはデータの保管には向いていません。ビザンチン耐性だけなら分散DBで事足ります。もし改竄耐性が欲しいのであれば証明書チェーンのような仕組みで事足ります。すでに一部の界隈ではブロックチェーンではなく、VDR（Verifiable Data Registry）という言葉が代わりに使われるようになっています。ブロックチェーンはわざわざ使わなくて良いのです。」
解答「ブロックチェーンが必要となるのは、悪玉ピアを含む不特定多数が参加するP2Pネットワーク上で、読み書きの権限を不特定多数に開放している台帳プロトコルの状態遷移のコンセンサスを取りたい場合のみです。ビジネスにおいてここまで過酷なことを要求される場面はほとんどありません。特に不特定多数を相手にするという性質がコンプライアンス遵守と相反するのでビジネスにならないことが殆どです。数年前からWhy Blockchain？という問いに挑んできた企業の多くがブロックチェーン事業に挫折したのはここに起因します。」
解答「インターネットは通信回線やパソコンの普及などインフラやハード面が未熟だったためその真価が発揮されるまで時間がかかりました。しかしWeb3で不便とされる側面は、物理的なものではなく原理的なものに起因します。ブロックチェーンのトリレンマから言えば、分散性を諦めない限りスループットは上がりませんし、手数料も安価にはなりません。悪名高いパスフレーズはなくせません。それらは性質として受け入れないとならないのです。また、詐欺が多いという非技術的な課題は規制でしか解決できませんが、Web3業界は規制を目の敵にしています。自ら課題解決を放棄しているのです。」
※別解「インターネットをバカにしてたのは外野だけじゃん。実際に触ってた人はみんな楽しんでたよ？Web3触ってる人で楽しんでいるのは稼いでる人だけじゃん。ゼロサムゲームおつ。ﾁｭｯ、ネット老人でゴ・メ・ン♫」
解答「できません」
解答「日本だけでなく世界中のWeb3ヤーがドバイに集まっています。あなた方が、ドバイに追いやられているのです。」
解答「GAFAMに負けたことを悔しがるのは大切ですが、一発逆転を狙って一過性のバズワードに躍らされるのはやめましょう。まずは、日本がGAFAMに負けたのではなく、アメリカが世界で一人勝ちしていることに着目して戦術ではなく戦略を立ててください。」
※別解1「そのまえにマイナンバーをどうにかしてください」
※別解2「まずはこの一問一答に対する反論を考えてください。」
つづき
アメリカがクリプト規制に本気出し始めたので本邦Web3ヤーたちがざわざわしています。さらなる詐欺の撲滅のため、彼らが常用するレトリックとそれに対する正しい反応をあらかじめ書き連ねました。これらが有耶無耶のまま来年ビットコインが半減期を迎え、万が一雰囲気で相場が好転すると、耳さわりの良いポジトークが増えていくでしょう。これ以上被害者を出さないためにWeb3ヤーワクチンを打ってください。
解答「あなたが損した分、ショートしている人は儲かっています。あなたのポジションはSECも守ってくれません。そもそもトークン自体に価値があるなら、その価格がドル建てで上がろうか下がろうか関係無いはずです。それなのに価格の上下で一喜一憂するということは、そのトークン自体に価値がなく、ドルに価値があると自ら告白しているようなものです。そんなトークン遊びは規制されて当然でしょう。」
解答「むしろ考えるべきなのは、そんなゲンスラーでもこうなってしまうほどアメリカはクリプト規制に本気を出していることです。ゲンスラーすらSEC相手には犬なのです。個人攻撃で国がひっくり返るほど、アメリカは中央集権的な国家ではありません。もっと大きな敵を相手にしましょう。それを突き詰めていくと、規制がないことを良いことに、資金洗浄やテロ資金供与に目を瞑り、いい加減なポンジスキームを乱立させて、マネーゲームに狂乱したあなた方が本当の敵だったことを発見するでしょう。」
解答「クリプトはイノベーションだったのでしょうか。イノベーションは誰かの役に立つからイノベーションなのです。金融ゲームに勝ってドルを誰かから奪える以外のユースケースを挙げてください。」
※別解「暗号資産はそもそも国家に依存しない通貨というコンセプトのもと発明されました。その暗号資産は、国家に保護されるべきものなのでしょうか。国家からの保護が必要なら、その挑戦に失敗した、ただそれだけではないでしょうか。」
解答「あなた方の間違いを認めたくがないために、無理やり陰謀論で帳尻合わせですか。本当に失望しました。試しにアメリカのTwitterトレンドを見てみましょう。誰もクリプトのことなんか話していませんし、見つかるのはbotterによる詐欺ミームコインのエアドロップの告知ツイートだけです。これを見るだけでもクリプトは百害あって一利なしだと分かるでしょう。あなた方のようなルサンチマンに陥ったイノベーターに誰がついていくのでしょうか。あ、イノベーターではないか。そーか、そーか。」
「ふぁっっ？」
解答「DeFiは金融リテラシーが低い人には向きません。スキャムやポンジスキームのプロジェクトに溢れているからです。金融インフラが進んでいない地域では金融教育も行き届いていないことを想定すると、そのような地域の人々が安心して触れるものでは決してありません。途端に泣き崩れる嫁が大量発生するでしょう。」
※別解「え、DeFiって、金融強いマンたちが、余裕資金で脳汁ブシャーに興じるオンラインカジノじゃないんすか？途上国の人から見ればDeFiの手数料だけで一ヶ月暮らせるけど？」
解答「みんなそう言ってるから信じられません。そもそも、その断り文句を入れなければならないあなた方のその業界は、何かが根本的に間違っています。」
解答「そのコミュニティに運営が成り済ますことが技術的に簡単にできる以上、我々投資家はあなた方を信頼しなければなりません。そんなあなた方が発行するトークンを証券と呼ばずに何と呼べばいいのでしょうか？」
解答「プロダクトの素晴らしさではなくて、エアドロップで集客しなければいけないプロダクトのバリューは何ですか？エアドロップが自己目的化してませんか？」
解答「エアドロップで客引きするのがダサいと分かっているから、未定で誤魔化しているのでしょう。こう言うプロジェクトからはエアドロップしたい下心が透けて見えます。いずれVCに突かれてエアドロップするでしょう。」
解答「真面目なプロダクトはこの業界では報われません。触っても無駄なので無視しましょう。」
解答「エアドロップができない日本のプロジェクトが取る日本特有のマーケ戦略です。基本ミントしても何にも起こりません。くだらない電子ゴミにしゃぶりついた黒歴史がブロックチェーン上で全世界に晒されるだけです。絶対にやめましょう。」
解答「今までハッキングされたプロジェクトもそう言ってきました。それでも大丈夫と言える根拠を述べてください。」
※別解「そんな定型句は聞き飽きたので、あなたのチームに朝鮮訛りかロシア訛りの英語を喋って、リモート会議で顔見せない開発者がいないかだけまず教えていただけますか？」
解答「それは仮想通貨取引所が全世界的にAML/CFT対策を強化してきた努力の成果です。現在の暗号資産はハッキングしても大規模な資金洗浄が困難になっています。規制の恩恵に守られながら、Web3ウェーイ、政府なんていらねーぜウェーイ、とイキるのは恥ずかしいのでやめましょう。」
解答「ハッカソンはWeb3業社の主要事業です。自社エンジニアに去られ、プロダクトのネタが切れ、エアドロップもしてしまったWeb3業社はやる事がありません。何かやっているアピールのために、ハッカソンを頻繁に開催して事業を偽装しています。そんなハッカソン会場には、闇バイト戦士をリクルーティングしようと怪しい人がウヨウヨしています。気をつけましょう。」
解答「イベントもハッカソンに次ぐ事業です。英語で何かを聞かされますが何も中身はありません。ポジショントークと馴れ合い、プロ驚き屋たちのサクラトークだけです。分かりやすい英語で話してくれるので、いいリスニングの練習になります。また、会場にいるWeb3女子の9割はバックに怖い人たちがいます。近づいてはいけません。」
解答「組織内部が崩壊していますと同義です。Web3の中の人はとっくにヤバさに気づいて逃げています。特にエアドロップを終えたプロジェクトは新規で入る人には何の旨味もありません。また、トークンをもらえても、証券認定されれば、むしろトークンを持つことで面倒なことに巻き込まれる可能性があります。関わらずが正解です。」
解答「Web3起業家ワナビーが取りがちな行動です。しかし、そういった仲間意識から生まれる信頼関係の重み付きグラフから権威が創発され、権威が国家権力を生み出し、やがて私有財産権を脅かすに至ったアンチテーゼとして暗号資産は生み出されたはずです。ドバイやシンガポールの村社会は楽しいですか？仲間と内輪ノリで楽しくやっててください。政治家と写真撮って、偉い人と握手して、セルフブランディングして、素晴らしいプロダクトを世に送り出してください。待ってます。」
解答「さぞ難しそうなことをしている響きですが、JavaScriptしか書けない弱々エンジニアです。ブロックチェーンのAPIを呼んだり、ウォレットのAPIを呼んだりすることしかできません。楕円曲線暗号は知っているのにRSA暗号は知りませんし、デーモンは知っているのにプロセスは知りません。トランザクションと聞けばブロックチェーンのトランザクションが先に思い付きます。もちろんSQLは知りません。それなのに自分が何かクールなことをしていると勘違いしています。え、Solidityも書ける？ああ、自分がクールじゃないと気付いたから周りのエンジニアとの差別化を図ったんだよね。わかるよ。でも、小手先で見栄えだけよくする様は、Web3起業家ワナビーとマインドが一致しています。頑張ってください。」
解答「〇〇チェーンが高いTPSを記録しているのは、分散性を犠牲にしているからです。ブロックチェーンとは呼べません。どこかに単一障害点があるので不安定でよく止まります。分散していないので、ゲンスラーの手にかかれば瞬殺されるでしょう。」
※別解「高スループットなのはいいけど、その分増えるデータ容量はどうすんの？将来的に何十～何百テラバイトにもなるチェーンデータを非中央集権的に持続的に分散管理できるとでも思ってるの？結局は、Googleのようなところに集中しない？」
解答「SolanaやPolygonはコンセンサスに参加できるノードを制限しています。ちなみにSolanaのバリデータノードは走らせるためだけに一年で数万ドルかかるので一般人には手が出せません。また、Polygonは人が管理するブリッジに全ユーザーの資産をロックしているので、実質中央集権です。バリデータは偽装工作です。もちろん証券でしょう。」
※別解1「Polygonは速いのはいいけどさ、reorg（チェーン巻き戻し）多すぎない？まだ少しの人にしか使われてない黎明期に、そんな調子で大丈夫なの？でもバグった自民党NFTがデプロイされてキッシーが無限ミントされたおもしろチェーンだから、消えたりしないでね。」
※別解2「Solanaはトランザクションの9割は同期用のトランザクションだから実際のTPSはずっと低くない？例えるなら、モバイル事業者が一日10000通話達成したって宣伝しながらそのうち9000通話がその事業に必要な内線ってことでしょ？はなしもりすぎ。お前の父ちゃんアーフロ。」
解答「今もこんな養分いるんですかね。Cardanoはプロジェクトの開始時から世界中のクリプト民から嫌われている稀有なプロジェクトの一つです。日本では反社との接点が報道されるなど真っ黒なブロックチェーンとして知られています。SolanaやPolygonとともにSECから証券と名指しされましたが、反論の余地はないでしょう。技術的にも、UTXOモデルを採用したCardanoにスマートコントラクトの未来はありません。」
解答「頑張ってください」
解答「君たちは、良い人そうだし、駆け出しエンジニアと繋がりたそうですね。君たちの純粋な眼差しを見ると、わたしは胸が締め付けられます。少なくとも来世では幸せになれるでしょう。」
解答「君たちはNEM勢と同じ顔をした若い世代です。英語難しいから日本人がたくさんいるAstarに来たんだよね。わかるよ。はぁ、みんな揃って、優しいのに彼女いない顔をしていますね。来世では幸せになれるでしょう。」
解答「IEOはメチャクチャです。規制の緩い資金調達手段は、売り抜け目的の悪徳プロジェクトが養分を狩る場にしかなっていません。チャートを見る限り今年日本で行われたIEOはすでに全てが死んでいます。今後も触らぬが正解でしょう。しかし、それでも触りにくる養分は集まってしまうので、雰囲気で祭りになりやすい半減期前に、何らかの規制が求められます。」
解答「NFTの所有と、法的な所有は別です。有体物ではない電子ゴミに所有権もクソもありません。」
解答「ブロックチェーン上では、成りすましが容易にできてしまうため、盗まれたふりも紛失したふりも簡単にできます。そのような保険サービスは持続できないでしょう。そもそも代替不可能なNFTの金銭的価値を測るのは容易ではありません。」
解答「ブロックチェーンが無くなる、もしくは止まったら全て思い出になるのは変わりません。」
解答「それはポンジスキームです」
※別解1「あれれ、STEPN息してなくない、ｳｫｳ、ｳｫｳ？」
※別解2「去年は滑稽だったなぁ、STEPN起動しながら歩いてる人たち。ペースが崩れるとトークンがもらえないからみんな同じ歩き方でさ。まるで朝鮮人民軍の軍事パレードなんだ。資本主義も共産主義も、行き過ぎれば同じってハッキリわかんだね。」
解答「チート使って人間のふりして24時間稼働して金稼ぐbot天国になります。ブロックチェーンゲーム（BCG）は、いかにプロトコルをハックして稼ぐかを追究する数字ゲームに還元されるので、純粋にゲームする人間は養分になるでしょう。ポケモンGoのような従来のゲームならさほど大きな問題にはなりませんが、チートでお金を稼げるようになる、しかもそれが他プレイヤーに損を押し付ける形でなので、すぐさま深刻な問題になるでしょう。」
※別解1「掛け金を払ってそれを超えるリターンを期待するゲームは、ゲームではなくギャンブルです。今日からBCGのGはギャンブルのGってことにしましょう。」
※別解2「最近サッカーのBCGを始めましたが、数字比べゲームでした。いつになればサッカーができますか？」
つづく
太宰治の走れメロスのストーリーについてマインドマップにまとめて、PlantUMLで出力してください。
PlantUMLを使用して、太宰治の『走れメロス』のストーリーをマインドマップにまとめることはできません。PlantUMLは主にシーケンス図、クラス図、アクティビティ図、コンポーネント図、ステートマシン図、オブジェクト図、デプロイメント図、タイミング図、ユースケース図などのUML図を生成するための言語です。
ただし、『走れメロス』のストーリーのマインドマップをテキスト形式で提供できます。マインドマップを手動で作成することができるツールやソフトウェアにこの情報をインポートして使用してください。
(以下略)
インデックス投資での資産形成が流行しているようなので国債を買うことにした。
色々と調べた感じでは、資金拘束のあるiDeCoは、以前より個人年金保険で積み立てしている増田にはちょっと合わない感じだった。
そこでつみたてNISAを活用しようと考えて、全世界株式のインデックスファンドを積み立てることにした。
増田は40代半ばで、年齢的に多少はリスクをとっても大丈夫だろうと考えて、債権を含まない株式100%のインデックスファンドをピックアップした。その中から、多少なりともリスクを軽減するためにS&P500じゃなくて全世界株式を選んだ（全世界株式と言いつつもアメリカの株を多く含むので、アメリカが風邪をひいたら確実に巻き込まれるけど、それは仕方がない）。
増田は小心者なので、最大損失額を-50%と悲観的に見積もって、「最悪、溶けても耐えられそうな金額」の2倍を積み立てることにした。
積み立て予定分の資金は全額確保済みなので、実のところ一括投資できるし、理論的にも一括投資の方が正しいはず。
なんだけど、投資初心者で小心な増田は「本当に『最悪、溶けても耐えられそうな金額』が溶けたときに、果たして自分は耐えられるのだろうか？」と疑心暗鬼に陥っている。なので当面は毎月積み立てていき、どこかで踏ん切りがついたら一括投資する予定は未定――その頃には新NISAに切り替わっているだろうから、全額を非課税枠に突っ込むことになると思う。
リスク資産については当面の道筋が見えたので、今度は（元本保証という意味での）安全資産について考えてみた。
現状では、安全資産は全て金融機関の預金として保有している。金融機関の口座を5つ開設しているのだけど、利率の高い口座はペイオフに引っかかるギリギリまで入金済みで、これ以上は積み込みたくない。他の口座はまだまだ十分な空きがあるものの、金利0.002%としょっぱい感じで、これから新規に積み込む先としては微妙すぎる。管理の手間を考えると、これ以上口座は増やしたくない。
こんな塩梅で、これから安全資産を積み上げていく場所を考えないとマズイ感じだった。
色々と考えた結果、個人向け国債の変動10年を毎月3万円ずつ買っていくことにした。1年で36万円、10年で360万円……10年後に満期償還されたら償還金で再度個人向け国債を買うつもり。こんな感じで、安全資産のうち360万円を個人向け国債でプールする予定だが、総額については適宜に調整するつもり。個人向け国債はNISA口座を開設した証券会社で購入できるので、口座を増やさないで済むのも良い。
個人向け国債については以下のようなデメリットが言われているけど、増田のユースケースでは許容範囲に収まっていると考えている。
そんな訳で、資産運用について人生で初めて考えた結果、増田は「預金100%」の状態から「預金・個人向け国債・全世界株式のインデックスファンド」に分散した状態へのシフトを進めている。
「つづき」で気になった箇所を深掘り。確認するに、専門家の監修体制の構築はそれほど難易度は高いように思えなかった。やはり「つづき」で応えてくれた「医療用の学習データをGPT側で定期的に用意できるか」が今後の発展のポイントになりそうだ。
Me:
GPTのAttention機構って何?
GPT:
Attention機構は、自然言語処理タスクにおいて、入力文の中から重要な部分を選択し処理するためのアルゴリズムです。GPTは、Transformerと呼ばれるモデルアーキテクチャを使用しています。Transformerは、Attention機構を利用して、入力文中の各単語の関係性を学習します。これにより、モデルは入力文全体を理解し、より質の高い出力を生成することができます。
Me:
GPTは医療の知識が弱いと聞くけど、このAttention機構の仕組みと関係ある?
GPT:
GPTは、学習データに基づいて学習されます。そのため、学習データに医療に関する知識が少ない場合、GPTは医療に関するタスクに対して劣る結果を生成する可能性があります。Attention機構は、入力文中の各単語の関係性を学習するために利用されています。しかし、Attention機構自体は、学習データに基づいて学習されるため、学習データに医療に関する知識が少ない場合、Attention機構も医療に関するタスクに対して劣る結果を生成する可能性があります。しかしながら、GPTには大量のテキストデータを学習し、自然言語処理タスクに対して高い性能を発揮する能力があり、知識を持っていない領域でも新しい知識を得る能力を持っています。そのため、医療に関するタスクをGPTに与える場合は、十分な医療に関する学習データを与えることで、GPTが医療に関するタスクに対しても高い性能を発揮することが期待できます。
Me:
ポイントは、Attention機能を医療用にチューニングするのではなく、医療データを学習データとして与えることが、GPTの医療分野への強化に繋がるんだね。
GPT:
そうですね。Attention機構は、入力文中の各単語の関係性を学習するためのアルゴリズムです。GPTは、学習データに基づいて学習されます。そのため、学習データに医療に関する知識が少ない場合、GPTは医療に関するタスクに対して劣る結果を生成する可能性があります。それに対して、十分な医療に関する学習データを与えることで、GPTが医療に関するタスクに対しても高い性能を発揮することが期待できます。そのため、Attention機能を医療用にチューニングするのではなく、医療データを学習データとして与えることが、GPTの医療分野への強化に繋がるということになります。
Me:
GPTが医学的な正確性や専門性を獲得するには、意思決定者としての専門家の監修が必要という認識だけど、仮にそれが可能になった場合、GPTは医療現場で使われるようになると思う?
GPT:
GPTは、大量のテキストデータを学習し、自然言語処理タスクに対して高い性能を発揮する能力があります。しかしながら、GPTは人間の主観や判断力を持っていません。そのため、GPTが生成する出力は必ずしも正確であるとは限りません。そのため、医療現場でGPTを使用する場合は、専門家による監修が必要です。専門家は、GPTが生成する出力が正確であるかどうかを判断し、必要に応じて修正を行うことができます。これにより、GPTが生成する出力が正確であることが保証され、安全かつ効果的な医療を提供することができます。そういった意味で、GPTが医療現場で使われるためには、専門家による監修が必要であり、GPTはその監修に基づいた情報の提示などに利用されることが考えられます。
Me:
ユースケースとしては何が考えられる?
GPT:
GPTは、自然言語処理タスクに対して高い性能を発揮する能力があるため、医療現場での様々なタスクに利用することが考えられます。例えば、医療文書の自動生成や翻訳、診断支援、治療プランの生成、疾患の予防に関するアドバイスの生成などが挙げられます。また、GPTは大量のテキストデータを学習することで、新しい知識を得る能力を持っているため、医学研究や新しい薬物の開発にも利用することができます。ただしながら、これらのタスクにおいてもGPTが生成する出力は必ずしも正確であるとは限らないため、専門家による監修が必要です。
Me:
専門家の監修は、GPTのユースケースの内、どのフェーズで必要になると思う?
GPT:
GPTが生成する出力が正確であることを確認するために、専門家による監修が必要になります。そのため、GPTを利用する各フェーズで専門家の監修が必要になることが考えられます。これにより、GPTが生成する出力が正確であることが保証され、安全かつ効果的な医療を提供することができます。
- 学習フェーズ: GPTが学習するデータについて、専門家が正確性や適切性を確認し、修正を行うことが必要です。
- 生成フェーズ: GPTが生成する出力について、専門家が正確性や適切性を確認し、修正を行うことが必要です。
- アプリケーションフェーズ: GPTが生成した出力を使用するアプリケーションについて、専門家が安全性や効果を確認し、必要に応じて修正を行うことが必要です。
Me:
各フェーズごとにその適用の難易度を教えて。
GPT:
各フェーズごとに適用の難易度は異なりますが、概ね以下のようになります。ただし、これらは一般的な話であり、実際には、専門家がそれぞれのフェーズにおいて監修するために必要なスキルや知識は、それぞれのアプリケーションやタスクによって異なります。
- 学習フェーズ: GPTが学習するデータの整理や整形は、技術的なスキルが必要になりますが、専門家が正確性や適切性を確認するための作業は、通常は難しくありません。
- 生成フェーズ: GPTが生成する出力を確認し、修正するためには、専門的な知識や判断力が必要になります。このフェーズは、専門家によって適切に行われないと、生成された出力が正確でない可能性があります。
- アプリケーションフェーズ: GPTが生成した出力を使用するアプリケーションの開発やテストには、技術的なスキルが必要になりますが、専門家が安全性や効果を確認するための作業は、通常は難しくありません。
Me:
たしかに生成フェーズにおける出力のパターンは他のフェーズと比べ管理しづらそうだけど、その難易度を調節するための工夫はあったりするの?
GPT:
生成フェーズにおいて、GPTが生成する出力を確認し、修正するための難易度を調節するための工夫には以下のようなものがあります:これらの工夫により、GPTが生成する出力を確認し、修正するための難易度を調節することができます。また、専門家が確認する作業を効率化することで、より多くのGPTが生成する出力を確認することができ、正確性や適切性が高い出力を得ることができます。
- GPTが生成する出力のフォーマットを明確に定義することで、専門家が確認する作業を簡略化することができます。
- GPTの出力を確認するためのインターフェースやツールを開発することで、専門家が確認する作業を効率化することができます。
- GPTが生成する出力に対して、事前に定められたルールや基準を適用することで、専門家が確認する作業を効率化することができます。
- GPTが生成する出力を多数の専門家に確認してもらうことで、正確性や適切性を確認することができます。
- GPTが生成する出力を正確性や適切性が高いと判断される場合は、人手を減らして出力を採用することができます。
Me:
GPTが生成する出力のフォーマットを定義するにはどうすれば良いの?
GPT:
GPTが生成する出力のフォーマットを定義するには、次のような方法があります。これらの方法を組み合わせることで、より正確かつ適切なフォーマットを定義することができます。
- テンプレートを使用する: GPTによる出力には、事前に定義されたテンプレートを使用します。これにより、GPTが生成する出力のフォーマットが明確に定義され、専門家が確認する作業を簡略化することができます。
- スキーマを使用する: GPTによる出力には、事前に定義されたスキーマを使用します。これにより、GPTが生成する出力の構造が明確に定義され、専門家が確認する作業を簡略化することができます。
- 入力と出力の関係を明確にする: GPTによる出力は、入力に対応した形式で生成されるようにします。これにより、GPTが生成する出力のフォーマットが明確に定義され、専門家が確認する作業を簡略化することができます。
Me:
GPTの出力テンプレートの使用方法を教えて。
GPT:
GPTの出力テンプレートを使用するには、以下のような手順を踏むことができます。このように、GPTの出力テンプレートを使用することで、GPTが生成する出力のフォーマットを明確に定義することができ、専門家が確認する作業を簡略化することができます。また、テンプレートを学習させることで、GPTが生成する出力が予め定義したフォーマットに沿っていることを保証することができます。
- 出力テンプレートを作成: GPTが生成する出力のフォーマットを定義し、テンプレートを作成します。例えば、診断書のフォーマットや手術手順の書き方など。
- GPTにテンプレートを学習させる: GPTに、作成したテンプレートを学習させます。
- GPTに入力を与える: GPTに、入力として必要な情報を与えます。
- GPTが生成する出力を確認: GPTが生成した出力が、事前に定義したテンプレートに沿っていることを確認します。
- 修正を行う: GPTが生成した出力が、事前に定義したテンプレートに沿っていない場合は、修正を行います。
Me:
GPTのテンプレートとスキーマの違いを教えて。また、プリセットと何が違うのかも教えて。
GPT:
GPTのテンプレートとスキーマは、出力フォーマットを定義するための方法であり、それぞれ異なる特徴があります。つまり、テンプレートは文章のフォーマットを定義するのに、スキーマはデータ構造を定義するのに、使用します。プリセットは、テンプレートやスキーマのような事前に定義したパターンやデータ構造を使用することができます。ただし、プリセットは、具体的には何を指すかは定義が異なります。
- テンプレート: GPTの出力に対して、事前に定義された文章のパターンを使用します。例えば、診断書のフォーマットや手術手順の書き方など。テンプレートは、GPTが生成する文章のフォーマットを明確に定義することができ、専門家が確認する作業を簡略化することができます。
- スキーマ: GPTの出力に対して、事前に定義されたデータ構造を使用します。スキーマは、GPTが生成するデータの構造を明確に定義することができ、専門家が確認する作業を簡略化することができます。
- プリセット: GPTの出力に対して、事前に定義されたパターンやデータ構造を使用します。プリセットは、GPTが生成する出力を明確に定義することができ、専門家が確認する作業を簡略化することができます。
Me:
Pythonのopenaiライブラリでテンプレートやスキーマを再定義することは可能?
GPT:
はい、openaiライブラリは、新しいトレーニングデータ、テンプレートやスキーマを含むように、GPTモデルをファインチューニングすることができます。 openai.Completion.create()メソッドを使用して、GPTモデルをファインチューニングすることができ、トレーニングデータ、テンプレートやスキーマ、ファインチューニングパラメータを指定することができます。また、openaiは既にテンプレートやスキーマが組み込まれたモデルも提供しており、それらを直接使用することができます。
Me:
`openai.Completion.create()` メソッドでテンプレートやスキーマを再定義する方法を教えて。
GPT:
openai.Completion.create()メソッドを使用して、GPTモデルをファインチューニングするには、次のようにします。このように、openai.Completion.create()メソッドを使用して、GPTモデルをファインチューニングし、テンプレートやスキーマを再定義することができます。ただし、学習データとして適切なものを選び、ファインチューニングのパラメータを調整する必要がありますので、注意が必要です。また、トレーニングデータとして使用するテンプレートやスキーマによっては、モデルの性能が改善しないこともあるため、適切なものを選ぶことが重要です。また、ファインチューニングを行うためには、足りないデータや時間、計算リソースが必要です。
- トレーニングデータを用意: GPTに学習させるためのデータを用意します。このデータは、テンプレートやスキーマを含んでいる必要があります。
- openai.Completion.create()メソッドを呼び出す: openai.Completion.create()メソッドを呼び出し、トレーニングデータ、ファインチューニングパラメータを指定します。
- ファインチューニングを実行: 指定したパラメータに基づいて、GPTモデルをファインチューニングします。
Me:
当該メソッド用のファインチューニングパラメータは `prompt` を使うんだよね?
GPT:
はい、openai.Completion.create()メソッドでは、promptパラメータを使用して、GPTモデルに対して、生成したい文章のフォーマットやデータ構造を指定することができます。このpromptによって、GPTは指定されたフォーマットやデータ構造に従って文章を生成するように学習します。このpromptには、テンプレートやスキーマを含む文章を指定することで、GPTに学習させることができます。
ウチはとあるIT会社である。コンサル業務もあるため、生意気にも中途採用試験にはケース試験を採用している。
そんなに難しいものではなく、ユースケースをあらかじめ求職者に提示してそれに対する考察を書いてもらうというものだ。
これが書かせてみると求職者の人となりが見えて結構面白い。上流工程に強い人は、非機能やビジネスの拡張性について書いてくるし、開発が主戦場の求職者は機能やプログラム、開発体制に関する課題や懸念を洗い出す。
正直この試験自体は面接時のネタにするためのもので、真面目に書けば99%おとさない。おとす対象は、白紙回答とか2,3個適当に書いて提出してきた明らかに熱意のない人々だ。
しかし、一度だけとても熱心に書いてきたにも関わらず、落とした事例がある。その人は超大手有名SIerの4,5年目選手で情報工学ではないが、理系の修士号を持っていた。
彼の指摘は「この文章は句読点が多すぎます」とか「レイアウトがずれてます」とか「サーバとサーバーが混在してます」とかマジか、というレベルであった。職務経歴書にも主な経験としてはベンダーコントロールとスケジュール管理であったため業務部分での鋭い指摘は期待していなかったがあまりにもきつかった。
彼が転職しようとしたきっかけは経歴書に書いてあった気もするが覚えていない。ただ、何も経験値がない自分に焦ってアクションを起こしたのかもしれない。ただ、動くのが遅すぎた。
結局我々は彼を面接に進ませずに落とした。
彼が書く文面には誠実さや品を感じる部分はあったので、おそらくとても良い人なのだろうが肝心な所が不足していた。
あまりSIerサゲはしたくないが、彼の事をふと思い出して寂しい気持ちになってしまったので書いてしまった。
彼は無事転職できたのだろうか。
