give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

システムスペックに関するページを新たに追加!Everyday Railsをアップデートしました

お知らせ

僕が翻訳者の1人として参加している電子書籍「Everyday Rails - RSpecによるRailsテスト入門」の小規模なアップデートを実施しました。

購入者の方にはおそらく通知メールが飛んでいるはずです。
アップデート版をダウンロードする場合はLeanpubにログインして、Libraryページにアクセスしてください。

アップデート版のダウンロードはもちろん無料です!

Everyday Rails - RSpecによるRailsテスト入門 | Leanpub
f:id:JunichiIto:20180219082935p:plain

具体的なアップデート内容

今回のアップデートでは原著の2018年8月22日版に追従しました。
2018年8月22日版では付録記事として、「システムスペックに移行する」が新たに追加されています。

システムスペックはRails 5.1以上 + RSpec 3.7以上の組み合わせで実行可能な、エンドツーエンド(E2E)テストの新機能です。
記事の中では既存のフィーチャスペックをシステムスペックに移行する手順が説明されています。

その他にも細かい誤字の修正等が実施されました。

このアップデートに関して、原著者のAaronさんがご自身のブログでアナウンスされているので、その翻訳も以下に掲載しておきます。

(翻訳)Everyday Rails・2018年8月版アップデートのお知らせ

原文: Everyday Rails Testing with RSpec book updates for August 2018 | Everyday Rails

Everyday Rails - RSpecによるRailsテスト入門」の新バージョンがLeanpubでダウンロードできるようになりました。もともと現行版に関してはこれ以上のアップデートはしない予定だったのですが、DeviseとGeocoder gemの変更によりサンプルコードのテストが動かなくなっていました。私はこの問題を修正し、それから読者のみなさんから報告されたその他の問題点もいくつか修正しました。

さらにみなさんへのボーナスもあります。今回のアップデートではシステムスペックへの移行ガイドも付録として追加しました。これは今年の初めにこのブログで公開したもの(英語版Everyday Railsブログ内の記事のこと。日本語訳はこちら)がベースとなっていますが、RSpec 3.8にあわせるため内容を少しアップデートしています。システムスペックは私が現行バージョンをリリースした数日後に追加されたRSpecの新機能です。第6章全体を書き換えるのは大仕事になるため、現行版のスコープに含めることは見送りました。しかし、今回追加したこの付録記事を読めば、ブラウザの統合テストを実行するために用意された新しい標準アプローチを習得できるはずです。

最後にみなさんにお願いがあります。私は最初の版をリリースした6年以上前から、本書の無料アップデートを提供し続けてきました。もしみなさんがこのアップデートを歓迎してくれているのであれば、ぜひご友人や同僚に本書を紹介してやってください。本書に関するツイート、トゥート(訳注: Mastodonにおけるツイートのこと)やシェアも大歓迎です。

みなさんよろしくお願いします!

(翻訳ここまで)

まとめ

というわけで、このエントリでは2018年9月6日に実施した「Everyday Rails - RSpecによるRailsテスト入門」のアップデート内容について紹介しました。

すでに本書を持っている方は最新版をダウンロードして、新しく追加されたシステムスペックの付録記事をぜひチェックしてください!

Everyday Rails - RSpecによるRailsテスト入門 | Leanpub
f:id:JunichiIto:20180219082935p:plain

「Everyday Railsって何?」「いったいどんな本?」と思われている方は以下のブログ記事をご覧ください😉

技術書、最初から完全に理解するか、頭の中にインデックスを作るか? 〜 #チェリー本 が後半から難しくなる問題を考える

はじめに

2017年11月に発売し、多くの方に読んでいただいている拙著「プロを目指す人のためのRuby入門」(通称・チェリー本)ですが、「わかりやすい!」という感想を多くいただく一方で、ときどきこういった感想を見かけることもあります。

いや、別にこういった感想を持たれるのは全然構わないんですよ!責めるつもりはありません。

なんせ、本を書いた僕自身も「この本、7章(クラスの作成を理解する)あたりから急に難しくなるよな〜😅」と思ってるぐらいですから。
もし「理解できなくて情けない、恥ずかしい」とか、「これを全部理解しないとRubyプログラマになれないのか」といったふうに、深刻に考えている読者さんがいるとしたら、そんなふうに考える必要はまったくありません。

というわけで、このエントリでは後半からどんどん難しくなってくる「プロを目指す人のためのRuby入門」をどう読み進めればいいのかという問題について、それを解消するいくつかの読書スタイルを提案してみます。

she's in my head

「全部理解しようとはせず、頭の中にインデックスを作る」という読書スタイル

これまでのプログラミング経験や実務経験は人によって異なります。
経験が豊富な人はある程度難しい内容が出てきても、これまでの経験と照らし合わせて「ああ、なるほど、この機能はこういう意味か。それならあんな場面で使えそうだ」とイメージが湧くかもしれません。
ですが、プログラミングを始めて間もない人はなかなかそうはいかないと思います。

「プロを目指す人のためのRuby入門」に限らず、技術書を買って読むときは「せっかくお金を出して買ったんだから、ちゃんと全部理解しないと!」と考える人も多いと思います。
もちろん、ちゃんと全部理解できるに越したことはないですし、その方が理想的ですが、必ずしも本の内容を全て完全に理解することだけが技術書の読み方ではありません。

インデックスを作る = 必要になったときに思い出せるようにする

もし、どうしても理解できない難しい内容が出てきたら、とりあえず「頭の中にインデックス(索引)だけ作って、どんどん読み進める」というスタイルにチェンジしましょう。
「頭の中にインデックスを作る」というのはすなわち、「実際必要になったときにあとで思い出せるようにする」ということです。

たとえば、他の人が書いたコードを読んでいるときに"yield"というキーワードを見かけたら、「yield?あ、そういえばチェリー本になんか書いてあったな」と思い出して、本を読み返せるようになっていればそれでOKです。

本を読むだけではピンと来ない内容も、実際にそれを必要とする場面が出てきたら自分の経験と本の説明がきれいにリンクし、自分の知識としてしっかり頭の中に刻み込まれるはずです。

自分の手と頭を動かす機会がやってくるまで、理解を先送りする

実際、僕自身も新しい技術書を読むときは、そんなふうに読んでいます。
最初から最後まで完全に理解しようとすると時間もかかるし、読み進めるのも非常にしんどくなります。
なので、「内容が難しくなってきたら最低限見出しの項目ぐらいは頭の中に入れておく。あとは必要になったときにもう一度本を引っ張り出して読み直す!」と考えながら読むようにしています。
この方が早く読み終わりますし、気分的にもすごく楽です。

実際問題、技術というのは本を読むだけでは身に付かなくて、「自分の手と頭を動かす」という行為を経ないと完全に自分のスキルとして定着しません。

だから、自分の手と頭を動かす機会がやってくるまで、本の内容の理解を先送りしてしまうというのもあながち悪い手ではないと僕は考えています。

ある意味これは「JIT(Just-in-time)型の読書スタイル」と呼べるかもしれません。
(そういえば、RubyにもJITが導入されますね!って、あまり関係ないけど・・・)

「ある程度経験値が上がってきたときにもう一度読み直す」という読書スタイル

「必要になったときに読み直す」というのもひとつの手ですが、もうひとつの考え方として「ある程度経験値が上がってきたときにもう一度読み直す」というスタイルもアリだと思います。

つまり、

「プロを目指す人のためのRuby入門」をざっくり最後まで読む
 ↓
Railsチュートリアルをやったり、自分でWebサービスを作ったり、仕事でRubyのコードを書いたりする(=経験値を上げる)
 ↓
あらためて「プロを目指す人のためのRuby入門」を読み直してみる

という読書スタイルです。

経験値を上げてから読み直すと、新しい発見が増える

経験値を上げてから本を読み直せば、最初に読んだときとは異なる、新しい発見がたくさん見つかると思います。
たとえば、「あ、こんな機能があるなら、あのコードはこう書けば良かった」とか、「前読んだときはサッパリ意味がわからなかったけど、仕事で一度使ったせいか、今読んだらよくわかるぞ!」といった感じです。

1周目で無理に全部理解しようとしなくていいんです。
2周目、3周目、と繰り返すたびにだんだんと理解できる範囲を増やしていけば、最終的に大半の内容を理解できるようになります。

これは言い換えるなら「終わりよければすべて良し・結果オーライ」パターンの読書スタイルですね。

知識の定着はプラモデルの色塗りと同じ?

話はちょっと脱線しますが、その昔、僕がプラモデル作りにハマっていた頃、「色塗りを上手くするコツ」として、こんな話を読んだことがあります。

色を塗るときは厚塗りして一度で塗ろうとせず、薄く塗っては乾かし、薄く塗っては乾かし、を繰り返した方がきれいに塗れます。

458_DSC_0865

技術書を読むときもこれと同じなんじゃないでしょうか?
つまり、1周目で完全に理解しようとせず、1周しては自分でコードを書き、もう1周しては自分でコードを書き・・・を繰り返した方が、きれいに知識が定着するんじゃないかと僕は思ったりします。

「質問したり相談したりできる環境を確保した上で読む」という読書スタイル

「いや、そんなにのんびりやってられないんだ!自分は1日でも早くスキルを伸ばしたいんだよ!」という人も、もしかしたらいるかもしれません。
そんな人は独学でなんとかしようとせずに、誰かに質問したり相談したりできる環境を確保することをオススメします。

具体的には、こんな方法が考えられるでしょうか。

  • 近くで「プロを目指す人のためのRuby入門」の読書会(勉強会)をやっていないか探してみる
  • プログラミングスクールに通って、講師やメンターに質問しまくる
  • (すでにプログラマとして働いている人なら)職場の同僚や先輩にどんどん質問する

「ここに書いてあるこの内容がよくわからない」とか、「この機能の使い道はいったい何なのか」といった質問をどんどんぶつけて疑問を解消していけば、かなり速いペースで内容を理解していけるんじゃないかと思います。

実際に行われている勉強会やイベントの例

ネットを探すと、「プロを目指す人のためのRuby入門」の読書会をやっているRubyコミュニティがいくつか見つかります。(どうもありがとうございます!)

社内で読書会をやっている会社もあるようです。(こちらもありがとうございます!)

そしてなんと、11月には筆者本人(はい、僕です)と合宿できるイベントもあったりします!
ここにくれば、筆者に質問し放題です(笑)。

こういったイベントやチャンスをどんどん活用していきましょう。
独学でがんばるのもいいですが、僕自身の経験上、プログラミングの習得は「自分よりもできる人」が近くにいた方が圧倒的に効率が良いです。

まとめ

というわけで、このエントリでは後半からどんどん難しくなってくる「プロを目指す人のためのRuby入門」をどう読み進めればいいのかという問題について、それを解消するいくつかの読書スタイルを提案してみました。

繰り返しになりますが、筆者自身から見ても、7章以降は急に難易度が上がってきます。
とはいえ、本の内容の全部が全部、頻繁に遭遇する機能や構文というわけではありません。
特に、各章の例題のあとに出てくる高度なトピックは滅多に使わないものも多いです。
(たとえば、refinementsやprependなどは、全く使わないわけじゃないけど、日常的に多用する機能ではありません)

本書はタイトルにもあるとおり「プロを目指す人のため」の本なので、開発の現場で必要になりそうなトピックをひととおりカバーするようにしています。
ですが、その中にも「自由に使いこなせるようになるべき知識」と「とりあえず、名前だけでも知っておけばOKという知識」の2種類があります。

後者のような知識は、僕自身としても「頭の中にインデックスを作っておいて、必要なときに読み返して理解すれば大丈夫」というスタンスです。
なので、読者のみなさん(特にプログラミング初心者の方)は「難しい、ようわからん・・・」とあまり落ち込まないようにしてください。

途中でやめるのはダメ!ざっくりでもいいから最後まで読もう

逆に一番ダメなのは、全部理解しようとして途中で力尽きてしまうケースです。
途中でやめたら、頭の中にインデックスを構築することすらできません。

ざっくりでもいいので、必ず最後まで読みましょう!
そして頭の中にインデックスを作りましょう!

このエントリのアドバイスを参考にして、みなさんが「プロを目指す人のためのRuby入門」を最後まで読み進めてくれることを願っています。
がんばってくださいね〜😘

ITエンジニアが知っておきたい、軽減税率制度(のイヤなところ)

はじめに

僕の妻は兵庫県西脇市で「Coupé Baguette(クープ バゲット)」という小さなパン屋さんを営んでいます。
その関係で、先日国税庁から消費税の軽減税率制度に関するお知らせが届きました。

f:id:JunichiIto:20180818112200j:plain

「軽減税率制度?あ〜、なんかそんな話もあったような」と思いながら資料を読んでみたところ、「げげっ、軽減税率制度ってこんな面倒な仕組みになってたの!?」とビックリしました。

というわけで、このエントリでは軽減税率制度の概要(と、ITエンジニアが困りそうなポイント)をざっくりとまとめてみます。

おことわり

僕自身は税理士のような税金の専門家ではないため、100%正しく理解しているとは限りません。
エントリ内に怪しい内容があればコメント欄等でご指摘いただけると助かります。

国税庁の資料から抜粋した、軽減税率制度の主なポイント

我が家にも届いた「よくわかる消費税軽減税率制度(平成30年7月)」(PDF/4,879KB)という資料から、個人的に気になった軽減税率制度の主なポイントを抜粋してみます。

一部の品目だけ消費税が8%に据え置かれる

2019年10月1日から消費税が10%に変わりますが、一部の品目だけ8%のまま据え置かれます。
これが軽減税率制度です。

f:id:JunichiIto:20180818101507p:plain

上の画像にもあるとおり、8%のまま据え置かれる品目は以下の2品目です。

  • 酒類・外食を除く飲食料品
  • 週2回以上発行される新聞(定期購読契約に基づくもの)
請求書やレシートの出力フォーマットを変更する必要がある

品目によって税率が変わるため、請求書やレシートでは8%の場合と10%の場合で別々に金額を出力する必要があります。

f:id:JunichiIto:20180818101524p:plain

テイクアウトとイートインで価格表示を変える必要がある(統一するのも可)

飲食料品は8%ですが、外食する場合は10%になります。
そのため、イートインスペースがある小売店などでは、「テイクアウトなら162円(=8%)、イートインなら165円(=10%)」というように、同じ商品でも価格表示を変える必要があります。

f:id:JunichiIto:20180818105619p:plain

ただし、上の図の一番右にあるように、同一の価格表示にするのも良いそうです。

その他、ややこしいルールがいっぱい

このほかにも軽減税率制度にはいろいろと複雑なルールが定められています。
詳しくは国税庁の公式ページにある各種資料をご覧ください。

軽減税率制度とは(リーフレット等)|国税庁

軽減税率制度、こんなところが困る

我々ITエンジニアにとっては、軽減税率制度のこんなところが困ります。

消費税率の一括変更、だけでは済まない

前述の通り、軽減税率制度では品目によって税率が変わります。

既存の情報システムでは「単純な消費税率の変更」には対応しているものが多いと思いますが、品目に応じて消費税率を変える仕組みまでは用意していないのではないでしょうか。
(さらに同じ品目でも、イートインとテイクアウトで税率が異なる場合がある!)

そのため、異なる消費税率の品目が混在するシステムにおいては、システムの改修を入れないと軽減税率制度に対応できません。

請求書やレシートの出力フォーマットを変えなければならない

請求書やレシートの表示も8%の品目と10%の品目で表示を分ける必要があります。
そのため、システムから請求書を自動生成している場合やスーパーのレジなどでは、システムの改修や機器の入れ替えが必要になりそうです。

その他もろもろ

このブログに書いた話は氷山の一角で、このほかにも軽減税率に関わるさまざまな特殊ルールがあります。
そのため、商品の仕入れや販売に関わる情報システム(いわゆる勘定系システム)ではそれに合わせて仕様変更を実施する必要が出てくると思います。

情報システムに関係しそうな考慮ポイントについては、こちらのブログによくまとまっています。

軽減税率がITに与えるインパクト - 急がば回れ、選ぶなら近道

また、国税庁が作成した「よくわかる消費税軽減税率制度(平成30年7月)」(PDF/4,879KB)という資料にも、以下のようなチェックリストが載っています。

f:id:JunichiIto:20180818113800p:plain

まとめ

というわけで、この記事ではITエンジニアにとって面倒くさそうな軽減税率制度のポイントについて、ざっくりと要点をまとめてみました。

軽減税率制度といい、サマータイム導入や新元号の公表タイミングの問題といい、何かと情報システムに負のインパクトを与える話題が妙に多いと感じる今日この頃です・・・。

と思ったら、Rubyのパパとして有名なMatzさんも同じことをつぶやいておられました。

いやあ、全く同感ですね😣

あわせて読みたい

サマータイム導入問題についても、個人的に思うところをこちらのエントリにまとめています。

おまけ

もし軽減税率制度に対応したレシート出力機能をシミュレートしたらどんなコードになるのかな〜?と思って、Rubyでサンプルプログラムを作ってみました。
が、案の定、考慮点がたくさんあってかなり大変でした・・・。

動作イメージはspecディレクトリのregister_spec.rbをご覧ください。