優れたテストの重要性 - IT戦記
JavaScript の進化 ここ 1, 2 年で JavaScript という言語は何倍も高速化されました。 それは何故でしょうか。 その要因を少し考えてみました。 SunSpider の出現 その一番の要因は、 JavaScript のパフォーマンステスト SunSpider ではないでしょうか。 SunSpider によって、シンプルで分かり易い JavaScript エンジンの指標が誰にでも分かる数字として提供されたのです。 これと似たような事例として、 acid2 test 、 acid3 test があります。 このテストも、レンダリングエンジンの正しさを分かり易い数字や絵として提供しました。 その結果、今日のウェブブラウザのレンダリングエンジンは目覚ましい進化を遂げたのです。 まとめ 進化の裏にはテストあり。 テストはソフトウェアの最良のマーケティング手段かも。 面白くて分か
クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか？ - @kyanny's blog
TL;DR - 最初の一人はつらいけど後続はそうでもないので先駆者は自覚と誇りを持ってオールグリーンを維持しよう このエントリはMarionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogというエントリの続きにあたります。未読の方は先にそちらを一読されることをおすすめします。 Marionette.js ベースで3ヶ月開発したアプリのカバレッジ推移をまとめてみた - @kyanny's blogの結論で触れたように、今回テストを書くことにこだわったのは、「クライアントサイド JavaScript (AltJS) のテストを書くのは本当に難しいのか？」という問いに対する自分なりの回答を実践して検証してみたかったという理由があったからだ。 以前から「クライアント JavaScript (CoffeeScript や他の AltJS を
JavaScriptの文化とleftpadの話とpadStartについて - from scratch
無駄にラノベみたいに長いタイトル書いちゃったんですが、まぁやっぱり一言くらいは残しておくかと思ったので書きます。長いのでまとめだけでも見てもらえると良いかもしれません。 leftpadの話はかなり大事になっていて、Node.js界隈を中心としてその他のOSSをやっている全体的に話が波及しています。幾つかの記事を読みました。今回はJSの文化と歴史についてちょっとずつ書いていこうかなと思います。 本の虫: npmからkikとその他諸々が消されたまとめ 江添さんの話はすごくよくまとまっていて、ネタも含めた上で一番面白い話になっていました、ここで言われている下記の疑問に答えていこうと思います。 もっと憂うべきパッケージがある。isArrayだ。このパッケージは一日88万回もダウンロードされていて、2016年2月だけの一ヶ月間に1800万回もダウンロードされていて、72個ものNPMパッケージが依存し
Webフロントエンドの人達(?)が次々と微妙なツールを導入して「流れが早過ぎる」とつぶやいているのを横目で見て感じている事 - latest log
自分の会社に「新ツール導入の際はCTOの許可が必要」というルールを生やして居心地を悪化させたり、後輩のやる気を削りたくなかったら、ツールの将来性を考えて行動したほうが… SI等のアレな現場にその手のルールが存在するのは何故なのか?という事と、自分達もその歴史の一節にならないように— コラーゲンたっぷりさん (@uupaa) November 20, 2015 必要な物は生まれる(創れば良い)ので、どんな問題がありどのような解決方法があり、状況の変化にどう対応するかなど、大人はツール導入前に織り込んでおくし、”勉強会の人が流行ってるって言ってたし”ですぐ廃れるツールを導入するなんて事を繰り返してると、あっという間にデストピアな職場に。な— コラーゲンたっぷりさん (@uupaa) November 20, 2015 “ツール導入で劇的に効率や抱えている問題が改善される”なら導入すればいいし、
最近あまり使ってない、流行っていた時期もあるフロントエンドもの
最近あまり使ってない、ちょっと前の流行りもの なんとなく書いてみます。Web アプリケーション開発屋さんなので、Web サイト制作屋さんとはかなり文脈ズレると思います。 jQuery ファミリー 個人的には jQuery って、協業用のツールという位置づけでした。jQuery でさえ書かれていれば、jQuery 書ける人材のほうが外からも調達しやすいため、人員の流動にも有効と考えられる頃が確かにありました。 DOM に触れてくれるな勢の台頭 ところが昨今では AngularJS や React、その他ライブラリでも DOM 操作が大いに抽象化されていることが多く、jQuery で直接 DOM を操作すること自体が相性良くないケースが散見されます。今思えば Backbone.js くらいのころが jQuery 需要の最終ピークだったように思います。 jQuery プラグイン の需要減 jQu
Sprockets再考 モダンなJSのエコシステムとRailsのより良い関係を探す - Qiita
すいません。締切守れませんでした…。 やっぱ、java-jaの忘年会の翌日は辛い…。 はじめに Webシステムを開発していると切っても切れないのがJavaScriptです。 Railsはかなり早い時期からalt-JSや結合、minify等を組み込めるようにフレームワークにそれを取り入れてきました。 それを支えているのがRails3.1から導入されたsprocketsです。 それに伴なってJSのライブラリをどうやって管理するかという点について、独自の路線を取ることになりました。 JSのライブラリを同梱したgemパッケージにラップしてrubygemsとして管理する方法です。 ある程度は上手くいっていたし、今もその流れは続いているんですが、時々問題になることもあります。 例えばメンテナの対応時期がズレてて古いバージョンのままだったり、似たようなgemが乱立してややこしくなったり。(backbon
#ガチJS でJavaScriptとフロントエンドの未来について熱い話をした - mizchi's blog
(追記): このブログで一部のJSをgithubに置いてたら 「The website abuses rawgit.com」という警告が出てました。現在修正しました。ご迷惑おかけしました。 @kyo_agoさんの主催で、 @mizchi(シングルページ系フロントエンドJSer) と @damele0nさん(ゲーム系HTML5のJSer)でJavaScriptについて話をした。すごく有意義な話だったので、会話を思い出せる限り書いてみる。 このエントリを読む前にこの記事を読むと幸せになれる。 幸せになりたいソーシャルゲーム系Webフロントエンドエンジニアが本気で考える HTML GUI ツール第一回 - damelog このまとめは僕の主観であり、僕が理解できた部分と自分の発言を一番覚えてるのでどうしてもそれが多めになりますが、ご容赦ください。ついでに酒入ってる。 iOS SafariのIE化
クライアントサイドJavaScriptのライセンス管理 | GREE Engineering
最近シリコンウエハーもらって嬉しかったago（@kyo_ago）です。 このエントリはGREE Advent Calendar 2013 11日目の記事です。 今回はクライアントサイドJavaScriptにおけるライセンス管理の問題を取り上げたいと思います。 ライセンス管理の問題点 「使用しているライブラリのライセンス管理をどうするか」はクライアントサイドJavaScriptにかぎらず発生する問題ですが、クライアントサイドJavaScriptには以下の様な特徴があるため問題が複雑になります。 コードが結合、圧縮される場合がある クライアントサイドJavaScriptでは読み込みの速度を上げるため、使用しているライブラリの結合、圧縮を行うことがあります。しかし、この時誤ってライセンス文が捨てられてしまうことがあります。 ソースが外部に公開される クライアントサイドJavaScriptではソー
Polymer と Web Components - steps to phantasien
先週はサンフランシスコで勤務先の年次博覧会が催され、中には自分と近いプロジェクトを紹介するセッションもあった。 いい機会なので便乗して宣伝してみたい。自主会社員活動につき勤務先の見解と違っても見逃してください。 さて件の年次博覧会、ウェブ開発者向けの講演の一つで Polymer という新しい JavaScript UI フレームワークが公開された。 Closure, GWT, Angular ときて また別のフレームワークかよ…とぼやく人の気持ちもわかる。でもそれほど被るものでもないから見逃してほしい。 なるべく多くのブラウザで動かそうとする既存のフレームワークと違い、 Polymer は新しいブラウザの機能を使い倒すことで強力なフレームワークを作ろうとしている。 別に特定ブラウザでしか動かないわけじゃない。ただ将来そうした新しい機能が各種ブラウザに備わる日を見越し、 そのときベストに動く
js で利用する DOM の名前をどうやってつけたらよいのか - おもしろwebサービス開発日記
js で DOM をゴニョゴニョしたい時、きっと皆さんは id や class で DOM に名前を付けて、その名前を利用して js の処理を書いていると思います。 例えば<input type="button" class="update" value="更新" />のようなボタンがあったとして、 js 側で更新処理を書くときには下記のように書きます。 $('.update').on('click', function () { // update 処理 }) でもこれだと問題になるケースがあります。よくあるのが、マークアッパーとフロントエンジニアが分業していて、マークアッパーがデザインのために class 名を変えてしまい js が動かなくなるパターン。分業せずに一人で全部やってたとしても、時間が経つにつれ使っている class 名が js だけで使っているのか、css でも使っている
なぜ CoffeeScript がよいか - 0xff.toBlog()
なぜ CoffeeScript がダメか - 冬通りに消え行く制服ガールは✖夢物語にリアルを求めない。 - subtechについて。 いや、本当はこのタイトルにするほど CoffeeScript 推しているわけではないのですが、まあそういう建前で書きます。 CoffeeScript のメリット 簡潔に書ける 簡潔であるということは、ソースコードにおいて、本質ではない部分を書かなくてよいということで、逆に言えば必要なことだけが書かれている状態に近くなります。少し慣れればむしろ読みやすくなる(と思います)。 JavaScript の罠を回避できる var を忘れた変数がグローバル変数になるとか、変数のホイスティングとか、オブジェクトリテラルの最後のカンマとか、 JavaScript の for in は prototype を辿ってしまう問題とか、JavaScript の等価演算子が曖昧すぎて
ベターJavaScript!? CoffeeScriptが注目されるワケ：Rails Hub情報局：エンジニアライフ
JavaScriptへコンパイルして実行することを前提としたスクリプト言語「CoffeeScript」がちょっとした注目を集めています。CoffeeScript自体は2009年末に登場し、その1年後の2010年12月にバージョン1.0がリリースされていますが、注目を集めたのは、数日前（2011年4月13日）にRuby on Railsの生みの親であるDHHが、次期バージョンのRails3.1でjQueryやSCSSと合わせて、CoffeeScriptをデフォルトとして採用するとTwitter上で発言して議論が巻き起こったからです。 Yes, it's true, Rails 3.1 is going to ship with CoffeeScript and SCSS in the box for use with the new asset pipeline. It's bad ass.
個人で使うドリコム式行動ターゲティング広告 - ぼくはまちちゃん！
はい！こんにちはこんにちは！ こんどは寝すぎで、ちょっぴり調子のおかしなはまちや２です！ こんにちは…！ ところでちょっと前に、こんな記事がありましたよね！ 行動ターゲティング広告はどこまで許されるのか http://it.nikkei.co.jp/internet/news/index.aspx?n=MMITbe000015102008 これの仕掛けの部分だけを簡単に説明すると… 見たことのあるページのリンク(visited)は色が変わったりする スタイルで、visitedなリンクと、そうでないものの高さとかを変えることができる 高さとかはJavaScriptで取得可能、つまり訪問済みリンクか取得可能 ページのどこかに、色々なサイトのURLを大量に隠しリンクしておく それぜんぶJavaScriptで調べて、来訪者が行ったことのあるページを把握 訪問済みサイトの傾向にあわせて広告表示 (簡
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
LLPlanets - JavaScriptプログラマのための 全方位的完全武装ガイド
Admiral
http://inucara.net/presentation/about-inucara.net/