勉強日記

チラ裏

捨てるということ

広義の勉強ということでね


小中学生編

部活を捨てた

ぼくは、小学校から中学校まで、吹奏楽部をやっていた。
うざい先輩がいたり、全国大会まで行ったり。
人並みに恋をしたり、その子には先約がいて弄ばれたり。
けっこう上手かったので、県のソロコンテストに出たり。
なんやかんや人並みの青春を謳歌した。

中3になるとき、ふとどうでもよくなって、辞めた。
「高校受験もあるし」とかなんとか、それらしい理由をつけて、辞めた。
学校の集会で校歌を歌うのは新鮮だった。今までは演奏する側だったので。

部活を辞めるとき、周りにはたいそう反対された。
しかし、辞めた。だってどうでもよかったし。
辞めてからというもの、母親は1年くらいずっとそっけなかった。

当時の我が家の家計は非常に厳しかったらしい。
親父が精神的に参って、まともな仕事を探せる状態にないとかで。
母親がパートを掛け持ちして、なんとか家計を支えている、みたいな話だったかな。
詳細はどうでもいい。過ぎたことだし。
重要なのは、金も時間もない中で、母親はぼくの部活動を全力でサポートしてくれていたということだ。

母親は、ぼくが本気で音楽が好きなのだと、プロになりたいのだと信じて全力でサポートしてくれた。
中古のマイ楽器を買ってくれた。
教本を買ってくれた。
社会人サークルに混じって一緒にコンサートした。
朝練のために早起きすると、それよりも早く起きて、朝食と弁当を作ってくれた。

ぼくはそれらを「どうでもよくなって」捨てた。
では、ぼくはそんな母親を騙した悪いやつなのか?

否、ぼくも最初は本気で音楽が好きだった。
小中学生のたわごとレベルだが、プロになりたいと思っていた。
それがいつしか、「ロールプレイング」に変質した。

「周りは、ぼくがこう振る舞うことを、ぼくに期待している」

しばらくの間、自分の意志でそれをやっていると錯覚していた。 それが、あるとき錯覚が解けて、ふと「どうでもよくなった」。

あれ、なんでこんなことしてるんだっけ--


はじめて「捨てた」のが中3の15歳。
今年で27歳になるが、ずっとその調子だ。


大学生編

ロールプレイング、再び

ぼくは小中高と進みながら、「将来はITをやりたい」と思っていた。

小学生のころはJavaScriptを触った。
ある日、商業高校生だった姉がJavaScript/HTML/CSSの本を買ってきた。
いわく、「これからはIT」と。慧眼である。
ガッツリ借りて私物化しているうちに、いつの間にかぼくのものになった。

中学生のころRPGツクール5を触り、プログラムというものに対する理解がだいぶ進んだ。
ブラウザで動くゲームを作り、友達に遊んでもらった。情報の授業が楽しみで仕方がなかった。
当時は「DHTML」とかいう言葉があったんですよ。あと<bgsound>タグとかあったなぁ。

高校ではJavaなどを触った。
当時はガラケーアプリ全盛期。休み時間はみんなチャリ走、糸通し
そんな中ぼくは「ぷよぷよテトリスを無料で遊びたい」という邪にして純粋な理由でアプリ開発に手を出した。
docomoだと自分のサイトで普通に配布できるんですよねあれ。Softbankぼく低みの見物だった。

このころ家計に余裕が出てきて、ぼくは成績優秀だったので、「大学進学していいよ」という話が降ってきた。
ぼくは「情報系に進みたい」と言った。
父親は「ITに未来はない」とかなんとか抜かしてた。姉と比べて見る目の無さよ。

父親は代わりに、「金属材料学」をすすめてきた。
2010年当時、世間のトレンドは「レアメタルの枯渇」だった。
その時、ぼくの中では半ば無意識下で「ロールプレイング」が始まっていたと思う。
ぼくは東北大学工学部材料科学総合学科に進学した。

部活を捨てた (2)

大学では奇術部に所属していたが、なんやかんやで3年で辞めた。
同期や後輩の才能、自身の才能の枯渇、努力するの疲れた等の理由。

思えば、この頃から捨てグセがついた気がする。

学歴を捨てた

大学でもぼくは優秀だったので、3.5年で飛び院進するなどした。
が、学部の学位記ももたずに大学院まで進んだところで「捨てた」。

これ、やりたかったことと違う--

6年間のモラトリアムと、何百万円単位の学費・生活費をかけて、最終学歴高卒を得た。 (笑えない)


社会人編

なんやかんやでIT系企業に就職。やりたいことできてよかったね。
RTAのつながり等、人脈が広がった。
あと、ゲームやオタク趣味を自重しなくなったのもここから。

保護者のもとを離れ自立し、捨てグセが加速する--

ぬるま湯のような環境を捨てた

入社後1.5年たったある日、客にこっぴどく叱られた。
このままではいかんと一念発起。技術面を鍛えるため、勉強会に通い始めた。

当初は、「会社をよくしたい、開発環境をよくしたい」と心の底から思っていた。
しかし世間とのあまりのズレに焦りと絶望を感じ、
「ここを改善するのは割に合わない」
と判断し、半年後に辞めた。

思い返せば、あの環境が一番楽だったなぁ。得るものがないだけで。

RTAを捨てた

部活と似たような理由。
ITの勉強で忙しくなって辞めた。

オタクグッズを捨てた(売った)

最近めちゃくちゃ忙しくて苦し紛れに捨てた。
例えばタペストリー。管理に結構ストレス感じるんですよね。

twitterアカウントを捨てた <- new!

捨てずに、ひたむきに頑張り続けている人たちを見ていて疲れちゃった。
あと「もう興味ないもの」とかガンガン流れてきて見るにたえないし。


人生を振り返ってみて

生活に負荷がかかったときなど、
「大事に育ててきたものを捨てる」
ことで再生をはかるクセがついている。

有形無形のものを捨て続けて、最終的に何が残るんでしょうね

twitterアカウント運用・設計を見直した


こうした

f:id:wand_ta:20200816162617p:plain

背景

  • 最近ツイカス気味でやるべきことが進まないのでSNSデトックスを思い立った
  • デトックスついでにアカウント運用を見直そうと思った
  • 運用以前に設計が終わっているのでその改善にあたった

改善前

f:id:wand_ta:20200816162912p:plain

  • 一言でいうと、「単一責任原則違反」 (?)
    • アカウントのフォロー理由は一つであるべき
  • 従来の運用では、単一アカウントの発信が「るつぼ」と化していた
    • 生業のWebエンジニアリング
    • 趣味のオタク活動
    • 誰得な生活ツイート
    • エロリツイート
  • 例えば、オタク活動が活発な時期にフォローしてくれたフォロアーさんにとって、Webエンジニアリングのツイートは邪魔でしかない

改善後

f:id:wand_ta:20200816163116p:plain

  • 自分の発信を顧みて、だいたいインタフェースが見えてきたので、それらに応じてアカウントを分けた
  • d_horiyama_core は人生や生活、健康にかかることだけをつぶやく。死ぬまで使う想定
  • 他のもの(d_horiyama_web, d_horiyama_ota)は、長い人生の中で爆破する想定で使う
    • 爆破後にも残したいような発信はcoreで行い引用・リツイートする

運用

メインアカウント

f:id:wand_ta:20200816163417p:plain

  • 当面はwebエンジニアリングを生業とし、それが生活の中心になるはずなので、d_horiyama_webは生活に関する発信を兼ねると思う

f:id:wand_ta:20200816163647p:plain

  • そういう場合は、生活ツイート等をcoreで行い、それをd_horiyama_webで引用・リツイートする運用とする

アカウント横断の知識の一元化

  • アカウント横断のためにbioにIDを直接書いたりフォロー・フォロアー関係をつくのは、以下の観点から望ましくない:
    • 管理が煩雑になる。新しいアカウントを作るたびに、既存の全アカウントを編集しないといけない
    • 美少女TLに技術の話が流入するなど、興ざめなことがおこる

f:id:wand_ta:20200816163840p:plain

  • そこで、アカウント横断の知識を「リスト」として一元化することとした
    • GoFのMediator Patternに近い
  • coreで公開リストを作成し、それを各アカウントから参照する
  • URIをインタフェース、リスト本体を実装と解釈すれば、各アカウントは疎結合に保たれる
    • アカウントを追加するたびに各アカウントのbioを編集したりフォロー作業を行う必要がない

ひとまずこれで運用してみようと思う。

ジェネリクスと変位について覚え書き -- なぜimmutableに書くのか

「setterをむやみに生やさずにimmutableに書こう」

という理由のひとつとして、「共変にできる」というのもあるんだなぁと思ったのでメモ。


よく聞く「T[]は不変(invariant)だよ」というやつ

  • 電車で考えてみる
    • Male extends Human, Female extends Human
    • Train<Human> ... 一般車両
    • Train<Female> ... 女性専用車両
  • Train<Female> extends Train<Human>と言えるか?
  • 一般には言えない
  • 反例: train.push(aMale)
  • Train<Female>push<Human>(aHuman: Human)を実装できないのでTrain<Human>としては使えない
  • is-a関係が崩れるので、とくに継承関係のない無関係な型になる(invariant)

必ずinvariantかというと、そうではない

  • Train<T>::at<T>(index:int): T これは問題ない
    • Train<Female>から取り出したFemaleはもれなくHumanとして使える
    • Train<Female>::at<Female>(index:int): FemaleTrain<Human>::at<Human>(index:int): Human として使えるということ
    • 「共変戻り値」という
  • Train<T>::push<T>(t: T): T これが駄目
    • 引数の場合、型を拡大できても、狭めることはできない
    • 「反変引数」という
    • 電車の例でいうと、女性が通常車両に乗るぶんには問題ない
  • 「共変かつ反変」というのが無理なので不変になるよ、という話
  • 反変なメソッドさえ生えていなければ、共変になりうる

共変なジェネリクスの例: ScalaのimmutableのList[+A]

  • Scalaだと型パラメータを[]で書くらしい
    • +が共変、-が反変を表す

www.scala-lang.org

def head: A
    Selects the first element of this iterable collection.
  • 要素取得。共変戻り値
final def map[B](f: (A) => B): List[B]
          Builds a new list by applying a function to all elements of this list.
  • コールバック関数fの型が(A) => B
  • 「反変引数」なので、引数型を広げるぶんには問題ない。(Female) => Bとして(Human) => Bを使うことができる
  • つまり、List[Female]List[Human]の機能を満たす。まだ共変
def appended[B >: A](elem: B): List[B]
    A copy of this sequence with an element appended.
  • リストに変更を加えるのではなく、新しいリストを返す
  • 引数型にも戻り値型にもList[A]の型パラメータAが出てこないので、変位にはとくに影響しない。共変を崩さない

そんなこんなでScalaのimmutableのList[A]は共変らしい


追記

PHPでは、PsalmとPHPDocコメントを使って共変の変位指定ができるらしい

CCNA試験対策 下巻ch12: Miscellaneous IP Services

https://www.ciscopress.com/store/ccna-200-301-official-cert-guide-volume-2-9781587147135www.ciscopress.com


First Hop Redundancy Protocol

The Need for Redundancy in Networks

The Need for a First Hop Redundancy Protocol

The Three Solutions for First-Hop Redundancy

HSRP VRRP GLBP
Full Name Hot Standby Router Protocol Virtual Router Redundancy Protocol Gateway Load Balancing Protocol
Origin Cisco RFC 6798 Cisco
Redundancy Approach active/standby active/standby active/active
Load Balancing per... subnet subnet host
仮想MACアドレス 0000.0c07.acxx
xxはHSRPのグループ番号を16進数にしたもの
0000.5e00.01xx
xxVRRPのグループ番号を16進数にしたもの
0007.b400.xxyy
xxはGLBPグループ番号
yyはその中でのシーケンス(01-04)

HSRP Concepts

f:id:wand_ta:20200704142231p:plain

R2(config)#interface g0/0/0
R2(config-if)#
R2(config-if)#ip address 10.0.0.200 255.255.255.0
R2(config-if)#
R2(config-if)#standby 10 ip 10.0.0.254
R2(config-if)#
R2(config-if)#no shutdown
  • PCから確認
    • 仮想IPv4アドレス10.0.0.254pingが通っている
    • 仮想MACアドレス0000.0c07.ac0aが振られている
      • HSRPグループ番号10 -> 0x0a
C:\>ping 10.0.0.254

Pinging 10.0.0.254 with 32 bytes of data:

Reply from 10.0.0.254: bytes=32 time=1ms TTL=255
Reply from 10.0.0.254: bytes=32 time<1ms TTL=255
Reply from 10.0.0.254: bytes=32 time<1ms TTL=255
Reply from 10.0.0.254: bytes=32 time<1ms TTL=255

Ping statistics for 10.0.0.254:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms

C:\>arp -a
  Internet Address      Physical Address      Type
  10.0.0.254            0000.0c07.ac0a        dynamic
  • echoは両routerに届くが、echo-replyはactive routerからのみ帰る (今回はR2)

f:id:wand_ta:20200704142243p:plain

  • active/standby
    • priority値でどのrouterがactiveになるか決まる
      • tie-breakerは物理IPアドレス
      • 最も大きいものがactiveになる
    • 後からpriority値の高いrouterを追加しても、OSPFのDR/BDRよろしくpreemptionはおきない
    • インタフェースコンフィグでstandby <group-number> preemptを設定することでpreemptionを有効化できる

HSRP Failover

  • MACアドレスを仮想化するのでホストのARPテーブルに変更は生じない

HSRP Load Balancing

  • HSRPではVLANごとにHSRPグループを作成し、仮想IPアドレスを割り当てる
    • 各HSRPグループでpriority値を調整し、「VLAN1ではR1をactive」「VLAN2ではR2をactive」という形で負荷分散を実現できる
  • cf. GLBPは1つの仮想IPアドレスに対して複数の仮想MACアドレスARP応答し、負荷分散を実現する

Simple Network Management Protocol

  • interface, IPアドレス、バッファといった変数を標準化したデータベースを作ることで、監視や管理を簡単にするという思想のもと生まれた
  • 機器上でagentを動かし、managerから操作を行う
  • MIB: Management Information Base
    • 「変数のデータベース」
    • ツリー構造
  • NMS: Network Management Station
    • managerが動作するPCやサーバ

SNMP Variable Reading and Writing: SNMP Get and Set

SNMP Notifications: Traps and Informs

The Management Information Base

Securing SNMP

  • SNMPv3でようやく本格的なセキュリティが搭載された
    • Message integrity
    • Authentication
    • Encryption

FTP and TFTP

Managing Cisco IOS Images with FTP/TFTP

The IOS File System

Router#show file systems
File Systems:

       Size(b)       Free(b)      Type  Flags  Prefixes
*   3249049600    2761893909     flash     rw  flash:
         29688         23590     nvram     rw  nvram:
  • NVRAM: startup configが格納されている
  • FLASH: IOSなどが格納される
Router#show flash:

System flash directory:
File  Length   Name/status
  3   486899872isr4300-universalk9.16.06.04.SPA.bin
  2   28282    sigdef-category.xml
  1   227537   sigdef-default.xml
[487155691 bytes used, 2761893909 available, 3249049600 total]
3.17338e+06K bytes of processor board System flash (Read/Write)

Upgrading IOS Images

Copying a New IOS Image to a Local IOS File System Using TFTP

  • TFTPサーバからコピーする
Router#copy tftp flash
Address or name of remote host []? 10.0.0.1
Source filename []? c2960-lanbasek9-mz.150-2.SE4.bin
Destination filename [c2960-lanbasek9-mz.150-2.SE4.bin]? 

Accessing tftp://10.0.0.1/c2960-lanbasek9-mz.150-2.SE4.bin...
Loading c2960-lanbasek9-mz.150-2.SE4.bin from 10.0.0.1: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[OK - 4670455 bytes]

4670455 bytes copied in 0.058 secs (6473925 bytes/sec)
  • コピーしたファイルを確認
Router#show flash:

System flash directory:
File  Length   Name/status
  4   4670455  c2960-lanbasek9-mz.150-2.SE4.bin
  3   486899872isr4300-universalk9.16.06.04.SPA.bin
  2   28282    sigdef-category.xml
  1   227537   sigdef-default.xml
[491826146 bytes used, 2757223454 available, 3249049600 total]
3.17338e+06K bytes of processor board System flash (Read/Write)


Router#dir flash0:
Directory of flash:/

    4  -rw-     4670455          <no date>  c2960-lanbasek9-mz.150-2.SE4.bin
    3  -rw-   486899872          <no date>  isr4300-universalk9.16.06.04.SPA.bin
    2  -rw-       28282          <no date>  sigdef-category.xml
    1  -rw-      227537          <no date>  sigdef-default.xml

3249049600 bytes total (2757223454 bytes free)

Verifying IOS Code Integrity with MD5

Copying Images with FTP

Router#copy ?
  flash:          Copy from flash: file system
  ftp:            Copy from ftp: file system
  running-config  Copy from current system configuration
  scp:            Copy from scp: file system
  startup-config  Copy from startup configuration
  tftp:           Copy from tftp: file system
  • ftpやscpも使える

The FTP and TFTP Protocols

FTP Protocol Basics

  • over TCP
  • 認証がある

FTP Active and Passive Modes

  • 2本のTCPコネクションを用いる
  • FTP control connection
    • TCP21番
  • FTP data connection
    • TCP20番が予約されているが、client/serverともにephemeral portを使うことが多い
    • active mode
      1. clientはdata connectionに用いるephemeral portを確保する
      2. clientはcontrol connection上でserverにFTP PORTコマンドを送信し、clientのIPとephemeral portを伝える
      3. serverはclientにTCP SYNを送信し、data connectionの確立を開始する
    • passive mode
      1. clientはserverにFTP PASVコマンドを送る
      2. serverはdata connectionに用いるephemeral portを確保する
      3. serverはcontrol connection上でclientにFTP PORTコマンドを送信し、serverのIPとephemeral portを伝える
      4. clientはserverにTCP SYNを送信し、data connectionの確立を開始する
  • active mode誕生の経緯
    • TCP20番を決めて使ってしまうと、複数のFTP clientを動かせない
  • passive mode誕生の経緯
    • サーバー側からTCPコネクションを確立してしまうとファイアウォールに阻まれる
      • ランダムなEphemeral Port全部開けるわけにもいかない
    • クライアント側からTCPコネクションを確立すればファイアウォールに阻まれない

FTP over TLS (FTP Secure)

  • FTP自体に暗号化がないのでTLSで補う
    • FTP AUTHコマンド

TFTP Protocol Basics

  • Trivial File Transfer Protocol
  • over UDP
  • 認証なし

CCNA試験対策 下巻ch17: Cisco Software-Defined Access (SDA)

https://www.ciscopress.com/store/ccna-200-301-official-cert-guide-volume-2-9781587147135www.ciscopress.com


SDA Fabric, Underlay, and Overlay

  • Fabric
    • Underlayとoverlayが組み合わさった全体をさす言葉
  • Underlay
    • 物理的なL2/L3ネットワーク
  • Overlay
    • Underlayの上で構築される論理的なネットワーク
      • VXLAN tunnelなど

The SDA Underlay

Using Existing Gear for the SDA Underlay

  • brownfield design
  • ノードには役割があり、要求するスペックが公式にまとめられている
    • Fabric edge node
      • 従来のaccess switchに相当
    • Fabric border node
      • WAN edgeに相当
    • Fabric control node
      • 論理と物理の変換を担う (LISP)
      • 多くのCPUとメモリを要するので、必要なスペックも高い
  • 既存のデバイスを用いる場合、このカタログに照らす必要がある

Using New Gear for the SDA Underlay

  • greenfield design
  • カタログ通りの製品を買えばいいだけ
  • プロビジョニング自体は依然として必要なことに留意する
  • Routed Access Layer Design
    • 全SwitchをL3にするすすめ
      • STPいらず
      • FHRPもいらなくなる

The SDA Overlay

VXLAN Tunnens in the Overlay (Data Plane)

  • VXLAN: Virtual Extensible LAN
  • VXLANを用いて、Underlayの物理的なネットワークを隠蔽してOverlay上の論理的なネットワークを構築する
    • 論理的なメッセージをVXLANでカプセルし、物理的なUDP,IP,Ethernetで再度包むことになる

LISP For Overlay Discovery and Location (Control Plane)

  • EID: endpoint identifier
    • Underlay Network上のサブネット
  • RLOC: Routing Location
    • Overlay上のアドレス
  • LISP map server
    • EIDとRLOCとの対応を管理する
    • Fabric Control Node上で動作する

DNA Center and SDA Operation

Cisco DNA Center

  • Cisco DNA Center対応機器を買うとプリインストールされているアプリケーション

Cisco DNA Center and Scalable Groups

Issues with Traditional IP-Based Security

  • 従来型のACLのつらみ
    • ACE: Access Control Entryが増えてくると収集がつかなくなる
      • 複数要件をまたいだACE
      • いつなぜ追加されたかわからないACE
      • 消すに消せない

SDA Security Based on User Groups

  • SGT: Scalable Group Tag
    • Employee, Internet, Partner, Guest といった論理的なタグ付けを行う
    • タグ間でアクセス制限を行う

DNA Center as a Network Management Platform

  • Ciscoは他にもネットワーク管理プラットフォームを提供している
    • Cisco PI: Prime Infrastructure など
  • 従来の管理プラットフォームと比較したときの特徴は

DNA Center Similarities to Traditional Management

  • トポロジマップの生成・表示、直感的なGUIなどは従来と差がない

DNA Center Differences with Traditional Management

  • 最大の違い
    • Cisco DNA CenterはSDAに対応している
    • PI等、従来のものは対応していない
  • Cisco DNA Center特有の機能
    • EasyQoS
    • Encrypted traffic analysis
    • Device 360 and Client 360
      • 360 = 包括的なヘルスチェック
    • Network time travel
      • 機器の、過去のある時点でのパフォーマンスを見られる
    • Path trace