http://help.github.com/fork-a-repo/

git clone git@github.com:username/Spoon-Knife.git

cd Spoon-Knife
git remote add upstream git://github.com/octocat/Spoon-Knife.git
git fetch upstream

Committing Changes

# To commit changes to local repository
git commit -a

# Send changes to remote repository:
git push origin master

Update a Forked Repository

#Fetches any new changes from the original repo
git fetch upstream

# Merge changes retrieved from the fetch
git merge upstream/master

Creating a Branch

# Creates a new branch called "mybranch"
git branch mybranch

# Switch to mybranch
git checkout mybranch

# Merge changes from mybranch into master and delete mybranch
git checkout master
git merge mybranch
git branch -d mybranch

# Delete remote branch after local delete
git push origin :mybranch

Getting a Remote Branch

http://stackoverflow.com/questions/1897475/github-how-to-checkout-production-branch

# To list branches:
git branch -a

#You could checkout directly the remote branch after fetching it
git fetch origin
git branch -f remote_branch_name origin/remote_branch_name
git checkout remote_branch name

# or shorter:
git checkout -b production origin/production

# Merge changes from remote production into local production
git co -b production
git pull origin production

Tagging

#Create local tag
git tag -m"Tag version 1.0" V1.0 

# Push tag to origin
git push --tags

Merge Patch Request Locally to Test it Out

# Every pull request has a .patch URL where you can grab a textual patch file to feed into the git-am command
$ git checkout master
$ curl http://github.com/github/jobs/pull/25.patch | git am
$ git push origin master

Checkout the video and live demo at http://blog.chililog.org/2011/10/24/remote-javascript-logging/.

I’ll be blogging about how I’ve used Netty, HornetQ, MongoDB and Sproutcore to build Chililog here.

Current web browser communications protocol is limited to the HTTP request and response paradigm – i.e. the browser requests and the server responds.

What if we want to use a different communications paradigm?  For example, what if we want to perform 2 way communications where the server sends a request and the browser responds?  A common use case would be the server notifies the client that an event has occurred.

This is where WebSockets come into play. WebSocket is a technology providing for bi-directional, full-duplex communications channels, over a single Transmission Control Protocol (TCP) socket.

In addition, because WebSockets can co-exist with other HTTP traffic over port 80 and 443, firewalls will not have to be re-configured.

Version Confusion

WebSockets is an evolving standard.  Just have a look at the different implementations and the different versions each support.

There have been numerous version of the WebSocket standards under different names.  So far, browser have converged on 2 versions.

• Hixie-76/HyBi-00
• Safari 5+, Chrome 4-13 and Firefox 4 supports this standard.
• There are two names for this version because the Hixie-76 documentation is used as input into the new HiBi IETF working group.
• A flaw in this standard was discovered in the handshaking which requires exchange of binary data in the HTTP body.  This did not work across some proxy servers.
• HyBi-10
• Chrome  14, Firefox 7 and IE 10 Developer Preview supports this standard.
• Handshaking is performed in HTTP request and response headers
• Uses wire protocol version 8.  You will see “Sec-WebSocket-Version: 8″ in the HTTP header.

Hybi-00 and Hybi-10 both represents versions of the specification document.  The version of the wire protocol are actually 0 and 8 respectively.

Typically, the wire protocol (sequence of bits and bytes sent over the network) does not change between different versions of the specification document.  As such, the wire protocol version is set by the version of the specification document at which the change was made to the wire protocol.  So version 8 of the wire protocol was made in Hybi-08.

What changes are made between different versions of the specification document? Corrections of typos, clarification of concepts and adjustments in handshaking.

The latest version is Hybi-17 (with a wire protocol version of 13).  So far, no browsers have supported that version.

Netty WebSocket Support

I’m using Netty 3.2.5 in building Chililog (topic for another blog post).

Netty 3.2.5 supports Hixie-75 and 76 but NOT Hybi-10.

I’ve compiled together my own WebSocket package for Chililog to support both “Hixie-75/76/Hybi-00″ and “Hybi-10″.  This allows my Chililog server to support all of today’s major browsers (except for IE which does not support Web Sockets at all).

I’ve used the word “compiled” because I’ve extensively used code from Netty and Webbit (for which Aslak Hellesøy has written hybi-10 support).  I’ve also used code from cgbystrom to help build web socket clients.

I’ve submitted the work back to Netty as pull request #26.

Points of interest:

1. I’ve not changed the existing org.jboss.netty.handler.codec.http.websocket package.  I’ve found quite a few frameworks using this package.  I think it would be best if the next version of Netty can be a “drop-in” replacement.
2. I’ve put all my changes in org.jboss.netty.handler.codec.http.websocketx.  The “x” is intended to represent multiple versions.
3. The websocketx package supports both WebSocket versions (“Hixie-75/76/Hybi-00″ and “Hybi-10″)  for both client and server.
4. Frames
• Data is sent between client and server in frames.
• The old websocket package implements only the DefaultWebSocketFrame.  Text, binary and closing frames are encapsulated into this single class.
• The new websocketx package implements frames as a different class: TextWebSocketFrame, BinaryWebSocketFrame, CloseWebSocketFrame, PingWebSocketFrame and PongWebSocketFrame.  I felt that this made the code easier to read and understand.
5. Encoders and Decoders
1. Hixie-75/76/Hybi-00 is implemented as WebSocket00FrameDecoder and WebSocket00FrameEncoder.
2. Hybi-10 is implemented as WebSocket08FrameDecoder and WebSocket08FrameEncoder.  The version #8 is used because the wire protocol #8 is used in conjunction  with the specification document version #10.
6. Server Handshake
• Implements the handshaking protocol on the server side.
• Hixie-75/76/Hybi-00 is implemented in WebSocketServerHandshaker00  
• Hybi-10 is implemented in WebSocketServerHandshaker10  
• WebSocketServerHandshakerFactory picks the correct handshaker to use based on the handshaking request sent by the client.
• See org.jboss.netty.example.http.websocketx.server.WebSocketServer  for an example.
7. Client Handshake
• Implements the handshaking protocol on the client side.
• Hixie-75/76/Hybi-00 is implemented in WebSocketClientHandshaker00
• Hybi-10 is implemented in WebSocketClientHandshaker10  
  
• WebSocketClientHandshakerFactory picks the correct handshaker to use based on the version of the specification passed in as a paramter.
  
• See org.jboss.netty.example.http.websocketx.client.App  for an example.

Hope this helps anyone looking for Hybi-10 support in Netty.

27 Oct 2011 – Update

Pull #26 request has been merged into Netty.  This feature should be in upcoming Netty release 3.3.

20 Jan 2012 – Update

This has now been released in Netty 3.3. See blog post.

http://blog.platinumsolutions.com/node/234

Then I got the dreaded Error 1053 on stopping.

It was happening to me on Windows 2008 Server 64 bit R2.

Found that if I put a timeout on the stop, i did not get the error.

set PR_STOPTIMEOUT=5

// Trap Esc(27), Backspace(8) and Enter(13) -
// Except bksp on text/textareas/password, enter on textarea/submit/link
if (typeof window.event != 'undefined') {
  document.onkeydown = function() {
    var t = event.srcElement.type;
    var kc = event.keyCode;
    //alert('Type: ' + t);
    // Type = '' is what I get from the A HREF elements that need to remain functional in my form
    return ((kc != 8 && kc != 13 && kc != 27) || (t == 'text' && kc != 13 && kc != 27) ||
            (t == 'textarea' && kc != 27) || (t == 'button' && kc == 13) || (t == 'submit' && kc == 13) ||
            (t == 'password' && kc != 27 && kc != 13) || (t == '' && kc == 13));
    }
} else {
  document.onkeypress = function(e) {
    // FireFox/Others
    var t = e.target.type;
    var kc = e.keyCode;
    if ((kc != 8 && kc != 13 && kc != 27) || (t == 'text' && kc != 13 && kc != 27) ||
       (t == 'textarea' && kc != 27) || (t == 'button' && kc == 13) || (t == 'submit' && kc == 13) ||
       (t == 'password' && kc != 27 && kc != 13) || (t == '' && kc == 13)) {
        return true;
    } else {
        return false;
    }
  }
}

Add the following column.

      SC.TableColumn.create({
        key:   'dummy',
        title: 'Row',
        width: 50,
        isReorderable: NO,
        formatter: function(v, target) {
          return target.get('contentIndex') + 1;
        },
        exampleView: SC.TableCellContentView.extend({
          textAlign: SC.ALIGN_RIGHT,
          fontWeight: SC.BOLD_WEIGHT
        })
      })

Note that the key is set to a dummy property in your model that does not exist.

In the formatter method, I get the row index, add 1 and display it.

1. Buildfile in apps/my_app directory override Buildfile in the project directory

2. Specify required framework in apps/my_app directory Buildfile

config :my_app,
         :css_theme => 'ace.my_app',
         :required => [:sproutcore, 'sproutcore/statechart', 'endash/table']

3. Put URL proxy in project directory Buildfile

config :all, :required => [:sproutcore]

## Proxies
proxy "/api", :to => "localhost:8989"

4. Default Buildfile settings is found here.