Last week Cale and myself both took a week of leave from our full-time jobs in a large company and we worked on our startup (FairDealFX) at Fishburners, a co-working space in the Brisbane CBD.

Neither of us are strangers to the startup community, both having been involved in other startups and startup weekends in the past. However, this was the first time I'd spent time in a co-working space as a "resident".

Within the first few hours I was starting to understand why so many small, constrained, startups are able to take on the big guys at their own game. I hope this article will help you learn about some of the great things about co-working spaces and some thoughts on how you might integrate them into your traditional workplace.

Convention Tests, AKA: Protecting "future me"

I needed a way to ensure that I didn't stupidly include internal data types in WebAPI methods

Every business these days is working in a fast moving, disrupted, technology-driven world. In order to survive we need to be constantly thinking outside the box, and potentially contrary to the ways we've been working for years.

For the last 10+ years I've primarily been a C# / .NET developer. This ecosystem is great, there are thousands of great packages available. The one thing that's been irritating me of late is the challenge of running .NET in containers such as Docker.

As luck would have it, I recently got an opportunity to work on a new side project FairDealFx which I (perhaps stupidly) decided to do using the MEAN stack (MongoDb, ExpressJs, Angular and Node). I've done some javascript and typescript as part of web projects in the past, but not an entire application stack.

This undertaking began as an offer to help a friend out with a project he had been working on in his spare time. His prototype was working well but I didn't think it would scale too well, so I offered to help refactor it a bit. This is when I got entirely carried away and picked a whole new tech stack.

Capabilities​

• Live Stream Video
• Include Presentation Audio / Video
• Include Live Audio

Our first "Hackathon", TattsHack, is done and dusted, and what an experience. From the original idea through to the event it was only a few short weeks, and of that we were only actively working on it for 15 business days.

In that time we went from a blank canvas to forming teams of volunteers to look after communications, rules, facilities and most importantly food! We designed logos, stickers, posters and had t-shirts printed. Given that it was the first event of this type it was decided to keep it to an MVP (Minimum Viable Product)... I think we failed there - it wasn't minimal by any stretch of the imagination. Even though all our volunteers and participants had their normal workloads to take care of, they threw themselves at the task with an enthusiasm that is rare to see. It was a clear sign that the tide of cultural change really is happening at Tatts.

I'm using the ServerSpec framework to do environment validation of development and test environments. The first version is set up in a very basic way where you pass a single host IP or Name and it connects over WinRM.

This is specifically designed to be an example of how one might test long-lived environments without taking the leap into configuration management tools such as Chef. Although that would be the logical and ideal situation, there are times where it's not yet possible to take that step.

For the second part of this series I'm going to take a bit of a detour away from the code. One of the things I'm seeing a lot of recently is projects where a huge amount of work is going into shippable features, but not actually shipping anything until the end. Of course you can't ship a 1/2 done product, but you could start shipping a minimum viable product and just because you're "an enterprise" doesn't mean you can't get value from Lean development methodologies.

One of the biggest time-killers in software development is deployments (and environment management). I've worked on some big projects recently where people are spending many hours each week creating, maintaining and deploying software packages. These hours could be better spent fixing bugs, or adding value to business by adding features to the software. Instead, they're spent manually performing and tweaking installations of the software, often with additional overhead due to the inherent human errors along the way.

Gathering useful instrumentation about running applications such as throughput and performance can be tricky, but invaluable for understanding bottlenecks or latency problems. There are a number of commercial products that cover this area such as AppDynamics, AppInsights, New Relic, Stackify etc... I've had some experience with these tools (especially AppDynamics) and I would say if you're going to be supporting an application in production where there would be financial impacts if your application is performing badly or fails in production, then spend the money on one of these tools.