リソース指向と操作指向のURLに関する最近の思い

弊社のwebAPIはRESTを捨てて操作指向のURLにすることが多いんだけれど、ここのところwebAPIだと結構そういう判断するところが増えてるように感じる(個人の感想です)。

SoEとSoRという話があったけれど、webブラウザ上でもスマートフォン上でもリッチなユーザ体験がモノを言うようになり、SoEなサービスが増えてきていることと操作指向のURLが増えていることは実は無関係ではないのではないか。

というのも、SoRの場合その性質上リソースに対する意識が高まるのに対して、SoEの場合はどちらかと言うとユーザ体験みたいなところに意識が高まる。で、ユーザがサービスを捉えるときのメンタルモデルって、「リソースの操作」とあまり一致しなかったりすると思うんですよ。そうすると、どうしてもリソース指向のURLでやっていくのに無理が出てきて、「じゃあいっそユースケース指向というか操作指向のURLでAPI作ればええんやないの。HTTPステータスも全部200で返してjson body見てね。」みたいな。

というようなことを最近なんとなく考えていました。

参加してきたぜ #nds50

お世話になっている勉強会であるところの長岡 IT開発者 勉強会(NDS)が第50回を迎えるということで、参加してきました。

第50回勉強会(2016/12/10) - 長岡 IT開発者 勉強会(NDS)

わたしとNDS

今は東京で働いているわたしですが、ちょっと前までは新潟県フリーランスとして働いていました。

フリーになる前は東京で会社員をしていたのですが、その頃よく顔を出させていただいていたHachipji.pmが最高で、新潟でも開発者コミュニティをやりたいなあと思っていました。その時に書いた日記を漁ってみたら、なんと2011年!もう5年も前のことなんですね。

d.hatena.ne.jp

完全に本題から外れるのですが、この頃から @hayajo さんに目をつけていた自分すごいなって思う。

で、Niigata.pmの活動をしていくうちに、「NDSっていう開発者コミュニティがあるらしいよ」ってことを聞いて、Niigata.pmと合同の勉強会も開催させてもらったり、ずっとNDSにはお世話になっています。

東京に引っ越してきてからはなかなか忙しく、あまり顔を出せなかったのですが、今回は記念すべき第50回!いくしかない!と思って行ってきたわけです。

自分の発表

わたしは builderscon2016 の再演をさせていただきました。

詳しい内容は弊社のテックブログの方に書いたのでそちらを参照してください。

techblog.reraku.co.jp

聴衆として

印象に残った発表はFileAPIについての発表とGoで作るLinuxコンテナとLoRaの話ですね。

FileAPIについては今まであまりきちんと追えてなくて、おおまかなところが概観できて参考になりました。

Goで作るLinuxコンテナの発表は、本当に素晴らしかった!

コンテナ技術は様々な技術の組み合わせでできているということが非常によく分かるし、単なる外部コマンド実行するだけのプログラムがだんだんコンテナになっていく様は魔法のようでした。高度に発達した魔法の中身を説得力のあるコードで解説している……みたいな感じで本当によかった。Web+DBとかで特集組んでほしい。

LoRaという通信規格についてわたしは全然知らなかったのですが、あんなに小さいものであんなに遠くまで無免許で電波飛ばせるのやばいという感じで、なにか面白いことができそうという予感がばりばりしました。でも具体的には何も思いつかないな!となったの自分の発想力の貧しさが悲しい……

またNDS参加したいっす。

双剣問題について

双剣問題についてはyatteiki.fmを参照してください。

双剣問題に関しては言いたいことがふたつあって、ひとつは小菅さんも言ってたけど、「別に結婚とかしたからといって楽になったり落ち着いたりするわけじゃない、むしろその分剣を振り続けなきゃならない」ってことで、ひとりだったらサボっちゃうところも、だれかと一緒に生活をする、その生活をやっていき続けるためにはサボることができなくなり、むしろ双剣を握り続けるモチベーションになるということがひとつ。

もうひとつが、双剣を振り続けてると「それが当たり前の環境」になっていって、双剣を握り続けるということが特別なことではなくなるということ。というか、特別なことじゃなくならないと双剣は握り続けられない、ということ。

たとえば、カンファレンスで発表をするということ。じつは、初めてカンファレンスで発表する日、わたしは緊張とストレスでトイレで吐いていた。そんな感じで、持ち慣れていない剣を持つためには腕力と強い気持ちが必要になる。けれど、それを続けていくと、いつの間にか周りの友人も「カンファレンスって発表して情報交換することのほうが大事っていうかそれが普通だよね」みたいな感じのひとが増えたりして、「カンファレンスで発表することなんて別に特別なことではない」みたいになっていく。というかそうじゃないと続けられない。毎回トイレで吐いてたらしんじゃうよ!

あるいは、OSSへのコントリビューション。わたし自身はこのあたりはかなり弱いんだけど、OSSにコントリビューションを続けてる人たちって「OSSで一発当てるぞ!」みたいな感じではなくて、あたりまえのことみたいに淡々とコミットを続けているように見える。

そんな感じで、双剣問題を別の視点から見ると、「双剣を持ち続けることをあたりまえのことに変えられるかどうか」というところが結構大きなポイントなのではないかと思う。そして、これはわたしの基本哲学でもあるんだけど、人生9割運と縁なので、じつはそうなれるかどうかは9割運と縁で決まると思う。残りの1割のところに、強い気持ちが必要なのかなと思う。

やっていく気持ちはとても大切なものだし尊いものだけれど、気持ちが途切れたら終わってしまう、という状況はあまりに脆弱だ。だから、強い気持ちがあるうちに、その気持ちを使って、気持ちに頼らずやっていける状況を作る、というのが双剣問題に対する1つの解決策なのかな、というのが所感です。

RDBMSが強すぎる件

以前、「RDBMSを採用すると、無料で外部キー制約とかチェック制約とかトランザクションが付いてきてオトク!!!」という発言をしたことがあって、その考えは今もあまり変わっていない。

RDBMSは単なる便利な箱じゃなくて、データの整合性を守るための仕組みがたくさん備わっている。もちろん、これらの仕組みは「タダ」で使えるわけではなく、データモデリングを学んだり、データ構造を学んだりという「投資」の結果うまく使えるようになるものだけれど。

ところで問題(?)は、RDBMSは強すぎる、ということです。

たとえば、トランザクションの話。「本質的にはトランザクション整合性である必要がなく、遅延してあとから整合性が取れてればよいような処理(つまり、結果整合性でよいような処理)」というのは、意外と多い。

多くの開発の現場では、トランザクション整合性が必要とされるか結果整合性でよいのかについてあまり考えず、「トランザクションはっとけば整合性が保たれていいよね」という感じでトランザクションが使われていることが多いのではないか。極端なところでは、web appの全てのリクエストの開始時にトランザクションを開始して、レスポンスを返すときにトランザクションをcommit(あるいはabortする)というような「フレームワーク」をオレオレで作っていたりするのではないか。

しかしほんらい、並行性を考えたら、トランザクションのような排他性のある制御は、可能な限り細かい粒度にしておくべきだ。めちゃめちゃでかいメソッドがsyncronizedで囲まれてたらみなさん怒るでしょ。

そう考えると、RDMBSの提供してくれるトランザクションは「ほんらいは」トランザクション整合性が必要なところでのみ用いるべきなのではないか。結果整合性で良いようなところでは、ほんとうのトランザクション境界のみでトランザクション整合性だけを保ち、あとはリトライとかいろいろ頑張って結果整合性を保つほうが良いありかたなのではないか。そうすれば並行性も上がる。

とはいえ、わたしたちの現実はそんなに単純に技術的な正しさ(とは?)だけで決まるわけではない。チームメンバーのスキルだとか、ビジネス上どれだけ堅牢である必要があるかとか、あるいはどれだけソフトウェアの速度が求められるのか、どれくらいのスケーラビリティを求められるのか、そういった諸々の要素によって「このソフトウェアはどのように設計されるべきなのか」は決まる。

なので、結論としては、トランザクション整合性であるべきなのか結果整合性で良いのかちゃんと判断した上で、「今回はほんらいは結果整合性でいいところなんだけど、楽するためにRDBMSトランザクションに頼っちゃおっか」とか「いやーRDBMSトランザクションに頼るほうが楽なんだけど、かなりシビアに更新がかかりまくるところだから、RDBMSにはトランザクション整合性だけ保証してもらって、ほかのところはワーカーに任せて結果整合性を取ろう」とか、そういうことを判断できるようになっておく、というのがわれわれ(誰?)に求められているのではないでしょうか。

正しい意見

日記

金曜は仕事で疲れてしまって例の本を進めることができなかった。

今日(もう日付が変わっているけど、寝るまでが「今日」)は進めようと思ったのだけれど、とにかく精神が厳しい感じになっていてこの状態で進めるのはあまりよろしくないという気がして開いていない。

誰かとの関係において、自分がなにか悪いことをしてしまったと思うとき、相手やその周囲に対してこちらからなにかを求めることは「逆切れ」のようで間違えているようにも感じる。が、一方で「"罪人"はなにも主張してはいけないのだろうか、"罪人"に対してならばなにをしてもいいというのだろうか」というような気持ちも同時に持ってしまい、精神的に身動きがうまくとれずにいる。

ここからさきは追記。

寝ようと思ってたんだけどうまく眠れなくて、結局本を進めた。

「XXできない」というのを5つ書き出して、そのあとそれを「XXしない」あるいは「XXしようとしない」というように書き換え、その結果自分の認知にどのような変化があったかを書く、という課題があった。

わたしは「C++が書けない」とかのほかに、「プライドを持ってる部分の弱みを見せられない」ということを書いたのだけれど、これを「プライドを持ってる部分の弱みを見せようとしない」と書き換えたことで、「あ、これは自分の"能力"や"性質"の問題だと思って諦めていたところがあるけど、自分がそうしようとしなかっただけなのだな……」という自己嫌悪と、同時に「となると、気をつけて細かく行動を変えることで改善できるかもしれない」という希望が同時に湧いてきて、しかしここでかなりキツくなってきたので今日はここまで。

日記 2016/8/4

しばらく、日記を意識的に書いてみようと思っている。

ちょっと訳あって「自分自身がどういう人間でどういうことを感じていてどういうことを考えているのか」ときちんと向き合ってみる必要があるなあということになり、「自己理解ワークブック」というものを始めてみた。

Amazon CAPTCHA

学生のころ、というか文学部で、あるいは自室の暗い部屋でしこしこと哲学書読んだり小説読んだり音楽聴いたりしていた頃は、少しでも「自己啓発」の匂いがするようなものに対してかなり強いアレルギー反応があったので、こういう本を読むことは考えられなかったように思う(この本が自己啓発系である、ということを言いたいわけではなくて、「自分が」そこに何を感じるかというむしろ自分側の問題)。でも、それで結局「現実世界に生きてない」みたいな感じになってる(それはプログラマになってからも同じなんだけど)ままだと、現実を生きて行くのに対して問題がある。

今も構造の面白さとかそういうものに興味が強くて、だから自意識べったり音楽とかそういうものよりも、リズムの構造だとかコード進行だとか、あるいはメロディと歌詞の相互作用だとかそういうことを考えるのがとても好きだ。あるいは、あるビジネス要請があるときに、その要請に適切なプログラムのアーキテクチャはどんなものだろう、というのを考えるのがとても好きだ。だけど、そればっかりやってたら、現実の問題に関してあまりに無力すぎる。

という感じで自分は現実が本当に苦手で、だから「自分は自分のことをきちんと理解していないせいで現実に問題を引き起こしている」ということさえちゃんと理解していなかったのだけれど、そのあたりについてずっと妻が指摘をしてくれていた。が、「なるほどなあ」と思う程度でスルーし続けてしまっていた。ようやく「なるほどなあ」ではあかんぞ、となったとき問題になったのが、現実が苦手すぎて「じゃあどうすればいいんだろう」がわからないレベルであるということだった。プログラミングを始めたばかりの頃、「なにかここに問題があることはわかるんだけどなんて単語でググったらいいかわからない」とかそういう状況を経験したことのあるプログラマは多いと思うのだけれど、わたしは「自分のことをちゃんと知る」ということに対して今そんな感じで、「正直どっから手をつけていいのか」という感じ。そういう背景があり、まずはこの本から始めてみようという形で購入に至った。

実際に始めてみると、文学部時代のただひねくれていただけの自分だったら多分スッと入ってこなかったと思うのだけれど、必要性を感じて読むとこれは一種のハックとしてものすごく優れている(そりゃ膨大な先人たちの努力によってなされた研究が元にあるのだから、考えてみたら当たり前のことなのだけれど……)と感じた。実際、最初のほうのワークを少しやってみたところ、びっくりするレベルで自分の気づいていなかった自分の感情などを客観視することになり、びびっている。まだスライムにもてこずるレベルの自分にとって、この本と向き合うのは結構タフなことで、あと前書きで「ワークをやるときは事前と事後に十分な心の休養を取ってくれ」と書かれており、ニャオスではあるけれど今日はここで止めておこうと思ってストップしている。

もしかしたら、意識的に日記を書こう、と思い立ったのは、自分が学生時代文章を書くことで自分自身の気持ちを楽にしていた部分があったという経験から来た一種の防衛反応なのかもしれない。

プログラマとコミュニティ あるいは SD8月号に記事を書かせてもらいました

表題にあるとおり、Software Design8月号の特集記事を書かせていただきました。GitHub入門的な記事です。

今書店で売ってる号は7月号ですので、今売ってるやつには載ってません(でももちろん買ってくださってもいいんですよ?)。発売日は7/18ですので、その後書店で購入したり、Amazonなどでお求めください。

www.amazon.co.jp

今年に入ってから、web+DB Pressの91,92号、SD8月号と、技術評論社さんの雑誌に記事を書かせていただく機会を立て続けにいただけて、ほんとうにありがたい限りです。

ところで、web+DB vol. 91の記事はYAPC::Asiaでの発表がきっかけでチャンスをいただいたのでした。92はPerlコミュニティつながりで頂いたお話でした。今回の記事に関しては、「Gitをはじめからていねいに」というドキュメントをGitHub上で公開しているのを目にとめていただいてお声がけいただくという経緯でした。

立て続けにこういう機会をいただき、拙いながらもアウトプットを続けていると、目にとめてくださるひとたちはいるのだなぁ、続けるというのは大事だなあというのを実感しています。ありがたいことです。

さて、このあとは壮大な蛇足です。

アウトプットのモチベーションの話

ところで、話が急に変わるようですが、わたしは文学部出身プログラマです。学生時代にきちんとコンピュータサイエンスを学んだことはなく、プログラミングは独学でやってきている人間です(そのため、きちんとしたコンピュータサイエンスのバックグラウンドに支えられた「基礎体力」のある方々に対するコンプレックスが結構強くあるのですが、それはまた別の話なのでおいておきます)。

「独学で」と言いましたが、それは決して「独力で」学ぶことはできないものです。わたしが主戦場としているいわゆるweb系は特にそうだと思うのですが、インターネットには、プログラマコミュニティが書き残してくれた膨大な数の知見が積み重なっています。もちろん、書籍から学ぶことも多かったのですが、それと同じくらい、インターネット上にアーカイブされた素晴らしい情報たちに、わたしはプログラマとして育てられてきましたし、現在も育てられています。

中でも、勉強会のスライドや発表には質の高いものが多いと感じます。これは、プログラマコミュニティがオープンにしてきてくれた、プログラマコミュニティの財産だと感じています。この財産を分けてもらうことで、独力ではできない独学が可能になっているとわたしは強く感じています。

さらに、インターネット上の情報だけではなく、なまのコミュニケーションも、わたしをとても育ててくれています。特に、Hachioji.pmで出会った方々、Niigata.pmで出会った方々、NDSで出会った方々、@9mさんを通じて知り合った方々とは、心理的に近い位置で技術的な相談をしたりされたりする中で、互いに切磋琢磨することができていて、この関係もまたわたしをプログラマとして現在進行形で育て続けてくれています。(この前のヤパチーでもshiba_yuさんやninjinkunさんとコミュニケーションできたことは大きな喜びでした!)

実は、わたしが技術的なアウトプットするモチベーションは、わたしを育ててくれているそんなコミュニティに対する恩返しがしたい、という気持ちが支えています。まあ、とはいえぶっちゃけ、そんなきれいごとだけじゃなくて、承認欲求にドライブされてる部分もめちゃめちゃ多くあるんですけど。でも、それだけではやっぱりやっていけないんですよね。クソリプ的な反応に心折れるし。わたしは、「ほんとうに多くのものをコミュニティや友人たちから受け取っているわたしが、自分の力でできることってなんだろう」という気持ちがなければ継続したアウトプットはできません。

アウトプットをしてたらいいことがあった

で、そうやってアウトプットを続けていたら、いいことがたくさんわたしに降りかかりました。

会社を超えて、プログラマ仲間がたくさんできました。その仲間たちは力強くて、わたしの知らないことをたくさん知っていて、しかもわたしが相談すると惜しみなくその知恵を貸してくれます。

転職や就職ができました。「コネ」ってわけではないけれど、アウトプットをたくさんした結果、「このひとはこれこれこういうことが得意でこういうことはあんまり得意ではないんだな」というのを分かった上で声をかけてくれるので、お互いにミスマッチをあまり心配せずに転職活動や就職活動を行うことができ、これはかなりありがたいことです。

そして、最初の話にようやくつながるのですが、雑誌の記事を書かないか、とお声がけいただくことができました。以前このブログにも書いたことがありますが、昔の夢が思わぬところでかなったりもしました。ありがたい話です。

でも、こんなの全部副次的なものです(とはいえ実際、かなり大きなメリットも享受しているのは無視できない事実だけれど、まあ、気持ちの問題として)。わたしにとっていちばん大きな喜びは、コミュニティから得た財産を、新しいだれかに渡すチャンスをたくさん得られるようになったことです。わたしの大好きな小沢健二の楽曲のワンフレーズに「愛すべき生まれて育ってくサークル 君や僕を繋いでる緩やかな止まらない法則」というのがありますが、まさにその法則のほんの一部にでも自分がなれているという実感こそが、わたしがアウトプットを経て得られているいちばんの果実です。

もし燻ってるひとがいたら、ぜひ一歩を踏み出してみたらいいんじゃないかという話

ようやくこの文章の結論にたどり着きました。だから、もし今この文章を読んでくれてるあなたが、プログラミングが好きで、なおかつアウトプットすることに興味があったりコミュニティに興味があるんだけど、それでもなんか一歩が踏み出せない、なんて状態で悶々としてるなら(そうじゃないならごめんなさい)、心配せずにその一歩を踏み出してみたらいいと思います。

もちろん、わたしはかなり運と縁に恵まれた例であるということは否定できません。なので、生存バイアス的なあれがそれしてる部分もあると思います。でも、プログラミングしてたら、みんな多かれ少なかれコミュニティから何かをもらってるんじゃないでしょうか。だったら、コミュニティからなにかをもらい、自分も誰かになにかを与えるというサークルの中に、一歩踏み込んでみるのは、単なるメリット云々を超えた意味があるとわたしは思います。

ブログを書く、というのもひとつの方法ですが、勉強会に登壇して仲間を見つけるという、ちょっと勇気が必要だけど大きな一歩を、この文章を読んだだれかが踏み出してくれて、上述のようなサークルがまたひとつどこかで産まれて育っていくようなことがあったら、わたしはとても嬉しく思います。

なんか大した実績があるわけでもなければロックスターでもないのに偉そうな言い方になってしまったけれど、「そういうの興味ねーよ」とか「お前に言われるようなことじゃねーよ」ってなってたらごめんなさい。エモいおっさんの戯言だと思って聞きながしてブコメあたりにでも「黙ってコードを書けよハゲ」「で、誰?」とでも書き残して叱責しておくれ。