はてなブックマーク

はじめに 洋書ですが、"Writing for Developers"という技術ブログの書き方を教えてくれる本を読んでみました。 www.manning.com 以下は公式ページにあった概要の翻訳です（ChatGPTで翻訳）。 「Writing for Developers」は、優れた技術的洞察を素晴らしいブログや記事に変える手助けをします。著者のピョートル・サルナとシンシア・ダンロップは、エンジニアとプロのライターという異なる視点を組み合わせ、説得力のある作品を書くためのサポートを提供します。この本は一般的な執筆ガイドではなく、技術的なトピック、執筆者、読者に特化して焦点を当てています。 楽しい例やユーモラスなイラスト、たくさんのジョークを通して学べます！この本は、アイデアの生成と優先順位付けから、計画、執筆、改訂の際に考慮すべきこと、成功したブログ投稿をさらなる機会への足がかりとして活

はじめに タイトルの通りですが、今年に入ってからメインの検索エンジンをGoogleからBingに変えました。 なぜ変えたのか？ それはこのブログを含む個人ブログがGoogleの検索結果に上がりにくくなってきたからです。 Googleで個人ブログが検索結果に上がりにくくなった例 たとえば、先日僕は自分の車のワイパー交換の方法をブログに書きました。 blog.jnito.com Bingで「volvo xc60 ワイパー交換」というキーワードで検索すると、僕のブログがトップに表示されます。 一方、Googleだと同じキーワードで検索しても全然表示されません。 いくらスクロールしても最後まで僕のブログは表示されませんでした。 「xc60 ワイパー 自分で交換」なら表示される しかし、インデックスに登録されてないわけではありません。 「xc60 ワイパー 自分で交換」みたいなキーワードにするとGo

はじめに 先日、弊社ソニックガーデン主催の「エンジニアのためのスキルアップ勉強会#2 自分が考える最高の開発環境」に参加しました。（登壇者ではなく視聴者として） sonicgarden.connpass.com その中で弊社の @ruzia がRubyMine愛、もといJetBrains愛を熱く語っていたのですが、同じRubyMineユーザーとして、彼の言うとおりRubyMine（およびJetBrains系IDE）の一番の強みはやっぱり、「デフォルトにして至高」つまり、「最初から全部入り」であることだな〜と再確認しました。 RubyMineじゃなくてもできるから、無料のエディタで十分？ RubyMineの便利機能を紹介するとよく耳にするのが、 「それ、RubyMineじゃなくても <<あの機能拡張>> を入れたら <<あのエディタ>> でもできるよ。しかも無料だよ！」 というセリフです。

はじめに 僕は趣味でよくギター（エレキギター）を弾きます。 ですが、長年ずっと困っていたことがありました。 それはギターアンプのノイズです。 多かれ少なかれ、エレキギターを弾くときはアンプからノイズが出るものです。 しかし、僕の家のギターアンプからは明らかに異常な「キーン」というノイズが出ます。 実際どんな音なのかは以下の動画で確認できます。（うるさいのでボリュームには気を付けて！） www.youtube.com このノイズは以下のような特徴があります。 5〜6年前から急に発生し始めた 常時ノイズが出るわけではなく、たまに発生する ノイズが鳴り始めると鳴ったり止んだりを繰り返す ギターを変えても、アンプを変えても同じようにノイズが出る（なので、ギターやアンプの問題とは考えにくい） ギターを全くつないでいない状態でもノイズが出る（なので、ギターのピックアップがノイズを拾っているわけではない

はじめに 仕事用のMacを3年ぶりに買い換えました。MacBook Air M3 15インチ (2024)です。 ちなみに今まで使っていたのはMacBook Pro M1 13インチ (2020) でした。 なんで買い換えたの？ 今まで使っていたM1 MacBook Proも大きな不満はなかったのですが、3年使ってきて「そろそろ買い換えてもいいかな？」と思っていたときに、M3チップ版のMacBook Airが発表されました。 www.apple.com M1→M2だとあまり変わらないかな？と思ってたのですが、M1→M3ならそれなりに速くなるんじゃないかと期待して「よし、買い換えよう！」と決めました。 （あ、ちなみに仕事用のMacは会社で購入してもらってます🙏） なんでAirなの？Proじゃないの？ 仕事用で使うならAirじゃなくてProの方がいいのでは？と思う人もいるかもしれません。 僕

新しいMacに買い換えてセットアップを進めていったら、なぜかChromeでパスワードの自動入力を利用しようとすると毎回Touch IDを要求されるようになってしまいました（どこかのタイミングでそれらしき確認ダイアログをOKした気もするけどよく覚えてない……）。 （ちなみに僕はOSの言語設定を英語にしているのでスクショは全部英語表記になっております。どうぞ悪しからず） Google Chrome is trying to fill your password on accounts.hatena.ne.jp. Touch ID or enter your password to allow this. もちろんセキュリティ的にはこっちの方が安全なんでしょうが、僕のデスクだとMacBook本体が遠いところにあるので、頻繁にTouch ID（指紋認証）を使うのはちょっとしんどいんです。 Appl

僕が翻訳しているRSpecの入門書「Everyday Rails - RSpecによるRailsテスト入門」は2014年2月に発売されました。 blog.jnito.com そう、発売からちょうど10年が経ったのです。 いつの間にか10年！僕も全然気付いていませんでした！！ おかげさまで本書は何度となくアップデートを重ねつつ、RSpecの定番の入門書としてたくさんの人に読んでいただいています。 現時点での読者数はのべ6800人以上です。ご購入してくださったみなさん、本当にどうもありがとうございます！ これまでの歴史 どういう流れで本書が翻訳され、現在に至ったのかを簡単にふりかえってみましょう。 2012年5月 原著「Everyday Rails Testing with RSpec」がLeanpubで発売 2013年10月 僕が原著を読み、その感想をブログに投稿 blog.jnito.co

お知らせ 僕が翻訳している電子書籍「Everyday Rails - RSpecによるRailsテスト入門」をアップデートしました🎉 すでに本書を購入されている方はLeanpubのサイトから最新版の電子書籍ファイルを無料でダウンロードできます。 leanpub.com 2024年版のアップデート内容 今回のアップデート内容は以下の通りです。 サンプルアプリケーションをRails 7.1 + Ruby 3.3 + rspec-rails 6.1で再作成 これに伴い、サンプルアプリのリポジトリURLも変更 新しいサンプルアプリのコードや挙動にあわせて、本書の記述を修正 リンク切れしていたいくつかのリンクを新しいURLに修正 Rails 7.1で作った新しいサンプルアプリケーションは以下のGitHubリポジトリに置いています。 github.com とはいえ、書籍としてはほとんど内容は変わって

はじめに：包丁が切れない！ 僕は全然料理をしない（できない）んですが、妻は料理が大好きです。 しかし、包丁が切れないことに不満を持っていて、「包丁が切れない、新しい包丁が欲しい」とずっと嘆いていました。 もちろん、毎日使う道具なので新しい包丁を買うことぐらいは全然構わないのですが、新しい包丁を買う以外に、「包丁を自分で研ぐ」という選択肢もあります。 いや、いちおう簡易シャープナーはあるんですよ。こんなやつが。 グローバル スピードシャープナー GSS-01 グローバル(Global)Amazon しかし、妻曰く「シャープナーを使っても翌日には切れ味が落ちる」とのことです。 なので、シャープナーではなく、ダメ元でいいから砥石を使ってちゃんと自分で一度研いでみよう、という話になりました。 よし、YouTubeで勉強だ！ 砥石で包丁なんて一度も研いだことがないのですが、とりあえずYouTubeで

はじめに 僕は自宅で長年WAKWAKというインターネットプロバイダを利用してたんですが、最近OCNに乗り換えました。 ・・・というだけなら「ふーん」で終わってしまうのですが、実は3ヶ月ぐらいかけて、 WAKWAK ↓ OCN ↓ BIGLOBE ↓ OCN とプロバイダを転々と切り替えながら、最終的にOCNを（しかもIPv6ではなくIPv4で）利用することに決めました。 このエントリではどういう経緯でこの結論に至ったのかを紹介します。 【もくじ】 はじめに 我が家のインターネット環境の紹介と、おことわり 用語の整理 困っていたこと：Amazon S3のファイルダウンロードが遅すぎる！！ IPv6にしてもまだ遅い！ iPhoneのテザリングだと夜でも3秒でダウンロードできるんですが？ NTTの人が試しにOCNにつないだら、あれ？速い！！ IPv4だと速いのに、IPv6だと遅いOCN・・・ 同

はじめに 前回のブログではWi-Fiの電波を安定させるためにルーターを壁掛けにした、という話を書きました。 blog.jnito.com 電波状況が改善したのは良かったのですが、それと引き換えに今まで使っていたNAS（Buffalo LS210D0201C）をつなげなくなってしまう、という問題が発生しました。 もちろん、壁付けしているWi-FiルーターにLANケーブルをつなげば引き続きNASが使えるのですが、配線がごちゃごちゃして美しくないのでそれはしたくないな〜と思いました。 このままNASを使うか、使わないか？ ただ、NASの用途は非常に限定的で、家庭用に使っているMacBook AirのTimeMachineバックアップのストレージとして利用しているだけです。 加えて、MacBook Airはほぼインターネット専用マシンと化しているので、仕事用のMacとは違ってローカルストレージのフ

はじめに 最近Wi-FiルーターをNEC Aterm WX5400HPに買い換えました。 ルーターを買い換えたのはIPv6（正確にはIPv4 over IPv6）でインターネットができるようにするためです。 「IPv6にしたらネットが速くなるはずー😊」と思ったんですが、それ以前にルーターを買い換えてから妻や子どもたちから「ネットがよく切れる💢」「LINEがしょっちゅう送信エラーになる😡」と不満の声が上がりました（あらら）。 原因はよくわからないのですが、部屋の少し奥まった場所にWi-Fiルーターを置いてたので、「もしかして？」と思って試しに部屋の外にWi-Fiルーターを置いてみたところ、ネットの調子が良くなりました。 イメージ的にはこんな感じです。 以前使ってたASUSのWi-Fiルーター（RT-AC68U）だと部屋の中に置いてても問題なかったんですけどね。 ちなみにWi-Fiルータ

はじめに 先日、「コードが動かないので帰れません！ 新人プログラマーのためのエラーが怖くなくなる本」という本が発売されることを知りました。 おお、これは気になる 👀 https://t.co/AVGT19OSQi— Junichi Ito (伊藤淳一) (@jnchito) 2023年9月6日 そしたらこの本の編集者さんが僕のツイートを見つけて「良かったらお送りしましょうか？」と連絡をくれたので、二つ返事で「はい！」と答えましたw というわけで、「コードが動かないので帰れません！ 新人プログラマーのためのエラーが怖くなくなる本」を早々とゲット！わーい！😄 せっかく送っていただいたので、本書の簡単な紹介と感想を書いてみようと思います。 【もくじ】 はじめに 本書はどんな本？ 本書の感想＝プログラミング初心者の強くて優しい味方みたいな本！ 薄い！ 堅くない！ 広く浅い！ 本書にあえて注文を

はじめに 2023年9月9日に開催された大阪Ruby会議03で、基調講演（キーノート）を担当させてもらいました。 regional.rubykaigi.org 当日使った資料はこちらです。 発表のタイトルは"Enjoy Ruby programming, Enjoy Ruby community!"でした。 今回の基調講演ではちょっと攻めた取り組みとして、「Hotwireを使ったモーダルUIを15分で作る」というテーマでライブコーディングもしてみました。 www.youtube.com ライブコーディングには思わぬトラブル付きものですが、今回は何とかノートラブルで実装できました！ 時間も15分以内（たぶん12〜13分ぐらい？）に収まりました〜😄 基調講演をするにあたって意識したこと 今回、基調講演を担当するにあたって「IT系カンファレンスの基調講演はどういうものであるべきか」を自分なりに

お知らせ 2023年9月9日（土）開催の大阪Ruby会議03で、僭越ながら基調講演をさせてもらうことになりました。 regional.rubykaigi.org 今回はめちゃくちゃ久しぶりのオフライン講演です！ オフラインでお話しするのはたぶん2019年の富山Ruby会議以来ですね。 blog.jnito.com 大阪Ruby会議03のテーマは「Rubyで笑おう」です。 大阪で「笑い」と来たら、「もしかして漫才みたいな基調講演でも要求されるのか！？」と思いましたが、運営チームの人たちに確認したところ、「Rubyで幸せになってみんな笑顔になってほしい」という意味の「笑おう」らしいです。 2019年の大阪Ruby会議02から早4年。 長かったコロナ禍を乗り越え、大阪Ruby会議が復活します！ 心の底から笑い合える日がまた来ることを願って、 今年のテーマは「Rubyで笑おう」としました。 Osa

お知らせ レバテックLABさんの「キャリアを創る思考法」という連載コラムの第2弾として、「伊藤淳一氏が「一番下手くそエンジニア」から脱出した4つの方法。2023年版ITエンジニアの生存戦略【後編】」という記事を寄稿しました。 levtech.jp どんな話を書いたの？ 僕がソニックガーデンに入社してから、界隈でちょっと名の知れた有名Railsエンジニアになるまでの華々しいキャリアを描きました・・・と言いたいところですが、華々しいどころか 「今までと勝手が違う！」 「全然パフォーマンス出せない！！」 「もう辞めてしまった方がいいのでは……」 と悪戦苦闘した最初の数年間を中心にいろいろ語っておりますw 「情熱プログラマー」を読んだときは自分が「一番の下手くそ」になる現場に憧れてたんですけどねえ。あはは😅 情熱プログラマー ソフトウェア開発者の幸せな生き方 作者:ＣｈａｄＦｏｗｌｅｒ,でびあん

はじめに 先日、こんなエントリを書きました。 blog.jnito.com 上の記事の中で、僕は「きれいなコードだけではすんなりコードが理解できないこともある」というような話を書きました。 もちろん、ある程度の規模になってくるといくらがんばっても「すんなり」では済まない場合も増えてくるけど、それでも最初に挙げた特徴を兼ね備えたコードとそうでないコードでは、開発効率に雲泥の差が出てくる。 僕が考える「良いコード」 - give IT a try きれいなコードを書くことはいつでも大事ですが、きれいなコード「だけ」では大きなコードを理解するのは難しいです。 そこできれいなコードを書くことに加えて、僕が意識しているコードを理解しやすくする工夫について書いてみようと思います。 ただし、ここで書く内容はあくまで僕が普段心がけていることです。 現場の文化やコードの規模や歴史、開発チームのスキルや人数、

こんなコードだとわかりやすい 僕が考える良いコードの特徴（条件）を挙げてみると、 ぱっと見たら、だいたい何をやっているのかがわかるメソッド名 ぱっと見たら、だいたい中身が何なのか想像がつく変数名 ぱっと見たら、だいたい何をやっているのかが把握できるメソッドの内の処理フロー 驚きが少ないメソッド 副作用が少ないメソッド（責務が1つしかないメソッド） DRY原則を守っているコード だいたいこんな感じ。 つまり「すんなり読めて、すんなりわかるコード」が理想。 プログラムが小さいうちや、一人で開発しているうちは「汚くてわかりにくいコード」であっても「自分さえわかればOK」で済んじゃうけど、プログラムの規模が大きくなったり、複数人で開発するようになると、「汚くてわかりにくいコード」は絶望的に開発効率を下げる。 こんなコードはわかりにくい たとえば上の反対で、 メソッド名だけ見ても何をやっているのか想

お知らせ レバテックLABさんの「キャリアを創る思考法」という連載コラムに「伊藤淳一氏が語る「僕の9年間の無名時代」。2023年版ITエンジニアの生存戦略【前編】」という記事を寄稿しました。 levtech.jp どんな話を書いたの？ 僕を知ってる多くの人は「Ruby界隈で有名な伊藤さん」という認識かもしれませんが、僕はもともとJavaやC#をメインで使っていましたし、知名度が上がってきたのは現職のソニックガーデンに入社してからです。 それまでは僕も「完全に無名の、ただのエンジニア」でした。 とはいえ、無名エンジニア時代も自分なりに将来のキャリアを考えながら行動しており、もしかするとそれが今につながっているのかな〜という気もしています。 この寄稿記事ではそんな僕の「無名エンジニア時代」を振り返ってみました。 「まだまだ無名」と思ってる人にこそ読んでもらいたい この時代の僕を知ってる人はあま

「えっ、SQLite3ってこんな仕様なの！？」と最近ビックリしたことを紹介します。 たとえばこんな2つのテーブルがあったとします。 CREATE TABLE blogs ( id int primary key, title varchar(32) ); CREATE TABLE comments ( id int primary key, content varchar(32), blog_id int, foreign key (blog_id) references blogs(id) ); ポイントはcommentsテーブルのblog_idにはblogs(id)への外部キー制約が貼ってあることです。 もちろん、blog_idもblogs(id)も、どちらもint型です。 で、以下のようなSQLを発行します（blog_idの値に注目）。 -- blogsにデータを追加 INSERT

お知らせ エンジニアtypeさんでインタビュー取材を受けた記事が公開されました。 こちらの『若手エンジニアの成長を妨げる“受託脳”とは？ 「受託開発でスキルアップできない」が大間違いな理由』というタイトルの記事です。 type.jp イントロダクションはこんな感じです。 「スピーディーに成長したいなら、受託開発より自社開発」そんなイメージから、受託開発を行う企業から自社開発企業への転職を目指す若手エンジニアは多いかもしれない。 だが、“チェリー本”の愛称でお馴染みの書籍『プロを目指す人のためのRuby入門』執筆者であり、ソニックガーデンのプログラマー・伊藤淳一さんと、同じくソニックガーデンで指折りのプログラミング力を誇る執行役員の遠藤大介さんは、その考えは「必ずしも正解とは言えない」と話す。 二人のエンジニアとしてのキャリアは15年以上。両者ともに、これまで受託開発の仕事を続けながら、現在

お知らせ Software Design 2023年3月号（現在発売中）の「ITエンジニアスキルアッププログラム」という特集に、「テクニカルスキルを磨く」という記事を寄稿しました。 どんな話が載ってるの？ プログラマ・ITエンジニアとしてこれからどんどん成長していきたい初心者さん向けに、以下のような話を書きました。 技術をどう学ぶべきか プログラミング力以外にエンジニアとして必要とされるスキルは何か 学びをさらに深めるためには何をすべきか 勉強が苦しい・しんどい、と感じたときはどうすれば良いか etc スキルアップの方法についてはもっといろいろ書きたい内容があったのですが、限られた紙面なので「その中でも特に」と思う内容を厳選して記事にしています。それゆえ、結構「濃い」内容になっているので、「これからやってくぞ！」と思っているプログラマのみなさんにぜひ読んでいただきたいです。また、新人の指導

（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな

2023年2月3日に株式会社N2iさん主催の勉強会、Meets Professionalで「Qiita 1位のアウトプットの達人が語る、良質な技術記事を量産する秘訣」という発表をしてきました。 n2i-engineer.connpass.com 当日使ったスライドはこちらです。 講演の前半は「僕がなぜアウトプットするのか、なぜそれを続けられるのか」について、後半では「アウトプットが苦手なみなさんの背中を押す話」をしました。 また、講演が終わった後は参加者のみなさんからの質問に答えるQ&Aタイムもありました。 YouTubeでダイジェスト動画が公開されているので、当日見逃した方はこちらをどうぞ。 さらにログミーさんにて書き起こし記事も公開されています。 講演の後半に実施したQ&Aタイムの内容も書き起こしされていて、すごい充実度です！ logmi.jp 全部4本あります。第2回以降の記事はこち