How to Use Github Professionally

Best Practices for Working with Github in Team Settings

I originally started writing this post as internal documentation for our own team here at Petabridge, but I thought this would be useful for our readers and users as well.

Github has evolved over the years into a vast, rich ecosystem filled with lots of first and third party features that make developers more productive and effective.

Yet the vast majority of developers haven’t had much experience working effectively with Github in day-to-day work. Many developers don’t have a Github account; some have created some simple projects or filed some bug reports on popular projects; and few have forked a repository and made a pull request.

In this post you’re going to learn the best practices for working with teams of developers on Github who are working towards producing production-ready software. Everything in this post is equally applicable for developers working behind the firewall on proprietary software via Github Enterprise as it is for developers who want to submit a patch to popular open source projects like Akka.NET.

Two Unnecessary Costs of Software Development

Putting my “Chief Technology Officer” hat on for a second, there are lots of cost levers behind the total expense of software development and most of them are necessities. Yes, we should always allow plenty of time and money for testing and user feedback. Yes, we should try to pay down technical debt. We’re not talking about any of that.

What I’m talking about are unnecessary costs, waste costs, that can be avoided via using Github effectively as a communication platform among a development team. Those costs are:

  1. False starts - designing the wrong thing from the beginning;
  2. Blind alleys - designing the right thing using the wrong strategy.

In both of these cases the developers’ time and company’s money is wasted....

Best Practices for Designing Akka.NET Domain Events and Commands

How to Make Akka.NET Programming Easier by Designing Events Well

In this blog post we’re going to cover some best practices you can use when designing domain events and objects intended to work with Akka.NET. If you follow these best practices you’ll run into fewer errors, clearer log messages, and a better extensibility experience.

Use Marker / Identity Interfaces Generously

This first tip is designed to make it easier to extend your messaging systems without having to manually update the Receive<T> statements on a large number of actors.

Suppose I’m working the code from our new Akka.Cluster Workshop - in this application we have a large number of domain events for the purpose of trading stocks:

  1. Bid - offer to buy N units of stock at a specific price point;
  2. Ask - offer to sell N units of stock at a specific price point;
  3. Match - the stock trading system has matched an Ask order with a Bid; and
  4. Fill - some amount of a Bid or Ask order has been filled by a Match.

All of these events have several common identifiers and properties that can be really useful for routing, sharding, or distributing these messages:

  1. The stock ticker symbol (MSFT, TEAM, AMD, etc…);
  2. The id of the order; and
  3. They all represent live trading events happening as a result of trader activity - this is distinct from an event emitted by the exchange indicating what the newest “market price” for a specific ticker symbol is.

Well, in order to make my system more extensible and easier to debug I’m going to introduce some common marker interfaces - for instance, an IWithStockId interface:

/// <summary> 
    
  

New Akka.Remote and Akka.Cluster.Sharding Command Palettes for Petabridge.Cmd

Tools for Akka.Cluster.Sharding Management and Akka.Remote Management

We introduced Petabridge.Cmd in 2017 to make it easy for Akka.NET users to deploy, monitor, and manage their Akka.NET applications. We have now expanded the capabilities of Petabridge.Cmd by introducing two new command palettes to further simplify the way you monitor your Akka.NET applications. The new command palettes will allow you to monitor your system connections with Petabridge.Cmd.Remote and allow you to obtain sharding information using Petabridge.Cmd.Cluster.Sharding.

If you have not heard of Petabridge.Cmd yet, please take a look at our introduction YouTube video for Petabridge.Cmd

Video Highlights

  • Description of Petabridge.Cmd.
  • How Petabridge.Cmd works.
  • How Petabridge.Cmd uses command palettes.
  • Demo of setting up Petabridge.Cmd and the use of commands.

Petabridge.Cmd.Remote Commands

Let’s cover the 4 new commands that we have introduced with Petabridge.Cmd.Remote. These can be used with applications using Akka.Remote or Akka.Cluster:

  1. remote stats - allows you to see the number of Association and Disassociation events seen by the node running your Petabridge.Cmd.Host;
  2. remote connections - provides you with the number of active remote connections to the local host;
  3. remote tail - writes all of the connections and disconnections events out to the console until stopped via Control + C and;
  4. remote history - shows the connection events witnessed by the node. Can show up to 1,000 events.

We encourage you to give these commands a try in your application. Below you can see the output of some of the commands in our remote command palette. We ran the remote connections on a cluster and you can see the connection of our host node to all of the remote nodes. We also ran our remote history command with...