Marcel Popescu

I just read an article about eliminating dependencies whose basic thesis is that instead of having a class that depends on something that can give you a value, just depend on that value directly. His example (which you can read more fully in the article) is that instead of having public InvoiceGenerator(IConfigurationReader configurationReader) { _configurationReader = configurationReader; } and later on calling var watermarkText = _configurationReader.Get<string>("invoiceWatermarkText"); if (!String.IsNullOrEmpty(watermarkText)) to get the text we need, just request the text directly: public Invoice GenerateInvoice(string watermarkText) { if (!String.IsNullOrEmpty(watermarkText)) There are two obvious problems with this, which you will hit extremely quickly in real code. One of them, pointed out by a comment by LeszekP, is that most of the time you will require more than a single value from an interface. ...

Going from abstract to concrete: Private currency: good. I would love to have lots of them, just as I love both gold and silver. Blockchain: not so good, more of a solution in search of a problem. The only advantage it has compared to an append-only database is decentralization… and I don't see a need for that. I would much rather have many private currencies. Also, in practice most coins are actually centralized, or at least a very small oligarchy. Bitcoin: nah. Really bad. Incredibly slow to initialize, slow transactions, easy to control by a sustained state-level effort, very low cap on number of transactions per second, plenty of bugs, hard-forks which means the code is actually controlled by a small group (which in turn means that I can't trust that the currency itself is decentralized)… nah. In conclusion, I like the initiative, and I'm 100% behind the idea that we need to separate states and money, but we're nowhere near yet.

One problem I encounter when processing lists is exception handling. I prefer to write code that "chains" calls transforming the data: var results = list .Select(DoThing1) .Select(DoThing2) // ... .Select(DoThingN) .ToList(); The problem with something like this is that, if any of the calls throws an exception, processing stops for the whole list. Handling that requires that I move the "chain" to a new method and handle exceptions there: var results = list.Select(InnerMethod).ToList(); // ... private ResultN InnerMethod(Input input) { try { var r1 = DoThing1(input); var r2 = DoThing2(r1); // ... var rn = DoThingN(rn_1); return rn; } catch(Exception ex) { // do something with ex, like logging return ?? // can't throw, I want to continue processing the rest of the list } } Now I have two problems :) One is that the code just looks uglier, so maybe most p...

oDesk and similar sites are an interesting source of programming ideas - there are a couple of job descriptions I've seen that I have found interesting. One of them went something like this (paraphrasing): I need to continuously get data from a site and write it to a database. They have a main API that I coded for, but it fails sometimes. There is a secondary API and I coded for that too, but the first one fails unexpectedly and I haven't yet figured out all cases. Plus, the secondary one can fail too, I want to be informed if that happens. Expressing this requirement in a different way, and assuming that the "want to be informed" part can also fail, the algorithm would look something like this: try the first API if that fails, log and try the second API if that fails, log and inform the client if that fails, log and write to an alert file if that fails… do nothing, it's more important for the program to keep running "Challenge accepted," as th...

As far as I know, I've always been a proponent of "worse is better" - I favor "cheap and bad" over "expensive and good". I don't wear brand clothing, I don't use brand appliances and I definitely hate brand computers. The price/performance ratio is one reason. Case A. One $100,000 computer with a guaranteed up-time of 99.9999% - that's less than an hour of downtime in a year . (I sincerely believe that any actual computer with such a guarantee would cost a lot more than that.) Case B. Several computers with a guaranteed up-time of 90% - that's one day of downtime in ten, or more than a month of downtime in a year. How many computers are needed to obtain the same reliability as the first system? Well... the chance of one such system failing is 1 - 90% = 10%. The chance of two of them failing at the same time is 10% x 10% = 1% (therefore, the up-time of two cheap systems has increased from 90% to 99%). Adding a third computer will increas...