こんな感じで AOP で処理してDataFetcherExceptionHandlerで良しなに処理してる。
package org.yoshiori.datafetchers.aop; import org.aspectj.lang.JoinPoint; import org.aspectj.lang.annotation.Aspect; import org.aspectj.lang.annotation.Before; import org.aspectj.lang.reflect.MethodSignature; import org.springframework.core.MethodParameter; import org.springframework.stereotype.Component; import org.springframework.validation.DataBinder; import org.springframework.validation.beanvalidation.SpringValidatorAdapter; import org.springframework.web.bind.MethodArgumentNotValidException; import javax.validation.Validator; @Aspect @Component public class GraphQLValidator { final Validator validator; public GraphQLValidator(Validator validator) { this.validator = validator; } /** * Validation like the Spring controller. * * @param jp */ @Before("execution(* org.yoshiori.datafetchers..*(..)) && @within(com.netflix.graphql.dgs.DgsComponent)") public void validateParameters(JoinPoint jp) { var signature = jp.getSignature(); if (!(signature instanceof MethodSignature)) { return; } var methodSignature = (MethodSignature) signature; var parameters = jp.getArgs(); var annotations = methodSignature.getMethod().getParameterAnnotations(); SpringValidatorAdapter adapter = new SpringValidatorAdapter(this.validator); for (var i = 0; i < annotations.length; i++) { for (var annotation : annotations[i]) { if (annotation.annotationType().equals(javax.validation.Valid.class)) { var bindingResult = new DataBinder(parameters[i]).getBindingResult(); adapter.validate(parameters[i], bindingResult); if (bindingResult.hasErrors()) { var m = MethodParameter.forParameter(methodSignature.getMethod().getParameters()[i]); throw new RuntimeException(new MethodArgumentNotValidException(m, bindingResult)); } } } } } }
使い方
@DgsData(parentType = "Query", field = "shows") public List<Show> shows(@InputArgument @Valid Hoge hoe){ ... }
なんかもっと良い方法あったら教えて欲しい。
The Launchable team is excited to announce that we have secured $9.5mil in series A investment! This will serve as the “launch” point for us to deliver on our vision of Continuous Quality for developers that will drive faster software releases.https://t.co/D8rNzB9E4C pic.twitter.com/jMaP5qb3BX
— Launchable Inc (@LaunchableInc) 2021年7月27日
シリーズAの資金調達をしました。USのスタートアップでシードラウンドから経験するのって結構貴重な経験かなって思ったので資金調達までどんな感じだったのか描いてみようと思います。
ググってもらった方が正確な情報が出てくると思うので詳しく知りたい人はググってください。 すっごい雑に言うとこんな感じです。
で、シードラウンドの途中で僕は入社しました。1年3ヶ月くらい前。
その時のプロダクトがどんな状況だったのかを説明すると、まだコアロジックのプロトタイプが出来ていたくらい。
ソースコードとかコミットログとか過去のテスト結果とか全部手元に有れば性能の出るモデルが作れることはわかったくらい。
そこからどうやってデータを集めるのか、そのモデルをどうやって実行してもらってどうやって結果を動かしてもらうのかとかから考え始めました。
簡単に言えばデータあれば性能出ることはわかったけどじゃぁそのデータってどうやって集めるの？と。
APIサーバ作ったり仕様考えたりもそうだし、データをどうやって持つのとか貯めるにしてもSaaSになるはずなのでデータ間のセキュリティも担保しなきゃいけないしとか、認証どうするとかそもそもインクリメントにデータ貯めて学習どうするんだとか
そこまで出来てWebinarとかやって「興味ある人はメールしてね」みたいな感じで募集をかけてそっからPMがSQL叩いてAPIトークン発行してメールで送るとか
それをカスタマーが自分でサインアップして自分でトークン発行したり出来るようにしたり、サイトから付加情報見れるようにしたり
正解は誰も知らないので何に注力するのか決めながら進んでいく感じでした。例えばDBは最後の砦だか最初から堅牢にセキュアになるように設計したり、逆にAPIサーバはデプロイ前のチェックを重厚にするよりエラー早期発見出来るようにしてすぐロールバック出来るようにしたり色々考えながら作って、作って運用して考えて変更してという感じで進んでました。っていうか今もそんな感じで進んでいます。
とりあえず楽しい。やらなきゃいけない事はいくらでもあるのでその中から自分で取捨選択して方針決めていくのはやっぱり楽しい。何やっても基本的に0 -> 1になるので何かするたびに出来ることが増えるのは純粋にやっぱり面白い。今はやっと最低限の道具は揃った感じにはなった。でも勿論全部完璧なわけなくてガムテープでとりあえず補修してる的な部分もある。なので新しいカスタマーがデータを送ってきてくれるようになると想定してなかった事とか起きて水道管ゲームのあっちの水漏れ直したらこっちで水漏れしてみたいな感じで日々色々な問題に対応したりしている。
焦燥感は結構あった。シードラウンドは本当に調達した資金を食い潰しながら走っている状況でこれを経験するのは本当に初めてなので焦燥感は結構あった。昔所属してた会社で月数億単位で赤字とかは経験したことあるけど赤字でも売り上げがあるのとは全然違う感覚だった。赤字でも100円でも売り上げがあればあとはそれを拡大していけばどんどん収入増えるだろうけど、そもそも売り上げが何もないのでゼロをいくら掛けてもゼロにしかならない状態、なので早く売り上げを作れる状況まで持っていかなきゃいけないっていう焦りはずっとあった。まぁ、資金食い潰してるとか偉そうに言ってるけど別にどのくらい残ってるのかとか見てたわけではないので本当に個人的に感じてただけなんだけど。
あとは前にも描いたけど、英語はやっぱり苦労しているとか、同僚がみんな優秀で楽しいとかもあります。
そんな感じでシリーズAの資金調達をしたんだけどむしろここからが本当の勝負どころ！！！
で大変だけど楽しいこともいっぱいあると思ってます。そして人手も全然足りていない！！！
特に今はData Scientistが欲しいです！僕らのサービスのコアである機械学習部分の改善をしていける人を探しています！一緒に小さいベンチャーから世界にインパクトを与える仕事しませんか？楽しいのは保証します！！！
最初に、メインのお知らせから Launchableでは新たに仲間を若干名募集しています！
https://www.launchableinc.com/careers
の三つです。 Software Engineer については同僚の書いたのを読んでもらうのがわかりやすいと思うので、それ以外について説明します。
Data Engineer はぶっちゃけ Software Engineer と募集要項に書いてあることはそんなに違いはありません。でもその違いの部分がすごく重要です。
それが「データ処理プラットフォームの構築運用経験」と「SparkおよびJavaの使用経験」です。僕たちはそこの経験が豊富ではないので、とりあえず今できる形でやっている部分が多いです。なのでそこをどんどん改善していける人を募集しています。
Data Scientist はわかりやすいですね。その名の通りです。僕らの使っているモデルの更なる改善と拡張が主な責務です。
と言うことで積極採用中ですので是非ご応募ください！！
気がついたら1年と1ヶ月くらい経ってたので軽く英語以外について書いてみる。英語については前にまとめたので yoshiori.hatenablog.com
良いところは自分たちが作っているものが良いものだと感じれることと同僚が優秀なところに尽きると思います。
テストの時間を短くして開発者の生産性をアップすると言うのはとても良い事だと素直に言えるし、そのための仕事をしていることは誇りに思える。一年前にはなかった色々なものが形になり動き始めていると言う状況に携わっているのは単純に楽しい。
同僚も川口さん始め優秀な人ばかりなので毎日勉強になりつつとても楽しい。これはエンジニアだけに限らずPMもメチャクチャ優秀な人なので本当にストレスなく働ける。
まぁ、ほんと10人前後の会社なのでなんでも自分たちでやらなきゃ行けないので xxxのリサーチとxxxのコーディングと採用サイトのアップデートみたいな軸が違うから優先順位つけるのが難しいタスクを同時にこなしたり大変な部分はあるけれどもやっぱり楽しいです。
まだまだプロダクト自体も未完成だし色々なことに積極的にチャレンジできるのでその辺が楽しめる人には本当におすすめの会社だと思うので是非気軽に応募してね！！！（1回目の面接は僕と 
id:ninjinkun になります）
前提条件書いておくと義務教育の英語レベルも無い人間の話です。三単現って言われて「麻雀の役？」とか思っちゃうレベル。
だいたい毎日1時間くらい使ってる感じ。
これがホント後の話にも続くんだけど当初の予定より全然成長していない。英語のミーティングや1on1にビビらなくなったって言うだけ。これは言葉通りでビビらなくなっただけで半分以下しか理解出来てないし言いたい事全然伝えられない。
まあ、そんななのでもちろん凹む。メッチャ凹む。でもなんというかそれの理由が分かったのでそれを今日は書きたかった。
多分英語学習が進まなかったり途中で挫折しちゃうのは目標が高すぎるからだという事に気がついた。
どういうことかと言うと英語勉強するときの雑な目標って「ネイティブの人と普通にコミュニケーション取れるくらいになりたいな」だと思うんだけど、実はそのゴールはメチャクチャ遠い。むしろ最終ゴールがそれなんだよね。
いきなりそこをゴールにしちゃうと本当に日々の成長を何も感じられずに泣きそうになってやめちゃうんだと思う。
とは言え適切なゴールが何なのかは俺も分かってない。分かってるのは「そのゴールは遠いやつだからそれに絶望して歩みを止めてはダメ」と言うことだけ。
まぁ、なので凹みはします。はい。
DMM 英会話は終わった瞬間に次の予定を入れてしまいます。途切れたらなかなか登録しにくくなるので。だいたい講師の人も2日先くらいのスケジュールしか登録してないので金曜のレッスン終わった後月曜日の予約を入れるのが結構大変だった。最近は必ず金曜日には月曜日のスケジュールを登録してくれてる良い先生を見つけたのでその人を予約してる。
Duolingo は毎日お風呂でやってる。もともとお風呂大好きでお風呂で本読んでたりしたんだけどその時間を英語勉強にしてる。お風呂入ったらまずはDuolingo起動すると言うのが習慣化というかパブロフの犬化されてて続いてる。
後、なんかスッゲー続けてる感出してるけど普通に風邪引いたりすると途切れちゃうし年末年始とかGWとかも途切れがち。
仕事に支障はある。それはちゃんと認めないといけない気がしてる。使ってるツールは主にDeepLとgrammarlyで両方とも課金してる。
ついつい意識高くなって「自分で英語読まなきゃダメだ」とか「英語で考えなきゃダメだ」とか思ってしまうんだけど普通に仕事としても遅くなっちゃうので逆にちゃんとツールに 頼らないといけないと思ってる。コレは意外な感覚だった。 英語で全部やろうとしてなんて言うか糞詰まりみたいに思考が止まる様になってしまう事がよくある。
なので最近はまず日本語で考えてラフな箇条書きにしてから英語にするようになった。
よく言われている勉強法ではダメだって言われてるやつ。 「英語で考えて英語で話せないとダメ」って言うのをよく見るんだけど、俺の場合はそれに拘ってしまうと考えている事が凄くゆっくりしか出てこなくなってメッチャ狭い穴から搾り出してる様な感覚になり辛かった。
プログリットみたいなやつで短期集中である程度地力を付けてから今の勉強法にした方が早いような気はしてるんだけど毎日最低３時間は確保しないといけないのは子育てと並行はなかなかに決断しにくい。3ヶ月それを続ける覚悟が出来たらやってみたいけどなかなかね。
大事なこと書き忘れてた！「もっと良い学習方法あるかも？」とか考えて学ぶのを止めちゃうくらいなら１つでも単語覚えたほうが良い。マジで。これ結構陥りやすい罠。
すっごくたまに「何か読んでおいた方が良い本とかありますか？」みたいな質問されることがあったんだけどこれに答えるのすごく難しいなぁと思ってる。
なんていうか本ってその人が必要な時に読まないと全く役に立たないし面白くもないと個人的には感じているからなんだけどね。
「xxxxに最近悩んでるんですけど何かお勧めの本とかありますか？」って聞かれて答えるのは逆に悪くない。なんというか目的があってそのために何か必要だっていう人に僕が読んだ中ではこれが良かったよって薦めるのはやりやすいし、僕も実際そうやって教えてもらって役に立った本はいっぱいある。
でも、すごく抽象的に「なんか読んでおいた方が良い本ありますか？」とか聞かれると困る。かといってそのまま素直に「本って必要じゃない時に読んでも退屈なだけだから自分が今読みたいと思う本を読んでおけば良いよ」って答えるのもなんか違う気がしてるんだよね。その質問してる人が望んでる答えじゃないよなぁとか。
なんでこんな事を書いてるかっていうとちょっとデザインパターンについて考えてたから。デザインパターンもなんとなく感覚が似てて必要な時にそのパターン読まないとあんまり面白くないというか身につかない気がしてるんだよね。それこそGoFとかを一から順に全部読んでも（もう設計とかが大好きになってる変人以外）楽しめないと思うんだよね〜。
で、そんな僕の今お勧めの本はこれです。
Launchable を導入する手順をデモを交えて紹介するウェビナーやります！
今回は僕がやるのですが、どちらかというと概念の話より、実際のコマンドや導入の手順などを重点的に説明しようと思っています。（まだ資料作り中なので）
RailsとRSpecを利用して説明しますが、コマンドの使い方などは他のテスティングフレームワークやビルドツールでも同じように使用できるのでRailsやRSpecを使っていなくても参考になると思います！
もちろん新しく追加された機能の紹介などもしますので、過去のウェビナーに参加していただいている方にも新しい発見を提供できるのではないかなと思っています。
ということでぜひ見に来てください！！！！
