jeudi 17 mai 2012

the main bug of eToro

Hi guys,

I've been playing a lot with eToro in the last months, mainly with the very innovative OpenBook and CopyTrader platforms. The whole system is getting better and better, release after release. But still, in my experience, one serious bug is blocking eToro from being profitable for me. Here its is.

You know you already met this bug if you've already seen the error "trade no longer copying original trade due to unsufficient funds needed for new stop loss".

This bug can happen in two different situations: when you copy a single trade from a Guru, or when you copy full activity of a guru using CopyTrader. I will take the first situation, as it is the simplest one to get things clear.

Let's say I copy a single trade from a guru, investing 100$ on this trade. Is is a "BUY EUR/USD" trade, with a Stop Loss (SL) at -100% and a Take Profit (TP) at +100%. I can either loose the 100$, or earn 100$ plus my initial 100$. The point is that by investing 100$ in this trade, I trust eToro that I cannot loose more than 100$. This is a vital point.

For this example, let's say that the guru did in fact invest 1000$ on this exact same trade.

Let's say EUR/USD goes down a lot, and that we're almost hitting -100% (SL). The guru is confident that EUR/USD will goes up again, thus chooses to add 1000$ to his trade (total amount of the trade is 2000$ for him), and lowers the SL. Indeed, a few minutes later, EUR/USD goes up, and eventually hits the TP. The guru gets back his 2000$, plus a profit of 1000$.

What happened to your copied trade? Well, you would expect that eToro replicated everything for you. After all, it's what CopyTrader is all about.

So, you would expect that eToro made you add 100$ to your trade (total amount invested 200$), then after hitting TP, you would get back your 200$ plus a profit of 100$, just like your guru did. But no!

When you invested 100$ on the trade, eToro considers you want to risk 100$ and no more. Thus, it will never add for you more money on a trade, even if the guru behind the trade does it. So what will happen for you? Your trade will hit the original SL, and you will lose your 100$.

Here we are. You lost 100% of your investment, but your guru made a profit of 100% of initial investment. That's the bug.

Is this bug happening a lot? For me, yes, definitely! When I use CopyTrader to copy what popular guru do, I make some profits, but regularly this bug happens again and again, eating all my profits and more, and at the end I just lose money.

With this bug, CopyTrader can't be profitable, that's my opinion.

So now, what could we do? Is there any solution? I can see several :

  • Solution number 1 : Guru should not be allowed to add any funds to a trade after it is started. It is a very radical solution, and would be very unpopular among gurus I guess, but still, this way, we can ensure CopyTrader really does what it's supposed to do.
  • Solution number 2 : eToro adds funds to your copied trades when guru adds funds. There is a big drawback: when you invest 100$ on a single trade, if the guru adds more funds later, you can actually loose (much) more than the initial 100$!
  • Solution number 3 : offer every user the option to enable "solution 2" in their settings. They should first fully understand the (high!) risks involved.
So you see, it's a complex bug, and there's no simple solution.

What do you think? Feel free to comment this post :-) Do you agree this is *the* bug of eToro?

Vermeer



Stumble Upon

Hi guys,

it's been several years that I've been fascinated by Stumble Upon. If you don't know about it, I can only encourage you to discover it: http://www.stumbleupon.com/home

What they are building is just amazing. They are using the collective intelligence of all their users to build a discovery engine. I have a lot of admiration for this kind of things.

How does it work?
Basically Stumble Upon will show you a first random web page (it can be an article, a video, a picture, whatever you can find on the web). Then you tell SU if you like it or not. Then you start over and over. Simple isn't it?

The point is that SU is going to learn quickly about you like and you don't like, and will start showing more and more relevant stuff, uniquely matching *your* tastes.

The concept is brilliant :-)

I also encourage you to learn the word "Serendipity" : http://en.wikipedia.org/wiki/Serendipity
You can experience Serendipity a lot while using SU for instance :-)

Vermeer

dimanche 26 février 2012

playing Burai Fighter Deluxe

This old GameBoy game reminds me of my youth, I love to play it now and then :-)

But.. there is an old glitch / bug with it. All is fine until you reach a level boss. You die instantly for no apparent reason. It happens every time. I'm using the original cartridge in a Game Boy Advance SP.

Here is what I found yet.
Another french guy is affected.

On that youtube video I found this tip:

The game has a strange glitch. Depending on how the cart is inserted, you will die as soon as a level boss comes on screen, but the game will seem normal up until that point. The only way to know is to get to the end. If you die, re-insert the cartridge. Enjoy.

But it does not work for me. :-(

On that other youtube video I found this comment:

PS: This game (at least for me) exhibited an odd quirk; it wouldn't work correctly on a Game Boy Color, only on the original b/w console. The game seemed playable initially, but the protagonist would instantly explode and die whenever a boss battle commenced. Strange and bizarre. :\

It seems I only have two options left:
- buy an old black and white "Game Boy Pocket" (no Game Boy Color, no Game Boy SP, all affected by this bug)
- have a try with emulators

UPDATE !! a few days later...


Both solutions worked for me and fixed the issue:
1) no more bug when playing the game with an emulator
2) no more bug when playing the game on a "Game Boy Pocket", after buying an old one online

Great! :-)

samedi 16 avril 2011

Rebirth

It's been a long time since I last wrote something on this blog. But I may soon find some new motivation to do so! Stay tuned... :-)

mardi 17 août 2010

Omnifocus sync performance issues

Hi everybody,

I've been encountering sync performance issues in my Omnifocus setup (desktop 1.7.5, iPhone 1.7, iPad 1.0).

The sync became longer and longer, taking up to 5 minutes on iPad and forever on iPhone.

Here is how I fixed it:
- in desktop software, go to preferences, sync, show clients, and purge any old client. It is very important all devices in this list have been synchronized very recently.
- let your iPhone and iPad open Omnifocus for one whole night
- the morning after, on your iPhone and iPad, go to omnifocus settings: your db should have been reduced to only 1 or 2 zip files! no more 100 or even 1000 zip files...
- try to sync again: it takes max 5 seconds!

Cool

lundi 26 juillet 2010

Ca c'est fait

J'ai créé mon fonds d'investissement : http://www.vermeercapital.fr/

:-)

vendredi 11 juin 2010

How to optimize Zabbix 1.6 Mysql database (too many temporary tables created on disk)

We have a zabbix server whose database is under quite heavy load. Recently, I noticed there were something like 200 temporary tables created per second (Created_tmp_tables), and 60% of them were written on disk!! (Created_tmp_disk_tables).

I first used a quickfix, namely mounting a ramdisk tmpfs somewhere in /tmp, and make MySql write disk temporary tables in it. Fine, the server was fast again.

Recently, I found a better solution: to really solve the problem. Basically, looking at temporary tables in /tmp, I found they were all very very small (1K). According to http://dev.mysql.com/doc/refman/5.1/en/internal-temporary-tables.html the basic reason why so tiny temporary tables could finish on the disk is: some TEXT or BLOB columns. Right, I found them inside zabbix database, using a full log of all MySQL queries.

Basically :


alter table items modify params VARCHAR(255);
alter table triggers modify comments VARCHAR(255);


just solved the problem. No more temporary tables written on disk.

By the way, make a backup first: this will truncate comments of your alerts, whenever they are longer than 255 characters.