「思考の整理学」を読んだ

書籍 fjord boot camp

www.chikumashobo.co.jp


久しぶりに美容院に行った帰りに書店により、前々から気になっていた「思考の生理学」購入しました！

この本について

1983年（文庫化は1986年）に出版され、約200ページであり、 東大生や京大生に支持されるているからといって特別に難しいわけではない！

先生、教科書に引っ張ってもらうグライダー。与えられた高さやスピードから揺れながら地面に落ちていくだけのグライダー。
頭というエンジンを使って飛ぶ飛行機。自力で離陸し空を飛べる飛行機。
どちらがこれからの社会を生き抜けるかそれはもう自明のこと。それをほぼ40年以上前に予言していたそんな本!

自力で空を飛べる、思考できるようにするためにどのような方法があるのかヒントになる本です！


所感

  • 朝飯前

「朝飯前」とは簡単なこと、やさしいことという意味を思い浮かべる。
しかし著者は、朝にやるからこそ簡単に感じるという逆転の発想を提示してくれる！

朝の生産性は1日の中で高いことは様々言われている。
そして昨今、睡眠の重要性が取り上げられる。この本も睡眠について脳の忘却と整理が行われ、起床後は頭がすっきりしていることが書かれている。
私として、睡眠は十分だが、朝の時間を有効に使えていない。
そこで次の日、起きてすぐこの本の続きを読んでみたら、昼や夜に読む感覚とは違うことがわかった！
少しずつ、朝活を取り入れて日々の学習効率を上げていきたいと思った。


  • メモ

学校ではノートに詳しく書き記す。
それは忘れないために記録すると、深くも考えずにやっていた！

この本ではメモをとると逆に忘れてしまうと著者は言っている！書いたことで安心してしまうためだ。
本当に大事なこと、関心あることは忘れない！

現在、私はプログラミングを学習していて、fjord boot campプログラミングスクール）`で日報を書き、メモをとることが多い。
今まで、サイトに載っていたことをただ貼り付けて、見返せるようにしていた。
しかし考えてみれば、そんな情報はまたググれば簡単に見つかるようなことばかりだ！
もっと有意義に使えるようにするにはどうすれば良いか考えている......

実は、前にヒントをもらったことがある！
それはRubyKaigiなどで活躍している角谷さんが講演をしてくださったときのことだ。
日報の書き方について以下のようにアドバイスをして頂いた。

・今の気持ち（感情）
あなたが書かなければ誰にも伝わらない。”相手に伝わるように”テキストで書くには訓練が必要だ
・やったこと（事実）
今日も１日がんばった！詳しく書きたいだろうけど、みんなは詳細を見たいかな？
・わかったこと（意見、解釈）
もちろん、感情以外も適切に伝わるようにテキスト出力するには訓練、訓練、訓練
・次にやること（計画、表明）
考えることは大事だけれど、明日の自分への置き手紙（明日の自分に適切に伝わるように書けるかな？）
・シャウトアウト（感謝）
チームに感謝。仲間に感謝。よい振る舞い、助かったことをフィードバックして増えたらうれしくない？


私はこの中で、感情が足りていないなと感じた。
というのも、今までプログラミングの知識や思考に関することだけを書いていた。
「あれがわかった、これはこう考えた。」など狭い次元で書いていた。
今、「Team Geek」も読んでおり、チーム、人と人との関係を意識するようになってきた。
PCのコードを眺めている時間が多く感じるが、一人でコードを書き続けることは少ない。(詳しくはTeamGeekを読み終わった後に所感を書きたい。)

自分として、fjordに通う他の生徒の気持ちを知りたい。
逆に、他の生徒も知りたいと考えているかもしれない。そのために、自分からも感情を書くことでお互いどう思っているのか知り合える。
また例えば、仕事で顧客や後輩の気持ちや感想を聞きたいということを考えると、fjordのメンターとしても生徒の気持ちという部分は一番知りたいのではないかと考える。

いろいろ試行錯誤して良い日報を書けるようにしていきたい！

論理演算子について(&&, ||, ??)

Ruby JavaScript

if文など、条件式で使われる論理演算子のAND演算子(&&)、OR演算子(||)、
Nullish coalescing演算子(??)について書きます〜

RubyとJavaScriptを例として使います〜


はじめに

前提知識として,Ruby,JSでfalsyな値(falseになる値)を整理 

false
nil



false
undefined
null
0
0n
NaN
""(空文字列)


これら以外はtruthyになる(falseになる値を覚えた方が効率が良い)


AND演算子

AND演算子（&&）は、左辺の値の評価結果がtrueならば、右辺の評価結果を返します
一方で、左辺の値の評価結果がfalseならば、そのまま左辺の値を返します

puts false && true  # => false
puts true && false  # => false

console.log(false && true) // => false
console.log(true && false) // => false


OR演算子

OR演算子（||）は、左辺の値の評価結果がtrueならば、そのまま左辺の値を返します
一方で、左辺の値の評価結果がfalseであるならば、右辺の評価結果を返します

puts false || true  # => true
puts true || false  # => true

console.log(false || true) // => true
console.log(true || false) // => true


Nullish coalescing演算子(JavaScript)

Nullish coalescing演算子(??)は、左辺の値がnulishであるならば、右辺の評価結果を返します
nulishとは、評価結果がnullまたはundefinedとなる値のことです

console.log(false ?? true) // => false
console.log(true ?? false) // => true
console.log(null ?? true) // => true
console.log(true ?? null) // => true


OR演算子と似ているが、falseや0は判定されないので以下のように違うことがわかる

const value = 0
console.log(value || 111)

// => 111

const value = 0
console.log(value ?? 111)

// => 0

開発用ブランチにいながら最新のマスターブランチを取り込む方法

GitHub Git

作業を別のブランチで進めているとき最新のマスターを取り入れたい時がある
また、プルリクでコンフリクトを起こすこともあるので解消方法を書く

最新のマスターブランチを取り込む

# masterブランチを更新
% git fetch origin master

# 作業中ブランチへ master を取り込む
% git merge origin/master

＊この方法はmasterブランチは更新されません。
masterブランチも更新する場合はmasterブランチに移動して同じく
% git merge origin/masterを行う必要があります
または下の方法で行えます
masterブランチが更新されない理由についてはfetchを解説している以下の記事を見てください

qiita.com

masterも更新したい場合

# もし、作業途中のものでcommit出来るものがあればcommitしておく
# masterブランチへ移動
% git checkout master
# git pullでmasterを最新に
% git pull origin master
# 作業していたブランチへ移動
% git checkout <作業していたブランチ名>
# mergeコマンドでmasterの内容を取り込む
% git merge master


コンフリクトを指摘されたら

  • マージするとどこのファイルでコンフリクトした指摘される
 % git merge master
CONFLICT (content): Merge conflict in <ファイル名>

# 省略〜〜〜〜〜〜
  • 指摘したファイルを開くと以下のように書かれているので修正する
<<<<<<< HEAD
ここに変更したもの
=======
ここはmasterのもの
>>>>>>> master



以上で開発ブランチにいながら最新のマスターを取り込みました。

Pull Requestのやり方

GitHub

毎回プルリクのやり方を忘れてしまうので備忘録として記録しておく

  • ローカルのブランチを確認

    *は作業中のブランチ

% git branch
* master


  • トピックブランチを作成

    （上はブランチの作成と切り替えをまとめてやってます。）

% git checkout -b <branch名>

# どちらか

% git branch <branch名>
% git checkout <branch名>

  • branchを確認すると新しく作成され、作業中の*がついている

  • コードの差分を確認

    ＋、ーで変更点がわかる

% git diff

  • ブラウザでもレイアウトが崩れていないか確認

  • 変更をコミット

% git add <ファイル名>

# 全てを対象にするなら

% git add *

その後

% git commit -m "コミットメッセージ"


  • リモートブランチの作成

    プルリクを送るためにはGitHub側に修正を加えたブランチが必要 手元のbranch名に相当するブランチを作成（同じブランチ名）

% git push origin <branch名>
  • ブランチを確認するとリモートブランチが作成されている
% git branch -a


GitHub側で操作する

  • ブランチを切り替える

    f:id:gallard316:20200813185325p:plain
    ブランチの切り替え

  • compareを押して差分を比較する

    ＋、ーで差分がわかる

    f:id:gallard316:20200813190216p:plain
    compareボタン

  • create pull requestボタン押してプルリクを取り込んでもらうためのコメントを記載する

    ブランチ名が既に書かれているかも

  • 最後にcreate pull requestで送信する

    これで完了

SQL＆データベース設計の学習

SQL 書籍 fjord boot camp

フィヨルドブートキャンプのSQL、データベース設計の課題を終えたので書籍について、またTwitterのERDを作成して見て感じたこと、そして今後の自分への戒めを書きたいと思います。

今回、SQL関連の書籍4冊を取り組みました。
①SQL ゼロからはじめるデータベース操作(翔泳社：著 ミック氏)
②SQL 書き方ドリル(技術評論社：著 羽生章洋氏)
③達人に学ぶDB設計徹底指南書(翔泳社：著 ミック氏)
④楽々ERDレッスン(翔泳社：著 羽生章洋氏)

www.shoeisha.co.jp

gihyo.jp

www.shoeisha.co.jp

www.shoeisha.co.jp


①SQL ゼロからはじめるデータベース操作

この本のおかげでSQLについて（SQL文の書き方を）理解することができました。
とてもわかりやすいです！
PostgreSQLを使って手を動かしながらSQL文を書くことができるので頭に残りやすいです。

しかし後半に難しい内容があります。
・ サブクエリ、相関サブクエリ
・ ウィンドウ関数
・ GROUPING演算子
このへんは何となくでしか理解できず、使いこなす自信がありません...
SQLを使っていく中で使いこなせるようになったら、またブログに書いて理解を深めていけたらと思います！

②SQL 書き方ドリル

何かを理解したことと使えるようになることは雲泥の差がある。
私も上記のゼロからはじめるデータベース操作を読んで、大丈夫だろうと考えていたが全く力はついていなかった...当たり前だ！

このドリルはアウトプットすることで、書く力と自信がつく。
アウトプットする題材がなかったのでよかったです。
ひとつ難点をあげると問題の解答の解説がほしかったです！

最後に自分に一言！
サブクエリができていなかったのでまた復習しましょう笑

③達人に学ぶDB設計徹底指南書

SQL使ってデータを取り出す事ばっかり考えていたけど、元となるデータの入れ物ももちろん作れるようにならないといけない。
それがDB設計！
この本はDB設計の中心、正しい正規化のやり方を学べました。

そしてさらに踏み込んで、
もう一つのテーマ、トレードオフも学べます。
トレードオフとは、何かをするために片方を立てれば、もう片方は犠牲にならないといけないこと。
例えば、痩せたいけど、甘いもの食べたいなど
DBになると、正規化はしばしばSQLのパフォーマンスを悪化させることがある。
例えば、テーブル同士をくっ付けたりすることはRDBMSにとっては重い作業である。
じゃあどうすればいいのかわからない？！
そんなときはとりあえず、正規化できるところまでしておくことが良いと著者はいっている。
このトレードオフの感覚を掴みいい塩梅を見つけるのは難しく、現場で実践していきながら身に付けたい！

④楽々ERDレッスン

この本はDB設計でテーブルを作る前の段階のER図を作成するための本です。
私としては所々しか理解できず、難しかったです。
先に③達人に学ぶDB設計徹底指南書を読んだ方が良いです。
この本は最後の章で身近にある注文表や水道料金通知書などをER図にしていたので具体的にやり方が理解できました。
やり方を知らないと何となくでやって、これでいいのかなと不安になる。

やり方メモ
①イベントを見出す
核となるテーブルを見出す。「〜する」に当てはまるもの、例えば、注文、購入など。これを「イベント系」と呼ぶ。
②リソースを抜き出す
次に、「誰が」や「何を」にあてはまる物を見出す。例えば、顧客、商品など。これを「リソース系」と呼ぶ。
③項目を入れていく
テーブルを出せたら、それぞれのテーブルに項目を入れていく。項目を入れて、さらに正規化できそうなら正規化する。
④リレーションシップを設定する
まずはそれぞれのテーブルに主キーを設定する。その後、テーブルを繋いでいく。


まとめ

SQLはいち言語だけあって奥が深いです。上記の本を読んで身に染みました。
スラスラとSQLを書けるようになりたいです！
データはますます重要性を増してきているのが普段生活していてわかります。
そのデータを根底にプログラミングが成り立っている(DOA)。
丁寧に着実にSQLを学習してきましたがまだまだ実践力が足りないので、これからも定期的に学習してきます。

Rubyでlsコマンドを作る

Ruby fjord boot camp

高い壁を乗り越えたときその壁はあなたを守る砦となる


先日、Rubyでlsコマンドを作る課題が合格しました😆
提出の要件として、オプションなし,-a,-l,-rのそれぞれのオプションをつけた場合（組み合わせもあり）、さらにクラス設計で書くというものでした。
最初はどこ手をつけていいのかわからず、やることの多さに圧倒されていました。またわからないことが多く、全く手が動かず立ち往生していた時もありました。
そんな困難のなかだからこそ、学んだことがたくさんありました。

メモをしながらコードを書く✍️

最初はとりあえずベタ書きからやろうとしましたが、やることが多くすぎる！
どこから手をつけていいのかわからない。
そこで頭の中を整理するために簡単にtodoリストを作って視覚化しました。
このおかげで、やることが細分化されたのでかなり気持ち的にも楽になり作業が捗りました。

リファレンスマニュアルを見る👀

コードを書きながら、自分の意図した通りに動かしたいときだけメソッドを調べるのではなく、コードを書くまえにチラッと使えそうなコードを調べることで作業が捗る！
公式のマニュアルは難解なところもあるが、敬遠せず見る癖をつける大事だと学びました。

クラス設計、メソッド定義について🛠

最も苦戦したのがクラス設計でした...
クラス設計、メソッドを使うと処理が簡単になるということはわかっていてもどうすればいいかわからない😖
本や記事でインプットはしても使いこなすことは難しく、2日くらいは手が動きませんでした。この時が一番メンタルにきていました。
何がわからないのかわからない、一向に進まないことが苦しかったです。
しかしそんな暗闇でもあがいていれば何か掴めるかもしれない。
その言葉の通り、あれこれと試行錯誤しているうちにうまくいくロジックが見つけ、不格好ながらもクラス設計で作ることができました！
その後はメンターのレビューもあり、すっきりとしたコードが完成しました🎉

まとめ

この課題を終えて、技術はもとより、メンタルが鍛えられました。
lsコマンドを作れたから何でもできるという気持ちが生まれました。
だからと言って安心せず、まだまだな部分も多いので、これからもどんどんプログラミングについて学習を進めていきます。