長年の悩みだったギターアンプのノイズが「マイ電柱」で直った件 - give IT a try
はじめに 僕は趣味でよくギター（エレキギター）を弾きます。 ですが、長年ずっと困っていたことがありました。 それはギターアンプのノイズです。 多かれ少なかれ、エレキギターを弾くときはアンプからノイズが出るものです。 しかし、僕の家のギターアンプからは明らかに異常な「キーン」というノイズが出ます。 実際どんな音なのかは以下の動画で確認できます。（うるさいのでボリュームには気を付けて！） www.youtube.com このノイズは以下のような特徴があります。 5〜6年前から急に発生し始めた 常時ノイズが出るわけではなく、たまに発生する ノイズが鳴り始めると鳴ったり止んだりを繰り返す ギターを変えても、アンプを変えても同じようにノイズが出る（なので、ギターやアンプの問題とは考えにくい） ギターを全くつないでいない状態でもノイズが出る（なので、ギターのピックアップがノイズを拾っているわけではない
僕が考える「良いコード」 - give IT a try
こんなコードだとわかりやすい 僕が考える良いコードの特徴（条件）を挙げてみると、 ぱっと見たら、だいたい何をやっているのかがわかるメソッド名 ぱっと見たら、だいたい中身が何なのか想像がつく変数名 ぱっと見たら、だいたい何をやっているのかが把握できるメソッドの内の処理フロー 驚きが少ないメソッド 副作用が少ないメソッド（責務が1つしかないメソッド） DRY原則を守っているコード だいたいこんな感じ。 つまり「すんなり読めて、すんなりわかるコード」が理想。 プログラムが小さいうちや、一人で開発しているうちは「汚くてわかりにくいコード」であっても「自分さえわかればOK」で済んじゃうけど、プログラムの規模が大きくなったり、複数人で開発するようになると、「汚くてわかりにくいコード」は絶望的に開発効率を下げる。 こんなコードはわかりにくい たとえば上の反対で、 メソッド名だけ見ても何をやっているのか想
妻がコロナになったので、生まれて初めて家事をワンオペで回そうとしたらめちゃくちゃ大変だった件 - give IT a try
はじめに ちょっと前の話になりますが、今年の1月頃に妻が新型コロナにかかりました。 僕と息子と娘は去年の夏にコロナになったのですが、家族では妻だけがかからなかったので、「妻は無敵なんじゃないか」と話していましたが、第8波の大きな波からはさすがの妻も逃げ切れなかったようです……。 ちなみに去年の夏にコロナにかかった話はこちらにまとめています↓ blog.jnito.com で、我が家において妻がコロナにかかって自宅隔離になるというのは、かなりの痛手です。 なぜなら、家事の大半が妻に依存していたからです。 以前から「かよこ（妻の名前）がコロナになったらヤバいよな〜」という話は夫婦でときどきしてたんですが、ついにそのリスクが現実になってしまいました😱 というわけで、このエントリでは妻が戦線離脱して僕が一人で家事を回そうとしたときに初めてわかったことや感じたことをあれこれまとめてみます。 我が家
雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try
（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
技術書にありがちな「IT技術は変化するけど、紙の本は更新できない問題」について僕なりの創意工夫を話してきました #DevReljp - give IT a try
先日のブログでもお伝えしたとおり、「DevRel Meetup in Tokyo #78 〜商業技術書出版を学ぼう〜」という勉強会で「出版したら終わり、にしない技術書執筆」という発表をしてきました。 devrel.connpass.com 当日使ったスライドはこちらです。 どんなことをしゃべったの？ 発表の概要はこんな感じです。 内容を随時更新できない紙の本と変化の速いIT技術はどうしても相性が悪い 相性の悪さは受け入れた上で、筆者が積極的に読者をサポートする 変化の速い技術は紙の本ではなく、電子書籍のみとするのも一手 拙著「プロを目指す人のためのRuby入門」の話題を中心に話しつつ、僕がなぜRailsの本ではなくRubyの本を書いたのかとか、電子書籍オンリーで販売している「Everyday Rails - RSpecによるRailsテスト入門」と紙の本の棲み分けについてどう考えているのか
【プログラミング初心者向け】クラスメソッドとインスタンスメソッドはどう使い分けるべき？ - give IT a try
はじめに ruby-jpのSlackで以下のような質問が投稿されていました。 クラスメソッドとインスタンスメソッドの具体的な違いがわかりません。 現状「クラスメソッドはクラスから実行でき全体に関する処理を書くときによく使うもの。インスタンスメソッドはインスタンスから実行でき、個別具体的な処理を書くときに使うもの。」という理解をしています。そして実装の際に「これはクラスメソッドとインスタンスメソッドどちらで書くべきなのか」悩むケースが多いです。 上記を踏まえて質問です。 クラスメソッドとインスタンスメソッドの具体的な違いを皆さんはどのように定義しているか どこからがクラスメソッドでどこからがインスタンスメソッドなのかの境目はどのあたりにあるか をお伺いしたいです！ クラスメソッドとインスタンスメソッドの使い分けは僕がメンターをやっているフィヨルドブートキャンプでもよく見かける質問です。 そこ
ITエンジニアがお金に関する本を10冊近く一気に読みあさってみた - give IT a try
はじめに：お金は稼げてるけどお金には無頓着な44歳ITエンジニア 僕はプログラマとして働いていて、株式会社ソニックガーデンのお給料やら、副業のフィヨルドブートキャンプのメンター料やら、執筆・翻訳した技術書（「プロを目指す人のためのRuby入門」と「Everyday Rails - RSpecによるRailsテスト入門」）の印税やらで、日本人の平均からすればそこそこいい年収を得ています。 具体的な金額は書けませんが、ここ数年は毎年1000万以上の年収がある、という感じです（機会があればこのへんの話も詳しく書きたい）。 が、基本的にお金には無頓着で生きておりまして、それゆえに毎年自分でもビックリするぐらいの税金を（泣きながら）払っております😭 あと、資産運用的なこともやっておらず、貯金がメインなので（浪費がメインという説もあり）、「あー、お金は稼いでるけど、そこからあとの使い方はなんかあんま
【書評】入門書は卒業したあなたに！"Polished Ruby Programming"を読みました - give IT a try
はじめに 最近発売されたRubyの洋書「Polished Ruby Programming」を読みました。 このエントリでは本書を読んだ感想を簡単にまとめてみます。 本書の感想 本書の著者はRubyコミッタとして有名なJeremy Evansさんです。 前書きにも明記されていますが、本書はRubyの中級者から上級者をターゲットにした本です。日本ではどうしてもRubyの本は初心者向けの本が多くなりますが（何を隠そう、僕もそういう本の著者の一人😅）、こういう「骨のある技術書」が出てくるのは非常に貴重だな、というのが第一印象です。 表面的なテクニックをなぞるのではなく、プログラムをどう設計すべきか、その設計にどういった良し悪しがあるか、といった点についても深く議論されています。そのため、サンプルコードだけでなく、英文もそれなりに書かれているのですが、使われている英語は比較的平易で、辞書無しでぱ
学校の勉強とプログラミングの勉強は何が違うか（そして技術書をどう読むべきか） - give IT a try
これは何？ これは僕がメンターをやっているフィヨルドブートキャンプで受講生向けに書いた記事です。 ただ、内容の8割ぐらいは未経験からプログラマを目指している初心者のみなさんにも役立つと思うので、そのまま公開することにしました。 想定読者は「フィヨルドブートキャンプの受講生」なので、フィヨルドブートキャンプの関係者以外の人が読むと「？？？」となる部分があるかもしれませんが、その点は悪しからず🙏 それでは以下が本編です。 はじめに みなさんはフィヨルドブートキャンプに入ってプログラミングの「勉強」をします。また、大半の受講生のみなさんは学校で「勉強」してきたと思います。どちらも「勉強」ですが、実は学校の勉強とプログラミングの勉強は異なる点が多いです。その違いを意識せずに、学校の勉強と同じ感覚でプログラミングの勉強をやると、非効率な勉強をしてしまう恐れがあります。 この記事ではプログラミングの
プログラミング初心者は変数名やメソッド名を略さない方がいいよ、という話 - give IT a try
今回のエントリでは先日、僕が勤めているソニックガーデンで話題になったプログラミング関連の小ネタを書きます。 それは何かというと、「プログラミング初心者は変数名やメソッド名を略さない方がいい」という話です。 長い変数名やメソッド名はつい略したくなります。 実際、僕も長い名前を略すときはよくあります。 ですが、略称を使うのは長年の経験から「この略称は一般的だから誤解を招くことはきっと少ないだろう」とか「前後の文脈から、変数の中身は誰が見ても明らかだろう」という想像が付いた場合だけです。 一方、プログラミング初心者の人は経験が浅いため、「一般的かどうか」とか、「誤解が発生しないかどうか」といった判断ができません。 そのため、他の人が見たときに「え、何この変数名？」と思ってしまうような略称を付けてしまう恐れがあります。 たとえば、先日のコードレビューで、初心者の人がrev_noという名前の変数を定
【初心者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
Rubyプログラマが中学校で情報モラル講演会をしてきたよ - give IT a try
はじめに 先日、Rubyプログラマが本職である僕が、なぜか地元・兵庫県西脇市の中学校で情報モラル教育に関する講演をしてきました。 このエントリではなんでそんなことになったのか、そしてどんなことを話したのか、といった話を書いていきます。 【もくじ】 はじめに 講演を依頼されたいきさつ 去年の情報モラル講演会は本当にひどかった 今年は誰かな〜？ → えっ、僕！？ 当日使用したスライド この講演で伝えたかったこと 「スマホやSNSは怖い」だけでは終わらせない トラブルに遭遇したら大人に頼る（一人で解決しようとしない） リスクを語るときは、必ず予防策と対処法をセットで伝える テクニカルな解決策（設定の変更等）は重視しない 大人だって失敗したり、ちゃんとできてなかったりすることを伝える 生徒さんたちの感想 その他の裏話等 「経験がない＆時間がない」で、かなり準備が大変だった 信頼が置ける専門家の方た
男女の参加バランスが良く、託児室があって、懇親会でぼっちにならないRuby勉強会を開催しました #tokyogirlsrb - give IT a try
はじめに このブログでも何度か紹介してきた「女性も参加しやすい（でも女性限定ではない）Ruby勉強会」、TokyoGirls.rb Meetupの記念すべき第１回を2019年3月2日に開催しました。 TokyoGirls.rb Meetupを開催しようと思った目的や背景は以前書いたこちらのエントリにまとめてあります。 今回のエントリでは、「男女の参加比率」「無料託児室」「懇親会のぼっち対策」という3つのポイントに注目しながら、当日の様子や運営上の工夫を書いてみたいと思います。 【もくじ】 はじめに ポイントその１. 「男性ばかり」でも「女性ばかり」でもない男女比率になりました 参加者の感想（と僕自身の感想） 男性エンジニアにも何かしらの気づきを与えられる勉強会でした 「自分は男性だし、興味がないなあ」という方も ポイントその２. 無料の臨時託児室を提供しました なかなか大変だった臨時託児室
女性も参加しやすい（でも女性限定ではない）Ruby勉強会を企画中です #tokyogirlsrb - give IT a try
お知らせ イベントページを公開しました！託児室もあります！たくさんのご参加をお待ちしております😃 techplay.jp はじめに タイトルの通りですが、現在、女性も参加しやすいRuby勉強会を有志のRubyistと企画しています。 まだ固まっていない部分もあるので変更される点が出てくるかもしれませんが、このエントリではこの勉強会の概要や開催のきっかけ等を書いてみようと思います。 【もくじ】 はじめに 女性も参加しやすい勉強会を開催しようと思った動機ときっかけ 女性の参加者や登壇者が目立ったRubyConf 男性でも女性でも興味がある勉強会には気軽に行けるようになってほしい 女性向けであることを明記しないと、女性の参加者は集まりにくい 勉強会の概要 登壇者と発表内容 ターゲットとなる参加者の方 運営チーム Q＆A Q. 女性限定ではなく男性も参加できるのはなぜですか？ Q. Rails
【問題提起】篠原嘉一氏に情報教育の講演を依頼する前に考えていただきたいこと ～ITエンジニアから見た、情報教育のあり方について～ - give IT a try
要約（僕の主張） 篠原嘉一氏の講演内容には、IT関連の知識がない人にはわかりづらいウソや間違い、極論が多く含まれているため、適切な情報教育だとは言いがたい。よって改善を強く希望する。 学校側は「生徒をネットのトラブルから守りたい」という思いが優先されるため、ITエンジニアよりも「情報の正しさ」がないがしろにされてしまうのかもしれない。だが、ITエンジニアとして、そして保護者として、学校は子どもたちに正しい情報を伝える努力をしてほしい。 我々ITエンジニアも情報教育を学校に丸投げするのではなく、正しい知識を伝えるために、主体的に情報教育に協力していく必要がある。 はじめに Image: http://www.mrf-ip.com/blog/0067/ 先日、息子が通っている中学校で開催された情報教育講演会に参加してきました。 これは中学校の全生徒と、任意参加の保護者で、情報教育（主にSNSや
結婚してから妻の影響で僕が変わったところを3つ挙げます - give IT a try
あぁ男もまた女によって変わるんだなぁ 最近は紅茶よりもコーヒーを飲んでるんだよ Mr.Children「友とコーヒーと嘘と胃袋」 はじめに 妻と結婚してからかれこれ10年以上経ちますが、結婚する前と今を比べると、妻の影響を受けていろいろ変わったよなーと思うことがあります。 あれこれあげるとキリがないのですが、その中から大きなものを3つ紹介したいと思います。 その１：ファッションや服装 一番大きく変わったのはファッションや服装かもしれません。 いや、変わったというより、全部妻に任せるようになりました。 僕が昔自分で選んでた服は「全部ダサい」とバッサリ切り捨てられ、結婚してすぐに捨てられました（苦笑）。 以後、購入する服やコーディネートは基本的に妻チョイスです。 「ちょっとそれは無理！」と思うような服ではない限り、基本的に妻の選んだ服を着ています。 こんなふうに書くと「かわいそう」とか「ひどい
ブログに技術書の内容を丸写しする問題点と、オリジナルなコンテンツを書くためのアイデア - give IT a try
はじめに 「プロを目指す人のためのRuby入門」を出版して以来、本で学んだ内容をブログに載せてくれている方をよく見かけます。 それ自体は著者として大変嬉しいのですが、たまに「ん？これはちょっと・・・」と思うようなブログ記事を見かけるときがあります。 具体的にいうと、本の内容を丸写ししているだけのブログ記事です。 このエントリでは本の丸写しがなぜいけないのか、かわりにどういうブログを書けばいいのか、ということについて書いていきます。 本の内容を丸写ししているブログの例 本の内容を丸写しをしているブログというのは文字通り「丸写し」しているブログです。 具体的なイメージを共有するために「こんな感じ」という例を載せておきます（特定の誰かのブログを意図しているわけではありません）。 タイトル「第2章 2.2.3 文の区切り」 「プロを目指す人のためのRuby入門」を読んでいるので、勉強した内容をメモ
技術書を書きたいITエンジニア必見！？「プロを目指す人のためのRuby入門」の舞台裏をお見せします - give IT a try
前回のブログでも書いたとおり、僕は2017年12月6日から10日まで東京に滞在していました。 そこで出会ったRubyプログラマのみなさんからよく聞かれたのは「あの本（＝プロを目指す人のためのRuby入門）って、書くのにどれくらいかかったんですか？」という質問です。 たしかに、Rubyのコードを書く人は多くても、本を書く人はあまりいないと思います。 そこで、このエントリでは執筆の様子がある程度わかるように、「プロを目指す人のためのRuby入門」（チェリー本）の執筆裏話を書いていこうと思います。 プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ) 作者: 伊藤淳一出版社/メーカー: 技術評論社発売日: 2017/11/25メディア: 大型本この商品を含むブログを見る ちょっと長いので先に目次を載せておきますね。
WEB+DB PRESS Vol.99の「良いコード」を本気でコードレビューしてみた - give IT a try
はじめに Twitterを見てたら、気になる雑誌の特集を見つけました。 WEB+DB PRESS Vol.99の「Rubyで学ぶ！良いコードって何だろう？」という特集記事です。 WEB+DB PRESS Vol.99 作者: ?橋健一,谷口禎英,井本大登,山崎勝平,大和田純,内村元樹,坂東昌哉,平田敏之,牧大輔,板敷康洋,大?浩崇,穴井宏幸,原口宗悟,久田真寛,ふしはらかん,のざきひろふみ,うらがみ,ひげぽん,池田拓司,はまちや2,竹原,片田雄樹,渋江一晃,WEB+DB PRESS編集部編出版社/メーカー: 技術評論社発売日: 2017/06/24メディア: 大型本この商品を含むブログを見るRuby大好き！きれいなコード大好き！！な僕にとっては、この特集は読まずにはいられません！ 早速買って読んでみました。 お～、なるほど、たしかにいいことが書いてある！ うんうん、そうそう・・・あれ？この
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
