  |
はてなキーワード: RUBYとは
https://survey.stackoverflow.co/2018#technology
https://survey.stackoverflow.co/2020#technology
https://survey.stackoverflow.co/2022/#technology
https://survey.stackoverflow.co/2024/technology
| - | 2018 | 2020 | 2022 | 2024 |
| JS | 69.8 | 67.7 | 65.36 | 62.3 |
| Python | 38.8 | 44.1 | 48.07 | 51 |
| TS | 17.4 | 25.4 | 34.83 | 38.5 |
| JAVA | 45.3 | 40.2 | 33.27 | 30.3 |
| C# | 34.4 | 31.4 | 27.98 | 27.1 |
| C++ | 25.4 | 23.9 | 22.55 | 23 |
| C言語 | 23.0 | 21.8 | 19.27 | 20.3 |
| PHP | 30.7 | 26.2 | 20.87 | 18.2 |
| Go | 7.1 | 8.8 | 11.15 | 13.5 |
| Rust | - | 5.1 | 9.32 | 12.6 |
| kotlin | 4.5 | 7.8 | 9.16 | 9.4 |
| Ruby | 10.1 | 7.1 | 6.05 | 5.2 |
| Swift | 8.1 | 5.9 | 4.91 | 4.7 |
| Scala | 4.4 | 3.6 | 2.59 | 2.6 |
変化がわかりやすいように2年ごとにした
JAVAって永遠に人気なのかと思ったけど、10年後人気言語と言えなくなってるかも
PHPはそろそろ厳しい
C#も地味に衰退
Stackoverflow surveyでRubyはもはや消えそうな勢いだぞ
ああ、Rubyか…。君のその気持ち、わかるわ。Rubyって、どこか優雅で深いところがあるけど、その分「速さ」って面では、どうしても物足りなさを感じるよな。まるで、黄金の器で盛られたスープを楽しんでいる最中に、突然お皿が割れてしまったかのような…。でも、そこにこだわり続けるのもまた美学だよ。
かつて、あのレオナルド・ダ・ヴィンチが「精緻さを追求する者は、同時に速度も追求すべきだ」と言ったように、速さを求めるなら他の言語を選ぶべきだという現実があるのは否めない。しかし、ただ速いだけが良いわけじゃない。音楽のように、時には遅さが必要なんだ。バッハが遅いテンポで奏でたフーガの中にも、深い美しさがあるように、Rubyにもその「遅さ」による味わいがあると思うんだ。
ただ、そのうねりの中でも、やっぱり効率を求める場面があるよね。例えば、18世紀の産業革命がそうだった。イギリスの労働者たちは、手作業から機械へと移行していく中で、新たな速度と効率を手に入れた。しかし、その陰にあったのは、肉体的にも精神的にも重い負担だったわけだ。速度を求めることで、得られるものもあれば、失うものもあるってことだよ。
それにしても、「Ruby界隈はカルトが多い」って表現、かなりインパクトあるね。確かに、Rubyのコミュニティは時に宗教的なまでに熱心だけど、その中にも多くの才能と情熱が息づいている。それに、難しいことに立ち向かう姿勢、まるでシェイクスピアの『マクベス』のような壮絶さを感じるよな。でも、君がそれに対して臆してしまうのも無理はない。やっぱり、過剰な熱意を感じると、少し距離を置きたくなるものだからさ。
それでも、君の言う通り、「速さ」を求めるなら、Rubyを使うのはなかなか冒険だ。でも、その「遅さ」に魅力があるし、その遅さの中に隠れた美しさを見つけることもできるんだよ。
ここ1年で初めてはてなブックマーク日毎の総合人気エントリ入りしたドメインからのホットエントリ、ブクマ数順トップ30
| ブクマ数 | タイトル | ドメイン |
|---|---|---|
| 2035 | 日本料理大全/JAPANESE CUISINE ｜ 京都府立大学 | www.kpu.ac.jp |
| 970 | Mac やめて Linux PC を自作した - IT戦記 | amachang.hatenablog.com |
| 811 | 科学的根拠に基づく「健康に良い食事」について｜国立健康・栄養研究所 | www.nibiohn.go.jp |
| 806 | 50代、「1日1捨」を11か月続けて革命が起きた。ものが減る以外の絶大の効果も ｜ ESSEonline（エッセ オンライン） | esse-online.jp |
| 768 | コイン電池、交換不要に 業界初の自立給電型開発 CR2032代替 SMK ｜ 電波新聞デジタル | dempa-digital.com |
| 729 | Google Playの住所公開に開業届で対応する | blog.mrym.tv |
| 607 | 人間をリソースと呼ぶことの何が問題なのか - valid,invalid | ohbarye.hatenablog.jp |
| 581 | 京都府立大学、『日本料理大全』のデジタル版を一般公開 | current.ndl.go.jp |
| 551 | 勉強から研究へ | member.ipmu.jp |
| 514 | 出版のお知らせ 「普通の人が資産運用で99点をとる方法とその考え方」 - hayato | hayatoito.github.io |
| 509 | もうすぐ 40 歳になるが労働を 3 年以上続けられたことがない IT エンジニアの話 - 30歳からのプログラミング | numb86-tech.hatenablog.com |
| 506 | news16 ｜ 株式会社ポケットペア | www.pocketpair.jp |
| 486 | Evernoteの華麗なるリブートとその未来 | lifehacking.jp |
| 479 | ディズニーのゲスト（入園者）が高齢化しているのは年間パスポート廃止だけが原因ではないらしい？ | ppc-log.com |
| 471 | 外部クリエイターによる当社所属ライバーの権利侵害行為等に関するご報告 ｜ ANYCOLOR株式会社（ANYCOLOR Inc.) | www.anycolor.co.jp |
| 457 | AIによってナスカ調査が加速したことで、既知の具象的な地上絵の数がほぼ倍増し、地上絵の目的が明らかになった｜国立大学法人 山形大学 | www.yamagata-u.ac.jp |
| 442 | コードレビュー開発者ガイド | fujiharuka.github.io |
| 417 | 10ギガ・ネットの不必要性(10G詐欺) ｜ www.kosho.org | www.kosho.org |
| 412 | ゲーム情報！ゲームのはなし | gamestalk.net |
| 392 | 【スパイファミリー×かまいたちの夜特別コラボ】スペシャル試し読み | promo.shonenjump.com |
| 388 | なぜ日比谷公園に一万人の陰謀論者が集まったのか - やばいブログ | y-ryukichi.hatenablog.com |
| 360 | 【富裕層】資産1億になって変わったお金の使い方、価値観【FIRE | 2week.net |
| 340 | iPhone 16：バッテリー - Apple サポート (日本) | support.apple.com |
| 337 | 📗 なぜ依存を注入するのか DIの原理・原則とパターンを読んだ感想 ｜ Happy developing | blog.ymgyt.io |
| 337 | なるほどTCPソケット ― Rubyで学ぶソケットプログラミングの基礎 ｜ snoozer05.org | www.snoozer05.org |
| 332 | Parquetフォーマット概観 - 発明のための再発明 | mrasu.hatenablog.jp |
| 322 | 一部報道の件について ｜ ニュースリリース ｜ アイコム | www.icom.co.jp |
| 317 | Xiaomi TV A Pro 43 2025 購入レビュー：「量子ドット」はウソですが･･･コスパは凄い！ ｜ ちもろぐ | chimolog.co |
| 307 | 「SwitchBot CO2センサー（温湿度計）/温湿度計 Pro」国内投入確定 | jetstream.blog |
| 296 | サンルーフはなぜ、採用車種が減ったのか?｜特集｜JAF Mate Online | jafmate.jp |
Ruby全盛期のちょっと後くらいからWebエンジニアをしているんだけど、React.jsがいろんな意味で扱いにくすぎる
関わっている人にもフロントエンドエンジニア(=React.jsしかやりたくない)が多いので毒気で吐き出しておきたい
ライフサイクルや裏側の仕組みをなんとなく理解していないと使えず無意味に複雑
useEffect一つとっても~~の場合はuseStateでいけるとかTIPS集みたいのがあるけど、そういうウンチクみたいなのわかってないと使いこなせないのは仕事増えてない？
仮想DOMで高速化とか言っているけどライフサイクル理解しないと速度でないよね？いつものプロジェクトそんなにちゃんと書けてる？jQueryで良くない？
ベストプラクティス知っててちゃんと設計しないと改修する工数がすごいことになる
そもそもプロジェクトにおいて作るものは都度変わっていくので完璧な設計は存在しない。なので、設計をきちんとしないとカオスになるのはReact.jsのほうが間違っている
React.jsと別のフロントエンドライブラリ比較するだけで空気悪くなるので正直フロントエンドエンジニアの人の前で話せない話題がある
なぜかフロントエンドライブラリをReact.jsしか許さない人が多いのはなぜ
言うまでもないけどNext.jsの記法はひどすぎる。Remixは良いけどそれならもうReact.jsじゃなくていい
数少ないメリットだったエコシステムだけど、もうReact.jsしか対応していないことなんてほぼ無い
フロントエンドリッチでアクセス数ものすごいサイトを運用するのにフロントエンドライブラリが必要だった時代にReact.jsを開発する必要があったのはわかるけど、もっと便利なフロントエンドライブラリあるし正直時代遅れなのを理解してくれ
例えば、俺、CoffeeScriptが嫌いだったんだけど、なんで嫌いかっていうとRubyが嫌いだからなんだけど（諸説あります
でも、頑張ってCoffeeScriptゴリゴリ書いてた人たちっていると思うんだよね
自分はTypeScript登場時からずっとTypeScriptなんだよね
あの、DelphiとかTurbo PascalとかC++ BuilderとかC#の原作者だよ？
しかし、なんだ、こうやって陳腐化していくことがどれほど多いことか、IT関係は
これが理系で機械工学関係だったら、流体力学とか材料工学が陳腐化するなんてないよね？
だから、大学で習う情報工学だとしたら、やっぱりできるだけ普遍的なことを習ってるはずなんだよ
でも、ITはyak shavingが多いよね
本質的な知識を得るために、WindowsやLinux上の環境で学ばなければならないわけで、
落ち着いて情報工学の勉強をするために、Windowsの余計な情報を表示するウィジェットの閉じ方を学ばなければならなかったりする、馬鹿げてるよね
そう考えると、料理、絵、音楽、みんな普遍的なものの集まりだよね
料理の四面体なんてあるけど、煮る焼く炒める蒸すどれも不変な過程だよね
調理器具だって、フライパンや鍋が日進月歩に進化して、以前のバージョンが使えない、なんて買い替え需要を促すための嫌がらせをメーカーがしたりもしない
絵だって、証券用インクとペンだとしても、液晶ペンタブレットだとしても、筋肉の知識とか、パースの知識とか、不変だよね、永遠に変わらないものだよね
まあ、流行の絵柄とかは変わるけど、そういう流行に流されないのも大事だよね
個性がない、ってことは、誰かが絵を見て、これは～さんの絵だ、って気づかれないってことだから、商品価値がなくなっちゃうよね
音楽理論も変わらない、楽器の弾き方も変わらない、正直、ギターなんてどこのメーカー買ったって同じようなものなんだけど、
同じエレキギターを何本も持ってる人っているよね、お金持ちだよね、自分はチューニングがそれぞれ違うギター複数本持ってるけど、それはチューニングのためなんだよね
話を戻すと、ITクソつまらなくなった、の元の文章にもTypeScriptでクソアプリ書いてたときが楽しかったみたいな話があったけど、
俺がMacOSX 10.2だったかで作ったアプリは、現在のMacではまったく動かないからね
だったんだけど、今のWindowsはAppleみたいになっちゃったよね、足切り、足切り、Windows 10は動くけど、11は動かないマシンが大量発生
単体テストというのは、画面を手動で操作してスクリーンショットを撮る仕事だった。エクセルで仕様書を書き、レビューをしていたが、レビューアーはテストケースよりも、枠線の整え方に気を配っていた。
誰かが自動テストを導入しようと言い出した。「再現性がある」「保守性が高まる」「もっと良くなる」と口々に言われていた。
でも、テストコードを開発する工数はどうするのか、開発コードが増えればさらに大変になるのではないかと不安があった。
それでも、これが実現すれば、何かが大きく変わる予感がした。
アプリケーションフレームワークはStrutsだった。フォームをポストする瞬間にカオスが生じ、50行の無駄なコードを書き、100行の読みにくいコードを理解することが技術者の条件だった。
ある人が「レイヤリング」という概念を持ち出し、別の誰かが「DI」と言い出した。アプリケーションアーキテクチャという言葉も登場し、ファウラーという人物の名前も聞こえるようになった。
新しい構造が提案され、それに影響を受けながら、「いつかは美しいアプリケーション構造が生まれるのかもしれない」と夢を抱いていた。
当時、PerlでCGIを作っていたが、PHPやRubyが登場した時は、正直Web"サイト"を作るためのものだと侮っていた。
しかし、次々と洗練されたWebアプリケーションフレームワークが生まれ、StrutsやJavaEEよりもはるかに使いやすくなっていった。
数多くのWebフレームワークの中で、どれを選ぶべきか悩みながら、「いつか完璧なWebフレームワークが現れるかもしれない」と期待していた。
サーバーは冗長化され、ReversProxyを使い、セキュリティのために構成を変更してきた。そしてクラウドが登場し、Dockerなんて本番で使えないと言っていた時代から、
気がつけばどこに存在するのかもわからないクラスターの中で、コンテナアプリが動いている時代になった痛快だ。
かつてLinuxマシン一台を「鯖」と呼んでいた時代から、世界は目まぐるしく変化し続けるとかと思っていた。
誰かがAjaxと言い出し、別の誰かがReactと言い出した。「こんな方法でHTMLを作って良いのだろうか？」と疑問に思いつつも、「Webはアプリケーションだ」という感覚が強まっていた。Webアプリケーションがどう進化していくのか、未来を感じることができた
私たちは、ソフトウェアを開発すること自体に大変さを感じていた。新しい技術やフレームワークが次々と登場し、その都度課題が解決される一方で、新たな課題が生まれる。これほど面白いことはなかった。そしてエンジニアたちには一体感があり、誰もが自分なりの方法で課題を解決し、そのフィードバックループが世界を動かしていた。だからこそ、今は少しつまらない。変化は穏やかになり、「お金を稼ぐ」という目標だけが共通となり、課題は個々の事象に閉じ込められている。しかし、それが悪いことではない。ただ、私たちの時代が変わったのだ。
かつては、私たちの目の前には普遍的な課題があり、それぞれがそれぞれの場所で課題を解決し、そのフィードバックループが世界を動かしていた。
生成AIで例えると、それをどう使うかではなく、エンジニアが一丸となって生成AIをチューニングしていた。世界情勢で例えると、世の中の飢餓を全世界の人がアイディア出して、解決しようとしてたいた。
今でも、普遍的な課題は世界中に転がっているが、それらは高度で、私たちには手が届かないものが増えてしまった。
ITは面白かった。プログラミングが分かるだけで、世界の課題を一緒に解決できる時代だった。それぞれが自分の場所で働くだけで、世界を動かしていた。そんな時代が終わってしまったと感じる。
老害といえば昔話だろ！
