リーダブルコード読書メモ ～その３～
これの続きです。今回は条件文をわかりやすくどうするか、あまりネストをできるだけ浅くしようという、話です。
- 比較文の書き方
- 左側に調査対象、右側に比較対象、とするとよい
Ruby
hogeflag == true
fuga < 10
条件文
ネストは浅くする
- 特に条件分岐が増えると結構つらい。深くなりそうな場合は既存ロジックも含めて以下を検討する
- 失敗ケースは早く返す（ガード節をうまく使う）
- continueを使う
- ガード節について
- 処理の対象外とするケースを関数やループの先頭に集めてreturnやcontinue、breakで抜けるコーディングテクニック
- 特に条件分岐が増えると結構つらい。深くなりそうな場合は既存ロジックも含めて以下を検討する
if !hoge
fuga = 0
end
if !hogehoge
fuga = 0
end
上記を以下のようにするとネストがなくなり、わかりやすくなる
fuga = 0 if !hoge
fuga = 0 if !hogehoge
終わりに
比較や条件文については要件によっては複雑になるのは仕方ないですが、今回紹介したような形でできる限りわかりやすく書くことを意識したいですね。。。
パーフェクトRuby on Railsを読む～その２～
前回はこちらです。
パーフェクトRuby on Railsを読んでいき、気になったところをメモっていきます。
本自体の個人的な評価ですが、Rails入門本では飛ばされがちな細かい情報（知っていたほうが応用が利く情報）が網羅されていて、Railsでなんかアプリ作り出したくらいの人には最適と思いますし、逆にそこまで敷居も高くないと思います。
Rackについて
- APサーバとフレームワークをつなぐインタフェース。これによりRailsから見たAPサーバを自由に選択できる（unicornやpumaなどが例）
- Rackには「callというメソッドの定義」「callにenvまたはenvironmentという引数を一つ渡す」「HTTPステータスコード（数値オブジェクト）、HTTPヘッダ（ハッシュオブジェクト）、レスポンスボディ（文字列）の三つを配列でcallに渡す」という規約があり、これを満たせばとりあえずOK
複数DB対応
- Rails6.0からはRails標準として複数DB対応が可能。database.ymlにprimaryとsubという形で接続したいDBを追加する。DB名とmigration_pathをそれぞれ追加する形。あとは通常通りmigrationすればDBセットアップは可能
- モデルを複数DB接続できるようにするためにestablish_connectionを用いる。モデル生成時に--database=subをオプションで指定すると、subデータベースに接続するための基底クラスが生成され、生成されたモデルはその基底クラスを継承する。
- DBごとに読み書きの分離が可能。database.ymlのDB追加時にreplicaという形で指定すると、読み取り専用のDBを設定することができる。
- アプリケーションレベルでは、モデル単位でどのDBに接続するかを設定する必要がある。この場合はモデル単位でconnect_toを利用してロール（writable、readable）とデータベースを明示する。DBコネクションをできる限り減らすため、テーブル全体に設定する場合はApplicationRecordで設定したほうが望ましい。
- ロール名は独自で設定可能で、application.rbで設定可能。
セキュリティやEarly hintsに関する記載については飛ばしましたｗ
終わりに
とりあえず３章まで駆け足でメモって見ましたが、複数ＤＢとかは大規模システムで普通に使いそうですね。例えば基幹システム側のＤＢとＲａｉｌｓのサブシステムのＤＢで色々やりたいとかそういう要件にも簡単に対応できそうな印象でした。
hontoの電子書籍はクーポンが充実していて非常にお得です。私もよくhontoの電子書籍を使っていますのでお勧めです（この本もこちらで買いました）
パーフェクトRuby on Railsを読む
前から手を出そうと思っていたパーフェクトRuby on Railsを読んでいき、気になったところをメモっていきます。
本自体の個人的な評価ですが、Rails入門本では飛ばされがちな細かい情報（知っていたほうが応用が利く情報）が網羅されていて、Railsでなんかアプリ作り出したくらいの人には最適と思いますし、逆にそこまで敷居も高くないと思います。
割と自分が知っている範囲の内容ではありますが、一部知らなかったことがあったりするのでその辺を書いていきます。
Scope定義した場合は、必ずActiveRecord::Relationを返す find_byなど、レコード検索時に該当データがない場合nilを返すメソッドについて、Scope定義結果がnilになった場合は、該当Scopeの検索条件を除外したクエリを発行して、必ずActiveRecord::Relationを返します。nilで返したい場合はクラスメソッドで定義する必要があるので注意。
ActiveRecordeでコールバックが実行されないメソッド ActiveRecordではバリデーション前後、更新前後などでコールバックにより処理を実行できる仕組みがあるが、一部実行できないメソッドがあるので注意。具体的には以下
- decrement
- decrement_counter
- delete
- delete_all
- increment
- increment_counter
- toggle
- touch
- update_column
- update_columns
- update_all
- update_counters
ルーティングにおけるmemberとcollection memberは個別のリソースに対するアクション、collectionは全体のリソースに対するアクションの設定 （idがいるとかいらないとかくらいの理解でよくわかってなかったですが、腹落ちしました。）
rescue_fromによる例外の扱い rescue_fromで指定したアクションで例外が発生した時のふるまいを独自に設定できる。例えばログインのアクション実行時にログイン失敗した場合はその画面を表示する、などが可能。 ApplicationControllerに指定することで、アプリケーション全体で設定できる。
respond_toによる表示の制御 respond_toでformat.htmlやformat.jsonをブロックで指定できる。これにより、リクエストヘッダやURLにより、どのフォーマットで画面表示をするかを制御できる。format.htmlとformat.jsonの2種類をrespond_toで指定する場合、～～.html（htmlの場合は拡張子不要と思われるが説明のためにあえてそう表記する）の場合はhtmlで、～～.jsonでアクセスした場合はjsonで画面表示される、という形で柔軟に対応が可能となる。html、json以外にもいくつかオプションがある。
variantsによるテンプレート切り替え ApplicationControllerに「request.varient」をコールバックで設定すると、アクセスした端末により、テンプレート表示を制御できる。例えばスマートフォンとPCで異なるテンプレートを表示したい場合などに有用
終わりに
今回は1,2章について自分が分からなかったところを中心にメモって行きました。最初ということもありそこまで真新しい話題はなかったです。章を追うごとに色々出てくると思います。 それにつれてブログの長さもどんどん長くなっていくんだろうなあ。。。
hontoの電子書籍はクーポンが充実していて非常にお得です。私もよくhontoの電子書籍を使っていますのでお勧めです（この本もこちらで買いました）
リーダブルコード読書メモ ～その２～
こちらの続きです。
3章
- 誤解を生むような名前ではないか常に意識する
- filter→select,exlude（filterではちょっとあいまいすぎるので、選択する、除外する、などより明確にする）
- limit→max,min（最大値か最小値かを明確にする）
- 範囲を指定するときはfirst、last
- ～～の間、を示すときはbegin、end
- boolについて
- 「これからtrue or false」か「すでにtrue or false」かがわかるようにする。need_password、user_is_authenticated
- 接頭辞にis、has、can、shouldが一般的に付けられる
- Rubyの場合は接尾辞に「?」が言語仕様として付けられるはずなのでいらないかも
- getの罠
- getは便利な言葉で使いたくなるが、より明確な単語を選ぶ（特にJavaとかだとgetterでgetを利用したりするので若干混同するかも）
- sizeは単にサイズを返すものから、サイズを算出するものもあるのでそれは明確にする。後者はcountとかつけるといいかも
- まとめ
- いい名前は誤解されない名前である。第三者がその名前を見て読む人によって解釈が変わらないことが望ましい
- いくつか名前を考えて、色々な角度で検討する。人と相談するなどが必要
4章
見た目が美しいコードを目指す
まとめ
- コードも文章なのでレイアウト的な読みやすさが大切
- コードスタイルは個人の好みでわかれるが、同じコード内にばらばらのスタイルがあるのはわかりにくい。統一すること
5章
- コメントについて
- コメントは書き手の意図を読み手に伝えることである。
- いたずらにコメントを入れるべきでない。コメントすべきでないものもある。
- コードの処理を逐一コメントにするのはよくない
- ～～の処理をする、～～の値を返す、～～の定義をする、などはコードを見ればわかる
- 仮にコードそのものがわかりにくい場合はリファクタリングする。コメントを入れることで改善してはいけない
- 何をコメントすべきか
- 自分の考えや改善点を入れる
- 一般的には～～と書くべきだが、～～の理由により～～というコードにした、という特殊な場合の補足
- TODOコメントによるコード改善の提案
- 定数やパラメータの設定値の理由
- 全体像が分かるようなコメント
- このファイル内のコードは何をしているか、が分かるような要約コメントがあるといい
- 自分の考えや改善点を入れる
- コメントは書き手の意図を読み手に伝えることである。
- まとめ
- コメントはいたずらに入れるべきではない。優れたコード＞ひどいコード＋優れたコメントである
- コードを読んでわからないような情報を入れる
終わりに
3～5章についてザーッと読んでいきましたが、レイアウトや名前のチョイスなど、通常の文章の書き方にもあると感じました。ソースコードも文章も、他人に見やすく、わかりやすいように気を付けたいですねえ
ドラゴン桜の東大模試数学の問題を解く
なんか話題らしいので解きました。
問題文が色々とおかしくないか？という突っ込みは置いておいて、私が解いたのはこちらです
「150足しても150引いても平方数となる自然数を求めよ」
以下解答。tex書くのめんどいので画像ですみません。あと字が汚いとか、ノートが見づらいとかすみません。。。
結論から言うと求める自然数は5626,634,250の三つです。
解答の流れですが、整数a,bを使って、及び
とおきます。これについて両辺を引き算すると
となります。そして、a-b、a+bについて、掛け算して300になる整数の組から、a,bを求め、mを求める、という感じです。
ポイントは、について300になるa+bとa-bの組はたくさんあり、一つ一つ見ていくのは現実的ではないので
* a,bの偶奇
* a-bとa+bは両方正である
ことをしっかり論じて、適切なa,bを求めていくところです。
私の回答は結構回りくどかったりするので、模範解答としては以下が参考になるかと思います。
— 林 俊介@数学YouTube1.13万人 (@884_96) 2021年6月7日
先入観って怖いですね
数学ネタなんですが、先入観って怖いなあと思うようなことがあったので。。。
以下の２問をまずは見比べてください
どちらも似たような問題ですね。上は今年の京都大学文系の問題、下は「理系数学良問のプラチカ」という問題集に出ていた問題です。某大学の入試問題です。
京都大のほうの問題は、に2,3,5,7と具体的な素数をpに代入すると、3の倍数になることに気が付きます。そこで、3で割ったあまりを考えて素数にならないことを示します。
となると、下の問題もあまりで分類したくなりますよね。ところがこれあまりで分類しようとしてもうまくいきません。どうやるかというとを
と考えて因数分解すると
となり、ここから
が合成数であることを論じていきます。
ちなみにこの因数分解は数1の基本的な問題ですので、そこまで難しい話ではないです。チャートに普通に出てたりします。
似たような問題でもうまくいかないときは別の方法に切り替えるのが大事ですね。
ITエンジニアとして生き残るための対人力の高め方読書メモ
ITエンジニアといえど、ただプログラム書いてればいいだけではなく、顧客と話したり、社内のメンバーと話をしてプロダクトを作っていきます。 一方、コミュニケーションが苦手、という人がいて、あまり話したがらない人が一定数いる印象です。かくいう私も中々人と話すのが苦手です。いや、普通に話す分にはいいんですけど、こうすれば仕事がうまく回るなとかそういうのに苦手意識があります。というわけで、以下の本を読んでみました。ざーっと気になるところだけ流し読みして言った感じです。
あと、いかに色々まとめていますが、私の主観が大いに入っていること、また、気になったところを掻い摘んでいるので割愛した内容がたくさんあります。
読書メモ
社外とのコミュニケーション
相手を理解したうえで、詳細を詰めていく
- 相手のやりたいことは何かを徹底的に聞き、理解する
- アクティブリスニング
- 相手が話しやすいと思える場づくり、表情、態度
- 相手の発言を繰り返す、掘り下げるなどして相手のことを理解する姿勢を見せる
- 相手が「理解してくれた」と思えるように安心させる
- アクティブリスニング
- 思い込みはなるべく排除し、相互理解ができるまでひたすら聞く。（純粋な心でヒアリングする）
- 相手のやりたいことは何かを徹底的に聞き、理解する
プレゼンテーション
- 資料の内容が分かりやすいだけでなく、場の雰囲気や話し方など相手が気持ちよく聞けるような環境が大事
- リラックスできる（雑談を入れる、表情、態度）などの環境
- アイスブレイク（要は雑談。天気の話とかでいい。これにより相手だけでなく自分の緊張も和らぐ）
- 話し方（スピード、声の大きさ、強弱、間）
- 内容が分かりやすい（独りよがりではなく、相手が分かりやすい内容であるか）
- 一気に資料を説明するのではなく、キリのいいところで問いかける
- リラックスできる（雑談を入れる、表情、態度）などの環境
- 資料の内容が分かりやすいだけでなく、場の雰囲気や話し方など相手が気持ちよく聞けるような環境が大事
わかった気になって勝手に解釈をしない
- 相手の話は大体抽象化されているので、具体的に色々聞く
- 範囲を指定する言葉は注意する。例：たくさん（具体的な数値は？）、〇か月/〇週間くらいで（具体的に何日か）
- 突っ込んで聞くとその話について相手の関心度合いが分かる（重要な話であれば具体的な話が多く出るし、そうでもなければ思い付きで言っている可能性が高い）
- 少なくとも抽象化された部分について、自分の解釈で具体化して理解しないようにすること
- 質問をすることは相手に失礼とか考えなくていい。躊躇してあいまいにして後で面倒なことになるよりずっといい。
- 相手の話は大体抽象化されているので、具体的に色々聞く
社内でのコミュニケーション
- 相手が受け入れやすい話し方をする
- アサーティブな表現を心掛ける
- 責めるような「なぜ」という表現ではなく、提案、依頼の表現にする
- 「なぜ～～なんでしょうか」→「〇〇の理由を教えていただけますか」
- 否定文ではなく肯定文にする *「～～でないとできません」→「～～すれば可能です」
- 「私」を主語にする
- 「～～だとあなたが～～です」→「～～だと私が～～です」
- 責めるような「なぜ」という表現ではなく、提案、依頼の表現にする
- アサーティブな表現によって、相手の怒りを買うことなく、自分の主張を伝えられる
- 自分の主張を伝えるために強い表現にするのはNG。また、自分の主張を言わず、従順になるのもよくない。
- アサーティブな表現を心掛ける
- 話しかけられやすい雰囲気を作る
- 話しやすい雰囲気を作りたいならまずは、たたずまいから
- 会議で眉間にしわが寄っている、話しかけても目を合わせない、ひたすら反論する、などが続くと、話しかけにくくなる。
- 話しやすい雰囲気を作りたいならまずは、たたずまいから
- 悩みは解決すればいい、ということではなく、共感も必要
- 相手の悩みに一方的に解決策を提示するのではなく、共感から入る。
- 悩み相談はまずは相手の話をひたすら聞く。そのうえで相手の思いにまずは共感する。
- 実は最初に言ってくれた悩みは表面的なところで、実はもっと根深い何かがあるのかもしれない。
- 部下の成長のために上司がやるべきこと
- その仕事をすることで何ができるようになるかを部下に伝える
- 仕事を任せるうえで「ストレッチ」「リフレクション」「エンジョイメント」の要素を持たせると成長が早い
- ストレッチ：自分が今できることをベースに背伸びになることに挑戦
- リフレクション：経験を振り返る
- エンジョイメント：達成感、意義を味わう
- 「俺ちょっとできるんじゃないか」と思っている勘違いの若手には効果的ｗ
あとがき
全体的に「相手の話にとことんつきあう」という姿勢を伝えたいのかなと思いました。相手の話に付き合い、本当の悩み、課題はなにかが見えてくる。それに共感することで信頼を得られる。 わかってはいますが、これを実践するのは大変と思いますｗでも日ごろから意識すれば少しずつ改善されるのではないかと思っています。
