  |
はてなキーワード: Ruby on Railsとは
----
「My Job Went To India」の改題改訂版が「情熱プログラマー」なんだ！ありがとう発注したわ。（たぶん達人プログラマーと混同して読んだ気になって読んでないパターンだわ）
俺の悪文のせいで意図が伝わらなかったであろうブコメがあったので、要旨だけ書き直しておくな。
ただ忘れないで欲しいんだけど、TerraformメンテしてAWSとかGCPで立ち上げてサービス公開するまでの速度は、相見積取って稟議通して部材調達から入ってた時代に比べると爆速だけど、人間の技術屋の需要は増えてる。
俺は、「マスタリングTCP/IP 入門編」を人間が読んで理解するのは古いよね、という時代にはならないと思ってる。
Slerが自前で手元で試すようになるから～ってのも懐疑的。SIerやメーカーが内製すると必ず子会社作って分離、ぼく発注者きみ受注者にしたがるので。これは技術じゃなくて感情とか経営の問題。
（ただし、Slerが7payみたいなことやらかすのでは？って疑問なら同意。たぶんそういう生成AIで俺たちでプロダクトなんか簡単に作れるじゃんよギークいらね（仕様バグあり）は一時は増えるだろうね）
追記ここまで
----
VibeCodingでIT技術者は不要になるのか？という話題が花盛りなのは理由があります。
ギーク（現場でコードを書いていたい人）が分かる話から、スーツ（人を集めたりお金を集めたり営業をする）が分かる話になってきたからです。
具体的に言うと、OpenAI社をはじめ続々とTDD(テスト駆動開発)でやってますみたいな、具体的な開発スタイルの話が出てきたから。
そうすると、現場の座組チョットワカルという強めの経営者が理解して判断し始めるんですね。
でもね、その道はもう15年も昔に我々は通り過ぎました。前回のブームと何が違うでしょうか？
技術者なら電子も機械も強電も弱電もお世話になったことのあるオーム社が過去に出していた直球の本の話から。
「My job went to India : オフショア時代のソフトウェア開発者サバイバルガイド」という書籍、何と発行年は2006年です。
かいつまんで話すと、インターネットが整備され、輸送コストがほとんどかからないソフトウェア開発では、アメリカのエンジニアは給与の面でオフショアに歯が立たない、だって、1/10の給与でインドのエンジニアは働くんだぜ？という本です。
そうした、価格競争力で負けるアメリカのソフトウェアエンジニアは、如何にして今後サバイブすべきなのか、という本になっています。
（普通に面白いしAIコーディング時代に通づるものがあるので復刊を希望したいところですが、まあ直球過ぎる題名を何とかしないと再販は無理でしょうな）
そして、JTCや外資問わず、過去にオフショア開発を経験された技術屋のみなさんははてブにも多く生息されているでしょう。
では、ジュニア開発者は不要になりシニア開発者のみになって、いまのソフトウェア開発は主に安い給与で働いてくれるところに遠隔で作業してもらって、レビューだけすれば良い環境ですか？
そうはなっていません。なぜでしょうか。
さて、今普通にXと連動する中古品売買プラットフォームを開発しようと思ったら、どうやってつくるでしょうか？
この文脈に埋め込まれたいくつもの情報「今」「普通」「連動」「中古品」「売買」「プラットフォーム」「開発」を解釈し、すり合わせ、未来の運営者も含めた全員に伝えるためのコストが、コミュニケーションコストです。
そうなると、「ちょっと良い感じにラフでいいからプロトタイプ作って持ってきてよ」で話が通じるのは、受注者マインドがしっかりした日本の受託開発現場の精鋭たちになるわけです。
テストケースだけを通過するように、内部テーブルを持たせた関数を大量に持ってこられてレビュー時に頭を抱えた経験が無いひとは、とても幸運なのです。
とは言え、これは何も文化の違いに起因するだけではありません。仕様とは、環境によって定まるものだからです。
例えば、うるう年判定の関数は、1581年以前をエラーにしますか？1873年以前をエラーにしますか？（ヒント：明治六年）
テスト駆動開発、古い言い方で言えばテストファーストの考え方は、成功したすべてのプロダクトで例外なく、ただの一つの例外もなく、必ず最初から取り入れるべきだったものです。
品質は最後に振りかける粉砂糖のようなフレーバーではなく、最初から設計に組み込むべきだからです。
ありとあらゆる趣味において、最初から良いものを使えば時間を無駄にせずに済んだ、と言われるような初期投資の大切さが説かれます。
果たして本当でしょうか？
そうです、その趣味にハマって生き残りサバイブした人から見れば、過去にその時点で投資をすべきだった、というのは正しいのです。
その趣味にハマれなかった人からすれば、少ない投資で自分に合わないことが分かったという合理的な選択であることと矛盾しません。
そのため、全ての失敗したプロダクトは、テストケースを書く時間でプロダクトを作り上げて、さっさと世に問うべきだったわけです。
少し昔話をしますが、オフショア開発において重要なのはドキュメンテーションとテストケース、それにレビューでした。
他の部署で失敗しつづけていたオフショア開発のやり方は、端的に言えば"教化"でした。
具体的には書けませんが、グッとお安い単価の国に出す仕事を、日本の会社に出すのと同じようにすべく、相手の会社のメンバーを教育して仕立て上げるブートキャンプの仕組みを作り上げていました。
発注側を変えずに済むように受注側を教育して、日本の会社に出すのと同じように単価の安いところに出せたらお得ですよね？でもこれは必ず失敗します。
何故か。だって、日本の会社と同じように働けるようになったら、日本の会社に就職するじゃないですか。少なくとも価値は上がったんだから単価を上げるように交渉しますよね？
結局のところ、当初言われていたような劇的な節約にはつながらないわけです。それなら下手に転職されるよりも自前で現地工場でも立てて地元に貢献しつつ雇用を創出した方が喜ばれるし持続可能です。
小なりとも成果が上がった方法は、フィードバックを相手ではなくドキュメントにした場合でした。
例えば先ほどの例で言えば、テストケースは通るが意図したコードにならなかったとき。
「普通はこういう意図でコードを書くから、テストケースを通るにしても、関数は次からこう書いて」というのが、相手に対するフィードバック。
「関数を書く前に、関数の意図をコメントで残して、レビュー時にはそれを見ましょう」というプロセスの修正が、ドキュメントへのフィードバック。
こうすると、担当者が退職していなくなっても、次の担当者はその方法を参考にすれば良いわけです。
これ、何かに似てませんか。現在のAIコーディングのベストプラクティスと呼ばれるものに非常によく似ているんです。
つまり、オフショア開発というのも、設計と実装が分離できるという前提に立って動いていたんです。
そして、実装しながら設計しても問題ないとする場合、それは「技術的な問題」ではなく「組織構造」に起因します。
つまり、プロダクトの構造を分割して、オフショア開発側に設計と実装とを委譲して、実装しながら設計を変えてもらうことが許容できるのは、契約や責任分界点、輸出入の法規を含めた法務の領域です。
少なくとも当時、諸々をクリアにして相手側にプロダクトの一部を荒い設計と共に切り出して、コーディングしながら再設計してもらい、テストケースを完備したコードとドキュメントを共に完成までもっていってもらったことは、大きな成果であったはずです。
（当時日本側と仕事をしたという実績があると大きな実力があるとみなされたと聞いたので、今はより良いところで良い仕事をされていると思います）
（あと、コミュニケーションコストと輸出入の関連法規が複雑だから）
少なくとも、納期までに契約したこれを納品してください、という枠組みの中では、実装作業だけ切り出すことはできない、というのが教訓として残ったはずです。
少なくともあと数年、場合によっては10年スパンで、日本ではほとんど変わらないと予想しています。
これは技術の話ではなく組織構造や、もっと言えばお仕事の進め方と契約の話だからです。
そうは言ってもジュニアエンジニアの簡単な仕事が減って成長機会が失われているのは事実では？と思うかもしれませんが、そもそもの前提が誤っています。
未経験（弱経験）者を雇って戦力まで鍛え上げる必要があるなら、AIに仕事渡してないでそのジュニアエンジニアにやらせるべきなんです。
ジュニアエンジニアとAIと両方にOJTさせて、その違いをレビューの場でフィードバックしてジュニアを育てるわけです。
もし、そんな時間は無いというなら、元々ジュニアエンジニアをOJTで育てていたというのは幻想です。
（たまに、失敗が経験になるとして、会社に損害を与える方法でジュニアを"教育"しようとする人がいますが、商習慣的にも信義則違反ですし言語道断です）
シニアエンジニアだけで事足りるとしてジュニアエンジニアを雇わなかった企業は、シニアエンジニアが抜けてガタガタになります。
これは中核エンジニアがゴッソリやめた会社が傾くなんて言う話で、昔からそうです。（たいてい、もっと人雇ってくれ待遇上げてくれみたいな悲鳴を圧殺した結果だったりします）
昔から、中堅がやれば手早い仕事を新入社員にやらせて鍛える、その代わり質は悪いし時間もかかるしフォローも必要だったわけでしょう。
AI時代が到来するとしても全く同じです。AIが出力するコードレビューで悲鳴上げてる場合じゃないんですよ。
レビューできるシニアエンジニアが足りなくなると予想されるなら、当然、ジュニアエンジニア雇ってレビューできるようにする必要があるんです。
そしてそれは、技術的な問題点ではなく、組織的・経営的な決断です。
国産LLM開発の文脈でもそうなんですが、ハードウェアの進歩を無視して話をする方が多いのが気になります。
現時点のコンピューターパワーは、10年後には手の届く価格になる可能性が十分高く、もっと言えば20年後には個人が所有する可能性すらあります。
いまから20年前の2005年は、Youtubeが誕生した年です。その時に、誰もがいつも手元にビデオカメラを持ち、即座に動画を世界に公開できるようになるとは思っていなかった頃です。
今もそうだと思いますが、ある分野で必要な性能にはもう十分という期待値があり、10年経てばある程度大きな会社の部署単位で現在最先端のコーディングAIがローカルで動くようになると想像するのは容易です。
そうなったときに、果たして営利企業が、エンジニアを育成するというコストを支払うかといわれると、疑問です。その時点で今後のリアルなコストと比較対象可能になるので。
だって、筆耕担当者とか、清書担当者を雇わなくなった企業って、多いでしょう？
My job went to AI として、じゃあ残るものは何？というのはオーム社の本を読みましょう。再販しないかなあ。
今後数年は変わらないでしょと書いたら今現在進行形で変わっとるわいと突っ込みが来そうなんで防衛的な意味で書いておくんですが、あなたは過去数年間同じ仕事してたんすか？
仕事のやり方とか内容とか、言語とかライブラリとか、毎年のように変わってたでしょ。
レビューの比率が多くなったとか、コード書かなくなったとか、そういうの、たぶん管理職になった人が嘆いてたのと同じっすよね？
少なくとも、ジュニアエンジニアが低品質なバイブコーディング結果を寄越すようになってレビューが大変とか嘆くのなら、まともなコーディング規約一つ作れていない組織の脆弱さを嘆くのが先では？
手癖でバイブコーディングしてヒットしたプロダクトに、あとから品質上げるように大工事するリファクタリングと言うよりリビルディングな仕事って、別に今もありますよね？
散々テストケースを書かなくて良いプロダクトなんて無いという講演だけ聞きに行って、自分とこでテストケースが自動で走るようになって無いなら、そこが問題でしょ。
https://www.youtube.com/@Miruru72
大げさな言葉と酒と自称鬱で「人生終わったわ」が口癖のイキる大学生時代の友達を思い出す。
正直みるる君のことをバカにする気持ちはあるが、嫌いではない。
まずはHTMLから。その後はCSS、JavaScript、Linux、GitHub、Ruby、HTTP、Nginx、データベース、Ruby on Rails、ポートフォリオ制作、就職活動、の順番で進める予定です。
よくわからないけど、
まだ若いんだし色々やって頑張ってほしい。
そして動画で嘆いてほしい。
コメント欄も応援しているようで、破滅に向かわせているような人もいるけど、諦めるな！！
私とさして年齢の変わらない、"子連れ"のカップルが、イオンのフードコートで、アイスを食べている。こんな当たり前の風景に、感動してしまった私は、俗に言う"負け組"、という事になるんでしょうか。
24歳で悲観するな！
LINEオープンチャット「はてなブックマーカー」の１週間分の要約を、さらにAIを使用し、試験的にまとめまています。
オープンチャットで話された1週間分のチャットログを、トピック別に整理して要約します。
🍽️ 食文化
庄内駅付近のマクドナルドでピクニックを楽しむ話題（ナゲットの感想など）。
ラーメン屋の米の質や、ラーメン屋勤務の思い出話が共有された。
高校受験が難しくなっている背景に普通の高校の減少があることが指摘された。
子どもの特性や遺伝的能力を教育にどう活かすべきか議論された。
子育てや妊娠・出産が会社評価に影響するという指摘や、帝王切開・多胎妊娠のリスクについて話題になった。
生成AI（特にAnthropicなど）の台頭によりWebエンジニアの需要が減るのかどうか議論された（AIを活用できるエンジニアの必要性が強調された）。
Twitterのシステム設計（Ruby on Rails）が、ユーザー数増加を想定していなかった問題について話された。
MaaS（Mobility as a Service）の実証実験が進んでいるが、現実的な運用が少ないとの指摘。
花粉症対策として舌下免疫療法を試している人の辛さや、抗ヒスタミン薬の併用が必要との意見。
ビタミンD、マグネシウム、亜鉛など栄養素が花粉症の改善に効果的と共有された。
プランク運動や、Habiticaなど習慣化アプリについて話題になり、習慣化のテクニック（嫌なことを10秒間だけ続ける方法）が紹介された。
メンタルヘルスの悩み（手の震え、職場ストレス、強迫性パーソナリティ）についての体験が共有された。
無印良品のオンライン購入待合室システムや混雑状況、購入の難しさへの不満が語られた。
残業時間（30時間、45時間超）の申請・計算について話題になる。
ディズニー映画（『リトルマーメイド』『わんわん物語』など）の評価が分かれ、思い出話が語られた。
漫画『望郷太郎』が話題になり、表紙と内容の差に戸惑いがあったことが共有された。
🚄 交通・移動
JRのシステムが古く使いにくいとの不満や、新幹線のトラブルが共有された。
地方交通の減便や値上げ、高齢者向け電動モビリティ導入の可能性について議論された。
大阪の地下鉄の混雑や街の独特な雰囲気について意見が交わされた。
琵琶湖と瀬戸内海を運河で繋ぐ構想に関する過去の話題が取り上げられた。
楽天・SBI証券の口座で不正アクセスが問題になり、契約内容変更による責任逃れへの懸念があった。
結婚後の収入を共有財産として管理することの重要性が議論された。
お得情報に流されないことが心の豊かさに繋がるという意見があり、クーポン（2500円オフ）の共有も行われた。
楽天リーベイツなどお得なサービスについての意見が交わされた。
SNSリンクが多く共有され、最新のアニメ化やスポーツニュース、イベント情報などが活発に交換された。
民主主義を軽視する風潮や、政治家・インフルエンサーの影響力の拡大に対して批判的な意見が交わされた。
職場環境で静かすぎることへの不満から、音楽（特にアンビエントミュージック）の重要性が議論された。
ライブを観に行った感想が共有され、ロックバーの経営不振や音楽の質についても語られた。
🎈 その他の話題
冗談として「会社への爆破予告」発言が軽く交わされ、カジュアルな雰囲気で話が進んだ。
石丸伸二氏の躍進について触れられた。
🗒️ 全体の傾向：
チャットでは「健康」「食文化」「教育」「テクノロジー」関連の話題が特に盛り上がり、それに加えて企業やサービスへの批判的・分析的な視点が多くみられました。日常の些細な出来事や体験談を通じて活発な意見交換がなされています。
https://anond.hatelabo.jp/20240722084249
https://www.youtube.com/@Miruru72
大げさな言葉と酒と自称鬱で「人生終わったわ」が口癖のイキる大学生時代の友達を思い出す。
正直みるる君のことをバカにする気持ちはあるが、嫌いではない。
まずはHTMLから。その後はCSS、JavaScript、Linux、GitHub、Ruby、HTTP、Nginx、データベース、Ruby on Rails、ポートフォリオ制作、就職活動、の順番で進める予定です。
よくわからないけど、
そして動画で嘆いてほしい。
https://www.youtube.com/@Miruru72
大げさな言葉と酒と自称鬱で「人生終わったわ」が口癖のイキる大学生時代の友達を思い出す。
正直みるる君のことをバカにする気持ちはあるが、嫌いではない。
まずはHTMLから。その後はCSS、JavaScript、Linux、GitHub、Ruby、HTTP、Nginx、データベース、Ruby on Rails、ポートフォリオ制作、就職活動、の順番で進める予定です。
よくわからないけど、
そして動画で嘆いてほしい。
TypeScript ベースのフルスタックフレームワークが増えてきたね。
フロントエンドもバックエンドもTypeScript 実装できてとっても嬉しいね。
しかし、バックエンドとフロントエンドと密結合な事実はとても怖いんだ。
フロントエンドの成長速度はとても早い。
React がデファクトになりつつあるが、 React ベースのフレームワークは群雄割拠だ。
むしろ、 React を排する新しい技術も出てくるくらいの戦国時代なんだ。
フレームワークを選定時、各言語でも多くて3つ程度に絞られるのではないか。
成熟しつつあるバックエンドと成長中のフロントエンドを一緒のライブラリで運用すること。とても怖い。
特に TypeScript はフロントエンドを祖に持つので、フロントエンドの事情がフレームワークの開発ロードマップの意思決定に強い影響を与える。
フロントエンドに破壊的変更が加わった時、バックエンド側にも影響を与える。
他フレームワークにおけるフロントエンドの実装について、あの Ruby on Rails ですらバージョン上がるごとにフロントエンドに破壊的な変更が入る。
まぁ View の取り扱いの黒魔術は魔境だから極力触りたくないが、バックエンドの側面のみを切り出した API モードであれば爆速の開発体験とテスト機構により信頼性が高い。
それなら、フロントエンドとバックエンドを別々に管理にしたい。
いや俺は、TypeScript のアプリケーションが嫌いなのかもしれない。
フォルダ設計も、テスト機能の整備も、ORMの設定も、最初から設定する必要があるから。面倒なんだ。
どうせ TypeScript アプリケーションの設計は設計者の自己満足になる。
そして、設計者は運用の責任を全うせずいなくなる。ドキュメントすら残さない。
それなら、規約で縛るフレームワークの方が、後任がキャッチアップしやすい。
設計者が知識を普及もしくはドキュメントを整備して知識の移転に心を砕いてくれれば、設計方針を汲み取りやすいのだが、そうしてる設計者はいるのだろうか。
後任のために、せめてものドキュメンテーションを心がける。
会社が倒産する主な原因だと分かり切っているRuby on Railsは決して開発で使用してはいけないと言う重要な話をしようと思います。
Railsは、メリットは、開発スピードは速く、開発していて楽しいが、
デメリットの方が遥かに大きく、ソースコードの分析は開発者本人にしか分からないので、
チームでの共同開発やメンテナンスに向かない、他人がソースを分析出来ないのでメンテナンス不能。
ですから、もし、Railsで企業の重要なシステムを動かしている場合は、メンテナンスや改善の必要が出た場合には、システムの設計書を元に、無ければ担当部署やお客様にヒアリングして調査して回って、必要なら最新、最先端の技術書や医学書などを調査したり専門家に意見を聞いたりなどをして、新たに、設計書を作り、PythonのFastAPIで開発しなおす需要と言うかニーズはかなり増加しております。
PythonのFastAPIは、Go言語のGinフレームワークと同等の高速性が御座います。しかも、Snowflakeと互換性があり相性が良いです。しかしシングルスレッドのマルチプロセスでしか動作しないと言うデメリットもあるので、将来のPythoのバージョンアップで、Ｖ言語の高速性をベースに中身とバックグラウンドはＶ言語で、見た目と構文はPython、セキュリティの脆弱性問題は発生しないと言うRustの様な仕様でトライブリッドの様なハイブリッドな仕様とするのが一番良いでしょう！
Python/Djangoも、PHP/Laravelも、Ruby on Railsも低速なので、世界中から大量アクセスの大規模なシステムには向かないと言うデメリットが大きいので、今から開発するなら、PythonのFastAPIが御勧めで御座います。
そんなのいらんぞ。
プロダクト開発の０→１を学ぼう
みたいのがある。
はてブでのブックマークの数から察するにオワコンになりつつあるのは確かなようだ
リリースのニュースなんかだとブックマーク数もおおかったけど、だんだん減ってる
Rails 7.0正式リリース、Node.js不要のフロントエンド開発環境がデフォルトに 195 users
https://www.publickey1.jp/blog/21/rails_70nodejs.html
↓
「Ruby on Rails 8」正式リリース。SQLiteを本番DBとして利用可能に。今後は6カ月ごとに新バージョンをリリース 33 users
https://www.publickey1.jp/blog/24/ruby_on_rails_8sqlitedb6.html
反論もへってきてる
エンプティノーズの手術を10/3にし、 それから一ヶ月経ったためトレーニングを再開することにした。
前回の外鼻形成術の時は、 術後一週間くらいで軽い気持ちでスクワットをしたところ 血が吹き出したため、 その反省から今回は術後一ヶ月経ってから再開することにした。
結論をいうと、慣らし目的で90kgのスクワットをしてみたが 血は出なかった。結局、90x8を4セットやった。 爽快だった。
スクワットは引退したんじゃなかったのか？ と思うかもしれない。 確かにおれは、以下のような記事を書いた。 理由としては回復力が落ちてきており、 致命的な腰ファックを負う前に引退しておくのが無難だというものだ。
しかしやはり、スクワットをしない人生は生きる価値がないと考える。 Ruby on Railsをやっているだけの人間をソフトウェアエンジニアと呼ばないのと同様に、 スクワットをやっていない人間をトレーニーとは呼ばない。
スクワットを再開するに当たって、 スクワットシューズを新調した。 以前に使っていたアディダスのシューズは靴底が剥がれてしまったため、 もう使いたくないからだ。 修理も考えたが、 修理をするとなれば靴底のゴムを剥がしてから再接着とかなるかもしれないし、 切ったりもするかもしれない。 あるいは、ゴム自体を別のものに交換するとかも考えられる。 そうなってしまったシューズは以前よりは不安定になるだろうし、 命をあずけることは出来ない。
というわけで、アシックスの定番ウエイトリフティングシューズを購入した。 値は張ったが、しかたがない。 サイズはAmazonの試着サービスを利用して、26.5cmを厳選した。 他にもナイキのロマレオスなど選択肢はあったが、 仕様が安定しているものがほしかった。 次にシューズが壊れた時には全く同じものがほしいからだ。
多くのウェイトリフター、パワーリフターに支持されているだけあって 素晴らしいシューズと思う。 底が硬く、靴自体も重いため、地面と接着するような感覚があった。 もちろん、かかとも高く作られており、しゃがみこみも自然だ。
今後、目標としてはやはり、200kgのスクワットを挙げたいと思う。 エンプティノーズの治療が競技能力にプラスに働くならばそう難しいことではないように思うが、 それでも簡単というほどではないだろう。
手術からまるまる一ヶ月、ジムに行けてなかったわけだが、 これによっておれは気力がなくなり鬱状態になっていた。 やはり、気力というものはトレーニングをしてエネルギーを使い果たし、 それを回復することでしか満たされないものなのだと思う。 身体が疲れていないので夜までキングダムを読んでしまい、 ２時に寝るなんてこともあった。 やはり、９時に寝て５時に起きるのが基本だ。 良いトレーニングをして、良い睡眠をとる。 我々はこれを基本としなければいけない。
DHHとは、David Heinemeier Hanssonの略で、彼はRuby on Railsの創設者として知られています。
彼の主張は、成功者の成功理由を学ぶことの重要性についてです。
しかし、あなたが指摘したように、これは「生存者バイアス」の問題を引き起こす可能性があります。
生存者バイアスとは、成功した例や生き残った事例だけを見て、それを全体の傾向やルールと誤解する傾向のことを指します。
つまり、成功者の戦略が必ずしも最善であるとは限らず、その戦略が成功した状況や条件も考慮する必要があります。
バイナリオプションの例を挙げると、運良く大儲けした人と同じことをすれば、必ずしも同じ結果が得られるわけではありません。
市場の状況、タイミング、リスク管理など、多くの要素が結果に影響を与えます。
そのため、成功者の戦略をそのまま模倣するだけでは、必ずしも成功につながるわけではないということです。
したがって、成功者の戦略を学ぶことは有益ですが、それだけに頼るのではなく、失敗したケースからも学び、自分自身の状況に合わせて戦略を調整することが重要です。
また、成功の再現性は確かに保証されていません。成功は努力だけでなく、タイミングや運など、コントロールできない要素も含まれています。
この期間に、様々なプロジェクトに関わり、多くのことを学びました。
今回は、私が経験した技術的な話を中心に、はてなでの仕事について振り返りたいと思います。
はてなでは、主にRuby on Railsを使ってWebアプリケーションを開発していました。
はてなブログやはてなブックマークなどの有名なサービスはもちろん、社内向けのツールや新規事業のプロトタイプもRailsで作っていました。
Railsは、高速に開発できるというメリットがありますが、それと同時にコードの品質やパフォーマンスにも気を配る必要があります。
私は、テストやリファクタリング、コードレビューなどの技術的なプラクティスを積極的に取り入れることで、Railsの開発をより効率的で安全に行う方法を学びました。
例えば、私が担当したプロジェクトでは、RSpecやRuboCopといったツールを使ってテストカバレッジやコード規約をチェックし、GitHub ActionsやCircleCIといったサービスを使って自動化しました。
また、Pull RequestやPair Programmingといった方法を使ってコードのレビューを行い、バグや改善点を見つけたり、知識やノウハウを共有したりしました。
また、はてなでは、AWSやGCPなどのクラウドサービスを活用してインフラを構築していました。
私は、DockerやKubernetes、Terraformなどのツールを使って、コンテナ化やオーケストレーション、インフラストラクチャ・アズ・コードなどの技術を実践しました。
これらの技術は、開発環境と本番環境の差異を減らし、デプロイやスケーリングを容易にするという利点がありますが、それと同時に複雑さやトラブルシューティングの難しさも増します。
私は、モニタリングやロギング、アラートなどの技術的な仕組みを整備することで、インフラの運用をより安定的で信頼性の高いものにする方法を学びました。
例えば、私が関わったプロジェクトでは、DatadogやCloudWatchといったサービスを使ってシステムの状態やパフォーマンスを監視し、SlackやPagerDutyといったサービスを使って異常や警告を通知しました。
また、ElasticsearchやFluentdといったツールを使ってログの収集や分析を行い、原因究明や改善策の検討に役立てました。
## チームでの協働
はてなでエンジニアとして働くことで、私は多くの技術的なスキルや知識を身につけることができました。
しかし、それ以上に大切だったのは、チームで協力して問題を解決することでした。
はてなでは、エンジニアだけでなくデザイナーやプロダクトマネージャーなどの他職種とも連携してプロジェクトを進めることが多かったです。
私は、コミュニケーションやフィードバック、ドキュメンテーションなどの技術的ではないスキルも重要だと感じました。
私は、自分の意見や提案を積極的に発信することで、プロダクトやサービスの品質や価値を高める方法を学びました。
例えば、私が参加したプロジェクトでは、SlackやZoomといったツールを使って日常的に情報交換や相談を行い、BacklogやJiraといったツールを使ってタスク管理や進捗報告を行いました。
また、FigmaやMiroといったツールを使ってデザインやアイデアの共有やフィードバックを行いました。
私は、はてなでエンジニアとして働くことがとても楽しく充実していました。
しかし、私は自分のキャリアについて考える中で、新しい挑戦をしたいという気持ちが強くなりました。
私は、自分の興味や関心のある分野にもっと深く没頭したいと思いました。
## おわりに
彼らに感謝する気持ちを込めて、このエントリーを書き終えたいと思います。
嫁のはてブが閉鎖して1週間が経った。変わらず手癖でGoogleに「嫁のはてブ」と入れてサイトに飛んでしまうのが悲しい。
[補足] 嫁のはてブ関連のブコメで「嫁のはてブって何だ？」というコメントを見かけたので、もし嫁のはてブを知らない人は以下ページを見てもらうといいと思う。 ■「はてブ」をリニューアル前風デザインで 個人が一晩で開発 - ITmedia NEWS https://www.itmedia.co.jp/news/spv/1301/09/news089.html
嫁のはてブの閉鎖が決まってからはてなブックマーク公式サイトを使おうとしてみたが、正直キツい。
アプリの方はまだ見た目には良さそうだったのだが、自分は気になった記事ページとブクマページを一旦タブで全部開いて、開ききってから読んでくというスタイルなのでアプリは合ってなかった。
Hatebu::Classic を試してみたがこちらもあまりしっくり来ず。
結局求めているものは嫁のはてブだったので、見た目ほぼそのままの なれのはてブ を作った。
（ちなみに作ったあとに はてなフィルター の存在を知った。もし作る前に知ってたら、なれのはてブは作らなかったかもしれない。）
500を超えるブックマークと、多くの人に利用していただけて大変感謝です。
また嫁のはてブと作者の後藤基史氏には感謝してもしきれない。約10年間本当にありがとうございました。
なれのはてブを作ってる時にふと思い出したのが、昔地元にあった十一屋という本屋のことだった。
近所にあった本屋で、物心ついた4歳頃には絵本を立ち読みしていた記憶がある。
小学校低学年の頃はマリオの攻略本や文房具を買い、高学年の頃はファミ通を立ち読みしたり大技林を買ったりしていた。
エヴァブーム後はアニメージュの綾波レイ、ホシノ・ルリ、リナ・インバースの熾烈なランキング合戦を毎号チェックし、電撃王のふりをして電撃姫を買うなど、まさに自身の成長とともにあった本屋だった。
小6か中1の時に閉店となり、文字通り泣くほど悲しかった。自分の中で最初の大きな喪失だった。
当時、再び同じ場所に十一屋という店名で本屋を開くことが少年の夢だった。
（残念ながら本屋は開けてはいない。またその場所に同じく思い出の地であった総合スーパーの清水屋の狭小店舗が移転してきたのもあり、現状同じ場所は難しそうである）
嫁のはてブができた頃、自分は新卒で入った会社を辞め、社員2人の会社で1人プログラマーをしていた。
Webサービスを作っていたのだが、当時の自分は学生時代にC言語とJavaを書いたことがある、新卒で入った会社ではABAPという謎言語を少し書きあとは専ら神エクセル作りとパワポに画面キャプチャを貼る仕事だったのでWeb開発経験はゼロ。
そんな自分を救ってくれたのはインプレスの基礎 Ruby on Railsと、そして嫁のはてブだった。
はてブでRSpecを書くことを覚え、いいgemを知り、Font Awesomeを知り、いい感じのjQueryを見つけ、Reactを知り、AWSの使い方を覚え etc…
この約10年間のプログラマーとしての成長はまさに嫁のはてブとともにあった。
いまもまだ閉店した本屋は復活させられないが、閉鎖したWebサービスは復活させたよと当時の自分に言ってあげたい。
今後も見た目のシンプルさはそのままにちょこちょこと機能追加していけたらと思っている。
もしよかったら使ってみてもらえると嬉しい。
