タグ

JavaScriptと*articleに関するtomk79のブックマーク (6)

  • 新・三大JavaScriptフレームワークの実践(Backbone.js Knockout.js Angular.js) - Qiita

    Todoリストの機能 1.テキストボックスから、Enterで追加できる 2.登録したTodoはダブルクリックで編集可能になり、Enterで編集確定できる 3.登録されているTodoの総件数がフッターに表示される 4.完了したTodoがある場合、それらをリストから消すボタンが表示される 5.全選択/解除を行うチェックボックスがある 個人的な結論 趣味開発で使うならAngular.js・仕事で使うならKnockout.jsをお勧めしたい。 まず、フレームワークを選択する際は、以下3つの選択基準を持つとよいと思う。 1.開発の規模 大規模ならBackbone.jsはお勧めできる。 書き方が決まっていて、チュートリアルに目を通せば(面倒なのは置いておいて)何を作らなければならないかは簡単に理解できる。そこそこの人数で長い時間の開発を行うなら、UIチームはアプリケーションとView、サーバーサイドは

    新・三大JavaScriptフレームワークの実践(Backbone.js Knockout.js Angular.js) - Qiita
    tomk79
    tomk79 2014/04/21
    JSのMVCフレームワーク比較
  • バーコードをjavascriptで作ってみた - コイン 2個 いれる

    ふと、バーコードってどうやって作るんだろうと疑問に思って調べたら、 英語Wikipediaにのってました。 参照→Wikipedia: European Article Number なるほど、単純に7桁ずつのグリッドになってて、0と1で塗り分けてるんですね。 仕様を作る時は誤読を少なくするような苦労があったんだと思いますが、仕様に沿って作るのは単純作業のようです。 C#で作ったら簡単だったので、javascriptにして動くようにしてみました。 ポカミスを繰り返して以外に大変でした。やっぱjavascriptは向いてないな。 JISは読んでいないので細かい仕様は分からないのですが、一応、携帯のバーコードリーダー機能では読めました。 作り方を説明しますと、例えば4901234567894の場合、 最初が4なので、パターンが LGLLGG RRRRRR になります。 2桁目以降は数字によっ

    tomk79
    tomk79 2014/01/20
    バーコードの作り方。
  • 日本人が開発したJavaScriptライブラリ、エンジニア別国内利用率ランキング - ふろしき Blog

    エンジニアGitHubにソースコードを上げると、転職で有利になる!」なんて言われている時代ですが、当にそうなのでしょうか?多大な時間を割いて、ソースコードを管理し、マニュアルを作り、特設ページを作り、公開することに意味はあるのでしょうか? 昨年の11月、ふろしき.jsでは1,300の優秀と評価されたWebサイトを調査し、利用率の高いJSライブラリをランキング化しました。実はこの調査、一筋縄ではいかず、実際には1,800弱とデータサンプルとしてはそこそこな母数を確保し解析しています。 その調査の中で、わかったことがあります。 フロントエンドは、日エンジニアが個人で開発したようなOSSのJSライブラリが多く含まれ、重要な部品として活用されているのです。個人でも入り込める隙がある、そう思うと、フロントエンド界隈でGitHub上にソースコードを公開するモチベーションは、比較的高いのではな

    日本人が開発したJavaScriptライブラリ、エンジニア別国内利用率ランキング - ふろしき Blog
  • 今すぐ辞めて欲しい、「jQuery勉強してます」「Backbone.js勉強してます」

    最近、といってもここ2年ぐらいからだけど、「jQueryの勉強してます」とか「Backbone.jsの勉強してます」とか、そういう人からのプログラミングの修得の相談とかを頂いたりする機会が多い。 それらの中で、非常に口をすっぱくして言っているんだけど、なかなか理解して頂けないのが、『「jQuery」や「Backbone.js」を使うな』という個人的なアドバイスだ。これは個人的には当に守ってほしい、絶対に手を出してほしくない、Framework達である。 なぜかみんな「jQueryってイケてる技術だよね」「jQueryだったらこんなこともいとも簡単にできちゃうんだよね」みたいな印象を持っている。もちろん、それは間違いではない。jQueryは早い。ライブラリもたくさんある。コミュニティも活発だ。リッチなウェブサイトなんて昔は数人月かけて作ったものだが、いまはjQueryとプラグインなんて使え

    今すぐ辞めて欲しい、「jQuery勉強してます」「Backbone.js勉強してます」
  • RequireJSを使うのを止めた理由 | それなりブログ

    RequireJS はみんな使ってるらしーし、 何かかっこいいし、意識高そうだし、使っとくか! ・・・と、思って試しに使い始めてみたのですが、 自分が作るような小規模なものの場合、 大変な割に良い事あんまりないので使うのを止めました。 以下、忘れそうなのでその理由をメモって置きます。 基的に、1枚のJSファイルが1モジュール、ファイル名がコードに影響する。それもあって、結合・圧縮は r.js という専用のツールが必要になる。Grunt の concat とか uglify とか使えない。 AMD の仕様では、「JSファイルのリストを順番通りに読み込み/実行する」ということができない。実際何が困ったかというと、分割した mocha テストケースを順番通りに実行できなくなったということ。結果は変わらなくても、順番通りに実行されないと結果が見辛いし、問題が起こった時に発見が難しい。ただしこれは

  • require.js 環境で mocha + expect + testem を使った JavaScript テスト - naoyaのはてなダイアリー

    先日書いた自分用アプリケーションのひな形 http://d.hatena.ne.jp/naoya/20130503/1367581629 http://d.hatena.ne.jp/naoya/20130504/1367640512 これに、JavaScript のテスト環境も追加したい。 結論からいくと、フレームワークには mocha + expect、ランナーは testem を使うことにした。ついでにテストダブルライブラリとして Sinon.js も有効にした。 ちなみに今回の文脈は End to End のテストではなくてユニットテスト周りのおはなしです。 mocha + expect JavaScript のこの辺のテスト周りは今もいろいろなツールの整備が進んでいて、今回採用した以外にも Jasmin や QUnit そのほか色んな物がある。昨今の状況に関しては 先日の HTML

    require.js 環境で mocha + expect + testem を使った JavaScript テスト - naoyaのはてなダイアリー
  • 1