インクリメンタルに新しい技術を取り入れる方法。TypeScriptへの移行を例にしたプロセス
📝 require(moduleName) は同期処理なのに対して、import(moduleName)は非同期処理となります。 📝 tsconfig.jsonでesModuleInteropがtrueでないとdeafult importの意味合いは異なります。 この表はCommonJS ModulesとECMAScript Modulesで機能的に1対1で応するという意味ではありませんが、 大まかにはこの対応表にそってECMAScript Modulesの構文へと変換ができます。 エディターを使い手動で変換したり、次のようなツールを使ってある程度機械的な変換も可能です。 cjstoesm commonjs-to-es-module-codemod このモジュールの変換で重要なことは、できるだけCommonJS ModulesとECMAScript Modulesを混ぜないことです。
事実上最後のJSON仕様「RFC 8259」と「ECMA-404 2nd Editon」公開。UTF-8エンコード必須に
RESTful APIのデータフォーマットなどで広く使われているJSON。IETFはJSON仕様「RFC 8259」を発表。従来の仕様をブラッシュアップしつつECMAの仕様との統一も実現した、事実上最後のJSON仕様になると見られる。 IETFからJSON（ジェイソン）の仕様を示した「RFC 8259」（The JavaScript Object Notation (JSON) Data Interchange Format）が公開されました。 IETFにおけるJSON仕様は、これまで「RFC 7159」が参照されていましたが、RFC 8259の公開によりRFC 7159は廃止（Obsolete）となりました。 RFC 8259は、多数の実装と十分な運用実績を積み重ねたインターネット標準「STD 90」としても参照されます。 ECMAとの統一を実現。事実上最後のJSON仕様になると見られる
JSON Schema 中心設計 - FlowType から RAML まで - - Qiita
はじめに Web サービスの運用を続けていくと，依存関係が徐々に複雑になっていきます．そしてメンテナンスするものが増えた結果，それらが相互に乖離していく，といったことが起こりがちです． そこで今回は，JSON Schema のみをメンテナンスしていくことで，動的チェック (バリデーション)，静的チェック (FlowType)，API ドキュメント生成，スタブ作成といった様々な恩恵を享受し，品質と保守性を同時に向上させるアプローチについて書いていきます．この JSON Schema を中心に据えたエコシステムを，__JSON Schema 中心設計__と呼ぶことにします． JSON Schema の仕様については割愛しますので，必要な方は こちら をご覧下さい．また，本記事では JavaScript での事例を紹介しますが，他の言語でも同様の適用ができるかと思います． アプローチ 本記事では
東京Node学園 14時限目で「Synth」について話してきました | Tokyo Otaku Mode Blog
昨夜、渋谷ヒカリエで行われた東京Node学園 14時限目で、トップバッターとして発表してきました。 発表内容は、「Synth」というWebアプリケーションフレームワークについてです。 Tokyo Otaku Modeでは、バックエンドとしてNode.jsとMongoDBを使っていてExpressで運用していますが、色んなフレームワークも触っていてSynthもそのうちの一つです。 SynthはInfoQの「APIファーストのWebフレームワークSynthを巡るコミュニティの困惑」という日本語版記事が出て初めて知った人が多いと思います。 記事にもあるとおり、JSONやテンプレートHTMLを返すAPIとそれを使ってクライアント側でアプリケーションを構築するという形に特化したAPIファーストのWebアプリケーションフレームワークです。 ちょうど上記の記事が出た頃、天下一クライアントサイドJS MV
最小最速で作るaltjs - mizchi's blog
最近、というか昨日からTypedCoffeeScriptの開発再開してAST 気分が盛り上がってるので、簡単なチュートリアルでも。 この記事でやること ASTの取得 ASTの生成 JavaScript の出力 やらないこと 構文解析 準備 適当にプロジェクト作ります。 $ mkdir tinyaltjs $ cd tinyaltjs $ npm init # 色々聞かれるけどEnter 連打で良い $ npm install escodegen esprima prettyjson --save esprima はJavaScript のコードをASTに変換。 escodegen は AST から JavaScript を生成。どっちもConstellationさん製 escodegenはConstellationさん製で、彼はesprimaにもコミットしてます。この界隈に来ると基本的に彼
jsだけ使ってメールが送れる世の中らしい - 以下斜め読んだ内容
便利ですね MailChimpがMandrillというメール専門のBaaSのようなことをやってる Transactional Email from MailChimp - Mandrill xhrでpostするとメールが送れる via: Send an email using only JavaScript — Design + Startups — Medium 12,000通/月まで無料 Mandrill - Transactional Email from MailChimp mailchimpのようにダッシュボードで、開封チェックとか送る側が知りたい情報が知れる機能が使える htmlメールとか、画像埋込とか、添付ファイルとかメールに欲しいものもひと通りできる Messages API | Mandrill やってみた mandrillでサインアップして、api keyもらう手順 割
Web Application の validation はどのレイヤーでかけるべきか - tokuhirom's blog
Web Application の validation はどのレイヤーでかけるべきか 数年前にも同じことかいた気がするけど、最近の状況にあわせてかいてみる。 途中で面倒になってきて説明が雑になっている点をご容赦ください。 言いたいことは「結局、昔はサーバサイドで懇切丁寧なエラーメッセージを出すためにModelではなくControllerでバリデーションに関する知識が必要だったけど 今はJavaScriptでやるから不要だよね１１１」ってことです。 この表題は、よく話題にあがるところなのだが、理想論としては Model, Controller, Client side のいずれにおいてもきっちりと validation を行うことがのぞましい。 しかし、実際にはなかなか面倒である。ということで、どこをはぶくかというと Controller における Validation であろう。 ユーザ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
