GoとRustの比較まとめ
Go と Rust 前提 参考資料を日本語で自分用にまとめ直したものです 類似点 安全 スケーラブル 開発者の生産性 現在人気である言語が前提としていたもの ムーアの法則は永遠に真である ほとんどのソフトウェアプロジェクトは小さいチームで開発され，チームは一緒に働く ほとんどのソフトウェアは相対的に依存が小さい．ほとんどプロプライエタリである 安全性は二の次．もしくは全く考慮されていない． ソフトウェアは大抵ひとつのプラットフォームのために書かれる GoとRustが現代の開発者の要求に答えている パフォーマンスと並行性 マルチコアを活かせる チームがスケール可能（レビュー可能） 以下を気にする必要が減る format security complex organization コードを理解するためのコンテキストが相対的に小さい buildと実行が容易 Open Sourceを前提としている
#golang は大規模環境向けか？
この記事は2021年5月頃に Scraps で書きなぐった記事をいちから書き直したものである。 Scraps の記事は既に非公開（アーカイブ）化している。 4,5月頃のこの手の記事（ポエム）は季節の風物詩みたいなもので，夏休み真っ盛りに書くには季節外れかもしれないが， Twitter でエゴサーチしてて「ひょっとしてブログ記事として纒めておいたほうがええかしらん」と思ったので，今更ながら書いておく。 起点となる tweet は以下： ちなみに表題の問いに対しては yes とも no とも言えない。リアルで問われても，おそらくは「時と場合による」としか答えられない。ソフトウェアというのは基本的に「一品もの」で，一般論で大雑把な話はできても，詳細を掘っていくほど難しくなる。プログラミング言語の選定はその最たるもので，結局は手持ちのソフトウェア資産と動員できるエンジニアのスキルで決定することが多
ERDをPlantUML形式で自動生成するツールを作った - くりにっき
PlantUML + ERDでPlantERDです github.com モチベーション PlantERDの特徴 使い方 出力するテーブル数の制限について 技術的に頑張ったこと テストのこと Foreign keyで隣接している別のテーブルを探す方法 複数DB対応のつらみ 追記：2019/12/13 9:45 モチベーション 既存プロダクトへの不満が一番大きいです。 https://github.com/voormedia/rails-erd は出力が画像なので取り回ししづらい そもそもRails前提なので他言語とかでは使えない https://github.com/schemaspy/schemaspy も悪くなさそうなんだけどここまでリッチじゃなくていい テーブル数個の小規模アプリならいいんだけど、中規模以上のアプリで使うと人間が読むに耐えないERDが生成されて精神が崩壊する 僕は初め
その設計、変更に強いですか?単体テストできますか?...そしてクリーンアーキテクチャ - Qiita
はじめに アーキテクチャや設計の書籍や記事、これまでの経験も踏まえ、学んだ事をここにまとめたい。(まだ、勉強中なので微妙なところもあるかもしれません。お気付きの点があればご指摘いただけるとありがたいです。) 参考文献や参考記事は、本当に良書、良記事で非常に参考にさせていただきました。 生意気なタイトルにしてしまいましたが、自分への戒めということもあってこのタイトルにさせていただいたので、ご容赦ください。 ある共通した話題 設計やアーキテクチャについて書かれた書籍や記事を読んでいく中で、言葉は違えどかなりの高確率で共通するテーマが存在した。 そう、それが 「変更に強くなろう」 といった趣旨のテーマだ。 アーキテクチャや設計に関する書籍や記事は様々な方法論で、これを実現しようとしていた。 今回のテーマと記事の構成 今回は、「変更に強くなろう」というテーマの中で重要だと感じた概念や考え方をまとめ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
