Building Web Reputation Systems- P18

Building Web Reputation Systems- P18:Today’s Web is the product of over a billion hands and minds. Around the clock andaround the globe, people are pumping out contributions small and large: full-lengthfeatures on Vimeo, video shorts on YouTube, comments on Blogger, discussions onYahoo! Groups, and tagged-and-titled Del.icio.us bookmarks. User-generated contentand robust crowd participation have become the hallmarks of Web 2.0.
Nội dung trích xuất từ tài liệu:
Building Web Reputation Systems- P18Putting It All TogetherWe’ve helped you identify all of the reputation features for an application: the goals,objects, scope, inputs, outputs, processes, and the sorts filters. You’re armed with arough reputation model diagram and design patterns for displaying and using yourreputation scores. These make up your reputation product requirements. In Chap-ter 9, we describe how to turn these plans into action: building and testing the model,integrating with your application, and performing the early reputation model turning. Putting It All Together | 221 CHAPTER 9 Application Integration, Testing, and TuningIf you’ve been following the steps provided in Chapters 5 through 8, you know yourgoals; have a diagram of your reputation model with initial calculations formulated;and have a handful of screen mock-ups showing how you will gather, display, andotherwise use reputation to increase the value of your application. You have ideas andplans, so now it is time to reduce it all to code and to start seeing how it all workstogether.Integrating with Your ApplicationA reputation system does not exist in a vacuum; it is small machine in your largerapplication. There are a bunch of fine-grained connections between it and your variousdata sources, such as logs, event streams, identity db, entity db, and your high-performance data store. Connecting it will most likely require custom programming toconnect the wires between your reputation engine and subsystems that were neverconnected before.This step is often overlooked in scheduling, but it may take up a significant amount ofyour total project development time. There are usually small tuning adjustments thatare required once the inputs are actually hooked up in a release environment. Thischapter will help you understand how to plan for connecting the reputation engine toyour application and what final decisions you will need to make about your reputationmodel.Implementing Your Reputation ModelThe heart of your new reputation-infused application is the reputation model. It’s thatimportant. For the sake of clarity, we refer to the software engineers that turn yourmodel into operational code as the reputation implementation team and those who are 223going to connect the application input and output as the application team. In manycontexts, there are some advantages to these being the same people, but consider thatreputation, especially shared reputation, is so valuable to your entire product line thatit might be worth having a small dedicated team for the implementation, testing, andtuning full time. Engage Engineering Early and Often One of the hard-learned lessons of deploying reputation systems at Yahoo! is the en- gineering team needs to be involved at every major milestone during the design process. Even if you have a separate reputation implementation team to build and code the model, the gathering of all the inputs and integrating the outputs is significant new work added to their already overtaxed schedule. As the result of reputation, the very nature of your application is about to change sig- nificantly, and those on the engineering team are the ones who will turn all of this wonderful theory and the lovely screen mock-ups into code. Reputation is going to touch code all over the place. Besides, who knows your reputable entities better than the application team? It builds the software that gives your entities meaning. Engaging these key stakeholders early allows them to contribute to the model design and prepares them for the nature of the coming changes. Don’t wait to share details about the reputation model design process until after screen mocks are distributed to engineering for scheduling estimates. There’s too much hap- pening on the reputation backend that isn’t represented in those images.Appendix A contains a deeper technical-architecture-oriented look at how to definethe reputation framework: the software environment for executing your reputationmodel. Any plan to implement your model will require significant software engineering,so sharing that resource with the team is essential. Reviewing the framework require-ments will lead to many questions from the implementation team about specific trade-offs related to issues such as scalability, reliability, and shared data. The answers willput constraints on your development schedule and the application’s capabilities. Onelesson is worth repeating here: the process boxes in the reputation model diagram area notational convenience and advis ...