自己紹介と書籍「クモ本」の紹介
始まりました、ツナギメエフエムの第 154 回です。
ツナギメエフエムは、IT 勉強会 コミュニティ繋がりの方々を
ゲストに迎えて、雑談するポッドキャストです。
まずは、Xのハッシュタグについてお知らせです。
ハッシュタグはカタカナで、 ツナギメエフエムです。
トークをお待ちしています。今回のゲストは、
たつきちさんです。それではまずは、 自己紹介をお願いします。
整いました。API プラットフォーム とかけて、
大きめの革製品とときます。
ほう、その心は?
本川大、本が話題、たつっちです。
よろしくお願いします。
よろしくお願いします。
10秒ぐらいで考えた謎解きをご用意してまいりました。
また今日も来て。
ちょっとこういうのはすべてもやっていた方がいいかなと思って。
前回もそうやってやりましたよね。
ぺちなごの宣伝をさせていただいたときに、
なんか気合い入れて謎かけ言ったんですけど、
めっちゃ滑った記憶があります。
これやり続けるのが大事なんで、こういうのは。
そうですね。
謎かけのおじさんとしてやっていきたいと思います。
はい、やっていきましょう。
ちょっとだけ一応真面目な自己紹介も一言だけ言ってもいいですか?
そうですね。お願いします。
すみません。改めまして、たつきっちと呼ばれています。
2月にですね、APIプラットフォームを活用したPHPによる
本格的なWeb API開発っていう長いタイトルの
技術書、通称クモ本っていう
相性で読んでるんですが、という本を上司しまして、
普段は一人会社を経営していて、
主にPHPとタイプスクリプトとかで
住宅でWebシステム作ったり、
技術コンモン的なことをさせていただいたりとか
っていうのを生業にしています。よろしくお願いします。
よろしくお願いします。
僕の方で事前に準備してた
紹介文的なものを
準備してたんですけど、もう全部言っていただいたので
言っちゃいました。すみません。
本の話をですね、今日はやっていきたいなと思っています。
ありがとうございます。
出ましたね。2月ですか?
そうなんです。皆さんよろしくお願いします。
クモ本です。
買いました。
ありがとうございます。
本当はペチッパー会議の時に買いたかったんですけど、
電子の方を買いたいなと思ってたんで、
物理の話にさせてもらって。
そうですよね。そういう方もいらっしゃると思います。
ペチッパー会議で長谷川さんがサイン会を開いてくださって、
今回来ていただいた方はありがとうございました。
なんで物理の本を
僕が買わなかったかっていう理由があってですね。
ページ数すごいんですよ。
そうなんです。重いのなんの。
なかなかじゃないですか。
物理本で560ページってやばいでしょ。
そうですね。ページ番号が付いてるのは
543までで、
入稿枚数が560ページなんですけど、
結構削るところ削って、
ギリギリまで削ぎ落として、
最後に残った543ページっていう感じです。
これ以上削れるところがなかったです。
僕は
Kindleで買ったんですけど、
老眼がひどくて、
大きめにしてるんですよ。
なるほど。
枚数がえぐいことに。
800とかになるわけですよ。
終わりが見えないですね。
これは読み終わるんかなと思って。
気長にのんびり読んでいただければ。
頑張って読ませていただきます。
書籍執筆のきっかけと制作プロセス
なんでこの本を書くことになったのかなとか、
そういったところから聞いてきてます。
そのきっかけみたいなところですね。
僕が半分冗談で、
APIプラットフォーム、
日本一極めるので、どちらかの出版社さん、
商業本出させてくださいっていうツイートを
昔しまして、それ本当に
ギヒョウさんが拾ってくれてっていうのがきっかけです。
これでもまあまあ本気で書いたんですか?
半分本気ですね。
そのツイートしたの2023年の
7月23日だったんですけど、
これ全然どうでもいい余談なんですけど、
7月23年7月24日が
TwitterがXに変わった日で、
その前日のツイートだったっていうのがこの前のツイートでした。
最後のツイートでした。
ポストではなくツイート。
その時、多分APIプラットフォーム、
実務で使ってたプロジェクトが
一段落したところで、多分自分の中に結構
ググっても全くわからなかった知見が
自力でいろいろ
編み出した知見がいっぱい溜まってたんで、
これ本になるなとか思いながらそんなことをつぶやいたような気がしますね。
そのツイートしたら、
あれなんですよ。
田中日佐寺先生がリプを
くださいまして、
APIプラットフォームの本を出させてくださいって
つぶやいたら、田中さんから
それではまずシンフォニーとドクトリについて説明しますっていう
ちょっとイジリツイートみたいな
が返ってきて、APIプラットフォーム説明しようと思ったら
最初にそこ説明せざるを得ないから
書くの大変そうだねみたいなニュアンスだと思うんですけど、
そこから始まった雑談を
ちょろっとツイッター上でしてたら
担当編集の方が日佐寺さんのファンで
日佐寺さんのことフォローしてて、
そのスレッド見てくれて、で僕に連絡してきてくれたっていう。
なるほど。
日佐寺様様で本になりました。
本当そうですね。日佐寺さん様様ですね。
もう足を向けて寝れないです。
なるほどな。
それがきっかけですね。
そうそう、SNSきっかけで本って出るもんなんだなと思って。
そうですね。
僕も10年ぐらい前に
シンフォニーの
後藤さんが書かれたシンフォニーの本に
一生だけお手伝いで書かせていただいて、
著者名に名前を入れていただいたことがあったんですけど、
それは本当に後藤さんの本で僕はちょっとお手伝いしていただいて、
ただ単調で書いただけみたいな感じで。
今回単調でほぼ初めて本を書いたみたいな感覚だったんで、
うんうん。
こんなきっかけで単調を書く機会が得られることもあるんだなあっていう感じでしたね。
いや、しかし、
そのページ質の話しましたけど、
すごいボリュームじゃないですか?
めちゃくちゃ大変でしたね、書くのは。
2年ぐらい書いてました、ずっと。
そのツイートした2023の夏に
編集さんから連絡いただいて
なんかちょっとじゃあ正立て考えていきましょうかみたいなのが始まり
多分秋ぐらいからなんかちゃんと真面目に原稿書き出したと思うんですけど
それから結局2025の年末まで書いてたんで
ちょうど2年間ぐらいですね。
ああ、そっか。
で、その間に1年間ぐらい
PHPカンファレンス名古屋のことしか考えてなかった時間があったんで
ああ、確かに。
その間はほぼ原稿ストップしてましたけど。
そっかそっか。
なんで正味1年ちょいって感じですかね。
その短調を書かれたときって
何か知ってますけど
どうやって進めるのかみたいなところが分かってないんですけど
本ってどうやってできていくんですか。
どうやってできていくか。
その進め方。
最初は本当になんかブログ記事書くのと一緒で
僕はPHPストームでマークダウンをずっと書いてました。
で、その最後の最後まで自分が書くのはマークダウンで
技表さんの場合はだと思うんですけど
著者が書いたマークダウンの原稿を
いい感じに組み反してくれる
マークダウンから本当の本の形に組み反してくれるシステムがあって
それに最適化させる
ちょっとしたタグとかを
僕の原稿執筆と並行で
編集さんが入れてくれて形が整って
後半の方はGitHubに原稿をプッシュすると
自動でPDFのビルドが走って
プレビューできるみたいな体制で
本当の本の形になってるなっていうのを見ながら書き進めてました。
なんか表紙に公式のロゴが載ってるじゃないですか。
あれって許可をいただいたんですか。
一応公式サイトにトレードマークポリシーっていうページがあって
それに見るとロゴの商用利用は原則禁止
どうしてもの場合はメールで連絡くださいみたいな感じの内容になってたんで
メールで連絡をしまして
APIプラットフォームのコードベースにまあまあコントリビュートしてるんですけど
みたいなところから書き始めて
アピールかなと
ちゃんとコントリビュートしてるものなんですがっていう感じで
今書いてる本の表紙にロゴ使わせてくれませんかねって送ったら
めちゃめちゃすぐに快諾のメールが返していただけて
なんならめっちゃ喜んでくれてて
反則のためのパンフレットとかステッカーとかも送りますよみたいな感じの返信をいただきまして
実際フランスからわざわざいろんなステッカーとかTシャツとかいっぱい送っていただきました。
フランスなんですね
そうフランスの会社が開発元なんですねAPIプラットフォーム
これって会社が元になってるんですか
OSSなんですがその作者の方
ケビン・ダングラスさんってフランケンPHPとかも作ってる人
そうなんだ同じ人なんだ
APIプラットフォームの作者で
この人がCEOのフランスの会社
読み方が僕フランス語わかんないんですけど
レティユールって読むのかな
レティユールっていう会社がフランスにあって
そこのCEOがケビン・ダングラスさんなんですけど
この会社が一応開発元となっていて
多分この会社さんは自社初で作ってるOSSとかを含む技術領域を中心に
コンサルティングとかトレーニングとかをするビジネスをしてる会社っぽいですね
このケビンさんはSymphonyのコアチームの人でもあります
なるほどなるほど
一個思い出したことがあって
APIプラットフォームカンファレンスって
書籍の中でも書かれてたんですけどやってるじゃないですか
あれフランスなんですよね場所が
そういうことっすね
そうですね
やっとわかった
フランス初のフレームワークっていう感じ
なるほどなんでフランスなのかなと思ってたけどそういうことか
そうなんです
ベージスすごいっていう話をしてましたけど
目次見たらわかるんですけど
APIの本じゃないんですよ
これは何とも言い難いんですけど
僕としてはWebAPI真面目に作ろうと思ったら
これもうするしかないよなと思いながら書いたらこうなりましたっていう感じ
なんですよね
Webシステム開発
まあまあそれは確かに
っていう側面がすごいあるなと思って
これはさすがに大変でしょうと思ったんですけど
なんかそのカバー範囲が多岐に渡ってるのは
結構書きながらこの一冊だけで
かなり本格的なレベルまでつまずくことなく
APIの開発進められるっていう状態に
読んだ人になってもらいたいって思いながら書いた結果
実務レベルのちゃんとしたWebAPI作る
WebAPI開発を語ろうと思ったら
最低限これは外せないな外せないなってやっていったら
こんだけ残ったみたいな感じですね
でもヒサテルさんがシンフォニーとドクトリーについて説明しますって書いてましたけど
まさにその通りで
まさにそうなりました
未来予知みたいな話です
最初にシンフォニーとドクトリーの話があるじゃないですか
APIプラットフォームとは何か？
それをしないで話が始められなかったんで
ハンズオンで動かしながら学んでいっていただく形にしようと思った瞬間に
実際動かすもののことを納得するために
最低限シンフォニーとドクトリーに分かった上でやらないと
何にも成り立たないなっていう感じになって
APIプラットフォームを使い始めるには
シンフォニーについて造形を深める必要がある感じなんですかね
今はシンフォニーとララベルのどっちかで
APIプラットフォームっていうのは使えますっていう状態なんですよ
元々はシンフォニーと併用する前提のフレームワークとして
最初は出てきたんですね
結構長い間バージョン1から2.3の頃まで
ずっとシンフォニーとの併用が前提ですっていう立場で
開発が進んでたんですけど
今4.3っていうのが最新なんですけど
4.0が出た時にララベルをサポートしましたっていう
代々的なニュースがあって
それ以降は既存のシンフォニーアプリケーション
あるいは既存のララベルアプリケーションに
APIプラットフォームを後付けでインストールすれば
使えますよっていう感じに変わってます
だからシンフォニーのことを知らない状態で
使い始めることもできはするんですけど
ただそれは半分事実で半分ごまかしてるところがあって
APIプラットフォーム自体は中身の実装に
めっちゃシンフォニーのコンポーネント使ってるんですよ
なのでシンフォニー全く知りませんっていう状態で
APIプラットフォームをララベルベースで使ったとして
多分困ったときにAPIプラットフォームのソースを見に行くと
シンフォニーコンポーネントで作られてて
そこが分からないと困るみたいなことは
全然起こるかなと思います
なるほど
はい
改めてなんですけどAPIプラットフォームとは
ざっくりどんなものっていうのを解説してほしい
一言で言うと
Web APIの開発に特化したPHPフレームワークですね
さっき言った通りシンフォニーまたはララベルと
併用することが推奨されていて
一応フレームワーク使わずに
スタンドアローンでも動きますっていうことには
なってるんですけど
それやろうと思ったら
めっちゃブートストラップのためのコードを
たくさん書かないといけないと思うんで
あんまりオススメは
公式からもオススメはされてないですね
なるほど
基本はシンフォニーで動いてるシステムか
ララベルで動いてるシステムに
アドオンするみたいな感じで
使うのがセオリー
コンポーザーリクワイヤー
APIプラットフォームすらシンフォニー
ってやつをインストールするか
すらララベルってやつをインストールするか
っていう感じで使います
単独でも使いはするけどちょっと厳しい
そうです
セットアップのためにいろんなことを
自分で書かないといけないんで
あんまりそれをやりたいことは
あんまりないかなっていう感じですかね
PHP専用って考えたほうが正しい
それそうです
PHPフレームワークですね
APIだけを
語で作るとかある話じゃないですか
それをPHPから呼ぶみたいなのも
システム的にあると思うんですけど
そういうふうに
APIプラットフォームで作ったものを
他の言語で呼ぶっていう感じはないってことですか
そうですね
それは基本的にないと思います
2023年の時点で
すでに知見が溜まっていて
本を書こうかなって思ったって言われてましたけど
そのAPIプラットフォームをそれ以前に
使おうと思ったきっかけみたいなところとか
どういったところが
これがいいなって思って使い始めたのか
みたいなところを教えてほしいなと
APIプラットフォームを使い始めたきっかけと魅力
そもそも
僕が最初にJitsumに投入した2000
多分1の末ぐらいかな
から始まったプロジェクトで
初めて
味見だけじゃなくてJitsumで初めて使ったのが
その頃だったんですけど
その時点でシンフォニー界隈では
すでにそれなりに知名度があったんですよね
名前は知ってるし
ちょっと触ってみたことあるぐらいの状態で
でももうちょっと詳しく言うと
シンフォニーにはバンドルっていう
プラグイン機構があるんですけど
以前はシンフォニーでWeb API作るぞってなった場合
FOS RESTバンドルっていう
いにしえのシンフォニーユーザーが
懐かしいっていうサードパーティー性のバンドルがありまして
それがずっとデファクトスタンダードだったんです
そのバンドルが2021年に
開発終了になりまして
その開発チームから代わりに今後は
APIプラットフォームを使ってくださいっていうツイートが
出たりしてたんですよ
多分僕の感覚ではその辺から明確に
こっちが標準なんだなっていう
空気がシンフォニーの界隈の中で出てきてて
っていうのがあっての2021末ぐらいに
僕が実践投入だったんで
普通に今だったらこれでしょみたいな感じで
そんなに迷うことなく使い始めたっていう感じですね
しかし僕
存在を知ってなくて
知らない状態で
APIプラットフォームってまあまあなビッグワードだなと思って
名前よくないですよね
名前強すぎませんか
めっちゃ僕もそう思います
検索するときに
ググりにくいし
僕はツイッターで
APIプラットフォーム
日本語のツイートを絞り込んで
エゴサしてるんですけど
全然関係ないオープンAI APIプラットフォーム
そうですよ
これはちょっとビッグワードだなと思って
なんでこんな名前にしたんだろうって
ユニーク性の高い名前にしたらよかったのにって思って
それは僕も思いますね
すごい強い名前ですよね
それはすごい感じました
同感です
あとなんかお仕事にもよると思うんですけど
RESTとGraphQL
どっちで使うパターンが多いですか
そうですね
APIプラットフォームは
簡単にREST APIとGraphQL APIが
作れますっていうフレームワークで
両方対応してるのが一個特徴なんですよね
質問の答えで言うと僕は
RESTしか使ってないです
これは個人的に今までのキャリアの中で
あんまGraphQL使ってこなかったんで
そんなに慣れてないっていうのもありますけど
正直APIプラットフォームまだ全然開発が活発なんで
RESTのほうの機能がメインで
GraphQLは設定で
オプトインすると有効化できるっていう
サブ的な立ち位置の機能で
割とバギーなことが多い印象が
正直あって
ちょっと避けてるっていうところもあります
僕もGraphQL開発で使ったことはないんですよね
RESTはちょっとありますけど
なるほど分かりました
本の解説の中で一部あったんですけど
APIのトラフィックって
Webセンターの80%超えるって
マジかって思って
今もそんな時代なのかって思って
APIトラフィックの現状とSPA/MPA
僕も執筆中にたまたまその情報を知って
マジかって思ってこれは引き勝手ええわと思って
一生の解説の中で付け加えたんですけど
本の中にも載せてますけど
出典は赤前の2019年のレポートで
はいはい
83%って書いてたかな
それぐらいの数字でしたね
でも考えてみれば多分そうですよね
あらゆるスマホ
クラウドサービスとか
普通のウェブサイトですら
SPAになってて
通信はAPIみたいなこともあるし
Web API以外のWebトラフィックって確かに
もはやあまりないよなっていう感じは
僕がアプリケーション開発に携わってた頃とはもう変わっていて
世界が変わってしまってますね
本当ですね真心込めて1URLロゴと
作ってたのは今や昔みたいな感じで
そうなんですよね
もうSPAですもんね
そうだから僕はAPIを使って
ウェブページを表現するっていう
開発に切り替わるぐらいのタイミングで
アプリ開発からもう離れてて
ちょうどあんま触ってないですよね
ゼロではないけどみたいなぐらいなんですよ
いわゆるMPAみたいに呼ばれる
SPAと対比してMPAと呼ばれてますけど
MPAと呼ばれる作り方で作ってた
多分最後のぐらいじゃないかな
なので勉強するのにもちょうどいいかな
と思って買ったんですけど
ありがとうございます
そうだから言葉は聞いたことあるけど
使ったことないキーワードとかがたくさん
いわゆるOpenAPIとか
JSON SchemaとかJSON LDとか
このあたりのキーワードが
実は全く分かってなくて
勉強しないといけないなと思って
でもまさにそういう人に
呼んでもらいたくて書いた本でもあるんで
赤瀬さんも多分呼んでいただければ
今出てきたようなキーワードは
全部多分理解していただけるかなと思います
頑張ります
赤瀬さんの場合
その辺の時代から
アプリ開発じゃなくなったっていうのがあって
こっちの動向キャッチアップしてない
っていうことだと思うんですけど
全然現役で
ウェブアプリ開発してる人でもいまだに
まだやっぱりNPAしか
分かんないみたいな人って
僕の感覚だとまだ全然いる気がするんですよ
でも現場によってはあるのかなって思うんですけどね
置いていかれてしまって焦燥感だけがあって
みたいな人を
救いたいなと思って
俺なら救えるって思って書きました
素晴らしい活動じゃないですか
そういう人の気持ちめっちゃ分かるんで
必死に食らいつきながらやってきた感じなんで
容量が悪くて
最初全然ついていけないみたいなのを
時間かけてなんとか習得してみたいな
タイプのエンジニアなんで
最初からこれをそう説明してくれればよかったのに
自分が書けたらいいなみたいな感じで書きましたね
本の執筆にあたって
いろいろ参考にした小説とかもあると思うんですけど
本書で解説される技術キーワードと執筆の意図
もしこの場で挙げれるものがあったら教えてほしいなと思って
本に参考文献で
載せたようなやつですね
前半のドクトリンの説明とかしてるところの
設計パターン
ORMの設計パターンの説明とかが出てくるんですけど
その辺はそれこそヒサテルさんの超絶本とか
本家のP of EAとか
あたりながら
正確な説明を心掛けようみたいなことをしましたし
HTTPの
基盤の話を割とするところが
たくさんあったんですけど
その辺は例えば
ウェブを支える技術とか
リアルワールドHTTPとか
は
結構あたりながら書きましたかね
セキュリティ系の話とかで得丸本
聞いたり
ウェブAPI全般のペットプラクティス
とかを参照するのに
ハッキングAPI
ありますね
APIデザインパターンとか
ちょっと前に出たウェブAPI開発実践ガイドっていうムックがあるんですけど
この辺とか
去年のですね
そうかな
HTTPに関する登壇をやったときに
このあたりの本って結構さらっと
さっき挙げてくれたような本とかを
結構読んでたりしましたね
いい本ですよね
APIのほうも意外とあるんですよね
オライリーからも結構出てて
はい
翻訳版出てないやつとかもあったりとかして
僕正直技術書あんまりたくさん
読んできてないんで
こんな引き出しないんですよね
リアルワールドHTTPとかも
今回この本書くのに読んだみたいな
そうなんですね
ハッキングAPIとかもそうかな
リアルワールドHTTPは面白いもんな
すごい良かったです
僕もすごい良かったですね
ありがとうございます
あとちょっと話が飛んじゃうんですけど
クモのことも話したじゃないですか
ロゴの発見を
なんでクモなんですかね
APIプラットフォームの公式ロゴが
クモのキャラクターなんですよね
これがなんでクモかは僕も別に知らないんですけど
多分スパイダーウェブっていうことなのかなって思いますが
そういうこと?
それぐらいしか考えられなくないですか
なるほど
参考にした書籍とAPIプラットフォームのロゴ
誰かに理由を聞いたわけではないですよ
多分そうかなって
めっちゃ納得
最初クモ本って言われてて
何のことかなって思ってたんだけど
ロゴがクモなんで
表紙のどの写真にしますみたいなのを
選ぶときに
可愛いクモのやつ選んでもらって今の表紙になったんですけど
表紙にクモがバーンっていて
クモ本みたいな分かりやすい相性があったら
みんな呼びやすいかなと思ってそうしました
公式サイト面白くて
ロゴが謎に充実してて
そうなんですよね
壁紙とかいっぱい配布してる
塗り絵とかあるんですよ
意味わかんない
塗り絵があって
何?みたいな
よくわかんないですけど
マーケティングの一環なんでしょうね
壁紙も結構可愛いんですよね
ロケットのやつ
謎に充実してるな
1個知らないツールがあったんですけど
インソモニア
書籍の中で
REST API の動作確認をするツールを
特にこだわりがなければ
僕と同じインソモニアってやつを使ってくださいって
書いてあって
そのツールですが
API開発ツール：Insomniaとその他
僕なんか昔からインソモニアずっと使ってますね
なんかこういうの色々ありますけど
こいつ使いやすいですか?
いる機能は全部あって
特に困ることもないんでずっと使い続けてる感じです
この本書くときに
もしインソモニアがもうすでに時代遅れだったら恥ずかしいなと思って
最近の流行りを一応調べたりしたんですけど
最近流行ってるものが他にもあるけど
別にインソモニアも人気が落ちてるわけではなさそうっていう
自分の中では結論を変えられたんで
普通に慣れ親しんでるインソモニアを使いました
これはデスクトップアプリケーションですか?
そうです
普通のいわゆるAPIクライアントツールですね
僕これ知らないなと思って
多分もう10年以上ずっと使ってますね
そんな使ってんだ
このウェブサイトの面白いなと思ったのが
ドメインを見るとドットレストなんですよ
インソモニアドットレストですよね
そんなトップレベルドメインあるんだって
これでも調べたらドットレストはレストラン業のためのドメインでした
そうなんだ
ドメインハックの一種みたいな感じの使い方でしたね
知らなかったな
別にウェブのレストとは関係ないレストランのレストでした
すごいトップレベルドメイン使ってるなと思った
いいですよね
こういうの好きなんですよね
さっき調べたみたいなことを言われてましたけど
他ありますっけ?
どっかでメモってるんですけど
デスクトップアプリケーションじゃないけど
ポストマンとかこういうやつですよね
そうですねポストマンのアプリも使えると思います
あれアプリもあるんだ
ホップスコッチっていうやつが
最近ちょっと流行ってそうな感じがありました
ホップスコッチ
これは多分特徴はブラウザ上で動きますっていうのが多分特徴なのかな
なんか使用感は別にインフルエンザとかと比べて
何か特別違うっていう感じがなかったです
同じようなことができるっていう
他にもいくつか調べたら
こういったやつはね大体一緒だとは思うんだけど
やりたいことが一緒ですからね
そうそうそう
なんか比較サイトみたいなやつとかを見たりしながら
まあまあ別にインソメニアでいいかっていう結論を出しましたね
なるほどありがとうございます
執筆におけるAIの活用とレビュー体制
あとすごい大量のページ数なので
使ったのかどうかちょっと聞きたいなと思ってるのが
AIは使いましたか?
あー
それで言うと
執筆期間の終わり頃にAIがやっと本気出してきたっていう感じの
タイミングだったんで
だからあんまり本文を
エージェントにガーって書かせるみたいな使い方は全くしてないですね
なんか真心を込めた手書きです
手をつけ始めたのかそうですもんね
そうそうあの2023末から2025末が書いてた期間で
クロードコードのリリースとかが
多分2025の5月とかのはずなんで
なんか終わり頃にAIがすごくなってきたみたいな感じで
強いて言うなら
それこそ本の中でJSON-LDとかOOSとか
いろんな標準仕様について結構しっかり裏取りのために
めちゃめちゃ詳しく調べながら書いたんですけど
その調べる作業を
例えばChatGPTにRFC読ませて質問ゼミにするみたいな
使い方は結構してましたね当時
それは便利でした
AIはやっぱりこの答えを持ってることについて
めちゃくちゃ詳しいじゃないですか
そうですね
なかったら調べるのもっと大変でしたね多分
RFCとかめっちゃ詳しいんで
ちゃんと返してくれるんで
あれは非常にいいなと思います
あと原稿の入稿の前日とかのタイミングで
結構なんか入稿ギリギリまで
原稿めっちゃいっぱい直したりしながら
ギリギリで直前2日ぐらい徹夜しながら入稿したんですけど
やっと一通りフィックスしたって思って
入稿前日ぐらいのタイミングで多分
フロードコードに誤植を探させたら
めちゃめちゃ大量に出てきて
AIがなかったら死んでたなって思いましたね
そういうチェックを人手でやってもらったりとかはしてないんですか
僕と編集さんとレビュアーの皆さんで
全部読んでずっと見てるのに
めちゃくちゃ大量に見落としがあって
レビュアーさんは何人ぐらいのお願いしたんですか
書いてた部分
最初のシャジでお名前を挙げさせていただきました
早々たるメンバーに
1,2,3,4,5,6名の方にレビューいただきましたね
僕も一度だけレビューさせてもらったことあるんですけど
ページ数が多いと大変なので
どう立てかうかみたいな
本当にとんでもあった時間がない中でお願いしたんで
2025年末にやっと書き終わって
年明けから皆さん読んでいただけるようになりましたって言って
2月の上旬ぐらいに入稿日があったんで
1月の1ヶ月間だけでお願いしますっていう頼み方をして
かなり本当むちゃくちゃなお願いだったのに
皆さん心よく引き受けてくださって
もう感謝してもしきれないですね
早々たる方の名前が出てたんで
そうなんです
素晴らしいな
ありがたい限りです本当に
脚注とコラムの活用、RESTの定義
読んでて非常にたつきちさんらしいなって思ったところがあって
注釈をつけてるじゃないですか
ちっちゃい本の中で
その注釈で
注釈飛ぶと
よくあるとかURLとかがあったりすると思うんですけど
そのURLと一緒に
プラスでコメントも書いてあって
ここにも説明あるのかと思って
びびまして
特徴的かもしれないです
本当特徴的だと思いますよ
いわゆる脚注ですよね
リボンで言うとページの下にちっちゃい字で書いてあるやつ
そこは技術書である以上嘘を書くわけにいかないんで
本文を分かりやすさのために簡潔に
あえて言い切っておいて脚注で
実はこの説明は一部不正確で厳密にはこうこうなんですみたいなのを
書くっていうパターンを結構使ったんですね
そういう脚注に言い訳みたいなのを
どうしてもたくさん書かざるを得なかったみたいな
事情はあるんですけど
脚注が多分多いし
一つ一つの脚注結構長めなんですよ僕
そう感じました
これは僕の好きな技術書がそうだったから
影響を受けたっていう面が多い
そうなんだ
長い脚注かっこいいなって思って
めっちゃ影響されました
具体的に自分の中で印象深く覚えてるのは2冊あるんですよ
1個はウヒョさんの通称ブルーベリー本
プロを目指す人のためのタイプスクリプト入門っていう
は明確に脚注が多いと思います
結構長い脚注もあって
それ読んだ時になんかかっこいいなって思ったんですよね
説明を省かずに仕切ろうとする姿勢がかっこいいと思ったのか
なんかわかんないんですけど
あともう1冊は杉本さん
去年PHPカンファレンス関西で基調講演をされた杉本慶さんの
データモデリングでドメインを駆動するっていう本
これも長い脚注が結構たくさんあって
めちゃくちゃかっこいいなって思って
無意識に真似してましたね
そういう影響下にあってあれらかの形だったんですね
読みやすい本文を読みやすくしようと思ったら
必然的にそうなったっていうのが一番の理由ではあるんですけど
僕は潜在的にそれを思考してたっていうのは大いにあるなっていう
小さく書いてあるけど説明長っと思って
びっくりしながら読んでて
そうなんです
そういう理由もちゃんとあったんです
それが分かって非常に納得感というか
あとはそういう言い訳というか本文で説明しきれないのを
どうしても正確に伝えるために脚注に書かなきゃみたいな側面があり
さすがに脚注に書ききれないぐらいしっかり細く説明したいっていうものも
時にはあって
そういうやつはコラムっていう形で1ページとかそれ以上使って
ガッツリ言ったらいいわけみたいなのをガッツリ書いてるっていうのもあります
コラムも多かった
そうコラムでその最たる例が
レストっていう用語について解説したコラムが1個あるんですけど
1ページのスクショをツイッターに貼ったら
200いいねぐらい
240ぐらいかな
めっちゃいっぱいいいねしていただいて
みんなレストなんだろうな
好きなのか俺も誤解してたわなのかわからないですけど
結構たくさんの方に呼んでいただきました
あれですよね
元の意味と
なんでしょうね
そうカイツマンで言うと
みんなレストAPIって言ってるけど
それは提唱者が言ってるレストっていう言葉とは意味が全然違うからねっていうのを
ちゃんとその説明をしないままに僕が本文の中でレストって言ってると
このにわかがって思われるじゃないですか
間違った意味でのレストっていうのを説明なしに使うのは
技術書として不誠実すぎるかなって思って
最初僕レストっていう言葉を本文の中に1個も使わずにずっと書いてたんですよ
半年以上
途中で限界が来てやっぱり
説明をした上でレストっていう言葉は使わざるを得ないなって思って
コラムを書いたんですけど
そういう
不正確なものを
あやふやなままに
読者に
渡しちゃうっていうのが
ちょっと僕の
なんですかね
あんまり自分で許せなかったから
そういう言い訳がたくさんありますっていう感じです
いわゆるクラッドを
として
クラッドを思い起こす
普通今レストAPIっていうと
HTTPメソッド
ポストゲットプットパッチデリートを
クラッドに対応させるような
ウェブAPIのスタイルのことを
みんなレストAPIって呼んでるんですけど
提唱者のロイ・フィールディングさんが
最初に定義したレストっていうのは
それとは全く違う意味なので
気をつけましょうねっていうものですね
その中に出てくるキーワードがあるじゃないですか
僕は未だにこの読み方がわからないんですけど
あ
HATEOASって括弧ですね
そうそうこれ知ってますよ
知ってますけど読み方がずっとわからないっていう
これはですね
僕もずっとわからなかったんですけど
多分ヘイティオスだと思います
一般的な読み方は
そうなんですか
おそらく間違ってたらすいません
ただ僕は脳内ではハテオアスって呼んでます
そうなんかその読み方をしてる人もいるし
全然音で言う場合は
みんな多分ハテオアスって言いますよね
日本語の場合
これも面白いですよね
これが元の意味に近いというか
そうですね
RESTはいくつかの制約を集めて
RESTっていうものですって定義されてて
その中で一番特徴的な制約が
このHATEOASってやつで
なんて言ったらいいのかな
サーバーから返ってくるHTTPのレスポンスには
次のアクションをするためのリンクが
そこに含まれてないといけませんよっていう原則
制約が
Hypermedia as the Engine of Application State
略してHATEOAS
ヘイティオスなんですけど
それがRESTを一番
端的に表す特徴的な制約と
言われている
さっきのクラッドになぞられるAPIスタイルは
別にこのHATEOASを満たしてもないし
それ以外のRESTの原則も全く何も満たしてない
全然違う意味のものなので
単にRESTって説明なしに言っちゃうと
本当の意味のRESTを指してるのか
慣習的な意味でのRESTを指してるのか
わからなくてちょっと扱いづらい言葉だねっていうような
そうですね
その辺の説明はしなかったらしなかったで
ツッコミが入るだろうし
怒られるの嫌じゃないですかそんな
ちゃんとわかってるのに省いたせいで怒られるの
勘弁なんで
ちゃんと説明しようっていう
その辺はねやっぱね
たつきちさんの誠実さが伝わってくる
作りだったなと思って
SymfonyCastsとコントリビューターとしての活動
めちゃ感じましたね
ありがとうございます
多分僕は怒られるのが怖くて言い訳してるっていう
感じですけどね
やっぱね読みながらこう
性格出てるなーみたいなのは
ありますね マジですか
感じましたよ本当に読んでて そうなんですね
分厚さとかわかんない
まあ確かに
省きたくなかったんだろうな
思いましたね
あとちょっと
話題が変わるかもしれないんですけど
シンフォニーキャストってなんですか
はいはい
シンフォニーキャストは
シンフォニーの
ビデオチュートリアルサイト
みたいなやつですね
これもともと非公式のサイトだったんですけど
10年くらい前に
シンフォニー公式の提携先みたいな形で
シンフォニーファミリーに加わりましたみたいな
感じの発表がされて その時から多分名前が
シンフォニーキャストに変わったのかな
ちょっとどのショーか忘れたけど
紹介があった気がしたので
APIプラットフォームのですか
違ったっけ いや多分ありますね 見た気がします
ですよね
これどんなサイトだろうなと思って
気になってたんであげたんですけど
これシンフォニー公式のビデオチュートリアルサイトですね
公式ドキュメントの
次にというか
より深く学びたい人が
有料でビデオを購入してみるみたいなサイトですけど
ここでより深く学べますよっていう感じの
やつです
確かにAPIプラットフォームのチュートリアルもあるっぽいですね
ありますね
バージョンが3ぐらいで止まってて 更新はされてなさそうな気がします
確かに3ですね
ちょっとAPIプラットフォームの開発が
すごい活発なんで
そこが追いついてないっていう面があるのか
ですね
僕が早口だったせいかあっという間に
準備してたものを消化してしまいました
いいじゃないですか
僕一個自慢話してもいいですか
お願いします
APIプラットフォームの公式サイトに
コントリビューター一覧みたいなページがあって
乗ってんの
トップ100の人が
ちょっと待ってくださいね
今見てます
これか
トップ100まではアイコン付きで乗ってて
その後
全員乗ってんのかな
僕トップ32番目にいるんで
アイコンが付いてます
乗ってるわ32番目に
日本人では僕が1位のはずなんで
すごいじゃないですか
このクモ本書くきっかけになったら
日本一極めますっていうツイートの伏線を
回収していると言ってもいいのでは
これは素晴らしい
だいぶかっこいいですね
ただこれはですね
本を書くためにコントリビュートしたみたいな
原稿書きながら
開発が活発なフレームワークなんで
まだまだバグとか
使用バグみたいなものもたくさんあってですね
解説書きながら
このバグはちょっと
ここはバグってますっていう説明するのちょっと嫌だなっていう
ものに出会うと渋々時間ないのにって思いながら
再現環境作って
コード書いてプルリコ送って
メンテナーの人とアウトコーダ議論して
修正内容調整して
マージされてみたいなのを結構時間かけて
何回も何回もたくさんしたんですよ
執筆期間中に
素晴らしい活動じゃないですか
それもあって順位が上がりました
かっこいい
本に都合のいいように
コードベースの方を修正するっていう
姿勢がいいじゃないですか
こういったバグは説明したくないなって
ここはバグってるんで僕が納得できないんです
もし自分が読者だったら
そんなバグのあるフレームは書きたくないわいって思うじゃないですか
めちゃくちゃかっこいいじゃないですか
だから執筆期間2年ぐらいありましたけど
APIプラットフォーム本体のコードを直してた期間が
たぶん1割ぐらいあると思います
原稿書いてたっていうよりかは
コード書いてたみたいな時間がめっちゃありました
いいじゃないですか
素晴らしすぎるんだけど
書籍完成の感想とサンプルアプリケーション
実際書き上げてどうですか
短調
いやー
今のところはもう二度と書きたくないなって思ってますね
大変すぎて
早く終わらせたいしか
もう後半思ってなかったですからね
期間も長かったでしょうかね
ただ今だったらAI使って
もっと楽できるなとは思います
一旦こう
ざっと走行書かせて
自分の言葉に書き直してみたいなデジタルでやるだけでも
相当ショートカットできるやろうなっていう
なんか
そうですね短調
ゆえにというか
単純に各分量が多いのもそうだし
僕のこの本の場合
サンプルアプリケーション作りながらハンズオンで学びましょう
っていう内容になってて
各章でどの題材を説明するかは
さっき決まってるじゃないですか
この機能について説明するっていうのは決まってて
その機能をその順番でちゃんと説明できるような
サンプルアプリケーションの
縦付けを考えるのが
バリクソ難しくて
途中でめっちゃそのサンプルアプリケーションの仕様変更めっちゃいっぱいしました
ハンズオンのコードがあるの
すげえなと思って
大変でした
ちゃんとお前のショーでやったことが後から繋がってくる感じになった時に
脳汁が出ますね
うまくいった
そういうハンズオン形式の本
すげえって思いますもん
動かしながら読みながらやると
ただこれ悲しいかな多分ほとんどの人は
手は動かしてはくれないんですよね
実際には
一部の熱心な方が
動かしながら思っていただけたら
救われます
動かしてくれることを祈ってます
それでいうと
サンプルアプリケーションのコードは
全部GitHubに上がってて
書籍の解説は
シンフォニーベースの解説なんですけど
ララベルベースで同じことをやったコードも
全部上げてあるんですよ
すげえ
なので書籍の方には
各章の末尾にコラムが1個挿入されてて
そのコラムでこの章で解説したことを
ララベルでやる場合はエッセンスとしては
こことここがこういう風に違いますみたいなのが
簡単に最低限説明してあって
詳しくはコードはあるんで読んでみてねみたいな形になってるんですけど
多分このサンプルアプリケーションの
ララベルベースのAPIプラットフォームを使った実装が
多分今めっちゃ希少性があると思います
どこググってもこんな
一通り全部の機能をララベル版で書いたコード
公開されてるもの多分ないと思います
それすごいですね
ララベルサポートされて間もないんで
ララベルでAPIプラットフォーム使い始めたっていう方って
多分基本的に困ってると思うんですよ
全然資料も情報もないから
確かにおっしゃる通り各章で
ララベルの場合の補足をされてましたけど
コードもちゃんと準備してるんですね
最悪本ちょっと買うのはなっていう方も
GitHubのリポジトリ見て
コード読んで勝手にタダで
学んでいただけるといいかなって思います
そっか公開してあるからね
どなたでも読めますので
そこは素晴らしいですね
いや本当お疲れ様でした
本書の推しポイント：標準仕様の解説
本当に疲れましたね
入校した日はもう
解放されたっていう
寝れるって思いました
寝れる
一通り準備してたやつはいけたと思うんですけど
何か話漏れたところとかあったりしますか
えっと
多分ないか
前後質問
多分大体お話できた気がします
ですね
本のPRというか僕の推しポイントもう一個だけ
はいはいどうぞ
途中で赤瀬さんが
SPA慣れ親しんでないからこの辺のキーワードが
あんまりピンときてないんですよねっていうのを
言っていただいたと思うんですけどその辺のキーワードの解説が
べらぼうに分かりやすく全部書いてあるんで
マジでそこを注目してほしいなって
思っています
JSON-LDとHydraの説明とか
ハイパーメディアAPIって何なのかとか
あとはOOSとOIDC
の説明とかもめちゃめちゃ
ページ使って書いてるんですけど
で見ましたよ認証のとこも
認証認可もすげーちゃんと書いてあって
その辺の説明
日本語でこんなに丁寧に分かりやすく書いてる人
俺しかおらんやろって自分で思ってるんで
そこ本当に読んでほしいですね
ちゃんと書いてあるからな
ビビるよな
認証と認可のところは本当に
一番まさかりが
飛んでくるエリアなんで
本当に裏取りを頑張りました
僕もふわっとした理解しか今までなかったから
そこを飛ばすわけにいかなかったんですよね
それ飛ばしてAPIプラットフォームで
自分で許せなかったんで頑張りました
その辺の姿勢がやっぱね
素晴らしいなと思って
立ち読みでも構わないんで
標準仕様の説明のところを読んで
頑張ったやんって思っていただけると嬉しいです
人柄が伝わる本の作りになってるんで
ぜひ手に取ってほしいですね
エンディング
よろしくお願いします
では第154回はこの辺で締めさせてもらおうと思います
最後にもう一度
Xのハッシュタグについてお知らせです
ハッシュタグはカタカナでつなぎめFMです
投稿をお待ちしています
つなぎめFMではクリエイター向け支援サービスのコーヒーで
皆様からのご支援をお待ちしております
ということで今回のつなぎめFMは達吉さんを迎えして
お話しさせてもらいましたどうもありがとうございました
ありがとうございました
