日本のWebデザインで見かける10個の特徴
ここ数年で、日本のWebデザインは大きく進化しました。 洗練されたデザインといえば、海外のものでしたが、今では日本でも数多く見られます。 デザインのスタイル、芸術的アプローチ、高度なソリューション、そして漢字や縦書きの文字を使ったデザインなど、日本のWebデザインで見かける10個の特徴を紹介します。 10 Distinctive Features of Japanese-Style Web Design 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 01. ハイテクな演出 02. 他とは異なるソリューション 03. 日本独自の配色 04. 縦書き 05. 自然の風景 06. 巧妙なヒーローエリア 07. アニメに影響を受けたイラスト 08. キャラクター 09. 日本の漢字 10. 日本の伝統的な音 01. ハイテクな演出 W
インフラエンジニアが一切コードを書かずにWebサーバーに認証機能を実装した話 ｜ Developers.IO
コンニチハ、千葉です。 AWSのサービスを組み合わせれば、独自の認証基盤を構築できます。例えば、WordPressを限定的に公開する、Apache、 Nginx、カスタムWebアプリなどなど、簡単に認証をかけたい場合、ベーシック認証は昔から利用されてきました。ただし、これはスケーラビリティや運用面でどうしてもつらい場面がでてきます。 そこで、ALBに素敵すぎる組み込みの認証機能が追加されたのでこちらを利用し、コードを一切書かずに認証を導入します。また、OIDCなど認証プロトコルに対応していますが、今回はシンプルにCognitoのユーザープールを利用し、ユーザー管理自体もCognitoに任せます。 要件 今回の想定する要件です。 Nginxを社内ユーザーのみに公開 スタンドアローンのユーザープールを用意(AD、OICD、SAMLなどによる連携なしで、独自でユーザーを管理) ユーザーは管理者が
手っ取り早くウェブアプリケーションにOAuth2認証を導入する - その手の平は尻もつかめるさ
bitly/oauth2_proxyを用いて，ウェブアプリケーションに手っ取り早くOAuth2認証を導入するという話です． oauth2_proxyは良い感じでOAuth2による認証を肩代わりしてくれる君で，何らかのリバースプロキシの認証機構と組み合わせて利用すると簡単にOAuth2ログインを実現することができます． 今回は例としてKibanaにGoogleのOAuth2ログインを導入してみたいと思います． 構成 Kibana bitly/oauth2_proxy nginx +------+ +-------+ +--------------+ +--------+ | | | | ----auth----> | | | | | user | --request--> | nginx | | oauth2_proxy | <--auth--> | Google | | | | | <--
Nginxのリバースプロキシでバックエンドとhttp2通信する - ASnoKaze blog
以前書いたとおり、ApacheではリバースプロキシでバックエンドとHTTP2通信することができます。 asnokaze.hatenablog.com Nginxの場合は、開発者のメーリングリストでGoogleの人が書いてる「ngx_http_v2_upstream」パッチを利用することでバックエンド(upstream)とHTTP2通信することが出来るようになります。 パッチ [PATCH 01 of 14] Output chain: propagate last_buf flag to c->send_chain() [PATCH 02 of 14] Upstream keepalive: preserve c->data [PATCH 03 of 14] HTTP/2: add debug logging of control frames [PATCH 04 of 14] HTTP/
CDN切り替え作業における、Web版メルカリの個人情報流出の原因につきまして - Mercari Engineering Blog
本日コーポレートサイトでお知らせした通り、Web版のメルカリにおいて一部のお客さまの個人情報が他者から閲覧できる状態になっていたことが判明しました。原因はすでに判明して修正が完了しております。また、個人情報を閲覧された可能性のあるお客さまには、メルカリ事務局より、メルカリ内の個別メッセージにてご連絡させていただきました。 お客さまの大切な個人情報をお預かりしているにも関わらず、このような事態に至り、深くお詫びを申し上げます。 本エントリでは技術的観点から詳細をお伝えさせていただきます。 2017年6月27日 CDNのキャッシュの動作について、CDNプロバイダと仕様について確認し検証を行いました。その結果一部記述に実際と異なる箇所があり、加筆修正いたしました。 概要 メルカリWeb版のコンテンツキャッシュをしているCDNのプロバイダ切り替えを行いました。 その際本来キャッシュされるべきでない
nginxによるTCPロードバランサー | メルカリエンジニアリング
SREチームの@cubicdaiyaです。今回はnginxによるTCPレイヤーでのロードバランスについて解説します。 ロードバランサーとしてのnginx nginxはHTTPやTCP、UDP等の複数のレイヤーでロードバランサーとして稼働させることができます。（TCPロードバランサーは1.9.0以降、UDPロードバランサーは1.9.13以降で利用可能です） また、ngx_http_ssl_module や ngx_stream_ssl_module を利用することでそれぞれのレイヤーでTLSを有効化することも可能です。 TCPロードバランサー用のモジュールを有効にする HTTPレイヤーでロードバランスするためのモジュールはデフォルトで組み込まれますが、TCP(とUDP)レイヤーでロードバランスするにはnginxのconfigureスクリプトに--with-stream(あるいは --with
Let’s EncryptのSSL証明書で、安全なウェブサイトを公開 | さくらのナレッジ
安全なウェブサイトを公開するため、無料で利用可能な Let's Encrypt の証明書を使う方法をご紹介します。Let's Encrypt の背景とSSL証明書の自動発行をはじめ、CentOS 7 上の Nginx ウェブサーバを SSL に対応する方法、そして、証明書を自動更新する方法を見ていきましょう（所要時間10～20分）。 なお、Let's Encrypt については既に中津川さんの記事「すべてのWebサイトの暗号化を目指すLet's Encryptを試す」で取り上げられていますが、今回は新しいクライアント certbot-auto を使う方法や、証明書の自動更新の仕方をとりあげます。 こんにちは！こんにちは！ みなさん、はじめまして。さくらインターネットの前佛雅人（ぜんぶつまさひと）です。さくらのナレッジに何か書け（業務命令）ということで、皆さんがサーバをより活用できるよう、ナ
光の速さのWEBサーバー(nginx)をlet's encryptでSSL化及びHTTP/2化。ついでにセキュリティ評価をA＋にする。 - Qiita
光の速さのWEBサーバー(nginx)をlet's encryptでSSL化及びHTTP/2化。ついでにセキュリティ評価をA＋にする。nginxCentOSSSLTLSLet’sEncrypt 前回のおさらい インフラ さくらのVPS(v4) SSD 1G CentOS7.2 (OS) ミドルウェア nginx 1.8.0 php7.0-fpm (アプリケーション） MariaDB(SQL) 5.5.44 フロントエンド Wordpress 4.4.1 前回の記事の通り、Ansibleであっという間に以上の構成のwebサーバーを組むことができました。今回の記事ではこれらを無料で証明書を発行するwebサービス、let's encryptを使ってSSL/TLS化しちゃいます。そして、ついでにSSLの評価計測サイトであるQualys SSL Reportのセキュリティ評価でA＋をもらっちゃいます
サーバサイドWebアプリケーションエンジニアにとって必携の一冊。「nginx実践入門」が発売されます | メルカリエンジニアリング
SRE(Site Reliability Engineering)チームの@kazeburoです。 1/16(土)にSREチームの久保(@cubicdaiya)が執筆に参加した「nginx実践入門」が技術評論社から発売されるので、紹介します。 gihyo.jp 電子版も同時に発売されます。こちらもどうぞ gihyo.jp メルカリとnginx このブログでもnginxの利用方法を何度も紹介していますが、メルカリではTLSのターミネーション、リバースプロキシや内部で使用する各種ミドルウェアのロードバランサーなどとしてnginxを利用しています。さらに、軽量スクリプト言語であるluaでnginxを拡張するngx_luaを活用してログ解析基盤を構築したり、ロードバランサーの動作をカスタマイズして一部ミドルウェアのレスポンス速度の向上を実現しています。nginxがメルカリのスケーラビリティを支えて
Let's Encryptとnginxでお金をかけずにHTTP/2サーバを立てる話を書いた - 最近のアクティビティ
最近話題のLet's Encryptを使って無料でSSL証明書を取得し、最近のnginxでHTTP/2サーバを立てる話を書きました。ピクシブ株式会社 Advent Calendar 10日目の記事です。 Let's EncryptとnginxでHTTP/2サーバを立てる - pixiv inside [archive] この記事を書いた経緯 皆さんはWebサービスで一発当てたいと考えたことはないでしょうか。私はあります。Webサービスで一発当てるためには、もちろんアイディアも重要ですがサービスの信頼性も大切です。今時、HTTPSで暗号化されていなかったり、オレオレ証明書でHTTPS通信を実現しているページに誰が個人情報を入力しますか？HTTPSに対応するには、証明書を買う必要があり、どんなに安くても年間3000円くらいはします。 いいドメインを取ろうとして、イケてる横文字のgTLDで取ろう
すべてのWebサイトの暗号化を目指すLet’s Encryptを試す | さくらのナレッジ
インターネットの爆発的な広がりに合わせてセキュリティ上の問題に注目が集まるようになっています。2010年頃にはFiresheepが広まり、公衆無線LANなどにつないだPCの通信を簡単にモニタリングできてしまう行為が問題になりました。また、昨今のプライバシーに対する懸念から、多くのサイトではHTTPSをデフォルトにするようになっています。 そんな流れもあって現在開発が進められているのがLet's Encryptです。誰でも無料で使えるSSL/TLS証明書発行サービスとなっています。先日、ついにパブリックβになり、誰でもすぐに使えるようになりました。そこで今回はLet's Encryptを使ったサイトのSSL/TLS化手順について紹介します。 なお、執筆時点ではApacheについてはプラグインが提供されていますが、nginx向けは開発中とのことです。ただし手作業で行う分にはnginxでも利用で
nginx の設定をレビューするときの観点をまとめてみた - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。 インフラチームの野島（@nojima）です。 チームのメンバーに nginx の設定について気をつけるべき点を共有するために、レビュー観点を書きました。 せっかくなのでここで公開します。 ほとんどの項目は自分やチームのメンバーの実体験に基いています。 レビュー観点 server server_name が他のやつと被っていないか。 listen する IP アドレスが同じ場合、server_name で区別できないといけない。 TLS を使う場合、SNI をサポートしないクライアントでは TLS 用の設定が default_server のものが使われる点にも注意。 TLS を使う場合、listen ディレクティブに ssl オプションを書いているか。 location location のマッチの順番に注意 正規表現の location は前方一致の location より
nginx で omniauth を利用してアクセス制御を行う - クックパッド開発者ブログ
インフラストラクチャー部 id:sora_h です。クックパッドでは、社内向けの Web アプリ (以降 “社内ツール”) を社外のネットワークから利用する際、アプリケーションレベルでのアクセス制御とは別に、リバースプロキシでもアクセス制御を実施しています。*1 これまで BASIC 認証あるいは VPN による社内ネットワークを経由した接続という形で許可していました。しかし、iOS の Safari などでは BASIC 認証時のパスワードを保存できない上、頻繁に入力を求められてしまいますし、VPN はリンクを開く前に接続をしておく必要があります。これにより、社内ツールを社外で開く時に手間がかかってしまう問題がありました。 これに対し、一部では typester/gate などを導入し Google Apps での認証を行なっていました。しかしいくつか問題があり、非アドホックな対応では
nginxをWebSocketのリバースプロキシとして使う - the glue
経緯 WebSocketを使ったアプリケーションを作ったが、ポートが80しか使えない nginxでどっちも80に流したい ポイント / はまり所 WebSocketのプロキシにはUpgradeヘッダ(HTTP 1.1)への対応が必要 Upgradeヘッダへの対応は nginx v1.3.13以降 参考: WebSocket proxying 厳しい条件から先に書く デフォルトだと30秒通信がないと切断される（！） nginxでリバースプロキシしているときだけ一定時間で接続が切れるので何かと思えば、 普通のHTTPの通信と同様に30秒（だったはず）通信がなかった場合はタイムアウトってことで自動でコネクションを切ってくれていたみたい。 ping/pongを30s以内にやればいいんだろうけど、とりあえず5分に設定。 config server { listen *:80 default_serv
がんばらない動的画像変換サーバーのつくりかた - スパイスな人生
tmixエンジニアのid:ksssです。 今年の夏も暑いですね。 僕は最近tmixで作ったドライTシャツを着て、朝のランニングで体力づくりに取り組んでいます。 http://tmix.jp/designs/2052395 このTシャツには、プログラマー界での有名な言葉をもじって「ぐだぐだ言ってないで、走れ！」という意味を込めていて、なまけがちな自分をとっとと走りに行かせようと意識をたかめています。 今回はここに表示されている画像の裏側についてお話したいと思います。 動的画像変換 このTシャツ画像はリクエストを受けたときに指定のサイズの画像を生成して返しています。 動的画像変換を使うと、管理するファイルの削減や、事前処理の単純化、デザインへの柔軟対応などのメリットがあり、tmixでも様々なページで使われています。 動的画像変換には様々な実装がありますが、tmixではあまりがんばらない動的画像
Nginxと名前解決の話 - Masteries
Nginxでは, serverコンテキストのlocationコンテキストにおいて, proxy_passディレクティブを利用することで任意のホストにアクセスを転送することができます. 例えば, serverコンテキストにおいて, location / { proxy_pass http://127.0.0.1:5000; } みたいに書いてあげれば, localhostの5000番ポートにアクセスを転送することが出来ます. Webサービスでは, こういう感じでNginxが443番(HTTPS)や80番ポート(HTTP)で受けたアクセスを5000番ポートなどで動いているWebアプリケーションに転送している訳です. で, このproxy_passディレクティブは, IPをそのまま書くのではなく, 次のようにドメインを書くこともできます. location / { proxy_pass http
rails4 + unicorn + nginx - Qiita
@app_path = '/home/rails/rails/test/json_server' worker_processes 2 working_directory "#{@app_path}/" preload_app true timeout 30 listen "/tmp/unicorn.sock", :backlog => 64 pid "/tmp/unicorn.pid" stderr_path "#{@app_path}/log/unicorn.stderr.log" stdout_path "#{@app_path}/log/unicorn.stdout.log" before_fork do |server, worker| defined?(ActiveRecord::Base) and ActiveRecord::Base.connection.disconnec
Nginx+Luaで実装したリバースプロキシをDockerとGoで自動テストした - Qiita
Nginxでリバースプロキシしつつlua-nginx-moduleを使ってリクエストやレスポンスを書き換える。図にするとこんな感じ。 client proxy app | 🍣 | 🐟 | |-------> 🐟 -------> 🐟 | 🍣 🍚 🐟 | |<--------|<----------| クライアントから寿司が送られてくるけどアプリケーションはネタだけ受け取りたいのでシャリはプロキシに抜いてもらう。 アプリケーションからのレスポンスにはさっきのネタが含まれているので、プロキシはシャリを戻してクライアントに返してあげる。 ローカルにOpenResty入れて適宜luaファイルを書き換えてcurlを叩くとかでもいいんだけど、絶対あとからだるくなってくるのでDockerでコンテナを立ち上げて、それに対してリクエスト投げるテストを書くことにした。 Dockerファイルはこち
HTTP2 時代のサーバサイドアーキテクチャ考察 - Block Rockin’ Codes
update 色々と twitter で議論が起こったのでまとめて貼っておきます。 togetter.com みなさんありがとうございました。 intro HTTP2 の RFC 化も目前ということで、そろそろ実際に HTTP2 を導入していくにあたってサーバサイドの構成についても、具体的にどう変わっていくかという点を考え始めていく必要があります。 そんな話を @koichik さんとしていたら、色々と考えが膨らんだのでメモしておきます。 前提 今回は、中規模のサービスを想定し、特に HTTP2 のサーバプッシュを踏まえた上でのコンテンツ配信などに、どういう構成が考えられるかを考えていきます。 また、本エントリ内では独自に以下の表記を採用します。 HTTP/1.1 = HTTP/1.1 (平文) HTTP/2 = HTTP/2 (平文) HTTPS/1.1 = HTTP/1.1 over
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch | Startup and Technology News
