I’m always curious when looking at running software what all it took to put that experience together. Never from a place to second guess one’s decisions but more just curiosity and this little game in my head where I try to deconstruct the solution all they way down to tools, frameworks and environments that were used to build it. That state of mind was the genesis for the below paragraphs. This is by no means a strong opinion piece to others, but when it comes to my personal setup (like most developers I know) I’m pretty particular.
Based upon my previous posts if you are following along I’m a big fan of C# and .NET. More specifically I’m in love with .NET Core. In my opinion, there isn’t a better general purpose compiled language. When it comes to the platform I’m currently working on, I’m using C# for the following workloads
- Real time event processing
- API development/delivery
- Core domain logic/libraries
- Data access and working with MongoDB
The craziest thing about all of this is that none of it is running on Windows. Well crazy if you’ve been a C# developer for more than 3 years. So I’m deploying workloads in both Docker (Linux) and then using AWS’ Lambda Serverless service. I’d say C# makes up 70% of what I’m working with on a day to day basis. Which leads into the other 30%
I really like Node. It’s super easy to get something up and running and holds its weight in terms of performance. Workloads I’m using this in
- Event driven processing
- Scripting and automation
When I started learning Node, I thought I’d be doing more with it in terms of the pipeline/platform work, but my C# pull ended up winning in out. I’ve talked to this before and written about it other spaces. It isn’t so much a reflection on Node as it is a nod towards .NET Core.
Our core front end application is built and delivered as a Single Page Application deployed to a CDN (I’ll have more on this in later posts). I’m working with React 16.4 right now and am very happy with it. Things I really like about React
- State management
- Build/deployment tools
If you think that frameworks are hot topics, just ask developers about their IDEs and Editor setups. I’m fairly vanilla when it comes to a lot of this but want to provide some reasoning as to why on these pieces of software. Before I do so though, lots of arguments about tool x over tool y over tool z. My opinion on the this is simple. Find the tool that works for you and makes it easy to work with your team members if you are using something exotic to your group. If they all use X and you want to use Y and you are the only one; don’t make it so that they have to deal with your configuration files every single time they open a project. Be kind. Multiple tools can co-exist but sometimes it takes work and compromise.
You would think that I’m using Visual Studio 2017 Enterprise. But that’s not the case. Quick detour. For years I had an internally laugh that I’d built all of the this .NET code hosted in a Mac because I’m a big fan of the operating system and workflow. Parallels was my sidekick. I could host my Windows VM, run my Visual Studio and the world was good. However, with the creation of .NET Core and the folks over at Jetbrains (who make R#) cranking out Rider, I can happily and natively code, compile and test all in one native environments. So Rider is my preferred IDE when working with C#. So this is simple to me
- .NET Natively compiled and run on a Mac
- Resharper functionality built into Rider (I’d be running R# anyways in Visual Studio)
- Customizability. Now I said I like things vanilla. I do when it comes to keymaps. But not look. I customize the heck out of the visuals of fonts, colors, styles etc.
I can’t give this product enough thumbs up. Is it perfect. No. No software is perfect. But they are constantly releasing and they’ve been at this a while and do a great job. If you were wanting to try it, take this recommendation for what it’s worth and give it a go.
Visual Studio Code I could have said Sublime, TextMate, Vim and on and on. But I’ve been using VSCode for about a year and I’m not moving off of it for the things I usages above. I love Webstorm (also from Jetbrains) but not as much as VSCode. Why
- Speed — it is super fast and can open large files
- Customizability – look, feel, options
- Plugins – there are so many plugins. It’s crazy actually. Don’t like one, write your own. It isn’t hard
- Release – Microsoft is pushing monthly releases and they are quality too which is quite impressive considering the size and scope of this editor
A developer has lots of reasons why they choose a text/code editor so I’m sure the 4 bullets above aren’t enough to convince you but if you are thinking of trying this editor out, you won’t be disappointed. It’s fantastic
I’ve barely talked lately about the data and how I’m dealing with the volume and variety of IoT sensors. This isn’t the spot to cover “why” MongoDB but it’s there and I’m using a product called Studio3T to manage, query and work with Mongo. I’ve tried the Mongo Compass product and it’s fine, but Studio3T’s is the SSMS (SQL Server Management Studio) for Mongo. I could go on and on about this product but highlights
- Query editor
- Pipeline/Aggregate builder
- Query as SQL — only used once but found it interesting
- Collection statistics
- Query optimization and analyzing
- Index building
Again, I could go on. I’m using a mixture of the Mongo C# driver to handle basic document mapping as well as custom pipelines and aggregations so building out the query, testing the indexes etc are often a first step before I implement the C# code. And this tool makes it so easy and nice. I love this piece of software and it is well worth the price tag if you are working with Mongo on a daily basis
Last set of this is the workflow and process pieces. I’m a fan of Atlassian so I’m all in on their suite of products. I find them very comparable to Visual Studio Team Services. One might be better in x and the other might be better in y and you’ll never 100% love any ALM but my opinion is that if you can get 90% or greater you won’t be looking to switch. And continuity is important when it comes to requirements, documentation, process and delivery.
- Jira – using this to manage our stories and process and requirements
- Confluence – wiki to handle bigger documentation and sharing when needed
- Bitbucket – our git host. I’m a command line guy so this works just like normal git
- Bitbucket pipelines – our continuous integration and deployment tooling
Really happy with the above stack with the exception of Pipelines. I find it to be lacking in features and not as “friendly” as something like Jenkins or VSTS. Maybe at some point I do something different but for now, the above all plays nicely and is working well.
I hope this has been useful or interesting to you guys. I’m a big golfer and I’m always looking in other peoples’ bags to see what their equipment or setup is. I thought this would be fun to show you WITB (What’s in the bag). Feel free to drop me any comments or follow up. I’m happy to talk further or share more opinions.