Fly.ioへのデプロイをGitHub Actionsで自動化する
この記事の立ち位置
- 自身の構築時のメモで、Fly.ioが公開しているドキュメントから変更した部分や、他に参照したドキュメントを書く。
- 2023年2月時点の情報で、内容・リンクが変更となる可能性があります。ご了承ください。
大元のドキュメント
やること
今回はすでに作成済みのリポジトリを想定。
- コンソール上で
flyctl auth tokenを実行し、トークンを取得。 - リポジトリのsecretsを設定する。キー名は
FLY_API_TOKEN。
対象のリポジトリの"Settings"→"Secrets and variables"→"Actions"→"Secrets"の箇所。 fly.tomlというデプロイのための情報が書かれたファイルをgit追跡対象に設定(.gitignoreから外す) 。.github/workflows/fly.ymlというGitHub Actions用のワークフローファイルを作成する。
fly.ymlファイルの中身
詳細はドキュメントのここからを参照。 今回は一部改変を以下のように設定。
name: Fly Deploy
on:
pull_request:
types:
- closed
branches:
- main
env:
FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}
jobs:
deploy:
name: Deploy app
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: superfly/flyctl-actions/setup-flyctl@master
- run: flyctl deploy --remote-only
変更箇所
GitHub Actionsが走るタイミングを「ｍainブランチにpushされたとき」→「mainブランチにプルリクエストがマージされたとき」に変更。
環境が2つある場合
例えばproduction/stagingの二環境が存在する場合、以下のページを参考にfly.tomlをfly.xxxxx.tomlといった形で複数作っていると想定。
この場合には以下を変更する。
.github/workflows/fly.ymlもfly.xxxxx.ymlといった形で複数作成する。- 実行条件内の
branchesを分ける。 - 最終行の
- run: flyctl deploy --remote-only末尾に- run: flyctl deploy --remote-only --config fly.xxxxx.tomlというように利用するtomlファイルを明示的に指定する。(コンソールでのflyctlと同じような考え方。)
設定してどうなったか
Fly.ioはデフォルトだとローカルからファイルをアップロードしてデプロイする形式。
以下のようなデメリットがあったので、これらが解消され、カフェでも作業ができるようになってホクホク。
もちろんCI/CDらしくもっとテストを走らせるとかゴニョゴニョできるようになりたい。
最後に
GitHub Actionsを始めて触ったものの、あまり引っかからずに設定ができた。
Circle CIからGitHub Actionsに移行しつつあると聞いたので、もっと触ってみたい。
BeRealなんぞや
もしかすると全く思わぬところからコメントがもらえるかもしれないので、コミュニティのtimesに書いた内容をブログにもしておく。
BeRealとは
BeRealは最近海外の若者に人気な写真共有アプリ。AppStoreに書かれているコンセプトとしては「BeRealにて本物の友情を築こう。」
読み方はサイトによって違うが、AppStore上では「ビリールと読みます」と書いている。
インスタなどとの違いとしては以下のようなもの。
- フィルター加工ができない
- 1日1回ランダムに通知が届き、2分以内に写真を撮ってシェアしなければいけない
- 他人の写真にリアクションをつける場合には自分の顔つきでリアクションを行う
2022年にはApp StoreのAppアワードにも選ばれている。
コンセプトなどを知った時の感想
インスタとかの映え文化の疲れから生まれたというのはアイディアとしては考えられるよねと思う。
ただ、都会に疲れたから田舎暮らしする！みたいな印象があり、今とは違うものが必ずしも自分に合っている！（はず！）とコンセプトであれば盲目的で違うよねと感じた。
田舎の、とはまた違うがこのアプリの良さ・アイデンティティはどこにあるのかを知りたいという気持ち。
断捨離やマインドフルネスといった煩悩を断つような使い方なのか？
気になって色々と調べてみる
意外とAppStoreのストア情報を見てみると「BeRealは中毒性があります」「BeRealを使うと感情的になるかもしれません」といった文言も書かれていて、必ずしも逆を行きたいというわけでもないんだなと思う。
使ってないうちにアレコレ批評するのも筋違いだと思うので、今度試してみる。
別観点だと
一方でZenlyなど、今までの感覚だとクローズドとはいえ他人と位置情報を共有するという行為はハテナと感じることもあったが、このアプリもそれに類するような考え方を適用すれば理解に一歩近づけるのかなという妄想もした。
Z世代のインサイトはよく分からないという気持ちもわかるし、どう頭を切り替えていくのかも個人的にはすごく気になる。
今までのアプリと違って、企業が宣伝のためにアカウントを運用することもしにくく、思い違いをしているとすぐに燃えそう。
最後に
今までのアプリとは違う面も合って話題としては面白いと思うんだけど、なんでこのアプリが良いの？はこれだけではなくプロダクトづくりにも関係しそうなので考えてみたい。
追記（2023/1/25）
コミュニティ内に投稿したTimesには以下のような反応があった。
- マネタイズを考えても課金と相性が悪そうに感じる→調べてみると、課金・広告がなく、調達した資金をアンバサダーに配っているなどしていたようで、ますます謎。
- コミュニティ内で使っている人は学生時代からの友人とふざけた写真を投稿しあっていて、Vineで投稿するような感覚に似ている、とのこと。
「先生、どうか皆の前でほめないで下さい―いい子症候群の若者たち」読了
初めに
それなりにゆとり世代の自分がもう一回りくらい下の人の内面を知りたく、書店で見かけたり話題になっていたので以下の本を読んでみた。
先生、どうか皆の前でほめないで下さい―いい子症候群の若者たち
簡単に感想
正直なところ、本書を読んでの感想を述べたり、受け止め方が難しいなと感じた。
8割くらいは若者（高校生〜大学生くらいが焦点）ってこんな感じなんですよ、という現象の説明が書かれており、いわゆるこうすれば良いよという共有するハウツー本ではなかった。
あとは「誘われたら職場の飲み会に参加する（断る方が面倒だから）」といった何となくの想像・直感と反することが多く書かれていたのが印象的であった。
本を読んで自分の行動をどう変えるか
アラサー・ミレニアル世代の自分としては半分くらい本に書かれている"若者"と同じような気持ちがあったり、一方で「こんなポーズを取ってうまくやっているんだな」と感心するような部分も多々あった。
例えば前者は「社会貢献がしたい」にしても「（誰かが調整してくれて、意思決定してくれて、動くためのマニュアルもあってお膳立てされた状態であれば）社会貢献がしたい（してもいい）」という思いがなかったかは考えさせられた。
なので自分に落とし込むなら本書で突っ込まれているような事については自身の認知が歪んでないかは見直したい。
あとはこういった考え方を持つ人を部下に持ったときにどう動かすかというのは正直なところ難しそうだなと感じている。
「究極のしてもらい上手」の項にあったように、自分でやった方が早いと考えてしまって逆に自分がやらされてしまう、という状況はすごく滑稽だなと。
自分でも転職を機に教えてもらう立場になることもあるので、タスクを任せる/任される、権限を委譲するといった手法や状況にはアンテナを張るようにしたい。
最後に
また読み返してみて考え方が変わったり、似たようなシチュエーションに遭遇したら記事を書くかも。
全体としては単純な事象としてというよりは、今までの世代の経緯であったり集団としての事象が書かれており、暖簾に腕押しっぽい印象を持ってしまったので、まずは自分の考え方とかに穿ったところがなかったかといったことから見直してみる。
2022年の振り返り
はじめに
最近は個人開発に比重を置きすぎてアウトプットできてない感が半端ないので、簡単に大きなトピック単位で振り返る。
各論
1.退職
今年はこれが大きかった。キャリアやスキルの先行きに対する不安だったり、忙しいプロジェクトでの燃え尽きだったり、人間関係だったりとこねくり回せばそれっぽい理由は付けられると思う。
ただ、個人的には30になる前に会社の看板を外して色々とチャレンジしてみたかったかったという面が大きかったと思う。
他責にするのは簡単だけど、そろそろ自分で意思決定するか、という感じ。
2.個人開発・勉強
幸いコミュニティで周りに同じように個人開発を頑張っている人が居るという感覚に助けられていると日々思っている。
あとは今まであまり見れていなかったIT関係のウェビナーも退職前や退職してから見まくった。（月に20本弱とか）
スライドでしか見たことがなかったt_wadaさんの質とスピードの講演を見て感銘を受けたのを覚えている。
良い話は何回聞いても新しい発見があるので面白い。更に勉強することで自分の発達の最近接領域が広がっているのもあるんだと思う。
そして12月くらいからはようやく暖め続けていたアイディアで個人開発を続けるも、出せるアウトプットがしょぼすぎて(’・ω・`)ってなってる。
今のところ、WIPで行けよという思いとか色んな葛藤と戦う毎日。
これは2023年になってある程度形になったら再度振り返る。
あとはコミュニティ内で輪読会に参加したのも個人的には大きかった。
今年発売した「エンジニアリングマネージャーのしごと」や「LeanUX」といったプロダクト・EMに寄った話と、Webセキュリティでは外せない名著である通称「徳丸本」を読んだ。
前者ではWeb系のカルチャーやプロダクト開発の考え方などを垣間見ることができ、色んなバックグラウンドの参加者の感想を聞いたりアジャイルコーチをされている方の一言などとても勉強になった。
後者では本当に基礎的なXSSやインジェクション、JSでは外せないCORSなどの話も理解しようと頑張れた（息をするようにできるところまではまだ未到達）ので、すごくためになった。
（徳丸先生のYouTube動画を徳丸本と一緒に見ると疑問が解消されたり、より理解が進んだので昔見たときよりも感動があった）
退職してから3ヶ月くらいなのでまだまだだとは思いつつ、果てが無いのと自分は組織に貢献したりするのが好きな性分だと思っているので来年は就活を頑張る。
3.私生活
これは驚くほど変化がないので2023年に期待、という感じ。
退職して外出する頻度は増えたが基本はカフェでPCカタカタしているだけなので、、
事務手続きを溜めたり面倒だなと感じることも多いので、この辺りもやはり会社員が性に合っているなと思う部分。
あとは大盛りじゃなくても足りたり、胃もたれが多くなった、、、
総論
「オレはようやくのぼりはじめたばかりだからな このはてしなく遠い男坂をよ…」（未完）
（年明け開発が一段落したらもう少し書きます）
競プロ世界ランカー×AI
動画を見た感想
あまりはてなブログ書けていなかったのでフリーフォーマット気味に書く。
ChatGPTの流行はさるもので、競プロ界隈にもその余波が来ていた。 （私自身はアルゴ式を最近触り始めたレベルなので、おっ？くらいの感覚で見ていた） 前後してしまうかもしれないが、「AIを使ってAtCoderを取り組むのってどうなんでしょうか？」といったことが代表の耳に入ったため、こういった声明が出された。
この後、chokudaiさん×ChatGPTでAIが書いたコードのみをコピって回答できるのかという試み(本人ノリノリ)が行われた。
この放送日の前日に行われたため、学習が行われていないであろうAtCoder Beginner ContestのA〜F問題に取り組み、Dまで解けて4完という結果だった。 点数というよりはここに至るまでの過程が面白く、いろんな事が起こっていた。
このくらいならまだいい方だが、
- 後半はChatGPTが画面に出力しきるまでの時間がボトルネックになった。
- 最終的には赤文字のエラー文言を出力して何も出せなくなった(吐血エンド)。
また、最終的には4問解けたが、かなり序盤からChatGPTの回答そのままでは正解ではなく、人間が誤っている箇所を指摘修正してもらう必要があった。 更に途中からはほぼ人間が実装方針を与えて、それに沿ってAIに解かせるという英才OJTのような事が行われていた。 なので例えば私レベルの初級者がChatGPTを使用して、AtCoderに取り組んでもほとんど点は取れないかなという印象だった。
ある程度競プロに親しんだ人が使えば満点では無いにしろそれっぽい回答がもらえるので補助としてなら使える、という立ち位置もあるだろう。（今回は自分で書いた方が早いということはしない縛りだった）
対話、コミュニケーション
ただ個人的には、より対話で正解に近づくためのアプローチも楽しそうだなと感じた。 動画の中でも上司と部下のアナロジーがあったように、ほとんど全部上司の言う通りに書いたというよりは、然るべきコミュニケーション・対話を取ることでアウトプットが出るのが理想的なんだろうなと思う。 とはいえ、この辺りはchokudaiさん的には「AIはどのあたりがわからないかを教えてくれない」と言っており、それもそれでなるほどなと思った。 そして上司は成果物をちゃんとレビューをできたり、真偽がわからないといけないのだ、、、
この辺りの対話が上手い人のイメージとして、数学ガールの結城浩先生が思い浮かぶ。 自身もChatGPTやAIの画像生成ソフトで遊んでおり、まるで人間と対話するかのように創造的なことをしているという印象を受けた。
競プロ的な使い方でなくても、対話でWebアプリを作ることも行われており、退屈なことはPythonにやらせようライクな世界になるのかなと考えを巡らせる。
そう考えるとAIや自動化の果てで人間しかできないコアコンピタンスってなんなんだろうなと真面目に考える時代が来たのかもしれない。
追記： あんまりchokudaiさんのブログの方を読まずに感想書いたらブログでちゃんと語っていたので後で読む。
「マーケターのように生きろ」読了
読んだ本
以下の本がKindle Unlimitedの対象になっていたので読んだ。
マーケターのように生きろ―「あなたが必要だ」と言われ続ける人の思考と行動
まず結論
これまでフワッとマーケティング面白そうだなーと思っており、この本を読むことでマーケティングの価値を認識した。
おそらく基本的なマーケティングの話も多かったと思うが、知らない内容ばかりであった。
また自分の性格とも親和性があるなと感じる部分があったため、もうちょっと他の本を読んだりして学習したい。
背景
エンジニアであまり接点はなかったが、マーケティングに興味を持ったキッカケは以下だと思う。
- プロジェクトでスマホアプリのマーケティングであったりプロモーションに携わることがあった。（社外へのプロモーション出稿や社内オウンドメディアへの出稿など色んな経路があった）
- 洗濯を干す時に聞いていた耳から学ぶマーケティングというチャンネルで色んな会社の事例を聞いた。
本書での個人的な共感ポイントまとめ
自分発信の「アート思考」に対して、他人軸で考えて顧客に価値を届ける「マーケティング思考」
マーケティングには①市場を定義する、②価値を定義する、③価値を作り出す、④価値を伝える の4つ。
また、マーケティングの4PとはProduct(商品), Price(価格), Place(販路), Promotion(販促)であり、目を引くプロモーションのことだけではない。また上のプロセスでもプロモーションは「価値を伝える」の部分でしかない。
（一方エンジニアは③価値を作り出す、とProductに集中しがちな気がする。相互に補完することが大事そう。）
- 物の価値には「顕在的⇄潜在的」「実利的⇄情緒的」の2軸、4象限が考えうる。参考
一番わかりやすい顕在的かつ実利的な実利価値のみにフォーカスしがちだが、例えばおまもりのような潜在的かつ情緒的な価値も存在する。
ただし相手にとって価値を感じられなければいけないため、相手から見つけ出すのは難しい。
考えたこと
- 自分の性格（この記事参照）を鑑みると、ユーザーの価値を考えるマーケティング的な考えと親和性が高いと思う。
- マーケティングのプロセスおよび4Pはどこかを突出させるわけではなく、いずれも満たしていく必要がありそう。
- 一方でその商品がもたらす価値といったポジショニングは明確にしなければブレそう。
ただし、潜在的や情緒的を相手の目線になって考える→作る→伝えるというプロセスは難易度が高いように感じたので、もう一度本書を読み直したり、別軸でスキルとして学びたい。
最後に
教科書的にマーケティングについて教えている本ではないが、おそらく著者の意図していたマーケティングってこんな感じのもので、人を理解して期待に応えらるマーケターのような生き方はどう？という主張は刺さった。
おまけ
読了後ちょっと時間が経ってから感想を書いていて、読書中メモも取っていなかったので割と前半部分に寄っていたり中後半の具体例を覚えていないので、もうちょっと本の読み方を考えないとと思う。。
今までの経験を棚卸し（2022.11）
はじめに
自分の現時点での経歴を、職務経歴書よりもカジュアルに書いていく。 背景を共有することでこの人はなぜこういったことを言うのだろう、を理解しやすくしたい。 一方劣等・優越コンプレックス的にならないように気を付ける（戒め） 身バレしてもそこまで痛くはないけど、ある程度はボヤッと書くとこもある。
概要
院卒だったので24歳くらいからIT業界に入り、 大体1年周期くらいでプロジェクトを移り変わり、手を変え品を変え色々やってきたなと思う。 この他に自主的に学習したりRUNTEQに通ったり。
やったこと
担当したプロジェクト一覧（一応ファーストビューで見れないように畳む）
1.金融系の保守開発プロジェクト（1年くらい）
- 役割：PjM補佐的な感じ、要件定義とか顧客折衝・UAT補助とかとか
- 技術：PHP, Oracle,... (開発はしなかったので、ほぼシステムは触らず)
- 一言：新卒で開発でもなく、プロパーがほぼいない中でプロジェクトを回していたので正直一番辛かった時期。気軽に相談できる人は大事。新人だったのでちゃんと色々やらかす。
2.証券系の保守開発プロジェクト（1年くらい）
- 役割：開発メンバー、移行計画担当
- 技術：Java(SpringBoot), Oracle, Linux, SVN...
- 一言：でかいシステム群の一番端っこのシステムの保守開発。ここはチーム体制だったり社内に有識者がいたりと1つ目よりは良かった&楽しかった。ただ、SVNでソース管理&本番端末室リリース(コロナ以降は変わったらしい)といった、古き良きパターンだったり、ドキュメントがガチガチレビュー&管理だったりとメリデメあるなと、、
3.証券トレードサイトの基盤更改プロジェクト（3ヶ月）
- 役割：開発メンバー、本番移行の作業者、コードレビューを齧る
- 技術：Java(Spring), MySQL, Linux, redis, git, AWS...
- 一言：本番リリースのための補強要員的な感じ。技術的には一番ちゃんとしてた&楽しかった。（とは言え、ドキュメントと実態の乖離など負債はモリモリ。）大きめの本番リリース特有の緊張感や深夜出勤とかを初めてしたのも印象的。
4.スマホアプリローンチプロジェクト（1年くらい）
- 役割：PMO、移行計画、ストア審査関連の社内申請、セキュリティの社内申請・社内システム管理
- 技術：Rails, MySQL, Android, iOS, AWS...
- 一言：スマホアプリの初期リリースだったので色々大変なことはあったけど、技術・ビジネスなど色んな観点で知見は増えた。技術的にはコンテナが使われていたりと一番モダンな感じ。デカい会社だったのでOSSとかよりはその会社のルールに詳しくなる。。フルリモートで、開発したいなーというフラストレーションと人間関係の大事さを思い知る。
5.RPA保守運用プロジェクト（9ヶ月）
- 役割：開発メンバー、ユーザーとの折衝・問い合わせ対応
- 技術：UiPath, SQLServer, Windows, SVN...
- 一言：がむしゃらにやっていたし、対ユーザーの度胸がついたり、最後辺りはある程度動けるようになったけどシステムについては反面教師にする点は多々あり。
あとで見返す用に残しておく
・RPA関連のリソースはソース管理されていない
・誰でも触れるNASに置かれているプログラムが本番として動く
・検証環境がなく自動化対象のサイトの本番アカウントを利用する必要がある
・ドキュメントが基本Excel管理なので最新の事象やステータスがイマイチわからない
・数十のRPAが日次・月次で動いており、皆やっていること・子細の仕様がバラバラ(ドキュメントなし)。かつ色んな要因でよく落ちる。
・エラーアラートがメールorダッシュボードを自主的に見るしか取得できないため、数分に一回見にいく習慣がつく（コンテキストスイッチ壊れるぅ）
・社員と被らない時間帯にzoomを借りないと画面共有ができなく、社内PCにRDPしている都合上通話時に2秒くらいラグがあるので顔の見えない相手と国際電話する感じになる。
技術スタック(左からできる順)
言語：Ruby, Java, JavaScript, (PHP) フレームワーク：Ruby on Rails, Spring Boot, Vue, React Native DB：MySQL, Oracle, SQLServer, DynamoDB ソース管理：gitとSubversionがどっこいくらい、、 AWSはEC2でのサーバ立てるとかLambda・APIGatewayとかの簡単なサーバレスがちょっとできるくらい。 その他 - スマホアプリ審査関連の知識 - GA4とかマーケティングツールとかをちょい齧り - 脆弱性対応をしたり、大企業の体系化されたセキュリティルールを見たりすることでセキュリティ周りもなんとなく。
終わりに
全体的に2ヶ月くらいガチれば追いつかれそうなくらいしかやってないので、自主学習頑張る、と言う締めで終わり。
