一条工務店のことに言及する増田やブクマカがちらほらいるので、一条工務店で建てた俺がなんとなく語る。 一条工務店は家を建てることに興味がなければそもそも認知してないっていう人のほうが多いメーカーだが、注文住宅の年間着工棟数でトップクラスのメーカーである。 特徴は大量生産のメーカーでありながら断熱・気密性能の高い家を建てていること。 主力商品のi-smartの場合、壁の断熱材は一般的に使われるグラスウールよりも性能の高いウレタンフォームを使用し、厚みも増し増し。 窓もLow-eアルゴンガス封入のトリプルガラス樹脂サッシが標準という徹底ぶり。 気密面では気密のとりやすいツーバイ構造を採用している（壁の断熱材の厚みを増やすために2x4ではなく2x6にしている） もちろん全棟気密測定を実施。 それでいてお値段は有名大手メーカよりも若干安いくらいに抑えられている。 そりゃ売れますよねっていう商品力であ
We are going to rewrite React from scratch. Step by step. Following the architecture from the real React code but without all the optimizations and non-essential features. If you’ve read any of my previous “build your own React” posts, the difference is that this post is based on React 16.8, so we can now use hooks and drop all the code related to classes. You can find the history with the old blo
shiodaifuku.io
Webエンジニアのブログです。
はじめに 今回の記事では、個人の独断と偏見で2022年～2023年で必ず確認するべきGitHubのリポジトリを紹介する。私のTwitterでこれまで紹介したものもあれば、そうではないものもある。 GitHubはプログラマーにとって、普段の学習・開発を進めるうえでもっとも重要な情報源の１つである。本記事では、分野ごとに確認するべきGitHubリポジトリを紹介する。 なお、今回の記事で紹介するGitHubリポジトリの分野は以下の通り。内容はWeb開発に特化している。 確認必須 Web Python JavaScript TypeScript ちなみに、「確認必須」は分野を問わずすべてのプログラマーに役立つGitHubリポジトリを紹介している。 今回の記事を通して、年末年始の学習・開発に大いに役立ててもらえたら幸いだ。 確認必須 freeCodeCamp 世界最大規模のプログラミングメディア「f
この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io
アプリケーション開発で、「ビジネスロジックは分離しろ」だとか「Controller にビジネスロジックを書くな」といったことをよく言われると思います。 しかし、ビジネスロジックという言葉の意味を聞いたり調べたりしてみても、「システムのコアの部分」とか「システムの目的になる処理をするところ」みたいなことを言われたりして、よく分かりませんでした。 そんな中、クリーンアーキテクチャや DDD の戦術的設計について学ぶことで、「ビジネスロジックとは何か」、「ビジネスロジックはどう実装するか」について、自分なりの考えが整理されてきたので、この記事ではそれをまとめます。 ※ 曖昧な言葉を自分としてどう使っているかという話になります。違う意味で使う方もいると思うので、ご注意ください ビジネスロジックとは何か 「システムのコアの部分」とか「システムの目的になる処理をするところ」といった説明も正しいとは思い
中山です ソリューションアーキテクトとして、AWS環境の利活用をお手伝いするお仕事をしています。 まれによく見るAWS環境 とりあえずこれを見てほしい。 これが絶対にだめと言いたいわけではないです。 一時的な検証環境だったり、とにかくスピード重視でサービスをデリバリーさせる必要があったり、サービスの提供者側が何ら責任を負わない・障害時のビジネスインパクトが無い（そんな状況あるのか？）という前提があったり、状況次第ではこれで十分な時もあると思います。 しかし、一般的な業務システムやサービスの場合にはいろんな意味で不十分でしょう。 では、このような環境をどのように育てていくとよいでしょうか。 この記事では、そんな育てかたの一例を紹介していきたいと思います。 なお、本記事はくっそ長いです。 ちなみに、最終的にはこうなります。 文字が小さすぎて読めない！ ちょっとそこのハ○キルーペ貸してくれーｗ
専門家と街の接着剤を見て歩く
パッと見える視界の中に絶対とは言えないまでもほぼ確実に存在するものがある。空気や水、都市においては接着剤もその一つだろう。専門家と一緒に街を歩くシリーズ、なんと今日は接着と接着剤を見て歩くのである。 50年接着剤メーカーにいる専門家と歩く 今回一緒に渋谷を歩いてくれる木村修司さんは接着剤メーカー・セメダイン勤続50年超の最古参社員だそう。検索をすると「接着剤博士」という異名まで出てくる。 接着剤について聞くうえではうってつけの方である。 一方、不安もある。街の接着剤を見ると言ってもそんなに話すことがあるのだろうか。違いが微妙すぎやしないか。だが聞いてみるとおもしろい話がたくさんあった。 セメダインの木村修司さん（左）デイリーポータルZ林雄司（右） ビルのガラスは接着剤でついている 渋谷の駅前からスタートです 林：たとえばこの景色で接着剤使ってるところって考えると…。 木村：いっぱいあります
WEB アプリケーション設計入門 / Introduction to web application design
PHP Conference Japan 2020 トーク前提の資料です。そのため、トークがないと理解が難しいかもしれません。 https://youtu.be/UTKJ-Lgn3aI?t=36 ※冒頭音声が小さいです。マイクを手に持ってから聞こえやすくなると思います。 資料中の ADOP …
Amazon EC2 を Arm に切り替えたら幸せなことしかありませんでした | CyberAgent Developers Blog
技術本部 サービスリライアビリティグループ（SRG）の長谷川 @rarirureluis です👳 #SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 はじめに Apple M1 で Arm という単語をよく耳にし、そしてその性能に驚いた方も多いと思います。Apple M1 が搭載された Mac のベンチマークはこちら そして Amazon EC2（以下：EC2）にも Arm が搭載されたインスタンスがあります。 https://aws.amazon.com/jp/ec2/graviton/ 今回はとあるサービスの全開発環境の EC2 インスタンスを m5.large から t4g.medium へ移行したら幸せになれたので、この記事を
長野県のJR茅野駅に隣接する茅野市民館図書室が最近、ネットで熱い話題となっている。ずらりと並ぶ本の背表紙が退色してしまい、青っぽくなっているのだ。原因は紫外線とみられ、「本の悲鳴が聞こえる」「意匠重視の設計者の自己満足」などなど、ネット上では厳しい意見があふれるが……。市民館側には公共空間としての狙いと高所にあるがゆえの悩み、ジレンマがあった。 茅野市民館は2005年10月にオープンした。キーワードは「交流」で、外からも見えるし、内からも外が見える。そうすることで異分野の人々の出会いを意識した。 図書室は最も駅に近い空間に細長く作られている。長辺は両側とも高さ5メートルを超える全面ガラス。蔵書は約1万点で、片側の全面ガラスから茅野駅の列車やホームが見え、片側には八ケ岳の山々が映る。開放感とロケーション、日当たりは申し分ないのだが……。 ネットの指摘通り、図書室に並ぶ本の多くは背表紙が青く変
なぜ僕が「SPAはコストが高い」と考えているのか
どうもみなさんこんばんは ちょっと前に「個人開発者やスタートアップの初期からSPAで開発するのはコスト高いっすよね」みたいな事を書いたらフロントエンドエンジニアの皆様からバチバチに叩かれた僕です 彼らには彼らの考えがあるのでそれはどうでもいいのですが、どういう理由があってその発言をしたのか～と言う部分が気になっている方もいたようなので説明しておこうと思います ちなみに今でも全く意見は変わっておらず、この発言に同意できるかできないかは単純に視点の違い、規模の違い、スキルの違いだと思ってます 追記: もちろんSPAじゃないと実現できないようなサービスを作りたい場合はSPA一択ですし（インタラクティブにHPつくるサービスとか。でも世の中の95%くらいのサービスはそうじゃないと思います）、サイトの利用はログインした人にだけ提供するような業務系ツールなどはまた話が別です 前提の話 こういう記事ではコ
エンジニアとして今の自分を形成した本5冊 エンジニアとして働くにあたって自分が大きく影響を受けた本を考えてみた。もちろん他にもあるが、今回は以下の5冊に絞って紹介する。 Clean Coder（クリーンコーダー） Team Geek Clean Architecture（クリーンアーキテクチャ） テスト駆動開発 LeanとDevOpsの科学 この記事の対象者としては、独学でプログラムを書き始めた人やエンジニアスクールを卒業したばかりの方というよりは、実務経験を1~3年くらい積んでいるけど次に何を学べば良いかわからず、自分でイマイチ伸び悩んでいると感じている人を主に想定している（かつての自分がそうだった）。 特にチーム開発、オブジェクト指向言語でのコーディング、テストコードを書いた経験がある人が読んで、本に書いてあることを実践すると自分の成長を実感するだろう。 「Clean Coder」、「
みなさんこんにちは。電通国際情報サービス(ISID) 金融ソリューション事業部の水野です。 これは電通国際情報サービス Advent Calendar 2022の16日目の記事です。 今回は、ISID金融事業部で運用しているスキルマップについてご紹介します。 テックリードとは 実は、ISIDの少なくとも金融事業部にテックリードと言うポジションはありません。 実在するのはチーフアーキテクトと言う職種のみで、各プロジェクトでリードエンジニアやテックリードという仮想的なロールがあるのが実態です。 一時期はフルスタックエンジニアと呼んでいる時期もありましたが、近年このワーディングが好まれない印象なので、大々的に使っていません。 主観ですが、フルスタックエンジニアはインフラ知識／運用系の知識のウェイトが高いエンジニアで、テックリードはソフトウェアアーキテクチャ、Webアプリケーション実装技術寄りのエ
「常識が変わってる」アニメや漫画でよく見る「狭い廊下の学校」はもはや時代遅れ？いつの間にか学校の構造が変わっていることに驚く人たち
晒黑的がんくま @gankuma_ あと、自分が子供の頃は教室の机には落書きや先輩が彫刻刀で彫ったキズとかあるのが当たり前だったけど、今の学校の机はほとんどの所で落書きや傷の無い綺麗な状態で使ってる印象があるね。 晒黑的がんくま @gankuma_ @li_vers 実際には結構多いよ。小学校だと授業中でも廊下（？）を児童がうろうろしてる時もあるよ。こちらで作業途上のものを廊下に置きっぱなしでも授業中なら子供に触られないだろーと思って「施錠とか不要ですよ」って言ったら校長先生から「そんな甘いもんじゃない」って言われるwww
結論 「アジリティ」「コスト最適化」「スモールな構成」「開発スピード」という観点でWebアプリケーションのアーキテクチャを考えてみました。 ServerlessFrameworkを使い倒す フロントエンドはS3 hosting + CloudFrontで。SSRもLambda@Edgeでできます データベースはRDSは使わずにDynamoDBで APIは基本的にGraphQL。必要に応じてRESTも簡単に追加できるよ。 補足(2022/04/12) 最近個人開発しているこちらのWebサービスはこのアーキテクチャに沿って作られています。 このアーキテクチャでどんなものができるのよ、という視点で見ていただくと面白いかもしれません。 ↓ 背景 アーキテクチャに絶対の正解はない アーキテクチャには絶対の正解はありません。 なぜなら、プロダクトやフェーズによって求められる要件が異なり、それに適したア
ritouです。このしずかなインターネットにおける初投稿です。 おそらく、このしずかなインターネットのID連携では次のような設計になっていま「した」。問い合わせをさせていただき、対応いただきました。 これまでもQiitaなどで同様の実装例が紹介されていた際にはコメントさせていただいていたものですので、アンチパターンの紹介記事として読んでいただければと思います。 「Googleアカウントでログイン」ではじめると、ユーザーが作成され、Googleから受け取ったメールアドレス([email protected])が設定される 次回から「Googleアカウントでログイン」をすると、Googleから受け取ったメールアドレスでユーザーを参照 試しに、次のような流れで動作を確認してみます。 「Googleアカウントでログイン」でアカウント作成([email protected]) 「メールアドレス変更」
中国で「家を新築する」のはほぼ不可能（どんな金持ちでも）
語学質問たん @GS___tan 【世界の不動産・中国】 8億円の中古高級住宅。でも内装がない。「前の持ち主が家を売る前に内装をはぎ取ったのですか? 」と中国人に聞くと「たぶんそうじゃない。内装は最初からない」という。「え、だってこれ中古でしょ」と聞くと（つづく） wuxi.anjuke.com/prop/view/A541… pic.twitter.com/NdqWcGq3MB
概要 本稿は、突然ムシャクシャした筆者が自分の考えるブロックチェーンの定義と、世間で言われているブロックチェーンの特性および応用例を批判するものである。 本稿は筆者の見解であり、所属組織の公式見解ではない。 ブロックチェーンの定義 そもそもブロックチェーンとはなんなのか。狭義には、「ブロック」の「チェーン」であることから、以下の定義をしたい。 データが、当該データ直前のデータの暗号学的ハッシュ値を持つリスト型のデータ構造 ここでは、そのデータの中に何を保持するかは一切考慮しない。 データがハッシュ値で連鎖することによって、リスト中の任意のデータのみを書き換えると、ハッシュチェーンの整合性が失われ、書き換えが行われたことを検知可能なデータ構造であると定義する。 しかし、世間で「ブロックチェーン」に興味を持つ諸氏はこの定義だけではいささか狭すぎると感じるだろう。 そこで、狭義のブロックチェーン
「マインクラフト」プレイヤーが催した「Minecraft違法建築イベント」が、現実にはあり得ないカオスな建物が生み出されて話題を呼んでいます。「違法建築」とは穏やかでないですが、要はオンラインで集まり、建物を好きなように建て増しして遊ぼうという試み。そうして出来上がった、複雑怪奇な構造が壮観です。 経過だけでワクワク 雑多なようでいて、全体像は調和したように見える 主催はマインクラフト建築コミュニティ（@mc_kenchiku_com）。海に囲まれた世界で、人々が生き抜くために高い建物を作り、ひたすら“上”を目指す――そんな世界設定の下にプレイヤーを募りました。開催に際しては、あらかじめ素朴な土台を用意。そこに大勢で気ままに増築していこうという趣向です。 基盤となったプレーンな土台。ここからああも変わるものか イベントには見学者を含め累計で168人が参加。ルールが「建築様式不問」だったこと
「最低な再開発」とSNSで名高い大阪梅田の住友タワマンの事例から、「日本で今後あるべき再開発」について考える｜倉本圭造
「最低な再開発」とSNSで名高い大阪梅田の住友タワマンの事例から、「日本で今後あるべき再開発」について考える 東京の明治神宮外苑再開発問題について書いた記事がめちゃバズってTBSの討論番組にも呼ばれたりしたので、日本各地の「再開発」について「アレはどう思う？」ってX（ツイッター）って知らない人に聞かれることが増えたんですよね。 なかでも、「大阪市立大阪北小学校跡地」に住友不動産が建てたタワーマンションは「最悪of最悪」の再開発だろう、という話がSNSで盛り上がっていて、興味を持ったので正月の帰省に合わせて現地を見に行ってきました。 今回記事は、この「梅田の住友不動産のタワマン」の話を皮切りに、よく話題になる明治神宮外苑や下北沢といった色んな事例を取り上げながら今の日本における「再開発」がどうあるべきか、について考える記事になります。 （いつものように体裁として有料記事になっていますが、「有
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
2022年10月1日に開催された #postdev での発表です
Instagramは2010年10月にサービスを開始後、2011年12月までのわずか1年間で1400万人に利用されるほど巨大なサービスに成長しました。こうしたスケールに対応できるシステムを組み上げたのはたった3人のエンジニアだったとのことで、どのように少人数でスケールするシステムを組み上げたのかについて、エキスパートエンジニアのレオナルド・クリードさんが解説しています。 How Instagram scaled to 14 million users with only 3 engineers https://engineercodex.substack.com/p/how-instagram-scaled-to-14-million レオナルド・クリードさんは、Instagramが3人のエンジニアで安定して巨大なサービスを提供できた理由として、下記の3つの原則を守ったからだと述べています
プラットフォームの上でものを作るということ Amazon EKS Advent Calendar 2019 の最終日です. みなさまご存知の通り、AWS には Amazon ECS と Amazon EKS という2つのコンテナオーケストレーションに関するサービスがあります. ECS は2014年に発表された AWS ネイティブなコンテナオーケストレータ、EKS は OSS のコンテナオーケストレータである Kubernetes をマネージドな形で提供するサービスで、2017年に発表されました. 今日はこの Amazon ECS と Amazon EKS という2つのサービスについての話を書こうと思います. // 読んでくださっているみなさまをミスリードしないための DISCLAIMER 本記事の著者は AWS に勤めています. また、この記事には僕個人の意見や想いも強くこもっています.
初めての技術選定を頼まれた時に大事だったのは俯瞰的・相対的な考え方だった - MonotaRO Tech Blog
背景 お題 技術の差別化 差別化から分かること 情報資産からToBeを考える 俯瞰的・相対的な技術選定 これまでの話から学んだこと 最後に はじめまして、MonotaROでデータエンジニアをやっています、芝本です。 エンジニアのみなさん、技術を使って何か作ってみるのって楽しいですよね。 私は、公私ともに日々物作りに励んでいます。プライベートだと、最近はマイクロフロントエンドについて学んでいます。 技術を使うためには、技術を学ばなければいけません。 プライベートにおいては、好奇心に従って自由に学びますよね。 とりあえずgit cloneして動かしてみたり、書籍を購入して読んでみたりします。 というようにプライベートでは主に次のような選択肢があると思います。 書籍を読んで好きなものを選ぶ 実際に手を動かしてみて好きなものを選ぶ 人に教えてもらって好きなものを選ぶ 基本的にプライベートの場合は何
改めて整理するアプリケーション設計の基本
●発表のアーカイブ動画はこちら：https://youtu.be/4rgGkoyUaZw ●発表の中で紹介しているUdemy講座：https://www.nextskill.co.jp/courses === プログラミングの基礎を学び、アプリケーション開発に実践的に関わり始めると、「…
Mermaid Flow is a Visual Mermaid live editor that aims to simplify creating Mermaid JS Diagrams online. Currently Mermaid Flow supports Flowchart diagrams, giving you the ability to Drag and Drop nodes, edges and labels to create your Flowchart diagrams visually. This mermaid live editor is useful for creating and maintaining complex diagrams such as Software Architecture diagrams. Once drawn, sim
質とスピード（2020秋100分拡大版） / Quality and Speed 2020 Autumn Edition
質とスピード（2020秋100分拡大版） 2020/11/20 @ JaSST'20 Kyushu
いわゆるGoFの23個のデザインパターン。知っておくに越したことはないが、フレームワーク・ライブラリに溶け込みすぎていて、現代では知らないうちに使ってることになるので、余裕があれば。
Rails の問題は Rails のベストプラクティスがフロントエンドのベストプラクティスの邪魔になるどころか全く逆方向で相反してる点です。DHHの思想がフロントエンドと根本的に逆行してる。そういう人が作るフレームワークなのでwebpackerの抽象化を根本的に間違ったりする。 — prev.js (@mizchi) December 1, 2020 昨日もリプライで少し書いたけど、DHH自体が直近のHeyの開発でも明確にJavaScriptというものを触れないようにすることを是としているような主張をしているので、DHH wayが色濃く反映される以上この状態はもう避けられない気がしている — potato4d / Takuma HANATANI (@potato4d) December 1, 2020 Railsがフロントエンドの最先端をゆく人々1から良く思われないのは事実として。 Vie
公開日：2021.10.26 更新日：2023.06.28 エスカレーターは誰でも乗れる魅惑の乗り物。エスカレーターを楽しむ極意、まとめます ※掲載内容は公開日時点の情報です。現在と異なる場合がございます。 「エスカレーターは魅惑の乗り物」とはりきってタイトルを付けましたが、そもそも普段エスカレーターを「乗り物」として意識されている方は少ないかもしれません。どちらかというと、ちょっと階段より便利な建物の一部、ぐらいの認識でしょうか。もはや日常の一部として、誰もが意識することなく当たり前に乗っていると思います。 私はエスカレーターに注目しはじめて15年ぐらいのエスカレーターマニアです。鉄道マニアなどをはじめとする「乗り物」マニアの中でも、たぶん日本で5人ぐらいしかいないのではないかと思われる“マニアックなマニア”です。そんな私から、「乗り物」としてエスカレーターを楽しむとはどういうことか、じ
全AWSエンジニアに捧ぐ、CloudWatch 設計・運用 虎の巻 / CloudWatch design and operation bible
全AWSエンジニアに捧ぐ、CloudWatch 設計・運用 虎の巻 / CloudWatch design and operation bible
設計ナイト2020 を受けて、今どんなアーキテクチャを選ぶべきかという話をしたくなったのだ。 kichijojipm.connpass.com 設計ナイトで高ぶった結果1時間コースの発表資料が完成したので供養場所を探しています。聞いてくれ！！！— Takafumi ONAKA (@onk) 2020年11月1日 お前誰よ 2000年代前半に SI 2000年代後半にブログ、SNS 2010年代にソーシャルゲーム 2020年代に UGC サービス をやってきた人間。数百万〜数億行のデータ、月間数千万〜数十億 imp 程度を主戦場にしています。 今日の話 DDD と PofEAA から学ぶパターン/アンチパターン Rails によって発見された、密結合で速く走れるソフトウェア 今求められているアーキテクチャ 昂ぶって 15,000 字ぐらい書いてしまった。 DDD と PofEAA から学ぶパ
管理マン🍄 @kanri_man2103 天窓はやめとけおじさん:天窓はやめておけ イケイケ設計士:体内リズムが良くなります 大工:天窓はやめておけ 防水業者:天窓はやめたほうが良いです 僕:天窓はやめておけ #天窓はやめておけ
『手を動かしてわかるクリーンアーキテクチャ 』の第二章の冒頭に登場する話題に共感したので紹介。 従来の多層アーキテクチャでは、データベースを中心にアプリケーションの 開発が行なわれます。この場合、Web 層はドメイン層に依存し、ドメイン層は 永続化層、つまり、データベースに依存することになります。そうなると、す べてのものは永続化層上に構築されることになり、その結果、いくつかの要因 が絡まり合って、問題が起きやすくなります。 手を動かしてわかるクリーンアーキテクチャ ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 20p 手を動かしてわかるクリーンアーキテクチャ ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 作者:Tom Hombergs,須田 智之インプレスAmazon 著者によれば、機能開発をデータベース中心に設計すると、ドメイン層と永続化層の密結合が
IPアドレスに縛られない新しい通信識別技術と既存のインターネットが共存するための国際規格が発行されました （METI/経済産業省）
欲しいデータ／コンテンツを取得する際に「場所（IPアドレス）」を指定して取りに行くのではなく、データ／コンテンツの「名前」を指定して取りに行く新しいネットワーク技術と、既存のインターネットが共存するための国際規格が発行されました。 この国際規格により、Society5.0 を支える重要な基盤要素であるIoTにおけるデータ通信が効率化され、様々な産業分野でデジタル化が促進されることが期待されます。 1．背景 現在の通信方式は、通信相手となるサーバの場所（IPアドレス）を指定し、常にそこまでデータ／コンテンツを取りに行くプロセスによって成立しています（図1参照）。この仕組みは、サーバ・端末の位置が変わらず、「一対一」の通信であることを前提として構築されたため、現在のようにサーバ・端末が移動し、「一対多」「多対多」の通信となる場面には十分に対応することができないことがあります。このようなケースで
概要 学生氏に適当なことを言い過ぎ反省しているので、バックエンドのいま覚えてる良かった記事の共有です。 まっさきにみるやつ Web 系エンジニアの学習ロードマップです。 とりあえずこのロードマップにのってる"紫のチェックマーク"がついたものを順番にこなしていけば良いとおもいます。backend のロードマップを紹介しましたが他にもfrontend やdevops などもあります。しかも毎年更新してくれます。 この記事はこのロードマップ以上の情報は提供できません。おわり。 roadmap.sh その他 エンジニアリングについては雑に調べると歴戦のエンジニア各位が紹介してくださってるので、クラウド系をメインに紹介します。 一般的なやつ タイトルママ。 バックエンドというよりエンジニアリング全般。 japan.googleblog.com 技術記事に特化したキュレーションサービスです。 追いたい
RESTful のウェブ API 設計で避けるべき 6 つのよくあるミス | Google Cloud 公式ブログ
※この投稿は米国時間 2022 年 12 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。 オンラインで、組み立て式のテーブルを注文したとします。ところが、パッケージを開けてみると、組立説明書が入っていません。完成品がどんなものかはわかっていても、それぞれのパーツをどう組み立てればいいのか、まるでわかりません。設計が不十分な API を使うコンシューマ開発者も、同じような経験をしているといえます。適切に設計された API なら、容易に見つけ、検索してアクセスし、使用することができます。高品質の API は、コンシューマ開発者がアイデアをひらめき、新しいユースケースを作り上げる手助けになってさえくれます。 もちろん、API 設計を改善する方法はあります。たとえば、RESTful のプラクティスに従うなどです。しかし、お客様が知らず知らずのうちに、ちょっとした不便
技術的負債の生態 - maru source
@t_wadaさんが翻訳されていた技術的負債の記事をあらためて読んでみたら非常に面白かった。技術的負債の本来の意味が説明されているので、まだ読んだことがない人は一読をおすすめする。 その翻訳記事を読みながら、Jasper（僕が開発しているGitHub用のIssueリーダー）のv1.0で技術的負債を返済したことを思い出した。そこで、その翻訳記事を参考にして技術的負債の生態について自分なりに考えてみることにした。すると面白い生態がいくつか見えてきた。例えば「生態③: むしろ技術的負債が生まれることそれ自体はポジティブである」などである。今日はそのことについて書いてみようと思う。 ちなみに今回は技術的負債への対処までは解明することができなかった。いつか続きを書けたらいいなと思う。 技術的負債が生まれる背景 まずはJasperで経験した技術的負債を紹介する。負債の内容自体はそんなに重要ではないので
根本の問題意識 ソフトウェアの設計スキルはどのように獲得する（させる）ことが効果的であるのか ソフトウェアアーキテクチャの目的 そもそもソフトウェアアーキテクチャはどのような欲望を満たすための方法か ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するための必要な人材を最小限に抑えること である。 (CLEAN ARCHITECTURE) 「求められるシステムを構築・保守するための必要な人材を最小限に抑えたい」 => 構築容易性 と 保守容易性 を確保したい 構築容易性 「構築しやすさ」とは？ ソフトウェアを構築するとはどういうことか ソフトウェアの2つの価値: 「振る舞い」と「構造」 振る舞い: 要件を満たすこと => いわゆる機能 構造: 振る舞いを簡単に変更できること => いわゆるアーキテクチャ 構築しやすさ=価値の生み出しやすさ 要件を満たしながら振る舞いを変更
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
一条工務店のことに言及する増田やブクマカがちらほらいるので、一条工務..
Build your own React
【決定版】2022年～2023年で必ず確認するべきGitHubリポジトリ 40選
Re: Rails を主戦場としている自分が今後学ぶべき技術について
「ビジネスロジック」とは何か、どう実装するのか - Qiita
冴えないAWS環境の育てかた α | DevelopersIO
図書館の本が真っ青 開放的過ぎた？「本に申し訳ない」：朝日新聞デジタル
エンジニアとして今の自分を形成した本を5冊紹介する - パンダのプログラミングブログ
エンジニアのスキルマップ・テックリードへの途 - 電通総研 テックブログ
個人開発・スタートアップで採用すべき最強のアーキテクチャを考えた - Qiita
メールアドレスをキーにしてID連携を行う設計の危うさ｜ritou
ブロックチェーンでそんなことはできない - chike0905の日記
「ワクワクする」「九龍城みたい」 145人のマイクラユーザーが作り上げた“違法建築”がカオス
Instagramはどうやって3人のエンジニアで1400万人にサービスを提供できるシステムを組み上げたのか
プラットフォームの上でものを作るということ
Online Mermaid Visual Editor | Mermaid Flow
ソフトウェアアーキテクチャを学ぶために - kawasima
Railsを主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ
エスカレーターは誰でも乗れる魅惑の乗り物。エスカレーターを楽しむ極意、まとめます｜KINTO
Smart UI パターンが再評価される世界 - id:onk のはてなブログ
天窓はやめとけおじさん『天窓はやめておけ』浪漫あふれるイメージの天窓になぜ『やめておけ』なのか？次々と理由が集まってくる
データベース中心の設計になってしまう問題と闘う - laiso
バックエンドに興味を持つ学生にオススメするクラウド系メインのリンク10選 - y-ohgi's blog
ソフトウェア設計を学びたい人々にまず教えるべきことはテスト技法ではないか - 余白