Tesmond's Useful Design

So it's MWC time in Barcelona, the rumours about what could be released had me eagerly looking to see what might be my next mobile. Obviously the expected big gun Samsung S5 was going to be announced. Well that has to be the biggest tech disappointment for me. For some reason Samsung released a phone which for the most part is worse than their 6 month old Galaxy Note 3. Each year the S range has spec wise been the best phone at least for a few months, but now Sony have out done them with the Z2 and are even planning to release it before the S5. It seems strange that Sony are suddenly looking to win the spec race. Not only that but they are even talking about a new flagship every 6 months ! Meanwhile HTC have already mocked the S5 and alleged that their follow up to the HTC One, which is to be unveiled March 25th, will be superior . I was certainly considering the S5 prior to the announcement, but now it is off my list. Essentially I would be surprised if their minor camera...

As I alluded to in my previous post there are many reasons to pick a database, performance is only one of them, but as it is the easiest to objectively assess that it where I am starting. So here is a quick look at query performance. So we have our 1,010,000 strong pair of databases. So how about a count of the number of editions which have a 1 in them (about 47000). MongoDB - 0.906 seconds Intersystems Cache - 2.247 seconds Well MongoDB takes a healthy lead in this respect. It should be said that by default MongoDB has its own query language, where as Intersystems Cache can be accessed through iteration or via SQL queries. Now I could have biased the query strategy, for example Intersystems Cache is significantly faster at selecting whole phrases, e.g. searching a specific property which appears multiple times can be returned faster that MongoDB, but in both cases I was looking at 0.010 seconds VS 0.007 seconds. It was consistently faster although it was in the magnitude of...

While looking through stackoverflow I noticed an interesting question about the differences between Intersystems Cache and MongoDB. Now these databases are substantially different in many respects, but both do allow for a more direct object mapping approach than you will normally experience in a standard SQL environment. Having read that MongoDB had recently secured $150M in financing I was curious as to what the platform was like. Picking a database is never just about raw performance, but it is one of the most important aspects so I thought I would start with this aspect. What I thought would be interesting would be to compare the insert performance of objects in Intersystems Cache VS the insert performance in MongoDB. I took a very simple example, inserting 10,000 objects each with 3 properties, performed both tests 3 times on my laptop and averaged the results. There were no indexes defined. This is not exactly a great test but as Cache was significantly faster at doing ...

Problems of Implementing Change As a software developer you are always an agent of change. There is a problem with this role however, many of your customers will share your joy of change with quite the same light. When Office 2007 came out I personally thought it was a substantially better interface. However, there was plenty of online criticism, features had been renamed and moved, Office experts suddenly didn't know where their obscure several level deep options were, and even though most options were easier to find, because some were harder it was not undeniably better. People even went so far as to develop software to alter the new ribbon interface back to the 2003 design. Windows 8 suffers some of the same issues, Microsoft improved the boot up time, the hibernate functionality, they built in lots of new features, however, the tile interface change and the separation of desktop and tile based apps has lead to the entire product being criticised.  It can be dishea...

Joel Spolsky wrote many years ago that a re-write from scratch was the single worst strategic mistake a company could make. He pointed to a number of notable failures that were re-writes from scratch. I believe his most salient points are You will have devoted a very large amount of development time to a product which will essentially have the same value as the product you are currently selling.  You will not have resource to improve the features of your existing product and your competitors will overtake you. Even if you develop using all the best practices available such as TDD or BDD, have a wonderful QA team a live field tested product is actually likely to be more robust. In essence he implies that refactoring legacy code is always the best path to adopt. The evidence he provides albeit from pre-2000 is somewhat compelling, and in fact some very successful companies have stuck to his mantra of refactoring sometimes in unique ways. By refactoring I mean the process...

Sometimes the little interactions are important. I recently ran a test build of Android 4.4 on my phone and discovered a new feature. This feature is the ability to pre-emptively "dismiss" a scheduled alarm. Prior to this feature I would need to turn the alarm off, wait for the alarm time to pass and then turn the alarm back on. Now this is an infrequent case, when for example I wake up a few minutes before my alarm is set to go and I don't want it to just go off for 5 minutes while I am in the shower. I have to switch it off and then remember to turn it back on. If I forget then the cost is reasonably high, I could miss my alarm the next day. Now repeating alarms have been on phones for many years and I have relied on my phone alarms since 2006, but it has taken 7 years for someone to come up with such a simple and useful interaction. I love it when something that has been "done to death" can suddenly have a new improvement that makes the feature just a l...

While my investigations have still left me sad to find that there is no real way to match the read performance of an SQL database I have found out some interesting little pieces of information on Caché. 1. Bitmap indexes always appear to be faster than standard indexes no matter how many unique values there are. 2. Traversing standard indexes manually is the fastest way to return a query first time (second time bitmap index SQL is the fastest). 3. Single Insert performance is good 4. Reversing through an on disk array (e.g. $ORDER(^global,-1) ) is slower than going through it forwards putting the data into an in memory array and then reserving through it! To my surprise all my tests showed that it was at least a 50% performance improvement and as the data grows it can double. The only problem is if the memory array grows too big then you will get a store error as the memory runs out. I am considering re-writing my queries to only reverse $ORDER in memory and checking the ...