読み込んでいます…ログイン
みなさんは普段JavaScriptを使って開発する場合、インデントはどのようにしていますか? タブ、スペース2個、スペース4個・・・などいくつかの選択肢があります。 個人で開発している方は問題ありませんが、チームで開発している場合は意見が分かれ議論になることもあるでしょう。プロジェクト開始早々インデント論争でチーム内の雰囲気を悪くしたくはありません。 本記事はそんなインデント論争の1つの解決策となるべく、ブラウザベンダーやプロダクトで定めているJavaScriptコーディングのインデントルールを調べてみました。 この記事のポイント* 海外のJS界隈ではスペース2個のインデントが多数派 ESLINTなどの設定ファイルからコーディングルールを調べられる なぜインデント論争が起こるのか? そもそもなぜインデント論争が起こってしまうのでしょうか? それはそれぞれ一長一短のため好みが分かれてしまうか
この記事は、アムステルダムで2015年に開かれたFronteersのカンファレンスで私が行った講演、「デバッグの技術」に対応するものです。 要約:利用可能なあらゆるツールの使い方を学び、必要なときにそれを使うことで、バグの撃退を楽しみましょう。そのほうが、キーボードを無暗に叩いて6か月も費やしてしまうより、ずっと楽しいものです。 本題に入る前に… この記事を終わりまでスキップしたければ…… Don’t. Write. Bugs. とはいえ…… おそらくこれを読んでいるあなたはロボットではないでしょうから、1個や2個のバグぐらいは書いてしまったことがあるでしょう。「銀の弾丸」は存在しないのです。 実際、先ほどジョークで申し上げた『バグを書くな』というのは、デバッグの仕方を学ぶことの対極にあるものです。必要なのは経験です。バグに対するアプローチを見つけられるようになるためにはバグに遭遇しなけれ
WP-CLIとWordPress公式ディレクトリを活用した爆速サイト構築術 ーインストールからデザイン、ページ作成までを10分でー
10.How do JavaScript closures work? http://stackoverflow.com/questions/111102/how-do-javascript-closures-work JavaScriptのクロージャーについて 結構とっつきにくい「クロージャー」に苦労されている人も多いかもしれませんが、サンプルコードが多いので英語わからなくても助かります 個人的にはQuestionの「Like the old Albert Einstein said: ... 」というくだりが好きw 9. What does “use strict” do in JavaScript, and what is the reasoning behind it? http://stackoverflow.com/questions/1335851/what-does-use
B! 509 0 0 0 以前、 sparkという シェルスクリプトで棒グラフを表示するコマンドを紹介しましたが、 さらに複雑なグラフや地図などもターミナルに表示してしまおうと言う プロジェクトの紹介。 blessed-contrib termui wopr ブラウザに表示させる blessed-contrib nodeがインストールされている必要がありますが、 nodeが入っているなら取り敢えず $ git clone https://github.com/yaronn/blessed-contrib.git $ cd blessed-contrib $ npm install $ node ./examples/dashboard.js を実行してみてください。 ターミナル上に こんな感じのものが表示されると思います。 追記: 2015/11/30 上のgifはGNU screenを立
html5j-begin.doorkeeper.jp javascriptの勉強が一通り終わったので、参加してきました! javascriptの勉強会に参加するまでの道のりが長かったぜ...(T_T) 話の内容 4名のJSオジサンからのありがたきお話+質問タイムって感じでした。 一つずつ、つらつら書いていきます(※長文注意ですぞ!) 1.ソースレビューから学ぶ Javascript + 1 株式会社サイバーエージェントの、宗定 洋平さんのお話です。 speakerdeck.com ざっくりまとめると、以下の4点についてのお話でした。 レビューでみているポイント 「バグがない」という言葉の定義 関数名のつけ方 ステップアップするために必要なこと 印象的だったのが...ステップアップするために必要なこと...それは... 「情報処理技術者試験を勉強する」です。 な、なんじゃそりゃー!初耳です。
こんにちは、トレンド調査ラボの井上寛之(@inohiro)です。 クックパッドの検索ログを基にした法人向けデータサービス「たべみる」の開発を担当しています。 本稿では、現在開発を行っているスマートフォン向けウェブアプリケーション(Rails)で採用した、 JavaScriptチャートライブラリを選定するにあたって検討した観点について述べます。 また、実際に採用したライブラリと、その利用例を簡単に紹介します。 ウェブ上に無数にあるJavaScriptチャートライブラリから、最適なものを一つ選択するのは なかなか難しい作業ではないかと考えています。おそらく、これから記述する条件を満たすライブラリは数多く存在し、 今回私が選択したライブラリ以上に良いものがあるのではないかと思います。 「何を以って良いライブラリとするか」という議論もまた難しい話題です。 そのようなライブラリについては、はてブコメ
(訳注:2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) 開発者は嫌うでしょう。 ここでは、標準的なコツや策略について書きますが、本当に興味があるのは、別のことです。究極の奇策を見つけたいと思います。策略をひとつずつ試して、プログラミングの聖域に少しでも近づければ良いのですが。 はじめに 私が初めて書いたビデオゲームは、 Ninja Wars (忍者戦争)でした。 そう、これは、画像で埋めたHTMLのtableです。 src 属性を変えることで、動きを実現しています。JavaScriptファイルの冒頭は下記のようになっています。 var x = 314; var y = 8; var prevy= 1; var prevx= 1; var prevsw= 0; var row= 304; var endrow= 142; var sword= 296; v
一見簡単に見えるJavaScriptでのリダイレクト(URL転送)ですが、よく知られた方法にはある落とし穴があり、Googleアナリティクスで正常な解析が行えなくなります。どんな落とし穴があるかと、その回避策について解説します。 なお、こちらの記事は、 SEM Technology - Googleアナリティクスに悪影響を与えずにJavaScriptでリダイレクトする方法 と同じ内容となっています。 はじめに モバイルサイトとPCサイト間のリダイレクトであったり、URL変更に伴うリダイレクトにおいて, .htaccessなどを用いたサーバー側でのリダイレクトが技術上できず、JavaScriptを利用してリダイレクトしているケースをたまに見かけます。 こうしたサイトでは、見た目上は問題なく動作しているものの、実はGoogleアナリティクスなどを用いてアクセス解析を行うと致命的な問題点がみつか
2015年にもなるのにJavaScriptでのDOM操作のパフォーマンスについて書く。ウェブページにインタラクションを持たせたい時に、JavaScriptでDOM操作を行うことがよくある。このDOM操作のパフォーマンスについて、よく聞く意見を大別すると次の2つがある。 JavaScriptによるDOM操作は重たい レンダリングが重いだけで、DOM操作そのものはそれほど重たくない JavaScriptでオブジェクトのプロパティを操作したりする単体の処理は通常1ミリ秒もかからないが、DOM操作をするとレンダリングが完了するまでに数十ミリ秒程度かかったりする場合がある。1番目のDOM操作が重たいと言っている人は経験則的にそう言っていることが多い。 レンダリングの仕組みを知っている人は2番目の意見を言うが、重箱の隅をつつくような話をするとこれも必ずしも正しいわけではない。DOM操作するコードによっ
prototype.js が jQuery に置き換えられた時、開発者が気づいたのは、自分に本当に必要だったのはprototypeのメソッド拡張などではなく、クエリエンジンだったということ。 coffeescriptが当初、熱狂的に支持された背景はなんだっただろう。今思えば、それはアロー記法とクラス構文だったと思う。 javascriptの関数型への憧れ、prototypeベースの限界 javascript は断じて関数型言語ではないが、他の言語と同じぐらい関数型言語に憧れていたのも、また事実だろう。しかしビルトイン関数が高階関数を要求するデザインにしては function というキーワードはながすぎたし、その function が暗黙に作り出す this スコープの複雑な振る舞いも開発者の悩みの種だった。「あらゆる関数スコープで状態を持つことが"できすぎる"」という割れ窓だった。 ES5
多くのWeb制作者はパフォーマンスというと、JavaScriptや画像の最適化、サーバーの設定、CSSなどのファイルの圧縮や結合を検討します。そして、Webページのコアとなる言語にも関わらず、HTMLは無視されがちです。 HTMLは単に複雑さと要素の数を減らすだけでは、パースにかかる時間をあまり改善することはできません。しかしよく作られたHTMLはページを素早くロードするための決定的な土台になり、異なるビューポートサイズに対応するレイアウトになります。 さまざまなデバイスに対して素早くロードし、うまくいくコンテンツを作ることができるクリーンで簡潔なHTMLのコードを紹介します。 High performance HTML 下記は各ポイントを意訳したものです。 著者のSam Dutton氏は、Google ChromeのDeveloper Advocateをされています。 ※当ブログでの翻訳
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く