"In those two days Ashic provided the technical foundation upon which we were able to build a business critical platform. His dedication and personable nature made him the ideal collaborator."
Jeremy Langworthy [Technology Director, ATG Media]
I provide a variety of consulting services. Consults usually take 2-10 days.
I can work onsite or remotely to help deliver software solutions.
The three day course coverse the basics needed to get you up and running with Domain Driven Design, Command Query Responsibility Segregation, Event Sourcing and related concepts. The course is a mixture of interactive lectures and hands on exercises. The course is targeted at developers and architects who are looking to build efficient, maintainable, raliable software. It will give you enough information to use these approaches, and make informed decisions as to which trade-offs to make, and when.
This is a five day course that delves deeper into implementation approaches, and messaging principles. In addition to covering the basics, this course also focuses on implementation challenges that teams using DDD, CQRS, and / or Event Sourcing typically face. We go in depth into exploring those problems, and present potential solutions in solving them. This course is also targeted at developers and architects. Whether you want to start off with deeper knowledge, or are having trouble after having adopted these approaches, this course should help.
This is a three day hands on course exploring core messaging principles using ZeroMQ. We first discuss the basics of ZeroMQ, and fundamental principles like Request-Response, Pub-Sub, Task Distribution, etc. We then move on to more advanced concepts like reliability, availability, fault tolerance, brokered and brokerless messaging, etc. We also explore ZeroMQ's versatility in terms of cross platform, cross language interoperability. We design appropriate protocols ourselves, and see how we can bend Zero to our will. The course is targeted at developers and architects who work with high throughput, distributed messaging systems, and / or are looking for better ways of integrating different services and applications.
In this five day course, you will learn the fundamental practices of agile software engineering. This is not about planning poker, sprint planning, scrum masters, etc. Instead this focuses on practical hands on exercises that target the fundamental skills to succeed with agile methodologies (and software development in general). During the course, we will cover distributed version control, build scripts, continuous integration, automated testing, TDD, BDD, acceptance testing, refactoring, deployment, continuous delivery, etc. We will cover tools including Git, Team City, Vagrant, etc. The course is geared towards developers and hands on architects.
This is a two day course, you will go through a series of practical exercises that will cover enough of Git to make you not only competent, but also confidence in using Git. We will cover the basics like commits, branching, merging, rebasing, remotes, etc. We will explore time saving ways of doing common day to day activities. We will then go deeper into some advanced and hidden features. We will evaluate various workflows, branching strategies, etc. We will also cover using Git in continuous integration, and where and how it can be leveraged in the deployment pipeline.
I'm a practitioner of Domain Driven Design (DDD), Command Query Responsibility Segregation (CQRS), Event Sourcing (ES), Service Oriented Architecture (SOA), Event Sriven Architecture (EDA), microservices, and messaging principles. I'm a big believer in just enough design (which tends to be very little), and emergent architecture. Rather than making technology choices up front, I prefer to prototype and experiment, and gravitate towards approaches that keep the most options open until the last responsible moment. As a corollary, I prefer principles that provide small incremental value as opposed to large big-bang releases.
I've seen a common theme in many clients attempting DDD, CQRS, Event Sourcing, SOA, etc. People tend to focus heavily on the technical details, and common superficial patterns. As a result, they miss out on the core values of the approaches. They tend to look for a cookie-cutter approach, often resulting in something similar to an n-layer architecture. This starts out well, but soon tends to result in features taking longer and longer to get delivered. Instead of trying to use the same patterns and practices regardless of requirements, I focus on identifying the ones that cater to a particular project's needs, and implement them with long term benefits in mind.
I'm a fan of "living software". I believe that unforseen scenarios and requirements will emerge, and that it is impossible to get everything right from the get go. As such, I divide systems into contexts and services, and implement each to be as good as necessary. Applying the same level of dexterity to everything only results in overhead and accidental complexity. Instead, I reserve the most focus for the contexts that provide the highest return, while ensuring under-performing bits can be easily replaced. As such, my solutions evolve over time, rather than following a pre-destined failure-bound path. Whether I am putting together a large topology for high performance reliable brokerless messaging with ZeroMQ, capturing domain events in an event store, composing functions with reactive extensions, exchanging 10 million + messages in memory per second with plain old C#, hooking together distributed applications with a broker like RabbitMQ, evolving level 3 ReST services, applying messaging through process managers, routing slips and sagas, or doing simple CRUD with Entity Framework - I always keep the bigger picture in mind.
With over 12 years of professional experience, I've used a few things.
Most of my commercial experience has been with .NET, and C#. I've been with the platform since 2002, having used the public 1.0 beta. After briefly using WinForms, I quickly switched my focus onto WebForms, and then ASP.NET MVC as soon as it came out. Since then, I've delved into high performance scalable distributed server-side applications, while keeping a keen eye on client side technologies like ASP.NET MVC, Web API, jQuery, Knockout, AngularJS, bootstrap, etc. For message oriented systems, I've used ZeroMQ, RabbitMQ, Mass Transit, NServiceBus, Service Bus for Windows Server, and - where appropriate - chose to implement custom messaging for problems that haven't fallen into the gaps filled by existing tools. In the .NET world, I've also used WCF, WPF, Prism, NancyFx, Windows Services, TopShelf, Reactive Extensions for .NET, Silverlight, NHibernate, Entity Framework, Dapper, Simple.Data, ASMX Services, various IoC containers (including Autofac, Structuremap, Unity), NCqrs, CommonDomain, RIA Services, etc. As a fan of automated testing, I've used tools like NUnit, XUnit, Machine.Specifications, SpecFlow, Moq, FakeItEasy, FitNese, and quite often create lightweight frameworks around NUnit for domain specific testing.
As mentioned before, most of my commercial experience has been with C#, and I'm more than at home with JavaScript. I am, however, interested in a broad range of languages. I've passed professional courses at Oxford University on Haskell and Erlang with distinction, and have completed Coursera training courses on Scala and R with 100% marks. I'm very keen on functional programming, and look to use F# wherever appropriate. In fact, most C# I write these days is heavily influence by functional programming concepts. I'm learning Python and Octave / Matlab as I get deeper into Machine Learning. Although it's been a while, I used to code quite a bit of C++ as well - from taking part in programming contests, to writing 2D and 3D engines on top of DirectX 7-9.
I'm a follower of Continuous Integration and Continuous Delivery. I build build scripts using Psake, MSBuild, etc., and my CI server of choice is Team City, though I have experience with Jenkins and TFS as well. I'm using tools like Puppet and Vagrant to take advantage of reproduceable environments, and am a fan of productivity tools like ReSharper, MightyMoose, etc.
I'm a relentless learner, and love to pick up new things. I like being out of my comfort zone, and am currently learning more of Erlang, Haskell, Scala, Node.js, Hadoop, Riak, Cassandra... I often sign up for online courses covering topics like Cryptography, Data Analysis, etc. that I find interesting and challenging. Sometimes I attend professional training courses. For example, I've been through Martin Thompson's Lock Free Algorithms and Jezz Humble's Continuous Delivery workshops. I have an extensive collection of books - from Joe Armstrong's latest Erlang writings to Gul Agha's works on Actor Models going back decades.
Agile, without the capital 'A'.
I've seen quite a few clients struggle with Agile. They have their people go to certification courses, make managers "scrum masters", set up rigorous processes, arrange planning meetings, reviews, and retrospectives. Yet they seem to have trouble where it matters - actually delivering software. In the formalisation of Agile, we seem to have lost what it stands for. We seem to value processes and tools over individuals and interactions. We try to create templates to be used in all projects, and try to plan away risk. We attempt to prevent failure, rather than learning from experiments. We hold onto the same practices of yesterday, but expect that with the addition of some meetings, a task board, and some sharpies - everything will get better on its own.
The value of agile or lean is not in the process, or estimations, or burndown charts. While these things can be useful, the core revolves around continuously delivering working software, and having working software as the measure of progress. Tightening the feedback loop not only gives us faster feedback, it also reduces risk and prevents us from veering off course. The process should facilitate software deliver, not the other way round. Different projects have different needs - trying to enforce the same processes across the board may seem like an efficient, repeatable option - yet it is one that can cripple the actual act of providing value. Instead of delivering value, Agile (with the capital 'A') turns into a hindrance that the team has to bear to keep management happy.
There are certain practices that are invaluable in sustainable and frequent software delivery. Continuous integration, efficient version control, push-button deployments, phoenix servers, high quality tests, refactoring where arppropriate, evolvable architecture, impact mapping, early risk identification, prototyping for solutions, pair programming, etc. canall help in creating releasable, production ready software that not only works, but evolves when necessary. These may seem technical, yet are fundamental in attaining the benefits of lean and agile methodologies. Guess what I tend to focus on?
Over the years, I've learnt a lot - and am still learning from - the wider software engineering community. I try my best to reciprocate, and enjoy doing so. I speak at various user groups like NxtGenUG (and it's many offshoot divisions), Canary Wharf Dot Net User Group, Skillsmatter, etc. I also present at various conferences - from local DDD ones, Skillsmatter Progressive .NET, etc. to international ones like Oredev, NDC, etc. I've also presented at a few online conferences, like aspConf, mvcConf, Virtual Techdays, etc. I'm the founder of the London ZeroMQ User Group, and we meet every couple of months (or so), and build something hands-on with ZeroMQ. I'm a moderator and "all star" of the official ASP.NET community at asp.net, and have been an ASP.NET / IIS MVP since 2009. I often write for various technical magazines, and of course, on my blog.