Vue.js: Revolutionary Front-end #1 http://abeja-innovation-meetup.connpass.com/event/38214/
はじめてのVue.js
Vue.js: Revolutionary Front-end #1 http://abeja-innovation-meetup.connpass.com/event/38214/
JavaScriptでパーサコンビネータのコンセプトを理解する(「正規表現だけに頼ってはいけない」の続き) - id:anatooのブログ
前回の記事の続き。前回は、正規表現が使えない時はパーサコンビネータを使ってみると良いということを書いた。 パーサコンビネータのためのライブラリは、以下のように各言語ごとにいくつかある。 JavaScript - Parsimmon Ruby - rparsec treetop Python - parsy PHP - PHPPEG 各言語でいくつかあるのだが、正規表現と違ってパーサコンビネータには統一的な書き方があるわけではないし、ライブラリによって使い方も様々である。なので、今まで正規表現だけ使ってきた開発者がちょっと使ってみようと思っても、使い方がよくわからずに面食らってしまうことがある。 パーサコンビネータはテキストをパースするための非常に強力な仕組みだが、その背後にある考え方を理解しなければこれらのパーサコンビネータのライブラリを使う際の障害になるだろう。逆に言うと、それさえ理解で
ライブラリをES2015(ES6)で書いて公開する所から始めよう
この記事はECMAScript 2015の事始めとして、ライブラリをECMAScript 2015で書いて公開するというところから始めるのがいいのではという内容です。 ECMAScript 2015(ES2015)はES6とも呼ばれていてどちらも同じものを指しますが、この記事ではES2015に統一します。 ECMAScriptのバージョンについては次のページを参照してください。 ECMAScript · JavaScriptの入門書 #jsprimer 2018-12-27: 追記 textlint/textlint-rule-helperのmasterはTypeScriptの実装へ変換されています。 Babelの実装はhttps://github.com/textlint/textlint-rule-helper/tree/2.0.1から参照できます Babel から TypeScrip
ES6のclassは巻き上げがされない - 素人がプログラミングを勉強していたブログ
ちょっとハマったのでメモ。 例えば alert(A); function A() { } はできるが、 alert(A); class A { } ができないのはなぜか。 class A { } class B extends A { } 例えば、このようなコードの場合、hoisting（スコープ先端への巻き上げ）をしても問題ないが、 関数と違ってextendsはその場で評価しなければいけないことがある。 例えば、 var A = function () { }; A.prototype.x = function () { return 1; }; class B extends A { } alert(new B().x()); というコードの場合、BクラスはAを継承しなければいけないので、var Aで宣言されているものはhoistingされないのでclass宣言もその場で評価しないと、
freeze/seal/preventExtensions の違いまとめ - うなの日記
ECMAScript 5 で追加された、Object.freezeやObject.sealを実行すると何ができなくなるのかについて。 こうなる。 preventExtensions seal freeze プロパティの追加 × × × プロパティの削除 ○ × × プロパティの値変更 ○ ○ × プロパティの属性変更 ○ × × 確認。 (function() { //"use strict"; // strict モードにすると、Firefox,Google Chrome,SafariではflozenObjectへの属性の追加等でもTypeErrorが発生するようになる。 // IEでは、非strict モードと変わらない動作をする。 describe('Flozen Object', function() { var flozenObject; beforeEach(function(
俺のaltjsがこんなに簡単にpegjsで作れるわけがない - Qiita
この記事はJavaScript Advent Calender 2014の10日目の記事です。 altjs作りたいやろ 半年前にこんなLTをやった。未完成で放置するのは気持ち悪いので、この機会に完成させようと思った…んだけど、advent当日の時点でまだ完成してない。すまんな。ただ知見は多少溜まったので、基本的なaltjsの作り方と合わせて紹介しようと思う。 altjsってどうやって作んの？ 方法は様々だけど、 文法をPEG(pegjs)で記述する ソースコードを、Parser APIで定義されるASTに変換するロジックを書く 変換されたASTを、escodegenでJavaScriptのコードにさらに変換する というのが今ならやりやすいと思う。結局ある構文をjsに変換するだけで、変換は既存のツールを使えるので、実はそんなに広い知識を要求せず、0から王道のコンパイラを作るみたいな壮大な話に
中間言語としてのJavaScriptはどうなったのか - .mjtの日記復帰計画
prev: http://d.hatena.ne.jp/mjt/20080904/p2 なぜか３年前の記事が急にブックマークされていたのでフォローする記事。 ↑の記事の1年後、InfoQの記事( http://www.infoq.com/news/2009/09/javascript-compilation-target )でいくつかのJavaScriptにコンパイルする言語が紹介された。もちろん、GoogleのGWT(Google Web Toolkit)もJavaScriptを出力するJava環境と言える。 先の記事で触れたエミュレータでの活用は、見たところDirect-threadingによるものに限られているように見える。つまり、CPU命令をJavaScript的なfunctionとして実装し、CPU命令と１対１対応させる。Google V8のような、Direct-threadin
言語女子会: undefとnullは両方必要？ - 西尾泰和のはてなダイアリー
Twitterのタイムラインが面白すぎて、ついうっかり言語を擬人化して脳内で言語女子会なるものを開いてしまいました。なお、登場人物と実在の人物は1対1に対応しません。 undefinedとnullの両方必要なの？ とあるプログラミング言語が集う女子会にて: Perl: そういえばさ、なんでJavaScriptちゃんってundefinedとnullの両方もってるの？ JavaScript: えっ、未定義の変数にアクセスした時undefined返したいじゃない？ Python: 例外投げて死ねばいいじゃん Ruby: 例外投げて死ねばいいよね Python & Ruby: ねー♡ Java: いやそこは参照型ならnull、数値型なら0で初期化すべきでしょ C: これだから最近の若い子は…初期化にだってコストが掛かるんだからね！デフォルトで初期化するなんて無駄遣いよ！必要な人だけが責任をもって初
Reactive Programming in JavaScript
- + 最近の小学校では、「お父さん・お母さんの名前をグーグルで検索してみましょう」という、世にも恐ろしい授業があるらしい。・・・。 — 丹 洋介 (@yosuke_tan) January 25, 2015
Pythonのラムダ辛い問題を解決する暗黙のプレースホルダ - タオルケット体操
＊ ネタ元 Rubyのブロックつらい問題を解決する暗黙のブロックパラメータ - Qiita RubyPythonのブロックラムダつらい問題 Pythonでショートコードをしようとおもうと、時々こういうことが起きます。 map(lambda it: it.upper(), ['foo', 'bar', 'baz']) それぞれの要素に対してupcaseを適用する、ただそれだけのためにitを2回も記述しなければなりません。っていうかそもそもlambda:って読みにくいです。 Pythonはラムダをあまり使わない言語なのでこの様なコードを書く機会は少ないですが、それでもちょくちょく出番があり、やがてあなたは辟易するはずです。 <中略> 参考になる例として、ClojureやScalaでは暗黙のパラメータ（プレースホルダ）を導入することでこの問題を上手く解決しています。 <例は省略> やりましょう
JavaScriptのデバッグ方法 – JSを嫌いにならないためのTips | POSTD
この記事のオリジナルは voxxed に投稿されたものです。 JavaScript関連の問題を抱えるチームをサポートする仕事を通じて、いくつか共通の問題点があることに気づきました。もしあなたもJavaScriptに対するイライラを感じているのであれば、この記事は何らかの助けになるかもしれません。おことわり：私がお教えするヒントはすでにご存知のものもあるとは思いますが、うまくいけば、多少なりとも有用な情報があるかもしれません。特にエンタープライズアプリケーションやCMSソリューションを構築する際に有効なヒントです。チームの誰もが話したがらないCMSのコードについてお話しします。いずれも必要に応じて採用できるものです。 debuggerステートメント 大半のブラウザでサポートされているにもかかわらず、JavaScriptを書く際に最も活用しきれていない機能の1つです。debuggerステートメ
WHATWG Streams APIについてのメモ - maru source
こんにちは丸山@h13i32maruです。 WHATWG Streams APIを少し触ってみたので、そのメモです。 ドキュメント WHATWG Streams このメモはLast Updated 21 January 2015を元に書いた whatwg/streams サンプルやリファレンス実装などがある このメモはcommit 879902を元に書いた Stream APIがブラウザにやってくる @jxckさんがnodeのStream APIと絡めてWHATWGのStreams APIを紹介している 概念 JavaScriptのプログラム中で処理する(大きめな)データの読み書きを統一的に扱うためのインターフェースをStreams APIとしてWHATWGが策定している。例えばXHRで大きなファイルを読み込んだ時にはすべてのデータを読み込んだあとにコールバックが呼ばれる*1。これだと読み
今時のブラウザが例外発生時にどんな情報を出しているのか調べてみたよ - latest log
本文には反映していませんが IE10で Error#stack が実装されました http://blogs.msdn.com/b/ie_ja/archive/2012/05/17/diagnosing-javascript-errors-with-error-stack.aspx JavaScript では例外が発生すると例外オブジェクトが生成されます。 この例外オブジェクトの仕様は標準化されておらず、各ブラウザで実装が異なります。 最新のブラウザで JavaScript の Error オブジェクトや Error から派生しているオブジェクトが持つ属性を調べてみました。 Safari Stable (Safari 5.1.1) try { throw new Error("hoge"); } catch (err) { var i, ary = []; for (i in err) {
Webパフォーマンスにおけるイニシャライズとランタイム
Webフロントエンド・パフォーマンス 思考整理系。 Webフロントエンドにおける3要素として、過去のセッションでは下記の3つを中心に紹介していました。 通信コスト - Networking 描画コスト - Rendering 計算コスト - Computing これらの問題は複雑に絡み合い、時として相反する関係をとります。例えば、通信コストを減らすために、視覚表現を画像からCSS3に置き換えたら、描画コストが高くなってしまいスクロールが重くなった、なんてケースは頻繁にあるでしょう。 理解の問題 この3つのコストは確かにパフォーマンスに影響を与える要因であります。しかし、その要因がWebフロントエンドのページライフサイクルにおいて、どこで影響を与えているかは表してくれません。 要因がどのような影響を及ぼしうるかという基礎的な理解と、パフォーマンスの問題に取り組むための切り口としての理解は、そ
basic.jsを作ろうとしてる話 // Speaker Deck
All slide content and descriptions are owned by their creators.
JavaScript の ; を省略する派 - Kato Kazuyoshi
むかし同じチームだったひとに、JavaScript のセミコロンを省略する派のひとがいて、他の人と「もう日本語かくとき句読点も省略すればいいじゃないの」とか、散々いっていた。でも実は GitHub も省略派らしい。 GitHub の JavaScript Styleguide は、まず最初の「新しい JS は CoffeScript で書け」にびっくりするのだけど、さらに読み進めていくと、既存の JavaScript について「なるだけセミコロンは使うな」とある。 Do your best to never use a semicolon. This means avoiding them at line breaks and avoiding multi-statement lines. For more info, read Mislav's blog post. 出来る限りセミコロン
小さいライブラリを採用する - mizchi's blog
僕がJavaScriptでライブラリを選定する際、迷ったら小さいものを使う。その理由について。 前提 前提として、枯れた環境で大きいフレームワークができるのは理解できるし、メリットも大きい。あるいは言語それ自身と区別できないぐらいに発達したフレームワークに依存するのも理解できる。RubyにとってのRailsとか、ErlangのOTPとか(いや、これは詳しくないけどそうなんだろうなっていう予想なんだけど)。 危険信号 今のJS界隈は動きが早すぎて、何に依存するのも危ない。とくにフレームワークと銘打たれたものは、でかすぎてどれも危険信号を放っている。 数年後、廃れてしまったフレームワークで開発し続けるのは、僕個人としてもあまり関わりたくないし、現場の離職リスクとして数字に出るだろうし、採用後の教育コストの問題になる。だいたいそういうものは元の設計者もいなくなるものだ。プロダクトの死を意味する。
10年以上Java屋してたおっさんが 今年からフロントエンジニアやっている話
Aug 21, 2014Download as pptx, pdf178 likes51,075 views
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Functional JavaScript/TypeScript
GitHub - mixi-inc/JavaScriptTraining: Training course repository for JavaScript
