SHOW AN ELEMENT ON SCROLL USING JQUERY:

Difficulty: Easy (though it is suggested you understand basic CSS and HTML)

Unfortunately, I am lazy and can’t be bothered to find which application on my computer records screens and then gif it, so please refer to this example. I recently used this technique in my Underwater theme, and was pleasantly surprised to find that it wasn’t as complicated as I thought it to be…

Read More

alamantusgamedev said:

What's your favorite JS engine and why? What do you think is the "best" to use (if it's not your favorite) and why? I'm starting to get my toes wet in JS game development at the moment (building a board game with vanilla JS and canvases), and since you're the one person I know who does JS games, you seemed like the perfect person to ask. :)

Hoo boy. In the words of another guy named Neil, that’s kind of a big question.

To start, here’s a listing of a bunch of HTML5 game engines: html5gameengine.com. Disclaimers: I didn’t write this, it’s probably not a complete list, etc.

Here’s a quick rundown of the engines I’ve used:

  • Akihabara - not a bad engine, introduced me to some cool things like translating ASCII art strings into level maps. It looks like development and support has disappeared, though.
  • Quintus - a very simple engine, but by its own admission is in a very early stage of development. There may be bugs, and you’ll probably have to do a lot of custom coding yourself.
  • MelonJS - I didn’t spend much time with MelonJS because I didn’t care for some of its conventions (and I was using Akihabara at the time). Looks like it’s still being developed, though.
  • CanvasQuery and rezoner's Games From Scratch method - not a complete engine, but definitely a way to build your own. This is getting closer to bare-bones vanilla javascript, but can be pretty fun. I had some trouble getting CanvasQuery to work as well as Rezoner does, but I’m sure I could’ve figured it out if I’d decided to stick with it.
  • Atom - similarly, not a full engine, just a framework. It puts a canvas on the screen and handles gameloop and input and not much else. If absolutely nothing else, it’s a good starting point for your own framework/engine/game-from-scratch development.
  • Phaser - okay, I haven’t used this one, but it looks pretty good. Active development, growing community, etc. If I weren’t using Impact, this would probably be my engine of choice.
  • Impact - my current engine of choice. Big feature set, robust documentation, communicative development community, tons of plugins and tutorials and videos, a cool level editor, and a tool for setting up your HTML5 game as a native mobile app. If you have $99 for the license, this is my recommendation. Note: it sometimes goes on sale, and I think there’s also student pricing available. Contact Dominic, the developer, and ask.

When it comes to writing “vanilla JS,” I like to look at peoples’ entries to JS competitions and game jams and see how they did it. Some cool examples:

If you’re going the “barebones” route, this post of mine might help.

I’ve got more advice and tools on my blog, tagged with advice and tool

I’m probably leaving stuff out, so if anyone has any more questions, feel free to ask.

JavaScript: タスクランナー Gulp を使ってみる
最近の Web 開発ではタスクランナーを使って色々な処理を自動化するのが主流になってるぽい。 有名なものに Grunt があるけど、最近は Gulp ってのも注目され始めているようだ。

まずは NPM で Gulp をグローバルとローカル両方にインストールする。 尚 Node.js や NPM 自体のインストールは割愛する。
$ npm install -g gulp
$ npm install gulp

Gulp の設定は Gulpfile.js というファイルで行う。 以下は ‘greet’ というログを出すだけのタスクを定義している。
$ cat << EOF > Gulpfile.js 
'use strict';

var gulp = require('gulp');

gulp.task('greet', function () {
  console.log('Hello, World!');
});

gulp.task('default', ['greet']);

EOF

‘gulp’ コマンドで ‘greet’ タスクを実行するとログにメッセージが表示される。
$ gulp greet
[01:32:47] Using gulpfile ~/Workplace/gulp/hellogulp/Gulpfile.js
[01:32:47] Starting 'greet'...
Hello, World!
[01:32:47] Finished 'greet' after 133 μs

‘default’ タスクを定義しておくと、タスクを指定しない場合の動作を決めることができる。
$ gulp
[01:43:23] Using gulpfile ~/Workplace/gulp/hellogulp/Gulpfile.js
[01:43:23] Starting 'greet'...
Hello, World!
[01:43:23] Finished 'greet' after 80 μs
[01:43:23] Starting 'default'...
[01:43:23] Finished 'default' after 7.59 μs

Gulp には組み込みでファイルの変更を検出する機能が備わっている。 試しに ‘Tempfile’ というファイルの変更を検出してみよう。 以下の設定で ‘Tempfile’ の変更を監視できる。
$ cat << EOF > Gulpfile.js 
'use strict';

var gulp = require('gulp');

gulp.task('watch', function () {
  gulp.watch('Tempfile', function () {
    console.log('Detect!');
  });
});

EOF

監視するファイルを作る。
$ touch Tempfile

‘watch’ タスクで監視を開始する。
$ gulp watch
[01:38:25] Using gulpfile ~/Workplace/gulp/hellogulp/Gulpfile.js
[01:38:25] Starting 'watch'...
[01:38:25] Finished 'watch' after 4.96 ms

別のターミナルから touch コマンドでファイルスタンプを更新してみよう。
$ touch Tempfile

すると ‘watch’ タスクを実行しているターミナルで、変更を検知してメッセージが表示された。 変更を検知した際の本来の処理内容は Sass や AltJS のコンパイルなどになるだろう。
$ gulp watch
[01:39:51] Using gulpfile ~/Workplace/gulp/hellogulp/Gulpfile.js                
[01:39:51] Starting 'watch'...                                                  
[01:39:51] Finished 'watch' after 6.57 ms                                       
Detect!

gulp.watch() メソッドの第二引数は関数でなくタスク名を配列で指定することもできる。
$ cat << EOF > Gulpfile.js 
'use strict';

var gulp = require('gulp');

gulp.task('logging', function () {
  console.log('Detect!');
});

gulp.task('watch', function () {
  gulp.watch('Tempfile', ['logging']);
});

EOF

次に、より実用的な使い方として LiveReload を試してみる。 既定の Web ブラウザにはあらかじめ LiveReload プラグインを入れておこう。 例えば Chrome なら以下を使えば良さげ。
https://chrome.google.com/webstore/detail/livereload/jnihajbhpnppcggbcgedagnkighmdlei

Gulp プラグインの gulp-webserver をインストールする。
$ npm install gulp-webserver

設定は以下の通り。 ‘app’ ディレクトリ以下をローカルの Web サーバで閲覧できるようにする。 その際 ‘livereload’ オプションを有効にすることでファイル変更を検知して自動でブラウザのリロードが走るようになる。 ‘open’ オプションを有効にしておくと、タスクを実行した際に Web ブラウザを開いてくれる。
$ cat << EOF > Gulpfile.js
'use strict';

var gulp = require('gulp');
var webserver = require('gulp-webserver');

gulp.task('webserver', function() {
  gulp.src('app')
    .pipe(webserver({
      livereload: true,
      open: true
    }));
});

EOF

公開するための HTML を用意する。
$ mkdir app
$ cat << EOF > app/index.html 
<!doctype html>
<html lang="ja">
<head>
  <meta charset="UTF-8" />
  <title>Document</title>
</head>
<body>
  <p>Hello, World!</p>
</body>
</html>
EOF

‘webserver’ タスクを実行すると Web ブラウザで上記のページが表示され、また同時にファイル変更の検知が開始される。
$ gulp webserver

試しに上記のページを書き換えてみると、ブラウザの表示内容が更新されるはず。
$ cat << EOF > app/index.html 
<!doctype html>
<html lang="ja">
<head>
  <meta charset="UTF-8" />
  <title>Document</title>
</head>
<body>
  <p>Hello, World!?!?</p>
</body>
</html>
EOF

今どきの Web アプリケーションの場合、HTML はもっぱら Web API を Ajax で叩くことになる。 上記のようにローカルの Web サーバで HTML の動作確認をしていると、Web アプリケーションとの通信に Same Origin Policy の壁が立ちはだかる。 例えば Web サーバが localhost:8000 で動作していたとして、Web アプリケーションが localhost:5000 で動作していると、オリジンが異なるため Web サーバ上の HTML からは Web アプリケーションにアクセスした結果が得られない。 Web アプリケーション側を、開発の時だけ XHR Level2 で実行できるようにするという手もあるが、恐らくはローカルで Web アプリケーションへのプロキシサーバを立てる場合が多いだろう。 gulp-webserver にはプロキシ機能が同梱されているため、次はそれを試してみる。

まずは Web API を想定したモックを作っておこう。 easymock は Web API のモックを作るためのパッケージだ。
$ npm install -g easymock

‘abc’ ディレクトリを作って ‘_get.json’ ファイルを用意する。 これは GET /abc したときの挙動を表す。
$ mkdir abc
$ cat << EOF > abc/_get.json
{
  "msg": "Hello, World!"
}
EOF

‘easymock’ コマンドで持っくサーバを動作させる。 デフォルトでは localhost:3000 で動作するようだ。
$ easymock
Server running on http://localhost:3000
Documentation at: http://localhost:3000/_documentation/
Logs at:          http://localhost:3000/_logs/

まずは ‘curl’ コマンドで動作確認しておこう。
$ curl http://localhost:3000/abc
{
  "msg": "Hello, World!"
}
よさげ。

gulp-webserver でプロキシを動作させる場合には ‘proxies’ オプションを指定する。 以下の設定では /abc 以下へのリクエストを localhost:3000/abc へとプロキシする。
$ cat << EOF > Gulpfile.js 
'use strict';

var gulp = require('gulp');
var webserver = require('gulp-webserver');

gulp.task('webserver', function() {
  gulp.src('app')
    .pipe(webserver({
      livereload: true,
      open: true,
      proxies: [
        {
          source: '/abc',
          target: 'http://localhost:3000/abc'
        }
      ]
    }));
});

EOF

タスクを実行する。
$ gulp webserver

すると localhost:8000/abc へのリクエストが localhost:3000/abc へとプロキシされるようになった。 これで Same Origin Policy は回避できたことになる。
$ curl http://localhost:8000/abc
{
  "msg": "Hello, World!"
}

ちなみに gulp-webserver のプロキシ機能は残念ながら WebSocket には現時点で対応していないようだ。 WebSocket も Web API と同様にプロキシしたい場合には、grunt-connect-proxy が対応しているため、そちらを使う必要がありそう。 ただ、WebSocket は Same Origin の制約は受けないはずなので、Web API と同じエンドポイントで扱いたいという以外で積極的にプロキシするモチベーションは無いのかな。

最近の Web 開発はどんどん複雑化している感じなので、タスクランナーで積極的に処理を自動化した方が良さげ。
Close

web audio API + canvas

Watch on epicwebdev.tumblr.com

Great lesson about Memory Management with Addy Osmani

Twilio, Tessel, and the Internet of People
9/16/2014– Jon McKay

Twilio and Tessel

Twilio is a company that is near and dear to our hearts at Technical Machine. We’re excited to announce that their Node.js library runs on Tessel. Twilio is the SMS and Voice glue for any communications-based applications and they have an amazing developer experience. Hands down, Twilio is the easiest way to send SMS and voice communications and I’ve yet to meet a dissatisfied customer.

In my opinion, Twilio and Tessel seem like a perfect match. Tessel is the fastest way to gather data about the physical world, and Twilio is the fastest way to get that information to the people who care.

Why SMS?

There are a whole slew of ways devices communicate with each other and with people: lightweight, radio frequency protocols (MQTT, CoAP, XMPP, BLE), haptics, or visual displays. But what happens when an individual needs to be notified of an event regardless of where they are in the world?

SMS is the best way to immediately get data to to the right person. While push notifications are also a reliable way of getting information directly to a user, it still requires them to download yet another app. As more and more connected devices have their own applications, it becomes increasingly tedious to download and use a separate smartphone application for each. Text messages are still the simplest way to get data from a device to a smartphone.

Running Twilio on Tessel

When we shipped Tessel, the runtime wasn’t compatible enough with Node for the Twilio Node.js library to run on Tessel. Not only that, but our WiFi state machine was unstable and prone to crashing making HTTP requests unreliable.

We’re really proud of the progress we’ve made since then to get the Twilio Node.js library running directly on a microcontroller. We’ve slogged through a whole slew of WiFi, JavaScript, and Node compatibility bugs for this library to start working. We’re starting to see other libraries (like Keen.io and MQTT which we’ll talk about more soon) Just Work on Tessel and it’s really exciting to see our original design finally coming to fruition.

We worked Ricky Robinet, a developer evangelist at Twilio to test out the Node library as we were fixing it. He was able to write a simple app on Tessel to get an idea of exactly how lazy his dog, Gif, really is. Using the Twilio Node library and the accelerometer module, he could detect when his dog was napping on the job, and send him a text with the nap duration. While it is an, admittedly, silly use case, his blog post shows the basics of loading the Twilio node module, monitoring the accelerometer values, and posting an SMS with an event has occurred. Check it out if you’re interested in sending a text message from Tessel!

Note: SMS in production

Lastly, running Twilio on Tessel is the fastest way to prototype an SMS-enabled system but you would want a different system design when moving to production. For example, you could move to a proxy-service oriented architecture: Tessel would send an HTTP request to a remote server and that server would take care of interacting with the Twilio service. The proxy server could also route incoming SMS messages down to the Tessel.

If you’re building an SMS-enabled Tessel application and you’d like help, feel free to post on our forums or shoot me an email at jon@technical.io.

-Jon

Close

HELL YE A   H

made in Processing

3

Ever since the clean up and reboot of our IDE, we have been making great strides in our code. Last week we got our code working in the browser and bringing in the data using oauth. Before this, the oauth was only working in the iOS simulator. We also created a lightbox-like picture display which can be used to view and scroll through tweets and is touch enabled.

After studying twitter Api further we fixed the bug in our loops which generated the diamonds. We finally have a working display of media and non media tweets using the gear image as a placeholder at the moment. His is very exciting for us because it allows us to move forward in our styling and testing and creating our sub pages.

Today we created our dynamic navigation system set up specifically for the iPad. This navigation updates the content using Ajax instead of loading each page individually like we previously had. In the long run this will save us time and size.

Text
Photo
Quote
Link
Chat
Audio
Video