タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
【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版プログラミ
はじめに 僕は趣味でよくギター（エレキギター）を弾きます。 ですが、長年ずっと困っていたことがありました。 それはギターアンプのノイズです。 多かれ少なかれ、エレキギターを弾くときはアンプからノイズが出るものです。 しかし、僕の家のギターアンプからは明らかに異常な「キーン」というノイズが出ます。 実際どんな音なのかは以下の動画で確認できます。（うるさいのでボリュームには気を付けて！） www.youtube.com このノイズは以下のような特徴があります。 5〜6年前から急に発生し始めた 常時ノイズが出るわけではなく、たまに発生する ノイズが鳴り始めると鳴ったり止んだりを繰り返す ギターを変えても、アンプを変えても同じようにノイズが出る（なので、ギターやアンプの問題とは考えにくい） ギターを全くつないでいない状態でもノイズが出る（なので、ギターのピックアップがノイズを拾っているわけではない
（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
はじめに：お金は稼げてるけどお金には無頓着な44歳ITエンジニア 僕はプログラマとして働いていて、株式会社ソニックガーデンのお給料やら、副業のフィヨルドブートキャンプのメンター料やら、執筆・翻訳した技術書（「プロを目指す人のためのRuby入門」と「Everyday Rails - RSpecによるRailsテスト入門」）の印税やらで、日本人の平均からすればそこそこいい年収を得ています。 具体的な金額は書けませんが、ここ数年は毎年1000万以上の年収がある、という感じです（機会があればこのへんの話も詳しく書きたい）。 が、基本的にお金には無頓着で生きておりまして、それゆえに毎年自分でもビックリするぐらいの税金を（泣きながら）払っております😭 あと、資産運用的なこともやっておらず、貯金がメインなので（浪費がメインという説もあり）、「あー、お金は稼いでるけど、そこからあとの使い方はなんかあんま
おことわり このエントリには健康に関する話題が載っていますが、筆者は専門家ではないので、あまり鵜呑みにせず話半分で読んでやってください。 はじめに：我が家に全自動コーヒーマシンがやってきた 最近、デロンギの全自動コーヒーマシンを買いました。 「マグニフィカS カプチーノ スマート コンパクト全自動コーヒーマシン (ECAM23260SBN)」っていうやつです。 【スタンダードモデル】デロンギ(DeLonghi)コンパクト全自動コーヒーメーカー ブラック マグニフィカ S カプチーノ スマート 自動カフェラテ・カプチーノ機能 ECAM23260SBN DeLonghi(デロンギ)Amazon このコーヒーマシンを使えば、ボタンひとつで美味しいコーヒーが飲める！ おうちでファミレスのドリンクバー気分！ わーいわーい！🙌 ・・・と、嬉しがって毎日コーヒーをがぶ飲みしてました。 以前からそこそこ
はじめに 僕は自宅で長年WAKWAKというインターネットプロバイダを利用してたんですが、最近OCNに乗り換えました。 ・・・というだけなら「ふーん」で終わってしまうのですが、実は3ヶ月ぐらいかけて、 WAKWAK ↓ OCN ↓ BIGLOBE ↓ OCN とプロバイダを転々と切り替えながら、最終的にOCNを（しかもIPv6ではなくIPv4で）利用することに決めました。 このエントリではどういう経緯でこの結論に至ったのかを紹介します。 【もくじ】 はじめに 我が家のインターネット環境の紹介と、おことわり 用語の整理 困っていたこと：Amazon S3のファイルダウンロードが遅すぎる！！ IPv6にしてもまだ遅い！ iPhoneのテザリングだと夜でも3秒でダウンロードできるんですが？ NTTの人が試しにOCNにつないだら、あれ？速い！！ IPv4だと速いのに、IPv6だと遅いOCN・・・ 同
こんなコードだとわかりやすい 僕が考える良いコードの特徴（条件）を挙げてみると、 ぱっと見たら、だいたい何をやっているのかがわかるメソッド名 ぱっと見たら、だいたい中身が何なのか想像がつく変数名 ぱっと見たら、だいたい何をやっているのかが把握できるメソッドの内の処理フロー 驚きが少ないメソッド 副作用が少ないメソッド（責務が1つしかないメソッド） DRY原則を守っているコード だいたいこんな感じ。 つまり「すんなり読めて、すんなりわかるコード」が理想。 プログラムが小さいうちや、一人で開発しているうちは「汚くてわかりにくいコード」であっても「自分さえわかればOK」で済んじゃうけど、プログラムの規模が大きくなったり、複数人で開発するようになると、「汚くてわかりにくいコード」は絶望的に開発効率を下げる。 こんなコードはわかりにくい たとえば上の反対で、 メソッド名だけ見ても何をやっているのか想
妻がコロナになったので、生まれて初めて家事をワンオペで回そうとしたらめちゃくちゃ大変だった件 - give IT a try
はじめに ちょっと前の話になりますが、今年の1月頃に妻が新型コロナにかかりました。 僕と息子と娘は去年の夏にコロナになったのですが、家族では妻だけがかからなかったので、「妻は無敵なんじゃないか」と話していましたが、第8波の大きな波からはさすがの妻も逃げ切れなかったようです……。 ちなみに去年の夏にコロナにかかった話はこちらにまとめています↓ blog.jnito.com で、我が家において妻がコロナにかかって自宅隔離になるというのは、かなりの痛手です。 なぜなら、家事の大半が妻に依存していたからです。 以前から「かよこ（妻の名前）がコロナになったらヤバいよな〜」という話は夫婦でときどきしてたんですが、ついにそのリスクが現実になってしまいました😱 というわけで、このエントリでは妻が戦線離脱して僕が一人で家事を回そうとしたときに初めてわかったことや感じたことをあれこれまとめてみます。 我が家
Twitterに書こうかと思ったけど、明らかに字数オーバーするのでブログに書きます。 タイトルの通り、技術書を紙の本で読むか、電子書籍で読むか、という話です。 結論からいうと、僕は基本的に紙の本を選びます。 紙の本のメリット3つ（+1つ） 1. 自分にプレッシャーをかけられる 一番の理由は、机の上に置いて「最後まで読め」と自分にプレッシャーをかけられるからです。 上の写真のように、いやでも目に付く場所に常時置いておくことで、思い出す機会や手に取る機会を増やすことができます。 これが電子書籍だと姿形（すがた・かたち）が見えなくなるので、強い意志を持っていないと「積ん読」のまま終わってしまう可能性が高くなります。 参考：ちなみに今読んでいる本はこれです↓ プログラミングTypeScript ―スケールするJavaScriptアプリケーション開発 作者:Boris Cherny発売日: 2020
過度なDRYは読みやすさの敵！？「リーダブルテストコード」という発表をしました #vstat - give IT a try
先日、このブログでもお伝えしましたが、「VeriServe Test Automation Talk No.3」というオンラインイベントで登壇してきました。 veriserve-event.connpass.com 申込者数はなんと1000人を超えていて、大変驚きました。 僕は「リーダブルテストコード」というテーマで発表しました。スライドはこちらです。 Twitterでたくさんシェアされたり、はてなブックマークがたくさん付いたり、こちらもすごい反響でビックリしました。 で、どんな内容だったの？ ひとことで言うなら「テストコードを徹底的にDRYにしようとしちゃダメよ！」というお話です。 このネタは昔からQiitaやTwitterとかでことあるごとに話してきましたが、この勉強会であらためてなぜダメなのか、DRYに書かず、どう書くべきなのか、という話を力説してみました。 優秀なプログラマほど、「
はじめに：包丁が切れない！ 僕は全然料理をしない（できない）んですが、妻は料理が大好きです。 しかし、包丁が切れないことに不満を持っていて、「包丁が切れない、新しい包丁が欲しい」とずっと嘆いていました。 もちろん、毎日使う道具なので新しい包丁を買うことぐらいは全然構わないのですが、新しい包丁を買う以外に、「包丁を自分で研ぐ」という選択肢もあります。 いや、いちおう簡易シャープナーはあるんですよ。こんなやつが。 グローバル スピードシャープナー GSS-01 グローバル(Global)Amazon しかし、妻曰く「シャープナーを使っても翌日には切れ味が落ちる」とのことです。 なので、シャープナーではなく、ダメ元でいいから砥石を使ってちゃんと自分で一度研いでみよう、という話になりました。 よし、YouTubeで勉強だ！ 砥石で包丁なんて一度も研いだことがないのですが、とりあえずYouTubeで
フィヨルドブートキャンプのコードレビューでよく指摘してるシリーズです。 次のようなパンを焼くRubyプログラムがあります。 このプログラムはどういう工程を経てパンが焼かれるのか、ぱっと把握できますか？ def main パンを焼く(粉, 水) end def パンを焼く(粉, 水) 焼く(パンを発酵させる(粉, 水)) end def パンを発酵させる(粉, 水) 発酵させる(パンを整形する(粉, 水)) end def パンを整形する(粉, 水) 整形する(パンをこねる(粉, 水)) end def パンをこねる(粉, 水) こねる(粉, 水) end main 上のプログラムは次のように書いても同じように処理されますが、工程の全体像がつかみやすいのはどちらでしょうか？ def main 生地 = パンをこねる(粉, 水) 整形された生地 = パンを整形する(生地) 発酵した生地 = パ
はじめに 社会人になると、いろんなタスクがあちこちからやってきて、対応するのが大変になります。 新卒で入社したばかりの新人ITエンジニアさんも、この先現場に投入されるといろんなタスクがやってきて忙しくなってくると思います。 そこでこのエントリでは、僕が仕事をする上で大事にしているポイントをいろいろと書いてみます。 この先もし、忙しくて忙殺されそうになったときは、このエントリを思い出して読み直してみてください。 このエントリの対象読者 僕はRailsプログラマとして働いているので、同じようにプログラマやITエンジニアとして働いている方を想定読者とします。 ただし、タスク管理という観点においては、技術職であってもそうでなくてもあまり変わりはないかもしれません。 また、タスク管理は仕事だけでなく、プライベートでも必要になるスキルです。 （たとえば結婚式の準備とか、勉強会の企画とか） これから書く
今回のエントリでは先日、僕が勤めているソニックガーデンで話題になったプログラミング関連の小ネタを書きます。 それは何かというと、「プログラミング初心者は変数名やメソッド名を略さない方がいい」という話です。 長い変数名やメソッド名はつい略したくなります。 実際、僕も長い名前を略すときはよくあります。 ですが、略称を使うのは長年の経験から「この略称は一般的だから誤解を招くことはきっと少ないだろう」とか「前後の文脈から、変数の中身は誰が見ても明らかだろう」という想像が付いた場合だけです。 一方、プログラミング初心者の人は経験が浅いため、「一般的かどうか」とか、「誤解が発生しないかどうか」といった判断ができません。 そのため、他の人が見たときに「え、何この変数名？」と思ってしまうような略称を付けてしまう恐れがあります。 たとえば、先日のコードレビューで、初心者の人がrev_noという名前の変数を定
僕たちは本当のSQLite3を何も知らない（柔軟なデータ型と外部キー制約の罠について） - give IT a try
「えっ、SQLite3ってこんな仕様なの！？」と最近ビックリしたことを紹介します。 たとえばこんな2つのテーブルがあったとします。 CREATE TABLE blogs ( id int primary key, title varchar(32) ); CREATE TABLE comments ( id int primary key, content varchar(32), blog_id int, foreign key (blog_id) references blogs(id) ); ポイントはcommentsテーブルのblog_idにはblogs(id)への外部キー制約が貼ってあることです。 もちろん、blog_idもblogs(id)も、どちらもint型です。 で、以下のようなSQLを発行します（blog_idの値に注目）。 -- blogsにデータを追加 INSERT
外資系企業で学んだ「何が起こりますか？対象者は誰ですか？何をしなければなりませんか？」スタイルのアナウンスメール - give IT a try
はじめに 僕の前職は外資系企業でした。 その当時、アメリカ本社からときどき送られてきた社内アナウンスメールのフォーマットがなかなか良かったので、今でもときどき使っています。 特に、このフォーマットは何かをお知らせするだけでなく、社員に何かしらのアクションをお願いするときに有用です。 というわけで、このエントリではこのメールフォーマット（記述スタイル）を紹介します。 「何が起こりますか？対象者は誰ですか？何をしなければなりませんか？」スタイルのアナウンスメールの記述例 どんなフォーマットなのかというと、「何が起こりますか？対象者は誰ですか？何をしなければなりませんか？」を見出しに書いて、本文を埋めていくフォーマットです。 たとえばこんな感じです。 社員各位 ○○○○○の計画メンテナンスについてお知らせします。 以下の内容を確認してください。 何が起こりますか？ 2020年1月11日（土）15
昨今の「未経験からエンジニア就職！」みたいなトレンドに対して業界歴20年の僕が考えていること - give IT a try
このブログ記事は動画バージョンがあります。動画で見たい方はこちらをどうぞ↓ www.youtube.com ちょっと前から「もやもや〜」と考えてることなんですが。 なんかここ数年、急にプログラマ（エンジニアと言われることが多いけど）の仕事が脚光を浴び始めた気がします。 「3K（笑）」から「お給料が良くて、自由に働ける、イケてる職業」に！？ 僕がこの仕事を始めた頃（20年前）とか、ソニックガーデンに入社した頃（10年前）はまだ「プログラマ？おたくっぽい」「あー、3Kでしょ？きつい、帰れない、給料安いw」みたいな扱いだった気がします。少なくとも日本においては。 ところが、この5〜6年で急に「お給料が良くて、自由に働ける、イケてる職業」みたいなイメージに変わってきたんですよね。 それ自体はとてもいいことだと思うんですよ。自分の仕事が「3K（笑）」と馬鹿にされるより、「お給料がいい！自由！イケてる
書き手の意図やコードの背景を残す方法のあれこれ −きれいなコードの次に意識すべきこと− - give IT a try
はじめに 先日、こんなエントリを書きました。 blog.jnito.com 上の記事の中で、僕は「きれいなコードだけではすんなりコードが理解できないこともある」というような話を書きました。 もちろん、ある程度の規模になってくるといくらがんばっても「すんなり」では済まない場合も増えてくるけど、それでも最初に挙げた特徴を兼ね備えたコードとそうでないコードでは、開発効率に雲泥の差が出てくる。 僕が考える「良いコード」 - give IT a try きれいなコードを書くことはいつでも大事ですが、きれいなコード「だけ」では大きなコードを理解するのは難しいです。 そこできれいなコードを書くことに加えて、僕が意識しているコードを理解しやすくする工夫について書いてみようと思います。 ただし、ここで書く内容はあくまで僕が普段心がけていることです。 現場の文化やコードの規模や歴史、開発チームのスキルや人数、
【プログラミング初心者向け】クラスメソッドとインスタンスメソッドはどう使い分けるべき？ - give IT a try
はじめに ruby-jpのSlackで以下のような質問が投稿されていました。 クラスメソッドとインスタンスメソッドの具体的な違いがわかりません。 現状「クラスメソッドはクラスから実行でき全体に関する処理を書くときによく使うもの。インスタンスメソッドはインスタンスから実行でき、個別具体的な処理を書くときに使うもの。」という理解をしています。そして実装の際に「これはクラスメソッドとインスタンスメソッドどちらで書くべきなのか」悩むケースが多いです。 上記を踏まえて質問です。 クラスメソッドとインスタンスメソッドの具体的な違いを皆さんはどのように定義しているか どこからがクラスメソッドでどこからがインスタンスメソッドなのかの境目はどのあたりにあるか をお伺いしたいです！ クラスメソッドとインスタンスメソッドの使い分けは僕がメンターをやっているフィヨルドブートキャンプでもよく見かける質問です。 そこ
これは何？ これは僕がメンターをやっているフィヨルドブートキャンプで受講生向けに書いた記事です。 ただ、内容の8割ぐらいは未経験からプログラマを目指している初心者のみなさんにも役立つと思うので、そのまま公開することにしました。 想定読者は「フィヨルドブートキャンプの受講生」なので、フィヨルドブートキャンプの関係者以外の人が読むと「？？？」となる部分があるかもしれませんが、その点は悪しからず🙏 それでは以下が本編です。 はじめに みなさんはフィヨルドブートキャンプに入ってプログラミングの「勉強」をします。また、大半の受講生のみなさんは学校で「勉強」してきたと思います。どちらも「勉強」ですが、実は学校の勉強とプログラミングの勉強は異なる点が多いです。その違いを意識せずに、学校の勉強と同じ感覚でプログラミングの勉強をやると、非効率な勉強をしてしまう恐れがあります。 この記事ではプログラミングの
はじめに この春からITエンジニアになったみなさん、どうもおめでとうございます。 これからたくさん勉強して、立派なエンジニアを目指していきましょう！ ・・・と言っても、最初はわからないことだらけだと思います。 一人では解決できない壁にぶち当たったときは、他の人を頼って質問した方が学習効率が良いです。 とはいえ、質問するときは上手に質問しないと、自分も答える人も無駄に時間を食ってしまいます。 というわけで、今回のエントリでは「上手な質問」について書いてみたいと思います。 なお、ここで想定している質問は、社内掲示板のようなオンラインでの非同期な技術系Q＆Aを想定しています。 ですが、基本的な考え方は対面で質問する場合も変わらないと思います。 まずはネットで質問のセオリーを学ぼう 上手な質問のしかたについては、すでにネット上に優れた資料があります。 これらの資料に目を通してもらえれば、僕が言いた
はじめに 弊社ソニックガーデンの中でも「この本、面白そう」と少し話題になった「ソフトウェアテスト技法練習帳」を買って読んでみました。 ソフトウェアテスト技法練習帳 ~知識を経験に変える40問~ 作者:梅津 正洋,竹内 亜未,伊藤 由貴,浦山 さつき,佐々木 千絵美,高橋 理,武田 春恵,根本 紀之,藤沢 耕助,真鍋 俊之,山岡 悠,吉田 直史出版社/メーカー: 技術評論社発売日: 2020/01/07メディア: 単行本（ソフトカバー） このエントリでは本書を読んだ感想をざっくりまとめておきます。 本書の概要と目次 最初に、本書の概要と目次を技術評論社の書籍ページから引用します。 この本の概要 新人や経験の浅いテストエンジニアにとって，座学で学んだ「ソフトウェアテスト技法」を実務に活かそうにも，どのように適用したらよいかわからないというのが悩みです。そこで，本書では実践的なシチュエーションを
はじめに この記事はフィヨルドブートキャンプの 「ちくしょう、勉強だ。」 キャンペーンの一環として書かれたインタビュー記事です。 新型コロナウィルスの感染拡大により家で過ごすことが増えていると思います。フィヨルドブートキャンプでは、 「ちくしょう、勉強だ。」 キャンペーンの一環として、プログラマーのリモートワークはどうなっているのか、フィヨルドブートキャンプにゆかりのあるメンター、卒業生、プロのエンジニアの方々にリモートワークの状況や環境、コツなどをインタビューしていきたいと思います。 第1回はkomagataさんでした。 fjord.jp 本エントリは第2回の記事（前編）になります。 Q1. お名前・お仕事・フィヨルドブートキャンプとの関係を教えてください。 伊藤淳一（@jnchito）です。株式会社ソニックガーデンでプログラマをやってます。 2020年2月からフィヨルドブートキャンプで
【Ruby版】xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - give IT a try
はじめに テストダブル（Test Double）について、わかりやすく解説した技術記事はないかな〜と探していたところ、こちらのブログ記事を見つけました。 goyoki.hatenablog.com とても詳しく解説されていたので、まさに打ってつけだったのですが、ふだん僕はRubyを使っているのでサンプルコードをRubyにしてみたいな〜と思いました。 そこで今回のエントリでは、原著者の id:goyoki さんの許諾をいただいた上で、上記のブログ記事の説明文を維持したまま、サンプルコードだけをRubyに書き直してみました。（goyokiさん、どうもありがとうございます！） ただし、Ruby版のコードにあわせて説明文を改変した箇所もいくつかあります。 それでは以下がRuby版の「xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の
はじめに 僕は折に触れて「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が有効なと
プログラマが小学生男子の「なりたい職業」の1位になったそうです。 【ベネッセ調査】小学生がなりたい職業ランキング「ユーチューバー」は男子2位、女子4位にhttps://t.co/qbIZu9oxwg 1位にはそれぞれ「ゲームクリエイター/プログラマー」と「芸能人」がランクイン。自宅で過ごす時間が増えたことで、より認識されたとも考えられる。 pic.twitter.com/cbWFpnnkZy— ライブドアニュース (@livedoornews) January 6, 2021 まあ、「プログラマとゲームクリエイターを一緒にしていいのか」とか、「女子は全然ランクインしてないじゃないか」とか、「プログラマといっても幅が広いぞ？どの分野のプログラマなんだそれは」とか、その他あれこれツッコミを入れたくなる要素はあるかもしれませんが、個人的には「そうかあ、やっとここまで来たかあ」という嬉しい思いです
Wi-Fiルーターを壁掛けにして自宅の電波問題を改善した話（とスパゲッティなケーブルたちを整理した話） - give IT a try
はじめに 最近Wi-FiルーターをNEC Aterm WX5400HPに買い換えました。 ルーターを買い換えたのはIPv6（正確にはIPv4 over IPv6）でインターネットができるようにするためです。 「IPv6にしたらネットが速くなるはずー😊」と思ったんですが、それ以前にルーターを買い換えてから妻や子どもたちから「ネットがよく切れる💢」「LINEがしょっちゅう送信エラーになる😡」と不満の声が上がりました（あらら）。 原因はよくわからないのですが、部屋の少し奥まった場所にWi-Fiルーターを置いてたので、「もしかして？」と思って試しに部屋の外にWi-Fiルーターを置いてみたところ、ネットの調子が良くなりました。 イメージ的にはこんな感じです。 以前使ってたASUSのWi-Fiルーター（RT-AC68U）だと部屋の中に置いてても問題なかったんですけどね。 ちなみにWi-Fiルータ
プログラミング初心者は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
技術書にありがちな「IT技術は変化するけど、紙の本は更新できない問題」について僕なりの創意工夫を話してきました #DevReljp - give IT a try
先日のブログでもお伝えしたとおり、「DevRel Meetup in Tokyo #78 〜商業技術書出版を学ぼう〜」という勉強会で「出版したら終わり、にしない技術書執筆」という発表をしてきました。 devrel.connpass.com 当日使ったスライドはこちらです。 どんなことをしゃべったの？ 発表の概要はこんな感じです。 内容を随時更新できない紙の本と変化の速いIT技術はどうしても相性が悪い 相性の悪さは受け入れた上で、筆者が積極的に読者をサポートする 変化の速い技術は紙の本ではなく、電子書籍のみとするのも一手 拙著「プロを目指す人のためのRuby入門」の話題を中心に話しつつ、僕がなぜRailsの本ではなくRubyの本を書いたのかとか、電子書籍オンリーで販売している「Everyday Rails - RSpecによるRailsテスト入門」と紙の本の棲み分けについてどう考えているのか
みんなが安心して参加できる勉強会・懇親会のために主催者ができること（自由に再利用 or 改変可能なスライド付き） - give IT a try
はじめに 先日、TwitterでIT勉強会や懇親会に関するこちらのツイートを拝見しました。 ↓勉強会に参加したい ・レベルについていけないかも🤯 ・違う目的で参加している人居たら嫌だな(そもそも出会い目的じゃ無いし) ・内輪感あり過ぎてて溶け込めない雰囲気じゃないかな🤔 ・懇親会はコミュ力最大限に使うし目的違うのでいらない ↓不安の結果 やっぱり自宅で勉強しよ😇 ※繰り返し— Shoko Sato 🐶 (@satoshoco) January 11, 2020 勉強会数えきれないくらい行ってるけど人見知りなので未だに懇親会苦手感ある(とっても楽しいのだけど) 懇親会でTokyoGirls.rbのぼっち対策が行われた会を数件見ていて、この活動広まるといいなあ…と思ってる。 https://t.co/40b4y52I3I— makicamel (@makicamel) January
【Ruby初心者向け】伊藤さんってなんでそんなにRubyについて物知りなんですか？への回答 - give IT a try
はじめに 僕はフィヨルドブートキャンプでメンターをやっています。 その一環として生徒さんが書いたRubyのコードをレビューすることもよくあります。 そんなとき「そこはこんなメソッドが使えますよ」「こう書いた方がシンプルですよ」みたいなコメントを入れると、「なんでそんなにたくさんメソッドを知ってるんですか？」「どうしたら豊富な知識を身につけられるんですか？」という返事が返ってくることがあります。 このエントリではその質問に対する回答をあれこれ書いてみようと思います。 【もくじ】 はじめに 前提として 仕事で毎日コードを書いてるから（コードを書いてる時間が長いから） とことんリファクタリングする リファクタリングに欠かせない、テストコードとgit コードレビューしてもらう / コードレビューする モブプロやペアプロをする 人に教える コラム：自分で自分好みの勉強会を主催してみる 情報をインプッ
【書評】入門書は卒業したあなたに！"Polished Ruby Programming"を読みました - give IT a try
はじめに 最近発売されたRubyの洋書「Polished Ruby Programming」を読みました。 このエントリでは本書を読んだ感想を簡単にまとめてみます。 本書の感想 本書の著者はRubyコミッタとして有名なJeremy Evansさんです。 前書きにも明記されていますが、本書はRubyの中級者から上級者をターゲットにした本です。日本ではどうしてもRubyの本は初心者向けの本が多くなりますが（何を隠そう、僕もそういう本の著者の一人😅）、こういう「骨のある技術書」が出てくるのは非常に貴重だな、というのが第一印象です。 表面的なテクニックをなぞるのではなく、プログラムをどう設計すべきか、その設計にどういった良し悪しがあるか、といった点についても深く議論されています。そのため、サンプルコードだけでなく、英文もそれなりに書かれているのですが、使われている英語は比較的平易で、辞書無しでぱ
予備校で習った「現代文の読解テクニック」を使って、Web記事から「筆者の主張」を抽出してみた - give IT a try
はじめに 元の記事は削除されてしまったのですが、昨日Qiitaで「Webエンジニア業界に感じた違和感」という記事を読みました。 内容の方は「まあ、言わんとすることはわからなくはない」という感想だったのですが、それ以上に「なんか読みにくい文章だな」「話が右へ左へ大きくブレていて（＝褒めたりdisったりを何度も繰り返していて）、結局何が言いたいのかよくわからないな」という印象を強く受けました。 そこで、本エントリでは昔僕が予備校で習った「現代文の読解テクニック」を使って、「筆者が主張したい内容」を抽出してみることにします。 予備校で習った「現代文の読解テクニック」とは？ 僕が予備校で習った「現代文の読解テクニック」は、ざっくりいうとこんなテクニックです。 「だが」「しかし」など、逆接の接続詞が登場したら、そこから後ろが筆者の主張なので、「だが」「しかし」の前に書いてある内容は無視して良い。 「
お客さ～～～ん。いかがですか～～～ 気持ちいいですか～～～ マッサージさせて頂いております この頃、また、たま～～～に流し台の前に居ると、飛びション？うれションしてくれることがあります。で、今朝も流し台の前で片付けていると来たしぐれちゃんが、恐らくお母ちゃんにカクカクのチャンスを伺いに来たか、ションしたい！？。。。と察したお母ちゃんは、とりあえずうさ神さまをなでなで。。。(*´ω｀*) から～マッサージ～～と、背中やら目尻の先、口の脇など全身のツボマッサージをしていると、どんどん🐰の目がとろ～～～んとしてくるのが分かり、こっちもモフモフな毛を触っているので眠くなってくるし。。。もう結構🐰！ということなら走って逃げてくれるのですが、うさ神さま、全く動く気配がなさそうで、２０分以上はマッサージさせて頂きました(;´･ω･) うさぎマッサージ師になれるかなぁ？ 買い物から帰ってきたお母ちゃん
はじめに 実はお盆から9月上旬にかけて、我が家は新型コロナでてんやわんやしておりました。 我が家は僕たち夫婦と長男、長女の4人家族なのですが、妻以外新型コロナにかかってしまいました。 つまり、僕も新型コロナにかかって寝込んでおりました。 いわゆる「第7波」は強烈で、あの人もこの人もコロナにかかってた印象です。 このブログを書いている時点ではピークが過ぎて話題性も落ちてきたように思いますが、備忘録的にブログを書き残しておきます。 かなり長いので先にもくじを載せておきます。 【もくじ】 はじめに 第一部・たぶん部活で感染した息子 息子の陽性が確定したあとにやったこと 意外と家族内感染してない！？ 感染力が落ちてもしばらく陽性が続くらしい そして新しい感染者なしでなんとか自主療養期間を乗り切った！！（このときは） 第二部・娘の発症、そしてさらに…… 今度も絶対生き延びるぞ〜！！・・・あれれ？？
大阪Ruby会議03でHotwireを使ったモーダルUIを15分で作ってみました＆基調講演裏話 #osrb03 - give IT a try
はじめに 2023年9月9日に開催された大阪Ruby会議03で、基調講演（キーノート）を担当させてもらいました。 regional.rubykaigi.org 当日使った資料はこちらです。 発表のタイトルは"Enjoy Ruby programming, Enjoy Ruby community!"でした。 今回の基調講演ではちょっと攻めた取り組みとして、「Hotwireを使ったモーダルUIを15分で作る」というテーマでライブコーディングもしてみました。 www.youtube.com ライブコーディングには思わぬトラブル付きものですが、今回は何とかノートラブルで実装できました！ 時間も15分以内（たぶん12〜13分ぐらい？）に収まりました〜😄 基調講演をするにあたって意識したこと 今回、基調講演を担当するにあたって「IT系カンファレンスの基調講演はどういうものであるべきか」を自分なりに
はじめに ちょっと前に「「このバイブルに育てられた」駆け出しエンジニアだった頃に読み込んだ、学びの一冊をご紹介」というweb記事が話題になっていました。 type.jp たぶん、長年ITエンジニアをやっている人なら1冊か2冊はそういった「バイブル」があると思います。 そこでフィヨルドブートキャンプのメンターに「あなたが「このバイブルに育てられた」と思う一冊は何ですか？」という質問をしてみました。 なお、回答者はメンターだけでなく、アドバイザー（メンターではないが、受講生の学習状況を確認できる企業関係者）や卒業生も含まれています。 というわけで、以下がその回答です！ 【もくじ】 はじめに メンターの伊藤淳一さん＝「情熱プログラマー」 メンターのinoueさん＝「リーダブルコード」か「アジャイルサムライ」 メンターのべーたさん＝「猫でもわかるC#プログラミング」と「ノンデザイナーズ・デザインブ
チェリー本発売3周年記念!? 技術書の商業出版と同人誌、どっちが儲かるの問題について - give IT a try
はじめに 3年前の今日、2017年11月25日に僕が執筆したRubyの入門書「プロを目指す人のためのRuby入門」（通称チェリー本）が発売されました。 つまり、今日でチェリー本が発売されて3年になります！（拍手〜！👏👏👏） プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで Software Design plus 作者:伊藤 淳一発売日: 2017/11/25メディア: Kindle版 ありがたいことにチェリー本は自分でも予想できなかったぐらい、たくさんの人に読んでもらえました。 すでに増刷も4回行われています。購入してくださったみなさん、本当にありがとうございます！😆 概して技術書は賞味期限が短く、3年も経つと内容が古くなって使い物にならなくなることもよくあります。 ですが、チェリー本はRubyの本質的な部分にフォーカスしているので、大半の内容は2
by John H. Gámez インターネットを長く使っている人の中には、「キャッチーなタイトルやサムネイルに引かれて動画をクリックしたら、釣り動画だった……」という経験がある人も多いはず。そんな釣り動画として有名な、リック・アストリーのMV「Never Gonna Give You Up」がYouTubeで10億再生を突破したと報じられています。 Thanks to the Rickroll, ‘Never Gonna Give You Up’ hits 1 billion YouTube plays - The Verge https://www.theverge.com/2021/7/31/22603429/rick-astley-never-gonna-give-you-up-1-billion-youtube イギリスの歌手であるリック・アストリーが1987年にリリースしたデビ
Tristan Redman on Twitter: "At #Tokyo2020 I cannot buy food unless it’s with a Visa card. Not even cash. Give me strength. https://t.co/KXvk2wlQyf"
At #Tokyo2020 I cannot buy food unless it’s with a Visa card. Not even cash. Give me strength. https://t.co/KXvk2wlQyf
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
長年の悩みだったギターアンプのノイズが「マイ電柱」で直った件 - give IT a try
雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try
ITエンジニアがお金に関する本を10冊近く一気に読みあさってみた - give IT a try
毎日3〜4杯飲んでたコーヒーを1日1杯に減らした話☕️ - give IT a try
理想のプロバイダを探し回った結果、OCNのIPv4に行き着いた話 - give IT a try
僕が考える「良いコード」 - give IT a try
技術書、紙の本で読むか、電子書籍で読むか？ - give IT a try
「ITエンジニア、包丁研ぎにハマる」の巻 - give IT a try
マトリョーシカ人形のようなメソッド設計を避ける - give IT a try
【新人ITエンジニア向け】僕が仕事をする上で大事にしているポイントあれこれ - give IT a try
プログラミング初心者は変数名やメソッド名を略さない方がいいよ、という話 - give IT a try
学校の勉強とプログラミングの勉強は何が違うか（そして技術書をどう読むべきか） - give IT a try
【初心者ITエンジニア向け】上手な質問は「相手にエスパーさせない質問」です - give IT a try
【書評】「ソフトウェアテスト技法練習帳」を読んで、体系的なテスト技法の知識を身につけよう - give IT a try
教えてリモートワーク・伊藤淳一さんの場合 〜仕事環境編〜 - give IT a try
僕がRSpecでsubjectを使わない理由 - give IT a try
プログラマがなりたい職業第1位になった話とか、昨今のプログラミングスクール問題とか - give IT a try
うさぎさんと飼い主の give & take な生活 - 黒うさぎのつぶやき
家族のうち4人中3人が新型コロナにかかった話（備忘録を兼ねて） - give IT a try
フィヨルドブートキャンプのメンター陣が語る「このバイブルに育てられた」学びの一冊 - give IT a try
世界一有名な釣り動画の「Never Gonna Give You Up」のMVが10億再生を突破
kidsprogramming-kenkyusha.com
news.yahoo.co.jp
news.yahoo.co.jp
jp.mercari.com
www.mofa.go.jp
togetter.com