Masashi Sato TECH DRIVE さんはインスタンス mstdn.techdrive.top のユーザーです。アカウントさえ持っていればフォローしたり会話したりできます。もしお持ちでないなら こちら からサインアップできます。
Bb7567a9f13cad51

Masashi Sato TECH DRIVE @ms2sato

ruby だってよ。
別に他の言語より特別使いやすいとか思わないけどもー。

hello-new-world.mybluemix.net/

でも、なにかコンテキストを絞って割り切るんだろうなと思ってたりする。

JSはawait async で情報与えている感じだから、その感覚でもう一歩進めるといいなーと思ってたんだけどね。難しい感じだったよ。

パラダイムまで一気に変えてしまうのは発明としては良いのだけれど、今の人たちに使ってって言いにくいし。うちのメンバーも嫌がりそう。

同期と非同期を共通の書き方でうまくいかんもんかなーとか思ってたんだけど、難しいね。

全部非同期の書き方にすれば良いんだけど冗長になってしまう。同期の書き方だと途中で処理が分岐することを示せないってなるのか。また考えよう。

@alg0002 日中ちょっと調子悪かったぽいです。対応できてなかったのですがもう落ち着いた模様。報告ありがとうございましたー。

自分だとローカルにいるのはあくまでリモートの影武者(スタブ)として考えるけど、色々な考え方あるよな、とログを拝見してて思ったりするなど。

自分の考え方はどっちかって言うと過去に縛られているので新鮮。

ううーん。そのアプローチならまずSOAPっぽいのを検討する方が幸せになれるかも。

システムが起動するタイミングでローカル・リモートのそれぞれで必要な型がわかっている状態を作ることを今は避けられない気がするよー(そこにチャレンジするのもありなんだけど、かなり過酷)。

SOAP時代は公開オブジェクトを事前に決めといて、そのオブジェクトが関連する型をwsdlへ全部事前にジェネレートしとく感じ。知ってるかもだけど。

変な話、私の望みの一つは、開発のスタンダードが一回ひっくり返って欲しいんだろうね。

自分の考えを表明しとくと

- Railsは初期開発の効率に寄せ過ぎていて、結局長く使っていく場合にしわ寄せが大きくなりがち。別に初動がもう少し遅くても良いから変化に柔軟にできないものか。

- RPCで「『どこが遅くなるか』がわからないこと」を目指す必要はないと思う。「どこを遅くしても良いか」を明示的に与えられれば良いはず。それがアノテートなのかアスペクトなのかDIなのかは実装の話。

- 今のタイミングは歴史が分岐するところだと考えているので、私は私の行って欲しい方向へ押す。みんな好きに押せば良いと思う。経験上、なにもやらないのがつまらないタイミングだと思う(公式に出すかとかOSSなのかとかそういう問題じゃなくて何かやる価値があると認識してる)。

誤解を与えてしまった様子ですが、私は「あらゆる」に対応したいというコンテキストで語ってはいませんよー。

別の切り口で、今実現していない自分の理想を追うことは自由で、私はそういう気持ちに素直に生きていたい。
それに誰も賛同しなくても私はそうやって勝手に生きていき、勝手に死ぬんだと思います。

現行のオブジェクトで物事を考える切り口でいくと、RPCでシステムを考えて「通信がどこにあるか」を設計から隠匿するのはありと思います。

それってなんてEJB?って聞かれそうですが、このアプローチはもう一度考える価値はあるかなーと。

Expressで作る時にコントローラ的なオブジェクトからJSのコードを自動生成して、ブラウザからRPCできるようなスタブを作ってたりしましたが、この感じ結構好きなんすよね。
「Restfulとか別にプロトコルの仕様だろ」くらいまで落とせたら嬉しい。そしてロジックの動く場所を別のステージに移動したい(ブラウザなの?サーバーなの?から解放されたい)。

5年前こんなの書いてた。懐かしい。
github.com/ms2sato/Restrant.js

Railsがものすごく割り切っていて、私のようなタイプの人間がこだわってしまうところをあえて雑に切っているのは確かに革命的に斬新だったと思っています。

ヒットの理由が本題ではないのですが、Railsが広く受け入れられたのは「顧客になるべく早く価値を与える点に特化した開発効率の最大化」を目指している、という点かと。

自分とこも事業としてはRailsを中心に扱っていますが(言語やフレームワークとしては技術者の私は好きじゃないけど、外部環境に依存する経営判断です)、規模の大きくなったRailsサービスのひどい有様も見ています。「Railからのうまい外れ方」を理解していない人がモリモリ機能追加しても、保守しにくいものが誕生するだけなんですよね。

その意味でRailsはWEBのシステムをよりよく作れるような土壌にはまだ到達できていないと考えています。

興味深いなー。

多分私たちって
「プログラミング言語が先にある」
という前提で考えてしまっていて、例えば「WEBのシステムを作る」
というような目的からスタートする思考を持ちにくくなっている気がします。

ひょっとするともっと開発や設計しやすい言語なり仕組みなりが考えられるかもしれないなと感じたりしてます。

最近Webassemblyを見ていると言語の枠がかなり自由になりそうなので、何かできないかなと思ったりしてます。

私は「ビジョンを持てる」ということが最大のヒトの価値だと思っているから、様々な意味の正解と思うものを機械から提供されて、それを選ぶだけになれたら、それはそれで幸せになれそう。

「正しさ」を論じる時には「基準」が必要で「基準」は意思の中から生まれると思ってます。つまり人が正しさを決めるはず。

自分だと大抵時間の制約がある中で脳内で直感による枝刈りを行って結論することあるけど、それがもしも網羅的なデータと共に何か提示されると、今とは違う決定ができる気がしているんだよね。有能な分析屋さんが隣にいる感じ?そういう意味ではただデータ集めてくるコンサルみたいな人はいらなくなるかもだけど。

その時機械がどういう想定でその結果を出したかまで出してくれると良いな。

自分はあんまり文章を上手い下手とかで考えてなかったりするから、こういうとこでは特に言いたいことアウトプットできれば良いと思うよ。空リプし合ってるだけだしw

何か共通の議論の目標を達成しようと思ったりすると、具体性だったり相手の心に届く何かが必要になるから大変な時もあるよね。

チームって単純に頭数揃えれば進捗二倍になるとかそういう考え方ではないですものね。

仕事の枠組み作る側がある程度そのことを理解して場を準備できると違うのでしょうが、なかなかそう都合良くことが運ばないのが現実な感じはあります。

成長を目的にすると速度は確実に犠牲になるので、そのあたりも。いい人ほど苦労する構図になりがち。

自分が書かずにレビュアー中心になった時「どこで割り切るか」が課題になることが多いです。

自分が想像する理想のコードまでレビューで鍛え上げていたら時間が足らないので、結局どこかで
「今日はこれくらいで勘弁してやる」
的な考え方が必要になると思うんですよね。

理想を実現できていない事実がストレスにもなるみたいで、自分の理想を吐き出したくなるのが禁断症状の正体では無いかと想像しています。