RESTful API との比較で GraphQL API を作ることの難しさ｜qsona
上の資料でも書いてるんですが、要点を言うと以下のようなことを主張している。 API の設計手法として、以下の2つのパターンが考えられる ・Resource-based API ・Usecase-based API Usecase-based というのは要はクライアントの要求にそのまま沿った形で API を作るということだ。しかし、UI やその他クライアントの要求というのは変わりやすいものなので、そのたびにいちいち API を変更しないといけないとか、API に一貫性がなくて使いにくいとか、1つの endpoint で多数の要求に対処する "神API" が作られてパフォーマンスが悪化する、というような問題が起こる。 したがって、注意深く RESTful API を設計すると Resource-based になる。ここで言っている Resource というのはテーブル設計にやや近いが、そのまま
対戦ゲームに学ぶ、フレームワークの設計技法とAIのアルゴリズム入門 #builderscon tokyo 2019｜qsona
builderscon tokyo 2019 にて、表題にて発表します(した)。スライドだけでは十分に情報を伝えられないため、この記事にて補足していきます。 登壇資料 指のゲームここ(heroku)で動かせます。本来は対戦ゲームですが、1人で両方動かす形です。Display GuideをONにすると、後退解析によって解析された結果を利用して、各Moveのwin/lose/drawが表示されます。 コードはこちら(GitHub: qsona/yubisen)にあります(かなり雑然としたコードでスイマセン)。boardgame.ioを利用しています。後退解析のコードはその中のanalysis.tsです。 ぷよぷよの名勝負紹介した対戦は ALF vs かめ 100本先取 (2010, 実況 Tom) です。劇的な結末を迎えます。ぷよぷよを知らない方も最後の方だけでもぜひ。 "天才の詰み"郷田真隆
"クソコード"は人格攻撃ではないのか｜qsona
これは仮説というか自分がこうだという話なのだが、自分のアイデンティティを侵食されると怒りが湧く。たとえば、自分が非常に大事にしている価値観に対して、同僚から「君のその価値観は間違っている」と言われたり、あるいは、作品とか、経歴とか、家族とか、そういう自分自身と非常に密になっていて同一視されるようなものをけなされたら、腹が立つということだ。 プログラマーにとって、ソースコードというのは一つの作品だ。仮に経験が浅い開発者であっても、あるいは経験が浅いからこそ、1行1行に時間をかけて考えながら作りあげる。それに対してこれはクソコードだと言われたらどうだろうか。考えてみる。 よく、クソコードというのはコードがクソだと言っているのであって、お前がクソだと言ってるわけではないから切り離して考えるべきだという言説がある。僕はこれには微妙に賛同できない。その人が生み出したコードは、少なくともその人のいくぶ
モバイルエンジニアのためのBFF入門 (1) 技術選定の軸｜qsona
とりあえず第一回として、iOS / Android のための BFF (Backends for Frontends) を作りたくなったときに、どういう技術で作るかを考えてみます。第二回があるかは未定。 そもそもBFFって何という方のために、手前味噌ですが自分の登壇資料をあげておきます。 言語とフレームワークの選定まず、いくつか観点を列挙する。 静的型付け or 動的型付け できれば静的型付けのが良いと思う。 iOS / Android が静的型付け言語を利用しているので、スイッチングコストが少ない。 あと、たぶんそんなに頑張ってテスト書かない(書くのが難しい)ので、極力型レベルでバグを検知したい。要はBackendのAPIをstubしないとテスト書けないんだけど、せっかくテストをしてもstubが間違ってると意味がないので、そこの(叩くAPIの型の)信頼性はどちらにしろ担保しなきゃいけない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
