過度なDRYは読みやすさの敵！？「リーダブルテストコード」という発表をしました #vstat - give IT a try
先日、このブログでもお伝えしましたが、「VeriServe Test Automation Talk No.3」というオンラインイベントで登壇してきました。 veriserve-event.connpass.com 申込者数はなんと1000人を超えていて、大変驚きました。 僕は「リーダブルテストコード」というテーマで発表しました。スライドはこちらです。 Twitterでたくさんシェアされたり、はてなブックマークがたくさん付いたり、こちらもすごい反響でビックリしました。 で、どんな内容だったの？ ひとことで言うなら「テストコードを徹底的にDRYにしようとしちゃダメよ！」というお話です。 このネタは昔からQiitaやTwitterとかでことあるごとに話してきましたが、この勉強会であらためてなぜダメなのか、DRYに書かず、どう書くべきなのか、という話を力説してみました。 優秀なプログラマほど、「
Ask me anything! 伊藤さんに聞きたい12個の質問に本人が答えてみた（動画＆テキストバージョン） #yochiyochirb - give IT a try
はじめに 2019年3月3日、よちよち.rbのみなさんに呼ばれて、「jnchito さんと！Ruby・Rails での『困った』を解消しよう会」を開催してもらいました。 yochiyochirb.doorkeeper.jp これは、よちよち.rbのみなさんからいただいた質問に、僭越ながら僕が答えさせていただく、という勉強会です。 当日は約40人もの参加者が集まってくれました。みなさん、どうもありがとうございました🙏 「先生席」に座る伊藤さん（それにしてもホワイトボードの文字よ・・・） 勉強会では1時間半ぐらいかけてじっくりとみなさんの質問に回答したのですが、僕の回答をそこだけでクローズさせてしまうともったいないので、「ざっくりとまとめたショートバージョン」を動画とテキストで紹介します。 【もくじ】 はじめに 動画バージョン 1. 毎日チェックしている情報はありますか？ あわせて読みたい
「RSpec で example の外で定義したローカル変数を使うのはアリか？」に対する僕の見解と解決策 - give IT a try
はじめに 先日、「RSpec で example の外で定義したローカル変数を使うのはアリか？」というブログ記事を拝見しました。 ブログの作者である「きいあむ」さんは、「exampleの外で定義したローカル変数を使うのもアリなのでは？」というスタンスで記事を書かれています。 ですが、僕は「うーん、これはちょっと・・・」という感が否めません。 そこでこのエントリでは上記ブログ記事の内容に対する、僕の見解と考えられる解決策を書いていきます。 RSpecでテストを書くことがある人は参考にしてみてください。 上記ブログの簡単なまとめ さくっと要点を把握したい、という方のために、きいあむさんの意見を簡単にまとめておきます。 RSpecでは値を共通化するために、インスタンス変数やletを使います。 たとえば、何も考えずに愚直テストを書くとこんな感じになります。 describe User do it
JavaやC#の常識が通用しないRubyのprivateメソッド - give IT a try
衝撃を受けたできごと 最近Rubyを勉強しています。 JavaやC#でオブジェクト指向プログラミングの基本はマスターしてるから、Rubyもそのあたりは楽勝〜！・・・と思っていたら、JavaやC#の常識が全く通用しない振る舞いに遭遇してかなり衝撃を受けました。それは、 privateメソッドはサブクラスからも呼び出せる ・・・ということです！！がーん。 たとえば、JavaやC#だと自分のクラス内でprivateメソッドが使われていない場合、不要なメソッドとして削除できます。(リフレクションを使って呼び出される可能性はここでは無視ね) しかし、Rubyでは誰かがサブクラスを作って呼び出している可能性があるので、privateメソッドを削除する場合は注意が必要です。メソッド名を変更する場合も同様ですね。 また、知らずに親クラスと同名のprivateメソッドを定義すると、予期せず親クラスの実装をオ
ひどいコードをメンテしてきたからこそ実感する、良いコードや良い設計の大切さ - give IT a try
はじめに 先日、社内で「良いコードの書き方やお作法、プログラミングの原則って、どうやったら身に付くんだろうねえ？」という話になりました。 もちろん、「本を読んで勉強する」っていのも勉強法のひとつなんですが、そもそも、もっと強烈なモチベーションがないと、必死になって良いコードの書き方やプログラミングの原則って勉強できないのでは？なんて思ったりします。 強烈なモチベーションというのは、たとえば、 いったい何なん！？このスパゲティコードは！！！ なんでこんなコードを俺がメンテしなきゃあかんの！！？？ あ～、もう最悪や！！俺はこんなコード、絶対に書かへんぞ！！！！ っていうぐらいのモチベーションです。 というか、これは単純に僕のケースですね、はい。 幸い、ソニックガーデンに入ってからは、周りのプログラマがみんなちゃんとしているので、そんな思いをすることはほぼなくなりましたが、前職、前々職ではそんな
【書評】RSpecの初心者から上級者まで役立つ！「Effective Testing with RSpec 3」を読みました - give IT a try
はじめに 数ヶ月前、RSpecコミッタのYuji Nakayamaさん（@nkym37）から突然連絡がきて、「リードメンテナのMyron Marstonが今度RSpecの本を出版するんだけど、Myronが日本人のレビュアーを探している。なので伊藤さん、レビュー記事を書いてみない？」というお話を受けました。 「はい、興味あります！書きます！！」ということで、二つ返事でオファーを受けることにしました😄 というわけで、今回読んだのがこちらの「Effective Testing with RSpec 3」です。 Effective Testing With Rspec 3: Build Ruby Apps With Confidence 作者: Myron Marston,Ian Dees出版社/メーカー: Pragmatic Bookshelf発売日: 2017/08/25メディア: ペーパー
筆者自らが語る「プロを目指す人のためのRuby入門」のこだわりと見どころ - give IT a try
このブログでもすでに何度か紹介していますが、いよいよ2017年11月25日に僕が執筆した「プロを目指す人のためのRuby入門」が発売されます。 僕の手元には一足先に見本誌が届きました！ 表紙は真っ赤なチェリーが目印です。 背表紙もよく目立つ赤色！ 写真ではわかりにくいですが、普通の赤色ではなく、少しピンク色がかった個性的な赤色です。 すでに東京都内を中心に、一部の書店では先行発売が始まっています。 ジュンク堂書店 池袋本店（池袋） 三省堂書店（神保町） 書泉ブックタワー（秋葉原） 有隣堂 ヨドバシAKIBA店（秋葉原） 紀伊國屋書店 新宿本店（新宿） 丸善 丸の内本店（丸の内オアゾ） 丸善 ラゾーナ川崎店（川崎市） 書泉ブックタワーでは早くもコンピュータ書のベスト3に入ったらしいです。 （まだ先行発売期間中なのにすごい！） 【書泉ブックタワーコンピュータ書ベスト】11/12-11/18付
「プロを目指すRailsエンジニアのための公開コードレビュー」という発表をしました #railsdm - give IT a try
はじめに 2017年8月24日にRails Developers Meetup #4という勉強会で「プロを目指すRailsエンジニアのための公開コードレビュー」という発表をしてきました。 このエントリではこの勉強会の発表内容を紹介します。 発表のテーマを決めるまでの経緯 以前、「WEB+DB PRESS Vol.99の「良いコード」を本気でコードレビューしてみた」というエントリを書いて結構な反響があったのですが、この記事を読まれた主催者の平野さん（@yoshi_hirano）から「良いコードとは何か、というテーマで体系的に語ってもらいたい」と声をかけてもらったのが登壇のきっかけでした。 ただ、「良いコードを体系的に語る」となると、僕の中ではおそらく「CODE COMPLETEやリーダブルコードを読め。以上！」になってしまうので、それよりも具体的なコード例を見ながら「ここはこう」「このコード
新人プログラマ向け・スキル向上のための具体的なアプローチと考え方 - give IT a try
はじめに：「僕にもそんな頃があった」 先日、西脇.rb＆神戸.rbの合同勉強会として「RailsプログラマのためのSQL勉強会」を開催しました。 この勉強会は出題者（＝僕）が出したSQL問題を他の参加者が解く、というスタイルの勉強会です。 参加者の方の中には最近プログラミングを始めた、という人も何人かいました。 そういう人にとっては問題がちょっと難しかったので、ときどき僕がサポートに回って質問に答えたり、解き方をある程度教えたりしていました。 また、話がちょっと脱線して「僕が作ったこれぐらいのWebアプリは、伊藤さんなら何時間ぐらいで作れますか？」みたいな質問を受けたりもしました。 その中で言われたのが、 「説明されたらわかるけど、自分一人でこの答えにたどり着くのは無理です」 「えっ、そんな短い時間で作れるんですか」 といったようなコメントです。 そういったコメントを聞くと、「あー、僕にも
プログラマ向け：自分の強みや得意分野を見つける方法 - give IT a try
質問：あなたの強みや得意分野は何ですか？ プログラマのみなさんに質問です。 あなたの強みは何ですか？ 胸を張って「任せとけ！」と言える得意分野はありますか？ これはソニックガーデンの採用面談でよく聞かれる質問です。 僕もときどき採用希望の人と面談（という名の雑談）をすることがあるのですが、この質問に対して「はい、私はxxが得意です！」と即答できる人はかなり少ないです。 まあ、入社を希望する段階でいきなり「これが得意です！任せてください！」と言うのはかなり勇気がいりますよね。 下手に偉そうなことを言って、あとから「なんだ、大したことねーな」と思われたくない、という不安もきっとあるでしょう。 僕もかつては即答できなかった 何にせよ、即答できない気持ちはよくわかります。 実際、ソニックガーデンに入社した当時の僕もそうでした。 しかし、入社してから3年ほど経ってみると、いつの間にか僕にも得意分野（
妻のパン屋のwebサイトをいろいろ更新した話 ～Rails 4アップデートとかサイトの高速化とか～ - give IT a try
はじめに 僕の妻は兵庫県西脇市でCoupé Baguette (クープ バゲット)という小さなパン屋さんを営んでいます。 この店のwebサイトは僕がRailsで作り、Herokuでホスティングしています。 http://coupe-baguette.com 去年の1月に全面改装して以来、あまり触ってこなかったのですが、RubyやRailsのバージョンも古くなってきたので、そろそろ最新化したいな～という気持ちが高まっていました。 というわけで先日、ようやくサイトをアップデートすることができました。 見た目の変化は全くありませんが、内部的にはRubyのバージョンが1.9.3から2.1.1に、Railsのバージョンが3.2から4.1にアップデートされています。 さらに、TurbolinksやCloudFlare(CDN = Contents Delivery Network)も導入して、サイトの
ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
このたびソニックガーデンの7人目のメンバーになりました - give IT a try
はじめに タイトルにもある通り、このたび株式会社ソニックガーデンで働くことになりました。 Rubyやアジャイル開発に興味がある方なら、きっとみなさんソニックガーデンのことをご存知なのではないでしょうか。 代表取締役社長の倉貫さんをはじめ、選りすぐりの精鋭部隊が今回僕を迎え入れてくれたことは非常に光栄です。 会社のため、お客様のため、プログラマを憧れの職業にするため、日本のIT業界発展のために精一杯頑張ります！ どうやって働くの？ 一部の方はご存知かもしれませんが、僕は現在兵庫県西脇市に在住しています。 ソニックガーデンのオフィスは東京の渋谷にあります。 なので僕はこれから単身赴任・・・ではなく、地元西脇市からリモートで開発を行います。 わかりやすく言うと、在宅勤務です！ もっとも、最初の3ヶ月ぐらいは研修期間として東京で働きます。 余裕があれば東京の勉強会等に顔を出すかもしれません。その際
FizzBuzz問題を使って社内プログラミングコンテストを開催してみた - give IT a try
はじめに 先日、社内で初めてプログラミングコンテストを開催しました。 お題はかの有名なFizzBuzz問題です。 全員楽勝で解答するだろうと思いきや・・・結果はいかに！？ ちょっと長いエントリですが、このコンテストの顛末をお楽しみください。 開催の動機と経緯 メンバーの向上心を刺激するために、なにか面白くて技術的に意味のあるイベントを開きたかった。 以前からFizzBuzz問題を全員で解いてみたかった。 FizzBuzz問題はプログラマなら解けて当たり前、というようなWeb記事をよく見かけていた。 これぐらいなら誰でも解けるだろうと自分も思っていたが、実際にやってみないとわからない。 そこで社内プログラミングコンテストを開き、みんなでFizzBuzz問題を解いてみたいと思った。 マネージャーに話を持ちかけたところ、すぐに賛同してくれた。 FizzBuzz問題以外の追加問題も作成したが、第１
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
キャリア戦略 カテゴリーの記事一覧 - give IT a try