Best practice for SOA based process-centric design

Pointers from one of the white paper I read:

1. Apply the componentization principle: Avoid embedding business rules into the application so that a tightly coupled design doesn’t constrain business. 
2. Apply granularity, modularity, and reuse principle: Reduce time to market by enabling modifications to the business rules and process flows quickly and independent of the application code. 
3. Apply the loosely coupled invocation principle and interoperability along with service consumption pattern: Seamlessly integrate other systems like payment services, booking etc. and also consume functionality from other systems as services. 
4. Apply service identification, design, and consumption principle: Expose the repetitive business tasks as services. For example, retrieving member information, generating reward certificates, etc. 
5. Apply process design, granularity and composite-ability principle: Design the desired flight reward booking process and other optimal sub-processes. 
6. Apply process metrics, analyze the metrics and improve the business processes: Compute the number of reward booking made in a day, loss of business due to not allowing purchase of shortage miles, etc. 
7. Apply versioning principle: Define process and service validity and manage old and new versions of processes and services so that they co-exist for a certain period of time before new processes and services fully take over.

Hibernate Configuration

Currently, I would prefer separating hibernate configuration into 2 files. With this, we can use spring to integrate and reuse the properties stated with EL. Hibernate will load the properties into config automatically as long as u name the file and variable correctly. Next post, I will show how to use EL to inject into bean automatically and the optimal setup for xml.

hibernate.cfg.xml
<hibernate-configuration>
<session-factory name="java:hibernate/SessionFactory">
<mapping resource="com/gl/dao/Country.hbm.xml">
</mapping></session-factory>
</hibernate-configuration>

hibernate.properties
hibernate.connection.driver_class=com.mysql.jdbc.Driver
hibernate.connection.url=jdbc:mysql://127.0.0.1:3306/glapp
hibernate.connection.username=root
hibernate.connection.password=password
hibernate.current_session_context_class=thread
hibernate.query.factory_class=org.hibernate.hql.classic.ClassicQueryTranslatorFactory
hibernate.dialect=org.hibernate.dialect.MySQL5Dialect
hibernate.show_sql=true

Presentation skills

You may wonder why I am touching something that is quite unrelated to programming. The truth is even for programming requires human interaction and to a certain extend good presentation is a must to bring your point forward, and not only that, one should aim to impress and sell the product well. The choice of words, the tone and especially the pace is all damn important. And so time to share one of the blogs I am reading everyday.

[Presentation Zen]
1. Chunking and exposure.
Identify and break down your presenting challenges into small manageable chunks, and deliberately expose yourself to each of them step by step.
2. Rehearsal.
Beyond just practicing your slide timings, actually visualize and hear yourself say the words with your slides. You see yourself in front of the crowd and rehearse your presentation to a variety of audience reactions, both positive and negative.
3. Self-talk.
Anxiety grabs onto self-critical talk such as “I’ll do a terrible job. What happens if the slide show fails. What happens if they don’t laugh at my jokes.” Your task is not to feed your anxiety with this type of talk, but to change it into “I can do this. I will follow my rehearsed plans. This is manageable.”
4. Arousal control via diaphragmatic breathing.
Calm your brain’s fear center with slow, deliberate breaths with slightly longer exhales. Slower rhythm (rather than deep breathing) is helpful for fear management.
5. Deliberate practice.
Practice your beginning, identify challenging concepts, and practice, practice, practice—out loud. These techniques work, and I use them myself as well as with clients. They are powerful and will prove useful in scenarios other than presenting."

Hope you will enjoy this.

Video: Javascript the good parts

Gotten this from the google blog, high recommended from my colleagues on how to write good javascript.



As usual, I will only share the good stuff. Pun not intended.

Learning iPhone development via iTunes

This link is shared in Facebook by one of my friend and I am quite surprise seriously Stanford is giving this course free of charge. I have yet to listen to it so do feedback to me on the quality of the lessons. If I'm not wrong, MIT also does provide a wide range of courses for free.

IMO, schools should still focus on lessons on improving engineering processes and practices. Application development on specific product come and go and hence it will be more beneficial for graduates to come out of school with the life-long "soft" skills like design pattern, best practises etc rather than going in too technically on a specific product.

Well its just my 2 cents opinion.

90% of the battle

Just to note down a conversation I had with a solution architect in the company. There is one particular portion that strikes me as I always thought that implementation phase might be the longest phase among the SDLC or  software development life cycle. I was surprised that it can be much shorter than what I think.

If the assumption is truly spot on, actually 10% of the time is doing implementation!

How can it be done? Probably the O2C SDLC will fit in perfectly. As programmers from China/India cost only 1/3 of Singapore, we can use 3 times the number of engineers to speed up the process. There are important consideration using this approach and one of them probably is whether the task can be split and run in parallel.

Having a infrastructure that is catered for the similar task also help the project to be on time tremendously. I will make some assumption that my current project should be at least 3-5 years and because of the infra, process has accelerated by 50% and more.

This is probably why the engineers won't get paid well unless the specialization is very niche. And that is what I'm aiming for: to have a balanced soft and hard skill set with my specialization on niche areas. Sounds like I'm asking for the best of both worlds :D

Moving on (to brunei)

I shall announce that the I have resigned from my job and move on to another company. Well I'm still doing the same job but with lower benefits.

As of now, I am in Brunei as a senior software engineer helping out with the requirements gathering. It is a rather refreshing experience compared to pure engineering job in previous company. I have been meeting up with several clients for the past 2 days and the skills required is quite different and hence I have to adjust myself to a totally different mindset. Like writing good and understandable minutes so that you don't have to rewrite and save the time for other task example sleeping.

Engineering is pure technical skills while requirements gathering is more of a soft skill. What I have learn is that once you are good at technical skills, you should be ready for gaining the domain knowledge for a specific sector. This is where you would value add. Knowing the processes of your client will help in knowing your client requirements beforehand and the obstacles ahead.

Knowing to do your task is one thing but the approach is also important. Requirement gathering is a human task and taking a soft stance towards your customer can help in building a cordial human relationship. As much as you want to get the things done, you also want your customer to be happy. Right?

I also learn about having a process towards gathering requirement is also beneficial. Talk with your customer about their requirements and then generate out a set of questionnaire for them to fill up before meeting up with them helps in reducing the time for requirement gathering.

Longer working hours seems like a norm like right now, just back from work and dinner, I am already at the living room with colleague ready to push on to finish the next task.

Time is short. Ciao