 |
 |
 |
| ||||||||
| ||||||||
 |
-- ITCertificationNews is an iEntry, Inc. publication -- |
 | Unsubscribe from ITCertificationNews. To unsubscribe from ITCertificationNews or any other iEntry publication, simply send an email request to: support@ientry.com |
Clipperz's Zero-Knowledge Web Application  By Savio RodriguesI previously wrote about Clipperz because I really think Marco and team at Clipperz have a great idea. To summarize, Clipperz has technology for "zero-knowledge web applications" which they have applied to an online password manager as a proof of concept. Marco writes: "We simply meant that Clipperz knows nothing about its users and their data! As a consequence of the "learn nothing" mantra, every zero-knowledge application should be completely anonymous, or at least it should make it impossible to relate the real name or email of a user to his data" It seems that Richard Stallman agrees that Clipperz technology could be very useful in the cloud-based computing world that awaits us. The guys at Clipperz and RMS have been talking about how Clipperz's technology could provide freedom and privacy in the cloud. To that end, they suggest (summarized from here): • Choose AGPL: If your services are based on software with an AGPL license, you have to make the source code available to anyone that uses the service • Add zero-knowledge sauce: The server hosting the web app could know nothing of its users, not even their usernames • Build a smarter brower: We still need to provide users of web apps with an even more flexible and secure environment. To expand on #3, Marco writes: "Stallman suggests adding a feature to the browser allowing a user to say: "When you get URL X, use the Javascript from URL Y as if it came from URL X." If the user does invoke this feature, he can run his copy of the Javascript and still being able to exchange data with the server hosting the web application. A browser with such capabilities could also easily verify if the Javascript from URL X is different from the alternative Javascript stored at URL Y. If the user trusts the present release of the Javascript code from URL X, he could make a copy of it at URL Y and be alerted if any change occurs. This solution protects the user from malicious code that could be unknowingly executed by his browser, stealing his data and destroying the whole zero-knowledge architecture " Personally, I think #2 and #3 are great ideas. I'm having trouble with #1, the AGPL requirement. From an academic standpoint, I can agree with it. But if we're asking Google, Amazon, Microsoft, IBM, Sun, HP, etc. to use AGPL'd code, it could become an uphill battle. Using the AGPL'd widget (from Clipperz in this case) that enables a "zero knowledge web application" is not the problem. However, the viral nature of the AGPL would be a concern for any vendor who intends to drive revenue from their proprietary code/application delivered via a SaaS from a Cloud. I guess that these vendors could always license the Clipperz technology... |
! |
 |
 |
| 06.11.08 Developing Your Site's Search Engine  By Mike MoranI'm old enough to remember when fathers and sons thought nothing of overhauling their own car engines-back before cars became little IT shops that need specialized equipment to repair. As a certified girly-man, I cringe at even the thought of overhauling an engine, but I do know how to overhaul your site search engine. (You won't even get dirt under your fingernails.) Search engines are complicated, which means that one size does not fit all. You need to be ready to customize the way your search engine operates so that it best fits your business and your customers. Each search engine provides different dials to turn and levers to pull, but here are some of the most important: • Default Boolean operator. We'll forgive you if your first reaction is, "What the heck is a default Boolean operator?" Don't be intimidated by the terminology-the name refers to how the search engine treats multi-word queries. If a searchers enters digital cameras, does the search engine look for pages containing both "digital" AND "cameras"? Or pages containing either "digital" OR "cameras"? It's your search facility, so you get to decide. Defaulting to AND usually provides more precise results, but also more "not founds."
• Rank-factor boosting. Search engines use myriad factors to rank search results. When it's your site search engine, those factors are under your control. Don't be afraid to tweak the weighting of your ranking factors and test the results. Most site search facilities benefit from customizing ranking factors for improved relevance. • Linguistic and synonym dictionaries. To improve recall, you can request that your search engine expand its matching to include linguistic variants and synonyms of the keywords the searcher uses. Sometimes this kind of expansion can produce spurious results, but you can customize the dictionaries so that only the most helpful related terms are used. • Country and language filters. If your Web site sells to people of multiple countries or languages, you need to ensure that your search results are limited to the country/language combination they expect. Your conversion rates will skyrocket if you properly filter the right country results for the right person. Expect your search engine to need some customization to provide optimal results. Now you at least know the basics to pay attention to. Comments About the Author: Copyright Mike Moran Mike Moran is an IBM Distinguished Engineer, expert on Internet marketing, and the author of Search Engine Marketing, Inc., the best-selling book on search marketing. Mike also writes the popular Biznology newsletter and blog. | |||||||
| | ||||||||||||||||
-- DevWebProUK is an iEntry, Inc. publication -- iEntry, Inc. 2549 Richmond Rd. Lexington KY, 40509 2008 iEntry, Inc. All Rights Reserved Privacy Policy Legal
|
 | Unsubscribe from DevWebProUK. To unsubscribe from DevWebProUK or any other iEntry publication, simply send an email request to: support@ientry.com |
!  |
 |
| 06.10.08 How To Monitor Customer Satisfaction  By Craig Borysowich To monitor how well a customer's expectations for quality service delivery are being met. Method Conduct periodic surveys of customer satisfaction levels. See also: Measuring Customer Satisfaction Use group process techniques to involve senior members of the project team in reviewing the findings of such surveys, identifying opportunities for improvement, and updating the project strategies and plans, as appropriate. As well, solicit input from project team members, who can often be the most help in finding solutions to any problems identified. See also: Develop Strategies and Plans Formally record and manage the action items that result from customer satisfaction surveys and track them through to closure. See also: Manage Action Items GUIDELINES FOR A CUSTOMER SATISFACTION SURVEY Define what you want the survey to accomplish. Typically this should be to measure the gap between a customer's expectations and his/her perceptions of the level of service being provided. Keep it simple and focus on the essential information - there is no guarantee that a complex approach will give you any more useful information. Focus on factors such as the following, which are generally recognized as areas of customer concern: • understanding the customer: the degree to which we know the customer and understand his or her needs, • technical competence: the degree to which we possess the required skills and knowledge to perform the service required, • reliability: the degree to which we perform as promised, dependably and accurately, • credibility: the degree to which we are perceived as trustworthy, believable, and accountable, • responsiveness: the degree to which we are willing and able to respond to problems and issues, • communication: the degree to which we listen to the customer, keep the customer informed, and support the customer through effective presentations, • courtesy: the level of politeness, respect, and friendliness of our people.
Make the survey form simple to complete. Make sure that the time required to complete the survey is not more than 10 minutes. Explain the objective of the survey, what the results will be used for, and that the individual responses will be kept confidential. Start with simple questions (as you would in an interview) to develop a profile of the respondent and the extent of their involvement with the IS organization. Where appropriate, use a simple scale for responses, such as the following: • Poor • Satisfactory • Good • Very Good • Excellent With this kind of scale, a reasonable target might be to achieve higher than 90 percent of very good or excellent ratings. Include space for comments and prompt respondents to provide comments with a suitable leading question. Probe for further information when respondents are dissatisfied (for example, "If you were not satisfied, what was your expectation and to what extent was this not met?"). Take into consideration the fact that some expectations may be unrealistic. For example, many customers may not agree with the change request process which protects the IS organization against uncontrolled scope change. In these cases, consider focusing on specific elements. For example: • To what extent was the change control process explained at project start-up? • To what extent did the IS organization work with you to find mutually acceptable ways to accommodate controlled changes (for example by substituting functionality without increasing the overall scope)? Pretest the survey questionnaire with a small number of representative customer contacts, and refine it as necessary. Measure customer satisfaction regularly and keep track of the changes over time. Comments
| |||||||||||||
| | ||||||||||||||||
| -- EnterpriseCustomer is an iEntry, Inc. publication -- |
 | Unsubscribe from EnterpriseCustomer. To unsubscribe from EnterpriseCustomer or any other iEntry publication, simply send an email request to: support@ientry.com |
!| |
| |
|
| 06.05.08 Some Difference Between Front-end And Back-end Developers  By Mads Kristensen Jakob asked me a question this evening: What is the difference between front-end and back-end developers? Not long after I was on my way home and couldn't stop thinking about it. I've never thought much about it before, yet I am convinced there is a difference. Also, I have a feeling that there must be a different answer for each developer in the world. Let's start by looking at some stereotypical differences. Front-end devs don't unit test whereas back-end devs take pride in their unit tests and test environment. In my experience this is definitely true. Front-end code is very difficult to test and those tests are even worse to maintain. It's a fulltime job. However, you have always been able to separate most logic from code-behind files and other classes into libraries that are testable. Maybe front-end devs just don't care as much about testability or are they more realistic in how they spend their time? Back-end devs are more low-level Threading and memory pointers are not interesting for most front-end developer. Back-end devs on the other hand knows all about it and how to utilize it to create scalable solutions. Front-end devs don't like operating on such a low level of abstraction and feels the platform should take care of it, so they don't have to. Otherwise you'll never get anything done. Some are extraordinary productive on a low level and some are equally productive but higher on the stack. Does this separate front-end from back-end devs?
Front-end devs make more mistakes Back-end devs don't just jump into development, but thoroughly sketch out every detail to avoid unforeseen scenarios. Front-end devs do just the opposite - they need to create and they need their endorphins fast. I've heard this many times before and I don't agree. There are just as many ugly pitfalls by rushing development in the front-end as in the back-end and front-end devs knows this. Still, they need their fast track to the endorphins, but does it collide with the quality? Back-end devs hates the client-side If there is one thing back-end devs hate more than Cirque du Soleil, it's JavaScript, stylesheets and HTML. Valid XHTML only makes sense to back-end devs if they have to parse it as XML. Front-end devs spend hours on end to perfect every pixel and even longer to validate their stylesheet and XHTML even though the average user wouldn't notice. Say cross-browser to a back-end dev and he shakes his head at the stupidity thinking that you could just have made a table design and there wouldn't be any problems. Is this a way of thinking about quality? A likely answer When I was hired by ZYB, my boss Ole Kristensen asked me if I considered myself as a front-end or a back-end developer. I answered that I thought of myself as a back-end dev but my heart was in the front-end. Maybe the answer has nothing to do with technicalities but is as simple as what you love the most. Comments About the Author: Mads Kristensen currently works as a Senior Developer at Traceworks located in Copenhagen, Denmark. Mads graduated from Copenhagen Technical Academy with a multimedia degree in 2003, but has been a professional developer since 2000. His main focus is on ASP.NET but is responsible for Winforms, Windows- and web services in his daily work as well. A true .NET developer with great passion for the simple solution. | ||||||||
| | ||||||||||||||||
| -- DevWebProUK is an iEntry, Inc. publication -- iEntry, Inc. 2549 Richmond Rd. Lexington KY, 40509 2008 iEntry, Inc. All Rights Reserved Privacy Policy Legal
|
| | Unsubscribe from DevWebProUK. To unsubscribe from DevWebProUK or any other iEntry publication, simply send an email request to: support@ientry.com |
By Dan Morrill 
