Sunday, February 10, 2008
Tuesday, December 18, 2007
Create your application for iPhone/Facebook/Android
Do you have to create an application for iPhone/Facebook/Android ?If your target is the B2C market and you reckon on early-adopters and geek people to talk about your project and make Buzz all around, you MUST create one application on these platforms. Just because it is where you need to be visible.
And the argument saying for example that iPhone is like no people is using it regarding the market share is a wrong argument. These people (including me) do have an iPhone (maybe 50% of them do?), have a facebook account, do tweet, will run Android soon, and will post an article to their blog embedding your application if you make it possible.
-- ahem, I've no iPhone for now, and of course would like to (message, message) ;)
Ah, and of course, your application must be free, fun, even useless, but nice, and will not necessarily help you earn some money, but will higher your buzz-meter and expose you to scalability failures eventually - in that case I can help :)
Tuesday, December 11, 2007
Sunday, December 09, 2007
Natural desire of rewriting software
The decision of rewriting the code of a significant part of a system is usually taken by an experienced developer, by itself, because "the code sucks". And usually without any real business consideration.The consequences of such rewrites are often disasters, making the company loose time and money, and even worse, breaking teams.
The more interesting and surprising thing is that this behavior is more often observed with talented developers (skilled, experienced, seniors ones) than with others less experienced developers.
The way I understand it is:

- They see as an evidence how to code software in a better way.
- They like simple, brilliant, but "simple to use", software. (I do too). And as a result, they tend to less tolerate complex, not easy to use code, and easily feel that the code developed by other people sucks. Plus, they don't want to rely on other people code, especially if it's "hard" to integrate or will make them write some "ugly" code.
- They are more subject to the NIH (Not Invented Here) syndrome. In some way, they would like all the software be written by themselves, if they had time to.
- They see what to do in a global and precise view, and then underestimate the time needed to achieve their development (and test it, and document it, and QA it, and deploy it, and debug it, ...).
If you are a good developer, and willing to re-write any significant code by yourself, please refrain your nature desire. And ask yourself: what benefit for the company? For the business? Does your action will reduce the time to market of the product? Does the company will earn more money? Could you be more useful by doing some other more urgent stuff?Maybe the code you want to replace is not perfect (even yours will be found perfectible by other people). But maybe it fits the company needs. At least for now. Maybe there's more urgent stuff to focus on. Maybe you will make the company loose time and money while you rewrite this code.
I have experienced this more than once on different projects. What I can say is that the more complex a project is (technically speaking) and is involving experienced developers, and the more I have been facing this NIH (Not Invented Here) syndrome that makes people reject the code written by others, and rewrite applications.More than that, I've been facing talented and respectable developers that refuse to have a look to systems written by their colleagues, and don't admit they need their features, and only want to code everything by themselves - they will then recode a large part of the system without having noticing it.
Worse than anything else, I've seen teams replacing teams in order to rewrite everything from scratch as a remedy to a malady... and finally fail, making the company loose time, money and talented people.If these words are ringing a bell in your head, please comment :)
Note: these words are not directly related to any project I may talk about in this blog.
Tuesday, October 02, 2007

Joost 1.0 is here !
You no longer need an invite
New features and new content inside
We've worked hard on it
Enjoy !
Wednesday, February 21, 2007
Cross-domain XSLT document() function in Firefox
I'm a fan of firefox. For many good reasons tied to both my user and developer experiences. So I've been first frustrated when I discovered a feature that all browsers seem to implement in a good way but not firefox. Explanations:This feature is related to the XSLT processor embedded in the browser, I'm using to quickly render XML documents into HTML without having to set up a web application.
Here is a sample:
1. the XML page opened directly with the browser:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="backend-system-versions.xsl" type="text/xml"?>
<?xml-stylesheet href="backend-system-versions.xsl" type="text/xsl"?><!-- IE hack -->
<services>
<service href="http://my.server1/RestService1"/>
<service href="http://my.server2/RestService2"/>
</services>
Note: this XML doc refers to web services RestService1 and RestService2 of different domains my.server1 and my.server2 that are supposed to return the following XML I integrate in my page:

<?xml version="1.0" encoding="UTF-8"?>
<root>
... usefull things ...
</root>
2. the XSL stylesheet looks like:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:template match="service">
<xsl:apply-templates select="document(@href)/root">
</xsl:apply-templates>
<xsl:template match="root">
... nice HTML rendering ...
</xsl:template>
...
</xsl:stylesheet>
The issue with firefox is the document(@href)function call which opens the XML document given by accessing the URI contained in the href attribute of the service node. Well... on IE and Safari it does, but not on firefox 2.According to the Firefox bug #353886 this is to avoid a security hole.
It means that if my XSL stylesheet contains a document('https://your.bank/account') and if your browser (IE or Safari) have your certificate to access your bank account, my page hosted on my server accesses your bank account and you are in trouble...
So, is Firefox the only secure browser ? I'm not frustrated anymore :)
Now, as a general notice, trying to access a foreign domain using either XSLT document() function or an XMLHttpRequest is a fault. Your web browser should not allow that.
Or at least inform you what the page is trying to do. Maybe an option for firefox ?
Anyway, I have to set up a webapp for my stuff now...
Labels: cross-domain, document(), firefox, XMLHttpRequest, xslt
Tuesday, January 16, 2007
Joost revealed !
Today, The Venice Project has revealed its brand and commercial name: Joost™

and with it, its new web site joost.com and a new client 0.7.3 with a joost skin (for beta testers only [1]).
From now on, it means more content, a client still in beta but even more stable than ever, new features in the coming days, and more and more beta testers.
For me, it means also I can now talk about it using its real name :)
[1] As we have now more invitations to distribute, send me an email to get one if you really intend to help us and give good feedback on Joost - I keep one for you, Guillaume, who ordered a DSL connection to be able to watch Joost (or was it to work at home as well?)

and with it, its new web site joost.com and a new client 0.7.3 with a joost skin (for beta testers only [1]).
From now on, it means more content, a client still in beta but even more stable than ever, new features in the coming days, and more and more beta testers.
For me, it means also I can now talk about it using its real name :)
[1] As we have now more invitations to distribute, send me an email to get one if you really intend to help us and give good feedback on Joost - I keep one for you, Guillaume, who ordered a DSL connection to be able to watch Joost (or was it to work at home as well?)
Labels: joost.com, theveniceproject


