過度なDRYは読みやすさの敵！？「リーダブルテストコード」という発表をしました #vstat - give IT a try
先日、このブログでもお伝えしましたが、「VeriServe Test Automation Talk No.3」というオンラインイベントで登壇してきました。 veriserve-event.connpass.com 申込者数はなんと1000人を超えていて、大変驚きました。 僕は「リーダブルテストコード」というテーマで発表しました。スライドはこちらです。 Twitterでたくさんシェアされたり、はてなブックマークがたくさん付いたり、こちらもすごい反響でビックリしました。 で、どんな内容だったの？ ひとことで言うなら「テストコードを徹底的にDRYにしようとしちゃダメよ！」というお話です。 このネタは昔からQiitaやTwitterとかでことあるごとに話してきましたが、この勉強会であらためてなぜダメなのか、DRYに書かず、どう書くべきなのか、という話を力説してみました。 優秀なプログラマほど、「
年内に発売？改訂版「プロを目指す人のためのRuby入門」を制作しています！ - give IT a try
お知らせ 現在、「プロを目指す人のためのRuby入門（通称・チェリー本）」の改訂版を制作中です。発売時期はまだ確定していませんが、年内の発売を目標に作業を進めています。順調にいけば12月のはじめぐらいには発売できるかもしれません。 現在発売中の「プロを目指す人のためのRuby入門」の第1版は2017年11月の発売なので、4年ぶりの改訂ということになります。 追記：発売日は2021年12月2日に決定しました 上で「順調にいけば12月のはじめぐらいには発売できるかもしれません」と書きましたが、発売には2021年12月2日に決定しました！Amazonにも販売ページができていて予約できるようになっています。 プロを目指す人のためのRuby入門［改訂2版］ 言語仕様からテスト駆動開発・デバッグ技法まで Software Design plus 作者:伊藤 淳一技術評論社Amazon で、どこがどう新
僕がRSpecでsubjectを使わない理由 - give IT a try
はじめに 僕は折に触れて「RSpecではなるべくsubjectを使わない方がいい」という発言をしています。 Qiitaとか見てるとRSpecのsubjectを愛用している人が多そうな印象なんだけど、僕はほとんど使っていません。「subjectは原則使わない。明らかにメリットがあるときにだけ例外的に使用する」が僕のポリシーです。ほら、RSpecの（元）メンテナさんもそう言ってるし。 https://t.co/Rp5EiIxCVb #Qiita pic.twitter.com/pMlN35ihEG— Junichi Ito (伊藤淳一) (@jnchito) 2019年5月28日 そもそもの話として、RSpecではsubjectは無理に使わない、というのが僕の持論です。なぜなら無理にを使うと、いびつなテストコードができやすいから。基本はsubjectなしで書く。明らかにsubjectが有効なと
【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版プログラミ
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
技術記事を書くことで得られる5つの効能 - give IT a try
先日、Qiitaの技術記事を書いているときに、ふと「そういえば、技術記事を書いてると、こういういいことがあるよなー」と思ったので、それをつらつらと書いてみます。 題して「技術記事を書くことで得られる5つの効能」です。 効能1：自分の理解が深まり、知識が定着する 「いいかげんな内容やウソは書きたくない」、「できるだけわかりやすく書きたい」と考えると、中途半端な理解や知識を必死に埋めようといろんなことを詳細に調べます。 その結果、記事を書く前よりもさらに自分の理解が深まって、知識が定着します。 効能2：「これ読んどいて」で説明が終わる コードレビューとかをしていて何か指摘を入れたくなったとき、そのトピックに関して過去に自分で書いた記事があると、「この記事を読んで修正してください」の一言で済むことがあります。 コードレビュー以外でも、「先日こんな問題に遭遇しました。みんなも気を付けて！」と、社内
アウトプットのネタに困ったらこれ！？Ruby初心者向けのプログラミング問題を集めてみた（全10問） - give IT a try
はじめに：「初心者は何をアウトプットすればいいの？」問題について 以前から何度か書いているのですが、Ruby初心者の方で「Rubyの勉強を始めました！アウトプットがんばります！」と言いつつ、実際はアウトプットしているのは、ほとんど書籍や他のサイトに書かれている内容を右から左へ丸写ししただけ、という方をよく見かけます。 その話題については、以下の記事で詳しくまとめているので、興味がある方はこちらをご覧ください。 blog.jnito.com qiita.com まあ、それはそれでさておき、「じゃあ、どうしたらいいの！？何をアウトプットすればあんたは満足するのさ！？」と思われる方も中にはおられるでしょう。 もちろん、その質問に対する回答についてはいろんなアプローチが考えられるのですが、今回は僕からひとつ、「アウトプット迷子」になっているプログラミング初心者さんに向けて、こんな提案をしてみたいと
ブログに技術書の内容を丸写しする問題点と、オリジナルなコンテンツを書くためのアイデア - give IT a try
はじめに 「プロを目指す人のためのRuby入門」を出版して以来、本で学んだ内容をブログに載せてくれている方をよく見かけます。 それ自体は著者として大変嬉しいのですが、たまに「ん？これはちょっと・・・」と思うようなブログ記事を見かけるときがあります。 具体的にいうと、本の内容を丸写ししているだけのブログ記事です。 このエントリでは本の丸写しがなぜいけないのか、かわりにどういうブログを書けばいいのか、ということについて書いていきます。 本の内容を丸写ししているブログの例 本の内容を丸写しをしているブログというのは文字通り「丸写し」しているブログです。 具体的なイメージを共有するために「こんな感じ」という例を載せておきます（特定の誰かのブログを意図しているわけではありません）。 タイトル「第2章 2.2.3 文の区切り」 「プロを目指す人のためのRuby入門」を読んでいるので、勉強した内容をメモ
デザイナさん直伝のCSSテクニックが満載！「RubyistのためのCSS勉強会」を開催しました - give IT a try
はじめに さる2016年1月9日、西脇.rb＆神戸.rbの合同勉強会として「RubyistのためのCSS勉強会」を開催しました。 主催者の僕自身が「参加して良かった！」と思えるぐらい有益な情報がたくさん詰まった勉強会になったので、今回のエントリではこの勉強会の内容を紹介します。 もくじ ちょっと長いので、先に目次を載せておきます。 はじめに もくじ 講師は合同会社フィヨルドの町田さん！ この勉強会で講義してもらったテーマ 座学編 Railsの app/assets/stylesheets 内のディレクトリ構成例 最近注目を集めているAtomic Designについて 3種類のリセット系CSSの特徴について 変更に強いマークアップのルールについて プログラマとデザイナの協業について ハンズオン編 進め方の具体例 1問目：グローバルナビゲーションの作成 2問目：アラート画面の作成 3問目：記事
このたびソニックガーデンの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ページを開く
