  |
はてなキーワード: アーキテクチャとは
よくプログラマーは問題が起こったらシステムで対処しろよ、人間はエラーするものだから頼りにするなと言う。
包丁は凶器かもしれないが使う人が問題で、システム側に問題ないと言い続けている。本当か？
毎日のTwitterの問題に、人の考えを変えさせなければならないとか、言動の場を与えるなとか、人に頼った解決策がほとんどだ。
20年前に書かれたなぜ動くか分からないコードで動いている自社製の制御ボードとそれが組み込まれた工場とかのシステムが、ある日突然止まったり、さすがに作り替えないともたないからって毎日毎日暗闇の中で絡まった電源コードをイジって解き続けるようなことを強いられる
新しいアーキテクチャで作ればどうということはないのに、オーバー50の古参や社長が作ったスパゲティのスパゲティのためのスパゲティを食って生きる会社だからスパゲティこそが本質であり価値であり飯のタネだから抜本的に置き換えられることはない
ただ会社に入って需要のままにAS ISなスパゲティコードを書いて何とか動かせただけなのに、ややこしくて難解でバグも多くて時々止まる遅いシステムを作ったバカが何故か古参で偉そうにしていてそいつの靴を舐めるくらいじゃないとスパゲティを解く社内限定の魔法の呪文は教えてもらえず会社に居られない
勉強になったと書いてしまったが、もう一度読み直すと以下の文章。
しかし、コンピューターのCPUとメモリー間、トランジスターの小クラスタ間などの“長い”距離では、電子ではなく光子を使用することでエネルギー消費量もシステムの発熱量も非常に少なくしながら、計算速度を向上させることができる。
もちろん、一般的な用途にも応用できる可能性がある。(中略)「ここで実証できたことは、チップスケールの電子・光子システム時代の幕開けを示すものであり、コンピューティングシステムのアーキテクチャを変革し、ネットワークインフラからデータセンター、スーパーコンピューターまで、より強力なコンピューターを実現する可能性を示唆するものです」と、研究者たちは論文に記している。
なのでCPU見据えてるよ。
Railsで業務システムを作ると死ぬ。というかスタートアップの文脈以外ではRailsを使わない方がいい。
Railsって「他の何を差し置いても初速が重要！」「成功してから考える！」スタートアップにとっては最適だと思う。
でも要件が複雑で長期的に運用、保守する前提のシステムを作るのには全く向いてないんだよね。
Railsを選択した時点でMVCかつモデルにいろいろ押し込んだ密結合なアーキテクチャを採用していて、これが規模の大きく複雑なシステムにマッチしないってことをもう少し意識した方がいい。
「技術的負債」なんて聞き心地の良い言葉で済まされるけど、要は設計不備でしょ。
もちろん要件を鑑みて意識的にこういうアーキテクチャを採用するなら何も問題ない。
作り散らかす人にとってはどうでもいいのかもしれないけど。
とにかく、向いていないことにRailsを使うと当たり前のようにしんどい。
信者は絶賛するのはいいけど、向き不向きがあるってことも同時に伝えてくれたらうれしい。
負債を返すのはおそらく作ったのとは別の人になるので。
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
202あとで/2672users ブログ: 「平常に戻る」ことはない - イギリスNESTA(科学技術芸術国家基金)より | okuranagaimo.blogspot.com
144あとで/741users 電子情報学特論：Chromiumのアーキテクチャを解き明かす - Google スライド
142あとで/2292users 0403「NY感染体験記（未確定）」｜qanta｜note
132あとで/1569users イラスト図解！ これが新型コロナウイルス（SARS-CoV-2）だ｜ぬまがさワタリ｜note
124あとで/1229users [PDF]COVID-19への対策の概念 | 東北大学大学院医学系研究科・押谷仁
116あとで/578users API 設計ガイド | Cloud API | Google Cloud
116あとで/1677users 緊急事態宣言から3週間 流行状況はどう変わったか(忽那賢志) - 個人 - Yahoo!ニュース
114あとで/911users 米ジャズプレーヤーが解き明かす“J-POP”の正体、音楽的アイデンティティ（KAI-YOU Premium）
114あとで/609users Google Cloud Platform のトレーニングコース、ハンズオンを 1 か月間無料で提供 | Google Cloud Blog
111あとで/506users ドキュメント作成スキル向上を目指す人向けおすすめ記事まとめ - Qiita
106あとで/970users 月例マグコミマンガ大賞2020 - マッグガーデン / 2月期 入選「賢者の教室」朝野茶柱 | MAGCOMI
104あとで/668users 論文の読み方 / How to survey - Speaker Deck
103あとで/617users SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち？〜 - Qiita
102あとで/452users Git / GitHub を使用したチーム開発時のガイドラインを制定しました | Developers.IO
102あとで/1032users 「日本人は幻想を抱く」新型コロナと闘うウイルス学者の『情熱大陸』のドキュメントがすごい！（追記あり）(水島宏明) - 個人 - Yahoo!ニュース
100あとで/549users Mr. ベイエリア on Twitter: "自分は機械学習を学びたい全ての人類に（CourseraのAndrew Ngのコースをやった後に）Andrew NgのStanfordのCS229の講義を見ることをオススメしてるんですけど、その講義の2018年度バージョンが公開され… https://t.co/OUokFft3ea"
97あとで/600users 自宅で学ぼう！AWS 初学者向けの勉強方法 6ステップ！ | Amazon Web Services ブログ
96あとで/435users 文字コード再入門 ─ Unicodeでのサロゲートペア、結合文字、正規化、書記素クラスタを理解しよう！ - エンジニアHub｜若手Webエンジニアのキャリアを考える！
95あとで/406users “アカウント作成後すぐやるセキュリティ対策” 編を公開しました！- Monthly AWS Hands-on for Beginners 2020年4月号 | Amazon Web Services ブログ
94あとで/538users 大幅にリニューアルされた Next.js のチュートリアルをどこよりも早く全編和訳しました - Qiita
94あとで/1004users 「一生役に立つ」人に質問するときに覚えておきたい…とある大学の授業で配られた『質問の仕方』のスライド - Togetter
93あとで/1447users ヨーロッパでコロナに感染して入院した話 - にゃんぶろ
93あとで/782users これからは「一番最初に思い出してもらえるブランド」しか生き残れない｜池田紀行@トライバル｜note
92あとで/2071users 一人暮らしで新型コロナウイルスにかかった話｜RO｜note
88あとで/794users 見ずして死ねない日本の伝統建築10選
87あとで/1317users リモートワークが 超快適になる製品9選 〜仕事に本気なあなたに〜｜村上僚｜note
86あとで/425users 「AIをどう習得したのか教えて」と大募集し、技術者から集まった記事49本を紹介 - 週末スペシャル：日経クロステック Active
86あとで/809users API 設計: gRPC、OpenAPI、REST の概要と、それらを使用するタイミングを理解する | Google Cloud Blog
86あとで/778users Gitでよく使用するコマンドをGIFアニメで解説 | コリス
85あとで/395users TypeScript 練習問題集 · GitHub
85あとで/2211users コロナの影響でスーパーで買うカツオの刺身が美味すぎる。｜すずきまこと｜note
開発リーダーやマネジメントをやったこともあるが、基本的に今でもずっとコードを書いているし今後も書くだろう。
俺はよくバグを出す。ひどいバグもよく出す。障害報告書が必要なバグの原因となるのが俺の設計・実装・テスト観点の見落としに由来していたことはしょっちゅうだ。どうすればバグがでなくなるか、テストの技法を学んだり、アーキテクチャの勉強も何年もしている。勉強したことを共有するのが好きなので登壇も時々する。それでもやっぱりバグを出してしまう。
手ひどい障害をおこしたときは俺も誰かの設計したアーキテクチャで、誰かの指示のもとコードを書いて、テストをして、俺が責任を持たないで済む仕事をしたいと思う事もある。
けど、ビジネス側に「これが決まらないと実装できません。以上」と優秀でビジネスに寄り添わない開発者に突き放されて宙に浮いた要求を「完全ではないけどこうすれば要求は限定的ですが満たせそうですね」とかやっちゃうんだよ。
俺は上司やビジネスにとって都合のいい存在なので、優秀でビジネスに寄り添わない開発者よりも出世してしまう。俺は優秀な開発者の軽蔑を感じながらも大事な機能を任されてバグ入りの機能をリリースしてしまう。
きついなーと思いながらも、そんなとき俺は黒田硫黄の「セクシーボイスアンドロボ」の一節を思い出す。「もっとうまくできる人がいれば、その人に投げ出していたかも。でも、それをやる人はほかには居なかったの」(voice11. 鍵)
俺の尻拭いをさせられている後任が何人もいることも、もちろん知っているし罪悪感に苛まれる夜も多い。
けど、俺は才能はなくとも常にベストを尽くしているんだ。その時、それをできる人間は「宇宙で私だけ」(voice3. エースを狙え！)だったんだ。お前はその時その場にいなかったか、寄り添わなかったか、手を挙げなかったんだ。
職業エンジニアになって一番思ったことは、「なんかよくわかんないけど動く」コードは許されないということ。
自分が書いたコードがたとえ一行でも責任を持たないといけない。
「なんかよくわかんないけど動く」コードを書き続けるということは、
せっせとバグの温床となる状況を作り出しているのと同じことだ。
「なんかよくわかんないけど動く」コードの「なんかよくわかんない」ところって、
プログラミング言語の仕様や、コンピューターアーキテクチャの理解が必要だったり、
ある程度まとまった時間を取って知識を習得する必要があるものばかりだ。
先延ばしし続けると、いつまでも自分のコードに自信が持てずプログラミングのことが嫌いになりそう。
アメリカが凄いのは疑いようがないが、日本がどうしてアメリカに肩を並べられるほど高度な工業力にならなかったのかが気になっている。
iPodはホイールの使い心地に極振りし、あの当時はまだ余力はあったように思う。
iPhoneが出て部品の割合が日本製が多かったことがあり、差別化の要因はソフトウェアと言われた時代があったが、
今はAppleが独自に作っている半導体が差別化要因になった。
GoogleもAppleほど上手くできていないが、独自半導体が差別化要因になった。
日本の場合、ガラケーと言われていた頃は、各社独自技術を詰め込んでいて差別化していた。
ソフトウェアに関しても、数字を入力するとリンク先に飛べるというのは、日本人には古臭く感じるだろうが、
インドだとQVGAが主流でありKaiOSに取り入れられようとしてる。
探せば日本からというのはあるが、主導権が取れていないという感じか。
spaceXなど宇宙製品を見るとアメリカがずば抜けているのがわかる。
飛行機分野もそうだ。
CPUやGPUの成長伸びしろが減っているが日本は作れるだけの技術はない。
スパコンは何とか富嶽がつないだが、次世代を育てるという感じでもない。
GoogleのTPUはアーキテクチャ的にはCPUより簡単なものになったが、日本でハードを作ろうという感じでもない。
量子コンピュータを作ろうにもマイクロウェーブ制御技術もない。
とある受託開発の会社を経営してんだけど、まぁ俺が元々フリーでエンジニアやってた時の延長線上みたいな会社でさ。
と言っても、もう20年目で社員は25人で小さいながらもまぁまぁな規模なんだけど、売り上げは安定しないし、給料はうなぎ登りだし。。
5年前にとある製品を俺主導で開発して、毎年本業の受託の30％くらいの売り上げが立つようになっていい感じだったんだけど、
一昨年あたりから売り上げが下がり出して、もう今はほとんど０になってしまい、次の製品の開発が必至な状態なんだけど、
ほとんどの社員は本業の受託で一杯一杯だし、手が空いてる人といえば俺くらいしかいなかったのね。
まぁなんだかんだで、営業もマネージメントも仕組みとしては回ってて、俺はキャッシュフローの管理と、勤怠が悪いような
元々Webエンジニアなので、NodeJSとかReactとか勉強し直して、今時のアーキテクチャーでまぁ今時のスタートアップ的な
サービスを作ってさ、今日社員みんなに次期製品のPoCとして発表したんだけど、アラフィフで元々ASP(Active Server Page)とか
JavaでWebシステムを開発してたのが、フロントエンドもWebpackから始まって、SCSS、ReactのHookとか理解して、バックエンドも
ちゃんとRestfulなAPIで設計してさ、DBもMySQLで結構頑張ったんだけど、反応がそれはもう微妙で。
まぁそれまで誰にも言ってなかったのも悪いんだけど、長い付き合いの社員に社長がやるんじゃなくて社員からボトムアップ的に
やらないと盛り上がらないよと言われて、まぁ至極正論なんだけど、ただでさえ受託でパツパツなのに、誰がやるねん見たいなさ。
だったらトップが自ら動こうと思ったらこんなんで。ちなみにアイデアは本当に悪くなくて、実装も綺麗にしたんだけど、
まぁ多分社員的にはつまらない受託の仕事の傍ら、イケイケの技術で自社プロダクトの開発をやりたいんだろうなぁ。
それが社長がやっちゃったから気にくわないんだろうなと思ったわ。
みなさん、こんばんは。
｢Merpaku Frontend Engineer Meetup｣の時間がやってまいりました。
今夜は、著名フロントエンドエンジニアの方々にお集まりいただき、｢2020年のフロントエンドJSフレームワークを考える｣と題しまして、お話をお伺いいたします。
ま～、僕の場合はね、海外の技術情報をチェックしてるんだけど～
今のフロントエンドはさ～、なんちゅ～の？
あの、Frontend Engineerの友達がベイエリアとかにいるんだけどね～、いつもSlackで現地のトレンド情報を送ってくれるんだけど、よく調べると、ま～あの、銀の弾丸はない、結局はトレードオフ。
C:あ、ちょっちょっといい？
あのね、僕～はやっぱりjQueryが一番いいと…
A:でもね、僕なんかなんちゅうの、海外のカンファレンスに参加する機会がすごい多いわけ。ね？
この間もUSやUKまわってきたんすよね。
そこで一番感じたのはですね、銀の弾丸はないけど、結局はトレードオフというのが一番感じたなぁ～
B:う～ん、キミとはちょっと違うんだよね。
僕は英語がわかるでしょ～？
だから勉強会なんか、登壇してくれって何度も頼まれてね、断ってるんだけど、まぁ、だいたいよく調べてみると、銀の弾丸はない、結局はトレードオフっていう。
C:う～ん、でもね、やっぱり僕はjQueryが…
そうじゃなくてさぁ、僕なんかは1日にね、1日に8時間コード書きまくって生活してるわけですよ。
そうすっと、すごいよくわかるのは、銀の弾丸はない、だけど、結局はトレードオフっていう感じだなぁ～。
僕はいいね数5万個だよ？5万個ついてんだよ？それも「先週いいねが多かった投稿ベスト20」ばっかりよ？
で、だいたいよく調べてみると、銀の弾丸はない、結局はトレードオフなんだよ。
C:あ、ちょっと言わせてもらうとね、僕なんかやっぱりね、jQueryがやっぱりいいなと…
A:あのキミ違うよ、だってさぁ、Watchのレポジトリ数なんか言ったら、8万ありますよJS。
それをさぁ、全部動かしまくって感じんのは、はっきり言って、銀の弾丸はない、だけど、結局はトレードオフ。
B:んはっ、僕なんかね、キミとはちょっと違うんだけどね、懇親会で質問したりとかね、ちゃ～んとフロントントエンドの話して聞くとですね、銀の弾丸はない、結局はトレードオフなんだよね。
C:っといいですか？
フロントエンドを理解するためにはさぁ、アーキテクチャと切り離せないと思うわけですよ。
ね？聞いてる？
ね、ほら僕は今、自作ライブラリ開発してますよね？TypeScriptの、ほら？
だから、そういうふうに、日常にアーキテクチャを取り入れることからね、フロントエンドを考えると、銀の弾丸はない、だけど、結局はトレードオフと言い切れると思うわけよね。
B:ちょっと待ってよ、は～キミとはちょっと違うんだけどね、技術顧問先なんか行くとね、全部僕がWebpackとか、CI環境とか、み～んなレビューするんだよ？ペアプロするんだよ？
そうやってコミュニケーションしてね、でフロントエンドは銀の弾丸はない、結局はトレードオフなんだよね。
C:やっぱアーキテクチャだったらね、Backbone.jsじゃな～い？
A:なんかおかしいんじゃないの～？
え～、今度Abema Towersでフロントエンドのカンファレンスの運営サイドもします。
ま、そういう世界にいてですね、はじめてフロントエンドがよくわかると言い切れると思うんですよね。
だから、そういう言い方からしてもね、銀の弾丸はない、だけど、結局はトレードオフと僕は思うわけなんですよ。
B:違～うちょっと、僕はね、キミとちょっと違うんだけどね、僕なんかね、今度フルタイムのOSS開発やんだよ？しかもWebAssemblyよ？
そうやって実際にOSSを作ってみてね、銀の弾丸はない、結局はトレードオフ。
A:…
B:…
A:ちっ
B:ちっ
A:だからさぁ!!!WebAssemblyがどうしたか知らないけどさぁ!!!
僕ね、今度Google Japanに頼まれて、六本木ヒルズでキーノートやろうかどうしようか迷ってる自分がここにいるわけ。
B:だけどね!!!
A:来場者は1万人だよ!!!
B:それはね!!!六本木ヒルズがいくつあったって1万人がね…
B:六本木ヒルズがね、どうやって…
B:jQueryが…
A:そういう真剣勝負をさ、実力を持ってるところから、もの見てごらん!?
B:違うんだよ!!!
B:ちょっと違うんだよ!!!
https://b.hatena.ne.jp/entry/s/jp.quora.com/hotondo-no-puroguramingu-gengo-de-kansuu-no-return-ga-1-tsu-shika-deki-nai-no-ha-naze-desu-ka を呼んだんだけど、回答・ブコメともにとんでもないことを書いている人がたくさんいてびっくりした。本質的に多値返しは直積型の返しと同じで、これはタプル・構造体と本質的に同じ、というのは多くの人が指摘している通りではあるのだが…。
動的型付け言語に慣れてらっしゃる方が多いのかもしれないけれど、配列というのは「同じ型をまとめた型」であるべき。動的型でいろいろ突っ込める配列は本質的には「直和型の配列」と思った方がいいよね。多値返しという意味では（記憶領域の面で）余分なコストがかかりうる直和型を選択する意味はないですよね？回答でもなんか配列返しに言及している某有名人がいたが、あれれ？という感じ。
もっとも、immutableな配列をtupleと呼ぶPythonという言語があるせいで引っ張られている感は否めないけども、配列とは本質的に異なる型が存在しているのは明らかですよね？配列と構造体って違うよね…？（言葉の定義の問題と言われそうだけれど、型システムの分野での言葉の定義は存在しているわけで、反論になっているとは思えない。『俺は明日からこのわんわんなく動物をネコと呼ぶから』と言っているようなもんでは。）
確かにナイーブにはレジスタに入れて返すのが素直だというのは同意するけど、でもそれ構造体と一緒だよね？昔のCではこれはできなかったというのは知らなかったので勉強にはなりました（未検証だけど）。
あと構造体返しの関数がどう機械語で実装されているのか知らなさそうな人がいるのにはちょっとびっくり。それでなんでレジスタがどうとか言えちゃうのかしら。構造体の値を返す関数ならばポインタは返さないですよ。そのポインタはどこを指してるんですか。実装しづらいとか何とか言ってる人たち、ちゃんとアセンブラ読んだことあるんですか…？本質的に何の困難もないです（ちなみに少なくともlinux amd64ではスタックに領域を確保してそのポインタを関数の引数の一部として渡します。まあヒープに置く場合でも余計なmoveが出ないようにしたいとかあるかもだけど、そんなでかいデータは普通無名構造体では扱わないでしょう）。
確かに、返り値の型が(A, A)のような場合はドキュメント読まないとわからなくなってしまうので可読性が下がるし構造体を使うべしというのは（ほぼすべての場合において）同意（多値は使いづらいというのは構造体は使いづらいという意味ではないですよね？）。でもさ、某有名人もgoで挙げているけれど多値って普通(A, B)みたいに違う型の値を返したくなることの方が多くないですか。この場合どっちがどっちかは自明だよね？ただの無名構造体だよ。多値返しは設計が甘いとかわけわからんことを言っている人もいたけれど、なんかこちらが不安になってきた。
…本当に意味不明で驚いた。id:megumin1氏が言っているように、tupleのパック・アンパックに余分なコストをかける必要はない（まあアドレス渡しになるから複数本のレジスタで返すのと比べたら余分なmovが入りうるという話はあるけど、この人が多値返しというので何を想定しているかわからないので何とも。）。何遍呼んでも多値返しとtuple返しの違いが判らなかった。おそらく前述のようにimmutableなlistのことをtupleと思っているのかな？と予想はするが…。
はてな界隈ってエンジニア的な印象があったんだけど、ここら辺の話ってそんななじみないのかな…？てか某有名人氏も型システムとかあんまりご存じないのかな…？むしろこれは増田が無知なんだろうか…？
MVP（Minimum Viable Product：仮説を検証することができる最低限のプロダクト）
ttp://kozy4324.github.com/blog/2012/03/20/report-agile-japan-2012/
とにかく雑に作れ - 東京工業大学エンジニアリングデザインプロジェクト - Medium
ttps://b.hatena.ne.jp/entry/s/medium.com/titech-eng-and-design/%E3%81%A8%E3%81%AB%E3%81%8B%E3%81%8F%E9%9B%91%E3%81%AB%E4%BD%9C%E3%82%8C-2f87cc00eb85
Things that are complex are not useful, Things that are useful are simple.
複雑だと役に立たない。何よりも単純であることだ。
完成に漕ぎ着けるのは、
付け加えるものがなくなった時ではなく、
Ruby入門 (全26回) - プログラミングならドットインストール
Ruby on Rails5 | プログラミングの入門なら基礎から学べるProgate
Ruby on Rails 5入門 (全28回) - プログラミングならドットインストール
Ruby on Rails チュートリアル：実例を使ってRailsを学ぼう - Michael Hartl (マイケル・ハートル)
Ruby on Rails ガイド：体系的に Rails を学ぼう
6 of the top 10 @ycombinator companies (by valuation) were built using Ruby!
ttps://prograils.com/posts/top-10-famous-sites-built-with-ruby-on-rails
スケーラビリティがとか、拡張性がとか、モノリシックなアーキテクチャは柔軟性がないんじゃとかいう声が聞こえてきそうだが(もっとも僕も前はそう思っていたのだが…)、
こんな技術的な美しさやなんちゃらビリティなんてものはスタートアップにおける開発速度の重要性に比べたらなんの意味もないものである。
最近PMFする前にアーキテクチャにこだわりすぎる事故をよくみる。
PMFする前のプロダクトなんて動けばなんぼなので、Railsで汚くてもいいからゴリゴリ書いて、最低限のJSをつけるだけでよい。
「スタートアップでWebアプリつくるなら、Railsでアプリ分割せずAPIモード使わずにシンプルにつくれ。
A Modern Web Application With Rails
ttps://medium.com/rubyinside/a-modern-web-application-with-rails-da3deb48014c
JavaScriptフレームワークはもうこりごり
Ruby on Railsを使って2週間で最初の動くバージョンを作り上げた
ttps://bit.ly/2KdcKim
Ruby on Railsで10分で作るTwitterもどき
ttps://bit.ly/2KVdAl8
１時間でツイッターサービスを作ろう！ – KRAY Inc.
ttps://b.hatena.ne.jp/entry/s/kray.jp/blog/twitter_service_in_1hours/
「1人で6時間で作った」 Twitterで匿名質問「Peing」人気、月間2億PV超えへ
ttps://bit.ly/3b7qyIz
僕はずっとRails使ってますが、別にRailsにこだわってるわけではないのでもっと良い技術があれば普通に移行すると思います
ただ移行するためには今持っているRailsの資産や経験など全てを超えてなお移行したほうがメリットある場合に限るので中々そういうものは少ないかな、、、と
ttps://b.hatena.ne.jp/entry/twitter.com/_sesere/status/953120084666433537
今は分かりませんが、数年前まではphpでrubyと同じ事をしようとするとソースコード量が3倍近く必要でした ソースが短ければバグが発生し辛いですし、ミスもかかる時間も減る と言うことで僕はruby、、、と言うよりrailsをおします
ttps://b.hatena.ne.jp/entry/twitter.com/_sesere/status/928170730893619200
Railsのセミナー面白かった。 スタートアップ企業の社長がPHPを捨ててRailsを選んだ理由がエンジニアの安定性というのが、今回聞いた中では一番心に残った。
エンジニア視点ではなく、経営視点で考えたら、ボトルネックは必ず人だからだよな。
ttps://b.hatena.ne.jp/entry/s/twitter.com/poepoe49091/status/762141005432750080
スピードに対してごちゃごちゃ言うなら C じゃなくアセ ンブラで書けばいい。
それをなんで C で書いてるのかって言えば、 それはもちろん「コードがわかりやすい」とか、「早く書ける」って のが理由だろう。
そして、Ruby は C よりわかりやすいし速く書ける。 ということは、「C よりも Ruby」というのは非常に自然な選択では ないだろうか？
Cで書くと2日かかる。実行時間は0.1秒
Rubyで書くと1日かかる。実行時間は10秒（Cの100倍）
と、すこし極端な仮定を置いてみると、どっちが得でしょうか。
ttps://jp.quora.com/naze-ruby-ha-hokano-gengo-to-kurabe-te-osoi-node-shou-ka
Railsアプリケーションを、Heroku上で1分間125,000リクエストに対応できるようにスケーリングする
ttps://postd.cc/scaling-rails-to-125-000-requests-per-minute-on-heroku/
ttps://magazine.rubyist.net/articles/0059/0059-Ruby-Rails-Beginners-Guide.html
ttps://techracho.bpsinc.jp/hachi8833/2019_01_25/68846
Railsは2019年も「あり」か？ Railsの長所と向いている用途
ttps://techracho.bpsinc.jp/hachi8833/2019_01_29/68871
30代後半や50代からでもソフトウェア開発者になるのには遅くないという10人の実例
ttps://bit.ly/2M6Dh6l
ttps://bit.ly/2J8ak5W
開発言語は基本的にPHPとJavascriptの職場。
別に複雑なコードでもないし、PHPやJSでも、まがりなりにもコードを書いてる人なら見ればわかるでしょって感じなんだけど。
スマホアプリ作るときも、JSならだれでもメンテナンスできるからってmonacaとかいうJSでアプリが開発できるやつを採用したけど、Webとはアーキテクチャが違いすぎるから結局一部の人間にしか触れなくて、そんなマイナーなプラットフォーム採用した意味なかったし。
ちょっとしたツールを作るときも、Windowsアプリとして作ったほうが使い勝手いいから、VB.NETかC#で作ろうって話になってもベテラン勢が猛反対して、無理やりPHPでWebアプリとして作ることになったし。
サーバーで使うシェルスクリプト(.sh)も未経験の俺が、ネットでチョコチョコとググって改修して、すごいびっくりされたことがあるけど、こっちからすればなんであんたらは触れないかっていう感じだし。(黒魔術的な書き方もあるらしいけどもちろんそんな書き方ではない)
Windowsサーバーで使う .BAT ファイルを書くときに、.BATファイルの仕様では黒魔術的なテクニックを使わないと実現できない仕様だったからほかの言語にしませんかって提案したけど、.BATでないとほかの人が保守できないからと却下。
無理に.BATで書いて、逆に変なテクニックを駆使した保守性皆無のコードになってたし。
どの言語を使うかって話題になると、自分の使ってる言語以外を使うとアイデンティティが崩壊するかのような勢いで反対する。
Haskellみたいにまったく思想の違う言語ならともかく、似たような言語で、かつifとループと配列とサブルーチンの概念を把握していたら理解できるような書き方しかしてないコードでも、普段使ってない言語って時点で理解不能に陥るんだよな。
https://anond.hatelabo.jp/20191115002701の続き
奴はこともあろうに親に対してテロ行為を行った。気に入らないことがあれば正本副本併せて三通の抗議文書をしたためて正式な手続きを経て論理的に伝えるべきところを、言語による議論を拒み直接行動という暴挙に出たのだ。知性の欠片もないなんと身勝手極まりない所業。赤ん坊だからたぶん口にしていたのはパイパイだけらしく吐瀉されたものは白く少量ではあったがゲロはゲロでテロはテロである。
くそっ！こうなると不得意ではあるが標的の父親も含めた白兵戦による鎮圧しかない。俺はもうスタスタと父親と標的の元へ行った。折しも今日バッグの中に、世間では「粗品」と呼称される社名入りのタオルが装備されていたのだ。ガキめ、お前の身勝手のせいでお前とお前の父親は俺の会社のプロモーションの一環に取り込まれるのだ。因果よのう。
俺が「タオルありますよ！」と声をかけると「あっあっすいません！」とうろたえた様子の父親。俺がそんな決死の白兵戦を展開しているときにさっきの女の子も寄ってきた。一応ここでは彼女をマユと呼んでおこう。なんか儚げで愛らしい響きじゃないかマユ。やはりマユも同業者だったか。「あたしウェットティッシュ持ってます！」。ほう、やるじゃないかマユ。「これアルコールじゃないからお顔拭いても大丈夫ですよ！」。その気配り、君も相当の手練れだな？マユのトートバッグから出てきたウェットティッシュは俺が予想していたポケットティッシュサイズのそれとは違い、円筒形のケースに入ったやつだった。うーん。何でこんなでっかいの持ち歩いてるのかなあ。場所柄ひとつの仮説が脳裏に浮かんだが俺は大人なのですぐ封印した。だっていま戦場だし。
それにしてもこのガキ、今頃になって自分のしでかした事に恐怖を覚えたのか凍り付いた表情で「へけっ」などと歯を見せている。歯ははえてないので正確には歯茎だ。ハム太郎の真似などしても無駄だとばかりにマユがウェットティッシュでガキの口の周りと顎の下あたりを激しく攻める。どうだ心臓が止まりそうに冷たいだろう。ガキは「んっんっ」とか言いながら抵抗するがマユは容赦しない。何が、んっんっだ。これは鎮圧だ。制裁だ。なるほど、口の周りは四つに畳んでちょんちょんと拭くと標的に効率的なダメージが与えられるのか。やがてマユの攻撃にガキが大口を開けて断末魔の深呼吸をしている。よしそのまま落ちろ。
すると、俺の腰のあたりから「〇〇ちゃんゲボした♪」と声がする。お姉ちゃんがなぜかニコニコ不敵な笑みを浮かべながら参戦してきた、ほう、2対2か？俺とマユの挟撃から弟だか妹だかを救おうと言うのか？こしゃくな。すかさず俺は彼女を恫喝した。「んーでもおねえちゃんもあかちゃんのときにやってるとおもうよ？」「やってないよぉ！ﾁｬﾊﾊﾊ」。明らかに虚偽の発言なのであるがここは徹底的に論破して奈落の底に突き落とすことはせず、「おねえちゃんすごいじゃん！」と言って議論を終結させた。この大人ならではの老練さ。お前の援護射撃など文字通り赤子の手をひねるようなものだ。
そうこうしていると山盛りのエビチリをたいらげたか母親が店の外に出てきて、事情を知ると俺とマユに恐縮したように礼を言い、俺には「あの…タオル」と言うので俺はすかさず「あー！いいですいいです！それ会社の粗品ですから！株式会社〇〇をよろしくお願いします（笑）」と言って立ち去ろうとしたら、先ほどの恫喝が効いたと見えて標的の赤ん坊ではなくお姉ちゃんの方が俺に先ほどの虚偽の発言に対する懺悔を意味するバイバイをしてきたので、お前の懺悔など認めんという意思表示で俺は侮蔑のバイバイを返した。標的はママに抱っこされて俺のタオルを食べていた。
なおその家族と俺に会釈して立ち去ったマユの向かった方向にある個性的アーキテクチャの建造物群を考慮し俺は先ほどの仮説を確信に変えた。
おつとめごくろうさまです。
