にたまごほうれん草ブログ

はてなダイアリーから移行したブログ。以前のはこちら→http://d.hatena.ne.jp/emergent/

私だって『実践Rustプログラミング入門』を書きました

8月22日に『実践Rustプログラミング入門』を発売してからすでに1か月弱経ってしまいましたが、共著者の1人として参加するという貴重な経験をしましたので、私もブログにしたためておこうと思います。書かずにいる間に増刷が決まっていました。ありがとうございます!

他の共著者の方々のブログ記事

執筆のきっかけや感想など

2019年のクリスマス、フォルシアの松本さん(id:matsu7874)からのメールでRust本執筆にお誘いいただいたのがきっかけでした。その後、年が明けてから共著者陣で集まりテーマをブレストし、大まかな方向性が決まったと記憶しています。しかし、3月ぐらいまでは皆なかなか筆が進まず…という状況で、4月に入るか入らないかあたりでみなさんエンジンがかかったような気がしています。

最初のブレストの際におおまかな章立てと分担は決めたものの、少し書き始めたところで全体を俯瞰すると「あれも足りないこれも追加したい」と色々意見が出てボリュームが増えていきました。校正に出すタイミングでは、時期的にフルリモートワークのときでしたが、日中に会社の仕事をやってから間髪入れずに執筆・レビュー作業に突入していて、本業なんだっけ状態に陥りつつも、非常に充実した日々でした。ちなみに私は、4章と、11章の「FFI」「Rustを仕事で使う」、3章のFutureを書きました。

それにしても、7人も執筆者が集まると、自分の知らないRustのネタや知識がたくさんあるということを思い知らされました。メンバーの中でプログラマーとして一番未熟な私にとっては、執筆やレビュー自体がとても勉強になり、ますますRustのことを好きになることができました。

現状の自分の立場にも恵まれ、Rustを趣味だけではなく業務で実戦投入することができたことは、これからもRustを使い続ける口実にはなるでしょう。Rustを使ったソフトウェアプロダクトの開発は、いいことが多いので、これからもどんどん発見・発信していけたらと思います。

私とRust

ここから先は、ほぼ自分語りです。

私がRustを本格的に勉強し始めたのは、2019年の初頭だったと思います。新卒で就職した2005年から、数年のソフトウェア開発者(家電のソフトウェアをC言語で書いていた)だった期間を経て、それ以降は長らく開発の上流工程やプロマネ的な立場でばかり仕事してきました。ここでいう上流工程とは、企画や基本設計ぐらいの領域を言っています。つまり、プロダクトのコードを触ることはほとんどなく、業務の合間にちょっとしたスクリプトを作成する程度。それなのに、40歳まで後2年というところでやっぱりコードを書く仕事をしたいと思い、現在の会社に転職しました。当然選考を受けている時点ではソフトウェア開発者としての期待値はそんなに高くなかったと想像していますが、チームマネジメントをすることを期待されて(だと思っています)採用してもらえました。そのときは自分含め6名だけの開発チームだったので、チーム環境の整備しつつ、既存のC++プロダクトをベースに機能追加やバグ修正を積極的にやっていきました。

しかし、入社当初持っていた「C言語をやっていたからC++もすぐ習得できるだろう」という考えは甘く、やればやるほどC++は難しい…と実感することになります。既存プロダクトの多くはC++で書かれていて非同期処理も多用されていました。ロジックが難しいということもありましたが、C++をメンテナンスできる人は限られる一方、非同期処理由来のバグはどんどん見つかって増えていく→自分ほか数名でバグを直さないといけない、という悩みがありました。そんな経緯もあって「もっと別の言語で安全に作り直せないだろうか」と考え始めたのでした。

そんな中で、いろいろ調べているうちにRustを知ることとなり、半年ほどの自分の勉強期間を経て、新規に作成するサブシステムを、自らRustで開発して商用ローンチまで持っていくことができたのでした。言語仕様やコンパイラの動作を実際に試していくうちに、Rustは非常にプロダクト開発向きだという思いがどんどん大きくなっていったのを覚えています。開発に着手するまでに「Rustはすごく良い!なぜならば〜(省略)。だからこれは私がRustで作る!」と社長やチームメンバーにアピールしまくっていました。今思うと、半ばゴリ押しだったな、と。

プロダクトがWebサーバーであり、ちょうどactix-webのバージョンが1.0.0になったばかりだったのはいいタイミングだったと思えます。着手タイミングあたりで、マネージャー(管理職)になったのもあって、「日中はマネージャーのお仕事、それ以外の時間は全部コード書く時間」みたいな生活をしてたような気がします。帰宅してからも土日もずっとRustでコード書いていた(か、試行錯誤していた)ような気がします。

そのときは、まだFutureを知ったばかりで、サンプルコードを読んで動かして、関係しそうなクレートのコードを読んで試行錯誤して…と、あまりスマートじゃないやり方でしたが、徐々に馴染んでくると、「コンパイラに怒られて直して、動かすとちゃんと動く」というRustの開発体験が非常に心地よく感じるようになってきました。怒られ続けて丸二日、みたいなときもありましたが…。

そのような日々を経て、バックエンドでプロダクトをローンチできたときは、感激もひとしおでした。そんなこんなの体験談をShinjuku.rsに投下していたら、松本さんに執筆のお声がけをいただけたので、これはもう是非!という形で引き受けていました。その後は冒頭に書いた通りです。

おわりに

『実践Rustプログラミング入門』は、発売後すぐに非常に好評をいただき、2週間経たずに増刷が決まりました。これには、Rustや競プロ界隈で名を知られた共著者の方々のおかげによるところが大きいですが、私も仕事での立場上、他社の人と関わることも多いので、この本を持ってRustを世の中の企業にもっと広めていければいいなと思います。

iPad Proを買いました

今まではカフェに入ってMBPを開いてiPhoneテザリングして…とやっていたのだけど、席についてiPadを開くだけでもうそこにほぼMac相当の環境があるってのは結構すごくないですか。(SIM入れられるやつなので)

プログラミングするには環境構築が結構大変そうだけど、何か見たり文章を書いたり、だと全然問題ない感じ。画面がiPhoneに比べて大きいから目の前にMacBookがあるような感覚でとてもよい。

しばらくヘビーに使ってしまいそうな予感。

Rust LT #7 発表資料まとめ

話を聞く側で参加してきました。懇親会には出られなかったのでブログでまとめとく。 rust.connpass.com

冒頭κeenさんのPCに合うコネクタがなくて発表順が変わったりしましたけど、プロジェクターへの出力はよくトラブルが起こるところですね。私のMBPも、Forciaさんとこで発表するときは何故か画面出力できない。ChromeCastとか使うと解決できるかもしれない。

話題のGUIツールキットOrbtkを読む

redox-osに組み込まれているGUIツールキットだそうな。Pure Rustだからブラウザでも見られるんですよー!と言われてコマンド一発でブラウザに表示してたのが本筋ではないながら一番びっくりした。

cargo-nodeってやつだそうで。こういう便利cargoコマンドもっと知りたい。

github.com

RustでJVMを作成してみた

JVMの仕様書って公開されてるんですね。ってわかってても実際に作っちゃうのはすごいです。

Rust for neuRo-simulation

自分がよく知らない分野の研究でRustが活用されている話だったので用語とかも興味深かった。口頭では淡々と話しつつ、スライドがコミカルでアニメーションしたりするのは面白いやり方。

rustfmtの中の人の発表(タイトル失念)

github.com

2019年の活動の振り返りと今後について話されていた。Rustのコードを書くときはもはや空気のように使っているツール。いつもお世話になっております。

そういえば最初の発表者のrchaser53さんもrustfmtの結構なコントリビューター。そういう人たちに会えるこういうイベントはいいやね。

Rustで作るTUIアプリケーション

資料見当たらず。

先月のShinjuku.rsでもターミナルアプリケーションの発表があったけど(tui-rsを使ってたかどうかは失念した)、GUIアプリケーション開発に馴染みが少ない(勝手なイメージ)Rustならではの面白いアプローチですね。

DNN CompilerをRustで書く

AI将棋とかR1に出たり、とかアクティブかつ話慣れてらっしゃる方だなぁと思った。

それはさておき、DNN推論するのにRustでPyTorchを上回れるってなにげにすごいのでは。理論力と実装力が両方必要そう。

Rustによる類似画像検索

RustにそもそもImageクレートなんてものがあることを知らなかった無知な私です。類似画像検索ってのは今まであまり必要になったことはないけど、大量の猫画像を整理するのに便利かもしれない。

同社内の営業からの金にならない仕事依頼への対策案

そもそもの背景

飲んでたときに同席者(とある企業の研究者)が、「営業が金にならない仕事を丸投げしてきて対応するのがつらい」とこぼしていたので、対策を考えていました。こういう、部門をまたいだ面倒事は管理職がちゃんと交通整理して然るべきですが、十分機能してなさそうなのでボトムアップで提案してみれば、と書いてみました。

というわけで以下が本文。

用語定義

以下では、営業部門で顧客からの仕事を投げてくる人を「営業」、受ける側の人を「研究者」と記載します。

営業側の困った振る舞い

  • 大企業相手の営業で、重要案件をゲットするための関係維持の口実とかで、何かしら細かい調査とかを振ってくる
  • その仕事で顧客からお金をとろうとしない

研究者が困っていること

  • 営業の顧客関係維持に役立っているだけで、技術的蓄積もあまりなく、研究者側の大した成果にもならない
  • 研究者側は営業から軽視されていると感じている
  • 結果、モチベーションもあがらない

想定される営業側の言い分

  • 最終的には会社全体の売上につながる
  • 研究者も実務に貢献できるしいいだろう
  • 顧客とは保守契約を締結していてその工数の範囲内だ
    • 結んでるかもしれないし結んでないかもしれない
    • 研究者側は、そういうことあんまり教えてもらえないよね

困った営業への対策

オススメの運用

メールなどで作業依頼が降ってきたら、「では、まず見積りしますね〜」と返す。見積りするのにかかりそうな時間は、このときに伝えておく。(明日まで、とか出張が入るので来週月曜日に出します、とか)

見積りを作成したら、次項の※1で洗い出したデータや仕様とともに提示。「これこれのデータをもらって内容を○日で確認したら、着手できる日をお伝えしますね」と一旦返信。着手したら何日でできるか、は見積りに含めておく。

作った見積りは、チーム内でリストにして管理しておきましょう。

具体的な内容は次項以降に記載します。

仕事が降ってきたら、まず見積りをしよう。

「○○なデータの傾向分析」だと仮定

  • タスクを細分化する
    • データの受け取り&内容不備の確認
    • プロジェクトの作成(管理用ディレクトリやリポジトリなど)
    • データの前処理
    • 実装
    • 学習、チューニング・・・etc
  • 見積りする中で、とある工程の作業に必要なデータを全部洗い出す(※1)
  • 各工程の工数と、労務単価をExcel等で整理し費用としてわかるようにして提出

個別の見積りを行ったら、チームで「外からの仕事の依頼」に対する見積りをリスト化する。

  • 基本事項:案件名、工数労務単価、原価(工数労務単価)
  • 一緒にまとめておくといいもの
    • 作業の難易度(研究者での作業が必要か、他の人でもできるか)
    • 依頼された作業によって得られるもの(ないならない、と書いておく)
    • 作業の支障になったこと(必要なデータの提供遅れ、営業側の動きが悪くて期限前に詰めた、など)

見積りをする運用にすると何がいいのか

  • 詳細に見積りをする中で(※1で)、あらかじめ先方からもらっておくデータや仕様を明確にすることで、着手してからあれくれこれくれと言わなくても済む
  • 少なくとも即日着手というのはできなくなるので、依頼する側も余裕を持って依頼するようになる(はず)
  • 営業側に「その作業依頼で、実質○○円分の稼働がかかってんだぞ」を可視化できるようになる
  • いずれはそれを元に営業部門と交渉する材料になる
    • 営業とその先の顧客に「○○円分の価値」を提供しているということを明示することで、営業に金をよこせ(金をもらってこい)と言える
    • 余計な作業を振るな、とも言える
    • 営業へのメリットもある
      • 作業リストは、もし営業が顧客と保守契約を結んでいるのであれば、顧客への保守費用上乗せの材料になる
      • 研究者に依頼する必要がある仕事とそうでない仕事がだいたいわかるようになる(業務委託PGを一人雇っておけば解決できるとか)
      • (研究者にとっての)定型業務をシステム化することで効率化する、という社内案件も作れるだろ

実際のチーム運用への適用

チーム内で合意をとろう

いきなりひとりだけでやり始めても、営業から上長にクレームが来るだけなので、最初のステップはチーム内で合意を得る必要がある。ここは慎重に。

チーム内打ち合わせの場が定期的にあるなら、「こういう営業に困ってて、それへの対策を考えてきた」と提案してみる。

見積り作業という手間が増えるので、反対する人も出るかもしれない。だけど、それすらやれない人はそもそも仕事ができないとか云々言う。スキルが属人化の懸念とかもある。

提案者自身が一番困っている立場であれば、上長(できれば管理職)に「自分が困ってるのでこうしたい。営業から文句言われたらかばってほしい」と味方につけておこう。上長・管理職以外で反対する人がいたら「てめえらが困ってねぇってだけで反対するな。俺が困ってるんだから助けろ。」と強引に進めるのもあり。ただし、最初に管理職を味方につけようね。

合意がとれたら営業に伝えよう

短期間にポコポコと営業から依頼が振ってくる状況であれば、合意がとれた次の依頼から以下のように返してみよう。

「チームの方針で、細かな依頼でも、見積りを作成することになりました。つきましては、まず見積りしますので○日ください」

てな感じで。で、上記の「オススメの運用」の内容を進めていく。

力こそパワー

上長よりもっともっと偉い人とも仲良くなっておきましょう。周りが敵だらけになったら、上長ごと力でねじ伏せてくれます。

技術書典7に参加してきました(機械学習の炊いたん2)

Twitterにいろいろ書いてしまったので引用しながら手抜きしますごめんなさい。

技術書典7は終わりましたが、Boothで引き続き購入できます。

tomo-makes.booth.pm

戦利品、他のサークルの書籍の感想など

おまけ

こつこつとコードを書き続けるためのプログラミング問題集

はじめに

半年ほど前に転職してから、ソフトウェアエンジニアとしてコードも書く立場となったのですが、やはり、長年コードを書き続けていた人とブランクのある私では、コーディングスピードが圧倒的に違ってきます。

もちろん、業務のバックグラウンドの知識の差もありますが、「コードを書くスキル」に関しては、ある程度は「どれだけの量、書いて動かしたか」だと思っていますので、極力毎日少しでもコードを書くようにしています。(書かないと覚えられないタイプ)

ただ、毎日とれる時間のばらつきや、ネタ切れなどありますので、手軽に書ける問題がたくさんあるサイトがあると重宝します。本記事では、私のよく使うサイトを紹介します。

Project Euler

projecteuler.net

コンピュータで解く数学の問題集サイト。アーカイブの最初は割と簡単なところから始まり、徐々に難易度が上がっていく。

私は50問を過ぎたぐらいから解くのに時間がかかるようになってしまい、別の言語で同じ問題を解く横展開ばかりしてしまって解答数の進捗が停滞気味…。

ただ、新しい言語を覚えるときは、ざっと言語仕様を眺めたあとは、実際に手を動かすために問題を解くというのが、最近の自分のお決まり手段になっているのでやってみるのがいいと思います。

上手くアルゴリズムを書ければ、1分以内には解けるように問題ができてる、と一応書いてある。

言語処理 100本ノック

www.cl.ecei.tohoku.ac.jp

言語処理、文字列処理に関する課題がステップ・バイ・ステップで列挙されています。私はまだ20問ほどしか解いていないですが、Project Eulerに疲れたら合間に言語処理100本ノックを、みたいな感じで少しずつ解いています。

AtCoder過去問

AtCoderの過去問を解くのもよいと思います。

非公式ですが、過去問をまとめているサイトや、最初に解くべき問題のリストをまとめてくれている人がいるので、参考にさせてもらっています。

ちなみに、筆者も何回かAtCoderに参戦したことはあるのですが、制限時間に追われて問題を解くのは苦手のようで、ズタボロでした。しかしそろそろ、半年ぶりぐらいにやってみてもいいかも。

qiita.com

今後やってみたいもの

画像処理100本ノック

GitHub - yoyoyo-yo/Gasyori100knock: 画像処理100本ノックして画像処理を画像処理して画像処理するためのもの For Japanese, English and Chinese

画像処理もあまりやったことがないので、体系的に経験できるといいなーと思っています。あと、音声処理もほしい(自分で作れ)。

Modern C++チャンレンジ

タイトルはC++ですが、Rustでもやってみたいと思います。

Modern C++チャレンジ ―C++17プログラミング力を鍛える100問

Modern C++チャレンジ ―C++17プログラミング力を鍛える100問

ディープラーニング∞本ノック!!(2019/05/12追記)

教えてもらいました。

github.com

おわりに

できる人はこういう問題集も一気にやっちゃうんだと思うのですが、最初はできなくても少し経ってから再度解くとわかるようになっていたり、てなことも多々ありますので、こつこつと忘れずに続けていくのが肝要です。

モチベーション維持のために私がやっているのは、進捗を見えるように、解いた分をスプレッドシートに記録していく、というものです。毎日一個ずつマルを付けていくと、だんだんマルの部分が増えていくのが楽しみになります。

さいごに、こういうのもあるよ、という問題集サイトの情報をお持ちの方がいらっしゃいましたら、情報いただければ小躍りします。

技術書典6へ参加してきました(「機械学習の炊いたん」寄稿と買い物)

参加したのは先週4/14。あっという間に1週間経っていましたね。

初出展

機械学習をテーマにした合同誌に寄稿させていただきました。

booth.pm

といっても、わたくし機械学習はとんと素人でして。

たまたま発起人の@tomo_makesが私の昔の同級生だったことから、声をかけてもらいまして、でもガチ勢の人たちに追いつく時間もないので、

  • 第1章:あやめ(猫)を画像認識してみるチャレンジ(そして失敗してあやめ画像でごまかす)
  • 第3章:機械学習を新たに学んで転職・採用のためのコラム

の2本を勢いでガーッと書ききって恥ずかしげもなく売りさばきました。

おかげさまで、紙の書籍は完売し、引き続き現場とBOOTHでの電子版の売れ行きもなかなか好調です。私以外の執筆者のみなさんのおかげというほかない、ほんとに。

よかったら上記のBOOTHへのリンクから、サンプルで目次を見ていただいて、興味がある方は購入いただけるとありがたいです!あやめのおやつ代になります。

本書内で散見されるあやめ見せびらかしの例

f:id:emergent:20190422024105p:plain f:id:emergent:20190422024304p:plain

その他の出展について

技術書典自体、前回以上に人がたくさん来ていたようです。13時までの入場が有料化したにもかかわらず、12時過ぎまで行列がはけなかったようですしね。

売り子の合間に見て回るのも一苦労でしたが、なんとか素敵な本の数々を入手することができました。少しずつ読んでいく楽しみ、積まれていくつらみを味わえるなんてなんという幸せでしょう。

次回、技術書典7に向けて、(今度こそ技術書にふさわしい内容を携えて)早速準備していきたいと思います。