【読書】「くそつまらない未来を変えられるかもしれない投資の話」を読んだ

本のイラストを描いている香山哲さんが好きで「くそつまらない未来を変えられるかもしれない投資の話」という本を買った。

読んでみたらすごくいい本だったので感じたことを残しておく。

好きだったお店が、なんとなく便利なコンビニで買物をするようになって潰れてしまうという、「たきたてマック」事件について書かれているが、

自分が高校生の頃、地元の個人で経営している本屋が好きで通っていたけど、なんとなく駅ナカの本屋を利用していたらいつの間にかなくなってしまった経験があった。

すっかり忘れてしまっていたけど、くそつまらない未来に加担してしまっていたのかと思いはっとさせられた。

しっかり自分の価値観に沿ってお金を使っていくこと(投資に限らず普段の消費も)について面白いたとえ話や具体例を交えて語られていて、あっという間に読み終えてしまった。

自分の価値観や行動が見直すいい機会になった。

【読書】SoftwareDesignのログ分析読んだメモ

  • ステートログ
    • 1日1回ログイン時などにDBの状態をそのままログに残す
  • データレイク
    • 今は未加工のデータをS3などにためておいて、ETLして使うのが主流
  • Parquet形式
  • Presto
    • Facebookが開発した分散処理基盤Athenaにも使われているのでクエリ高速化などで知識が必要
  • AWS Glue
    • ETLに使う
  • デッドレターキュー
    • Lambdaでのログ加工に失敗したときの再試行用にSQSをデッドレターキューに指定できそう

【読書】「なっとく!アルゴリズム」メモ

Twitterで見かけて読んでみた。 本当はだいぶ前に買ったけど文字が小さすぎたのでKindleで再チャレンジしたら読みやすかった

1章

ビッグオー記法について

2章

配列、リンクリストについて

3章

再帰について。ここは妙な苦手意識があったけど、浮かんだ疑問についてのカバーがしっかりしていて理解しやすかった。 末尾再帰は知らなかったので理解しておきたいし、Haskellも触ってみたくなった。

4章

クイックソートと分割統治について。クイックソートは知っていたけど、分割統治といいう方法論だとは知らなかったので、一段深く理解できるようになった気がする。

5章

ハッシュについて。ハッシュが衝突した際にリンクリストになるというところは納得感がすごかった。今触っている言語でどう実装されているか気になったので調べよう。

6章

幅優先探索について。感覚で触ってしまっていた箇所なので、言葉で読めたのは良かった。

7章

ダイクストラ法について。理解できたけどそれ以上はよくわからなかった。ベルマンフォード法も調べてみよう。

8章

貪欲法、NP完全問題について。これは全く知らなかった内容で、近似で妥協するという点は目からウロコだった。

9章

動的計画法について。これも理解はできたけど、、という状況。

10章

k近傍法について。内容は単純だったが機械学習にも触れられていて面白かった。

11章

読み始めたきっかけはここに載っているアルゴリズムを理解できるようになるためだったので、挑戦していきたい。 (木(ツリー)、転置インデックスフーリエ変換、並列アルゴリズムMapReduce、ブルームフィルタとHyperLogLog、SHAアルゴリズム、ディフィー・ヘルマン鍵交換、線形計画法

【AWS】最近調べたことまとめ

AWSはいろんなサービスが多くて混乱するので、チェックしたものをメモ

Cognito

簡単に言うとユーザー認証サービス。
ログインとかユーザー作成とか、アカウント連携とかやってくれる。

Amplify

AWSのサービスが使いやすくなるjsのライブラリ。

AppSync

QraphQLが簡単に使えるサービス。
RDBとかNoSQLとかに自動で保存できる。

【Flutter】よく出てくる単語を雑に解説

Flutterでよく出てくるけど直ぐに忘れちゃう単語がありますよね。。
思い出せるように雑にメモしておきます。

ちなみに、Flutter初学者は日本語の情報が少なく心が折れてしまうかもしれないが、
公式で出しているYoutubeの動画は英語がわからなくても理解できると思うのでオススメです。

前置き

基本的なWidgetとして、StatelessWidgetとStatefullWidgetがある。
複雑なアプリでは動的に表示情報を書き換えることが多く、StatefullWidgetを使う機会が多い。
しかし、StatefullWidgetは子Widgetの一部のみを書き換えるなどの器用な事ができず、ごそっと全部書き換えてしまいがち。
そんな中で、これを回避するいろんな手法が出てきたり、Flutter公式で用意してくれたりしている、、んだと思う。
あとはReduxが出てきた背景と同じ事が起きているんじゃないかな。。

BLoCとは

Viewとビジネスロジックを分離しましょうというよくある話の実践手法の一つ。
Providerと呼ばれるビジネスロジックを提供するだけの擬似Widgetを作り、親として設定する。
WidgetからはProviderを介してビジネスロジックを参照できるので、Viewとロジックが混在しないようにできる。
(強い人や公式がpackageを作っているので、BLoCを使うときには乗っかるといい。)

InheritedWidget

Viewを持たない擬似Widget
これを継承したWidgetを親として設定すると、setStateされても参照している子のみ再描画(build)できる凄いやつ。
BLoCで出てきたProviderも実はこれ。
参照するにはof(context)という静的メソッドを作ろう、使い勝手はSingletonのinstanceメソッドに似ている。

StreamBuilder

Streamの値が更新される度に、子Widgetをbuildしてくれる便利Widget
Streamはリアルタイムに値を通知・受け取りできるトンネルで、Observerパターン的なやつ。

ScopedModel

基本的にはBLoCと似ていて、ビジネスロジックをModelに置き換えたイメージ。
親としてScopedModel<ビジネスロジック>というWidgetを設定し、
使うときにはScopedModelDescendant<ビジネスロジック>というWidgetでラップして使う。
ツリー構造上でビジネスロジックの使用可否が判別しやすく、スッキリ書けるが、buildの制御がまだイマイチらしい。

【プログラミング全般】最近調べたことまとめ

しばらく離れていたらすっかり忘れていたので記録。

Webサーバー、アプリケーションサーバーについて

認識が混ざっていた。 WebサーバーはApacheとかNginxとか。 アプリケーションサーバーはUnicornとかPumaとか。 厳密にはWebサーバーにもなるが、本番環境ではNginxなどをリバースプロキシサーバーとして仲介させるのが一般的。

Rackについて

さっぱり記憶から消えていた。 Nginxを介してUnicornに届いたリクエストはRackという規格に基づいて、Railsに届く。 それ以外にも色々なミドルウェアを挟むことができる。実体はgem。

UnicornとPumaの違い

Unicornはプロセスベース、Pumaはスレッドベース。 PumaはMRI(CRuby)だとGILがあり、1プロセス1スレッドしか実行できない。 JRubyなら回避できるが、利用できるgemや更新頻度を考えると現実的ではないらしい。 また、厳密にはデータベースの結果待ちなどで並列化は可能なので、使用するメリットはある。

Rails: Puma/Unicorn/Passengerの効率を最大化する設定(翻訳)