Today, on September 17th 2016, I am very excited to announce the next evolution of .NET software development, coaching and consulting: “TeamVirtuoso”.
TeamVirtuoso is the summation of my technology consulting experience. TeamVirtuoso’s lineage may be great but it’s history is short. Into early 2017; I’ll be working to make TeamVirtuoso “Big and Visible” with activities such as blog posts and speaking engagements. Much of my personal content will be published under the TeamVirtuoso banner and on the TeamVirtuoso site.
Let’s define TeamVirtuoso:
TeamVirtuoso is an Agile software consulting company that lives in the sweet spot between “Big A” agile and “We have daily stand-ups”.
TeamVirtuoso specializes in the Microsoft platform. We build software using C#, Build systems in F#, Deploy to Azure, Run servers on Linux and carry MacBooks so we can develop Xamarin iOS applications.
TeamVirtuoso is open. In the near future we will be sharing our entire delivery model handbook. Every step in our practice will be made available for both clients and competitors to review. It is our hope that this level of transparency can help the entire software industry build better software.
TeamVirtuoso is community focused.
TeamVirtuoso ships, to production, during the first week.
TeamVirtuoso is built on trust.
TeamVirtuoso builds distributed, cloud native, event sourced, solid, applications.
TeamVirtuoso is a startup.
TeamVirtuoso is for startups.
TeamVirtuoso is excited about the future of the .NET platform.
“TeamVirtuoso is ready to help you embrace that future.”
I’ve been blogging since 2009, thats a long time. In that long time I’ve used lots of tools and technology that is just not relevant anymore. I also started and stopped open source projects. All the time sporadically posting my personal notes about whatever random tool or technology I was using/learning.
All those posts have been removed. Sorry if you wanted to read a not about the dojotoolkit or the advantages of channel factories with WCF.
I spent a few minutes talking with a team member about hexagonal architecture today. It reminded me how much I’ve learned about software development over the years.
I don’t get to actually focus on the practice of developing software on a day to day basis anymore. Bluntly; it’s been a few years since my primary responsibility has been guiding a single time to building a single system…and it’s sub-systems.
I’m going to add a talk about Hexagonal Architecture to my growing list of talks I’d like to focus on. Along with Microservices and Event Sourced architectures I should have a nice collection of xplat talks that will focus on the essence not the ceremony of building quality systems.
After years of using wordpress; I switched to using GitHub’s “ghpages” to host and publish my content. ghpages had many upsides, learning a new technology (Jekyll), hosting for free, speed, writing posts in markdown, and more.
As of today, I’m still using Jekyll but I am moving from ghpages to a linux server on Azure. Here is why I am moving and what my setup looks like.
Jekyll has become my de facto platform when building static sites or blogs. I’m going to stick with Jekyll for the time being…unless the setup I have for hosting/writing becomes cumbersome.
Azure Linux server
Here is where things get interesting. At first I deployed the pre-build static site to Azure App Services and everything worked well after a few config tweaks but I ran into one major problem. I want to run a jekyll build each day so that future dated posts are added to my blog.
Here is what I wanted:
- onnect App Service to Github
- Write custom build.cmd / .deployment to install ruby, restore gems and build site
- Deploy site
- Schedule daily deployments (so that we run ‘jekyll build’ and pick up new posts)
Everything worked with the exception of scheduling deployments. I got the deployment url from the portal
But ran into an error when posting to that URL. So I read the documents on github, https://github.com/projectkudu/kudu/wiki/Continuous-deployment, but still got an error. So I grabbed the webhook url from GitHub, put it into postman but still got an error.
Bottomline; I could not get scheduled deployments to run.
My options are to use VSTS or to stand up a Jenkins server…..well…or just use cron.
I decided to use an ubuntu linux server, install ruby and Jekyll (requires node and gcc) I started writing a build script. The plan was to run it from cron but ended up using Jenkins because I was running into issues with cron (permissions).
Now that Jenkins is configured and this post is created - with a date in the future - this post should be published tomorrow. I’m going to configure IFTTT to check the RSS feed and tweet the new post.
Ok. Microservice - both personally and professionally I’ve been working on microservice based projects. I’ve learned some lessons and I have some thoughts about building such a platform.
I’m not sure that title would get picked up, so I’ve softened the abstract a little. Time to start building out the slides and submitting it to local user groups and regional conferences.
Should your next project use a Microservice based architecture?
Now that you’ve been to all the talks describing what Microservices are; let’s review how you can evaluate if you should be using Microservices for your next project. In this session we will take a 1000 foot view of a Microservices based architecture and review my personal experience delivering Microservices based solutions. Also; if a Microservices based architecture is best for your project we’ll review how to convince your boss, your team, or your customer that a Microservices based architecture is the best architecture for your next project.
Most demos will be in C#