雀巽の日記帳

雀巽が綴る日常の記録

"Web API: The Good Parts" を読んだ

ITライフ 読書生活

"Web API: The Good Parts" を読みました。

Web API: The Good Parts

Web API: The Good Parts

一言で言うと Web API 設計時に考慮すべきことと良い見本が詰まった本 でした。

個人的にはエラーの表現方法、レスポンスヘッダ（HTTP の仕様に即したメタデータや Content-Type の扱い）、運用面の話が印象に残りました。

エンドポイント (URI) 設計については良くやっているので「せやな」と思いながら読み進めていたんですが、 SSKDs 向け（というかほぼ自分向け）の Web API しか作成したことがなかったので、LSUDs 向けのレスポンス設計や運用面の話はかなり学びが多かったです。

また、Web API 設計時に HTTP の仕様や制約をどう活用するかという話も非常に良かったです。

例えば、バージョン情報や独自ヘッダを Content-Type で表すのは HTTP の仕様上は美しいが、 クライアントとしては不便になることがあるなど、 仕様上の美しさと利便性のトレードオフを考えないといけない点などが印象に残りました。

運用面では Web API バージョニング（廃止）の話で取り上げられていた Twitter が実際に行った Blackout Test はなかなか参考になりそうだなーとも思いました。 あと、バージョニングはセマンティックバージョニングのメジャーバージョンだけを指定すれば良いようにするのも、なるほど確かに、という感じでした。

リソース指向の Web API の上にオーケストレーション層を載せる話も出てきました。

thenextweb.com

オーケストレーション層を作ったことはありませんが、こうすると良いよなぁとは思っていたので、 JSON を吐く機械になれる機会があればチャレンジして見ようと思います。

Web サービス開発に関わるは読んでおいて損はないと思える本でした。

「語源でわかった!英単語記憶術」がとても面白かった

英語生活 読書生活

「語源でわかった!英単語記憶術 」を読みました。

語源でわかった!英単語記憶術 (文春新書)

語源でわかった!英単語記憶術 (文春新書)

語源について書かれてる本は多いですが、これは「印欧祖語」の「原音」まで遡って解説してる点が良いなと感じました。

あまりたくさん読んではいませんが、他の語源関係の本だと、 単に接尾語、接頭語、語幹の羅列になっているタイプのものが多い印象です。

個人的にはこちらの「原音まで遡る」というアプローチが非常に身体に合いました。

読むのは結構大変でしたが、かなり多くの発見があり良かったです。

何度読み返しても学びがある系の本だと感じるので、ちょいちょい読み直したいなと思います。

とても面白く、良い本です。

Windows の初期設定をまとめたよ

ITライフ Notes

MacBook Air をさよならバイバイして、Dell XPS をゲットしたので、Windows の初期設定についてまとめてみます。

  • 必須アプリ
  • 便利アプリ
  • キーボード設定
  • 日本語入力
  • 開発設定
  • おわりに

必須アプリ

上記インストール後、Search the web and Windows から Default Programs の設定を開き、

に変更する。

便利アプリ

キーボード設定

CapsLock を Ctrl に割り当てる

SharpKeys を利用し、CapsLock を Ctrl に変更する。 実行後、CapsLock を Left Ctrl に割り当て、Write to Registry をクリックし、再起動する。

キーリピート

Control Panel -> Keyboard で Keyboard Properties を開き、Speed の Repeat delay を最短に、Repeat rate を最速にする。

日本語入力

Language Settings から Preferred Languages に日本語を追加し、その後 Keyboards に Microsoft IME を追加する。 Ctrl + Space での入力切替を行うために Microsoft IME Options -> Open -> Key & touch customisation を開き Key assignment を On にし、Ctrl + Space に IME-on/off を割り当てる。

また、デフォルトを 日本語入力にするため、Settings -> Devices -> Typing -> Advanced keyboard settings を開き、Override for default input method を Japanese - Microsoft IME に設定する。

開発設定

2019/10/09追記: WSL2 を利用した開発環境に切り替えました。

necojackarc.hatenablog.com

2018/04/22追記: openSUSE から Xubuntu に開発環境を切り替えました。

necojackarc.hatenablog.com

Linux

Windows での Linux ライクな開発は諦め、VMWare Player 上に openSuse を Xfce で導入する。

以下の公式サイトから必要なモノをダウンロードし、インストール。

デフォルトだと OneDrive 以下の Documents に Virtual Machines\openSUSE を作ろうとしてくるので、忘れずホーム以下に Virtual Machines\openSUSE として保存するようにインストール時に変更する。

ディスクは Store virtual disk as a single file とし、サイズ上限は推奨値の 20GB にした。 Customize Hardware では Hardware requirements を参考に、Memory は 2048MB、Processors は 2 とした。

openSUSE のインストール中に VMware が親切にも VMware Tools for Linux をインストールできるよと教えてくれたので、こちらもインストールする。

インストール後、またもや親切にも VMware tools のアップデートがあるよと教えてくれたので、アップデートを実行する。 VMware は常に新設で、アップデート方法は画面に表示されてる HELP に飛べば見ることができた。 正直色々と VMWare のことはよくわかってないので、これについてはとりあえず全部デフォルト値で入れておいた。

ネットワーク設定

VMWare のネットワーク設定は NAT (おそらくデフォルト値) にしておく。

まずはゲスト側の IP アドレスを固定にする。

ゲストに入り ifconfig を叩き、現在の MAC address と IP を確認後、C:\ProgramData\VMware\vmnetdhcp.conf を admin 権限で開き以下の通り Host を追加。

# openSUSE
host VMnet8 {
    hardware ethernet 00:0C:29:08:96:8F;
    fixed-address 192.168.221.128;
}

次に C:\ProgramData\VMware\vmnetnat.conf を admin 権限で開き必要な Port Forwarding Rules を追加する。

具体的には以下のように、[incomingtcp] に設定を追記する。

[incomingtcp]
:
# openSUSE
1080 = 192.168.221.128:1080
3000 = 192.168.221.128:3000
3002 = 192.168.221.128:3002
4200 = 192.168.221.128:4200
7020 = 192.168.221.128:7020
7357 = 192.168.221.128:7357
8080 = 192.168.221.128:8080

それぞれポートは、

Port App Note
1080 MailCatcher mailcatcher --ip=0.0.0.0
3000 Rails dev server bin/rails s -b 0.0.0.0
3000 Serverless offline sls offline -o 0.0.0.0 start
3002 Browsersync
4200 Ember.js dev server
7020 tiny-lr (LiveReloaded server used by Ember)
7357 Test'em (used by QUnit in Ember)
8080 Webpack dev server

で使用している。

2ファイルの編集が完了したら、

を Services から restart する。ゲスト OS へ割り当てる IP を変更している場合はゲスト OS も reboot する。

次に openSUSE 側で YaST -> Security and Users -> Firewall を開き、Disable Firewall Automatic Starting を設定し、Firewall を無効化する。

これでゲスト側でアプリケーションを起動すれば、ホスト側から localhost:PORT としてアクセスが可能になる。

参考

キーリピート

  • Repeat delay: 300
  • Repeat speed: 80

解像度 (DPI)

Windows 側の DPI スケーリング (画面拡大率) が Virtualbox 内の OS には反映されないため直接設定を変更する。 XPS 13 では 150% が推奨値かつデフォルト値だったが、流石にでかすぎるので 125% に変更した。

調べたところ、

  • 小-100%(96 DPI)
  • 中-125%(120 DPI)
  • 大-150%(144 DPI)

が Windows の基本数値らしい。

Menu -> Settings -> Settings Manager -> Appearance -> Fonts を開き、Custom DPI setting を有効にし、Windows 側に合う数値を設定する。

ただ、普段は外部モニタで作業しているので、基本は無効にしている。

日本語入力

Fctx-mozc を Fcitx - openSUSE に従い、以下のコマンドでインストール後、再起動する。

$ sudo zypper install fcitx-mozc

再起動後、右下のキーボードアイコンから Input method に Mozc を追加する。

これで Ctrl + Space で日本語入力へのトグルでの切り替えが可能になる。

CLI 環境

ターミナルは Xfce デフォルトの Xfce Terminal を利用する。 最初からまともな Terminal があり、Windows と違ってここで消耗しない素敵。

開いたら Preferences を開き Colors の Presets から Solarized (dark) をロードする。Solarized 最高。

ただし、デフォルトの Solarized だと一部の文字が背景色とほぼ同じになっており見えないという残念な問題が発生するので、 Palette の一番左下の色を開き、「Red:0, Green: 108, Blue: 136 (#006c88)」あたりまでスライドさせておく。

フォントは Appearance -> Font から Monospace / Regular / 11 とした。 フル HD モニタで Vim を垂直分割した際にほぼちょうど横幅が100文字になりいい感じ。

そして必要なツール一式を以下の通り導入。

$ sudo zypper install make gcc git tmux xsel gvim

Git を導入後、再度ここを参考に Github の設定を行う。

./ssh/config は Windows と同様に設定。

Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/github/id_rsa

そして necojackarc/dotfiles を README に従いぶち込み設定完了。

おわりに

System => System protection => Create からシステムの復元ポイントを作成しておく。 Description は "Just after initialization" とでもしておくと、あとでわかりやすくて良い。

関連記事

necojackarc.hatenablog.com

関連画像

「Team Geek ―Googleのギークたちはいかにしてチームを作るのか」を読んだ

ITライフ 読書生活 ビジネスライフ

「Team Geek ―Googleのギークたちはいかにしてチームを作るのか」を読みました。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

この本、メッチャ良いです。

エンジニアが忘れがちだけど、絶対に心がけておくべきことについてみっちり書いてあります。

また、自分の中の「良きリーダー像」が見えてきたのもかなり収穫でした。 自分用メモ書いたので、適宜見返して自分のものにしていきたいなと思います。

軽妙な語り口で書かれた本で、更に200ページもなく薄い本なので、是非気軽に読んでみてください。

HRT*1 を大事に生きていこう！

*1:Humility, Respect, Trust

痔瘻手術から9日目で無事ゴムが取れました

日常生活

先週の月曜日に痔瘻の手術をしてきたんですが、手術後9日目の本日、無事にゴムが取れました！

necojackarc.hatenablog.com

お医者さんが「1週間〜10日で取れる」とおっしゃていたんですが、まさにドンピシャリでした。

ちなみに、外れたゴムの記念写真も撮りました。

f:id:necojackarc:20161005133824j:plain

このサイズのゴムが1週間ちょっとで身体を貫通して外れるなんて、人間の身体って凄いですね……。

そして輪っかちっちゃ！こんなんがお尻についてたら痛いはずやわ！

明日また通院予定です。変な外れ方してないかだけが心配です。

経過良好だといいなー。

日帰りで痔瘻の手術をしてきました

日常生活

本日、日帰りで痔瘻の手術をしてきました(´；ω；｀)

全体的に消化器官が弱く下痢しやすいんですが、半年前の新サービスリリース前後に下痢下痢してたころ、肛門周囲膿瘍からの痔瘻になっちゃってたっぽいです。

この頃、夜中まで働いてたりとストレスが多く、更に睡眠不足も重なっており免疫力が低下してたと思うので、それで……という感じだと思います。

「痔瘻（じろう）」とは、名前の通り痔の一種ではありますが、よく知られてる「いぼ痔」や「切れ痔」とは別物です。「穴痔」と呼ばれることもあるそうです。 治療方法が手術オンリーというクレイジーなやつです。勘弁してくれよまじで……。

www.rakuc.com

入院して半身麻酔での手術が多いようですが、近所の先生は基本的に日帰りで局所麻酔で手術を行うスタイルのようでした。

おそらく術式は下記のリンクにある「痔瘻結紮法」か何じゃないかなと思います。

www.amigo2.ne.jp

有名な治療法は思い切ってバサッといく「痔瘻切開開放術式」と、数ヶ月かけて徐々に取り除く「シートン法」だそうですが、 「ウチではシートン法みたいなまどろっこしいことはしない」とおっしゃっていました。強い。

じゃあ何なんだろうと思って説明を元に調べてみたところ、「痔瘻結紮法」が一番近そうな感じでした。

術式に使っていたゴムもネットで調べて出てくるものに比べて細い気もしますし、外に出てる結び目も小さい感じがしますし、 確かに一般的なシートン法ではないんだろうなぁという感じです。ただ、原理はシートン法と同じだと思います。

Wikipedia での医療関連情報は間違っているものも多いと良く聞きますし、まだまだインターネットは発展途上だなとも思いました。

完治するまではなんとも言えませんが、普通は「入院・半身麻酔・数ヶ月」で処置するものを「日帰り・局所麻酔・数週間」で終わらせるという、 圧倒的名医感漂う先生*1でした。説明も丁寧でわかりやすく、こちらのどんな質問にも答えてくれる信頼できる先生でした。

とりあえず、今日からしばらくの間、痛み止めとの共同生活が始まります……！

全ては身体が資本！健康第一でいきましょう！

*1:超名医かヤブ医者のどっちかだろうなって感じがしますね。笑

ERD（概念/論理/物理設計）の管理について

ITライフ

ERD（概念/論理/物理設計）の管理についてのメモです。

Web サービス企業では設計書の作成や管理がされない傾向にありますが、 以前も書いたように ERD は作成し管理すべきだと考えています。

necojackarc.hatenablog.com

ただ、最近 ERD の管理で煩わしいなと感じる部分がありました。 それは、Rails のマイグレーションファイルと論理/物理設計の内容が重複していることです。

概念設計*1はもう一段抽象度の高い内容となっているので重複していると感じないのですが、 論理/物理設計に関しては「論理/物理設計 = テーブル構成そのまま」となるので、内容が重複してしまっていました。

これに対する2パターンの解決案を書きます。

パターン1: 概念設計のみ保持する

概念設計の ERD のみドキュメント管理をし、論理/物理設計を作らないパターンです。 マイグレーションファイルなので実装自体が管理されている場合、これで良い気がします。

パターン2: 論理/物理設計を保持し DDL を利用する

DDL を利用し、論理/物理設計の変更自体をデータベース自体の変更とするパターンです。 SIer 時代に大規模プロジェクトではこちらのパターンを採用していました。

まとめ

  • 概念設計は実装の経緯や意図が現れているため常に保持すべき
  • 論理/物理設計はほぼ実装そのものであるので二重管理となる場合は不要

単純に「同じ抽象度のモノを同時に管理するのは DRY じゃない」という話でした。

補足: 概念/論理/物理設計について

それぞれが何をするべきフェーズなのか、以下にわかりやすくまとまっていました。

www.atmarkit.co.jp

概念設計

業務の観点から必要な情報を漏れなく管理できるように設計します。 抽出した情報は、正規化し、あるべき姿で情報を整理し、概念ER図に表します。

論理設計

データ構造の変更を最小限に抑えながら性能向上を図ります。

物理設計

ユーザー要件として性能要件や可用性を考慮したデータベースを設計します。そのために必要なハードウェア資源、ミドルウェアの選定、パラメータの設定を行います。

正規化が論理設計に含まれているケースもみますが、データベーススペシャリスト試験などの本を見てみると、 上記の分け方で書かれていたので、この分け方が一般的なんじゃないかと思います。

また、「概念設計では属性を書き出さない」という誤解もありますが、書き出すケースも書き出さないケースもあると思います

*1:属性を持っていないものこそが概念 ERD だという誤解を耳にしたことがありますが、属性は持っていても良いです。目的とフェーズ次第だと思います。例えば正規化をする際には属性が無いと難しいかと思いますし、概念上のデータをできるだけ正確に表すのであれば、属性も重要な要素になると思います。