JavaScript・jQueryの改修・高速化のためのメモ - Qiita
たまにJavaScriptやjQueryなどの改修が入ったりすると忘れてしまうので、自分用のメモとして残しておきます。 JavaScriptコーディングベストプラクティス（高速かつ堅牢なコードを効率よく書くために）を参照しながらのメモになります。 随時、この記事に追記予定です。 高速化メモ JavaScript編 スタイルシートは上に、JavaScriptは下に指定する JavaScriptファイルは読み込んだ後、通常はスクリプトを解析している間、他のファイルの読み込みをブロックする JavaScriptはページの上部に指定すると、このブロックによりロード時間が増加する場合がある スタイルシートはなるべく上に、JavaScriptファイルは下部にしていることで、ロード時間が短縮できる 画面描画に関係ないJavaScriptは、</body>の直前に書く $(document).readyを
忙しい人のためのIntelliJ IDEAショートカット集（´-`） - Qiita
新卒で入社してもうすぐで一年を迎えようとしている大久保です。（´-`） 最近ジョインしたプロジェクトでIntelliJ IDEAを使っているのですが、あまり機能を使いこなせていないなと感じたので、IntelliJ IDEAのショートカット調べました。（´-`） 自分がググったとき、ショートカットキーだけじゃなくて、Gif画像付きで使用例も見れたらうれしいので可能な限り作ってみました。（´-`） 例で使用しているコードの言語はScalaです。 現在使っているのがMacなので記述はMac版のショートカットのみです。 WindowsのIntelliJ IDEA使っている方がいましたらWindowsのショートカットキーについての編集リクエストいただけると嬉しいです。（´-`）.｡oO（他力本願） @data9824 さんにWindows版のショートカットを追加していただきました！ Git機能につい
iOS ヒューマンインターフェースの原則 - Qiita
はじめに iOS のヒューマンインターフェースを理解するためにはまず UI 設計の原則を定めた聖典 iOS Human Interface Guidelines を読むことから始めなければなりません。ここにはプラットフォームの特徴からデザインの原則、それぞれの部品が何のためにデザインされたのか、どう利用するのか、iOS を構成する UI の基本指針がまとまっています。 よく、『磨りガラス効果がかっこいい』『アニメーションしておくとイケてる』『ボタンは右配置の方が右手で押しやすい』『流行っているから』……などの観点によって UI の設計が決められることがありますが、そういうことではないのです。いや実際かっこいいかわいいだとかの感覚は重要なのですが、見た目が何となくそれっぽいだけでは優れた UI とは言えません。磨りガラスでも何でも必ずそこには意味があります。だからこそ HIG に書かれた思想
javascriptで文字コード変換 - Qiita
概要 javascriptの文字列はUTF-16で String#charCodeAt(i) で取得出来る数値は2byte(0x0000から0xffff)になる。 escape("あ") は UTF-16がそのままエスケープされ "%u3042" になるが encodeURI("あ"),encodeURIComponent("あ") などではUTF-8に変換されて "%E3%81%82" になる。 var str = "文字列をUTF-8に"; var utf8str = unescape(encodeURIComponent(str)); var utf16str = decodeURIComponent(escape(utf8str)); if (str == utf16str) {alert(true);} //=> true とすることで UTF-16<=>UTF-8 の変換は出来
Dockerコンテナでprotractorのテストを実行、キャプチャも撮りたい！ - Qiita
はじめに きっかけ ただいまフロント側を担当していますが、酷いコードでe2eテスト担当の方にご迷惑をおかけしています...。 e2eテストは、実行の際にはブラウザの起動（Selenium Webdriverなどなど) が必要になるので、テスト担当の方のローカル環境でテストを実施していただいてるのが現状。Commitの度にテストを自動で実行する...というのができたら、テスト担当の方も作業が楽になるはず^^; ただでさえ酷いコードでご迷惑かけているので、なにかもっと楽に実行して時間を他のことに使えるようにできないかな...と思ったのがきっかけです。 すでに世の中では、e2eテストももちろん自動化はされていると思うのですが、まだその知見がなかったこととe2eテストの知識も浅いため、お手軽に利用できるようになった Dockerを使ってやってみようと思った次第です。 今回やること / やらないこと
Selenium,IEWebDriverでのテストが実行できない場合の対処方法 - Qiita
概要 http://qiita.com/takky/items/9a2c1dc36c1a729c56cb でseleniumIDEで作ったテストケースでchrome、IEでもテスト実行するのを書いたが、 その中でIEの動作がうまくいかないことがあったので、記載する。 以下の設定漏れがの可能性があるので見直す。 保護モード ツール→インターネットオプション→セキュリティタブで保護モードを有効にするにチェックが入っていることを確認する。 レジストリ IE11の場合レジストリの追加がされているか確認する。 プログラムの「ファイルと検索」から regedit.exeを開いて \HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_BFCACHE があるか。 また
今さら聞けないWebAPIの実装方式RESTとSOAPの違い - Qiita
REST API RESTはREpresentational State Transferの略。 RESTの世界では、ネットワーク上のコンテンツ(リソース)を一意なURLで表すのが基本。 各リソース（URL）に対してGET,POST,PUT,DELETEでリクエストを送信しレスポンスをXMLやjsonなどで受け取る形式（レスポンスのフォーマット形式は指定されていない）。 RESTはURLがリソースに対応づけられるためURLは名詞的になることが多い。 SOAP API SOAPはSimpleObject Access Protocolの略。 リクエストおよびレスポンスともにXMLフォーマットのデータで行う形式。 SOAPのURLは操作と対応づけられるため、URLの命名が動詞的になることが多い。 参考： http://programming-10000.hatenadiary.jp/entry
Protractor: AngularJSの次世代E2Eテストフレームワーク - Qiita
AngularJSはテストを重視しているフレームワークだと言われています。 それは、DIが標準搭載されているのでサーバーとの通信などのテストしにくい部分を簡単にモックに差し替えることが出来たり、ユニットテストやEnd to End（E2E）テストのためのフレームワークを持っていたりするからでしょう。 そして、現在標準で含まれているE2Eテストのための機能は、今後ProtractorというSelenium WebDriverJSベースのフレームワークに移行すると発表されています。（AngularJS 1.2 & Beyond） これまでのE2Eテストフレームワークを捨てて新しいものに乗り替えるのには理由があります。 それは、Seleniumをベースにすることで次のような恩恵を受けられるからです。 ブラウザを操作するためのAPIが充実 複数ブラウザでの実行が可能 リモートページのテストが可能
AngularJSのテスト(Unit Test/end-to-end test)って何が良いの？ - Qiita
AngularJSを利用したのなら、絶対にKarmaとか Protractorを活用すべきです。ちゅうか、活用しなさい。と言いたいです。システムを保守フェーズに安定的にメンテナンスするならそう考えるのがふつうになるべき。 （※Protractorについては、こちらの記事がとても参考になります） 例によって「Mastering web application development with AngularJS」を読んで書かれていたポイントを読んだ感想をこちらにまとめてますが、 2章のテスト解説部分に下記の文章があります。 There is a quote saying that writing code without a Version Control system (VCS) is like skydiving without a parachute. Today one would
AngularJSのMVWパターンを理解する - Qiita
12/4の記事（AngularJSを使ったWebアプリのアーキテクチャ設計）で書くと言ったまま放置していたので、AngularJSのMVCパターンについて書いてみたいと思います。 AngularJSのMVCについては、12/19のお前のAngular.jsはもうMVCではない。と言われないためのTutorialというすばらしい記事がありますが、本記事ではもう少し抽象的な内容を扱ってみようかと思います。 MVW（Model-View-Whatever）パターンとは MVCパターンには、MVC2、MVP、MVVMなど数多くの派生パターンがあります。 目的は同じなのに派生パターンがたくさんあるのは、それぞれのプラットフォーム固有の問題（フレームワークの違いや、サーバサイドかクライアントサイドかの違いなど）によってMV*の*の役割が異なるからです。 AngularJSは公式ページで"Superhe
AngularJSでPromiseを返す関数をモック化してテストする - Qiita
Promiseを返す関数をモック化してテストするサンプルです。 Promiseがresolveやrejectされた後の処理はscope.$digest()が呼ばれないと実行されないため、 テストコード内のどこかのタイミングでscope.$digest()を呼んでやる必要があります。 angular.module("myApp", []).controller("hogeController", function ($scope, hogeService) { $scope.hoge = ""; hogeService.deferredHoge().then(function (x) { $scope.hoge = x; }); }); describe("Promise test sample", function () { var $rootScope; var $q; var $con
Jasmine使い方メモ - Qiita
describe('add 関数のテスト', function() { it('1 + 1 は 2', function() { expect(add(1, 1)).toBe(2); }); it('1 + 4 は 5', function() { expect(add(1, 4)).toBe(5); }); it('10 + 2 は 12', function() { expect(add(10, 2)).toBe(5); // わざと失敗させている }); }); <!DOCTYPE html> <html> <head> <meta charset="UTF-8" /> <script src="jasmine.js"></script> <script src="jasmine-html.js"></script> <script src="boot.js"></script> <
Angular2のServer Side Renderingに触れてみる - Qiita
はじめに 今回のエントリでは、 Angular2 とServer Side Rendering(以下SSR)について書きたいと思います。 Angular2でSSRを実現するためのモジュール群は angular-universal で開発されています1。 コーディングレベルでのモジュール利用方法についても記載しますが、APIや利用可能なオプション等の詳細については日々刻々変化が予想されます。 今日時点では、Angular2の開発チームが目指しているゴールと、それを支えているアーキテクチャについて理解しておいた方が今後の変化に柔軟に対応できると考えています。今回のエントリでも、この点を踏まえて書いていくように努めます。 前半でAngular UniversalのDesign Docを交えながらSSRの仕組みに関する話を、後半でExpressと連携させてAngular Universalを動作さ
Node.js + Express 4.x + MongoDB(Mongoose)でRESTfulなjsonAPIサーバの作成を丁寧に解説する．+ テストクライアントを用いたAPIテストまで - Qiita
Node.js + Express 4.x + MongoDB(Mongoose)でRESTfulなjsonAPIサーバの作成を丁寧に解説する．+ テストクライアントを用いたAPIテストまでNode.jsserverMongoDBExpressrest Node.js Advent Calendar その2 http://qiita.com/advent-calendar/2015/nodejs2 Node.js Advent Calendarはこちら! http://qiita.com/advent-calendar/2015/nodejs こちらは1日目の記事です! RESTfulなAPIサーバって良く聞きますよね． 実際の開発でも，クライアントサイド，サーバサイドと作業を分担して行う事が多いと思います． 同様な記事は多々あります． しかしながら，具体的なコードへの言及や実行方法の確認
Solidityによるコントラクトの作成(1) - 基礎 - Qiita
--networkid：networkIDを指定します。1,2,3以外の数字を使いましょう。 --genesis ：genesis blockを指定します。 --datadir ：databaseのあるディレクトリを指定します。 console ：consoleを開くために必要です。 geth command line options コントラクト作成 早速コントラクトを記述してみましょう。言語はSolidityを使います。 (事前にsolidityコンパイラ(solc)がインストールされているか確認してください。されてない場合はこちらの記事に沿ってインストールしてください。) エディタで次のようなコントラクトを記述しましょう。これはEthereum上に独自のコインを作るためのコントラクトです。 contract token { mapping (address => uint) pub
Riot はミニマルで Web Components のような UI ライブラリ - Qiita
古典的な構成のサービスを AWS Lambda + S3 で動作するサーバーレスアーキテクチャで再構築し、そのフロントエンドに Riot を採用しました。 プロジェクトは WWD JAPAN.com として公開しています。 React や Angular などに代表される JavaScript の UI ライブラリのうち、Riot はミニマルな API と HTML 標準に近い文法を採用しているのが特徴です。 Riot はコンポーネントベースの UI 開発から複雑さを取り除き、楽しさを与えます。 TL;DR Riot はこれまでの UI ライブラリと比べて以下の点で異なります。 必要最小限の API 少ないボイラープレート Web Components ( HTML Template ) に似た文法 React のコードと比較してみます。 ToDo アプリケーションを React で書くと
スクロールバーの幅に依存しないスタイル指定 - Qiita
問題 CSSで overflow: scroll; を指定した要素はスクロールバーが表示されます。 ...と、思っていた時期がぼくにもありました。 Yosemite 以降の Mac(OS X 10.10~) では、OS のデフォルト設定でスクロールバーを非表示にしている為、overflow: scroll;を指定してもスクロールバーは表示されません。 その為、スクロールバーが表示される前提でスタイル指定していると表示が崩れてしまいます。 「え？同じブラウザを使っているのに表示崩れが起きるだと！？」 「OSも影響するよー」「▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂」 そもそもスクロールバーの幅はOSやブラウザによって異なるはずで、本来はこれに依存しないスタイル指定をするのが良いはずです。 とはいっても、面倒であったり難しかったりで一般的なスクロールバーの幅(15pxぐらい)を width の計
jQueryの基本 - $(document).ready - Qiita
これは画像などを除いて、HTML=DOMの読み込みが終わったらfunction()の中の処理(=なにかしらの処理)を実行するという意味です。 jQuery(JavaScript)はHTMLが完全に読み込まれないまま何か処理を実行すると大抵正しく動作しません。なのでこのreadyを使うことになります。 $(function(){ //なにかしらの処理 }); jQuery(document).ready(function() { //なにかしらの処理 }); jQuery(function(){ //なにかしらの処理 });
Reactを使うとなぜjQueryが要らなくなるのか - Qiita
はじめに React（通称 React.js1）を全く知らない、あるいは幾つか記事を見たけどなんなのかピンと来ていない、という人のために書いています。 「jQuery くらいしか知らない」くらいの人に具体的に雰囲気を知ってもらうのが目的であり、すでにやる気がある人向けのチュートリアルではありません。やる気が出れば日本語版ドキュメントを読んで手を動かせばあっという間なので、そこまでの興味が出ることを目標にしています。 以降では ES2015 (ES6) の文法（アロー関数とか）を使っています。この部分が怪しい人は先にアロー関数と const 文だけでも知ってから先に進んでください。 以下の説明中、このアイコンで表すのは（2023 年現在から見た）『昔話』です。新しく自分のコードを書く際には本来知らなくていいことですが、古い記事を見たときに混同しないための参考情報として書いてあります。この記事
リダイレクト時に利用すべきHTTPステータスコード - Qiita
※「許可」は実質、ほとんどのブラウザでGETに変更される模様です。 具体例 掲示板への投稿が終わって遷移させるときは… 303 See Other を使いましょう。過去には 302 Moved Temporarily (302 Found の以前の名称) が使われていましたが、現在では迷わずこれ1択です。 メンテナンス中にお知らせページに飛ばしたいときは… 302 Found または 307 Temporary Redirect を使いましょう。「POSTのままお知らせページに飛ばす」ようにしても特に意味が無さそうなので、302 Found のほうがナチュラルと言えるかもしれません。 【追記】 もしURLを変更せずにそのページで即503 Service Unavailableで返せるような設計になっていれば、そうしたほうが良いでしょう。 サイトを移転したときは… 301 Moved Per
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
