Node.js Live Edit - Chrome DevTools - Dev Tips
Chrome DevTools: Live edit running Node.js code with hotswapping Last updated: 19th July 2020 DevTools now has native Node.js debugging. One powerful feature is the ability to live-edit already running code in a Node.js execution context, this is sometimes referred to as 'hotswapping'. You can enable the Node.js debugging experiment in DevTools and then run this command in your terminal: node --in
schemizeのnode.js版作った - Qiita
shcemizeという、JSONからJSON Schemaを生成する便利なGemがある。 schemizeを使うためだけにGemfileを書くのが嫌だったので、node-schemizeを作った。 // とりあえずグローバルにインストール $ npm install -g schemize // デフォルト $ echo '{ "key": "value" }' | schemize {"type":"object","properties":{"key":{"type":"string"}}} // プリチー $ echo '{ "key": "value" }' | schemize --pretty { "type": "object", "properties": { "key": { "type": "string" } } } // プリチーはインデント数と"tab"が指定可能
どうしてこうなった？ Node.jsとio.jsの分裂と統合の行方。これからどう進化していくのか？
7 principles for rich web apps And how next.js achieves these principles
Node.js と io.js の統合は最終局面へ - from scratch
いくつかこの何日間でニュースが出ているので紹介します。 ちなみに、 io.js と Node.js のニュースに関してはこれまで２つ書いたので、まだ良く知らない人はそれをまずはご一読ください。 yosuke-furukawa.hatenablog.com yosuke-furukawa.hatenablog.com さて、次の展開へ、という事でいくつか話があります。 「Join the Node Foundation?」 というissueが mikeal から提案される github.com issue 本文を翻訳したものを貼っておきます。 Node Foundationのためのすべての文書が揃った。 TSC Charter (技術委員会の目的) Development Policy(開発ポリシー) Convergence Plan(移行プラン) Project Lifecyle (Wor
isomorphic tokyo meetupの感想とメモ・資料 #isomorphic_meetup - pirosikick's diary
nodejs.connpass.com ニフティの場所難易度高い＆都庁前駅でGoogleマップ使ったら現在地が御徒町になるなどのトラブルがあり、最初の発表の半分くらいを聞き逃したorz 感想 真のIsomorphic（Truly Isomorphic）ってのがよくわかってなかったが、「IsomorphicってServer Side Renderingのことっしょ？」に対する「いやいや、Viewだけじゃなくて全部が両方で動くことやで」みたいな理解であっていますでしょうか？ 「Server SideレンダリングできるとSEOにいい」とか個別の事象に対して注目してしまっているので、 新しい技術や流行りの技術が出てきたことによってArchitectureがどう変化したかや、 それらが生まれる背景にある課題など、 もっと俯瞰して見る必要があるなと感じた。 @koichikさんの歴史から辿っていく感じ
Introducing node-firefox – Mozilla Hacks - the Web developer blog
NOTE: we presented this project last Sunday at FOSDEM, but not everyone could make it to Brussels, so here’s a post explaining what node-firefox is and how can it help you superturbocharge your Firefox OS app development! At Mozilla we’re always looking for ways in which we can make developers’ lives easier. When aspiring app developers told us that it was cumbersome to get started writing Open We
npm とフロントエンドのパッケージ管理の未来
JavaScript 系パッケージマネージャの重複問題 npm は言わずもがな Node.js のパッケージマネージャだが、フロントエンド開発においては Bower も利用するのが一般的になっている。この現状の問題点は、package.jon と bower.json という似たような管理ファイルを二重で管理しなければならないということだ。 現状の使い分けをおさらいをしておくと、次のような感じになる。 タスクランナー（Grunt/gulp）・モジュールシステム（browserify/webpack）・テストスイート（karma/testem）などの開発環境系の管理が npm の主なお仕事。インストールされたパッケージは node_modules 内に展開されて、CommonJS スタイルのモジュール管理から利用する。 本題につながる話としては、ブラウザで動くライブラリの一部は npm にも
npm 2.0.0でローカルモジュールを使ってrequire('../../../')を回避する
概要 npm 1.xの時はローカルにあるディレクトリへの相対パスをdependencyフィールドで指定できなかった。 そのため、ローカルにあるモジュールをたどるにはrequire("../../../")のような指定が必要になっていた(ライブラリに切り出せればいいけど、アプリケーション固有のUtilsなどがある場合これ面倒になる) Better local require() paths for Node.js avoiding ../../../../../../.. How I Work Around The require(“../../../../../../../”) Problem In NodeJS | ThoughtStream.new :derick_bailey そのため、npm linkやnode_modulesにそのまま追加してやるなど、微妙なハックがひつようだった
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - shipitjs/shipit: Universal automation and deployment tool ⛵️