作業ログのすすめと知見

去年ごろから作業ログを毎日書き始めたのですが、おすすめの書き方やサービス等の知見が溜まってきました

目的

半年近く日々の作業を記録に残してきて、以下のような意義があると感じています

• 昨日や一昨日までの進捗が一目見てわかるので、今日何をすべきかを瞬時に気づくことができる
• １か月後等に「自分１か月前は何をしていたっけ？」となったときにすぐに思い出せる
• アイデアに到達した道のりをいつでもたどることができる

特に三点目に関しては、アイデアが乱立してきたときに「結局、自分は何がやりたかったんだっけ？」とならないために重要だと感じています

書き方

作業ログは書き方のようなものはありませんが、前述の意義を発揮するために「毎日続ける」ことが必須の要件だと考えています

「毎日続ける」というのは思ったよりも労力が必要で、かく言う私も大抵のことは三日坊主ぐらいで終了します

そんな私が作業ログを毎日続けられているのは以下のような要件を満たしているためだと思っています

• 一日あたり1分以内に記述が完了する
• 書くための労力が最小限
• 何を書くかに関するフォーマットが決まっている

三点目に関して、例えば私は以下のようなフォーマットで書いています

- やったこと
  - [x] 研究した
  - [x] 睡眠した

サービスの選定

作業ログは何かの記録媒体に保存するわけですが、その記録媒体を何にするかというのは割と重要な問題です

自分の場合、前項の3つの要件を掘り下げると以下のようになりました

• 一日あたり1分以内に記述が完了する
  • 自分はMarkdown形式が一番書きなれていて、最速で入力がおわる
  • よってMarkdown形式で保存できるサービスがいい
• 書くための労力が最小限
  • 「書くぞ！」と脳で考えてから最小の入力数、クリック数で作業ログの記述を開始できる
• 何を書くかに関するフォーマットが決まっている
  • この点はMarkdown形式を満たすものであれば即座にフォーマットを作成できるので、あまり気にしない

結論から言うとHackMDを使うことが最適解だと気づいたのですが、その気づきに至るまでの変遷を記しておきます

1. VSCode

シンプルにVSCodeを使ってMarkdown形式で書いていました

ただ、以下のような不満点があり、次のサービスへと移りました - 普段別のプロジェクトを開いている関係上、作業ログを書くために次のような労力が必要

1. プロジェクトを閉じる
2. 作業ログが入っているフォルダを開く
3. 作業ログを開く

• 出先で書こうと思うとファイルの同期が面倒で、それを解決するためにさらに労力が必要

2. growi.cloud

ファイルの同期が面倒な問題を解決するために、Webベース、クラウドベースで管理したいと思うようになりました

growi.cloudとはMarkdown形式で記述でき、エントリを階層管理できる情報共有ツールGrowiのSaaS版です

growi.cloudは要件をほぼ満たしていたのですが、次のようなことを思いました

• 作業ログのエントリに到達するまでに若干の労力がかかる
  • エントリまでのURLをどこかに保存しておけばいい話なのですが、それ自体をどこに保存するかといったことが問題に
• 自分で Ctrl + Sを押さないと保存できない
  • これは完全に個人的な問題なのですが、保存し忘れたときに入力した内容が飛んでいると非常に萎えます

SaaSではない版を導入してCodiMDと一緒に使うことも検討したのですが、自分しか使わないサービスにそこまで労力を使いたくないなぁ～と思い、他のサービスにしました

3. HackMD

現在の最適解だと思っているHackMDです

HackMD(CodiMD)はGrowiでも使うことのできるMarkdownが書ける共同編集ツールです

今現在メリットと感じているのは以下のような点です

• （既にログインしていれば）ブラウザにhackmd.ioと打ち込めばよく、複数の作業ログ間の移動もより少ないクリック数でできる
• Ctrl + Sを押さずとも保存してくれる
  • 小さい利点のようで実は大きく、エネルギーが尽きかけでログを書くようなときに非常に役に立ちます

まとめ

長期的な目線で～月に～をしたということは覚えていても、日ごとに何をしたかというのは記憶しづらいです

上記で示したサービス以外でもサービスは多様にある(ScrapboxとかNortionとか)とは思うのですが、こと作業ログに限っては時系列のつながりが物理的な上下でみられるMarkdownで書くのが自分は一番良いと思っています

みなさんの作業の振り返りをする一助になれば幸いです

就職することにした

自分は現在B4で、昨年から大学院に進学するか、就職するかで迷っていたのですが、この度就職することにしました

迷っていた時に相談に乗っていただいた方、ありがとうございました

判断に至った経緯や理由を自戒のために残しておきます

2020年6月

このころから夏季インターンシップへの応募が始まり、進路を色々と考えるようになりました

また、セキュリティ関連の仕事がしたいなぁとぼんやり思い、2社ほどのインターンシップに応募しました

2020年8月

6月に応募した会社のうち、1社が選考を通ることができたので、5日間ほどのインターンシップに参加しました

そこで、以下のような事を思うなどしました

• セキュリティ（インターン先で行ったのは脆弱性診断の演習的な内容でしたが）は業務にしても楽しい
• 子会社/下請けは嫌だなぁ...
  • これに関しては主語がでかすぎるとは思っているのですが、元々がブラックボックスになっているものをいじるよりかは、その元々の部分を開発なりしたいなぁと思うようになりました

2021年1月

SecHack365での開発も佳境に入ってきて四六時中ソフトウェア的なものづくりをしているうちにセキュリティ的な仕事だけでなく、開発職もいいなぁと思うようになりました

ただ、研究駆動の人たちの姿をみているうちに研究(≒大学院への進学)もいいなぁとも思うようになり、迷いが本格的に出てきたのでSecHack365のトレーナーやトレーニーの方に色々相談を持ち掛けました

そこで頂いたアドバイスの中に、「研究室に配属されないと研究の雰囲気は分からないと思うので、就活も同時並行で進めておいて、4～5月あたりに決めるとよい」のようなものがあり、自分でも確かにそうだなと思ったため、就活も同時並行で進めることにしました

この時期に前から気になっていた2社ほどに応募しました

2021年4月

SecHack365も修了し、新学期が始まり、研究室にも配属されたころ、応募していた企業の中から内定を頂きました

内定を頂いたからには内定受諾の如何を返答する必要があり、おおよそ2週間ほどず～っと迷っていました

結果的には内定を受諾したわけですが、以下に主な理由を書きます

• 大学院の授業に興味を持てなかった
  • B4になり、本当の意味で自由に授業が取れるようになったのですが、僕の興味分野に合致するような授業を見つけることができなかった(し、過去を振り返ってもあまりない)ため、大学院も...と考えてしまいました
  • これに関しては、完全に僕の授業に対する積極性があまりないことが原因だと思っています
    • その気になれば他学部/他大学履修をすればよかったのですが、魅力的な授業を発見する労力よりも自学自習をしたほうが楽しいし、役に立つという考えに至りました
    • 他大学の大学院への進学も考えたのですが、上記の理由により候補から除外しました
• 自分に必要なことは実務上の知識だと感じた
  • これはSecHack365の活動中に感じたことなのですが、自分には「実際に試してみた」系の経験が足りないと感じました
  • 解決策としては、「実際に試している/現在進行形で使っている」コミュニティ（勉強会/職場/サークルetc...）に飛び込むのが一番だと考えているのですが、その中でも職場が今求めているものに一番近いと判断しました
    • ただ、これは大学院に進学して、長期インターン等によって得られるものと同等な気もするのですが、内定を頂いた後（＝本当の実務で経験できる可能性が確定している）に考えているため、内定を受諾するという判断に至りました
• 自分を認めてくれている気がした
  • 就活の面接において「自分の成果物をプレゼンする」という機会があったのですが、プレゼン後、面接官の方からは内容を理解したうえで成果物に関するアドバイス等をいただくことができました
  • 研究室の教授に大学院への進学の如何を相談した際に、「大学院には有無を言わせず行くもんだ」的なアドバイス(?)を頂いたのですが、「なぜ」大学院に行くかに関する理由を見出せない以上、自分の主義信条上、行くべきでないという判断に落ち着きました
    • 何年か経った後に結果的に「有無を言わさず」大学院に行ったほうがよい(学歴や経験の面からみて)ということはなんとなく理解できるのですが、目的も目標もなく2年間を過ごすのは何か違う気がしています

上に色々と書いているのですが、要点をまとめると以下の通りです

• 大学院での研究/研究に臨む環境に興味を持てなかった
• 実務で得られる知識が必要だと感じた

よって、就職した後、大学院での意義を見出すことができたなら、途中で退職なりをして大学院に進学することも可能性としてはありなのかなとも思ったりしています

まとめ

振り返ると、もし落ちたら大学院へ行くいい理由ができたぐらいに(途中まで)考えていたため、本選考に応募したのは実質1社と、かなり挑戦的な就活だったような気がします

結果的に就職することにしたわけですが、これは時期の問題だとも考えています

自分の所属している学科では学部3年の後期から研究室に仮配属という形で活動をし始めるのですが、コロナの影響で対面の機会がなく、研究室MTG等でWebカメラを有効にすることが義務付けられていないため、研究室の先輩の顔も知らなければ、同じ学年の顔もほぼ知りません

仮に内定が出る時期が遅い、研究室での積極的な活動がある等、研究室の雰囲気や研究とは何かに関することが既に感じられていたならば、決断は変わってきたような気がします

SecHack365を修了しました

先日、2020年度のSecHack365を優秀修了生として修了しました。

開発駆動コース 仲山ゼミに参加しました。

#SecHack365 修了しました

— ユクロ (@kurokuro_dev) 2021年3月5日

SecHack365とは

若手セキュリティイノベーター育成プログラム SecHack365は、25歳以下の学生や社会人から公募選抜する40名程度の受講生を対象に、サイバーセキュリティに関するソフトウェア開発や研究、実験、発表を一年間継続してモノづくりをする機会を提供する長期ハッカソンです。 全国の一流研究者・技術者や受講生等との交流をするなかで、自ら手を動かし、セキュリティに関わるモノづくりができる人材 (セキュリティイノベーター) を育てます。

開催概要 | SecHack365 より

SecHack365とは、NICT(国立研究開発法人情報通信研究機構)が主催する長期ハッカソンです。

トレーニー(受講者のこと)はトレーナー(指導者のこと)の指導・助言のもと、約一年間の期間で何かしらのものづくりをします。

今年はコロナの影響で実質８か月程でしたが、ハッカソンといっても放任主義のようなものではなく、具体的には以下のようなイベントがあります

• イベントデイ
  • イベントデイはほぼ毎月開かれるイベントで、一年間の序盤～中盤ではトレーナー以外のすごい人を招待して、その人の話を聞いたり、トレーナーの得意なテーマについての議論をしたりしました
  • 終盤では、作った作品をトレーナーやトレーニー陣に見せてフィードバックをもらう、展示会的なものがメインでした
• ゼミワーク(以下ゼミ)
  • ゼミは所属コースによって大きく変わりますが、私が所属していた開発駆動コースでは、毎週ZoomでMTGを開き、それぞれのやったことや得られたものを発表し、トレーナーからフィードバックをもらうようなことを行っていました

1年間の流れ

応募時

応募した動機は以下の２点です

• TwitterのTLで去年度のトレーニーを見ているうちに、楽しそうだな～と思った
• その時、ちょうど「ゼロトラストネットワーク」を図書館で読んでいて、（引きこもり的性格も相まって）ゼロトラストネットワークを家に建てられたらなぁと思った

7月～9月

• 開発駆動コースの仲山ゼミに合格しました
• ただ、この時期は開発駆動のくせに、ろくな開発をせず、OpenIdとかTPMとかについて調査ばかりしていました
• 調査やトレーナーからの助言を頂いているうちに、テーマが二転三転しました...（二転三転に付き合ってくださったトレーナーの仲山さんや横山先生、ありがとうございました）

10月～12月初め

• 「ゼロトラストな考え方」が気に入っており、それを実現したいと思うように
  • 「ゼロトラストネットワーク」の本を読んでいたこともあり、"ネットワーク"の部分に固執していた節があった気がします
• 同じ時期に技術書典で購入したDIDに関する本を読み、DIDに興味を持ちました
• ただ、様々なDID Methodのプロダクトのデモを試しているうちに、取り巻く環境が面倒だなぁ...と思い、それが成果物への大きなモチベーションになりました

12月終わり～3月初め

• 最終発表会などの外部に向けて公開する、重要な発表機会が重なり、締め切り駆動がだんだん加速していきました
• その結果として、優秀修了生に選んでいただきました
  • これは技術的に優れていたということはなく、表現の部分が主に評価されたのかなと自己分析をしています（そういう意味では全てオンラインの今年だからこそな気もします）
• このあたりから、作業ログ*1を付け始めました
  • 今まで、ゼミの取り組みとして毎週おきに進捗は取りまとめていました
  • いつかのイベントデイの講演にて「習慣化のコツは（進捗の）傾きをゼロにしない」という話があり、傾きをゼロにしないため + それを残しておくために、毎日やったことを書くようになりました
  • 前日までの進捗 + やるべきことが一目見るだけで思い出せる等のメリットを感じているため、現在も続いていますし、今後も続ける気がします

成果物

僕がSecHack365で作ったものはCassisというDID(Decentralized Identifiers)をカジュアルに扱うツール Cassis です。

DIDって面倒だなぁ…というのを大元のモチベーションにして、DIDをぱっと使えるCLIツールを作成しました。

成果物のポスターはこちら

身についたこと

問題を見据える力

以前まで製作物を作る際のモチベーションとしては「作りたいから作った」というような衝動的なものが多かったのですが、SecHack365を通じて「～という問題があるから作った」というようなものに昇華できた気がします。

また、これは「～という問題があるから～を作ろう」というアイデア出しの部分だけでなく、今まで作ってきたものを再考するきっかけにもなっている気がします

任意の相手に適切に伝える力

今までの自分は

相手に伝える労力　＞＞＞　それの対価として得られるもの

と考えている節があり、自分のやっている分野に興味のない人には適当に説明して済ますようなところがありました

しかし、SecHack365では沢山の発表機会（毎週のゼミや内輪での発表会、外部向けの発表会etc...）があり、その過程で以下のような、伝えることに対するメリットに気づくことが出来ました

• 量が多く、質の良いフィードバック
• ふとしたとき（アイデアに詰まった時など）に、こちらの状況がわかっているので助けられることが多い

このメリットに気づいてからは、人に説明するときに積極的に伝える努力をしました。例えば、以下のようなことです

• 動画形式の発表では、動画に字幕をつける
  • 発表内容を理解する以前の問題（言葉が聞き取れなかった、専門用語を聞いてもググれない等）をなくすため
• 専門用語を伝える相手によって置き換える
  • これは経験則的な視点なのですが、専門用語の意味を逐一丁寧に説明するよりも、何か平易な単語に置き換える方が理解されやすかったです

全体を通して

SecHack365は僕に成長の機会を与えてくれたイベントでした

僕の場合は、技術的な成長よりも価値観の成長や心理的な支えになっていた面が大きいと感じています

また、人によっては（というのも僕は積極的なコミュニケーションというのが大の苦手で、懇親会的な出来事を半ば拒絶していた節もあるので...）全国から集まるトレーニーとの交流も大きな魅力だと思います

応募するかどうかを迷っている方がいれば、とりあえず応募するのがよいと思います！

*1:現状としてHackmdに書き溜めているのですが、行数が増えるとレスポンスがガタ落ちするので、良い感じのサービスを探索中です...

Aries Cloud Agent Pythonでハマった点まとめ

Aries Cloud Agent Python(ACA-Py)とは

Aries Cloud Agent Pythonは非モバイル環境でDID(decentralized identity)のアプリケーションやサービスを動かすための開発環境です.

DIDに必要な処理がREST APIの形で提供されているので、APIを叩くだけでDIDが出来るようになります.

ハマった点

ACA-Pyは非常に有用な開発環境なのですが、デモに載っていない範囲が存在したり、ドキュメントが散逸していたりと、若干不親切です.

学習ついでに実装をしている中で、実際にハマった事がわりとあるので、備忘録的にまとめます.

なお、使用しているバージョンは 0.5.6 で、Ledgerはvon-networkを想定しています.

Ledgerとのやりとり

DIDに関して学習する際にACA-Pyのデモを参考にすることが多いのですが、（恐らくACA-Pyの範囲ではないため）デモではLedgerとのやり取りに関しては明示的には触れられていません

具体的には次のようなことです

• LedgerへのPublic DIDの登録
• LedgerへのSchemaの登録
• LedgerへのCredential Definitionの登録

Public DIDの登録

von-networkの/registerに以下の内容のようなjsonをPOST

{
    "alias":"issuer1",
    "seed":"gLyjhihWzueCSkCygJEJdyzNHWMSPStM", //32byte
    "role":"TRUST_ANCHOR"
}

Schemaの登録

ACA-Pyのadministrative APIの/schemasに以下のようなjsonをPOST

{
    "attributes": ["hoge", "fuga"],
    "schema_name": "hoge",
    "schema_version": "1.0"
}

Credential Definitionの登録

ACA-Pyのadministrative APIの/credential-definitionsに以下のようなjsonをPOST

{
    "revocation_registry_size": "1000", //0にすると怒られる
    "schema_id": "hoge", // ↑のschemaを発行すると発行される
    "support_revocation": "false", // revocation(失効)を有効化するかどうか
    "Tag": "hoge"
}

issue-credential

Issue credentialの定義に関してはAries RFC 0036に記載があります.

これによると

Note: In Hyperledger Indy, where the request-credential message can only be sent in response to an offer-credential message, the propose-credential message is the only way for a potential Holder to initiate the workflow.

とあるので、いきなりCredentialをIssueするrequest-credentialは(Hyperledger Indyでは)ダメらしい （ACA-PyのデモではいきなりIssueしてたような...? 明示的に行われてないだけで、勘違いでした）

なので、ここではHolderがproposal-credentialをIssuerに送るフローを想定します

proposal-credentialするには

proposal-credentialするには、Holderのadministrative APIに以下のjsonをPOSTします

{
    "connection_id": "hoge-hoge-hoge-hoge-hoge", // connectionを確立した相手のconnection id. /connectionsで確認可能
    "cred_def_id": "hoge:3:CL:15:default", // ↑で定義したcredential definition id
    "credential_proposal": {
      "@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/issue-credential/1.0/credential-preview",
      "attributes": [ //罠
        {
          "name": "name",
          "value": "Yukuro"
        },
        {
            "name": "number",
            "value": "12"
        }
      ]
    },
    "issuer_did": "hoge", //issuerのDID
    "schema_id": "hoge:2:test-schema-01:1.0", // ↑で定義したschema id
    "trace": false
  }

なお、connection_idとcredential_proposalの箇所以外は全てoptionalらしいです

このjsonですが、attributesの箇所が割と罠だと個人的には思っています

というのも、attributesのnameにはschemaの属性名を、valueにはセットしたい値をいれるのですが、自分はattributesと書いてあるので以下のようなjsonのように書くものだと思いこんでました...(なので、気づくまでに1日溶かしました)

"attributes": [
    "name":"Yukuro",
    "number":"12",
]

このproposal-credentialを発行するとcred_ex_id(credential exchange id)というものが発行されるので、それを各エージェントのAPIで扱うという流れになります

おわりに

DIDは、ただでさえ新たな分野で参照元が少ないのに加え、ググることが大変に難しい(doの過去形としてヒットする)ので学習するのに割と苦労しています

今後もこのようなハマりポイントは出てくると思うので、追記したいと考えています

(あと、マサカリもお待ちしています)

Amazfit band 5のバンドを交換した

先日購入したAmazfit band 5のバンドを交換した。

Amazfit band 5をナイロンバンドに出来た〜 pic.twitter.com/wWmAw3BG3w

— ユクロ (@kurokuro_dev) 2020年12月2日

• バンドの部分はAmazonで購入したナイロンバンド
• 接続部(Amazfit本体を埋め込むやつ)はCheetah TPUを使用して3Dプリンターで刷った

なぜ交換したか・作ったか

• Amazfit band 5に付属のラバーバンドだと肌荒れが起き、かゆくてたまらなかった
  • ナイロン製のバンドは肌荒れが起きにくいという噂を聞いたため
  • Apple watch等のデフォルトでラバーバンドが交換できるようになっているスマートウォッチを買う資金がなかった
• Thingiverse等でAmazfit band 5用のファイルが見つからなかった

製作

• 作ったのはAmazfitを接続する部分だけ
• Fusion360で設計してEnder3で出力した
• バンドとの接続にはフィラメントをそのまま通して、はんだごてを使ってTPUで刷った部分と共に溶着した

交換後

• ナイロンバンドはめちゃめちゃ快適
  • さらっとしているし、蒸れない
• 割と不格好になってしまったが、少なくとも冬のシーズンは服の袖に隠れるし、妥協することにした

• 今回作成したデータはThingiverseで公開しているので、気に入ったバンドがあれば適当に付けられる

  • Amazfit band 5 replacement kit by yukuro - Thingiverse

• フィラメントによる溶着を初めて試したが、割と耐久性があって驚いた

技術書典9で3Dプリンタの本を出した

技術書典9で3Dプリンタの本を出した

現在行われている技術書典9において、3Dプリンタの本を出しました。

techbookfest.org

本の紹介

出した本では「Ender3の改造を通じて3Dプリンタに詳しくなる」ことを目的として以下の内容を書きました。

• ノズル/ホットエンド(Microswiss All Metal Hotend kits)の購入/交換方法
• モータードライバ(TMC2208)の購入/交換方法
• マザーボード(SKR v1.3)の購入/交換/配線
• Octoprintの導入
• Klipperの導入/設定

また、付録として以下の内容も書きました。

• 3Dプリンタの各部名称
• 3Dプリンタの仕組み
• Curaの設定/フィラメントごとのプロファイル

主に自分がEnder3を買ってからBLTouch(3DTouch)をつけたり、Octoprint/Klipperを導入したりする流れをまとめました。

なので、最新の情報かと言われると微妙ですが、3Dプリンタに興味をもつ or 改造を始める第一歩になれば良いなと思い書きました。

付録として3Dプリンタの基礎に関する説明も入っているので、これから3Dプリンタを始めようとする方にもおすすめです。

書いた動機

技術書典には秋葉原通運会館で行われていたころから色々技術書を買っていたりしたので、いつか自分で書いてみたいなぁと思っていました。

ただ、物理本を印刷する手間（印刷代、紙面の調整etc...）を考えると敷居が高いし、せっかくの即売会なのに電子版のDLカードだけ持っていくのもなぁとも思っていました。

しかし、技術書典9になるとオンラインであるためか

• 販売手数料が無料（売上が20万円以下の時）
• 電子版が中心(?)

になっており、これは出すしかない！と思い、サークルとして出展するに至りました。 あと、コロナの影響でバイトが消えたので収入が欲しかった...

書いた環境

執筆にはRe:VIEW+GitHub ActionsとTechboosterさんが出してくださっているRe:VIEW-Templateを使用しました。

Word等で書いてもよかったと思うのですが、ある程度モダンな環境で書きたいし、Re:VIEWを使用して技術書を書いている方が割といたのでRe:VIEWを使いました。

レビュー環境

今回は何名かの方に書いた書籍のレビューをお願いしたのですが、最終的なレビューの環境にはGoogle Driveのコメント機能を使用しました。

理由としては、GitHubを普段使わない方が多く、その負担から本来出るはずのレビューが出てこない懸念があったためです。

ただ、Google Driveに一々レビュー対象のPDFファイルを手動で上げたりしていたので、次回書く時までにはいろいろと整備したいですね。

感想

思っていたよりもずっと簡単に技術書を書くことが出来ました。

今のところ、想定していたよりも多くの人に読んでいただけて、感動するばかりです。

次に技術書を頒布できる場所が出来たら、是非参加したいです（そのためにはネタを仕入れなくてはならないのですが...）

SORACOM Summer Challenge 2020で不快指数通知デバイスを作った

SORACOM Summer Challenge 2020に参加してきました

作ったもの

Challengeの中では以下のような不快度通知デバイスを作りました

• GPSマルチユニットから温度と湿度をもとに不快指数を計算し、不快指数が80以上ならSlackに通知します