この記事は、設計・アーキテクチャ Advent Calendar 2018 の第7日目の記事である。 はじめに この記事では、IT業界19年目の僕が実践している変更に強いアーキテクチャについて、出来るだけ難しい表現を避け、教科書的なありきたりな内容ではなく現場の肌感覚に近い切り口で「超ザックリ」な解説を試みてみようと思う。 普段自分がよく用いている実装パターンの紹介ともいうべきかも知れない。 この記事で説明すること いざ「変更に強いアーキテクチャとは」とズバリ訊かれても、一概に「これだ！」という答えはない。 プログラミング言語や、フレームワークによっても条件が異なるし、利用可能な技術や開発チームの特性、業務要件や運用要件の特性によっても様々であるし、インフラや開発プロセスまで含めて考えると考慮すべきことは無限にある。 ここでは主にソフトウェアの構造という観点から、"変更に強い" ということ

BEMによるフロントエンドの設計 第1回 基本概念とルール この記事ではフロントエンドの設計方法「BEM」を紹介します。第1回目はBEMのもっとも基本となるBlock、Element、Modifierの概念と、class名の命名ルールを解説しています。 はじめに 最近フロントエンド界隈で、『BEM』という言葉を見かけることが増えてきました。BEMとは、Block、Element、Modifierの略語です。Webサイトのコンポーネント化のためのフロントエンド設計方法のひとつで、厳格なclass名の命名ルールが特徴的な手法です。 第1回は、BEMをまったく知らない方向けの入門編です。 なぜBEMが必要なのか 私たちはHTMLとCSSを使うことでしか、Webサイトを作ることができませんが、HTMLとCSSにはプログラム的な機能が備わっていません。そのために、フロントエンドエンジニアは次のような

BEMとは BEMは命名規則など、CSS設計の考え方のアイデアのことです。（構成案） BEMはBlock, Element, Modifierの頭文字をとったものです。 BEM 公式サイトの文章を引用します。 BEM Quick start BEM (Block, Element, Modifier) is a component-based approach to web development. The idea behind it is to divide the user interface into independent blocks. This makes interface development easy and fast even with a complex UI, and it allows reuse of existing code without copyin

こんにちは。マツコです。 突然ですが、CSS設計はとても重要なものです。 一定のルールがないと、コーダー各々が違う考え方でスタイルづけをして余計なCSSが増えてしまったり、本人でなければ分からないルールが発生してしまい、メンテナンスがしにくくなってしまいます。 そのため、以下のことを強く意識してCSS設計を行うことが大切だと言われています。 予測しやすい 再利用しやすい 保守しやすい 拡張しやすい 今回は上記の目的を達成するヒントとなる、著名なCSS設計手法である「OOCSS」「BEM」「SMACSS」についてお話したいと思います。 概要 Object Oriented CSS(オブジェクト指向CSS)の略。 オブジェクト指向に基づいて、考案された設計手法です。 Yahoo!のNicole Sulivan氏によって開発され、Twitter（とBootstrap）やGithub、Youtub

ここ数年、CSSも設計の重要度が高まり、様々な設計手法が出てきています。 「OOCSS」「SMACSS」「BEM」などが代表的な手法で、これらの考え方をベースにした派生版も優秀なものが出てきていますよね。 弊社ではBEMをベースにFLOCSS等を交えたCSSガイドラインを使用しています。 良い面も多いですが悪い面もあり、導入が失敗だったと感じたこともありましたが、いまは慣れたこともあり使用しています。 今回はBEMが破綻するケースを挙げてみたいと思います。 あくまでも慣れ、スタッフの認識度合いによりますので参考程度に読んでみてください。 デメリット 1. BEMの記述法、概念 ここが曖昧なままだとCSSの設計はすぐに破綻します。 まずは以下のような情報に目を通すことが重要ですね。 https://en.bem.info/ https://csswizardry.com/2013/01/mi

Node.jsをリアルタイム解析サービスの開発で5年間使って知ったメリットやデメリットを紹介します。大規模な解析サービスをNode.jsで記述する上での工夫などについても解説しています。

自分はCODEPREPというオンラインプログラミング学習サービスをやっているのですが、今年の 2 月に React と TypeScript を使ってフロントエンドを再構築し、半年間サービスを走らせてみた結果について振り返ってみたいと思います。 はじめに CODEPREPは月間で 50 万 PV 以上ある Web サービスです。 そのため、それなりの事態は発生するだろうと思い、フロントエンドにはエラー監視を導入して、ユーザーのブラウザ上で何かエラーが発生したら、直ちに Slack に通知が来て対応できるような万全の準備をしていました。 しかし、自分が担当して来た Web サービスの中では、もっともユーザーに頻繁に使われているにも関わらず、稀に見る安定稼働のサービスとなっています。 今回は、選定したフロントエンドの技術スタックのどの辺りが良かったのか、少し振り返りたいと思います。 TypeS

Este documento presenta conceptos clave de diseño de dominio y arquitectura de software. Explica patrones como agregados, fábricas y repositorios para modelar entidades y servicios, y describe técnicas como capas de anticorrupción y contextos de dominio acotados para dividir una aplicación. También cubre temas como modelado de eventos, diseño estratégico y mapeo de contextos de dominio.Leer menos

上記の他に以下のような規則も必要に応じて設けると良いでしょう。 接頭辞（プレフィックス）を必要に応じて付ける（例：is-xxxx） 単語は略語を使用しない（NG例：cnt, hdg, tbl） 参考 変数名の命名規則/＊＊ケースの使い分け 命名方法 命名規則が決まればそれに則って命名すれば良いのですが、どういう単語を使えば良いのか指標がほしいところです。 英単語がすぐ出てこないような時はネーミング辞書 Codicを使ってみると良いです。命名の参考としては良いツールだと思います。 目的や内容によっては汎用的に使える英単語も存在します。例えば、レイアウト用の要素としてcontainer, row, col。ジャンル・業界別の要素としてabout, results,productsなど。 レイアウト用のclass名や汎用class名に関してはいろんなCSSフレームワークのコードを見て研究すること

今日朝イチで見たエントリーがこれでした。 qiita.com 論理削除の弊害は色々なところで言われているけど、僕の足りない頭で理解している所によると、二つの値しか持たない削除フラグ的なものはカーディナリティが云々で検索条件につけても性能上的にもよくないし、意味がないということです。 論理削除を完全に悪だとは言いませんが、論理削除を極力排したい人たちは、基本的にデータそのものを削除する、もしくは論理削除というのはまだ要件的に未確定な要素が隠されていることを示すフラグであると考えているようです。 僕がITの業界でキャリアをスタートしてから2年目くらいに配置されたプロジェクトではT字型ER手法というのをベースにしたテーブル設計をしていて、そこでかなり鍛えられたわけですが、その時にはだいたいこのような原則を叩きこまれました。 テーブルに状態を持たせない 究極には機械が認識するキーと、人間にとって意

RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiita 論理削除が云々について - mike-neckのブログ Kazuho's Weblog: 論理削除はなぜ「筋が悪い」か 流行っているので乗っかります。 結論 「データ制約の強力さと集合としての表現力を捨てながら、Relational Databaseを使うのはなぜか？」 論理削除フラグのデメリット 大体三つあると考えています。 ユーザーの言葉でない データ制約の弱さ 集合として認識できない ユーザーの言葉でない 私の経験上は、ユーザーから「論理削除」という言葉を聞いたことがありません。 次のような要件は、聞いたことがあります 社員が退職（・転属）する （売掛金の回収を諦めて）売上を打ち消す 「お知らせメッセージ」を公開日がくるまで非表示にする 既読メッセージを表示しない 保存期間が過ぎたアンケート結果をオペレ

前例がないため、どこにも答えが存在せず、基本的に色々なものを１から考えて作ることが多くなります。 その時重要になってくるのが、と、 キャッチアップ力 と 基礎理解力 だと思っています。 私の場合、衛星が撮影した画像を処理して蓄積する処理をVHDLで組むというのがあったのですが、全くVHDLを知らない状態から1ヶ月半ほどで実装する必要が生じ、何とか間に合わせたという経験がありました。 その時は、基本的な知識を本やWebから調べ、回路を組みながらあれこれ試して勘所を掴み、最終的に実装に落としていくというような事をしましたが、昨今テクノロジーの進化と変遷が激しくなる中で、未知の技術を学習して「使える」状態に持っていくための、 自分なりのフレームワーク を持っておくことが非常に重要であると思っています。 逆に言うと、何かした時に、常にそれを自分の中にフレームワークとして蓄積するという意識を持って取

結論 簡単に監視ソフトのDMLをまとめと思ったが、ボリュームあるからやめた nagios は外部キー無し、テーブル名にプレフィックスありの特徴があります Schema ER Nagios Zabix Table List Nagios mysql> show tables; +----------------------------------------+ | Tables_in_nagios | +----------------------------------------+ | nagios_acknowledgements | | nagios_commands | | nagios_commenthistory | | nagios_comments | | nagios_configfiles | | nagios_configfilevariables | | nagio

OPENLOGI Advent Calendar 2017 最後の投稿です。 株式会社オープンロジは 2013年12月25日 が創業日で本日がちょうど創業4年目の節目になります。 オープンロジのサービスリリースが 2014年10月 なのでそれからは3年程になります。 物流アウトソーシング「オープンロジ」がサービス開始――中小事業者や個人をターゲットに お陰様でユーザは徐々に増え今年の夏にはシリーズBラウンドをむかえ事業規模も大きくなってきました。 こんなサービスを３年間支えてきた技術や逆に使わなくなってしまった技術を振り返りながら整理したいと思います。 インフラ 何はともあれサービスを運用するにはサーバーが必要ですがAWSなどクラウドインフラのおかげで誰でも簡単にサービスを立ち上げられる世の中になりました。 オープンロジも誰でも簡単に物流サービスを提供したいという思いがあり、物流のAWSと

おはこんばんちは。 がんばってブログを書きたいので、ちょうどいま読んでいるSQLアンチパターンという本を、噛み砕いて離乳食くらいの柔らかさにして晒してみます。すでに読んだ人はいますぐそっ閉じ、まだ読んでない人は、こちらも同様にそっ閉じしてお風呂に入ってすぐ寝ましょう。 SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 9人 クリック: 698回この商品を含むブログ (45件) を見る かなり圧倒的に当たり前のことしか書いてないんですけど、そういう本こそが良書だっておじいちゃんの息子の息子が言ってた気がします。 アンチパターンが全部で25個、ｶｯﾁｮｲｲタイトルとともに紹介されています。「目的」「アンチパターン」「解決策」をそれぞれ示します。本書だと、「アンとパターンを

質問をすることでしか得られない、回答やアドバイスがある。15分調べてもわからないことは、質問しよう！新規登録して質問してみよう

基本 普通にcookie使えばいいと思います。 loginリクエストもajaxで投げればcookie返ってくるので、何も考えることないかなと。 Cookie 動作イメージは以下の形です。 == サーバ → UA == Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com == UA → サーバ == Cookie: SID=31d4d96e407aad42 (from https://triple-underscore.github.io/RFC6265-ja.html) ブラウザの状態管理のためのもの。 もちろん主要ブラウザはどこも付いてます。 railsでもplayでもとりあえずこれでセッション管理されています。 secure属性があると、httpsのときだけやりとりされます。 HttpOnly属性があると、jsから読

名前 とりあえず削除フラグ 目的 エンドユーザから見るとデータがないことにしたいけど、実際のデータは消したくない 削除したデータを検索したい データを消さずにログに残したい 誤った操作をなかったことにしたい、直ぐに元に戻したい アンチパターン 例えばis_deletedというカラムがtrueの場合は削除されているとみなす メリット update文ならデータが簡単に元に戻せる気がするのでなんとなく安心 -> 俺のupdate文でなんとかなる！！ 起こること SELECTするときには常にWHERE句が追加で必要になり、コードが削除フラグだらけになる 全員テーブル設計に精通してるわけではないので、テーブルによって削除フラグの有無があったりした場合、認識の齟齬を生みやすい 例えばrubyでdefault_scopeを用いて、よかれとおもってコードレベルでデフォルトを変えたらバグがたくさん出てくる