Kyashに入社して1年が経った

Kyashに入社して1年が経ちました 思ったよりもあっという間という感覚だけど、ここ1年を思い出すといろいろありました

今までと違ってGo言語の環境だしFintechだし色々と不安があったけど、普段使っているサービスに携わりたいという気持ちで飛び込んで良かったと思っています 一緒に働いているメンバーはみんないい人で楽しいし頼りになるし日々成長しているという実感を感じています チームのリードを任せてもらったりとチームメンバーと一緒にバックエンド側だけではなくていろんな方とコミュニケーションを取りながら楽しくやっています やはりどの会社でも課題はたくさんあって1年間で感じてきた課題をまたこの1年でどうにか改善していきたいと思い目標設定をして頑張っているところです Go言語頑張らねば!と思っていたけどどちらかというとドメイン知識をしっかりと培うことが大事で今でも四苦八苦しながら開発運用をしています そもそもGo言語はそんなに頑張らなくても覚えられるので大丈夫だった(今までの知見も役に立っていると思うけど)

プライベート的なところでは今までは邦ロック等のライブやフェスに行くことが多かったけどコロナを堺に完全になくなり、今はクラシックコンサートに多ければ月1くらいで行っている ライブ大好きなので出不精だし面倒くさがりだけどいくつかライブのチケット買って3月4月5月くらいは予定が出来ている テックイベントやカンファレンスなどにもオフラインで顔を出し始めているので会場でお会いした方とは色々とお話したいです キャンプにも月1くらいでは行っていてスパイスカレーにハマったり割と充実した日々を過ごしています

色々あった1年ですが常にモチベーションは保たれているような気もするし、メンバーのモチベーションを保たせる存在にもなりたいし、奮い立たせる存在でいたい 尊敬する人が増え、大変と感じることはあるけどやりがいは感じているし、新しい目標・なりたい自分というのも見つかった One Teamでやっていっている感が楽しい会社でワクワクしたものを作っているのでこれからも頑張ろうと思う

技術的問題へのアプローチを考える

これは Kyash Advent Calendar 2023 の16日目の記事です。

Kyashでバックエンドエンジニアをしている @a1yama です。

Kyashに入社して本日で9ヶ月が経ちました。

思っていたよりも時間が経つのが早く、充実しているのだと実感している次第です。

また、技術的問題へのアプローチを考えるというタイトルですが、入社9ヶ月で感じたことを綴ったものです。

はじめに

Kyashに入社してから様々なプロジェクトに携わってきました。

Kyashで働いているメンバーは個々人の問題解決能力も高く、提案もたくさん出してくれます。

こういうときどうしたら良いだろう、どうしたら良かったのだろうという悩みは話し合いで比較的早く解決できるように思っています。

その中で技術的な問題やリリース時の問題をどのように解決してきたかを簡単に紹介できればと思います。

パフォーマンスに対するアプローチ

Kyashではサービス開始時からのトランザクションデータを大量に保持しています。

そのため機能追加や改修の際にパフォーマンスや負荷問題について気にしないといけない場面があります。

期間も短い中でどこまでパフォーマンスを考えながら開発ができるか話し合い、パフォーマンス計測を行いその結果から何かできないか話し合うことになりました。

パフォーマンス計測を担当したメンバーが事細かにドキュメントにまとめてくれて、ボトルネック部分をシーケンス図に書いたり、テーブルのレコード数を算出してくれたりとかなり分かりやすいドキュメントになっていました(見せれないのが悔しいくらい)

その中からパフォーマンス改善案をチーム内で話し合って、総意を得た後にマネージャーやその処理に詳しいメンバーに展開していきました。

結果的にそのプロジェクトでは今のままでも耐えうるという判断となりましたが、今までボトルネックになっていた部分ではあるから改善案の中から一つの対応を行う運びになりました。

まだパフォーマンス改善の対応は完全には出来ていないですが、対応する際には有益なドキュメントがあるのでやることは明確になっています。

また、他のチームからの意見としてもパフォーマンス、負荷問題についての話はたまに出てくるので、その際にも説明として使える資料になっているので大変助かっています。

プロジェクトの開発が始まる前にパフォーマンスの問題に着目して計測をして改善案を提示できる良いチームだなと感じた瞬間でした。

Cacheに対するアプローチ

KyashのCache問題についてもエンジニアメンバーから度々話が出てくることがあります。

大量のデータを捌くためにCacheを使っているので、Cacheを保持するタイミング、消すタイミングを気にする場面がいくつかあります。

入出金、決済、送金などトランザクションデータが多い中で集計をしないといけないのですが、その中で更に家計簿機能が追加になり、集計期間がユーザごとに変わるようになりました。

その機能を加えていざリリースを行ったのですが、正しく集計ができておらず間違った表示になっていました。

リリースは取り下げて原因を調査した結果、Cacheが原因ということが判明しました。リリース後にCacheを削除しようという判断になり、手動でCacheを削除することで想定通りの表示となり無事にリリースを行うことができました。

リリース後の振り返りの際にCacheの話になり、チーム内でどうしたらよかったのか話し合った結果、CacheのKeyをちゃんとバージョン管理して異なるリリースのデータが混ざらないようにしていればよかったという結論に至りました。

もちろんCacheを削除するという対応も間違いではないと思いますが、Cacheのバージョン管理をしていたらそもそもリリース時の問題も起こらなかったと思います。

もしくは先に表示がおかしくなるので、Cacheを消す手順をリリーススケジュールに加えておくべきだったかと思います。

何か問題が起こった際にすぐに原因を調査して、振り返りができているのでチームとしての成熟度は上がってきているなと実感しています。

 

最後に

Kyashに入社して9ヶ月が経ちましたが、チームメンバー、エンジニアメンバーが素敵な方ばかりだなぁと感じています。

Kyash自体の文化もそうですが、エンジニアだけではなく他の部署の方々も素敵な方が多く楽しく過ごしています。

今まで好きだったサービスに関われていることも嬉しいですが、それ以上に素敵なメンバーに出会えたことを嬉しく思っています。

もし興味がありましたらKyashの求人から応募してください。

目標と継続

1月の更新を忘れたのとキリが良いので毎月更新はやめようと思う。 最近書きたいこともなくなってきたし、結構時間がかかるからさっと書きたいときに書くもので良いと思う。

恐らく今月か来月くらいにババっと更新することありそうなので。そんな案件があるので。

書くこと出来たり書きたくなったら書く。

雑記はほどほどに

教育の効率

なにかのプロダクトではないけど、勉強という意味で Laravel + Vue.js でアプリケーションを作成しようとした。

複数メンバーで開発(勉強)を行っていく中である程度の設計、教育をする予定でした。

最初は Laravel + Vue.js + Vue Router + Vuex で構築をしたのだが、Vue Router が理解できない。元々LaravelのRouterに書いていたのにAPIのRouterしか書かなくて実際のパスってどこ?みたいな状況になった。

教え方が悪かったというのもあると思うけど、Laravelを少しでも触ったことがある新人からすると、急にVue Routerを使うと分からないらしい。

かと言って、個人的にVueを使うならVueで全部書きたい思ってしまうのでVue Router、Vuexも使いたいところだったけど、実際の業務でもそこまでは使わないかもとのことだったので、Vue RouterとVuexは不採用となった(結局最初に作ったところでは使っているけど)

例えば管理画面の作成で一覧画面の表示をコントローラーでテーブル参照して、bladeで行う
追加画面などの処理はAPIで行うといった要所要所でAPIだったりそうじゃなかったりとソースが散らかるのが嫌だったり、結局Vue使う意味とかなくなりそうで怖い

目的がLaravel + Vue.jsの勉強なのでそんなことはないと思うけど、そういうことは大いにありそうで、そこだけは結構懸念しているところではある

何かを勉強する前に、どのように勉強をするのが効率的なのかなどを教えるほうが先だったなと少し後悔しているけど、それはまた教えればいいので、とりあえずやりたいようにやらせてみようと思った。

勉強でもアプリケーションを作成しようということですべてをきれいにやろうと思ってしまった僕がいけないので、きれいにやるところとそうではないところをちゃんと決めてやっていこうと思う。

リモートだし、最初からgitきれいに管理しようとしないで、途中でもレビューするために途中のものをコミットしてもらうとか。rebase教えるのはあとにしてログが汚いままで進めて、ソース書けるようにするところを目標にするとか。

教育も効率よくって思っていたけど、あまり良くないのかもしれないと思う今日このごろ。

windows で npm コマンド実行するといろいろ失敗する

windowsでnpmコマンド使わないほうがいいです。

めんどくさいです。

きっとmacがいいんだろうね。

mac book pro買ってください。

npm install

npm installすると共有フォルダとかいろいろの関係もあってなのかそもそもwindowsでダメなのかちょっとちゃんと理解していないけどシンボリックリンク等の関係でエラーになる

--no-bin-linkオプション付けて実行しましょう

npm install --no-bin-link

ちなみにvagrantとかで共有しているなら仮想環境からでもオプションつけないと怒られる

それでもダメなときがあるから基本的にnpmコマンドはwindowsで実行しろが鉄則

npm run dev

cross-envがないって怒られる

これに関してはpackage.jsonいじれとかあるけど邪道すぎでしょ

gitで管理しているファイル変更するのはさすがに良くないのでないならちゃんとグローバルにインストールしましょう

npm install --global cross-env

Laravelでvueとかいろいろあるから(そうじゃなくてもコンパイル前提のフロントエンドの時代だからね)この辺は流石にやっておかないといけないよね

クリーンインストールしてから久々にvagrant環境でLaravel Mix使ったから忘れていた

Laravelの開発ならdocker使わせて~!

せめて環境はキレイにプロジェクトに含ませておいて~!

GitHub Actionsで複数サーバにデプロイする

事前準備

以下のところで(githubのsecrets)秘密鍵を登録する 名前は適当なものをつける 今回はSSH_KEYにした

https://github.com/{ユーザ名}/{リポジトリ名}/settings/secrets

実装

ルートの .github/workflows/deploy.ymlに以下を記載 ymlファイルの名前は適当なものをつける

name: deploy

on:
  push:
    branches:
      - master

jobs:
  deploy:

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v1
      - name: composer install
        run: composer install
      - name: ssh key generate
        run: echo "$SSH_KEY" > key && chmod 600 key
        env:
          SSH_KEY: ${{ secrets.SSH_KEY }}
      - name: rsync deploy for remote1
        run: rsync -rptgDvz -e "ssh -i key -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" ./ www@ホスト名:デプロイ先
      - name: rsync deploy for remote2
        run: rsync -rptgDvz -e "ssh -i key -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" ./ www@ホスト名:デプロイ先

masterブランチにプッシュされたら仮想のubuntu環境でcomposer installして、secretsのSSH_KEYからkey作ってrsyncするってだけです。 普通に1箇所にデプロイするだけでも十分なのでこれでやってみるといいかも ただrsyncしているだけなので、ドットファイルとかデプロイ時に作成したkeyファイルも一緒にデプロイされているので、削除する処理が必要 rsyncのdeleteとかでも良いのかな?

参考になったところがいくつか記号をわざとなのか全角にしていてコピーしづらかったのでちゃんとしたやつです。

Laravel6.*でvue環境構築の準備

プロジェクト作成

composer create-project --prefer-dist laravel/laravel vue-laravel "6.*"

2020.10.31現在で6.20.2が降ってくる

$ php artisan --version
Laravel Framework 6.20.2

laravel/uiインストール

composer require laravel/ui:^1.0 --dev

laravel/ui vueインストール

php artisan ui vue

## フロントエンドパッケージインストール

npm install

Vue Routerインストール

npm install --save vue-router

フロントエンドビルド実行

npm run dev

参照 qiita.com Laravelの開発よって一部変わっていたところがあるのでメモ 多分しばらく8とかは使わないと思うので

僕らには選択する権利がある

技術ブログとはなんなのか。最近ほとんど雑記ばかりで申し訳ない。 誰に対して書いているわけでもなく自分の記憶を文字にしてあとで思い出すものだから気にしないけど。

フリーランスになってからいろいろと仕事をしてきた。 ほとんどが昔の知り合いとの仕事だけど、それで生きているんだけど、たまに全く別口からの仕事もある。 結論としては素人とは仕事したくないなのだけど、細かいことは以下の通り。

まぁその仕事が酷いという愚痴なんだけど、SIer上がりだからとか、個人仕事が自社開発のゼロ構築とかそういう話ではなく、単純に仕事として、一人のシステムエンジニアとして、話したい。 基本的に顧客はITに疎いとしても少なからずビジョンをもって仕事を依頼してくるものだと思う。 中には「ITよく分からないけど、エンジニアってなんかそこそこお金出せば全部やってくれるんだよね」みたいな感じで接してくる人いるけど本当にそういう顧客が一番めんどくさい。

サービスのアカウント作成も出来ないとか普通にいるし、いい感じにサイト作ってとか、参考資料も何もないし、素材も使えそうなものが全く無いとか。 そのくせ作ったものに対しては文句ばかりで変更の連続。 最初からそのイメージがあるならちゃんと共有してほしい。 イメージどおりに作っているのに、イメージをこちらが提供するなら別にエンジニアに頼まなくても自分たちでやったほうがいいとか言い出すし。 それならまずデザイナーとでも話し合って作りたいもののイメージ作れば良いのでは…そういう手順の話もしたのに。

素人とは仕事したくないんだけど、全部こちらに丸投げでイメージもなく、何も出来ないような人とは仕事したくないという感じですね。 IEでしか動かなCMS作っていた会社とか、勉強するからとりあえず作ってくれたらあとはやるよ(結局今サイト放置されている)って言ってきたおじさんとかいたけど、少なくともパソコン触れたし、最低限のことは出来ていたけど、それでもそのレベルでも一緒に仕事することでストレスは溜まっていくし、その結果他の仕事に支障が出る。 お金の問題ではなく単純に人としてやITリテラシーの問題ではあるんだけど、そういう人とはいくらお金を積まれても仕事はしないと心に誓った。

せめてやりたいことがしっかり固めて、必要な使える素材なりをちゃんと揃えてからお話ください。

あとワクワクしない仕事は義理でもやらないってことかな。 生活できるお金は稼いでいるのでとりあえず精神的に不利益になることはしない。

投資でもして生きていこうかな。

HHKB HYBRID Type-Sについて

HHKB Professional BTを買ったのが2016年12月22日だったので、それから約4年経って新しいHHKBを購入した。 HHKBは恐らく何十年も使えるキーボードだと思うので、HHKB Professional BTはそのまま別のところで使うことになると思う。

まずType-Sの静音性については普通のHHKBと比べるとかなりすごい。 これはもう普通のHHKBには戻れないかもしれない。 この打鍵感と静音性は癖になる。

キー配列は今までと同じでUSなので、なんの問題もないです。 キーマップの変更があるけど、AutoHotKeyでカスタマイズしている関係で場所によって、前のキーボードを使うなどすることを考えると、わざわざ変えなくてもいいかなと思う。 MacライクでAltの空打ちでIMEの変更しているので、どうしてもAutoHotKeyは必要だし、今までの運用で良いかなと思う。

正直静音感以外は何も変わったところは無いけど(これは僕の使い方の問題でHYBRIDは様々な変更点があるので素晴らしいです)、もう一台欲しくなるほど打鍵感が良いのでおすすめしたい。

ぺちぺちキーボード使っている人からするとうるさいって言われそうだけど、個人的にはかなり静かだと思う。 これで通話しながらキーボード打っていてもうるさくないと思う。

今までのHHKBの打鍵音もキーボード叩いているって感じがして好きだったけど、今はこの静かなスコスコ感の虜になっている。

オンラインコンクール開催にあたっての反省点

縁がありオンラインコンクールの主催をすることになった。 しかし準備期間は1週間。要項を決めたり審査員を決めたり方法を決めたりして1週間が終わった。 その間普通に他の仕事もあったので時間は全然足りなかった。 ある程度睡眠時間を削ったが仕事が山積みでようやく最近終わったものもあったり、本当に大変な期間だった。

1週間で開催したので、本当になんの準備も出来ていなかった。 特にサイトから申し込みがあった際にメールから名簿を作らないといけなかった。 本来ならDBなどで全て行いたいところだったのにそれが出来なかった。

その次に参加者から動画が送られてくるのだが、全て手作業で名簿にURLを追記して管理したり、本当に管理面で大変なことが多かった。

審査してもらうにしても毎回URLを審査員に送るという手間があった。 専用のサイトを作るや、マイページで管理するなどやり方はたくさんあった。

参加者にはマイページより、振り込みの証明書や動画URLを送ってもらい、審査員は専用ページから審査する参加者の動画を閲覧。点数をつけたりコメント動画をアップしたりする。 参加者はマイページで審査結果やコメント動画を閲覧できる。 必要メールはフラグが立っている参加者へ一斉送信出来る。

最低ここまでは実装したかった。 結果は何一つ出来なくてすべて手作業。 毎日1時間を削って作業したがとてもではないが間に合わなかった。

また、審査期間などそのあたりももう少し余裕を持てばよかった。

たくさん反省点があることはとても良いことなので、次回開催の際にもう少しシステムは組んでおきたい。

たくさんご迷惑をおかけしてしまったので、とても落ち込んだ時期もあり辛かったけど、これからもこういった分野でもなんとか生きていけるように頑張りたいと思う。 システムで快適になる可能性があるものをどんどんシステム化出来るように日々精進していきたい。