qsona

Software Engineer

qsona

Software Engineer

  • 新説: 最後の審判 (将棋)

    縫田光司氏による詰将棋の傑作「最後の審判」(1997)。将棋のルールの矛盾を突いた問題作です。現在までの議論では、成立するかルール上不定とされています。果たしてそうなのでしょうか。日本将棋連盟公式による「将棋ガイドブック」(2003)を読みほどき、その真相に迫ります。

  • 固定された記事

マインドの低い焼物売り

栃木県に益子町という焼物の産地がある。毎年5月と11月に陶器市があって、いろんな作家が作品を出していてとにかく様々な陶器がずらーーーっと並んでいる。 僕はこれがすごく好きで、家族や友人と何度も行っている。益子焼というのは歴史がわりと浅く(150年くらい)、その分なのか、かなり自由な風土のようで、釉薬の色など基本の型はあるものの、それに則らなくても良いとされている。実際に個性豊かな作品が多くて、見ていて全く飽きがこない。なんなら益子の土を使わなくても良いとか。都心からも比較的

qsona

    • 目黒区長選挙2024の候補者所感

      自分にとっては最も他人事ではない選挙が明日あります。まだ誰に投票するか決めていないので、考えつつ所感を書いてみます。 はじめにかいでん議員の記事を読むべし。 区長に何を求めるのか?個人的に思うのは、行政のリーダーとして、目黒区における現実の問題を直視し、一つ一つ地道に解決していく組織をリードしてほしい。 逆に言うと、目新しさとか、強力なトップダウンでの問題解決は、あったほうがいいが二の次だと思っている。それよりも、地道な合意形成や、行政組織のメンバーにとって信頼できる振

      qsona

      • Engineering Manager の自己効力感下がりがち問題

        Engineering Manager という仕事をしていると、自己効力感が低下する瞬間がけっこうあると感じる。(多分 Engineering に限らない Manager 一般の話も多いと思うけど、ここではその考察はしない) 仕事において自己効力感が高まる状態というのは、たいてい、自分が何か努力して、それによって目に見える成果が出ているときに生まれるのではないかと思う。ところが、Engineering Manager の仕事というのは基本的に、自分以外のみんなが成果を出せて

        qsona

        • スタディサプリの開発チームを離れました (リクルートを退職しました)

          いわゆる退職エントリです。2019年10月から3年9ヶ月在籍したスタディサプリの開発チームを離れることになりました。 自分は Quipper Limited 時代に入社し、途中でリクルートへと会社統合された後もずっとスタディサプリの開発にずっと関わっていました。そんなわけで「株式会社リクルートを退職しました」というタイトルがいまいちしっくりこなくて、中途半端なタイトルになりました。 次は決まっていて、また別の記事でお知らせします。(・・・って前回の退職記事のときも同じこと

          qsona
        • 固定された記事

        マインドの低い焼物売り

        qsona

        • 目黒区長選挙2024の候補者所感

          qsona

        • Engineering Manager の自己効力感下がりがち問題

          qsona

        • スタディサプリの開発チームを離れました (リクルートを退職しました)

          qsona

        マガジン

        • 新説: 最後の審判 (将棋)
          3本

        記事

          Re: GraphQL Error、下から見るか？横から見るか？

          上記のトピックについてもう少し突っ込んだ議論をしたい。 背景: GraphQL におけるエラーの表現の手法Web API において、正常系以外の、例外(エラー)的な状況をレスポンスの情報に埋め込みたい場合、REST API では HTTP ステータスコードがよく用いられる。 一方、GraphQL API では、複数のリソースを同時に取得することが前提にあるので、「リソースXはエラーであるがリソースYは正常である」のように Partial Error の状況を表現したいことが

          qsona

          Re: GraphQL Error、下から見るか？横から見るか？

          qsona

          Engineering Manager はじめました

          "プログラマー定年" 35歳を目前にして Engineering Manager (以下EM) の職を拝命しました。 直接のきっかけは、数ヶ月前にチームの EM から来期 EM やってもらえないかと言われたことで、少し考えたり相談したりしたが、そこまで迷いなく引き受けた。一番のネックは「俺が他の人と1on1等を出来るほど信頼に足る人間なのか?」というところで、正直今でも疑問で不安だが、多分他の人たちも始めは多かれ少なかれ同じようなことを感じながらだったのではないか。 さて

          qsona

          Engineering Manager はじめました

          qsona

          RESTful API との比較で GraphQL API を作ることの難しさ

          そんなものはない、と思っていた時期が私にもありました。 上の資料でも書いてるんですが、要点を言うと以下のようなことを主張している。 API の設計手法として、以下の2つのパターンが考えられる ・Resource-based API ・Usecase-based API Usecase-based というのは要はクライアントの要求にそのまま沿った形で API を作るということだ。しかし、UI やその他クライアントの要求というのは変わりやすいものなので、そのたびにいちいち

          qsona

          RESTful API との比較で GraphQL API を作ることの難しさ

          qsona

          コロナワクチン接種記1

          7月くらいに来るはずだった職域接種が2回流れ。そうこうしてるうちに目黒区で打てる案内が来た。 予約解禁当日0時から予約を試みる。LINEのチャットボットで予約を取る直前まではなんとか進めるが、最後の予約のところで数十分待たされて「枠がなくなりました」というのが2回くらい続いて、取れないまま寝落ち。 ワクチン予約という対象ドメインの性質上、枠以上の予約を受付することは許されないので、きちんとロックをとって1つずつ進める必要があるのはわかる。しかし、会場ごと・かつ10分ごとく

          qsona

          コロナワクチン接種記1

          qsona

          マクドナルド理論の逆

          最近しくじった話。 とあるテーマについて議論するミーティングに呼ばれた。アジェンダが丁寧に提示されていて時間もあったのと、自分にとって結構経験があるテーマだったので、事前に考えて一つの筋の通った意見を持っていた。 当日、参加者から意見を言うタイミングで、とりあえず積極的に発言する人がいなかったので、「手法Aが良いと思います。理由はこうです(浅い説明)」と発言した。 悪いことに、そこからとにかく議論が紛糾してしまった。手法Aは限定的な状況に使える手法で、安易に使ってしまう

          qsona

          マクドナルド理論の逆

          qsona

          優先度の誤謬

          僕は夜シャワーを浴びずに朝シャワーを浴びることが多い。 その理由はこうだ。まず、なんらかの理由で夜シャワーを浴びずに寝てしまったとする。そうすると朝は体が気持ち悪いので、シャワーを浴びる。夜になると、「今日は朝シャワーを浴びたし、まあいいか」と思って、シャワーを浴びずに寝る。しばらくそのループが続く。 しかし、本当は夜シャワーを浴びてから寝る生活スタイルのほうが、自分の幸福度は高いのである。しかも、朝浴びても夜浴びても頻度は1日1回、労力は変わらない。 だったらなぜ夜シ

          qsona

          優先度の誤謬

          qsona

          最小限の Pull Request Template を考える

          コンテキスト: GitHub などを利用したチーム開発を想定する。OSS開発に対するコントリビューションの話ではない。 よくあるパターンとして、Pull Request を読んでも変更の背景などがよくわからない、ということが多くなってきて、それの対処として Pull Request の説明を書きましょう、となり、それをある程度強制させるためのテンプレートが欲しくなる。 が、世の中のテンプレート例などを見ると、重厚すぎると感じることが多い。必要よりも多すぎると、書くのが大変

          qsona

          最小限の Pull Request Template を考える

          qsona

          qsona へのお仕事の依頼について

          (更新日: 2024-01-02) 副業として、技術支援業をはじめます/やっています。具体的には、週1回・1時間程度のミーティング + チャットなどで、非同期的に相談・壁打ちなどをお受けする形を考えています。必要に応じてコードも書きます。 技術的には、Backend全般, Microservices, GraphQL, Ruby on Rails, Node.js などが主に仕事で利用している領域です。また、Engineering Manager や、開発組織全体のリード

          qsona

          qsona へのお仕事の依頼について

          qsona

          BackendチームとFrontendチームとアジャイル

          話があんまりまとまってないけどとりあえず出す。 職能型組織とその弊害ある程度大きい Web プロダクト開発の現場 (例: エンジニアが全部で20人) において、その内部が Backend チーム / Web Frontend チーム / iOS チーム / Android チームみたいにサブチームとして分かれていることは実際よくあることだと思う。 アジャイル開発の文脈だと、基本的にこういう分け方はあまりよろしくないとされる。この分け方だと、それぞれのチームに閉じてユーザー

          qsona

          BackendチームとFrontendチームとアジャイル

          qsona

          (雑思考メモ) Consumer-driven Contract testing を普通のプロセス内のテストに使えるか

          class A => class B => (DB呼び出し) みたいな感じになってる時に、Aをテストしたい時にBをstub/mock したいんだけど、そのstubが正しいことって (特にRubyだと) 往々にして信頼できなくなってしまう。 信頼度を上げるために、この stub/mock を B側のテストと連動させられないか? ということを考えた。 例えば B のテストに、「状態 X において、引数 Y で呼び出すと、戻り値 Z を返す」みたいなテストがあるとする。この時、

          qsona

          (雑思考メモ) Consumer-driven Contract testing を普通のプロセス内のテストに使えるか

          qsona

          Schema-Driven Development とアジャイルなチーム

          最近は新規サービス開発で GraphQL を使っている。同じチームでAndroidエンジニアの geckour 氏が記事を書いてくれていたので、触発されてちょっと書く。 上の記事の中で、この新規開発以前にあったAPI開発の問題点となぜSchema-drivenな開発にしたいのかについて触れられているので、ぜひそちらを見ていただきたいとして、僕が感じたschema-driven developmentの意外?な副次的効果について書いてみたい。簡単に書くと、各開発者が職能を超え

          qsona

          Schema-Driven Development とアジャイルなチーム

          qsona

          マイクロサービスを (Ruby on Rails 以外の任意の言語) で書くことについての意見

          この文書は、ある組織において、ある一つの Ruby on Rails で書かれたサービスの全部または一部を、(言語A) で書き直したい、という proposal に対して qsona が表明した意見の文を、一部手直ししたものです。このサービスは、現在担当しているチームとは別の人が初期実装をしたものであり、現在はまだ小規模ですが、今後新しいチームの手により発展していくもので、現在の規模のうちに要件や新しいチームメンバーに最適な言語で書き直すという選択は十分合理的です。また、この

          qsona

          マイクロサービスを (Ruby on Rails 以外の任意の言語) で書くことについての意見

          qsona