CSSのfont-familyで游ゴシックを指定すると、Windowsで細くなってしまう問題の原因と解決方法を中心として、最近の日本語フォント事情をまとめました。 CSS Nite LP47 Coder's High 2016にてお話した内容です。 昔からマークアップエンジニアを悩ませて…
5. 現在までの流流れ 2012/01: IETF HTTPbis WGで次世代のHTTPの話が出始める 2012/06: HTTP/2の議論論を開始するための草案が提出される 2012/11: SPDYを議論論の開始点として策定が始まる 2013/01: 最初の草案がリリースされる 2013/08: 最初の実装向け草案がリリースされる 2014/05: <今はココ!> 2014/07: 最終草案リリース (WGラストコール) (予定)
RESTful APIの記述標準化を目指す「Open API Initiative」をマイクロソフト、Google、IBMらが立ち上げ。Swaggerをベースに 10年以上前、XMLの登場に続いてXMLベースのAPIを記述する標準フォーマット「WSDL」が提唱されました。 WSDLにはAPIの仕様がマシンリーダブルな形で記述されており、APIを呼び出すためのプロトコルやデータフォーマットをあらかじめ知ることができます。WSDLを利用することで、APIをコールするためのコードを自動生成することが可能でした。 しかしXMLベースのAPIは期待されたほど普及せず、現在ではよりシンプルなRESTful APIが事実上の標準となっています。 そしてRESTful APIのためのWSDLとも言うべき、RESTful APIのインターフェイスを記述するための標準フォーマットを推進する団体「Open AP
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください(初回相談無料) 全国100万人のモノリシック巨大アプリケーションに苦しむみなさんこんにちは。 世の中猫も杓子もマイクロサービスだ!!とかAPIだ!!とか言っていますが、実際にマイクロサービス環境にしようとすると、どのようにしてAPIのサービスを取りまとめるかが課題になります。 一般的には以下のようなやり方になります。 複数のサービスに分散しているAPIを統合するゲートウェイを用意するそのゲートウェイでは以下のようなことをおこなうクライアントからのアクセスのシングルエンドポイントの役目を果たすAPIの実体へのルーティング認証アクセス記録の収集スロットリング(過度なアクセスの抑止)実体がダウンしている場合のデグレーションこのようなAPIゲートウ
PDCAは「小さな改善」を指すものではないし、そもそもWebサイト改善には向いてない。まずPDCAはP=計画ありきの「マネジメント」の話だし、Webはコントロールできない要素が多すぎて精度の高い計画立案が難しいからだ。 PDCAサイクルの出自は製造業の品質管理である。そしてPDCAという概念のキモは、「品質管理の話をしていると思ったらいつの間にかマネジメントの話をしていた。何を言っているのかry」である。例えば「C」は品質チェック作業はなく、品質のばらつき具合が事前の計画どおりだったかどうかを判断する。それはP=計画の検証そのものだ。製品の品質を管理するときに、単に品質チェックの「作業」を頑張ればいいのではない。品質の問題が生産工程全体のマネジメントの問題にスライドしていく。それがPDCAという概念の画期的な点だった。 だからPDCAというのは製造業だろうがWebだろうが、常にマネジメント
#cto_sushiでChangeLogやIssueを追う技術、reftest、GitHubスパムなどについて話してきた。(この中に現在CTOはいなかった気がします) ログ: #cto_sushi - Togetterまとめ 久々に を食べるSushiイベントだった気がします。 これからの Web について真剣に議論している。 #cto_sushi pic.twitter.com/c3xXrkasVi — Jxck (@Jxck_) May 26, 2015 #cto_sushi pic.twitter.com/oAts18i7O3 — Yosuke FURUKAWA (@yosuke_furukawa) May 26, 2015 クリップボード API - kyo_ago 机が埋まる前にLTスタート。 クリップボードについて kyo_ago #cto_sushi — azu (@azu_
WebAPIの仕様を記述する方法はいくつかあると思う。 普通に日本語で記述する JSON Hyper-Schema、WADL、RAML、Swaggerなどを使う 仕様書の代わりにプログラムを書く HTTPメッセージそのものを記述しておく でも、文法にばらつきがあったり、読みにくかったり、ツールのセットアップが面倒だったり、どれもイマイチな所があって、手軽な方法が欲しいと思っていた。 何気なくcurlコマンドのオプションを調べていたら、「もうこれでAPIドキュメント扱いにしちゃえばいいんじゃね?」と思えてきたのでメモしておく。 curlコマンドのおさらい curlコマンドはlibcurlの付属コマンドで、最近のUnix系OSなら大抵最初から入っていると思う。コマンドの詳細はmanを読んでいただければ。 cURL - How To Use (マニュアルページ日本語訳) curlコマンドのオプシ
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
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0062 号 バックナンバー Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist Magazine 0059 号 Rubyist Magazine 0058 号 RubyKai
企業やプロジェクトによってデザインガイドラインは自ずと必要になってきます。それが社で働くデザイナーの共通認識になる訳ですが、例えばFacebookアプリを作る際にはボタンやデザインをFacebookっぽくしたくなるのではないでしょうか。つまりデザインガイドラインは社内だけでなく社外の人にとっても有益なのです。 そこで登場したのがPrimerです。PrimerはGitHubが作り、使っているデザインガイドラインになります。 Primerの使い方 スクリーンショットを多めで紹介します。まずはグリッド。 ヘッダー。h1〜6まで対応。 テキスト。若干小さめ? インラインテキストの装飾。 ボタン。ここはGitHubっぽいですね。 ボタングループ。こういうのもGitHubで使われていますよね。 フォーム。シンプルです。 フォームグループ。縦に並べる時に使えます。 メニュー。アイコンはオプションです。
スマートフォンの普及で、PCで閲覧するWebサイト(以下、PCサイト)に対する注目度は下がっています。しかし、BtoBのデジタルマーケティングにおいては、PCサイトが今後も戦略の中心になるでしょうし、BtoCにおいても、PCサイトが不可欠な領域もまだまだ多いです。 ハードウェア的に大きな変化のないPC向けのWebデザインというと、ノウハウは固定化されている印象もありますが、実際には時代の流れを受け、今も変化を続けています。特に以下のような環境変化が、PCサイトのUIデザインにも大きな影響を与えています。 表示デバイスの多用化 スマートフォンアプリの一般化 タッチスクリーンの普及 トレンドに合わせれば成功、というではありませんが、その根底に流れているユーザ動向の変化については、十分に理解しておく必要はあるでしょう。そこでこのエントリーでは、PCサイトのUIデザインにおける最新動向を、その背景
久しぶりにWebサイトのfaviconを変えようと思い、調べてみると、必要なfaviconが大幅に増えていることがわかりました。 その数、何と21個! そんなに増えていたとは。 一応、以下にリストアップしてみます。 faviconのリスト favicon.ico: IE用 favicon-16x16.png: タブ表示用 favicon-32x32.png: Mac版Safari用 favicon-96x96.png: Google TV用 favicon-160x160.png: Opera 12 までのスピード・ダイアル用 favicon-196x196.png: Android版Chrome用 mstile-70x70.png: Windows 8 用 mstile-144x144.png mstile-150x150.png mstile-310x310.png mstile-31
料理動画事業室の @yoshiori です。前に「RESTful Web API 開発をささえる Garage」で紹介した RESTful Web API を開発する Garage のクライアント側のライブラリを公開しました。この記事ではその使い方を紹介したいと思います。Garage の設計思想やサーバ側の実装については上記記事を御覧ください。 今回は簡単にクライアント側の挙動を知っていただくために pry を使って説明したいと思います。 アクセスするサーバは先程の記事で作成したアプリケーションを使用してみます。 サーバの準備 https://github.com/taiki45/garage-example の README にも書いてありますので簡単に進めたいと思います。 まずは下準備としてコードを github から clone してきて、ライブラリのインストールと DB のマイグレ
レスポンシブでWebデザインを組むのは当たり前、今のトレンドはマテリアルデザインにあるという時代になってきました。フラットUIを踏襲しつつ、アニメーションを効果的に使うことでさらにユーザビリティ高いデザインを可能にします。 主にモバイルアプリ用に使われていますが、Webデザインにおいても十分利用が可能です。今回はマテリアルデザインを実現するスタイルシートフレームワーク、Materializeを紹介します。 Materializeの使い方 今回はスクリーンショット多めに紹介します。 Materializeはレスポンシブかつマテリアルデザインのフレームワークになっています。開発の高速化、ユーザ体験重視、ドキュメントとサンプルを多めにして学習コストを低くするといった特徴があります。 MaterializeはHTML5/JavaScript/CSS3製のオープンソース・ソフトウェア(MIT Lic
Removing User Interface Complexity, or Why React is Awesome I've been studying frameworks and libraries like Ember, Angular, and React the past several months, and given Web Components a lot of thought. These all solve similar problems to varying degrees, and are in conflict in some ways and in harmony in others. I'm mostly concerned with the core problems of data binding and componentizing UIs. A
趣味などでWebサービスを作るときにもっとも悩ましいことのひとつがデザインだと思う。外観は重要な要素だとは理解しているし興味も一応あるけれど、実践に乏しいからどうしていいのかわからない。かといって、タダで頼めるような都合のいいデザイナーはいない。結局めんどうになって、Twitter Bootstrapで体裁だけでっち上げた妙にオタク臭いデザインになってしまう。僕もかつてはデザインを気にも留めないクソエンジニアだったけど、必要に迫られて勉強したらそれなりに手を動かせるようになったのでその方法を紹介する。僕が今年入社したスタートアップにはデザイナーがおらず、新機能を作るときなど仕方なくデザインをこなす必要があった。結果的に、仕方ないなりにPhotoshopを使ってプロトタイプを作りHTML/CSSコーディングするくらいはできるようになった。ここに書くのは仕方なくそれなりのWebデザインをする方
最近フロントエンドでfacebook/reactをずっと使っている。世界的には一部のエンジニアの間で流行っているのだが、国内だとqiitaのタグ等を見てもどうも少ない。みんなもっと使うべきだと思うので、宣伝かねて意見をまとめてみる。 複雑化するデータバインドに対する懸念 MVWのVに対して思いを馳せると、だいたい次のことに行き着く。すなわち、「ある構造体の入力に対して、必ず一意なビューを生成したい」 {items: [1, 2, 3]} を入力とすると、 1, 2, 3のli要素になってほしい。これは単純な例だから問題に成り得ないように見えるが、アプリケーション全体の状態を一つのjsonとして定義し、 そこから常に0から組み立てればアプリケーションの健全性が確保できると考えたことはないだろうか? 現実の問題 UIのだいたいの状態は遷移で表現される。遷移の差分をプログラマが記述する。jQue
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く