Here is my presentation for Silicon Valley Code Camp 2015 on EcmaScript 6: "Amazing new features in JavaScript"

http://www.slideshare.net/mkumar327/ecmascript-6-53522648

Silicon Valley Code Camp 2013

After one year of gap, I am back to Code Camp. I presented a session on JavaScript. Good thing is that I got some positive feedback from the audience but unfortunately I could not cover the code walk-through and the fun part - Solving Rubik's Cube. Need to manage time properly in my presentation.

Thank you so much to all of you who came to my presentation!

I am going to work a little bit more on Rubik's Cube program and post it later.

Java scrip rubikcube from Manoj Kumar

Silicon Valley Code Camp 2010: Asynchronous Web Services

Thanks everyone for showing up early on Sunday for my presentation. I had really nice time talking to many attendees who had so many questions.

I have presented sessions on this topic in last three JavaOne. ppt for the last year's java one in publicly available at:

http://developers.sun.com/learning/javaoneonline/sessions/2009/pdf/TS-4993.pdf

Feel free to post your questions.

JavaOne 2009

I am presenting two sessions in the JavaOne this year.

BOF-4394 Case Study: Managing a Large Web Service Project Based on Java™ Technology
TS-4993 Dealing with Asynchronicity in Java™ Technology-Based Web Services

The inspiration for the first one came from one of my colleagues in Oracle, Vaibhav Lole, who was leading a web service project and kept asking me all sorts of questions during the project. I have invited him to share the experience with us and learn from other developers who come to our session.

The second one is a repeat from the last year. We wanted to add new stuff for a change but after doing lots of editing and trying to keep the number of slides within limit, we could not do the justice. I'll try to describe some of the major issues in this blog that I want the community to share with me.

1. Can we make WS-AT work with One-way calls and requests with non-anonymous replyTo?

Problem with the one-way call is that the service is supposed to return immediately (after doing some basic stuff) to release the http connection so that the client can proceed. And then the server continues processing the request. If the transaction context is passed to such a call then the client will not know when to commit. Also, the transaction will be active at the server side in a different thread probably which is kind of weird for the transaction as traditionally the transaction context is associated with only ONE thread. To add to the problem further, if the one-way/async request is stored in the JMS queue then the async message listener will not see the message until the transaction is committed. So, if the client's transaction waits for the response for the async request before it commits, it will never receive the response.

We have two solutions for this problem:

a. Do not support WS-AT for one-way/async calls. This is what is done by some vendors. If you use such a system, your applications transaction control is broken the moment you start using one-way/async calls.

b. Lets interpret the meaning of transaction for one-way/async calls in a different way.
If a one-way/async call is made, the transaction context from WS-AT must be passed if server allows that.

The server should 'record' the request 'within the current transaction'. For example, saving the request message in the database or JMS queue should be done within the running transaction.

When the WS-AT transaction is committed in the client's side, the 'recording' of the request message is also committed at the server side.

If the client's side transaction fails, the message recording at the server side rolls back.

The actual processing of the request happens outside the client's transaction but only after the successful commit of the client's transaction.

If something goes wrong in the execution of async operation, we cannot 'rollback' the client's transaction (as it is already committed), but service may provide other compensating methods for that purpose.

In my opinion, we should go by the second option as completely disabling WS-AT for one-way calls gives us nothing but the broken applications. Making the server 'promise' that the async operation will get executed ONLY if the client's transaction is a committed is a BIG step forward.

More to come later..

Rubik's cube

I got hold of rubik cube after more than two decades and found out that I had forgotten many moves. Tried to look at internet, where you can get thousands of solution, but these are not MY solutions and so it's hard to remember. So wrote some simple java program to find out the moves.

Here is a set of moves that one can use to solve the cube.

Correct first layer by common sense. ===============================================================

For second layer: Keep the correct face as BACK.
================================================================
Move#1: only one cubelet moves in the second layer : ru
=======

(r'fr f uf'u') ==> main move: fl -> ru, other movementa are in 3rd layer that we don't care.

Full move:
(r'fr f uf'u') ==>
fru -> ulf -> ruf
dfl -> ldf
ru -> df -> uf -> fl -> ru

Move#2: only one cubelet moves in second layer : lu
========
(lf'l'f'u'fu) ==> main move: fr -> lu

fru -> ful -> ufr
dfr -> rdf
fr -> lu -> df -> uf -> fr


For third layer:
================================================================
First correct colors of all middle ones.. ignore the positions of the edges

keep third layer (that is to be corrected) as RIGHT SIDE



Move#3
=======
to flip fr and dr

f r d r' d' f'

(frdr'd'f') ==>
fru -> drf -> ruf
bru -> drb -> rub
fr -> rb -> rd -> fr

Move#4
=======
to flip fr and br, do the reverse of the above.

f d r d' r' f'

(fdrd'r'f') ==>
fru -> fdr -> ufr
bru -> bdr -> ubr
fr -> rd -> rb -> fr

=================================================================

Now rest can be done in any sequence
-------------------------------------------------------
1. Keep the third layer as the FRONT

First correct the positions of all corners. Make sure that coreners are not like a <=> b and c <=> d. If it is so, just turn once 90 deg.
Then one will go in right place, rest 3 can be corrected by ..

Move5#
======
(r'd'ldrd'l'd) ==>
fru -> drf -> ful -> fru

This moves 3 corners in front clockwise, leaving dlf intact.

To move the same 3 anti clockwise, do this:

Move 6#
=======

(rf'l'fr'f'lf) ==>
fru -> lfu -> drf -> fru
-----------------------------------------------------------

2. To correct the rotations on all the corners:

use Move#5 + move#6 to rotate

Move#7
======
(r'd'ldrd'l'd rf'l'fr'f'lf) ==>

dfr -> rdf --> turned antcloskcwise +1
flu -> luf --> turned anticlockwise +2 or clockwise +1


3. To correct the position of all the edges in the last layer, use this move with some required prep-moves


Move#8
======
| f2 ^ f2
V |

1st move is to move the middle slice down, looking from front, or anti clockwise looking from right side
3 rd move is just the opposite of the first one.

fu -> bu -> fd -> fu

If front is the last layer, then fu and fd are fine, bu seems odd as it has been already corrected. Here the idea is that
move fr or fl to bu position, do the move and then get bu back.

To move fr to bu, do (r2 b)
To move fl to bu, do (l2 b')

After moving fr or fl to bu, do Move#8, and then get bu back to fr or fl.

I just started using closure and can't stop thinking or talking about it!

One thing that I am not very happy about is the control abstraction.

A method that accepts an unrestricted closure as the last argument can be called using the control invocation syntax.

Why should we have this restriction that only the last argument can be called using the control invocation syntax?


It will be nice to have any number of arguments to be like that. Ex.

    public static void DoInSequence( {==>void} first, {==>void} second) {
        first.invoke();
        second.invoke();
    }

right now we can do ..

    DoInSequence(
    { =>
        System.out.println("3.First");
    })
    {
        System.out.println("3.Second");
    }

but not..

    DoInSequence()
    {
        System.out.println("3.First");
    }

    {
        System.out.println("3.Second");
    }