Rails Developers Meetup 2019(2019/03/22 - 23)
![Ruby on Railsの正体と向き合い方 / What is Ruby on Rails and how to deal with it?](https://cdn-ak-scissors.b.st-hatena.com/image/square/6ea9aa83b4715ee72b4ec70d67ae747dac8aaf86/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fce30c3cf9433471283e24855f6bdd2b4%2Fslide_0.jpg%3F12160993)
Rails Developers Meetup 2019(2019/03/22 - 23)
2013年から2017年のあいだ、スタートアップを含む2000以上の組織に対して、いかに組織のパフォーマンスを加速するかという聞き取り調査を行い、その調査結果をまとめたものです。 その調査結果のひとつにこのグラフがあります。 これは組織のエンジニアの人数とそのパフォーマンスを、組織の違いによって示したものです。 横軸がエンジニアの人数、縦軸はエンジニアあたりの1日のデプロイ数を指標としたパフォーマンスです。 これによると、パフォーマンスの低い組織はエンジニアが増えるとデプロイ数も減少しています。普通のパフォーマンスの組織はエンジニアが増えてもデプロイ数に変化はありません。 一方でパフォーマンスの高い組織はエンジニアが増えるほど指数関数的にデプロイ数が増えていきます。メルカリが目指しているのはここです。 これは単純にアーキテクチャをモノリシックからマイクロサービスへ移行するだけでは実現できま
https://starttoday-tech.connpass.com/event/96477/ オウチーノではもともとサービスごとに異なる言語やFWを用いてシステムが分かれており、担当者もそれぞれ別々でした。そのため各サービスに精通した担当者が少なく、担当者は日々の運用で手一杯という状況下で、リプレイスもうまく進んではいませんでした。 そこでリプレイスよりも、分かれているシステムをひとつのモノリシックアプリケーションに集約することで、チームとしてよりワークすることをまずは目指しました。 一方で数多くのサービス機能を集約することは、そのモノリシックアプリケーションが急激に肥大化することも意味します。そこでモノリスにすることでの弊害をなるべく抑えつつ集約していく事例についてご紹介します。
前置き この記事、本来は Flux には Model がないのではないかと思った覚書 - ナカザンドットネット と Flux の Store が ViewModel かって話からの MVW とかどうでもいいって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く のアンサーとして書き始めた記事だが、前置きだけで別テーマとなったので、前後編に分割する。 僕は元々がゲームクライアント屋だったときの発想を引きずってるのと、既存の Web の開発の文脈に対して距離を置いていることを明言しておく。あとこういうテーマでとある原稿書いていたので、頭の整理も兼ねて。 ActiveRecord の功罪を振り返る このテーマを語るにあたって、まず Rails の MVC について述べなければならない。なぜなら、フロントエンドのアーキテクチャとは、サーバーサイドの MVC の模倣に始まり、破綻し、結果として
HTML5 Conference 11/25
Lightweight Architecture Decision Records とは? Lightweight Architecture Decision Records とは、 重要なアーキテクチャの意思決定を背景と結果とともに記録する手法 です。 Architecture Decision Records は ADR とも呼びます。 一般にこれらは Wiki や コラボレーションツールに保存されます。 ADRにお役立ち情報 以下のリポジトリに実際に ADR を導入する際の手順などがまとまっています。 github.com と言ってもシンプルなもので、実際にやることといえば テンプレートを決める ファイル名のフォーマットを決める アーキテクチャの意思決定をする 意思決定内容をテンプレートにそって記載してバージョン管理ツールに残す このぐらいです。 ツール ADRのためのコマンドライン
先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
翻訳を担当した書籍『進化的アーキテクチャ ― 絶え間ない変化を支える』(オライリー・ジャパン)が8月18日に出版になります。原書は2017年に出版された『Building Evolutionary Architectures ― Support Constant Change』(O'Reilly Media)です。 O'Reilly Japan - 進化的アーキテクチャ 現代におけるエンタープライズアーキテクチャは、もはや静的な計画をあてにすることはできなくなっています。そしてソフトウェア開発エコシステムは、ツールやフレームワーク、技術イノベーションの流れと共に絶え間なく変化しています。こうした状況の中で、いったん構築したシステムを成長させていくには、さまざまな変化に適応しながら進化するアーキテクチャをシステムに組み込む必要があります。本書は、そうしたアーキテクチャを「進化的アーキテクチャ
Clean Architecture 達人に学ぶソフトウェアの構造と設計 Robert C. Martin(著), 角征典, 髙木正弘(訳) アスキードワンゴ 2,816円 (2,560円+税) アーキテクチャのルールはどれも同じである! どんな種類のシステムでもソフトウェアアーキテクチャのルールは同じ。ソフトウェアアーキテクチャのルールとは、プログラムの構成要素をどのように組み立てるかのルールである。時代を超越した不変のルールたちを紹介する。 関連サイト本書の関連ページが用意されています。 Clean Architecture - アスキードワンゴ内容紹介本書は、"Robert C. Martin. Clean Architecture: A Craftsman’s Guide to Software Structure and Design. Prentice Hall, 2017.
事の発端 始まりはこちらのツイートから。 Usecasesレイヤーを充実させていったらVuex Actionsほとんど使わなくなるな笑 — Andy (@andoshin11) 2018年6月15日 それはどういうことだよ・・・ フロントでどう使うんだ・・・? と疑問に思い、自分なりに検証・実装してみたいと思ったのが事の発端です。 Clean Architectureとは? まず根本の理解がほぼなかったので調べることにしました。 こことか https://qiita.com/koutalou/items/07a4f9cf51a2d13e4cdc こことか https://blog.tai2.net/the_clean_architecture.html こことか https://qiita.com/Tueno@github/items/705360b357c2a00c9532 こことか h
現場のES201x と未来のアーキテクチャ - インサイドフロントエンド2
autoscale: true Faao - ドメイン駆動設計で作るGitHub Issue Client - 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info 過去に作ったやつ azu/GithubReader: Github Notifications Client for OS X azu/github-reader: [node-webkit] GitHub client app - Viewer for Notifications and News Feed. azu/github-issue-teev: [NW.js] GitHub Issue Manager(Viewer) Faao Faao - Feature Support Modern browser/mobile/Electron(re
(追記) 本記事,頭のなかを整理しきれていない状況で書いたためよくわからないことになっていますが,Clean ArchitectureやRedux,DDDの優位な点を解説するような記事ではないことをご了承いただけると幸いです. 全体の構成がどうなっているか・モチベーション・pros・cons等については後日別記事にまとめようと考えています. いま書いているアプリがClean ArchitectureになりそこねたMVPと中途半端なDDDを組み合わせたようなアーキテクチャになっている. このアプリをある程度キチンとClean ArchitectureとDDDに寄せるにあたり,DDDのレイヤ分け(Data/Domain/Presentation)をどこまで厳格にやるかで悩んでいる. 現状 だいたいこんな感じ. Data/Domain/Presentationのすみ分けはしていない 実装上は意識
Androidアーキテクチャことはじめ ― 選定する意味と、MVP、Clean Architecture、MVVM、Fluxの特徴を理解する Androidアプリの開発において悩ましいアーキテクチャの選定。本記事では選定する意味を改めて整理し、 MVP・Clean Architecture・MVVM・Fluxといった最新の実例を紹介します。 はじめまして。Androidエンジニアの藤原聖(ふじわら・さとる/@satorufujiwara)です。 現在は株式会社サイバーエージェントで、エンジニアリングマネージャーを兼任しています。2017年で35歳になり、定年を迎えました(プログラマの定年については「体型を支える技術」などを参照)。 Androidアプリ開発には2010年から携わっていますが、今現在の関心事は何といっても公式開発言語に採用されたKotlin。そしてもう一つが、Androidの
12/1 に Qiita のトップページをリニューアルしました。これまで React を使っていましたが、それをやめて hyperapp を採用しました。まわりを見てもあまり採用事例が見当たらないので、この記事では一体なんで今をときめく React ではなく hyperapp を選択したのか、どういうところが魅力的なのかについて プレゼンテーション層を実装するためのツールとして 学習コスト の観点から書きたいと思います。なおこの記事に書かれていることは全て個人の感想であり、はっきりいって個人の日記レベルです。 それと hyperapp の開発者が社内にいるという事情もあるので、そこら辺さっぴいて読んでください。 TL;DR プレゼンテーション層を実装するためのツールとして React は機能過多だし、機能不足 hyperapp は過不足ない 学習コスト 仮想 DOM は学ぶ価値のある知識
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く