「コンポーネント」を含む日記 
はてなキーワード: コンポーネントとは
2025-01-28
■anond:20250128003928
LAMPとは？
ソフトウェアにおける「LAMP」とは、Webアプリケーション開発や運用のためのオープンソースソフトウェアの組み合わせを指します。
- L - Linux: オペレーティングシステム（OS）
- A - Apache: Webサーバー
- M - MySQL: データベース管理システム
- P - PHP (または Perl や Python): サーバーサイドのスクリプト言語
主な特徴
- オープンソース: すべてのコンポーネントが無料で利用可能であり、カスタマイズ可能。
- 安定性と柔軟性: 長年の開発と利用により、安定性が高く、様々な規模のプロジェクトに対応可能。
- 広い採用: Web開発の基本スタックとして、多くの開発者や企業に使用されている。
それ以前は？
LAMP登場以前のソフトウェア開発環境は、現在に比べて選択肢が限られており、多くの場合、コストが高かったり技術的なハードルが高かったりしました。
1. 商用UNIXシステム
1990年代初頭まで、UNIXベースのシステムがエンタープライズレベルで広く利用されていました。これには、Sun MicrosystemsのSolarisやIBMのAIXなどがあり、これらのシステムは高価でありながら強力なサーバーとして機能しました。
2. プロプライエタリなデータベース
OracleやIBM DB2などの商用データベースが一般的で、これらは高価なライセンス料が必要でした。MySQLのようなオープンソースのデータベースが広まる前は、大規模なデータ管理には高い投資が必要でした。
3. CGIスクリプト
Webアプリケーションにおいては、CGI（Common Gateway Interface）スクリプトが利用されていました。これにはPerlがよく使われており、サーバーとブラウザ間のデータ交換を扱っていました。しかし、CGIはプロセスごとに新たにスタートするため、スケーリングには不向きで、リソースを大量に消費する傾向がありました。
4. 初期のWebサーバー
Apache登場以前は、NCSA HTTPdのような初期のWebサーバーソフトウェアが利用されていましたが、設定や管理が複雑で、今日ほど柔軟ではありませんでした。
5. フロントエンド技術
フロントエンドの開発では、HTMLが基本的であり、JavaScriptが登場し始めたばかりで、CSSはまだ普及していませんでした。このため、デザインと機能性は限られており、ユーザー体験は今日見られるようなリッチなインタラクティビティには程遠いものでした。
そのような環境下でLAMPが登場しどのような影響があったのでしょうか？
LAMPスタックの登場は、ソフトウェア開発とインターネットのWebサービスの領域に大きな変革をもたらしました。
以下に、その主な影響を挙げます。
1. コスト削減
LAMPスタックの各コンポーネント（Linux, Apache, MySQL, PHP/Perl/Python）はオープンソースであり、無料で利用可能です。
これにより、企業や個人開発者は高額なライセンス料を払うことなく強力なWebアプリケーションを構築できるようになりました。
この低コストのアプローチは特にスタートアップ企業や小規模プロジェクトに大きなメリットをもたらし、革新的なアイディアが資金の制約なく試される土壌を提供しました。
2. 技術の普及とアクセシビリティ
LAMPスタックは、その設置と運用のしやすさから、多くの開発者に受け入れられました。
オープンソースであることから、コードのカスタマイズや改良が可能で、コミュニティからのサポートも豊富でした。
これにより、Web開発の敷居が大きく下がり、より多くの人々が開発活動に参加できるようになりました。
3. 性能とスケーラビリティ
Apache Webサーバーは、高いカスタマイズ性と拡張性を持っており、MySQLは大規模なデータセットでも高性能を発揮することができました。
PHPは動的なWebページの生成に適しており、これらの技術が組み合わさることで、性能が要求される大規模アプリケーションも効率的に運用可能になりました。
4. プラットフォームの成熟
LAMPスタックの普及により、Web開発プラットフォームとしての成熟が進み、企業や開発者は、安定した基盤の上でさらに複雑なアプリケーションを構築することが可能になりました。
これにより、電子商取引、コンテンツ管理システム（CMS）、およびその他多くのWebベースのサービスが急速に広がりました。
5. 革新の促進
低コストかつ高機能な開発環境が広く利用可能になったことで、新しいタイプのWebサービスやビジネスモデルが登場しました。
LAMPを基盤とする多くのスタートアップが、業界に新風を吹き込み、既存の市場構造を変革する原動力となりました。
LAMPスタックの影響は、テクノロジー業界全体において、コストの効率化、アクセスの拡大、そしてイノベーションの加速という形で現れました。
2024-12-21
■「電源で音質が変わるか」というテーマで、Copilot の作文
Copilot に作文を依頼した。
「電源で音質が変わるか」というテーマで、それに否定的に答えたＡＩに、音楽評論家の人間が反論を語る、という作文を書いて。
以下、回答。
━━━━━━━━━━━━━━━━━━━━━━━━━
AI：電源の品質が音質に影響を与えるという主張は、科学的根拠に乏しいと言えます。現代のオーディオ機器は、電源の変動を補正するための高度な技術を備えており、電源の違いが音質に顕著な影響を与えることはほとんどありません。例えば、ノイズフィルターや電圧安定化装置が内蔵されているため、電源の質が音質に与える影響は最小限に抑えられています。
音楽評論家：AIの見解には一理ありますが、実際のオーディオ愛好家やプロフェッショナルの現場では、電源の質が音質に与える影響を無視することはできません。特に高級オーディオ機器においては、電源の質が音の透明感やダイナミクスに大きく影響することが知られています。
例えば、オーディオ評論家の間では、電源ケーブルや電源コンディショナーの違いによって音質が変わることが広く認識されています。これは、電源から供給される電流の質が、アンプやDAC（デジタル・アナログ・コンバーター）の動作に微妙な影響を与えるためです。電源のノイズや不安定な電圧が音質に悪影響を及ぼすことは、実際のリスニングテストでも確認されています。
さらに、オーディオ機器の設置環境や使用する電源の種類によっても音質が変わることがあります。例えば、専用のオーディオルームで使用する場合と、一般的な家庭のリビングルームで使用する場合では、電源の質が異なるため、音質にも違いが生じることがあります。
結論として、電源の質が音質に与える影響を完全に否定することはできません。オーディオ機器の性能を最大限に引き出すためには、電源の質にも注意を払うことが重要です。AIの見解は技術的な側面に焦点を当てていますが、実際のリスニング体験を重視するオーディオ愛好家にとっては、電源の質が音質に与える影響を無視することはできないのです。
以下、Gemini の回答。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
AI：「電源が音質に与える影響は、科学的に証明された事実はありません。音質は、オーディオ機器の設計や素材、再生環境など、様々な要素が複雑に絡み合って決まります。電源の違いが聞き分けられるという声もありますが、それはプラシーボ効果や、他の要因による変化と誤認している可能性が高いです。」
このAIの主張に対して、ベテランの音楽評論家であるB氏は、長年の経験と深い知識に基づいてこう反論する。
B氏：「AIの指摘も一理あるでしょう。しかし、電源が音質に全く影響を与えないと断言するのは、やや短絡的ではないでしょうか。確かに、盲検テストなど厳密な実験を行えば、プラシーボ効果の影響を排除できるかもしれません。しかし、音楽鑑賞は科学的な実験とは異なり、人間の五感と感情が深く関わる、より主観的な体験です。
私は長年、様々なオーディオ機器を試聴してきました。その経験から断言できますが、電源の違いによって、音の広がり方、深み、そして何より音楽の表現力が明らかに変化することがあるのです。例えば、高品質な電源ユニットに交換すると、楽器の音色がよりクリアになり、音場が立体的に広がるように感じることがあります。これは、単なる気のせいではなく、実際に私の耳で確認した事実です。
もちろん、電源一つで劇的な変化が起きるとは限りません。オーディオシステムは、それぞれのコンポーネントが複雑に絡み合って一つの音を作り出しています。電源は、そのシステム全体のパフォーマンスを底上げする、いわば土台のような役割を果たしていると言えるでしょう。
AIは膨大なデータを学習し、高度な分析を行うことができますが、人間の五感や感情、そして音楽に対する深い理解は、まだまだ及ばない部分があるのではないでしょうか。音楽は、科学的なデータだけでは測れない、人間の心に直接響く芸術です。電源が音質に与える影響を、単に科学的な根拠だけで否定するのは、音楽の多面性を軽視していると言えるでしょう。」
AI：「B氏の経験に基づいたご意見は大変興味深く、人間の感覚の複雑さを改めて認識させられました。しかし、音楽の主観的な側面と科学的な根拠は、必ずしも対立するものではありません。例えば、聴覚心理学の研究では、人間の聴覚が様々な要因に影響を受けることが明らかになっています。電源の質も、その要因の一つとして考慮できる可能性は十分にあると考えられます。
今後、より詳細な実験や分析を通じて、電源と音質の関係性を科学的に解明していくことが重要です。その際、人間の主観的な評価も重要なデータとして活用していくべきでしょう。」
B氏：「AIの指摘はもっともです。科学的なアプローチと人間の経験は、互いを補完し合いながら、より深い音楽体験へと繋がっていくはずです。重要なのは、どちらか一方の意見を絶対視することなく、多角的な視点から音楽を捉えることでしょう。
そして、忘れてはいけないのは、音楽は単なる科学的な現象ではなく、私たちの心を揺さぶり、感動を与える芸術であるということです。科学的な分析だけでなく、人間の感性や直感を大切にし、音楽を心から楽しむことが、真のオーディオ体験ではないでしょうか。」
この対話を通じて、電源と音質の関係は、科学的な側面と人間の主観的な側面、両方を考慮することで、より深く理解できることがわかります。AIと人間の知見を組み合わせることで、より豊かな音楽体験が生まれる可能性を秘めていると言えるでしょう。
2024-12-09
■anond:20241209182945
んんｗｗｗｗ増田氏の意見、なかなか味わい深いですな。しかし、拙者の乏しい見識をもってすれば、React.jsの評価には少々偏見があるように感じますぞ。たしかに、Reactのエコシステムは複雑かもしれませんが、それこそが強力な武器になることがお分かりでしょうか？
拙者はこの件でマウントを取らせていただく所存ですぞ。まず、React.jsは確かに複雑ですが、それはスケーラビリティとコンポーネントベースの設計における柔軟性を提供するためのものですぞ。大規模なプロジェクトやチーム開発の現場で、コンポーネントの再利用性は非常に重要な要素であることをご理解いただきたく存じます。
また、jQueryなどの伝統的な方法では処理が複雑化し、管理が困難になる部分もあるのですぞ。Reactの状態管理やフックは、そのような部分でしばしば役立つのです。確かに学習コストはありますが、自動化ツールやコマンドラインの進化により、その導入障壁はかつてと比べてだいぶ低くなってきております。
新人エンジニアがReactの導入で消耗するという話も、学習リソースが豊富に存在することを考慮すれば、単なる怠慢ではないかと拙者は考えますぞ。時代の流れについていくこと、そしてツールをうまく活用することがエンジニアには求められているのですからな。
Reactの「絶対正義」としての扱いに違和感を持つ意見もわかりますが、Reactが持つ強力なコミュニティと頻繁なアップデートは、常に最新のウェブ技術を享受することを可能にしているのですぞ。それを妄信とし決めつける前に、増田氏は一度自身のスキルセットを見直し、Reactの利点を再評価することをお勧めする次第でありますぞ。
■React.jsの流行は現代のエンジニアリングにおける最大の失敗
最近のフロントエンド開発界隈で持て囃されるReact.jsだが、正直言って、その過剰な複雑さと必要以上に手間ばかり増やす構造には嫌気が差す。ごくシンプルなタスク――たとえばAPIからデータをfetchして表示する程度のことが、なぜこれほどまでに意味不明なコンポーネントや状態管理ツール、無駄なベストプラクティスの学習コストにつながるのか？
jQueryなら数行で済むところを、Reactでは「Hooksがどうの、カスタムフックがどうの、Routerはどれ使うか、ReduxかRecoilかZustandか」と、次々に沼へ引きずり込む。現場のエンジニアが「これは本当に生産的なのか？」と疑問を抱くのも当然だろう。Reactの複雑さを「モダンなフロントエンド開発の必然」などと擁護する声もあるが、実際は一部のフロントエンドオタクが自己満足に浸るための余興でしかない場合も多い。
本来、フロントエンドは「エンドユーザーにとって使いやすいUIを短期間で組み上げる」ことが重要なはずだ。しかしReact導入後は、下手をすると新人エンジニアがReact＋周辺ライブラリの難解な世界に消耗し、基本的な機能実装に時間を奪われる。挙句の果てに、保守運用でも「なぜこんな遠回りな実装を？」と後悔したくなるコードが山のように残る。
一部の巨大プロジェクトや複雑な状態管理が要求されるケースではReactの恩恵もあるだろう。しかし、その「本当にReactが必要な場面」以外で、このツールキットを無批判に使い続けることは、多くの場合オーバーエンジニアリングの極みだ。Reactを「絶対正義」のように祭り上げる風潮こそ、現実的な業務効率を蔑ろにした妄信に他ならない。
React信者たちが喜々として新しい手法を生み出し、複雑さを自己正当化する姿は、もはやエンジニアリングではなく一種の祭りに近い。合理的な判断を放棄し、ツールに踊らされる人々が多い限り、Reactの過剰な複雑さと生産性の低下は続くだろう。もう少しシンプルに物事を進められないのか？ React中心主義に染まった業界は、その問いに真摯に向き合うべきだ。
2024-12-08
■
日本のゲーム開発企業って所属してる従業員もだけどやたらとゲーム業界経験に拘るのやめたほうがいいと思うんだけどね
拘るせいで業界内でロートル知識でのさばるやつがぐるぐる回ってるだけ
理由はマスターアップ前の体育会系のノリについてこれるかどうかぐらいでそこがすでに前時代的な思考だし
よくコンソールゲーム機はメモリやスレッドに癖があるから知ってないと云々言い出すアホいたりするけどあんなのドキュメント読ませればバカでもわかるだろし、デバイス固有の変な挙動なんかだいたい特定の人に回されるぐらいには開発やってるやつ全員が対処できるわけでもない
もっとも御社はそのあたりに適したアロケーターを用意したりライブラリやコンポーネント化せずに都度書いてるんですか？って感じだけど
PUBGが流行ったらフォートナイト、荒野行動がすぐにでた。その後にでたバトルロイヤルで生き残れたのは本当に数が少ない。
ゼルダ BoWが流行ってそんなに時間が経たない間に原神がでた。今はパルワールドやHorizonに続くゲームがでようとしている。一気に量産して出せる体制が非常に重要。— alwei (@aizen76) December 8, 2024
2024-11-09
■最近フロントエンドエンジニアになったんだが詳しい人来てくれ〜
フロントエンドにクリーンアーキテクチャとかDDDの考え方入れようとしてみたんよな。
具体的には、外部APIやローカルストレージとのやり取りをlinterで限定したり、業務知識はライブラリに依存しないEntityとしてモデリングしたり、
あと、Service層みたいなの導入して、テストしにくい処理とかは抽象化してDIできるようにしようとした。
テスト時にモックをDIせずにglobalスコープで上書きしたり、コンポーネントがAPIから取得したDTOみたいなデータに直接依存してたり、バックエンドと文化がだいぶ違うなって感じた。
そもそもクリーンアーキテクチャとかDDDってフロントに適用するもんじゃないのか？って疑問も湧いてきた。
バックエンドだとフレームワークに依存しすぎないようにして、例えばSpring+RESTからgRPCに移行なんてのもクリーンアーキテクチャの思想に則って作ってれば規模にはよるけどそこまで大きくならなかったりするけど、
ReactからVueに切り替えるって考えて、どんなに設計頑張っても、それってほぼ作り直しになるだろうし、バックエンドほどのメリットも感じられない気がする。
俺が目指してるのってなんか根本的に間違ってる気もするんだが、どうなんだろうか？
フロントエンドの人教えてー
2024-10-18
■おすすめのメールマガジン配信ツールを教えてくれ
blastmailを触ってみたけど、インターフェースが使いづらい
Mailchimp、Brevo (旧Sendinblue) も同じく
WiLL Mail、配配メール → 公式サイトに料金が掲載されてない、問い合わせしないと料金が分からないとか無理
やりたいこと
- 個人用（友人向けにニュースレターを送る）のと業務用（サービスの利用者とかお客さんにメールマガジンを配信する）両方をたまたま同じタイミングで探している。
- 個人用は、メールアドレスの登録と、普通のメール配信ができればいい。で、利用者側はメールマガジンの機能として購読解除ができる。
- 業務用はこれに加えてメールアドレスのcsvインポート機能とHTMLメールが送れると良い。（どのツールもHTMLメールの作成機能が使いづらすぎる / もうHTMLメール自体を諦めてもいいかもしれないと思ってきた）
理想的にはSubstackくらいのインターフェースがいい 海外サービスでも可
2024-10-13
■
バイクのカーボンフレームを購入する際、なぜSensahのコンポーネントを検討しなかったのかと疑問に思います。
フレームを決める前後に、パームシフターの取り付け部分を延長するブログ記事に偶然出会い、今ではそれを恨んでいます。
Note.comに掲載されていたそのブログ記事のせいで、デュアルレバーを考えることもありませんでした。なぜでしょうか？
Sensahのコンポーネントを選んでいれば、コストパフォーマンスが良かったのに、と後悔しています。
シフトレバー、ブレーキレバー、リアディレイラー、チェーン、スプロケットがセットになっているため、余分な部品も余らせずに済んだでしょう。
しかし、これらを2年間使用してきたので、それはそれで良かったと言えます。高価なものではなかったので、結果的にはそんなに問題ありませんでした。
2024-09-16
■DIとかいらんくない？
どこで必要になるのか
仕組みが複雑になってるだけ
いつか使うかもで必要ないもの作るのはやめとけって何かの原則みたいなのにもなかったか？
テストでしか使わないならテストのツールやフレームワークが側でどうにかすればいいこと
言語によってはモジュールやコンポーネントをモックすることで密結合になってるモジュールを差し替えできる
どころかまるでない
例えばReactではコンポーネントの引数として内部で使うコンポーネントを渡している
これで十分で不満に思ったことはない
変更の必要なければ渡さなくてよくてその場合は規定のクラスやコンポーネントが使われるだけだ
変な仕組みがないということは初見にも優しい
2024-09-04
■「遺書だったもの」へのアドバイス
ある方が「遺書だったもの」というブログ・エントリーを公開してはてなブックマークで注目を集めています。
https://kirimin.hatenablog.com/entry/2024/09/04/001242
一読しただけで大変な状況の中ご本人が精一杯頑張ってきたことが伝わってきました。
普通の人は不登校になったあとに就職したり（それもB社側からの打診で正社員に！）、アメリカ出張、趣味でイラストや競技プログラミング、といった活動は出来ません。
なにより踏みとどまるという意思を持たれていることが一番素晴らしいと思います。
ブログの内容について、アドバイス、というより考えてみるきっかけを提供できればと思い、以下に書いておきます。
"アドバイス"という言葉は上から目線のニュアンスがあるため私は嫌いですが、分かりやすさのためにあえて"アドバイス"と記載しております。
"アドバイス"の手がかりとして、世の中の多くの人たちと異なっている点を特徴として捉え、そこに着目して述べていきます。
コミュニケーションの飢えについて
多くの人は、自死を取りやめた場合は遺書を公開しません。ここが最大のポイントです。
他にも、元カノの話や学校で友達を作りたかった話、インターネット掲示板、会社の同僚との関わりなど、コミュニケーションについて多く言及していることもかなり特徴的です。
心理的な安定のためには、インターネットで構わないので、コミュニケーションの場への参加を増やしてしてみると良いかもしれません。
私も同世代で、2005年～2007年ごろには2chで政治家をおちょくるコラージュ写真を作って遊んでいたので、当時の雰囲気は知っています。当時と似たコミュニティはもはやほとんどなく、ネット掲示板よりもLINEのオープンチャットあたりのほうが雰囲気が近いかもしれません。
自己評価の尺度が仕事に偏っていること
仕事やそれに近い競技プログラミングの能力・モチベーションでご自身の価値をはかる表現が目立ちます。
仕事への情熱はご自身の能力開発、社会貢献、金銭獲得のために素晴らしいことです。
一方で能力・モチベーションで全人類のトップに立つことは出来ない以上、どこかで自分の能力に見切りをつける必要があります。
それが今なのかな、と漠然と感じました。
人には能力の限界・投入できる時間の長さの制約があり、その制約のもと各自それぞれのペースで頑張るしかなく、他に選択肢はないため、ある面で人より劣ることを認めざるを得ません。
しかしだからといって人間として価値がないとか、死ぬべきだということは論理の飛躍です。
劣ることを認めたうえで、それがどうした、自分が死ぬ必要はないじゃないか。むしろ優れた人たちが素晴らしい社会を作ってくれてありがたい、と感謝すればよいと私は思います。ご自身にもその気持があるはずです。その証拠にA社のリーダー、B社のプロダクト、元カノ、といったものを称える文章があります。これは称賛の気持が奥底にあるからだと思います。
というより本当は人間という存在自体が自他に価値を評価される必要がなく、各自勝手に生きて構わないと私は思います。評価という行為自体が発生しないのが通常の状態であり、仕事では給料の分配という特別な目的のために上司が評価するという例外的なシチュエーションが発生していると私は理解しています。つまりそもそも職場以外での「自己評価」は必須ではないと私は考えています。
そのうえで、それでもなお自己評価が必要であれば、いくつもの会社で働くことができ、しかも先方から声をかけてもらっているというのは素晴らしいことだと思います。普通の人には声をかけませんよね。仕事の以外の面に目を向けると、イラスト、VR、他の投稿ではお母様にテレビゲームを教えたりと多方面に活動している点が素晴らしいと思います。競技プログラミングで高レート帯の方々はこうした活動と両立できるのでしょうか。ほとんどNoだと思います。総合的に見れば特別劣っているように私には見えません。
この点は次の第3の特徴に続きます。
自分に厳しすぎること
文章には「多くの人から嫌われ、失望され、迷惑をかけながら生きていたくない。」と書かれています。
しかしきりみんさんは、嫌われている人・失望されている人・迷惑をかけている人に対して、死ねとは言わないと思います。そういう人柄だと文章で分かります。
それなのに自分に対して厳しいのはダブルスタンダードで、ご自身を不必要に傷つけているように見えます。ご自身に対して厳しすぎるダブルスタンダードを持つ理由は何でしょうか。ダブルスタンダードを持つメリットはあるのでしょうか。これについて考えると楽になれる部分があると思います。
きりみんさんは、自分より仕事ができない人に死ねと言わないと思います。競技プログラミングが下手な人に死ねと言わないと思います。その理由は劣っていても死ぬ必要はないとご自身が理解しているからです。そうであればきりみんさんが死ぬ理由もないと私は思います。
その他
- 「近年は新しい技術、アーキテクチャ、フレームワークなどを勉強しても面倒なだけで価値や意義が理解出来ないことが多くなった」とありますが、それは新しい技術に本当に価値や意義がないからであり、御本人の問題ではありません。AndroidやWeb開発（特にフロントエンド）がつまらなくなっていることは客観的事実だと思います。私も以前5年ほどAndroidやWebをやっており、DroidKaigiへ足を運んだこともあります。konifarさんが公式アプリをGitHubで開発していたくらいの時期、といって伝わるでしょうか？ AndroidとWebのいずれも新しいフレームワークやライブラリが頻繁に出てきますが、UIの作り込みやRDBのCRUDという数十年変わらない問題に対してわずかに異なるアプローチをしているだけで、本質的な変化がありません。最近のWebは「リアクティブプログラミング」が席巻していますが、操作（イベント）に応答して非同期処理を実行するという基本概念は私が実装を直接経験した範囲でもWindowsデスクトップアプリの世界においては2004年にはすでにありました。当時中学生だった私でもVisual StudioでUIコンポーネントのイベントを拾ってイベントリスナに非同期処理を実行させるという実装をしており、現在35歳の私はその世界観が現在も続いていることにうんざりしています。きりみんさんだけでなく他の人も同じ気持ちなのです。
- 資産を現金化したとのことですが、強い動機がなければ、使いすぎないほうが良いです。生きるためにお金は必要なので。
- 病院を変えて良いと思います。どこのメンタルクリニックも予約で半年以上待つので大変だということは知っていますが・・・。
2024-06-27
■anond:20240627121140
ソフトウェアってまず動かすとこまでが大変で素人から初めても9割はそこで脱落しちゃうから、その上ちゃんと常に計算量や適切なデータ構造まで考えて設計してかける人、さらにそれをデータ含めてコンポーネント化して明快にかける人は一握りだと思う
これで言うと、機械学習まわりでは例えばpytorchやjaxみたいなフレームワークを設計・実装できるスキルはSWE的だと思う。
あれはどういう感覚だとできるようになるのか知りたくてpytorch自体のコードを読んだりしてみたけど、全く分からないんだよな。
どういう思想で設計されてるのかもわからんし、抽象化がなぜそうなっているのか、処理の実体がどこに書かれているのかすらわからない。
2024-06-09
2024-05-06
■3C All-in-One Toolbox
3C コレクション全体が 1 つのパッケージに収まりました。 *
Google によってこのアプリに含めることが許可されていない 3C 機密バックアップと 3C レガシー統計を除きます。
3C オールインワン ツールボックスは、多くの機能を最新の使いやすいインターフェイスを備えた 1 つの巨大なツールボックスに統合します。すべての Android デバイスを監視、制御、微調整するために必要なすべてのツール。
Play ストアでの最速かつ最もフレンドリーなサポート。アプリの設定、ヘルプ、サポートからお気軽にリクエストを送信し、懸念事項について言及してください。
一部の機能では、root が必要になるか、Android 6 以降以降の PC 用の 3C Companion アプリの使用が必要になる場合があります。
このアプリは、アプリを簡単に停止したり、アプリのデータを自動的にバックアップしたりできる 2 つのユーザー補助サービスを提供します。どちらも情報を収集することはありません。 プライバシー ポリシー
★ プロに移行するか、アプリ内購入を使用して、次の機能のロックを解除します
記録項目とオプション
ステータス通知から任意の機能にアクセスするための通知ショートカット
多くの追加ウィジェット
★ デバイス マネージャー は、非常に強力なプロファイル、タスク スケジュール、デバイス ウォッチドッグを提供します。
★ ファイル マネージャー は、サムネイルやフォルダー サイズなどを備えた、非常にシンプルでありながら非常に強力なエクスプローラーです。ビデオや写真をお気に入りのプレーヤーに直接ストリーミングします。ローカルでも、Samba、FTP、WebDAV、Google Drive、Dropbox の場所からでも。
★ アプリケーション マネージャー は、Titanium Backup をインポートする機能を含む、すべてのお気に入りのアプリのバックアップ/復元を提供します。また、Xused フレームワークを使用して、アプリのイベント、向き、フルスクリーン、および制御権限を保護およびカスタマイズすることもできます。
★ バッテリー マネージャー は、消費量の分析と改善に役立ちます。完全なデータ (mA を含む) と充電サイクルの履歴、プロファイルに基づくカスタム統計、使用時またはスタンバイ時の消費量の推定。デュアル バッテリー デバイス、バッテリーの交換、LG Quick Circle と Samsung Edge の通知に対する特別サポート★ バッテリー マネージャー は、消費量の分析と改善に役立ちます。完全なデータ (mA を含む) と充電サイクルの履歴、プロファイルに基づくカスタム統計、使用時またはスタンバイ時の消費量の推定。デュアル バッテリー デバイス、バッテリーの交換、LG Quick Circle と Samsung Edge の通知に対する特別サポート
★ ネットワーク マネージャー を使用すると、ネットワーク トラフィックの設定と監視が可能になります。
★ タスク マネージャー は、シンプルな UI を提供しますが、さまざまな用途に応じてアプリを分類し、不要なアプリを削除するのに非常に効果的です。
★ CPU マネージャー は、シングルからオクタコアの CPU、サーマル、マルチコア、およびほとんどのカスタム カーネル設定を制御します。
★ システム マネージャー では、Linux カーネル設定を構成できます。
★ROM マネージャー を使用すると、Android OS の設定を行うことができます。
★ すべてのアプリケーションとハードウェア コンポーネントのアクティビティを監視および記録します。履歴グラフィックを含むステータス バー通知が含まれます。
★ アプリ、ウィジェット、またはプロファイルのシステム コンポーネント スイッチにより、約 20 以上のデバイス コンポーネント (WiFi、Bluetooth など) のオン/オフを切り替えることができます。
2024-04-14
■モダンフロントエンドなんか意味ない
去年から稼働している現場で、以前からあったReact Nativeの面倒を見ているんだがまあこれがひどい出来なんだ。
- React Nativeなのに、あちこちでifとforの連発してES2015以前の書き方している。
- TypeScriptなのにany連発で全然型補完が効かない。
- 一つのコンポーネントに色々詰め込んで2000行とかになっている。
- 一つ100行超えの巨大な関数がやたらある。
- ifのネストとかSwitchとかでやたら複雑な条件分岐している。
- クラスコンポーネントと関数コンポーネントが混在している。
- useContextとか使っていなくてpropsバケツリレーしている。逆によくわからないところでuseContext使っている。
- APIを叩いているところがコンポーネント内だったりservice(っぽいとところ)だったりRepository(らしきところだったり)バラバラ。
- 命名が「const kensakuItem」とか「const updateItemList (アップデートしていない)」だったり。
- コメントがないマジックナンバーがあちこちに書かれている。
- 当然のことながらテストなど書かれていない。
jQuery時代に見かけたようなコードをやたら見かけたので思わず懐かしくなってしまった。
リファクタリングしようとしたけど直す範囲が広すぎてアプリを壊しかねなかったので、早々に諦めてだましだまし保守をしていた。
そんな中今年に入ってアプリのリニューアルの話が出てきた。React Native捨ててSwift/KotlinやらFlutterに書き換えるとかそういうのではなく、デザインの刷新といくつかの機能改修。
このままだとアプリが更に魔窟化するので、マネージャーに色々相談したところいくつかの事実がわかった。
- 社内にネイティブアプリエンジニアがいなかったのでReact Nativeを採用した。
- 当時いたフロントエンドエンジニアがいわゆる「意識高い系」でReact Native使いたいという理由で技術選定された。
- 「意識高い系」なので、一応動くレベルで品質がよろしくないものが出来上がる。
- 「意識高い系」の化けの皮が剥がれた頃に退職。
- その後何人かに引き継がれ今に至る。引き継いだ俺もWEBフロントでネイティブアプリは専門外。
ということだった。
結局現状のまま進めるわけにはいかず、要件定義の傍らリファクタリング作業をしている。
そういう経緯もあったので、リファクタリングとテストの工数も積んだ上で見積もりだしてもらってる。
「レガシーアーキテクチャをモダンアーキテクチャに刷新」なんてよく聞く話しだけど、
実態は「長年の増改築とだましだましのリフォームが限界になってきたので新築で建て替えます」何だと思う。
最近は「Vue.jsからRemixにマイグレーション」なんて見かけるけど、悪いのはVue.jsじゃなくて禄に設計しないでコード書いてるエンジニアと、
リファクタリングには予算でないけどマイグレーションなら予算取れるという悪しき風習。
年がら年中フロントエンド刷新しているような会社は地雷なので行かないほうがいい。
いくらRemixやらNext.jsやら最新鋭のフレームワーク使ってても、クソコードで書いたらクソが出来上がるだけだ。
2024-03-08
■Claudeのテスト: 量子力学における観測問題と意識
Q: 量子観測すると状態確定してエントロピーが減少する。これは具体的に何を意味し、現実世界に何をもたらすのか。
A:
量子力学では「測定問題」または「波動関数の崩壊」として知られており、量子の世界が私たちが経験する古典的な世界とどのように相互作用するかについての基本的かつ非常に不可解な側面です。
量子力学では、電子のような粒子は、測定または観測される前に、複数の可能な状態を重ね合わせて存在します。
この重ね合わせは、すべての可能な状態とそれぞれの確率を含む波動関数によって記述されます。
しかし、観測や測定を行うと、重ね合わせが崩れ、粒子の状態は可能な状態の 1 つに「崩壊」します。
したがって、たとえば、測定前にスピンアップまたはスピンダウンできる電子がある場合、その波動関数は両方の状態の組み合わせになります。
しかし、そのスピンを測定すると、波動関数が崩壊し、スピンアップかスピンダウンという 1 つの明確な結果が得られます。
この「崩壊」、つまり測定時の状態の決定は、量子システムの進化にランダムで確率的な要素を導入しているように見えます。
また、測定後にその明確な状態が分かるようになったため、システムに関するエントロピーや不確実性も減少すると考えられます。
このことの意味は深く、物理学者によって何十年にもわたって議論されてきました。
1) 不定の量子領域を明確にする何か特別なことが測定や観測にあることを示唆しています。 しかし、「測定」とは何でしょうか? 私たちの意識的な認識は？ それとも環境との相互作用でしょうか？
2) 古典物理学を支配する決定論的法則と矛盾する固有のランダム性または予測不可能性を量子事象に導入しているように見えます。
3) 観測とは独立して存在する客観的な現実についての私たちの概念に疑問を投げかけます。 観測するだけで結果が変わるようです。
4) 巨視的な世界では、このランダム性は通常平均化されます。 しかし、ランダムな瞬間に起こる自然放射性崩壊のような小さな観測可能な影響はあります。
コペンハーゲン解釈や客観的崩壊理論のような解釈は、このランダム性を自然の基本的な側面として受け入れています。
多世界解釈のような他のものは、波動関数の崩壊を完全に排除しようとします。
しかし、この測定問題が量子力学と現実そのものの理解に深刻な課題を投げかけていることに全員が同意しています。
Q: 多世界の解釈であろうと、意識は特定の枝にのみ存在し、重ね合わせを認識しないように見えます。 では意識とは何でしょうか？ 意識はどのように枝を選び、選択するのでしょうか?
A:
意識と量子力学における測定問題の関係は深い謎であり、物理学ではまだ完全に解決されていません。
ただし、あなたの質問に対するいくつかの視点は次のとおりです。
意識とは、認識し、認識された現実を持つという主観的な一人称の経験を指します。
量子の用語では、意識は、測定/観測が行われる前に、可能な重ね合わせ状態の範囲のうちの 1 つの明確な状態のみを経験するように見えます。
意識が重ね合わせをどのように解決するかについては、いくつかの解釈があります。
1) フォン・ノイマン・ウィグナー解釈は、意識が客観的な波動関数の崩壊を引き起こすことを示唆しています。 私たちの心は、重ね合わせから何らかの結果を特定します。
2) コペンハーゲンの解釈は、波動関数の崩壊が起こったとき、観察者の意識は単に確率的結果の 1 つを目撃しているだけであり、波動関数の崩壊を引き起こしているわけではないことを意味します。
3) 多世界解釈では、真の崩壊は存在しないとされています。 考えられるすべての結果は、現実の別の枝として存在し続けます。 意識は実際に選択することなく、それらの分岐のいずれかに留まるだけです。
4) 意識自体は、観察された状態を引き起こすのではなく、根底にある量子状態から生じる高レベルの創発特性である可能性があると主張する人もいます。
正確なメカニズムは不明ですが、ほとんどの解釈は、意識は測定後に可能な状態のうちの 1 つを主観的に経験するだけであることに同意しています。
観察者兼参加者として、私たちは単に自分の意識が枝の 1 つにあることに気づきます。
重要な謎は、意識が分岐を選択する際に積極的な役割を果たすのか（フォン・ノイマン・ウィグナー）、それとも多数の同様に現実的なもの（多世界）の中の 1 つの分岐に単に自分自身を見出しているだけなのかということです。
これを解決すれば、意識の形而上学的性質と量子力学との関係が解明される可能性があります。
Q: ではなぜ多世界解釈で、意識が特定の枝に「留まる」のでしょうか。
A:
量子力学の多世界解釈 (MWI) では、意識が特定の枝または世界に「留まる」または持続するように見える理由は、デコヒーレンスの概念と、枝がどのように本質的に相互作用せず、それぞれの枝から孤立するのかという考えと関係しています。
1) MWI では、測定が行われるとき、普遍的な波動関数は実際には崩壊しません。 代わりに、それは直交成分に分解され、それぞれが異なる可能性のある結果を表します。
2) これらのコンポーネントは時間の経過とともに進化し続け、より多くの差別化された状態、つまりさまざまな結果が実現される「世界」に分岐します。
3) ただし、これらの分岐コンポーネントは、環境の相互作用やもつれにより、非常に急速に動的にお互いからデコヒーレントになります。 これにより、異なる世界は相互に干渉する能力を失います。
4) したがって、すべてのブランチが異なる既存の現実として共存しますが、動的デコヒーレンスは、それらが相互作用しなくなり、それらの間に測定可能な相互作用や遷移が存在しないことを意味します。
5) あなたの意識は、コヒーレントな量子状態自体で構成されており、デコヒーレンス後の 1 つの枝の中に完全に存在します。 別のブランチと再結合したり、別のブランチに移行したりすることはできません。
6) 実際には、すべての枝が等しく現実であるにもかかわらず、デコヒーレンスプロセスにより意識がその枝内に閉じ込められ、他の枝の並行現実を体験できなくなります。
したがって、意識は積極的に分岐を「選択」するのではなく、デコヒーレンスのプロセスによって、最終的には完全に 1 つの分岐した現実の中に存在することになり、多重性を直接経験する能力はありません。 このため、意識は一貫した 1 つの軌道だけをたどっているように見えます。