Apr 29, 2010
Nov 22, 2009
Aug 29, 2008
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 email@example.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 firstname.lastname@example.org
It's as simple as that but hurry up before they fix it.
Nov 17, 2006
- Service2 exposes function to update the database field
- Service1 invokes this function of Service2 to update the field value
- 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!
Oct 14, 2006
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-
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.
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).
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!