LayerX 採用情報/[2023ver]LayerX一部メンバー紹介/中川 佳希 / Yoshiki Nakagawa
採用中ポジション一覧カジュアル面談
採用中ポジション一覧カジュアル面談
LayerX 採用情報/[2023ver]LayerX一部メンバー紹介/中川 佳希 / Yoshiki Nakagawa

中川 佳希 / Yoshiki Nakagawa

自己紹介

大学時代からリクルート、フリークアウト等でインターンを経験後、株式会社エウレカに入社。 インフラエンジニアとしてPairsや新規サービス開発に従事。 その後フリーランスとして、機械学習分野での産学連携プロジェクトへの参加や決済サービス、動画配信アプリをフロントエンドからインフラまで担当。

コンテンツ

LayerX インボイスの技術スタック〜分野横断で開発するためのSchema Driven Development〜 - LayerX エンジニアブログ
DX事業部の @yyoshiki41 です。 今回は、 今年1月にリリースしたLayerX インボイス のアプリケーション開発についてです。 インフラ構成については、昨日の LayerX インボイスのインフラアーキテクチャ で紹介されています。 LayerX インボイス は、主に経理業務を行う方を対象ユーザーにした SaaS プロダクトです。 サービス内で以下の業務を行うことがメインになっています。 請求書の受領 請求書から仕訳を行う オンラインバンキングに取り込むためのデータを出力する 会計ソフトに仕訳データを連携する また上記の他にも マスタデータ（例えば、仕訳データの入力に使う取引先や部門、税区分など）の管理や会計ソフトへの連携 源泉税の支払管理 請求書の社内での確認 などを行う機能が実装されています。 エンジニアの普段の業務としては、馴染みのないものがほとんどですね、、 前置きが長くなりましたが、経理業務や会計からは少し離れ、本題のアプリケーション開発の話に移っていきます。 チームの特徴としてはフロントエンド開発だけを行うメンバーはおらず、 バックエンドエンジニアがフロントエンド開発を行う UIデザイナーもフロントエンド開発を行う という体制で開発をしています。 担当の領域を明確化するのではなく、機能単位で実装者をアサインして進めており、 プロダクトが立ち上げ期においては（必要な機能数が多いこともあり）非常にワークしていると思います。 プロジェクト初期に、サービス立ち上げを行った経験値を持つエンジニアが揃っていたこともうまくハマった点でもあります。 Frontend Backend に限らず、Backend Ops などをきれいに線引くことは難しく、 両者を行き来できるとコミュニケーションコストや機能提供スピードの面でもメリットを享受出来ると考えています。 現在は、PCブラウザでのみサービス提供をしており、 Nuxt + TypeScript で、SPA という見慣れた構成かと思います。 Cloudfront + S3 での静的配信を行う形を取っています。 バックエンドは、Go がメインで使われています。 使っているライブラリなどは下記です。 選択の理由としては、以下のような理由が挙げられます。 まず薄く入れれるもの PR / Fork してメンテして運用出来るもの 静的型付けでコーディング出来るもの Goプログラムと外部とのデータ I/O の変換（marshalling/unmarshalling）部分を自動化出来る（e.g.
https://tech.layerx.co.jp/entry/2021/04/06/090000
MySQL Generated Columns を活用したユニークキー制約 - LayerX エンジニアブログ
DX事業部の @yyoshiki41（中川佳希）です。 現在は、 LayerX インボイス という経理業務を行う方を対象ユーザーにした SaaS をメインで開発しています。 今回は、MySQL での Generated Column の活用についての紹介です。 カラム定義時にロジックを組んでおくことで、演算や条件分岐ロジックの結果を値として、仮想的に参照可能にするもしくは記憶領域に格納することが出来る機能です。 ドキュメントには以下のような直角三角形の斜辺 sidec を格納するスキーマの例が紹介されています。 AS 以降にカラムの値計算を行う式が定義されています。 よく紹介されている例としては、以下のようなものがあります。 複雑な条件結果を先にカラムに定義しておき、クエリ条件を簡略化させる STORED を指定して記憶領域に書き込みを行っておき、クエリ参照時には計算コストをかけない JSON 型のようなインデックスキーをつけれないカラムに対して、インデックスキー用のカラムを生成する JSON との組み合わせの例としては、以下のようなものです。 json のキーとして version を持つデータに対して、インデックスキーカラムを設定できました。 アプリケーションが読み書きするデータの整合性は、DB側でも外部キー、ユニークキーやCHECK制約などを用いて担保したいものです。 今回紹介したいのは、ユニークキーとして Generated Columns を活用する例です。 レコードの物理削除を行いたくない場合に、 deleted_at カラムを用いることがあるかと思います。 名称 name カラムに対してユニークキーを設定したいとします。 まずは、 nameと deleted_at （nullableなカラム）の複合ユニークキーを設定した良くない例は下記です。 CREATE TABLE `bad_examples` (
https://tech.layerx.co.jp/entry/2021/06/22/090000
MySQL 外部キー制約とインデックスに必要な知識 - LayerX エンジニアブログ
バクラク請求書 でリードエンジニアをしているSaaS事業部の @yyoshiki41（中川佳希）です！ バクラクシリーズでは、経理向けSaaSに始まりコーポレートDXをサポートする複数プロダクトを提供しています。 サービスローンチから1年経過したこともあり、2021年12月から2022年1月は短い間に事業部として怒涛のリリースの日々でした。 サービス全体で変化はありましたが今後も変わらずプロダクト開発を通して、経理・コーポレートチームの仕事がバクラクになるようサポートしていきます！ 今回の記事は、MySQL の外部キー制約とインデックスについてです。 多くの人が馴染みあると思いますが改めて整理すると、2つの役割を担っていると言えます。 複数のテーブル間でインデックスとしてデータの参照を効率的に行う（外部キー） 複数のテーブル間でデータの一貫性を保つ（外部キー制約） 上記をサンプルのテーブルを使って具体的にみていきます。 親テーブルとその外部キーをもつ子テーブルを以下のSQLで作成してみます。 作成されたテーブル定義の結果は以下です。 比較してみると上の children テーブルのCREATE文は簡略化して書いたもので、MySQLが自動でインデックスキー（ KEY parent_id ）を作成してくれている事がわかります。 上では簡略化した書き方をしましたが、外部キー作成の構文は以下で表現されます。 [CONSTRAINT [symbol]] FOREIGN KEY [index_name] (index_col_name, ...) REFERENCES tbl_name (index_col_name,...)
https://tech.layerx.co.jp/entry/2022/01/31/093141

Podcastを聴いてみる🎧

 
Post on X
LayerX 採用情報/[2023ver]LayerX一部メンバー紹介/中川 佳希 / Yoshiki Nakagawa