MogLog

メモというか日記というか備忘録というか

今更ながらベイマックスを見たら脳が震えた

中身のない日記です。

AmazonKindle本50%OFFセールがやっていたので適当に気になった本を数冊買ったところ、Amazonビデオの割引クーポンが送られてきたのでベイマックスを見ることにした。 うーん、めちゃくちゃおもしろかった。最高。 (何がおもしろかったか・どうおもしろかったかを伝えるのは苦手なので小学生並みの感想まで)

小学生時代にディズニーやジブリのビデオを擦り切れるほど見てきたマンとしては、ベイマックスがもし小学生時代にあったら50回くらいは見ていたんじゃなかろうか。という感じ。 若干ネタバレになるが、「辛いことが起こる → なんやかんやある → ハッピーエンド」という王道展開が大好物なんだ。

小学生時代に刺さった作品は、「もののけ姫」、「ビアンカの大冒険」、「ジャングルブック」、「トイ・ストーリー(初代)」とかだったなぁ。 大学生以降は、若干毛色が違うアニメだけど「Steins;Gate」とか。ほとんどは王道ハッピーエンド展開。単細胞です。

アナと雪の女王」、「ズートピア」とか少し前に話題になったディズニー作品もまだ見ていないので、見てみたいという気持ちが高まった。

といった感じでベイマックスはすごく良かったのでまだ見ていない人は見てみてはどうだろうか。

LPICレベル1 合格体験記

LPICレベル1を受験し、無事に合格できたので感想やら何やらを書いていく。

受験の動機

ことのはじまりはSREに興味があって、SREにどんな技術セットが求められるかを調べたりしていたところLinuxの深い知識を求められる傾向があると気づいたことだった。

また、Linuxは業務で何年か使っているのだけど、必要に応じて書籍やインターネットで調べたりするくらいしかしていなかったので体系的に学び直したいとはそれ以前からも思っていた。

Linuxの書籍は探せばたくさんあるのでそれらを読んで学習する形でも良かったかもしれないが、スキルを証明するものが 欲しいなと思ってLPICというLinuxの資格試験を受けることに決めた(単に資格が欲しいという感情と、資格以外の形でLinuxのスキルを第三者に証明するのは難しいなという気持ちの両方があった)。

勉強期間

最初に軽く問題を解いてみたところ、結構わからないところが多かったので3ヶ月間かけることにした。 LPICは試験日を自由に決められるので、予め試験日の予約までしてしまいそれまで頑張るスタイルにした。

ちなみにLPICレベル1は受験費用が30000円もかかり、受験を申し込む段階で絶対に落ちたくないという気持ちを高めてくれます^^

勉強方法

休日といえど受験生のときのように1日に何時間もやるのは無理そうだったので(気持ち的に)、毎日コツコツ時間を作るようにした。 出勤時の電車の中での30分と、仕事の終わりにカフェで30分 ~ 90分程度時間を取った。

やることとしては問題集を解くのがメインだったが、コマンドなど実際に手を動かさないと覚えにくいものはできるだけ手を動かすようにした。

またあまり良くない学習方法とは感じつつ、モチベーションを保つために色んな書籍を買ってしまった。

最初はこの問題集をやり…

Linux教科書 LPICレベル1 スピードマスター問題集 Version4.0対応

Linux教科書 LPICレベル1 スピードマスター問題集 Version4.0対応

次にこの問題集をやり…

(PDF版付)徹底攻略LPIC Level1問題集[Version 4.0]対応

(PDF版付)徹底攻略LPIC Level1問題集[Version 4.0]対応

最後にはこの教科書を読み直した。

Linux教科書 LPICレベル1 Version4.0対応

Linux教科書 LPICレベル1 Version4.0対応

一応、それぞれ2周はした。

合格してみての所感

かなりタメになったと思う。

個人的にLPICで良かったと思うのは、長く使えるであろう知識と実務ですぐに役立つ知識の両方が試験内容に含まれているところ。

コマンドのオプションをちゃんと覚えていないと答えられないような問題もあり、最初は「そんなのコマンド使うときにhelpやmanを見ればいいだろ」とか思っていたし、オプションを覚えるのはなかなかに辛かった。しかし、ちゃんと覚えておくと使いたいときに即座に使えるし、覚えていない他のオプションも見てみようという気にもなるしでいいこともあった。 こういう勉強の過程でmanを読む癖がついたのも良かった点だと思っている。

また最初の動機にも書いたがLinuxを体系的に学べたような気はしていて、同じようなことを考えている人にはオススメできる。

3ヶ月間というのは正直時間を取りすぎたような気がしているが、その分点数はちゃんと取れて、やりきった感を得られたので良しとしたい。

『Web開発者のための大規模サービス技術入門』がめっちゃ良かった

『Web開発者のための大規模サービス技術入門』を読んだ。とても勉強になった。

特に興味深く読めたのは次の部分。

  • ハードウェアレベルの話(第2回)
  • OS(Linux)のキャッシュまわりの話(第3回)
  • DBのスケールアウト戦略の話(第4回)
  • アルゴリズムの話(第7回)

その中でもアルゴリズムの話が一番収穫があった。 正直苦手意識がある分野だったのでこれまで避けがちだったが、Webアプリケーションを題材にして具体的な事例や効果が合わせて書かれていたので、楽しんで読むことができた。

次のステップとして、以下の文を引用。

大規模なWebアプリケーションを運用開発しようとすると、この理論と実践、その両方をやらなくてはいけない。

この辺をバランス良くやっていくのは、はてなのような会社に求められている技術的要件です。どちらか一方ではダメです。

理論を追求していって論文を書けるくらいの知識を持っていても、いざ実装しようとすると、実装のために必要ないろいろなバッドノウハウが出てきますし、一方でたとえバッドノウハウだけ知ってても、大規模なデータを目の前に出されたときに「どう処理していいかわからない」ということになってしまう。 ですから、両方をバランス良く使えるようにならないといけません。

※ p.115 より引用

本書を読んだ段階ではまだ理論を学んだだけで実践まで到達していないので、ここから何らかの方法で実践につなげて引き出しを増やしていきたい。

復習用読書ログ

以下は、自分の復習用に作った読書ログ。
「これは覚えておきたい」と思ったことを中心にまとめている。

第2回:大規模データ処理入門

  • 大規模データの難しい点を端的に言うと「メモリ内で計算できない」こと。メモリ内で計算できれば力技でやっても計算はそこそこ速く返ってくる。
  • メモリとディスクの速度差は約10万~100万倍 → メモリの方が圧倒的に速い
  • メモリは電気的な部品であるため、探索速度に物理的構造は関係ない
  • ディスクはなぜ遅いか
    • 「ヘッドの移動」と「円盤の回転」という2つの物理的な移動が必要になるため
    • さらに、もしデータがディスク上にバラバラに配置されている場合はもっと遅くなる
  • ディスクの遅さに対するOSレベルの工夫
    • OSは連続したデータを同じようなところに固める
    • データを取得するときは1byteずつ読み取るのではなく4KBくらいをまとめて読み出す
    • → このようにしてディスクの回転を少なくし、処理速度を上げている
  • 転送速度、バスの速度差
    • メモリにしてもディスクにしてもCPUとバスでつながっている。このバスの速度にもかなりの差がある
    • メモリ:7.5GB/sec
    • ディスク:58MB/sec
    • hdparmというLinuxのツール(コマンド)で転送速度を測定できる
  • Webアプリケーションの3層構造:Proxyサーバ - APサーバ - DBサーバ
  • CPUバウンドなサーバのスケーリングは簡単 → 同じ構成のサーバを増やしてロードバランサで分散する
  • I/Oバウンドなサーバのスケーリングは難しい
  • 大規模データを扱うための勘所
    • いかにしてメモリで済ませるかを考える
      • ディスクのシーク回数の最小化
      • 局所性を活かした分散
    • データ量の増加に強いアルゴリズム、データ構造を使う
      • 例:線形探索の計算量はO(n)だが、二分探索はO(log n)
    • データ圧縮、情報検索技術を有効活用する

第3回:OSのキャッシュと分散

  • OSにはキャッシュ機構がある。Linuxではページキャッシュ等と呼ばれる
  • このLinuxのページキャッシュの特性は知っておくべき
  • 仮想メモリ機構
    • OSは仮想メモリ機構を持っている
    • 仮想メモリ機構は、論理的なリニアアドレスを物理的な物理アドレスへ変換する働きをする
    • OSはメモリを直接プロセスに渡さず、カーネルの中でメモリを抽象化して管理する。これには様々な利点がある。
    • ページ:OSが物理メモリを確保・管理する単位
  • プロセスがディスクからデータを読み出す流れ
    • ① OSがディスクから4KBのブロックを読み出す
    • ② 読み出したデータをメモリに置く(プロセスは直接ディスクにアクセスできないため、このステップが必要)
    • ③ OSはメモリの番地をプロセスに教える
    • ④ プロセスがメモリからデータを読み出す
  • ページキャッシュ
    • Linuxではディスクにデータを読みにいくと必ず1回メモリに置いて、それが必ずキャッシュされる。したがって、2回目以降のアクセスが高速になる
    • ページ = 仮想メモリの最小単位
  • LRU
    • メモリの余裕が1.5GBあって、4GBのファイルを全部読んだらどうなるか
    • LRU(Least Recently Used):一番古いものを破棄して一番新しいものを残す
    • → LRUの仕組みを使うので、最近読んだところがキャッシュに乗って、昔読んだ古い部分は破棄される
  • I/O軽減策は、OSのキャッシュを前提にI/Oの軽減を図るのが効果的
  • I/O対策のポイント
    • ① 扱うデータのサイズに注目する。データ規模に対して物理メモリの方が大きければ全てキャッシュできる
    • ② 経済的コストとのバランスを考慮する。ハードウェア側(メモリ量)で頑張るべきか、ソフトウェア側で頑張るべきか?
  • データがキャッシュに乗り切らない規模になったらどうするか?
    • ここで初めて複数サーバにスケールさせるという考え方が浮かんでくる
    • DBサーバを増やしたいときというのは、負荷軽減というよりもキャッシュの容量を増やしたい、あるいは効率を上げたいというときのほうが多い
    • ただし、単純に台数を増やしただけではキャッシュできない割合が変わらないのでほぼ意味がない
  • 局所性を考慮して分散する
    • アクセスパターンを考慮して分散させることでキャッシュを最大限利用する
    • はてブの例:人気エントリーのページを表示する場合はDB1へ、個人のブックマークのページを表示する場合はDB2へ、というように振り分ける
  • パーティショニング
    • パーティショニング:1つのDBを複数のサーバに分割する手法のこと
    • 局所性を考慮した分散を実現するためには、このパーティショニングがよく使われる
    • テーブル単位での分割や、データの途中での分割など
    • → DBが分割されることで、アプリケーション側で参照先の振り分け処理が必要になる(が、修正コストは小さい)

第4回:DBのスケールアウト戦略

  • アプリケーションを書く人が分散されたシステムを前提に書くときに何に気をつける必要があるか
  • 分散を考慮したMySQL運用のポイント
    • ① OSのキャッシュを活かす
    • ② インデックスを適切に設定する
    • ③ スケーリングを前提とした設計をする
  • OSのキャッシュを活かす
    • 全データサイズに気を配る。データ量 < 物理メモリとなるようにする
    • スキーマ設計がデータサイズに与える影響を考慮する
  • インデックス重要
    • アルゴリズム・データ構造において、探索のときには広くツリー(探索木)がよく使われる
    • MySQLのインデックスは、B+木(ビープラスツリー)というデータ構造が基本(B+木はB木(ビーツリー)から派生したデータ構造)
    • 探索ロジック:まず根から自分の探している値が格納されていることを確認する → 無ければ子を辿る(どの子を辿るべきかは一意に決まる) → 最終的に木の高さ分の回数しか子を辿らない(そのため、高速な検索ができる)
    • B木の場合、各ノードの大きさを任意に設定できる。ここで、Linuxの1ページのサイズにノードの大きさを合わせることで、ディスクのシーク回数を最小化し、探索速度を高速化できる
    • B+木は、各ノードの中では子へのポインタしか持っていなくて、ポインタ以外のデータとしての実際の値は一番最後の葉(リーフ)にしか持たせない構造になっている
    • → とりあえず、B+木はDBにデータを保存するのにB木よりもさらに最適化されたデータ構造である、という点は抑えておく
    • インデックスの効果例:4000万件のtagテーブルから検索
      • インデックス無し(=線形探索)→ O(n)なので、最大4000万回の探索
      • インデックスあり(=B木で二分探索)→ O(log n)なので、最大25.25回の探索
      • ※ 計算量だけでなく、ディスク構造も最適化されるため、ディスクシーク回数も改善される
    • MySQLにおいて、基本的にインデックスが使われるのはwhereorder bygroup byの条件に指定されたカラム
    • MySQLにおいて、インデックスとして作用するのは「明示的に追加したindex」、「プライマリキー」、「UNIQUE制約」
    • MySQLにおいて、複数のカラムに同時にインデックスを効かせたい場合は複合インデックスを使わなければならない
    • インデックスが期待通りに動いているかの確認にはexplainコマンドを使う
  • MySQLの分散 スケーリング前提のシステム設計
    • MySQLレプリケーション機能:マスタに書き込まれた内容をスレーブがポーリングして自身に反映させ、マスタのレプリカとなる。これにより同じ内容のサーバを複数用意することができる
    • 更新クエリはマスタへ、参照クエリはスレーブへ流すようにアプリケーション側で制御する。スレーブに更新クエリを流すと不整合が発生してレプリケーションは停止する。
    • スレーブへの振り分けはアプリケーション側で細かく制御することも可能だが、ロードバランサを使うと簡単に分散できる
    • 参照系はスケールさせやすいが、マスタはどうやって分散(冗長化)させるか?
      • Webアプリケーションの特性として、多くは参照系のクエリになる。そのため、マスタがボトルネックになって困るということは少ない
      • 書き込みが激しいシステムの場合、テーブルを分割する方法がある
      • 書き込みが激しいシステムの場合、そもそもRDBMSを使わないという選択肢もある。KVSの方が用途に合う場面も
    • パーティショニングを前提にした設計
      • MySQLには基本的に異なるサーバにあるテーブルをJOINする機能が無い
      • → JOINクエリは対象となるテーブルが将来にわたってサーバにまたがる分割を行わないことが保証できそうな場合のみしか使わない
      • ※ MySQL5.1系から異なるサーバにあるテーブルをJOINすることは可能(FEDERATED句)
    • パーティショニングのトレードオフ
      • [good] 負荷が下がる
      • [good] 局所性が増してキャッシュ効率が高くなる
      • [bad] 運用が難しい(複雑になる)
      • [bad] 故障率が上がる
      • ※ パーティショニングは切り札

第5回:大規模データ処理[実践]入門

  • 統計処理や検索処理といった、本質的に大量のデータにアクセスしたい(しなければならない)場合にどうするか
    • こういったケースでは、RDBMSには限界があることが多い
    • バッチ処理RDBMSからデータを抽出し、そこから別途インデックスサーバを構築し、そのインデックスサーバにWebアプリケーションからアクセスさせる
    • はてなではこれを「用途特化型インデクシング」と呼んでいる
  • 特定の目的だけに使いたいとき、その目的だけに特化してチューニングしたデータ構造を使うことで、高速な処理を実現する
  • Webアプリケーションの世界では理論と実践の両側から攻めていかなければならないことが多い
  • 課題が本質的になるにつれ、小手先のテクニックでは通用しなくなってくる。そのときに必要だったのは、新しい技術やノウハウではなく、古典的だけれども本質的な理論だった

第7回:アルゴリズムの実用化

  • 対象となるデータが大きくなればなるほど、アルゴリズムやデータ構造の選択が速度に響く
  • 線形探索
    • データ中から必要なデータを先頭から順番に見て探す
    • n件に対してn回の探索が必要 → O(n)アルゴリズム
  • 二分探索
  • 最大の探索回数は計算回数の目安となる指標で、計算量と呼ばれる
  • 比較すると・・・
    • n = 1000の場合:O(n)は最大1000回、O(log n)は10回
    • n = 100万の場合:O(n)は最大100万回、O(log n)は20回
    • n = 1000万の場合:O(n)は最大1000万回、O(log n)は24回
  • なぜアルゴリズムに対する知識が必要なのか
    • 計算機の資源は有限である
    • エンジニアの「共通言語」として
    • アルゴリズムを知っておくことで、新しい問題に対処できる可能性が広がる
  • アルゴリズムの評価には、前述のオーダー表記を使うのが一般的である
  • オーダー表記は、対象とするアルゴリズムが入力のサイズnのとき、大雑把にこのぐらいの計算量がかかる、というのを示す
  • O(1) < O(log n) < O(n) < O(n log n) < O(n2) < O(n3) ...
  • 大切なのは、オーダー表記そのものではなく、オーダー表記を使って比較されるアルゴリズムのうち、その差がどのくらいになるかといった感覚
  • データ構造とアルゴリズムがセットで論じられるのは、アルゴリズムでよく使う操作に合わせてデータ構造を選ぶ必要があるから
  • 計算量のオーダー表記では「定数項」を無視する。定数項とは、そのアルゴリズムの実装中、入力サイズには依存しないけど実行しなければならない処理の類
    • 例:関数呼び出し、一時変数の確保、if文など
  • 簡単な実装では定数項はそのアルゴリズムの計算量にほとんど影響を与えないが、複雑な実装になると定数項が無視できなくなってくる
  • ソートのアルゴリズムは理論的にはO(n log n)が下限で、平均計算量O(n log n)を達成するアルゴリズムは複数存在する。しかし、その中でも一般的にはクイックソートが最速と言われている。
    • なぜか:クイックソートはその特性上、CPUキャッシュを使いやすい利点があるため
    • → 定数項が速いという例
  • オーダー表記は比較するのには便利だが、実装込みで考えた場合それだけが全てではない

第11回:大規模データ処理を支えるサーバ・インフラ入門

第12回:スケーラビリティの確保に必要な考え方

  • APサーバは基本的にスケールが容易
    • なぜか:APサーバは状態を持たないため。リクエストごとに別のサーバに飛んでも問題が発生しない(ことがほとんど)
  • DBやファイルサーバは、分散・スケーラビリティの確保が難しい
    • その中でも、writeの分散は難しい
    • readは比較的容易
  • どのようにスケールさせていくかを検討するために、まずはサーバの負荷状態を把握する
  • 負荷を見る際にはまずロードアベレージから見る
    • ロードアベレージ:プロセスがいつでも動ける状態なのに、実際にCPUが割り当てられていなくて待ち状態にあるプロセス数の平均値
    • CPUがきれいに割り当てられていると、ロードアベレージは0に近くなる
    • CPUコア数以下であれば良い

第13回:冗長性の確保、システムの安定化

  • APサーバ
    • APサーバはスケーラビリティの考え方と同様に、台数を並べるのが基本
      • 1,2台停止しても十分処理できるような処理能力を確保する
    • サーバは様々な要因で止まる
      • 人為的ミス
      • 物理的故障
    • ロードバランサによる自動フェイルオーバ、フェイルバックでの対応
      • フェイルオーバ:壊れたサーバを自動で切り離す
      • フェイルバック:正常になったサーバを自動で復帰させる
  • DBサーバ
    • DBサーバも台数を並べて1,2台停止しても十分処理できるようにする
    • マルチマスタという手法を使い、マスタの冗長化を行う
      • マルチマスタでは双方向でのレプリケーションを行う(お互いがお互いのスレーブであるという状態になる)
      • MySQLの実装では片側に伝わるまでに遅延がある → ミリ秒単位で見るとデータが一致していない状態が常にある
      • わずかではあるがデータが一致していないタイミングで異常が発生すると同期がズレる → ここは割り切って常に動かすことを優先させている
  • ストレージサーバ
    • はてなでは、画像などのメディアファイルを保存するための分散ストレージとして、MogileFSを使っている
    • 分散ファイルシステムを使うことで、スケーラビリティと冗長性の確保が同時に実現できる
  • システム安定化
    • システムを安定化させるためにはトレードオフがいくつかある
    • 安定性と資源効率のトレードオフ
    • 安定性と速度のトレードオフ
    • マシンリソースをギリギリまで使うような設定にしない。こういう設定は予期しないデータ量の増加やバグが発生した場合に障害となる。そのため、7割程度までしか使わない、といったような余裕を持った設計にする
  • 実際の安定化対策
    • 大枠は以下の2つ
      • ① 適切なバッファの維持
      • ② 不安定要因の除去
    • バッファの維持
      • 限界の7割運用で実現
      • キャパシティの7割を超えたらサーバを追加したりメモリを増やしたりする
    • 不安定要因の除去
      • SQL負荷対策:重いSQLを発行しない。どうしても重くなるSQLは別ホストへ切り出す。など。
      • メモリリークを減らす:アプリケーションエンジニアの基本(常識)としてやってもらう
      • 異常動作時の自律制御:自動DoS判定、自動再起動、自動クエリ除去...

第14回:効率向上化作戦

  • 冗長化を進めていくと、サーバが突然ダウンしても大丈夫なようになるが、リソースの使用率は低下する
  • はてなでは、以下の方法で効率の向上を図っている
    • 仮想化技術:ホストの集積度を上げることで、サーバのリソース使用率を上げる
    • 自作サーバ:サーバの冗長な仕様を削ぎ落とし、システム全体の低コスト化を図る
  • 仮想化技術の目的
    • スケーラビリティ
    • コストパフォーマンス
    • 高可用性
  • 仮想化技術の効用
    • IPMIの代替としてのハイパーバイ
    • ハード差分の吸収(環境の抽象化)
    • 準仮想化を使用
    • リソース消費の制御
  • 仮想化サーバの構築ポリシー
    • 仮想化技術の最も基本的な目的はハードウェアの利用効率の向上
    • 空いているリソースに適したゲストOSを追加する(例:CPUリソースが空いていたらAPサーバ、I/Oリソースが空いていたらDBサーバ)
    • リソースの消費傾向が似ていて、かつ負荷の高いマシンの同居は避ける(リソースを食い合ってしまうため)
  • 仮想化によって得られたメリット
    • 物理的なリソース制約からの解放
    • ソフトウェアレベルの強力なホスト制御
    • ハードウェア・運用コストの低下
    • コストパフォーマンスの向上
    • 高可用性
  • 仮想化の注意点
    • パフォーマンス上のオーバヘッドがある
    • 仮想化技術の実装上の不具合による、不安要素の増加
  • ムーアの法則集積回路上のトランジスタ数は18ヶ月ごとに倍になる
  • SSDのアクセス性能
    • はてブでは、DBのスレーブサーバで多く使用されている
    • 良好なランダムアクセス性能。メモリほどではないが十分高速
    • メモリ > SSD > HDD RAID-0 > HDD RAID-1

『知識ゼロからの宇宙入門』を読んだ

『知識ゼロからの宇宙入門』を読んだ。

知識ゼロからの宇宙入門

知識ゼロからの宇宙入門

読みはじめた動機

突然、宇宙について知りたくなった。その理由は自分でもよくわからない。

感想

斜め読みというか、ちょっと考えたくなるような場所でも無視してどんどん読み進めたので、そんな読み方での感想を書く。

まず全体としてはタイトルの通り、ほとんど宇宙に関する知識が無くても読める本だった。

太陽、地球、月の説明からはじまり、太陽系、銀河系...と読み進めていくうちに徐々にスケールが大きくなっていく(中盤過ぎまで)。 途中、宇宙のあまりのスケールの大きさに理解が追いつかなくなった。
地球の約109倍の大きさを誇る太陽(直系 約139万2,000km)がデカさ最強の座を途中までほしいままにしていたのに、ベテルギウスという恒星はなんと太陽の900 ~ 1000倍近くも大きいというから驚きだ。さらに、そんなベテルギウスだって所詮は1つの恒星に過ぎず、星々の集まりである銀河は宇宙空間に1000億個以上あるというのだ。

ドラゴンボールに例えると、ピッコロ大魔王最強かよって思ってたらサイヤ人が出てきてナッパマジ強えーってなってるところにフリーザの戦闘力が53万と知って唖然とする感じです。

ここまでスケールがでかいと自分の小さな悩みなんて考えるだけ馬鹿らしくなりますね?

そして、こういうのを読んでいて毎回気になるのは、これらの情報はどうやって調べたんだろう、というところ。
全部がすっきりわかったわけじゃないけど、本書にもそのあたりは少し書かれている。例えば、めっちゃ遠くが見える望遠鏡を使って地上から観察する方法とか。そこから更に発展して、地上からだと大気に遮られてしまうので、宇宙に望遠鏡を持っていってそちらでより鮮明な観察をする方法とかもあるようだ。その他、様々な探査機が今も宇宙を飛んでいて、そういうところから情報を集めているらしい。NASAは偉大。

初心者目線だけど、本書は宇宙をこれから知ろうという人には優しくかつ体系的にまとめられていると思う。教科書的な側面もある。

また、感覚だけど著者が宇宙大好きなんだなっていうのが感じられてよかった。そういう本は読んでて楽しいんだよね。

もっとちゃんと知りたいと思った事柄

以下、ちゃんと仕組みや原理を理解したいと思ったもの。そのうち調べる。

  • オーロラが見える仕組み
  • 月の動き
  • 日食の仕組み
  • 月食の仕組み

読むのにかかった日数

3日

目次

chapter1 太陽と地球 月

  • 太陽系の王者 太陽
  • エネルギーの源 太陽
  • 太陽風が作るオーロラ
  • 地球 46億年の歴史
  • 命の星 地球
  • 地球に季節がある理由
  • 月にうさぎが見えるわけ
  • 自転しながら公転する月
  • 月に隠された魅力
  • 幻想的な日食と月食

chapter2 私たちの太陽系

  • 太陽系の仲間たち
  • 太陽系の誕生
  • 暑くて寒い水星
  • 鏡のように輝く金星
  • 巨大火山のある火星
  • 第二の地球候補 火星
  • 小さくても仲間が多い 小惑星
  • 太陽になれなかった木星
  • ガリレオが発見した木星の衛星
  • 環が魅力的な土星
  • 個性的な土星の衛星たち
  • 横倒しで回る天王星
  • 一番遠い惑星 海王星
  • 神話にまつわる惑星の名
  • 太陽系とともに誕生 外縁天体
  • 彗星の落とし物 流星

chapter3 夜空に輝く恒星

chapter4 銀河から宇宙の果まで

  • 宇宙の広がり
  • 私たちのすみか 銀河系
  • ブラックホールをもつ銀河系
  • 銀河系とその仲間たち
  • 渦巻きだけじゃない銀河の形
  • 華やかなスター 活動銀河
  • 銀河の群れ 銀河の集団
  • 泡のような宇宙の形

chapter5 宇宙の誕生と歴史

  • 無から誕生した宇宙
  • 夜空にひそむ 宇宙の歴史
  • 一番星や銀河の誕生
  • 闇の力が左右する 宇宙の未来

chapter6 宇宙の探求

  • 変わってきた宇宙の見方
  • ロケット開発から月への着陸まで
  • 地上から宇宙から 宇宙の観測
  • 太陽系の惑星を探る
  • 宇宙に滞在 国際宇宙ステーション
  • これからの宇宙開発

chapter7 宇宙を楽しもう

  • 夜空を見上げよう
  • 星を見つけよう
  • 月を楽しもう
  • 流れ星を見よう
  • 「食」を楽しもう
  • プラネタリウムに行こう
  • 公開天文台に行こう
  • HPで宇宙にくわしくなろう
  • 宇宙にまつわる遺跡に出かけよう

初めてのスペイン旅行を楽しむためのスペイン基礎知識

...っていうタイトルの記事があったら嬉しいな〜、と思って調べたけど無いようなので書いた。 この記事のスコープは、スペインのかなり基礎的な知識。

※ 注意:記事の内容がタイトル通りになっている保証はありません

内容のほとんどは、以下の書籍とスペイン - Wikipediaから引用している。

A20 地球の歩き方 スペイン 2016~2017

A20 地球の歩き方 スペイン 2016~2017

国旗

f:id:mogulla3:20161120205243p:plain

※ 画像引用元:スペイン - Wikipedia

上から赤・黃・赤の国旗。通称「血と金の旗」。
中央の紋章は5つの王国(カスティーリャ、レオン、アラゴン、ナバーラ、グラナダ)を表す。

ちなみに国の標語は「Plus Ultra」らしい。雄英高校の校訓じゃないですかー^^。

地理

地方行政区画

17の自治州と50の県がある。以下に、代表的な県と合わせて記載する。

f:id:mogulla3:20161120210410g:plain

※ 画像引用元: スペイン地図 - 旅行のとも、ZenTech

国土面積

約50.6万平方km。日本の約1.3倍。

人口

約4646万人。日本の1/3。
土地は日本より広いけど、人口は日本より少ないという羨ましい感じ。

首都

マドリードマドリード州)。人口は約313万人。
ちなみに東京は1362万人くらいいる。東京多すぎ。

言語

英語のレベルは日本と同程度らしい。なんとか聞きとれるけど、話せないとか。親近感。

気候

地形と海流が影響しあうスペインでは、地方によって大きく気候が異なる。

  • 北部のカンタブリア海沿い:多雨。夏は涼しく冬は温暖な海洋性気候。
  • マドリッドを中心として中央部:昼夜で気温差が激しい。夏は暑く、冬は寒い大陸性気候。
  • スペイン東部や南部などの地中海沿岸地域:年間を通して温暖で乾燥した地中海性気候。

服装は、基本的には日本とほぼ同じで大丈夫とのこと。

通貨

  • 通貨単位はユーロ(€)。 スペイン語読みだと「エウロ」。
  • 補助通貨単位はセント(¢)。スペイン語読みだと「センティモ」。
  • 1€ = 100¢ = 125円
  • 紙幣:5, 10, 20, 50, 100, 200, 500ユーロ
  • 硬貨:1, 2ユーロと1, 2, 5, 10, 20, 50セント

時差

日本との時差は8時間ある。きつい。

政体

議会君主制
17の自治州からなり、それぞれ独自の政府を持つ。自治州はさらに50の県に分かれる。

宗教

キリスト教カトリック教徒が圧倒的多数。

電圧とプラグ

  • 220V。日本は100V。
  • 周波数50Hz。日本は50/60Hz。
  • プラグはCタイプ。日本はAタイプ。

日本国内の電化製品を使用する場合は変圧器とプラグ変換器が必要。ただしデジカメやPC、スマートフォンなどはプラグ変換器だけで良い場合が多い。

度量衡

日本とほぼ同じ。

  • 距離:メートル法
  • 重さ:グラム、キロ
  • 液体:リットル

助かる。

サッカー

食文化

食事の回数が5回ある。

  • デサジュノ:朝食。起きがけに食べる。
  • メリエンダ・メディア・マニャーナ:朝の軽食。午前11時頃に食べる。
  • アルムエルソ:昼食。午後2時頃食べる。1日のメインとなる。
  • メリエンダ:夕方の軽食。午後6時頃食べる。
  • セナ:夕食。午後9時頃食べる。スープやサラダ。

食べ過ぎじゃない?

トイレ

トイレは「アセオス」または「セルビシオス」と呼ばれる。
公衆トイレは街中には少ないので、美術館やレストランで済ませるのが吉らしい。

SやCとだけ書かれていることも多いようなので、区別はつけられるようにしておいたほうが良さそうな予感。

シエスタ

  • スペインの習慣の1つ。
  • 13:00 ~ 16:00頃にある昼休憩のこと。
  • シエスタの時間帯(大体15時頃)は商店、企業、官公庁などの多くが休憩時間となる
  • シエスタがある代わりに、スペインの朝は早い。よって睡眠過多にはなっていない。

キーワード

  • エスタシオン:駅のこと。
  • セントロ:街の中心部のこと。
  • プラサ:広場のこと。街の中心となる広場は「プラサ・マヨール」と呼ばれる。
  • カテドラル:キリスト教における司教座のある教会のこと。
  • メルカード:市場のこと。

地球に季節ができる仕組みについて調べた

知識ゼロからの宇宙入門

知識ゼロからの宇宙入門

『知識ゼロからの宇宙入門』という本の中に「地球に季節がある理由」という章があったけど、ちゃんと理解するために追加でいくつか調べたのでその時の記録を残す。 他人向けに書いてないので、親切な内容にはなっていないと思う。

なぜ地球に季節があるのか

答え:太陽の照り方に差があるため。「差」というのは次の2つ。

  • 日照時間
  • 太陽の当たる角度

なぜ太陽の照り方に差が起こるのか

ではなぜ、日照角度や太陽の当たる角度に差が生まれるのか。
それは、地球が自転軸を約23.5度傾けて、太陽の周りを1年かけて回っていることによる。

起きていること

日照時間の違い
  • 夏の頃は太陽が出ている時間が長い
  • 反対に冬の頃は太陽が出ている時間が短い
  • だから夏は暖かく、冬は寒い

f:id:mogulla3:20161119192038j:plain
※ 引用元:http://www.nipponhyojun.co.jp/search/rika/ri_17/

太陽の当たる角度の違い
  • 夏至の太陽高度は78度。真上に近い。
  • 冬至の太陽角度は31度。斜めから。
  • 立春立秋は54度。夏至冬至の中間。
  • 垂直に当たるほど暖かいため、夏は暖かく冬は寒い

f:id:mogulla3:20161119192201p:plain
※ 引用元:https://www.nipponhyojun.co.jp/search/rika/ri_21/cont2.html

補足とか調べたときの感想

  • 自転軸の頂点にある北極では、夏は太陽が沈まず、冬は太陽が昇らない
  • 赤道直下は自転軸の傾きの影響が少ないため、太陽がほぼ真上から当たる。そのため、年間を通して暑い。
  • 太陽と地球との距離は四季の変化には関係ない。正確には、太陽と地球との距離より自転軸の傾きによる影響の方がずっと大きい。ちなみに、太陽と地球との距離が1番近くなるのは1月で、遠くなるのは7月(このことからも距離はほとんど関係ないことがわかる)。
  • 23.5度という微妙な傾きのせいか、仕組みを理解しづらいときがあった。そういう時は、地軸の傾きがもっと大きいと仮定して極端に考えてみると理解しやすくなるかもしれない。
  • 三球儀があると理解しやすそう(なぜかamazonで検索するとめっちゃ高いやつばっかり出てくる)

参考

『話したくなる!つかえる物理』を読んだ

『話したくなる!つかえる物理』という本を読んだ。

話したくなる! つかえる物理 (アスカビジネス)

話したくなる! つかえる物理 (アスカビジネス)

読みはじめた動機

とにかく物理まわりの知識無さすぎてマズイな、って感じたのがきっかけ。 万有引力の法則とかエネルギーとか質量保存の法則とか電気とか、ほとんど覚えていないし誰かに説明できそうにも無いなと。これくらいは最低限の知識を持っておきたいなと。

あとは単純に、目次を読んでみておもしろそうだと思ったので買った。 ややこしい数式とか図が出てくるのは苦手だけど、そういう類の書籍でも無さそうだったし。

感想

良かったところ

小学校・中学校で学んだ物理(理科)の知識が浅く広く、かつ読みたくなるようなタイトルでまとまっている。 最低限の知識をおさらいしたいと思っていた自分の目的と中身がマッチしていて良かった。また、飽きずに楽しく読めるような構成になっていたのも良い。

ちなみに、”読みたくなるようなタイトル”というのは例えば次のような感じ。

  • 死海で人がぷかぷか浮くのはなぜ?
  • 「消せるボールペン」の原理とは?
  • 救急車が通り過ぎると音が変わるのはなぜ?

身近な現象を使ったタイトルになっているのが、興味を持てた理由だと思う。

1テーマごとに5ページ程度で簡潔にまとまっているので、電車の中や昼休みに細々と読む自分にはそういう点でも合っていた。

悪かったところ

著者は敢えてやっていると思うけど、最低限の説明しか書かれていないので納得しきれない部分とか疑問に感じる部分が結構出てきた。 「原理はわかったけど、なぜそうなるのかわからない...」とか。

例えば第1章の「力と運動」のパート08では次のような説明がある。

よく磨いた包丁を使うと物がよく切れる理由は、包丁の刃に垂直な方向に押した力の分力が働くからで、刃先がとがっている方が、分力が大きくなるからです。

なーんで、刃先が尖っている方が分力が大きくなるんだろう...って思ったけどこの書籍ではこれ以上のことは知ることはできなかった。

まとめ

  • 広く浅く物理の知識を学びたい、という人には良いと思う
  • 身近な現象を例に、興味を持って読めるようなタイトル・構成になっているので飽きずに読める
  • 最低限の説明しかないので、疑問を抱く部分がおそらく出てくる。が、本書のみでそれを全て解決するのはおそらく困難

なお、本書のはじめの「読者の皆さんへ」という章には次のように書かれている。

私たちの身のまわりの現象には、物理の法則がしっかり関係しています。 「物理の目」を少し持つだけでも、「ここにも物理がある!」とおもしろがれる場面が増えることでしょう。 私たちは「知れば・わかれば、物理はこんなにおもしろい!」ことを示したかったのです。

(略)

私たち執筆者一同は、皆さんに「物理も案外おもしろいじゃん」と思ってもらえることを願っています。

本書の狙い通り、「物理おもしろいな」という気持ちになれました。ありがとうございます。

読むのにかかった日数

約5日

目次

最後に目次を紹介する。

第1章 力と運動

  • 01 速さと速度の違いとは?
  • 02 ピストルとライフル銃 弾丸が遠くまで飛ぶのはどっち?
  • 03 重くても軽くても物体は同時に落下する?
  • 04 ボールの飛距離をもっとも伸ばす角度とは?
  • 05 どんな固いものでも力を受けると変形する?
  • 06 北海道と沖縄では体重が違う?
  • 07 飛行機はなぜ飛ぶことができる?
  • 08 明石海峡大橋の支柱が約300メートルもあるのはなぜ?
  • 09 子どものお手伝いはいらぬお節介?
  • 10 子どもと横綱が綱引きをして子どもが勝つ方法とは?
  • 11 宇宙飛行士は慣性の法則で遭難する?
  • 12 10メートル競争をしたら、人、スポーツカー、バイクの1位はどれ?
  • 13 なぜ深海魚をつり上げるととんでもないことになる?
  • 14 大きな力を出す機械の原理とは?
  • 15 死海で人がぷかぷか浮くのはなぜ?

第2章 仕事、熱、エネルギー

  • 16 物理の仕事ができる人とは?
  • 17 本当に楽な仕事はあるの?
  • 18 人間は電球何個分のエネルギーで生きている?
  • 19 ジェットコースターには動力源がない?
  • 20 アメリカでは体温98.6度が平熱?
  • 21 温度が上がると5円玉の穴は大きくなる?
  • 22 なぜ最高気温の記録は沖縄ではなく内陸地域なの?
  • 23 冷却ジェルシートは発熱に有効ではない?
  • 24 「消せるボールペン」の原理とは?
  • 25 世界の年間消費エネルギーは、太陽エネルギー1時間分でまかなえる?
  • 26 人類の夢、永久機関とは?

第3章 光、音、運動

  • 27 全身を映すのに必要な鏡の大きさは?
  • 28 老眼鏡をかけている人は虫眼鏡をかけている?
  • 29 7色の虹の外側にあるものとは?
  • 30 雑音が消えるヘッドホンのしくみとは?
  • 31 恐竜の鳴き声は「ギャオー」ではなかった?
  • 32 ゾウは10キロ離れた場所にいても会話できる?
  • 33 音の出るしくみとは?
  • 34 声でワイングラスを割る?
  • 35 救急車が通り過ぎると音が変わるのはなぜ?

第4章 電気

  • 36 雷の正体は静電気にあった?
  • 37 コンセントの電圧も感電すれば命の危険がある?
  • 28 電子の流れは人が歩くよりも遅い?
  • 39 なぜ電線に止まった鳥は感電しないの?
  • 40 電気料金はどうやって決まるの?
  • 41 乾電池1個で子どもをぶら下げる?
  • 42 スピーカーはマイクにもなる?
  • 43 IHクッキングヒーターのしくみとは?
  • 44 なぜ電気器具は地域によって買いかえが必要なの?
  • 45 地球と木星との間でする会話は往復1時間もかかる?

第5章 原子

  • 46 すべての物質が90数種類の元素からできている?
  • 47 放射能の名づけ親はキュリー夫人だった?
  • 48 なぜ遺跡の年代測定は可能なの?
  • 49 長崎に投下された原爆は、1円玉1個分のエネルギーに等しい?
  • 50 「母なる太陽」のエネルギー源はどこにある?