フロントエンドの開発環境に Docker は不要(少なくともMacでは) - mizchi's blog
追記: 前提部分 開発環境を docker-compose で抽象することが最近のベストプラクティスだとされているが、フロントエンドをコンテナに突っ込むと無視できないIOボトルネックが発生する。 とくにwebpackのファイル監視からのビルドで発生する高頻度のIO処理を捌くために、フロントエンドだけはホスト環境に移したほうがいい、という主張。 これについて speakerdeck.com 自分の意見 Web開発者の主要な開発環境である Docker for Mac は I/O がとにかく遅い (3x~5x) data volume の driver やら cache を工夫しても遅い npm install/webpack は 基本的に I/O ヘヴィー とくに大規模開発時の watch => build がクリティカル webpack.conifg の entry で自分が関与する部分以
pyenvが必要かどうかフローチャート - Qiita
pyspaの統合思念体の渋川です。 「pyenv使いましょう！」系の記事、全部ゴミ — Yoshifumi YAMAGUCHI (@ymotongpoo) September 29, 2016 これはpyenvがダメではなくて、pyenvをとりあえずインストールしておきましょう記事がダメという意味だそうです。すでにとんぷーが5年前にこの問題について書いています。これを読んで分かる人には不要です。 この記事では「便利」と「必要」は分けて考えています。後者にフォーカスしています。 前提知識 Environment Isolation Tool(環境分離ツール)というカテゴリの開発補助ツールがあります。pip install Sphinxとか書いたら、ライブラリはグローバル空間に入っちゃいます。複数バージョン入れられません。そんなときに使うのが、この環境分離ツールです。最近はいろいろな言語がこれ
Rubyが今のPythonの地位にいない理由
_ Rubyが今のPythonの地位にいない理由 歴史のことなんぞなんも知らんけど、「技術的には今のPythonの地位はRubyでもよかったのに、そうならなかった」のが何故か、その理由を書いてみよう。僕はRubyの歴史なんて知らないし、以下の文章は全部、まるで見てきたかのように書いてますが、適当に書いたくせに何故か断言口調になっている怪文書の類いです。 https://twitter.com/mametter/status/741950239662170112 まめさんの書いた理由リストはどれも関係ない。いやカスってるけど。難しいというのも関係ない。 僕がRubyを知ったころ…最初に書いた通りRubyの歴史なんて知らないので、別に早くもないわけだけど…Rubyというのは全く使われていない言語だった。どっかの好き者がPerlの替わりに単純な処理に使って、「ウフ、美しくかけた、グフッ」とかつぶ
Gopherの道を歩む – Node.jsからGo言語への移行 | POSTD
私は大学時代に、興味本位でJavaScriptを始めて、それ以来ウェブページを幾つか作成してきました。JavaScriptは常にC言語やJavaの合間の楽しい息抜きでしたが、アニメーションや、ユーザをあっと言わせるようなちょっとしたことを提供するといった、特殊な目的にかなり限られた言語だと考えていました。JavaScriptは覚えやすく、開発者に具体的な結果をすぐにもたらしてくれるので、コーディングする方法を学びたいと思っている人に私が教えた最初の言語でした。JavaScriptにHTMLとCSSを少し組み合わせれば、ウェブページが出来上がります。プログラミング初心者には喜ばれます。 その後、あることが2年前に起こりました。当時、私は、主にサーバーサイドのコードとAndroid用のアプリのプロトタイプに取り組む研究職に近い立場にいました。すぐにNode.jsの存在が目に留まりました。バック
Issac Schlueterが語るNode.js v1.0へのロードマップ - ワザノバ | wazanova.jp
http://www.youtube.com/watch?v=82hJbjqbIt4 Node.jsのコアチームのリーダであるIssac SchlueterがSan FranciscoのMeetupで、Node.js v1.0にむけての現状アップデートをシェアしてます。 Stream2のステータス 相当リファクタリングした 99%後方互換性 npmの計画 githubログイン、githubレポジトリとの統合 レコメンデーションエンジン モジュールランキング: CPAN Kwaliteeっぽいものにしたい Node.jsは成長した APIが壊れるなんて過去のこと。我々は大人になった。 今動くコードは来年も動く Node.jsがたった4年半でここまで成熟するとは皆思わなかったはず。 だからNode.jsコアは小さなサイズをキープしたい Node v0.12 TLS (Transport La
The Node.js Community is Quietly Changing the Face of Open Source | caines.ca
The Node.js Community is Quietly Changing the Face of Open Source If you consider the number of packages on pypi, npm, and rubygems, and the release dates of python (1991), ruby (1995) and node.js (2009), it looks a lot like those communities are getting new packages at the following rates, per year: python: 29,720 packages / 22 years = 1351 packages per year ruby: 54,385 packages / 18 years = 302
簡単に手元でHTTPのファイルサーバ立てる方法 - かみぽわーる
.zshrcにstatic_httpdって関数つくってる。 dotfiles/.zshrc at master · kamipo/dotfiles · GitHub function static_httpd { if type plackup > /dev/null; then plackup -MPlack::App::Directory -e 'Plack::App::Directory->new(root => ".")->to_app' elif type ruby > /dev/null; then if ruby -v | grep -qm1 'ruby 2\.'; then ruby -run -e httpd -- --port=5000 . else ruby -rwebrick -e 'WEBrick::HTTPServer.new(:Port => 5000, :D
uu59のメモ | Node.jsの癌騒動まとめ
承前 まずNode.js is CancerでTedさんは以下の3点を問題視しました。 ブロックしないから速いとかプログラマは未熟でもいけるとかスケーラビリティとか全部大嘘だろう システム管理者にやさしくないアーキテクチャ JavaScript製 あまりに感情的で論点が曖昧なこの記事に、多くの人がtrollingだと指摘しつつも色々と論を展開しました。 2日後に出たTed本人によるフォロー記事では主に1点目について掘り下げています。 まず数学を使ってイベントモデルとスレッドモデルのそれぞれのスループットについて考察していきます。数式や変数展開の説明をしていくと長いので要点だけまとめると以下のようになります。 スレッドの実行数を増やせばCPU-boundなときはもちろんI/O-boundなときでもスループットを伸ばせる 理論的にはイベントモデルでもスレッドモデルでもスループットの最大値（＝限
なぜ coffee-script が盛り上がるか - mizchi log
情報感度が高く体面を気にするIT企業の皆さんは、今日はさっさと帰れと言われてるので、やることなくなったエンジニア達がcho45さんの釣り針に釣られてハッスルしているのだと思われます。弊社も朝からudzuraあたりがハッスルしてるのをみてました。 暇なので大喜利に参加。というか、他の方が言及していない、なぜcoffee-scriptの良い面、について書きたいと思っています。 -> のエイリアスが、関数オブジェクトの意識を変えた > の関数定義はJS本来の関数型言語への意識を呼び覚ましました。そもそも今までが関数型もどきの言語ポテンシャルだったくせに関数オブジェクトが文字数的な問題で使いにくかったのです。 テンプレートエンジンのCoffeekupでは、高階関数の入れ子によってDOMを表現するなんてこともやってます。 doctype 5 html -> head -> meta charset:
Node.js の環境管理(version manager) について。 #nodejs_jp
[追記] nvm は .zshrc のいじり具合によっては、表示がうまくいかなかったり、すこし変な動きをしたりすることが有るという意味で。nvm 自体はそれらを事細かに対応するつもりはなく、自分は bash に切り替えることで全ての不具合を回避しているという意味です。「nvm は使い物にならん」とか「インストールもまともに出来ない」などと言うつもりはないし、書いてません。実際今使っています。 全ては自分が zsh を使っていることに起因している。 node.js v0.6 のリリースと npm のアップデートも有り、 一旦環境を見直そうと .nvm/ .npm/ を全部消した。 折角ならツールも見直してみようかと思ったが、あまり変わってなかった。 node.js の環境管理(version manager)は以下のものがある。 nvmnavennodeenvnvm(https://gith
LL Planets来たった - Life goes on
今日はLL Planetsに来てます。以下内容のメモ書き。Twitterやってないんでここに書くけど、ほぼリアルタイムで。 (2011/08/25追記：公式に当日使われて許可済みのスライドがまとめられていました) メタプログラミングの光と影 Perl、Ruby、Python、Heskellでのメタプログラミングの紹介 Perlではあんまり、メタプログラミングは使わない印象だけど、パーサーまでメタプログラミングでイジる事ができる。 RubyはrailsでDSLが爆発的に増えた感じ。元々RubyのAPIは豊富にある。 Pythonも言語自体でサポートされている機能で内部DSLなどはできるが、外部DSLは苦手。 Heskellは、コードが分からなすぎてワロタ。だけど、関数パーサーなどは手軽に出来る。あと、型安全って良いですね。 基調講演：「JavaScriptプログラマのための全方位的完全武装ガ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBMがRustを使ってNode.jsのプロジェクトを書き換え。その背景とは？
Windows Azure
LinkedIn での Ruby on Rails 対 Node.js
GitHub - hakobera/nvmw: Simple Node Version Manager for Windows