過度なDRYは読みやすさの敵！？「リーダブルテストコード」という発表をしました #vstat - give IT a try
先日、このブログでもお伝えしましたが、「VeriServe Test Automation Talk No.3」というオンラインイベントで登壇してきました。 veriserve-event.connpass.com 申込者数はなんと1000人を超えていて、大変驚きました。 僕は「リーダブルテストコード」というテーマで発表しました。スライドはこちらです。 Twitterでたくさんシェアされたり、はてなブックマークがたくさん付いたり、こちらもすごい反響でビックリしました。 で、どんな内容だったの？ ひとことで言うなら「テストコードを徹底的にDRYにしようとしちゃダメよ！」というお話です。 このネタは昔からQiitaやTwitterとかでことあるごとに話してきましたが、この勉強会であらためてなぜダメなのか、DRYに書かず、どう書くべきなのか、という話を力説してみました。 優秀なプログラマほど、「
【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版プログラミ
Tama Ruby会議01で「テストコードの役割」について発表してきました #tamarubykaigi01 - give IT a try
はじめに 2019年7月6日、渋谷のGMO Yoursさんで開催されたTama Ruby会議01で「なぜテストを書くの？（または書かないの？） 〜テストコードの7つの役割〜」という発表をしてきました。 スライドはこちらです。 このエントリではこの発表の紹介やイベントの感想を書いていきます。 この発表テーマを選んだ経緯 スライドの9枚目にも書いたとおり、もともとは「RSpecを題材にしたテックな話を」とお願いされていました。 しかし、ネットなどを見ていると、「テストって難しい」「RSpecがわからん」と言っているプログラミング初心者さんたちは、テストについて何か根本的な思い違いをしているんじゃないか？という漠然とした疑問や懸念を僕は持っていました。 テストにおける「土台となる考え方」を会場のみなさんと共有したかった そういう状態でRSpecのテクニック的な話をしてもどこか歯車がかみ合わないと
ブログのサイドバーにGitHubの「草」を載せました（その動機と「ブログに草」のススメ） - give IT a try
お知らせ このブログのサイドバーにGitHubの「草」を載せました。 ただし、「草」が表示されるのはPC版のみです。 スマホで見ている方はPC版に切り替えてチェックしてみてください。 「えっ、草？草っていったい何！？」 GitHubの「草」をご存じない方のために、簡単にこの変わった技術者用語（ジャーゴン）を説明しておきましょう。 ここでいう「草」とは、GitHub上の活動状況を可視化するGitHubの機能のことを指します。 たくさん活動している人ほど、緑のマークが付いていき、それが草のように見えるので、「草」とか「芝生」と呼ばれます。 僕は表立った活動があまり多くないので緑の部分が少ないですが、すごい人は「まさに芝生！」というぐらい青々と緑が茂っています。 ちなみに上の画像は id:koic さんのGitHubプロフィールページから拝借しました。（すごい草の量！） 緑が多い人ほど「たくさん
Ruby関西 勉強会で「プロを目指す人のための例外処理（再）入門」という発表をしてきました #rubykansai - give IT a try
はじめに 2017年1月13日（土）に開催された第80回 Ruby関西勉強会で「プロを目指す人のための例外処理（再）入門」という発表をしてきました。 会場はすごくきれいで快適な、大阪梅田のグランフロントにあるAimingさんでした。 （どうもありがとうございました！） このエントリでは僕の発表内容と、勉強会中のエピソードを書いていきます。 発表スライド 当日使用した僕の発表スライドはこちらです。 例外処理については過去にいろいろ痛い目に遭わされているのと、間違った使い方をしている初心者さんをよく見かけるので、「お願いだから正しく使って！！」という気持ちでこのスライドを作りました😅 例外処理にまつわる僕の体験談については「本当にあった怖い話」としてスライド内で紹介していますw その他にも例外処理のバッドプラクティスやベストプラクティスなど、例外処理を書くときは絶対に押さえておきたいポイント
ひどいコードをメンテしてきたからこそ実感する、良いコードや良い設計の大切さ - give IT a try
はじめに 先日、社内で「良いコードの書き方やお作法、プログラミングの原則って、どうやったら身に付くんだろうねえ？」という話になりました。 もちろん、「本を読んで勉強する」っていのも勉強法のひとつなんですが、そもそも、もっと強烈なモチベーションがないと、必死になって良いコードの書き方やプログラミングの原則って勉強できないのでは？なんて思ったりします。 強烈なモチベーションというのは、たとえば、 いったい何なん！？このスパゲティコードは！！！ なんでこんなコードを俺がメンテしなきゃあかんの！！？？ あ～、もう最悪や！！俺はこんなコード、絶対に書かへんぞ！！！！ っていうぐらいのモチベーションです。 というか、これは単純に僕のケースですね、はい。 幸い、ソニックガーデンに入ってからは、周りのプログラマがみんなちゃんとしているので、そんな思いをすることはほぼなくなりましたが、前職、前々職ではそんな
シンプルでわかりやすいコードを書くためにあなたがすべきこと - give IT a try
はじめに 先日、とある知りあいのRubyプログラマからこんな相談を受けました。（内容はちょっとボカしてます） 社内のコードレビューでもっときれいなコードを書けるようになった方がいい、と言われました。 「きれいなコードを書けるようになれ」と言われても、具体的にどうすればいいかわかりません。 伊藤さんのアドバイスを聞きたいです。 この内容だけだとどんな問題があるのかわからないので、実際に指摘を受けたRailsアプリのコードを見せてもらいましたが、確かに「もうちょっと頑張りましょう」と思うような点がチラホラありました。 ただ、具体的にどうすればいいの、という答えは一言では言えません。 というわけで、今回のエントリではこの悩みを解決するのに参考になりそうな話をあれこれ書いてみようと思います。 （その前に）もくじ かなり長い記事になってしまったので、先に目次を載せておきます。 はじめに （その前に）
悩んでるポイントはみんな同じ！？「Rubyistのためのテストコード相談会」の質疑応答まとめ - give IT a try
はじめに 先週の土曜日（2015年5月16日）に西脇.rb＆神戸.rbで「Rubyistのためのテストコード相談会 ～テストの書き方に悩んでいませんか？～」という勉強会を開催しました。 この勉強会は「テストコードに関する疑問や悩みをみんなで持ち寄り、みんなで解決すること」を目的にした勉強会です。 勉強会中はいろいろと興味深い議論が出たので、今回のエントリではその内容を簡単にまとめてみます。 勉強会で挙がった質疑応答 よく使うフレームワークは？ RSpecが大多数、Minitestが若干名。 gemを開発するときはMinitest、RailsはRSpec、というように開発内容によってフレームワークを使い分ける、という人もいた。 Minitestってどうなの？ 導入が簡単。assertメソッドだけ知っていればなんとかなる。 Railsにも対応している。Capybaraも使える。 RSpecのs
ソニックガーデンで行われているコードレビューの具体例をお見せします (SonicGardn Study #11 の補足として) #sg_study - give IT a try
はじめに 2014年8月11日の晩に放送されたソニックガーデンのweb勉強会、SonicGardn Studyでは「いつまでクソコードを書き続けるの？ 〜出来るプログラマだけが知っているコードレビュー7つの秘訣〜」というタイトルで、弊社ソニックガーデンの西見さん(@mah_lab)が講演してくれました。 デキるプログラマだけが知っているコードレビュー7つの秘訣 from Masahiro Nishimi いつまでクソコードを書き続けるの？ 〜出来るプログラマだけが知っているコードレビュー7つの秘訣〜 - YouTube この放送の中でも触れられていたように、ソニックガーデンではコードレビューを大事にしています。 ただ、勉強会のスライドの中では具体的なコード例や指摘の例がほとんど出てこなかったので、「実際どんな感じなの？」という疑問を持った方もいたんじゃないかと思います。 そこで今回は「入社
動画(スクリーンキャスト)で学ぶRubyリファクタリング: Keitai Message編 - give IT a try
はじめに 僕が主催している西脇.rbの勉強会では、毎回「参加者が自分でコードを書く」「参加者がお互いにコードレビューする」ということを重視しています。 一言で言うと、「自分の手と頭を動かす勉強会」になっています。 先日開催した「Rubyプログラミング Dojo」でも、お題となるプログラミング問題を各自が解いて、最後に全員でコードレビューしました。 Photo by: @spring_aki その勉強会の参加者に岡田さん(@shinokada)という方がいます。 岡田さんは勉強会が終わったあとも自分でプログラミング問題を見つけて、解答となるRubyのコードを書いてきてくれました。 ただし、岡田さんはまだRubyを始めてそれほど長くないので、そのコードには改善する余地がまだまだあります。 そこで、岡田さんが書いてきてくれたそのコードを僕の方でレビューし、いろいろとリファクタリングしてみました。
ソフトウェア開発プロセス残酷物語 - give IT a try
昔々、あるところにジェイソンという、大変真面目な開発者がおりました。 彼がとある会社の情報システム部にやってきたとき、彼は社内システムのクオリティのひどさに衝撃を受けました。 情報システム部といっても、その会社では外注はせず、社内の開発メンバーがシステムを作っていました。 ジェイソンがそこで最初に担当したシステムは、見事なまでのスパゲッティコードでバグだらけ、データ設計も素人レベルでパフォーマンスも最悪、エラー処理もずさん、おまけにまともなドキュメントもなく、ちょっとした障害を調査したり、小さな改造を実施したりするのにも、大変な苦痛を伴うという、それはそれは大変なシロモノでした。 このシステムは元々エセーグルという、ちょっと変わった名前の開発者によって作られていました。 しかし彼はすでに別の開発チームに異動していて、こちらの質問には答えてくれますが、もはや本人が直接手を動かすことはありませ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
