はてなキーワード: rdbとは
ごくごく常識的な内容だった
標準的なRailsアプリならDBはRDBだし、I/O待ちはほとんどDBアクセスと言っていい
RailsユーザーがRailsのイベントでRailsユーザー向けにやってるトークなんだからそこは前提だろ
スライドの大筋は古典的なI/OバウンドとCPUバウンドの話題であり、DBアクセス以外のI/O待ちにも触れてる
要するにどう見ても最低限の知識があるはずの人間がなんでそんなタイトルを付けてるのかっつーと、I/Oなんて言っても意味が分からない程度の初級者のための配慮だろうがよ
どう見てもやべーのはお前だから
ある方が「遺書だったもの」というブログ・エントリーを公開してはてなブックマークで注目を集めています。
https://kirimin.hatenablog.com/entry/2024/09/04/001242
一読しただけで大変な状況の中ご本人が精一杯頑張ってきたことが伝わってきました。
普通の人は不登校になったあとに就職したり(それもB社側からの打診で正社員に!)、アメリカ出張、趣味でイラストや競技プログラミング、といった活動は出来ません。
なにより踏みとどまるという意思を持たれていることが一番素晴らしいと思います。
ブログの内容について、アドバイス、というより考えてみるきっかけを提供できればと思い、以下に書いておきます。
"アドバイス"という言葉は上から目線のニュアンスがあるため私は嫌いですが、分かりやすさのためにあえて"アドバイス"と記載しております。
"アドバイス"の手がかりとして、世の中の多くの人たちと異なっている点を特徴として捉え、そこに着目して述べていきます。
多くの人は、自死を取りやめた場合は遺書を公開しません。ここが最大のポイントです。
他にも、元カノの話や学校で友達を作りたかった話、インターネット掲示板、会社の同僚との関わりなど、コミュニケーションについて多く言及していることもかなり特徴的です。
心理的な安定のためには、インターネットで構わないので、コミュニケーションの場への参加を増やしてしてみると良いかもしれません。
私も同世代で、2005年~2007年ごろには2chで政治家をおちょくるコラージュ写真を作って遊んでいたので、当時の雰囲気は知っています。当時と似たコミュニティはもはやほとんどなく、ネット掲示板よりもLINEのオープンチャットあたりのほうが雰囲気が近いかもしれません。
仕事やそれに近い競技プログラミングの能力・モチベーションでご自身の価値をはかる表現が目立ちます。
仕事への情熱はご自身の能力開発、社会貢献、金銭獲得のために素晴らしいことです。
一方で能力・モチベーションで全人類のトップに立つことは出来ない以上、どこかで自分の能力に見切りをつける必要があります。
それが今なのかな、と漠然と感じました。
人には能力の限界・投入できる時間の長さの制約があり、その制約のもと各自それぞれのペースで頑張るしかなく、他に選択肢はないため、ある面で人より劣ることを認めざるを得ません。
しかしだからといって人間として価値がないとか、死ぬべきだということは論理の飛躍です。
劣ることを認めたうえで、それがどうした、自分が死ぬ必要はないじゃないか。むしろ優れた人たちが素晴らしい社会を作ってくれてありがたい、と感謝すればよいと私は思います。ご自身にもその気持があるはずです。その証拠にA社のリーダー、B社のプロダクト、元カノ、といったものを称える文章があります。これは称賛の気持が奥底にあるからだと思います。
というより本当は人間という存在自体が自他に価値を評価される必要がなく、各自勝手に生きて構わないと私は思います。評価という行為自体が発生しないのが通常の状態であり、仕事では給料の分配という特別な目的のために上司が評価するという例外的なシチュエーションが発生していると私は理解しています。つまりそもそも職場以外での「自己評価」は必須ではないと私は考えています。
そのうえで、それでもなお自己評価が必要であれば、いくつもの会社で働くことができ、しかも先方から声をかけてもらっているというのは素晴らしいことだと思います。普通の人には声をかけませんよね。仕事の以外の面に目を向けると、イラスト、VR、他の投稿ではお母様にテレビゲームを教えたりと多方面に活動している点が素晴らしいと思います。競技プログラミングで高レート帯の方々はこうした活動と両立できるのでしょうか。ほとんどNoだと思います。総合的に見れば特別劣っているように私には見えません。
この点は次の第3の特徴に続きます。
文章には「多くの人から嫌われ、失望され、迷惑をかけながら生きていたくない。」と書かれています。
しかしきりみんさんは、嫌われている人・失望されている人・迷惑をかけている人に対して、死ねとは言わないと思います。そういう人柄だと文章で分かります。
それなのに自分に対して厳しいのはダブルスタンダードで、ご自身を不必要に傷つけているように見えます。ご自身に対して厳しすぎるダブルスタンダードを持つ理由は何でしょうか。ダブルスタンダードを持つメリットはあるのでしょうか。これについて考えると楽になれる部分があると思います。
きりみんさんは、自分より仕事ができない人に死ねと言わないと思います。競技プログラミングが下手な人に死ねと言わないと思います。その理由は劣っていても死ぬ必要はないとご自身が理解しているからです。そうであればきりみんさんが死ぬ理由もないと私は思います。
正解が「数学的」に決まるところ。たとえば「1■1=2 のときに ■を答えなさい」というときに競プロは■を答えるだろうし、それを早く答えて悦に入るだろう。
それもいいけど、いちど数学的に答えが決まっちゃう問題はライブラリにまとめられて、一般的なコーダはなにも考えなくてもインポートして処理できちゃうわけ。上の例えだとふつーのプログラマなら「枯れたライブラリをインポートして、正しく答えが出ると確信できるなら『答えは正しいとか考えなくても』それを使って対処する」ので、データの振る舞いとか気にしないで済む。たとえば SQL なんて、実行時計画という「アルゴリズムを常に指定するなら不要な」話題があるのだけど、データ量によって適切なアルゴリズムが変化するから仕方ないし、概ね RDB は賢いのでヒューマンが考慮するのは問題がある場合だけなのだ。よって、競技プログラマが生産性を確実に上げるという根拠はない。
もちろん、アルゴリズム知識を身につけるのは大切だし、クヌース先生も書いてたけど分散処理アルゴリズムはフロンテイアだろうよ。というか、暗号分野やセキュリティの領域や、条件が過酷な場合(宇宙線の影響下とか、メモリの少ないエッジコンピューティングとか)だと、アルゴリズムの研究や追求は大切なのは今も同じだ。でも、競技プログラマが新規にアルゴリズムを開発したり、セキュリティに向上したという話は聞いたことがないが、レッドコーダー諸君は自前で創造して使われた実績はあるのだろうか?
ついでに聞いてみたいのだが、競技プログラマたちは「マルチスレッドなコードで早く書こうとしないのはなぜ?」「そもそも、競技プログラミングで使うコードは便利なスニペッツがあるけどそれってチートでは?」「ときどき正規表現で解く問題があるけど、そのときの計算量は無視してない?」という矛盾を抱えているのてはないか?と思うのだが如何か。
究極的には競技プログラミングに必要な知識というのは、産業用途で要求される知識の一部でしかないのが問題なんだと思うよ。ほら、アレだよ、むかし話題になった「数学だけデキる人向けの東工入試をやったら、英語ができなくて卒業できなかった」という童話に近いんだよ。競技プログラムってインとアウトしか見てないブラックボックステストだから、ここだけしか計算機科学の知識が無いというヤバ人材の育成しかなってないのだろうな。
まぁ、下っ端プログラマには要らないだろうけど、いわゆるシステムエンジニアとかアーキテクトとか言われるレベルの仕事するには、なるべく知っとかないといけないよね。
オレの場合は、大学はかろうじて理系の一角だったけど、学問的にコンピュータサイエンスを学んだことはなくて、某IT会社でなかば業務上の必要に迫られ、なかば趣味的な興味本位もありで、ちょっとずつ勉強した。
で、もう20年くらい前だし、すでに廃止されてる(と思う)ので、守秘義務違反とかの面倒なことにならなそうだと想定してぶっちゃけると、大手携帯会社のショップで各店舗独自のプロモーション打ったりするためのWebシステムの開発に関わったことがある。
顧客の(および自分とこの)エライ人なんかに、システムの設計の根拠(この方式が最善なのか?もっと安く早くやれる方法はないのか?などなど)を常に問いかけられ、説明説得しなきゃならない。そこでコンピュータサイエンスに基づいて理路整然と話をすると、ちゃんと信頼してもらえるし、納得してカネ払ってもらえるw
そこで使ったのが、以下のような各種理論だ:
などなど... 自分史上最高に残業させられたこの仕事やってた年の年収は、900万円台おしくも1000万には届かなかったねぇw
--追記--
コンピュータサイエンスがらみの思い出でもう一個面白い(とオレが思う)ネタがあるので、ついでに書いとこうw
これは、上で書いた携帯会社のシステムよりだいぶ前のことになるが、とあるグループウェアの開発に関わってたとき、メールをFAXに向けて出力するドライバを書いたことがある。昔のことなのでオープンソースもあんまり普及してないし、タダでお手軽に使えるライブラリが見つからなかったので、「車輪の再発明」っぽいけど自分でハフマン符号化によるデータ圧縮のアルゴリズムを勉強して作ったのだ。
Win32のAPIとか呼び出して、ビットマップにテキストを描画させたとこから、ドットをちまちま数えて、白のドットがいくつ続いてたらこのコード、黒がいくつ続いてたらあのコード...って可変長のビットパターンをつなぎ合わせてファイルに書き出す...みたいな。これが理論通りにうまいこと動作して、FAXから文書が出てきた時はとっても楽しかったw
ほいノ
高専行こうと思えば行けたんだけど、実家離れるの怖くて偏差値45の工業高校へ。
18歳までフリーター。
18歳〜21歳まで定時制に通った。
英語は個人的にそこそこ勉強したけど、数学なんかはⅠの後のAが半分も終わらなかったレベルのバカ校。
この時期は暇で、なぜかやる気に満ち溢れてたから、TOEIC700近くとか日商簿記2級とか色々資格を取った。
24歳でうつになって、30歳くらいまで日雇い・派遣↔無職を半々くらいでリピートしてた。
やってる仕事は大したことなかったけど、幸い仕事中にPCをめちゃくちゃ使うのでやりたい放題だった。
この時にプログラミングを始めた。
ここで年収どんどん上がった。
36歳でうつが再発して辞めて今に至る。
基本は、仕事で使えそうなもの・必要なものをその都度吸収していった感じ。
Webが中心ではあるけど、組み込みとかのハードが絡む分野以外は結果的に広く浅く手を出してる、つもり。
Excel VBA | 1年 |
VB.NET | 半年 |
JavaScript(Node.js) | 4年 |
HTML | 1年 |
SQL | 4年 |
GAS | 3年 |
C# | 1年半 |
TypeScript | 2年 |
Java | 半年 |
C++ | 半年 |
ラダー、FB(三菱、シーメンス) | 1年 |
実務経験があるって胸張って言えるのはこれくらい。
大体習得順。
他には、Python、Julia、R、Fortran、Rust、Go、Dart、Shell、Deno、CSSなんかは少しずつかじってる。
最近はWebに関してはほとんどJS(TS)で済む感じになったので楽。
なんでPLCが最後やねんってツッコミは置いといて、Web系寄りでラダーも触ってるって人は観測範囲ではあんまりいないので、それが俺の数少ない強み。
RDBはPostgreSQL、SQL Server、MySQL、SQLiteの順で実務経験あり。
NoSQLはFirestoreが実務経験あり、実務なしだとNeo4jとか。
PaaSはGCP(Firebase)、AWSの順で実務経験あり。AzureはADとVM周りをちょっと触った程度。
Dockerはよく使うけどKubernetesとかまでは行ってない。
後は産業用の通信プロトコル的なやつを無駄に色々触ってる。Modbus TCPとかORiNとかCC-Linkとか。PLCもそうだけど、あの辺は日本とドイツとアメリカが未だに既得権益で幅利かせててまじで闇深い。その代わりそれをブレイクスルーできればめっちゃ稼げる分野だと思う。
閑話休題。
フリーターでどんな仕事してるか知らないけど、仕事で一日の半分が無くなっちゃうじゃん?
以下、俺の場合ね。
次長クラスの人が「この製造番号でクレームがあったんだけど、作業当時どんなことあったか覚えてない?」みたいなことをわざわざ現場まで何度も聞きに来るんだよ。
作業したのなんて半年前だったりするから一々覚えてないっすよ、って言ってるのに何度も聞きに来るから、イラッとして仕事用のPCで勝手にExcelで業務日報を付けるようにして、イントラのファイルサーバーに置いて「そういう時はこれ見て下さい。次長の貴重な時間が勿体ないです」って言ったのよ。
それだけでめちゃくちゃ喜ばれる。
で、今度はその次長が「この製造番号どれくらいの時間で作業終わった?」みたいなことを現場までわざわざ何度も聞きに来るから、俺はその時またイラッとして、Excelでストップウォッチもどき作って製造番号とか工程ごとに時間計測して記録して、やっぱりファイルサーバーに置いて「これ見て下さい」って言ったのよ。
それでまた、めちゃくちゃ喜ばれる。
最初はプライベートな時間も結構使ってやってたんだけど、そういう周りに喜ばれる効率化を繰り返してると、少しずつ業務時間内で自分のスキルアップに直結する時間を作れるようになる。
自分でこれ面倒くせーな、効率よくできねえかなって思ったら、じゃあどうやって?てのを考える。
ちなみにPCがなくても、たとえばメールアドレスさえあれば今の時代カイゼンはできる。
大きな会社に勤めてるとかだと使うのが難しいんだけど、IFTTTとかが良い例かな。
これはiPaaSっていうサービスの一種で、まあ言葉の意味は覚えなくて良いんだけど、要は「イベントAが発生したら別のイベントBを起こせ」っていうのを登録して、自動化できるWebサービス。
例えば、あなたが日雇いの会社にいて、毎日違う現場に働きに行くとする。
で、出勤前、現場到着時、勤務終了の時にLINEで毎日報告しなきゃいけないとする。
で、その報告を受けた事務方は、Googleスプレッドシートにその都度入力する。つまり、それだけの為の事務員が一人いる。
面倒くさいし、お金がかかる。
そこで、「特定のグループでLINEを受信したら(イベントA)、特定のGoogleスプレッドシートに情報を記録せよ(イベントB)」っていうのをIFTTTに登録すると、少なくとも事務員の入力の手間は省けるってえ寸法だ。
IFTTTはたくさんイベントを処理させたい場合は有料になっちゃうけど、個人で試すぶんにはクレカ登録しなきゃいいだけだから試してみるといいよ。
月1000円で学べる。コスパは圧倒的。
入門コース(学習に180時間と公称してる)がしっかり理解できていれば、Webで大抵のものは作れる。
ただし、大筋は問題ないんだけど、細かい部分で最新技術をキャッチアップできてない可能性があるので、そこは注意した方が良いかも。
https://www.nnn.ed.nico/pages/programming/
N予備校の入門コース終わらせたら、基本情報技術者か応用情報技術者を取る。
そしたら、職歴書の作り方次第で中小企業の社内SEにはまず転職できる。
中小企業の社内SEは、ITリテラシーの低い社員が多い中で「Excelのセルの色が変わらなくなっちゃったんだけど!」とか「複合機が紙詰まりって言ってるけどその紙が見つからない!」とかクソイージーなクエストをこなすだけでおちんぎんが貰える、人によっては天国、人によっては地獄のような職業だ。
ごめん、流石に言い過ぎた。実情は色々と面倒くさい。DXとかバズワードを聞きかじったクソ重役から突然言い渡される重めのミッションとか。
けど安定なのは間違いない。
N予備校の入門コース終わらせたら、基本情報技術者か応用情報技術者を取る。ここは社内SEと同じ。
生産技術ってのは、誤解を恐れずにすげえ簡単に言えば、カイゼンばっかりやってる人たちのことだ。
あんまり詳しくは言えないんだけど、俺が最後にやっていた仕事は言わば生産技術だった。
で、中小企業の生産技術は、Webに強い人材をかなり欲しがっている。有り体に言うとIoTとかね。
IoTは最近、セキュリティの強化がかなりクローズアップされていて、そのせいで二の足を踏んでる企業が多い。
そこに滑り込むのはアリだと思う。
よく「T型人材」って言われ方をするけど、どっちのスペシャリストの言うこともある程度分かる「橋渡し」的な人材になると途端に貴重になって需要が増すので、上昇志向があるなら「Web+何か」の組み合わせでお金稼ぐのが良いんじゃないかな。
ま、橋渡しって自然とプロマネとか任されがちで、裁量大きくて大変なんだけどね。
質問あればどうぞ。頑張って。
どんな感じでした???
https://shannon-lab.co.jp/?p=9737
昨今ではFacebookが開発したJavaScriptフレームワーク「React」が注目を集めています。Facebook、Instagram、Airbnb等の大規模なサービスから、プロトタイプまで幅広い現場で採用されています。
また、GoogleのBaaS(Backend as a Service)「Firebase」が登場し、バックエンドの開発が不要となり、大幅な開発工数の削減が可能となりました。
Reactにフロントエンド、Firebaseをバックエンドとして採用することで、効率的に質の高いWebアプリケーションを開発することが可能になりました。
しかし、ReactやFirebaseは日本語の情報も少なく、学ぶ機会も限られています。本講座では、React、Firebaseの基礎からアプリケーションの開発までマンツーマンで指導を行います。
ReactとFirebaseの基礎を習得し、演習としてSNSの開発を行うことで理解を深めます。
Authentication基礎と会員機能
Firestore基礎とRDBとの違い
Cloud Storage基礎
Cloud Functions基礎
SNS開発演習1
SNS開発演習2
SNS開発演習3
本講座のメリット
開発からデプロイまで、テストツールを使い実際の開発に限りなく近い環境で学ぶことにより、実践で生きるスキルが身につきます。一人でもアプリの開発ができるようにスキルアップしていけます。
受講費 月7万x6ヶ月=42万円+税
'''
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
342あとで/2882users Amazonプライムビデオで観てほしいおすすめの人気映画42選 ~編集部厳選~ : 映画ニュース - 映画.com
256あとで/1375users 真面目なプログラマのためのディープラーニング入門 | 新山 祐介 | github
233あとで/1341users 実践 Docker - ソフトウェアエンジニアの「Docker よくわからない」を終わりにする本 | ほげさん | Zenn
185あとで/949users ソフトウェア開発の見積もり入門 | hakotensan | Zenn
183あとで/1374users ロシアのウクライナ侵攻の背景を読み解く | 東京大学 | 鶴見太郎
180あとで/968users Google が公開している、より良いデータ分析のためのガイドブック「Good Data Analysis」で、データ分析の要所が簡潔にまとめられていて感動した | hurutoriya
178あとで/1408users フォントが大好物な人に朗報🎉 MORISAWA BIZ UDゴシックとUD明朝がオープンソースになったぞ!! | coliss
169あとで/887users 高木浩光さんに訊く、個人データ保護の真髄 ——いま解き明かされる半世紀の経緯と混乱 | 一般財団法人情報法制研究所出版部
168あとで/958users はじめに – アルゴリズムとデータ構造大全 | take44444 | github
166あとで/1232users ガラケーしか使えないデジタル音痴だった私が「GISでデータ分析」できるようになるまでの話|NHK取材ノート|note
156あとで/728users セキュリティエンジニアが本気でオススメする開発者向けコンテンツ 20選 - Flatt Security Blog
153あとで/1187users iPhone・Macの標準アプリ「メモ」のディープな使い方 | デジタルシニア
153あとで/987users なんとなくプレイしてもそこそこ囲碁のルールがわかるようになる「ぷよ碁」 | Gigazine
150あとで/926users 30代後半になって初めて発信活動を始めたら人生が変わった話 - Qiita
144あとで/1584users ロシアの攻勢と新世界の到来 (2022/02/26): 侵略成功時のロシアの予定稿 全訳 - 山形浩生の「経済のトリセツ」
143あとで/1309users 鶏むね肉を驚くほどしっとりさせた台湾料理「ジーローファン」の作り方【ネクスト魯肉飯】 - メシ通 | ホットペッパーグルメ
141あとで/786users RDBのデータモデリング・テーブル設計の際に参考にしている考え方と資料 | Rebi | Zenn
140あとで/1336users 「依頼された仕事をやらない人」は、なぜあれほど言われても、仕事をしないのか | 安達 裕哉 | Books&Apps
139あとで/891users 「ウクライナ」(2) 小泉悠・東京大学先端科学技術研究センター専任講師 2022.3.9 | YouTube
139あとで/698users テーブル設計の考え方とやり方 [入門編] | 増田 亨 | SpeakerDeck
137あとで/733users オードリー・タン氏が日本人のために「デジタルとITはまったく別物」と語る理由 | ビジネス+IT
137あとで/765users AWS、オンラインロールプレイングゲームでAWSのソリューション構築を学べる「AWS Cloud Quest」公開。実際にプレイしてみた | Publickey
137あとで/909users 手軽に負荷テストができるツール「Taurus」がスゴい | tonchan1216 | Zenn
131あとで/1149users クレカを100万円使って解脱に至るための曼荼羅 - 本しゃぶり
123あとで/587users システム運用アンチパターン | O'Reilly Japan
121あとで/896users 【引越しやることリスト】事前に役立つ知識を50個まとめた | SPOT
119あとで/831users 背景合成アプリ「Shoost」レビュー 映画のワンシーンのような「いい感じ」の絵を手軽に作れる | PANORA
118あとで/724users 電子メール送信に関する技術 | Yuuki Takahashi | Zenn
116あとで/555users 1on1の「話したいことは特にないです」を解決する ~ 共感から始まる関係性改善のススメ ~ / How to solve rejection on 1on1 | 面川泰明 | SpeakerDeck
116あとで/1088users 「強いエンジニアは結局休日に勉強してるじゃん」って思うけど - spice picks
だからもし、法定通貨が打ちのめされてブロックチェーンが覇権をとったら面白いと思う。
RDBのボトルネックを解決するかもしれないブロックチェーン技術というのにもかなり興味を持ってる。
いつかは必ずこっちが勝つとは思うんだけど、、、、
今の界隈に関して少し違和感がある部分に関してまとめておく。
よく批判に挙がる早い者勝ちとかガス代に対する批判は個人的には別にそんなに気にならない。
どんな市場も早い者勝ちだし、ガス代だってある程度歪でも広まっているんだから問題ないし、ビットコインの信頼性を担保に法定通貨が取引されてる現状だって、個人的には全然ブロックチェーンの勝利だと思っている。
それよりも、ブロックチェーン需要はどこにあるのか?というのに違和感がある。
以前からdappsと呼ばれるものには興味があるんだけれど、dappsの多くは需要ドリブンで利用されてるんだろうか??
ゲーム自体が楽しいからやるのではなくて、投機目的でアイテムを手に入れたいとかってゲームをやってたりしないだろうか?
Defiもそう。供給側がたくさんの価値のある通貨を持っていたり、なんらかの市場に対する投機なり投資目的で参入してきていないかな?
ここまでの認識が間違ってるなら間違ってるって教えてほしい。
でも、間違ってないなら、ちょっと供給過多な市場って気がするんだよね。
もちろん、一部では優れたゲームやブロックチェーンベースならではの優れたdefiの仕組みがあるなら教えてほしい。
Braveやaudiusは需要ドリブンになっていそうでおもしろいなぁと思っている。
ウェブサイトの広告以外の収益源はずっと課題だし、アーティストにとってSpotifyやiTunes収益分配は課題だと思う。
ブロックチェーンって需要はこうやってみるとそんなにないかもなぁって気がするんだけど、DXという需要は確実にあるよね。例えば電帳法の改正とかは確実に需要がある。
で、これらって技術的にはブロックチェーンが得意な分野だと思うんだけど、普通のWebアプリで解決しちゃう人が多いと思うんだよね。Web3で解決しようぜ!っていう人も中にはいるかもしれないけれど、需要がWeb3までまだ辿り着いていないんだと思う。
Web3はどんどん盛り上がってほしいと思うけれど、「素人が手を出してこれ全然役に立たない!最悪」って空気にはなってほしくないんだよな。
逆にプロの人にはどういう需要に対して、何を解決できるか?というのを真剣に考えて、いい感じに市場にしてほしいなぁと思います!
おう!外部キー制約を語るとは、RDB を勉強しているのだな?いい心がけだ。増田は外部キー制約があると「どんなメリットがあるか知りたい」のだな?良し、答えてやろう!外部キー制約があると「変なデータが入らない」ということが開発者が『保証』できるのだ。うん、それで?って増田は思うだろう。それで、実例を挙げるけど、sex というカラムを create で作ったときに、そこに insert into で入る値が「男」「女」「その他」というデータに限りたいときが設計者にあったとする。そうすると、「 insert するのは『チンポ』でしょ?」みたいなアホを防げるだろ?もちろん、limit みたいな副クエリで実装しても構わない場合もある。型を指定して、boolean にしたい場合もある。だが、「入るのはこれだけだと思うが、後に追加で変更できる」としたら、嬉しい場合があるのじゃ。まぁ、究極的に OOP や関数型言語、または(古い)命令形言語だと、enum みたいなものなんだよ。いや、だとしたら、enum でよくね?って思うのなら、リプライくれ。答えるから。