Getting started with .NET Core class libraries and xUnit testing

After we saw in the previous .NET Core blog post how easy it is to get started and run our first “Hello, World !” program let’s continue the series with another simple exercise : we’ll write a basic class library that checks whether a number is prime or not and some unit tests for it.

Let’s start by opening Visual Studio 2017 for macOS and creating a new project: from the .NET Core menu select the Class Library option and click Next.

Give your  new project a name and click Create.

Before moving on let’s discuss a bit the difference between the two options we saw above: .NET Standard Library and Class Library , or .NET Core class library as it may seem confusing for the first time user.

First of all, the .NET Standard is a specification, while .NET Core is one of its implementations.

As a general rule, we would choose to create a .NET Standard Library when we’re concerned about compatibility. Libraries that target .NET Standard will run on any .NET Standard compliant runtime, such as .NET Core, .NET Framework, Mono/Xamarin, while libraries that target .NET Core can only run on the .NET Core runtime.

Another aspect to take in consideration is access to .NET API surface area. .NET Core allows access to aprox. 20 additional libraries some of which are not compatible with .NET Standard.

Since in this example we’re not concerned about portability and we just want to explore .NET Core we’ll go with the second option.

Next, we’ll create a super straightforward math library that just checks if a number is a prime or not. I won’t go in too much detail here about prime numbers and what’s the best/most efficient way to perform this kind of check. This seemed just a good example to illustrate the use of a class library and how to test it. Here is the code:

Now that we have our shiny Math library let’s add a test project so we can verify that the code does the right thing. In the Solution explorer right-click and select Add -> New Project…

Next you’ll see two options : xUnit Test Project and MSTest project, I went with the first one as I haven’t used xUnit before and was curios to see what is it all about. Click Next.

Give your test project a name and click create.

The next thing to do is to add the math library as a reference to test project in order to gain access to it.

Now let’s write our first unit test. Unlike NUnit, xUnit requires the attribute [Fact] in order to recognise a test. Other than that, the syntax for the assertions is quite similar to what you find in other testing frameworks and very easy to use. In our first test we’ll check that one is not a prime number:

Let’s run the test : observe the left-side menu that allows you to either run a selected test or all of them. We can see the results in the window at the bottom of the page: Successful Tests. Passed: 1

Let’s add a few more tests just to make sure we’re covering other cases:

Next, we run all of them and we should have four successful tests. Tadaaa….

As I said in the previous .NET Core tutorial: easy peasy lemon squeezy. Now that we know the basics, follow me in the next episodes where we’ll begin our .NET Core deep dive.

Thanks for visiting!

RESTful APIs

Yet another talk turned into a blog post, this time hosted by AND Digital at their Women in Engineering Day event. When preparing the talk I chose this subject as it’s something I’ve been working on in the past few months at my job and greatly enjoyed it. I had written API consumers before and was already a big fan of the principles behind the technology but actually building an API made things even more exciting. Questions arose, such as “What is the best way to expose the data?” or “How should we name the endpoints?” and we all know that naming things is the hardest part of software development.

But what is an API?

Application Programming Interfaces are tools or libraries that assist developers in writing code that interfaces with other software. An API is basically a piece of software that plugs one application into the data and services of another.  They are not destined for humans but for other software and they allow the humans to focus on other aspects of development such as UI, UX and so on.

So why are they a big deal?

I strongly believe that APIs are for software what Rolls Royce engines are for aviation: beautiful pieces of engineering that are matched with beautiful design. And that also means separation of concern : people who work on the engines can focus solely on them and people who work on the aircraft’s body can focus on their own stuff.

But really now, they’re awesome for lots of reasons:

• Facilitating company growth: you can expand overseas without actually opening offices there, form partnerships with other players in the industry and even just raise public awareness on your products by allowing the dev community to use your public API for their projects (think Facebook Graph API) . And then, there’s of course the money : some companies charge fees for using their APIs or use a freemium model.
• Allowing users to create alternative apps/ third parties: which means encouraging innovation – if people don’t waste time re-inventing the wheel all the time they will have enough headspace for innovation and they will come up with new and fun ideas to use your data and services. When that happens within the same company it takes us to the previous point – growth.
• Allowing people to manipulate a certain product to better fit their needs: an example of this situation in which I was involved recently is a certain accounts software that also provided an API which allowed us to migrate and re-model our data in order to leverage the functionality they were offering.
• Exposing information of public interest: https://data.gov.uk/ is a brilliant example of this and it benefits both researchers and  the general public.

REST

REpresentational State Transfer  is the widely accepted way of building APIs and it’s more of a general good practice manual rather than a rigid protocol. It has all sorts of advantages like: it uses less bandwidth than other technologies; it’s not restricted to but it’s mostly used with HTTP (POST, PUT, GET, DELETE); it’s stateless, meaning that the session state is not stored on the server side which makes it compatible with cloud application therefore providing scalability.

Most of the time REST and SOAP are presented as enemies but some people in the field don’t necessarily agree, stating that SOAP is a protocol while REST is an architectural style therefore they are not comparable.

SOAP – standing for Simple Object Access Protocol is perceived as the old fashion way of building APIs, a rigid, very verbose and full of limitations way.

In the battle of REST vs. SOAP the trophy seems to go our player as it represents the architectural style of the web itself, it’s protocol independent, it allows for client-server architecture and, unlike SOAP which only supports XML, it allows the use of different formats like JSON, text, XML etc.

Tools and frameworks

As I said before, REST is more of a guideline so in order to actually build an API you will be needing to make use of different tools and frameworks depending on your experience and technology stack.

• NancyFx – as the GitHub repo states – “Lightweight, low-ceremony, framework for building HTTP based services on .Net and Mono”. It’s excellent for binding JSON to .NET objects. and it also organises code neatly into modules.
• ASP.NET Web API – a framework for building web API’s on top of the .NET Framework.
• SWAGGER/ OpenAPI – a project used to describe and document RESTful APIs, It provides all sorts of tools such as editors for design, a code generator, UI tools etc.
• AWS API Gateway – Amazon’s web service for API management : publish, maintain, monitor and add security to your API. Amazon also insures scalability and you have the possibility to set rate limits. There is a free tier available for POCs or personal projects and after that it’s 3.5$ per million calls received , pay as you go. A fair price if you ask me!
• Postman – a tool for testing your work, very straightforward and easy to use.
• https://github.com/marmelab/awesome-rest# –  you can find here a collaborative list of great resources about RESTful API architecture, development, test, and performance

More resources

So, if I caught your attention and you want to study more about APIs here’s a list of useful resources:

• https://developers.google.com/apis-explorer/#p/​
• https://www.pluralsight.com​
• https://www.udacity.com/​
• O’Reilly Media – RESTful Web APIs
• O’Reilly Media  – REST API Design Rulebook​ 

Thanks for dropping by!

Give your retros a bit of a kick with these 10 exercises

Another thing I’ve been up to lately besides coding and talking about coding at different meet-ups is a bit of Scrum Master training. One of the things I’m responsible for in my team as part of the training is to host the retros and make them a bit more fun in order to encourage people to get involved and open up.

Image source

To put you in a bit of context, just in case you haven’t adopted Agile methodologies yet, a retrospective is a regular meeting held at the end of a sprint in which the team reflects on what happened in the iteration and identifies actions for improvement going forward.

After a while these meetings might get boring or you could end up in the situation where only a few people speak up while introverts can’t express their views on the previous sprint. Fun exercises like these are supposed to lighten up a bit the atmosphere and encourage everyone in the team to contribute to the meeting.

1. One word – Describe the last sprint in one word only. You’ll need post-its and pens. Everyone writes down their word and gives the post-it to the person on their right. At the end each team member reads the post-it they received and tries to see what the author meant. The person who wrote the word might give additional explanation towards why they chose that word.
2. The many faces of Captain Jack – print a few images with different facial expressions of Captain Jack Sparrow (discontent, happiness etc.) and place them on a white board. Ask the team to reflect on the sprint and to stick post-its with the things the suit best the faces of Captain Jack.
3. Movie retro – Similar to the “One word” exercises,  but this time each team member will have to associate the sprint with a movie title. Try guessing why they chose that name.
4. The “Thank you!” session – Recognizing and rewarding work is very important in agile teams – even a simple “Thank you!” from your team can go a long way. Give each participant 3 thank you certificates and ask them to complete them. Each certificate has three sections : “From”, “To” and “For”. Discuss at the end.
5. Lego retro – You will need lego bricks to hand out to your team. Ask them to build something that reflects their feelings on the sprint and discuss.
6. Draw me a picture – Give the team pencils and paper and ask each member to draw an image that for them represents the sprint. Discuss at the end.
7. Three little pigs – On a white board draw three columns and in each column a house: house of straw, house of sticks and house of bricks. The house of straw represents the things that are flaky and prone to error, the house of sticks represents the things we do that are pretty solid but could still use some improvement and the house of bricks represents the things that we have and are rock solid. Ask your team to share their thoughts on post-its and stick them in the appropriate column.
8. Sailboat – This retrospective technique uses a sailboat as a metaphor for the team. The team identifies anchors (impediments) and wind (positive forces) and chooses an area to improve. The scrum master will draw or print a large sailboat and the team will note on post-its the things they associate with the anchors and winds.
9. Starfish retro –  On a white board draw a starfish or something similar to one. The starfish will divide the board in 5 sections: Keep doing, Less of, More of, Stop doing and Start doing. Give your team post-its and ask them to write something about your sprint for each section. Discuss and write down action items.
10. Retro of retros – This is about gathering feedback on how the retros are going. The team will write down what goes well and what could be improved about the retrospective meetings. Discuss and come up with actions.

So far, I’ve done three of the exercises with my team : One word retro, The many faces of Captain Jack Sparrow and the Movie retro and from meeting to meeting I could see improvement in the team’s attitude towards the exercises and the retro itself. From “This is nonsensical” reaction in the first one to “I like how the retros are going now” in the third, I could see not only that communication was improving but we also learned interesting things about each other. For example, in the Movie retro two of my colleagues who in general seem to disagree about many things  and have different roles in the team chose the same movie title while sitting  at opposite ends of the table. After a bit of banter, the team realised that some things must be improved and that these things look the same to very different people and perspectives.

I’m looking forward to this week’s retro and I hope you’ll have fun in your next one as well!

Minimalism in software development

A couple of weeks ago I did a talk on Minimalism in software development at a meet-up hosted by the London Software Craftsmanship Community . This subject has been on my mind for a few months now and it was the first talk in which I wasn’t addressing a particular technology but software in general so naturally, I was a bit nervous. But since the talk went pretty well I decided to turn into a blog post. Here it goes.

What is minimalism?

It all started with when I moved countries almost 3 years ago and I suddenly had to fit all of my belongings in two suitcases and then into a tiny room in East London. This was followed by other 4 moves in different areas across London and every time I found myself giving up on clothing items, books, small furniture and other things that I just accumulated but didn’t actually need. I eventually gave up buying too much stuff altogether and decided to invest in travelling and building a nice savings account. Nowadays everything we own can fit in a car and if we decide that in a couple of hours we want to move to France, I’m pretty sure that’d be doable.

Nice story, but what’s your point?

The point is that minimalism is a mindset, a tool that you can adapt to different situations and areas to gain clarity, freedom and simplicity by removing any distractions or clutter. It brings instead efficiency and creativity, it help avoiding debt and the stress of keeping up with the Jonas by saying no to consumerism.

For me it was about bringing freedom to travel and move rather than worrying where to fit 20 pairs of shoes.

But most importantly it’s a about intentionality : choosing to free yourself of too many possessions to make room for things of higher value. Surely you might ask: “But how am I going to be the next Steve Jobs if I back out from competition and ambition? Money is important after all.” And I would say that is a very valid point, but it turn out Steve Jobs was a minimalist himself : he had several copies of his favourite turtleneck sweater (and mind you, we’re talking about expensive, cashmere Issey Miyake turtlenecks) and his home had almost no furniture although he lived in a very nice neighbourhood. His mindset was clearly reflected and Apple’s products: simple, yet very sophisticated with a passion for high quality design.

In the recent years minimalism has become almost trendy thanks to the increasing popularity of the Scandinavian interior design style and big names in fashion.

What isn’t minimalism?

It’s not a set of strict rules like “You mustn’t own a car, you should only have five t-shirts etc.” , it’s not just restrictions or a goal in itself. One does not just adopt minimalism for the sake of minimalism but to obtain something valuable such as time , experiences or just some headspace.

Minimalism in software development 

Finally, back to our point. Seeing that minimalism can be applied in art, architecture, music, fashion, design and in the day to day to life I thought why not software as well?

I believe that there some principles we can borrow to obtain positive results such as less yak shaving, therefore more efficiency, maintainable code, less budget leaks and happier employees. It turns out the idea isn’t really new, a group of people came up with something called “The Minifest” a while ago and even in the agile methodologies there are ideas that can be considered minimalist.

  These are all sensible and good ideas to follows but let’s extend them a bit and see how they can be implemented in a pragmatic fashion. And software isn’t only code itself but also resources, people and processes so let’s examine each of these.

Code level – micro

The practical things a developer can do are: refactor, refactor, refactor, using coding guidelines, applying principles such as KISS and YAGNI as they all come to the same conclusion – simple is better. Also, don’t hack it but don’t be a smarty pants either: eliminate overkill or CV-driven development. Develop in small iterations, get quick feedback, fail fast and get ready to throw your work in the bin and start all over again.

Code level – macro

And by this I mean code at team or organisation level, not just an individual. As a team let’s get rid of too many repo’s with code that has been retired, POC’s or training exercises for new employees or interns. Archive or delete them altogether and the next developer who will have to search for the uses of a certain dll in the entire codebase will thank you.  Declutter as much as possible : unclosed pull requests, branches from years ago , millions of useless info logs that take up space and money need to go. Even using too many technologies , tools and programming languages just because they’re trendy but don’t actually fit the purpose can be bad for your organisation in the long term. CV driven development is not sustainable and our teams are only as strong as their weakest member is. If a technology is not widely understood among the team and only one lone ranger is using it there might be a problem somewhere.

Also, fighting too many battles at once can prove itself harmful. In war, as in business, resources are limited and it’s always about who obtains most results with minimum effort. If you’re going to split your army and make them fight on every front you’re in for a defeat. You probably won’t win every every client you pitch or launch versions of your app for every platform out there, so pick your battles.

Conflicting ideas from tech leads and architects (in larger organisations) might prove stressful for developers especially if they rotate in teams. Unity and collaboration between leaders, the business and IT is essential in order to produce quality software.

A few things that help in organisation with lots of teams and projects:

• APIs  – a unified way of accessing and exposing resources means you can plug in any type of UI and have multiple teams work on things on parallel: mobile apps, responsive website and back-end development can all happen at once without too many surprises at integration time.
• Libraries, modules commonly used  across the company – it can be a front-end library  that leads to coherence across products and applications  or a services dll that can be reused and would cut down development time.

Infrastructure

I’ll keep it short and sweet with this one as it’s not really my field of expertise, so I’ll just point out to these things:

• Don’t use servers too powerful for what they’re meant to do
• Not all environments were created equal – if your team is not spread across lots of time zones maybe switch off those test machines during the night to cut some costs
• Do regular clean-up on file servers
• And take it to the cloud , but make sure you use plans that actually charge you for what you use and not more

Third parties,  licenses, vendors etc.

Keep an eye on unused tools, licenses or subscriptions, contracts with vendors that haven’t been reviewed or renegotiated in a while and of course, use third parties when it’s easier and better than building things in-house.

Processes

Opt for little bureaucracy, agile methodologies and eliminate any internal process that could slow down or frustrate employees without bringing any value.

All these for what, you say? Well surely, not just for the sake of doing them because we read it in a blog post. But to make better software, create room for efficiency, headspace and innovation, better usage of budgets and a better company culture.

Thanks for making it this far!

Getting started with .NET Core and Visual Studio 2017 for macOS

According to Microsoft, “.NET Core is a general purpose development platform maintained by Microsoft and the .NET community on GitHub. It is cross-platform, supporting Windows, macOS and Linux, and can be used in device, cloud, and embedded/IoT scenarios.”

So why is it a big deal? Back in the day, as a .NET developer you were stuck with the Windows OS and if you wanted to play by your rules there was a lot of hustle to go through. VMs, booting different OS’s on the same machine and just a lot of yak shaving in general. Once you managed to get somehow get you software out the deployment was once again bound to Windows Servers. Today, thanks to .NET Core we have options such as deployments on Linux machines using Docker or even going serverless with Amazon Lambda functions.

Since this will be the future of Microsoft development I’ll begin a series of blog posts in which we’ll learn together how to use it and why it’s hot.  This first post is very straightforward and  embarrassingly short, but on the other hand it proves the point: it has become ridiculously simple to develop .NET software regardless of the platform.

Let’s go!

What you’ll need:

• A supported version of macOS
• Visual Studio 2017 Community for macOS
• .NET Core SDK for macOS

Where to start

After installing Visual Studio and the .NET Core SDK let’s start a new project. For this simple demo we’ll choose from the .NET Core menu the Console Application option:

Click Next and give your new project a name. Let’s go with the classic “Hello World!”.

Click create and we’re ready to start coding.

This template already has the necessary code to output the “Hello world!” message so we’ll just run it by pressing F5 or clicking on the arrow on the top bar.

Tadaaa… it’s working! Easy peasy lemon squeezy. Follow me on the next episode when we’ll try something a bit more complex.

Thanks!