The 1.0.1 release of the open-source SubEtha mailing list manager is now available. Deployed on JBoss, SubEtha offers virtual domains, multiple email addresses per user, attachments kept on the server, pluggable mail processing filters, per-list role-based permissions, and more.
SubEtha's features include:
Very easy installation on Windows and Unix platforms
A user-friendly web interface for all configuration management
Virtual domains (ie list@foo.com and list@bar.com are separate lists)
Users can have multiple email addresses and self-moderate messages from unknown addresses
Intelligent attachment handling; attachments can be removed from delivered mail and replaced with a download link to the archives
Pluggable, configurable message processing filters which can arbitrarily modify the inbound and outbound message streams. Example filters include attachment stripping, header munging, spam detection, and insertion of advertising
Per-list role-based permissions
One-step creation of basic list types (ie "Announce-Only List" or "Technical Support List"). The set of available types is pluggable.
Searchable, threaded archives
Users can reply to messages from the archives. They can click on a button and have the message resent to them normally.
Intelligent VERP bounce processing
Clusterable for nearly unlimited scalability
Easy integration with any mail transport agent (MTA)
EJB and SOAP interfaces for automation
International characters in emails are properly passed through the system and rendered in the web interface
RESTful, bookmarkable URLs
A modular SMTP library that can be used outside SubEtha - see SubEthaSMTP
SubEtha is a three-tiered J2EE application using EJB3 and JMS. It is designed to deploy on JBoss and relies on numerous other open source projects including Hibernate, Velocity, Tagonist, and Lucene. The code is well-commented and designed to provide a tutorial of:
Building a three-tiered middleware application using JBoss and EJB3
A variety of entity relationships using Hibernate
Using the Hibernate 2nd-level cache to nearly eliminate database hits
Creating and using a Hibernate custom type
Using JBoss Service POJOs
Using JBoss Message-Driven POJOs
Securing an application using J2EE security
Integrating with JBoss JAAS-based security system
Full text indexing using Lucene
Using the world's simplest web framework, Tagonist (also described as a "laughably simple web framework")
Validating HTML form inputs with Hibernate Validation
Zero-effort form processing with the Propertizer
Unit testing EJB systems with JUnit
Threaded replies
· SubEtha 1.0.1 (Java EE mailing list manager) released by Jon Stevens on Mon Apr 16 06:22:06 EDT 2007
· Great :) by Gavin King on Mon Apr 16 20:02:17 EDT 2007
· thanks! by Jon Stevens on Tue Apr 17 02:14:15 EDT 2007
· Re: Great :) by Jan de Jonge on Tue Apr 17 06:07:10 EDT 2007
· Re: Great :) by Gavin King on Fri Apr 20 12:08:03 EDT 2007
· no kidding! by Jon Stevens on Wed Apr 25 12:01:33 EDT 2007
· Re: Great :) by Raul Garcia on Tue Apr 17 07:40:30 EDT 2007
· Re: Great :) by code flunki on Thu Apr 19 06:22:58 EDT 2007
2007年5月17日星期四
Agile Offshoring : It's hard work but it works!
Agile Offshoring : It's hard work but it works!
Software Off-shoring is a reality of the day however there are many projects which fail due to incorrect off-shoring. Apart from tremendous advantages, off-shoring brings additional complexity, risk and avenues for wastage. This experience report will discuss how we turned off-shoring into a successful model based on Toyota manufacturing Process. We call this methodology 'Lean Agile Off-
shoring.'
Our goal to go offshore was to deliver software faster by leveraging a vast talent pool at offshore location with higher efficiency. We chose Scrum and the Toyota way of working because of its strong foundation in successful new product development. The Toyota principles can be very well applied to any software development project. The underlying points discuss the Toyota way of working and how they were mapped to make our off-shoring process lean.
The overall methodology remained Scrum and Toyota way of working helped us to look at improving on a daily basis.
The project on which we applied this methodology is a batch processing system for a central social security organization. Our system processes relevant incoming data employer and employee data from the Income Tax department, validates this data and creates income declarations for a person for a period. The system handles 16 million records per month with the throughput of 50 records per second.
Principle 1: Define a long term philosophy and stick to it
We started out with the project off-shoring with one thought in mind that we are going to work on this not like a one project task but we are going to base all our actions on a long term vision to be the best agile company with a stable and repeatable off-shoring model. It should be a model from which the software community can benefit as a whole. We would not take any shortcuts that defy or compromise quality for the project.
We would actively invent and refine the way to work so as to improve the success rate of the way agile projects are off-shored across the industry.
Principle 2: Create connected, continuous process flow to bring problems to the surface
We decided to be agile in all our actions and follow no plan driven methodologies. However it is easy to lose way without a plan, this is where continuous communication and integration play a vital role.
We followed a model of regular sending of ambassadors from one site to the other, making the business context travel across geographies, building trust, gelling across the wire and mentoring.
Communication was also facilitated by having 'always on' communication machines across geographies. Talking to the team across the geography was a matter of picking up the mike and talking.
For project work we had single code base for multi site development with continuous integration so that problems would surface out quickly and would be taken care of immediately.
Principle 3: Using pull systems to avoid overproduction
Taking hint from the above principle we decided not to produce everything based on push but on the basis of stakeholders pull. After all we are not writing lines of code to increase our code base but the whole intent is to add business value with every line that we write. We reduced the size of the iteration if the pull was not strong enough or else used time to refactor, improve the quality of process and deliverables thus achieving success in making sure that we produced what the customers want, when they want it, with the best quality.
Principle 4: Leveling burden (heijunka)
Toyota talks about reducing muda (waste), muri (overburdening people) and mura (unevenness).
Keeping in mind the above 3 the biggest wastages in an off-shored project are in terms of extra features, more detailed than required requirements, extra layers of abstraction between the team and the customer, finding relevant information, defects not caught by tests, inefficient hand-off to the customer.
We took care of eliminating waste by developing only for todays stories, using story cards which were detailed only for the current iteration and had just enough information, coded directly from the stories and for clarification even the offshore team could always be in touch with the customer, test first both developer and customer tests. For leveling of work we always worked according to the team velocity and made sure that there were no uneven trends in the amount of user stories completed. There is nothing more harmful in a software project than burnt out team members. Teams velocity plays a very important role in deciding who does what and how much we do as a team.
Principle 5: Build a culture that stops to fix problems (jidoka)
We promoted a culture to stop work if there is a problem that can affect the quality of the deliverable.
If the offshore-onsite team felt that they could not communicate effectively we installed an 'always on' communications machine with always-on skype voice and video channel.
Once the team felt that our sprint evaluation was not being effective and we were not getting what we desired, we called off the evaluation, brainstormed on how we can do it better, had an improved kickoff in which we reduced the time spent on the reviews and followed an agenda to guide us through.
If there was an issue with our continuous integration or performance testing environment then we fixed that first before going further with developing stories.
If we developed enough stories but the functionality testers did not have time to test them then we stopped developing more stories till the testing team was comfortable with what we had done so far.
All this not only helped us by using counter measures but we were also able to error proof future situations.
Principle 6: standardized processes and procedures
Standardization is the basis for continuous improvement, empowered employees, rules and procedures as enabling tools, and a hierarchy that supports organizational learning.
We created standardized processes for the way to do development using TDD, issue tracking and resolution process, build generation and testing process. This is not to say that these processes were frozen in time, they were as alive and agile as our project but having some standards ensured that we started on a stable platform which can be improved further by the team.
Principle 7: Use visual control so that none of the problems are hidden
Our motto, everything should be visible to everyone on the team and yes this includes the client.
We created a common product backlog for onsite and offshore team in Jira, created a common burn down chart and issue log which was available for the client to report production issues and even look into our daily status. Cruise control would visually report the status of a build with every check-in and a build bunny would announce the success or failure of a build.
The physical and virtual walls and white boards had enough visual information for any stakeholder to walk to the wall and white board and get the information about the project in a matter of 10 minutes.
We decided to keep all visual information on our virtual team boards which were created on a wiki and then print out the relevant ones to paste on team walls.
Principle 8: tailor technology to fit people and processes
The truly lean project has two key features.
It transfers the maximum number of tasks and responsibilities to developers actually adding value to the product, and has a process for tracing defects and working on them as soon as they occur.
People is the greatest asset of an agile team, we want the team to change and tailor technology to suit their needs best rather than technology dictating how things should be done. In one example we moved our entire presentation logic from Struts to Spring MVC because it made more sense in the present context and the team as a whole took a decision to make the change. The best decisions and commitments came from a team when they took the decision on their own. The self organizing team knew best how to tailor technology and processes to work in the best interest of everyone.
Principle 9: Develop leaders from within the team
It is a well-known concept machinery depreciates and people appreciate.
We were committed to develop leaders in our offshore project from within the team. Instead of bringing scrum masters from elsewhere we sent some people from onsite and offshore teams for scrum master training and needless to say that these are the people who know the teams best.
Principle 10: Develop exceptional team associates
Unhindered communication, effective teamwork, form vs function of teams, good pay, the best facilities, a safe working environment, a work balanced life, continuous improvement, job rotation.
All these when followed in the right spirit can create star teams.
Healthy communication within different geographies is a core for efficient teams. For this we had a lot of seeding visits early the in the project intended to create the relationships, and regular visits to maintain the relationships. Of course the idea of these visits was not to get work done but to get healthy relationships going between geographies.
People are often discouraged from asking questions, talking about problems, warning about unfeasible deadlines, or proposing alternatives to perceived instructions from superiors. Though getting teams to be more pro-active is an uphill battle, and one that inevitably takes a lot of time.
However we actively promoted a culture of asking a lot of questions and highlighting issues. Once people realize they have the freedom, and the responsibility, of making decisions - they further contribute to becoming an exceptional associate.
Principle 11: Develop partners and suppliers as extension of the enterprise
Fair and honorable business relations is the key to have long term working relationships with the partners and suppliers.
We tried to follow this in spirit by exposing the wiki and Jira to customer and other software vendors who were working on different modules of the same project. This have full visibility into who is doing what, we could set clear expectations with all the stakeholders and vendors. The advantage, we built a huge wealth of trust and transparency, we had nothing to hide.
This not only gave a lot of credibility to our offshore process as a whole but actively helped in our long term mission to take the best practices to the software community by involving a bigger group of partners. Our partners learned from our burn down charts and Sprint signatures and we learned from theirs.
Principle 12: Go and see for yourself
There is nothing like being in the trenches to get the real feel of the situation, hence we had no lip service designers and architects on the team, everyone had to code and code well apart from any other role that they were playing. Period.
This helped us bringing about the attributes of clearly assign tasks to yourself and other people, speak on basis of well verified data, consult experts, analyze and understand situations and their solutions.
Principle 13: Evaluate alternatives while looking for consensus and implement them fast
We actively followed a policy of not picking a single direction and going down that one path until we had thoroughly considered alternatives. Once we picked the right path, we moved quickly and continuously down the path.
At several instances we tried to find alternatives to various issues like how to get Dutch documents across to the offshore team - should we manually translate them? Should we use a tool, since a tool would get us 60% there? Finally we decided that the Dutch team would make Jira issues out of relevant documents and then the offshore team would study the issues and ask questions on that. This approach went well and quickly with the team.
Principle 14: Become a learning organization through relentless reflection ( Hansei ) and continuous improvement (kaizen)
This is the most important principle which has helped us reach where we are today, we do rigorous iteration evaluations for reflections of good things to preserve and areas of improvement to help us improve iteration on iteration.
We solicit constant and immediate client and team feedback so that the ultimate aim of the software is realized in an effective and efficient way.
Apart from this we made it a point to get to the root cause of any problem that we came across by asking “why” 5 times.
Conclusion
To conclude I would say that we are still learning. The lean production metaphor has been successfully applied to software offshoring but it can be improved. The Toyota principles when applied to software offshoring can make remarkable differences to the way software is being developed and offshored. We are trying to continuously improve and reach our goal of 'Whitebox Lean Agile Offshoring' in which transparency and quality are taken to the extreme.
As an advice for the offshoring industry, follow Scrum with the Toyota principles in spirit without diluting their essence. Apply them to your way of working and see the magic unfold.
Threaded replies
· Agile Offshoring : It's hard work but it works! by Vikas Hazrati on Fri May 11 11:20:36 EDT 2007
· double negative by Jesse Kuhnert on Fri May 11 11:50:11 EDT 2007
· Find agile offshore team by Johnson Ma on Sun May 13 23:03:35 EDT 2007
· Too generic statement by Tariq Yaqub on Mon May 14 04:05:35 EDT 2007
· It is Neither Lean nor Agile by Irakli Nadareishvili on Mon May 14 09:01:24 EDT 2007
· Re: Agile Offshoring : It's hard work but it works! by Jin Chun on Fri May 11 11:52:10 EDT 2007
· Offshoring show me where it worked by vineet kalathil on Fri May 11 16:34:46 EDT 2007
· Re: Offshoring show me where it worked by bad mASH on Fri May 11 22:38:56 EDT 2007
· Re: Offshoring show me where it worked by Jesse Kuhnert on Sat May 12 00:11:21 EDT 2007
· Re: Offshoring show me where it worked by Vikas Hazrati on Sat May 12 03:01:51 EDT 2007
· Please check the link by vineet kalathil on Mon May 14 09:56:38 EDT 2007
· People are still offshoring? by Prodeep Ready on Fri May 11 19:14:04 EDT 2007
· Re: People are still offshoring? by Fyodor Kupolov on Sat May 12 04:21:14 EDT 2007
· Re: People are still offshoring? by Wille Faler on Sun May 13 09:16:38 EDT 2007
· Re: People are still offshoring? by Fyodor Kupolov on Sun May 13 15:43:41 EDT 2007
· myth of vast offshore talent by peter lin on Sun May 13 13:57:36 EDT 2007
· Re: myth of vast offshore talent by Anurag Shrivastava on Tue May 15 00:44:00 EDT 2007
· Re: Agile Offshoring : It's hard work but it works! by Vikrant Jain on Sun May 13 15:17:35 EDT 2007
· Re: Agile Offshoring : It's hard work but it works! by Tariq Yaqub on Mon May 14 04:08:33 EDT 2007
· Re: Agile Offshoring : It's hard work but it works! by Dave Rooney on Mon May 14 09:58:13 EDT 2007
· Toyota model won't work in IT by vineet kalathil on Mon May 14 10:01:18 EDT 2007
· Re: Toyota model won't work in IT by Dave Rooney on Mon May 14 10:18:30 EDT 2007
· Re: Toyota model won't work in IT by Anurag Shrivastava on Tue May 15 00:58:57 EDT 2007
· Re: Toyota model won't work in IT by Irakli Nadareishvili on Tue May 15 02:55:28 EDT 2007
· WAIT is not bad by vineet kalathil on Tue May 15 15:00:59 EDT 2007
· Re: Toyota model won't work in IT by Vikas Hazrati on Wed May 16 00:17:36 EDT 2007
· Agile offshoring : The challenges by Prabhakar Karve on Tue May 15 06:06:14 EDT 2007
· Re: Agile offshoring : The challenges by Vikas Hazrati on Wed May 16 00:01:51 EDT 2007
Software Off-shoring is a reality of the day however there are many projects which fail due to incorrect off-shoring. Apart from tremendous advantages, off-shoring brings additional complexity, risk and avenues for wastage. This experience report will discuss how we turned off-shoring into a successful model based on Toyota manufacturing Process. We call this methodology 'Lean Agile Off-
shoring.'
Our goal to go offshore was to deliver software faster by leveraging a vast talent pool at offshore location with higher efficiency. We chose Scrum and the Toyota way of working because of its strong foundation in successful new product development. The Toyota principles can be very well applied to any software development project. The underlying points discuss the Toyota way of working and how they were mapped to make our off-shoring process lean.
The overall methodology remained Scrum and Toyota way of working helped us to look at improving on a daily basis.
The project on which we applied this methodology is a batch processing system for a central social security organization. Our system processes relevant incoming data employer and employee data from the Income Tax department, validates this data and creates income declarations for a person for a period. The system handles 16 million records per month with the throughput of 50 records per second.
Principle 1: Define a long term philosophy and stick to it
We started out with the project off-shoring with one thought in mind that we are going to work on this not like a one project task but we are going to base all our actions on a long term vision to be the best agile company with a stable and repeatable off-shoring model. It should be a model from which the software community can benefit as a whole. We would not take any shortcuts that defy or compromise quality for the project.
We would actively invent and refine the way to work so as to improve the success rate of the way agile projects are off-shored across the industry.
Principle 2: Create connected, continuous process flow to bring problems to the surface
We decided to be agile in all our actions and follow no plan driven methodologies. However it is easy to lose way without a plan, this is where continuous communication and integration play a vital role.
We followed a model of regular sending of ambassadors from one site to the other, making the business context travel across geographies, building trust, gelling across the wire and mentoring.
Communication was also facilitated by having 'always on' communication machines across geographies. Talking to the team across the geography was a matter of picking up the mike and talking.
For project work we had single code base for multi site development with continuous integration so that problems would surface out quickly and would be taken care of immediately.
Principle 3: Using pull systems to avoid overproduction
Taking hint from the above principle we decided not to produce everything based on push but on the basis of stakeholders pull. After all we are not writing lines of code to increase our code base but the whole intent is to add business value with every line that we write. We reduced the size of the iteration if the pull was not strong enough or else used time to refactor, improve the quality of process and deliverables thus achieving success in making sure that we produced what the customers want, when they want it, with the best quality.
Principle 4: Leveling burden (heijunka)
Toyota talks about reducing muda (waste), muri (overburdening people) and mura (unevenness).
Keeping in mind the above 3 the biggest wastages in an off-shored project are in terms of extra features, more detailed than required requirements, extra layers of abstraction between the team and the customer, finding relevant information, defects not caught by tests, inefficient hand-off to the customer.
We took care of eliminating waste by developing only for todays stories, using story cards which were detailed only for the current iteration and had just enough information, coded directly from the stories and for clarification even the offshore team could always be in touch with the customer, test first both developer and customer tests. For leveling of work we always worked according to the team velocity and made sure that there were no uneven trends in the amount of user stories completed. There is nothing more harmful in a software project than burnt out team members. Teams velocity plays a very important role in deciding who does what and how much we do as a team.
Principle 5: Build a culture that stops to fix problems (jidoka)
We promoted a culture to stop work if there is a problem that can affect the quality of the deliverable.
If the offshore-onsite team felt that they could not communicate effectively we installed an 'always on' communications machine with always-on skype voice and video channel.
Once the team felt that our sprint evaluation was not being effective and we were not getting what we desired, we called off the evaluation, brainstormed on how we can do it better, had an improved kickoff in which we reduced the time spent on the reviews and followed an agenda to guide us through.
If there was an issue with our continuous integration or performance testing environment then we fixed that first before going further with developing stories.
If we developed enough stories but the functionality testers did not have time to test them then we stopped developing more stories till the testing team was comfortable with what we had done so far.
All this not only helped us by using counter measures but we were also able to error proof future situations.
Principle 6: standardized processes and procedures
Standardization is the basis for continuous improvement, empowered employees, rules and procedures as enabling tools, and a hierarchy that supports organizational learning.
We created standardized processes for the way to do development using TDD, issue tracking and resolution process, build generation and testing process. This is not to say that these processes were frozen in time, they were as alive and agile as our project but having some standards ensured that we started on a stable platform which can be improved further by the team.
Principle 7: Use visual control so that none of the problems are hidden
Our motto, everything should be visible to everyone on the team and yes this includes the client.
We created a common product backlog for onsite and offshore team in Jira, created a common burn down chart and issue log which was available for the client to report production issues and even look into our daily status. Cruise control would visually report the status of a build with every check-in and a build bunny would announce the success or failure of a build.
The physical and virtual walls and white boards had enough visual information for any stakeholder to walk to the wall and white board and get the information about the project in a matter of 10 minutes.
We decided to keep all visual information on our virtual team boards which were created on a wiki and then print out the relevant ones to paste on team walls.
Principle 8: tailor technology to fit people and processes
The truly lean project has two key features.
It transfers the maximum number of tasks and responsibilities to developers actually adding value to the product, and has a process for tracing defects and working on them as soon as they occur.
People is the greatest asset of an agile team, we want the team to change and tailor technology to suit their needs best rather than technology dictating how things should be done. In one example we moved our entire presentation logic from Struts to Spring MVC because it made more sense in the present context and the team as a whole took a decision to make the change. The best decisions and commitments came from a team when they took the decision on their own. The self organizing team knew best how to tailor technology and processes to work in the best interest of everyone.
Principle 9: Develop leaders from within the team
It is a well-known concept machinery depreciates and people appreciate.
We were committed to develop leaders in our offshore project from within the team. Instead of bringing scrum masters from elsewhere we sent some people from onsite and offshore teams for scrum master training and needless to say that these are the people who know the teams best.
Principle 10: Develop exceptional team associates
Unhindered communication, effective teamwork, form vs function of teams, good pay, the best facilities, a safe working environment, a work balanced life, continuous improvement, job rotation.
All these when followed in the right spirit can create star teams.
Healthy communication within different geographies is a core for efficient teams. For this we had a lot of seeding visits early the in the project intended to create the relationships, and regular visits to maintain the relationships. Of course the idea of these visits was not to get work done but to get healthy relationships going between geographies.
People are often discouraged from asking questions, talking about problems, warning about unfeasible deadlines, or proposing alternatives to perceived instructions from superiors. Though getting teams to be more pro-active is an uphill battle, and one that inevitably takes a lot of time.
However we actively promoted a culture of asking a lot of questions and highlighting issues. Once people realize they have the freedom, and the responsibility, of making decisions - they further contribute to becoming an exceptional associate.
Principle 11: Develop partners and suppliers as extension of the enterprise
Fair and honorable business relations is the key to have long term working relationships with the partners and suppliers.
We tried to follow this in spirit by exposing the wiki and Jira to customer and other software vendors who were working on different modules of the same project. This have full visibility into who is doing what, we could set clear expectations with all the stakeholders and vendors. The advantage, we built a huge wealth of trust and transparency, we had nothing to hide.
This not only gave a lot of credibility to our offshore process as a whole but actively helped in our long term mission to take the best practices to the software community by involving a bigger group of partners. Our partners learned from our burn down charts and Sprint signatures and we learned from theirs.
Principle 12: Go and see for yourself
There is nothing like being in the trenches to get the real feel of the situation, hence we had no lip service designers and architects on the team, everyone had to code and code well apart from any other role that they were playing. Period.
This helped us bringing about the attributes of clearly assign tasks to yourself and other people, speak on basis of well verified data, consult experts, analyze and understand situations and their solutions.
Principle 13: Evaluate alternatives while looking for consensus and implement them fast
We actively followed a policy of not picking a single direction and going down that one path until we had thoroughly considered alternatives. Once we picked the right path, we moved quickly and continuously down the path.
At several instances we tried to find alternatives to various issues like how to get Dutch documents across to the offshore team - should we manually translate them? Should we use a tool, since a tool would get us 60% there? Finally we decided that the Dutch team would make Jira issues out of relevant documents and then the offshore team would study the issues and ask questions on that. This approach went well and quickly with the team.
Principle 14: Become a learning organization through relentless reflection ( Hansei ) and continuous improvement (kaizen)
This is the most important principle which has helped us reach where we are today, we do rigorous iteration evaluations for reflections of good things to preserve and areas of improvement to help us improve iteration on iteration.
We solicit constant and immediate client and team feedback so that the ultimate aim of the software is realized in an effective and efficient way.
Apart from this we made it a point to get to the root cause of any problem that we came across by asking “why” 5 times.
Conclusion
To conclude I would say that we are still learning. The lean production metaphor has been successfully applied to software offshoring but it can be improved. The Toyota principles when applied to software offshoring can make remarkable differences to the way software is being developed and offshored. We are trying to continuously improve and reach our goal of 'Whitebox Lean Agile Offshoring' in which transparency and quality are taken to the extreme.
As an advice for the offshoring industry, follow Scrum with the Toyota principles in spirit without diluting their essence. Apply them to your way of working and see the magic unfold.
Threaded replies
· Agile Offshoring : It's hard work but it works! by Vikas Hazrati on Fri May 11 11:20:36 EDT 2007
· double negative by Jesse Kuhnert on Fri May 11 11:50:11 EDT 2007
· Find agile offshore team by Johnson Ma on Sun May 13 23:03:35 EDT 2007
· Too generic statement by Tariq Yaqub on Mon May 14 04:05:35 EDT 2007
· It is Neither Lean nor Agile by Irakli Nadareishvili on Mon May 14 09:01:24 EDT 2007
· Re: Agile Offshoring : It's hard work but it works! by Jin Chun on Fri May 11 11:52:10 EDT 2007
· Offshoring show me where it worked by vineet kalathil on Fri May 11 16:34:46 EDT 2007
· Re: Offshoring show me where it worked by bad mASH on Fri May 11 22:38:56 EDT 2007
· Re: Offshoring show me where it worked by Jesse Kuhnert on Sat May 12 00:11:21 EDT 2007
· Re: Offshoring show me where it worked by Vikas Hazrati on Sat May 12 03:01:51 EDT 2007
· Please check the link by vineet kalathil on Mon May 14 09:56:38 EDT 2007
· People are still offshoring? by Prodeep Ready on Fri May 11 19:14:04 EDT 2007
· Re: People are still offshoring? by Fyodor Kupolov on Sat May 12 04:21:14 EDT 2007
· Re: People are still offshoring? by Wille Faler on Sun May 13 09:16:38 EDT 2007
· Re: People are still offshoring? by Fyodor Kupolov on Sun May 13 15:43:41 EDT 2007
· myth of vast offshore talent by peter lin on Sun May 13 13:57:36 EDT 2007
· Re: myth of vast offshore talent by Anurag Shrivastava on Tue May 15 00:44:00 EDT 2007
· Re: Agile Offshoring : It's hard work but it works! by Vikrant Jain on Sun May 13 15:17:35 EDT 2007
· Re: Agile Offshoring : It's hard work but it works! by Tariq Yaqub on Mon May 14 04:08:33 EDT 2007
· Re: Agile Offshoring : It's hard work but it works! by Dave Rooney on Mon May 14 09:58:13 EDT 2007
· Toyota model won't work in IT by vineet kalathil on Mon May 14 10:01:18 EDT 2007
· Re: Toyota model won't work in IT by Dave Rooney on Mon May 14 10:18:30 EDT 2007
· Re: Toyota model won't work in IT by Anurag Shrivastava on Tue May 15 00:58:57 EDT 2007
· Re: Toyota model won't work in IT by Irakli Nadareishvili on Tue May 15 02:55:28 EDT 2007
· WAIT is not bad by vineet kalathil on Tue May 15 15:00:59 EDT 2007
· Re: Toyota model won't work in IT by Vikas Hazrati on Wed May 16 00:17:36 EDT 2007
· Agile offshoring : The challenges by Prabhakar Karve on Tue May 15 06:06:14 EDT 2007
· Re: Agile offshoring : The challenges by Vikas Hazrati on Wed May 16 00:01:51 EDT 2007
Design :: How to expose API for adding new object to a list
Hey,
I have a swt client and a stateless facade that expose the server API to the client.
Suppose that I have two objects - Company the contain list of workers
I want to write a generic API to the client that create,add,update,delete objects.
Some objects, like worker need to be created in a parent context.
I mean that in order to create new worker we need to have the company that the worker belongs.
So, I thought about the following API:
Object public createObj(parentId,parentType,obj);
The function will add the worker to the list of workers in company and will return the new Worker object (with the ID).
There are some issues here:
1. In order to save the new worker I need to get the workers list in company than add the new worker and save the company.
The problem is that in case that there are thousands of workers we will need to load all the workers for only save one worker.
2. hibernate required to save the company object in order to save the worker (there are OneToMany), so the persist return Company object but i want to return to the client the new Worker that has been created.
I don't want to run on all the thousands of workers in order to search this worker.
How you overcome the problem that I mention above?
Thank you
I have a swt client and a stateless facade that expose the server API to the client.
Suppose that I have two objects - Company the contain list of workers
I want to write a generic API to the client that create,add,update,delete objects.
Some objects, like worker need to be created in a parent context.
I mean that in order to create new worker we need to have the company that the worker belongs.
So, I thought about the following API:
Object public createObj(parentId,parentType,obj);
The function will add the worker to the list of workers in company and will return the new Worker object (with the ID).
There are some issues here:
1. In order to save the new worker I need to get the workers list in company than add the new worker and save the company.
The problem is that in case that there are thousands of workers we will need to load all the workers for only save one worker.
2. hibernate required to save the company object in order to save the worker (there are OneToMany), so the persist return Company object but i want to return to the client the new Worker that has been created.
I don't want to run on all the thousands of workers in order to search this worker.
How you overcome the problem that I mention above?
Thank you
Marc Fleury interviewed by BusinessWeek
JBoss founder Marc Fleury explains how his hot startup makes profits from its free application-server software to BusinessWeek in "The Myth of Open-Source."
Document literals in JWSDP 1.6
Arun Gupta has written up a blog mentioning his use of doc literal services in JWSDP 1.6 as opposed to RPC/ENC, in context of the Fast Infoset project on java.net.
Given that rpc/enc is the source of a lot of the concerns around web services in Java, his example is worth looking at, as many have suggested doc/literal as a way of "fixing" web services.
Given that rpc/enc is the source of a lot of the concerns around web services in Java, his example is worth looking at, as many have suggested doc/literal as a way of "fixing" web services.
Kirk Pepperdine: 'Use with care' label for refactoring tools
Kirk Pepperdine has noted in his blog that refactoring tools, although useful, can serve to hide flaws in implemented code. His point is that if you change a method name by hand and it introduces a lot of errors, you've got poor coupling - and refactoring tools hide that from you.
Messaging is the Right Way to Build a Distributed System
A message-based design is fundamentally the right way to think about building a distributed system, as opposed to code sharing, remote procedure calls, and the like. Eric Armstrong explains why.
Read Messaging is the Right Way to Build a Distributed System.
Threaded replies
· Messaging is the Right Way to Build a Distributed System by Floyd Marinescu on Tue Jul 26 16:00:35 EDT 2005
· Messaging is the Right Way to Build a Distributed System by Brian Miller on Tue Jul 26 17:14:28 EDT 2005
· Messaging is the Right Way to Build a Distributed System by Billy Newport on Wed Jul 27 17:40:01 EDT 2005
· Messaging is the Right Way to Build a Distributed System by Maarten Hazewinkel on Thu Jul 28 04:54:55 EDT 2005
· Pro's and Con's of Async by Steve Harris on Thu Jul 28 11:28:42 EDT 2005
· Messaging is the Right Way to Build a Distributed System by Billy Newport on Thu Jul 28 13:57:47 EDT 2005
· Messaging is the Right Way to Build a Distributed System by Cameron Purdy on Thu Jul 28 20:54:40 EDT 2005
· Messaging is the Right Way to Build a Distributed System by adrian osullivan on Wed Aug 03 05:45:42 EDT 2005
Read Messaging is the Right Way to Build a Distributed System.
Threaded replies
· Messaging is the Right Way to Build a Distributed System by Floyd Marinescu on Tue Jul 26 16:00:35 EDT 2005
· Messaging is the Right Way to Build a Distributed System by Brian Miller on Tue Jul 26 17:14:28 EDT 2005
· Messaging is the Right Way to Build a Distributed System by Billy Newport on Wed Jul 27 17:40:01 EDT 2005
· Messaging is the Right Way to Build a Distributed System by Maarten Hazewinkel on Thu Jul 28 04:54:55 EDT 2005
· Pro's and Con's of Async by Steve Harris on Thu Jul 28 11:28:42 EDT 2005
· Messaging is the Right Way to Build a Distributed System by Billy Newport on Thu Jul 28 13:57:47 EDT 2005
· Messaging is the Right Way to Build a Distributed System by Cameron Purdy on Thu Jul 28 20:54:40 EDT 2005
· Messaging is the Right Way to Build a Distributed System by adrian osullivan on Wed Aug 03 05:45:42 EDT 2005
订阅：
博文 (Atom)