angularJS でSPA開発する際のアーキテクチャについて - Qiita
これに従う必要は無いがこうしておくと後々やりやすいよってやつ クライアントサイドとは言え、大規模で保守性の高いアプリを作るなら、アプリケーションは次の5つのレイヤに分けておいた方がいい。 View 層 View は、ユーザーとのやりとりを行う。 金額のデータに ¥ や , を付加したり、リストの表示、メニューの出し入れなどのいわゆる「プレゼンテーションロジック」もこのレイヤが担当する Controller 層 Controller は、View と後述の Service をつなぐ部分。ここにはデータのバインドとページ遷移の簡単な if 文を除き、ほとんど何も記述されない。 ほとんど何も記述しない。 ほとんど何も記述しない。 ただただ View と Service のパイプ役に徹するべきである。 ほとんど何も記述してはいけない。 30行超えたら危険信号、50 行を超えるようなら設計がおかしい
フラクタルで木を書く - Qiita
そういえば書いたことなかったのでやってみた。 概念 何度再帰するか決める(depth) 座標を指定する(x1, y1) 方向を指定する(θ) x1, y1から、その方向に線を引く(x2, y2) 再帰回数が残っていれば、引いた先(x2, y2) から、任意の角rとして θ-r, θ+r方向へ線を引く コード 注意: 伸ばす長さ、角度に乱数が入っている {sin, cos, PI} = Math drawLine = (ctx, p1, p2) -> ctx.beginPath(); ctx.strokeStyle = 'gray' ctx.moveTo(p1.x, p1.y); ctx.lineTo(p2.x, p2.y); ctx.stroke(); drawTree = ( ctx # canvas context x1, y1 # position len # length of n
js->coffee移行にあたって考えたこと - Qiita
個人製作のシステムのjsをcoffeeに完全移行したのでその雑感を書きます。あくまでも個人的な感想です。感じ方は人それぞれです。 ちなみに僕は勉強を兼ねて手で移行させましたが、js2coffeeというツールを使うと自動で変換してくれるらしいです。 先に結論 coffeeの方がいいと思う。 よくある批判に「js書けばいいじゃん」というのがあるけど、極端な話、「アセンブラ書けばいいじゃん」と高級言語が出てきた頃に言ってた人と主張の方向性は似てると思う。極端すぎるけど。 jsには落とし穴がいっぱいある。慣れてもたまにはまる。varを忘れたり「関数の頭で全部のvarを列挙する」というプラクティスに従ってたら、冗長になって管理するコスト高くなったり。 coffeeを使うとそういう余計な問題を意識しなくてよくなるのはとても大きい。 しかもjsでできることの全てをcoffeeでできる。工夫が必要になる場
爆速でHTMLコーディングするためのtips - Qiita
心構え ・HTMLは最小限にする ・JSも最小限。不要なら ・デザインとか全部決まってから手を付ける。 開発環境 ・リアルタイム入力補完ができるエディタ （プログラマならEcripseとかEmeditorとか、MacならCodaか） ・動作確認の InternetExplorer ＞Macで動いてWindowsでレイアウト崩れた！Windowsが悪い！ ←なに言ってんだ・・・？？ ・おまけでDreamwaver。 下準備 ・予め画像を切り出しておく。 HTMLコーディング開始 ・画像切り出しは全部後回しにして、 ZencodingでHTMLを「一気に」組む。 HTML”だけ”組む。 IDやclass名もここでつけちゃう。 ブラウザで開くとめちゃくちゃだけど気にしない。 文字も入力しない。 画像やCSSパスを設定する。 ・作ったHTMLをDreamwaverにコピペして、 Dreamwave
mocha+testling-ciでブラウザテストを自動化する - Qiita
{ "testling": { "browsers": { "ie": [ 6, 7, 8, 9, 10 ], "ff": [ 12, 13, 14, 15, 16, 17 ], "chrome": [ 20, 21, 22, 23 ], "opera": [ 10, 11, 12 ], "safari": [ 5.1 ] }, "harness" : "mocha", "files": "test/*.coffee" }, "devDependencies": { "chai": "*", "mocha": "*", "coffee-script": "*" } } githubのプロジェクトページでwebhookを設定 プロジェクトページ > settingボタンをクリック > サイドバーからservice hooks > WebHook URLに http://git.testlin
Backboneでデータバインディングを使ってMVVMをするフロントエンドアーキテクチャ - Qiita
前提 会社(Quipper)で今からこういう風にしたい、と宣言した社内ドキュメントを公開する。 枯れてるわけではない。 coffeescript Backbone Backbone.stickit (データバインディング) Chapling.js(は、オマケなのでどうでもいいがサンプルコードはこう) backbone.stickitは安心と信頼のNYT製。(実質Backbone作ってるDocumentCloudと一緒のところ?) backbone.stickit 目的 データバインディングを全面的に使って再描画を最小限にし、コードの見通しをよくしたい。 モデルの役割を明示的にし、MVVMを導入する。 理想的なAPI 擬似コード # ビューモデルの定義 class TopicViewModel extends Model defaults: title: '' # たぶんここでパラメータ名(
CoffeeScript 1.7.0 でメソッドチェーンがしやすくなった - Qiita
これまで CoffeeScript で jQuery などのメソッドチェーンを使う際、引数を括弧で囲まざるをえず「これじゃあ JS 書いてるのと変わらないじゃないか！」と思っていたみなさん、こんにちは。 CoffeeScript 1.7.0 から、括弧なしでチェーンできるようになりました。 $ = require 'jquery' $ '.hello' .data 'foo', 'bar' .css color: '#999' fontWeight: 'bold' .on 'click', -> doSomething() .on 'mouseover', -> doOtherThing() .show()
CoffeeScriptが1.9でgenerator構文をサポート - Qiita
追記: タイトル変更。v1.9 でリリースされました(2015/01/30) ES6以降にやや慎重な対応をみせるcoffeescriptですが、やっとgenerator構文がサポートされたようです。 Add yield support · Issue #3073 · jashkenas/coffeescript · GitHub 色々と構文の候補がありましたが、関数ブロックの中にyieldキーワードが存在する場合は自動的にジェネレーター関数になるような仕様に落ち着いたみたいです。 generator概要(知ってる人は読み飛ばしてよい) 関数ブロックの中でyieldを使うと関数がgenerator化されます。yield化された関数は実行されるとgeneratorを返し、 generatorは.next()を叩くと次のyieldキーワードで渡された値が取得できます。もう一度叩くとその位置から次
React + (Javascript || CoffeeScript) + Bower スタータキット @masuidrive - Qiita
React + (Javascript || CoffeeScript) + Bower スタータキット @masuidriveJavaScriptVagrantgulpReact 最近、React.jsにハマっています。いままでとパラダイムが結構ちがうのですが、とても面白い感じです。React.jsがどんな物についてはかは、下記の記事にまとめて見ました。興味のある方はまずこれに目を通してみてください。 Ajaxを劇的に簡単にするReact.js – @masuidrive blog Reactを簡単に始めるには、jsfiddleのReactサンプルや公式スタータキットを使う方法があります。 両方ともブラウザだけで実行でき手軽なのですが、ソースファイルを分割しrequireで読み込んだり、ライブラリを使ったり、SaSSを使うようなコンパイルが必要なモノには対応する事ができません。 実際にR
TypeScript & CoffeeScript & Browserifyによるフロントエンド開発環境 - Qiita
この記事の内容は古くなりました、新しい記事はこちらです。 Browserifyの記事が増えてきましたが、 自分でもフロントエンド開発環境を構築してみて、納得のいく構築が出来ましたので公開します。 GitHubへのリンク 2015/03/26追記 独自タグによるalias指定をoptionalに変更し、 require時に相対パス指定か、aliasがある時はalias指定のどちらも使えるように修正しました。 概要 このプロジェクトは、以下の機能を持っています。 TypeScript、Browserifyの差分ビルド gulp.watch、Watchifyの変更監視による自動ビルド TypeScript、CoffeeScriptのソースファイルを混在出来る ファイルごとに型が欲しいか、短く書きたいか、で好きな方を選べばいい CoffeeScriptで書いたクラスをTypeScriptでrequ
【mkdirからデプロイまで3分】Sinatra+Haml+Sass+Coffee でサクッとHerokuに公開して捨てるwebアプリ - Qiita
【mkdirからデプロイまで3分】Sinatra+Haml+Sass+Coffee でサクッとHerokuに公開して捨てるwebアプリRubyCoffeeScriptSinatraSassGem あいさつ Rubyでゴニョゴニョして、Haml+Sass+Coffeeでサクッとviews作って Herokuにサクッとpushして公開して吐いて捨てるようなアプリの作り方です. チャチャッと動いたモノを見せたい時とかに便利 3分というのはビジネスロジックの構築を除くプロジェクトのひな形作ってデプロイに至るまでの時間. 適当なひな形を持ってきた方が早いかもしれませんが、一回は手を動かさないとなんか気持ち悪い人向け. 今回使ったのはここに置いときました、jqueryとか定番ライブラリ入れとくと便利そう 以下説明 手順1: フォルダを作ってgemを揃える 今回はyour_appというアプリを作る事とし
CoffeeScriptを使う理由 - Qiita
function Person() { this.name = "takashi"; this.age = 20; }; Person.prototype.echo = function () { return "Hello " + this.name + " !!"; }; コンストラクタ、メソッドを書いただけで、コード量が増えてきましたね。 毎回クラス名とprototypeと書く必要があります。 めげてきましたか？ 私はめげてます。 次は継承してみましょう。 function inherits(ctor, superCtor) { ctor.super = superCtor; ctor.prototype = Object.create(superCtor.prototype, { constructor: { value: ctor, enumerable: false, writ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://qiita.com/mmyoji/items/ce7fef70c0c91aca793b