# 参考資料 - https://speakerdeck.com/hanhan1978/purohuairawoshi-tutaphpapurikesiyongai-shan-falsekan-suo - https://speakerdeck.com/hanhan1978/web-applicat…
Webアプリケーションのパフォーマンス・チューニングの勘所 / web tuningperformance
# 参考資料 - https://speakerdeck.com/hanhan1978/purohuairawoshi-tutaphpapurikesiyongai-shan-falsekan-suo - https://speakerdeck.com/hanhan1978/web-applicat…
著名なオープンソースRailsアプリのapp/以下を見る
Railsにおける app/ とは app/はRailsのアプリケーション用ディレクトリで、普通のRailsアプリケーションでは、この下にmodels,controllers,viewsを含めた様々なディレクトリが作られます。 基本的には新しいディレクトリを追加する必要はないのですが、アプリケーションが複雑になると、Railsを拡張するべくここにアプリケーション固有のディレクトリを作って、その下に関連するファイルを置くことがあります。 中には、servicesやserializersのように、多くのRailsアプリケーションで見られるものもあれば、完全にアプリケーション独自のものが作られることもあります。また、アプリケーションによっては独自のディレクトリは一切作らないものもあれば、大量に作るものもあります。それぞれアプリケーションの開発方針によるものです。 本記事では、比較的有名なOSSの
ボトムアップドメイン駆動設計
はじめに この記事は前後編に分かれています。 順序だてた解説になっているので最後までお付き合いいただけると幸いです。 後編記事: https://nrslib.com/bottomup-ddd-2/ 順序立っての説明になっておりますので、前編からご覧になることを強くお勧めします。 セミナー情報 こちらの内容のセミナーを不定期で開催しています。 ◆セミナーページ 第一回: https://ddd-community-jp.connpass.com/event/103428/ 第二回: https://ddd-community-jp.connpass.com/event/107106/ 第三回: https://nrs-seminar.connpass.com/event/117283/ ◆あとがき 第一回ボトムアップドメイン駆動設計勉強会を開催しました セミナースライド まえがき この章は
RDBの作成時刻や更新時刻用カラムに関するプラクティス | おそらくはそれさえも平凡な日々
RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_
Laravel で Service 層を取り入れるときに検討したいこと - Qiita
この記事について 普段何気なく使っている Service クラス（Service 層）について、書籍を中心にその役割や目的について書かれた資料を読みながら、Laravel 製のウェブアプリケーションに Service 層を取り入れる際の判断材料となるような情報や観点を、提供できればと思います。 以前にも調べたり考えたりしたんですが、そのときは明確な役割や使い方の提案ができなかったので、それの補遺的な位置づけになります。 Laravelでウェブアプリケーションをつくるときのベストプラクティスを探る (9) Service編 - Qiita Service レイヤーとは これ 出典: Martin Fowler's Bliki https://martinfowler.com/eaaCatalog/serviceLayer.html どんなときに Service 層が必要になるか Despit
Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
Rails を使った EC アプリケーション開発について学べる本 "Take My Money" を読んだ - kymmt
読みました。 Take My Money: Accepting Payments on the Web 作者:Rappin, NoelPragmatic BookshelfAmazon どんな本か 副題が "Accepting Payments on the Web" となっているように、決済 (payment) システムをもつ Web アプリケーションを作る方法について説明しています。『達人プログラマー』などでおなじみの The Pragmatic Bookshelf シリーズの本です。 チケット販売システムの開発を通して、次のような具体的な話題に触れています。基本的には Rails 5 を使ってロジックからビューまでを開発していきます*1。 決済システムの実装 ショッピングカート 外部決済サービスとの連携 サブスクリプション機能 エラーケースとその対策 管理画面の実装 返金など注文の操
機械学習素人が2か月半で機械学習を入門したことまとめ - あさのひとりごと
ちまたでは、機械学習がブームのようです。 が、、まったく時代についていけていません。 しかし、機械学習、特に自然言語処理に精通した人の採用にかかわる仕事をしている、、、 にもかかわらず、自然言語処理どころか機械学習が全く分からない。 これでは、いけない。ということで 「機械学習をたしなむ学生の皆さんと、ふわっと雑談ができるレベル」 を目指して、2017年正月明けから勉強を始めました。 ちなみに、どんなにキリが悪くても1日3時間まで！と決めています。 そもそも機械学習に興味関心があるわけではない やらなければならない他の仕事がある 家事育児が優先 なので、すこしでも無理すると続かないためです。 「AIで世界を変えられる！」 「人工知能で想像もできない未来が、、、」 みたいなご時世の中、ありえないほどの低テンションで淡々と勉強しているわけで 逆に、そういう意識低い系人間はそんなに多くないでしょ
GoでWebアプリケーション作る練習をした - はこべにっき ♨
GoでWebアプリケーションを書いてみる練習として RequestBin ぽいものを試しに作ってみた。gomibakoという名前であまりひねりはない。以下のURLで試せます。 https://gomibako.douzemille.net/ ソースコードもGitHubに公開してある。 github.com 何ができるか HTTPリクエストを受け付ける用のURLを作ることができて、そのURLに対するHTTPリクエストのログをWeb上で確認することができる。ちょっとしたWebHookの動きのチェックとかリバースプロキシの設定確認とかに使えて便利。 具体的には以下の様にして使える https://gomibako.douzemille.net/ にアクセスして "New Gomibako" ボタンを押す https://gomibako.douzemille.net/g/deadbeaf123/
アセットパイプライン - Railsガイド
本ガイドでは、必要なアセット管理タスクの処理方法について解説します。 このガイドの内容: アセットパイプラインについて Propshaftの主な機能とセットアップ方法 SprocketsからPropshaftへの移行方法 より高度なアセット管理用ライブラリの利用法 1 アセットパイプラインについて Railsのアセットパイプライン（Asset Pipeline）は、JavaScript、CSS、画像ファイルなどの静的アセットを整理・キャッシュ・配信するために設計されたライブラリです。これらのアセットの管理を合理化および最適することで、アプリケーションのパフォーマンスとメンテナンス性を高めます。 Railsのアセットパイプラインは、Propshaftによって管理されています。Propshaftは、基本的なアプリケーションにおけるトランスパイルやバンドルや圧縮が、ブラウザでのサポート強化やネッ
複雑な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アプリケーションを作るにあたりドメインモデルをどう実装するか悩んだ 色々と試行錯誤した
Web開発でもアプリ開発でも使える状態遷移図を自動生成するツールを作りました - Qiita
概要 先日こちらの記事でgraphvizを使って状態遷移図を作成する方法をご紹介したのですが、これでもまだ複雑で記述量も多いのでとっつきづらいと思い、このgraphvizのソースコードを自動生成して画像を出力するコマンドラインアプリケーションを作成しました。 このアプリケーションはPyagram（ぱいあぐらむ）といい、その名前から察しがつくかと思いますがPythonを使用して開発されました。開発期間は１日でした。 このPyagramを使うことで複雑な状態遷移図を比較的簡単に作成することができるようになりますので、以下でご紹介したいと思います。 状態遷移図の描き方についてはこちらの記事を参考にしています。 出来上がりの図は以下のような感じになります。 図には幾つかのオブジェクトがあります。 図のタイトル（最上段） ビュー（二重丸） サーバサイドの処理（灰色の背景の一重丸） 画面遷移（破線の矢
SPAである価値 - nobkzのブログ
以前、少し前だが、以下のブログを読んで、SPAであるべき価値について考えたことを述べる。 anond.hatelabo.jp mizchi.hatenablog.com そもそもSPAとは? この議論をする前に、そもそもSPAとは何だろうか?という点について整理しておこう。僕は2つの点で特徴があると思っていて、 フロントエンドGUIであること Webアプリケーションであること この2点かなと思う、簡単にまとめると、 フロントエンドGUIであること まずは、「フロントエンドGUI」というのはどういうことかと言えば、サーバーサイドレンダリングとは対照に、jsによるDOM操作によって、UIを切り替えて行って構成するGUIを指す。 Webアプリケーションであること GUIではあるのだが、それは、Webアプリケーションでもある。サーバーからAjaxやwebsocketなどによって、サーバとデータのや
インフラを意識してコードを書くということ - Hatena Developer Blog
チーフエンジニアの id:Songmu です。 4月に 新人エンジニア研修を行なった のですが、その際に、「インフラを意識したアプリケーションの書き方」という講義を担当しました。そこでおこなった講義の内容について整理しながら書き起こしていきたいと思います。 インフラを意識すると何が良いか 業務でWebアプリケーションを扱うと、個人ではなかなか扱えないトラフィックであったりデータ量を扱うことになります。小規模サービスでは考えなくてよかった多くのことを考慮する必要がでてきます。なかなか体験できないことでもあるので、楽しく、やりがいもあります。 また、そういった経験を通して、インフラを意識しコードをかけるスキルを身につけることは、Webエンジニアとしては大きな強みとなります。ISUCONで優勝できるかもしれません*1。 インフラを意識すると何が良いか 〜 中規模ベンチャーの場合 そもそも、はてな
10年のツケを支払ったフロント界隈におけるJavaScript開発環境（2016年4月現在）。 - 日々、とんは語る。
2015年はCSSが普及した以来となる10年に1度のフロントエンド大変革期で、それまでのツケが一気に回ってきたと個人的に感じていました。目まぐるしく状況が変化していきましたが、2016年になり、個人的にだいぶ落ち着いてきたと感じているので、ここらへんでまとめておきたい思います。 最初に結論を書いておくと、 『React + Redux + react-router + material-ui + axios + ES2015 + Babel + webpack + ESLint + Airbnb JavaScript Style Guide』 という組み合わせが、いま僕の採用しているJavaScriptの環境です。 主要ライブラリは React A JavaScript library for building user interfaces | React 去年、一気に普及したReact
2016年、C言語はどう書くべきか (前編) | POSTD
(訳注：2016/3/2、いただいた翻訳フィードバックをもとに記事を修正いたしました。) (訳注：著者のMattより、「本文中で明言はしていないが、この記事の内容はx86-64 Unix/Linux/POSIXでアプリケーションをプログラミングする場合にフォーカスしている。他のプログラミング領域では、対象とするシステムに応じた(例： 8-bitの組み込みシステム、10年前のコンパイラ、多くの異なるCPUアーキテクチャで動く必要のあるアプリケーション、Win/Linuxでのビルド互換性など)特有のアドバイスが必要」との補足を頂いております。) 以下の文章は2015年の始めに書いたドラフトで、今まで公開していませんでした。私のドラフト用フォルダの中で誰の目も引かなかったため、大部分が書いた時のままです。公開するにあたり、単純に2015年を2016年に変更しました。 必要な修正、改善、苦情があり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Webアプリエンジニアに贈る アプリケーション開発におけるサーバーレス流の考え方 / The concept of serverless in application development
ウェブセキュリティの最近の話題早分かり
http://post.simplie.jp/posts/39
harold-spm.com