Category Archives: AccidentalFish.ApplicationSupport

Accidental Fish Application Support v3.3.0 Release

Last night I published a minor update to this framework to GitHub and NuGet that adds new timer capabilities via the new ITimerFactory interface.

An interval timer is available that runs an action, then pauses for the specified on completion, and runs the task again until cancelled (either by the action itself or a cancellation token). A regular metronomic timer is available that runs an action n seconds irrespective of task duration. Importantly in the latter case if the action takes longer than the duration of the timer to complete it will be cancelled to prevent compounding overlapping action issues (excessive CPU usage, out of memory etc.).

I’ve also added an IBackoffFactory interface that allows the backoff policies to be created with custom backoff timings. The backoff policies continue to be directly injectable with their default timings.

I hope these additions are useful. Feedback is, as ever, welcome.

Accidental Fish Application Support v3.1.0 Release

This week I’ve published a couple of updates to this framework taking it to v3.1.0.

Release notes for v3.0.0 are here and for v3.1.0 here.

There are breaking changes moving to the v3.x series as I’ve completely overhauled the logging framework to allow for the introduction of robust logging providers deeply into the framework including a new NuGet package for Serilog. There is a sample showing how to use this package and the new logging framework.

In addition I’ve upgraded the queueing system with some new features.

Firstly there is brand new support for large message queues – as in queues with message sizes in the megabytes or gigabytes. This is surfaced through the ILargeMessageQueueFactory and ILargeMessageQueue interface and combines a standard queue with a blob repository. The ILargeMessageQueue interface is derived from the standard IAsynchronousQueue and so can be used interchangeably and transparently with existing queue consumers.

Finally the queues now provide access to message properties where the underlying queue supports this feature – for example Azure Service Bus queues, topics and subscriptions.

I’m planning to add support for DNX and Entity Framework 7 in the near future (weeks, not months).

As ever if you have any issues or feedback then you can get in touch here or over on GitHub.

AccidentalFish.ApplicationSupport v2.1.0 Released

I’ve just pushed to Nuget the latest version of this framework. Full release notes are available here. The main addition is the support for IoC containers other than Unity – I’ve added support for Ninject and Autofac with this release however I’ve also improved the component host with a default restart handler and made a set of bug fixes.

I’ve also been working on tutorial / getting started documentation and you can find the first part of this here.

As ever I’d love to hear any feedback you might have either here or over on the GitHub Issues page.

AccidentalFish.Application Support v2.0.0 Release

This is now available in both GitHub and NuGet. There have been a large number of changes mostly to make the naming consistent throughout the framework and also documentation has been added to all public interfaces in the AccidentalFish.ApplicationSupport.Core assembly / package.

Release notes are available, the API reference, and documentation site updated.

Any issues please let me know here or on GitHub.

AccidentalFish.ApplicationSupport v2.0.0

As part of my documentation push I’m also dealing with some unresolved naming issues and inconsistencies I’ve noticed since releasing v1.0.0.

As addressing some of this means breaking changes, and following the semver rules, I’ll be releasing this as v2.0.0 of the framework in due course.

I’m tracking the changes in a release note as I make them and you can already see that here if you want a view of what is coming.

AccidentalFish Application Support Updates

A quick post with a few bits of news regarding my lightweight application framework.

Logger

Yesterday I pushed out a new version of the packages that contain an updated logger that will work alongside my Owin middleware for HTTP logging and correlation ID attachment.

If you use that middleware package, and an appropriate filter (Web API or MVC) in a project using the logger then everything should just work.

Versioning

I’ve not been strict enough over the versioning of this framework and I’m going to tighten this up by adopting the Semver format and guidelines. I am aware of a few, minor, upcoming breaking changes as I’ve realised I’ve got some naming inconsistencies in the interfaces (particularly around the use of async) – at least by adopting Semver it will be clear when I make those changes.

Documentation

The long promised documentation is now underway – something of a minor miracle as I’m always distracted by Visual Studio! I’m hosting it on GitHub Pages, go check it out. It’s early days but I’m hoping to make fairly short work of getting started guides so at least there’s a clear way into the framework.

I’m writing the documentation using Markdown and that’s getting translated into HTML on GitHub Pages via Jekyll. I’ve not used Jekyll before but it’s pretty simple to get going with and coupled with Markdown seems to be a neat solution to creating verbose documentation. I’ll be producing API reference documentation using C#s XML comments and Sandcastle.

Http Logging and Correlation IDs

I’ve recently pushed out some new open source for HTTP logging / tracing and alongside that support for adding correlation IDs to http calls and tracking them across MVC and Web API applications.

It’s fully documented and can be found in GitHub and on NuGet. The logger is independent of storage mechanism however I’ve currently only created a repository for Azure. I’ll probably add a SQL repository shortly.

The NuGet packages are entirely free standing other than the minimal Microsoft dependencies required.

I’m currently working on adding correlation ID support to the logging framework contained within the wider AccidentalFish.ApplicationSupport framework and I expect that to roll out early next week.

Alongside this I’m having a bit of a documentation push for all my open source. Other than Markdown and Sandcastle I’d be very interested in hearing how others have approached creating large amounts of technical documentation in the Microsoft space.

As ever feedback and issue reports are very welcome.

AccidentalFish ApplicationSupport – v1.0.0

As per my previous post I’m spending some time on my application framework – I’m aware of this getting used, by myself and others, in a variety of projects and some of the flaws in the code as it stands now are starting to hurt. Since I first put it together the Azure libraries have also come on a long way and this has led to some friction.

That being the case I’m taking this oppurtunity to revisit the framework with a number of objectives:

  1. Reduce the number of dependencies. Even the core assembly had accumulated around 10 NuGet dependencies including Azure storage, Entity Framework, Unity, AWS and SendGrid.
  2. Removal of the Enterprise Library Transient Fault framework.
  3. Support for dependency injectors other than Unity.
  4. Switch to NewtonSoft Json for serialization.
  5. Documentation and samples.
  6. Move to the “new” way of restoring packages.

This does mean a bunch of breaking changes but I think they’re worth making to achieve the above.

I’ve got a compiling first stab at v1.0.0 in GitHub. I’ll be testing this in an upcoming project and dropping the packages into the NuGet prerelease channel.

AccidentalFish ApplicationSupport NuGet Packages

I just wanted to give a little bit of warning to anyone using these that an upcoming version of these packages is going to be somewhat restructured.

Over time they’ve become a bit monolithic and adding the NuGet package to a solution can result in all manner of dependency NuGet packages being added even if you’re not using those parts of the framework. And if you follow me on Twitter you’ll know I do so hate DLL hell!

To resolve this I’m going to pull them out into multiple NuGet packages. I’m not quite sure what the final shape will be yet but the best indication is probably given by the latest work I’m doing here. I’ve just started adding some wrapped cache support (Redis) and rather than just bundle it into the .Azure package I’ve added the core interface to the .Core assembly and have created a new assembly .Cache. So you can imagine that in a reworked NuGet world that might be 3 NuGet packages:

AccidentalFish.ApplicationSupport.Core
AccidentalFish.ApplicationSupport.Azure
AccidentalFish.ApplicationSupport.RedisCache

My instinct is I’ll actually end up with 6 or 7 NuGet packages as follows:

AccidentalFish.ApplicationSupport.Core
AccidentalFish.ApplicationSupport.AzureStorage
AccidentalFish.ApplicationSupport.AzureServiceBus
AccidentalFish.ApplicationSupport.EntityFramework
AccidentalFish.ApplicationSupport.RedisCache
AccidentalFish.ApplicationSupport.SendGridEmail
AccidentalFish.ApplicationSupport.SesEmail

I’m not planning on significant C# level API changes so once you’ve got the packages you need things should continue to work as is.

If you’re using this NuGet package and have alternative suggestions then let me know.

12 Hour Coding Challenge – AngularJS and Azure

This last weekend I set myself a challenge to build and ship a web application in under 12 hours and in the process learn something about AngularJS – a framework I’ve been itching to try for some time. I also wanted to build something that would serve as a basis for a small iOS application written in Swift (to learn a little about that) and that might allow for extension opportunities in iOS8.

The good news is I succeeded in my challenge and you can find the website here and the source code on GitHub. I’ll post more details on how to build, configure and deploy this application shortly.

Without further ado – this is how my day went.

Hour 1 – Idea, Technology Choices, System Architecture

With only 12 hours and some learning to do I needed something I could pair back to a useful absolute minimum but that I could evolve additional features on top of easily in the future. I used to be a big user of delicious but gave up on it while it was under Yahoo’s tenure. I have tonnes of different devices, on different platforms (so for example iCloud syncing of bookmarks isn’t enough for me iPhone and iPad yes but what about my Surface?) so thought I’d have a bash at a simple online bookmark site. I paired things back to a handful of requirements I thought I could achieve:

  • Signup and sign-in (in a way that I could expand to include social account sign in in a later version)
  • View links in descending order they were saved
  • Save links in the website
  • Save links from a bookmarklet (button on your browsers toolbar)
  • Tag links
  • View links in tags in descending order they were saved

As both AngularJS is new to me, and Swift also when I get rount to that, I wanted to build everything else on a solid well understood foundation and so for the backend picked:

  • C# and .Net 4.5.1 – I’m hankering to experiment with Go but if I added that to everything else there’s no way I’d finish in 12 hours so I stuck to C#.·
  • Azure – table storage, web sites and a worker role. I plumped for table storage rather than SQL as I want this to scale easily and be super cheap to run – I’m paying for it myself and am willing to sacrifice features and some development complexity for a lower monthly bill.
  • Asp.Net Web API – I know this really well now so an obvious choice for the web service layer given I was using C#.
  • My open source Azure application framework, it wraps up most common operations you’d undertake against the core of Azure in a testable fashion and makes deployment and configuration easy.
  • My open source ASP.Net Identity 2.0 table storage provider.
  • The Bootstrap CSS template for the UI. Looks ok out the box and I can apply an off the shelf theme easily later (or tinker with it myself).

Most of the above took place in my head with a handful of notes.

Hour 2 – AngularJS Research

I didn’t expect this to hold too many surprises in terms of the overall system architecture as I’m pretty familiar with rich browser application development in jQuery and have some experience in backbone and Knockout but I didn’t know how to structure an application properly in AngularJS.

All I’d done with this previously was really an equivalent of the sample on the home page tucked away inside another website but it looked to be a super useful and comprehensive single page application framework that could provide a really clean MVC structure for a JavaScript client. I basically went through the developer guide at quite a clip and looked at the structure of a couple of non-trivial apps.

I was no expert after an hour, and didn’t expect to be, but I felt I could build the backend and not get surprised by the front end to a degree that would cause me to uproot the system architecture. Importantly I learned how I could integrate the client with the authentication endpoint via a helpful blog post (thank you!) which also introduced me to interceptors – most handy.

Hours 3 to 6 – Build the Backend

The storage model fell pretty trivially out of the requirements and came together quickly. I used the Chrome plugin Postman to test my REST interface without needing to write further code. I used my standard approach to this sort of thing in terms of project structure.

Nothing really new at all so largely just predictable legwork and at the end of the period I had a clean back end following a fairly pure REST model that I was fairly sure would work for the UI and I could deploy into Azure. So I did just that.

Hours 6 to 12

Best summarised as grappling with AngularJS with lots of Googling and referring to the documentation!

Actually to be fair other than a couple of pain points it was rather simple and I’m pretty sold on AngularJS as a framework for single page applications, I will certainly be using it on future projects.

I basically copied the application folder structure I would use if I was building a traditional server page request website in ASP.Net MVC and that I’d seen used in a couple of other apps that worked out really well with controllers, views and services separated by folders. I added a service layer that used the $http angular module to talk to my Web API and kept the http grub out of the controllers.

I managed to avoid the temptation to fall back to old patterns and stuck as far as I could to straight AngularJS, for example it was tempting to start inserting jQuery all over the place to show and hide things whereas I really wanted to do this in a clean and declarative fashion using Angular.

I had to refactor things a couple of times but nothing major – it came together quite easily. The last hour was putting a front page on it and dealing with something I hadn’t considered – as a new user when I went to the bookmark feed there is no real clue as to what to do next so I added a quick “if there are no links welcome page”. By the time I’d begun the UI work my own test account was littered with links!

The things that caused me most pain:

  • CORS support. My client website was running in a different domain (localhost in development) to my Web API and would in production (it’s static HTML so why waste expensive Asp.Net server resource!) and this meant I needed to use the CORS protocol (Cross Origin Resource Sharing) to access the Web API from JavaScript. Except…. it didn’t work. After much teeth gnashing it turned out that there were issues with the Web API 2.0 binaries and accompanying Web API 2.0 CORS package and I would need to upgrade to 2.2. I did this but in Microsoft’s recent “fun” fashion that included breaking changes on a point release. Fortunately simple to fix and then everything worked fine.
  • Infinite scrolling. I wanted to take an infinite scrolling approach to the bookmark list. You’ll have seen this if you’ve use things like Facebook or Twitter in a web browser – there are no “next page” and “previous page” buttons you simply scroll towards the end of the page and the next page is fetched in the background and added to the bottom. There is an AngularJS module that purports to assist with this however it had a number of bugs (must do a pull request) and so I spent 30 minutes learning the code and fixing them. Fortunately it was only 100 lines of code to deal with and still was a net win in terms of time. Maybe I’ve just missed something in terms of library dependencies.

Lessons Learned

  • AngularJS is pretty cool! Easy to use, well considered, and provides excellent structure. My only concern is that while digging around for answers to common problems it seems to be evolving very quickly with not a lot of consideration given to backwards compatibility. Maybe I’m wrong – I’m utterly new to it.
  • By keeping things tightly focussed I had something in the hands of a customer (me!) in 12 hours from start to finish. It doesn’t let me do things I’d eventually want to do (edit links and tags, delete links for example) and has some rough edges but I can already use it and “pilot” it myself in a beta fashion. I shipped as early as I absolutely possibly could.
  • The aggressive timescale meant I couldn’t go off on architectural / development flights of fancy, not that that’s really my thing – see below. I think every line of code I wrote in this system is specific to the business problem in hand. No custom UI components, no custom architecture, no funky “time saving” code / model / blah blah blah generators that are often the symptom of over architected solutions put together by people with too much time on their hands! My first choice was always to go find something off the shelf (hence my infinite scrolling bug fixes – and even factoring that in it was quicker than writing it myself).
  • There are lots of things I’d like a site like this to do (social sharing, editing as above, public / private feeds and links, trending URLs) and while I had those in mind and have rough views of how to build them I did not allow myself to get distracted by them. If I had my 12 hours would have become a week, would have become 2 weeks and so on. Just because they are not in v1 (or v0.1 if you prefer) doesn’t mean they can’t be put into v1.1.
  • You really do need to stand on the shoulders of giants – I can’t emphasise enough how strong my belief is that if the code you are writing is not specific to your particular problem then you’re going wrong: you’re hovering around the ankle while someone else starts at head height!

Next Steps

  • Understand the best way to unit test AngularJS and, errr, write the unit tests.
  • Present a tag list in the UI.
  • Deal with error conditions, particularly http errors, in a consistent way.
  • Beef up validations on both the server and the client.