Ember Data は、Beta なこともあり、まだあまり情報がないので整理しておきます。Guides にもあまり書かれていないので、Discussion Forum や Stackoverflow を参考にしました。 ActiveModelAdapter RESTAdapter という一見デフォルト風の Adapter がありますが、Rails の snakecase な変数名から JavaScript な camelcase に変換してくれる ActiveModelAdapter が使いやすいと思います。 Rails 側では Active Model Serializer を使って JSON を出力します。 Rails の routing 衝撃的なことに、AcriveModelAdapter は（RESTAdapter も）ネストした URL に対応していません。Adapter に手

ie以外でもクリップボードが使えるsetClipboard.js IE以外のブラウザでもクリップボードにコピーが簡単にできるjavascriptライブラリを作成しました。 IEにはclipboardData.setDataという関数があり、クリップボードへのコピーなどが簡単にできますが、IE以外のブラウザはクリップボードにアクセスする機能がありません。 そこでflashプレーヤ―のsetClipboard関数を利用してクリップボードにコピーするライブラリです。 まずは関連ファイルをダウンロードします。 ダウンロード(setClipboard.zip) 解凍してできる『setClipboard.js』と『setClipboard.swf』は同じディレクトリにアップしてください。 header要素などでsetClipboard.jsを読み込みます。 <script type="text/jav

Help us understand the problem. What is going on with this article?

$(function(){ /* ごにょごにょ */ ContactManager.Contact = Backbone.Model.extend({ }); // 追加 ContactManager.ContactCollection = Backbone.Collection.extend({ model: ContactManager.Contact }); ContactManager.ContactView = Marionette.ItemView.extend({ template: '#contact-template' }); ContactManager.onStart = function(){ var alice = new ContactManager.Contact({ fisrtName: 'Alice', lastName: 'Arten', phoneNu

掲題の本を手に入れてからしばらく放置していましたが、Backboneの冗長な書き方に嫌気がさしていたので(書き方悪いだけ)、Tutorial形式でMarionette.jsを勉強できる良い機会だったので試してみました。 今回から何回かに分けて書いていきます。 環境 Mac OSX v10.9.5 Backbone.Marionette.js v2.2.0 Bootstrap v3.1.1(本はおそらくv2.3.2) フォルダ構成 . ├── assets │   ├── css │   │   └── bootstrap.min.css │   ├── fonts │   │   ├── glyphicons-halflings-regular.eot │   │   ├── glyphicons-halflings-regular.svg │   │   ├── glyphicons-h

I've never used Ember Components before, so I wanted to try making something similar to my React Highcharts component in Ember. I wasn't quite a fan of the existing docs Mistake I made here: instead of using the global $, this.$ needs to be used to specifically get the component jquery object. Conclusion Using the Ember.Component event cycle, I can manage the overall Highcharts instance fairly eas

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

今日は、他のJavaScript MVCフレームワークに対するEmber.jsの優位点を 説明します。 まず、なぜJavaScript MVCフレームワークが必要なのか、jQueryでは 不足なのかという点について説明します。 jQueryについては、ここをご覧になっているほとんどの人が ご存知だと思います。jQueryは、DOMイベントと処理のバインディング、 要素への値のセットを簡潔に書けるシンタックスシュガーとして 扱うことができますが、jQueryだけを用いて処理を記述すると、 どこに何の処理が書いてあるのかわかりにくい、整理されていない コードを書いてしまいがちです。 心当たりのある方も多いのではないでしょうか。 これは、プログラムが構造を持っていないのが原因です。 プログラムの構造とは、処理の種類ごとにコードをまとめることを 指します。 jQueryは便利な簡潔記法を提供します

この資料では、JavaScript でオブジェクト指向プログラミングを行う際に備えておくことが望ましい、基礎知識や概念について解説します。 【対象者】 ・JavaScript でアプリケーションを構築できる方 ・JavaScript におけるオブジェクト指向プログラミングの 実現手法や原理への理解を深めたい方 ・Java 的なクラスベースの言語との違いに違和感や混乱を 感じてらっしゃる方

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

公式サイト: Backbone.js公式リファレンス: Backbone.jsWikipedia: Backbone.js - Wikipedia

Ember.jsに関する情報が集まっています。現在68件の記事があります。また54人のユーザーがEmber.jsタグをフォローしています。

ブラウザやスマートフォンのWebView上で動作するJavaScriptについてのアドベントカレンダーです。 クライアント側で動くJavaScriptの事であれば、AltJSやJSライブラリ、将来のバージョンについての話題、スマートフォンのWebViewについての話題などでもokです

Backbone.jsのTIPSとかパターンとか、他のライブラリとの連携などなど。 フルスタック感がない分、各自でいろいろ編み出しながら使いこなしていると思うので、そのあたりの共有がてら書きましょう！

1. 大規模 JavaScript その設計と実装と現実 株式会社Aiming ソフトウェアエンジニア 竹馬光太郎 2012/10/24@AimingStudy#6 12年10月24日水曜日 2. @mizchi / Koutaro Chikuba 2012/3/1- Aiming/Software Engineer * github https://github.com/mizchi * blog http://d.hatena.ne.jp/mizchi 12年10月24日水曜日

JavaScript界のハリーポッターこと「Browserify」が最近元気ですね。Node.js的な var myModule = require('myModule')式の記述が、ブラウザのスクリプトでも使えるようになって、ついでに1ファイルにまとめるのもやってくれるツールです。ポストRequireJSとして期待されています。 ただ、公式ドキュメントがコマンドラインの説明に重点を置いていて、最初これだけだといまいち分かりにくい...。そこで、実際の開発で使いやすいように、ビルドツール(gulp.js)から実行するための最小構成を作ってみようかと思います。(Gruntでも同様のことは可能です) require!: Bowerも使えます 対象のスクリプトの中身は、例えばこんな感じ。この例では、ModernizrとjQueryと、独自スクリプトを組み込んでいます。外部ファイルを指定するだけで

マニュアルから概要のみ抜粋。 レジスタの種類 無名レジスタ "" 10個の番号付きレジスタ "0 から "9 小削除用レジスタ "- 26個の名前付きレジスタ "a から "z または "A から "Z 4個の読み取り専用レジスタ ": と ". と "% と "# expression 用レジスタ "= 選択領域用レジスタ "* と "+ と "~ 消去専用レジスタ "_ 最終検索パターン用レジスタ "/ 1. 無名レジスタ 最後に使用されたレジスタの内容を格納。 削除・ヤンクなどされるたびに書き換えらる。 "というレジスタ名で指定可能 _を指定した削除_ddの場合はどのレジスタにも入らない 2.10個の番号付きレジスタ "0 から "9 レジスタ名 意味

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Shougo: 地獄のビムサワ Shougo: 「へー Vimってエディタだったんだー。いや俺Vimから出ないから知らなかったわー」 Shougo: というネタを今日思いつきました。 Shougo: 「あれ俺一人でVim プラグイン書いちゃった？ いやVim scripterじゃねーから　無意識だったわー。完全に無意識だったわー」 Shougo: 「前までは全然Vimなくても平気だったのになー。前に戻りたいっす。自分前に戻りたいっすわー」 ujihisa: 「ねぇ聞いてくださいよォー。昨日Vim script2時間しか書いてなくてさァー」 Shougo: 「Vimが動かなくなっても動じない。それが俺の流儀だ」 ujihisa: 「(vimrcみて) 短いねー」 ujihisa: Emacsに魅せられたか・・・ Shougo: 「素のVimつれーわー　まじ素のVimつれーわー」 ujihis

OpenAIのWhisper文字起こし25MB制限を解決するPHP, Laravel, ffmpegを使ったファイル分割の例 OpenAIのAPIを使った音声の文字起こしは、今や多くのアプリケーションで利用されています。この記事では、特にWhisper文字起こしの25MB制限に焦点を当て、PHP, Laravel, ffmpeg…

CoffeeScriptの関数は明示的にreturnするべき 「CoffeeScriptの関数は明示的にreturnしてはいけない理由」を探す暇あったら他にやるべきことあるのでは? という両者相反する内容の記事がございました。両論もっともな内容であり、また実行速度だけではなく思想も絡んでしまう非常に煩わしい問題であります。 はじめに筆者の立場を明確にしておきます。筆者は日本国内で働くウェブアプリケーション開発者です。主にウェブアプリケーションフレームワークとしてRuby on Railsを使用しており、それによりCoffeeScriptも日常的に使用し、そして記述しております。 筆者にとってのJavaScriptという言語は、プログラミングというものを深く学ばんと思わせる契機となった言語であり、深い愛着ととともにわずかながらも執着のようなものを抱いております。そのためJavaScriptを

綺麗なコードと汚いコード。どちらのプログラマと一緒に働きたい？～可読性を意識したプログラム言語はRuby, CoffeeScript, Elixir #Ruby #CoffeeScript #Elixir 2014.02.04 Category：技術コラム Tag：CoffeeScript ,Elixir ,Ruby CodeIQの出題者である@tbpgrさんからの寄稿記事です！どうして汚いコードができてしまうのか、どうやったら綺麗なコードが書けるのかをわかりやすくポイントで解説しています。 また、綺麗なコードを書くには、言語の特性も関係するということで、可読性を意識したプログラム言語として、Ruby、CoffeeScript、Elixirを挙げています。 これであなたのコードも綺麗になる！？ by CodeIQ運営事務局 プログラムの可読性について CodeIQでRubyやCoffeeS

前編はこちらです 4：テストに伴うコスト 2014年5月27日 audio 今回のテーマは、テストとTDDのマイナス面です。 テストをやりすぎることがあるか、そして機能的なコードよりテストを重視するチームには問題があるかという点について議論しました。 議事録 Davidが会話の口火を切りました。 「トレードオフについて話すなら、当然そのマイナス面について理解しなければならない。なぜなら、欠点のないトレードオフは存在しないからだ」 このあと彼は続けて、TDDは開発者に何かを強制するわけではないが、ある一定の方向に導くことは確かだと言いました。 それから、最初の問題点として、テストの過剰な実施を取り上げました。 TDDでよく言われるのは、テストに失敗せずして1行のコードも書くべきでないということです。 Davidも当初はこの考え方を合理的だと思っていましたが、そのうち、テストをやり過ぎる傾向が

この記事面白かったです！ 「出来る」と「実装する」の間には多くの解決すべき問題が含まれているから気をつけろよっていう警鐘を鳴らしている記事なのに、「出来るからやるって単純バカなんだけど」っていう反応が多いのが印象的でした。その理由の９割は、タイトルに「エンジニアはネ申」って書いたせいだと思うけど。 私からは、社内業務システム内製を通じて感じました、創造主であるところのエンジニアとハッピーに仕事をするためにはこういうことを一緒に考えよう、っていう話をしたいと思います。 実装可能と実現可能は別問題 前述の記事も僕の補足も、主題はこれだけ。だいたいそんな感じ。でも、順を追って説明します。 技術的に実装可能なのか否かは、当然一番最初に考える問題です。そこでNoならこの話は終わります。技術的と簡単にまとめますが、エンジニアによって判断基準は全然違うから悩ましいです。そこは差し引いて、単純に求められた

たまにはブログ更新したいから、ついさっき流れてきたエントリに食いついちゃうよー。 ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change! 工程の分断はあり得ません ソフトウエアの設計に実装経験が要るか要らないかというのはそもそも議論にならない。「ソフトウエアの設計＝仕様の設計+コードの設計」なんだから、例えればコインの表と裏。それらは引き離すことは出来ないのに引き離して分業しようとするからよろしくないことが起きてしまうというのが、上記記事の主題かと思います。簡単に言えば。 僕もこの点については「工程の分断」という言葉で何度も書いています。コインの表と裏であるべきものを分断してしまうと、互いのフィードバックを得る術を無くしてしまいます。そうなったら良いことは無い。ここは誰でも納得がいく所でしょう。 仕様を設計するチャンスって超少ないんじゃない？