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

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

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

必須アプリ

• Google Chrome
• Google Drive
• KeeWeb
• VLC media player
• SharpKeys

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

• Music player: VLC media player
• Video player: VLC media player
• Web browser: Google Chrome

に変更する。

便利アプリ

• Evernote
• Adbe Acrobat Reader DC
• WinRAR
• ScreenToGif
• NeeView
• qBitTorrent

キーボード設定

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 で導入する。

気が付いたら（※注 openSUSE ユーザ会の人にどのディストリビューション入れるか悩んでるって話したら） openSUSE 入れることになってた。

— 雀巽（じゃくそん） (@necojackarc) November 4, 2016

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

• VMware Workstation Player - VMware Products
• openSUSE Leap - Linux OS

デフォルトだと 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ファイルの編集が完了したら、

• VMware DHCP Service
• VMware NAT Service

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

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

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

参考

• VMWare Player上で動作するUbuntuのIPアドレスを固定化する
• VMware player NATで起動したゲストOSにssh接続する

キーリピート

• 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

関連画像

PC 新調いえい！ pic.twitter.com/IzFc7LXF86

— 雀巽（じゃくそん） (@necojackarc) November 9, 2016

ついに買ってしまった……！ pic.twitter.com/ii2XK2VTAZ

— 雀巽（じゃくそん） (@necojackarc) November 9, 2016

良い感じになってきたぞ！ pic.twitter.com/HgMiVAEEra

— 雀巽（じゃくそん） (@necojackarc) November 9, 2016

結局この形で落ち着いた。 pic.twitter.com/zqfAgfra3f

— 雀巽（じゃくそん） (@necojackarc) November 9, 2016

openSUSE 入れた。Geeko 可愛い。 pic.twitter.com/G8mgvevSgC

— 雀巽（じゃくそん） (@necojackarc) November 14, 2016

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

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

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

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

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

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

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

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

*1:Humility, Respect, Trust

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

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

necojackarc.hatenablog.com

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

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

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

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

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

経過良好だといいなー。

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

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

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

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

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

www.rakuc.com

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

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

www.amigo2.ne.jp

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

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

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

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

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

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

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

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

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

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

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

necojackarc.hatenablog.com

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

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

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

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

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

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

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

まとめ

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

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

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

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

www.atmarkit.co.jp

概念設計

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

論理設計

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

物理設計

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

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

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

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

「達人プログラマー」が全部入りエンジニア教本だった

「達人プログラマー―システム開発の職人から名匠への道」を読みました。

達人プログラマー―システム開発の職人から名匠への道

こちらは UNIXという考え方―その設計思想と哲学と共に t_wada さんが「若者向け課題図書」として挙げられていた本です。

若者への課題図書としてまずは『達人プログラマー』と『UNIXという考え方』を挙げた http://t.co/o7pEFBn26m http://t.co/zcbcmu2Apz

— Takuto Wada (@t_wada) April 23, 2015

necojackarc.hatenablog.com

読んだ感想ですが、流石若者向け課題図書と言うだけあって「全部入り教本」という感じでした。

開発者としての哲学に始まり、ツール、設計技法、そしてプロジェクト運営など、 システムを作る上で必要になることに対して一通り言及しています。

そして、それぞれで述べられている「心がけ」は色々なプラクティスや手法にも通ずる的を射たものでした。

確かにこの辺りの内容は早い段階で抑えておくべきだなと思います。 知っておいて欲しい心がけの宝庫でした。

ただ、そういった特性上、タイミングによって響く言葉は違うということも痛感しました。

リーダブルコードの時もそうだったのですが、 知っていることや当然だと思っていることも多く載っており、 一瞬「せやな」という感情に支配されていたりもしました。笑

necojackarc.hatenablog.com

もちろん幅広いトピックを扱っているので、響いた部分も多々あります。

以下、響いた言葉を一部抜粋していきます。

早めにクラッシュさせること

障害対応やデバッグをしている際に、本当の原因がどこかわからないで困ることがあるなというのを思い出しました。 例外が起きた位置でクラッシュさせておけば、原因究明に大いに役立ちます。死んだプログラムは嘘をつかない。

全ての例外ハンドラーを除去しても、そのプログラムは動作することができるだろうか？

例外を通常の制御フローに組み込むのは間違いなく悪手です。 そしてこのセリフは例外ハンドラーの使われ方が正しいか正しくないかを考える際に役立つなと思いました。

ソフトウェアは建築と言うよりもガーデニング（つまりコンクリートではなく、より有機的なもの）に近い

「建築のようには絶対行きません！そうだそうだ！もしそうならウォーターフローでうまくいくはずだ！」みたいな気持ちになりました。 今度からソフトウェア開発はガーデニングに例えようと思います。もしそんな機会があれば……。

まず、初期の計画と条件に従って、庭にさまざまな植物を植えます。すると、あるものは力強く育ち、あるものは枯れてコンポストの材料になってしまいます。また、日当たりや雨風の関係で植物をお互いに動かすようなことも行います。育ちすぎた植物は、株分けしたり剪定し、配色の合わないものは美的感覚を満足できるところに移動させます。雑草を抜き、必要に応じて肥料もやります。常に庭の健康状態を監視して、必要な調整（土壌、植物、レイアウト）を行うのです。

リファクタリングの必要なコードを「腫瘍」と考える

小さい内に摘出しないと肥大化して転移するという点で、まさに腫瘍だなと思いました。 腫瘍を見つけたらしっかり無視せず、チケットを切るなど何らかの対応はしておきたい。

プロジェクトの用語集を作ること

これ大事！共通言語大事！

枠にとらわれずに考えるのではなく、枠を見つけだすこと

見かけ上の制約に囚われず、自分が思っているよりも大きな「真の制約」を見つけるべきという話です。 枠を見誤っているケースというのは確かによくあると思います。本物の枠を見極めていきたい。

解説しない方が良い場合もある

「靴ひもの結び方を言葉で説明してみる」とこれの意味がすぐにわかると思います。 自然言語だけでは伝わらない情報がある、というのは肝に銘じておきたいです。

ストレート・ジャケット*1効果

解釈の余地を与えない設計というのは、スキルや技芸といったプログラミング努力を奪い去る意味らしいです。 解釈の余地がないとなると、単なる作業になってしまい、全く面白くないですものね。

「自然言語の限界」と「ストレート・ジャケット効果」から、詳細過ぎる仕様書がいかに害であるかがわかりますね。

まとめ

エンジニアとして心がけを幅広く教えてくれる良書でした！

*1:straitjacket: 拘束服

「Head Firstデザインパターン」が設計力を底上げしてくれる良書だった

「Head Firstデザインパターン ―頭とからだで覚えるデザインパターンの基本」を読みました。

Head Firstデザインパターン ―頭とからだで覚えるデザインパターンの基本

新人研修中に凄腕エンジニアに薦められて早三年半、やっっっと読みました。 流石凄い先輩が推薦してるだけあって、期待通りかなりの良書でした。

以下、良かったところをザックリ書いていきます。

パターンが活躍する実例から導入が始まる

特に良いなと感じた点は、各パターンが活躍する実例から導入が始まる点です。

大まかな流れとしては、「こんなものが作りたいんだよねー」という小話（要件）が最初にあり、まずはそれに沿った設計が提示されます。 すると要件の変更やら何やらが発生し、現状の設計のままだと問題があることに気づき、リファクタリングを余儀なくされます。 そこで「むむ、確かに。どうしたら良いんだろう」と考えさせられてからの、パターンの登場！

このような流れなので、そのパターンが適用できる状況や、解決可能な問題がスッと頭に入ってきます。

パターンへの深い理解がしやすく、記憶にも残りやすい作りになってるなと感じます。

デザインパターンへ懐疑的な人へのメッセージ

デザインパターンへ懐疑的な人へのメッセージが載っていたのも良かったです。

というのも、実は「優れたオブジェクト指向設計をしてればデザインパターンは不要では？」と若干思ってました*1。 しかし、そうじゃないんだよと、デザインパターンを学ぶことに意義はあるよと、そういう話があり良かったです。

重要度が高いパターンの重点的解説

使用頻度が高く重要度が高いと思われるパターンを重点的に解説してある点も、メリハリがあり良かったです。 正直「こんなにいっぱいあんのかよ」と思ってたので、重要なものを示してくれるのは本当にありがたかったです。

パターンは単なる道具

「デザインパターンに縛られるな。パターンは単なる道具。基本は設計原則に従いシンプルに保て」と言った、当然だけど初学者がハマりがちな罠への言及もしかっかりあり良かったです。

目指すところは優れたオブジェクト指向設計者であるというのを強く感じました。

まとめ

とっても良い本でした！

*1:ホントは本を読むのがめんどくさくてそう言い訳してただけです。笑