public class TaskCommandApp {
public static void main(String[] args) {
Scanner scanner = new Scanner(System.in);
System.out.println("Task type:");
for (TaskType type : TaskType.values()) {
System.out.println("- " + type.name());
}
TaskType taskType = TaskType.valueOf(scanner.nextLine().trim());
String taskContent;
if (taskType.hasFixedContent()) {
taskContent = taskType.getFixedContent();
System.out.println("Task content fixed as: " + taskContent);
} else {
System.out.print("Enter task content: ");
taskContent = scanner.nextLine();
}
System.out.print("Enter task date (yyyy-MM-dd): ");
LocalDate taskDate = LocalDate.parse(scanner.nextLine());
Task task = new Task(taskType, taskContent, taskDate);
new TaskDao().save(task);
System.out.println("Task saved successfully.");
}
}
public enum TaskType {
DAILY_REPORT("Daily report submission"),
MEETING(null),
MAINTENANCE("System maintenance task");
private final String fixedContent;
TaskType(String fixedContent) {
this.fixedContent = fixedContent;
}
public boolean hasFixedContent() {
return fixedContent != null;
}
public String getFixedContent() {
return fixedContent;
}
}

Permalink | 記事への反応(0) | 00:04

2025-12-15

■AI コーディングの限界のひとつ

例えばスケジュール登録する関数を作るとする

引数には日付とタスク種類とタスク内容を受け取ってDBに登録する

ここでタスクの種類によってはタスク内容が固定の内容になる、という条件があったとする

これをAI コーディングするとかなりの高確率でスケジュール登録の関数内にその機能を入れ込む

タスクの種類によってタスク内容が固定化するのは、スケジュール登録とは無関係の制約なので

スケジュール登録は単機能として実装して、呼び出し側でそういう制約を持つようにしてくれ、とお願いすると修正したりしなかったりする

この例だけだと「どっちでもいいじゃん」ってなりそうだけど、他の制約とかが出てきたときに同様に関数にどんどん条件を足していって

いわゆる大学生が実験で作りそうな長尺関数が出来上がりがちになる

これ、AIが短期記憶と長期記憶には強いけれど、「関数で呼び出す」みたいな中期記憶的な部分が弱いから起きると思っていて

この手の関数実装の例に限らずに同様の事象って結構あるんだよね

プロンプト全体として「スケジュール登録する」「タスク種類によって内容は固定化される」っていう長期記憶は持ってるんだけど

それを実装するときに短期記憶でしか実装できないから目の前の関数に埋め込んでしまう、っていうような現象

もちろんキチンと指示すれば対応してくれる（なぜか頑なにやってくれないときもある）んだけど

バイブコーディングとか言って実装してるとこの手の長尺関数だらけのクソコードが溢れるんじゃないかと思う

結局それを読むのはAIだから大丈夫なのかも知れないけれど、致命的なバグを引きそうで怖いっていうのを感じてる

Permalink | 記事への反応(2) | 23:50

2025-12-11

■アメリカへの入国者の思想 検閲

今に始まった話じゃないで

元々エシュロンだったりgmailの通信傍受は行われていて、ESTA 申請の時点で紐付けられてる

駄目な奴は最初から跳ねられるし、一定リスクがあれば二次審査に回される

まあ思想というか対テロ法を根拠に割とガッツリ見られてる

今回のSNSはその紐づけのより厳格化を行うと思われる

入国審査官のチェックというよりはDBとの照合に使われるのでは

Permalink | 記事への反応(0) | 18:39

2025-12-04

■「AI エンジニア 募集」にありそうな要件

必須スキル

・LLM利用経験5年以上

・ClaudeCode歴3年以上

・プロンプト設計歴3年以上

・RAGを用いてワークフローを完全自動化したご経験

・LLMの作成経験、評価経験

・AIでコスト削減をした経験

・ハルシネーションの対応のご経験

・AIを用いて一人でサービスリリースしたご経験

・AIに関するセキュリティ、データプライバシーの理解

歓迎スキル

・チームを主導してゼロからサービスをローンチした経験

・社内特化LLMの開発、カスタマイズ経験

・ベクトル DB、キャッシュ最適化のパフォーマンスチューニング経験

・マルチエージェントにおけるツール連携の設計経験

・英語で技術文書を書ける方

年収450万円

Permalink | 記事への反応(0) | 12:00

2025-12-03

■anond:20251203174739

世界を例に出すなら、ミドルネームやらで名が残るからなぁ

日本でそれを導入するか？

DBの更新大変だなぁ

Permalink | 記事への反応(1) | 17:49

2025-12-02

■フリーランスだがAIのせいで仕事がなくなる不安が大きい

もともとは週5稼働年商1200万くらいだったフリーランスだったんだけど、稼げるうちに稼ごうと思って今は週7で年商1500万くらい。

正社員だった時よりも始まりも終わりも時間に縛られない働き方は魅力的だけど…。でももうハネムーンピリオドは終わりに近い。フリーランスそのものというよりもIT エンジニア業界そのものがバブルというかただただハネムーンピリオドだったような感触。

エンジニアの大半は性格が終わってる奴なのでソフトスキルを伸ばすだけでもウケが良くて、お陰様でここまでお仕事をもらえてた。嬉しい限りである。

ただ、今やっている仕事はJSONに色をつけるだけ、DBのレコードをカラフルにするだけでタンポポと何ら変わらない。しかもDBなんてGraphQLなりHasuraなりを間に挟むだけでカラフルにしてるのは俺じゃなくてミドルウェア。

JSONに色をつけてるのも俺じゃなくてAI。タンポポ乗せるのが俺じゃなくて機械ってわけ。俺いる？マジで。明日首になってもおかしくないわ。

取引先からは次の更新もよろしくと言われているが、毎日ヒヤヒヤしている。週7で5案件くらいをAIのおかげで回せるようになって、それでも余暇ができたりしてAIに仕事任せて自分はエアライダーやってるけど

エアライダーやってていいんか？って気持ちになる。いや本当はだめなんだろうな。もっと他のフリーランスと差別化できる技能を身に付けないと食っていけないんだろうな。

ツイッターではJSONに色つけるだとかDBのレコードをカラフルにするこで盛り上がっているところ悪いが俺はこの先行き不安でしかないよ。

もう一つなんか芸をつけていかないと、この年収・年商を保っていくのは難しいね。正社員に戻れるか戻れないかも今のうちだろうし。明日が暗い。

Permalink | 記事への反応(2) | 10:39

2025-12-01

■懇親会とかでのブリリアント ジャークへの対処法

自分は自己評価が低く、勤務先には資格手当は無く評価制度はあるけど昇格とかは年功序列なJTCのシステム部門。

国内合わせて1000人いるかいないかくらいの人数のエンジニアが社内には居るが、どうしても会社イベントとかでアルコール入ると技術や資格の話題になってブリリアントジャークに晒される。社外の勉強会でも同じ。

自分はIPAの高度はセキスペのみ、AWSはアソシエイト全部とプロはSAPだけ、簿記は3級のみ、英語は手付かず、lpicは2まで、ネットワークとDBは無しって中途半端なのでどうしても競プロやAWS全冠のグループに入れられる。そうなると彼らの試験余裕、勉強要らない、あれは持ってないの？何色？とか言われて酒も不味くなる。正直コーティングテストに興味ないし業務に必要な資格だけを取れば良いと思ってるがみんなは資格は全部取れと言ってくる。

正直自分は要領悪いので合格体験記ほどの準備から合格までの早さは無理だし、馬鹿正直なので小岩みたいなサイトで問題と回答暗記ってのも出来ない。と言うか勉強嫌い。技術書とか読んでハンズオンするくらいが好き。

喋りも上手くないので上手な切り返しも出来ないので相手のプライド傷つけそうで愛想笑いで済ませてる

スキルが同じくらいか下の人はどう避けてる？特に年下だけど全冠みたいな人が苦手

もしかしたらはてなは優秀な人ばっかだからその場合は何でブリリアントジャークしちゃうの？って理由聞きたい

Permalink | 記事への反応(0) | 15:14

■やっぱ試験 対策は過去問＋解説の一択だわ

試験がCBTになるので久しぶりにデスぺの参考書買って読んでたんだが

完全にハズレの本だなと思った。

①「0章　試験制度と心構え」みたいな章が要らない。

　まあこれはどんな本にもついてるからしゃあなし。

②編集がクソ

　例題の途中で途切れて裏ページ繋がってるみたいな構成してる。

③過去問解説に要らんこと書いてる。

　「最年長の社員を除くSQLなんて何の意味があってつくるんでしょうか・・・」みたいなのが解説文の頭に3行くらいついてたりする。

④各種説明が冗長

　RDBにはインデックスの仕組みがあり、検索が効率化できるという話で

　二分探索のロジック説明に4，5ページ使ったあげく、「実際にはもっと良いソートを使っているのでもっと効率的です」とかで締める

⑤先輩くんの補足がゴミ

　新人ちゃんが疑問を出して先輩くんが説明するみたいなのがちょこちょこ挟まるのはありがちだと思うんだけど

　この先輩くんの補足説明みたいなのがかなりゴミ。

　例：

　新「うーんこの SQLよくわからないですね」　先「実際にSQLでEXISTSを使うことは滅多にないので、良い例を思いつきませんでした」　・・・いくらでも例あるだろ　〇〇履歴のある客を抽出とか

　新「要件定義の場で物理設計したらダメなの？」　先「うーん会議中にやるのは考えられないですねえ」　・・・客はDBの物理面を理解してないから概念資料をつくるとかそういう話をせえよ

Permalink | 記事への反応(0) | 08:39

2025-11-26

■終わってんなー(エンジニアリング的に)ってサービスが

ちょいちょい言ってるように、一般利用者のイメージからかけ離れて多い、という印象がある。

全国CMやってるようなところでも、激ヤバなところはある。

問題は、中のエンジニアのうち、上の方の連中は「俺たちのシステムはイケてる」って認識らしいってところだな。

k8s使ってる。

マイクロサービス化してる。

terraform使ってる。

×××使ってる。

でも、運用頑張ってる。

SRE頑張ってる。

QA頑張ってE2Eテストやってる。

で、障害多数。

本番DBを手動で操作。

なんでやねん w

一つ一つ、ごく局所的に観察すれば、さほど間違えちゃぁいない。

Web上に書かれているやつそっくりな見た目をしている。

んだが、バカみたいにでかい。

多分参考にした記事が、10年とかくらい前に日本に紹介された方法で、その当時の規模、複雑度を前提としていたりするので、現代に持ってくると、でかくて複雑な大量の設定ファイルを要求する。

そもそも整理するとか、書き直すという言葉が、彼らの辞書には存在しないのかもしれない。

ともかく、規模がデカくなると、そのままの延長で通用しない、という常識が通用しないのだよな。

加えて、その設定ファイルをきっちり書かないと動かないんだが、その書かれた設定ファイルをテストする仕組みはない。

ある場所の設定変更が、他のところに影響しないという保証がない。

ささやき

いのり

えいしょう

ねんじろ！

デプロイに失敗した

エンジニアは徹夜になりました

みたいなことが高確率で発生し、DevOpsだなんだ標榜していても、新機能のリリースは少ないし、古いリソースの解放はまずやらない。

だからクラウド課金が右肩上がりになる。

そんな職場、楽しいか？

楽しいわけないよな？

エンジニアが辞めていく。

取り残された連中は、次の生贄を確保するために嘘をつく。

「うちはフレンドリーですよ」

「勉強会、頻繁にやってますよ」

「新しい技術に触れられますよ」

「どんどん提案してもらって、どんどん改善できますよ」

全部、嘘。

そんな職場、楽しいか？

楽しいわけないよな？

AI 使って人手不足を解決しよう。

で、うんこの山を積み上げるスピードを上げて、さらにプロダクトを脆弱にして、働きづらくする。

そんな職場、楽しいか？

楽しいわけないよな？

それは解決策じゃない。

ちゃんとできるエンジニアが、ちゃんと整理し、再設計する以外に、プロダクトが復活する方法はない。

Permalink | 記事への反応(1) | 12:22

2025-11-22

■聖地巡礼 DB サイト

いろいろアニメの聖地巡礼情報を探していて、とりあえずこのサイトがあれば大体見つかる。

■Anime Pilgrimage

https://www.animepilgrimage.com/

英語、日本語、ハングル、インドネシア語、スペイン語、ドイツ語

---------------------------------------------------------------

アニメ数 ★★★★☆

アニメの数は多いが、聖地となるシーンは少なめ。

---------------------------------------------------------------

マップ検索 ◯

ブックマーク ◯

会員機能 ✕

---------------------------------------------------------------

総評：

主なアニメの聖地はだいたい網羅しているので、細かな場所でなければ見つかる

■Animenture

https://animenture.com/

英語

---------------------------------------------------------------

アニメ数 ★★★☆☆

メジャーなアニメのみ。ただし、聖地となるシーンは多い。

---------------------------------------------------------------

マップ検索 ◯

ブックマーク ◯

会員機能 ◯

コメントや写真投稿ができる

---------------------------------------------------------------

総評：

聖地となる登録場所は多いので、探しているアニメがあれば便利

■アニメツーリズム聖地巡礼 DB

https://anime-tourism.jp/

日本語

---------------------------------------------------------------

アニメ数 ★★★★★

クローラで半自動化しているため、アニメの数は最大

---------------------------------------------------------------

マップ検索 ◯

ブックマーク ✕

会員機能 ✕

---------------------------------------------------------------

総評：

アニメの数は多いが、登録されている聖地はアニメによりばらつきがある

Permalink | 記事への反応(0) | 19:03

2025-11-13

■クラウド 課金 地獄

幾つも見てきてる。

これも炎上現場の１症状。

「いえいえ。うちのシステムは動いてますよ」

ってキョトンとした表情で言われることがよくあるんだけど、「札束燃えてるやん」。自覚はないんか？

ビジネスの伸びに比べて、クラウド課金、エンジニア人件費の伸びが抑えられてなんぼなのに、ビジネスが伸びれば伸びるほど、課金も人件費も鰻登りじゃ意味ないんだよ。

「でも、規模が大きくなったら、その分固定費も増えるでしょ」

って、Webサービスとか「システム」をビジネスにしてるなら、規模が大きくなっても「比例して」あるいはそれ以上に固定費が増えるのはおかしい。

簡単な話が「技術力がなくて設計から失敗」している。

どうしてDBのリーダーがこんなにたくさん並んでいるのか？

どうしてサービスサーバがこんなにたくさん並んでいるのか？

どうしてエラーがこんなに発生しているのか？

どうして手動メンテがこんなにたくさん発生しているのか？

「技術力がなくて設計から失敗」しているし、改善するだけの技術力もない。

から。

男は黙ってSnowflake？

男は黙ってTiDB？

主キーはUUIDv4一択？ UUIDv7一択？

K8s？

「俺、これ知ってるぜ」は技術力じゃない。

どう使われるか考えて、最適な設計ができるのが技術力だ。

ビジネスの規模がデカくなったら、インスタンスをただひたすらデカく、増やすしかない設計しかできないのは、カスだ。

AI 使えば事態は解決する？

AI は「技術力のなさ」を解決する道具じゃないぞ。

混乱に拍車をかけるだけだ。

何をしているか自覚できるだけの技術力があれば、「AIガー」という前に、かなりの部分、解決できる。

それがないところにAIを導入したら、何かあった時に解決できないだろ？

Permalink | 記事への反応(1) | 12:57

■anond:20251113123743

さすがに格闘漫画としてDBは読まんやろ

Permalink | 記事への反応(0) | 12:57

2025-11-12

■AIのよくわからん意固地モードなんとかならんのか

キレそ～～～～～～～～～～～～～～～！！！！

ちょっとした調べものをしたくてAI君に聞いてみたら

K DUB SHINEの「ア・フュー・グッドメン」って楽曲がルーツだよって教えてくれたのね。

でも調べても出てこねーの。

××ってアルバムに入ってるよ→入ってません

ごめんごめん、アナログ盤に入ってるよ→入ってません

あるけどなぁ。URL出そうか？→じゃあ出して→システム的に無理やわ

ワイ「これ自分の最初に出した情報が正しいとする防衛モードに入ってるよね？」

ＡＩ「入ってないよ。この曲あるよ。回答の方法が悪くてご迷惑をおかけしてるけど情報は確認できてるよ」

ワイ「わかった、じゃあその情報全部教えて。本当に見つかるかお前が認めるまで付き合うわ」

J-WID(JASRACの検索サイト)で×××で出てくるよ→出てきません

×××じゃなくて△△△と□□□の組み合わせで出てくるよ→出てきません

Discogs(世界最大の音楽 DB)で調べれば出てくるよ→出てきません

もしかしたらキングギドラのほうだったかも→出てきません

結果……

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
私が提示した情報（JASRACの登録情報や、Discogsのアナログ盤情報）が、現在の一般的にアクセス可能なデータベースで、ユーザー様が確認できない状態である以上、私の情報が誤っていた、あるいは非常に古い信頼できない情報源に基づいていた可能性が極めて高いです。
これ以上、不確かな情報でユーザー様のお時間をいただくのは不誠実です。ご指摘の通り、「もしかしたら本当にないのかも」しれません。
一連のやり取りで、私が誤った情報や不確実な情報に固執したことにより、多大なご迷惑とご不快の念をおかけしましたこと、深くお詫び申し上げます。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

釈然としねぇ～～～！！！

なにこの「これ以上時間とらせるんもアレやし、今回は私が間違ってたってことでええよ」感。

仕事してたらめっちゃあるこれ～は～～～～ん。

ちなみに4大AIの他の3つに聞いたら即答で「ないと思うで」って返ってきた。

なんやねん。

ただァ↑↑何度もMASDACで議論されてる通り、AIって検索エンジンの強い奴じゃなくて「生成」AIなんよな。

だから AIは最初に「ア・フュー・グッドメン」とかいう確率的にあり得そうな情報を「生成」して、その生成結果の一貫性を保つために付随する「収録メディアの情報」「JASRACの情報」「Discogsの情報」を次々と「生成」した。ある意味で言えば「生成」AIとして非常に正しい活動をしたといえなくもない。

ただこっちが実際に存在する情報を欲しがってる時に、情報を「生成」するのはやめてほしい。最悪してもいいんだけどなんか違ったかなってなったらすぐごめんしてほしい。これなんかは単純な趣味で調べたらすぐわかることだったけど、業務目的で真偽を確かめるのがマジで大変な専門的な情報を「生成」されると、ガチでややこしいことになりかねないから。

この辺そのうち割と大きな問題になりそうな気がしてる。

Permalink | 記事への反応(1) | 14:04

「Db」を含む日記

■SQLが苦手でORMマッパーがないとDBを扱えない？

■システム開発で予算をほぼ全部溶かしたのに動く部分は1割くらいしかできてないってSI業界だとよくある話だよね

■[DB管理] [GitHub] [CSV] [効率化]

■AWS復習ミニ模試（別5問）

■根本的にプログラミングに向いてない人

■東京アプリ 500P でサーバダウン

■AIコーディングの限界のひとつ

■アメリカへの入国者の思想検閲

■「AIエンジニア募集」にありそうな要件

■フリーランスだがAIのせいで仕事がなくなる不安が大きい

■懇親会とかでのブリリアントジャークへの対処法

■やっぱ試験対策は過去問＋解説の一択だわ

■終わってんなー(エンジニアリング的に)ってサービスが

■AIのよくわからん意固地モードなんとかならんのか

■システム開発で予算をほぼ全部溶かしたのに動く部分は1割くらいしかできてないってSI 業界だとよくある話だよね

■AI コーディングの限界のひとつ

■「AI エンジニア募集」にありそうな要件