Message Queues

Just read this interesting article comparing various message queue solutions. https://softwaremill.com/mqperf/  From my perspective the technology that is selected is not that important.  The most important factor is ensuring your system is abstracted and decoupled sufficiently such that you are insulated from which particular queuing technology you choose. 

More Integration Tests, Less Mocking, More Linting

Read this great article today by Kent C Dodds

https://blog.kentcdodds.com/write-tests-not-too-many-mostly-integration-5e8c7fff591c

My take away from it is the following:

1. Integration Tests give the best ROI - but people start to write unmaintnable monoliths by getting obsessed with too much code coverage and trying to mock absolutely everything.  On the other hand too much end to end testing results in fragile tests that become up a maintenance issue (see software testing ice cream cone anti-patten).  A focus on integration testing gives the best bang for buck.  

2.  Linting is good - There are lots of good linting tools out there.  You can usually hook them up in with your IDE so they can give you feedback every time you compile.  These will help improve the quality of your code and may help pick up simple bugs that people rely on 100% unit test coverage to eliminate. 

I couldn't agree with this article more.  Especially point 1.  This isn't to say that we don't need some decent unit test coverage.  But lets not get obsessed with 100% or you will find yourself spending so much time writing and maintaining tests that you lose your agility which is the whole thing TDD is supposed to support. 

Dependency Injection

In my day job I've been helping architect a restful service framework for another group.  Amazingly the 'legacy' system developers in this group weren't aware of dependency injection.  After seeing their eye glaze over by trying to explain the concept I decided to hunt around for a simple example.  I was surprised at how bad most of the explanations and examples out there are.  Fortunately I stumbled across this excellent blog post on CodeArsenal.net.

http://www.codearsenal.net/2015/03/c-sharp-dependency-injection-simple.html#.Wo5cBq6WbmE

I showed it to the developers and they said it instantly clicked.   

3 new entries in OWASP top 10

OWASP have updated their top 10.  3 new entries have been added.  They are XXE and Insecure Deserialisation, as well as Broken Access Control.  See below.

For more details check out https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf

'You Cast' Working Again

Our app 'you cast' experienced a crippling issue earlier this year whereby it just started playing the sound but no picture. This was caused by a chromecast firmware update that didn't seem to play nice with our method of casting videos.

As the 1 star reviews started piling up I spent a lot of time trying to get around this issue. I tried two main main methods:
1. Analysing LAN traffic with wireshark created by android apps which use the official chromecast API.
2. Scouring the web for various open source projects which claim to allow users to cast using the latest chromecast protocol but without using the official API. Most of these were node.js projects on git hub which never seemed to actually cast anything. The closest I got was with this one which connected to my chomecast but then crashed when I actually tried to cast a video.

After quite a few roadblocks other priorities got in the way and I basically gave up. The little bit of advertising revenue we'd been making didn't exactly seem worth the hassle.

However recently I noticed my chromecast device received a firmware update. I tried 'you cast' out and sure enough it is now working again. Last week I made a minor fix to the app and published it to the store just so that users are aware its working again.

Oh well, glad its fixed, and at least I'm an expert in node.js now.

Our new app 'You Cast' is out

This month we released our latest app 'You Cast'.  This was one app I basically built for myself.  I almost exclusively watch TV through my Chromecast device these days.  Mostly I do this through my android phone or tablet or via a laptop.  However sometimes my wife's 640 XL running Windows Phone 8.1 is the only thing handy.  Unfortunately google have not provided any official chromecast api support for windows phone 8.1 and Windows 10 apps. 

Frustrated by the inability to cast videos from this device I set about creating an app that would fill this void. 

This involved quite a bit of research, wire-shark network traffic analysis and trial and error but after few weeks of effort I was able to produce an app that allows you tube videos to be cast from windows phones. 

So far the response has been pretty positive.  It took a few weeks before it showed up in the store but as of last week the acquisitions grew from basically none to over 1000. 

I have included a banner ad at the top of the app.  So far the ad impressions seem pretty steady. I use pub center as my paid network and ad duplex for affiliate advertising,  See ad duplex graph below.

Anyway regardless of whether it makes any money this app has served its purpose by giving me another device to cast videos with.  If you have any feedback or feature request leave a comment or send us an email/tweet.

Microservices

There has been a lot of hype around microservices over the last couple of years.  I've been doing a fair bit of research and experimentation with this architecture and think it is the perfect fit for certain large project but needs to be adopted with very careful consideration. 

The positives are undeniable, having independently deploy-able, language agnostic services that can be tested in isolation definitely has the potential to scale well.  This will also add much needed flexibility that is lacking in many complex systems. 

However for many projects this architecture will introduce significant real world challenges including:

Code Reuse: When I started looking into Microservices the following question kept coming up "Where should I draw the line between having shared class libraries vs moving common code into a new shared services?"

Shared class libraries are frowned upon by many purists because it goes against the independence paradigm of microservices and will thus reduce some of the benefits of having services that are truly decoupled .  However not having a shared class library is likely to result in significant refactoring of code when logic that should of been shared is moved from one service to another.  This has the potential to be expensive and may result in many other interdependent services being affected. Obviously this kind of problem exists with non-microservice architectures however changing a class library, compiling and then fixing every compilation error as well as using built in refactoring functionality in IDE's such as Visual Studio is likely to be easier than refactoring services across a varied technology stack and having to rely on excellent unit test coverage to ensure everything is picked up.

 As is often the cases with tight deadlines and limited budgets there will be cases where moving common code into a new service becomes too costly and/or risky and developers will end up redundantly replicating code which breaks the DRY design principle and will reduce the overall maintainability of the system.

Debugging: It is likely to add complexity to debugging when a developer needs to step through code across independent, queued, services calls through logic that is implemented in a variety of technologies.

Language Agnostic: One of the commonly spruiked advantages of microservices is that they are language agnostic. However without careful consideration this can lead to the creation of a very complex technology stack.  This may make maintainability an issue because software currency upgrades and patches will become more complex and because finding experts who have experience with a varied technology stack become more difficult to find.

Version and Deployment Control: This one is pretty obvious.  It can be difficult enough trying enforce consistent and understandable version numbering accross an n-tiered application.  Try having hundreds of services and multiple persistence repositories and this can get very confusing and difficult to control.

Refactoring: Undoubtedly deciding when to create a new service, merge two or more services, or split existing services into multiple services will be a relatively common occurrence.  This will have a cost because merging or splitting services could result in hundreds of services and potentially thousands of test cases being significantly affected.

So in summary, microservices architecture certainly has some advantages but it will work best when some very careful guidelines and standards are put in place across a project team to address some of the issues I've detailed above.