saino.me (kaishuu0123)

都内でひっそりと生きる IT エンジニアの個人ブログです

トップ > テクノロジー

個人的なテクノロジー関係 2019 年振り返りと 2020 年でやりたいこと

テクノロジー プログラミング 雑記

年始に自分が「こんなこと思っていたんだ〜」と後で見返すための楽しみを作っておこうかなと思って書きました。

2019 年振り返り

できたこと

  • Re:Backlogs のリリース github.com

  • TD4 をブレッドボードで作った (こ、これ今年だったのか) www.saino.me

  • Vue.js の体系的な知識の取得 (個人ブログ) www.saino.me

  • SPA に関して思うことの執筆 (個人ブログ) www.saino.me

  • 最近の WordPress 周辺事情の技術習得と結局はてなブログに移行した (Google AdSense 周りもこれでなんとなく分かった) www.saino.me

  • Qiita 記事執筆 3本 (ちょっと少なめ)

    • VS Code Remote Development の方法が分かったのが一番よさげ　

  • OSS プロジェクトの commit

    • 軽微な bugfix が結構ある
    • diff2html への commit が割と印象的

  • kubernetes 関連は引き続きキャッチアップ中

    • Istio を試してみるところまではやった
    • CRD までは手が伸びきっていない気がしないでもない

  • Storybook 関連の調査

    • 調査だけ。体系立ててプロジェクトに適用ってところまでは至っていない

できなかったこと

  • 個人プロジェクト vscode-erd + erd-go + graphviz-dot.js のメンテ qiita.com
  • ot-es.js のメンテ github.com
  • React 関連のキャッチアップ
    • 結局 Hook までの理解が至っていない
  • TypeScript 関連のキャッチアップ
    • これもなんとなく使っている感が否めないので、どこかで一気にやるかな〜
  • ネットワーク関係の記事執筆

2020 年でやりたいこと

何か作るやつ

  • (優先度高) Re:Backlogs の機能追加、改善
    • 主要機能として SAML、LDAP 認証対応と Multi Drag & Drop に対応する
    • rails-erd と Github Actions 使って ER 図も出せるようにしよう
  • MiniDiff (仮) の実装と公開
  • (優先度低) 個人プロジェクトのメンテ
    • とりあえず、現状に合わせた Issue 潰しを時間が見つけられたらやる
    • 需要に合わせて柔軟に
  • WSL 2 リリースされたら Windows 環境上での開発環境構築方法を体系立てる
    • とりあえず JS と Ruby 周りかな。Go も救えるようにしてみたいけど
  • ネットワーク関係のユーティリティプロジェクトを 1 つ何か考えてみる
    • シンプルでいろいろな機器に対応可能なもの
    • ログインしてコマンド実行するだけ、とか
    • Prometheus の exporter との関係性を考えながらバランスを取れるようなもので
    • もしくは Draw 2D Touch と MRTG を組み合わせて、それっぽいトラフィック画面が閲覧できるアプリとか
  • 個人の技術レベルをアピールするようなページを作る
    • 自分は何ができて何ができないのか、ひと目で分かりづらい気がするので、とりあえず自己紹介がてらページを作ってみる
  • 記事執筆 or 個人的な発信をもう少し増やす
    • テクノロジーとは若干それることがあっても、個人的なことを日々書いておく

お勉強 & 趣味

  • Go 周辺事情の再キャッチアップ
    • パッケージ管理周りが変わったので、そこらへんの知識をアップデート
  • CHIP-8 エミュレータ作ってみる
    • 個人的に楽しそう
  • React エコシステムキャッチアップ
    • そろそろ固まってくる頃だし、覚えておいてもよさそう
  • 複雑な Web UI の技術習得
    • JavaScript + SVG or Canvas でゴニョゴニョする
    • インタラクティブな UI 作れるのは素敵だよなぁ〜と
  • Git の内部構造の理解
    • 自分で作ってみる
  • Adobe Illustrator で何かイラスト描く
    • やろうやろうと思って勇気がでない :;(∩´﹏`∩);:

MiniDiff (仮) gem を作ることを考える

テクノロジー プログラミング 雑記

個人用で後で作ろうと思っていたものなので、メモみたいな形になっています。

概要

diffy gem は 内部で diff コマンドを利用しているため、 実行環境に diff コマンドをインストールすることが必須になっている

diff-lcs は一部 ldiff という形でコマンドが提供されているが、bin に関しては多機能になりすぎないようにしている。

diff-lcs の挙動は十分に優秀なので、これらを活用して、使うことが簡単な diff の gem を作ることを目指す

機能的なこと

必要な機能としては man diff 相当でいうと

  • --label でラベルが付与できること
    • とはいえ --label オプションは暗黙的に 1つ目が old、2つ目が new となっているので、もう少しオプションはわかりやすい名前にしてもいいかもしれない
  • また、-I オプション(ignore-matching-lines) オプションである

とりあえず上記をサポートしつつ、diffy のようなインタフェースがあることを目指す (diffy の API の切り方にはセンスを感じる)

バイナリファイルのサポートはしない

context (-c) 形式 と unified (-u) 形式をサポートする

主にフォーカスする箇所

github.com

  • この部分(ldiff.rb)を徹底的に作り込む形にする

参考情報: diff-lcs から返ってくるデータ構造

=> #<Diff::LCS::Hunk:0x00007f907110e9c0
 @blocks=
  [#<Diff::LCS::Block:0x00007f907110e998
    @changes=[["-", 0, "all: build"], ["+", 0, "all: built"]],
    @insert=[["+", 0, "all: built"]],
    @remove=[["-", 0, "all: build"]]>],
 @data_new=
  ["all: built",
   "",
   "build: depend peg bindata",
   "\tgo build",
   "",
   "peg:",
   "\tpeg erd.peg",
   "",
   "run: build",
   "\tcat examples/nfldb.er | ./erd-go -o nfldb.dot",
   "",
   "depend:",
   "\tglide install",
   "",
   "bindata:",
   "\tgo-bindata -o=templates_bindata.go ./templates/...",
   "",
   "examples: build",
   "\tcat examples/simple.er | ./erd-go -o examples/outputs/simple.dot",
   "\tcat examples/simple.er | ./erd-go | dot -Tpng -o examples/outputs/simple.png",
   "\tcat examples/nfldb.er | ./erd-go -o examples/outputs/nfldb.dot",
   "\tcat examples/nfldb.er | ./erd-go | dot -Tpng -o examples/outputs/nfldb.png"],
 @data_old=
  ["all: build",
   "",
   "build: depend peg bindata",
   "\tgo build",
   "",
   "peg:",
   "\tpeg erd.peg",
   "",
   "run: build",
   "\tcat examples/nfldb.er | ./erd-go -o nfldb.dot",
   "",
   "depend:",
   "\tglide install",
   "",
   "bindata:",
   "\tgo-bindata -o=templates_bindata.go ./templates/...",
   "",
   "examples: build",
   "\tcat examples/example.er | ./erd-go -o examples/outputs/simple.dot",
   "\tcat examples/simple.er | ./erd-go | dot -Tpng -o examples/outputs/simple.png",
   "\tcat examples/nfldb.er | ./erd-go -o examples/outputs/nfldb.dot",
   "\tcat examples/nfldb.er | ./erd-go | dot -Tpng -o examples/outputs/nfldb.png"],
 @end_new=3,
 @end_old=3,
 @file_length_difference=0,
 @preferred_data_encoding=#<Encoding:UTF-8>,
 @start_new=0,
 @start_old=0>

Re:Backlogs の使い方を Twitter もどきアプリの開発を例に紹介します

テクノロジー プログラミング 雑記 解説記事 Re:Backlogs

はじめに

先日、Re:Backlogs をリリースしました。

ですが、このツール、初めて使う方には「このツールがどう嬉しくて、どう使うのか？」というのが「分かりづらいかも ... ( >﹏<)」と思い、このエントリを書きました。

(とはいえ、redmine_backlogs と使い方は一緒でアジャイル開発に向いているのですが、それもそれで使い方の解説はあまり無く ...)

なので、一つの例として、「Twitter もどき(Web)アプリを作る」というシチュエーションで使い方を紹介していこうと思います。

そもそも Re:Backlogs は下記のような悩みをサポートすることを目的としています。

  • 「やりたいことはあるけど、そこそこやることが多くて、上手く整理できない」
  • 「継続的な開発、運用をしていくのが大変だし、そもそもどうやればいいの？ガチガチな体制ではやりたくない ...」
  • 「複数人で分業したいけど、どう分業するのがいいか分からない」

これらの「思い浮かぶことは曖昧だけれども、基本的な項目はすぐに思いついて着手できる」ようなケースには向いていると思います。

また、Re:Backlogs を使う上で、下記のようなフェーズがあります。

  1. プロジェクト自体の計画 (プロダクトバックログに Story を追加)
    • 実現したい機能、目的の追加
    • ここでは「できるかどうか」ということは考えずに、「実現したいこと」に集中します。
  2. Sprint 計画 (プロダクトバックログから Sprint に Story を追加)
    • プロダクトバックログに列挙された目的がどの程度消化できるかを考えます。
  3. Sprint 消化 (Kanban 画面で Task を追加して消化)
    • 偉そうに計画を立てるフェーズから実作業に入っていきます。

それぞれのフェーズは同じ人が担当したり、異なる人が担当することもできます。

それでは順を追って、アプリ開発の計画を立てていきましょう٩(ˊᗜˋ*)و

Re:Backlogs でプロジェクトを作成

f:id:kaishuu0123:20191223124932p:plain

まずは Re:Backlogs 上でプロジェクトを作成します。

  • プロジェクト名: Twitter もどきアプリ
  • 説明文: 適当
  • チケットプレフィックス: TMDK

TMDK というのは (Twitter MoDoKi) の頭文字を取りました。

ラフな設計フェーズ

Twitter もどきアプリを作るときにはまずアプリの設計から始めます。そんな仰々しいことはせず、箇条書きで思いついた順に機能を書きます。

  1. アプリにログインができる
    • この機能がないとユーザが識別できませんね
  2. ログインしたユーザで Tweet ができる
    • Twitter における核の機能です
  3. ユーザがほかのユーザをフォローできる
  4. Tweet に対して「いいね！」できる
  5. Tweet を Retweet できる

...

とこんな感じで核となる機能を列挙していきます。

「〜できる」という形式で書くと目標としてわかりやすくなると思います。

また、箇条書きの 1 項目が大きすぎると感じる場合には、複数の Story に分割すると達成しやすい目標になりやすいです。

設計を元にストーリーを起こす

上記の箇条書きを元に Story を追加していきます。 f:id:kaishuu0123:20191223125319p:plain

追加し終わると、下記のような形になると思います。

f:id:kaishuu0123:20191223125332p:plain

Story のカテゴリ

カテゴリ名 日本語別名 意味
Feature 機能 機能追加をする Story はこのカテゴリになります。開発目的である場合、大半の Story がこの Feature カテゴリに属します。
Improvement 改善 UI を良くしたり、処理速度を上げるためなど、アプリ自体の改善目的のために使います
Bugfix バグフィックス 文字通り、アプリ内でバグが出たときのためのカテゴリです。不具合を修正するために使います
Support サポート アプリを開発する上でインフラ系の作業を行うときや、ドキュメントを執筆するなど、開発とは異なる Story に使います

起票したストーリーを元に sprint 計画を立てる

「Sprint を追加」から Sprint を追加して、2 週間程度で消化可能なストーリーをプロダクトバックログから Story をドラッグ & ドロップして追加していきます。

今回はログイン、Tweet、フォローあたりが消化可能という前提で Sprint に追加します。

f:id:kaishuu0123:20191223125645p:plain

ストーリーを消化していく

計画した Sprint を元に消化フェーズに入ります。

Story を消化する人は実作業者になります。

ここからは Kanban の画面に入ります。

f:id:kaishuu0123:20191223131355p:plain

Kanban の画面から「Task を追加」ボタンで Story を達成するためのタスクを追加していきます。

f:id:kaishuu0123:20191223132254p:plain

後は自分で追加した Task を消化していきます。

Task のステータス

ステータス名 日本語別名 意味
New 新規 タスクを何も着手していない
In Progress 進行中 タスクを進めている
Resolved 解決 タスクが解決した状態。誰かの確認(自分自身でも OK)によって Done に遷移します
Feedback フィードバック 解決になったタスクで何らかのフィードバックがある場合、ここにタスクが移動します
Done 完了 タスクが確実に完了である状態です
Rejected 却下 タスクとして却下するケースです。ちゃんと却下理由を残しておきたい場合に活用します

Sprint を閉じる

Sprint 内の Story が全て完了( Task が全て Done )になると、Sprint を閉じることができます。

f:id:kaishuu0123:20191223133746p:plain

繰り返し

これ以降は先述したフェーズを繰り返していきます。

  • プロダクトバックログから淡々と Story を消化してもよいですし、
  • 足りない機能などがあれば、また Story を起こしたり、
  • Sprint の計画を立ててみたり

と自由に使うことができます。

端的に言えば 「1. 実現したい目的を列挙する」「2. 計画を立てる」「3. 計画を消化する」というサイクルを回すイメージです。

Re:Backlogs を使うことによるメリット

重要なことは

「大きな目的を達成するために小さい目的をたくさん作って、段階的に大きな目的を柔軟に達成すること」

なので、あまり堅くやりすぎず、積み重ねていくことが大切だと思います。

完璧にやろうとしすぎて、せっかくのアイディアが実現できずに挫折してしまったら意味がありません。

それよりも手堅いところから進めながら、自分が起こした Story を後からみて、機能カタログを見るような気持ちで進めていく方が開発や作業は楽しいと思います。

また、Story を細かく分けて起票することにより、複数人での分業がしやすくなります。

また、Sprint の計画を 1ヶ月にすることによって、月次作業に適用することもできますし、Story のカテゴリを自由に編集できるので、運用作業や個人・複数人の ToDO に転用することもできるかもしれません。

最後に

自身でめっちゃ使っているにも関わらず、ほかの人に進め方を説明しようとすると結構難しいですね ( >﹏<)

ニュアンスが伝わって活用して頂ける方が少しでも増えたら光栄です✨

Re:Backlogs というプロジェクト管理(タスク管理)ツールを OSS としてリリースしました

テクノロジー プログラミング 作ってみた OSS 雑記 Re:Backlogs

自分の Qiita 記事からブログへの転載です。そこそこいいものが作れたなぁと思っています (∩´∀｀)∩

qiita.com

20191221_rebacklogs.gif

読み方: Re:Backlogs (リ・バックログ)

https://github.com/kaishuu0123/rebacklogs

2019/12/23: 使い方の記事を書きました。 Re:Backlogs の使い方を Twitter もどきアプリの開発を例に紹介します

画面紹介

デモサイト: https://rebacklogs.saino.me/

Twitter, Google, GitHub ログインに対応しているので、お気軽にお試しください ✨

マスターバックログ

スクリーンショット 2019-12-20 15.38.54.png

プロジェクトのトップページにあたる「マスターバックログ」という画面です。

この画面でプロダクトバックログの中に Story を追加したり、Sprint を追加した後にプロダクトバックログから Story を Drag & Drop で追加したりします。

カンバン (Kanban)

スクリーンショット 2019-12-20 15.40.52.png

マスターバックログにある Sprint のところから Kanban ページに飛ぶことができます。

この画面で Story を達成するためのタスクを追加したり、進行度に合わせてカードを Drag & Drop できます。

プロジェクト設定画面

スクリーンショット 2019-12-20 15.43.20.png

プロジェクト名の管理や、グループ管理、 Story のカテゴリ、ステータス管理を行う事ができます。

説明

Re:Backlogs はアジャイル開発時のチーム開発を円滑にするための OSS です。

Re:Backlogs では「小さな目的は複数のタスクによって達成できる」という前提を置いています。

本来何らかの目的を実現したい場合、1 つのタスクだけでは目的は達成できません。

例えば、「ログイン機能を作る」という目的には「実装」というタスクと「動作確認を行う」というタスクが考えられます。

スクリーンショット 2019-12-20 18.12.12.png

アジャイル開発に馴染みのある方はご存じかもしれませんが、

  • まずは「プロダクトバックログ」と「スプリント」があり、
  • プロダクトバックログにストーリー (実現したい小さい目的) をどんどん追加して、
  • 追加されたストーリーを消化するときには期間が設定された「スプリント」にストーリーを追加し
  • そのストーリーを達成するためのタスクをストーリーの配下に追加します。

ストーリーの目的が大きすぎる場合には、達成可能な適切な粒度にストーリーを分割するようにします。

これらのアジャイル開発の管理を実現するツールとして Re:Backlogs を作りました。

セットアップ方法

手元で試してみたい方は、Docker Image もありますし、リポジトリの中に docker-compose.yml を同梱していますので、下記の手順で試してみてください

git clone https://github.com/kaishuu0123/rebacklogs

docker-compose up -d

開発動機

様々なタスク管理ツールを調べたり、実際に業務で使ってみましたが、「小さい目的を達成するためにタスクを複数作ることができる」ツールが少なく、似たようなプロジェクトやソフトウェアがあっても操作感に不満があったためです。

似たようなソフトウェアとしては、下記のようなソフトがあります。

しかし、これらのツールは個人で使うには仰々しく、普段使いする上で導線が微妙だったり、多機能すぎるところがありました。

なので、上記のツールの良いところ取りをして、シンプルなプロジェクト管理ツールが欲しくなり開発しました。

あと、いわゆる「今時なものを使って 普通っぽい Ruby on Rails + webpacker + Vue.js アプリ」を自分で所有したかった、というモチベがあります。

ソースコード

GitHub でソースコードを公開しています。

https://github.com/kaishuu0123/rebacklogs

少しでも「いいね」と思ったら、Star してくださると喜びます :sparkles:

使っている技術

  • Ruby on Rails
  • webpacker
  • Vue.js

実装してて楽しかったところ

Drag & Drop による操作と、バックエンドのソート順保持

この機能を実現するために下記の技術を使いました

  • バックエンド側は ranked-model gem を利用
  • Vue.js 側は vuedraggable を利用

ソート順を正しく動作させるにはそこそこ苦労しましたが、実現したときにはとても嬉しかったです

見やすい色を自動的に決めるアルゴリズム

スクリーンショット 2019-12-20 15.42.32.png

「ストーリーのカテゴリのバッジ色をユーザが設定できる」機能があります。

その際に「背景色を指定するといい感じの文字色にする」という機能を作ったのですが、色に関するアクセシビリティについて勉強になりました。

調べてみると、 WCAG contrast ratio Guideline というのがあり、WCAG contrast ratio Guideline 1.4.3 Contrast (Minimum) というものを参考にして実装しました。

他にも参考にした記事

webpacker でのパフォーマンスチューニング

これはタイトル通りですが、webpacker で生成される js が重くなったので、それらを軽くするための作業をしました。 ( commit log )

ここまで書いたはいいんですけど、結局 environment.splitChunks() の 1行だけでだいぶ軽くなったので後程直しました(´・ω・｀)

開発者なりにユーザビリティを考えること

これはちょっと実作業とは異なりますが、自分なりの「使いやすさ」を考える作業はとても楽しかったです。

「少しでも楽に Story が起票できて、 sprint を管理できる方法は何だろう？」と考えて、ボタンをどこに置いたらいいか、などの試行錯誤はなかなか楽しかったです。

最後に

これからも自分なりに Re:Backlogs を進化させていこうと思います 💫

もし、使ってみて良かったときには Twitter や GitHub star などで反応していただけると嬉しいです ✨

プロジェクトロゴをどうしようか考え中です ...

お化けっぽい感じでカワイイテイストがいいのですが、自分でイラレで描こうか迷っています :;(∩´﹏`∩);:

2019/01/06 追記

使い方の解説記事を書きました

www.saino.me