Vueを用いた開発プロジェクト用に「コンポーネント設計・実装ガイドライン」を作った話 - Qiita
はじめに こんにちは、モチベーションクラウドの開発にフリーのエンジニアとして参画している@HayatoKamonoです。 この記事は、「モチベーションクラウド Advent Calendar 2018」8日目の記事となります。 概要 モチベーションクラウドの開発チームでは2018年10月から改善期間と称して、開発に関するガイドラインやルール作りをはじめとする、様々な改善活動に取り組んでいます。 その改善活動の一環として作成した「コンポーネント設計・実装ガイドライン」を今回は説明を交えながらご紹介して行きたいと思います。 目次 Componentの粒度に関して Container ComponentとPresentational Component コンポーネントの共通化に関して コンポーネント実装時の細かな決め事 CSSに関して まとめ Componentの粒度に関して これまではフロント
【Vue.js】負債を返却しながら機能追加しなければならない状況で実践したフロントエンドのコンポーネント設計 - クラウドワークス エンジニアブログ
はじめに こんにちは！ 社会人2年目を頑張っております、エンジニアの@b0ntenmaruです。 今年2月までリファクタリング専門チームにてcrowdworks.jpの技術的負債を返却するために奮闘しておりましたが、そこから現在まではユーザーの皆様に安心安全なサービスを提供するためにクラウドワークス 安心安全宣言のための施策を行っています。 リファクタリング専門チームについては以下をご覧ください。 engineer.crowdworks.jp qiita.com 施策による機能開発を行う際に直面した課題 施策では主にフロントエンドの機能追加をすることになったのですが、技術的負債によりスピードを維持しながら開発を続けることは困難な状態でした。 crowdworks.jpを取り巻くフロントエンドの技術スタックはざっくり書くと下記3つに分類できます。それぞれで発生している問題を簡潔にまとめます。
とにかく分かりづらいTwelve-Factor Appの解説を試みる
WEBエンジニア勉強会での資料です。12Factorに関する僕なりの解釈を解説しています。 https://web-engineer-meetup.connpass.com/event/75898/Read less
Power Theory of Software Architecture
今日の講演の趣旨： ソフトウェアアーキテクチャというと、もしかしたら技術的で高度に専門的な事柄であるように聞こえる。 そのため、「要素技術」に詳しい人が「アーキテクチャ」を作るという誤解をしているケースがある。 また、プロジェクトマネジメント・プロダクトマネジメント・ピープルマネジメントのそれぞれが アーキテクチャとは無関係であると誤解されているケースがある。 今回の公演では、 これらは有機的に絡み合っていて、不可分であるという点を強調したい。 そのために、 「アーキテクチャ」という概念を次のように定義したい 何かをしやすくしたり、しにくくしたりする構造。 この何かをしやすくしたり、しにくくしたりする力を「権力」と呼ぶ。 この権力は、「他の選択肢」を選べないという時に生まれる。 この選択肢と依存のネットワークから生まれる権力の構造を「アーキテクチャ」と規定すると、 ソフトウェアの交換可能性
SAML認証に関する自分なりのまとめ - なんとな～くしあわせ？の日記
SAML認証に関わるプログラミングをずっと続けていたので、ここらで少しわかりやすいまとめと考察を書きたい。 用語説明 SP-initiated SAML IdP-initiated SAML SAMLのXMLの中身 <AuthnRequest> <Response> 誰かの１秒のために３時間デバッグする 便利なツールやドキュメントなど まず、SAMLはだいたい２種類に分けられる。SP-initiated SAMLとIdP-initiated SAMLだ。 用語説明 SPとはService Providerの略でWEBサービスの提供側を指す(例：Cybozu, Dropbox） IdPとはIdentity Providerの略でIDやIDのもつ情報の正当性を保証する側を指す(例：AWS, Google, Salesforce もしくはOpenAM, CA SiteMinderのようなIdPを
Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
お前らがModelと呼ぶアレをなんと呼ぶべきか。近辺の用語(EntityとかVOとかDTOとか)について整理しつつ考える - Qiita
お前らがModelと呼ぶアレをなんと呼ぶべきか。近辺の用語(EntityとかVOとかDTOとか)について整理しつつ考えるmodelDDD設計 みなさんは、Modelと言われたときに何をイメージしますか？ こんなアレを思い浮かべた方も多いかと思います。 マサカらせてください。やはりお前らのModelは間違っている。 アレをModelと呼ぶと何が不味いのか すみません、早速言い過ぎました。半分は正しいです。MVCの発明者、Trygve Reenskaug氏による1979年の説明によると、 Models represent knowledge. A model could be a single object (rather uninteresting), or it could be some structure of objects. 1 このように「Modelは単体のオブジェクトであっても
サーバーレスについて語るときに僕の語ること // Speaker Deck
サーバーレスについて最近思っていることをポエムしました. サーバーレス過激派です. Presented at Serverlessconf Tokyo 2017.
事業会社におけるマイクロサービス化について - arclamp
がちがちのエンタープライズ系で既存システムのマイクロサービス化に取り組むときに注意したいこと。 儲かる機能をマイクロサービス化する マイクロサービスの最大の目標は「サービス化された機能のリリースサイクルを、その機能を管理するチームが独自に決定できるようにする」ことです。つまり、システム内の他の機能や他システムとの調整をしないで、いつでも好きなようにリリース可能であることが大事です。もちろん、日中に。 それは何のためかというと「機能をどんどん改善して儲けたい」からです。これまでは、儲かる機能を改善をしようとしても、その他の機能や他システムとの調整や影響範囲調査やリグレッションテストに時間がかかってリリーススピードをあげることができませんでした。この問題が解決できればウハウハできるはずです。 マイクロサービスのサービス分割点について聞かれることが多いですが、それは「ビジネス部門が『早くリリース
Serverless Anti-Patterns
1. Serverless Anti-Patterns Keisuke Nishitani (@Keisuke69) Amazon Web Services Japan K.K. Mar 09, 2017 Photo via VisualHunt.com 2. Profile Keisuke Nishitani Specialist Solutions Architect, Serverless Amazon Web Service Japan K.K @Keisuke69 Keisuke69 ✤ RESTおじさん ✤ 餃⼦の王将エヴァンジェリスト（⾃称） ✤ ⾳楽が好きです、フジロッカーです、今年も⾏きます ✤ ブログ: http://keisuke69.hatenablog.jp/ Keisuke69 Keisuke69Keisuke69x
技術的負債の返済プロジェクトが失敗する 11 のワケ - jfluteの日記
ワケ一覧 序の口: フレームワークだけが負債だと思ってる 序二段: ビジネスサイドに理解してもらう努力がない 三段目: 技術で遊び過ぎてしまう 幕下: 太り過ぎアーキテクチャ 十両: 過去に目もくれず、現状だって見ない 前頭: 技術に詳しいだけでアーキテクト 小結: アーキテクトの知識と覚悟が足りない 関脇: スパンが長く、モチベーションが続かない かど番大関: スパンが長く、人の入れ替えでチグハグ 大関: アーキテクチャデザインはどこへ？ 横綱: 実は人間的負債だった 序の口: フレームワークだけが負債だと思ってる みんな、フレームワークが大好き。とはいえ、さすがにみんな、「フレームワークが古いことだけが負債」だなんて思ってないはずだが...なのに多くの人が、あたかもそのような振舞いと判断をしてしまう。潜在意識の Big Issue だから？ o 信用できないテストデータ も負債 o 現
もしインターネットの1秒が1年だったら - SunPro 2016技術書典
2016年、インターネットが日本中のあらゆる人間に行き渡るようになってから、すでに10年単位の時間が経過しています。今日においてインターネットを支えるネットワーク技術が重要であることは言うまでもありませんが、実際にネットワークでどのタイミングで何が起こり、どれくらいの時間が費やされるのかということを身を持って体感している人は、たとえネットワークに精通している人でも少ないのではないでしょうか？この記事では、1秒というわずかな時間を1年にまで拡大し、ネットワーク上で何が起こっているかを人間スケールでざっくりと解説していきます。 2.1 はじめに たぶんはじめまして。博多市(@hakatashi)です。今回は技術書典向けの小企画として、「インターネットの1秒がもし1年だったら」というだいぶ抽象的で怪しい記事を書こうと思います。 インターネットというのは光の速さを身をもって感じることができるメディ
SpringでField InjectionよりConstructor Injectionが推奨される理由 - abcdefg.....
SpringでField InjectionよりConstructor Injectionが推奨される理由を調べてみたメモです。 (2016/12/30) サンプルコードにfinalをつけるように修正 (2017/03/29) Immutabilityについて追記 --- 家でも会社でもIntelliJを使って開発しているのですが、 Spring Bootで@Autowired(@Inject)を使うと下記のような警告が出るようになりました。 警告内容を見てみると、フィールドインジェクションは推奨されません、とのこと。 「Field injection is not recommended.」 警告の詳細を見てみると下記のように書いてあります。 「Field injection is not recommended. Spring Team recommends: "Always use
AWSユーザーは必ず覚えておきたいExponential Backoffアルゴリズムとは何か - yoshidashingo
cloudpackエバンジェリストの吉田真吾（@yoshidashingo）です。 Exponential Backoff 直訳すると「指数関数的後退」つまり、指数関数的に処理のリトライ間隔を後退させるアルゴリズムのことです。 詳しくはWikipediaに記載があります。 Exponential backoff - Wikipedia 日本語でブログに書かれている方もいらっしゃいます。 exponential backoffのメモ – Siguniang's Blog これを見ていると、どうやらこのアルゴリズムは古くから通信装置において、イーサネットフレームのデータ送信時にコリジョン（衝突）を検出したら一定時間待機して再送して、処理を完結させるためのアルゴリズムとして使われているようです。 通信機器の世界に限らず、アプリケーションの分野でも、大規模で予測不能な処理量を有限なリソースでさばく
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How to Design Software — Tags and Groups
アーキテクチャ決定のお供にLightweight architecture decision records
NoOpsへの挑戦
https://d1.awsstatic.com/Industries/HCLS/Resources/AWS%20GxP%20Example%20Architectures.pdf
AWSでアプリ開発するなら 知っておくべこと
Salesforce サクセスナビ
