タグ

2015年6月10日のブックマーク (7件)

  • CSS 設計の長い夢 - ペパボのフロントエンドスタンダード

    フロントエンド周りの技術は驚異的なスピードで進化し、また多様化しています。それらを全てマスターするのは途方もなく大変なので、ペパボでは、社内のエンジニア・デザイナが「最低限これだけはおさえておこう」というスタンダードを文書化することにいたしました。社内向けを想定した文書ではありますが、社内のみに留めず多くの方に役立てたいと考えたため公開します。 スタイルシートの夢 (1) 予測しやすい (2) 再利用しやすい (3) 保守しやすい (4) 拡張しやすい 代表的な CSS 設計手法 既存プロジェクトCSS に立ち向かう! (0) 流れ (1) 既存の CSS ファイルを元に SCSS ファイルに変換する (2) イニシャライズ CSS や共通の箇所のスタイルを分離する (3) CSSLint を使って、修正しやすいところから整理していく (4) コンパイル (5) スタイルのスコープ(あ

    CSS 設計の長い夢 - ペパボのフロントエンドスタンダード
    Jxck
    Jxck 2015/06/10
  • HTML5 History APIで非同期通信時にURLを変更する方法 | 株式会社LIG(リグ)|DX支援・システム開発・Web制作

    こんにちは、フロントエンドエンジニアの店長です。 先日記事が出てましたが改めて自己紹介します。 大学卒業後はカフェで仕事をしていたのですが、退職して1年半ほどWebデザイナーをしていました。そして、LIGにはフロントエンドエンジニアとしてジョインすることに。 お察しのとおり、店長というアダ名はカフェで働いていたためです。 今後ともよろしくお願いします。 さて、今回はHTML5のHistory APIについてお話したいと思います。 History APIについて History APIには以前からブラウザの履歴(スタック)を行き来する機能があったのですが、HTML5でさらに以下のような機能が追加されました。 画面を遷移せず、履歴に新たなURLを追加する。 現在のページの履歴を変更する。 ブラウザの戻る・進むボタンをクリックしたときにイベントを検知する。 このような機能がどんな場面で使われてい

    HTML5 History APIで非同期通信時にURLを変更する方法 | 株式会社LIG(リグ)|DX支援・システム開発・Web制作
  • Swift 2.0 の try, catch ファーストインプレッション - Qiita

    WWDC 2015 で Swift 2.0 が発表されました。オープンソース化などのうれしいニュースでも盛り上がっていますが、言語仕様としては try, throw, catch が導入されるという大きな変更がありました。投稿は、 The Swift Programming Language の新章 Error Handling を読み、多少のコードを書いた上での個人的な感想です。 結論から言うと、 try, catch の導入は良い変更だと思えないけど、 try, catch を導入する前提なら考え得る限りベストに近い仕様だった、って感じです。 よかったのは、 ErrorType は enum タイプセーフなエラー情報 エラー処理が強制されている(検査例外のような形) try! でエラーを無視できる あたりです。個人的には、 try, catch でなく Either 的なものを公式サ

    Swift 2.0 の try, catch ファーストインプレッション - Qiita
    Jxck
    Jxck 2015/06/10
    新しい言語でも try-catch は入ってくるんだなぁ。
  • アセンブリ言語のみで言語処理系を作った話 // Speaker Deck

    第11回 カーネル/VM 探検隊

    アセンブリ言語のみで言語処理系を作った話 // Speaker Deck
    Jxck
    Jxck 2015/06/10
    すごい
  • IEだけに適用されるHTML「条件付きコメント」の使い方

    こんにちは、さち です。 ウェブサイト制作の経験がある人には有名な話なんですが 古いバージョンの Internet Explorer(以下:IE) は ウェブサイトの表示で 特殊な挙動,未実装の問題 があり サイトを作る時に、別途 IE 対策が必要です。 そこで今回は IE だけに適用される HTML を記述できる 「条件付きコメント」の使い方についてまとめていきます。 「条件付きコメント」とは? 「条件付きコメント」は IE だけが解釈できる HTML コードです。 構造は下記のようになっています。 <!--[if IE 7]> 適用するHTMLコード <![endif]--> 最初に、<!--[if IE 7]> で適用する IE のバージョンを指定。 例では、[if IE 7] なので 閲覧者のブラウザが IE7 の場合に適用します。 次に、適用内容を HTML 形式で記述。 最後に

    IEだけに適用されるHTML「条件付きコメント」の使い方
  • 砂糖の甘い付箋

    マイナンバーと、どうやって付き合っていくのかについて、いくつかの観点で紹介していこうと思う。 まず、最初は、マイナンバー制度が導入されたら、市民として何に注意しなければならないかを考えてみる。 マイナンバーは当面は、行政手続きだけで利用されるので、まず、そのような利用場面を考えてみる。 現在は、役所の窓口に行って、自分に関する何かの行政手続きをする際に、氏名を申請することがあるだろう。氏名だけでは、同姓同名者がいるかもしれないので、住所や生年月日も合わせて申請することになる。 氏名や住所を記載したり申し出たりすることで、自分がどこの誰かが伝わり、他の人ではない自分に関する手続きを申請することができるわけだ。 そのように、自分がどこの誰かを他人と区別してわかってもらうための情報を、特定用情報と言う。この場合には、氏名や住所が特定用情報となる。 氏名や住所を特定用情報として申し出るのと同じよう

    砂糖の甘い付箋
    Jxck
    Jxck 2015/06/10
    “市民として注意しなければならないことは、 自分がマイナンバーを申し出たときに、相手が、本人確認をしっかりしているかをチェックすること。”
  • 「番号」は漏れると危ないのか?

    さて、マイナンバー対応バブル真っ盛りの夏を迎えつつありますが、皆さんいかがお過ごしでしょうか? 折しも年金番号が盛大に漏れて1、マイナンバーへの影響もあるのではないかとなども言われておりますが、そもそも「番号」が漏れることを「住所・氏名・生年月日」などの各種個人情報以上に大騒ぎするのには私は違和感があります。それは、こと漏洩に関して言うと、プライバシーインパクトは「番号」<「住所・氏名・生年月日」<<「付随する情報」だからです。 以下、簡単化のために「番号」<「住所・氏名・生年月日」に焦点を絞ります。 1. なりすましによる被害 「番号」それ自体は、その人のデータを他の人のデータから区別するという能力しか無いはずです。米国のSSNなどは、誤った理解から番号自体を人確認に使ってしまったりしてなりすまし事故を盛大に起こしております2が、日マイナンバーや年金番号はそんなことはしていないは

    「番号」は漏れると危ないのか?