Cloudflareにおけるメール・ソリューションとしてのMailgun
Value Domainで取得したドメインをCloudflareの提供するネームサーバーでGitHub Pagesに向けてやるのは、低コストでウェブサイトをホスティングする優れた手段だ。問題はメールだ。Cloudflareではメール関係の機能はまったく用意されていない。またValue Domainで無料で取得できるXREAのアカウントはメールだけの利用は禁止されている。本道としては別にメール・サーバーを用意するわけだが、転送だけで良いのなら無料枠内で利用することができるMailgunを使うのが良さそうだ。 Mailgunではアカウントを取得後、まずドメインを追加する。すると計5つのDNSレコードが提供される。 認証用のTXTレコードが2つ 送信メールでのトラッキングに使われるリソースのためのCNAMEレコードが1つ 受信用のMXレコードが2つ これらDNSレコードをCloudflareのコ
HTMLは開発者たちのために
昔からよく「HTMLの正しさ」というような表現を見る。少し前はHTMLの構造的な完全さや文法的な正確さなどにウェブページの表示やCSS、そしてJavaScriptが依存していたので、そういった点を強く意識する必要があった。Firefoxが親切に教えてくださっていたXMLパースエラーのことを思い出すとわかりやすい。僕も良くそれに類する表現を使っていた。 今はブラウザーとウェブ標準技術が共に進化したので、そういった形式的な正しさはさほど重要ではない。かろうじてハイパーリンクだけがまともな壊れたHTMLでもなんとか修復して解釈してくれる。命名規則ベースのCSSならばHTMLがどうあれうまくスタイルが当たってくれるだろう。足りない機能はDOMツリーの状況をほとんど無視できるShadow DOMでどうにでもできるというわけだ。 HTMLにCSSとJavaScriptを生やしてウェブページが出来ていた
スクロールは制御するな - Weblog - Hail2u.net
WWD Japanのウェブサイトがリニューアルして、スッキリした見やすそうな印象のものに変わった。しかし実際のところ見やすさは見せかけだけで、ナビゲーションをクリックしても見当違いのタブに切り替わったり、ニュース一覧からニュースをクリックしたら、要約ページへ移動するだけで、本文へはもう一度クリックしなければならなかったりする。中でもひどいのがMobile Safariでの閲覧だ。 このウェブサイトではスクロールをほぼ自前で制御しようとしているため、常にこのようにMobile SafariのURLバーとツールバーが上下にそれぞれ表示され続ける。その上、最上端にロゴとグローバル・ナビゲーション、最下端に広告がそれぞれ固定位置であるので、コンテンツの領域がかなり制限されている。iPhone 5SやSEどころか6+や7+でさえも致命的なのではないかと感じられる狭さだ。 とにかく文書を読ませようとい
2015年に見限ったCSS - Weblog - Hail2u.net
去年はCSSグラデーションを見限ったような気がする。CSSグラデーションは便利ではあるものの、実装の差がいまいち想像しづらく思ってもみない結果になることがよくある。SVGでやった方が結果からもテクスチャであるという面からも安定という印象だったため、去年からほとんど使わなくなった。今年はtext-shadowとletter-spacingプロパティー、そして::selection擬似要素を見限った。 text-shadowプロパティー 文字に影を付けるプロパティーだが、あまり有効に使える場面がない。エンボスやべベルの代わりにするには貧弱すぎることや透過しかできず合成モードを持たないことあたりが足を引っ張っている。もちろんいわゆるなんちゃってフラットデザインというレベルだと文字に影を付ける必要がほとんどないことも影響がある。 実際に今年作った・見たウェブサイトで使った・使われていたというのは記
ブックマークのおっかけ
ソーシャル・ブックマークはまだそれなりに機能するが、いまだに追いかけるのが難しい。その中ではてなブックマークのお気に入り機能は出色の出来栄えと言えそうだが、やはりブラウザーであのページを見るのは辛い。かといってRSSリーダーで読むのもなかなか難しいと感じる。HBFavは良いものだが、やはりデスクトップでどうにかしたい。 ストック型では色々試した末にはてなブックマークのお気に入りRSSからIFTTTのEmail Digestに貯めて毎日深夜に送っておくという形でしばらく落ち着いた。RSSリーダーでお気に入りフィード読むのは本当に苦行だったが、相当マシな気もする。特に気が向かなかったら読まずにとっておくこと(未読でプレッシャーかかったりしない)も、捨てることもできる。僕は送る時間を夜中の3時にして余裕のある朝にチェックできるようにしているが、みながウェブページを見てブックマークし終わる午後3時
1文字だけの改行の拒否
日本語の文章では任意の位置で改行できるため、レスポンシブ・ウェブ・デザインでは多くの場合、望まない位置での改行が起きる。例えば最後の1文字だけ次の行になってしまうと、読みやすさや理解度に致命的な影響を与える。例えば「？」だけ次の行に送られた場合、あるとないのでは大きく印象が変わるだろう。Twitterで@Takazudoと@oosugi20の会話を見て、やはりみな似たようなことは考えるものだと感じ、このあたりのことについて書いてみたくなった。 僕はjQueryで最後の五文字では改行が起きないようにいじったりしていた(うろ覚えで書いたもので、実際にはもっと複雑にやっていたと思う)。見出しがテキストのみの場合、最後の数文字の間に非改行ゼロ幅スペース(U+FEFF)を仕込むことで、その間で改行が起こらなくなるという仕組みだ。ここでは比較のためにクラスで判定するように書いてあるが、実際にはh1から
我慢の期間
MovableTypeとWordPressとJekyllとHugoや、Gruntとgulp、SassとLESSとStylus、果てはjQueryなどの話はスケールやパターンを変えて繰り返される。その話はあたかも特定の何かに依存することが良くないとか新しいこっちのがすごいぞというように結論づけられることが多くて、僕にはちょっと頷けないこともあったりする。大切なのは何を解決しようとしていたかを忘れないことだと思う。複雑化しそうな場合にそこから先へ踏み込まずに我慢する期間がいるとかかも。 GNU makeでいいじゃん的な結論はそれは確かにビルドという点ではそうなんだけど、Gruntが解決しようとしていたのはそこじゃない。npmという生態系の中で完結させやすいタスク実行環境を手軽に用意することができることで、それ以上でもそれ以下でもない。実行速度以外にも腐臭を放つAPIやプラグイン間で一貫性のない
MessageFormat
Pluralization for JavaScriptという名詞の複数形についての記事を読んで、MessageFormatという仕組みがあることを初めて知った。複数形や三単現、性別による言葉遣いの違いなどを言語ごとに定義しておき、出力する際にその定義を利用して自然な結果になるようにする仕組みのようだ。 MessageFormatの仕組み自体もわかりやすくて良かったが、記事に書かれているようにちょっとしたローカライズにおいても威力を発揮しそうなのが良さそうに思えた。昨今のウェブサイトやウェブアプリにおいては、完全な国際化やローカライズよりも重要なUIパーツの正確なローカライズがまず必要になっているので、そういう小さなところから使える仕組みであるMessageFormatはポイントが高いだろう。国際化はともかく、完全なローカライズくらいまではスケールすると思えるので、規模によっては使えないと
クリティカルCSSの動的なインライン化
Inlining critical CSS for first-time visitsという、クリティカルCSSを初回訪問時のみインラインに展開して、その後はインライン化せず予めキャッシュさせておいたフルセットのCSSを使うというアイディアについての記事を読んだ。実装はともかく、アイディアとして成立していないんじゃないかと思う。 クリティカルCSSをインライン化することのメリットは既に多くのウェブサイトでも取り上げられており、もちろんネタ元のGoogle PageSpeedでも項が割かれている。ここでは特に触れないが、描画領域の大きさにかかわらず初期描画の高速化には大きなメリットがあるとは言えるだろう。上記リンク先の記事ではそれを動的に行うことで、2度目以降の訪問の時にはキャッシュ済みであるフルセットのCSSを使わせるようにし、効率的なキャッシュ運用と保守性を実現する実装について解説されて
Semantic Versioningにおける破壊的な変更
io.jsがv1.3.0になり、ビルトインのURLモジュールでresolve('/foo/bar', '.')が/foo/とスラッシュ付きで返されるようになった。今までは/fooとスラッシュなしで返っていたので、これは破壊的な変更であり、Semantic Versioningに従うならばメジャー・バージョンを上げるべきではないのかという議論がなされていたようだ。 仮にこういった実装ミスの修正が破壊的な変更だとすると、ほとんどすべてのバグ・フィックスは破壊的な変更になってしまう。バグ・フィックスは必ずどこかで何か(モンキーパッチとか)を破壊するし、破壊しないことを保証することは不可能だ。Semverにおいては変更の仕分けはユーザーの利用ではなく、仕様という観点での話になる。つまり仕様に変更があったかどうかが焦点になる。 このURLモジュールのケースでは、仕様が外部(ドキュメントのブラウザーの
よろしくESLint
重い腰を上げてESLintを使い始めた。そろそろv1.0.0になるらしい。これは良いなと思ったところを簡単にまとめておく。ついでに引っかかって対処にちょっと悩んだところも。既にすごく好感触なので、このまま素直に乗り換えられると良いな。 package.jsonに設定が書ける 外部設定ファイルとしては.eslinrcの他にもpackage.jsonに混ぜ込むこともできる。フィールド名はeslintConfigで、それ以下は同じ。 { "eslintConfig": { "env": { "node": true } } } 通常のnpmパッケージでは別にした方が良さそうだが、依存解決にnpmを使うだけとかコマンド作るためだけのようなプライベートなケースでは特に気にせず混ぜてしまって良さそう。 no-multi-spaces 複数の連続した空白が検出できる。 var a = 1; これで警告出
mit-license.org
Open Source InitiativeのMITライセンスのページのURLを使ってMITライセンスと明示している人は結構多いと思います。ライセンス全文コピペするの面倒ですしね……。ただその場合は権利者の名前等を予め書き、ライセンス条項については以下のURLを参照……などと注意書きも含めた方が無難です。そういうのを「忘れるし！ 面倒だし！」と思ったRemy Sharpがmit-license.orgというウェブサービスを作ってくれました。 登録するとユーザー名をサブドメインとしたURLが確保されます。例えば僕の場合はhail2u.mit-license.orgです。このページを見るとわかるように権利者の名前と発行年、オプションとしてWebサイトのURLにリンクを張れたりもします。 curlでJSONを送りつけるという方法でも登録できるみたいですが、JSONファイルの登録とバッティングした
依存しているもののメジャー・バージョンアップ
自身のライブラリーなどにおける依存しているものがSemantic Versioningで言うところのメジャー・バージョンアップした場合、APIに互換性のない変更が加えられたということなので、動作を確認して自身のライブラリーもバージョンアップする必要がある。多くの場合、パッチ・バージョンアップで十分だが、互換性のない変更が加わったAPIを透過的に使っていた場合にどうすれば良いのかよくわからなくなった。 透過的に使っていたAPIに互換性のない変更が加わっているということは、ユーザーがライブラリーを使う方法に互換性のない変更が加わるということになる。仮にこれが依存しているものの変更でないとすると、当然メジャー・バージョンアップすべき変更ということになる。 しかしこういった場合にメジャー・バージョンアップするとすると、最悪の場合依存しているもののメジャー・バージョンアップごとに自身のライブラリーも
CSSライブラリーはそのままでどうぞ
Normalize.cssを始めとして、Twitter BootstrapやPureに至るまでCSSのライブラリーは数多くある。それらはそれなりに気をつけて作られているが、他のライブラリーと混ぜることはもとより、ページ制作者のCSSと混ぜることは想定されていない。単純にlink要素を使って先に読ませるか連結するだけで使わないと、開発者はもちろんそれらが使われているページのユーザーにも意図しない不具合が起きる可能性がある。 そのためNomralize.cssなどではわざわざ以下のように推奨されている。 It is recommended that you include the normalize.css file as untouched library code. 概ねライブラリーと呼ばれるものには手を付けるべきではないが、フロントエンド界隈では軽視されている傾向があるように思う。特にC
GitHub Pagesとwwwなしドメイン
wwwなしドメインをGitHub Pagesで運営しようとAレコードを使って設定すると、全てのリクエストが302 Foundで処理されるようになる。特に実用上の問題はないが、パフォーマンス上のデメリットは大きい。www付きで運営するのが手っ取り早いが、wwwなしでどうしても運営したい場合はCloudflare経由にするのがコストが低い解決法だろう。 CloudflareにはCNAME Flatteningという機能があって、これによりCNAMEレコードを使ってwwwなしドメインを設定できるようになっている。これを使って設定すると302 Foundによるリダイレクト経由になることを回避することができる。設定は特に(GitHub Pagesを使おうというような人には)難しいことはない。 GitHub Pages側が提供するwwwあり→wwwなしへの301 Moved Permanentlyによ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
