TLN

Just a point when using npm you can do two types of install. A local for the appli­ca­tion you are writ­ing and a global for use at the com­mand line. The rule being … “Install locally for require(). Install glob­ally for CLI apps.”

How­ever and i com­plet­ley missed this and so wasted an hour or so but when installing for a local app you need to run the com­mand “npm install clus­ter” from the root of the app so it get put where the app can find it. Me i was assum­ing (dan­ger­ous) that you installed it to a cen­tral loca­tion and theat the $PATH pointed to it Doh!

To put it sim­ply, Krumo is a replace­ment for print_r() and var_dump(). By def­i­n­i­tion Krumo is a debug­ging tool (ini­tially for PHP4/PHP5, now for PHP5only), which dis­plays struc­tured infor­ma­tion about any PHP variable.

A lot of devel­op­ers use print_r() and var_dump() in the means of debug­ging tools. Although they were intended to present human read­ble infor­ma­tion about a vari­able, we can all agree that in gen­eral they are not. Krumo is an alter­na­tive: it does the same job, but it presents the infor­ma­tion beau­ti­fied using CSS and DHTML.

Except the col­lapsi­ble DHTML tree built around the struc­ture of the dumped PHPvari­able, and the improved by the CSS looks, Krumo offers addi­tional use­ful features.

Since NoSQL became a trendy term you often see this sort of post in var­i­ous blogs and forums.

“We are build­ing a new appli­ca­tion and we are con­sid­er­ing using NoSQL(Trendy NoSQL name here) as the only Data­base so no hybrid sys­tem RDBMS/noSQL

Now there are a num­ber of imme­di­ate flaws in this ques­tion which should lead to a lot of pain in the project if they carry on like this.

The first and sim­plest is that while SQL (or per­haps we should say rela­tional) stan­dard data­bases are just that, a stan­dard, based on the ANSI SQL and mean­ing that whether you use Ora­cle or MySQL or MSSQL you are pretty well grap­pling with the same thing. How­ever NoSQL while seem­ing to does not imply any stan­dard­i­s­a­tion or even similarity.

One list of the archi­tec­tures of NoSQL breaks down as follows

• Doc­u­ment store
• Graph
• Key-value store (with these variants)

• Eventually‐consistent key‐value store
• Hier­ar­chi­cal key-value store
• Hosted ser­vices
• Key-value cache in RAM
• Key-value stores on disk
• Ordered key-value stores

• Mul­ti­value databases
• Object data­base
• Tab­u­lar
• Tuple store

The prob­lem is peo­ple are decid­ing to go with a tech­nol­ogy that they know so lit­tle about that they need to ask a rather gen­eral forum if it is a good idea and how to do it. Then every­one jumps in and sug­gest pro’s and con’s and eso­teric plumb­ing for data struc­tures and even some alter­na­tive prod­ucts which are “much bet­ter” than what­ever the other one was.

Now call me old fash­ioned if you like but wouldn’t it be bet­ter to per­form a detailed require­ments analy­sis (or at least a basic require­ments analy­sis) of the project to deter­mine it’s archi­tec­ture and the data struc­tures needed to sup­port that archi­tec­ture and the longer term appli­ca­tion objec­tives and then inves­ti­gate which data stor­age method is going to fit those requirements?

Of course if it’s just a fash­ion thing and you just feel like using a new tech­nol­ogy you have seen blogged about then go ahead. In this case one is as good as another and yes sure use a cou­ple of them to make life more interesting.

Short on here a js cdn that serves up and com­mu­nity voted js library and then keeps it for­ever. Cool

cdn js

it does what it says on the tin

I have not seen another one and prob­a­bly for the fol­low­ing rea­son. In spite of what it says on the Sim­plePO web site trans­la­tors do not like and often will not work on side by side trans­la­tion sys­tems as shown above.

That is how pro­gram­mers imag­ine trans­la­tors will work and it is flawed. Trans­la­tors work with a toolkit called TMX, Trans­la­tion Mem­ory Exchange (generic name see Okapi an open source imple­men­ta­tion to get a feel for it), and in this they build up trans­la­tion dic­tio­nar­ies for words, phrases and sen­tences. They the take a file of vary­ing for­mats and feed it into the TMX soft­ware, this gives them a first pass that is 60%, 70% etc trans­lated but like Google lan­guage API hor­ri­bly man­gled in terms of mak­ing sense in the tar­get language.

Then what they do is trans­late the words not dealt with by TMX, adding to the dic­tio­nar­ies where log­i­cal, and they col­lo­qui­alise it, i.e. make it work in the tar­get lan­guage and make sense of it. For this rea­son the trans­la­tor should always be trans­lat­ing into their native language.

They do it this way for a num­ber of rea­sons, a) it makes sense and works and reduces their work load and b) because they get paid by the word and to do side by side trans­la­tion does not allow them to use their tools and max­imise their income.

What trans­la­tors want is a file in a for­mat that you can export, they can import and trans­late, export and send back to you to import.

The files for­mats can be csv, rtf, tmx, xliff, get­text and if you read the Sym­fony frame­work docs you can see how they do it and han­dle it (they do a pretty good job in my opinion).

Hav­ing said all that i was in a sim­i­lar posi­tion about 8 years ago when hav­ing to write a site in Eng­lish, French, Ger­man, Hun­gar­ian and Slo­va­kian and i did the same as Sim­plPO and sim­ply wrote my own side by side appli­ca­tion to allow this to be done. How­ever the com­pany we were writ­ing the appli­ca­tion for did all their own trans­la­tion in house so we didn’t hit the prob­lem with trans­la­tors. When we did we wrote an export to RTF and import from RTF (that in itself is mind bog­gling) so the trans­la­tors could func­tion as above.

How­ever Sim­plePO is the only other imple­men­ta­tion of the idea i have seen. The frame­works such as Zend seem to think you just cre­ate lookup tags to replace words and phrases and build no con­trol into the appli­ca­tion to man­age the process. Con­se­quently it soon gets out of hand and the main­te­nance of it becomes both dif­fi­cult and expensive.

Most peo­ple who write mul­ti­lin­gual web sites actu­ally don’t. They write a mas­ter site and then make a copy, trans­late it and main­tain the trans­lated ver­sion. It seems clunky to us log­i­cal types but is actu­ally very effective.

One of the rea­sons it is effec­tive is the i18n and l10n are about many other things than language.

• Look and feel. Anglo sax­ons like cool colours and san serif type­faces, His­panic peo­ples like Serif type faces and brighter colours. And as you cross other cul­tures the expec­ta­tions vary wildly in lay­out, types, colours etc.
• French and to some degree Ger­man is 30% longer, more ver­bose, than the equiv­a­lent Eng­lish so you lay­out goes to hell in a hand bas­ket real quick.
• Semitic lan­guage run right to left
• Japan­ese and other lan­guage that are not alpha­bet based can run ltr rtl top to bot­tom and some do not even have white space
• dates? US, Japan­ese, UK, Hun­gar­ian as all different
• cur­rency and num­ber for­mats, don’t even start me off

Well sorry to go on and to sum­marise:- For sim­ple side to side just write it your­self, took me about two weeks with­out any frame­works and work­ing it out as i went along just use tag replace­ment. But any more and con­sider what you are doing. Carefully.

The inte­grated build plat­form “Hud­son.” has been gar­risoned by Ora­cle. Either fed up with the infight­ing that had led to the spin-off “Jenk­ins” project, or sim­ply unable to fig­ure out a way to mon­e­tize the code, Ora­cle threw up their hands and gave the whole she­bang to Eclipse.
Is MySQL next?

48 hours only, save 30 dollars

here

For those of us using Sym­fony we have got used to the excel­lent debug bar that lets us work out where we are and what we are doing. Cur­rently work­ing on a Zend Frame­work project i was miss­ing it so looked around and found this excel­lent piece of work

ZFDe­bug