くりにっき

フルスタックキュアエンジニアです

2019年振り返り

ポエム

tl;dr;

色々ありました

登壇

特に意識していなかったんですが今年に入って1～9月まで大小色んなところで毎月登壇していました。

その中でも大きかったのは pixiv TECH SALONとRubyKaigi 2019の登壇ですかね。

inside.pixiv.blog

inside.pixiv.blog

特にRubyKaigi登壇の実績ができたことでRuby界隈でも認知度がそこそこ上がって自己紹介しやすくなったというのはあります。

余談ですがRubyKaigi 2020のCFPネタはまだ全くありません。*1

趣味コード

自分の場合作るものによって https://github.com/ と https://gitlab.com/ を使い分けているのですが*2、GitHubはほぼ毎日草が生えてます

f:id:sue445:20191231164805p:plain

https://github.com/sue445

f:id:sue445:20191231164839p:plain

https://gitlab.com/sue445

OSSは新規に作ったものだけで9個。

sue445.hatenablog.com

sue445.hatenablog.com

sue445.hatenablog.com

inside.pixiv.blog

sue445.hatenablog.com

sue445.hatenablog.com

sue445.hatenablog.com

sue445.hatenablog.com

sue445.hatenablog.com

一番反響は大きかったのは最後のplant_erdかな。

余談ですがOracle対応もだいたい終わってるもののもうちょいリリースに時間かかりそうです。*3

github.com

お仕事

社内ツールの整備、手作業の自動化、CI全般お悩み相談、辻PR *4など、「どんな仕事してるんですか？」って聞かれると困るくらいには手広く色々やってます。

代表例はこれです。

inside.pixiv.blog

推し事

プリキュアで2回（計3公演）、プリパラ＆プリ☆チャンで4回（計7公演）ライブに行ってました。

後者が多いのは単純にライブの数が多かったため。

ガァルマゲドンは推せる。

dic.pixiv.net

今年一番の思い出です。

見た映画

イベント上映やオールナイト上映とかで一度に複数本見てたりするので単純な映画の本数は把握してないんだけど、劇場に行った回数だけなら22回。

大半が新宿バルト9なんですが、夕方割で1300円 *7でちょいちょい見てるのが一番多いかな。こういう時会社が代々木にあるとむっちゃ便利。（会社から徒歩20分くらいなので定時ダッシュすれば夕方割の回に間に合う）

キンプリはいいぞ。（洗脳済）

ライフイベント

地上波デビュー

縁あって esa 利用企業の社員役として登場しています(\( ⁰⊖⁰)/)

商業誌執筆

縁あって執筆させてもらいました。

sue445.hatenablog.com

sue445.hatenablog.com

ソフトウェアデザイン 2020年1月号

ソフトウェアデザイン 2020年1月号

来年の抱負

「手作業を　誰でもできる　ようにする」でやっていこうと思います。

*1:LTネタは1つあるんだけど40分枠が思いつかない

*2: https://gitlab.com/sue445/tanuki_reminder や https://gitlab.com/sue445/gitlabci-bundle-update-mr のようにGitLabのシステムと密結合してるツールはドッグフーディングのためにGitLab.comを使ってる

*3:CI上でバイナリ作るところまでいけたんだけど、MySQLやPostgreSQLの実行時にもOracleのdllやlibが要求されてるのでバイナリ分けた方がよさそうな感じ

*4:Slackでなんか困ってる発言を見かけたら辻斬りみたいにサクッと直してPR投げる

*5: https://twitter.com/ac_ebina1/status/1080716559050432512, https://twitter.com/ac_ebina1/status/1080717398846582785

*6:https://twitter.com/ac_ebina1/status/1115162891039035393

*7:https://tjoy.jp/shinjuku_wald9/price

僕がOSS導入時に気にしてること

ポエム

前置き

  • 社のesaに投下したものの反応が薄くて寂しいので全体公開
  • 他人が作ったOSSを使うにあたって、もしあまりメンテされないOSSを使うと結局別のOSSに乗り換える必要があっておつらいので、僕がどんな観点でOSSを選択してるのかをまとめました
  • あくまで僕が見ている観点なので異論は認める

観点

GitHubやGitLabなどのリポジトリの場合

  • Star数
    • 多ければ多いほどいい
  • 放置されてるIssueやPRの数
    • 少なければ少ない方がいい
    • オープンになってるPRがたくさんあってもちゃんとレビューされてマージされてるのであればいいんだけど、放置されてるとヤバい
    • もしこの手のOSSを導入する時は最悪自分でforkしてメンテし続ける覚悟が必要（経験者談）
  • masterブランチやdevelopブランチの最終コミット日時
    • 最終コミットが1年以上前とかだとPR投げても依存ライブラリとかの関係でCIコケることがあるので要注意
  • 定期的にリリースされているかどうか
    • 最終tagとmasterの差分コミット数で見る
    • 小規模なライブラリであればPRマージして即リリースしてくれると嬉しい
  • CIのバッジ
    • ずっとビルドがコケてると誰も見てなくてメンテされてない可能性が高い

https://rubygems.org/

  • gemのDL数

https://hub.docker.com/

  • イメージのstar数やpull数やtag数
  • latestタグの作成日時
  • 定期的にビルドされてるかどうか
    • 手動でも自動でもいいんだけど定期的にイメージがビルドされてないと不安
      • 自分がCIで全自動dockerイメージリリースしてるだけに特にそう思う *1
    • 企業や公式がメンテしているイメージはそうでもないんだけど、個人がメンテしてるイメージは使い捨てが多くてGitHubに比べて全体的に質が悪い印象
      • なので、余計にオレオレイメージを作るしかないんだよなあという負の連鎖...

共通 (2019/12/29 11:30追記)

  • ライセンス
    • GPLじゃないかどうか
    • どこにもライセンスの明記がないと躊躇する
      • 個人リポジトリだと書き忘れてるだけの場合があるのでissueで聞いてみる

2019/12/29 11:30ブコメレス

id:otherworld

ライセンス気にしないのかな…

id:codingalone

まずライセンスでは？コピーレフトだと最悪なこになる

id:jacoby

GPL汚染とか怖くないのかな？

重箱の隅をつつくような細かい指摘ありがとうございます！

そもそもの発端が「死なないOSSを見極めるの難しいっすよね〜（なので活発にメンテされてるOSSを選ぶべき）」っていう社内での会話から雑に書き殴っただけなので、適切なライセンスが設定されてるか見るのは当たり前すぎて意識していなかったので追記しました。

*1:https://sue445.hatenablog.com/entry/2019/06/13/221004 参照

「自前でGitLabを管理するために知っておかなければならないこと」の付録 #gihyosd

gitlab

これは GitLab Advent Calendar 2019 - Qiita の18日目です。

大事なことなので最初に

僕がGitLab特集で書いた「自前でGitLabを管理するために知っておかなければならないこと」が掲載されているSoftware Design 2020年1月号の発売日なのでみんな買ってくれよな！！！

ソフトウェアデザイン 2020年1月号

ソフトウェアデザイン 2020年1月号

紙面の都合で当初のアウトラインや原稿から削った箇所があるのでアドベントカレンダーとして供養しようと思います。*1

付録A：GitLab.comを使いつつ自前のGitLab Runnerを使う

これはコラムで載ってはいるのですが、紙面の都合でだいぶ削ったので完全版を書きます。

以下、原稿での完全版

GitLabの面白い特徴として、GitLab Runnerを自由に登録できるというのがあります。

GitLab全体に登録するShared Runner以外にもグループ単位とプロジェクト単位で登録できるSpecific Runnerがあるため、 後者のSpecific RunnerであればSaaSであるGitLab.comであっても自前のGitLab Runnerを利用してCIを行うことができます。

SaaSであるGitLab.comだと全体で共有のShared Runnerが用意されているため通常は自分でRunnerを用意する必要はないのですが、下記のような理由でGitLab.comでもRunnerを自分で用意するメリットがあります。

1つ目の理由はShared Runnerの順番待ち回避のためです。前述の通りShared RunnerはGitLab.com全体で共有のため時間帯によっては待たされることもあります。 そのため自分でRunnerを用意することでこの順番待ちを回避できます。この自前のRunnerはShared Runnerとの併用もできます。

2つ目の理由はデプロイ用途です。CIは社外の環境で実行してもいいけど、デプロイだけはイントラネット内からの方が都合がいいことも多いでしょう。 外部からイントラネットにアクセスするための踏み台サーバを用意してもいいのですが、イントラネット内にデプロイ専用のRunnerを用意した方がセキュアで踏み台サーバ自体のメンテナンスコストも不要になるというメリットがあります。

下図のようにRunnerで指定したタグをジョブにも付与することで、指定したRunnerでのみそのジョブを実行することができます。

Runnerにdeployタグを設定する例

f:id:sue445:20191208011216p:plain

.gitlab-ci.yml でdeployタグを設定する例

deploy:
  script:
    - ./deploy.sh
  tags:
    - deploy

3つ目の理由はCIでの非Docker環境の利用のためです。GitLab.comのShared Runnerは全てDockerコンテナ内での実行が前提です。 通常のCIであればこれで問題ないのですが、WindowsやMacなどのマシンのハードウェアの機能をCIで利用したいということもあるでしょう。 iOSアプリのビルドをXCodeがインストールされたMac上で行いたいというのが最たる例でしょう。 このような場合はMacのマシンにGitLab RunnerをインストールすることでGitLab CIで実現可能になります。

以上はGitLab.comで自前のGitLab Runnerを用意する理由になりますが、これらは自前のGitLabにおいても用途によってRunnerを使い分ける指針になると思います。

付録B：公式Dockerイメージを使う

こちらはアウトラインには書いたものの、原稿を書く前段階で分量が多くて紙面に入らない可能性が高かったため削った内容です。

公式ではOmnibus GitLabを推奨していますが、Dockerに慣れていて自分でKubernetesやDocker Swarmでクラスタが組める場合には個人的には公式のDockerイメージを使うのもありだと思います。

hub.docker.com

ただしGitLabを動かしているホストマシンのgitユーザのみのsshをDockerコンテナに通す方法があまり資料がないのですが、下記を参考に設定してみてください。

オンプレミスでいく場合KubernetesかDocker Swarmが候補として挙げられます。

GitLab公式でHelm Chartが公開されているのでKubernetes派の人はこれを使うといいでしょう。

https://docs.gitlab.com/charts/

ただしLimitationsにもあるように制限事項がいくつかあって、一番大きいと思われるのはGitLab Pagesが使えないことです。

クラウドであればEKSやGKSなどのマネージドサービスが候補として挙げられます。

しかし注意点が1つあります。

EKSを使う場合同じAWSのマネージドということでデータベースでRDSを使いたくなるかもしれませんが、RDSだとデッドロックが発生する事象があるためそこだけ注意してください。*2

3rd partyのDockerイメージですが https://github.com/sameersbn/docker-gitlab というのもあります。

こちらは実際にピクシブ社内で使っていてその運用事例を下記にまとめているので興味がある人はどうぞ。

inside.pixiv.blog

*1:付録公開にあたって編集者の方からはOKを貰っています

*2: https://gitlab.com/gitlab-org/gitlab/issues/30528#note_215845940

ERDをPlantUML形式で自動生成するツールを作った

golang

PlantUML + ERDでPlantERDです

github.com

モチベーション

既存プロダクトへの不満が一番大きいです。

  • https://github.com/voormedia/rails-erd は出力が画像なので取り回ししづらい
    • そもそもRails前提なので他言語とかでは使えない
  • https://github.com/schemaspy/schemaspy も悪くなさそうなんだけどここまでリッチじゃなくていい
  • テーブル数個の小規模アプリならいいんだけど、中規模以上のアプリで使うと人間が読むに耐えないERDが生成されて精神が崩壊する
    • 僕は初めて触るアプリだと実装を把握するために特定のテーブルに隣接するテーブルのみ抽出して関係性を抽出してるんだけど、そういうことを自動でやりたかった

PlantERDの特徴

  • golangで作ったシングルバイナリなのでバイナリポン置きでどこでも使える
  • 出力形式がPlantUML（プレーンテキスト）なので取り回ししやすい
    • plant_erdで生成したERDをコミットすることでスキーマ変更前後の差分もgit上でいい感じに管理できると思います
    • UMLの出力だけ行うことで、テーブル配置の座標計算や画像生成などをツール内で考えなくてよかったのが嬉しい
  • 対応してるDBは下記
  • 「usersテーブルからForeign Key 2本以内の距離のテーブルまでを出力」のように、出力するテーブルを指定できる。（後述）

使い方

SQLite3だとこんな感じ。MySQLやPostgreSQLもオプションが増えるだけで使い方はだいたい一緒です

$ ./plant_erd sqlite3 --database /path/to/test_db.sqlite3

entity articles {
  * id : integer
  --
  * user_id : integer
  --
  index_user_id_on_articles (user_id)
}

entity users {
  * id : integer
  --
  name : text
}

articles }-- users

f:id:sue445:20191212225017p:plain

出力するテーブル数の制限について

例えばこういう7つのテーブルがあるとしてます。

$ ./plant_erd sqlite3

f:id:sue445:20191212230004p:plain

これを

$ ./plant_erd sqlite3 --table articles --distance 1

のようにオプションを渡すことで、articlesテーブルからForeign Keyで隣接する距離1以内のテーブル（つまりarticlesテーブルと直接隣接するテーブル）のみ出力することができます。

f:id:sue445:20191212230239p:plain

技術的に頑張ったこと

テストのこと

ツールの性質上MySQLやPostgreSQLといった外部のミドルウェアがないとテストができないという問題があります。

ローカル環境を汚したくなかったので このようなdocker-compose.yml を書いて docker-compose up するだけでローカルでMySQLとPostgreSQLを使ったテストができるようにしています。（MySQLやPostgreSQLの環境変数がセットされていなければスキップしてSQLite3のテストしかしない）

あとマトリクステストを頑張ったのでDockerHubにあったMySQLとPostgreSQLのイメージの主要バージョンは全部テストしています。

Foreign keyで隣接している別のテーブルを探す方法

大学の卒論でグラフ理論をやっていたのでその時の経験を生かしてgolangで無向グラフを実装しています。*1

詳しくはこの辺のソースを見てください。（途中まで行列を書いて数学的に説明を書こうとしてたけどブログウケしなさそうなのでやめた）

複数DB対応のつらみ

SQLのDDLやDMLなどはSQL99で仕様化されているので多少方言はあるものの各DB間でそんなに差異はありません。

しかしplant_umlで必要なテーブル情報やインデックス情報の取得方法は各DBの実装に大きく依存していたので実装するのはかなり苦労しました。

この辺に僕の苦労が詰まっています。

この辺の実装はactiverecordのconnenction_adaptersの実装をむっちゃ参考にさせてもらいました。

https://github.com/rails/rails/tree/v6.0.1/activerecord/lib/active_record/connection_adapters

追記：2019/12/13 9:45

id:tinsep19

schemespyでテーブルのリンク辿ると、距離1,2の関連図があるけどね

重箱の隅をつつくような細かい指摘ありがとうございます。

上にも書いているようにここまでリッチじゃなくていい（cliで完結したい）ってのと、gitでコミットした時に履歴が読める形式のdiffがほしいという理由でUMLで出力したいという気持ちがありました。（schemespyはサンプル見た感じ画像かsvgでしか出力してなかった。もし認識違ってたらまた重箱の隅をつつきにきてください）

あとPlantUMLは距離1,2に関わらず任意の距離の関連図を取れるのでそこだけは優位性がありますね。

*1:余談ですが大学の卒論ではC++で無向グラフを実装しました

Software Design 2020年1月号のGitLab特集に寄稿させて頂きました #gihyosd

gitlab

商業誌デビューです！

gihyo.jp

f:id:sue445:20191207005442p:plain

きっかけ

GitLab.JP の @hiroponz79 さんにお声がけいただいて参加することになりました。

僕の担当について

GitLab特集は全3章構成なのですが、僕は第3章の「自前でGitLabを管理するために知っておかなければならないこと」というタイトルで寄稿させて頂いています。

「自前でGitLabを管理するために知っておかなければならないこと」というタイトルの通り、僕の知ってるGitLab運用の知見を余すところなく書いています。

当初の予定だと GitLab令和最初のリプレイス。フルコンテナ化ポスグレ移行 - pixiv inside を深掘りした内容を書くつもりだったのですが、気づいたら全く別ベクトルのGitLab運用の話になって8〜9割くらい新規に書いていました。

GitLabが巨大なRailsアプリということもありどのRailsアプリでも汎用的に使えるunicorn-worker-killerの監視の話についても書いてるので、そっち方面での知見も得られると思ってます。

紙面の都合でいくらか内容を削ったので削った分は後日付録として別エントリで書こうと思ってます。*1

余談1

余談ですが、hiroponz79さんから声がかかったのと全く同時期に別方面でCI系の執筆依頼があって、てっきりSoftware DesignのCI特集で双方から僕にオファーがきたのかと思ったのですが、全く関係なかったというエピソードがあります。

ちなみに同時期に2本同時に執筆は体力的に厳しいのでもう片方のはお断りさせていただきました。

余談2

この記事の執筆中のBGA*2は アイカツ！ だったので、実質アイカツでできているといっても過言ではないです。*3

ソフトウェアデザイン 2020年1月号

ソフトウェアデザイン 2020年1月号

Amazonに自分の名前載ってるのすげーなｗ

f:id:sue445:20191207010829p:plain

*1:編集の人に問題ないことは確認済

*2:Back Ground Animation

*3:僕の好みはユリカ様です

HP Pavilion 23-q191jp ハイエンドモデルのメモリを増設した

3年前くらいに買った HP Pavilion 23-q191jp ハイエンドモデル のメモリを増設したのですが、分解に手間取った＆ググっても詳しい分解手順が書いていなかったのでメモ

注意点

  • 自分で分解するとメーカー保証を受けられなくなるので自己責任で！

メモリ増設の経緯

今回8GBから16GBに増設したんですが、8GBだと下記のようにかなりストレスフルでした

  • PCの電源を入れてまともに使える（ChromeとSlackが操作できる）ようになるまで20分くらいかかる
  • Slackのワークスペースをたくさん開くとメモリを食いつぶす
  • とにかく重い
  • 全てが重い
  • メモリ8GBには人権がない

ここまでくると本当にPC買い直すかなって気持ちになってたのですが、8GBのメモリが数千円で買えたのでダメ元で増設しました

分解手順

1. モニタの下のキャップを2つ外してネジを緩める

ネジを外すのではなく緩めるのがポイント。ネジを緩めることでカバーを浮かせられるようになります

詳しい事 teru-maru.com

f:id:sue445:20191206225255j:plain

f:id:sue445:20191206225123j:plain

2. 背面のスタンドを外す

これが最難関ポイント

スタンドの根本部分

f:id:sue445:20191206221503j:plain

実はカバーになってて外せます。キッチリハマっているのでマイナスドライバーみたいに固くて平たいものを隙間に入れないと外せないです

f:id:sue445:20191206221448j:plain

カバーを外すとネジが4つあるので、こいつを外さないとカバーを外せません。

f:id:sue445:20191206214843j:plain

f:id:sue445:20191206214850j:plain

ちなみにノーヒントでここのネジの存在に気づくまで2日間くらいかかりました。。。

3. カバーを外す

ネジを外すことで前後に開けることができるのですが、これもキッチリハマっているのでマイナスドライバーなどでゆっくり外しましょう

4. 金属のカバーのネジを外してメモリを挿す

写真の右下部分のカバーがネジ4本で固定されているのでドライバーで外すとメモリが挿せるようになります

f:id:sue445:20191206215603j:plain

f:id:sue445:20191206220114j:plain

5. 組み立てる

逆順で組み立てる

6. タスクマネージャーで本当に16GB使えているか確認する

タスクマネージャーで確認したところ、メモリは16GB認識されているものの、「ハードウェア予約済み」が9GBあって16GB分フルで使えない感じでした

ググったら下記のように「ブート詳細オプション」の最大メモリにチェックが入っていてOSで使えるメモリの上限が8GBになっているようでした

blueskyzz.com

チェック外して再起動することで無事16GB使えるようになりました

f:id:sue445:20191206232716p:plain

メモリ増設の効果

PCの電源を入れて10分ちょいで使えるようになったので効果はあった模様

tanuki_reminderを作った

gitlab Slack ChatWork

tanuki_reminderとは

マージされていないMRの一覧を指定した時間にチャットに通知するリマインダーで、 Pull Reminders のGitLabクローンです。

f:id:sue445:20191117012728p:plain

Pull Remindersが便利なのでGitLabでも使いたくて作りました。

gitlab.com

名前の由来

Pull Panda がパンダなので動物つながりでGitLabなのでタヌキにしました

余談ですがtanuki呼びは公式設定です

f:id:sue445:20191117084501p:plain

https://gitlab.com/gitlab-org/omnibus-gitlab/blob/12.3.4+ee.0/files/gitlab-ctl-commands/upgrade.rb#L178-197

技術的なこと

使い方

.gitlab-ci.yml に下記のようなジョブを書いてschedulerに登録するだけで使えます。

include:
  - remote: https://gitlab.com/sue445/tanuki_reminder/raw/master/ci-templates/slack_reminder.yml

slack_reminder:
  variables:
    # GITLAB_ACCESS_TOKEN: "" # [required]
    # INCLUDE_WIP: "false"    # [optional] put `true` or `false`
    # MERGE_REQUEST_COUNT: 10 # [optional]
    # SLACK_WEBHOOK_URL: ""   # [required]
    # SLACK_CHANNEL: ""       # [optional]

include:
  - remote: https://gitlab.com/sue445/tanuki_reminder/raw/master/ci-templates/chatwork_reminder.yml

chatwork_reminder:
  variables:
    # GITLAB_ACCESS_TOKEN: "" # [required]
    # INCLUDE_WIP: "false"    # [optional] put `true` or `false`
    # MERGE_REQUEST_COUNT: 10 # [optional]
    # CHATWORK_API_KEY: ""    # [required]
    # CHATWORK_ROOM_ID: ""    # [required]

通知対象のリポジトリにリマインダージョブを書いてもいいですが、通知専用のリポジトリを作ってschedulerに通知対象のリポジトリを複数登録するのが運用的に楽だと思います。

基本的にはGitLab CI上で動かすことを想定していますが、ビルド済のバイナリやDockerイメージでも配布しているのでGitLab CI以外でも使えると思います。