Simple, powerful, free tools to create and use millions of apps.

本稿は、JavaScriptのテストについて最も重要な根拠、用語、ツール、アプローチなどの知識を身に着けることを目的とした簡略版ガイドブックです。本稿で検討する数々の側面に関する最新の秀逸な記事も紹介しつつ、私たちが経験的に得たことも多少付け加えたいと思います。 Facebookによるテスト用フレームワークであるJestのロゴをご覧ください。 見てお分かりのように、このフレームワークは「苦痛のない」JavaScriptのテストをスローガンに掲げています。しかし、 “次のように言う人” もいます。 苦痛のないテストなんてあり得ない。 実際、Facebookはこのスローガンを掲げるだけの素晴らしい理由があります。一般的にJSのデベロッパは Webサイトのテストにあまり満足していません 。JSのテストには制限があり、実装が難しく、低速である傾向があります。 一方、正しい戦略を立てて適切にツールを
はじめに こんにちは、普段はPawooの開発を担当している新卒エンジニアのabcangです。 最近話題のHeadless Chromeを使って魚拓を作ってみましたので、その話をします。 結論から言うと、こういうものができました。 以下、詳しくお話していきます。 日々行われるデザイン変更をどう把握するか pixivには毎日新機能やUIの変更がデプロイされており、どんどんページが変わっていきます。 ある日、ディレクターから「デザインの変更履歴を追うための魚拓ツールがほしい」と相談されました。魚拓ツールがあると、なにか数値の変動があったときにデザインの崩れを確認したり、過去のデザインを振り返ったりするときに便利とのことです。 ちょうどそのタイミングでHeadless Chromeが利用できるGoogle Chrome 59がリリースされていたので、試すいい機会だと思い引き受けました。 Headl
追記 11/12/25 Bi ってそんなに一般的ではない、 Both-Sides JavaScript の方が、ということでまた変更しました。(side でなく side's') 11/12/04 Both Side JavaScript は変ということで、 BSJS=Bi-Side JavaScript に変更しました。 本文 CSJS と SSJS で両方同じ言語で処理が書けるメリットの 1 つとして、 書いた処理の共有があげられます。 (そこにメリットを感じない人もいるかも知れませんが。) 例えば Validater を共有 クライアントの状態をサーバで再現 などがあります。前者はそのままですね。 受け取った入力のバリデーションはサーバでは必須で、フィードバックを速くするためにクライアントでも同じように行う場合があります。 今まではサーバで書いたバリデーションと同等のものを JS に
Node.js+Socket.IO+MongoDB こんにちは! 著者は、マインドフリーという会社でNode.jsを使ってWebアプリなどを作成している。この連載では、最新Webテクノロジを使った研究開発の事例や実績を発信する弊社のサイト“Tech Release”のリニューアルで培ったNode.jsに関する知識を分かりやすくお伝えする。 Tech Releaseは一見、普通のブログに見えるが、実は記事の更新内容がリアルタイムにView画面に反映されている。管理者が、記事の文章(データ)に変更を加えると、その記事を見ている人にもページをリロードせずに、リアルタイムに文章(データ)が変化していく。 このUXを実現するために開発したシステムが、REALTIME BLOG ENGINE「REABLO」というエンジンだ。「REABLO」はNode.jsとSocket.IO、MongoDBを使用して
# Install Meteor npx meteor # Create a new Meteor + React App meteor create happy-chat --react # Navigate to your new project cd happy-chat # Start the development server meteor npm start import { Mongo } from 'meteor/mongo'; import { has, ID } from 'meteor/jam:easy-schema'; export const ALLOWED_EMOJIS = ['😊', '❤️', '😃', '⭐', '🎉']; const errorMessage = `Only emojis ${ALLOWED_EMOJIS.join(', ')}
まえがき JavaScript、書いてますか? JavaScriptは今や世界中の人々に愛されています。 stackoverflowの2016年の調査によるとJavaScriptは地球上で最も一般的に使用されているプログラミング言語だそうです。 JavaScript is the most commonly used programming language on earth. Even Back-End developers are more likely to use it than any other language. link しかしJavaScriptは愛されすぎているが故、しばしば黒魔術のようだと比喩されることも少なくありません。 愛と憎しみが紙一重とはこのことですね。 ということでそんなこんなはどうでもいいのですが、自分もJavaScriptは大好きです。 今回は黒魔術まと
Nodeネタも幾つか書いてきたのだけど、最近、真剣に express のフレームワークをマスターしておくべきだと感じたので、「expressやるなら connect.js 読んでおけ!」 といわれてる事もあって、connect読んでます。 これまでは、オレオレフレームワークとか言いながら、Nodeの基本にのみ従って書いてきたサーバー(FreeStyle Wiki のフレームワークを移植してたのが実際だけど)。 最近では、「レスポンスヘッダに Etag を使いたいよな」とか、色々と考えるところがあって、自分しか知らないオレオレフレームワークよりも nodeの開発元 joynet が公開する express を使う方向に軌道修正すべきと感じた次第。 ここで、「connect.js 読んでおけ!と言われる理由」をば。 sencha labs が開発した Node JSでサーバーを書く時の接続周り
背景 Javascript で Web アプリを作ろうとすると、よくわからないことだらけで超混乱します。 npm と bower の違いは? npm はサーバーサイド用、bower はクライアントサイド用らしいよ えっ、でもなんで bower のインストールに npm が必要なの? サーバーサイドは Rails で書きたいから npm 要らないと思うんだけど・・・ ていうかサーバーサイドJSとか node.js って何? よく見る browserify って何? こういった疑問が沸き上がるのは、各ツールが生まれた文脈がよくわかっていないからです。いろいろ調べてやっとちょっとわかってきたのでメモします。間違いがあったらご指摘ください。 「CommonJS」誕生 - Javascript は汎用プログラミング言語へ その昔、Javascript 大好きおじさんは言いました。 Javascrip
注意とお願い この記事の内容はもはや古いです。ここに書いている方法では動かないものをいくつか見つけました。参考にする際は動作をよく確認してから使ってください。 ひとつお願いがあります。「あれ、動かないぞ」というコードを見つけたら是非コメントか編集リクエストで教えてください。解決方法までなくても結構です。「これはもう動かないよ」という印をつけたいのです。 この記事はYou Don't Need jQueryの日本語訳と同じ内容です。 先日ひょんなことからYou Don't Need jQueryの日本語訳をさせていただきました。著者のCam Songさんからも快諾をいただけたので1、Qiitaでも公開させていただきます。 なお、本家の英語の説明は継続的にメンテされているので、この記事の情報は古くなっている可能性があります。 追記 この記事は当初は「もうjQueryは必要ない」というタイトルで
Backbone.jsで書き始めたら「Backboneどう?」と聞かれることがあったので、自分ではあんま語れるほど知らないけど「ここらへんの記事は素晴らしいよ!」というものをまとめておいたヽ(・ω・´)ゝ まずは読んでおくべきもの Backbone.js Advent Calendar 2011 なにはともあれまずはBackbone.js Advent Calendar 2011 ある程度まで書けるようになる情報は総ざらいで書いてあると思う。 中でもBackbone.js入門はありがたい。読んでおけば基本の仕組みを知ることが出来る。 Backbone.jsが依存しているunderscore.jsの情報なんかもあったりしてありがたい。 ちなみに今年(2012)のAdvent Calendarはこちら。今はまだ始まったばかりだから情報少ないけどこれから充実してくるだろうし楽しみ(´ω`) Ba
以前、オセロの対戦AIの作成しましたが、そこでは実装を簡略化する為に盤面の価値を 盤面の価値 = 自分の石の数 – 相手の石の数 という単純な方法で決めていました。 でも、これには問題があります。 同じ石でも配置場所によって価値は異なるはずです(例: 角は最強)。それが考慮されていません。ゲーム終盤になってくると石の数が重要になってきます。でも序盤から石の数を重視するのは方向性としておかしいです。 という訳で、 序盤から中盤では石の配置場所を重視する終盤では石の数を重視する 形で盤面の価値を算出すれば、結構良さそうなAIになりそうです。 しかし、今度は 「序盤」「中盤」「終盤」をどのように区別するのか?石の配置場所の強弱はどう決めるのか?同じ配置場所でも周囲の状況次第で強弱が異なるのでは? という問題が出てきます。これは作るのが面倒臭そうです。 どうにかしてお手軽かつそこそこ強そうなAIを
JavaScriptチュートリアルBeginner's tutorialsYour first website: Adding interactivityDynamic scripting with JavaScriptJavaScript frameworks and librariesJavaScript ガイド入門編文法とデータ型制御フローとエラー処理ループとイテレーター関数式と演算子Numbers and stringsRepresenting dates & times正規表現インデックス付きコレクションキー付きコレクションオブジェクトを利用するクラスの使用プロミスの使用JavaScript 型付き配列イテレーターとジェネレーターInternationalizationJavaScript モジュール中級編Advanced JavaScript objectsAsynchrono
がまだ私には難しすぎる気がするよ…… Elm - functional web programming (http://elm-lang.org/) ElmというFRPやろう (http://qiita.com/jooex/items/89ab4bf7c953a6f40069) elmはHaskellに似た構文を持つ関数型言語のAltJS。コンパイルするとJavaScriptが生成されるのでブラウザ上で動くゲームも作れる。なのでごく簡単なミニゲームをelmで作ってみた。 Sine Jump (http://abagames.sakura.ne.jp/elm/sj/) ゲームライブラリ相当の部分を除くと250行強というところなので、コードの分量的にはCoffeeScriptで書くのと似たようなものかちょい長めというところかなあ。でもコードを書く際には関数型言語ならではのかなり違う発想が求めら
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く