サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
iPhone18 Pro
nekogata.hatenablog.com
本質的な複雑性と偶有的な複雑性の区別は、有名な『銀の弾丸はない』で提唱されたものだ。 本質的な複雑性というのは、「どうあがいても、その問題に内包されている複雑性」のことで、たとえば医療で言ったら「麻薬施用免許を持たない医師やスタッフが麻薬処方の指示を出してはいけない」というのはあたりまえの話だけど「じゃあその処方箋はどう現場で管理されないといけないんですか」とか「鍵付きのところに保存されてないとダメで、そこから取り出すためには麻薬施用免許を持った医師が出して、麻薬施用免許を持った医師がハンコを押した処方箋がないといけない、そしてそれは参照できるところに管理されていなければならない」みたいな話はまあ、医療安全上の本質的複雑性だと言っていいだろう。 一方で偶有的な複雑性というのは、実装方法だとか、技術的な制限だとか、あるいは間違えた解決領域を作ってしまったことだとかによる複雑性だ。たとえば、シ
corp.classi.jp このようなニュースがありまして。このタイミングにて、親会社への転籍ではなくて転職を選ぶことにしました。3/31まではClassiに籍としては残りますが、すでに最終出社を終えております。社としてのClassiは解散、という形になりますが、Classi、tetoruの両サービスは親会社の運営にてしっかり継続されます。 企業の解散といえば、にっちもさっちもいかなくなって解散する企業がほとんどの中、利益をしっかりと出せている状態で親会社に吸収合併される形で解散、というのは、会社の解散としてはだいぶ幸せな解散の形なのではないでしょうか、と思っています。思えば、会社の最後を看取るという経験は生まれて初めてのことです。2018年8月入社なので、7年半も所属してしまいました。きっかけがなかったらもっと所属したかもしれません。2020年に大きなインシデントを起こしたのち、ビジネ
ソフトウェアサービスというのは、リリースした瞬間から、もっと言えば書いてリポジトリにコミットした瞬間から「コスト」を産み始める。 新しい機能を作りたいとき、われわれは既存の機能、既存のコードとの整合性をとる必要がある。そのため、「既存のコード」の量が多ければ多いほど、「新しい1行」を追加するときのコストは上がる。また、ライブラリアップデートやフレームワークのアップデートをするときも、「既存のコード」の量が多ければ多いほど作業量は増える。また、リリースされているのであれば、そのコードが使う計算資源は当然ランニングコストとしてかかってくる。また、顧客からの問い合わせの調査においても、コードの量が多ければ多いほど調査のコストは増える。つまり、あらゆるコードは「ランニングコストのかかる困ったもの」であるとみなすことができる。 では、なぜそのような困ったものが存在することが許されるのか。これは単純で
世間ではよく、「プロダクトにオーナーシップを持て」というようなことを言われる。かんたんにいうと「このプロダクトは自分のものだ」と思って仕事しろ、という話だ。よく言われるということは、逆にいうと「そうなっていないことが多い」ということだとも思う。つまり、「ほんとうはオーナーシップを持っていてほしいんだけど、そうじゃないから、"持て"と言われる」ということだ。あいさつがあたりまえになされている場所では「あいさつをしましょう」と言われない、というような話。 では、なぜオーナーシップを持つことが難しいのだろう？ ぼくは、いままでいろんな現場を見てきて、いくつかのアンチパターンがあるな、と思っている。 アンチパターンの解説から入るまえにまず、前提の話から。そもそも、ソフトウェアエンジニア自体が「オーナーシップなんか持ちたくないよ」と思っている場合、それはどうやってもオーナーシップを持たせることは不可
ブログなので雑にバラバラと書く 手がとにかく早い まあ機械なのでそれはそう 意味のあるフィードバックをClaude Code自身が得られるような工夫が必要 「生成」AIなので生成することは向いているけど、チェックすることには向いていない。あたりまえだけどテスト書いてなかったりしたら人間の何倍も早くぶっ壊していくと思う テストもとにかくサボる テスト書けって言っても書かない。必ず実行しろっていってもサボる カバレッジ目標とかを明示的に与えたほうがいいのかもしれない（試してみる） 外部API叩いてるところとか、そういうものはClaudeCodeが直接FBを確認しにくい。こういうときは当てずっぽうでやらせるのではなくて「人間が手伝うから、なにかを確認してほしくなったら確認手順を人間に教えて」と言ってFBループに人間が介在するとうまくいく。うまくいきはするんだけど、人間が介在するのでスピードがガタ
昔書いて結構ご好評を得た「process-book」なんだけど、サンプルコードが古かったりbuild環境が古かったりしたので、令和最新版にリバイスした。 https://github.com/Shinpeim/process-book リバイスした内容としては…… docker containerでの実行環境を同梱した GitHub Actionsで pages のbuildとreleases（pdf版）をビルド,publishするようにした サンプルコードをRubyに統一 ClaudeCodeと一緒に、説明が薄いところなどを加筆修正した 基本的な内容は変わっていないです。正直ずっと「価値のある文章のはずなんだけど、いろいろと古くなってて手をいれないとな……」「けどめんどくさいな……」が戦っていたんだけど、Claude Codeとの生活を始めたことで「まあパッとやっちゃうか」になることがで
TL;DR: マルクスは、生産手段（工場とかね）が資本家に独占され、労働者は生産手段を持たないため労働力を生活のためのもろもろに変換するしかないという状況を問題視した ソフトウェアエンジニアをはじめ、いわゆる「知識労働者」は、生産手段がその頭の中に存在するという点で、資本家に対して競争力を持つことができた面がある。ソフトウェアエンジニアが長らく転職市場で有利だったのはそのひとつの証左と見ていい 一方で、LLMの台頭で、その「生産手段」は資本家どころか、私企業に独占される未来は蓋然性が高いように見える ぼくたちは今まで見たことのない地獄に足を踏み入れているのかもしれない マルクスは、労働「からの」疎外という概念も提唱していて、雑に要約してしまうと、生産手段を失った労働者は、「自ら財を生み出す」という喜びを失ってしまう、ということを言っている だから、「手元にある生産手段」として、ローカルLL
ソフトウェア開発には大きな不確実性がつきものであることはすでに現代では広く知られている。 この不確実性とどのように向き合っていくか、ということも多く語られていて、いわゆるスクラム開発というフレームワークは、不確実性に対して「適応性」を高めていくために用いられるフレームワークだったりする。また、「不確実性の高い部分と低い部分があるなら、高い部分を先にやっつけてしまう」というようなテクニックも当然有用だろう。あるいは、高度な技術力のある人間の高度な設計力によって、不確実性を軽減するアーキテクチャを導入できることもある。 このように不確実性に立ち向かいコントロールしていくことが重要なのはいうまでもないけれど、一方で、不確実性のコーンを引用するまでもなく、結局のところ、リリースするまで不確実性は「なくならない」ということに眼を向ける必要も同時にあると思う。どれだけ適切に不確実性に立ち向かっても、必
社内で書いた内容から、一般化できる話だけを抜き出して書いた記事です。 TL;DR 意思決定者は、 仕様が複雑になればなるだけ、指数関数的かつ継続的にコストがかかることを理解する必要がある。 ユーザーの要求や利便性について優先順位をつける必要がある。 それらを揃えた上で「いっちゃんいいバランスで顧客要望に応える」必要がある。 コストについて サービスあるいは機能の一生 サービスあるいは機能は以下のライフサイクルを辿る 初回リリース以前 初回リリース以後、クローズ以前 クローズ 実は一番コストがかかるのが「初回リリース以後、クローズ以前」の部分。なぜならサービスの一生のうちほとんどの時期がここなので……。 初回リリース以前にかかるコスト いわゆる「初期開発」が行われる。 当然、この時に仕様がシンプルであればあるだけ初期開発にかかるコストは低くなるし、仕様が複雑であればあるだけ初期開発にかかるコ
uzullaさん主催の「みんなで作るテックカンファレンス」のya8に参加してきました。 わたしはアンカンファレンススペース担当として、二日間アンカンファレンススペースの切り盛りをさせていただきました。アンカンファレンスのキモは「一方通行ではなくて参加者みんなで議論する」だと思っているのですが、実際二日間においてほとんどずっと活発な議論が行われていて、参加して発言してくださったみなさんに大変感謝しています。しかも、「いつメン」の同窓会ではなく、いろんな方が発言してくださっていて、ほんとうにいいアンカンファレンスになったなと思っています。 議論の内容については余裕ができたら改めてまとめるかもしれません。 さて、実は私は、約5年ぶりくらいのカンファレンス参加でした。長い間カンファレンスに出席していなかったのには実は理由があります。詳しい理由は控えるのですが、ひとことで言うと、以前「自分とテックコ
組織やチームはそれぞれルールや文化、仕組みを持っている。この仕組みやルール、文化はときに外部から見ると「アンチパターン」に陥っているようなこともある。そのとき、「アンチパターンを抜け出してベストプラクティスを」と言うのは簡単だけど、実際にそこから抜け出すのは「言う」のと比べるととても大変なことだ。なぜなら、多くの仕組みやルールは複雑かつ有機的に絡まり合って現在の「仕事のフロー」を形成しているからだ。自分の職能の範囲だけで改善しようと思っても、仕事は自分の職能の範囲では完結せず、「他の職能のやり方がこうだからベストプラクティスは採用できない」となってしまいがちだ。こういう「変えるのが大変」という状況をぼくは「チームの慣性力が働きすぎている状態」と呼んでいる。 では、この慣性力に負けないためにはどうすればいいのだろうか。ぼくは心構えとしては以下のようなことを考えている。 文化や仕組みを変えるの
よく、「仕事の属人性を排除して、仕組みやルールで標準化すべき」ということが言われる。これは決して間違えていないと思うけど、一方で片手落ちだと思う。たしかに、労働集約型の事業においては、「人数を増やせば増やすほど利益につながる仕組みやルール」を作ることが大事になるだろう。一方、知識集約型の事業においては、これは必ずしも真ではないと思う。 言ってみればあたりまえのことだけれど、ルールや仕組みは、増えれば増えるほど労働は平準化されていく。労働集約型の事業においては、「ローパフォーマーを減らすこと」のほうが、「ハイパフォーマーにさらに高いパフォーマンスを発揮してもらうこと」よりも重要だ。だって数がたくさん必要なんだもん。そのため、ハイパフォーマーにとっては「枷」になってしまうようなルールや仕組みであっても、その仕組みを課すことでローパフォーマーでも一定のアウトプットが出ることが重要となる。つまり、
「顧客中心主義」という言葉を振りかざすひとは胡散臭く感じてしまうが、一方で重要な考え方であるとも思うアンビバレントがある 労働についての話。 労働をしていると、「どうしてうちの組織はこうなってないんだ」とイライラすることはだれにでもあると思う。というか、そういうイライラを失ってしまったとしたらそれはもう理想を失っているということで、改善の機会を失っている。理想と現実の間のままならなさにイライラしながらも顧客（その顧客は社内の別の部署かもしれないが、それが最終的にエンドユーザーに届くロジックは強固にたてついていないといけない）に対してなんらかの価値を提供して対価を得るのが労働だとさえ思う。 ところで、この理想を実現するためにはどうしたらいいのだろうか。理想を知ること、理想の状態を想像することは簡単だけど、このままならない現実を理想に近づけるためになにかを変えるというのはすごく大変だ。このギャ
2023年度を迎え、所属するバンドも新しい音源の制作としてレコーディングを開始しました。わたしの所属するバンドは、2度ほどいわゆる「エンジニア付きレコーディングスタジオ」でレコーディングをしたのですが、そのあとの音源制作は、基本的に私がエンジニアをしてDIYレコーディングを行っています。わたしがバンドでDIYレコーディングを始めたときは、まだ音楽のお仕事でお金をもらい始める前のできごとなので、まごうことなき「アマチュアによるDIYレコーディング」です（でした）。 さて、ところで、エンジニアさん付きのレコーディングプランの価格を調べてみたことがありますか？ 調べるとみなさんびっくりされると思います。たとえばスタジオノアのレコーディングプランでは、スタジオ代に追加で ￥24,200- 支払えば、きちんとしたエンジニアさんが6時間もレコーディングを行ってくれます。高い？ いえいえ、サウンドエンジ
編曲やレコーディングを真剣にやり始めて、他人様に提供するようになってから随分と経つ。その中で、自分にとってはエレキギターの録音が最も難しい課題のひとつとしてずっと立ちはだかっていた。もうずっといろんな手段を試してみたけど、最近ようやく満足に片足突っ込んだ音を録ることができるようになってきたので、それについて書く。なお、スタンスとして「高い機材買いまくればそりゃいい音で取れるけど、そうじゃなくて創意工夫で現実的な範囲で最高の音を録りたいんじゃ」というスタンスです。 最初に結論 及第点出すならstrymon IRIDIUM買っとけば間違いない マイク録りするなら覚悟が必要。そこは底無し沼だ、気をつけろ。自宅でやるなら以下の戦略を取ろう 音量が小さくてもいい音が出せるセッティングを突き詰める マイキングがかんたんなセッティングを突き詰める 「手軽に安価でシミュレーターよりいい音」を出せるリグは以
自分のバンドで使いたいから作った。 ニーズ ライブをやるときに、セットリストが足元にあると便利。 BPMも同時にわかると便利 便利なんだけど、ふつうBPM:88ですって言われてもそれがどれくらいの速さなのかはパッとわからない 楽譜アプリとかで、視覚的にBPMがわかる（丸が点滅してくれる）やつもあるんだけど、ライブしてる途中にスマートフォンとかタブレットとかいじってるところあんま見られたくない できればペダルボードの横とかに放置しておくだけで全曲のBPMを視覚的に教えてほしい。 機能 ライブでやる曲のリストをformタブから入力できる prompterタブではそのリストが表示され、「signal」というカラムでその曲のbpmに合わせて「●」が点滅してくれる share linkをコピーすると、アプリをインストールせずにバンドメンバーに展開可能 その際入力しておいたセットリストとbpmはURL
組織やチームにおいて、合意は非常に重要だと思う。そもそもなんらかの合意が存在しないチームや組織はそれはもはや組織やチームではなく、バラバラな個人の集まりとなる。 一方、合意はとても高コストだ。全ての行動に合意が必要となる場合は、動きはとても遅く、目的を達成するためのコストは跳ね上がる。なにをするにしても「根回し」と「合意」をとらなければならなくてとにかく仕事が進まない、というのはよく聞く嘆きではないだろうか。合意は重要だが、一方でハイコストなので、合意を取る必要のないものについては合意なしで済ませることも重要となる。 合意は非常に重要だが、ハイコストである。このジレンマに対しては、「合意を取るべきものはなにか」「何ならば合意を取らずに進めていいのか」の合意、いわば合意に関するメタ合意とでも呼ぶべき合意が重要になると考えることができると思う。メタ合意さえあれば、本当に合意を取るべき（と合意が
今日は掲題のような文章について。 世の中には「すでにわかっているひとにはよくわかるしとてもわかりやすいんだけど、わかってないひとにとってはなんのこっちゃかわからん」みたいなタイプの文章が存在すると思う。 たとえばソフトウェア開発の文脈で言うと、基本情報技術者試験の勉強の際に読むようなやつを想像してみてほしい。ぼくは基本情報技術者試験って結構役に立つよなあって思っている側の人間で、ある程度ソフトウェア開発の経験を積んだひとからもけっこう「内容はいいよね」っていう言葉は聞くと思う。で、この「内容はいいよね」ってところが結構ポイントだと思っていて、実際にソフトウェア開発の経験をある程度積んで、暗黙知や経験知がある程度溜まった状態、つまり「わかっている」状態であれらを読むと「わかるわかる」となるが、一方でそういう暗黙知や経験知がない状態で基本情報技術者試験に合格しても結構「とりあえず暗記したけどこ
ソフトウェアの内部品質への投資を怠ったが故に、その内部品質がビジネスの足枷になってしまった、という失敗はよく聞かれる例だと思う。 そういう場合、「なのでソフトウェアの内部品質を直しましょう！」と言う発想になりがちだし、当然そのための投資を始めることは必要なのだけれど、それ以上に注目しなければならない問題がある、と最近は思うようになった。 「内部品質が落ちたので内部品質を直しましょう」というのは、単なる対症療法である上に「いつんなったら直って内部品質への投資やめられるの」という誤った問いを誘発してしまう。よくある話として、一定の内部品質を達成するために「リプレースプロジェクトです！」と言って書き換えを進めて、それが終わったらまた内部品質は鑑みられなくなるような話があるし、内部品質だけではなく「EOL対応」とかでもそういうケースはまま聞く。 じつは直面すべき課題は「内部品質の低さ」や「依存ライ
いろんなところで主張してきたことの繰り返しになりますが、ソフトウェアの設計とは、「解きたい問題に対して適切な構造を与えること」だとわたしは考えています。 「解きたい問題に対して適切な構造を与えること」という以上、「解きたい問題」が変われば「適切な構造」も変化する、ということが言えるはずです。これは「まず問題を適切に捉えること」の重要性を示していると言えると思っています。しかし、そのことと同等に問題とされるべきは、「適切な構造は何によって構成されるか」であるとも思います。 わたしは、ソフトウェアの「適切な構造」を構成する二大要素は「関心の分割点」と「分割点によって分割された要素同士の依存関係」だと思っています。 つまり、ソフトウェア設計とは、「まず解きたい問題を理解し、その問題に応じて、適切な関心の分割点を見出し、見出された関心の分割点で分割された各要素に対して最も適切な依存関係を設定するこ
軽く振り返りたい。 去年の10月からVPoTになって、ずっと手探りでやってきていつのまにか1年以上経ってた。 正直言って、始めてから半年くらいは「何を期待されていて、自分ができることが何で、それをどう進めるべきか」が全然わからなくて、自分が何をすべきかということを探る期間だったし、ちゃんと機能できていなかったと思う。具体的に何をやっていたか、と言われてちゃんと応えられる成果がない。まあ、半年くらいそんな感じで右往左往しながら、今までと違う立場で社内を観察していたのはまるっきり無駄とは言えず、今の仕事につながってはいるかな、とは思う。けど正直機能できてなくてすまんかった、とも思っている。 では今何をやっているかと言うと、課題を抱えた現場に対してアドバイザリーとして入っていって改善おじさんをやったり、そういう現場レベルのことよりもでかい粒度で「全社レベルでの仕事の構造を変える」ことに注力してい
この10月から、VPoTという肩書がついた。公式な経緯などは会社のブログのほうに書いたのでそちらを読んでいただきたいのだけれど、こちらは個人の日記なので個人の日記レベルのことを書く。 VPoTになるまでは、テックリードという肩書で、社内を見渡して「あ、ここちょっと自分が入っていった方が物事がうまく進みそうだな」というところに入っていっては手を動かすというようなムーブをしていたのだけれど、冒頭に貼った記事のような経緯で、今は手を動かすことよりも、仕組みづくり、組織構造に起因する問題に対する解決となる構造を作ることなどが主な仕事になった。 じつは、ぼくは今の会社に入るときに明確に「CTOやそれに準ずる仕事はしたくない」と伝えた上で採用してもらっている。なのになぜ心変わりをして、いままたCTO業の一部のようなことをやっているか、ということを今日は書きたい。 そもそも、ぼくがなぜCTOやそれに準ず
コミュニケーションが成立するためには、双方の発信器官、受信器官（ここで言う器官というのは身体的な器官のことではなく、「メカニズム」くらいの意味だ）が健全に稼働していることが必要条件となることは言うまでもないことだとおもう。片方の受信器官が壊れていたら、とうぜんもう片方がいくら発信したところでその信号はだれにも届かないまま消えていく。これは逆もまたおなじことが言えて、片方の発信器官が壊れていたら、とうぜんもう片方がいくらがんばって受信したところでそれは理解不能なものになるし、そもそも発信されてないものを受信することはできない。いくら耳をすましていても。 いま、双方の発信器官受信器官が健全に稼働していることをコミュニケーション成立の「必要条件」と言ったけれど、ではこれらの条件はコミュニケーション成立の「十分条件」だろうか？ ということを考えてみたいと思う。換言すれば、「双方の発信器官も受信器官
gemとかが標準エラー出力に対して「deprecatedなメソッド呼んでるよ〜」みたいなwarningを吐いてくれることがあると思うんですが、自分のプロダクトコード側でそのメソッドを呼んでいるわけではなくて依存してる別のgemの気がする、犯人は誰だ！みたいなときの話です。 だいたい./vendor/bundle以下を検索すればまあ犯人見つかるというのはあるんですが、メソッド名を動的に作ってるやつとかがいると引っかかってこなかったり、あとは同じ文字列がたまたま関係ないところで出現してるみたいなときもあるにはあり、「このwarningを出してるところのスタックトレースがほしいよお！」ってなることがある。そのようなときには、 class CustomStdErr < IO def write(*args) p caller STDERR.write(*args) end end $stderr
builderscon2019に参加してきました。以下技術的ではない部分の振り返りです。技術的な部分の振り返りはまたあとで書きます。 今年はすごく自分のメンタルが乱高下する、とてもヘヴィなbuildersconとなった。というのも、まさに前回の記事に書いたことが起こったのがbuildersconの前夜祭だったからだ。前回の記事は自分もまだ混乱のさなかにあるときに書いたものなので、だいぶ落ち着いた今、再度そのあたりの話をするところからはじめたい。 前回の記事にも書いたけれど、「マッチングアプリのいいね自動化」という内容そのものが悪である、という立場にぼくは立たない。マッチングアプリというのは、そもそも男女ともに「性的に選別」しあうものである。そうである以上、「マッチングアプリ上での性的な選別の自動化」は問題ないはずだ、という立場ではある。「どんな文脈であれ人間を性的に選別するような発表はそも
エンジニアの集まるカンファレンス（参加者の多くはソフトウェア・エンジニアだが、ものづくりするひとすべてを対象としたカンファレンスなので、暫定的に「エンジニア」という括りで話します）において、マッチングアプリ上で女性の外見を判別して自動でいいねを押すという発表がなされている現場に居合わせた。このエントリの目的は特定の発表自体の是非を判断することではないので、リンクしない。「リンクしなければそもそもその発表の是非の判断ができないじゃないか」という向きもあると思うけれど、少し調べればわかることだし、その発表自体の是非を議論したいなら、調べるくらいのコストをかけて別のところでやってくれたら嬉しいと思っている。 さて。少なくとも今回参加しているカンファレンスのジェンダーバランスは、めちゃめちゃ偏っている。おそらく、多くの技術系のカンファレンスにおいても、そうなのではないかと思う。これ自体がいびつであ
労働の現場においては、gemにオレオレパッチを当てたい、ということがまれにあります（あ、いい忘れてましたがこれからRubyの話をします）。もちろん、オレオレパッチは基本的には避けるべきものですが、そうも言っていられない深遠なる事情というのが、労働においてはある……。労働にはいろいろあります……。 さて、オレオレパッチの是非については一旦おいておいて、gemにオレオレパッチを当てたいとき、オープンクラスを利用してモンキーパッチを当てることが一般的には多いのではないでしょうか（繰り返しになりますがここではオレオレパッチの是非は問いません）。Railsを利用している場合、config/initializers以下にモンキーパッチのためのファイルを入れて、Rails起動時にgemの挙動を拡張、あるいは変更する、というような手段が多くの場合取られるのではないかと思います。 しかし、Railsを利用し
twitterに書いたやつ再掲+加筆。 Webフロントエンド、というかSPAの設計で、単なるwebAPIラッパーに対して「Repository」と名付けるケースが散見されるけど、ぼくはあれあまり好きではないです。というのも、Repositoryという名前がついてると、集約的なもの、それが言い過ぎならいわゆるEntity、それも言い過ぎならひとかたまりのデータを保存、取得するだけの責務のように思えるからです。けど、実際の「Repository」を見てみると、取得されるのは画面の仕様にベッタリなJSONだったり、更新系としてもなんちゃらidとパラメータを渡すようなIFになってることが多いですよね。画面の仕様にベッタリなJSONが返ってくるようになってたり、idとパラメータ渡すだけだったりするのは、多くの場合考えることが少なくて済むし通信量も減る良いプラクティスだと思うので、それ自体は問題ではな
最近、高校の先生が「知識問題」「思考問題」という言葉を使ってらっしゃるのを聞いて、「なるほど、面白い分類だな」と思った。それ以来「知識問題と思考問題」という視点で物事を眺めるのが自分の中でブームとなっている。 もちろん、知識問題と思考問題というのはきれいにスパッとわかれるものではなく、グラデーション状になっていると思う。この問題はやや思考問題よりだね、とか、かなり知識問題に振れてるね、とか、かなり思考問題寄りだね、とか。 ソフトウェアの設計について考えてみると、じつは、ソフトウェアをどのようなレイヤーに分割するか、というような話はかなり知識問題寄りに見える。この問題には先人の知恵がたくさんあって、それらが「傾向と対策」として未知の問題にも流用しやすい。 一方で、レイヤーの内部をどのような責務でどのようクラス、コンポーネントに分割していくのかというのは、かなり思考問題よりに見える。このとき、
次のページ
このページを最初にブックマークしてみませんか？
『猫型の蓄音機は 1 分間に 45 回にゃあと鳴く』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
