AMP/PWA をどこで/いつ使うか - Qiita
某所で使った資料の公開版 用語整理 PWA: ネイティブアプリのようなUXを提供するための機能群 SPA: JSで遷移するシングルページアプリケーション AMP: 後述 PWAMP: AMPで流入させてPWAを起動する形式 MFI: モバイルファーストインデックス いまさら聞けないPWAとAMP アメブロ2017: Isomorphic Web Appの進化編 AMP とは イニシャルビューのためのHTMLの特殊なサブセット GoogleにホワイトリストされたHTML属性しか使えない GoogleにホワイトリストされたJSプラグインしか使えない CSSはHEADに全部書く AMP仕様を満たすと、Googleがキャッシュして、モバイルの検索流入ではそのキャッシュを使う HTTPS必須 必ずしも全ページをAMPに対応する必要はない PWA: ServiceWorker の機能 リソースの先読み
kobito-oss のソースの読み方 - Qiita
メインの開発者として、備忘録を残しておく。 どんなものか試したい人は、 https://mizchi.github.io/kobito-oss/ で、IndexedDBの許す5MBぐらいまでは試せる。 一応言っておくと、これは僕が退職するんでOSS化ってわけではなく、元々あった計画の前倒しです。時期が早まったのはある。 以下、どのようにコードを読むか。 念頭に置くこと 2年前 の技術選定のスタック Mac版Kobitoと仕様が違う。Kobitoと同期しない、Inboxという仮グループがある。 mizchi/arda electron 以前の atom-shell 時代の互換コードが一部残ってる 細々とバグ対応はしつつ、あんまり依存パッケージのメンテ出来てなかった 公開にあたって、個別のタスクの綺麗さより、ビルドできるの優先した とりあえず yarn で固定して yarn upgrade-i
「後付の型システム」の活用についてFlowtypeとReduxから考える - Qiita
FlowtypeやTypeScriptは静的解析によって事前に型違反を検知することができる。JavaScriptは動的型付けの言語であり、本来はランタイムにしか型が出現しない。 FlowtypeとTypeScript、ともに「それ自身がランタイムではない」というのが特徴であり、一種のLintツールだと言うことができる。ランタイムではないがゆえに、嘘の事前条件を与えることでそれらを騙すことができるし、自らに有利な制約を追加できるという柔軟性を持つ。 JavaScriptの現実においての型 例を出そう。 type MyUtil = { foo(v: string): number; }; const util: MyUtil = new HogeUtil(); util.foo(1) //=> type error HogeUtil は何かしらのユーティリティ関数の詰め合わせだが、fooにしか
型なき世界のためのflowtype入門 - Qiita
http://qiita.com/mizchi/items/3bbb3f466a3b5011b509 で紹介したモダンJSスタックの上に、flowtype を導入して型をボトムアップに追加していくアプローチを紹介します。 なぜflowtypeか、そのゴールは 流行っているライブラリのみを組み合わせて使う場合や、バックエンドとの連携において型が十分に提供される環境なら、正直、flowtypeよりtypescriptでいいと思っています。flowtypeが力を発揮する環境は、既存のJSが大量に存在する環境や、railsなどの動的な型のフレームワーク環境で、静的な定義が抽出できない環境だと思います。 よほど品質が低いライブラリを使わないかぎり、バグはほとんど自分が記述したコードによって発生します。なので、まずは「自分が書いたコードのIFを明確にし、その静的なチェックを行なう」、というのを最初の目
春からはじめるモダンJavaScript / ES2015 - Qiita
春ですね！人の配置がリファクタリングされ、コードもリファクタリングの季節です。 では僕がここでモダンなJavaScriptとES2015の利点を語る役をやるので、みなさんはチームを説得する役をやってください。 JavaScriptの歴史 まず最初にJavaScriptの歴史を踏まえることで、今学ぶべきものとその理由を確認しましょう。 なぜ2016年の記事でES2016ではなく、ES2015なのか、と疑問に思った方もいるかもしれません。それは、ES2015がただの年次アップデートではなく、これから始まる毎年のメジャーバージョンアップの起点となるバージョンであり、またES5から飛躍的に仕様が増えたバージョンであるからです。 簡単に(雑な)歴史を紹介します。 ブレンダン・アイクによってNetScapeに実装/搭載された古の時代〜IE6 (1996~2005) ES3: 一時はシェア7割を誇ったレ
Real World Electron Development - Qiita
~ Case of the Kobito, Markdown Editor for YAPC Hackathon! @mizchi / Koutaro Chikuba, Increments Inc About Node.js / Frontend Engineer Single Page Application Specialist Kobito for Windows Developper Increments Inc (Providing qiita.com / Qiita:Team) Sorry, my English is not so good. YAPC::Asia 2015 Hackathon | Peatix の発表資料 ここで喋ることは一昨日急に決まったので(YAPC回るし)スライド作る時間なかった。ゆるして。 発表中に @benogle 氏に何度か質問しながら進行しま
NightmareでE2Eテストしつつスクリーンショットとってgifに結合したら目視チェックが最高に楽になった - Qiita
最近またe2eを書いたりしてる。色々悩んだけど、やっぱNightmareを使うことにした。 Nightmareについては僕が前書いた記事を参考にしてください NightmareでE2E - Qiita Nightmareの良い点 Zero configuration というかただのスクレイパー 悪い点 プロセス立ちあげるのが遅い JSわかってないと読みづらい PrecepeterとかTestiumとかProtractor試したけどどれも走らせるだけでいっぱいいっぱいで、もう面倒臭い。 僕は行儀が悪いのでスクレイパーを走らせられればいいです。エビデンス() はスクリーンショットで確保する方向で。 連番のスクリーションショットを取りながらNightmareを走らせるサンプル Nightmare = require 'nightmare' class TestRunner extends Nig
JavaScriptのモジュールシステムの歴史と現状 - Qiita
社内向け資料。自分が書いたコードを説明するために資料作る羽目になった。 昔のことはうろ覚えで雰囲気で書いてる部分もあるので、そこらへん勘弁。 古の時代(~2010) 前提としてJavaScriptは名前空間がwindowの一つしかない。 昔Prototype.jsがあった。もうみんな忘れたけどあの時期はプリミティブなオブジェクトのprototypeを生やしまくって、それが衝突しまくってprototype良くない的な雰囲気が生まれたり生まれなかったりした。 その反省があってか(歴史的に若干微妙な気がするが) jQueryは名前空間を一つに集約した。いわゆる jQueryPlugin は、jQueryのプロトタイプにヘルパを生やしまくっていた。グローバルを汚すのは駄目だけどjQueryの名前空間を汚すのはいいよね、ぐらいの考え。 jQuery非依存なライブラリは、「GoodParts」として、
俺のJSライブラリの世界観(2014末版) - Qiita
http://qiita.com/advent-calendar/2014/frontrend 概論 ここ近年のモダンJSは特に理由がなければcommon.jsのrequireスタイルで記述され、webpack/browserifyでビルド/読み込むことを前提にしてよい。今やビュー層を除いてブラウザとnodeのライブラリの境界は非常に曖昧である。 識者諸君においては常にどちらの環境でも読み込めるようなライブラリを提供するように心がけることを切に願う。 今日はライブラリの名前しか出さないんで各自ググるように。 立場 サーバサイド~ゲームプログラミング出身node寄りフロントエンドエンジニア このサイトのスタッフだけど他のことに手一杯でQiitaのフロントはまだそんなにいじってない すまんな 他ってなんだろうな 言語 CoffeeScript TypeScript 最近DDDっぽい構成を目指し
なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita
追記: 情報が色々と古くなったため、2020年に書き直した版へのリンクを張っておきます。 この記事は VirtualDOM Advent Calendar 2014 - Qiita の初日です。 初日ということで、基調講演風に、Virtual DOMとはなにか、なぜ僕はこんな興奮しているのか！という話から。 Virtual DOMとはなにか 既存の概念で当てはめると、JavaScriptのMVC, MVW(Whatever)フレームワークのViewに位置します。が、その程度では終わりません。仮想DOMとは世界を革命する力であり、このjQueryのDOM操作で汚れきったフロントエンドを救う救世主なのです。 現時点で自分が知っている限りは、以下の実装を指します。 facebook/react 最も使われてるFacebookの実装 Matt-Esch/virtual-dom Altenative
facebook/flowファーストインプレッション - Qiita
前々から出すよ出すよ詐欺してたflowがやっと出た。大雑把にはfacebook製のTypeScriptだと思っていれば良いです。 まだnpmで提供されてなくて、 Flow | Getting started with Flow で実行バイナリが配られてる。 npmで提供されてない理由は、たぶんocamlで書かれてるから。Future Planにjs_of_ocamlでコンパイルされたものが提供されると書いてあった。 DLして適当なパス通った場所に置いてつかう。 TypeScriptとの比較 思想はTypeScriptと同じなので、大枠は一緒だといってよい。 ぱっと見気になったのは、Nullableの書式が違うのとかあるけど、もっと大きな違いもたくさんある。 FlowとTypeScriptにあるもの declareキーワードによるアノテーション ES6 classes Generics ここ
react-jadeでjadeテンプレートから仮想DOMを出力する - Qiita
常日頃Reactに足りないのはテンプレートエンジンだ！と主張していたのだけど、react-jadeは試した感じ信頼できそうな感じだった。 jade公式なんで信頼できそう。信頼できそう、とは変なパースミスとか起こらないだろうという意味 jadejs/react-jade var React = require('react'); var jade = require('react-jade'); var dummyTemplate = 'button(onClick=onClick) this is button'; var template = jade.compile(dummyTemplate); var Foo = React.createClass({ onClick: function(){ console.log('clickcckckckckc'); }, render: f
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
