hi

http://wpproservice.com/choices.php?meat=ggxvfbny241feb51r


Prashant

hi

Hi



http://fgmf.com/jet.php




parashar_prashant

Improved and moved

This blog has now moved to a more improved and customized page

www.prashantparashar.com







*********************************************

Future Technology: Cool Sixth Sense Technology

How to get a two-letter e-mail address at in.com ?

Did you always want to have a real short and sweet e-mail id on a website. But Ah! yahoo, google and others always put those restrictions that your userid should be at least these many characters.

So, the desire to get a real good id was always a dream. A dream only till recently.

Somebody launched a website in.com and wanting to project it India's next yahoo or google mail service (?) .
As the service is relatively new, chances are that you would get your first name as e-mail id. And who knows you could get really lucky if it goes to become next yahoo!

So, what's so wonderful about all this? Well, the intersting part is:

You could get a two-letter e-mail id at in.com using a small hack

Welcome to the Internet in.com!

Just a small trick gets you a two letter id, just like I got pp@in.com for me.

While signing up on the website, put two consecutive periods (dots) between the two letters that you want your e-mail Id to be and thee you go!

For example, two select my id "pp" , I selected a user-id "p..p" and got pp@in.com

It's as simple as that but hurry up before they fix it.

Service-Oriented Organization/Staffing

Increased focus on maintenance, modularity and components decoupling encouraged birth of new design patterns and design paradigms. After Object-Oriented Methodology being adopted as defacto in most of the part of software industry, focus on component decoupling increased, eventually giving birth to the revolutionary concept of "Service-Oriented Architecture".

Service-Oriented Architecture provided new dimensions to component-decoupling, distributed-computation and distributed-development. Architecture provided a simpler way to neatly draw those blocks in a software design diagram and cleanly connect them with a single-line. Two or more components interact with crystal-clear interface making them perfectly decoupled and implementation-independent.

So far so good. Now let's get a little more pragmatic and look deep into application in current software development scenario. Say, in a large software system, Service-Oriented Architecture is implemented and two subsystems, say Service1 and Service2, are decoupled as components providing services to each other. Services are exposed for each subsystem by a common development team.

The development team managing both the subsystems has detailed knowledge of internal implementation of these subsystems; and this is one factor that could prove to be the biggest disadvantage to the original architecture.

Suppose, Service1's function someoperation() is exposed as a service and it needs to update a database value, which actually belongs to Subsystem2. This should ideally be done by -

• Service2 exposes function to update the database field
• Service1 invokes this function of Service2 to update the field value

Unfortunately, this is not a perfect world. Development team might intend to deviate because of the triviality of the operation and rather more effort involved in exposing (and invoking) a function as simple as a getter or setter. Consequently, this may lead to chaos in an architecture that was intended to be Service-Oriented.

Ideally, these scenarios should never have happened. Practically, they do; more often than not.

To overcome these one would suggest to focus more on the guidelines, strict reviews or what not. But very source of the problem cannot be ignored - access, knowledge and co-existence of subsystems. I would suggest a solution that follows: Service-Oriented Staffing.

Service-Oriented Staffing

Either it's Service-Oriented architecture or not, software development teams could be organized in a service-oriented fashion by providing services (corresponding to business function of the software) to one another. The system areas can be restricted to each team and teams communicate on a strict protocol basis. This would give distinctive advantage in terms of adhering to strict architecture or design because:

• Teams cannot access other subsystems' data without invoking a service
• Teams cannot "directly" perform a business function that was intended to be performed by another service
• Because they are different teams (at least logically), they can sit together and finalize on the type of operations that must be exposed

Because every single access of another subsystem required goes through a strict process of deciding on service functions to be exposed, it could become highly impossible to deviate from the intended architecture.

Teams could prove to be more independent in their functional area and probably achieving an expertise much faster than in a common-team project.

Application to any architecture

Although, it sounds that Service-Oriented Staffing can be applied only to the software systems that follow Service-Oriented Architecture(SOA, it's not the case though. One could organize development teams in a service-oriented fashion by aligning their business functions and then dividing the system's area among components/teams. However, it would almost be impossible if the business functions in a software system cannot be logically grouped together. Steps below describe how a non SOA system could follow Service-Oriented Staffing and get the benefits of decoupling:

• Group together the business functions of the software system. More than one group must be identified.
• Carefully divide the data (database and files) among these groups
• Staff/Organize the team into these groups
• Improve these groups by inducting more functions to remove inter-dependencies
• Restrict the inter-group direct accesses

The whole process could either be made slow by first getting prepared for Service-Oriented Staffing, or Staffing could be rolled out in one-go and then stabilizing the system slowly. Both approaches would have balanced trade-offs though.

SOA is just not a software design tool, but has much more in store for the interested ones!

Design & Architecture - restrictive world?

The post "C" era surely changed the way a software analyst approaches a problem - the Object-Oriented way. Object-oriented paradigm came as a big reprieve to the then ever-growing C community and a much awaited shift and focus on maintainability of code. And then the software industry started its ever-lasting bond with the words "design" and "architecture", which by then were more popular in other engineer streams including electronics/computer hardware.

The essence of good designs being Information-hiding, it has been advocated as the most popular and compulsory tool to build good designs. Therefore, nobody may even imagine to counter the obvious information-hiding paradigm.
Undoubtedly, information-hiding is a wonderful way to create software that are maintainable and encourage concurrent developments in large teams, off-late the thrust on information hiding has been so much so that it creates an impression of negativitism, restrictive world - an overuse of a wonderful design tool. And, as many(not most) modern architectures adapting the hyper-hiding techniques, the poor programmer might end-up either violating the architecture by silent tinkering or come up with a side-design that doesn't seem to violate the architecture and looks like a parallel to the original one but honestly a work around to the hiding-problem.

The benefits and wonderful usages of information-hiding has been cited in thousands of published papers and books and it's clearly a revolutionary tool that has benefited the industry. At the same time, it's the overuse that is the villain and leads to deliberate architecture tinkering and spoiling whole concept of software design - contrary to original intention. But why one has to tinker with a supposedly good design? Possible reasons can be-

1. Performance
This should be the single largest factor to influence tight-designs. The problem begins when the architecture doesn't provide a faster way of interaction among software components while there does exist one.

For example, if an architecture doesn't allow interaction other than in XML format while the use of binary media at the same time doesn't pose any security threat (if, say, components are physically on the same machine. This kind of adventures are though more common in the performance intensive Online Transaction Systems.
The solution lies in designing interactions carefully and not getting carried away by a particular industry trend (afterall industry is what is competing with you!). Second, keep your options open for interface changes in your design. (Unfortunately, most modern frameworks are taking XML as de-facto without giving a second thought).

2. Too-tied-up
If a system is designed in too much of over-enthusiasm about information hiding and providing strict interfaces, it's more often than not that either it will lead to large design-violations or the coding team will invest sufficient amount of effort in struggling with finding an workaround to access hidden information by hopping up the interfaces - upcasting, downcasting, RTTI and what not!
The solution lies in identifying the information to be hidden carefully and not negatively. Most designs are based on fundamental "hide whatever is not required". Well, it should be "make accessible if it doesn't harm".


A good design is not necessarily restrictive and it shouldn't be. One of the by-products of restrictive design is that the programmers doesn't grow by time becoming true programmers and then architects but may end-up being just the developers. It would then be much more difficult to explain or justify a good design/architecture and possibly to sell the idea of architecture in software - forward to the past!

So, let it be a free world - and not so free that it becomes a crime!