Magnolia Tech

いつもコードのことばかり考えている人のために。

ソフトウェアエンジニアに必要な資質の一つ目は「エラーメッセージが出たら、読んで理解しようとする姿勢」です

最近のプログラミング言語の傾向として、エラーメッセージを改善して、より分かりやすいメッセージが出力されるようになっていますね。

gihyo.jp

techlife.cookpad.com

上記は、PythonRubyの事例ですが、最近の言語はどれもエラーメッセージが親切になってきました。

それでも読まないのはなぜなんでしょうね…一番の近道だと思うんでけどね。

とはいえ、エラーメッセージを読むだけで解決するバグばかりでもないので、エラーが解決しない時にさっさと方向転換するのも大事な方針ですよね。

というわけで、ずっと同じことを繰り返し言っているような気もしますが、まずはこの3つから始めるといいんじゃないかなーって。

2022年の買った書籍

あれ!意外と少ない...けっこう同じ本を何度も読んでいるからかもしれない。

2022年の今年買ったもの

書籍系は、また別にまとめるとして...それ以外で買ったもの

Anker 521 Charger USB PD 40W

プラグが折り畳めないのがちょっと難点な、Type-Cが二つ刺せるUSB PD対応の充電器。

HomePod mini2台の給電用に使っている。

ちょうど2台分の給電にマッチしていて、HomePod mini用か?と思えるくらい(違う)。

Anker PowerLine III Flow

謳い文句の通り、シリコンで覆われているので、全然絡まない。

Anker Nano II 65W ホワイト

Anker製品ばっかり買っている気がする......

持ち運ぶ用の充電器としてはサイズ的に、ベスト。

電源プラグは折りたためるし、65Wの給電が有ればたいていのPCも大丈夫。

最近の、複数同時に給電できるタイプはちょっと高いので、持ち運び用だったらこのくらいがちょうどいい感じ。

MARANTZ PRO Umpire

オンラインミーティング用。

配信する訳じゃないから、このくらいかもなーと思いつつ、最近Audio-TechnicaのAT2020USB-XというType-C接続できるマイクがちょっと気になる。

KATOMOKU plywood wall clock 4

リモートワークに一番必要なものは、見やすいところに掛けられているアナログの壁掛け時計だと思っていて、これがあるだけで時間を意識できるようになってくれる。

時間の区切りを意識しないと、無限にやってしまう......

エレコム マウスパッド 生地テクスチャ タイベック

雑に実物も見ないで買った割にけっこう気に入っているマウスパッド。今まで買った中では一番しっくりきている。

エンボディチェア

これは2021年の12月に購入だったけど、まだ1年経ってないのでセーフ?

人それぞれ合う椅子は全然違うから誰でにもおすすめという訳ではないけど、この椅子は自分にはすごく合ってて、1日中座っていても全然疲れない。

後傾姿勢用だから書き物にはまったく合わないけど、PC作業中心の人向け。

背面のデザインが独特なのも好みのポイントだけど、まぁ座っていると見えないよね...

年末は『ちょうぜつソフトウェア設計――PHPで理解するオブジェクト指向の活用』を読んで過ごすんだ!

「ちょうぜつエンジニアめもりーちゃん」で知られる(?)田中ひさてるさんの本がついに出版される!!(ので、速攻注文した)

PHPぜんぜん分からないけど......

12月10日発売なので、年末は『ちょうぜつソフトウェア設計』を読んで過ごすことにしました。

ちなみに、「ちょうぜつエンジニアめもりーちゃん」って何?って人は、Twitterハッシュタグ「#ちょうぜつエンジニアめもりーちゃん」でチェック!

twitter.com

見えないモノを見ようとして......

それなりの経験を積んでいくと、エディタのカーソルの動きとかエラーの出方とかで、「あーここに全角スペースが有るんだろう」みたいなエスパー力が身に付くわけだけど、人類は道具で進化するので、フォントが最初から全角スペースを可視化してくれていればそんな努力(?)の必要は無くなってしまう。

不可視キャラクタを表示してくれるフォントやエディタの機能、シンタックスハイライト、テストコード、CI/CDの結果、さらにはプロジェクト管理のガントチャートなど……ソフトウェア開発の世界にはいろいろな「見えないことを見えるようにする」取り組みが行われてきた。

成果物を作る人自身、レビューをする人、管理をする人、報告を受ける人、出資をする人……色々な立場の、色々な要望に合わせて可視化が行われる。

そして、その可視化が必ずしも関係者全員に対してプラスの結果だけをもたらすわけではない、みたいなことを先日のこのエントリを見ながら考えた。

bufferings.hatenablog.com

このエントリでは、期限をコミットしようとすると、その変動リスクの許容度に合わせてバッファを積まなければならず、その結果、速が出ないことが有る、という話だったのだけど、可視化そのものにかける作業量が、最終成果物を作る作業時間を削ってしまう、みたいなことはよくあることなのだ。

見積を作って、説明して、交渉して、発注したり……という時間が有ればそもそもさっさと作れてしまったのでは?という経験は誰しもあるはずで……


見えないモノを見ようとして、見てはいけないものが見えてしまったり、見ている間に時間が過ぎてしまったり、見ていると思っていたら、見られていたり……でもやっぱり見えるようにはしなければいけなかったりと、かくもソフトウェア開発は難しい。

ISUCON12予選問題をdocker-composeで起動する - 続き...network_modeのhost指定を止める

blog.magnolia.tech

前回のエントリの続き...前回、macOS版のDocker Desktopではnetwork_modehostを指定すると、Docker Desktopが起動しているLinux仮想マシンがホストになってしまうため、macOS側のブラウザではトップページへアクセスできないと書いた。

というわけで、network_modeからhostの指定をすべて削除した。

networkの作成

変更した箇所はリンク先のリポジトリに書かれている。

github.com

docker-compose.yml

  • ファイル名docker-compose.ymlは、今では非推奨になっていて、compose.yamlが推奨になっているので、ファイル名を変更
  • compose.yamlでは、フォーマットのversion指定は必要がないと公式ドキュメントに書かれていたので、削除
  • 新しくisucon-tierというネットワークを作成し、コンテナはすべてそこに属するように修正した
  • すべてのhost指定を削除した
  • linksをやめて、depends_onに修正

nginxの設定変更

  • IPアドレスが、他のサービスなのに127.0.0.1で指定されている箇所について、名前解決可能なFQDN(ここではサービス名)に修正 networkを新しく作るとサービス名、コンテナ名などでの名前解決が可能となる

data/Makefileの修正

data/Makefileの中でmysqlが同じホストで動いている前提になっているので、127.0.0.1をすべてホスト名(service名)としてのmysqlに変更。 また、portも13306になっている箇所は、すべて元の3306に修正。

その後、初期データのビルドを行う。

$ cd /home/isucon/data
$ make build-for-docker-compose

ベンチの実行

nslookupで、nginxが動いているサーバのIPアドレスを取得

$ nslookup nginx
...

Non-authoritative answer:
Name:   nginx
Address: 172.18.0.4

取得したIPアドレスを指定して、ベンチマークを実行

$ go run cmd/bench/main.go -target-url https://t.isucon.dev --target-addr 172.18.0.4:443

成功!

ベンチマークの数値は特に変わらず(当たり前)

ブラウザからのアクセス

/etc/hostsに、127.0.0.1admin.t.isucon.dev指定でアクセスできるように追記

ブラウザを起動し、https://admin.t.isucon.devへ接続...サーバ証明書の期限が切れていた...終了...

curlは、証明書を検証しないオプションがあるので、それを指定して実行

$ curl -k https://admin.t.isucon.dev

JavaScriptが必要なサイトなので、JavaScriptを有効してね!というメッセージが出て終了......とりあえず到達はしている模様......


とりあえず、環境は整備できたので、次はアプリケーション側に手を入れるナニカをやります。

『Linuxのしくみ』は、アプリケーションの向こう側を知るために読むべき

2022年も良い技術書がたくさん出版されましたが、その中でも『Linuxのしくみ』はぜひ手元に置いておきたい1冊ですね。

特に、主にアプリケーションレイヤーを主戦場としている人たちにとって、OSは各種ミドルウェアと比較すると「よく分からないもの」という存在になりがちです。しかし、OSがなければアプリケーションも動かないわけで、基本的な知識としてこの本に書かれているようなレベルのことを押さえておくと性能が出ない時に無闇に資源を増やす前に考えるべきことの気づきが得られます(無闇に資源を増やす、という選択肢が取れる時代になったのは、それはそれで良いことですが)

特に、前半のプロセス周りは、「sar」「taskset」など自分も今までちゃんと使ったことがないコマンドがどんどん出てきて、非常に学びがありました。

やっぱり「推測するな、計測せよ」ですね(これも本書に出てきます)!

HWで直接実行されているOS上のアプリケーションでも、仮想マシン上のアプリケーションでも、コンテナ上のアプリケーションでも、メモリ上に乗ったコードがCPUで実行されている、という面ではなにも変わらないので、少なくとも1章〜5章、10章〜12章くらいはざっと目を通しておくと良いでしょう。

とにかく買いに行きましょう、読みましょう、書かれているコードを動かしてみましょう、カーネルの気持ちになってみましょう、という1冊です。


ちなみにKindle版でもいいのですが、この手の技術的にかなり突っ込んだ内容の本がフルカラーで出版されるのは珍しいのでぜひ紙の本で買っておくと、ふとした時に読み返しやすくて良いと思いました。