If your source code is a trade secret, then make sure that employees and management knows that too…

When management tries to save money, and there are no formal policies and procedures, then don’t get surprised when data leaks occur… Ungrounded Lightning shares the following story at Slashdot.

Reminds me of story about a graphics chip company

I’ll leave the company name out (mostly to protect my source B-) )

This was in the early part of the cycle of:
– A handful of companies made graphics accelerator chips..
– A BUNCH of new companies also made graphics accelerator chips.
– There was a shakeout and only a few survived – not necessarily many – or any – of the original handful.
The company in question was one of the original few.

The hardware was good. But much of the performance advantages were due to some good algorithms in the driver, which were applicable to other good, bad, or moderate capability hardware, rather than depending on special features of the company’s product.

As with many Silicon Valley companies, where the value added was so high that the administration could be utterly wacky or clueless and the company would still survive for years, this one had some managers make some dumb decisions.

One dumb decision was to try to save money by limiting the personnel to one new floppy disk per month. So the developers kept reusing the disks they had, when they shouldn’t.

As a result, the golden master for an object-only release of the driver was built on a used disk, which had once held the complete sources of the driver in question. Apparently the “reformat” process used didn’t overwrite the sectors – but the manufacturing process that cloned the golden master DID copy those sectors.

A customer tried an undelete utility and found almost the entire source code. Oops!

This news got out. Over the next couple years the great algorithms went from being a valuable trade secret (much of the company’s “secret sauce”) to a de facto industry standard.

Source: Slashdot

How to save / receive jpg image or any binary data in C# Web Api 2

Searched all through the web for a simple way to save / receive binary data or image file using Web Api 2. Solutions range from very complex to complex:

  • using JSON (30% overhead?)
  • BSON (looks nice, but not widely supported – bsonspec.org)
  • Multipart MIME (why multi-part, if we have only one file?)
  • Complex Web Api / MVC controllers encapsulated by enterprise classess, etc.

They all are missing the simplest form — POST binary data, receive binary data… all in one line of code

HttpContext.Current.Request.SaveAs(filename, false);

Yes! That’s it! One line and data from Binary HTTP POST response is saved.

In case you are looking for the simple way to send binary data using the same Web Api, here is a code we are using.

HttpResponseMessage response = new HttpResponseMessage(HttpStatusCode.OK);
byte[] binaryData = File.ReadAllBytes(@"C:\full\path\to\image\photo.jpg");

if (binaryData == null) throw new FileNotFoundException("something bad happened!");
response.Content = new ByteArrayContent(binaryData);
response.Content.Headers.ContentType = new MediaTypeHeaderValue("image/jpeg");
return response;

//if your are using IHttpActionResult, use return ResponseMessage(response);

And as always, your comments are welcome! Registration is not required.

No more sense to keep all these MSDN disks

I have several active Microsoft MSDN licenses / subscriptions, and the oldest one comes with the biggest MSDN disc collection (more than 1500 CDs and DVDs). The 2015 is the year when the Cloud has won. Disks are going to recycling plant, and I am left with a small virtual .iso collection, and big collection at the MSDN download site. Internet is so fast here in Latvia, that full DVD disk is downloaded faster, than I can make a cup of coffee.

R.I.P. my MSDN collection.

Real men don't make backups