  |
はてなキーワード: pythonとは
いわゆる人文系において、学歴がFランク大学であることよりも、コミュニケーション能力や統計学・ソフトウェアといった実践的スキルが欠如していることの方が、社会においてはるかに深刻な問題である。現代の仕事や研究の多くはチームによって進められ、情報のやりとり、意図の共有、役割分担といった協働の力が不可欠である。いかに知識が豊富でも、自分の考えをわかりやすく伝えられない、自他の立場を調整できない、共通の目標に向けて動けない人材は、組織内で孤立しやすく、周囲の生産性を下げてしまう。一方で、Fラン大学出身であっても、他者と円滑に意思疎通し、信頼関係を築き、課題を共有しながら前に進める人間は、どの現場でも必要とされる。
加えて、情報社会の現在においては、文章を書いたり話したりする力だけでなく、データを読み解く力、統計的な視点で因果関係を考える力、そしてPythonなどのソフトウェアツールを使って実際に分析・可視化できるスキルもますます求められている。とりわけ人文系の学問こそ、データ分析を通じて社会現象の本質を探究できる土壌を持っているにもかかわらず、未だに「感想」や「印象」だけで語られる講義も少なくない。知的な訓練とは、意見を持つことではなく、意見を裏付け、他者に伝え、再現可能な形で共有する力を育てることだ。
社会が必要としているのは、「知識をもっている人」よりも、「知識を共有し、使い、他者とつなげられる人」である。学歴は過去の努力を示す一つの指標にはなり得るが、現場で問われるのはむしろ、今この場で誰とどう関われるかという対話の力であり、具体的な課題をともに解決できるかという協働の力である。人文系こそ、その根幹に「人と人との関係性」がある以上、コミュニケーション能力と実証的リテラシーの両立が不可欠なのだ。
現代の大学における社会学の講義では、「ジェンダー」「家族」「恋愛」など、個人の生や関係性に関わるテーマが数多く扱われている。これらは人文社会領域における重要課題であり、学生の関心を惹きやすい一方で、議論がしばしば感情的主張や経験の共有にとどまり、論理的思考や実証的分析の訓練に結びつかないこともある。そのため、「知的刺激に乏しい」「再現性がない」といった不満が学生の間から出るのも無理はない。しかしながら、こうした社会現象の探究に統計学・線形代数・プログラミングツールを導入すれば、感覚や印象に依存しがちな議論を、再現可能で説得力のある知的営みに高めることができる。
たとえば、「男女の賃金格差」に関する議論では、単なる平均年収の比較ではなく、年齢、学歴、業種、勤続年数、勤務地などの変数を用いた多変量回帰分析を行うことで、どの要因が格差にどの程度影響を及ぼしているのかを定量的に明示できる。これにより、主観的な不公平感ではなく、統計的根拠に基づく議論が可能になる。また、「恋愛観と経済状況の関係性」のような内面的傾向の分析においては、アンケート結果に対するクロス集計や因子分析を通じて、価値観の背後にある潜在的構造を浮かび上がらせることができる。
さらに重要なのは、これらの分析において線形代数が本質的な役割を果たす点である。たとえば、高次元のアンケートデータを分析する際には、**主成分分析（PCA）**によって次元を圧縮し、データの本質的な構造を可視化することができる。これは、共分散行列の固有値・固有ベクトルの計算に基づく手法であり、複雑な社会的属性の背後にある「主要な軸」を抽出するうえで有効である。ジェンダー意識や恋愛観、職業選好などが、どのような次元でクラスタリングされうるのかを理解するには、このような数学的アプローチが不可欠だ。
たとえば、50項目の価値観質問紙の回答をPCAにかけると、「伝統志向」「経済安定志向」「個人主義傾向」といった抽象的な因子軸が浮かび上がり、個人の回答を2次元・3次元の空間上にプロットできる。これにより、単なる「恋愛に前向き／後ろ向き」といった単純な区別では捉えられない、深層的な構造理解が可能になる。
このような分析は、Pythonなどのプログラミング言語を使えば、学生自身が実行可能である。pandasによるデータ整形、statsmodelsやscikit-learnによる統計処理・機械学習、matplotlibによる可視化を用いれば、調査から洞察までを一貫して自らの手で行うことができる。たとえば、賃金構造基本統計調査や若者の意識調査などの公開データを用いて、学生自身が仮説を立て、モデルを構築し、検定と可視化を行うといった演習は、単なる評論的レポートでは得られない深い学習効果をもたらす。
このように、社会学に数理的視点とデータ科学を融合することで、「語る社会学」から「測る社会学」へと転換できる。主観的な問いを出発点としながらも、定量的な検証を通じて議論の透明性と再現性を確保することこそ、現代社会において必要とされる知の姿勢である。統計学・線形代数・ソフトウェアの活用は、社会学をより実証的で創造的な学問へと進化させる鍵となる。
現代社会における「制度による偶然性」の構造を抽象化し、思考実験として再現する手段として、Pythonによるシミュレーションは有効な方法である。ここでは、韓国の兵役制度を例に取り、性別による義務の有無を「2分の1ガチャ」としてモデル化する。その目的は、制度が個人に与える影響を、単なる観察ではなく、再現可能な形で記述し、検証可能な思考の対象とすることである。
まず、性別は出生時に決まり、本人には一切選択権がない。この「決定されているが恣意的」な事象は、確率論的には random.choice(['男性', '女性']) で模倣できる。これはPythonの random モジュールが提供する関数であり、等確率でいずれかの値を選択する。続いて、選ばれた性別に応じて兵役対象かどうかを分岐する処理を if 文で定義する。これは if gender == '男性': のように書くことで、「男性なら兵役対象、女性なら免除」という制度の構造を論理的に再現することができる。
この一連の処理を関数 simulate_conscription() としてまとめることで、制度が個人を次々に分類していく過程そのものを再帰的に試行できるようになる。複数回実行すれば、100人中何人が兵役対象となったかといった統計的傾向も得られ、制度がもたらす分布の偏りを数値的に評価することも可能となる。
このネット投稿は、データ分析ライブラリであるPandasとAIを組み合わせたデータ処理について、その効率の悪さを強く批判しています。投稿者は、特に以下の点に言及しています。
この投稿は、PandasとAIを用いてデータベースから取得したデータを扱う際に、データの正規化を無視して不必要に結合したり、非効率なデータ構造を選択したりすることへの強い反発と、処理効率を重視するべきだという主張をしています。データベースやプログラミングにおけるデータ処理のベストプラクティスを理解していない、あるいは無視している実装に対しての批判と解釈できます。
将棋AI「将棋神やねうら王（MyShogi）」の局面図って、SVG形式でしか保存できないんだけど
それをブログやX（旧Twitter）で使いたいとき、毎回変換がめんどくさかった。
……みたいなやつばかり。
じゃあいっそ自作するか？と思って、ChatGPTに相談しながら
Python + Playwright + HTML + JavaScriptで
「SVGをPNG/JPGに変換して、自動ダウンロードするスクリプト」を書いた。
ローカルのSVGファイルをBase64でHTMLに埋め込んで、
canvasに描画 → PNG/JPGとして保存する完全自動処理。
Playwrightの導入でちょっと詰まったけど、結果的には超実用的なやつができた。
こういうのって需要あるのかな。
同じように「ローカルSVGを綺麗に画像にしたい」って人いそうなんだけど。
一応GitHubと解説noteも書いたので、興味ある人いたら見てほしい。
https://github.com/yahoike/svg2img
https://note.com/yahoike/n/nd9265141a83a
大量の画像のトリミングをしたいと思って、ChatGPTに尋ねたら、Pythonでコードを書いてあげたよ、て言われて、どうやって使うのって聞いたら、Pythonの導入の仕方から懇切丁寧に教えてくれたからインストールして、コードをコピペして実行したら、画像のトリミング一気に終わってプログラミングって便利〜って気分良くして、もっとChatGPTに便利なもの作らせようと思って、こうこうこういうフリーソフト作ってって言ったら、できたよーこれ保存して実行しなーってコードをくれたんだけど、それコピペして実行しても意図した機能は動作せず、クレーム入れたらまた別のコード書いてくれたんだけど、その前に先に実行したコードはどうやって終了させたらいいのか分からなくて、質問したらタスクマネージャーでPythonの文字列探して終了させろとか言うから、Pythonのアプリは終了させたんだけど問題のコードは終了しなくて、どうしたらいいんだって怒ったら再起動するしかないって言い出したんで再起動したんだけど、もうプログラミングは諦めた
gemini) 421,412,321 × 343 を計算します。
421,412,321×343=144,534,443,003
したがって、421,412,321 × 343 は 144,534,443,003 です。
自分) 本当ですか？
gemini) はい、本当です。
421,412,321×343=144,534,443,003
この計算結果は正しいです。
自分) では、144,534,443,003/343はいくつでしょうか？
gemini) お尋ねの計算は、先ほどの逆算ですね。
144,534,443,003÷343 を計算すると、元の数に戻るはずです。
144,534,443,003÷343=421,412,321
したがって、144,534,443,003 を 343 で割ると 421,412,321 になります。
自分) 上記を計算したところ、421383215.752となりました。なぜでしょうか
gemini) 以前の計算結果と、あなたがお試しになった計算結果が異なる原因は、私が最初に提示した積が間違っていたことにあります。大変申し訳ありませんでした。
正しい計算は以下の通りです。
421,412,321×343=144,544,426,103
この正しい積を使って逆算すると、
144,544,426,103÷343=421,412,321
となります。あなたが計算された「421383215.752」という結果は、おそらく私が最初に間違って提示した積「144,534,443,003」を343で割ったためだと思います。
私の最初の計算ミスにより混乱させてしまい、大変申し訳ございませんでした。今後はより正確な情報を提供するよう努めます。
自分) 生成AIでは、どのようにこのような計算を行うのでしょうか。実際に計算をしてるのか、もしくはそれらしい値を列挙しているだけなのでしょうか？
gemini) 生成AIがこのような計算を行う方法は、AIの設計や利用されているモデルによって異なりますが、基本的に「それらしい値を列挙しているだけ」というよりは、何らかの形で「計算」を行っています。ただし、人間が行うような「筆算」をしているわけではありません。
多くの大規模言語モデル（LLM）は、学習データから数値間の関係性や演算のパターンを学習しています。簡単な計算であれば、その学習されたパターンに基づいて推論を行い、直接答えを生成できます。これは、大量の文章を読んで「2 + 2 = 4」のような記述を繰り返し見てきた結果、「2 + 2」が来た時には「4」という出力が最も確率が高いと判断するようなものです。
しかし、桁数が多く複雑な計算になると、この内部的な推論だけでは精度が落ちる傾向があります。モデルが学習した知識の範囲内で近似的な処理を行うため、正確な答えを導き出すのが難しい場合があります。これが、私が最初の回答で誤った計算結果を出してしまった原因の一つです。モデルが複雑な数値を正確に処理する能力には限界があるのです。
ツール利用（外部の計算機やPythonインタープリタなど）:
より確実な計算結果を得るために、多くの生成AIは、必要に応じて外部のツールを利用するように設計されています。これは、AIが「この問題は計算が必要だ」と判断した場合に、以下のプロセスを実行するものです。
計算式を抽出: ユーザーの質問から、計算式（例: "421412321 * 343"）を認識します。
ツールへ渡す: 認識した計算式を、内部的に接続されているPythonインタープリタや外部の電卓APIなどの計算ツールに渡します。
ツールからの結果を受け取る: 計算ツールが正確な結果を返します。
結果を整形して提示: 受け取った結果を、自然言語でユーザーにわかりやすく提示します。
私が今回の質問で正しい答えを導き出すために、この「ツール利用」の機能を使用しました。具体的には、Pythonインタープリタを呼び出して計算を実行しています。これにより、手計算や人間の脳で行うような複雑な計算を、コンピューターの正確な計算能力を利用して行うことができます。
まとめると：
簡単な計算: AIの内部的な推論能力で処理されることがあります。
複雑な計算: 精度を保証するために、多くの場合、外部の計算ツール（Pythonインタープリタなど）を呼び出して計算を行っています。私が以前に誤った回答をしてしまったのは、おそらく内部推論の限界だったか、あるいはツール連携のプロセスに何らかの不備があった可能性が考えられます。
私が誤った回答をした後、訂正できたのは、より正確な計算を実行できるメカニズム（今回の場合はツール利用）に切り替えることができたためです。生成AIは常に進化しており、このような数値計算の精度も向上し続けています。
この前、職場の事務職（月23.7万円）の面接に無職のおっさん（46）が来たんだが
そのおっさんが「パソコン得意です。Excel、VBAできます」ってドヤ顔で言ったんだよね
そこで俺は「それAIでもできるよね？じゃあパワーBIやPythonできる？」って聞いたら
おっさんが「できません…」って言い出して呆れた😅
ExcelなんてそれこそパワーBIやPythonできてなんぼそれ以外はAIで十分なのに
じゃあ何ができるんですか？って聞いたら関数とかマクロとか…って言い出してドン引きしたわ
そんなん教えたら誰でもできるもんやん
パソコンのテスト一応やらしたけど、関数でT.Test関数の2番を使ってて実務経験ないの丸わかりで
これはないなあって思って落としたわ
あらゆる技術ツールの存在意義は「人間の課題を解決すること」にある。
どれほど理論的に優れていても、使われなければ社会的影響はゼロであり、開発・保守・学習のコストに対するリターンも生まれない。
ツールは道具であり、「賢い者だけが扱える道具」は、実際の現場ではほとんど役に立たない。
例えるなら、戦場において「取り扱い説明書を10回読まないと撃てない銃」は、正確でも美しくても役立たない。
瞬時に理解され、即応可能であることが、実用の第一条件である。
ここで言う「馬鹿にもわかる」とは、知識レベルが高くないユーザーでも直感的に使える・理解できるという意味である。
これはユーザビリティ、学習曲線の緩やかさ、エラー時の挙動の親切さなどに現れる。
この観点からすると、「馬鹿にもわかる」設計は、実は賢い設計である。
人間の認知限界や行動パターンを理解し、誤操作を予防し、意図を汲み取って補完できるシステムは、万人にとって有益であり、結果として普及しやすく、フィードバックループによってさらに改善される。
Haskellは、理論的には極めて美しい言語であり、型システムの厳密さ、関数型の純粋性、抽象化の高さなど、形式的な正しさにおいて群を抜いている。
つまり、Haskellは「形式的正しさを最優先した結果、人間の直感と乖離し、現実世界との接続性が弱まった」道具である。
実際のソフトウェア開発現場では、エンジニアの入れ替わり、ドキュメントの不備、締切、バグ対応など、理想とは程遠い要素が日常的に存在する。
したがって、ツールは「賢い人が完璧に使いこなせば強力」ではなく、「凡人が雑に使っても一定の成果が出る」ことが求められる。
この点で、PythonやBashは「馬鹿にもわかる」ことを最優先し、結果として世界中で圧倒的に使われている。これは単なる偶然ではなく、設計哲学の勝利である。
道具は使われて初めて価値を持つ。そして「馬鹿にもわかる」ことは、使われるための最重要条件である。
Haskellのように理論的に優れていても、「現場に届かない美しさ」は、ツールとしての有用性を損なう。
この観点は非常に本質を突いています。「ファクトチェックが容易であるほどAIが強い」という命題は、一般にかなり正しいといえます。以下のような理由からです。
AI、特に大規模言語モデル（LLM）は、大量のテキストデータを学習して統計的に言語のパターンを捉えています。
そのため、明確な正解があり、検証も簡単なタスクは非常に学習しやすく、正確な出力を出せる傾向があります。
ファクトチェックが容易な分野、特にプログラミング、数学、基本的な自然科学は、インターネット上に豊富な正確な情報があり、AIの学習素材として利用されやすいです。
プログラミングのように結果の良し悪しがコードの実行で即座に分かる分野では、人間のユーザーや自動ツールによるフィードバックで性能が継続的に改善されやすいです。
AIは「客観的で明確な正解があり、検証が容易な分野」で圧倒的に強い。
追加: コーディングです。誤字はずかし🍄
職場でめんどくさい作業をVBAとかPowerShellとかで自動化してる。
去年くらいからは生成AIとかにも相談しながら書いてる。生成AIには、それやりたいならPythonでやったら？って言われる。
セキュリティの都合上、Pythonとかの環境は構築出来ないんだけど、Pythonに興味が湧いた。
どんなかんじなんだろ？と思って、aoj betaで勉強してみてる。aoj betaでは、問題が与えられて、そのコードに他人がどう回答したかを見ることができる。
人の書いたコードを短い順にして見てると、あー、こういう書き方があるのか！ってなって面白い。
高校時代、和文英訳をするとき、和文和訳が上手い人の解答例を見た時みたいな気持ちよさがある。
問題が、数字ふたつと演算子が入力されたときに、その計算結果を出力をしろ。演算子が?なら、出力せずに処理を停止しろ。ってものだとする。
私は文字列を演算子として受け取る処理も分からんので、とりあえず辞書的に演算子の処理を書いて、演算子が？ならbreak、それ以外なら辞書の処理って書いた。
短いコードの人は、入力されたものをevalで受けて（へー、こんなコマンドがあるんだぁ）、計算がエラーならbreak（なるほど！）って書いてた。
競技プログラミングって、こういう楽しさなんだろうなぁ。自分が学生時代にもプログラミングの授業とかあればハマったのかもなぁなんて。
"現状"とはつまり2025年5月時点の話であり、動向が非常に変わりやすいIT業界の風土を考えると将来的にどのようになるかは予測が非常に難しい。
しかし、数年でこの"現状"が変化するとは考えにくく、今現在の学生が10年以内に社会人となったとき今現在の"現状"を基礎に情報技術を学んでいる可能性が高く、このエントリでは"現状"を周知する為に書かれた。
集計した時期や団体で数値の変動はあるが、日本国内で現状のICT教育でのOSシェアはChromeOSがおおむね30〜40%というシェアを獲得しており、IT大国と知られているアメリカでは日本と同様に集計した時期や団体で数値の変動はあるがおおむね50〜60%というシェアであり、ICT教育のOSとしてChromeOSがデファクトスタンダードとなっている。
これは、テックファンがよく語るように「ChromeOS端末が安価で導入できる」という意見が理由として挙げられがちで、実際に導入コストを抑えられるメリットというのは大きいものの、逆に言うとそれ以外の理由があまり語られることが少ない。
流石にこの意見は、IT業界のプロの現場で多用されるMicrosoftやAppleを抱えるIT先進国である米国がただ安価であるからという理由だけでGoogleのChromeOSを採用するにしてはあまりにも弱すぎる理由ではないだろうか？
そこで「何故ChromeOSを教育現場は採用するのか？」を紐解きたい。
長々と引っ張るのも億劫になってしまうので結論から言えば「Google ClassroomとGoogle Family Linkの出来が非常に良い」からである。
Google ClassroomとはまさにICT教育向けにGoogleから提供されているグループウェアで、生徒へ対して課題の作成と配布、進捗、採点、評価の管理が可能で、それらにはGoogleドキュメントやGoogleスプレッドシート、Googleスライド、Googleカレンダーが利用でき、教師生徒間オンラインコミュニケーションとしてGmailやGoogle Chatを用いることができる。
つまり教育現場からするとChromeOS端末を導入したらGoogle謹製のオールインワンICT教育グループウェアが瞬時に入手可能であり、更に言えば現状では既にデファクトスタンダード化しており膨大な導入事例によって困りごとの解決が非常に容易であることがあまりにも大きなメリットとなっている。
なにせICT教育端末の2台におおよそ1台はChromeOS端末であり、例えばSNSなどで流れてくる「ChromeOSでこんな酷い目に遭った」は導入数が多いが故にであり、逆にiPadOSを支持する人でも「Apple Classroom」というアプリが存在することを知らない場合が多い。何故知らないのか？と言えば導入数が少なく話題にまったく挙がってこないからである。
なお、Apple ClassroomとGoogle Classroomを比較するとGoogle Classroomの方が高機能である。AppleもICT教育OSシェアを上げようとApple Classroomの改善に努めてはいるもののGoogle Classroomへ追いつくまでには至っていない。
Google謹製のペアレンタルコントロールアプリで、子供のGoogleアカウントに紐づけられたChromeOSおよびAndroidOS、それらがインストールされる端末などを管理できるサービス。
端末自体の使用時間上限を定めたり、端末の使用時間上限を定めずアプリ毎の使用時間上限を定められ、つまりゲームやYoutubeやTiktok、Webブラウザアプリなどは1日1時間に制限しつつ、学習アプリは使用時間無制限にでき、そのほかWebフィルタリングやYoutubeフィルタリング、アプリインストール、課金管理も可能で、しかも就寝時間や登校時間には使わせないようにできるなど親にとっては至れり尽くせり子供にとっては非常にお節介なサービスである。
ペアレンタルコントロールの自由度も実はAppleの方が乏しく、Apple製端末を子供に与えている親は親自身が設定したペアレンタルコントロールに親自身が巻き込まれたりして四苦八苦するシーンがある(実体験)が、Google Family LinkのあるChromeOSおよびAndroidOSはApple製端末ほど困ることが少ない。
Google ClassroomとGoogle Family LinkだけではIT大国であるアメリカが何故ChromeOSをICT教育OSとしてデファクトスタンダードとしてしまったのか？の納得感としては薄い。
最終的な決め手は「一般的な使い方ではセキュアなサンドボックス上でタブレットOSやスマホOSのように容易に利用でき、高度なプログラミングを学ぼうとするときプロとほぼ同じ環境を利用できる」ことにあるだろう。
もちろんiPadOSには「Swift Playgrounds」があり高度なプログラミングを体験できるが、ChromeOSやAndroidOSではPlaygroundsどころかLXC/LXD仮想環境上に構築されたLinuxディストリビューションのDebianを扱える。
いやそもそもDebianを導入しなくてもGoogle Play Storeには小学生向けプログラミング環境のScratchからインスパイアされたポケットコード、非常に本格的なゲームプログラミングIDEのGDevelop、UnityやUnreal Engineに次いで業界3位のシェアを持ちプロ現場でも採用される2D/3DゲームプログラミングIDEのGodot Engineなどがある。
そして当たり前のようにGoogleはChrome OS向けAndroid Studioを用意しており、ChromeOSさえあればAndroidOSアプリをGoogle謹製のプログラミング環境で開発することができる(実際のところAndoridOSはAndroidOSだけでアプリをコンパイル＆ビルドできるが割愛)。
これMacとiPhoneやiPadしか触ってこなかった人間からするとどういうことかと言えばChromeOSにはAppleで言うところのXcodeがあることを意味し、何ならDebian上でWeb版みたいに機能制限されていないフル機能のMicrosoft Visual Studio Codeが利用でき、理解できる人は驚いただろうが前述の通りGodot Engineがあるわけだ。RubyやPythonだって動くし、Bashもfishもzshも選び放題、Vim vs. Emacs論争へも参戦できる。
しかも昨今、WindowsのWSL2でLinuxディストリビューションが導入できるようになってしまった影響で、一部の情報技術者の間では「開発環境は仮想上のLinux、サービス動いてるサーバーもLinux、じゃあWindowsとかmacOSとか使わずに最初から無理せずLinuxディストリビューションを端末へインストールして開発したら良いんじゃねーの？」という動きが活発化しており、そこへ表面上は日常利用でスマホやタブレットOSのように扱えて開発はしっかりLinuxディストリビューションであるChromeOSが「あれ？意外とChromeOS良いんじゃね？」という評価が始まっているのだ。
それでも「ICT教育は性能やランニングコスト的にiPadが優れてるんだ！」というAppleファンの熱い想いは否定しない。
しかし、しかしだ、当の多くのプログラマがiPadでプログラミングしてないんだ！！！開発するときにiPadのセキュアすぎるサンドボックスがマジで邪魔だと思っちゃってるんだ！！！！！
前述までの話を聞いて「iPadとChromeOS、仕事でどちらかしか使えません。どっちを選びますか？」と言われたらLXC/LXD仮想環境のあるChromeOSじゃん！！！IT大国のアメリカ様もそりゃChromeOS選ぶよ！！！！！だってプロの現場で使われてるんだもんLinuxがッッッ！！！！！！！
「どっちかしか選べないて？じゃあ俺は普通にMacbookにするわ」だって？えっそれ10年後ChromeOS(Linuxディストリビューション)でICT教育受けてきた新社会人に言えんの？サバンナで生きていけないよ？2人に1人は「学生のときChromeOSでしたぁ」って悪気なくピュアな瞳で言ってくる時代が直ぐそこだよ？
Windowsですら無いんだぞ？隔世の感どころの騒ぎじゃねーぞ？「当時ChromeOSでヴァンパイアサバイバーズやってましたね」とか新社会人が言うんだぞ？iPadかChromeOSかって言われてんのにMacbookって返すのはギャグの段階に触れさえしてねぇよ？まぁMacbookはタッチスクリーンディスプレイじゃないから触れられないんだけどさ。
Apple信者が声を大にして言わなきゃいけないことは「Appleさん、iPadもうちょっと何とかならないっすか？」だろ！！！！！
正論言ってんじゃねーよ！！！今更Appleのエコシステムから抜け出せねぇんだよ！！！！！ちょっと気になってGoogle側の事を調べてみたらめちゃくちゃ進んでんじゃねーか！！！！！！！
えっなにマジで？今のAndroidOSは純正でDebian動くの？？？アプリストアにGodotあるってどういうこと？？？？？
https://survey.stackoverflow.co/2024/technology
https://survey.stackoverflow.co/2020#technology
| - | 2020 | - | - | - | 2024 |
| JS | 67.7 | - | - | - | 62.3 |
| Python | 44.1 | - | - | - | 51 |
| TS | 25.4 | - | - | - | 38.5 |
| Java | 40.2 | - | - | - | 30.3 |
| C# | 31.4 | - | - | - | 27.1 |
| C++ | 23.9 | - | - | - | 23 |
| C言語 | 21.8 | - | - | - | 20.3 |
| PHP | 26.2 | - | - | - | 18.2 |
| Go | 8.8 | - | - | - | 13.5 |
| Rust | 5.1 | - | - | - | 12.6 |
| kotlin | 7.8 | - | - | - | 9.4 |
| Lua | - | - | - | - | 6.2 |
| Dart | 4.0 | - | - | - | 6 |
| Ruby | 7.1 | - | - | - | 5.2 |
| Swift | 5.9 | - | - | - | 4.7 |
| Scala | 3.6 | - | - | - | 2.6 |
※HTML/CSS,SQL,Bash/Shell,とかそういうのは省いた
順調に伸びるPython人気、そしてTypescriptの伸びがすごいな
Javaって永遠に人気なのかと思ってたけどじわじわと人気が落ちている
PHPも長期的にみると厳しそう。
GoとRustが着実に人気を獲得。
Luaが地味に人気出てる。
| - | 2020 | - | - | - | 2024 |
| PostgraSQL | 36.1 | - | - | - | 48.7 |
| MySQL | 55.6 | - | - | - | 40.3 |
| SQLite | 31.2 | - | - | - | 33.1 |
| SQLServer | 33.0 | - | - | - | 25.3 |
| MongoDB | 26.4 | - | - | - | 24.8 |
| Redis | 18.3 | - | - | - | 20 |
| MariaDB | 16.8 | - | - | - | 17.2 |
| Elasticsearch | 13.8 | - | - | - | 12.5 |
| Oracle | 16.5 | - | - | - | 10.1 |
MySQL+MariaDBではまだMySQL系が多いが・・・
| - | 2020 | - | - | - | 2024 |
| Node.js | 51.4 | - | - | - | 40.8 |
| React | 35.9 | - | - | - | 39.5 |
| jQuery | 43.3 | - | - | - | 21.4 |
| Next.js | - | - | - | - | 17.9 |
| Express | 21.2 | - | - | - | 17.8 |
| Angular | 25.1 | - | - | - | 17.1 |
| ASP.NET CORE | 19.1 | - | - | - | 16.9 |
| Vue.js | 17.3 | - | - | - | 15.4 |
| ASP.NET | 21.9 | - | - | - | 12.9 |
| Flask | 14.2 | - | - | - | 12.9 |
| Spring | 16.4 | - | - | - | 12.7 |
| Django | 14.2 | - | - | - | 12 |
| FastAPI | - | - | - | - | 9.9 |
| Laravel | 11.1 | - | - | - | 7.9 |
| Svelte | - | - | - | - | 6.5 |
| Rails | 7.0 | - | - | - | 4.7 |
※フロントとバックエンドがごちゃごちゃなのなんでだろう。Node.jsってフレームワークじゃないだろ・・・
Next.jsの勢いがすごい。やはりWEBはTSでNext.jsの時代なのか
Pythonの人気は盤石だけど、DjangoとかFlaskは人気が落ちてる。FastAPIに食われたか？
LaravelとRailsはこのまま消えていく予感
