雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try
（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
プログラミング初心者は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
発表でうまく話すためには （富山Ruby会議01のPRをかねて） #toyamark - give IT a try
はじめに 僕は今年の8月末に銀座Railsという勉強会で登壇してきました。 講演が終わったあと、Twitterでみなさんの感想を読んでいたところ、こんなツイートを見つけました。 今回も銀座Rails勉強になったな。 内容もさることながら、伊藤さん、喋りが上手いなぁと思って聞いていた。 構成とかどうやって考えてるとか、練習とかはどのぐらいしたんだろうかとか、後々思い返して結構気になってる。 #ginzarails— 𝕐.𝕊𝕦𝕫𝕦𝕜𝕚 (@y_s______731) August 29, 2019 どうもありがとうございます！ 発表のしゃべり方は、自分でもうまい方なんじゃないかと思っています（笑）。 コメントをくださった方が「構成の考え方や練習量が気になる」とおっしゃっているので、今回は僕が考える「発表でうまく話すコツ」を書いてみようと思います。 【もくじ】 はじめに いきなり種
過度な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
今回のエントリでは先日、僕が勤めているソニックガーデンで話題になったプログラミング関連の小ネタを書きます。 それは何かというと、「プログラミング初心者は変数名やメソッド名を略さない方がいい」という話です。 長い変数名やメソッド名はつい略したくなります。 実際、僕も長い名前を略すときはよくあります。 ですが、略称を使うのは長年の経験から「この略称は一般的だから誤解を招くことはきっと少ないだろう」とか「前後の文脈から、変数の中身は誰が見ても明らかだろう」という想像が付いた場合だけです。 一方、プログラミング初心者の人は経験が浅いため、「一般的かどうか」とか、「誤解が発生しないかどうか」といった判断ができません。 そのため、他の人が見たときに「え、何この変数名？」と思ってしまうような略称を付けてしまう恐れがあります。 たとえば、先日のコードレビューで、初心者の人がrev_noという名前の変数を定
【新人ITエンジニア向け】僕が仕事をする上で大事にしているポイントあれこれ - give IT a try
はじめに 社会人になると、いろんなタスクがあちこちからやってきて、対応するのが大変になります。 新卒で入社したばかりの新人ITエンジニアさんも、この先現場に投入されるといろんなタスクがやってきて忙しくなってくると思います。 そこでこのエントリでは、僕が仕事をする上で大事にしているポイントをいろいろと書いてみます。 この先もし、忙しくて忙殺されそうになったときは、このエントリを思い出して読み直してみてください。 このエントリの対象読者 僕はRailsプログラマとして働いているので、同じようにプログラマやITエンジニアとして働いている方を想定読者とします。 ただし、タスク管理という観点においては、技術職であってもそうでなくてもあまり変わりはないかもしれません。 また、タスク管理は仕事だけでなく、プライベートでも必要になるスキルです。 （たとえば結婚式の準備とか、勉強会の企画とか） これから書く
教えてリモートワーク・伊藤淳一さんの場合 〜仕事環境編〜 - give IT a try
はじめに この記事はフィヨルドブートキャンプの 「ちくしょう、勉強だ。」 キャンペーンの一環として書かれたインタビュー記事です。 新型コロナウィルスの感染拡大により家で過ごすことが増えていると思います。フィヨルドブートキャンプでは、 「ちくしょう、勉強だ。」 キャンペーンの一環として、プログラマーのリモートワークはどうなっているのか、フィヨルドブートキャンプにゆかりのあるメンター、卒業生、プロのエンジニアの方々にリモートワークの状況や環境、コツなどをインタビューしていきたいと思います。 第1回はkomagataさんでした。 fjord.jp 本エントリは第2回の記事（前編）になります。 Q1. お名前・お仕事・フィヨルドブートキャンプとの関係を教えてください。 伊藤淳一（@jnchito）です。株式会社ソニックガーデンでプログラマをやってます。 2020年2月からフィヨルドブートキャンプで
【初心者ITエンジニア向け】上手な質問は「相手にエスパーさせない質問」です - give IT a try
はじめに この春からITエンジニアになったみなさん、どうもおめでとうございます。 これからたくさん勉強して、立派なエンジニアを目指していきましょう！ ・・・と言っても、最初はわからないことだらけだと思います。 一人では解決できない壁にぶち当たったときは、他の人を頼って質問した方が学習効率が良いです。 とはいえ、質問するときは上手に質問しないと、自分も答える人も無駄に時間を食ってしまいます。 というわけで、今回のエントリでは「上手な質問」について書いてみたいと思います。 なお、ここで想定している質問は、社内掲示板のようなオンラインでの非同期な技術系Q＆Aを想定しています。 ですが、基本的な考え方は対面で質問する場合も変わらないと思います。 まずはネットで質問のセオリーを学ぼう 上手な質問のしかたについては、すでにネット上に優れた資料があります。 これらの資料に目を通してもらえれば、僕が言いた
みんなが安心して参加できる勉強会・懇親会のために主催者ができること（自由に再利用 or 改変可能なスライド付き） - give IT a try
はじめに 先日、TwitterでIT勉強会や懇親会に関するこちらのツイートを拝見しました。 ↓勉強会に参加したい ・レベルについていけないかも🤯 ・違う目的で参加している人居たら嫌だな(そもそも出会い目的じゃ無いし) ・内輪感あり過ぎてて溶け込めない雰囲気じゃないかな🤔 ・懇親会はコミュ力最大限に使うし目的違うのでいらない ↓不安の結果 やっぱり自宅で勉強しよ😇 ※繰り返し— Shoko Sato 🐶 (@satoshoco) January 11, 2020 勉強会数えきれないくらい行ってるけど人見知りなので未だに懇親会苦手感ある(とっても楽しいのだけど) 懇親会でTokyoGirls.rbのぼっち対策が行われた会を数件見ていて、この活動広まるといいなあ…と思ってる。 https://t.co/40b4y52I3I— makicamel (@makicamel) January
【書評】「レガシーコードからの脱却」の9つのプラクティスは圧倒的に正しい（経験者談） - give IT a try
はじめに 株式会社アトラクタの原田騎郎さん（@haradakiro）から、書籍「レガシーコードからの脱却」をご恵贈いただきました。（どうもありがとうございます！） せっかくいただいた本なので、本書を読んだ僕の感想を書いてみようと思います。 どんな本なの？ 端的に言うと、「初めからレガシーコードを作りださないための9つのプラクティスを説明した本」となります。 最初にタイトルを見たときの印象は「今そこにあるレガシーコードを、どうやってイケてるコードに書き直していくのか？」を説明した本なのかなと思ったんですが、本書が主眼としているのは「そもそもレガシーコードを作らないこと」でした。 ですので、「レガシーコード改善ガイド」とは毛色が違う本だと考えた方が良さそうです。 （「レガシーコード改善ガイド」は、「今そこにあるレガシーコードを改善する方法」を解説した本です） レガシーコード改善ガイド (Obj
Rubyプログラマが何を考え、どうやってコードを書くのか、その過程を動画にしてみました - give IT a try
はじめに：銀座Rails #12で登壇させてもらいました 去る2019年8月29日、銀座Rails #12で「プログラマがコードを書きながら考えること 」という発表をさせてもらいました。 ginza-rails.connpass.com この発表では「プログラマが書き上げたコード（＝完成形）」ではなく、「そのコードをどうやって書いたのか？（＝何を考え、どんなツールやテクニックを使って、どれくらいのスピードで書いたのかという点、すなわち、コードを書く過程）」をテーマにしました。 そして、その過程をわかりやすく伝えるために、スライドだけでなく、僕がガチンコでコードを書いていく様子を動画コンテンツとして会場のみなさんにお見せしました。 これまでいろんな勉強会やイベントで発表してきましたが、動画を事前に用意して発表で使ったのはこれが初めてです。 初めての試みなので、どうなるかちょっと不安でしたが、
Rubyプログラマが中学校で情報モラル講演会をしてきたよ - give IT a try
はじめに 先日、Rubyプログラマが本職である僕が、なぜか地元・兵庫県西脇市の中学校で情報モラル教育に関する講演をしてきました。 このエントリではなんでそんなことになったのか、そしてどんなことを話したのか、といった話を書いていきます。 【もくじ】 はじめに 講演を依頼されたいきさつ 去年の情報モラル講演会は本当にひどかった 今年は誰かな〜？ → えっ、僕！？ 当日使用したスライド この講演で伝えたかったこと 「スマホやSNSは怖い」だけでは終わらせない トラブルに遭遇したら大人に頼る（一人で解決しようとしない） リスクを語るときは、必ず予防策と対処法をセットで伝える テクニカルな解決策（設定の変更等）は重視しない 大人だって失敗したり、ちゃんとできてなかったりすることを伝える 生徒さんたちの感想 その他の裏話等 「経験がない＆時間がない」で、かなり準備が大変だった 信頼が置ける専門家の方た
恥ずかしがらずにオープンな場で積極的に質問していきましょう、という話 - give IT a try
はじめに 先日、Teratailに以下の質問が挙がっているのを見つけました。 Ruby - irbと打つと「can't find gem irb」とエラーが出ます。どうしたらいいでしょうか｜teratail 質問の内容は、「rbenvのインストール後、irbを起動しようとするとエラーが出て起動しない」というものです。 質問者の方は拙著「プロを目指す人のためのRuby入門」の学習を進めようとして、この問題に遭遇したそうです。 エラーが出てirbが起動しない、という現象は今まで聞いたことがありません。 irbはRubyが持つ基本機能の一つだからです。 原因は僕もはっきりわからなかったのですが、"rbenv-communal-gems"というあまり聞き慣れないrbenvプラグインを使っていたので、もしかしたらこれが原因ではないかと推測しました。 そこで、「もしかすると"rbenv-communa
男女の参加バランスが良く、託児室があって、懇親会でぼっちにならないRuby勉強会を開催しました #tokyogirlsrb - give IT a try
はじめに このブログでも何度か紹介してきた「女性も参加しやすい（でも女性限定ではない）Ruby勉強会」、TokyoGirls.rb Meetupの記念すべき第１回を2019年3月2日に開催しました。 TokyoGirls.rb Meetupを開催しようと思った目的や背景は以前書いたこちらのエントリにまとめてあります。 今回のエントリでは、「男女の参加比率」「無料託児室」「懇親会のぼっち対策」という3つのポイントに注目しながら、当日の様子や運営上の工夫を書いてみたいと思います。 【もくじ】 はじめに ポイントその１. 「男性ばかり」でも「女性ばかり」でもない男女比率になりました 参加者の感想（と僕自身の感想） 男性エンジニアにも何かしらの気づきを与えられる勉強会でした 「自分は男性だし、興味がないなあ」という方も ポイントその２. 無料の臨時託児室を提供しました なかなか大変だった臨時託児室
プログラマの成長とチクセントミハイのフロー理論 - give IT a try
はじめに 先日、はてなブックマークのホットエントリー入っていたこちらの記事を読みました。 https://note.mu/denkigai/n/nafff6bd87802note.mu すごく理路整然として読みやすい文章を書かれるので、プログラマとしても十分やっていけそうな方だなー、と思ったのですが、いろいろあって３年半で会社を辞められたそうです。（詳しくは上記記事をお読みください） この話を読んだときに、ふと「チクセントミハイのフロー理論」の話を思い出しました。 というわけで、このエントリではフロー理論の話と、僕自身の経験談などをつらつらと書いてみることにします。 フロー理論の「不安・退屈・フロー」 フロー理論は、集中力が高まってその人のパフォーマンスが最大限に活かせる「フロー状態」が有名です。 それだけでなく、フロー理論を説明するときは、人の精神状態を「不安・退屈・フロー」の3つに分け
GitHubのプランを有料(Pro)から無料(Free)にダウングレードする手順 - give IT a try
はじめに 2019年1月にGitHubのプランが変更され、今まで有料だったプライベートリポジトリも無料で使えるようになりました。 GitHub Free 無料で利用できるプランでも、プライベートリポジトリが利用できるようになりました。プライベートプロジェクトにGitHubを利用する開発者は、リポジトリごとに最大3人のコラボレータとの共同作業が可能です。パブリックリポジトリは(もちろん)引き続き無料で、コラボレータの数に制限はありません。 新しい年とともに、新しいGitHub を | The GitHub Blog 今のところ、個人で使用しているリポジトリに関しては1人か2人ぐらいのコラボレータしかいないため、「GitHubさん、どうもありがとう」という思いをこめつつ、月額7ドルの有料プラン(Pro)から無料プラン(Free)にダウングレードすることにしました。 このエントリではその手順を簡
開発時間短縮のためのプラクティス10選 - give IT a try
このエントリを書いた背景 先日会社で「開発時間を短縮するためのアイデアやノウハウをみんなでシェアしよう」という課題が出されました。 「カウボーイコーディングとコピペプログラミングで技術的負債たっぷりのシステムを作りましょう。そうすれば開発時間はぐっと短くなりますよ」なんてことは口が裂けても言えないので、真面目に考えてみました。 色々あるとは思うのですが、その中でも特に重要だったり、言語や技術を問わずに使えそうなものを10個選んでみました。 どれもまあ、基本中の基本だったり、アジャイル開発だと常識的に行われているようなことばっかりかもしれません。 とはいえ、おいらの会社に限定されるような話は載っていないので、ここにもその時に書いた内容をそのまんま載せておきます。 ただし、あなたの仕事とおいらの仕事は少し違うと思うので、読む前に以下の前提条件を確認しておいてください*1。 このエントリを読む前
O/Rマッピングツールに対する誤解をときたい - give IT a try
2010.12.23 追記 本エントリの続編となる「実装編」のブログを書きました。 こちらも合わせて読んでみてください。 O/Rマッピングツールに対する誤解をときたい -実装編 Part1- - give IT a try 本文にコメントすると泥沼に巻き込まれそうなので、ここに書いておきます。。。 http://el.jibun.atmarkit.co.jp/g1sys/2010/05/post-2d1b.html なんかこのコラムのコメントを読んでいると、「O/Rマッピングツール(ORM)はSQLを書きたくない開発者のためのツールだ」と思われているような感じを受けます。 おいらはこれまでORMを使った開発プロジェクトに3回参加しました。 確かに最初のプロジェクトでは「SQLを書かなくてもいいんだよ」とリーダーから説明されたような記憶があります。 しかしその発想は大きな誤解です。 ORMを
ITエンジニアが知っておきたい、軽減税率制度（のイヤなところ） - give IT a try
はじめに 僕の妻は兵庫県西脇市で「Coupé Baguette（クープ バゲット）」という小さなパン屋さんを営んでいます。 その関係で、先日国税庁から消費税の軽減税率制度に関するお知らせが届きました。 「軽減税率制度？あ〜、なんかそんな話もあったような」と思いながら資料を読んでみたところ、「げげっ、軽減税率制度ってこんな面倒な仕組みになってたの！？」とビックリしました。 というわけで、このエントリでは軽減税率制度の概要（と、ITエンジニアが困りそうなポイント）をざっくりとまとめてみます。 おことわり 僕自身は税理士のような税金の専門家ではないため、100%正しく理解しているとは限りません。 エントリ内に怪しい内容があればコメント欄等でご指摘いただけると助かります。 国税庁の資料から抜粋した、軽減税率制度の主なポイント 我が家にも届いた「よくわかる消費税軽減税率制度（平成30年7月）」（PD
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
