Using the KeyedCollection object in C# .NET

The abstract generic KeyedCollection object can be used to declare which field of your custom object to use as a key in a Dictionary. It provides sort of a short-cut where you’d want to organise your objects in a Dictionary by an attribute of that object.

Let’s take the following object as an example:

public class CloudServer
{
	public string CloudProvider { get; set; }
	public string ImageId { get; set; }
	public string Size { get; set; }
}

The Image IDs are always unique so the ImageId property seems to be a good candidate for a dictionary key.

Here’s an example:

Read more of this post

Using the HashSet of T object in C# .NET to store unique elements

The generic HashSet of T is at first sight a not very “sexy” collection. It simply stores objects with no order, index or key to look up individual elements.

Here’s a simple HashSet with integers:

HashSet<int> intHashSet = new HashSet<int>();
intHashSet.Add(1);
intHashSet.Add(3);
intHashSet.Add(5);
intHashSet.Add(2);
intHashSet.Add(10);

HashSets can be handy when you want to guarantee uniqueness. The following example will only put the unique integers in the set:

Read more of this post

Messaging with RabbitMQ and .NET review part 9: headers

Introduction

In the previous post we looked at two ways to filter messages from an exchange to one or more queues bound to it. Routing keys provide a simple mechanism where the routing key of the message, such as “asia” is forwarded to all queues that also have a routing key “asia”. In other words the filtering is based on a direct string comparison. The Topic message exchange pattern is a more sophisticated variant where the ‘*’ and ‘#’ placeholders let you fine-tune the binding rule between an exchange and a queue. We can also bind multiple queues to the same exchange with varying routing keys.

In this post we’ll look at one more message filtering technique called headers which is in fact very similar to the topic MEP. The headers MEP offers a very fine-grained way to set up the binding rules between the exchange and the queue(s).

Read more of this post

Introduction to Amazon Code Pipeline with Java part 24: summary

Introduction

In the previous post we finalised the code for the job worker daemon thread. The job worker daemon is the central work horse of the Code Pipeline third party action. It includes all the necessary functions and objects that poll the CP endpoint for new jobs and act on each new job. The job worker is started as soon as the servlet context listener object has been executed. The daemon then sets up the polling action which is executed at specific intervals. As soon as there’s some new job the third party action will act upon it in some way. That part is entirely up to what your plug-in will accomplish.

The previous post was also the last part in this series. In this post we’ll quickly summarise what we’ve gone through in this series.

Read more of this post

Introduction to Amazon Code Pipeline with Java part 23: job worker daemon wrap-up

Introduction

In the previous post we finished discussing the job poller implementation. The job poller’s execute function runs every time the job agent polls Code Pipeline for new jobs. The job poller is responsible for pulling the new jobs and handing them over to the job service and job processor that will process them in some way. The poller will also send a signal to CP whether the job was a success or failure. The exact branching depends on the job status.

We’re now ready to return to the job worker daemon implementation. We’ve seen all the classes that the job worker calls upon either directly or indirectly so it’s time to connect the parts. We’ll do that in this post.

Read more of this post

Packing and unpacking files using Tar archives in .NET

You must have come across files that were archives using the tar file format. Tar files are most often used on Unix systems like Linux but it happens that you need to deal with them in a .NET project.

You can find examples of .tar files throughout the Apache download pages, such this one. You’ll notice that .tar files are often also compressed using the GZip compression algorithm which together give the “.tar.gz” extension: they are files that were packed into a tar archive and then zipped using GZip. You can find an example of using GZip in .NET on this blog here. I have only little experience with Linux but I haven’t seen standalone “.tar” files yet, only ones that were compressed in some way. This is also the approach we’ll take in the example: pack and compress a group of files.

Read more of this post

Messaging with RabbitMQ and .NET review part 8: routing and topics

Introduction

In the previous post we looked at two-way messaging in RabbitMq. This messaging type corresponds to the Remote Procedure Call (RPC) messaging pattern. RPC is slightly different from the previous MEPs in that there’s a response queue involved. The sender sends an initial message to a destination queue via the default exchange. The message properties include a temporary queue where the consumer can reply. The receiver processes the message and responds using the response queue extracted from the message properties. The sender then processes the response. We managed to set up a rudimentary chat application in our demo project at the end of the post.

In this post we’ll concentrate on two message filtering techniques: routing keys and topics. The two are quite similar so a single post is enough to handle them both.

Read more of this post

Strategies to extend an existing interface in .NET

Let’s say you have the following interface in production code:

public interface IPrintable
{
	void PrintMe();
}

…and you’d like to extend it in some way: add one or more parameters to the PrintMe method or add another method to the interface.

This will be difficult as it breaks all existing implementations of the IPrintable interface. If you own the whole code base then you may take the time and update all places where the interface is used.

If, however, this is not the case then you’ll need to follow another strategy.

One option is to create another interface and let it derive from the existing one:

public interface IPrintableExtended : IPrintable
{
	void PrintMeExtended(string argument);
	void PrintMe(int howManyTimes);
}

You can then start programming to the extended interface in all future code.

Another, more long term option is using the obsolete keyword in .NET and thereby discourage the usage of IPrintable. You can replace the existing interface with a brand new one and start programming to that instead. Note that this process can take years for all clients to update their code to the new interface instead.

One last option I can think of can be used for brand new interfaces so that they’ll be more forward-looking. Instead of a set of primitive arguments to a method you can let an object hold the parameters like here:

public class PrintArguments
{
	public int HowManyTimes { get; set; }
	public string Format { get; set; }
	public bool Pretty { get; set; }
}

public interface IPrintable
{
	void PrintMe(PrintArguments printArgs);
}

You can then add new properties to the PrintArguments object if you need new arguments to the PrintMe method. You’ll probably need to adjust your code for default and missing values but existing code won’t break at least.

View all various C# language feature related posts here.

Implementing equality of reference types by overriding the == operator with C# .NET

In this post we saw how to implement the generic IEquatable interface to make two custom objects equatable using the static Equals method.

You’re probably aware of the equality operator ‘==’ in C#. Let’s see what happens if you try to use it for a custom object:

public class Person
{
	public int Id { get; set; }
	public string Name { get; set; }
	public int Age { get; set; }
}

Read more of this post

Introduction to Amazon Code Pipeline with Java part 22: the job poller implementation

Introduction

In the previous post we looked at the job service interface and its implementation. The job service is responsible for polling for new jobs, acknowledging them and setting their final statuses to either success or failure. Much of the implementation uses the AWS client library to execute the work. We also know that each job polling thread will get a job service. The functions in the job service will be called by the job poller at a fixed interval.

We also started looking into the job poller implementation briefly but the job service took up most of the discussion. In this post we’ll finish the job poller class.

Read more of this post

Elliot Balynn's Blog

A directory of wonderful thoughts

Software Engineering

Web development

Disparate Opinions

Various tidbits

chsakell's Blog

WEB APPLICATION DEVELOPMENT TUTORIALS WITH OPEN-SOURCE PROJECTS

Once Upon a Camayoc

ARCHIVED: Bite-size insight on Cyber Security for the not too technical.