kinoppyd.dev

blog

products

accounts & contact

kinoppyd dev

kinoppyd blog

hello jekyll

2022-12-01 00:00:00 +0900

このエントリは、SmartHR Advent Calendar 2022の1日目です。

Hello Jekyll

ブログをWordpressからJekyllにお引っ越ししました。3年くらい前からWordpressから静的サイトジェネレーターに乗り換えたいなぁと思ってたけど、大分腰が重かったです。めちゃめちゃ重かったです。移行したことを褒めてほしい。すげえ気持ちが大変だった。

いっっっっっちばん腰が重かった理由はMySQLで、ブログを始めた当時の自分はブログ以外にもいろんなプロダクトとDBインスタンスを共有しようと思っていたので、Wordpress用のサーバーとは別にMySQL専用のVPSを借りました。そしてWordpressとMySQLはインターネット経由でつなぐため、SSLで通信していました。ブログにも書きましたね。なんですが、2014年にHeartbleed脆弱性が見つかり、各OSが古いバージョンのOpenSSLを使った通信を拒否するようになりました。なので、2018年とか2019年頃に「Wordpress移行してえなぁ……」と思っても、Wordpress用のDBからJekyll用のファイルに直接エクスポートツールがMySQLとSSL経由で通信できなくなり、いろいろな手を講じてエクスポートするのがとにかくめんどくさくてめんどくさくて……2022年11月まで放置することになりました。まあ結局、Wordpress側にXMLエクスポート機能がついていることに気づき、XMLをJekyllのMarkdownに変換するためのツールもあったので、それを使うことによって今までのSSLに関する努力は全部無駄になりましたが。

Why Jekyll

ブログの移行先は静的サイトジェネレーターを使うことは決めていました。Webアプリケーションとして動いているブログは、アップデートに追従するのが精神的負担すぎると感じたためです。デプロイなどの自動化を行うというのもありますが、その自動化をメンテするコストもバカにならないし、自動化されたシステムを維持するのって金銭的コストもかかるんですよね。お金を生んでくれるシステムならいいんですが、単なるブログに月に数千円払うのはだいぶ経済的な負荷が高いなと感じます。それならば、単純な静的ファイルを生成してくれるジェネレーターの方が良いなというのが理由です。コメント欄がなくなるくらいしかデメリットないですしね。


zoomガチャ

2021-12-01 00:00:21 +0900

いえーい、どもども、ハッピー……何だっけ? 12月なんだから何かしらがハッピーな……えーっと、あれよ、その……アレだ、いえーい! ハッピー! やったー!

この記事は SmartHR AdventCalendar の1日目です。

アジャイルチームとガチャ

SmartHRの各チームでは、今年はだいぶアジャイルチーム、とりわけクロスファンクショナルチーム化を目指す流れがありました。多分クロスファンクショナルチームをググると、各分野の専門家たちが1つのチームで問題解決に当たる的な話が出てくると思いますが、SmartHRではその特色をさらに進めて「専門家のもとで誰でもなんでもできるようになる」ような結構スパルタな感じの開発チームを作っています。例えば、チームのQA専門家のもとでプロダクトエンジニアは全員QAの自動テストにコミットできるようになったり、UXWと呼ばれるプロダクトの文言を万人に使いやすくするためのライティングチームのもとプロダクト内で使う文言に全員で注意を払ったり、プロダクトデザインチームの監修のもと開発時にデザインの草案とアクセシビリティを意識したデザインプロトタイプ駆動の開発全員で行ったり、結構いろんなことをプロダクトエンジニアをはじめとするチームの全員がやっているような感じです。

当然、チームのスプリントを計画するスクラムイベントを中心としてスプリントレビューやリファインメント、プランニングや日々のデイリースクラムまで、ありとあらゆるミーティングで属人化の排除が進むようになっています。これは、特定の誰かがチームから離脱したとしても、それによってチーム全体の活動に悪影響を及ぼさないようにという理由からで、特にスクラムイベントのファシリテーションにおいては全員がすべての役割をこなせるように、トークスクリプトを用意した上でランダムに割り当てられたチームメンバーが行います。

さて、ここで問題になるのが誰がファシリテーターをやるかです。先ほどお話した「チームから離脱」というのは、有給なんかも該当します。たとえば、スクラムイベントでいつもファシリテーションをやってくれる人が、その日に体調悪くなって休んだりしたらじゃあ延期だねとはならないですよね? つまり誰でもファシリテーションができなくてはいけないんです。自分がいるチームでは、ファシリテーターのトークスクリプトと、ランダムにファシリテーターを決めるという運用でこの問題に立ち向かっています。でも、どうやってランダムにファシリテーターを決めるんでしょうか?

答えはガチャです。ガチャ。射幸心を煽る悪い文明のアレです。僕も結構嫌いですよ。でもまあ、リスク(例えば課金とか税金とか)さえなければ、わりとガチャは公平で良い文明です。何の理由もなくサイコロ振ってるのとそう大して変わらないですからね。

単に限定的なメンバーの中で回すガチャは、比較的簡単です。なぜなら、その限定的なメンバー全員をSlackのカスタムレスポンスで登録して、特定のキーワードでランダムに選ぶということが可能だからです。しかし、参加者が不特定なケースでのガチャって、どうすれば良いんでしょうか? 例えば、毎週木曜日に開催されるエンジニア定例だけど、参加自由で誰が来るかわからない、参加の候補者は40人を超えるけど実際に来るのは20人みたいなケースです。事前に登録しておきますか? 無理ですよね。なんならハズレのほうが多いですし。じゃあ当日にzoomのミーティングに参加している人の中からダンダムに選びたいってなったら、どうすれば良いんでしょうか?

zoomとガチャ

これに関しても答えは簡単です。zoomのAPIを使って、今現在ミーティングに参加している人の一覧を取得し、その一覧を何かしらの方法でランダムにシャッフルすれば良いのです。簡単。


大急ぎでRails+Reactのアプリケーションを作るときにやったこと後編

2020-12-23 23:59:41 +0900

ある日突然、大慌てでWebアプリを作らなくてはいけなくなった

このエントリは、第二のドワンゴ Advent Calendar 2020の23日目です。

このエントリは、大急ぎでRails+Reactのアプリケーションを作るときにやったこと前編の続きです

このエントリは、自分は仕事でRails+ReactのAPI+SPAプロジェクトをいくつか経験してきたが、0からその環境を作ったことがないということに気づいてしまった私の記録です。多くの躓きを経て、非常に非常にかんたんな機能しか持たないアプリをつくるのにのべ20時間ほどの時間を要しまし、自分はReact+Railsエンジニアになったつもりでいたという反省文、その話の後編です。これから書くことは、0からRails+React環境を用意したことのない人に向けて書く、まさに書くは一時の恥、書かぬは一生の恥のエントリです。

前回までにやったこと

前編では、サンプルアプリ「ねこねこかわいい」を作るために以下の工程を説明しました。

  • rails new

  • DBの用意

  • Webpackerの設定

  • RailsとReactのインテグレーション

  • UI FrameworkとしてSmartHR UIの導入

後編のこのエントリでは

  • axiosのクライアントを用いてReactからRailsに通信

  • Google OAuthでユーザー登録

  • S3に画像の投稿

  • Herokuへのデプロイ

までを解説します。

axiosクライアントの作成


大急ぎでRails+Reactのアプリケーションを作るときにやったこと前編

2020-12-01 05:04:09 +0900

このエントリは、SmartHR Advent Calender 2020 の1日目です

ある日突然、大慌てでWebアプリを作らなくてはいけなくなった

先日、勤め先のSmartHR社である奇妙な福利厚生制度が爆誕し、盛り上がった。この福利厚生制度に関してはちょっとした理由で詳しく書けないので、ぜひSmartHR社にカジュアル面談という形で話を聞きに来て確かめてほしい。

で、その福利厚生制度は、あるルールで複数の従業員の組み合わせが条件を満たしたときに効力を発するものだった。その組み合わせの条件はそんなに大変ではないが、自分から能動的に制度を利用しようと思う人でなければなかなか面倒というか、とにかく誰もかもが「制度を使うためにマッチングしてくれるアプリほしいな」と思っていた。私もそう思った。だから、普段仕事で使っているRailsとReactでサクーっと一晩で社内マッチングアプリを作り、社内でのスーパーハカーの名声をほしいままにしようとした私は、早速 rails new した。

そして気づいた。確かに自分は仕事でRails+ReactのAPI+SPAプロジェクトをいくつか経験してきたが、0からその環境を作ったことがないということに。薄々気づいていたが、もしかして自分は用意された環境でしか仕事が出来ないのではないか。いやそんなことはない。そういう気持ちを打破するためにも、なかば強迫観念に突き動かされるようにマッチングアプリの作成に取り掛かった。結果として、多くの躓きを経て、非常に非常にかんたんな機能しか持たないアプリは4日後に完成し、なんとのべ20時間ほどの時間を要した。

最終的にアプリは完成したが、この簡単なアプリを作るために20時間を要したという事実は、私の心臓を強く締め付けた。普段社内で「いやー僕RubyとかRailsとかReactとかできまっす」みたいな顔してる自分が急に恥ずかしくなってきた。頬に含羞の色が浮かび、空恥ずかしさに心がざわめき、穴があれば入りたい、生き恥をさらすとはまさにこのことである。しかしだからこそ、これから書くことは同じく0からRails+React環境を用意したことのない人に向けて書く、まさに書くは一時の恥、書かぬは一生の恥のエントリである。

ねこねこかわいい

突然だが、最近猫を飼い始めた。いろいろあって猫を飼うのが夢だったが、それが叶った形だ。猫は可愛い。本当に可愛い。だから、うちの猫を自慢したくなる。ということで今回は、社内の福利厚生マッチングアプリで得た知見をもとにうちの猫を自慢するためのアプリケーションをRails+React構成で作ってみようと思う。なお、最速で完成させつつアプリを大きく成長させるための土台もしっかり作ることを目指すので、まずはSPAとかのしゃらくさい方法はとらず、Webpackerを使いRailsからReactのコンポーネントをレンダリングするし、RailsはAPIモードとかにはしない。しかし、すぐにでもWebpackerを抜け出し、Webpackでフロントを完全に管理し、RailsはAPIとして機能できるようにする準備もやる。だから、きっちりした構成を最短で作るための、自分がやった最速の構成ということになる。そのため、それなりの分量があるので、前編と後編で分けることにした。

このアプリ「ねこねこかわいい」が目指すのは

  • RailsでバックエンドのAPI作成とWebpackerで作成されたアセットの配信

  • React+TypeScriptでフロントの作成

  • axiosを使用してReactからRailsに通信

  • Google OAuthでユーザー認識

  • S3に画像の投稿

  • Herokuへのデプロイ

の5つの項目となる。S3はActiveStorageを使うのでGCSでもいいし、Herokuも大して変わらんのでBeanstalkやAppEnginでもいい。BeanstalkはEC2のことを考えるのがめんどくさく、AppEngineは無料でFlex環境が使えないからHerokuを使うだけだが、とりあえずこの構成で始める。

また、このエントリの流れをコミットしたリポジトリも用意した。

https://github.com/kinoppyd/nekonekokawaii

各見出しの中では、実際に手順をコミットしたパーマネントリンクも提示する。

rails new


APIがカオスってたプロダクトでOpenAPI対応やってみた

2019-12-01 03:10:09 +0900

このエントリは、 SmartHR Advent Calendar 2019 1日目の記事です

こんにちは、SmartHRでエンジニアやっているppydです。いま会社では、SmartHRに蓄積されたデータを可視化して分析する簡易BIツールを開発するチームに居て、フロントエンドとバックエンドとインフラのエンジニアをやっています。それくらい人手が足りてません、みんなSmartHRにきてください。助けて。

カオスったAPI

いまのプロダクトには途中参加なので、先人たちの名誉のために言っておきますが、そもそものAPIの設計がカオスっていたというわけではありません。グラフを描写するフロントライブラリのAPIの都合や、検索フィルタの条件が複雑すぎるために、エンティティの一部がカオスっていたというのが正しい表現です。とはいえ、それのおかげでAPIのレスポンスの全容がつかみにくく、またきちんとした型定義が無かったために、せっかくフロントはTypeScriptを使っているにも関わらず型の恩恵を受けられない箇所があったことは残念でした。他にも、現在のバックエンドはRailsを使っているのですが、ActiveRecordを使った実直な実装が果たしてこの先BIツールの要求に対して耐えられるのであろうかということも検討する段階にあり、もしバックのアーキテクチャを変えたときにフロントと不整合を起こさないためにも、APIの厳密な仕様を確定させることが必要だと感じていました。

そのため、フロント側のAPIクライアントを型付きで自動生成したい、そしてバックエンドの変更でフロントを破壊したくない、という2つのモチベーションで、プロダクトにOpenAPIを入れることにしました。

OpenAPI

すでに有名なので軽く触れるくらいにしておきますが、OpenAPIはRESTのWebAPIにおける仕様の記述方法です。もともとSwaggerという名でしたが、後にOpenAPIという名前に変更になり、現在はバージョン3が公開されています。RESTのAPIのかなり厳密な仕様を、YAMLもしくはJSONで記述します。

RubyとOpenAPI

Ruby製のプロダクトで(別にRubyに限った話ではなく、ほとんどの言語でこうだと思いますが)OpenAPIに対するアプローチは2つの方法があります。

1つは、何かしらの方法でOpenAPIの仕様に則った定義ファイルを書き、その定義をcommitteeなどのGemで常にチェックする方法です。これはOpenAPIの定義そのものに則りAPIサーバーを作成する、いわばTDD的な手法です。この方法の優れた点は、正しいテストがあればOpenAPIの定義を守ることを実装に強制することができることです。もちろん、APIを作成してからOpenAPIの定義を書くことも多々あると思いますし、これからお話する内容もそうなので、完全にTDD的とは言えません。が、方法としてはまず定義があり、実装を合わせていく、ということに変わりはありません。

もう1つは、swagger-grapeなどを使い、実際のAPIの実装仕様そのものからOpenAPIの定義を作り出す方法です。この方法の優れた点は、OpenAPIの定義が絶対にAPIサーバーの実装と乖離しないことです。そのため、APIサーバーから自動で生成されるOpenAPIの定義から、更に自動で生成される各言語用のAPIクライアントは、常に間違いなく最新のAPIサーバーの仕様を満たしていると保証されている点です。

この2つの方法には、それぞれ利点と欠点があり、そしてほぼお互いに真逆の特性を持っていると言えます。前者のメリットは、APIの定義は決してズレないということであり、後者のデメリットはAPIサーバーの実装によって定義はすぐに変わるということです。そして後者のメリットは、極力少ないコードで型情報付きのAPIのクライアントを自動生成できることで、前者のデメリットはAPIの定義の作成や変更に大きなコストがかかることです。


技術書典7で、「ActiveRecord完全に理解した」という本を出します。

2019-09-21 13:10:08 +0900

免責事項

本書のタイトルにある「完全に理解した」とは、ActiveRecordを完全に理解することではなく、あくまで社会通念上相当のActiveRecord「完全に理解した」であり、本書はActiveRecordを完全に理解することを何ら保証するものではありません。

技術書典7

ドワンゴを退職してSmartHRで働き始めそろそろ一ヶ月のkinoppydです。技術書典に出ます。場所は「◎貴サークル「トレイリア学園」は、 か01C に配置されました。」です。ブックマークはここからどうぞ。今回は、ActiveRecordのソースコードリーディングの本を出そうと思います。500円です。前回はメタプログラミングRubyの解説本でしたが、それを書いている過程で「そろそろActiveRecordのソースとか、俺でも読めたりするんじゃないかな……」という気持ちになったので書いてみました。

cover

そんな思いつきから、ひたすらActiveRecordのソースを読んでみた結果を、簡単にまとめて本にしてみました。

内容としては、ActiveRecordで最もよく使われている(であろう)機能のestablish_connection, find, where あたりのメソッドがどうやって動いているのかを、実際にソースコードを追いながら見ていく本です。実は7月の頭あたりからこの本の構想を考え、がんばってActiveRecordのソースコードめっちゃくちゃ読んだんですが、いかんせん相手は巨大すぎて、全てを読むことはできませんでした。そのため、一応自信を持って解説できるであろう範囲に狭めて深堀りしていく内容の本となっています。

そのため、AssociationやMigrationやSTIの内容などは全く出てきません。というより、それらのソースコードをまだ読めていないので、多分次の技術書典では「ActiveRecordなにもわからない」という本を出すと思います。

この本を読むためには

この本を読むためには、メタプログラミングRubyを通して読んだことがある程度の知識が必要である前提になっています。


株式会社ドワンゴを退職します(5年2ヶ月ぶり1回目)

2019-08-30 23:44:49 +0900

2019年8月末で、株式会社ドワンゴを退職します。これは主に社内の友人に向けた文章ですが、一応自己紹介は書いておきます。


技術書典6で、メタプログラミングRuby本を出します

2019-04-12 02:40:21 +0900

技術書典6に参加します

今回も技術書典にサークル参加します。ブースは「か54」です。

今回の本は、メタプログラミングRuby第2版の内容を追いかけつつ、現実のプログラミングという世界ではどのようにメタプログラミングが利用されているのかを解説する本です。具体的には、Sinatraのコードのなかからメタプログラミングが用いられている箇所をピックアップして、それを教本に従って解説します。

メタプログラミングRuby第2版は、本の中でいくつか現実のコードを出して解説をしている箇所がありますが、いずれも断片的で複数の巨大なコードベースにまたがったものなので、追跡が難しいです。そこで、Sinatraというミニマルなコードベースの中から、強力なメタプログラミングを使っている箇所を取り出し、それがプロダクトに対してどのような意味を持っているのかを考えていきます。

本を書いた環境

こっちが本題です。

前回の技術書典5では、StackEdit+GitBookという環境で執筆を行いました。これはいくつかの要件があったけれど、最終的になんかいろいろうまく行かなくてこうなってしまった、という環境の成れの果てです。詳細は前回のブログを見てください。

今回の環境

いくつかの選択肢がありましたが、今回は最初からRe:VIEWを使って本を書くことに決めました。理由としては、次にあげるいくつかの前回の反省があります。

  • GitBookの成果物は、印刷するのにやや難がある

  • Markdownから望むRe:VIEWの形式に変換するのには、現実的に無理がある

  • というよりも、そもそも文章フォーマットの相互変換に無理がある

Markdownで執筆したものを、望むような形で印刷可能なPDFに変換することは、もはや無理だと悟ったというのが最も大きな理由です。PandocやSphinxも、変換は行ってくれますが結局の所は出力の形式が望んだものになるかどうかは確かではありません。そうなった場合、PandocやSphinxの気持ちを感じながらMarkdownを修正していくということはもはや不可能です。ならば最初から余計な相互変換を持たないRe:VIEWを使うべきだという結論になりました。複数の入力を受けつけ、複数の出力をしてくれるソフトは確かに便利ですが、アンコントローラブルになる箇所が多く、執筆時間が限られているときには選択が難しかったのです。

幸い、Re:VIEWのフォーマットは比較的わかりやすく、リストなどにやや不満はありつつも十分に1日で書けるようになるものでした。そのため、今回は最初からRe:VIEW形式で執筆を行おうと考えました。しかしその一方で、いくつか諦める必要のあるものもありました。

  • ライブプレビュー

  • クラウドエディタ

この二点です。

ライブプレビューに関しては、まあそれはそうという感じしか無く、都度ビルドして確認することしかできません。

クラウドエディタに関しては、まあクラウドエディタでRe:VIEWファイルを書けば良いので特に諦める必要はなかったのですが、EditStackに不満を持っていた私はあれからもっと良いクラウドエディタに出会っていませんでした。良いエディタという意味で言えば、esa.ioはかなり気に入っています。しかし、これはMarkdownに特化しているため、使えませんでした。

しかし、原稿をクラウドエディタで書くことを諦められなかった私は、考えました。結果、Re:VEIWフォーマットとMarkdownはなんとなく似てないこともなかったので、今回はまず概要と草稿をesa.io上で執筆し、そのMarkdownデータを手でRe:VEIWに変換した上で、本を作るための細かな命令などを手元のエディタで行いました。おそらく、技術書を書く上で一番つらいのは、最初の草稿をあげるまでで、そこから先は多少の原稿の修正と、印刷用のマークアップ作業です。なので、その辛い箇所をクラウドエディタでなんとかして、機械的にちかい作業はローカルのエディタで行うように分担したのです。

最終的に、Re:VIEWのファイルはGitで管理してGitHubにプッシュしていたので、GitHub上からクラウドエディタのようなこともできなくはなかったですが、それはやらなかったです。

用意した環境


Mobb 0.5 and Repp 0.4 out now

2018-12-26 00:01:12 +0900

このエントリは Mobb/Repp Advent Calendar の二十五日目です


Mobb/Repp Advent Calendar のネタが尽きたので、開発してて面倒な話をします

2018-12-24 23:53:57 +0900

このエントリは、 Mobb/Repp Advent Calendar の二十四日目です