shiki0331’s blog

Web Developer. TypeScript / React.js を中心に学んでいます。 ブログ内容で間違っている箇所などありましたら、ご指摘していただけると助かります。

振り返りKPT

最近ソニックガーデン代表・倉貫さんのブログを見てから、「振り返り KPT」を良いなと思いTwitterでやってみました。


KPTの詳しくは倉貫さんのブログ見て下さい。https://kuranuki.sonicgarden.jp/2018/04/kpt-method.html


けど、Twitterでやる意味はないかなと思いました。


初めは140字以内で要約する練習になるし良いかなと思ってたんですが、それだけのためにTwitter使うのもなと思いました。


あくまで自分のために書くものですしね。


振り返り KPTを広めていく上ではTwitterの方がいいのかな？


とりあえずは今後、はてなブログに書いていきます。



では今日の振り返り KPTです。



考え方・価値観が固まってきた。


考えや思ってることを文章にしたりするのはいいけど、口に出すのは上手くできないから普段から発言しよう。


明日の面談は自分を取り繕わないようにする。



以上です！


読んでくれた方はありがとうございました。



20分チャレンジ リーダブルコード 第三章 「誤解されない名前」

20分で本を要約していきます！



変数の名前には誤解されない名前を付けよう。


あいまいな名前を付けてしまうと、コードの理解を複雑にしてしまう。



filter・length・limitのような名前だとコードの意味がわかりにくい。


例えばCART_TOO_BIG_LIMITの名前では未満か以下なのかわからない。


限界値を含めるときは名前の前にmaxやminを付けて明確にしよう。


MAX_ITEMS_IN_CARTなら名前から以下であると予測できるだろう。


次は範囲を指定するときだ。


start・stopでも表せるが、first・lastの方が理解しやすいだろう。


lastであれば最後まで含まれると予測できるからだ。


他にもbegin・endと表してもいいだろう。



ブール値の名前の付け方だ。

ブール値は論理値。つまりtrue・falseのこと。


read＿password ＝ trueでは、

パスワードをこれから読み取るのか？

パスワードをすでに読み取ってるのか、わかりにくい。


代わりに、need＿password やuser_is_authenticatedと名前を付けるべきた。


そうすれば誤解されないだろう。



名前を決めるときには複数の名前を検討するのが大事だ。


名前を付ける時には理解しやすさを求めるのも大事だが、誤解されない名前といった視点を持つとより良いだろう。



以上です！



僕は英語が苦手なので、名前を付けるときにパッと単語が出てこないですね。


なので、類似語を調べたりすると良い名前が

付けれる気がします。


リーダブルコードにも書いてありましたね！



名前を付けたときに、本当にその名前で良いか一度立ち止まって考える癖を付けるべきですね。



本を要約するときにはコピペになりすぎず、内容をできる限り短くできるように心がけているつもりです。


あとは自分の言葉で置き換えることですね。


けど、これがなかなか難しい、、

結構コピペになってしまってるかな、、


次回はもっと意識します！！


最後まで読んでいただき、ありがとうございました。


競技プログラミングを解こう part4

最近AtCoderのA問題が解けるようになってきたので「今日も余裕かな〜」と思って 解いてみたら難しかったです、、泣

 

けど面白い問題だったので、是非解説していこうと思います！

 

まずは問題内容です！

 

問題文

文字列 S が入力されます。これは、西暦 2019 年の実在する日付を yyyy/mm/dd の形式で表したものです。(例えば、2019 年 4 月 30 日は 2019/04/30 と表されます。)

S が表す日付が 2019 年 4 月 30 日またはそれ以前なら Heisei、そうでなければ TBD と出力するプログラムを書いてください。

制約

  • S は西暦 2019 年の実在する日付を yyyy/mm/dd の形式で表す文字列である。

入力

入力は以下の形式で標準入力から与えられる。

S

出力

S が表す日付が 2019 年 4 月 30 日またはそれ以前なら Heisei、そうでなければ TBD と出力せよ。

入力例 1 Copy

Copy
2019/04/30

出力例 1 Copy

Copy
Heisei

入力例 2 Copy

Copy
2019/11/01

出力例 2 Copy

Copy
TBD

 

atcoder.jp

 

 

解けましたか？？

今回の問題は今までの問題よりも、色々な解き方があると思います！

 

 

では解説していきます〜

 

 

 

 

 

 

まずは入力です。

制約

  • S は西暦 2019 年の実在する日付を yyyy/mm/dd の形式で表す文字列である。

入力

入力は以下の形式で標準入力から与えられる。

S
 yyyy/mm/ddなので
ex) 2019/03/31　(僕の誕生日、、笑）
 
上記の様に年月日を / で区切って入力できる様にしてあげればいいんですね。
 
区切るといったら  split
入力といったら gets
 
上記のメソッドですね〜
 
入力は
y, m, d = gets.split("/").map(&:to_i)
 
これで 2018/03/31 と入力すると
 

y,m,d = gets.split("/").map(&:to_i)
2018/03/31

=> [2018, 3, 31]

 
となります！
 
 
map(&:to_i) っていらないんじゃ？と思いがちですが
 
ですが、、
 
y,m,d = gets.split("/")
 2018/03/31

=> ["2018", "03", "31\n"]

 

Stringになってしまい、なおかつgetsを使っているので改行が付いてしまうんですね。

 

なのでIntegerにするために map(&:to_i)  が必要なんです！

 

 

ちなみに僕は入力が

入力

入力は以下の形式で標準入力から与えられる。

S
 だったので一文字の入力で yyyy/mm/dd を表さなければいけないと思ってハマってました、、笑
けど別に y, m, d みたいに分けてもいいみたいですね。
 
 
次は出力を考えていきましょう。
 
日付が 2019 年 4 月 30 日またはそれ以前なら Heisei、そうでなければ TBD と出力せよ。
 
4月は30日が最終日です。
なので4月ならHeisei  5月ならTBD  と言い換えることができます。
 
m > 4
 
つまり上記のように不等号で表現できます。
 
後は if 式に当てはめるだけです〜 
  1. if m > 4
  2. puts "TBD"
  3. else
  4. puts "Heisei"
  5. end
 
 
なので答えはこうなります。
  1. y, m, d = gets.split("/").map(&:to_i)
  2. if m > 4
  3. puts "TBD"
  4. else
  5. puts "Heisei"
  6. end
 
 
僕は日付だったので Date Classとか使うのかなーと思ってたんですが、使わなくても全然いけますね！笑
 
個人的に「なるほど〜！！」と思った答えがありました。
  1. puts gets.delete("/").to_i > 20190430 ? "TBD" : "Heisei"                                                       

 

delete("/")  で入力されたスラッシュを消して、20190331みたいに連続させた数字にして不等号で比べるんですね。

 

「こんなやり方もあるんだー！」と思って楽しかったです！

 

 

今までRailsをやってきましたが、正直Rubyの知識を使うことが余りなかったので凄く勉強になりますね。

 

何より楽しいです。笑

 

 

最後まで読んでいただき、ありがとうございました。

 

競技プログラミングを解こう　part3

今回はAtcoderのB問題をやってみました〜

 

B問題はA問題より難易度が高いです。

 

下記が問題内容です。

問題文

ABC 洋菓子店では, 1 個 4 ドルのケーキと 1 個 7 ドルのドーナツが売られている.
このとき, 合計金額が N ドルとなる買い方はあるか, 判定せよ. ただし, 同じ商品を二個以上買っても良く, 買わない商品があっても良いものとする.

制約

  • N は 1 以上 100 以下の整数

入力

入力は以下の形式で標準入力から与えられる.

N

出力

合計が N ドルとなる買い方がある場合 Yes, そうでない場合 No と出力せよ.

入力例 1 Copy

Copy
11

出力例 1 Copy

Copy
Yes

ケーキを 1 個, ドーナツを 1 個買えば合計 4+7=11 ドルとなる.

入力例 2 Copy

Copy
40

出力例 2 Copy

Copy
Yes

ケーキを 10 個買えば 4×10=40 ドルとなる.

入力例 3 Copy

Copy
3

出力例 3 Copy

Copy
No

ケーキの値段は 4 ドル, ドーナツの値段は 7 ドルと, どちらも 3 ドルより高いためそのような買い方は存在しない.

atcoder.jp

 

 

Aに比べると難しい！！

 

自分はわからなかったので答えを見ました泣

 

せっかくなので解説していきます！！

 

 

 

入力

入力は以下の形式で標準入力から与えられる.

N
 まずは入力からですね。
N = gets.to_i
 
これで入力した数字がNに入ります。
 

出力が難しいですね、、

 

制約を確認してみましょう。

制約

  • N は 1 以上 100 以下の整数

 

上記の制約なので、ケーキは一個4$なので

4$*25個=100$

最大25個買えますね。

 

次はドーナツです。

同じように考えると、ドーナツは一個7$なので

7$*14個=98$

最大14個買えます。

 

問題文に下記の記述があります。

同じ商品を二個以上買っても良く, 買わない商品があっても良いものとする.

 

なので

ケーキを0〜25個買ったケース+ドーナツを0~14個買ったケースが、入力したNと等しければ'YES'となります。

 

全部のパターンを考えれば良いのでeachを使います。

 

(0..14).each do |d|
　(0..25).each do |c|
　　
　end
end

dはドーナツ、cはケーキです。

 

これで全部のパターンを考えられます。

 

あとは入力したNと等しければ'YES'、等しくなければ'No'となるようにします。

 

(0..14).each do |d|
　(0..25).each do |c|
　　if c*4 + d*7 == N
　　　puts 'Yes'
　　　exit
　　end
　end
end

puts 'No'

 

ケーキ + ドーナツがN$であればYESと出力します。

 

exitを入れるのはif文が成立したら、そこでプログラムを終了させるためです。

exitがないとプログラムが続いてしまい、Noも出力されてしまいます。

 

初めは

if c*4 + d*7 == N
　puts 'Yes'

　exit
else
　puts 'No'

　exit
end

 

でもよくない？と思ったのですが、この場合はNに4が入力されてもeachなので0から順番にd・cに値が入っていきます。

 

つまり、 if  c*4 + d*7 == N　が成立しなかった時点でelseにはいってしまいます。

 

だから下記の記述でなくてはいけません。

(0..14).each do |d|
　(0..25).each do |c|
　　if c*4 + d*7 == N
　　　puts 'Yes'
　　　exit
　　end
　end
end

puts 'No'

 

 

なんとなくわかったでしょうか？

 

B問題もスラスラ解けていけるようになりたいですね〜

 

最後まで読んでいただき、ありがとうございます。

20分チャレンジ　リーダブルコード　第二章　「名前に情報を詰め込む」

本を要約するパート２です。

 

今回もリーダブルコードを要約します！

前回に引き続き第二章です。20分チャレンジです！

 

 

 

誰もが変数名から必要な情報を読み取れるような名前付けが理想的だ。

 

良い名前付けをする方法をいくつか説明していく。

 

変数名には抽象的ではなく、具体的に想像できる名前をつける。

 

例えばsizeの名前は一見わかりやすそうだが、そのsizeが何の大きさ・長さ・量を指しているかわからない。

startと似た使い方ができる単語だけでも、begin・launch・open・createなどある。

 

変数の使い方によって明確な単語を使い分けれるようになろう。

 

 

tmp・fooなどの意味のない言葉を名前に選ばないようにしよう。

ただし、一時的な情報の保管ですぐに上書きしてしまう場合にはいいだろう。

 

 

時間やバイト数など値があるものには「変数名＋値」とすると、よりわかりやすいだろう。

 

例えば、start_msやsize_mb

こうすることで、より名前に明確な情報が持たされる。

 

長すぎる名前は覚えにくいし、コードが折り返されると理解しにくい。

 

長すぎる名前は良くないが、短すぎると情報が詰め込めない。

どうすれば良いか？

 

変数のスコープが小さければ、短くて情報が少なくてもいいだろう。

スコープが小さいということは、近くに変数名があるので確認しやすい。

 

 

自分で考えた名前の省略形は使わない方が良い。

しかし、string・documentなどはstr・docと略してもわかるだろう。

 

公式ドキュメントや技術書で省略されている名前に関しては省略しても良いだろう。

 

 

プロジェクトメンバーや会社などでコードの書き方を統一して一貫性をもたせることも大切だ。

 

 

変数名を見ただけで必要な情報が取得でき、コードがより読みやすくなるように名前を付けよう。

 

 

最後まで読んでいただき、ありがとうございます。

 

 

今回は時間配分が上手くできなくて、後半が駆け足になってしまった。

初めにページ数と時間を考慮して時間配分を決め、時間内に理解しやすい要約ができるようにしていこう。

 

最後まで読んでいただき、ありがとうございました。

 

 

10分チャレンジ　リーダブルコード　第一章　「理解しやすいコード」

今回はオライリージャパンから出版されている名著である「リダーブルコード」の

第一章である「理解しやすいコード」を読んで自分なりに解釈して要約したものを10分で書いてみます。

 

良いコードは理解しやすいコードは優れた設計やテスト、バグの見つけやすさにも繋がる。

 

良いコードとは？

 

良いコードとは理解しやすいコード。

それも自分が理解しやすいではなく、他の人が見ても理解しやすいようにするべきである。

 

なぜ他人のために？と思うかもしれない。

個人開発では自分しか見ないとしても、数ヶ月後の自分がコードを見たときはあたかも他の人のコードに感じることもある。

 

だから個人開発でも理解しやすいコードを意識するべきである。

 

 

コードは短ければ良いが、必ずしも短く一行に収まるコードが良いとは限らない。

一行に凝縮するよりも二行、三行と分けて書いた方が理解しやすいケースもある。

 

あくまで「理解しやすいコード」を意識して書くことが大切。

 

それを書くには他の人のコードを見るように、初めて見たコードを見るように書くことが重要。

 

 

最後まで読んで頂きありがとうございます。

本の要約は思ったよりも難しいですね。ただのコピペにならないように自分で解釈してかつ、他の人が見てもわかるようにする。

 

あれ、なんかプログラミングのコードと似てますかね笑

今書いてて思いました笑。

 

 

APIとは？APIを叩く？

初め「APIを叩く」という言葉を聞いたときは意味不明でした。

 

APIってなに？叩くものなの？？　みたいな感じでした。笑

 

APIとは

Application Programming Interface

アプリケーション　プログラミング　インターフェース　です。

 

インターフェースは「接点」という意味なので、アプリケーションとプログラミングの接点的な意味です。

 

アプリケーションとプログラミングを行き来できるような扉とイメージしてください。

 

扉の機能に加えてアプリケーションから情報を取得できる仕組みも付いています

。

 

つまりAPIを叩くとは、プログラミングでアプリケーション（Youtubeとか）の情報を取得するというイメージです。

 

具体的にいうと、Youtubeだったら動画の情報とか、食べログでは店舗の情報、Newyork Timezでは記事などです。

 

なので簡単に自分のアプリケーションで動画や記事の一覧、店舗の位置情報などを利用することができます。

 

APIを提供しているアプリケーションは多いです。しかし、自由に使えるのではなくAPIを使用します！という登録が必要になってきます。

 

中にはお金がかかるものや、回数制限などもあるので確認してみてください。

 

 

最後まで読んで頂きありがとうございます。

間違っている箇所などありましたら指摘して頂けると助かります。