uuidgen コマンドをちょっとだけ便利にする

justInCaseTechnologiesのエンジニアの Otani です。

開発でユニークな識別子が必要な場面が時々あり、そのような場面で Universally Unique Identifier - UUID を使うことが多いです。

tl;dr

uuidgen に以下のような、エイリアスを設定して、UUID を簡単にペーストできるようにしてます。

alias uuidgen='uuidgen | tr "[:upper:]" "[:lower:]" | tr -d "\n" >/dev/stderr | pbcopy'

uuidgen コマンド

macOS には uuidgen というコマンドがあり、UUID が必要な場面で使っています。

$ uuidgen
B2907FAD-2DCC-49AC-9178-8206876A6175

基本的にはこのように大文字の出力されるのですが、私個人は小文字での表記になれているので、小文字を使いたいところ。また、出力された文字列をいちいち選択してコピーするのも面倒。

エイリアス設定

という訳で、以下のようなエイリアスを設定しています。

alias uuidgen='uuidgen | tr "[:upper:]" "[:lower:]" | tr -d "\n" >/dev/stderr | pbcopy'

uuidgen した内容をパイプで渡しながら、小文字変換したり (tr "[:upper:]" "[:lower:]")、末尾改行なくしたり (tr -d "\n") して、クリップボードに格納します (pbcopy) 。

ちょっとだけ工夫したのは、結果を stderr にも出力するようにしているところ。

alias uuidgen='uuidgen | tr "[:upper:]" "[:lower:]" | tr -d "\n" | pbcopy'

でもやりたいことは実現できるのですが、結果がターミナルに表示されなくなり、ペーストするまでどんな UUID が得られたのか分かりません。

なので、 stderr に出力することもよって結果もターミナル上で確認できるようにしています。

使い方

標準で用意されている uuidgen を上書きしているので、単に uuidgen と実行すれば良いだけです。

$ uuidgen
2df3da7d-287b-4301-ad0f-b07607f01b4b

ちなみに私個人は .zshrc

setopt magic_equal_subst

を指定しているので、 =uuidgen で元の uuidgen を実行できるようにしています。

$ =uuidgen
E34C966D-7BF1-4CBD-B989-C638302104F3

追記 2021.11.22

zsh / bash なら tee コマンドを使っても同様のことができるようです。

alias uuidgen='uuidgen | tr "[:upper:]" "[:lower:]" | tr -d "\n" | tee >(pbcopy)'

stderr に余計な出力しないので、こちらの方がよいかもしれません。

参考 : コマンドの結果を画面とパイプの両方に渡す方法

追記

状態管理どうしてますか?

justInCaseTechnologiesのエンジニアの Otani です。

3ヶ月前の話になってしまいますが、スタートアップReact LTで「状態管理どうしてますか?」と題して、発表しました。

tl;dr

justInCaseTechnologiesウェブフロントエンド、2021年7月時点での大まかな方針:

  • 小規模のプロダクトには Recoil / Jotai を使っていく
  • 中規模以上のプロジェクトでは Redux Toolkit を使っていく

スライド

サンプルコード

githubサンプルコードを挙げています。

にそれぞれのライブラリを使ったサンプルプロジェクトが納められています。

dist ディレクトリにある index.html だけ共有していますが、基本各サンプルは独立させているので、それだけ取り出してボイラープレートのように使っていただくことも可能だと思います。

各ライブラリの感想

React Context

他のライブラリに依存せず、 React だけで完結するのは強みですが、どうしても Context を設定するための記述が必要になってしまい、状態管理という本来の目的から外れた部分の実装が目に付く印象です。

Redux Toolkit

この発表した当初は justInCaseTechnologies では Redux Toolkit を採用したプロダクト・プロジェクトはありませんでした。

個人的には別の会社で以前 Redux を使ったことはありましたが、「おまじない」が多くそれがちょっと苦痛だったりしたのですが、今回この発表をきっかけに Redux Toolkit を使ってみたら、簡潔にわかりやすく記述できるようになっていてその印象が変わりました。

MobX

justInCaseTechnologies では、他ライブラリの依存関係などもあって、当初の最新版 (v6) は利用していませんでしたが、発表では v6 でサンプルコードを組んでみました。

v4 までのデコレータを多用した実装とは異なり、すっきりとした記述での実装ができるように。一方で class を使った実装から離れていくという React のトレンドとはちょっと異なる部分もあるのでちょっとしたモヤモヤ感……。

Recoil

比較的新しい状態管理ライブラリ。 atom という単位で状態をとりまとめていくスタイル。後述する Jotai も同じようなアプローチを取っていています。

この管理の仕方、管理する状態が少なければそんなに問題にならないのですが、増えてくると追いかけるのが大変になってきます。ライブラリが軽量なのもあって取り回しは良い印象はあるのですが……。

Jotai

Recoil 同様 atom 単位で状態を管理するというコンセプトのライブラリ。Recoil よりも記述量は減る傾向にあって、比較的すっきりとした実装にすることができるとは思います。

一方で Recoil でも触れたように管理する状態そのものが増えてきて、 atom 相互の関係性が複雑になってくるときつくなる印象は否めません。

発表できなかったこと

後述の通り、時間勘違いしていて、当日は全く触れることができなかったライブラリに Zustand (ツシュタント) があります。前掲のスライドでは「おまけ」として掲載。

カスタムフックの生成関数が用意されていて、作ったフックをコンポーネントで利用するという形になっています。全然知らなかったライブラリなんですが、使い勝手は良さそうで個人的には今後どこかで本格利用してみたいとは思いました。

発表を通して

発表準備のために、今回は実際にサンプルコードを組んでみましたが、React Contextを除いて、実装面においては正直このサンプルコードの規模感では、どのライブラリも大きく変わらない印象があるのは否めません(苦笑)。

一方で実際組んでみると、それぞれのライブラリの書き味は結構違うことも分かりました。ReduxToolkit を通して利用すると以前実装に使っていたときよりも全然印象が異なったのは大きな収穫。以前と比べて React 周辺の技術スタックに対しての知識が増えたのも大きいとは思いますが。

Recoil / Jotai / Zustand あたりは重量感を感じることもなく、さっと導入できそうな印象があり、個人的には今後もちょっと注力していきたいと思っています。

発表当初は justInCaseTechnologies で利用していなかった Redux Toolkit 、その後の開発案件で利用するものが出てきています。最初から中規模以上を目指したものなら、手続きに関する記述が安定している Redux はチームで開発するプロジェクトには向いている印象を持っています。

発表の反省

ライトニングトーク、発表枠 15 分ということで準備していましたが、直前の打ち合わせで質疑応答含めて 15 分ということが発覚して、めちゃくちゃ焦りました。

結局発表だけでほぼ 15 分使い切ってしまったのは大反省(おそらく、オーバーしていたはず)。次回からはちゃんと時間確認します……。

AWS DevDay Online 2021登壇のご報告

ソフトウェアエンジニアの @xhiroga です。

2021年9月39日、AWSの数多のカンファレンスで最も開発者に特化した AWS Dev Day Online Japanに登壇してきました。
資料はこちらです → [AWS CDK] 1,000+のCloudWatch Alarmsを自動生成する技術
感想を添えてご報告いたします。

TL;DR

  • 応援してくださった皆様に感謝
  • 登壇をネタに様々な人と繋がれた
  • これまでのAWS CDKに関するLTの集大成
  • Twitterの反響・よいアンケート結果

応援してくださった皆様に感謝

AWS Dev Day Online JapanはCFP制で、一般人気の高いセッションが採用される仕組みでした。
Twitterのお知り合いの皆様やそうでない方にも「見たい!」との反応をいただけたのが、今回の機会につながったと考えています。ありがとうございました!良いものをお届けできたでしょうか?

登壇をネタに様々な人と繋がれた

AWS CDKに関する登壇であったことから、周囲の知見のある方にレビューや練習を申し込ませていただきました。
コロナ禍のリモートワークの折、しばらくぶりのエンジニアの方と練習ついでに雑談もでき嬉しかったです。

また、資料レビューにはAWS CDKユーザーとして大先輩(とこれまで勝手に尊敬していた)のtmkさんにもご協力いただきました。本当にありがとうございました!
CDKアプリを我流で書いてきた自覚があったので、登壇前に客観的なご意見をいただけてとても安心しました。

これまでのAWS CDKに関するLTの集大成

実は今回初出のネタは多くなく、私のCDKに関するLTの集大成だったりします。
普段から気づいたことを細かく発信しており、それが今回の登壇につながったと感じております。

Twitterの反響・よいアンケート結果

登壇中・登壇後にTwitterで知らない方(でもCDK Loverの方)と繋がれるのが登壇の魅力だな、と思っています。
情報は発信する人に集まる、という言葉もありますしね。

登壇後しばらくして事務局からアンケートもいただき、詳細は共有できないものの(私だけで)累計数百人のオーディエンスがいたとのことでした。初めての数でびっくりしています。 (Startup Architecture of the Year 2019も 50~200人くらいだった気がするので(目測)、それよりも多い人数でした)

まとめ

いろんな方の応援のおかげで、得難い経験をさせてもらいました。
今後も社内で面白い取り組みをして発表していきたいので、その際はぜひご視聴・ご意見いただけると幸いです!

面白いSREの仕事をしたい!という方はこちらからご応募お願いします🙏

チケット管理ツール再考察 YouTrack vs ClickUP

ソフトウェアエンジニアの @xhiroga です。
保険SaaS joinsureのプロダクトを新規開発するにあたって、チケット管理ツールを再選定したので記録に残します。網羅的とは言い難いですが、多少なりともお役に立てば幸いです。

結論

  • YouTrack, ClickUpともにプロダクト開発に十分利用できる
  • YouTrackはデータ構造が、ClickUpはWebベースのUXが勝る
  • 複数人・複数チームでの開発ではYouTrackが、小規模開発ではClickUpが向いていると判断した

前提

joinsureの開発はスクラムで行っています。
したがって、BizDev, PdM, デザイナー, エンジニアの全関係者が同じボードを使えると望ましいです。例えば、「カスタマーサポートに寄せられたご意見の分析」「ユーザーストーリーからオブジェクトを抽出する」といった仕事もチケットで管理したい、というわけです。

さらに言えば、バックオフィスではAsanaを使っており、これを統一したい思いもありました。

また、justInCaseは(主にWeb版のUXの悪さを理由として)過去にJiraからYouTrackに移ってきた経緯がありました。したがって、メンバーがストレスなく使えることは強く意識していました。

比較

YouTrackとClickUpを、それぞれ1年/半年利用して感じたPros/Consです。

YouTrack

Pros

  • データ構造が優れている。具体的には、プロジェクトとボードの関係性が1:1ではなく、1:Nである。
    • Jiraなどではどんなボードを見たいかを考えてからプロジェクトの単位を考える必要がありましたが、YouTrackではボードに表示するチケットが所属するプロジェクトをクエリで指定できます。プロジェクト設定で余計に悩むことが減り、ありがたいです。
  • 全体的に柔軟なカスタマイズが可能。プロジェクトに任意の型の属性を追加したり、ダッシュボードやレポートを作成したり、スプリントの期間を自由に指定できたり、等々。
  • JavaScriptライクな記述ができる、柔軟なワークフロー

Cons

  • 設定が柔軟すぎて、初心者がプロジェクトを設定すると何かしら間違いが起きる。
    • 例えば、権限の設定ミスでボードが見えなくなる事故が年に3回くらい起きる。
  • ちょっとしたサービス間連携にもスクリプトを書かされる。
    • いまどきSlack通知やGitHub連携はWeb画面からポチッと設定できて当然だが、(一部例外はあるが)JavaScriptを書かないといけない。
  • ネイティブアプリがありえないくらい使いづらい。もっさりしている上に必要なボタンが探しづらいUI/UX。

ClickUp

Pros

  • 開発者向けツールと一般的なタスク管理ツールのいいとこ取りといった印象
    • Web画面のUI/UXがよい。チケットの編集ひとつとっても、YouTrackに比べて表示が大きく、操作がしやすい。
    • 繰り返しタスクも作れるので、営業やバックオフィスの人にも使ってもらえるかも。
  • 2017年の創業だけあり、Webサービス間連携はコンソールからポチで可能。
  • ゲストを招待できる。例えば特定のボードに対して、社外の人に参照権限を渡すことが出来る。
  • 比較サイトでのレビューが圧倒的に良い
    • G2 Crowdでレビュー数が約100倍あり、レートもYouTrackに勝っている。
    • 単なる人気ではなく、開発者以外でも使える間口の広さが反映されていることは考慮すべき。

Cons

  • プロジェクトとボードが紐ついており、例えばチケットをスプリントに移動すると、元々どのプロジェクトに紐ついていたかわからなくなってしまう
    • これにより、プロジェクトをエピックやユーザーストーリーに見立てる運用ができなくて辛い。
  • 2021年現在、同時編集にバグがある。正確なことは不明だが、複数人で編集していると操作(チケットを完了にする、スプリントを閉じる、など)が何度やっても反映されないことがある
    • これがスクラムイベント中に多発するので本当に困る
  • チケット番号が数字ではないため、GitHubの機能でチケット番号をリンク化することができない。

評価

両方ともいいところと悪いところがハッキリしており、(いいとこ取りのツール出てこないかな...)と本当に思いました。笑
業務に差し支えるのはどちらかと考えると、複数人・複数チームでの開発ではClickUpの欠点(特にプロジェクトとボードの関係性とバグ)が問題になると考えています。比べると、YouTrackの欠点は運用でカバーできる範囲ですね。

結論

justInCaseでは久しぶり(1年ぶりは当社では久しぶりです)のチケット管理ツールの見直しでしたが、YouTrackを続投する、という結論にいたり、そのようにチームメンバー・他チームの皆さんにも共有した次第です。

一方、チケット管理ツールのような激戦区のSaaSでもこれだけ改善できるポイントがあるのだな、と、今回比較して少し意外な気持ちになりました。
ましてや保険業界のSaaSともなれば、改善すべきことは山積していますね!

justInCaseではツールへのこだわりのある素敵なメンバーを大募集しています。なにかのご縁ですので、ぜひ一度お話できれば幸いです🙏

スタートアップ開発しくじり先生LTに登壇しました

バックエンドエンジニアのOsanoです。

5月18日にCoral Capital様主催のスタートアップ開発しくじり先生LTに登壇しました。

関連リンク

テックブログ始めました。その経緯と今後運用を続けるための考察

justInCaseTechnologies (以下、JICT) のエンジニアの kondei です

当社のテックブログを設立したので、その目的と、廃墟にならず運営するためにはどうすればよさそうか考察したので記事にしてみます

現状

  • エンジニアの採用に苦労している
  • そもそも応募者が少ない気がしている
  • 社員のイベント登壇や社員が書いた記事などの情報が集約されておらず、散逸していて探せない状況になっている
    • 社員のツイートなどはあるが流れていってログとしての機能が弱い

採用上の問題の仮説

  1. JICTのエンジニアが何をやっているかわかりづらいし、技術力やメンバーのブランド力による訴求力が弱いので応募に至らない潜在的候補者がいるのではないか
  2. JICTのコーポレートサイト が必要最低限で、情報がないし正直技術力も感じさせないので応募に至らない潜在的候補者がいるのではないか
    1. JICTが保険システムを提供している少額短期保険会社であるJICのコーポレートサイト は内容が充実しているが、 justInCaseTechnologies で検索すると上のが最上位にヒットするので、応募を考えた方はそちらを見ることも多いはず
    2. JICのコーポレートサイト のデザインに合わせることができていない(2021年9月時点)ので困惑を生んでいる可能性があった

また、コロナ前は在職者が候補者と一緒に飲みに行って親密度を高めることがあったけど、今はご時世的に無いので、上記のようなオンライン情報の重要度が少し上がってるのではないか

残念ながらこれらを直接検証する方法はないものの、議論の中で「採用候補者の方にアンケートして、どの情報が良かった・もっと欲しい情報が何か などの情報を集める」ことはできるという話が上がったため、余談ですが それも派生して行うことになりました

対策として考えたこと

JICTエンジニアに関する集約された情報がないことへの対策

  • 何らかのサービスを用いてテックブログを作る(低〜中コスト)
  • コーポレートサイトにテックブログの仕組みを実装する(高コスト)

結論として、低コストな外部サービスでテックブログを試しに作ってみることにしました

後述するかなりの懸念はありましたが、対策は講じる上で、廃墟になったら閉じるということも視野に入れて、試すことを優先しました

JICT側のコーポレートサイトがイケてないことへの対策

  • コーポレートサイトを作り直す(中〜高コスト)
  • いっそコーポレートサイトを消す(低コスト)
    • 場合によってはテックブログに会社情報を移転?

結論として、JIC側と違ってJICT側のサイトはまだレガシーなコードベースになっているので、組織だって対策することは一旦保留になりました

しかし当社の Otani がデザインを一致させる改修をしたことで、混乱を生むデザインの違いは解消されました

足りない部分があれば改修を続けるようにはしたいと思います

テックブログをどうすれば続くのかについて考察

以下、テックブログに関してのみ記述します

テックブログを廃墟にせず運用することを考えるにあたって、次の記事は大いに参考になりました

note.com

共感した部分を引用すると

採用担当1人ではできず、協力を仰いだ数名でも続かない。全社的に巻き込まないと達成されない

「会社を盛り上げるために協力してくれ」で始まったブログは多く見ましたが、概ね最初の一ヶ月盛り上がって終わります。私が観察した範囲では、下記の要素のうち2項目くらい揃ったら直ちに危篤状態になります。

・編集長が居ない/転職する

・誰がいつ投稿するか決めない、スケジュールがない、締切がない

・濃密すぎる文章チェック・法務チェック

・(上記とは逆に)チェックが皆無で内容がしょぼく、社内外にディスブランディングとなって「投稿したら負け」という雰囲気になる

・(ヘッドハンティング対策で)完全匿名にする

・業務時間外に書かせる

・PV、LGTM、応募者などKPIを設ける

・社内に称える文化がない

・他職種から遊びに見えるような立て付け

があります

それに対する対策を考えたものが以下になります

低コストなものをなるべく書く

  • イベント登壇ログを簡単な文章で投稿
    • 「○○が○○に登壇しました 」
    • 発表資料も置いときたい
  • QiitaとかZennに書いた技術記事(not 義務)があれば、リンクを簡単に投稿
    • 「○○が技術記事を投稿しました https://~~
  • ADR書いたら投稿
    • 社内向けに作ったのを転記するだけなら低コストのはず

高コストなものは義務化しない

  • よくある(会社の名を背負っての)気合の入った技術記事
    • 当然運用上は歓迎だが、義務にはしない

いつ、誰がやるか明瞭にする

最初は定期ブログ会(月1,2回で、1回15分とか)でネタを話して執筆担当者を決める事を考えました

しかし全員を巻き込みたいのに全員の入ったミーティングを作ることは無理というジレンマから、以下のようなSlackメンションを2週間に1回飛ばすことでスレッドで話す運用にしました

@エンジニア全員へのメンション

テックブログのネタ出しのリマインドです
書きたい/書きます/自分のコレどう?/他人のアレどう? というネタがあればスレッドに記載・相談してください
例)
• 技術記事
• Qiitaなど外部に書いた記事へのリンク
• 登壇・発表の記録、発表資料
• ADR
• 開発環境やツールなどエンジニア的ネタ
記事は随時基本的に自由に書いていいので、書いた記事の事後報告も歓迎です

その他

  • 特定の誰か(テックブログ発足を推進した自分とか、CTOとか、テックリード達とか)の意欲や頑張りに依存しない体制にする
  • 業務であるという意識を共有する
  • 書くことにインセンティブが生じるようにする
    • 技術記事であれば、筆者名(ハンドル名)を明示することで個人の技術的経歴が増えるようにする
  • 発信したら評価になるようにする
  • コーポレートサイトからリンクする

また、当社の Ogasawara から寄せられた面白い案としては以下のものがありました

個人が書いたものに、当社の求人を載せるというのはどうか?

逆に言えば、求人を貼るのであれば休日や朝晩に書いた記事であっても稼働を請求して良いものとする。

会社がなくなった時に記事がなくなるリスクもなくせる。

終わりに

当社ではエンジニアが個人的に記事を書いたり発表したりすることは既に行われています

しかしそれを集約した場が無いと、発見されず勿体ないという思いが僕にはあります

運用は変わっていくかも知れませんが、テックブログによって当社のエンジニア組織や技術力の魅力がより多く伝わるようになれば良いなと思います

また潜在的な候補者だけでなく、営業の際の技術上の訴求力向上にも繋がると良いなと思います