You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
bouzuya/bbn-cycle で cyclejs/cyclejs 7.0.0 を試している。まだ途中だけど、現状での印象を書く。 v7 の変化としては次のような点が挙げられる。 JavaScript -> TypeScript RxJS -> xstream virtual-dom -> snabbdom TypeScript への変化は個人的には嬉しいのだけど、Cycle.js が TypeScript 化されてもほとんど影響がない。まず Cycle.js の API を直接的に使う場面はほとんどない。ぼくの認識では message 基盤の提供や event flow の制御をしているだけだからだ。それに Cycle.js の API は TypeScript 向きじゃない。Sources なども { [driverName: string]: any; } 程度にしか、型の補助を
業務システムのUI構築に採用されるJavaScriptコントロール「Wijmo」。軽量で高性能な製品を提供しつづける舞台裏を開発者に聞く[PR] 業務アプリケーションの開発でWebとモバイルへの対応を進めようとするとき、大きな課題の1つとなるのが、Webやモバイルに合わせた優れたユーザーインターフェイスをどう構築するのか、でしょう。 デスクトップアプリケーションとして作り込まれてきた業務アプリケーションのユーザーインターフェイスを、Webブラウザ対応にし、しかもモバイルデバイスの小さな画面とタッチ対応へ再構築することは容易な作業ではありません。 HTML5/JavaScriptのユーザーインターフェイスコントロールである「Wijmo」(ウィジモ)は、こうした課題を解決できる機能を提供します。 Wijmoは、業務アプリケーションでよく使われるExcelライクなグリッドコントロール、オートコン
A topic that frequently confuses users in the #Node.js channel, is the Promise.try method provided by Bluebird. People often struggle to understand what it is, or why they should use it - and this isn't helped by the fact that almost all guides to Promises fail to demonstrate its use. In this brief article, I hope to provide a better explanation of what Promise.try is, and why you should always us
package.json の browser field 実践編 package.json の browser field 入門編 では、package.jsonのbrowser fieldの役割と機能について紹介しました。 本編では、この機能のbundlerごとの実装の違いと、それを回避する方法を説明します。 ここで取り上げる実装の違いとはずばりpathの解決方法です。 ./から記述するかどうか .jsを記述するかどうか mainとの対応関係 この3つの要素が絡んできます。 なお、パス解決のresolverを指定できる系もあるようですが、ここでは各々のbundlerがデフォルトで用意しているresolverについて論じています。 (なぜなら、resolverを外部が指定しなければ意図通りbundleされないというのは、利用者にとってはbundleされないのとほぼ同義です) 調査したbun
Talk about Stream API difference between node.js and whatwg at #tng11 2016/08/08
npmrcのドキュメントを読みなおしていたら、.npmrcは/path/to/my/project/.npmrcのようにプロジェクト毎に配置することが出来る事に気づいて、ちょっと使ってみたら便利だった。 globalやhomeディレクトリへの設定を前提としたnpm configの記事は結構あるが、プロジェクト毎でnpm-configについて書かれている記事があんまり無かったのでまとめてみる。 npm-configの何が良いのか? project毎に出来ると何が良いのか? npm-configの設定をすると、色々コマンドを省略出来たりして良い事がある。 (参考:2016年版 Node.jsで幸せになれる10の習慣) npmrcやnpm-configは、個人開発用であれば、$HOME/.npmrcへの設定だったりnpm config setでの設定で十分。 また、npm registryに登録
マイクロソフト、オープンソースのJavaScriptエンジン「ChakraCore」をLinux版Node.jsに対応、「Node-ChakraCore on Linux」プレビュー版公開 マイクロソフトは、Microsoft EdgeやWindows 10で使われているJavaScriptエンジンのコア部分を「ChakraCore」をLinux対応にし、さらにNode.jsに対応させた「Node-ChakraCore on Linux」のファーストプレビュー版を公開しました。 ChakraCoreは2015年12月にオープンソース化され、WindowsだけでなくLinuxやmacOSへの移植が進められることが明言されていました。 さらに今年に入って2016年1月にはNode.jsのJavaScriptエンジンとして使われているV8の代わりにChakraCoreを使えるようにNode.js
ECMAScript Version Detector ECMAScript Version Detectorというツールとライブラリを書きました。 azu.github.io/ecmascript-version-detector/へアクセスして、好きなコードをペーストすると、そのコードの構文がECMAScriptのどのバージョンから使える機能なのかを表示してくれます。 たとえば、以下のコードはasyncとawaitの部分がまだProposalであるAsync Functionsであることを検出してくれたりします。 目的 Babelなどの変換ツールでECMAScriptのProposalな機能などが身近になりました。 しかし、それがまだ仕様に入ってないもの(Proposal段階であるもの)ということを意識しないで書いてる人もよく見かけるようになりました。 そのため、まだProposalの
タイトルに要素を詰め込みすぎましたが、要は CircleCIを使ってbundle updateを定期実行する - Qiita の npm update 版です。web appのJavaScriptライブラリ管理にnpmを使うとき、依存関係のアップデートを継続的に行うためのツールです。 https://github.com/bitjourney/ci-npm-update これはいまのところGitHub専用です*1。CIサービスはドッグフーディングも兼ねてCircle CI用の起動スクリプトを同梱してますが、実際には ci-npm-update を定期実行するだけなので簡単に代替可能です。 これはCircle CI + Heroku Schedulerで動かしていて、以下のようなフローです。Circle CIはJenkins含め他のCIでも動かせますし、Heroku Schedulerはcr
JavaScript game library which can be edited, saved and run on browser. You can share it without server.
NW.js (previously known as node-webkit) lets you call all Node.js modules directly from DOM and enables a new way of writing applications with all Web technologies. New way of writing native applications using web technologies: HTML5, CSS3, and WebGL Full support for the features in browser Complete support for Node.js APIs and all third party modules Call Node.js modules directly from the DOM and
Written in JavaScript, works cross-browser. Provides SQL-like APIs that are fast, safe, and easy to use.
Node.jsで作られたアプリケーションをデプロイするときに、npm shrinkwrapを使って依存モジュールのバージョンまで固定した状態でインストールする方法を紹介します。 背景 npm install で依存モジュールをインストールするとき、package.json で ^1.2.3 や ~1.2.3 といったバージョン指定をしているモジュールが1つでもあると、semver に従って 1.2.5 などのより新しいバージョンがインストールされる可能性があります。 セマンティックバージョンの意味からすれば、1.2.3 が互換性のある 1.2.5 に置き換わっても同じように動作すべきですが、現実問題としてテストしたバージョンと本番にデプロイされるバージョンが意図せず変わってしまうのは気持ちが悪く、依存モジュールを含めてバージョンを固定する方法を調べました。 実現方法 まずは npm ins
autoscale: true Almin.js | JavaScriptアーキテクチャ 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info 中規模以上のJavaScript 設計が必要になる 正しい設計はない Bikeshed.js :bike: 人、目的、何を作るかによってアーキテクチャは異なる 前回の続き? How to work as a Team Read/Write Stack | JavaScriptアーキテクチャ 用語 設計の目的 中規模以上のウェブアプリ SPAというよりは、画面が複雑なElectronアプリのようなイメージ スケーラブル 人、機能追加、柔軟性、独立性 見た目が複雑ではないアーキテクチャ 書き方が特殊ではなく見て分かるもの 設計の目的 テストが自然に書ける パーツごとに無理なく
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く