OneSignalについて調べた
- PWAについて調べる
- OneSignalでpush送信ができる
- ネイティブアプリでしかできないことも多いが、要件によってはPWAのほうがネイティブアプリよりもいい場合がありそう
- WEBの技術者のほうが数が多そうなので、未来でネイティブアプリよりもシェアをとっていたら面白い
「スパイダーマン ファー・フロム・ホーム」見ました
ネットフリックスで見ました。 1/7から公開される映画の予習として見ました。
スパイダーマンシリーズについてよくわかってなかったのですが、映画だけで3シリーズあるようです。
今回見たのは3シリーズ目の2番目の映画です。3番目が1/7から公開予定です。
スパイダーマンのいいところは平凡な主人公がある日突然、力を手に入れて、ヒーローになっていくところです。 日本のヒーローの大多数と違い、人間としての脆さや葛藤みたいなものが描かれています。 そこが人間らしくて感情移入しやすいような気がします。
今回見たシリーズは比較的に明るい話が多そうで、見やすい様な気がします。比較的1番目のスパイダーマンの話が重い印象があります。
「劇場版 呪術廻戦 0」見てきました
あらすじは書きませんが、とても話のテンポがよくて、長めの時間だったと思うのですが全く退屈しませんでした。
主題歌もかっこいい。 エンドロールで制作に関わったひとたちの名前が出てきますが、とてもたくさんのひとたちが関わってるんだなと思いました。
ここからネタバレになるかもしれないのでまだ見てないひとはブラウザバックで。
主人公が最初自信ない感じなのですが、呪術高専に入った時点でチート級の能力があります。 その力を自分で扱える様になっていく感じがとてもよかったです。
テレビアニメは見ていて0に関しても漫画をぱらぱら見ただけで事前にあらすじの情報は入れていきませんでした。
リーダブルコードを読んだ
リーダブルコード
――より良いコードを書くためのシンプルで実践的なテクニック
3年ほど前に購入した時に一読したのですが、あらためて読みました。 前半は読みやすく、後半からコードを追うのが難しい箇所があり、時間がかかりました。 読書したときのメモや感想をまとめました。
理解しやすいコードを書く
- コードは短いほうがいい
- ただし、理解しやすいコードのほうが大事
- コードは理解しやすい前提で短い方がよい
名前重要
- いい名前をクラス、メソッド、関数、変数につける
- たとえば、単にgetではなくてget以外の何をgetするのかがわかる単語に変えたほうがよい
- もしくはget+動詞とか
- 基本的には、名前に一時的以外の情報がないtmpは避ける。tmpを変数や返り値の変数に使うと何を返すかわからないので意味のある名前がよい
- ただ、変数のスコープが狭く(3行とか)、用途が明確な場合には使ってもいい
- for文など繰り返し処理内でiなどの変数を使うのがいいが、複数同じ用途の変数がある場合は、iではなくitems_iなど他のものと区別できるものがいい
- 意味がわからない省略した名前を使ってはいけない
- スコープがせまくて、使用する箇所が近くにあって用途がわかる場合であればよい
- 短くしても意味がわかるものは、短くする (例)convertToInteger() を toInt()
見た目の美しさ
- インデント重要
- 複数連続で定義する変数や配列の中身の定義だと縦に揃えるととても見やすい
- 並び順に意味をもたせる。並び順には理由があるとよい
- どんな理由でもよいが、できれば、他と統一性があるとよい
コメント
- コードを読んですぐにわかるものにはコメントを書かない
- 読んですぐにわからなそうなコードにはコメントを書く
- そのほうが早く処理を追うことができる
- 短い簡潔な文章であっても全体像がおぼろげでもわかるコメントがあるとよい
- 新しくプロジェクトに入り、全体像がわからないとつらい
- ソースをがんばって読むよりも処理の要約がコメントされていたほうが時間がかからない
- コメント中にそれやこれといった代名詞が何を指していないかわからない場合に代名詞を使わない
- 代名詞がひとつしか刺さない場合は使ってもよい
- メソッドの引数と返り値の例を示すと分かりやすい場合がある
if文について
- if の左側に変化する。右側に変化しない値を持ってくると読みやすくなる
# コード例 if (length > 0) { // なんらかの処理 }
- ifは基本、肯定が先、否定があと
- 否定が主な場合は、否定が先
三項演算子
- 条件が単純で1行で読みやすくかける場合は、三項演算子を使う
- ガード節や変数への代入で使うと便利
- ネストが2重以上で、複雑で分かりづらい場合は、if/ elseのほうがよい
- 三項演算子のデメリットはデバッガーでデバックしずらいこと
ガード節
- 早く返すと読みやすくなる場合は、ガード節を使う
# コード例 def hoge(params) return false if params.nil? # 以下、なんらかの処理 end
ネスト
- true/falseを返す関数では、ifの中にifを書くようなネストの深いコードを書くよりif文の中で早めに都度returnさせたほうがネストが浅くなって読みやすい
- ifの中にifを書くよりも、ifをふたつ書いた方がよい
変数のスコープ
- 変数のスコープは小さくしたい。変数を変更する際に、影響範囲が小さくなって読みやすくなる
メソッドの分割
- そのメソッドの上位の目的ではないものは、関数を分けて抽出する
- 読みやすくなるし、再利用できるかもしれない
- メソッドにひとつのことをさせると単純に読みやすい
- 覚えることが少なくてすむ
コードを書く前に
- 人に説明するつもりでやりたいロジックをシンプルに整理する
コードを書かない
- 要件を確認して、簡単な実装にできないかを考える
- コードを書かないのが一番バグがない
- ライブラリがあれば自分で書かないで、それを使ったほうがよい
テストを書きやすくする
- クラスを小さく
- クラス、メソッドがひとつのことをしている
- クラス同士が依存が少ない
全体的な感想
原文もそうだと思うのですが、文章が優しく、翻訳も優しくて、読みやすいです。 15章「分/時間カウンタ」を設計・実装するぐらいから僕は急に読むのが難しくなった印象があります。
サンプルコードも多くの言語で書かれていて、自分の好きな言語、得意な言語が出てくるとうれしいですね。
随分前に一回読み、内容を忘れていたのですが、確かに自分の中に無意識にやっていたことがありました。 コードを綺麗に読みやすく書くのは、自分の中で優先順位が高いのでネットの記事や他の書籍等でも読んでいるので、そこで重複してるかもしれませんが。
ヴェノム:レット・ゼア・ビー・カーネイジを見てきました
事前に、予備知識を入れていきませんでした。 家族が見ていた、前のものを見ていたので、だいたいの内容はわかっていました。
とても、面白かったです。 グロいと目を覆いたくなるシーンはうまく見えないように作られているのかそこまでないので、安心して見れるかもです。
ネタバレになりそうなので、感想は、簡単にしか書けません。
これはヴェノムに限らないのですが、こういう拒絶しあっても結局共闘するみたいな話って好きだなって思いました。 お互いにダメダメだったのにふたりになるとすごくなるみたいな話が好きですね。
ナイツの塙宣之とYouTuberコヤッキーのトークライブ!行きました。
大井町のきゅりあんというところでした。 夜7時からだったので、遅めに電車に乗りました。 日が暮れてからでかけるのはおっくうなのですが、ライブなのでいつもよりは足取り軽かったです。
4人の方がステージに立ちました。
塙さん凄く話し回してて、凄かったです。
いっぱい笑いました。 コヤッキーさんも話うまかったです。 たくさんの人達が見てる前で噛まず、会話もかぶさず、何も見ずできるのはすごいなーと思いました。
ワンピースは、今は読んでないのであまり分かりませんでしたが楽しめました。
- 政府関係者の話
- マスターのワンピース考察
- 黄金伝説の話
が面白かったです。 漫才もコヤッキーさんが完璧にしてきたので、未経験とは思えませんでした。 塙さんとセリフが被らないようにしていらっしゃったと意識されているのかなと思いました。 本家の土屋さんは、ある程度塙さんのセリフと被せ気味のツッコミなので、相対的にコヤッキーさんのツッコミは遅いような気が素人目にしましたが、面白くて、とてもよかったです。 行ってよかった。
エンディングで塙さんが急に真顔になって、すぐにはけていくところが正直びっくりしました。 onoffの切り替えがすごいのかもしれません。 ボケだったのかもしれません。
前提がわからないので、?マークがつきました。 とーやさんのボケぶりを見て、聞く人が認識していないものの(前提がない)ボケは成立しないなと思いました。 塙さんからもそういうとこだぞとつっこまれていました。