こまぶろ

技術のこととか仕事のこととか。

続:Keynote で作成したスライドを Speaker Deck にアップロードすると Transcript が文字化けする問題への対応

Keynote で作成したスライドを Speaker Deck にアップロードすると Transcript が文字化けする問題があり、その対処法を以下の記事で紹介していた。

ky-yk-d.hatenablog.com

最近のMacはPostScriptをビルトインでサポートしなくなった

しかし、記事の中で言及していたMacの「プレビュー」がPostScriptファイルのサポートをやめてしまったため、現在ではPostScriptからPDFに変換する部分は別のツールを使って行う必要がある。

support.apple.com

代わりのツールの一つ:Ghostscript

この記事では、代替の方法のひとつとして、Ghostscriptを紹介する。

www.ghostscript.com

Macの場合、Homebrewでインストールするのが簡単だろう。

$ brew install ghostscript

GhostscriptでPostScriptからPDFに変換する

Keynoteから「プリント」→「PostScriptとして保存」として作成したPostScript(ps)ファイルを、Ghostscriptの ps2pdf を使ってPDFに変換することができる。

$ ps2pdf input.ps output.pdf

こうして作成したPDFをSpeaker Deckにアップロードすれば、文字化けを回避することができる。

補足

手元の環境で作成したpsファイルでは、 ps2pdf では以下のようにエラーになり変換できなかった。

$ ps2pdf input.ps output.pdf
GPL Ghostscript 10.03.0: PDFDocEncoding ad is undefined

@toshimaru_eさんの手元では ps2pdf でも変換ができているようなので、ファイル側に問題があるように思われる。

なお、原因は特定できていないのだが、同じファイルもPDF 1.3を用いる ps2pdf13 を使えば変換することができた。

$ ps2pdf13 input.ps output.pdf

謝辞

以前書いた記事の方法が現在では一部使えなくなっていること、Ghostscriptで代替できることを指摘してくださり、 ps2pdf での動作の状況も教えていただいた@toshimaru_eさんに感謝します。

MacでDocker Desktop4.27.0に上げたらMySQL 5.7(amd)のコンテナが動かなくなった場合の対処法

追記

Docker Desktop は runcの脆弱性対応で2024/2/2現在の最新はv4.27.1になっています。

www.docker.com

環境

事象

Docker Desktopのバージョンをv4.27.0に上げたところ、これまで使用できていたmysql:5.7のDockerコンテナが起動できなくなった。

エラーメッセージは、以下のようなもの。

2024-02-01 17:38:46 2024-02-01 17:38:46+09:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.43-1.el7 started.
2024-02-01 17:38:46     qemu: uncaught target signal 11 (Segmentation fault) - core dumped

対処法

MySQL 5.7の公式Dockerイメージにはarm版が存在せず、amd版をApple Silicon上で動作させていたが、バージョンが上がったことでqemuでは動作しなくなった模様。

qemuではなくRosettaを使うように設定を変更することで、動作するようになった。Docker DesktopのSettings > General から、"Use Rosetta for x86/amd64 emulation on Apple Silicon"にチェックをつけて再起動すればよい。

SettingsのGeneralタブで、Use Rosetta for x86/amd64 emulation on Apple Siliconにチェックがついています

なお、macOSがMonteleyではこの設定項目が表示されずRosettaが使えないようなので、その場合はVentura以降にOSバージョンを上げればよい。また、macOS 14.1以降でDocker Desktopを動かしている場合はデフォルトでqemuではなくRosettaが使われるようになっているとのこと。

Rosetta for LinuxはAppleシリコンを搭載したMacのmacOS 13.0以降で使用可能。macOS 14.1以降ではデフォルトで有効になっているとのことです。

www.publickey1.jp

良い子のみんなは早くMySQL 5.7を脱却して8.0に行きましょう

2023年に読んで印象に残った本、読書に関するふりかえり

年の瀬なので、今年読んだ本のふりかえりをば。それではレッツゴー!

実践的データ基盤への処方箋

会社でデータ基盤周りのことを考える機会があったので読んだ。データ基盤素人にもわかりやすく書かれていたと思う。最初の一冊として良いというのを同僚のデータエンジニアからも言われた。

Webブラウザセキュリティ

認証認可周りを触る機会があったので読んだ。Webアプリケーションのセキュリティに関しては徳丸本などもあるけど、この本はブラウザに特化していて仕様の話なども充実しているので面白かった。

図解即戦力 暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書

これも認証認可周りを触るときに読んだ。「図解」とあるので初歩的なものをイメージしがち(自分はそう)なのだが、これはなかなか骨太で、数学的な部分も入ってくる。しかしそれでいて読みづらくはないというのが素晴らしいと思う。

誤謬論入門

ky-yk-d.hatenablog.com

ブログにしたもの。IT系とは別のところで反響が大きかった。インターネット上の言説に違和感を感じるときにこの本の整理を参照すると少し違和感をクリアにできる。

アジャイルプラクティスガイドブック

Rettyの常松さんの著書。スクラム関係の本やアウトプットが多いのに対して、アジャイルの技術的プラクティスについてはあまりまとまった形で出てくることがないなと感じているなかで、待望の一冊だった。

アジャイル開発をする上で悩んでいることがある開発者のみなさんは自分も運営で関わっているScrum Developers Night!をよろしく(以下のページは前回開催時のもの。次回開催の案内は2月を予定していますので、Scrum Masters Night!*1のconnpassのグループに参加して通知をお待ちください)。

smn.connpass.com

世界一流エンジニアの思考法

マイクロソフトの牛尾さんの著書。noteやブログで牛尾さんがどういうことを感じている/考えているのかは以前からウォッチしていたが、それが書籍という形でまとまったもの。想定読者としては現場のエンジニアよりも「管理者」向けの側面が大きい(倉貫さんの『人が増えても速くならない』に近いものがある)と感じるのだが、最初の方に書かれている牛尾さんの周囲の優秀なエンジニアの行動パターンの話は非常に興味深く読んだ。

特に、「理解に時間をかける」という話が印象的だった。自分の所属する会社でも学習への投資が積極的に行われている(下記のブログ参照)のだが、ついつい目の前の仕事を前に進めるために不十分な理解を放置して進んでしまいがちだと感じていたのだが、やはり理解に時間をかけてスキルを伸ばすことが将来的にいい仕事をするためにも必要で、自社のマネージャーもそれを期待しているということもあって、この本を読んだ頃からは以前よりも「理解に時間をかける」ようになった(もちろん時にはスピードを重視しないといけない場合もあるだろうけど)。

tech.bm-sms.co.jp

Linuxのしくみ

ky-yk-d.hatenablog.com

こちらもブログにしたもの。秋以降は『プログラマーのためのCPU入門』、『コンテナセキュリティ』、そして現在は『詳解システム・パフォーマンス』と(アプリケーション開発者から見た)低レベルのところに意識的に取り組んでいる。記事にも書いたが、最初に読む本として『Linuxのしくみ』は非常におすすめ。

プロダクトマネージャーのしごと

自分はプロダクトマネージャーではないが、プロダクトマネージャーに限定されない仕事の考え方の話も書かれているという評判を目にして読んだ。たしかにそういう側面もある本で、時々読み返す本になりそうだと思った。

特に印象に残っているのは「過剰コミュニケーション」の話と、

「最初のドラフトは1ページで、作るのに1時間以上かけない」という話。

数年前、私はビジネスパートナーたちに「チームにドキュメントに使う時間と労力を減らせとコーチする割には、いまだにあなた自身は内部ミーティング資料を念入りに作り込んでいるんですね」と指摘されました。私が「当然ですよ。あなたたちは優秀だからいいけど、私は仕事をちゃんとやってるって思わせたいんです」と言うと、全員が一瞬固まりました。「はぁ」。

(『プロダクトマネージャーのしごと』p.154)

www.mindtheproduct.com

www.onepageonehour.com

2024年に向けて

来年の4月でソフトウェア開発者として働き始めてから7年が経つことになる。

ソフトウェア開発関連の書籍を読むことはキャリア初期から自分を大いに助けてくれてきたのだが、この1,2年くらいは仕事で向き合う課題が単なる知識不足では解決できないものが多くなってきて、以前ほど書籍を読むことの意義が感じられなくなってきている側面があり、以前ほどたくさん本を読まなくなっていた(2022年末のサッカーW杯でサッカーにどハマりして休日の夜が欧州サッカーで消費されるようになったのと、2023年1月クールのアニメ「お兄ちゃんはおしまい!」で声優・アーティストの石原夏織さんのファンとしての動きを再開したのとで、そもそも学習にかける時間が減ってしまったというのも大きいのだが)。


www.youtube.com

しかし、2023年後半からはややバランスを取り戻して、学習への時間を増やし始められている。書籍を読むことで解決する仕事上の課題が増えたわけではないのだが、周りのシニアなエンジニアと話していると自分が知らないことをたくさん知っているなと感じることが多くあるので、仕事基準ではなく人基準で足りないところを埋めていこうと思って勉強をしている。

また、↓で書いた毎日1ページでもいいので本を読むという活動に参加したこともいいきっかけになっている。やはりピアプレッシャーは習慣化の大きな助けになる。

この活動は「みんチャレ」というアプリを使ってやっていて、5人1組でヨーイドンで始めるものなので現在自分の参加しているグループに追加で参加してもらうことはできないのだが、仲間さえ集まれば簡単に(アプリは無課金でも利用できる)始められるので、興味がある人がいたら周囲の人に声をかけてみるといいと思う。

minchalle.com

そういうわけで、2024年はより一層ペースを守って勉強することを重視したいと思います。みなさん良いお年を。

*1:Scrum Developers Night!はScrum Masters Night!の派生イベントで、同じconnpassに同居しています。Scrum Masters Night!もエンジニア歓迎だと思うのでそちらもぜひどうぞ。

1年間積読になっていた『Linuxのしくみ』を読んだ

この記事は、「積読 Advent Calendar 2023」6日目の記事です。

adventar.org

昨日の記事は @hanhan1978 さんの記事でした。


『[試して理解]Linuxのしくみ ―実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識【増補改訂版】』を読みました。発売日は2022年10月17日で、発売されて割とすぐに買った記憶がある(現在は3刷までは少なくとも出ているようだが、手元にあるのは1刷)のですが、1年経ってようやく読みました。

gihyo.jp

なぜ買ったのか

自分の主戦場とする領域の1つ下のレイヤの知識を知っておきたかったからです。

自分は普段、Webアプリケーションの開発をしていて、バックエンドを主に触っています。学生時代の専門は情報系ではなく、成り行きでソフトウェア開発の会社に就職することになってからプログラミングを学びました。

就職してからは、コードの書き方や設計の考え方、あるいは開発プロセスについて関心が強く本をよく読んでいたほか、仕事で使うミドルウェアやツールをユーザーとして学ぶ(ex. MySQLのインデックスの使われ方や最適化がどうとか)ことはあったものの、インフラのレイヤのことをちゃんと学ばない(仕事で接するたびにその部分だけ調べる程度)まま生きてきてしまいました。目の前の仕事をこなすだけならそこまで困るわけではないのだけど、技術者としてはやはりそこもわかるようになっておきたいなという思いを持っていました。

同じ背景で、少し前(2022年1月に読み終わっているようです)に『コンピュータアーキテクチャのエッセンス』は読んだものの、ハードウェアの話が中心なので正直ピンと来ず、自分の普段触っているレイヤとの隣接性も感じられなかったため、消化不良のままになっていました。

www.shoeisha.co.jp

そんな中で、『Linuxのしくみ』の増補改訂版が出るよ、カラーになって読みやすいよ、プログラマにもおすすめだよ、というのをTwitterで見かけて、これだったら興味を持てるかもしれないと思って買ったのでした。

なぜ1年間積んでいたのか

ここ1年、単純に本を読む量が減ってしまっていたというのがまず大きいです。理由は色々とありますが、これを書き始めると長くなるので省きます。

他には、やはり「仕事に短期的に直結しない本なので後回しになってしまった」というのもあります。そもそもの動機からして、「毎日の仕事をこなす分にはそこまで困っていないんだけど、読んでおきたい」という切迫感の弱いものだったし、仕事に直結する勉強(たとえば、アプリケーションの認証認可の部分を実装するにあたって、OAuthやOIDCの勉強をしたり、『暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』を読んだり)と比べて具体的なきっかけを普通に仕事をしているだけで得ることが少ないので、一度積読になってしまったあとは手付かずになっていました。

なぜ今になって読んだのか

直接のきっかけは、最近仕事をしている中でスレッドやコンテキストスイッチの話を同僚とする機会があったからです。

幸いなことに現在同じチームで働いている同僚には低レベルのことをよくわかっているシニアなメンバーがいて、チーム内のコードレビューやモブプログラミングでそこの知識も踏まえて話をしてくれるのですが、「おっ、今この人の言っていることがわからないぞ」と思わされることが時折ありました(その都度説明してもらったり調べたりはする)。

そんな中で、先日スレッドやコンテキストスイッチの話になり、ぼんやりとはわかっているが理解度が全然足りないなということを改めて感じたので、重い腰を上げて読み始めました。

感想

非常に読みやすかったですし、自分が知りたいなと思っていたところを知ることができました。

「実験と図解で学ぶ」とあるように、文章での説明に加えて実験と図解が豊富にあるのですが、特に実験のパートが「サンプルコードとその出力」というプログラミング言語の書籍でよくあるものに留まっておらず、レイテンシやリソースの使用量などのデータを表やグラフにして掲載していたのが良かったです。仕組みを図や文章で説明するだけでなく、「その結果として、実行した際にどのような挙動になるのか」まで理解させてくれるのがこの本の良さだと感じました。

終章では、この本を読んだ後にどんな勉強をするとよいかという紹介がありましたが、自分の場合はWebアプリケーションの運用と開発のための知識・スキルをつけていきたいので、巨大積読である

を次は消化していきたいと思います。来年は積読を増やさず、これまでに積んできた書籍を着実に読んでいくぞ……!


『Linuxのしくみ』と前後して、関連する内容のある以下の本も読みました!積読を解消しているぞ!!!

*1:原書が『Linuxのしくみ』の終章でも紹介されていました。翻訳が出たのは今年になってからですね。

ICとEMの狭間を揺蕩っている(会社ブログにインタビュー記事が載りました)

掲題の通り、会社のブログにインタビューしてもらった記事が載りました。

tech.bm-sms.co.jp

組織の一員として語るべきことは記事中で語っていますので、そちらをぜひご覧いただきたいのですが、せっかくの機会なので記事には載らなかった個人的な話を少し書いておこうかと思います。「あれ、エンジニアリングマネージャーなりたいっていってなかったっけ?」という話です。


記事では、2020年4月に現職に入社してから社内でどのようなことをしてきたかを、開発者としての開発チームでの仕事以外の部分にフォーカスを当てて話しました。一般的にはエンジニアリングマネージャーなどが関わることが多そうな領域に、IC(Individual Contributor)の立場にありながら関わっていることがわかるかと思います。

Twitterなどではしばしば語ってきたところですが、2017年4月に新卒でソフトウェア開発者としてのキャリアをスタートしてから、1年経たないくらいの時期にあった2冊の書籍との出会いが自分のこれまでのキャリアにとっては大きなインパクトをもたらしました。いずれも2018年2月に出版された『カイゼン・ジャーニー』 と『エンジニアリング組織論への招待』です。

プログラミング未経験で開発者として就職して、「これからは技術で仕事をしていくんだな」と漠然と考えていた自分にとって、ソフトウェア開発の世界で、いわゆる「技術」とは異なるトピックが存在していて、どうやらそこがうまくいかないことで苦労することも少なくなく、その部分の問題解決のスキルを強みとして仕事をしている人たちがいるらしい、ということを知ったのがこの時期でした。

これらの書籍との出会いをきっかけに、アジャイルやマネジメントなどのコミュニティに出入りするようになり、自分よりも少し先輩に当たる人たちとの関わりができました。そうした人たちとの交流から、自然とアジャイルコーチ/スクラムマスターやエンジニアリングマネージャーといった仕事に興味を持つようになりました。現職に入るときも、そういう志向を口にしていたような気がします。


で、現職に入ってからほぼ3年半経つのですが、エンジニアリングマネージャーにもなってないし、スクラムマスターロールで仕事をしているわけでもないのですよね。どうしてこうなった?

理由は色々あります。一つの理由は、記事の中でも話しているように、現職の組織文化として「マネージャーだからこれをやる」という発想が弱く、「必要だと思ったらロール関係なくやればいいでしょ」という感じなので、元々やってみたいと思っていた活動にエンジニアリングマネージャーにならなくても携わることができているというのがあります。もちろん評価などの権限はないのでそういうことはやっていないのですが、採用面接に出たり、組織改善の取り組みに関わったりと、そこそこやりたいことができているわけです。

他には、現職で働いている中で、自分の技術スキル不足が仕事を進める上での1番のネックだなと感じる経験を多くしてきたというのもあります。開発プロセスなどのことは色々と勉強してきたので、その観点から改善を図るというのは必要であればやるし、実際にうまくいったことも多いのですが、それ以上に「自分がもっとコードをゴリゴリ書けたら前に進んだのに」などと思う機会や、チームが停滞しそうになったところを技術力(時に筋力)で突破 する同僚の姿をみる機会が多く、「もっとこっちの力を身に付けた方が自分の満足のいくパフォーマンスが仕事で出せるんじゃないか?」と思うようになりました。

「将来エンジニアリングマネージャーやるならこれくらいは技術も知っておきたい」というふうに考えて技術の勉強をするという話もよく見ますし、自分もそういうふうに物を考えることもありますが、それ以上に「仕事を前に進めるために自分がもっと持っていたら良かった力はなんだろう?」というところで、いち開発者としてのスキルをもっと磨きたいと考えて、正式にエンジニアリングマネージャーというロールを担いにいくことをしていないということです。


まぁそういうわけで、ICとEMの狭間を揺蕩い続けているわけです。

自分と似たような志向を持っていた(多分年齢の近い)開発者の人がエンジニアリングマネージャーになって活躍している姿をみて「自分はこれでいいんだっけ?」と思うことももちろんありますし、マネジメント以外の領域で一芸に秀でている人に憧れる思いもありますが、少なくとも「こっちに進んでいればよかった」という後悔は今のところはないので、それは幸いなところだなぁと思います。

とはいえ、今後どういう方向に進んでいこうかというのはやっぱり悩みどころですし、考えていかねばならんなぁとも思っています。 知人の皆様におかれましては「軽率に」飲み会に誘うかもしれませんのでどうぞよろしくお願いします。