qsona

Software Engineer

qsona

Software Engineer

    マガジン

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

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

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

    最近の記事

    • 固定された記事

    マインドの低い焼物売り

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

    スキ
    22
      • Engineering Manager はじめました

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

        スキ
        20
        • RESTful API との比較で GraphQL API を作ることの難しさ

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

          スキ
          48
          • コロナワクチン接種記1

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

            スキ
            5

          マガジン

          マガジンをすべて見る すべて見る
          • 新説: 最後の審判 (将棋)
            qsona

          記事

          記事をすべて見る すべて見る

            マクドナルド理論の逆

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

            スキ
            8

            優先度の誤謬

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

            スキ
            2

            最小限の Pull Request Template を考える

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

            スキ
            6

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

            副業として、技術支援業をはじめます/やっています。具体的には、週1回・1時間程度のミーティング + チャットなどで、非同期的に相談・壁打ちなどをお受けする形を考えています。必要に応じてコードも書きます。 Backend全般, Microservices, GraphQL, Ruby on Rails, Node.js などが主に仕事で利用している領域です。 ご相談は Twitter (@qsona) の DM, または mori.jmk@gmail.com までご連絡くだ

            スキ
            8

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

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

            スキ
            22

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

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

            スキ
            2

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

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

            スキ
            28

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

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

            スキ
            32

            管理画面としてのJenkins

            Web系開発のコンテキストにおける話です。 Jenkins を運用しているとよくあるパターンとして、最初はエンジニアが実行する単発のバッチ処理や、システム的に重要な定期バッチ処理のために使われているのだが、そのうち、CSやマーケティングなど、エンジニア以外の様々な業務を受け持つ人によって実行されるようになる。 それでそのうち、たとえば権限管理の問題とかが出てきて、「そもそもJenkinsはシステム管理者が使うものであって、それ以外の人が使うものは管理画面を用意すべきなので

            スキ
            8

            Pull Request レビューの限界

            いくつか念頭にある過去の他の方の記事や発言があるのだが、パッと見つけられないのでゼロベースで書く。 Pull Request のレビューという文化がほぼ完全に定着してからかなり経った。5年前くらいはまだ「Pull Request のレビューを開発フローに入れています」みたいなことを採用ページの文言に入れている会社が結構あったが、今時もはや当たり前になりすぎて誰も言わなくなった。 それくらい Pull Request を出してそれをチームの人がレビューするというフローは当た

            スキ
            47

            幼児と自転車で出かける時に気をつけていること

            東京の都市部に住んでいると (僕は目黒区) 自動車を持つのが難しく、自転車はかなりの重要な移動手段である。なので、子供も早いうちから自転車乗れるようにしておくと色々楽。とはいえ、目黒区は日本で一番道が狭いらしく、大通りのようにビュンビュン車が通るわけではないが、細い道にもかなり車が通るし歩行者も多いので、幼児に走らせるのは簡単ではない。 実際に自転車で外に出かけられるようになるためには、 ・自転車の運転技術 ・交通ルールを守ったり、動き方を判断する技術 の両方が必要である。

            スキ
            8

            note.com移行記念カキコ

            本当に偉業。お疲れ様でした。 これが意味するところもその大変さも、業界人以外には多分わからなくて、僕も偉そうに言えるほどちゃんと想像ついているわけじゃなかったりはする。 am2時にnote.com開いて、status code 503 でメンテページが返ってるのを見て、丁寧な仕事だなーなんて思ったのだけど、少し考えてみればこれを200で返しでもしたらわりかし大ダメージを受けるんだな、などと気づく。自分はメディア系(コンテンツ系?)のサービス開発に関わったことがないのだけど

            スキ
            12