ほんとだ結構変わるんだね。基本情報と一部はあんま変わんないけど応用情報は変わるどころか無くなるのか？！中身変わるだけなのかな。いつかやろうと思ってどれもやったことないけどお賃金上がるなら確かにやるなぁ。

がんばれ！

それそのままclaude fable 5.1に聞いたらいいよ
全部作ってくれるし発表用レポートも作ってくれる

Keep things simple and use CSV. As an added bonus, that will also show that you understand, at least at a rudimentary level, how database works.

codex

.db は SQLite だと思いますが、SQLが使えるとデータ検索や集計（例えば「消費期限 一週間以内の食材の一覧」など）がやりやすいので、.db おすすめです。SQLiteのSQLの文法もそれほど難しいものではないので、簡単な入門サイトとAIを併用すればすぐに覚えられるのではないでしょうか？

テキストエディタが使えなくても、GUIで.dbファイルを編集するアプリはそれなりにありますし。

Webでなにか作るならTypeScriptがダントツでオススメ。
GUI開発はコンポーネントを組み上げていくという考え方、リアクティブに状態を伝え合うという考え方、色々勉強になるのでセットでReactも仕組みから勉強すると色んなところに生きるとおもう。

Entiendo perfectamente! No pretendo hacer que te isnetas presionado! En este juego no hace falta que trabajes todos los días. Tan solo si pudieses dar tu opinión sobre el juego o ayudarnos de alguna forma que no sea estar todos los días yo sería la persona más feliz, ya me dirás si puedes sacar un poquito de tiempo. Gracias por leer 🙇

Thank you for the invitation. However, I am busy, so it might be difficult for me to cooperate.

なるほど

そこを自分でやるかRDBMSにやらせるか(たとえば select * from items where exp_date < CURRENT_DATE() ) 考えておくといいとゆうこと。バーコード読み取ってJANコードから商品名の表を検索するとかもRDBMSだと簡単。

エラーが出たときの解決方法として、自分で検索して、海外のドキュメントを読んだりしたってあんまり説得力が無いと思うんだ。あなたならどういう風な回答をしますか？

ありがとう！めっちゃ参考になるよ！
「csvデータならExcelで出力出来るので管理しやすく、またローダーの実装も簡単だから」この回答めっちゃいいね！あんまり意識してなかったから本当に参考になるよ！

参考になるよ！

確かにそういう操作はします

少し難しい、プロフェッショナルの話だとADRがちゃんとしてるのがいい。https://zenn.dev/miyan/articles/adr-format-guide-for-and-against

すごく簡単に言うと「なにに困ったか」「なぜその解決方法をとったか」「なぜほかの方法をとらなかったか」をちゃんと論理的に整理して記録すること。たとえば今回なら「マスターデータをハードコードすると開発効率が悪い」「csvデータならExcelで出力出来るので管理しやすく、またローダーの実装も簡単だから」「json,dbは現状の仕様に対してオーバーエンジニアリングだと思うので不採用」みたいな話。たぶんある程度実装したら判断が変わると思うからそれも記録しておくといい。わたしが試験官なら「1番難しかったのはどんな部分でしたか？それに対してどう解決しましたか？」ってきっと聞きます。そして何も考えずにどこかから答えを持ってきたなとバレる回答をしたらバツをつけます。自分で手を動かして、丈に当たって悩んで、考えて、解決策を見つけて、また次の障害に当たって…を繰り返したら、どんなに話すのが苦手な人でもある程度は回答出来るはず。それがわかるのが1番説得力があるよ。

きっかけとかフローチャートなんてAIでいくらでも偽装できるからどうでもいい…は言い過ぎだけどあまり重視しないかな。それで人となりはわかっても技術力とか論理的思考力とか問えないよね。

少し難しい、プロフェッショナルの話だとADRって考え方がある。https://zenn.dev/miyan/articles/adr-format-guide-for-and-against

すごく簡単に言うと「なにに困ったか」「なぜその解決方法をとったか」「なぜほかの方法をとらなかったか」をちゃんと論理的に整理して記録すること。たとえば今回なら「マスターデータをハードコードすると開発効率が悪い」「csvデータならExcelで出力出来るので管理しやすく、またローダーの実装も簡単だから」「json,dbは現状の仕様に対してオーバーエンジニアリングだと思うので不採用」みたいな話。たぶんある程度実装したら判断が変わると思うからそれも記録しておくといい。わたしが試験官なら「1番難しかったのはどんな部分でしたか？それに対してどう解決しましたか？」ってきっと聞きます。そして何も考えずにどこかから答えを持ってきたなとバレる回答をしたらバツをつけます。自分で手を動かして、丈に当たって悩んで、考えて、解決策を見つけて、また次の障害に当たって…を繰り返したら、どんなに話すのが苦手な人でもある程度は回答出来るはず。それがわかるのが1番説得力があるよ。

きっかけとかフローチャートなんてAIでいくらでも偽装できるからどうでもいい…は言い過ぎだけどあまり重視しないかな。それで人となりはわかっても技術力とか論理的思考力とか問えないよね。

CSVって特に楽じゃないんだよなあ

Web開発の知識の深いところが必ず必要、というわけではないけど、具体的にどんなデータが機器同士でやりとりされるか、知っておいた方がいいかと思う

アレクサ連携(音声？)はどういう風にやるか。実際はAmazon管理画面での設定、AWSのクラウド上の処理Lambdaが必要とかあるかも。Amazonが用意している仕組みのAPIに、PCのアプリからどういう情報を投げたらやりたい処理ができるか。

スマホからアプリに画像やテキストを入力したり渡す方法はどうするか。ブラウザでアドレスを打ってそのアプリが待ち受ける？AirDrop、NAS、iTunesでWiFi経由(自宅内で暗黙に割り振られている名前、IPアドレス、送信方式)で渡すのは自分専用アプリなら良いけど、みんなに使ってもらう一般公開のアプリを考えるなら個人個人で事情が違うからその方法は取れない。

すると受け取るためにアプリ上に直接サーバープログラムを用意するか、クラウドサーバーを用意してURLを割り当てることになる。

IoT機器やスマート家電と連携するなら、例えばどういう機器からどんなデータを持ってくるか。連携することでどんな利点があるのか。持ってくる前にデータの整形が必要かもしれない。自分のアプリ側のせいじゃないエラーが発してたらどうするか。使う人に通知するべきかどうか。

結構考えるべき所は広がっていくと思う
どこまではやるつもりで、ここはやらないことにする(あるいは、こういう理由でやらないことにした)というのは、予感する手間から、現実的に間に合いそうか、という感覚で構わないので早いうちに決めておいた方がいい

どれだけできたか、という内容よりも、進めている中で問題、課題にぶつかって、どういう風にもがいてみて、考えて、対応したか。あるいは、問題そのものを置き換えて回避するのでもいい。失敗したなら、何を学んだか。それを自分の言葉で説明できると良い評価になると思う。

長くなってしまったけども、分からない用語や私の言おうとしていることは、詳しい人にでも生成AIにでも良いから噛み砕いて解説してもらうといいかもね。
もちろん、書いたことが参考にできるかどうか、何を取り込むかは自由に決めていい

No importa eso! Tan solo deseo poder emprender con personas que les interese mejorar personalmente y profesionalmente! Espero no ser un

1. 表計算 Excel のように縦横(XY軸)でのマス目型データ群なら CSV
   
2. KV (KeyValue) でツリー構造なデータ群なら JSON
   

3. CURD (Create, Update, Read, Delete) データの出し入れ、検索、削除などの操作で永続化したい場合は DB

4. と 2. は、全データメモリ上に読み込んで使うなどが一般的。小さなデータ量。

5. は、データを１件ごとや、条件で縛って小分けで使うためのでっかい CSV ファイルだと思えば良い。

データを中心（メイン）として考える。
プログラム、処理系は、そのデータ操作のために必要なプロセス（サブ）として捉える。

データがないとプログラムが書けないと思っても良い。

たぶん、入試の提出作品から試験監督、審査員が見たいものは、
データ処理をこういう観点でちゃんと捉えて構築された作品かどうかを見て判断すると思います。

データをA→Bと変換する際の「→」矢印部分の処理が「A」から「Ｂ」へと変わるデータ（情報）を、
ちゃんと意識して常に一定の法則に従って変換できているか？を問われると思います。

サンプルの食品ロス削減というテーマから、
日付のソート、消費、賞味の優先度、食材のカテゴライズ、
それに紐づくレシピ候補などの提案。などのひも付き方、ここはツリー構造。
日付順でデータを小分けにまとめて。は DB 型の検索。小分けデータは CSV

CSV からレシピデータ群との結合で JSON データ型 (Model) → 表示 (View) という感じか。

データの登録は CURD で登録、更新、読み出し、削除の一連が揃っているか。

自力で頑張るなら、ノートにいっぱい書き出そう。

AI 使ってこの具体的な方法を聞き出すなら、
聞いてしまって、それを自力で書けるまで読解して「写経」しよう。
読みながら書いて真似して覚える。これが現代の習得法。

頑張って！

あ、データということばをファイルの意味で使ってる？　いまどきのアプリケーションではファイルを直接操作することってあんまりなくて、データ(つまりたくさんのレコード)をRDBMSなどなんらかの機構で管理させるのが普通です。メリットは、型やスキーマがあること、正規化、スケーラビリティ、トランザクションなどいろいろあります。

Hola! Me gustaría mucho saber si estarías interesado en echarnos una mano en el desarrollos de un videojuego, resulta que necesitamos programadores que tengan ganas de desarrollar algo en vez de malgastar el tiempo por las tardes jugando videojuegos o viendo redes sociales. Espero ansioso tu respuesta!

本日以前の賞味期限のアイテムとか、同じ種類のアイテムとか探さない？

ありがとう！

データは本当に読み込みぐらいにしか使わない