タグ

webappに関するissmのブックマーク (81)

  • Node.js における Promise を使った例外処理 - from scratch

    さて、 Node.js のエラーハンドリングは難しいと言われてますが、 2016年現在、つまりNodeの v4 とか v6 が主流になり、 Promise が基的な処理として採用されている状況ではどうでしょうか。ちょっと考えてみます。 一応これの補足です。 qiita.com TL;DR 未だに難しい。ただし、 Promise で改善されている。async-await や zone まで来たらかなり楽になる。 あと、 unhandledRejection が uncaughtException よりも酷いことにならないので、大分マシになっている。 Node.js のエラーハンドリングの難しさ まず JavaScript には同期と非同期のエラーハンドリングのやり方があります。前者は所謂 try-catch による方法、後者は callback を使って第一引数で実現する方法や emit(

    Node.js における Promise を使った例外処理 - from scratch
  • マイクロサービスのトレードオフ | POSTD

    (編注:2020/08/11、いただいたフィードバックをもとに記事を修正いたしました。) マイクロサービスのアーキテクチャスタイル がモノリシックアーキテクチャよりも優れたアプローチであるというのは、多くの開発チームが実感していることです。その一方で、生産性を低下させる重荷のようなものだと感じているチームも存在します。プラスの面もあればマイナスの面もあるという点においては、マイクロサービスも他のアーキテクチャスタイルと変わりません。具体的なコンテキストに適用する前に、これらをよく理解して、賢明な選択をする必要があります。 マイクロサービスがもたらす利点 強固なモジュールの境界 :マイクロサービスではモジュラー構造が強化されています。この点は、チームの規模が大きくなるほどその恩恵は増してくるでしょう。 個別にデプロイ :サービスがシンプルなほどデプロイは容易です。また、マイクロサービスではそ

    マイクロサービスのトレードオフ | POSTD
  • Microservices とクラウド、それからオンプレミスの可能性について新卒Webエンジニア向けにまとめてみる - Qiita

    Microservices とクラウド、それからオンプレミスの可能性について新卒Webエンジニア向けにまとめてみるinfrastructuremicroservicesSOA これはなに この記事は 第2のドワンゴアドベントカレンダー のために書かれました。昨日は Rustで動的ライブラリに依存しないLinuxコマンドを作成する方法 について @sile さんが素晴らしい記事を書いて下さりました。Rust は難しくてよく分かりませんが、きっと素晴らしい言語だと思います。 さて今日は、Webサービスへの要求をみたすために、アプリケーションとインフラがどうやってコラボレーションするべきなのかについて考えます。私は 2015年新卒としてドワンゴに入社しました。この記事は私のような Webサービスエンジニア、システムアーキテクト初心者の方々を対象に書かれています。 もちろん、ドワンゴがいまどのよ

    Microservices とクラウド、それからオンプレミスの可能性について新卒Webエンジニア向けにまとめてみる - Qiita
  • ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ

    この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。 はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、PerlScalaGoもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談

    ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ
  • 書籍『Webアプリケーションセキュリティ対策入門』のCSRF脆弱性 | 徳丸浩の日記

    図のように、大垣のCSRF対策方式(以下、「大垣方式」と表記)では、トークン(同書ではフォームIDと表記)をランダムな鍵として生成(②)し、それをフォームの隠しフィールドとDBに保存します(③、④)。ユーザーがフォームをサブミット(⑤)すると、送信されてきたトークンがDB上に存在するか確認(⑥)し、あればトークンを削除(⑦)して、サーバー上の処理に進みます。⑥でトークンがDBにない場合は、エラーとして処理には進みません。 一般的なCSRF対策手法との違い 大垣方式が一般的なCSRF対策と異なる点は以下の2点です。 フォームの2重投稿防止機能を兼ねている トークンがセッション変数ではなくDBに保存される トークンの有効範囲は? トークンがDBに保存される場合、トークンの有効範囲が気になるところです。大垣および第二版のソースを見ると、トークンを保存するテーブルの定義は以下の通りです。 CR

  • Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ

    先月投稿した2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介しました。 今回は、前回同様、主に新卒Webエンジニア向けに、Webアプリケーションサーバとデータベースサーバ間の接続管理モデルと運用事情について紹介します。 データベース接続の永続化やコネクションプーリングとは何なのか、なぜ必要なのかといったことが主な話題です。 背景 データベース接続の永続化とはなにか データベース接続のオーバヘッド データベース接続の永続化手法 コネクションプーリングとはなにか コネクションプーリング: ドライバ型 コネクションプーリング: プロキシ型 コネクションプーリング全体について PostgreSQLMySQL 参考資料 まとめ 背景 2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャの話とWebアプリケーショ

    Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ
    issm
    issm 2015/06/30
    とてもよいまとめで勉強になる.特に「プロキシ型コネクションプーリング」という考え方を知れたことはよかった.
  • Perlはもう古い、これからはDocker - ゆううきブログ

    記事の内容はWEB+DB Vol.88 Perl Hackers Hub 第34回 に「DockerによるPerlのWebアプリケーション開発」という記事にまとめなおしていますのでそちらをご覧ください。 「Perl Hackers Hub」では、「DockerによるPerlのWebアプリケーション開発」と題して@y_uuk1さんにご執筆いただきました!Dockerの基的な考え方からPerlのWebアプリ向けのDockerfileの書き方まで、実践的な内容です! #wdpress— WEB+DB PRESS編集部 (@wdpress) 2015, 8月 22 この記事は Perl Advent Calendar 2014 の19日目の記事です。 Plack/Carton で構築したモダンな Perl の Web アプリケーションの開発環境を Docker 化するための試行錯誤を紹介します

    Perlはもう古い、これからはDocker - ゆううきブログ
    issm
    issm 2014/12/19
    脳内のベースイメージになるように何度も読む.
  • 全文検索可能な電子図書館を作ってみた - おんがえしの blog

    読みの図書館 http://honyomi.ongaeshi.me/ 先日リリースしたHonyomi1.0をベースに作成しました。 再配布可能な電子書籍を集めて全文検索出来るようにしてあります。 原文のpdfをその場で読んだりダウンロードしてオフラインで読むことも可能です。 気になったページにブックマークを付ける、メモを残す、他の人の書いたメモを読むことも出来ます。 詳しい使い方はこのサイトについてをどうぞ。 作った経緯 Honyomiという手持ちのpdfをまとめて検索したりメモを書けるツールを作っているのですが、自力で書籍サーバーを立ち上げて自分の蔵書を管理するのはやっぱり大変なので、やろう!って思ってもらえるように実際に動くものを立ち上げたいと思っていました。 立ち上げるにあたって「何のを置くか」というのが一番大切で自分が個人で使っている(有料の書籍がたくさん入った)Honyomi

    全文検索可能な電子図書館を作ってみた - おんがえしの blog
  • DockerにRijiを乗っけてみた | All Your Bugs Are Belong To Ass

    https://registry.hub.docker.com/u/ytnobody/docker-riji/ とうとう僕もdockerhubデビューです。過去、炎上案件ともボヤ騒ぎとも取れるようなエントリを公開し、それはそれは嗤い物にされるような内容でした。 そんな僕ですが、今あなたが見ているこのブログ、dockerで稼働しております。ええ、知の高速道路はありませんでしたが、知の一般道をひた走ってここまで来ました。 さて、このブログはRijiというブログツールが稼働しております。これは非常にシンプルなツールですが、細かい説明はこのあたりを見ていただくと良いと思います。 Rijiをdockerで稼働させたらどうだろうか このように考えたのは、Docker as a Service(DaaS) というものを使ってみたかったからなんですが、じゃあ何を稼働させようか・・・と考えた時に、「ああ、俺

  • Content-Security-Policy と nonce の話 - tokuhirom's blog

    Content-Security-Policy の nonce を利用すると、XSS の脅威をかなり軽減できます。 そこで、Web Application Framework ではデフォルトで対応したほうがよいのではないか、という旨を @hasegawayosuke さんから教えて頂いたので、実装について考えてみました。 とりあえず CSP の nonce はどういうものなのかを考慮するために、コード例を探していたのですが、実際に動くサンプルというものが nonce 関連のもので見当たりませんでした。 そこで、実際に動くサンプルを用意しました。 https://github.com/tokuhirom/csp-nonce-sample 以下は Sinatra で書かれたサンプルコードです。 require 'sinatra' require 'securerandom' get '/' d

  • ajaxでクロスドメインのAPIを叩く時にやったこと - itochin2の日記(仮)

    アプリのweb viiewから、ajaxでクロスドメインのAPIを実行しようとして とても大変な思いをしたので備忘録。 概要 APIサーバーから、アプリのWebViewで表示するHTML(文字列)を取得する HTMLの中で別サーバーのJSを読み込む。 JSからXMLHttpRequestでAPIを実行する。 APIはGETとPOSTの2種類。 APIサーバーはPerlで、WAFにAmon2を使用。 GETが失敗する件 ログを見ると、OPTIONSリクエストに403を返していた。 What is OPTIONSリクエスト? プリフライトリクエストという。 リクエストを送信しても安全か?サーバーがリクエストに対応しているか? ということを調べるために、ブラウザが特定の条件を満たす場合に飛ばす。 特定の条件 以下、HTTP access control (CORS) | MDNより引用。 GET

    ajaxでクロスドメインのAPIを叩く時にやったこと - itochin2の日記(仮)
  • Perl 初心者がウェブアプリケーションを書く時に気をつけるべきこと - tokuhirom's blog

    $c->req->param('id') みたいなメソッドは使ってはいけない。これは歴史的経緯から残っているものなので、基的に使わない方がいい。 $c->req->parameters->{id} をかわりに使ってください。 Perl の世界には List コンテキストというものがあって、これがウェブアプリケーションを開発するときには鬼門となります。 +{ id => $c->req->param('id') } のようなコードは、param メソッドはリストコンテキストではすべての id を返すので、 ?id=3&id=hasegawa&id=yosuke というようなクエリが来ている場合、 +{ id => 3, hasegawa => 'yosuke' } のようなデータ構造が作成される。これは明らかに意図していない挙動である。 以下の様にかくのがおすすめです。 my $id =

  • Reverse Proxyがなぜ必要か、勝手に補遺 - たごもりすメモ

    「全体のリソース効率を上げましょう」というためのものである。 Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー これは完璧に正しくて、ただ「リソース効率」という概念はあまり具体的な想像が追い付かない人がいそうだなと思ったので、ちょっとだけ補足しようと思った。 Reverse Proxyを入れることでリソース効率の向上を狙うんだけど、それは以下のような複数の場面におけるそれぞれのリソース効率向上を複合的に狙うものだ。 通常時のトラフィック配信におけるCPU・メモリ使用率を最適化する バースト時(過負荷時)のトラフィックをより細かく制御可能とする 障害時におけるダウンタイムおよび総合的な計算・配信能力の低下を極小化する 多数のサーバによる構成全体を増強・入れ替え・移動あるいは削減する際の自由度の向上を狙う 簡単にコンピュータの性能だけで言うと最初の項目だけをリソース効

    Reverse Proxyがなぜ必要か、勝手に補遺 - たごもりすメモ
  • Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー

    フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews この記事が目に入って読んでみた。なるほど、昨今は Reverse Proxy は便利な L7 ルーター的なものとして認識されているのだな、と思った。URL の Rewrite や、VirtualHost 云々。確かに Reverse Proxy の便利な側面ではある一方、それらは Nginx などの Reverse Proxy でなければ実装が不可能かと言えばそんなことはないものでもある。 自分は Reverse Proxy はもうすこしサーバー/インフラ的な側面でその役割を捉えている。今更何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。 Reverse Proxy はWebシステム全体のリソース最適化のためのパーツ Reverse Proxy のインフラ的な視点での役割は「Web

    Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー
  • Deploy to Heroku / Webアプリケーションのポータビリティ再び - naoyaのはてなダイアリー

    Heroku の新機能で Heroku Button が出た。 見るよりも、触る方が早い。以下のボタンを押すと md2inao をあなたの Heroku アカウントにデプロイして、動かすことができる。 ボタンを押すと以下のような画面が出て、Deploy to Free を押すと直ちにデプロイが始まる。 GitHub からソースコードが Heroku にデプロイされて、Web アプリケーションが動く。 ご満悦。 このボタンを README.md に置いておけば、Webアプリケーションを自分で動かしたいなと思ったユーザーが、自分自身の環境で好きな時にそれをデプロイして使うことができる。 すなわち、Heroku Button で、URI を介した Web アプリケーションの交換が可能になった。 Heroku Button Heroku Button を有効にするための前提は割とシンプルで Git

    Deploy to Heroku / Webアプリケーションのポータビリティ再び - naoyaのはてなダイアリー
  • ʕ  ゚皿゚ ʔ GolangのWeb Application Frameworkを色々試してみてもいいかしら? - ( ꒪⌓꒪) ゆるよろ日記

    うちのメロンちゃんはLv.117です。 Golangで、簡単なWebアプリケーションをいくつかのフレームワークを用いて作成してみた。 サンプルアプリケーションは、こんな感じのPhotoギャラリーアプリケーションで、画像URLを入力すると追加される。 PureというCSSフレームワークのサンプルから拝借した。 Photo Gallery – Layout Examples – Pure ソースコードはGithubで公開している。 yuroyoro/golang_webapp_framework_samples · GitHub 今回試したのは、net/httpパッケージ、Martini、 Revel の3つ。 net/http編 まずは基net/http編。ソースコードはこちら。 http - The Go Programming Language net/httpパッケージでサーバーを

    ʕ  ゚皿゚ ʔ GolangのWeb Application Frameworkを色々試してみてもいいかしら? - ( ꒪⌓꒪) ゆるよろ日記
  • Docker で Web アプリを運用してみた - kotas.tech

    Docker してますか! 実は実験的に Docker で Web アプリを数ヶ月運用しており、色々と試行錯誤してきたので、少しずつアウトプットしていきます。 ちなみに Ruby 製のアプリで、AWS の EC2 上で運用している、小〜中規模ぐらいのものです。 2014-06-16 16:00: 追記あり Docker イメージのビルドについて Dockerfile を普通に書いてます。 今のところ、2層構造にしていて、 ベースとなるイメージ Ruby アプリケーションサーバー (Puma) アプリケーションのソース (git clone) bundle install デプロイされるイメージ (ベースイメージを元に作る) git pull してソース更新 bundle install し直してベースにない gem を入れる asset の precompile という感じでやってます。

    Docker で Web アプリを運用してみた - kotas.tech
  • Module::CoreList の Web Interface を作りました - blog.nomadscafe.jp

    あるモジュールがPerlのコアモジュールに含まれているか、どのバージョンが含まれているかをたまに確認したくなりますが、その時に使うのが Modure::CoreList です。Modure::CoreListにはコマンドラインツールも用意されているのですが、tokuhiormが Web Interface版を作っていてとても便利でした。が、こちらは今404になってしまっているので、tokuhiromに確認の上、新しくサイトを動かしました。 http://corelist.rpee.be/ 画面はこんな感じ あるバージョンのperlにどのモジュールのどのバージョンが含まれているのかと、モジュールがどのPerlに含まれているのかのリストがでます。 もとのソースコードを参考にしつつ、Kossyとboostrap3で移植しました。移植するついでに、Proclet、Server::Starter、c

  • Router::BoomとRouter::Simpleの文字列エンコードまわりの動作 - Hateburo: kazeburo hatenablog

    昨日気付いた。 Router::Simpleはいわゆるutf8 flaggedな内部文字列を渡すと、キャプチャしたテキストも内部文字列として得られるけど、Router::Boomはバイナリ列となる。 use Router::Boom; use Router::Simple; use Encode; use Test::More; use utf8; subtest 'boom' => sub { my $path = '/foobarです'; my $router = Router::Boom->new(); $router->add('/:user', 'dispatch_user'); my @args = $router->match($path); is $args[1]->{user}, 'foobarです', 'match'; ok Encode::is_utf8($args[

    Router::BoomとRouter::Simpleの文字列エンコードまわりの動作 - Hateburo: kazeburo hatenablog
  • 平均レスポンスタイム50msをPerlで捌く中規模サービスの実装/運用

    5. 広告の目的? • 広告が成立する条件 • “出す”場所がある • “見る”人がいる • ”出稿”したい誰かがいる • 広告枠 : オーディエンス : 広告主

    平均レスポンスタイム50msをPerlで捌く中規模サービスの実装/運用