s4na's blog

s4naのテックブログ

ファーストペンギン

ノートにツイートを貼れるサービス「twi-note」を作成しました

目次

はじめに

今回の記事では、私がフィヨルドブートキャンプで作成した、「twi-note」というサービスについて書きました。

twi-noteとは？

github.com

twi-note.herokuapp.com

twi-noteはノートにツイートが貼れるサービスです。

一番のポイントは「ツイートが簡単に貼れる」ところです。

ツイートを簡単に貼るための4つの工夫

ポイント１：検索結果の全ツイートを一括で貼れます。

ツイートの検索結果から一つ一つツイートをいちいち選ぶのが面倒な場合、一気に貼ることができます。

ポイント２：ツイートをドラッグ＆ドロップで貼れます。

ツイートの検索結果からツイートをドラッグ＆ドロップで貼ることができます。

ポイント３：時間を指定して、ツイートを検索できます。

ツイッター公式の検索機能では日付単位でしか検索できないのですが、twi-noteを使えば時間指定で検索する事ができます。 ※Twitter APIの関係上、現状１週間ほど前までのツイートを検索することができます。

ポイント４：作成したノートをダウンロードできます

作成したノートを、テキストファイルとしてダウンロードすることができます。 そのため、その後自分のエディタやノートサービスで作業を継続することができ、今まで使ってきたノートと競合することがありません。

作った理由は、ノートにツイートを貼るのをもっと簡単にしたかったからです

サービスを作り始めたきっかけは単純で、ノートにツイートを貼るのを「もっと簡単にしたかったから」です。

私は技術系の勉強会に参加するのが大好きで、昨年だけでも55回参加しています。（数えたらそうでした）

そして、勉強会に参加した際、ほぼ毎回ノートを作成しており、 そのノート作成にあたって、勉強会のツイートを使っていたことから、 ツイートをまとめられるサービスがあったら便利だな〜と思い作りました。

似ているサービスとの違い

「なぜ自分で作成するの？Togetterさんがあるのでは？」 そう思われるかもしれません。

Togetterさんは大変便利なサイトです。 ですがTogetterさんの場合、Togetterさんのサイトでツイートをまとめることがメインです。

私の場合は最終的には自分のノート（Markdown）に情報をまとめることがメインなので、 目的と手段が違っているし、やりたいことができなかったから作りました。

フィヨルドブートキャンプというプログラミングスクールでサービスを作成しました

今回の記事ではフィヨルドブートキャンプの話が多分に出てきますので、まずは簡単にご説明させていただきます。

フィヨルドブートキャンプとは、現場の即戦力になれるプログラミングスクールです。

bootcamp.fjord.jp

フィヨルドブートキャンプでの「現場の即戦力」の定義は「Issueを一人でこなせる人」になります。

詳しい定義については、フィヨルドブートキャンプのメンターであるkomagataさんのブログにまとまっていますので、下記記事をご確認いただければと思います。

Railsエンジニアとして就職できるレベルとは - komagataのブログ

今回私は、このフィヨルドブートキャンプで「デザインレビュー＋コードレビュー」を受けながらサービスを作成しました。

初めてのサービスづくりで挑戦したことと、学んだこと、こうすれば良かったと思ったことについてまとめ

サービス企画編

Getting Realという本のやり方を真似する事で、ユーザーが0じゃないサービスを作ることができる

フィヨルドブートキャンプでは、サービスを企画するにあたりBasecampが作成したGetting Realという本をもとにしてサービスを企画します。 ※Basecamp＝Ruby on Railsを開発したDHHさんが所属されている会社です。

このGetting Realを参考にする事で、「自分の問題を解決することができる ＝ ユーザーが最低一人は居るサービス」を作ることができます。

どんな方法なの？と思った方もいらっしゃると思います。 自分なりに重要だと思った事をまとめ他内容を以下に書いておきます👍

Getting Realまとめ
## 最も重要なこと3点
- シンプルに作る
- 実際の画面から作り始める
- 自分＝顧客が本当に必要なものだけを提供する

## シンプルに作る理由
素晴らしいソフトウェアには、無駄な線や無駄なパーツがないので、全てが作り手の表現したいことになり、伝わりやすくなります。
また、技術的負債や肥大化が起きず、大きなお金やチーム、長い開発サイクルが不要になります。

## 実際の画面から作り始める理由
機能的な仕様は一種の虚像であり、現実のユーザーの体験は実際の画面にあります。
実際の画面から作り始めることで、より早く現実のユーザーの体験に辿りつけるからです。

## 自分＝顧客が本当に必要なものだけを提供する理由
自分の問題である時、本当に必要なものだけを作ることができます。
顧客にとって本当に必要なものを作る時、それは付加価値ではありません。
付加価値は、ユーザーのためではなく競争相手に打ち勝つために追加されています。

本を読んだだけではすぐ実践できない

Getting Realを読み終わった当初、サービスの企画案をガンガン出していったのですが、全部落ちました。

改めて考えてみると、Getting Realの概念が自分のものになっていなかったからだなと思います。

まとめるのは重要ですね・・・これからも頑張ってブログを書いていきたい・・・

アイデア出しに挑戦

では実際にどういうアイデア出しを行ったのか。 通った企画と通らなかった企画を以下に載せておきます。

通った企画（今回作成したサービスの企画）
# twi-note

## エレベーターピッチ
[twi-note]というサービスは、
[勉強会参加時、ノートばかりとらず、楽しみながら参加したいけど、やはりノートを取らないと知見がたまっていかない問題]を解決したい
[勉強会参加者]向けの、
[ノート作成支援アプリ]です。
ユーザーは [勉強会のハッシュタグのついたツイッターのタイムラインをノートに貼り付けること] ができ、
[通常のテキストだけのメモ] とは違って、[勉強会のハッシュタグと時間を入力するだけで、簡単にmarkdownのノートとしてまとまる機能] が備わっている事が特徴です。

## 似ているサービス
[togetter](https://togetter.com/hot)
ツイートまとめサービス

[min.t](https://min.togetter.com/)
togetterと同じ開発会社がツイートまとめアプリとして開発

通らなかった企画＋フィードバック

# myなろうランキング

## エレベーターピッチ
[myなろうランキング] というサービスは、
[小説家になろうというサービスで、ユーザーが新しい作品を探そうとした時、ランキングを見てもに既にみたことのあるの作品が表示されるという問題] を解決したい
[小説家になろうのヘビーユーザー（毎日ランキングを見るような）] 向けの、
[スコップ（新規作品を探す時のスラング）アプリ]です。
ユーザーは [サイトに登録して、作品を既読リストに追加することで、自分用にカスタマイズされた日次、週次、月次、年次ランキングを見ることができる。] ができ、
[既存の紹介サイト、ランキングサイト] とは違って、
[既に読んだことのない作品が見つかるという要素] が備わっている事が特徴です。

## 備考
- [小説家になろう](https://syosetu.com/)のホームページ
- 「小説家になろう」は情報取得のため[API](https://dev.syosetu.com/)を用意してくださっている。
- 商標利用について、表記のルールはあるものの、ルールを守れば利用可能みたいです
  - https://hinaproject.co.jp/hina_guideline.html

## FB
> 機能追加という時点で不要な機能になってしまいそう
> これは小説家になろうさんが解決する課題
> 会社や面接官によっては理解されないことはあるかもしれないですね。この問題自体、悪くはなさそうです
> 自分が採用する側に立って考える
> どっちを評価する会社に入りたいか
# アーチャーチューナー

## エレベーターピッチ
[アーチャーチューナー] というサービスは、
[アーチェリーの上達を慣れや勘任せにしている] を解決したい
[自分の癖がわからない人] 向けの、
[癖分析アプリ]です。
ユーザーは [打った矢の位置を記録すること] ができ、
[手書きのメモ] とは違って、
[経過時間による癖がわかる機能] が備わっている事が特徴です。

## FB
> 今現在の s4naさんの 問題ではない（学生時代やっていたものの、私は今現役でアーチェリーをしていない為）
# 年間行事スケジューラー

## エレベーターピッチ
[年間行事スケジューラー] というサービスは、
[例年ある作業だが、作業日がパッとしないためギリギリまで残る問題] を解決したい
[年間行事を記憶頼りに行なっている人] 向けの、
[スケジュール管理サービス]です。
ユーザーは [一度行事の設定を行うだけで、作業日を決めることができ] ができ、
[記憶頼りの作業] とは違って、
[サービスが作業日を自動で決めてくれる] が備わっている事が特徴です。

## ユーザーの入力作業
作業名：夏の大掃除
作業日：8月第2週金曜日
作業日オプション：平日を除く
通知：メール
通知対象：本人・家族

## 対象の行事と効果
- 誕生日の一週間前に準備する
    - ギリギリになりがち
- 家族で夏に大掃除
    - 毎年時期が近くなってきたらいつやるのか？いつが空いてるのか？問題になる
- 年賀状準備
    - 毎年遅くなる。

## FB
> Googleスケジューラーで良さそう
# 予定かぶらな〜い

## エレベーターピッチ
[予定かぶらな〜い] というサービスは、
[予定調整アプリで複数の予定を調整すると被ったり調整が入る問題] を解決したい
[忙しい人] 向けの、
[予定調整サービス]です。
ユーザーは [予定の候補日を入力すること] ができ、
[調整さん] とは違って、
[予定が重複しない機能] が備わっている事が特徴です。

## 問題
本アプリ以外での予定調整情報が出揃わないと、予定重複が回避できない。
ネーミングから必ず回避できるというユーザーの誤った印象を与えそう

予定管理者が予定決定ボタンを押さないと反映されない

## FB
> 全ての予定をサービスで管理しなければいけないのが弱い

デザイン編

ペーパープロトタイプのデザインに挑戦

人生の中で、デザインを積極的に行なってこなかったツケが回ってきたな・・・と思いながら挑みました。

実際に作ってみたことで、もっと細かく作り込んでおけば手戻りがなかったな・・・ということがたくさんあります。 特にランディングページの内容について細かく決めておくべきだったと思っています。

f:id:s4na:20200204191928p:plain

f:id:s4na:20200204192007p:plain

f:id:s4na:20200204192017p:plain

f:id:s4na:20200204192036p:plain

f:id:s4na:20200204192052p:plain

f:id:s4na:20200204192108p:plain

アイコンがきれいだと、やる気が出る。サービス感が出てくる

はてなブックマークで以前見かけた記事を参考に、作成しました。 （今見たところ、記事が非公開になっていたので、リンクは貼り付けておりません）

アイコンを作成したことで、サービスを作ってる感が出てきてテンションが上がりました💪

f:id:s4na:20200224191201p:plain

アイコンの作成方法

アイコンは以下のステップで作成しています。

  • フリーアイコンを探す。（ライセンスもちゃんと確認する。）
  • グラデーションの画像を探す。
    • itmeoで探しました。
  • マスク処理のできる画像編集アプリを用意する
    • 今回画像編集アプリにFigmaを利用しました。
  • グラデーション画像をフリーアイコンでマスク処理をする

サイトに使う色決め、とても難しい

色を決める際について考えていたことは、主に２つです。

  1. 「色相＝色の意味」を決める
  2. 「色の明度、彩度＝色づかい」を決める
「色相＝色の意味」を決める

調べたところ、optinmonsterというサイトにサイトで使う色使い（危険、安全などなど）が載っていたので、こちらを参考に色の意味を決めていきました。

また、共通化するために、以下のようにSassのファイルに色を定義しました。

$normal-button-color: #7d666a
$primary-color: #2d92c4
$secondary-color: #239986
$danger-color: #e9566e
$warning-color: #dfc333
$infomation-color: #2fcd64
$disabled-color: #c1c5b9
「色の明度、彩度＝色づかい」を決める

色の明度、彩度によって色の見え方感じ方が全然変わります。

まずは自分で作ってみようと思い、作ってみたものの。全然ダメでした😢 調べてみたところ、ジェネレーターを使うといいという記事があったので、それを参考にしてみたら、上手くいきました。

使用したサイトについて、簡単に説明させていただきます。

色々な色の組み合わせを見せてくれるサイト

https://coolors.co/

このサイトを使い、ランディングページ（トップページ）の色使いを決めました。 色を組み合わせるのが苦手なので、大変助かりました。

1つの色を入力するとそれに合わせて130色作成してくれるサイト

https://palx.jxnblk.com/

このサイトを使うと、1つの色を入力するだけで130色（＝13色相×明暗10色）の色を作成することができるのできます。

色の色相だけ変える作業が苦手なので大変助かりました🙏

CSSのフルスクラッチに挑戦

1つのサイト全てのCSSを1から書くのは、今回が初めてでした。 フィヨルドブートキャンプの課題でも、CSSを書いたりしたのですが、CSSのクラス名命名から何から行ったのは初めてなので、結構学ぶことが多かったです。

CSSのクラス名の命名は、BEMを使うと簡単に決まる

BEMとは、Block, Element, Modifierの略称です。

  • Block = 親が何か
  • Element = 要素名
  • Modifier = 状態など

BEMは住所みたいな感じで、使うことで間違ってCSSのクラス名が被ることを避けてくれたり、再利用可能になったりします。

BEMについて詳しくは以下の記事を参考にしたり、フィヨルドのデザイナーのmachidaさんにレビューしていただきながら作成しました。

https://qiita.com/Takuan_Oishii/items/0f0d2c5dc33a9b2d9cb1

CSSのクラス名について、属性を与える場合はBEMではなく .a-XXX, .is-XXX を使い分けると良い

フィヨルドブートキャンプでスクラムをしている際、デザインはほとんど担当してきませんでした。

そのため、ソースコードを読んでいる際、CSSのクラス名で .a-XXX, .is-XXX というのを度々見かけて、 「なんだこれは？」と思っていました。

実際にCSSを書く段階になったところで理解できました。

a-XXX は「オブジェクトが "何" であるか」（箱なのかフォームなのかカードなのか）を表したものです。（一つしか存在しない）

is-XXX は「オブジェクトの状態」（危険なのか、安全なのか）を表したものであることを表しています。

これがわかってからはスッキリ書けるようになりました。

命名については、@sanfrecce_osaka さん（フィヨルドブートキャンプの先輩）が教えてくださった以下のサイトが大変役に立ちました。 ありがとうございます🙇‍♂️

http://sparkle-day.com/weblog/make-website/497

レスポンシブ対応

主に、スマホサイズ(979以下)とPCサイズ（980以上）の時のCSSを作成しました。 ※細かいところのデザインを修正するために微調整は行っています。

@media screen and (max-width:979px)
  // スマホサイズ
@media screen and (min-width:980px)
  // PCサイズ

スワイプ機能の実装に挑戦

Swiper.jsを利用して実装しました。

以下サイトを参考にすれば、簡単に実装できました。

https://www.willstyle.co.jp/blog/724/

WebpackerでJS、CSSライブラリの読み込みに挑戦

大変苦労しました。 JS、CSSライブラリの読込先が別なことが肝だなと思いました。 もしかしたらもっと上手くやる方法があるのかもしれません。

Webpackerなので最終的には一つにまとめるのですが、 Railsの上にあるVue.jsの中で使っているせいで、少し複雑になっています。

以下のように、ひとえにライブラリと言っても、「JSライブラリ」、「JSライブラリ付属のCSS」、「Vue.js内のJSライブラリ」という3つに分かれ、別々のところに別々の書き方をしなければなりません。

- Rails
  - Webpacker
    - CSS（application.css or application.sassで設定）
    - JS（application.jsで設定）
    - Vue.js
      - JS（個別のvueコンポーネントで設定）

しかも、微妙に書き方が違っています。 もしかしたらWebpackerへの読み込み設定を変更する事で、統一できたりするのかな？とも思い調べましたがよくわかりませんでした。

参考：外部ライブラリ読み込みの書き方

参考までに、私の書き方を載せておきます。

JSライブラリ付属のCSS

JSライブラリ

Vue.js内のJSライブラリ

テーブルのレスポンシブ対応

以下のサイトを参考に、テーブルのレスポンシブ対応を行いました。

https://cotodama.co/table_responsive/ https://www.webcreatorbox.com/tech/responsive-table

色々やり方はあるみたいなのですが、私の場合は表示する項目が違うことから、 PC版とスマホ版で別の要素を表示する実装方法をとりました。

# イメージ
- テーブルのカラム
  - PC版の要素
  - PC版の要素
  - PC版の要素
  - スマホ版の要素

iPhoneでみた時に画像が横向きに表示されてしまった

iPhoneからアップロードしたJPEG写真が横向きになる問題(EXIF, Orientation)をみたところ、EXIFのOrientationがおかしいとのことです。

簡単に修正を行い、横向きにならなくなりました。

タブの押してる感を出した

タブの押してる感を出したいな〜ということをツイッターでつぶやいていたところ、

親切な@yrinda_ さん, @sea_baya さん が助けてくださいました。 ありがとうございます🙇‍♂️

ツイートを参考に、実装させていただいたところ、見事解決しました👍

CSSのレイアウトに関するディレクトリ構成を「Atoms + Blocks」で作成

初めはAtomic Designに挑戦してディレクトリを分けたりしたのですが、最終的には「Atoms + Blocks」に落ち着きました。

採用した一番の理由は、どこに何があるか調べるのが容易だったためです。

- atoms
- blocks
  - note
    - note.sass
    - note-show.sass
    - ...
参考：実際のディレクトリ

https://github.com/s4na/twi-note/tree/master/app/assets/stylesheets

Rails編

ユーザー認証機能の追加

Devise, OmniAuthを利用して実装しました。

セキュリティの観点から、routes, controllerで不要な機能を無効化するのが肝だと感じた

CSRF対策

https://github.com/s4na/twi-note/pull/97

OmniAuth gemを利用する際は、外部Gemとcontroller側でセキュリティの設定が必要なようです。 ※設定するように、GitHubのセキュリティアラート（The request phase of the OmniAuth Ruby gem is vulnerable ...）も発生します。

対策に必要なGemはこちら（OmniAuth - Rails CSRF Protection）です。

Twitter Gemの利用に挑戦

探していたらGemがあったので、APIではなくGemを利用しました。

利用方法については、こちらの記事を参考に進めていきました。

qiita.com

下記サイトにアクセスして、Developer登録を行います。

https://developer.twitter.com/content/developer-twitter/ja.html

Twitter APIは利用申請の承認に時間がかかるという話を聞いていたのですが、すぐに使えるようになりました。

ただ、サイト毎にオリジナルの英文数百文字×5本ほど書く必要があるので、英語を書くのが苦手な人は、ここで苦労するかもしれません。 私は苦労しました😢

JS/Vue.js/API編

Twitter連携でWrite権限を外す

Twitter Developerのサイトで、認証したユーザーのアカウントを編集できる、Write権限をオフにしました。 ※デフォルトはオンです。

これは重要な設定だと思いました。

ユーザーからしたら「s4naという名前も聞いたこともない個人開発者に、ツイッターのフォロー・アンフォローを操作できる権限を与えたくないな・・・」という風に考えるのでは？と思ったからです。

ユーザーの不安を減らすため、必要がないのでオフにしました。

Twitter APIのID&SECRETの環境変数を設定

Heroku本番環境での .env ファイルの運用について悩んでいたところ、ツイッターではくどーさんよりアドバイスをいただきました。ありがとうございます！

アドバイスを元に、Herokuサーバーに .env ファイルを置こうとするのではなく、環境変数を設定しました。

環境変数の設定については、以下サイトを利用しました。 シェルのコマンドで、簡単に設定することができます。

https://qiita.com/kazuhikoyamashita/items/2c3c31155e98675f780f

フロントエンドをVue.jsで実装

フィヨルドのスクラムでVue.jsのコードを書いていたので、APIとのやりとりはなんとか実装できました。

https://github.com/fjordllc/bootcamp/pull/1230

Vue.jsのコンポーネントの設計、とても難しい

Roppongi.vueで似たような事例のLTを聞いていたこともあり、

https://docs.google.com/presentation/d/1wwikvKkwCT9p8AeR73UhzGMw6WTLMwT4CnxV8tGtXjI/edit#slide=id.gcb9a0b074_1_0

「進○ゼミで聞いたやつだ！！」というノリで、 自作コンポーネントに対してv-modelで良い感じ実装しようとしてみました。

ところが、既存のv-modelであるtextareaに対して、更にその親のv-modelを継承しようとすると、警告が発生して上手く実装することができませんでした。残念です😢

ただ、その過程でリファクタリングしていたおかげで、コードを書き始めた初期の 「親から子にメソッドと渡して、そのメソッド内で子から親の変数を参照する」みたいな、 ツラミのある実装は回避できるようになったので、成長を実感しました。

もっと上手くなりたい・・・

JavaScriptのClassにJestでテストを追加

JavaScriptのテストライブラリ、たくさんあってどれにしようか迷っていたのですが、Sendagaya.rbで@tkawaさんと@fukajunさんに教えていただいた、Jestを採用しました。ありがとうございます！

公式のドキュメント通りに作業すれば、素直に追加できました。

https://jestjs.io/docs/en/getting-started

Sendagaya.rb、良い勉強会です！！ 毎週月曜日行っていて、私はここ数ヶ月、毎回参加しています！！

ドラッグ&ドロップを実装

本アプリでは、検索して取得したツイートを移動する機能があります。

@mpywさんに教えていただいた、Vue.Draggableを選択しました。

外部ライブラリ利用は、ドキュメントを読めば簡単に実装できて良いですね。。。

Datetime型が落とし穴、Datetime pickerの導入

Datetime pickerとして、vue-datetimeというライブラリを追加しました。

結論からいうのですが、すっごいハマりました。。。

どういうことかというと、JavaScriptのDate型、moment.jsのdatetime型、LuxonのDatetime型がそれぞれ別物だからです😢

特にLuxonのDatetime型のformatはISO 8601 and RFC 2822という規格で定められており、年月日の表現が少し特殊です。

Formatting - Luxon

例えば日時は英単語の頭文字を取って、 yyyy/mm/dd hh:mm で表したいところですが、 yyyy/LL/dd HH:mm になります。

私は始め yyyy/mm/dd hh:mm と記載していたため、月と時間がズレるという現象が起きました。

時間がズレたのに気づいた時、Herokuのサーバーはアメリカにあるため、 タイムゾーンがズレているからだと勘違いして、コードの奥深くまで探検しにいってました。

ところが、フロント側まで遡ってみても、データは日本時間で、 「あれ？おかしいな？・・・もしかして！！」と思い、勘違いに気づきました😢

また、 yyyy/mm/dd hh:mm 形式で日時を管理していた場合、細かなところで変換を噛ませないといけなかったりして大変でした。

CI編

GitHub ActionsでCIに挑戦

GitHub Actionsは2019年11月頃に正式リリースしたばかりです。

2019年11月13日の Ebisu.rb#26 でも話があり、@yasuhirokiさんというGitHubのリポジトリでGitHub Actionsの全コマンド？を試されている方がLTしていて、面白そうだな〜と思い実装してみることにしました。

結構簡単に実装できた。 ・・・と思ってました。

ハマりポイント

実は、途中までCIが機能していないことに気づいていませんでした。 GitHub Actionsはコマンドに対する戻り値が0かどうかで判断しています。 例えばrubocopは0~9が正常なのでそのままだとエラーになったりします。

私は /bin/lint にlintのシェルを作成していたこともあり、CI上でシェルをそのまま叩いていました。 その場合、判定される戻り値はシェルの戻り値なので、一番最後の行の結果だけになります。 そのため、エラーが検知できていませんでした。

#!/bin/bash

bundle exec rubocop -a

# 👇もしここで失敗しても、正常終了になる
bundle exec slim-lint app/views -c config/slim_lint.yml
bin/yarn eslint app/javascript
bin/yarn eslint test/javascript

GitHub Actionsを通して、CIについて理解が深まりました💪

GitHub Actionsのキャッシュ機能追加

CIの時間を待つのが嫌だったので、GitHub Actionsのキャッシュ機能を使いたいな〜とつぶやいていたところ、みかみんさんさんにサイトをご紹介していただけました。

記事を紹介してくださったみかみんさんさん、途中サポートしてくださったmikkameeeさん、記事を作成したVincent Voyerさん本当にありがとうございました🙇‍♂️

記事を参考にしたら基本的に動いたのですが、追加で実装している部分で少し躓いたのでので書いておきます。

躓いたところ
Chromeのインストール

前設定ではCabybaraでシステムテストを行うために、Chromeのインストールを行なっていました。 今回それを写したところ、sudoを追加してほしいとメッセージが表示されるようになったので、追加しました。

Jestの実行

今回Jestでテストを実行しています。ローカルでは問題がなかったのですが、サーバー上で行うときはGem内のテストも実行してしまいそうになりエラーになったので、 testPathIgnorePatterns にvenderを追加しました。

参考

A Rails and PostgreSQL setup for GitHub actions (CI)

GitHub編

Dependabotを設定

前にOmotesando.rbで保立さん(@purunkaoru)がDependabotからの脱却というDependabotの運用についてLTをしていたので、そちらを参考にさせていただきました。

内容を簡単に説明させていただきますと、以下のようになります。

  • Dependabotは依存関係のあるライブラリがアップデートされると、PRを投げてくれるサービス
  • でも、導入するとPRをたくさん投げすぎて人件費というコストがかかる
  • Dependabotの設定変更で、かかるコストを減らすことができる
  • 具体的なやり方は、Dependabotの設定を「セキュリティアップデートのみ」に変更すること

今回はこのLTを参考に、「セキュリティアップデートのみ」の設定にしました。

CIにバッジがあると、本物のOSSっぽさが出る

READMEにGitHub Actionsのpassing badgeを追加

CIの設定を毎日実行するように変えた上でこのバッジを追加することで、（テストが書かれている動作については）アプリがちゃんと動く証明ができるようになりました。

f:id:s4na:20200129115521p:plain

issue率表示

https://github.com/s4na/twi-note/pull/162

こちらのサイトで作成しました。

https://isitmaintained.com/

f:id:s4na:20200129115548p:plain

ツイートボタンの埋め込み追加

https://github.com/s4na/twi-note/pull/192

下記サイトを参考に、README.mdにツイートボタンを追加しました。

github.com

f:id:s4na:20200129115341p:plain

タスク管理編

タスクは小粒にすることで、進み続けることができる

フィヨルドブートキャンプの進捗報告会で、「タスクが小さい方が良い」という話を聞きました。 どうしてもタスクが大きい場合は、大きいタスクをそのまま設定するのではなく、「タスクを分割するタスクを設定してもいい」ということでした。

「とりあえずフィードバックしていただいたことは実践しよう💪」と思い、実践してみたところ、嬉しい効果がいくつかありました。

実践したことで、「次に何をするか迷うことが減った」ように感じました

大きいタスクを実行しようとしていた時は「大きいタスクの中にはまた細かいAとBというタスクがあったりします。その場合、AとBから先に行う方を選ぶ」という作業が発生します。 小さいタスクになったことで、こういった迷いが減りました。

毎日何かしらのタスクを終了させることができ、毎日進捗を報告することができました

フィヨルドブートキャンプでは、学習を行った日は日報を書くという決まりがあります。 悩んでいることなどについて、メンターが相談に乗ったり、アドバイスのコメントを書くためです。 また、明言はされていませんが「個人としてその日1日の進捗に達成感を感じるためという効果もあるのかな？」と思っております。 毎日何かしらのタスクが終了することで、達成感があり、開発が長続きしても、気持ちが落ちることはほぼありませんでした。

「いつかやる」リストを作ることで、本当に必要なことだけ取り組める

本サービスを開発するにあたって、「無限にやりたいことが出てくる」という問題がありました。

今回が「初めての個人開発」であったこと。 「就職活動で利用するポートフォリオ」であったことも合間って、無限にやりたいことが出てきました。

そして同時に、やらないことが出てきました。

以下、やらなかったことリストです。

・・・などなど合計で30件以上になりました。

やりたいことは無限に出てくる・・・でも、サービス開発は、どこかで区切りをつけなければなりません。

今回私は、サービスのコアの価値に寄与するかどうかで判断しました。

具体的には、エレベーターピッチの問題に対する解決です。

はてなブックマークの記事をみて、自分のサービスに適応したいものを見つけたら、とりあえず「いつかやる」リストに追加する

この施策は大変上手く機能しました。

かねてより、はてなブックマークを見たり勉強会に参加すると、度々面白そうな話を見聞きすることがあったので、 自分のサービス開発に利用できそうなことをまとめていました。

その結果、本記事でも紹介しているように、色々なツールやライブラリを参考にすることができました。 そのおかげか、サービスの開発において「どんなツールがあるのかわからないので調べる」みたいなところで詰まることも少なかったように感じます。

コツコツ情報を貯めるの大事ですね。

備考

まだベータ版ですが、以下のようなデザインツールの共有サイトもあるみたいなので、参考にしてみても良いかもしれません

https://www.designvalley.club/

一人でアジャイルを回して学んだこと

https://github.com/s4na/twi-note/wiki

サービス開発において、一人ふりかえりミーティングを行なっていました。 フィヨルドブートキャンプのスクラムという課題でアジャイル開発手法のスクラムというやり方で開発していたので、 それを参考に、一人でアジャイルしていました。

毎週何をやるのか明確になり、一人で開発し続ける際にやる気が継続できました。

納期の管理に失敗した

失敗したことも正直に書こうと思います。 全体としての個人的な納期は全然間に合いませんでした。

納期が遅延したことの主な原因としては、「初めて自分の作ったサービスなので、機能をモリモリ追加したくなったこと」でした。 エンジニアリング組織論で、「エンジニアリングとは不確実性」「不安なタスクから先にこなす」という話を読んでいました。 そのため、理性としては「不確実なこと」「不安なこと」から取り組んで、後半は納期が見えるようにしていくはずでした。 しかし、後半になってからも色々挑戦したいことがたくさん出てきて、そこに時間を投入してしまいました。

また一方で、1イテレーション毎の納期の管理は成功しました。 「今週はこういうことをやろう」と決めたら、守ることができました。

個人開発で、ストーリーポイントは導入しなくて良かった

フィヨルドブートキャンプのスクラムでも使っていたため、その流れで導入してみました。 正直、「必要なら取り掛かるし、あとでもいいならやらないだけ」なので、ポイントを降ったことでの効果は感じませんでした。

仕様変更が多く、突発的に要望がどんどん増えていく場合、あまり必要ないのかな？とも思いました。

ストーリーにタグ付けするのは良かった

「バグの修正については、早く取り組みたい」と思ったりしました。 必要に応じてタグつけしていくのは「テンションを上げる」という面でメリットを感じました。

参考：一人ふりかえりの記録について

WikiのPagesに記録を作成しております。

github/s4na/twi-note/wiki

今後の課題

個人的に思っている課題

Slackとの連携

勉強会によっては、Slack上で勉強会の情報をやりとりしているところがあります。 そのため、Twitterと同様、Slackとの連携も行いたいと考えています。

Connpassの開始終了時間との連携

Connpassの利用規約確認の上、スクレイピングを行うことで、 勉強会の「勉強会ハッシュタグ」「開始時間」、「終了時間」の取得を行いたいと考えています。

時間予約

数が増えていくと勉強会終了後、毎回人が手動でノートを作成するのが手間です。 あらかじめ「勉強会ハッシュタグ」「終了時間」を入力しておくと、時間になったらノートを作成してくれる機能があると便利そうです。

meguro.rbという勉強会で使用して出てきた課題

2019/1/31、meguro.rbという勉強会に参加した際、実際に使ってみました。 その際、課題が見つかったので、追記させていただきます。

一時保存機能が欲しい

通信が不安定なところでノートを作成していた時に「データがなくなってしまうのでは？」と心配になる時がありました。

ツイートの並びが昇順になっていないバグがあった

ツイートの並びを昇順に設定していたつもりが、ソートが上手くいっていませんでした。

👉対応済み

分単位だと細かくて時間指定するのが面倒。10分単位など、もっとざっくり指定したい

1分単位だと、スマホで指定する際移動するのが大変でした。 10分、15分単位で選べると便利だなと思いました。

👉対応済み

「誰がツイートしたか」という情報が必要だと感じた

どういう文脈での発言なのか、経緯が知りたいと思うことがありました。 誰がツイートしたかの情報を書いても良いのかな？と思いました。

👉対応済み

勉強会ハッシュタグを保存するため、前回の検索情報を保存したい

一時保存してから再度編集しようとした時、 前回の検索情報がなく、再度検索の設定するのが手間だと感じました。

👉対応済み

一度に表示されるツイートの表示件数を絞りたい

現状、ツイートが100件縦長に表示される状態になっています。 これだと作業しづらさを感じるため、表示件数を絞りたいと思いました。

やっておけばよかったと思ったことについて

本ブログにも色々書いているのですが、他に書いていないことについて書いていきます🖋

最終的な成果発表の形を意識しておけば良かった

もちろんサービスづくりなので、一番大事なのはより良いサービスを作る事だと思うのですが、 私は目標の一つとして、最終的な成果報告の形をブログにしようと決めていました。

しかし、それを作り始めたのが結構終わりの方だったので、作り始めてから「あの時どうしたんだっけ？」と調べる事が多かったです。 そのため、早い段階で「どんな形でブログとして残してこう？」というのを考えておけばよかったな〜と後悔しています。

さいごに

本サービスの開発において、大変多くの方にサポートしていただきました。 フィヨルドブートキャンプのkomagataさん、machidaさん、並びにメンター・アドバイザーの皆さま、Rubyコミュニティの皆さま、きゅきゅさん主催の弱々エンジニア会の皆さま、ツイッターの皆さま、多くの方にご支援いただいたことで、サービスを完成させることができたと思っております。

この場をお借りして御礼申し上げます。 本当にありがとうございました。

今後もサービスの改善など、やっていきたいと思いますので、その際はご相談など乗っていただけると幸いです。

また、色々な人にお手伝いいただいたご恩に関しては、後進の方にも繋げていきたいと思っております。 「サービスの開発について聞いてみたいことがある！」という方がいらっしゃいましたら、 お気軽にご連絡いただければと思います。

連絡先：Twitter@s4na_penguin

以上、貴重なお時間頂きありがとうございました。