エンジニアの集合知をノードグラフで図解するSNSサイトを作った。「ノード・ノード・ノード（デスクトップ版）」
サイトコンセプトはエンジニアの集合知をノードグラフにして図解するSNS。
サイト名は「node-node-node（ノード ノード ノード）」。デスクトップ版のみ。
エンジニアの集合知をノードグラフで図解するSNS。
「node-node-node（ノード ノード ノード）」
https://www.node-node-node.com/
考えたのは「新しい技術を学ぶ時に各技術要素の関係が分かりにくい。ググればピンポイントで内容が分かるが各技術の関係は不明なまま。そこを集合知を使ってシステムが自動的に図に示してしてくれればいいのに」と。
トップページはこれ。
親ノードについた子ノードはパラっと開いて、グリグリとドラッグできる訳でして、こうして階層構造の技術リンクをマッピングしていけば理解しやすいかな、と。
例えば私の専門はバックエンドなのでインフラやバックエンドの処理はそれなりに把握しているが、JavaScriptをはじめとするフロントエンドの知識はあまり無い。今回のnode-node-nodeのフロントエンドはReact+Reduxで作っていて、その技術情報を手探りで集めてコードを書いた。するとフロントエンドの専門家なら常識でも、専門外の人からは謎な用語がポンポン出て来る。
npm, Babel, webpack, ES2015, Enzyme、とか。
これらの用語についてはググればヒットするし、一応は分かる。仮にnpmがナニなのか知らなかったとしても、ググれば一瞬で分かる。それでも本当に分からないのはこれらの技術要素の関係。各々の技術については分かったつもりになっても、npmとES2015はどんな関係なのか。それぞれ把握しておかなければならないのか、その技術の関連性はずごくあるのか、またはまったく無いのか、などだ。
ここでは誰もがよく知る技術用語だけをピックアップしたので「そんなもん分かるだろ」と思われたかもしれないが、以下のサッカー戦術用語の場合はどうだろう？
トータルフットボール、ゼロトップ、ミケルス、オフザボール、ポゼッションサッカー、ゲーゲンプレス、４−４−２、ゾーンプレス、アリーゴ・サッキ
これらの用語の相互関係が頭の中に描ける人はある程度サッカーに詳しい人だろう。サッカーに詳しくない人でも、用語をググれば分かる。でも各用語が分かったとしても現在のサッカーシーンの主流戦術や、今までの歴史を俯瞰した概念はなかなか得られない。
そこは「各要素の関係図」を示してもらえれば分かるし、初学者が学ぶ際に役に立つ、というのが本サービスのコンセプト。
これはRailsに必要な技術をマインドマップに示した図。分かりやすいが、そもそもこれを作ったのはきっとRailsのエキスパート。
こういうのはひとりのエキスパートに頼るよりも、ネット文化に添って集合知を結集して自動作成されるようにしたかった。「人気のあるノード＝有用なノード」として目立つ場所に出てくるようにした。
例えばJavaScriptはこんな感じ。
そもそもJavaScriptの初学者はフレームワークとしてReactやらAngularJSがあって、それらがJavaScriptである、ということから理解する必要がある。で、このノードのつながりを見れば一目瞭然かな、と。
早くたくさんの人に使っていただいて、もっといろんなノードが付いて欲しいなーとか思ったりしている。
モバイル版を無視して、デスクトップ版しか出さないのはいかがなものか、というご指摘もあるかもしれないが、基本的にPCでコードを書くエンジニアに向けたサービスなのでご了承ください。とにかく公開してその後のサービスの使われ方を見て変更をかけていくつもり。
ご自身が書いた技術記事が有用だと思う方や、他の人が書いた役に立つ技術記事をご存知の方は、ぜひその記事リンクを貼ったノードを作っていただけますでしょうか。
原理的にはどこまでもスクロールできるほぼ無限大に大きなノードグラフができる。
いつの日か考えもしなかったような巨大な集合知のノードグラフがnode-node-nodeにできていることを願って公開した。
使った技術
個人的にはGraphQLがこのサービス内容に対しては最適だったな、と。
料金はドメイン登録料だけで他は無料で済ませることができた。GCPの永年無料枠サイコー。
Front-end
- React
- Redux
Back-end
- Ruby 2.5
- Rails
- GraphQL
Infra
- Google Cloud Platform
- heroku
- MongoDB
- Redis
- Cloud flare
- SendGrid
- NewRelic
エンジニアの集合知をノードグラフにして図解するSNS。
「node-node-node（ノード ノード ノード）」
https://www.node-node-node.com/
良くても悪くても賞賛でも罵倒でもなにかコメントか反応いただければ嬉しいです。反応ゼロが一番辛い。。。
YAGNIはソフトウェア実装の原則。直訳は「そんなモン要らんって！」
YAGNI (You Ain't Gonna Need It) 直訳は「そんなモン要らんって！」
YAGNIの原則は「機能は実際に必要となるまでは追加しないのがよい」とすること。後で使うだろうという予測の元に作っても、実際に使われるのはほんの一部。ソフトウェア実装において「予期しない変更」は常についてまわり、できるだけ設計をシンプルにするべき。現実の問題に集中して余計なモノを足さない。
それがヤーグニ。
会話の中での使い方は「それってヤグニだろ」とか「なんでって？だってヤグニだし」無駄にカッコつけて「そこはですね、単一責任の原則に反してまして。。。」なんて言うよりよほど親しみがあっていい言葉だと思う。
日本の中学校の先生からマルをもらえる英語に直すと「You are not going to need it.」実際に英語圏の職場で話す場合は「よーえいん、がな、にーでぃTっ」
YAGNI物語
エンジニア歴５年目に到達したA君は持ち前の技術を活かすべく海外転職を狙っていました。見事にロンドンのIT企業への転職が決まり、意気揚々とイギリスにやってきました。
慣れない英語を駆使しながらも、自己紹介を終えて自分のデスクにつきました。するとA君とチームを組むことになった金髪美女プロジェクトマネージャーのB子が話があるので会議室に来て、と言いました。２人っきりで小さな会議室に入るとB子の色気と強烈な香水の香り、UK訛りの英語に悩殺されそうでした。そうした中でなんとか理解したのは以下のこと。
- 新しいウェブサービスのプロトタイプを作って欲しいの（ハート）
- それは大企業とのコラボプロジェクトなの（ハート）
- アタシが相手企業の重役達にプロトタイプを持ってプレゼンしなくちゃいけないの（ハート）
A君は他にも色々はっきりしなくて聞きたいことはあったけど、英語もいまいち分からないし、これ以上会話を続けるとB子の短いスカートから伸びる太ももと乳の谷間に悩殺されるので「分かりました」といって会議を終了しました。
張り切っているA君はまずはReactでプロトタイプを構築することにしました。ReactのState管理には当然Reduxとしました。クライアントサイドだけでなく、ちょっとしたサーバーサイドの機能も要るだろうな、と考えたA君はRailsサーバーも立てました。するとAPIが必要になります。そこはRESTfulではなく、流行りのGraphQLにしました。かっちょいいー。こんな素敵なプロトタイプを見せたらB子とニャンニャンできるかも、と想像してほくそ笑んでいました。
セクシー金髪美女のB子がA君に聞きました。「プロトタイプできた。見せてくれる？」
A君が誇りを持って見せた、プロトタイプをざっと確認したB子はトップページのスクリーンショットを取って、その画像を自分のプレゼン資料に貼り付けて言いました。「ありがと」
その日の晩、A君がロンドンのパブでひとりで飲んでいるとB子が同じ会社のイケメンマネージャーと一緒にいました。彼らはA君に気付いていません。彼らがA君の名前を言っているのが聞こえてきたので、気付かれないようにそっと聞き耳を立てました。
イケメン「最近入ったA君、どうだった？」
B子「意欲はあるんだけど、作業が超遅いの。単にHTMLでプロトタイプのトップページ作るだけなのに、なんであんなに遅いんだろ。ああいうのに限ってベッドの上ではやたら早いのよね」
イケメン「あんなのじゃなくてオレがかわいがってあげるよ」
B子「ニャンニャン」
A君はがんばってムダに実装したReact+Redux+Rails+GraphQLを思って、ひとしれず泣きました。
ヤーグニ！おわり。
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
「『イチから作り変えてまえ！』は絶対にやってはいけないこと」というJoel Spolskyの記事が示唆に富んでいて面白い
Joel Spolskyという人は有名どころではスタックオーバーフローを作った人で、他にもTrelloとかも創業しつつ、以前はマイクロソフトでプログラムマネージャーとしてエクセルを設計したり、面白い文章のブログ書いたりと、多才でユニークなエンジニア。
その人が書いた「エンジニアが絶対にやってはいけないこと」という２０００年に書いた記事は今でも人気。先日、同僚がSlackで「この記事面白いよ」と貼ってきて「あーそういえばこれ以前にも読んだな」と思いつつ再読するとやっぱり示唆に富んだいい記事だったのでここで紹介することにした。
話は昔あったネットスケープという名のウェブブラウザのリリースから始まる。かつて９０年代はブラウザといえば、インターネットエクスプローラーとネットスケープの２つがシェアをほぼ独占していた。インターネットエクスプローラーの勢いが増す中でネットスケープは新バージョンのリリースを急いでいた。ところがV6のリリースは最後のリリースから３年とめちゃくちゃに時間がかかって、その間に急激にシェアを落としてしまった。なんとかV6をリリースしてもその質も内容も伴わずシェアを奪い返すことなく消滅してしまった。
つまりネットスケープ社はたくさんのソフトウェア会社が共通して犯すある最悪なミスを自ら招いてしまったのだ、と。それは
ソフトウェアをイチから作り変えること
以前まであったコードを全部捨てて、３年かけてまったく新しいソフトウェアに書き換えて、ダメだなー、と。
エンジニアが既存のコードを眺めて「このクソコードが！」とか「こんな汚いコードとは付き合ってられねーわ」と不平を漏らしているのはどこでも見かける。私も含めてついつい考えてしまうのが、「この既存コードを全部窓から投げ捨てて、イチから作り直したらどんなに気持ちいいかなー」だ。
こうして既存のコードをこき下ろす原因についてSpolskyがこう解説する。
The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:
It’s harder to read code than to write it.
そうして既存コードをこき下ろすのは「コードは書くより読む方が大変」だからだ、と。
もっとちゃんと読んで、例え巨大な行数のコードがひとつのクラスの中にあったとしても、先人達がそうしてしまうまでに何があったかを考えめぐらしてみましょう、と。もちろんひとつのクラスの中に何行もあるコードは悪い例と認めつつも、そこに至るまでのデバッグにつぐデバッグと修正が蓄積されている訳で、捨てるのはもったいない。捨てるのは気持ちいいかもしれないが、まっさらから作るのが必ずしも前回を上回る品質になる保証は無い。まっさらから作ったところで十中八九同じ種類かまた新しいバグを生み出すののは確実。
それよりもちゃんとコード読んで適切なリファクタリングして、パフォーマンスチューニングするのが最適解なんですよ、と。
全部翻訳するのは面倒だから、恐ろしく要約してしまった。こうして私が結論だけ書いても「は？だから？」となったかもしれない。できれば原文を読んでいただければSpolsky氏のブログ文章の面白さを感じていただけると思われる。
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
