複雑なJavaScriptアプリケーションを考えながら作る話
autoscale: true theme: Plain Jane,5 複雑なJavaScriptアプリケーションを考えながら作る話 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info #jsprimerを書いています JavaScript入門書に興味ある人はウォッチ :star: :warning: 注意 :warning: 作成するアプリケーションによって必要な構造は異なります 今回の話はある程度の規模で複雑性を持つクライアントサイド ライブラリ抜きで数万LOC >= 長期的にメンテンナンスや変更が発生するアプリケーション サーバサイドレンダリングはしないクライアントアプリケーション 3行でOK 複雑なJavaScriptアプリケーションを作るにあたりドメインモデルをどう実装するか悩んだ 色々と試行錯誤した
綺麗なAPI速習会 - Qiita
Wantedly Engineer blogに本速習会資料を閲覧向けに再編しました！ ぜひご覧いただけると幸いです！ 本記事は、綺麗なAPI速習会@Wantedlyの資料として作成されたものです。 同時にこちらのコードも参照してください。 マイクロサービス 流行りのマイクロサービス、何がいいのか 各々自由な言語やArchitectureでサービスを立てられる 障害の影響が部分的 変化に強い 個別デプロイ etc... マイクロサービス化をすすめるにあたり、やりとりは全てAPIで行う 内部のAPIであっても外部に公開できるようなクオリティのAPIを作成し、それを元にサービスを作っていくことが重要 APIGatewayとBFF API Gateway Pattern 公式サイトより 「見た目はモノリシック、実装はマイクロサービス」 一箇所見に行けば全てのAPIを見つけられる 細かい権限管理も可
より良いCSSを書くための様々なCSS設計まとめ
CSSは誰でも簡単に自由に書けるのですが、好きなように書いていると「ここを変更したら、違うところが崩れた」といったようにすぐに破綻してしまいます。 さらに、複数人で書いている場合は、各々が好きなように書いて読むだけでも苦痛なCSSが出来上がってしまいます。 そこで、これらの問題を解決するために考えられたのが「CSS設計」です。 今回は記事が長くなり過ぎるので、CSS設計の概要のみを説明し、参考となる公式ドキュメントへのリンクを記載しました。 CSS設計とは CSS設計は、CSSを記述する時のルールとなるものです。プロジェクト毎に適したCSS設計を採用することで、「良いCSS」にすることができます。 最近では、命名規則はBEMで、構成はSMACCSのように各CSS設計の概念を取り込んだオリジナルの規約をつくるといったことも多いようです。 「良いCSS」とは 「良いCSS」の定義として、おそら
私がMVCフレームワークをもはや使わない理由
数ヶ月前、私はなぜここにたどり着き、何が可能かを理解する旅に出ました。この旅は、私にアプリケーションアーキテクチャ、MVCという強烈な宗教に対する疑いをもたらしました。そして、リアクティブ、関数型プログラミングの真の実力に触れたのです。また、シンプルさに集中する旅でもあり、私たちの産業はうまくやっているという考えを捨てる旅でもありました。どんなことを見つけたか興味がある方もいるでしょう。 私たちの見ている画面の背後にあるパターンはMVC –Model-View-Controllerです。まだウェブがなくソフトウエアアーキテクチャも分厚いクライアントが単一のデータベースに原始的なネットワークでアクセスするのがせいぜい、という時代にMVCは生まれました。そして数十年後、MVCはまだ現役であり、衰え知らずでオムニチャネルアプリケーションの開発に使われています。 Angular2のリリースの前にM
バッチ処理の設計書の書き方について質問です。「コードを見ずに設計書だけでテスト仕様書を作れ」と指示されて、設計書を見ていま... - Yahoo!知恵袋
バッチ処理の設計書の書き方について質問です。 「コードを見ずに設計書だけでテスト仕様書を作れ」 と指示されて、設計書を見ています。 バッチ処理の設計書の書き方について質問です。 「コードを見ずに設計書だけでテスト仕様書を作れ」 と指示されて、設計書を見ています。 これは上司が新規でつくった設計書なんですが、エラー処理への分岐が書かれていません。 正常処理の分岐しか書かれていません。 エラーメッセージの一覧表はもともとあり、それを見てメッセージからどんなときにエラーがでるのか推測しろ、と指示されました。 今後のために聞きたいのですが、設計書というのは正常処理だけを記述するものなのでしょうか？ (別の現場も経験したことがあるのですが、大手企業向け業務系システムでがちがちな設計書しか見た事がありません) どこの現場もそのようなものでしょうか？
米マイクロソフト本社で目の当たりにしたビル・ゲイツの決断力
６月１日発売の『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』には、いくつかマイクロソフト時代のエピソードが書かれていますが、これもその一つです。この「シカゴ対カイロ」の社内抗争はマイクロソフト時代の思い出の中でも、筆頭のものです。 ◇ ◇ ◇ ビル・ゲイツの意思決定は光速 ビル・ゲイツが仕事で重要視していたのは、＂光速＂と言っても過言ではない迅速な意思決定です。これについては、どのくらい迅速だったかを象徴するエピソードを紹介します。 あれは忘れもしない1995年1月、シアトルの冬らしい小雨の降る昼下がりのことでした。米マイクロソフト本社内にはＯＳの開発に関する派閥争いがありました（ＯＳとはマイクロソフトで言うWindows Vistaだったり、アップルでいうところのOS Xなどのパソコンやスマホを動かすための基本ソフトのこと）。＂カイロ＂というグループと＂シカゴ＂という
コンピューターを破壊する不運な名前を持つ人々 | スラド IT
BBCが、「不運にもコンピュータを壊してしまう名前を持つ人々」を紹介している（Slashdot）。 紹介されている1人目はJennifer Nullさん。Nullさんが飛行機のチケットを購入しようとすると、ほとんどのWebサイト上でエラーメッセージが表示されるという。彼女の姓である「Null」を入力しているにもかかわらず、「姓の項目にスペースを入れていませんか、入力を確認して再試行してください」といった表示がされ、電話で航空会社に問い合わせても説明が理解されなかったり、解決方法はないという返答が戻ってくるという。また、航空会社だけでなく政府の納税関連Webサイトなど、ほかのサイトでも同じような問題に悩まされるという。 同様の問題を抱える名前を持つ2人目は、ハワイのJanice Keihanaikukauakahihulihe'ekahaunaeleさん。こちらは姓が長すぎて入力できないとい
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
カクヨムは担当者レベルの想定が甘いからもうチョット揉めるだろ
オッス、オラCGM関連のお仕事関係者！ 季節外れのインフルエンザだよ！ カクヨムは出版社の都合優先し過ぎの漁場設計だから上手く行ってないな。 （下読み素人にさせてピックアップ後のだけ編集者が読みたいとか、そういうね） お話の前提カクヨムは、Consumer Generated Media（消費者作成メディア、略してCGM）そのものなのよね。 つまり、「運営が選んでなんかする」んじゃなくて、 「小説を書く人」が「小説を書いてコンテンツを作る」「小説を読む人」が「小説を読んでコンテンツを評価する」運営は場を提供すれば、勝手に面白いものが増えて、 勝手にピックアップ（下読み）が完了する、美味しいプラットフォーム。 カドカワにとっては、美味しい漁場ね。 という企画書になってるハズ。 非対称性が存在しないとうまくいかない評価Youtubeとかニコニコが曲がりなりにも回るのは、暴力的なまでに圧倒的多数
pelletkachels | blog over bedrijven en feitjes en de pelletkachel
Welkom bij Pelletkachels.nl, jouw ultieme bron voor alles wat met pelletkachels te maken heeft! Maar we zijn meer dan alleen een platform voor het bespreken van warmtebronnen. Bij Pelletkachels.nl geloven we dat het delen van kennis en ervaringen over bedrijven en gebeurtenissen ook essentieel is voor het creëren van een betrokken en geïnformeerde gemeenschap. In dit blog duiken we dieper in de we
Java/Androidにおける例外設計、あるいは「契約による設計」によるシンプルさの追求 - Qiita
なぜ今Javaの例外処理か Javaにおける「チェック例外」はSwift、Objective-C、Ruby、JavaScriptといったネイティブ・ウェブアプリ開発でよく用いられる他の言語には現れないものです。 SwiftにはOptionalやErrorTypeがありますが、Javaにおいてもnullやエラーのハンドリングの実装方法をうまくやる必要があります。 なぜ例外を握りつぶしたらいけないのか、なぜアサーションが望ましいのか、なぜチェック例外と非チェックを分けたのか、という点を考えてみたいと思います。 参考資料 例外設計における大罪 （契約プログラミングについて） Effective Java読書会9日目 - 例外 （Javaにおける例外の扱いについて） 契約による設計から見た例外 （この記事の方がより詳しいけど難しいイメージ） チェック例外と非チェック例外の違い チェック例外→「回復
モンストを支えるインフラの今とこれから
dots. Conference Spring 2016 ゲーム開発の裏側 http://eventdots.jp/event/580344
ロードバランサのアーキテクチャいろいろ - yunazuno.log
少し前に，Facebookのロードバランサが話題になっていた． blog.stanaka.org このエントリを読んで，各種Webサービス事業者がどういったロードバランスアーキテクチャを採用しているのか気になったので調べてみた． ざっくり検索した限りだと，Microsoft, CloudFlareの事例が見つかったので，Facebookの例も併せてまとめてみた． アーキテクチャ部分に注目してまとめたので，マネジメント方法や実装方法，ロードバランス以外の機能や最適化手法といった部分の詳細には触れないことにする． 事例1: Microsoft Azure 'Ananta' MicrosoftのAzureで採用されている(いた？)ロードバランサのアーキテクチャは，下記の論文が詳しい． Parveen Patel et al., Ananta: cloud scale load balancing
スケールアウト再考
Mercari JPのモノリスサービスをKubernetesに移行した話 PHP Conference 2022 9/24Shin Ohno
[意訳]グローバルCSSの終焉 - Qiita
このポストは以下の記事の意訳です。 The End of Global CSS 何か間違いなどありましたら、ご指摘いただけると幸いです。 (以下、訳) CSSセレクタはすべて同じグローバル空間に存在しています。 CSSに触れた人は皆、以下のような見解に至っていることでしょう。 CSSの考えはドキュメントの時代に設計されたもので、今ではモダンなウェブアプリケーションのためのマトモな開発環境を提供することが困難であると。 全てのセレクタには意図しない副作用を起こす可能性があり、期待と違う要素にスタイルが適用されてしまったり、他のセレクタと競合してしまったりします。さらに驚くべきことに、セレクタはグローバル空間で詳細度の競争に負けることもあり、ページのデザインに全く影響を持たなくなることだってあり得るのです。 CSSファイルを変更する時はいつでも、スタイルが適用されるグローバル空間について慎重に
![[意訳]グローバルCSSの終焉 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/43753a0361c196b5cec5a61c39a24a5c7a8e7fbb/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCJUU2JTg0JThGJUU4JUE4JUIzJTVEJUUzJTgyJUIwJUUzJTgzJUFEJUUzJTgzJUJDJUUzJTgzJTkwJUUzJTgzJUFCQ1NTJUUzJTgxJUFFJUU3JUI1JTgyJUU3JTg0JTg5JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz02NzJjZmQwODQ0NWVkYjNhNmJkMDY2YzE0YWI0NGRiOQ%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwY2h1Y2swNTIzJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0wYmU4Nzk0Mzg4MjBiNjRhMWVlMGFkNmI1NTI5MTg5ZA%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Dcd956fcbc979fa49122abb897262b937)
MVCモデルにおけるサービスの役割について教えて下さい
CakePHPという、1つのフレームワークの中での、1つのとらえ方については 他の方の回答が参考になると思いますが、一歩引いて一般的にMVCとサービスというのがどういう関係にあるのか、それぞれの言葉の意味という点で回答します。 質問ではMVCについて、次のように書かれています。 コントローラはユーザからの要求に対して必要な処理を抽出し、 ビューは結果などを伝えるために表示するもの、 モデルはコントローラから要求される処理をまとめておくものだと認識しています。 この分類はそんなに間違っているということはありません。しかし、実際「コントローラから要求される処理」にはいろいろな種類のものがあります。たとえば、 DBに情報を保存する／DBから情報を取得する メールを送信する アップロードされた画像ファイルのサムネイルを作成する があります。これらの何がモデルで、何がビジネスロジックで、何がサービス
MVCについて考える
はじめに こんにちは。今年の3月からKRAYに入社した阿部です。 ブログには初登場になります。 今日は、昨今のアプリケーション開発では誰もが耳にしているであろうMVCパターンを取り上げます。(以下MVCと呼びます) 開発者それぞれで理解や解釈が違っていることが多く、しばしば議論を呼び起こします。「ぼんやり」と理解したままの方も多いのでは無いでしょうか？ 私もある程度、開発で実践してみるまでは、なかなか良い形でMVCを適用することが出来ずにいました。皆様のMVCへの理解を少しでもクリアに出来れば幸いです。 定義をおさらい MVCは図で示されることが多いですね。 Wikipediaを見るとMVCの典型的な相関図が掲載されています。 (Wikipedia日本語版 Model View Controller より) Wikipedia英語版にも掲載されているこの図ですが、かなり上のレイヤから見た考
俺が勝手に考える正しいMVCの実装。モデルはデータAPI！ - はかますたいる！きょろの技的雑記
最近、一緒にコードを書く人（特にRailsから始めた学生さん）に、 MVC（Model - View - Controller）において、「model = DB」だと考えている人が多いなぁと感じたので、このあたりに関する自分の考えをまとめて書いておきます。 あくまで俺の考えなので、違ってたらごめんね。 MVCをちゃんと理解している人には当たり前すぎる話かもなのでスルーでよろしく！ 初学者はViewをモリモリ生やす これはプログラミングを始めた人なら誰でも経験ありますよね。 むしろ、MVCとか始める前の、誰でも経験あるであろう <?php print '<a href="${hoge}">link</a>'; なんてのは完全にViewだけで実装されたプログラムですね。 最近のMVCのテンプレートはとても高機能です。 変数の宣言も、条件処理も、ループも、プログラム言語としてひと通りの「逐次、反
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
トランザクションの設計と進化
スマートフォンゲームのチート事情
