I am Joannes Vermorel, founder at Lokad. I am also an engineer from the Corps des Mines who initially graduated from the ENS.

I have been passionate about computer science, software matters and data mining for almost two decades. (RSS - ATOM)


Entries in web (25)


From RAD to test driven ASP.NET website

Both unit testing and R.A.D. (Rapid Application Development) impacted quite deeply my insights over software development. Yet, I have found that combining those two approaches within a single ASP.NET project is not that easy especially if you want to keep the best of both worlds. There are at least א (alef zero) methods to get the problem solved. Since my blog host does not provide yet that much disk storage, I will only describe here 2.5 design patterns that I have found to be useful while developing ASP.NET websites.

  • R.A.D: all your 3-tier layers (presentation, business logic and data access) get compacted into a single ASPX page. ASP.Net 2.0 makes this approach very practical thanks to a combination of GridView, DetailsView and SqlDataSource.

  • CRUD layer: The business logic and the data access are still kept together but removed from the ASPX page itself. This design pattern (detailed below) replaces the SqlDataSource by a combination of ObjectDataSource and library classes.

  • Full blown 3-tier: Like, above but the business logic and the data access gets separated. Compared to the CRUD layer approach, you get extra classes reflecting the database objects.


Using combinations of GridView, DetailsView and SqlDataSource, you can fit your 3-layers a single ASPX page, the business logic being implemented in code-behind whenever required. This approach does not enable unit-testing but if your project is fairly simple, then R.A.D. works with a dramatic productivity. For example, has been completely developed through R.A.D (with a single method added to the Global.asax file that logs all thrown exceptions). I would maybe not defend R.A.D. for large/complex projects, but I do think its very well suited for small projects and/or drafting more complicated ones.

The forces behind R.A.D. :

  • (+) Super-fast feature delivery: a whole website can designed very quickly.

  • (+) The code is very readable (not kidding!): having your 3-layers in the same place makes the interactions quite simple to follow.

  • (+) Facilitate the trial & error web page design process: It's hard to get a web page very usable at once, R.A.D. let you re-organize web page very easily.

  • (-) If the same SQL tables get reused between ASPX pages, then data access code tends to be replicated each time (idem for business logic).

  • (-) No simple way to perform unit testing.

  • (-) No structured way to document your code.

"CRUD layer" design pattern

The main purpose of the "CRUD layer" is to remove the business logic and the data access from the ASPX page to push it into an isolated .Net library. Yet, there are several major constraints associated to this process. The first constraint is to ensure an easy migration from R.A.D. to "CRUD Layer". Indeed, R.A.D. is usually the best prototyping solution. Therefore the main issue is not to implement from scratch but to improve the quality of the R.A.D. draft implementation. The second constraint is to maintain business logic and data access design as plain as possible (verifying the YAGNI principle among others). The CRUD layer is an attempt to address those two issues.

The CRUD layer consists in implementing a class

public class FooCrudLayer
public FooCrudLayer() { ... } // empty constructor must exists
public DataTable GetAllBar( ... ) // SELECT method
DataTable table = new DataTable();

using (SqlConnection conn = new SqlConnection( ... ))
SqlCommand command = new SqlCommand( ... , conn);

using (SqlDataReader reader = command.ExecuteReader())

return table;

public void Insert( ... ) { ... } // INSERT method
public void Delete( ... ) { ... } // DELETE method
public void Update( ... ) { ... } // UPDATE method

Notice that the select method returns a DataTable whereas most ObjectDataSource tutorials would return a strongly-typed collection List<Bar>. The presented approach has two benefits. First, the migration from the SqlDataSource is totally transparent (including the sorting and paging capabilities of the GridView).

<ObjectDataSource Id="FooSource" runat="server"
UpdateMethod="Update" >

... (parameters definitions)


Second, database objects are not replicated in the .Net code. Indeed, replicating the database objects at the .Net level involves some design overhead because both sides (DB & .Net) must be kept synchronized.

The forces behind the CRUD layers

  • (+) Very small design overhead compared to R.A.D.

  • (+) Easy migration from R.A.D.

  • (+) Unit testable and documentable.

  • (-) No dedicated abstraction for business logic.

  • (-) Limited design scalability (because it's not always possible to avoid code replication).

Full blown 3-tiers

I won't say much about this last option (this post is already far too long), but basically, the 3-tier design involves to strong type the database objects in order to isolate business logic from data access. This approach comes as a large overhead compared from the original RAD approach. Yet, if your business logic gets complex (for example workflow-like processes) then there is no escape, layers have to be separated.


Over the Internet, your name is your personal trademark

I have been dealing with freelancers for various tasks (translations, graphists, development), and it's still unbelievable that most freelancers do not pay any attention to maintain a consistant name in their communications. Let me clarify this point: I do not care to know of the exact legal name of any freelancer I am dealing with. But how can I even recognize the person if messages never get signed twice with same name?

Over the Internet, your name is your personal trademark. If you're not careful, people will simply not remember who you are and this rule isn't restricted to freelancers. The most usual consequence over poor name branding is that people will filter out your communication attempts (email, intant messenger and the like) as spam. A clear naming policy means that your name must be explicited and obvious in all your communications ranging from Skype to regular postal mails.

In my experience, the most common inconsistant naming case are the following:

  • The e-mail must completely match the person name. If your name is John Smith then your email must be not or If you have a lengthy name so will be your e-mail address.

  • The Skype/MSN/Whatever username must completely match the person name too. I have found the instant messaging practices to be even worse. Fantasy names like batman4ever are not uncommon. A good practice is to use your e-mail as a instant messenger id.

  • Lack of personal home page: Google is the de facto yellow pages. When somebody type your name then he must get your home page. If your name is really John Smith then it's going to be tough. Well, in such case, just add some random nickname between the first and the last name to become distinguishable.

It may appear obvious to some of us, but it seems that many people do not realize that the lack of consistency in their communications does have a strong (negative) impact on the people they are communicating with, especially if the name is the only concrete reference to the person


Additional goodies from the blog spammers

An interesting thing about running a web application, it's that people never cease to surprise you. I have already discussed the behavior of the scammers within PeopleWords. Now, I am encountering a new kind of annoying people: the blog spammers.

Given that has no blog, there is no reason for blog spammers to get interested in Peoplewords, right?

Wrong, PeopleWords has no blog, but blog spammers don't care. What blog spammers are detecting is the link toward an XML feed.

<link rel="alternate" type="application/atom+xml"
title="PeopleWords, JobBot" href="AlertAtomFeed.aspx" />

This XML feed is not carrying blog posts, but PeopleWords translations jobs. As a side effect, the zombie army[*] commanded by spammers considers that any website providing an XML feed is a blog and therefore they try to fill up all the available forms with various crappy contents.

On PeopleWords, the only freely available form accessible without user registration is actually the user login form. As a consequence, I get a dozen blog spamming attempts everyday generating errors that are caught in the server logs.

[*] The PeopleWords server logs indicate that the blog spam attempts are coming from a large number of different IPs. This would indicate that the blog spammers are using a large amount of regular (but infested) machines over the internet.


Building a safe community for online translation works

This article focuses on the various issues related to online trust for freelance translation jobs and the various solutions adopted by freelance websites in this domain. As for all online activities, trust is a difficult yet critical element to obtain. My personal experience in this domain comes from the management of the PeopleWords website.

The naive approach: the rating system

Most freelance websites provide a rating system for all users (PeopleWords is no exception, see [1]). After each translation job, the customer can rate the translator and vice-versa. On the long run, competent translators and reliable customers accumulate a large amount of positive evaluations. The trust is build on those evaluations. Yet the downside of the rating system is the initialization phase. This part should not be neglected because every customer or translator has to go through that phase in the first place (no matter matter how "established" the website can be). Most of the websites that I am aware of don't do much beside their rating system. For example, since PeopleWords is just starting at this moment, nobody has positive evaluations (well, I do have positive evaluations, see what the the translators say about me, but being the website operator myself, it does not count much). I will start with a short analysis of the risks involved for unrated translators or customers. The analysis is followed by an evaluation of a few approaches that can be used to solve those issues.

Risk analysis on the translator side

For example, on PeopleWords, a translator is paid only on translated documents delivery. Therefore there is a risk for the translator to accept a job and not get paid in this end. The important question is What is the risk of accepting a job from an unrated customer?. My personal opinion on that matter is not much. I am not saying that dishonest customers do not exist, I am just saying that I believe them to be quite infrequent, probably not more than a few percents. Why?

  • It's hard, as a customer, not to reveal your identity through the documents to be translated. In this aspect, the situation is not symmetric between customers and translators. The online translator can easily disguises his identity, but the task is much harder for the online customer. As a crook, your identity is certainly the last thing you would like to reveal to your victims.

  • Almost no translation job comes as a one shot. If you need a translator now, then, most probably, you will need a translator again in a near future. Therefore it is more interesting, even on a sole financial basis, to have a stable customer/translator relationship rather than trying to crook random translators again and again. Also the web is not a very forgiving place, if you crook somebody, this person is probably not going to sue you (at least not for $100) but this person can hurt your reputation in spreading the word through forums or blogs. Additionally if the job is a large and obvious one shot then the translator can ask for a fragmentation of the payments as the work goes on.

  • As a customer, what you obtain from the translator has no financial value for anybody but yourself or your company. This point should not be overlooked. Indeed, if I refuse to pay an online vendor on eBay after receiving an ordered product, I can actually re-sell this product and obtain some cash from it. But in case of a translation job, I have no simple way to turn a translated document into cash.

As a side argument, I would add that online freelancers are well-armed against online frauds. Professional freelancers are usually quite experienced in the art of dealing with "remote" people. Exactly like experienced web users easily spot phishing attacks, experienced freelancers can probably identify most of the online scam.

Risk analysis on the customer

Typical freelance scam: Through many years experience, I translate all documents in many languages. All domains. Lowest prices. No delay. Please contact me at

As a customer, since you pay only on documents delivery, there are not risks, right? Wrong, there are a lot of risks. Worse, the customer may not even realize that he has been crooked before the document is actually published in one form or an other.

  • As a customer, you have no way to check the quality (or even the content) of the translated documents. How can I check that the translator just didn't use a software to produce a abysmal translation of my documents? This point is very important, because it means that crooks can actually turn translation jobs into cash through sabotage.

  • The costs involved through missed deadlines (or through poor translation qualities) can

    also vastly exceed the translation costs. In other words, if the customer does not get the translated documents within a given deadline (or if the quality is poor), the delay (or the bad impact) can cost him much more that the actual translator fees.

The translation sabotage is really a major issue. On PeopleWords, I have identified that

roughly 20% of the translation offers are just scam. This problem is far from being specific to PeopleWords. On most of the website that I have tried, the scam rate was, in my experience, always roughly the same (actually, I would say, the more "established" the website, the higher the scam rate). The fact that customers are, on average, much less experienced than freelancers to deal with scammers is only aggravating the problem.

Solution n'1 that does not work: Screening job offers for pre-approval

Most of the freelance websites actually screen all offers for a pre-approval by their staff before publishing the offers. One obvious drawback of such an approach is the additional business day of delay to get a job offer published. The second drawback is that such a screening process requires human resources that are paid, in the end, by the customers.

There are basically two kinds of abusive job offers. This first kind is just plain classical spam (the content of the offer is simply totally irrelevant to any translation job). This kind of abuse is annoying but mostly harmless for the freelance translators. The second kind of abuse is the case of the never-paying customers that continuously create new accounts under different names to crook freelance translators on a regular basis.

Unfortunately, the second kind of abuse is never going to be filtered because no matter how dedicated are the website operators, the offer "looks" right (there is nothing wrong with the actual offer content).

My opinion is that many websites rely on such a pre-approval step because it gives them a (false) sensation of control. But clearly this practice does not add any value either for the customer (whose job offers are delayed) or for the translators (because real abuse won't be filtered).

Solution n'2 that does not work: Escrow account

Some websites propose an escrow account where the customer can put the money at the beginning of the job. When the job is done, the customer releases the amount frozen in the escrow account. In case of disagreement, a neutral party is called to "solve" the case. The important question is Does the escrow account reduce the overall risks or costs? My conclusions are actually quite counter-intuitive: I believe that the escrow account increases the risks and the costs for both customers and translators.

But if the escrow account provides no advantage for either the customer or the freelancer, why does it even exists? Why web designer would have ever bothered to implement such a system if it was the case?

My opinion (discussed below) is that customers and freelancers have no interest into relying on escrow accounts; but there is one person that has actually a strong financial interest in such a system: the website operator himself. Indeed, the "frozen" money on the escrow account is not frozen for everyone, the money is actually earning interests for the profit of the website

operator. Moreover that money is actually providing a large amount of cash to run the website to the detriment of both customers and translators. In case of non-disagreement, the escrow account is clearly just a financial overhead for both of them.

Let us see now what happen in case of disagreement. The disagreement can only occurs if the customer refuses to release the money from the escrow account. Why would the customer do that? Case A: the customer is a crook, he wants his money back. Case B: the translator is a crook, the translation does not match the quality requirements. In any case, the customer, being honest or not, will claim that the translated documents do not meet some "quality" requirements. For the neutral party who is supposed to "solve" the case, it's going to be tough; because unless you have 200 translators covering all technical domains in all languages, you have no (reliable) way to tell if the customer is honest or not.

Worse, the neutral party has no interest to solve the case (well, no interest to solve it as fast as possible). The longer it takes to solve the case, the more profitable it is because the money is earning interests on neutral party bank account. At the end, what happen? Since I tend to pay freelance translators when I require their services, I have never experienced myself the "disagreement resolution" part of the system; therefore the following is just a wild guess of my own (remember that we are considering people with no previous ratings). In case of disagreement, the website operator will wait first and then he will take a random decision (like splitting the amount of money in two and sending 50% back to the customer). Why a random decision? Because, as a website operator, you cannot financially afford a "wise" decision to each disagreements. It is not possible to pay a reliable offline translators to evaluate disagreements when your profit margin is lower than 5%. As a consequence, only option available to the website operator is just to take random (or quasi-random) decisions.

Filtering abusive translators: a solution that might work

Abusive translation offers is the Number One issue for customers and translators alike. Why? Because abusive translators

(i.e. scammers) hurt the freelance system as a whole. Being myself a customer of freelance translation services, I have always a feeling of walking through a minefield when I browse freelance translator offers. As I said, roughly 20% of the offers definitively look very suspicious. As a direct consequence, I would guess that most customers will simply be very reluctant to hazard a translation job over the web because of the "minefield" answers that you get.

The situation is not desperate though. The good news is that liars tend to be greedy and lazy too. When I started to browse the system logs of PeopleWords (that include the times, the languages, the number of offers made by each translators), I realized that scammers where basically all following the same patterns: they answer all open translation job offers in less then 10 mins. Languages do not matter (scammers can do anything ...), specialized technical documents are never an issue and no matter the amount of work it can always be done in 48h. As I said, scammers are too greedy to actually resist the urge of answering ALL open translation job offers, and scammers are too lazy to actually create accounts with ad hoc profiles that would actually match the translations jobs.

What should be done with those of scammers? Banning them is a bad idea. Indeed, once banned, the scammer will just come back under a different name, and we are back to the starting point. Therefore, in PeopleWords, I have opted for a more twisted solution, scammers are just shadowed. Since the scammer is not banned, he can continue to browse all translation offers, he can also continue to post offers too. The only difference being that offers send through a shadowed account are never visible from the customer side... This system is not perfect, a scammer can create customer account, log in, post a job, log out, log in again, post a offer, log out, log into the customer account again, and check if his offer is visible. But it's a time-consuming process and scammers are already too lazy to provide a user profile that would simply match the translation jobs anyway.

I believe that this approach has a large added value for both the customers and the translators. Indeed, those scams are obvious only from a website operator viewpoint (that can easily spot translators making inconsistent offers), but would probably less than obvious for the customer that do not have access the website logs.

Filtering abusive customers: a solution that might work

As I discussed here above, the most "dangerous" kind of abusive customers are not spammers (those are just annoying), it's the never-paying customers seeking "free" translations, crooking each time a different translator. Since no particular patterns (at least no obvious patterns) can be used to distinguish such a customer, it is not possible to "catch" them before they actually crook at least one translator. Moreover, since the customer ends up with a negative evaluation after crooking a translator, he never use the same account twice. Ratings are just useless to deal with those people.

The approach used by PeopleWords consists in relying on the only people that are actually able detect the fraud: the translators themselves. In order to leverage the "distributed" knowledge, PeopleWords includes a system dedicated to abuse reports. Freelancers can actually help the website to prevent such a customer crooking other freelancers.

What should be done with those crooks? Again, banning them is a bad idea because they will come back. I am still currently hesitating between several options to deal with such users. The option currently in use consists in shadowing their offers. A shadowed offer is not visible anymore by the translators. The only issue being they will quickly realize that something is wrong if they do not get any offers; because when you propose a translation freelance job, you always get offers. Therefore, as an additional option, I am thinking of using the scammers list but for the reverse purpose. Instead of displaying the legit translator offers, only the scam offers are displayed to such customers. This option is so twisted I am not sure to actually ever use it, but using scammers to fight back never-paying customers is still a very interesting perspective.


[1] PeopleWords only provides binary evaluations: I am satisfied or I am not satisfied (plus an additional but optional comment). This system is very rough compared to most of the other websites. For example, provides no less than 10,000 possible rating combinations after each job (4 evaluation criterions ranging from 1 to 10 involve indeed 10,000 combinations). If PeopleWords has such a simple system, it is not due to the lack of fund (PeopleWords is dramatically under-funded) but a design choice. If tomorrow, PeopleWords provides 20 evaluation criterions each one of them ranging from 1 to 100, will the PeopleWords ratings become 10 times more accurate than Guru's ratings? Certainly not. As a customer, I have no clear idea of the "quality" of the translation job anyway. I can use MS Word spell checker to see if the translator has left many obvious spelling mistakes, but I can't really do more. As a translator, there is, usually, not much to say about the customer either. My personal opinion is that providing more complicated rating systems actually decrease the quality of the ratings. Indeed, if the system is not totally idiot proof, then users will start to do mistakes simply because they do not understand the system. For example, if you can evaluate somebody on a scale ranging from 1 to 10, what is the meaning of 10? In the German educational system, 1 is the best grade. In the French (primary) educational system, 10 is the best grade. Some other countries, like the USA, prefer the use of letters. Bottom-line: do not try to be smart, you will just confuse your users.


A few marketing tips for online freelance translators from a customer view point

Let me get the point clear: I am not a translator, I have never step a foot into a translation agency and I know nothing about the translation business. But as a simple customer, I have had a large amount of interactions with many freelance translators (most of this experience is related to the setup of the PeopleWords website).

Good online marketing is about sending positive signals to the customers. As a freelance translator, what signals are you sending to your customers?

If I am writing this small guide, it's because I have noticed that translators, in my experience, have, on average, really poor online marketing strategies. When I say "online marketing strategy", I mean What are you doing to convince a customer that you are an honest and brilliant translator. I have seen dozens of translators, often claiming years of experience for large and well-established companies, doing so ridiculous mistakes in their interactions with potential customers (i.e. myself) that I think a few "marketing" tips might not be totally unnecessary.

Sending your resume

Frankly for a $100 online translation, I am never going to read your resume. Consider that for a $100 job, I am receiving a dozens of resume. Do you really think that a typical customer is going to read 20 pages (or more) of resume for a $100 job? Additionally, there are so many resume just freely available on the web, what kind of proof is that? What tells me that you did not just get a random resume on the web and put your name on it? For online translation jobs, the usability of resumes is close to zero.

Not disclosing your personal data

What is your real name, your address, etc? Most online translators seem to be very reluctant to disclose anything. Do not expect the customer to ask you such information, you have to disclose everything first. Just consider the customer position: if you have to choose between 1) a "real" person with a "real" name and a "real" address; 2) a fly-by-night anonymous login. Who would you choose? By the way, what are the risks of disclosing such information anyway? If you are afraid of being visible on the web, surrender now all hopes to become a successful online translator. Also avoid any, and e-mail addresses. Those e-mail providers are widely known to be totally anonymous. You need a trustful e-mail address (see point below).

Not having your own website (or blog)

A website or a blog (with some content in it) is really a strong signal for the customer. It means that you have a persistent online existence. Persistence means that you did not appear last week and consequently that you will most-probably still exist next week. The number one quality of freelance translator homepage is not shiny designs (who care's if it's just plain text) but bilingual content. Your page must be available at least in two languages. What a better proof that you're not a soon-to-be-vanished crook? Setting up an homepage requires only a few hours of work. Yet, my guess would be that more than 95% of the freelance translators do not have a personal homepage.

Poorly written communications

As a French customer, I can't judge whether you're writing good Chinese or not. I have no way to check your Chinese writing skills. Therefore, I will judge your skills based on what you will be writing to me. If your communications are constantly full of spelling mistakes, how can I trust you not having the same amount of spelling mistakes in the translated documents? My experience is that more than half of translators do not pay any attention to the spelling mistake in their communications. Spelling mistakes are a strong negative signal for the customer.

Unfocused job application

This point is connected to the resume discussion here above. A customer posting online a translation job is most likely to get at least a dozen of competitive translation offers. Therefore, your answer must be sharp and focused. Do not cut-and-paste a 10 line presentation of yourself, it's almost as pointless as sending your resume. In your answer, you must prove to the customer that you have some understanding of his context and that your experience matches his documents. In the customer's mind, such an answer sends a highly positive signal that you've already started to work on his case (which is not totally untrue).

As final note, remember that the customer choices are more a matter of trust than a matter of price.

Page 1 ... 1 2 3 4 5