Software. Startups. Outer Space.
I get asked regularly in the Akka.NET Gitter Chat and elsewhere about “when will Akka.NET support .NET Core?”
Part of the issue I’ll address here is that .NET Core means different things to different people and there hasn’t been clear messaging on that...
I’ve been a .NET developer for roughly 10 years now - since the summer after my freshman year in college in 2005 I’ve been developing in Visual Studio and .NET. I’ve founded three startups on .NET, worked for Microsoft, and founded multiple successful OSS projects in .NET - I say...
One of my primary responsibilities with the Akka.NET project is release manager - I put together the release notes, press the big green button when we’re ready to deploy, and make sure that each contributor signs off on the release.
The thing I take most seriously about my job...
I originally posted this to the Petabridge blog earlier today. See the original here.
Not long ago in Akka.NET-land we had an issue occur where users noticed a dramatic drop in throughput in Akka.Remote’s message processing pipeline - and to make matters worse, this occurred in a production release of AKka.NET!
Yikes, how did that happen?
The answer is that although you can use unit tests and code reviews to detect functional problems with code changes and pull requests, using those same mechanisms to detect performance problems with code is utterly ineffective. Even skilled developers who have detailed knowledge about the internals of the .NET framework and CLR are unable to correctly predict how changes to code will impact its performance.
Hence why I developed NBench - a .NET performance-testing, stress-testing, and benchmarking framework for .NET applications that works and feels a lot like a unit test.
I was asked by a close friend earlier this week about whether or not I have any references, books, or recommended reading for anyone wanting to get into startups. I don’t have a single source that I can point to, so I thought I’d write one!
Let’s start from the...
And now for something completely different - I’m hosting a conference in the November 12-13th in Mountain View, California called Access to {AI}.
...There’s lots of different types of developers you’re going to need to work with over the span of your career in the software business, but the one I want to talk about today is the kind you need when you’re trying to build something new.
Finding a developer who can...
The next major milestone for Akka.NET is Akka.NET v1.1, the primary focus of which is a...
Last year I had to spend a fair amount of time working on C and C++ projects in Visual Studio 2013, and one of the tasks that I had to learn how to do was use Visual Studio’s pre-build and post-build events to copy all of my dependent DLLs into the final output folder for my applications.
In C# we take the ability to do this for granted - if we need to add a reference to another project in our Visual Studio solution we just Add Reference –> Projects –> [Project Name] and boom, we’re all set. Visual Studio will automatically copy our dependent binaries into our final /bin/[Release|Debug] folder automatically.
In C/C++ - hell no. You have to do this all yourself!
This is an archive of a blog post I wrote for the MarkedUp Analytics blog on July 23rd, 2014. It’s been a popular post and I’m posting it here in order to preserve it. I shut down MarkedUp in November, 2014.
The MarkedUp team has had experience developing SDKs, high-performance APIs, working with Cassandra / Hadoop, and service-oriented software for several years. However, when we started laying out the blueprint for MarkedUp In-app Marketing we knew that it would require a radically different set of tools than the traditional stateless HTTP APIs we’d been used to developing for some time.