【翻訳】AngularJSからReactへ: Isomorphicな方法 | POSTD
先週、私たちはWebサイトを検索エンジン向けにインデックス付けできるようにしようとしていました。この記事では、私たちがWebサイトを書き直していて学んだことの要約を紹介したいと思います。 背景 2ヵ月前に RisingStack.com を作成した時、私たちはそのWebサイトでどんなテクノロジを使うか決めなくてはなりませんでした。イベントを追跡する静的なページが数ページあるだけだったので、とても簡単でしたが、私たちはWebサイトをスケーラブルでできるだけ高速なままにしておきたいと考えていました。 私たちのチームは AngularJS の経験が豊富なので、フロントエンドにAngularを選ぶのは妥当だと思われました。 この記事はReactやAngularJSがどちらか一方より優れている理由について述べているわけではないので注意してください。どちらがいいかは常にユースケース次第です。 “Ang
Private Presentation
Private content!This content has been marked as private by the uploader.
開発者のマインドシェアを奪い合うJavaとNode.js | スラド デベロッパー
20年前には思いもよらなかったことだが、現在はJavaとJavaScriptがプログラミングの世界で覇権を争っている。InfoWorldのPeter Wayner氏が、昔ながらのコンパイラ方式のJavaが守り続けている領域と、Node.jsにより速度と柔軟性を獲得したサーバーサイドのJavaScriptが選ばれる領域との仕分けを行っている。 記事によれば、「コンピューティングの歴史で、1995年はとても忙しいときだった。Javaが登場し、JavaScriptが続いた。名前から同じ系統と思われがちだったが、2つは全く異なるものだった。一方はコンパイル方式で、静的型付けを使用するのに対し、もう一方はインタープリター方式で、動的型付けを使用する。これは2つのまるで方向の異なる言語の技術的相違点の一部に過ぎないが、Node.jsの出現により競合する方向へ進むことになった。」とのこと。
最近あまり使ってない、流行っていた時期もあるフロントエンドもの
最近あまり使ってない、ちょっと前の流行りもの なんとなく書いてみます。Web アプリケーション開発屋さんなので、Web サイト制作屋さんとはかなり文脈ズレると思います。 jQuery ファミリー 個人的には jQuery って、協業用のツールという位置づけでした。jQuery でさえ書かれていれば、jQuery 書ける人材のほうが外からも調達しやすいため、人員の流動にも有効と考えられる頃が確かにありました。 DOM に触れてくれるな勢の台頭 ところが昨今では AngularJS や React、その他ライブラリでも DOM 操作が大いに抽象化されていることが多く、jQuery で直接 DOM を操作すること自体が相性良くないケースが散見されます。今思えば Backbone.js くらいのころが jQuery 需要の最終ピークだったように思います。 jQuery プラグイン の需要減 jQu
io.jsとES6とトランスパイラまわりの現状 - 素人がプログラミングを勉強していたブログ
最近いろいろな環境でES6まわりの環境が整いはじめたので、使っていくために下調べしておこうと思う。 ES6の実装状況であるが、ECMAScript 6 compatibility tableにまとめが載っている。 例えば、io.js (nodeのfork)のES6実装状況。stableなES6 featuresが元から有効になってる。 現在有効なのは、文字列テンプレート、for of、generators, Promise, Map, WeakMap, Setなど。 最新版をターゲットにするのであれば、上の機能は何も考えずにそのまま使うことができる。 このうち、テンプレート、for of, WeakMap以外はpolyfillが手に入るので、それらを使わなければPromise, Mapなどはfeature detectして実装されていない場合はmoduleを読み込むことで幅広いバージョンを
JSDOMとReact.addons.TestUtilsでReactをヘッドレスにテストする - Qiita
JSDOMはnode環境でDOMをシミュレートするやつ。React.addons.TestUtilsはReactに同梱されているテストツール。この2つがあわさり最強に見える。 今作ってるライブラリのために、しばらくブラウザ使わずにテストしてたけど、ブラウザ立ち上げる必要なくて非常に快適。これ https://github.com/mizchi/arda/tree/master/test JSDOM、昔はとにかく不安定な印象だったけど、最近はよくできてる印象。見なおした。 コード # globalにdocumentとwindowを定義することで、DOM環境を参照できるようにする # 必ずReactの前に読み込むこと jsdom = require('jsdom').jsdom global.document = jsdom('<html><body></body></html>') # gl
io.js-v1.0.0のリリースによせて - ぼちぼち日記
1. 祝 io.js-v1.0.0/1.0.1 のリリース NodeやJSの情報にアンテナを張っている人なら知っているとは思いますが、昨日無事「io.js」がリリースされました。 リリース直前のバグ修正の追い込みやライブラリアップデートのごたごたは、かつてのNodeのリリースそのままでした。 今日のリリースを予言していたわけではないですが、実は昨年の8月初旬に、 ということを書いていました。 これがまさに現実になってしまったなぁ、と驚きと共に感慨深いものがあります。 Nodeの方は、今Julienが頑張ってチケットをクローズしており、近日中に Node-v0.11.15がリリースされる予定です。問題なければNode-v0.11.15のリリース2週間後にNode-v0.12 になるでしょう。 io.jsができた細かい経緯については、古川さんの「io.jsについて知っていること」が詳しいです。
The Refactoring Tales - JavaScriptのリファクタリング本を読んだ
GitHub: jackfranklin/the-refactoring-tales 読んだ日付: 2015年1月11日 まだ4章の途中までしか書かれてないですが、ウェブ版は無料で読めてPDF版等は買えるようになるようです(6-7章ぐらい予定) The Refactoring Tales - JavaScript Playground またGitHubにソースが公開されています(ウェブページはまだ反映されてない感じのtypoの修正等がありました) 感想 1,2章はフロントのJavaScriptで、jQuery世界を例にjQueryでべったり書いてしまったものをどうやって分けていくかの話。 1章はとても読みやすくて完成度もあるので読んでみるといい気がします、2章のカヌーセルの話はもっと深くやっても良かったような気がします。 縦に並ぶ$を見かけるとつらい感じになりますが、まずは手が出しやすい場
io.jsについて知っていること - from scratch
今、Node.jsに起きてることを語る上で、io.jsは避けて通れない話題でしょう。 今回のNode.js アドベントカレンダー 2014の締めを飾るために、このio.jsについて僕が知っている限りの事をまとめて書くことにします。 io.jsを知り、今後"Node"がどうなっていくのかを皆で一緒に考えていきましょう。 またこの一連のio.jsのfork騒動はOSSという特殊なプロジェクトをどう進めていくのがハッピーなのかを知る一つの教材だと思います。 OSSに関わっている皆さん、今回も長いですが、最後まで読んでもらえると幸いです。 io.js とは何か Node.jsのForkです。次のNode.jsの安定版になる、v0.12をForkしています。「アイ・オー ジェイエス」と読みます。名前の由来は木星にある四番目に大きな衛星の名前から取られました。*1 Nodeを使っている人のことをnod
【翻訳】いいDockerイメージを構築するには？ ーDockerfileのベストプラクティス | POSTD
Dockerレジストリ は、今やあふれんばかりの状況です。これを書いている時点で、”node”と検索すれば、1000件弱の結果がヒットします。どうやって選べばいいのでしょうか？ いいDockerイメージを構成するもの いい悪いは主観ではありますが、私がいいと考えるDockerイメージには、いくつかの基準があります。 実用的： 以下に例を挙げます。 最初にコンテナにアップデートを適用しなくても、Android SDKのイメージがプロジェクトをコンパイルできる。 MySQLのコンテナが、データベースとユーザを使用してサーバをブートする方法を明示する。 最小限： コンテナの利点は、アプリケーションをサンドボックスできること（セキュリティがない場合には、ホストファイルシステム上で混乱を避けられること）です。ホストシステムにnode.jsをインストールしたり、JDK（Java開発キット）でシステムを
npm で依存もタスクも一元化する - Qiita
タスク管理 package.json にはパッケージの依存を書いて npm install するのが基本だけど、 タスクの管理をどうするかというのは、別途また考えないといけない。 自分は gulp が良いと思っているが、 grunt や jake や make を使う人もいる。 また、たくさんオプションをつければほぼ一つのタスクが実行できてしまう browserify, jsh/eslint, mocha などのコマンドを提供するツールもある。 そして、 npm にも一部それらをサポートする npm run 機能があるので、そこに Unix ワンライナーを書くこともできる。 今回は、「どのタスクツールが最良か」みたいな話ではなく、それらをどうやって実行するか、または npm との棲み分けとか構成の流儀について、最近良いと思っているやり方について書いておく。 各方針で問題点を書いていくが、
npm とフロントエンドのパッケージ管理の未来
JavaScript 系パッケージマネージャの重複問題 npm は言わずもがな Node.js のパッケージマネージャだが、フロントエンド開発においては Bower も利用するのが一般的になっている。この現状の問題点は、package.jon と bower.json という似たような管理ファイルを二重で管理しなければならないということだ。 現状の使い分けをおさらいをしておくと、次のような感じになる。 タスクランナー（Grunt/gulp）・モジュールシステム（browserify/webpack）・テストスイート（karma/testem）などの開発環境系の管理が npm の主なお仕事。インストールされたパッケージは node_modules 内に展開されて、CommonJS スタイルのモジュール管理から利用する。 本題につながる話としては、ブラウザで動くライブラリの一部は npm にも
browserify をはじめてみる
Browserify を触ってみたメモ。 Browserify とは CommonJS のモジュールの仕組み、つまり Node.js の require をブラウザ上でも使えるようにするもの、ということでいいみたい。Readme を読む限りは、npm にあるモジュールをブラウザ上にもっていくために作られ始めたような印象をうけるが、ちまたのエントリーをみていると AMD に代わりに CommonJS でフロントエンドの依存関係の管理をする (RequireJS ではなく、Node.js 感覚で require 関数をフロントエンドで使う) ためのツールとしても使っていいようだ。 やりたいこと 複数の js ファイルの依存関係を記述したい 最終的に、依存関係を考慮した順番で、ひとつの js ファイルに結合したい 作りたいのは第三者のサイトに埋め込んでもらうスクリプト (サードパーティスクリプト
世界のJavaScriptを読もう @ 2014
世界のJavaScriptを読もう @ 2014 ^目的: ウェブの世界は絶対変化するもの 変化する前提の行動が求める それをどうやって見ていくか、それを知ってどうするか ^ JavaScriptやブラウザ周りのリリースの状況はウェブの変化にあわせるように変化してきている。 どのように変化してきたか知り、どうやって変化を見ていくのか、そしてわたしたちはどう変化していくのかを考えよう。 アジェンダ 世界のJavaScriptを読もう @ 2012 の続編的なものです ブラウザやJavaScriptのリリースは変化してきている 私たちはどのように変化を知り見ていくのか そして私たちはどのように変化していくのか [fit] 世界のJavaScriptを見る話 [fit] JSer.info 開始 2011年〜 ^ JSer.infoを始めた2011年を一つの基準として考えて、 そこからブラウザや
#10 node.js sideshow | mozaic.fm
#10 Node.js SideShow Theme 第10回目の SideShow です。 @koichik さんの「ところでみんな Promise 好き？」から始まった、 Promise / Generator / Rxjs などの話題と、 Java の Future や Haskell の Monad との関係などの解説です。 エピソードの感想などは、 #mozaicfm までお願いします。 Guest @koichik @yosuke_furukawa Show Note 0:00 ~ : そもそもみんな Promise 好き? ES6 Promise WindJS カール・ヒューイット 1:40 ~ : そもそもの Promise とは？ Java の Future Haskell の Thunk 7:30 ~ : 本当に Promise は必要なのか？ Scala の Opti
自堕落な技術者の日記 : 様々なサーバーのPOODLE SSLv3脆弱性(CVE-2014-3566)対策のまとめ(更新3) - livedoor Blog（ブログ）
基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 もくじ 1. はじめに 2. SSLv3を無効化できる場合のサーバー対策 2.1. Apache HTTPD Server + mod_ssl 2.2. Apache HTTPD Server + mod_nss 2.3. nginx 2.4. lighttpd 2.5. Microsoft IIS 2.6. (訂正)Apache Tomcat (Java JSSE) 2.7. Node.js 2.8. IBM HTTP Server 2.9. Amazon Web Services 2.10. その他のサーバー 2.11. SSLv3 を無効化するリスク 2.12. OpenLDAP 3. 諸般の事情で SSLv3 を有効にせざるを得ない場
npm Blog Archive: npm@2.0.0
The npm blog has been discontinued. Updates from the npm team are now published on the GitHub Blog and the GitHub Changelog. Last week, I released npm@2.0.0. If you’ve been using npm@1.4, it’s a substantial update, but that’s not why it’s 2.0.0. npm@1.0.1 was released on April 30th, 2011 – three and a half years ago. 1 That’s basically the entire lifetime of Node as a viable platform. Why bump the
node.jsのnative addonを作るときはNANを使おう。 - from scratch
さて、 Node.js v0.12 で変わることの一つとして、native addonを作る時に後方互換性を壊す変更が加えられています。 これにより、v0.10でnative addonを作っているモジュール達は、ほとんど動かなくなってしまうことが考えられます。 V8側がこの後方互換性を壊す変更をしているため、V8に追従しているNode.js側としてはこのbreaking changesを受けざるを得なかったんだと思います。*1 どれくらい変更されてるのかは node.js の native addon で Hello World モジュールを作る方法が載っているのでそれをまずは参考にします。 // これまでの v0.10ではこう書いてた。 #include <node.h> #include <v8.h> using namespace v8; Handle<Value> Method(
Node Express でそこまで取り上げられていないあれこれ
くまくらです。 私は API サーバを実装する際に Node の Express を利用する事が多いので、今回は使っていて知った事のうち、世間的にはポツポツ程度にしか取り上げられていない事柄をいくつかあげていきます。簡単に Express を利用している初心者レベルを主な対象としています。 前置き 以後の文中にて登場する名称／変数値は、Express API リファレンス を始めとした各種ドキュメント内でも扱われているものと同等に、以下のインスタンスを指すこととします。 app: Application インスタンス req: Request インスタンス res: Response インスタンス routes: Application インスタンスによるURLルート定義にてマッピングされた Middleware app, req, res のライフサイクルについて 本当に基本的なことです
Farewell Node.js (翻訳) - from scratch
「visionmedia、Node.js辞めるってよ」って事で、今回はこの話の翻訳ですね。 Farewell Node.js — Code adventures — Medium 最近のnode.jsはホントTJ Fontaine のリーダー就任から始まってNode.jsでできたエディタであるAtomがreleaseされたり、gemのモジュール数をnpmのモジュール数が抜いたり、socket.io v1.0が出たりと色々あるんですが、今回の話は飛び抜けて衝撃的だったなぁと思ってます。 一応知らない方のためにvisionmediaについて説明しておくと、以下のモジュールは全てvisionmedia製です。 express (Web Applicaiton Framework) mocha (Testing Framework) jade (hamlライクなtemplate engine) s
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
