Sunday, December 30, 2012

Messaging for Mobile Apps (XMPP)

I've been looking around for a solution to messaging between devices since I'd like to experiment with creating a lite version of a game (Avatar) that I worked on in college as a learning experience. More about that at another time.

http://en.wikipedia.org/wiki/Avatar_(video_game)

XMPP (Jabber) looks interesting. What's really attractive is that I may design the App with no server-side component with just message handling on the Internet. It's different since Avatar in college depended on shared memory (common) and only used a message queue for a portion of the game.

Here's video that got me started (Hulu developers):

Building Asynchronous Communication Layer w XMPP, Ruby, Javascript
by Andrew Carter and Steve Jang
http://www.youtube.com/watch?v=3ZynQ04BuN8

And an interesting article:

http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes

And a JavaScript library to experiment with:

http://strophe.im/strophejs/

Jabber server to experiment with:

http://www.ejabberd.im/

http://www.jabber.org

I've been working through the XMPP Professional Programming with JavaScript and jQuery book. (Jack Moffitt's Blogbook site, book forum, and Github with code.)

A very valuable link to know about relates to CORS and cross-domain security issues:

http://metajack.im/2010/01/19/crossdomain-ajax-for-xmpp-http-binding-made-easy/

And root article on CORS:

https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS?redirectlocale=en-US&redirectslug=HTTP_access_control

Another interesting link -- covers configuration issues related to cross-domain:

Build a web-based notification tool with XMPP
https://www.ibm.com/developerworks/xml/tutorials/x-realtimeXMPPtut/

Covered in the book -- more reading some day on the theory behind Google Docs multiple editors of a document:

http://en.wikipedia.org/wiki/Operational_transformation


Tuesday, October 16, 2012

Alvin Roth Wins Nobel Prize


I was fortunate to have worked my way through college as an Undergraduate Research Assistant with the Economics department at the University of Illinois working on multi-player bargaining experiments funded by some NSF grants where one of the researchers was Al Roth. He was already well known in game theory at the time these experiments were conducted.

The Sveriges Riksbank Prize in Economic Sciences in Memory of Alfred Nobel 2012 was awarded jointly to Alvin E. Roth and Lloyd S. Shapley "for the theory of stable allocations and the practice of market design"

http://www.nobelprize.org/nobel_prizes/economics/laureates/2012/

Three of his earlier papers where we (Ron Harstad, Michael Barr, myself) contributed by building multi-player experiments on PLATO:


Expectations and Reputations in Bargaining: An Experimental Study (1983)
https://web.stanford.edu/~alroth/papers/1983_AER_Expectations_and_Reputations.pdf

The Role of Information in Bargaining: An Experimental Study (1982)
https://web.stanford.edu/~alroth/papers/1982_E_Role_of_Information.pdf

Sociological versus strategic factors in bargaining (1980)

A footnote in history!

Monday, July 30, 2012

Tips for Working with an Overseas Team

Working with distributed and overseas teams is a fact of life these days in technical environments especially and knowing some basic tips will utilize the talents of the entire team more effectively.

Time Zones

Time zone differences can accumulate to mean real schedule slippage so you have to try to use the time zone difference to your advantage. For example, if the shift in India starts 10 hours ahead of east coast time consider working in the evening for an hour or two to prep work plans for the next day. When you arrive in the east coast morning, the team in India will have had several hours to work on tasks that you'd agreed to. If you wait until the morning you may miss an entire day of productivity in India.

This time zone issue even comes into play with east coast / west coast teams. If your west coast team gets a late start they are going to push the east coast team to have meetings at the end of the day. Not always practical. And having the west coast team get up early constantly is often not workable, especially with tech workers who seem more prone to night work than morning work in my experience.

Asynchronous communication like email helps of course, but still, email that is not responded to for many hours requires more time to come back up to speed. If you are both online working and can respond within 30 minutes or so the thoughts behind the email will still be quick to draw on.

Communication

Verbal communication can be challenging with language barrier and accents so I find that technical conversations and involved explanations are best handled with email. Having a call several times a week is important though to establish an emotional connection with the overseas team.

Make sure you respond to questions from the overseas team promptly. Just deciding that they'll figure it out is a recipe for rework and lowers morale. I also like to solicit feedback and suggestions as there are some incredibly talented people working in India and elsewhere and as a team we need to tap the talent of all members as much as possible.

Importance of an Issue Tracking System

Having issue numbers to refer to as a shared language (interesting comparison to mathematics as a universal language) is very helpful. It takes time to establish a procedure with the team to make sure everyone is being diligent about using the issue tracking system, but it really pays off in adding shared organization around the work tasks.

It's very handy to be able to pull Excel extracts from the issue tracking system to build ad hoc reports. And investing in some Excel macro development to create regular reports instead of developing full online reports (at greater expense) can be a reasonable way to go, especially if the product manager or another in-house team member writes Excel macros. Reports can be adjusted quickly for reporting to senior management.

Quality Assurance

Although QA should definitely be part of the overseas team's process, you need to have either in-house QA or QA provided by another vendor. I would argue for at least some minimum QA by in-house personnel who can also double as support because they know the product. Even if the overseas team produces perfect work, there are going to be misunderstandings around requirements and an in-house QA team will be more likely to pick those up. The in-house Product Manager also has to participate in QA.

Personnel Issues

It's really essential to have localized management that's responsive. It's just not practical or fair to manage an overseas team of a dozen or more at an individual level. There are going to be personal issues as with any team and not being present physically makes it impractical to know what is going on. Having a good relationship with the management onsite with the overseas team is important. Invest in it.

Financial Issues

The overseas team needs to provide good time records and they need to be tied back to the issue tracking system so you can monitor and defend the costs associated with various development, QA, and support issues. It will take a few (monthly usually) cycles to establish a good routine.

Management Philosophy

On software teams and with the rise of Agile in particular, managing teams with Theory X is not effective so the skilled manager of an overseas team (any team really) needs to find a way to encourage the team to produce great results using a Theory Y philosophy.

Wednesday, May 30, 2012

Mobile HTML5 Dev Test Site: RingMark

Facebook sponsored test suite for HTML5 mobile development. Very cool.

http://rng.io/