basyura's blog

あしたになったらほんきだす。

GraphQL しらべ

某雑誌の冒頭に「GraphQLすごいんです」しか書いて無くて何がすごいのかどういうものなのかがさっぱり伝わらなくて逆に気になったので調べ(ググっ)てみた。

まとめ

いいとこ

  • 柔軟性が高い (API に対する多様な要求に答えやすい)
  • 一般的な REST API のように不要なものも含めて固定された項目を返すのではなく、1 クエリ(リクエスト)で必要なものを必要なものに絞って一括取得できる

分からん

  • メリットを感じられるケースがどの程度あるのか
  • 保守、性能面で RDB で SQL を叩くよりどの程度メリットがあるのか

memo

注意点

  • Client にクエリの決定権がある。Client にとって必要十分なクエリを起こすだけで済む。

GraphQLの利点

  • クエリとレスポンスの構造に対応関係がある
  • スキーマとその一部である型システムによりエディタにおける補完や型チェックなどのツールによる開発サポートが受けられる (IDE: GraphiQL - グラフィクル)
  • クエリの学習コストが低いことです。
  • 既存のクエリを壊さずにアプリケーション API を進化させることができます。
  • 柔軟性が高い (必要なものを絞って取得できる)

GraphQLの欠点

  • パフォーマンス分析が難しい → エンドポイントが一つしかないのでまとめられてしまう
  • 処理系の実装が難しい
  • 画像や動画などの大容量バイナリの扱いが難しい → Base64 でも 1.3倍になる / メモリに乗らないものは処理できない
  • 保守可能な GraphQL スキーマを作成する作業が付加される

links

GitHub

ウクライナ情勢 2022.02

f:id:basyura:20220224160741p:plain

links

words

北大西洋条約機構(NATO) - Wikipedia

  • North Atlantic Treaty Organization
  • 独立した加盟国が外部からの攻撃に対応して相互防衛に合意することで、集団防衛のシステムを構成している。加盟国は、域内いずれかの国が攻撃された場合、集団的自衛権を行使し共同で対処することができる
  • 第二次世界大戦が終わり、東欧を影響圏に置いた共産主義のソビエト連邦との対立が激しさを増す中で、イギリスやアメリカが主体となり、1949年4月4日締結の北大西洋条約により誕生した。「アメリカを引き込み、ロシアを締め出し、ドイツを抑え込む」。
  • ウクライナ、ベラルーシは NATOとの鑑賞地帯として重要

ブダペスト覚書 - Wikipedia

  • ハンガリーのブダペストで開催された欧州安全保障協力機構(OSCE)会議で署名された政治協定書
  • ベラルーシ、カザフスタン、ウクライナが核不拡散条約に加盟したことに関連して、協定署名国がこの3国に安全保障を提供するという内容

流れ

  • 「大国復活」の野望(?)
  • 東欧諸国を NATO に加盟させない約束をしていた(?)
  • ウクライナはロシア派と欧米派で大統領が入れ替わり続けている
  • プーチン大統領は「『オレンジ革命』によって、ウクライナはもうかつての政権ではない」「革命政権であって、全く別の政権ができあがっているので、覚書にある領土の保全や武力の不行使というのは、すでに適用されない」という考え方を明らかにしています。 (link)

トライアングルストラテジー

ファイナルファンタジータクティクスが面白かったし(遠い記憶)、HD-2D も良さそうなので体験版を試してみた。

導入ストーリー長い

  • これは仕方ないのかもしれないけど途中で飽きてきた。登場人物が多いのが記憶力がヨワヨワな身としては更につらい。都度、話している人の説明が見れたのは良かった。

戦闘時の移動でぬるっと後ろに来る

  • 前面 3 マスはスルーして移動できないような縛りがないと、固まって前進してるのにヌルッと移動してきて横や後ろからしばかれるので違和感がありすぎて萎える。
  • ガード役といいつつスルーされて後ろ叩かれる。かといっても敵側に突っ込んでいくのも違うしなぁで困惑

2 章までやったけど一旦終了。

Next.js 入門 2

サーバー側にリクエストを投げた結果を受けて表示したい。

import Link from "next/link";

export default function IndexPage({ param }) {
  return (
    <div>
      Hello {param.Hello}.{" "}
      <Link href="/about">
        <a>About</a>
      </Link>
    </div>
  );
}

export async function getServerSideProps() {
  const res = await fetch(`http://localhost:1325/api/echo`);
  const data = await res.json();
  return { props: { param: data } };
}

エクスポートしたい。

$ npx next export

Error occurred prerendering page "/". Read more: https://nextjs.org/docs/messages/prerender-error
Error: Error for page /: pages with `getServerSideProps` can not be exported. See more info here: https://nextjs.org/docs/messages/gssp-export

The getServerSideProps lifecycle is not compatible with next export, so you'll need to use next start or a serverless deployment.

ダメなんか・・・。node.js でサーバー動かせばいいんだけど諸事情にやりづらい環境なので辛い。

windows service で動かす方法があったのでメモ。

Next.js 入門 1

ファイル構成が好みだったのでチュートリアルを進めていたのだけど、Vercel 以外にデプロイする方法がよく分からなくて手が止まってしまったので調査。なるべく golang を使って動かしたいのでその路線で調べてみる。

ポイント

  • next export を使うと html に出力される
  • リクエストパスのファイルがない場合は .html でファイルを探し直して返す。

embed を使うパターンがいくつかヒットしたけど、単純にファイルを読んで返すパターンでやりたかったので上記サイトを参考にさせて頂きつつ自作。

$ npx create-next-app helloworld
$ cd helloworld
$ npm i
$ npm run build
$ npx next export
$ mv out ../public
$ go run main_nextjs_server.go 

Image タグを使っていると

Error: Image Optimization using Next.js' default loader is not compatible with `next export`.

と出て失敗するので、build の前に削除するか通常の html タグに書き換えるかで対応する。next チュートリアルのブログサンプルは動いたけど特に url パラメータから web の API にリクエストを投げて描画するパターンが動くのかがポイントなので継続して調査する。

※ 久しぶりに iPad に logicool のハードウェアキーボードをさして記事を書いてみたけど発狂するレベルで効率悪い。iPhone でフリック入力使う方がはかどるんじゃないかと思ってしまう。英数キーで IME をオフにしたいのだけどちょうどいいところに space キーがあって毎回誤爆してしまう。ここの誤爆を抑えられるだけでだいぶ違うと思う。ctrl+space での切り替えに慣れた方がいいのか。

languishing

年明けから(年末からだと思うけど)全方位的にやる気がアレでウォーキングもだるくなってゴロゴロしていて何かを始めても集中力が無くすぐ飽きるの繰り返しになっているのだけど vimrc いじりは割と長時間やっていられる不思議。気になるところが割と明確でそれを改善しようとするアプローチに対してフィードバックが早いからだろう。 asyncomplete.vim に乗り換えた後、ある程度補完処理を自分でコントロールしたくなったので processor を書いてちまちま更新している。ある時から補完の挙動が怪しく、補完したい単語の手前を書き換えてしまうことがままある。

    e.Static("/", filepath.j

たとえば go で ↑ を入力していて、j の位置に Join が候補として補完メニューに出るので確定すると、

    e.Static(filepath.Join

になるとか。デフォルトの processor を使えば起こらないので自分の書き方がおかしいんだろうなと思うものの比較しても良く分からない。引数で optionsmatches が渡ってくるので、これをもとにフィルタリングする。

options : { 
  "lnum":26,
  "bufnr":1,
  "col":29,
  "changedtick":82,
  "typed":"    e.Static(\"/\", filepath.j",
  "base":"j",
  "startcol":28,
  "filetype":"go",
  "curpos":[0,26,29,0,29],
  "filepath":"(略)/stats/stats.go"
}

match : {
 "status":"success",
  "ctx":{
    "lnum":26,
    "bufnr":1,
    "col":28,
    "changedtick":81,
    "typed":"    e.Static(\"/\", filepath.",
    "filetype":"go",
    "curpos":[0,26,28,0,28],
    "filepath":"(略)/stats/stats.go"
  },
  "startcol":28,
  "items":[
    {"word":"Join","abbr":"Join","user_data":"{\"vim-lsp/key\":\"26\"}","kind":"function","empty":1,"dup":1,"icase":1}],
  "refresh":true
}

通常は option.base に単語が入ってくるので、 matches で各 completor が抽出した items を filter すればいい。これが、入力している文脈によって

basee : [/", filepath.j]

のように変化することがある。option の startcol と matches の startcolctx.col を使って単語を抽出するように書き換えてみたけど、回避できないケースが出てきた。 結局の所、prabirshrestha/asyncomplete-file.vim の有りなしで挙動が変わり、さらに見ると asyncomplete#complete を呼ぶ呼ばないで挙動が変わることが分かった。fork してマッチするものがない場合は asyncomplete#complete を呼ばないようにした。何も考えずデフォルトの processor を使えばいいんだけど・・・並び順とか優先順位とかちらつきとかファイルタイプによって設定変えたいとかが気になってしまってアレ。

zenn.dev

はてなブログを使うメリットとか面白さがかなり前から無くなってるものの惰性で続けてた。 基本的に自分のことは日常系・技術系どちらも自分のところに書く方がいいでしょとは思い続けていたけど上記の通りだし、たまにある「機能修正・改善をお知らせします」を見てもアレだし、はてブもアレなので新しいことに取り組んで見る。

zenn.dev に上がってくる記事がなかなかいいし、zenn client でプレビュー見ながら記事を書いて GitHub と連携してデプロイの仕組みも面白い。試し記事をいくつか投稿してみた。この blog に投稿済みのネタを幾つか投稿しつつ新しいネタも定期的に投稿できたらいいなと思う。

この blog を放置するわけではなく何かしら投稿するので相乗効果でるといいな・・・?