Techie Head

All of our decisions when creating software have pros and cons. Solution A might solve the problem well but lack flexibility. Solution B might have loads of flexibility and solve the problem just as well but be difficult to understand. A third solution, C, might be flexible and intuitive but involve a large upfront cost. I remember when I first started developing software, I'd be presented with a problem and then I'd work at it until I solved it and then move on. It was certainly a simpler time! The issue now is that I see so many different ways of solving a problem it can be almost impossible to choose which one to go with. There are several common themes I think about when evaluating the options: Simplicity Flexibility Testability However, aside from the technical considerations there's also the business concerns: Deadline Severity Budget It's these concerns which generally lead to technical debt . It's a great metaphor. Just as financial debt ...

Background One of the main problems we encountered using Entity Framework was its lack of support for full text search. Our search function is based around a series of processors that attempt to match the incoming phrase against a set of patterns that we're expecting (10+). For example, there's one for dates and times, recent financial quarters as well as more domain specific ones. Everything is cached and so is really fast, except when it isn't: Here's the monitoring chart for our SQL DB in Azure That's a spike to 100% resource utilisation because we fall through to a phrase search as a last resort (which cannot be cached) - it's exceedingly rare but it still hurts. Before EF, the app used full text search and it was one of the casualties when the app was migrated to EF4 several years ago. The lack of full text search has been getting more and more painful as the amount of data has grown. We really needed full text search back... Command intercept...

I've been a fan of Application Insights for quite some time now, it's helped debug and resolve problems that we didn't even know we had! In the new tiers in Azure, the free tier gets 5 million data points a month. That sounds like a lot, until you get a message 10 days into the month warning that you've already used 80% of the limit. Our problem was that it tracks a whole heap of requests to things we don't care about. For example, requests for images, some AJAX requests for social media sharing links and our custom health probe (used by Azure load balancing to decide whether to route requests) were taking up a big portion of that data allowance. I opened up Bing and Googled whether I could exclude some urls - that led me to this Stack Overflow question: http://stackoverflow.com/questions/31149720/is-it-possible-to-exclude-a-url-from-application-insights It looked sensible enough. I first upgraded all of my Application Insights NuGet packages to the latest ver...

I just had a problem that has taken ages to solve so blogging on the off chance it helps someone in need (or possibly future me). When this happens you need to check that you don't have a dodgy instance lying around on your localdb. All of the stuff I read online pointed at the storage emulator using (localdb)\v11.0 but I couldn't see anything in there when I checked. I decided to do a bit more digging: Running sqllocaldb i lists the instances on my localdb... I connected to MSSQLLocalDB with Visual Studio's Sql Server Object Explorer (Sql Server Management Studio would work just as well) And deleted the AzureStorageEmulatorDb* entries. The next time I started to storage emulator it all worked fine!

Froala was very straightforward to get up and running. Their documentation is pretty good but lacks an English version of the server integration for image/file uploads. Ignoring the paste, here's a view of the simple upload of images/files. I have added a parameter to the method called location which lets me have the editor save files to different places depending on where the editor is. [HttpPost] [Route( "content/uploadfile" )] public ActionResult UploadFile( string location, HttpPostedFileBase file) { string fileName; try { // resourceService handles resizing image and saving to Azure blob storage. fileName = resourceService.AddFileInLocation(location, file); } catch (Exception ex) { return Json2( new { error = ex.Message }); } // /resources/ proxies requests to assets var data = new { link = ( "/resources/" + location + "/" + fileName).ToLower() }; return Json2(d...

When needing to add a bit of WYSIWYG into a web application I've always gone with the stalwart TinyMCE. It does the job, it's configurable with regards to what you allow in your elements and generally users use it without too much trouble. We just had a few issues that were annoying with TinyMCE so we went on a hunt for a new editor to use in its place. A colleague recommended Froala  as he had recently evaluated it for another project. We use angular extensively (and had to write a directive for TinyMCE integration) so I was expecting to have to do the same for Froala. Not so! They already have a directive for angular available on GitHub . It took approximately 5 minutes to go from TinyMCE to basic Froala. It took another day or so to get all the functionality we wanted - that includes creating APIs for image and file upload. Things I really like about Froala: Good documentation It seems to produce better html than TinyMCE did (fewer random <p> tags!) Pastin...

Today I messed up. I'm a strong believer in sharing experiences of failure. If no one talks about the times they make mistakes, we're going to be doomed to repeat the same errors over and over again. So, here goes... Today I made a big mistake in a production application that resulted in 15 minutes of frantic database scripting and partial service interruption. I'm going to share what I did wrong, in part so that I focus on what I can do better next time but also because I don't want other people to make the same mistakes. Here's what happened. In our application we have some entities which use a natural key rather than a database generated primary key. This can make life easier when querying as you reduce the number of joins but still have referential integrity (with the cost of a bit of denormalisation). In the past, the whole DAL was hand coded SQL so it saved a considerable amount of developer time; we now use an ORM so we really don't care about the ...