  |
はてなキーワード: sdkとは
セルシスではプラグインSDKのダウンロード時に、使用許諾に合意する必要がある。
そして、その第4条には、プラグインSDKの再配布についての条項がある。
ざっくりいうと、「公式で審査の上で公開する以外の、勝手な再配布は認めない」というもの。
なので、プラグインSDKを利用しようとする以上、この規約には当然従う必要がある。
だが、青猫氏は審査前にGitHubで勝手にSDKを使った自作プラグインを公開してしまった。
それのみならず、「審査が通らなかったら、ソースコードとビルド用バッチファイルの形で非公式に配布する」と
https://x.com/aonekoss/status/1836418339729739860?s=61&t=w77c_83Mc7twk3hZpQ2ZPw
バッチファイルならプラグインとして完成していないとみなせるからOKだろう、という理屈と思われるが、
ということで、この件、AIとか反AIとか一切関係ない話である。セルシスの審査を待たずに公開し、
審査が通らなかったら非公式にばら撒くと宣言している青猫氏と、規約を守れと繰り返すセルシスの話だ。
Device Info は、高度なユーザー インターフェースとウィジェットを使用してモバイルデバイスに関する完全な情報を提供するシンプルで強力な Android アプリケーションです。たとえば、デバイス情報/ 電話情報には、CPU、RAM、OS、センサ、ストレージ、バッテリー、SIM、Bluetooth、ネットワーク、インストール済みアプリ、システム アプリ、ディスプレイ、カメラ、温度などに関する情報が含まれます。また、デバイス情報/ 電話情報は、ハードウェア テストでデバイスのベンチマークを行うことができます。
中身 : 👇 👇
👉 ダッシュボード : RAM、内部ストレージ、外部ストレージ、バッテリー、CPU、利用可能なセンサ、インストール済みアプリ & 最適化
👉 デバイス : デバイス名、モデル、メーカー、デバイス、ボード、ハードウェア、ブランド、IMEI、ハードウェア シリアル、SIM シリアル、SIM サブスクライバー、ネットワークオペレータ、ネットワークタイプ、WiFi Mac アドレス、ビルドフィンガープリント & USB ホスト
👉 システム : バージョン、コード名、API レベル、リリース バージョン、1 つの UI バージョン、セキュリティ パッチ レベル、ブートローダー、ビルド番号、ベースバンド、Java VM、カーネル、言語、ルート管理アプリ、Google Play サービスバージョン、Vulkan のサポート、Treble、シームレスな更新、OpenGL ES およびシステム稼働時間
👉 CPU : Soc - システム オン チップ、プロセッサ、CPU アーキテクチャ、サポート対象の ABI、CPU ハードウェア、CPU ガバナー、コア数、CPU 周波数、実行中のコア、GPU レンダラー、GPU ベンダー & GPU バージョン
👉 バッテリー : ヘルス、レベル、ステータス、電源、テクノロジー、温度、電圧と容量
👉 ネットワーク : IP アドレス、ゲートウェイ、サブネット マスク、DNS、リース期間、インターフェイス、周波数、リンク速度
👉 ネットワーク : IP アドレス、ゲートウェイ、サブネット マスク、DNS、リース期間、インターフェイス、周波数、リンク速度
👉 ディスプレイ : 解像度、密度、フォント スケール、物理サイズ、サポートされているリフレッシュレート、HDR、HDR 機能、明るさのレベルとモード、画面のタイムアウト、向き
👉 メモリ : RAM、RAM タイプ、RAM 周波数、ROM、内部ストレージ、外部ストレージ
👉 センサー : センサー名、センサベンダー、ライブセンサ値、タイプ、電力、ウェイクアップセンサ、ダイナミックセンサ、最大距離
👉 アプリ : ユーザーアプリ、インストール済みアプリ、アプリバージョン、最小 OS、ターゲット OS、インストール日、更新日、アクセス許可、アクティビティ、サービス、プロバイダ、レシーバー、抽出アプリ Apk
👉 アプリアナライザー : 高度なグラフを使用して、すべてのアプリケーションを分析します。また、ターゲット SDK、最小 SDK、インストール場所、プラットフォーム、インストーラ、および署名によってグループ化することもできます。
ディスプレイ、マルチタッチ、懐中電灯、ラウドスピーカー、イヤースピーカー、マイク、耳近接、光センサ、加速度計、振動、Bluetooth、WI-Fi、指紋、音量アップボタン、音量ダウンボタンをテストできます。
👉 温度 : システムによって指定されたすべての温度ゾーンの値
👉 カスタマイズ可能なウィジェット ： 最も重要な情報を表示する 3 つのサイズの完全にカスタマイズ可能なウィジェット
👉 レポートのエクスポート ： カスタマイズ可能なレポートのエクスポート、テキストレポートのエクスポート、PDF レポートのエクスポート
権限 👇 👇
READ_PHONE_STATE - ネットワーク情報を取得するには
BLUETOOTH_CONNECT - Bluetooth テスト
READ_EXTERNAL_STORAGE - イヤースピーカーとラウドスピーカーのテスト
この記事では、暗号資産投資を考えている初心者の方向けに、いま界隈がどういう状況になっているか、もし投資するとしたらどのようにアプローチしていくべきかを身も蓋もない形で説明します。
以下のどれかが望ましい。
2024年のメインイベントは米国ETFとビットコインの半減期、そして利下げ開始である。
つまり主導権は米国経済でありつつ、暗号資産のサイクル的には半減期通過で一定の期待が持てる状況。
ビットコインはまもなく米国の現物ETF判断が出て、かなり確度が高く承認の見込み。質のいい資金の流入が期待できる。
イーサリアムもETF申請が行われており、こちらも確度が高い。スケジュール的にはビットコインの相当あとになりそう。
コインベースは、これらのETFのカストディアンとしてほぼすべての申請が指名している。新NISAでビットコインETFはまだ買えないので、もしその枠で検討するならコインベースがいいだろう。ただし、コインベースは自分の鍵で管理できるアセットではない。分散思想的にNGな人はビットコインかイーサリアムを買えば良い。
上記三種以外にお金を入れる人は、自信過剰な界隈の猛者か、資金を最速で失うお客様である。これを忘れてはいけない。
上記で挙げなかったが、ソラナ（SOL）とアバランチ（AVAX）は選択肢として検討しうる。ただ、ビットコインやイーサリアムより遥かに価格変動が大きい。例えばソラナでいえば、以下の文脈を踏まえた投資が必要。
もし現時点で一つでも詳しくないトピックがあるとしたら、貴方は情報で劣後している。投資家ではなく出口様である。止めておいたほうがいい。
1月初旬（というか数日中）に承認されそう。承認後は資金流入が期待できるが、事実売りで低迷期があるのではないか？と懸念されている状況。
2024年4月になりそう。売却圧が減りテクニカル的に煮詰まることで、半減期後しばらくすると価格が急騰すると一般的には言われている。現在のところ再現性もある。ただし、半減期の前後で毎回大きな調整が発生している。
2024年3月ごろになりそう。いわゆるレイヤー2と呼ばれる連中の取引手数料が減ると思えばOK。
いつ始まるか不明。
利下げが始まると、一般的には債権に資金が流れるため、株やコモディティの価格は下がりがち。
①②③の価格押上効果は強そうだが、④を考えると、通年でのんきに価格が上がっていくというシナリオは考えづらい。
かなり高い確率で、大きめの調整があるだろう。そのため、どのタイミングで資金を入れるかはよくよく考える必要がある。
株の暴落があると思うなら調整を待てばいいし、難しいことを考えたくないならドルコスト平均法でのんびり買えば良い。
「暗号資産業界に興味があるから、NISAでコインベースを買って放ったらかします」も悪い選択肢ではない。
上記以外にお金を入れるな。これに尽きる。インフルエンサーが様々な暗号資産を煽るだろうが、彼らは本質的に出口を欲している。あなたはお客様だ。ゲーム、GPS、AI、新興チェーン、まあとにかく手を変え品を変え出てくるだろう。
だが、どれほど詳しい人であっても、基軸となるトークンよりも良いパフォーマンスを出すことは至難である。
2023年の年初にBTCを買ってホールドすれば、資産は3倍弱になっていた。大きな声を出してキラキラと煽る彼らがそれ以上の利益を出せていたか？答えはNOである。もちろん例外はいるが、そんなのは例外に過ぎない。
ブロックチェーンゲームで良作が出たとしよう。あなたはそのトークンを買ってはいけない。楽しいゲームが出たら遊べ。シンプルにそれだけでいい。買うな。初心者が、界隈の猛者を差し置いてラッキーパンチを引けるか？ そんなことは不可能である。
BTCとETHを以外を買った場合、あなたは高確率でお金を失う。
Inscriptionのせいで、これまでシットコイン製造機と散々バカにしていたスマコン通貨と同じ悲劇がビットコインで発生。
ビットコインは最早シットコイン製造機であり、ギャンブルの本場である。ETF賛否と合わせてコミュニティで意見が割れる。
彼らの本音と建前を書くとこうなる。
Inscription：
（本音）俺たちの大好きなビットコイン上でカジノ遊びしやがって、ふざけんな絶対に許さん
（建前）Permissionlessなので止めることはできない。手数料が増えることも持続可能性にとってプラスである。
ETF：
（建前）ETFは、自分の鍵を自分で管理するビットコインの本来のTrustlessに反する動きである。賛同しない。
ソラナの猛追を受けて自信喪失気味。待望のアップデートが目前、Modularの筋の良さも相まり決済レイヤーとして展望が良くなっている状況でこれは不思議極まる。
一方でOFAC準拠のバリデーターが増加傾向だったり、バブル期に弱者から資金を抜きまくっていた勢力がエアドロにタカり始めた結果、本家シットコインカジノの汚い輝きが増してきた。彼らは投機を越えた投棄勢であり、ロクな連中ではない。イーサリアム界隈に行くなら注意しよう。
Trustlessの世界で、CZをTrustする不思議なひとたちがかつていた。米国に押し込まれた結果、王国は半壊。パーティー会場として散々散らかされたBSCは廃墟と化し、深刻なアイデンティティ危機に見舞われている。opBNBはOP stackを使って構築されているが、BSCに共通する文化、つまりオリジナルに対する敬意が極めて希薄。コピーキャットを礼賛する連中の集まりのなかで、Pancakeだけが唯一、勢力を保っている。
2023年に最大の利益を得た勢力。といっても、「FTX崩壊事件後、ATHからどの程度戻したか」という指標で見ると実は他とそんなに変わらなかったりする。開発者コミュニティが残り継続的なアクティビティがあるのは素直に称賛されるべきだろう。とはいえ、JLPはオラクル決済型GMXとほぼ同じ設計で、Bonkはミームである。現状、何もかもが足りていない。FTXの巨大な売圧はまったく解決していないし、他と比べたときの高インフレ体質は調整時の脆弱さにつながる。もちろん高値更新を続ける可能性はある。だが、イキリ散らかした後始末はどこかで歪みとして発生するだろう。
ModularのETHとモノリシックのSOLに囲まれて、存在感がどんどん薄くなっている。
イーサリアムのアップデート後はさらに苦しい立場になりそう。最近Avalanche Foundationがミームトークンに出資する発表をしていたが、まさに迷走を象徴している。
ATOMはもう救えない。みんな諦めた。可哀想に。Celestiaが生まれたことで、Modularの中心候補としてイーサリアンと奇妙な共闘状態になりつつある。同床異夢となるかは分からん。
DoKwonが、事業失敗ではなく単なるポンジ詐欺師だったことは様々な報道や裁判で明らかになっているが、全員目を背け忘れたフリをしている。
過去に煽ってた連中は涼しい顔をして別のプロジェクトを推している。
あとこいつの問題は、「これを買えば安心」という基軸がないこと。これに尽きる。Tia高すぎるだろ。
もう救えない。polkadot sdkは微妙に使われているが、そいつらが生き残っていけるかは不明。生き残ったとしてもDOT本体とはあまり関係がない。現在の構造で競争に勝ち抜くのは無理。
無理。がんばってください。
期末時価に対する税制改正など、バズワードだったWeb3をテコにした法改正はとてもうまく立ち回っている印象。汗をかかれたかたはお疲れ様でした。一方で一向に統一されないJVCEAとJCBA、トラベルルールで相互に送付ができない取引所など、なんでそうなるねんという状況が多い。控えめにいって業界としてのガバナンス能力がない。
経営層もさー、明らかにプライベートでスマコン触ってないでしょ？ そういう人が指揮をとるのは業界の損失なので、さっさと後進に道を譲ってください。
https://agree.5ch.net/test/read.cgi/operate/9240230711/
0001５ちゃんねる ★
2023/07/11(火) 00:00:00.00ID:LokiTech
旧バージョンの5chブラウザ（API前）は近く再度利用可能となります。
5chのAPIは現在公開しており、開発者は誰でも5chのブラウザを作成できます。
全ての5chブラウザは自身の広告SDKを使用でき、収益を分配する必要はありません。
もしJaneを通じてRoninを購入した場合は、ジェーンに対して返金を請求してください。
旧バージョンの5chブラウザ、っていうのが何を指しているのか知らんが
多分ギコナビやらV2CみたいなJaneStyle以外の専ブラが使えるようになるんだろう
あとAPIが公開されてるから誰でも今から新しい5chブラウザ作れるらしい
仮にこの記事にブコメがついたとしたら、やっぱり投機投機書かれるだろう。
そういう人はこの記事の対象ではないので無視して良い。はてなコミュニティの老化は見てて悲しいね。
これは明らか。今ではない。
いま、米国債の利回りとステーブルコイン運用の利回りを比較したときに、前者のほうが高いからである。
FOMCの政策金利は4.5%で、ステーブルコイン運用は安定を取るとせいぜい5-10%程度である。一見後者のほうが良いようにも思えるが、前者はリスクを取らんでいいのでお話にならないほど差がある。
結果、いまスマコン上で発行されたステーブルコインの償還が止まらない。市場がシュリンクしていく過程にある。新規流入がなければBTCの新規マイニング分が吸収できないので、価格はだんだんと維持できなくなり、いつか暴落を始める。
半減期後、新規が細ってBTCが暴落を起こすのは毎回引き起こされている現象ではある。今回は特にマクロが悪いので、いつもよりもっと悪いことになる可能性が高い。
2022年は酷い年だった。2023年には期待したいところだが、残念ながら、特に前半はまだこの道半ばにいる可能性が高く、強気でいられる理由がない。
話を戻そう。米金利。ターミナルレートに到達してから利下げ開始までは結構な時間がかかると見られている。
景気は悪化していく可能性が高い。いまは株価が景気悪化を折り込み始めたタイミングである。
あと何周かするとテーマが景気悪化から利下げに戻ってくるので、実際にそのような発言・観測が出てきたとき買い始めるのが良さそうだ。
ただ、「いつ利下げを折り込み始めるのか」「折り込み始めたタイミングの価格帯が今よりも下なのか」は誰にもわからない。
下落相場のなかにあっても、短期的な反発は必ず起きる。今の価格が底で、Pivotのタイミングではもっと上の価格帯である可能性もある。が、慌てて買わずに、時期を待つことをオススメする。無意味なリスクを取る理由がない。
もし、マクロを見ずに買い始めたいのなら、「BTCが前日比10%以上値を下げた」日から分散購入しよう。
一年に数回は発生する珍現象で、タイミングとしてはおそらく望ましい。
この分野もだいぶ勝者が絞られてきた。具体的にはatom, matic, avaxが候補である。
Solanaは残念ながら脱落した。
atomは将来性があるが、難しい。atomの価値＝cosmos sdkの価値ではないからだ。
maticはzk(e)vmの展開次第では化ける。
avaxは上記二者と比べると差別化に苦労しているように見える。
オラクル系も差別化されていて、勝利者であるchainlinkは可能性があるように思える。
一応候補としては挙げたが、これらがBTC/ETHを安定的にアウトパフォームすることは難しい。
Solanaの劇的な死をいったい誰が予測できたといえるだろうか。そしていままでの価格推移がそれを証明している。需給でイーサに勝つのもなかなか難しい。
BTCは自分のウォレットにうつしてガチホする以外に選択肢がない。WBTCはやめておけ。
ETHはどこかのサービスでステークしよう。現状stETHが安牌である。
こういう愉快な連中が、表向きニコニコしながら内心敵視しあっているのが現状のクリプト業界である。といいつつも前進はしている。どれかに張るならBTCかETHが良い。
学歴がよくなくて、就職が困難だったので中小 SIer で働いていた。 (プライム案件を取ってこれる分マシらしい)
レキサルティ、レクサプロ、デパスのお世話になって続けてたけど、結局は薬でどうにかできず、辞めてしまった。
参考程度だけど、未経験の人が 300万 をもらうために、どのようなスキルが必要かを、まとめておく。
ちなみにどれくらいプログラムが書けなかったかというと、競技プログラミングで努力しても AtCoder の黄色になれず青色のままってくらい。
AtCoder でいう、初心者から抜け出せないという、要するにセンスがないということなのだけど、そういう人も居そうなので、参考までに。
未経験のプログラマに対して、これだけ要求されるのだから、未経験の人は覚悟するようにという指針を提供したいので書いた。
基本的に、損害を与えた場合には、それを作業者が補填するという誓約書を結ぶ。
要するに、捨て駒として扱って、失敗したら賠償しろ、という事になる。
このことを認識して、失敗しないように振舞ないと、連帯保証人含めて迷惑をかける事になる。
要するに、低賃金で未経験プログラマを案件にノーリスクで送りこんで、稼ぐための手段です。
基本的に PL (夢想家) → PM (御用聞き) → プログラマ という環境なので、プログラマが自分でディレクションして意思決定する必要がある。
例えば、下請けの場合は、PM の御用聞きの結果の WBS に合わせないと、顧客から DM で 瑕疵担保責任がどうとか言われる。
社内開発の場合は、PL の方から直接、長時間の叱責を受けなくてはならない。
そういう不幸を防ぐためにも、自分でディレクションして、PM の決めた実態を反映していない WBS に合わせて作業するスキルが要求される。
基本的に手戻りは個人の過失になってしまうため、手戻りしないように考え抜いて意思決定をする、というのが重要になる。
これこそ、ガクチカと呼ばれる、頑張れますというスキルなので、学生時代に頑張っておけばよかったなぁ。
こう見せたい、こう表現したい、という事を伝えるには、必然的にデザインの知識が必要になる。
創造的思考とデザインは切っても切り離せない概念で、デザインとは創造なのだから、当たり前である。
ソフトウェアアーキテクチャも、ソフトウェア設計も、コーディングもデザインと言えるかもしれない。
顧客と 1:1 で話す事が DM でもボイチャでも突発的に発生するので、いつ、いかなる時でも論理武装していなければならない。
まぁ、顧客であったり PL であったりはキレるのが仕事なので、それに対して理路整然と説明する必要がある。
なんとなく、では納得しないし、すぐ損害賠償請求とかそういう話にいくので、答えられないと持ち帰りますとお茶を濁して、エマージェンシーになる。
後述する設計能力においても、課題を把握するための言語技術(言語化能力)は重要なファクターだと思う。
C/C++ のシステムプログラムはフレームワークが基本的に無いので、自分で概念を整理して、どのような変更、拡張があるかを考えて設計する必要がある。
この能力が弱いと、手戻りが発生しやすくなり、瑕疵担保責任を問われることになる。
読んだ本の中だと、ボブおじさんの本が、やっぱりしっくりくるなという個人的な感想がある。
UDP で送ってくるデータを受けて 24/365 で停止しない WebAPI への繋ぎ込みという簡単な作業があって、振られた。
リークしてはいけないという事で malloc は禁止で、グローバル変数を利用するという変なルールがあった。
Rust で書けばいいんじゃないかなと思ったけど、Rust 書くのもシンドイし、C/C++ で、しんどくて読みづらいコードを書いた。
あとで保守する人が大変そうだけど、そういうルールを決めたのは PL だしね。
なんか、特殊な PCI Express のカードからベンダーが用意している SDK でデータ引っこ抜いて Web API へつなぎ込む部分をやった。
一応、SDK の使い方をパラ見して 1 日で作ったので、別に負担じゃなかったけど、素人にやらせるんなとは思った。
当たり前だが、DB 作って RestAPI を生やすのは現代のプログラマにとって自然にできなければならない。
なので、新規開発のサブモジュールのバックエンドを任せられた。
だが、ORM の癖を把握したり、発行されるクエリを確認したりするのは、疲れる。 SQL を直書きするのはシンドイ。
結局 SQL を直書きすることにしたけど、あまりいい決断ではなかったと思っている。
それ以外は フレームワーク に乗ってしまっていいので、書き捨てる分には楽だった。
最近だと、TypeScript で Prisma 使うのが、型安全でよさそうだなと思っている。
デプロイを EC2 直でやったり ECS にしたりとしていたので、ベアメタルの知識が必要になった。
要するに systemd のいじり方とか、死活監視の仕方とか。
個人的には、クラウド嫌いなので、ベアメタルの方が安心できる。
Bind で権威DNS を管理して、postfix で絶対止めてはいけないメールサーバを管理するとかもあったけど、出来て当然ではある事だし。
未経験プログラマでも、月単価 100 万以上で顧客に請求してるんだから、会社はそりゃ儲けるだろうと思った。
会社が一人前の経験N年のプログラマといったら、その通りに振舞う必要がある。顧客に責任はないのだから。
当たり前だが、Webディレクション、Webデザイン、Webプログラミング, Webマークアップ は、全て作業者であるプログラマの仕事になる。
個人的には、これが分かれている理由が良く分からないけど、分けたい人がいるんだろう。
デザインで、CSSフレームワークを使うと、その色が出るという事で、全部 CSS は手書きしていた。
tailwind が出た現在では使っていればよかったなと思う。
結局、全く分からない中、手探りでデザインし、コードを書いて、顧客に 1 日 5 ~ 10 回リリースするという行為をした。
顧客は大手企業だったので、自社のエンジニアならもっと出来る、と叱責されまくったけど、だったら自社でやればいいじゃんと思った。
一応、今でもサービスは生きていて、ユニークユーザ数は上がっているらしい。
そして、焼き付け刃だったので、 WAI-ARIA を知らず、アクセシビリティへの配慮が足りない事が問題になってしまった。
これはなんとか保守対応にねじ込めたのでトラブルにならなかったけど、瑕疵担保責任と綱渡りだなと思った。
当たり前だが、リリースサイクルを短くしないと顧客はキレてしまうので、CI/CD を整えないといけない。
今は Github Actions とかあるけど、昔は無くて Bitrise が高いからみたいな理由で Azure Pipelines で CI/CD フローを構築した。
もう Multi Stage Pipeline になってるだろうけど、Release Pipeline が GUI からしか設定できないのが辛みだった。
当然だが、デプロイするためには IaC を整える必要がある。
これを知らずに、コンソールでポチポチしていたので、 IaC 出来てない事がバレた時に色々怒られてしまった。
本来はテストも自動テストを整えて、質保証をしてバグを減らさなければならない。
だが、テストを書くという手間を払えなかったので、人力テストしかできなかった。
一応、リグレッションテストを人力でやりまくったので、バグ発見曲線が結合テストでの IF 不一致しかない、という結果にはなったけど
自動化できれば費用が必要じゃなかったから、怠慢だと、責められてしまった。
未経験でも誓約書を盾に、振られた事全部を出来なくてはならない慣習があるので、プログラマはそんなに良い職業じゃないよ。
甘い考えで、プログラマになろうと思っているのなら、考え直した方がいいです。
「AMPやめました」という記事がちょっと前まで流行っていたが、CWVの改善に専念できる広告ビジネス（AMPの多様な広告SDKを組み込めない点は致命的欠点となる）のサービスでの話ばかりだった。
逆に言うと、広告ビジネスではなく、CWV改善に専任スタッフを充てられないような会社にとっては依然AMPは有用で、実装的にもNextJSのAMPモードのような汎用性のある実効的な手段が枯れてきたこともあって、「今だからこそAMP」という部分もあるように思い、そのうち擁護の一つも書いておこうかと思っていた。
ところがだ、GA4移行の実質的なデッドラインである7月 https://fujii-yuji.net/2022/04/18/153533 まで3ヶ月を切ったにも関わらず、未だにAMPはGA4に対応していない。
https://www.suzukikenichi.com/blog/google-analytics-4-doesnt-support-amp-yet/
https://github.com/ahmedkaludi/accelerated-mobile-pages/issues/4793
うちの会社のアプリの通信の一部にはピン留めされた証明書が使われている。
と言ってもサードのサービスとの通信でだ。そのサービスのSDKをアプリに仕込んで、ユーザーの挙動を逐一そのサービスに送って後で解析するのだ。
そしてそのサービスはセキュリティを理由にこの技術を使っている。
これにより中間者攻撃ができないので何を送ってるのかはセキュリティ専門家でも分からない。
だから何でも送り放題だ。うちはパスワードこそ送ってないが、こんなもんまで送って良いんかなというものも送っている。
でも通信を覗けないのでバレない。これ自分がただのユーザーだったら超嫌だなと思う。
当方、地方駅弁を中退して東京の「偏差値の高い、理系のイメージの無い、学費の高い、ロイヤル・ゴシップ」で有名な大学に再受験した、今はしがない三十路のオジサン・プログラマーですのよ。まぁ、マイクロソフトやグーグルの日本法人に入れなかったけど、それぐらいなら上場企業を創業したかったし、ゲームも自前でコードを書きたかったから、それができなくてコーダーに落ち着いたけど、悪くない人生だと思ってる。想定外なのは、カネがないくらいだ。
それで、何が言いたいかというと、地方駅弁の情報理系は「教育の品質は劣っていなかった」ということを言いたいのだよ。なんていうか、地方駅弁の方が教育の品質は良かったのよ。間違いなく、地方駅弁の方が予算は潤沢だった。おそらく、九工大や会津大とか筑波大とか、本当に教育は頑張っていると思う。たとえば東京の理系大学だと、東大と東工大は別格として、早稲田と慶應（後述するがSFCは立地がダメ）も一流は多い。ただ、マーチレベルになると教育は、地方駅弁か高専の方が良いような気がした。頭の出来は、地方駅弁が有意にマーチか関関同立に劣るということはないと思う。というか、マーチ理系のプログラマーは東大と一橋と京大のプログラマー転向者（NやFとかの SIer に入って、プログラミングの歓びを知ったタイプ）にボコボコにされるケースが多いような気がする。都内だと LL の需要が高くて、理工系の知識が不要なコードで食っていけるからなんだろうけどさ。早慶の文系のプログラマー転向組は「これだから、私文は...」という感じが多かったので、本当に不思議な気がする。あと、何故か音楽好きな連中は、文系でもプログラマー適正が高い気がする。
それ以上に、東京がすごい。なんというか、東京中心部のプログラマーの需要は凄まじく、バイトでも「俺の書いたコードが、世界で動く」というチャンスをくれたりしたので、やっぱり大学の立地は資産の上では差がつくと思うよ。自分なんかも、SDK を Java と Objective-C と JavaScript で書かせてもらったのは刺激になったよ。若さを金にできるのは、東京の良さだと思う。たとえば、大御所のソフト会社（チュンソフトやスクエア）が、学生起業で大きくなれたのは、東京の土地でないと難しいと思うし。あと、駅弁大学のベンチャー企業は成功していて、それは必ず東京で成功している。
自分の周りではクラブハウス流行ってるんだけど、このサービスも機能追加やPlatform化が遅れたりすると、ユーザ離れが進んでSNS事業だけだとやっていけないみたいな話になって、これからはゲームだって話で、「クラブハウスストライク」とか出すんでしょ？でもって、レイトマジョリティの「クラブハウスってゲーム会社が出してるクラストっていうのがあって」とかいう話を聞きかじったアーリーアダプタとしては「だいたい合ってるけど、全然違うんや」って言葉を口の中で噛み殺したりすることになるんでしょ?
運よく上場できても、赤出したりして経営陣が揉めてCEOが退任して、マネタイズちゃんとしようと言いつつ、うまくできなかったりして、元のCEO呼び戻せとかいう話になって戻して、やっぱり広告必要だって話になって、ルーム一覧に広告が表示されるようになって、Streaming APIみたいなのも廃止されるんでしょ?
上場して大きな会社になった場合には、Platform化に成功して、他社向けにClubhouse SDKとか提供して、他社アプリからめっちゃ情報収集してるとかで批判されて、創業者は創業者でその頃にはお金持ちになって財団とか設立して「クラブハウスはもういい」みたいなこと言い始めるんでしょ?
他にも、上場せずにM＆Aされた場合には、M＆Aした会社から機能を増やせとか利益を上げろとかめっちゃ言われて、元々シンプルなポラロイド風の写真共有サービスだったのに、ポラロイド風以外の写真共有や動画共有まで機能として入れることになって、全然違うアプリになっちゃって、元の創業者がキレて辞めたりするんでしょ?
うまくいけば、アーリーアダプタはその大部分が数年後とかには飽きて使わなくなってると思うんだけど、その頃にアプリを使い始めたレイトマジョリティと話をしてみたら、「最初の頃はもっとシンプルで、楽しかったんだよなぁ」と思ってるアーリーアダプタと、「このアプリすごいね」と言うレイトマジョリティで、なんか噛み合わない感じになったりするんでしょ?
全部知ってるんだから。
next.js が vercel を提供して CDN からサーバーサイドでの処理までをワンストップに提供しているとか、 firebase がクライアントサイドでの SDK と Cloud Functions をなるべく一貫した体験で提供しようとしていることとか、あるいは今話題の React Server Component とかについて、フロントエンドの最前線がいったいどのような苦しみにあるか、理解できる人は実はあまり多くないのではないか、と僕は思っている。
それは何かといえば、絶望的なまでのサーバーサイド/バックエンドへの忌避感だ。「とにかくフロントエンド領域しか絶対にやりたくない」という人が沢山いるが、しかし一方フロントエンドで無理しないでサーバーを書くだけで楽になるようなタスクはいくらでもある(典型的には API たくさんアクセスするとか)。
そうしたときに、フロントエンドメインだがバックエンドも書けるみたいな人がそういうサーバー忌避患者を介護する層として BFF の需要があり(無論それだけが BFF に求められるのではなく認証などの要素も大きいが)、サーバーサイドレンダリングというタスクもあるため node.js で何らかのサーバーが書かれていった。
アイソモーフィックな JS によりフロントエンドとサーバーサイドを統合する、という試みはこれまであまり成功しなかったので(結局どっちにも詳しくないといけないから正しく書ける人がすくない)、 next.js の getStaticProps や React Server Component は「サーバーサイドだけで動くコードを見た目上フロントエンドのコードの中に含める」という解決策を提示した。
ここまでしないとフロントの人がサーバー側を書いてくれないという現実は、あるわけですよ。「そんな奴言って聞かせりゃいいじゃねえか」とか思うかもしれないけど、これが現実。これが全てという話でもないけど、わりとこんな話が大きいように僕には見える。
起きていることはそういう話なのだけど、これはけして JSP 時代への先祖帰りではなく、この進歩の先にはサーバーとクライアントを跨いで快適な UX を誰でも簡単に実現するという未来が、もしかしたら今回こそ実現できるかもしれない、と僕は思ってます。
