Tuesday, December 18, 2012

Thoughts on JavaScript Development

Subject: Thoughts on JavaScript Development

  • note: originally emailed 12/18/2012 and sanitized for public consumption
  • sidenote: posting here so i can lead people here whenever they ask me about this stuff...



Sent by XXX:
I am trying to put together an argument to use pure JavaScript. I wanted to get some of your thoughts on large scale application JavaScript. Like how feasible you think it is to use JavaScript for large scale applications and where the code base can become large. Also some ideas on how to combat the fact that JavaScript is not a structured language and sometimes makes maintainability of a code base and testing and such a nightmare.


I would have to ask, what is the application trying to do?

One of the mantras of “unix” utilities is, small programs that does one thing really really well.  But you can put a bunch of them together to make really powerful and extremely flexible set of tools.  Putting them together leverages each of the specialized utilities (concentrated in what they do) to make a bigger (and more useful) end product results.

Wait… here it is: http://en.wikipedia.org/wiki/Unix_philosophy
  • To this, I would liken it to the *.lib concept in programming (instead of end user executables)

You will have some people argue against that for ‘large scale application’ – but I contend that it is [usable].

As for code bases becoming large:
  • Just like any other programming languages, a good set of APIs and documentation would carry it a long way.
  • Again, think of it as if you were releasing an XYZ.lib object, it is only useful if it's easy to pick up and run with it.
  • However, in JS, it’s even easier for people to just try:
    • By just including an 'example' demo with the "library" --  this will make developers that much closer to using it.
    • [Downloading and running it] is a lot easier than "lemme see how I’m supposed to be using this…"
  • Large code base can be managed by modularizing the components to specific tasks
    • This is by far my #1 requirement and the way I do things.
    • Think of this as, if I find a better replacement, I can drag and drop it in.
    • Lately [work related], it’s the need for an [alternative] mode – using a plug-in style provides the mechanism for this.
      • So in [ABC], for example, the core logic of controlling the boxes and displaying the visuals are all the same.
      • The network messages, on the other hand, are different.  So these were split off from the core base code.  Again maintaining the separation of logic by putting them in their own "modular" file/component.
      • [XYZ] does this too.  Right now we have basic [xyz1] and [xyz2] (it isn’t separated yet) but think of it as how you have [awesome featurez currently]. All of the core functionality are split out.  This can also be done in JS.
        • I hope to split out [xyz2] and make (maybe) [xyz3 soon] to further show the modularity concept.

As for its non structured language:
  • Just like any other programming languages, unit testing is invaluable.
  • Javascript is just as easy to unit test and can be done along with normal development.
    • I would contend that it is even easier to write test cases for it in JS.
    • I can add a “debug” [file] version that is normally not picked up on release -- but when included, [it] will augment the features, capabilities, flow, etc. without interrupting or polluting the base code.
      • I have done a GIANT code clean up to show this concept a bit more clearly.
      • The PHP code was cleaned out of any ‘core logic’ – this was pushed in the base game JS code
      • Any “add-ons” are dynamically included (see AlertBox, DebugPrint, [abc], etc as examples).
        • None of them have any required code called from the base game
        • Just including the JS file will automatically generate and append the required code in the browser
    • Again, following the “example” demo method, you see it running live, can take any of the code you may find useful or leave it alone, very flexible.
  • I would also argue that it’s actually easier to maintain (and read and follow the flow) of scripting languages than the giant plumbing [code in] structured languages.  Which goes into my next topic: framework.
    • But first, don’t get me wrong, I totally understand the need for strong typed languages and I have programmed with them a lot in the past.
    • But, I [find] there are a lot of times when I need to write quick and small utilities, [and] I prefer to write them with as little lines of code as possible.
    • The benefits of extreme-rapid-development with very-fast-iteration times has far outweighed the usability of strict and terse programming.

HTML(5) + CSS(3) + JS *is* a framework [out of the box].  A lot of work has been done by a bunch of hard core nerds that created quite simply an extremely robust yet flexible/tailor-able renderer that can be your basic e-reader, live auction viewer, balance your financials, connected/online universe, and a whole heap of other possibilities.
  • I would also mention that there isn’t that much more (system) code that needs to be written to provide features already supported by the browser itself. Let me re-phrase that.  There’s no need to re-write (i.e. re-invent) the core features already available in the modern browser.

Finally, the sheer volume of documentation, books, online resources and examples out there makes it very easy to find solutions to questions, problems and wonderment when everyone is speaking down to the nuts and bolts – pure JS.  Otherwise, you will be hard pressed to find the same answers, suggestions and recommendations if it was written anything else for the browser.

Hope this helps

Posted by Nick Shin at 11:47 AM 0 comments
Labels: , ,

Wednesday, December 12, 2012

jenkins and puppet

Subject: jenkins and puppet

  • note: originally emailed 12/12/2012 and sanitized for public consumption
  • sidenote: posting here so i can lead people here whenever they ask me about this stuff...


Ok, here’s what I got from trying to figure out what Jenkins and Puppet is.


Starting with Puppet, from Puppet Labs:

At first, I thought they are something like building you own distro with a configurable ‘manifest’ (it kinda is).  But upon reading part 2 of their 'learning puppet' docs it finally became clear what puppet does (go figure that it was on the last page of their collection of docs:).

It basically describes the "agent" doing a pull-request from the "master" for work" – this is nothing more than:
  • Poll the server to find out what-to-do…

In a nutshell, this is a way to deploy a node (either natively or VM) like any other linux distro, but does have some interesting ways to configure/interface with cloud providers (like netflix’s asgard), see the node’s status, configurations (like openNMS/nagios) as well as updating/patching them (like rsync).

Again, the feature is the ability to run unit testing with the agent and master configuration.


Jenkins is a continuous integration server.  Basically, a 'build server' – which I believe is a must have for any projects that uses compilers.  Not quite so much for web based content though [using Jenkins, that is...].
  • However, the stuff that you plow into Jenkins is the same stuff I plow into a script file.
  • Put this together with a cronjob (or whatever periodic scheduler you like) and you have Jenkins.
    • which can have more [added tasks], customizations and logic plowed in there
    • and generate a results page


It doesn’t seem that Jenkins will run and do unit testing on the build’s executable.
  • But, this is where Puppet comes in.


Posted by Nick Shin at 4:54 PM 0 comments
Labels: ,

Thursday, April 19, 2012

advergaming

Subject: advergaming

  • note: originally emailed 04/19/2012 and sanitized for public consumption
  • sidenote: posting here so i can lead people here whenever they ask me about this stuff...



Just a comment (or my ramblings) on advergaming in general:

Advergaming has been kicked around a lot a few years ago when every ad agency wanted to get in on the console market.

The best example of a very successful execution was the burger king games:



The Magnum ice cream ‘advergaming’ is an interesting one.
  • The game was actually quite easy to (get into and) play.
  • The scrolling through the many ‘random’ web sites is also ‘nice’.
  • But, I think I would get tired of playing this and in fact, I would only play it once.
  • I actually tried playing again to see if I can click on any of the ‘websites’ you were running across to see if the links were live.
    • They were not.
    • This is where I think they fell a little sort of.
    • You would think they the pages you would run across would be dynamically changeable/updated.  This made the game ‘old’ really fast. 

It’s a good start…

However, [here's an] example [I'd like to bring up]:  a live page with clickable links and everything ‘real’ – is way more effective, you don’t play this, but it is based on a game and is something similar to ‘outside of the box interactions’:





From: [colleague]
Subject: advergaming

Building off of last week’s brainstorm on creating a value proposition to entice transitional players with social/casual content I thought I’d share this interesting game/ad.

http://pleasurehunt.mymagnum.com/

the simple interaction of right left arrow and space is augmented with changing background content (advertising content) that itself becomes interactive in different ways.  Magnum ice cream is turning what had been a cost (advertising) into a rev stream (others advertisers paying them - assumedly) to be content in their game.

I’ve never heard of Magnum ice cream, but I’ll look for it now. This is one area they could have improved this content: they should’ve worked their distribution channels into the content so I’d know where to look for their product.

Hope this gives you some ideas for your group’s deliverable next week.

Thanks,

Posted by Nick Shin at 3:09 PM 0 comments
Labels:

Tuesday, February 14, 2012

improving browser reflow (rendering) performance

Subject: improving browser reflow (rendering) performance

  • note: originally emailed 02/14/2012 and sanitized for public consumption
  • sidenote: posting here so i can lead people here whenever they ask me about this stuff...


[Boss],

To answer the question on why the android tablet was performing worse than the iPad, I took out the transparent animated images during the ‘spin’ to ‘fix’ the issue.  (This is probably why iPad didn’t support animated PNGs in the first place.)

To understand why the rendering was bad and how to improve on 2D performance for the browser games we’re doing, last night I got a crash course about browser “reflow” behavior.

In a nutshell: I was wondering if there was a way to stop the browser from re-drawing the page every time one element was being change.

There is no ‘double buffering’ for the browser, but there is something close to it (DocumentFragment).  Meaning, that I would have to update/animate everything that is dynamic manually in the render/game loop.   The payoff is a (2-3x) performance improvement.

I am going to restructure the current games to take advantage of this.  [XYZ] was re-rendering the pages 3 times an update using the animated PNGs and [ZYX] rotation.




The following are resources to learn more about this:

Here is an nice example of how a browser draws stuff to the page:

Here’s some information on what the rendering path looks like on your typical browsers (in a easy to read format)

If you want to know more (warning: VERY INDEPTH) about how browsers work:

Posted by Nick Shin at 2:50 PM 0 comments
Labels:

Monday, February 6, 2012

[ data data data ]

Subject: [ data data data ]

  • note: originally emailed 02/06/2012 and sanitized for public consumption
  • sidenote: posting here so i can lead people here whenever they ask me about this stuff...
From: XXX
the "need" for convenience
I have learned a very important lesson about that phrase when a friend of mine told me this:
"Me and computers are like a plugged in electric toaster in a bath tub full of water.  I am willing to pay extra for the added convenience of having something that just works.”

Authenticity… trustworthy… 'to be treated as humans'
There will always still be the need for anonymity, especially if you’re a parent with children trying to keep them safe from the crazies.

I'm beginning to see a resurgent desire for simple, straightforward, lasting, superior items.
Beginning?  This has always been the bane of internet browsing forever -- terse and obtrusive $#!t plastered all over the website.  How many web sites have you been to that was just too cluttered to use in the past 10 years -- flash heavy, ads spaces everywhere, pop up windows, "join/create a profile" overlays...

I don’t surf web sites anymore.  I find them on RSS feeds or when they are mentioned on podcasts.

I always use ‘adblock plus’ on my browser.


I absolutely agree that simpler, cleaner and streamlined web sites are the future -- to bad marketing will do everything they can to screw that up.  I almost shed a tear when 'mobile' sites started showing up -- a simpler, cleaner and streamlined version of their desktop counter-part.  Too bad many of them are a little 'too simple/vague'.


I don't know how many scripts I have to auto download web pages for me; snip the areas of interest I want; and collate all of the relevant data on a single page.  Too many web sites now want you to click through so many links to get the overall data, and most of them with extremely s.l.o.o.o.o.o.o.w response times.

Will we ever have so much information online that people stop asking each other for recommendations (i.e. will we ever make an information filter that is as personal and reliable as another human)?
I have learned a funny thing from another friend of mine:
If there are no ads, who will tell me what to buy next?

Now, you have to ask yourselves; are advertisers just as 'reliable' as another person?  I mean, they are done by people.  They are put up on TV, radio, print, whatever that are run by people.

Many 'humans' use them as a 'source' for [ finding out more / talking about it ]. It would seem to me that information online is just the same.  A source to springboard off of to find out more information about it if it interests you.

I always like to say:
Having too much information is better than not having enough.

I would like to close by also saying this; sometimes, information overload is perceived that way only because 'humans' are also very visual creatures.

You can look at a ton of data (i.e. 'read' it) if you like to watch paint dry.

Or you can 'watch' the data if it's been converted into a more palpable format.  Visualization (in computer graphics) is one of those exciting areas where art and design is merged in with the terse and bland 'data tables'.  One famous example of this is the visualization of flight path data.

Some good books on this topic:

I know there are more, I just don’t remember the titles to them off hand.

[But,] here’s something cool I just ran into:
http://www.blendernation.com/2012/02/08/blender-movie-winner-in-2011-science-visualization-challenge/


Posted by Nick Shin at 4:22 PM 0 comments

Thursday, February 2, 2012

Social Gaming

Subject: Social Gaming

  • note: originally emailed 02/02/2012 and sanitized for public consumption
  • sidenote: posting here so i can lead people here whenever they ask me about this stuff...


I haven’t done any FB apps, but I just ‘made’ a FB app following some dirt simple instructions.

You can see it here:

The ‘app’ is actually hosted outside of Facebook:
  • You can right click on (on the very right edge of the flash content and scroll bar, if you can) and see that it’s just an <iframe> (what Facebook is calling the canvas) pointing to the source of that asset.
    • You should see it open to: (or if you are having trouble getting the right click menu button to show the browser menu instead of the flash menu)

So, getting stuff to show up on Facebook is easy.  The power comes when you want to do things like inviting/playing with friends, integrate with Facebook’s credit (payment system) and other features that tie into their API’s.

For example, to look yourself up on Facebook’s API system:

And using code facebook has provide at:

You can, for example, fetch all of your friends:


<?php
require 'facebook-php-sdk/src/facebook.php';

 $facebook = new Facebook(array(
    'appId' => 'YOUR_APP_ID',
    'secret' => 'YOUR_APP_SECRET'
));

 $me = $facebook->api('/me/friends');
/*
 * access all the information of friends
 * $me has the JSON detail of all the facebook friends of the current user
 */

 foreach($me['data'] as $frns) {
    $id = $frns['id']; /* make the echo statement a little easier to read */
    $name = $frns['name']; /* make the echo statement a little easier to read */
    echo "<img src="https://graph.facebook.com/$id/picture" title="$name" />";
?>



There are much more terse ways to do this.  They are all found on Facebook’s developers docs:



The following is where I got the dirt simple instructions from:


So, to answer the original questions:
  • To Build FB games:
    • You can use whatever flash, unity or plain ol HTML assets you have.

  • To scale FB games:
    • FB punted on this and makes the developers host the content.
    • So, you will need servers for the (static) pages.
    • You will need more servers if you want to do things outside of the FB infrastructure.
      • Like what? May be like a [super awesome] mechanism that FB’s systems doesn’t provide.

That’s all I got for a few of hours of research…

Posted by Nick Shin at 2:24 PM 0 comments
Labels: ,

Thursday, January 12, 2012

HTML5 CSS3 and stuff

Subject: HTML5 CSS3 and stuff

  • note: originally emailed 01/12/2012 and sanitized for public consumption
  • sidenote: posting here so i can lead people here whenever they ask me about this stuff...


So, during the winter break last month – I just happen to be at the large brick n mortar book store that’s still around looking for that last minute gift selection.

I wandered to the “computer” section as I always do and noticed a few new books on the shelf and proceeded to thumb through it.


The first book that got my attention was the HTML5 Cookbook

The next book: HTML5 Canvas


The following book: HTML5 Applications wasn’t that great.  But it did tell me about me two other books:
  • Building Android Apps with HTML, CSS, and JavaScript
  • Building iPhone Apps with HTML, CSS, and JavaScript: Making App Store Apps Without Objective-C or Cocoa

And those lead me to the Phone Gap project – now acquired by Adobe.  This is a path to develop native application via HTML5 + CSS3 + javascript code base.  The project is technically an open source project and can be found at Apache’s repository: at first called ‘callback’ – now called ‘Cordova’.


Finally, some other goodies I happen to run across:
  • The Book of CSS3: A Developer's Guide to the Future of Web Design
  • JavaScript: The Definitive Guide: Activate Your Web Pages (Definitive Guides)


Anyways, here’s a collection of must have bookmarks:


There are a lot of other HTML5 books out there:

And, with some high profile acquisitions:

This stuff is becoming more and more mainstream.




Sent: Thursday, October 13, 2011 4:19 PM

I forgot to add the following

If you are familiar with Visual Studio’s Debugger, then you are going to feel right at home with the firebug plug-in for firefox:
  • http://getfirebug.com/doc/breakpoints/demo.html
    • Break on all errors (such is unknown function or variable names), equivalent to compile time error
    • Break on attribute or DOM property change – equivalent to VS break on watch point change
    • You can even break on CSS style rule changes
    • It has watchlists
    • Setting breakpoints
    • It also has a runtime profiler (and quite nice too)
    • And even a memory profiler (just as nice)
    • Finally, a network profiler
    • which didn’t work so well when flash inside of a flash file were making raw network calls
    • but if you use standard HTML request, it spells out everything your browser is doing (except for websocket calls – hopefully, it will be supported in future releases)

The only other negative thing I ran into is that it doesn’t trip on syntax errors (because the file never gets “loaded” to the browser, so firebug doesn’t know about it) – but you can use JSlint for something like that

And I forgot to add this for supported browsers:
  • Chrome 14


Sent: Wednesday, October 12, 2011 3:27 PM

Since I’ve been diving into the world of HTML 5 CSS3 and javascript, I figure that I share some of my findings.


Note: make sure you’re running at least:
  • Sarafi 5.1
  • Firefox 7
  • IE 10 (which isn’t out yet)

Browser technology has come a long way.  Take a look at the following:
CSS3 is supposed to be “hardware accelerated” which I can only guess it means that it builds GPU instructions from the baked set of styles.

Javascript has to run on the CPU.  CSS are normally not changed after it is set.  So it gains a lot from deterministic values.


Anyways, here’s another cool demo:
  • www.idangero.us/cs/
  • The package is a product, so this one requires licenses
  • But it shows what a little bit of CSS and javascript together can make

Here’s a pile of “best-of”:

For a little crash course on HTML5:

Enjoy! -- Nick

Posted by Nick Shin at 1:51 PM 0 comments
Labels: , ,
Subscribe to: Posts (Atom)