雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try
（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
過度なDRYは読みやすさの敵！？「リーダブルテストコード」という発表をしました #vstat - give IT a try
先日、このブログでもお伝えしましたが、「VeriServe Test Automation Talk No.3」というオンラインイベントで登壇してきました。 veriserve-event.connpass.com 申込者数はなんと1000人を超えていて、大変驚きました。 僕は「リーダブルテストコード」というテーマで発表しました。スライドはこちらです。 Twitterでたくさんシェアされたり、はてなブックマークがたくさん付いたり、こちらもすごい反響でビックリしました。 で、どんな内容だったの？ ひとことで言うなら「テストコードを徹底的にDRYにしようとしちゃダメよ！」というお話です。 このネタは昔からQiitaやTwitterとかでことあるごとに話してきましたが、この勉強会であらためてなぜダメなのか、DRYに書かず、どう書くべきなのか、という話を力説してみました。 優秀なプログラマほど、「
プログラミング初心者はgit commitする前に必ずdiffを自分でレビューするクセを付けよう - give IT a try
プログラミング初心者向けのTipsです。 まあ、タイトルに書いたとおりなんですが、プログラミング初心者は（というか、プログラマならみんな）git commitする前にdiffを自分でチェックするようにしましょう。 それはなぜか？ しょーもないミスを自分で見つけるためです。 しょーもないミスというのは例えば、消し忘れのコメントや、デバッグ用に書き込んだprint文、無駄な空行、おかしなインデント、管理対象外とすべき一時ファイルや隠しファイル等々です。 def create @book = Book.new(book_params) puts @book.title # ほら、デバッグ用のputsが残ってるよ！！ if @book.save redirect_to @book, notice: '登録しました' else render :new # インデントが1文字ズレてるよ！！ end e
Rails 6リリース記念！？Qiitaにいろいろ記事を書きました - give IT a try
先日、Rails 6が正式にリリースされました。 ついにRails 6が正式リリースされたようです！🎉 Rails 6.0: Action Mailbox, Action Text, Multiple DBs, Parallel Testing, Webpacker by default, and Zeitwerk | Riding Rails https://t.co/pHoJb68B97— Junichi Ito (伊藤淳一) (@jnchito) 2019年8月16日 だから、というわけでもないのですが、Rails関連の記事をいくつか書いてQiitaにアップしています。 Railsアプリのアップグレードの手順 1つ目はRailsアプリのアップグレード（バージョンアップ）の手順です。 永久保存版！？伊藤さん式・Railsアプリのアップグレード手順 - Qiita qiita.com
Rubyプログラマが中学校で情報モラル講演会をしてきたよ - give IT a try
はじめに 先日、Rubyプログラマが本職である僕が、なぜか地元・兵庫県西脇市の中学校で情報モラル教育に関する講演をしてきました。 このエントリではなんでそんなことになったのか、そしてどんなことを話したのか、といった話を書いていきます。 【もくじ】 はじめに 講演を依頼されたいきさつ 去年の情報モラル講演会は本当にひどかった 今年は誰かな〜？ → えっ、僕！？ 当日使用したスライド この講演で伝えたかったこと 「スマホやSNSは怖い」だけでは終わらせない トラブルに遭遇したら大人に頼る（一人で解決しようとしない） リスクを語るときは、必ず予防策と対処法をセットで伝える テクニカルな解決策（設定の変更等）は重視しない 大人だって失敗したり、ちゃんとできてなかったりすることを伝える 生徒さんたちの感想 その他の裏話等 「経験がない＆時間がない」で、かなり準備が大変だった 信頼が置ける専門家の方た
RubyプログラマによるEIZO EV2785（27インチ・4Kディスプレイ）使用レビュー - give IT a try
はじめに 僕は2019年1月末に、EIZOのEV2785-BKという27インチ・4Kディスプレイを購入しました。 EIZO FlexScan 27.0インチ ディスプレイモニター (4K UHD/IPSパネル/ノングレア/ブラック/USB Type-C搭載/5年間保証&無輝点保証) EV2785-BK 出版社/メーカー: EIZO発売日: 2018/01/30メディア: Personal Computersこの商品を含むブログを見るこのディスプレイを購入して2ヶ月ほど経ったので、実際に使ってみた感想をあれこれ書いてみようと思います。 なお、僕の使用環境は以下のとおりです。 使用PC MacBook Pro 2017 13-inch, Touch Barありモデル 主な用途 プログラミング（職業は在宅で働くRubyプログラマ） その他 EIZO EV2736Wからの買い換え 【もくじ】 はじ
自由に再利用＆改変可能（CC BY）なアンチハラスメントポリシーを作成しました #tokyogirlsrb - give IT a try
はじめに 2019年3月2日に開催されるTokyoGirls.rb Meetup vol.1の開催に向けて、TokyoGirls.rbでは独自のアンチハラスメントポリシーを作成しました。 このアンチハラスメントポリシーは、クリエイティブ・コモンズ 表示 4.0 国際（CC BY 4.0）ライセンスで公開しているため、どのコミュニティでも自由に再利用および改変することができます。 このエントリではこのアンチハラスメントポリシーに関する詳しい情報を紹介します。 【もくじ】 はじめに そもそも「アンチハラスメントポリシー」って何？ アンチハラスメントポリシーを策定する動機 で、どんなアンチハラスメントポリシーなの？ このアンチハラスメントポリシーの特徴 見出しを付けて文書構造をわかりやすく 文章は極力簡潔に あえて強い言葉を使わない 自由に再利用と改変ができるライセンスにした まとめ：冷たい鎖で
プログラマの成長とチクセントミハイのフロー理論 - give IT a try
はじめに 先日、はてなブックマークのホットエントリー入っていたこちらの記事を読みました。 https://note.mu/denkigai/n/nafff6bd87802note.mu すごく理路整然として読みやすい文章を書かれるので、プログラマとしても十分やっていけそうな方だなー、と思ったのですが、いろいろあって３年半で会社を辞められたそうです。（詳しくは上記記事をお読みください） この話を読んだときに、ふと「チクセントミハイのフロー理論」の話を思い出しました。 というわけで、このエントリではフロー理論の話と、僕自身の経験談などをつらつらと書いてみることにします。 フロー理論の「不安・退屈・フロー」 フロー理論は、集中力が高まってその人のパフォーマンスが最大限に活かせる「フロー状態」が有名です。 それだけでなく、フロー理論を説明するときは、人の精神状態を「不安・退屈・フロー」の3つに分け
ブログのサイドバーにGitHubの「草」を載せました（その動機と「ブログに草」のススメ） - give IT a try
お知らせ このブログのサイドバーにGitHubの「草」を載せました。 ただし、「草」が表示されるのはPC版のみです。 スマホで見ている方はPC版に切り替えてチェックしてみてください。 「えっ、草？草っていったい何！？」 GitHubの「草」をご存じない方のために、簡単にこの変わった技術者用語（ジャーゴン）を説明しておきましょう。 ここでいう「草」とは、GitHub上の活動状況を可視化するGitHubの機能のことを指します。 たくさん活動している人ほど、緑のマークが付いていき、それが草のように見えるので、「草」とか「芝生」と呼ばれます。 僕は表立った活動があまり多くないので緑の部分が少ないですが、すごい人は「まさに芝生！」というぐらい青々と緑が茂っています。 ちなみに上の画像は id:koic さんのGitHubプロフィールページから拝借しました。（すごい草の量！） 緑が多い人ほど「たくさん
Rails Girls Osaka #5 に参加して、女性限定イベントであることの意味を考えた #railsgirlsosaka - give IT a try
はじめに 2018年6月17日に開催された、Rails Girls Osaka #5にコーチとして参加してきました。 今日はこちらのイベントに参加しております。 #railsgirlsosaka pic.twitter.com/lTEpRha2Bg— Junichi Ito (伊藤淳一) (@jnchito) June 17, 2018 Rails Girlsは以前から興味はあったのですが、参加したのは今回が初めてです。 機会があれば参加したいと思っていたのですが、コーチ枠も結構早く埋まってしまうんですよね。 ですが、今回は「コーチが不足して困っている」という情報を見かけたので、「お、これはチャンス！」と思って参加することにしました。 https://www.facebook.com/RubyKansai/posts/2172675319426147 というわけで、このエントリではRail
【問題提起】篠原嘉一氏に情報教育の講演を依頼する前に考えていただきたいこと ～ITエンジニアから見た、情報教育のあり方について～ - give IT a try
要約（僕の主張） 篠原嘉一氏の講演内容には、IT関連の知識がない人にはわかりづらいウソや間違い、極論が多く含まれているため、適切な情報教育だとは言いがたい。よって改善を強く希望する。 学校側は「生徒をネットのトラブルから守りたい」という思いが優先されるため、ITエンジニアよりも「情報の正しさ」がないがしろにされてしまうのかもしれない。だが、ITエンジニアとして、そして保護者として、学校は子どもたちに正しい情報を伝える努力をしてほしい。 我々ITエンジニアも情報教育を学校に丸投げするのではなく、正しい知識を伝えるために、主体的に情報教育に協力していく必要がある。 はじめに Image: http://www.mrf-ip.com/blog/0067/ 先日、息子が通っている中学校で開催された情報教育講演会に参加してきました。 これは中学校の全生徒と、任意参加の保護者で、情報教育（主にSNSや
筆者自らが語る「プロを目指す人のためのRuby入門」のこだわりと見どころ - give IT a try
このブログでもすでに何度か紹介していますが、いよいよ2017年11月25日に僕が執筆した「プロを目指す人のためのRuby入門」が発売されます。 僕の手元には一足先に見本誌が届きました！ 表紙は真っ赤なチェリーが目印です。 背表紙もよく目立つ赤色！ 写真ではわかりにくいですが、普通の赤色ではなく、少しピンク色がかった個性的な赤色です。 すでに東京都内を中心に、一部の書店では先行発売が始まっています。 ジュンク堂書店 池袋本店（池袋） 三省堂書店（神保町） 書泉ブックタワー（秋葉原） 有隣堂 ヨドバシAKIBA店（秋葉原） 紀伊國屋書店 新宿本店（新宿） 丸善 丸の内本店（丸の内オアゾ） 丸善 ラゾーナ川崎店（川崎市） 書泉ブックタワーでは早くもコンピュータ書のベスト3に入ったらしいです。 （まだ先行発売期間中なのにすごい！） 【書泉ブックタワーコンピュータ書ベスト】11/12-11/18付
関西Ruby会議2017で「Rubyistと技術記事」という発表をしてきました #kanrk2017 - give IT a try
はじめに 2017年5月27日に開催された関西Ruby会議2017で「Rubyistと技術記事」という発表をしてきました。 このエントリではこの発表の内容や、イベントの様子を紹介します。 当日はこんな会場でした。広い！ スライドと発表内容の概要 発表で使ったスライドはこちらです。 スライドを見てもらえば、発表内容はだいたいつかめるはずです。 ただ、僕はスライドに書いていないことも口頭でいろいろしゃべるスタイルなので、細かい内容は会場にいないとわからないと思います。 もし「細かい内容も知りたい！」という人がいたら、Twitter等でコンタクトをください。 一般に公開していないマル秘資料（何？）をお渡しします。 8割ぐらいのみなさんが僕のことを知ってた！ 発表の途中で、会場のみなさんに「僕のことを知ってる人はどれくらいいますか？」って聞いてみたら、8割ぐらいの人が手を挙げてくれました！ こんな
ITエンジニアが誤った情報にツッコミを入れるのは「正しさハラスメント」ではない - give IT a try
はじめに 先日、はてなブックマークで話題になっていたこちらの記事を拝見しました。 確かに「一理ある」といえばそうなんですが、僕個人はこの意見に対して率直に「NO」だと感じました。 僕は基本的に自分の専門分野であれば、結構積極的に技術記事にツッコミを入れていくタイプです。 このエントリでは、なぜ僕は「NO」だと感じたのか、そしてなぜ積極的にツッコミをいれていくのか、その理由について書いていこうと思います。 元記事の要点 僕なりに元記事を要点をピックアップすると次のようになりました。 ITエンジニアの中には初心者の成功体験を折りに来る人がいる。 筆者は成功体験の「気持ちいい」状態を阻害する行為に疑問を覚える。 初心者にはセキュリティ周りについて教えても仕方がない。 初心者もいずれセキュリティ対策について知識を得るはずだ。 早すぎる指摘が生まれるのは「それが間違っているから」だ。 初心者にはまず
「レンジで字が消える！」というYouTube動画を真似した息子がノートを黒焦げにした話（※追記あり） - give IT a try
2016.10.30 追記：おわび この記事は元々、YouTubeをよく見ているお子さんを持つ保護者のみなさんに向けて、注意喚起をしたいと思って書いた記事でした。 ですが、YouTubeの利用規約には「本サービスは13歳未満の子供による利用を意図していません。あなたが13歳未満の場合、YouTubeウェブサイトを利用しないで下さい。」との記述があります。 お恥ずかしいことに私はこの利用規約をちゃんと確認していませんでした。 利用規約を確認しないまま、子どもにYouTubeを視聴させてしまったことは、私の完全な注意不足でした。 大変申し訳ありませんでした。 また、記事の中で「おそらく動画を投稿した本人たちはそこまでの危険性があるとは自覚していないのでしょうが、もう少し想像力を働かせて上記のような問題点に配慮してほしかったなと思います。」と書きましたが、私もこのブログを公開することで動画を投稿
Everyday Railsのチャリティセールはあと1週間です！(2016年5月31日まで) - give IT a try
すでに目標額の倍以上、1,125.83ドル（約12万3000円）に到達！ このブログの読者の方はすでにご存知だと思いますが、熊本地震の災害支援のために2016年4月25日から2016年5月31日まで「Everyday Rails - RSpecによるRailsテスト入門」のチャリティセールを実施しています。 収益はなんと昨日（2016年5月24日）の時点で 1,125.83ドル（約12万3000円） になりました！ 売上部数でいうと、合計114部になります。 当初の目標は500ドルでしたが、すでに目標額の倍に到達してしまいました。 これはとても嬉しい驚きです。 購入してくださったみなさん、どうもありがとうございました！ チャリティセールは残り1週間です！ このチャリティーセールは5月31日までなので、今日を含めるとあと7日で終了します。 6月1日からは最低購入価格を9ドルから16ドル（通常
シンプルでわかりやすいコードを書くためにあなたがすべきこと - give IT a try
はじめに 先日、とある知りあいのRubyプログラマからこんな相談を受けました。（内容はちょっとボカしてます） 社内のコードレビューでもっときれいなコードを書けるようになった方がいい、と言われました。 「きれいなコードを書けるようになれ」と言われても、具体的にどうすればいいかわかりません。 伊藤さんのアドバイスを聞きたいです。 この内容だけだとどんな問題があるのかわからないので、実際に指摘を受けたRailsアプリのコードを見せてもらいましたが、確かに「もうちょっと頑張りましょう」と思うような点がチラホラありました。 ただ、具体的にどうすればいいの、という答えは一言では言えません。 というわけで、今回のエントリではこの悩みを解決するのに参考になりそうな話をあれこれ書いてみようと思います。 （その前に）もくじ かなり長い記事になってしまったので、先に目次を載せておきます。 はじめに （その前に）
英語力をアップさせる知見がいっぱい！「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 「こういうときに英語ができなくて困る」「英語ができ
MinitestとRSpec、FixturesとFactoryGirlの良いところ悪いところをコードを書いて比較してみた - give IT a try
（2022.5.4追記） FactoryGirlはFactoryBotという名前に変更されています（参考）。この記事は昔の名前である「FactoryGirl」を使っています。 はじめに 今年のゴールデンウイークはMinitestとRSpec、FixturesとFactoryGirlについていろいろ研究（？）していました。 具体的にはこんなことをやっていました。 Rails Tutorial 第3版を写経した（第3版ではMinitestとFixturesを使っている） Rails TutorialのテストコードをRSpecとFactoryGirlで書き直した Everyday RailsのテストコードをRSpec + FactoryGirlからMinitest + Fixturesに書き直した The Minitest Cookbookを読んだ 今回のエントリではMinitestとRSpec
Ruby初心者必見！？「ビンゴカード作成問題」のリファクタリング風景をお見せします #codeiq - give IT a try
はじめに 先月、CodeIQにビンゴカード作成問題を出題しました。 CodeIQに「ビンゴカード作成問題」を出題しました。みなさんの挑戦をお待ちしてます！ - give IT a try このビンゴカード作成問題、ありがたいことに50人もの方が解答を送ってくれました。 挑戦してくださったみなさん、どうもありがとうございました。 前回のエントリでは優秀作品ベスト3を発表しました。 今回のエントリはその続編です。 一部の解答（5本）について、僕が実際にいただいた解答を採点しつつ、リファクタリングする様子を動画に撮っておいたので、その様子をお見せしちゃいます。 おさらい「ビンゴカード作成問題」とは？ ビンゴカード作成問題とはその名の通り、Rubyを使ってビンゴカードを出力する問題です。 Bingo.generate_cardというメソッドを呼ぶと以下のような文字列を出力する、というのが要求仕様で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
