9 years ago.

mbed SERVER MAINTAINENCE DESTROYS 4 MONTHS OF FREESCALE DEVELOPMENT WORK

Yesterday, while working on the code for a new product, suddenly the computer screen froze. After numerous attempts to get a response from the website, I received the notorious 502 Error. Several attempts to reload the web page resulted in the same response. Forty minutes later, I was able to access the site but to my horror, the file I have been working with for the past four months was empty.

I past the information about the file to mbed's service department, and this morning I received the cavalier message, "Sorry we could not find your data." This was followed by another message, "We deem this service request as solved."

This is more than unfortunate, this is akin to negligence. The actions of your company just cost Freescale 4 months of development work on one of our key products. How it is possible to take down the mbed developer site during prime working hours for the majority of North America? What confidence can you give your/our customers that this type of negligence will not happen again?

Would it not have been possible to send an email to each registered user, notifying them that the site would be down from X to Y, and to download any important data?

As a professional embedded systems developer, I am greatly disappointed by the actions of mbed, and I can no longer recommend it as a serious development platform to my customers.

Sincerely,

Bill Smith Senior Member of Technical Staff Freescale Semiconductor

.

posted by -deleted- 09 Apr 2015

3 Answers

-deleted-
9 years ago.

I feel your pain, and have posted this question: http://developer.mbed.org/questions/7034/Offline-Compiling-with-Offline-Version-C/. I have also experienced lost productivity due to outages, together with two of my colleagues.

.

posted by -deleted- 09 Apr 2015
9 years ago.

First of all, it was no intended take down but technical issues. Which sadly they have had more often lately, and add to that that mbed isn't really good at communicating, and you got the current situation. From http://developer.mbed.org/questions/7031/After-the-compiler-went-down-briefly-yes/ I would suppose they still have older backups, it is nice if someone from mbed staff could comment on that. Also no idea how they managed to run out of disk space with no one noticing. Although I guess if there is no script running to inform an admin, it could happen. That it also affected backups is bad.

Luckily I was not working on anything, but for this I am not going to put the complete blame at mbed.

Working for four months on a single file without making any backups yourself or any commits is bad from a productivity POV already, you want to be able to go back to an older version. Worse yet, working on a key project for a multi-billion company for months where you completely rely for your data on a free third party with which you have no SLA is not handy.

How do we submit a feature request for the IDE to warn users to save, commit and exit before maintenance begins. I agree that there should be a monitoring system for low disk space.

posted by -deleted- 09 Apr 2015

Yes bad me for not backing up all my work every night before leaving work. I will suffer for my stupidity. What about adding the provision in the IDE to automatically store a copy of your source files to your hard drive?

posted by Bill Smith 09 Apr 2015

You can always source your revisions to mbed through a different repository first in order to maintain your code revisions directly (github). Also, exporting your code to your hardrive is effectively the same thing as storing the files locally; the only thing is that you have to do more work as the user for these solutions.

posted by Elijah P 09 Apr 2015

nvm

posted by Erik - 09 Apr 2015
9 years ago.

Quote:

Yes bad me for not backing up all my work every night before leaving work. I will suffer for my stupidity.

Not backing up every day is normal.

For a hobbyist not backing up for 4 months is stupid.

For a professional developer to spend 4 months on some code and not perform a single commit to the version control system that is already setup is almost as unbelievable as a cloud service web site not noticing that they are about to run out of disk space.

(oops. that was supposed to be a comment on the above thread, not a new answer to the post. If only this site would forget things for you. ;-) )