僕が考える「良いコード」 - give IT a try
こんなコードだとわかりやすい 僕が考える良いコードの特徴（条件）を挙げてみると、 ぱっと見たら、だいたい何をやっているのかがわかるメソッド名 ぱっと見たら、だいたい中身が何なのか想像がつく変数名 ぱっと見たら、だいたい何をやっているのかが把握できるメソッドの内の処理フロー 驚きが少ないメソッド 副作用が少ないメソッド（責務が1つしかないメソッド） DRY原則を守っているコード だいたいこんな感じ。 つまり「すんなり読めて、すんなりわかるコード」が理想。 プログラムが小さいうちや、一人で開発しているうちは「汚くてわかりにくいコード」であっても「自分さえわかればOK」で済んじゃうけど、プログラムの規模が大きくなったり、複数人で開発するようになると、「汚くてわかりにくいコード」は絶望的に開発効率を下げる。 こんなコードはわかりにくい たとえば上の反対で、 メソッド名だけ見ても何をやっているのか想
妻がコロナになったので、生まれて初めて家事をワンオペで回そうとしたらめちゃくちゃ大変だった件 - give IT a try
はじめに ちょっと前の話になりますが、今年の1月頃に妻が新型コロナにかかりました。 僕と息子と娘は去年の夏にコロナになったのですが、家族では妻だけがかからなかったので、「妻は無敵なんじゃないか」と話していましたが、第8波の大きな波からはさすがの妻も逃げ切れなかったようです……。 ちなみに去年の夏にコロナにかかった話はこちらにまとめています↓ blog.jnito.com で、我が家において妻がコロナにかかって自宅隔離になるというのは、かなりの痛手です。 なぜなら、家事の大半が妻に依存していたからです。 以前から「かよこ（妻の名前）がコロナになったらヤバいよな〜」という話は夫婦でときどきしてたんですが、ついにそのリスクが現実になってしまいました😱 というわけで、このエントリでは妻が戦線離脱して僕が一人で家事を回そうとしたときに初めてわかったことや感じたことをあれこれまとめてみます。 我が家
雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try
（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
昨今の「未経験からエンジニア就職！」みたいなトレンドに対して業界歴20年の僕が考えていること - give IT a try
このブログ記事は動画バージョンがあります。動画で見たい方はこちらをどうぞ↓ www.youtube.com ちょっと前から「もやもや〜」と考えてることなんですが。 なんかここ数年、急にプログラマ（エンジニアと言われることが多いけど）の仕事が脚光を浴び始めた気がします。 「3K（笑）」から「お給料が良くて、自由に働ける、イケてる職業」に！？ 僕がこの仕事を始めた頃（20年前）とか、ソニックガーデンに入社した頃（10年前）はまだ「プログラマ？おたくっぽい」「あー、3Kでしょ？きつい、帰れない、給料安いw」みたいな扱いだった気がします。少なくとも日本においては。 ところが、この5〜6年で急に「お給料が良くて、自由に働ける、イケてる職業」みたいなイメージに変わってきたんですよね。 それ自体はとてもいいことだと思うんですよ。自分の仕事が「3K（笑）」と馬鹿にされるより、「お給料がいい！自由！イケてる
マトリョーシカ人形のようなメソッド設計を避ける - give IT a try
フィヨルドブートキャンプのコードレビューでよく指摘してるシリーズです。 次のようなパンを焼くRubyプログラムがあります。 このプログラムはどういう工程を経てパンが焼かれるのか、ぱっと把握できますか？ def main パンを焼く(粉, 水) end def パンを焼く(粉, 水) 焼く(パンを発酵させる(粉, 水)) end def パンを発酵させる(粉, 水) 発酵させる(パンを整形する(粉, 水)) end def パンを整形する(粉, 水) 整形する(パンをこねる(粉, 水)) end def パンをこねる(粉, 水) こねる(粉, 水) end main 上のプログラムは次のように書いても同じように処理されますが、工程の全体像がつかみやすいのはどちらでしょうか？ def main 生地 = パンをこねる(粉, 水) 整形された生地 = パンを整形する(生地) 発酵した生地 = パ
過度なDRYは読みやすさの敵！？「リーダブルテストコード」という発表をしました #vstat - give IT a try
先日、このブログでもお伝えしましたが、「VeriServe Test Automation Talk No.3」というオンラインイベントで登壇してきました。 veriserve-event.connpass.com 申込者数はなんと1000人を超えていて、大変驚きました。 僕は「リーダブルテストコード」というテーマで発表しました。スライドはこちらです。 Twitterでたくさんシェアされたり、はてなブックマークがたくさん付いたり、こちらもすごい反響でビックリしました。 で、どんな内容だったの？ ひとことで言うなら「テストコードを徹底的にDRYにしようとしちゃダメよ！」というお話です。 このネタは昔からQiitaやTwitterとかでことあるごとに話してきましたが、この勉強会であらためてなぜダメなのか、DRYに書かず、どう書くべきなのか、という話を力説してみました。 優秀なプログラマほど、「
ITエンジニアがお金に関する本を10冊近く一気に読みあさってみた - give IT a try
はじめに：お金は稼げてるけどお金には無頓着な44歳ITエンジニア 僕はプログラマとして働いていて、株式会社ソニックガーデンのお給料やら、副業のフィヨルドブートキャンプのメンター料やら、執筆・翻訳した技術書（「プロを目指す人のためのRuby入門」と「Everyday Rails - RSpecによるRailsテスト入門」）の印税やらで、日本人の平均からすればそこそこいい年収を得ています。 具体的な金額は書けませんが、ここ数年は毎年1000万以上の年収がある、という感じです（機会があればこのへんの話も詳しく書きたい）。 が、基本的にお金には無頓着で生きておりまして、それゆえに毎年自分でもビックリするぐらいの税金を（泣きながら）払っております😭 あと、資産運用的なこともやっておらず、貯金がメインなので（浪費がメインという説もあり）、「あー、お金は稼いでるけど、そこからあとの使い方はなんかあんま
学校の勉強とプログラミングの勉強は何が違うか（そして技術書をどう読むべきか） - give IT a try
これは何？ これは僕がメンターをやっているフィヨルドブートキャンプで受講生向けに書いた記事です。 ただ、内容の8割ぐらいは未経験からプログラマを目指している初心者のみなさんにも役立つと思うので、そのまま公開することにしました。 想定読者は「フィヨルドブートキャンプの受講生」なので、フィヨルドブートキャンプの関係者以外の人が読むと「？？？」となる部分があるかもしれませんが、その点は悪しからず🙏 それでは以下が本編です。 はじめに みなさんはフィヨルドブートキャンプに入ってプログラミングの「勉強」をします。また、大半の受講生のみなさんは学校で「勉強」してきたと思います。どちらも「勉強」ですが、実は学校の勉強とプログラミングの勉強は異なる点が多いです。その違いを意識せずに、学校の勉強と同じ感覚でプログラミングの勉強をやると、非効率な勉強をしてしまう恐れがあります。 この記事ではプログラミングの
【JS完全に理解した】JavaScript PrimerとプログラミングTypeScriptとレガシーフロントエンド安全改善ガイドを読んでみた - give IT a try
はじめに 僕は仕事でRuby on Railsを使ってWebアプリケーションを開発しているので、JavaScriptはそれなりに使えます。 ですが、サーバーサイドで使っているRubyに比べると、JavaScriptの習熟度はそれほど高くありません。 とくに、文法が一気にブラッシュアップされたES2015（ES6）以降の知識は「なんとなく把握はしているが、あくまでなんとなく」といった感じです。 また、最近よく名前を聞くようになったTypeScriptも「名前は知っているが使ったことはない」というのが現状です。 というわけで、「そろそろちゃんと勉強しておかないと」という思いから、以下の本を購入してみました。 JavaScript Primer 迷わないための入門書 (アスキードワンゴ) 作者:azu,Suguru Inatomi発売日: 2020/06/10メディア: Kindle版プログラミ
Rubyプログラマが中学校で情報モラル講演会をしてきたよ - give IT a try
はじめに 先日、Rubyプログラマが本職である僕が、なぜか地元・兵庫県西脇市の中学校で情報モラル教育に関する講演をしてきました。 このエントリではなんでそんなことになったのか、そしてどんなことを話したのか、といった話を書いていきます。 【もくじ】 はじめに 講演を依頼されたいきさつ 去年の情報モラル講演会は本当にひどかった 今年は誰かな〜？ → えっ、僕！？ 当日使用したスライド この講演で伝えたかったこと 「スマホやSNSは怖い」だけでは終わらせない トラブルに遭遇したら大人に頼る（一人で解決しようとしない） リスクを語るときは、必ず予防策と対処法をセットで伝える テクニカルな解決策（設定の変更等）は重視しない 大人だって失敗したり、ちゃんとできてなかったりすることを伝える 生徒さんたちの感想 その他の裏話等 「経験がない＆時間がない」で、かなり準備が大変だった 信頼が置ける専門家の方た
ITエンジニアが知っておきたい、軽減税率制度（のイヤなところ） - give IT a try
はじめに 僕の妻は兵庫県西脇市で「Coupé Baguette（クープ バゲット）」という小さなパン屋さんを営んでいます。 その関係で、先日国税庁から消費税の軽減税率制度に関するお知らせが届きました。 「軽減税率制度？あ〜、なんかそんな話もあったような」と思いながら資料を読んでみたところ、「げげっ、軽減税率制度ってこんな面倒な仕組みになってたの！？」とビックリしました。 というわけで、このエントリでは軽減税率制度の概要（と、ITエンジニアが困りそうなポイント）をざっくりとまとめてみます。 おことわり 僕自身は税理士のような税金の専門家ではないため、100%正しく理解しているとは限りません。 エントリ内に怪しい内容があればコメント欄等でご指摘いただけると助かります。 国税庁の資料から抜粋した、軽減税率制度の主なポイント 我が家にも届いた「よくわかる消費税軽減税率制度（平成30年7月）」（PD
新人プログラマ向け・スキル向上のための具体的なアプローチと考え方 - give IT a try
はじめに：「僕にもそんな頃があった」 先日、西脇.rb＆神戸.rbの合同勉強会として「RailsプログラマのためのSQL勉強会」を開催しました。 この勉強会は出題者（＝僕）が出したSQL問題を他の参加者が解く、というスタイルの勉強会です。 参加者の方の中には最近プログラミングを始めた、という人も何人かいました。 そういう人にとっては問題がちょっと難しかったので、ときどき僕がサポートに回って質問に答えたり、解き方をある程度教えたりしていました。 また、話がちょっと脱線して「僕が作ったこれぐらいのWebアプリは、伊藤さんなら何時間ぐらいで作れますか？」みたいな質問を受けたりもしました。 その中で言われたのが、 「説明されたらわかるけど、自分一人でこの答えにたどり着くのは無理です」 「えっ、そんな短い時間で作れるんですか」 といったようなコメントです。 そういったコメントを聞くと、「あー、僕にも
プログラマ向け：自分の強みや得意分野を見つける方法 - give IT a try
質問：あなたの強みや得意分野は何ですか？ プログラマのみなさんに質問です。 あなたの強みは何ですか？ 胸を張って「任せとけ！」と言える得意分野はありますか？ これはソニックガーデンの採用面談でよく聞かれる質問です。 僕もときどき採用希望の人と面談（という名の雑談）をすることがあるのですが、この質問に対して「はい、私はxxが得意です！」と即答できる人はかなり少ないです。 まあ、入社を希望する段階でいきなり「これが得意です！任せてください！」と言うのはかなり勇気がいりますよね。 下手に偉そうなことを言って、あとから「なんだ、大したことねーな」と思われたくない、という不安もきっとあるでしょう。 僕もかつては即答できなかった 何にせよ、即答できない気持ちはよくわかります。 実際、ソニックガーデンに入社した当時の僕もそうでした。 しかし、入社してから3年ほど経ってみると、いつの間にか僕にも得意分野（
英語力をアップさせる知見がいっぱい！「Rubyistのための英語勉強会」を開催しました - give IT a try
はじめに 先週の土曜日（2015/8/29）に西脇.rb＆神戸.rbの合同勉強会として「Rubyistのための英語勉強会」を開催しました。 nishiwaki-koberb.doorkeeper.jp この勉強会はその名の通り、Rubyist（Rubyプログラマ）の英語に対する苦手意識を克服し、英語力を高めることを目的にした勉強会です。 いちおうRubyist向けとはなっていますが、大半の内容はRubyist以外の人にも役立つものだと思います。 そこで今回のエントリではこの勉強会の内容や発表された知見等を紹介します。 会場は阪神深江のNilquebe（ニルキューブ）さんでした 当日の流れ 当日はこんな感じのタイムスケジュールで進行しました。 13：00～13：30 自己紹介 13：30～13：45 語彙力診断テスト 13：45～14：15 「こういうときに英語ができなくて困る」「英語ができ
プログラマ歴12年の僕が選んだ「10年経っても役立つ技術書17選」 - give IT a try
はじめに 僕がプログラミングを始めてから、もうすぐ12年になろうとしています。 この12年間、いろんな技術書を読んだり、仕事やプライベートでたくさんコードを書いたりしてきました。 最初に入ったSIerでは主にJavaを、前職の社内SE時代はC#をメインのプログラミング言語として使ってきました。 現在はRubyをメインで使っていますが、言語が変わっても、また何年経っても「これはあのとき学んだ知識が役に立ってるよなあ」と思う瞬間がときどきあります。 そこで今回はこれまでに読んだ技術書を一通り振り返り、「この本で学んだことは今でも役に立ってる」と思うものを17冊ピックアップしていきます。 おことわり (2014.09.29 20:00追記) このエントリのタイトルは「10年経った今でも役に立っている」という意味で付けています。「今から10年後まで役立つ」という意味ではありません。（紛らわしくてご
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
