宮水の日記

宮水の日記

主に書評や資格取得について記事を書いています。

メモの魔力を読んで、エンジニアとして活かせそうなことまとめ

f:id:kattyan53:20210503012037p:plain
メモの魔力を読みました。

◽️なぜ読んだのか

3年前くらいに周りの人が「すごいよかった」と口を揃えて仰っていたので、DMMブックスのセールをきっかけに読むことにしました。

◽️ざっくり本の概要

メモを取る理由

著者がメモを取る理由は、「記録するため」ではなく「知的生産」のためだそうです。
筆者がオススメする方式のメモをとることによって、アイデアを生み出せるようになったり、いつもは素通りしてしまう情報をキャッチできたり、話の骨組みがよくわかるようになったり、曖昧な感覚や概念を言葉にできるようになります。

メモの取り方

じゃあどんな風にメモを取るかというと、「ファクト→抽象化→転用」というフレームワークを使ったり、「日付・サマリー・標語」を書いたり、4色ボールペンを使い分けたりします。

とったメモで思考を深める方法

便利なフレームワークでメモをとったあとは、そのメモで思考を深めていきます。
例えば、「このお店すごく居心地がよかったな(ファクト)」と思ったら、感想で終わらずにどうして居心地がよかったのか書き出しておきます(抽象化)。するとその経験が、居心地のいい別のコミュニティを作る際にうまく応用できたりするそうです。

メモで自分探し

このメモは、自分探しにも応用できます。「自分」とはどういう人なのか、人生でやりたいことはなんなのかなど列挙していきます。
3章に渡って自分が本当にやりたいことを探っていく方法が書かれているのですが、この章が、本書で「メモで人生が変わる」と言われている所以です。

◽️エンジニアの勉強で応用できそうだなと思ったこと

仕事に直接関係ない、よくわからなかった単語をとりあえずメモしておく

自分の心に刺さった語彙、引っかかる表現があったら、なるべくすべて、メモしておきましょう。

本書では、「何気なくメモしたことが自身の表現を豊かにする肥やしになる」とありました。このことを普段の仕事に応用してみると、例えば違う職種の方が呟いていたこと、全然ついていけなかった(直接仕事に関係ない)技術トークで出てきた単語などなど、そういうことをメモして、時間ができたときに深掘りしてみると良さそうだと思いました。

例えば、先日「抽象構文木」という単語をメモしていました。仕事で使わないし、そのときはよくわからなかったのですが、調べてみると基本情報の問題で解いたことあったし、言語を作るときに必要であることがわかりました。全く別の日に新しく本を読み進めていたら、まさに「抽象構文木」の話が出てきてびっくりしました。こんな感じで、一見関係なさそうな単語でもとりあえずメモしておくと別の場所で出会ったときに便利だなと思いました。

ファクトを個人開発のアイデアに繋げてみる

通常のメモであれば、ここまでに聞いた「ファクト」を書くだけで終わりでしょう。
〜中略〜
「ここで書いた具体的な情報を受けて、何か言えることはないか。そこに気づきはないか。他に応用可能な法則はないか。」
こうした思考作業を僕は「抽象化」と呼んでいますが...

今日私は、ホットクックの購入を検討していました。ホットクックを買ってもあんまり使わなくなるのが怖くて、「自分でレシピを応用できるのか」気になっていました。すると、「ホットクック部」なるものがあることを知りました。ホットクック専用のクックパッドみたいなサービスです。この本を読むまでは、「へー便利だなー」だけで終わってたんですけど、「他に応用可能な法則はないか」考えてみたときに、現在私が開発している個人プロダクトに応用できそうだと思いました。

「一調理器のためにレシピを投稿するのは面倒だと思うけど、どうしてみんなわざわざ会員登録して自分のレシピを投稿するんだろう...」という疑問が湧いてきました。買って使ってみるまでまだ調査はできませんが、レシピをわざわざ投稿したくなる仕掛けがあって、私たちのサービスの口コミ投稿を増やしたい課題にも参考にできるんじゃないかと思いました。

技術書は「構造を読む」

例えば僕は、人より早く本を読むことができます。それは、「本の具体ではなく、抽象を読んでいるから」です。個別具体のエピソードではなくて、「抽象レベルでは何を言っているか」という観点で読む。構造を読む、ということです。

技術書って、自己啓発本とは違って読むのに本当に体力がいりますよね。読んでてわからないところがあると、挫折してしまいがちです。でも、この「構造を読む」というのはとてもいいやり方だと思いました。例えば、「アンダースタンディングコンピューテーション」という難しい本を読むことにしたとします。

1章1章の話は難しくても、「はじめに」と「対象読者」を注意深く読むと、この本は、「計算とは何か」という問いに対して、難しい数学の知識を利用をせず、Rubyを使って実際にプログラムを作りながら解説してくれる本なんだな、 ということだけはまずわかります。

次に目次を眺めると、1章では「Rubyの構文についておさらいするんだな...」 2章では「意味を記述する様々な方法を調べることで、おもちゃレベルのプログラミング言語を設計するんだな...」と大枠だけ理解することができます。実際にプログラムを作りながら理解して読まないといけないと思うとしんどいですが、まず章ごとの要約をしてからより細かいところを読んで手を動かしていくのもアリだと思いました。

読みたい本や資格はとりあえずメモしておく

この本では、人生で本当にやりたいことを見つけるために、なんでもいいからやってみたいことを列挙して優先順位をつけてみる章があります。
私も、とりあえず気になった本や資格は、読む/読まない・取る/取らないに関わらずTrelloにメモしておこうと思いました。

まとめ

やっぱり普段とは違うジャンルの本を読んでみると、仕事や勉強に応用できそうな新しい発見があって面白かったです。
ぶっちゃけノートに愚直にメモを取ることは私にはできなさそうなので、Trelloなどを活用してメモを取っていこうかなと思いました。

ここまでお読みいただきありがとうございました!

Rubyの多重代入でハマって、抽象構文木の出力の仕方が学べた話

最近ハマったのでメモです。

困ったこと

まずは以下のコードをご覧ください。

class HogeHogeService
  def self.call(*a, **k)
    new(*a, **k).tap { |s| s.call }
  end

  def initialize(a_code:, b_code:, c_code:)
    @a_code = a_code,
    @b_code = b_code,
    @c_code = c_code
  end

  attr_reader :a_code, :b_code, :c_code

  def call
    p a_code
  end
end

HogeHogeService.call(a_code: 'a', b_code: 'b', c_code: 'c')
    # => 期待する値: "a"なのに、なぜか["a", "b", "c"]になる

a_codeを参照したとき、"a"だけ出て欲しいのになぜか身に覚えのない配列が表示されて困りました...。





















答え

class HogeHogeService
  def self.call(*a, **k)
    new(*a, **k).tap { |s| s.call }
  end

  def initialize(a_code:, b_code:, c_code:)
    @a_code = a_code  # <=ここにカンマがついていたから!
    @b_code = b_code # <=ここにカンマがついていたから!
    @c_code = c_code
  end

  attr_reader :a_code, :b_code, :c_code

  def call
    p a_code
  end
end

# => "a"
HogeHogeService.call(a_code: 'a', b_code: 'b', c_code: 'c')

Rubyって、こんな風にカンマをつけて変数を定義すると、配列として解釈してくれるんですね。
多重代入の1種だそうです。
docs.ruby-lang.org

a_code = 'a', 'b', 'c'

 # ["a", "b", "c"]
p a_code


今回のコードでも同じパターンの多重代入が行われていました。

a_code = 'a',
b_code = 'b',
c_code = 'c'

# ...!?  b_codeとc_codeの出力どういうことなの...
p a_code #=> ["a", "b", "c"]
p b_code #=>"b"
p c_code #=>"c"

会社の方に教えていただいたのですが、AST(抽象構文木)によると、代入式の左辺にカンマがなく右辺にカンマがある場合、右辺は配列として解釈されるそうです。
RubyのソースのASTを見る方法 - Qiita


全然読めません👼が、@ NODE_ARRAY (line: 1, code_range: (1,9)-(1,40)) って書いてありますね!

❯ ruby -e "a_code = 'a', b_code = 'b', c_code = 'c'" --dump=parsetree
###########################################################
## Do NOT use this node dump for any purpose other than  ##
## debug and research.  Compatibility is not guaranteed. ##
###########################################################
# @ NODE_SCOPE (line: 1, code_range: (1,0)-(1,40))
# +- nd_tbl: :a_code,:b_code,:c_code
# +- nd_args:
# |   (null node)
# +- nd_body:
#     @ NODE_PRELUDE (line: 1, code_range: (1,0)-(1,40))
#     +- nd_head:
#     |   (null node)
#     +- nd_body:
#     |   @ NODE_DASGN_CURR (line: 1, code_range: (1,0)-(1,40))
#     |   +- nd_vid: :a_code
#     |   +- nd_value:
#     |       @ NODE_ARRAY (line: 1, code_range: (1,9)-(1,40))
#     |       +- nd_alen: 3
#     |       +- nd_head:
#     |       |   @ NODE_STR (line: 1, code_range: (1,9)-(1,12))
#     |       |   +- nd_lit: "a"
#     |       +- nd_head:
#     |       |   @ NODE_DASGN_CURR (line: 1, code_range: (1,14)-(1,26))
#     |       |   +- nd_vid: :b_code
#     |       |   +- nd_value:
#     |       |       @ NODE_STR (line: 1, code_range: (1,23)-(1,26))
#     |       |       +- nd_lit: "b"
#     |       +- nd_head:
#     |       |   @ NODE_DASGN_CURR (line: 1, code_range: (1,28)-(1,40))
#     |       |   +- nd_vid: :c_code
#     |       |   +- nd_value:
#     |       |       @ NODE_STR (line: 1, code_range: (1,37)-(1,40))
#     |       |       +- nd_lit: "c"
#     |       +- nd_next:
#     |           (null node)
#     +- nd_compile_option:
#         +- coverage_enabled: false

上記は読めなかったので、rprという抽象構文木を画像にしてくれるgemを使ってみました。

hoge.rb(ファイル名は任意)に解析したいコードを書いて、同じディレクトリ上で以下を実行します。

sudo gem install rpr
rpr hoge.rb -f dot | dot -Tpng -oast.png
open ast.png


これなら読みやすいですね!ちゃんとarrayとして解釈してることもわかりました☺️
f:id:kattyan53:20210425143654p:plain

Rubyの多重代入は奥が深いこと、抽象構文木についても触れることができた良い機会になりました。以上です!

イラストでわかる DockerとKubernetes

イラストでわかる DockerとKubernetesを読みました。
f:id:kattyan53:20210322140440p:plain

gihyo.jp

なぜ読んだのか

私は、Dockerの使い方はなんとなくわかりますが、仕組みについて全然知りません。kubernetesに関しては、何をやっているのかもよくわかりません。弊社SREさんに、この本をおすすめしていただいたので、読むことにしました!仕組みを知るにはどうやら、”コンテナ技術”というところに注目する必要があるようです。

対象読者

  • コンテナ技術に始めて触れる方
  • DockerとKubernetesの基本的な機能の概要を、コンテナの仕組みをふまえつつ とらえられるようになりたい方

この本で学べること

  • コンテナ技術の概要
  • Dockerとkubernetesの持つ基本的な機能
  • コンテナランタイム(コンテナ技術における最も基礎的なソフトウェア。「コンテナを作り出し管理すること」という役割がある)について

本の概要

第1章 コンテナ技術の概要

第1章では、「コンテナ技術」の概要について書かれています。

コンテナ技術とはその名から想像されるとおり、1つの共有されたOS上(ホストOS)で複数の独立したアプリケーションの実行環境を作成する技術です。

DockerとKubernetesはどちらも”コンテナ”に関するツールです。
Dockerは単一マシン上でコンテナ群を管理・コンテナイメージの作成・共有などに関するツールで、Kubernetesは、複数のマシンで構成される環境でのコンテナ管理に用いられるツールです。

コンテナには、

  • 軽量な実行環境
  • 高いポータビリティ(どんな環境でも同じように動く、コマンドなどの使い方が一緒)
  • 巨大なエコシステム(OSS化されており、バックにちゃんとした組織がある)

という利点があります。詳しくは本書をご覧ください。

第2章 Dockerの概要

2章では、Dockerのコンテナへの基本的な操作である「Build、Ship、Run」について、そしてコンテナのレイヤ構造・について書かれています。

Dockerは、単一のマシン上でのコンテナ群の管理や、コンテナイメージの作成、そしてそのイメージのチーム・組織間での共有など、コンテナにまつわる基本的なワークフローをサポートするツールです。

Build ... コンテナイメージの作成
Rub ... コンテナの実行
Ship ... レジストリを用いたコンテナの配布

一番最後には、Dockerのアーキテクチャの概要と、Dockerがコンテナの実行環境を作成するために用いる低レベルなコンテナランタイムである「OCIランタイム」の概要について述べられていましたが、私には難しかったです。笑

第3章 Kubernetesの概要

第3章では、Kubernetes の特徴、kubectlについて、基本的な機能について述べられています。

Kubernetes は、複数のマシンで構成される環境でのコンテナ管理に用いられる、「オーケストレーションエンジン」と呼ばれるツールです。

これもKubernetes 初学者の私には難しかったので、出てきた単語を出来るだけまとめます。

Kubernetesはステートレス/ステートフル/バッチ処理などの様々なデプロイ方針に対応できる」
ステートレス ... 書き込まれたデータをその終了とともに破棄し、それ自体に永続的なデータや長期的な状態を持たせない方針のこと。
ステートフル ... たとえばデータベースなどコンテナ自身の寿命よりも長期的な状態やデータを管理するアプケーションを実行すること。

クラスタ ... コンテナ群を実行するマシンの集合
ノード ... 各コンテナが実行されるマシン
ノードコンポーネント ... そのノード上のコンテナ群の実行管理やイメージの管理、通信の管理などを行う。Dockerなどのコンテナランタイムも含まれている。
コントロールプレーン ... Kubernetesクラスタ全体の管理を担うコンポーネント
リソース ... クラスタ全体の管理情報

Pod ... Kubernetes におけるもっとも基本的なデプロイ単位。複数のコンテナ群を一つにまとめたもの。
ラベル ... クラスタ上で稼働するPod群をグルーピングして扱えるようにしたもの

「Pod群をクラスタ上に配置するためにKubernetesがサポートする機能のうち基本的な6つのリソース」
Deployment ... Pod群を一定数維持しながらクラスタ上に展開するリソース。
StatefulSet ... ステートフルなPod管理に有用なリソース。ノード故障やスケールインによりPodが終了し、その後そのPodを再実行する場合にも、終了前の状態を引き継ぐように動作させることが可能。
DaemonSet ... ノード上でのログ収集やモニタリングなど、アプリケーションによってはノードと密接に関係し、各ノード上でいわゆるデーモンプロセスのように1台ずつ稼動させるのが適するデプロイで使われるリソース。(難)
JobとCronJob ... Podをジョブ的に単発に実行するときに有用なJob。
ConfigMapとSecret ... Podとして実行されるアプリケーションとその実行時に必要となる設定項目・秘匿情報とを独立に管理できるようにするリソース
Service ... Kubernetesクラスタ上でPod群へのサービスディスカバリを行う上で重要なリソースの1つ。Serviceを用いることで、あるサービスを提供する複数のPodに共通のIPアドレスを付与し、まさに1つの「サービス」のようにアクセスできるようになる。

コンテナランタイムとコンテナの標準仕様の概要

DockerやKubernetes上でコンテナを実行するとき、コンテナはどんなソフトウェアがどのようにして作り出しているのでしょうか。──その役割を担っているのは「コンテナランタイム」というソフトウェアです。コンテナランタイムは、Kubernetesのような上位のオーケストレータから指示を受け、マシン上でPodやコンテナの作成・管理を担います。

この文章しかわかりませんでした。笑

まとめ

Dockerは普段から使っているので、仕組みがわかってよかったです。
Kubernetesに関しては、その特徴やkubectl、いろんなデプロイ方法に対応できることがわかりました。何より、よく使われている用語が一気に学べてよかったです。
コンテナの話に関しては全体的に、私には難しすぎました。複雑なデプロイ環境を自分で作ったことがないので、「こんなデプロイ方法に対応してるんだよ!」と言われてもあんまりピンときませんでした。本が悪いわけではありません!!

この本は、「コンテナの仕組みをふまえつつDockerやKubernetesの仕組みを知りたい方」向けの本だったので、まずはDockerとKubernetesの使い方を別の本で学んで、自分でデプロイ環境を作ってみてから「なるほど、こういう仕組みで動いていたのかー」と納得できる本なのかなぁと思います。インフラの勉強の道のりはまだまだ長いです!!

gihyo.jp

ここまでお読みいただきありがとうございました!

「学びを結果に変える アウトプット大全」を読みました。

f:id:kattyan53:20210417203505p:plain
先日DMMブックスで100冊まで70%OFFセールをやっていましたね。
そのときに、ランキングをみて気になった本を爆買いしました。

そのうちの1冊が、この「アウトプット大全」です。

CHAPTER 1 アウトプットの基本法

この章は、アウトプットって何するの?その効果とは?ということが書いてあります。

インプットとは、読む・聞くのことで、アウトプットとは、書く・話すことです。
黄金比率はインプット:アウトプット=3:7がよいとされているそうです。

CHAPTER 2 科学に裏付けられた、伝わる話し方

人に話すことは、アウトプットです。この章では、人に話すときにどんな話し方をするのがいいアウトプットなのか書かれています。「ポジティブなことを話す」「挨拶をする」など一見アウトプットに関係なさそうな話が書いてありましたが、内容は仕事で応用できそうな大切なことがたくさん書かれていました。

CHAPTER 3 能力を最大限に引き出す書き方

書くこともアウトプットです。アウトプットする小道具や、ノートの書き方、まとめるときの考え方などが書いてあります。
私は職業柄パソコンを使いがちですが、記憶を定着させるには手書きの方がいいそうです。最近はリモート勤務が多いので難しいのですが、わかりやすい説明をする訓練に、絵で説明する訓練を自分の手元だけでもやってみるといいのかなと思いました。

CHAPTER 4 圧倒的に結果を出す人の行動力

この章では、時間の使い方・物事の考え方・感情に対する対処法についての話が多かったです。

繰り返し出てきたのは、「ちょっと難しいこと」をやることです。確かに、モンハンでも超絶余裕なクエストよりも、装飾品や食事、武器などをちゃんと考えないと倒せないようなちょっと難しいクエストの方が楽しいんですよね。仕事でも、フロントエンドのタスクよりも、書き慣れているRailsのちょっと難しいタスクの方が楽しいです。「ちょっと難しいこと」って、物事を継続する上で大切な要素なんだなと思いました。

他にも、どうやったらアウトプットのやる気を継続させることができるのか書かれていました。

CHAPTER 5 アウトプット力を高める7つのトレーニング法

タイトルの通り、アウトプット力を高めるためのトレーニンについて書かれています。日記を書いたり、本の感想を書こう、誰々に発信しよう、というようなことが書かれています。

個人的感想

本全体、話の一つ一つがコラムのようになっているので、1時間くらいで読めました。
「アウトプットは大事」というのは頭ではわかっていても、どうして大事なのか、効率的な方法がここまでたくさんまとまった本というのはなかなかないと思います。誰が読んでも10個くらいは新しい気づきのある本だと思いました。

私は例えば試験勉強をするとき、インプット多めの勉強をしてしまいがちです。この本にある通り、「ちゃんと問題を解いたり、ブログでアウトプットしないとなー」と思いつつ、なかなかやる気が出ないんですよね。

しかしながら、この本を読んで「なぜアウトプットするのかいいのか?」理解し、何と言ってもやる気が出てきました。
まずは二つ、「技術書を読んでブログにアウトプットする」「早寝早起きをしてアウトプットする時間を作る」というのをやっていこうと思います!

初めてのGraphQL を読んだ

初めてのGraphQLを読みました。(どうでもいいけど、本当は去年の12月くらいに読んでメモブログを書いていなかったので投稿。)

初めてのGraphQL ―Webサービスを作って学ぶ新世代API

初めてのGraphQL ―Webサービスを作って学ぶ新世代API

なぜ読んだのか

  • 仕事でGraphQLとApolloを使うことになり、この二つを包括的に学ぶのに良さそうな本だったから。
  • この本が日本語で書かれていたから。

対象読者

  • GraphQL初学者
  • アプリケーション開発のアーキテクチャAPI設計に興味を持ち始めた中級以上のWeb開発者
  • 初級のWeb開発者であっても、GraphQLに興味があれば役に立つ

この本で学べること

  • GraphQLの概要と歴史
  • グラフ理論について
  • GraphQLのクエリ・ミューテーション・スキーマ設計について
  • GraphQLを用いたWebサービスの実装を一通り(GprahQL サーバー/GraphQL クライアント)

本の面白かったところ

GraphQLとは

APIのための問い合わせ言語。データベースに問い合わせる為に開発されたSQLの考え方をインターネットに適用したもの。
SQLのクエリはデータベースに対して行われるが、GraphQLのクエリはAPIに対して行われる。

Railsを使うエンジニアにとって馴染みあるRESTとは違うところ

RESTの課題は以下の通り

  • 余分なデータを取得しすぎてしまう
  • N+1的なものが起きやすい
  • フロントに新しい機能が追加されると新しいエンドポイントが必要になることが多い

GraphQLなら、

  • 必要なフィールドだけを指定できる
  • 一度のリクエストで必要なデータだけ取得できる
  • 単一のエンドポイントで済む
イントロスペクション

GraphQL Playgroundで確認できる充実したGraphQLのドキュメントは、イントロスペクションを利用して実現されている。

以下のようなクエリを打つと、

query {
  __schema {
    types {
      name
      description
    }
  }
}


こんな感じでAPIスキーマを取得できる

f:id:kattyan53:20210322132848p:plain
個人開発のリポジトリで実行してみたらスキーマいっぱい出てきた

GraphQLサーバーの実装

本書ではexpress-graphqlを使用。
私はgraphql-rubyを使うので、結構読み飛ばしちゃった。
わかりやすいQiitaがあったけど、忘れちゃった...。

GraphQLクライアントの実装

様々なGraphQLクライアントがある中で、Apollo Clientについて書かれていた。
私はサーバーサイドメインになりそうだったので、一旦読み飛ばしちゃった。

Apollo Clientはキャッシュが優秀らしい...?
Apollo Clientめっちゃ難しかったので、個人開発では、もうちょっとシンプルらしいurqlっていうのを使ってみてます。
qiita.com

フロントのタスクをやりそうになったら、また読んでいこうと思います🙏

まとめ

GraphQLについて概要、歴史、文法的なところ、サーバー、クライアント...と、広く浅く、包括的に学べて良かったです!

これは会社の人から教えてもらったのですが、GraphQLサーバーとGraphQLクライアントに関しては結構情報が古かったりするそうです。
私の場合、さらっと読み流す程度にして、自分が使う予定のgraphql_hogehogeや、hogehoge clientの公式ドキュメントを読むようにしました。

初めてのGraphQL ―Webサービスを作って学ぶ新世代API

初めてのGraphQL ―Webサービスを作って学ぶ新世代API

ここまでお読みいただきありがとうございました!

デザイン入門教室[特別講義] 確かな力を身に付けられる ~学び、考え、作る授業~

今回は、「デザイン入門教室[特別講義] 確かな力を身に付けられる ~学び、考え、作る授業~」を読みました。

なぜ読んだのか

個人開発で作ったサイトのデザインをもっとよくしたいと思ったからです。

対象読者

・自分自身で何らかの紙面や資料などを制作する機会がある人
・紙面や資料で他人に何かを伝える機会がある人
・これからデザインを勉強しようとしている人
・デザイナー1年生

この本で学べること

・デザインの基本のき

本の概要

本の概要は、目次を見ていただいた方が早いです。
全体的に図がとても多く、一目見て理解できるものばかりです。

Chapter 1 - デザインをはじめる前に ~ はじめに知っておくべき最重要ポイント ~

以下二つの言葉が刺さりました。

デザインはあくまでも手段であって目的ではない。
センスより「目的を明確にする」「デザインの基本ルールに従う」方が大事。

Chapter 2 - レイアウトの基本ルール ~ 紙面イメージを決定する配置設計の基礎知識 ~

Chapter 2では、マージンの基本、グリッド、コントラスト(対比)、余白...といったことが書かれています。

Chapter 3 - 写真と画像 ~ 目的別で学ぶ、写真の選び方と使い方 ~

この章は、TOPページでどんな写真を採用するといいか非常に参考になりました。

Chapter 4 - 配色の基本 ~ 色には人の心を動かす力がある ~

題名の通り、それぞれの色のもつ印象や、色の相性、大きく見える・小さく見えるなど目から鱗の情報ばかり載っていました。
サイトの配色はなにがベストかよくわからないので、ターゲット層を元にどんな印象を持ってもらいたいかでまた改めて考え直してみようと思いました。

Chapter 5 - 文字と書体 ~ 読みやすく、人を惹きつける文字と書体の使い方 ~

逆にタイポグラフィなどについては書かれていません。
フォントだけでとても感じ方が異なることを知れたのが印象的でした。

Chapter 6 - 文章のデザイン ~ 読みやすい文章制作の基礎知識 ~
Chapter 7 - インフォグラフィック ~ 情報の図式化と、グラフ・表の作り方 ~

もうあんまり機会なくなっちゃったけど、パワーポイントで説明資料を作るときに役立ちそうでした。

Chapter 8 - 実践演習 ~ 頭の中のイメージを具体化するデザイン実技 ~

改善前のポスターを元に、デザインの改善案を考える実践演習が載ってます。
私は読み流しただけにしましたが、どんなことをテーマとするか、改善後のポイントまで丁寧に載ってました。

まとめ

読みやすい本だった

主なページ構成としては、最初に少しポイントだけ述べて、図や写真がたくさん載っています。
そのため、非常にわかりやすかったです。

紙で読むのがおすすめ

普段はkindleで本を読むことが多いですが、配色についても触れられているため、紙の本を買ってみましたが大正解でした。印刷が綺麗で、読みやすい構成になっているので、紙の本がおすすめです。

目的を明確にする

最初の章であった”センスより「目的を明確にする」「デザインの基本ルールに従う」方が大事”という言葉がとても心に残りました。なんとなく綺麗にしたい、ではなくて「このページではなにを強調したいのか?」「どんな印象を持ってもらいたいのか?」など、まずユーザーにどう思ってもらいたいのか考えると、この本のどこを参考にしたらいいのかわかって有効活用できると思いました。


非デザイナーの方は、家に一冊置いておくと絶対便利だと思います。
ここまで読んでいただきありがとうございました!

RubyでEnum, sort_by, find_indexを使った複数条件下のソート

お仕事で、以下のようなソートを実装する機会がありました。

例として教科書を題材にします。

Text model

教科書は、教科コード、4種類のとあるタイプと、応用/基礎の情報を持っています。

class Text

  enum type: {
    a_type: 'a_type',
    b_type: 'b_type',
    c_type: 'c_type',
  }

  enum subject: { japanese: 'japanese', math: 'math', english: 'english'}

  # 基礎/応用はfalse/trueで表現しています
...
end

仕様

これから実装するのは以下の仕様です。

  • 最初に教科でソートする。
  • 同じ教科の中でtypeごとにソート
  • それでも一緒なら「基礎/応用」でソートする

例えば、
```
{subject: 'english', type: 'c_type', support_advanced: true},
{subject: 'english', type: 'a_type', support_advanced: true},
{subject: 'english', type: 'b_type', support_advanced: true},
{subject: 'english', type: 'b_type', support_advanced: false},
{subject: 'math', type: 'c_type', support_advanced: true},
{subject: 'japanese', type: 'b_type', support_advanced: false},
{subject: 'english', type: 'c_type', support_advanced: true},
```

みたいなデータがきたら、
```
{subject: 'english', type: 'a_type', support_advanced: true},
{subject: 'english', type: 'b_type', support_advanced: true},
{subject: 'english', type: 'b_type', support_advanced: false},
{subject: 'english', type: 'c_type', support_advanced: true},
{subject: 'english', type: 'c_type', support_advanced: false},
{subject: 'math', type: 'c_type', support_advanced: true},
{subject: 'japanese', type: 'b_type', support_advanced: false},

```
みたいにしたいです。

困りポイント

  • enumvalueが数値じゃないので困った...。

結論

こうやって書きます。

  subjects = %w[english, math, japanese]
  types = %w[a_type, b_type, c_type]
  sort_support_advanced = [true, false]

    texts.sort_by do |text|
      [
        subjects.find_index { |subject| text.subject == subject },
        types.find_index { |type| text.type == type },
        sort_support_advanced.find_index { |support_advanced| text.support_advanced == support_advanced }
      ]
    end

解説

配列の番号で順番を指定できます。

find_indexは条件に一致する最初の要素の位置を返します。

  subjects = %w[english, math, japanese]
  types = %w[a_type, b_type, c_type]
  sort_support_advanced = [true, false]

そしてsort_by に、配列のindex(位置情報)を渡してあげると、配列で並べた通りに並べ替えてくれます。

    texts.sort_by do |text|
      [subjects.find_index { |subject| text.subject == subject } ]
    end

ソートした中でさらに別の条件でソートしたい場合、以下のように書くと上から順に並び替えてくれます。

    texts.sort_by do |text|
      [
        subjects.find_index { |subject| text.subject == subject },
        types.find_index { |type| text.type == type },
        sort_support_advanced.find_index { |support_advanced| text.support_advanced == support_advanced }
      ]
    end


以上です。