  |
はてなキーワード: アプリケーションとは
画面上でできなくしてもサーバーに直接リクエスト送ってくるからって同じことをサーバーでも実装しないといけなくてすごくめんどくさい
言語同じかつ単純な規則な共通化できたりするけど実際はそうじゃないものが多いし
画面での操作禁止とそれらを無視して編集後のデータだけ送ってくるのだとチェックの仕方も違う
追加できないなら追加ボタン出さないだけで済むが、サーバー側だと送られてきた件数だけじゃなくてもともとあったものと一致してるかもチェックが必要とかそういうの
ウェブのほうが楽だからデスクトップアプリからウェブに移すがここ数年は多かったが本当に楽か？って思う
画面の柔軟性はあるが、そのせいであれこれ細かい注文がついたりしてそれも面倒が増える原因だし
ウェブだとそれが当たり前だからってサーバー側もデータのチェックしてるけどデスクトップアプリじゃそんなことしてなかった
それのリプレースなんだし、別にしなくていいんじゃないかと思う
デスクトップアプリだってサーバーと通信してるんだから直接リクエスト投げれるわけだし
ウェブなら便利な開発者ツールがあるから今送ったものの中身を見てちょっとか書き換えて送るが楽なだけ
デスクトップアプリだってパケットキャプチャしたり、逆コンパイルしてソースコード見ればできるわけだし
クライアント証明書があるから～とかいう意見聞いたことあるけど、ローカルにあるファイルなんだから、直リクエストするときだってそれ使えるよね
デスクトップアプリだと起動後のホーム画面から順番にボタンを押さないと画面を開けない
だから一覧画面で編集ボタンを出さなければその項目の編集画面は開けない
そのせいで一覧画面で編集ボタンを出さないのに加えて編集画面で自分が編集可能かのチェックまで必要になる
めんどくさい
考えてみればURLで直接開けることは要件にあるわけじゃないんだし、URLにマッピングしないメモリ内でのルーティングでもいい気はする
リロードすれば毎回トップページに戻るけど普段使う上でリロードなんかしないし別に問題ないと思う
Q.
1つのCPUコアでの逐次処理を高速化することには限界があるため、コア数を増やし並列化させることで性能を向上させる必要がある、という考え方について、市販のサーバコンピュータとスーパーコンピュータで違いはありますか？
A.
この考え方に関して、市販のサーバコンピュータとスーパーコンピュータの間には基本的な違いはありません。両者とも、シングルコアの性能向上に限界がある中で、並列化によって全体的な処理能力を高めるという方向性を共有しています。しかし、その実現方法や規模には大きな違いがあります。 サーバコンピュータとスーパーコンピュータの並列化アプローチの比較 1. 並列化の規模 サーバコンピュータ: 数個から数百個のコアを使用 スーパーコンピュータ: 数万から数百万個のコアを使用 2. 並列化の方法 サーバコンピュータ: 主にSMP（対称型マルチプロセッシング）やNUMA（非一様メモリアクセス）アーキテクチャを採用 比較的少数のプロセッサを密結合 スーパーコンピュータ: 大規模な分散メモリシステムを採用 多数のノードを高速ネットワークで接続 3. 相互接続技術 サーバコンピュータ: 一般的なネットワーク技術（イーサネットなど）を使用 スーパーコンピュータ: 専用の高速相互接続技術（InfiniBand、Tofu Interconnectなど）を使用 4. ソフトウェアとプログラミングモデル サーバコンピュータ: OpenMPやpthreadsなど、比較的シンプルな並列プログラミングモデルを使用 スーパーコンピュータ: MPIなどの複雑な分散メモリプログラミングモデルを使用 ハイブリッド並列化（MPI+OpenMP）などの高度な技術も適用 5. スケーラビリティ サーバコンピュータ: 中規模までの並列化に適しているが、大規模になるとスケーラビリティに課題 スーパーコンピュータ: 極めて大規模な並列化に対応できるよう設計されている 6. 用途 サーバコンピュータ: ウェブサービス、データベース、ビジネスアプリケーションなど、比較的汎用的な用途 スーパーコンピュータ: 気象予報、宇宙物理学シミュレーション、分子動力学計算など、極めて計算負荷の高い科学技術計算
これはおそらく3つの中で最も簡単な方法だ。現在のChatGPTは、基本的に、テキストを入力できる孤立した箱の中に座っている人間のようなものだ。初期のアンホブリング改良では、個々の孤立したツールの使い方をモデルに教えていましたが、マルチモーダルモデルでは、近いうちにこれを一挙にできるようになると期待しています。
つまり、Zoomでの通話に参加したり、オンラインで調べ物をしたり、メッセージや電子メールを送ったり、共有されたドキュメントを読んだり、アプリや開発ツールを使ったりといったことだ。(もちろん、より長いホライゾン・ループでモデルがこれを最大限に活用するためには、テスト時間のコンピューティングをアンロックする必要がある。)
最終的には、ドロップイン・リモートワーカーのようなものができると期待している。エージェントは、あなたの会社に入社し、新しい人間の雇用のようにオンボードされ、Slackであなたや同僚にメッセージを送り、あなたのソフトウェアを使用し、プルリクエストを行い、大きなプロジェクトがあれば、人間が独立してプロジェクトを完了するために数週間留守にするのと同等のことができる。これを実現するためには、GPT-4よりもいくらか優れたベースモデルが必要だろうが、おそらくそれほどでもないだろう。
https://situational-awareness.ai/wp-content/uploads/2024/06/devin.gif
Devinは、完全に自動化されたソフトウェア・エンジニアを作るために、モデル上の「エージェンシー・オーバーハング」／「テストタイム・コンピューティング・オーバハング」を解除する初期のプロトタイプだ。Devinが実際にどの程度機能するかはわからないし、このデモは、適切なチャットボット→エージェントのアンホブリングがもたらすものに比べれば、まだ非常に限定的なものだが、近々登場するもののティーザーとしては役に立つだろう。
ところで、私は、アンホブリングの中心性が、商業的応用という点で、少々興味深い「ソニックブーム」効果につながると期待している。現在とドロップイン・リモートワーカーの中間モデルは、ワークフローを変更し、統合して経済的価値を引き出すためのインフラを構築するために、膨大な手間を必要とする。ドロップイン・リモートワーカーは、統合が劇的に簡単になる。つまり、リモートでできるすべての仕事を自動化するために、ドロップインするだけでいいのだ。つまり、ドロップイン・リモートワーカーが多くの仕事を自動化できるようになる頃には、中間モデルはまだ完全に活用され統合されていないため、生み出される経済価値のジャンプはやや不連続になる可能性がある。
https://situational-awareness.ai/wp-content/uploads/2024/06/overview_ooms_gpt2togpt4.png
https://situational-awareness.ai/wp-content/uploads/2024/06/overview_ooms_2023to2027.png
数字をまとめると、GPT-4に続く4年間で、2027年末までにGPT-2からGPT-4規模のジャンプが再び起こると（おおよそ）予想される。
GPT-4のトレーニングに3ヶ月かかったとしよう。2027年には、一流のAIラボはGPT-4レベルのモデルを1分で訓練できるようになるだろう。OOMの効果的なコンピュート・スケールアップは劇的なものになるだろう。
それは我々をどこへ連れて行くのだろうか？
https://situational-awareness.ai/wp-content/uploads/2024/06/overview_counting_the_ooms.png
GPT-2からGPT-4までで、私たちは～未就学児から～賢い高校生になった。とんでもないジャンプだ。もしこれが、私たちが今一度カバーする知能の差だとしたら、それは私たちをどこに連れて行くのだろうか？私たちは、それが私たちをとてもとても遠くに連れていっても驚かないはずだ。おそらく、ある分野の博士や最高の専門家を凌駕するようなモデルまで到達するだろう。
(このことを考える1つの良い方法は、現在のAIの進歩の傾向は、子供の成長のおよそ3倍のペースで進んでいるということだ。あなたの3倍速の子どもは高校を卒業したばかりだが、いつの間にかあなたの仕事を奪っていくだろう！)
続き I.GPT-4からAGIへ：OOMを数える(10) https://anond.hatelabo.jp/20240605211837
最後に、定量化するのが最も難しいが、それに劣らず重要な改善のカテゴリーを紹介しよう。
難しい数学の問題を解くように言われたとき、頭に浮かんだことを即座に答えなければならないとしたらどうだろう。最も単純な問題を除いて、苦労するのは明らかだろう。しかしつい最近まで、LLMにはそうやって数学の問題を解かせていた。その代わり、私たちのほとんどはスクラッチパッドで段階的に問題を解いていき、その方法ではるかに難しい問題を解くことができる。「思考の連鎖」プロンプトは、LLMのそれを解き放った。生の能力は優れているにもかかわらず、明らかな足かせがあるため、LLMは数学が苦手なのだ。
私たちはここ数年で、モデルの「足かせを外す」ことに大きな進歩を遂げました。これは単に優れたベースモデルをトレーニングするだけでなく、アルゴリズムの改良によってモデルの能力を引き出すものです：
足場作り。CoT++について考えてみよう：ただ問題を解くようモデルに求めるのではなく、あるモデルに攻撃計画を立てさせ、別のモデルに可能性のある解決策をたくさん提案させ、別のモデルにそれを批評させる、といった具合だ。例えば、HumanEval（コーディング問題）では、単純な足場作りによってGPT-3.5が足場なしのGPT-4を上回った。SWE-Bench（実世界のソフトウェアエンジニアリングのタスクを解くベンチマーク）では、GPT-4は~2%しか正しく解くことができませんが、Devinのエージェントの足場があれば14-23%に跳ね上がります。(後ほど詳しく説明するが、エージェントのアンロックはまだ初期段階に過ぎない。)
ツール：もし人間が電卓やコンピュータを使うことを許されなかったらと想像してみてほしい。まだ始まったばかりだが、ChatGPTはウェブブラウザを使ったり、コードを実行したりできるようになった。
エポックAIによる研究によると足場作りやツールの使用など、これらのテクニックのいくつかを調査したところ、このようなテクニックは多くのベンチマークで通常5～30倍の効果的な計算量の向上をもたらすことがわかった。METR（モデルを評価する組織）も同様に、同じGPT-4ベースモデルからのアンホブリングによって、エージェントタスクのセットで非常に大きなパフォーマンスの向上を発見しました。
https://situational-awareness.ai/wp-content/uploads/2024/06/metr_gains_over_time-1024x597.png
これらをコンピュートとアルゴリズムの効率で統一した実効的なコンピュート規模に当てはめることは困難ですが、少なくともコンピュート規模の拡大やアルゴリズムの効率とほぼ同規模の大きな進歩であることは明らかです。(また、アルゴリズムの進歩が中心的な役割を担っていることも浮き彫りになっています。0.5OOM/年の計算効率は、すでに重要なものではありますが、ストーリーの一部に過ぎません。）
「アンホブリング」こそが、実際にこれらのモデルが有用になることを可能にしたのであり、今日多くの商業アプリケーションの足かせとなっているものの多くは、この種のさらなる「アンホブリング」の必要性であると私は主張したい。実際、今日のモデルはまだ信じられないほど足かせが多い！例えば
ここでの可能性は非常に大きく、私たちはここで急速に低空飛行の果実を摘んでいる。これは非常に重要です。"GPT-6 ChatGPT "を想像するだけでは完全に間違っています。 GPT-6＋RLHFと比べれば、進歩は段違いだ。2027年までには、チャットボットというより、エージェントのような、同僚のようなものが登場するだろう。
続き I.GPT-4からAGIへ：OOMを数える(8) https://anond.hatelabo.jp/20240605210232
コンピュートへの大規模な投資が注目される一方で、アルゴリズムの進歩も同様に重要な進歩の原動力であると思われる（そして、これまで劇的に過小評価されてきた）。
アルゴリズムの進歩がどれほど大きな意味を持つかを理解するために、MATHベンチマーク（高校生の競技用数学）において、わずか2年間で～50%の精度を達成するために必要な価格が下がったことを示す次の図を考えてみてください。(比較のために、数学が特に好きではないコンピュータサイエンスの博士課程の学生が40%のスコアを出したので、これはすでにかなり良いことです)。推論効率は2年足らずで3OOMs-1,000倍近く向上した。
https://situational-awareness.ai/wp-content/uploads/2024/06/math_inference_cost-1024x819.png
これは推論効率だけの数字だが（公開データから推論するのが難しいトレーニング効率の向上と一致するかどうかはわからない）、アルゴリズムの進歩は非常に大きく、また実際に起こっている。
この記事では、アルゴリズムの進歩を2種類に分けて説明します。まず、「パラダイム内」でのアルゴリズムの改良を取り上げることにしま す。例えば、より優れたアルゴリズムによって、同じパフォーマンスを達成しながら、トレーニングの計算量を10倍減らすことができるかもしれません。その結果、有効計算量は10倍（1OOM）になります。(後ほど「アンホブリング」を取り上げますが、これはベースモデルの能力を解き放つ「パラダイム拡張/アプリケーション拡張」的なアルゴリズムの進歩と考えることができます)。
一歩下がって長期的な傾向を見ると、私たちはかなり一貫した割合で新しいアルゴリズムの改良を発見しているようです。しかし、長期的なトレンドラインは予測可能であり、グラフ上の直線である。トレンドラインを信じよう。
アルゴリズム研究がほとんど公開されており、10年前にさかのぼるデータがある）ImageNetでは、2012年から2021年までの9年間で、計算効率が一貫して約0.5OOM/年向上しています。
アルゴリズムの進歩を測定することができます。同じ性能のモデルを訓練するために必要な計算量は、2012年と比較して2021年にはどれくらい少なくなっているのでしょうか？その結果、アルゴリズムの効率は年間0.5 OOMs/年程度向上していることがわかります。出典Erdil and Besiroglu 2022.
これは非常に大きなことです。つまり、4年後には、～100倍少ない計算量で同じ性能を達成できるということです（同時に、同じ計算量ではるかに高い性能も達成できます！）。
残念ながら、研究室はこれに関する内部データを公表していないため、過去4年間のフロンティアLLMのアルゴリズムの進歩を測定することは難しい。EpochAIは、言語モデリングに関するImageNetの結果を再現した新しい研究を行っており、2012年から2023年までのLLMのアルゴリズム効率のトレンドは、同様に～0.5OOM/年であると推定しています。(しかし、これはエラーバーが広く、また、主要なラボがアルゴリズム効率の公表を停止しているため、最近の上昇を捕捉していません）。
https://situational-awareness.ai/wp-content/uploads/2024/06/llm_efficiency_epoch-1-1024x711.png
Epoch AIによる言語モデリングにおけるアルゴリズム効率の推定。この試算によると、私たちは8年間で～4OOMの効率向上を達成したことになります。
より直接的に過去4年間を見ると、GPT-2からGPT-3は基本的に単純なスケールアップでした（論文によると）が、GPT-3以降、公に知られ、公に干渉可能な多くの利益がありました：
最近リリースされたGemini 1.5 Flashは、"GPT-3.75レベル "とGPT-4レベルの間の性能を提供する一方で、オリジナルのGPT-4よりも85倍/57倍（入力/出力）安い（驚異的な利益！）。
公開されている情報を総合すると、GPT-2からGPT-4へのジャンプには、1-2 OOMのアルゴリズム効率向上が含まれていたことになります。
https://situational-awareness.ai/wp-content/uploads/2024/06/stacked_compute_algos-1024x866.png
GPT-4に続く4年間はこの傾向が続くと予想され、2027年までに平均0.5OOMs/年の計算効率、つまりGPT-4と比較して～2OOMsの向上が見込まれます。計算効率の向上は、低空飛行の果実を摘み取るようになるにつれて難しくなる一方、新たなアルゴリズムの改良を見出すためのAIラボの資金と人材への投資は急速に増加しています。 (少なくとも、公開されている推論コストの効率化は、まったく減速していないようだ)。ハイエンドでは、より根本的な、トランスフォーマーのようなブレークスルーが起こり、さらに大きな利益が得られる可能性さえある。
これらをまとめると、2027年末までには（GPT-4と比較して）1～3OOMのアルゴリズム効率向上が期待できることになります。
続き I.GPT-4からAGIへ：OOMを数える(6) https://anond.hatelabo.jp/20240605205754
私はただの会社員で、栄養の関わる知識はネットに転がっている程度しかありません。
この献立表は作り置き用です。
日曜日にまとめて買い物→調理→冷蔵・冷凍するためのプロセスです。
本当に申し訳ないんですが、購入してからすぐにカッターで本を解体してスキャンしてPDF化します。（スキャン後はマスキングテープでくっつけて本棚に入れてあります）
PDF化する理由は、献立を組み上げる作業は全てPC上で行っていきますが、PDFの方が本よりもレシピを探しやすいというのが1番の理由です。
また、最後はレシピ1つ1つを画像ファイルにするので、一旦PDFにしておいた方がその作業が楽になるという理由もあります。
スキャン環境が無い場合は、タブレットやスマホを使用してレシピの内容まできちんと読める状態の解像度で撮影し、画像ファイルタイトルに頁数を振っておくといいです。
1つずつレシピを読み込んで表計算アプリケーションに情報を書き出します。
PC上で計画・管理、スマホ上で閲覧出来るのが理想なので、私はMicrosoftのオンラインExcel（無料版）を使用しています。
｜【料理タイトル】｜【ジャンル】｜【調理方法】｜【冷凍可否】｜【PDF頁】｜
上記の順番でセルに入力していきます。次から詳細を掘り下げます。
△：野菜なしでタンパク質のみ 例）鶏のてりやきからしマヨソース
緑：鶏肉
茶：牛肉
黄：たまご
青：魚
薄橙：大豆
使用されている調味料を元にジャンルを記入、セルの色付けをします。
色付けの凡例は次の通りです。
水色：お酢（さっぱり系）
9割は振り分けられますが以下のように振り分けが難しい料理もあります。
→オリーブオイルとしょうゆを使ってるけどどちらかといえば洋食かな～→薄緑
レンジ調理、フライパン調理、鍋調理、トースター調理等を記入します。
山本ゆりさんの一部のレシピ本には冷凍の可否が書かれていますが、冷凍NGの食材が使用していなければ自己責任でOK認定にしています。
→豆腐、じゃがいも、卵、きゅうり、レタス、水菜、アボカド、ちくわ等
この後に情報を入れ替える作業があるので、どのレシピがどこに掲載されているかを把握しておくために頁数を記入します。
https://f.hatena.ne.jp/lyri/20240522143436
※「翌日」は「翌日に食べないとだめ」、要するに「冷凍不可」を意味します。
※余談ですが、料理タイトルをグレーアウトしているのは新しい本において調理の未済管理のために私が作ってみたレシピに施しているだけです。左側の★は子供が美味しい連発したレシピです。△は子供の苦手食材、苦手調理方法を含んでいるレシピです。
現在は書き込んだ頁順にレシピが並んでいると思われますが、これらをタンパク質順にソートします。
https://f.hatena.ne.jp/lyri/20240523101436
こうすることで「鶏が足りない！」 「ここに豚が欲しい！」 「トマト系のレシピ無いかな～」 「レンジ調理できる副菜ないかな～」等、検討時のレシピの検索が非常に便利になります。また、PDF頁数も一緒に移動することで索引機能を果たします。
例）
主菜A：◎肉入り野菜炒め（玉ねぎ・にんじん・キャベツ）→主菜に野菜たっぷり入ってるな～「○かぼちゃの煮物」を添えとくか
主菜B：○ぶり大根（大根）→大根だけか～緑もないし「◎なすとピーマンの甘辛味噌」にしよう
どうしても「○主菜＋○副菜」となる場合は【我が家の毎日食べても飽きない野菜】を味噌汁の具やサラダにしています。
キャベツ、大根、トマト、ピーマン、ごぼう、にんじん、かぼちゃ、ブロッコリー、おくら、わかめなど。もっと増やしたい。
これらの味噌汁とサラダは応急処置なので、わざわざ表には書いていません。
現在は子供が少食なので主菜と副菜のみにしていますが、もう少し大きくなったら味噌汁とサラダもレギュラー入りさせたいし、その時は味噌汁ルーティーンも組み込んでいきたいです。
（後で見本を載せていますが、現在は子供のストライクゾーンが和食に多いので偏りがちです。成長に伴って変革していきたいです）
理由は調理のモチベーションを保つため、1品目をレンジ調理している間に2品目の材料を切ったり下ごしらえをしたり出来るので時短になるため、レンジ調理したものはそのまま粗熱を取って冷蔵庫や冷凍庫に入れてしまうので、フライパンや鍋を洗う回数や手間を減らせるからです。
毎日作る時間が確保できるのであれば、フライパン調理のみで構成しても良いと思います。私も本当はそうしたいです。
火：主菜２ 副菜Ａ（冷蔵保存） ←副菜は原則2日間で食べきります
金：主菜５ 副菜Ｂ（冷凍保存） ←副菜は原則2日間で食べきります
冷蔵：主菜１ 主菜２ 副菜Ａ ←冷凍NG食材を含んでいてもOK
私は作り置きよりも作りたてのおかずを食べたい派です。なので、水曜日だけは子供が好きで野菜もたくさん食べられて比較的調理時間が短くて手間がかからないなおかずを組み込んでいます。親子丼、ピラフ、グラタン（ほぼシチュー）、オムライス、焼きそば、パスタ等です。
ただし、山本ゆりさんのレシピ（特にレンチンするやつ）は一旦冷まして味が浸透してから再度加熱して食べるとめっっっっっっっっっちゃくちゃ美味しいので、作り置きに向いているものが多いとも感じています。
冷凍したおかずの解凍方法は、食べる瞬間の24時間前頃から冷蔵庫に入れておくと自然解凍されます。
私は前日の夕食後に冷凍庫から冷蔵庫へ移動しています。そうすると冷蔵したものと同程度の加熱時間で食べられます。
ちなみに水曜の主菜３は使用するお肉や魚だけ日曜の買い物直後に冷凍して、火曜の夜に冷蔵庫に移動して自然解凍された状態で調理します。
https://f.hatena.ne.jp/lyri/20240523103013
水曜日のセルが黄色なのは、私が献立を考える際に「ここは固定！」とわかりやすくするために塗った名残なので特に意味はありません。
タンパク質、野菜数、ジャンル、調理方法のバランスが割と整っているのではないでしょうか。
完璧に組み立てるのは正直かなり難しいです。
例えば上画像の5週目の木曜と金曜は○と△で構成されてしまっているので、更に味噌汁を追加するか、もしくはバターしょうゆの味付けとスナップえんどうに合いそうな野菜（いんげんとかアスパラ？）を追加したいところです。味噌汁を新たに作る方が簡単で食卓の見栄えは良いです。
これらは更に小さいセルで管理すると見える化でき、ジャンルや野菜のばらつきをチェックできます。
入れ替えの際はこちらの更新も必要で面倒ですが、やっておくと新たなレシピを組み込む際に非常に明快になります。
https://f.hatena.ne.jp/lyri/20240522151313
入れ替えが発生する要因として1番多かったのは、ジャンルの偏りと野菜の偏りです。
中華系ばっかりで胃もたれやばいな！とか1週間ずっとブロッコリーとキャベツ食ってるな！等です。
散らすと飽きが来なくて良いです。
カレーやシチューは1ヶ月に1回にする等、何かを固定すると組み立てやすかったです。
また魚のレシピが少なくなりがちなので、まずは魚を設置してみるといいかもしれません。
主菜も副菜も夜に食べきってしまうのではなく、基本的に翌日の朝食とお弁当でも食べています。
金曜の主菜５は翌週月曜日の朝食とお弁当にするので、金曜分と月曜分に小分けにして冷凍すると尚良いです。
私は面倒なので金曜分をまるごと解凍して夕食に出し、その後粗熱を取って再冷凍しています。（あんま良くない？）
献立表を組み終わったらレシピのPDFから画像ファイル（PNGやJPEG等）を作成して、Googleドライブのようなクラウドストレージに格納します。
PDFを画像ファイルに変換するアプリケーションを使用したり、私はScreenpressoを使用して切り取っています。
https://f.hatena.ne.jp/lyri/20240523114245
これは4周目のフォルダです。1ファイル700KBくらいでした。サイズは600×600くらい。
文字が読める程度の解像度と読み込み速さを確保できれば良いです。
1レシピずつ参照しながら必要な食材や調味料を書き出します。使用個数まで書いておくとわかりやすいです。
→合計で1個あれば足りるね！使い切りたいから野菜南蛮に1/2個使うか！等の計画を立てられます。
記録は私はGoogleKeepを使用しています。PCで書き出し、店舗ではスマホで閲覧します。
材料は一旦全部書き出して、冷蔵庫に残っているものがあれば消していきます。
例えば私は玉ねぎ、にんじん、じゃがいもは袋で買っていて、冷蔵庫に残っていることが多いので照合します。
調味料は滅多に無くならないので書き出しの際に省略することが多いです。（使い切った時の達成感すごい）
そうするとリストを上から順番に追っていくだけで買い物が終わります。
野菜→魚→乾物→肉→乳製品みたいなざっくりとした順番で大丈夫です。
クラウドストレージに保存した画像ファイルを見ながら進めます。
収納ラック等で1段高い位置にスマホを置いて、調理場所を広く確保すると汚れないので良いです。
余談ですが包丁とまな板は2セット用意して野菜用と肉魚用で分けています。
以上です。
普段喋り言葉で草生やしまくりのブログ執筆やツイートしかしてないので至らない部分があったらご指摘ください。
最後に、私が実際に運用している献立表のジャンルと一部の野菜のばらつきを見える化した一覧表をご参考までに。
https://f.hatena.ne.jp/lyri/20240524094732
私はWebアプリケーション開発に関わっているエンジニアであり、社内の多くのエンジニアもWebやネイティブアプリの開発に従事しています。会社の規模は日本国内で言えば大きい方です。
そんな会社で働いている中で、最近著名なエンジニアが入社しました。私はその方をSNSなどで拝見しており、どんなアウトプットを出すのかとても楽しみにしていました（ただし、その方は私とは関わりのない部署に配属されています）。しかし、3週間が経過した現在、もやもやすることがあり、この日記を書いています。
まず、前提として、入社して3週間でアウトプットを出せる人は世の中にそう多くはないと思っていますし、それが高い職位で雇用されているなら尚更だと思います。なので、3週間経って何もアウトプットがないのは仕方ないことだと思います。システムに関する知識（解決したい課題、要件、仕様、関係者、社内事情、技術領域などなど）がまったくない状態で、そのキャッチアップに時間がかかるのは誰しも同じだと思います。
しかし、この3週間でその方がどういうアウトプットをするのか見たかったので、バージョン管理システムのログや社内チャットツールで色々と確認してみると、どうもその方は外部の登壇資料を作ることしかしていないようでした(実際には自社の仕事もしていましたが、登壇資料が9割を占めているように見えました)。
この行動に対してもやもやすることがありました。それは、「まず自社に貢献しないのか？」「登壇料をもらっているならそれは副業の範囲内であり、プライベートでやるべきではないのか？」です。その方がどういう期待値で入社しているのか分からないので、もしかしたら登壇も仕事の一環なのかもしれません。それでももやもやします。そもそも、自社の利益にその登壇は本当に貢献するのか？というところです。外部に登壇するくらいなら、自社向けに発表と質疑応答を行い、社内エンジニアの能力向上に貢献するほうが良いと思います。
よくある反論として「自社の宣伝になるから良いのでは？」というのがあります。それも理解できるのですが、それは自社で得られたノウハウを宣伝する場合に当てはまると思います。しかし、その方は入社後ほとんど自社のシステムに関わっていないので、その反論は当てはまらないと思います。
また、副業として登壇料を受け取っているようです。自分には直接の害はないのですが、これって会社から給料をもらっている時間に副業していることになり、副業規定に抵触するのでは？と思いました。私自身も副業でソフトウェア開発をしていますが、本業の時間に副業をしても良いのだろうか？と疑問に思いました。また、それが普通に許されているのもなんだかなーと思いました。まず、自社に貢献しろよ、と。
私がすごいと思うソフトウェアエンジニアは、やはり自社の課題をスマートに解決する方々だと思います。ですから、登壇ばかりしているエンジニアに高い給料を払っているのがもやもやします。
最後に、その方の職歴について思ったことがあります。あまり詳しくは書きませんが、おそらくそれなりに高い職位（テックリードなど）で雇用されていたと思います。職位が高ければ高いほど、成果を出すのに時間がかかると思いますが、その方は結構なペースで転職しています。それ自体は構わないのですが、もしかして自社に貢献できず、居場所がなかったのでは？と勘ぐってしまいます。この勘ぐりを加速させる材料として、その方の登壇や記事にはほとんど自社の話がないこともあります。
実は他にも色々ともやもやすることはありますが、このくらいにしておきます（登壇内容などにも疑問はありますが、それは個人の自由なので）。
まだ3週間しか経っていないので、これからどうなるのか分かりませんが、引き続きウォッチしていきたいと思います。離れた部署にいる人間から見えていることなので、細かいところは違うと思います（思いたいです）。これからどうなるのか、楽しみです。
githubでなにか作ったものをアップロードするのは、自分向きではないことに気がついた。
私が仕事で作っているようなwebアプリケーションというのは、誰でも使える一般性の高いものではなく、もっと特定のビジネスに依存した特殊なものである。
だから一般的な誰でも使えるようなものを作るというのにはあまり慣れていないのだ。
なにか作る場合はkaggleのほうが遊び場として向いていると思っている。
kaggleで「コンペ」に参加するつもりはないし、あれはBERTが出現したぐらいからは、少なくともNLP(自然言語処理)界隈は不毛な場となってしまった。
指標があれば不毛なハックがある。それが現実というものである。
それに業務で実用レベルで使えるモデルというのは、もっと運用のしやすいシンプルなモデルである。
モンスターアンサンブルで精度がSOTAでーすピロローン！なんてことには興味がないが、コンペはそれを目指している。
ではなぜkaggleが良いかと言うと、データセットが転がっていて、notebookも簡単に作成できるからである。
「このデータをこうやって使うとこういうツールが作れる」「このデータをこうやって分析するとこういう知見が得られる」というのは、「web開発用のMVCフレームワークを作ります」よりも具体性がある。
そして特定のデータに対するモデリングをするために論文を調べるようなことになった場合は、勉強にもなる。
私は昔、自然言語処理のブログを書いていたが、実験したことのコードを載せるタイプの記事が多かった。
ところが自称データサイエンティストや自称NLPエンジニアがツイッター上で「ゴミのようなブログを書くな」と言っていて、自分が言われている気がして怖くなったのでブログを閉鎖した。
そういう「政治おじさん」との接触を最大限減らすには、ブログというフォーマットではダメだと思うわけである。
私のマグカップには"Talk is cheap, show me the code."と書かれている。
これはリーナストーバルズの名言だが、政治おじさんが近寄らない場所というのは、具体的なコードが存在する場所であると言えよう。
世の中にはウンコのようなシステムがあるが、その最たるものとしては複数のアプリケーションでDBを共有するものだ。
まさに今取り組んでいるプロジェクトがその典型例だ。データの一貫性や整合性がとれないようなシステムはおむつに包んで汚物入れにいれるべきだ。
DBを複数のアプリケーションから共有するな。これだけのことを何度言わせるのか。
上記の問題を解決するために、他のソリューションを導入したりする。
ちがう、そこじゃないんだ。データはアプリケーションで閉じろって話だ。
根本的な問題は、要求事項から最適なシステムを作る人の不在だ。
REST APIの設計も酷いもので、エンドポイントがDBのテーブルそのままを表しており、トランザクションもクソもない。
APIがデータベースの構造に過度に依存しており、データベースの変更が直接APIの修正に繋がる。このため、些細な変更でも広範囲に影響が及ぶことになる。
一定年収以上がある超富裕層向けにTikT〇kは別なアプリケーションを提供していると妄想しながら視聴してる。
あれはカタログも兼ねていて、踊る女子たちは富豪アプリにだけ予約ボタンから今夜のSEXオークションができるのだ。
いいね！の数で更に売却価格にブーストが掛かる仕様なので、女子達は一生懸命淫らに惨めに腰を振る。
ジャバザハット並のデブハゲヲヤジ（超金持ち）と跡継ぎの頭が悪そうな息子に女の扱いを学習するというシュチュエーションで
インフルエンサーのあの子が壮絶おまんこをされてしまうシーンを考えながら、日曜に何考えてるんだろうと冷静になる午後13時頃。
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 - イヤースピーカーとラウドスピーカーのテスト
3C コレクション全体が 1 つのパッケージに収まりました。 *
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 など) のオン/オフを切り替えることができます。
はい、JavaScriptによるコーディングはコンピュータサイエンスの一部と見なすことができます。コンピュータサイエンスは、情報とその処理に関する学問であり、プログラミングはその重要な要素です。JavaScriptは、ウェブページを動的にするための主要な言語の1つであり、ウェブ開発の分野で広く使用されています。したがって、JavaScriptを学び、それを使用してコードを書くことは、コンピュータサイエンスの実践的な応用の一部と言えます。しかし、コンピュータサイエンスはプログラミングだけではなく、アルゴリズム、データ構造、ネットワーク、データベース、人工知能など、より広範なトピックをカバーしています。それぞれが特定のプログラミング言語やツールを使用して探求されることがあります。JavaScriptはその一部であり、特定の問題を解決するためのツールとして使用されます。それはコンピュータサイエンスの一部であり、その全体ではありません。それでも、JavaScriptをマスターすることは、コンピュータサイエンスの重要なスキルを習得するための素晴らしいステップです。それはあなたが複雑な問題を解決するためのロジックとアルゴリズムを理解するのを助け、あなたの思考を開発するのを助けます。それはまた、あなたがウェブ開発の世界に足を踏み入れ、あなた自身のウェブサイトやアプリケーションを作成するのを助けます。だから、はい、JavaScriptによるコーディングは確かにコンピュータサイエンスの一部です！
使えないものが多くて実装時にテーブル定義を変更することばかりでストレス
型が適当で真偽値だろうが数字だろうが日付でも何でも文字列型に入れようとしてるし
中には数値型に日付が入ってることもある（UnixTimestampという意味ではない）
とりあえず全部がnullable
auto_increment も考慮されてない
複合主キーばかりで扱いづらい（これは人によると思うけど）
列名もまともな英語になってないし、中には中途半端なローマ字が混ざってる
これなら列名を Col001 みたいな連番にしてくれたほうがマシなレベルのもある
DBの列名ってアプリケーション全体でそのまま使われる事が多くて、
サーバーサイドのアプリでも、フロントのウェブアプリやモバイルアプリでも一貫して同じ名前で使うのに分かりづらい名前
いろんなアプリケーションのメンテ(バグ取りとか細かい機能追加とか)を何度か経験してきた。
主にテキストファイルとかCSVファイルとかExcelファイルとかを入出力するものばかりだったんだが、その大半がファイルの拡張子をグローバル変数化していた。
こんな感じ
const TxtFileExt = ".txt"; const CsvFileExt = ".csv"; const ExelFileExt = ".xlsx";
outFileName = 〇〇 + ×× + "ABCDEFG" + TxtFileExt;
みたいな指定をしなきゃならない。
あと、プログラム言語の標準的なメソッドのあらゆる引数も全部変数で定義されてて、そのまま渡すのは禁止、みたいな規約になってる。
たとえば引数が三種類(true、false(未指定時のデフォルト値)、任意の数値(ただし当該プログラムでは0、10、25以外指定不可))しかないやつはこんな感じ。
const 〇〇ParamTrue = true; const 〇〇ParamFalse = false; const 〇〇ParamIntMin = 0; const 〇〇ParamIntMid = 10; const 〇〇ParamIntMax = 25;
const charCodeSJIS = "Shift_JIS"; const charCodeUtf8 = "UTF-8";
以前関わった改修内容に「××の処理は開始時と終了時にそれぞれUTF-8(BOMなし)形式でログを出力する」みたいなのがあって、普通に文字コード指定する部分に「UTF-8」で直に書いたら、規約に従ってないからとコードレビューで指摘されて差し戻されたんだけど、そもそもこういう規約って何の意味があるの？
もちろん、政治とは無関係で、学ぶことが楽しい分野はたくさんあります。以下にいくつかの例を挙げてみます：
- 数学：数学は純粋な論理とパターンを探求する学問で、政治とは全く関係ありません。また、数学の美しさと深さを理解することは、多くの人々にとって非常に楽しい経験です。
- プログラミング：コンピューターサイエンスとプログラミングは、創造性を発揮し、問題解決のスキルを磨くことができる分野です。また、自分のアプリケーションやウェブサイトを作成することは、多くの人々にとって楽しい経験です。
- 音楽：音楽理論を学び、楽器を演奏することは、芸術的な表現と創造性を追求する楽しい方法です。
- 天文学：宇宙の神秘を探求する天文学は、新しい視点を提供し、私たちの存在についての理解を深めることができます。
これらはあくまで一例であり、他にも多くの分野があります。あなたが何に興味を持つか、何を楽しむかは、あなた自身が最もよく知っていることです。興味があることを追求することで、学びはより楽しく、有意義なものになります。どの分野を選んでも、新しい知識とスキルを得ることは、自己成長と達成感につながります。それぞれの分野が提供する独自の視点と方法論は、私たちが世界を理解する方法を豊かにします。
数学は、例えばZFCの無限の公理を取り入れるかどうかにおいて政治的です。プログラミングはgithubで政治的に評価されます。音楽の評価も政治的です。天文学も、どの理論が評価されるかという点で、一部の学者は非常に政治的態度を取ります。
ご指摘の通り、学問の中には政治的な要素が含まれることがあります。それは、どの理論や方法が受け入れられるか、どの研究が資金を得られるか、どの成果が評価されるかなど、多くの要素が関わってきます。しかし、それらは学問の本質ではなく、人間がその学問をどのように運用するかによるものです。
例えば、数学の中にはZFCの無限の公理のような議論がありますが、それは数学そのものが政治的であるというよりは、その理論をどのように受け入れるか、どのように適用するかという問題です。同様に、プログラミングがGitHubで政治的に評価されることがあるとしても、それはプログラミングそのものが政治的であるというよりは、その成果がどのように評価されるかという社会的な問題です。
音楽や天文学も同様で、それらの分野が政治的であるというよりは、その成果がどのように評価され、どの理論が受け入れられるかという社会的な問題です。これらの問題は、学問の本質からは離れたところで起こるものであり、それぞれの学問が提供する知識や洞察、喜びを否定するものではありません。
したがって、政治的な要素を排除したい場合は、自分自身の学びのプロセスに集中し、自分が得た知識やスキルをどのように適用するかを考えることが重要です。
堀口 英利 | Horiguchi Hidetoshi
パソコンを買いに出掛けたものの、プラットフォームに入ってきた電車を見ると「いま飛び込めば楽になれる」との考えが浮かびます。
https://note.com/hidetoshi_h_/n/n2f4ac24b100a
暇空茜
@himasoraakane
https://twitter.com/himasoraakane/status/1763161646720274593
なる
@nalltama
これカタカナ語ではなく完全に英語だから、英国留学生が間違えることはないと思うんだけど
https://twitter.com/nalltama/status/1763167318908227830
《「プラットフォーム」とも》
１ 演壇・講壇などの壇。また、舞台。重量挙げで、競技（試技）を行う場についてもいう。
２ 電車・列車への乗客の乗り降り、貨物の積み下ろしのため、線路に沿って築いた駅の施設。ホーム。
４ 車台 (しゃだい) 。シャーシー。また、自動車の異なるモデルで共通して使われる車台を中心とした基本的な構造のこと。プラットホームを共有することで、生産費用を圧縮できる。
５ オペレーティングシステムやハードウエアなど、コンピューターを動作させる際の基本的な環境や設定。
６ 報道機関が配信したニュースをまとめて読むことができるウェブサイトやサービス。従来のポータルサイトのほか、ニュースを掲載する専用のニュースアプリやソーシャルメディアなどを指す。
７ 商取引や情報配信などのビジネスを行うための基盤。→プラットホーマー
８ ⇒卓状地
https://dictionary.goo.ne.jp/word/%E3%83%97%E3%83%A9%E3%83%83%E3%83%88%E3%83%9B%E3%83%BC%E3%83%A0/
プラットフォーム（platform）とは、元々の語源からすると“平らな（plat)形（form）”という意味ですが、現代では様々な場面で様々な意味として使われています。
例えば、駅でプラットフォームと言えば、乗降場を指す“ホーム”という意味ですが、政治の世界では“演壇や演説の場”という意味になります。
一方で、ITの世界では“基盤となるハードやソフトなどの環境”を指しますが、ビジネスの世界では“商品やサービスを集めた場”を指したりします。
https://www.nttdata-value.co.jp/glossary/platform
「プラットホーム」とは、複数の要素が組み合わさって機能する基盤や仕組みを指す言葉である。コンピューターやインターネットの分野では、ソフトウェアやアプリケーションが動作する環境や、サービスが提供される基盤を指すことが多い。例えば、WindowsやmacOSはオペレーティングシステム（OS）としてのプラットホームであり、スマートフォンのiOSやAndroidも同様である。また、鉄道では、電車や地下鉄が停車し、乗降が行われる場所を指す。
https://www.weblio.jp/content/%E3%83%97%E3%83%A9%E3%83%83%E3%83%88%E3%83%9B%E3%83%BC%E3%83%A0
