Sunday 5 February 2017

How to choose an open source project to contribute to?



There are plenty of open source projects, and you probably use some. Open source projects can be a good source of learning and can help improve your developing skills. You'll have a chance to read carefully written code, used by many people. You'll have a chance to receive feedback from the project owner. Finally, you can contribute to a project you love. It might be scary in the beginning, and for many developers, the big question would be:

How to choose an open source project?

If there is an open source project you use and would like to contribute to it by resolving an issue that annoys you or adding a feature that would be beneficial for you, then go ahead. For those who don't know where to start, http://up-for-grabs.net/#/ is a good place. The website lists open source projects that mark their issues as easy to start with. It also allows filtering open source projects by programming language or technology.

Once you narrowed your search to a list of several open source projects, the dilemma is how to choose. In this post, I'll try to give tips that might help you in choosing an open source project.


Interesting domain
Before you dive deep into source code, think whether the domain of an open source project attracts you. If you're mainly a back-end person, I doubt a 3D graphics project will cause you the same passion as some other server-side component. So, do what you love.

Clear and permissive license
The open source world looks very open, but there are strict rules, regarding software licensing. I am sure you don't want to deal with legal issues when you contribute a few lines of code. So, make sure the project has a clear and permissive license that appears on its website. If you are not sure what software licenses mean, here is a good and short guideline: https://choosealicense.com/

Unit tests
Unit tests indicate the project was probably well-designed, open for modification, and allow you to make sure your additional code does not break existing functionality.

Documentation
While documentation is usually a weak side of most open source projects, some basic documentation is required. Make sure it describes how to build the project, how to run tests, how to use it, what are contribution guidelines.

Continuous integration
Although the open source scene resembles the jungle or worldwide west, the opposite is true. Open source project usually involves the cooperation of developers from different locations and time zones. Without proper methodology, which includes continuous integration on a publicly available server, would not be possible. A few CI systems provide free service for open source projects, such as AppVeyor, Travis, CircleCI, and TeamCity.

Responsive 
No matter what you will contribute to an open source project, I assume you prefer a timely fashioned response. Any feedback is better than no feedback. Submitting a Pull Request ignored by a project owner might be frustrating. You can view the list of open Pull Requests and get an impression of the responsiveness of the project owner.

Nice 
Project owners might be very sensitive about their code. It can be understood; it's their baby, and they invested many hours to do it. However, polite communication that respects contributors is one of the key conditions to get new contributors to join the project. You may look at conversations on issues, discussions on closed Pull Requests to understand how nice the owner is.


I hope this blog post will help you to choose an open source project, and it will help you to improve your programming skills.

Monday 29 August 2016

Choosing an IoC Container talk at Israeli .NET Developers User Group

Last week I had the honor to hold a talk at the Israeli .NET Developers User Group. The subject was "Choosing an IoC Container", but the main goal was not to choose the best container ever, rather to present different features of IoC Containers and provide the tools to compare between them. Based on the feedback I received from the survey, it achieved the goal.

I would like to share the slides and the code samples presented during the talk.



Friday 29 April 2016

How to verify that a class is serializable?

Recently I've came into investigating a failing End-to-End test that was failing inside the WCF service with an exception. The exception was related to WCF serialization of the return type of the service. As usually I decided to tackle this issue in the TDD way:

  1. Write a fialing test that reproduces the issue
  2. Write the minimum amount of code to make the test pass
  3. Refactor if needed

I already had a failing End to End test that was failing, but it was a heavy and complex test. All I wanted to a small, fast, isolated and reproducible test that would test only the serialization of that class. We're using FluentAssertions library for readable and intuitive assertions in our unit tests I checked whether it contains a way to verify whether a class would be successfully serialized in WCF. Unfortunately, it had two similar methods:

I need to explain what these methods exactly do for those who are not familiar with them:

  1. Serialize the instance using the selected serialization method: binary or XML
  2. Deserialize the result of the above serialization
  3. Compare the values of the resulted instance with the original one
It was exactly what I needed, but these methods use different serialization methods than WCF. WCF uses DataContract serialization. I decided to contribute to FluentAssertions library and to add the required method. Dennis Doomen generously accepted my pull request and the new method is available in the official nuget package starting from version 4.5.0. Here how it looks like with the new method:


Last but not least: if you encounter into WCF serialization issues, take a look at my post from 2010 with some WCF Serialization Tips.


Thursday 3 December 2015

How to access TeamCity REST API from C#?

If you work with JetBrains TeamCity as your Continuous Integration server, you probably know that it has rich REST API that allows querying builds, their configuration, builds queue and also perform CRUD operation on them. It might be extremely useful for building custom monitor, triggering builds, cleaning builds queue and many other activities.

In this post I would like to present FluentTc: an easy to use library for all the above operations. When I started working on this library, I had in mind, that it should has fluent, easy to discover API. That's what I like in libraries I consume, so I developed a library that looks like I like it and I hope that you r will find it also usable and easy to use.

In order to get started to use it, you need to install the recent package from Manage Nuget packages -> Search FluentTc

or typing the below in your Package Manager Console of

install-package FluentTc 

So now, having the reference, let's get to the code.

In order to get all the build of specific Build Configuration, you can simply use:


If you are familiar with TeamCity REST API you might know that when retrieving list of entities, it returns only some basic properties of those entities, Id, Name and some Href. It also provides an option to retrieve additional properties. And this is how it can be done using FluentTc:



The above methods return default amount of builds as retrieved from TeamCity REST API. If there is large amount of builds, you'd probably prefer retrieving them with paging, i.e. a few builds each time. This is how it can be achieved with FluentTc:



Of course you can apply different query filters when retrieving your builds. For example, in order to retrieve not personal, pinned, successful builds, that ran during the recent day under specific build configuration, use this:


Credits:
FluentTc was inspired by Paul Stack's TeamCitySharp library.

For questions/suggestions feel free to comment below.

Sunday 15 November 2015

How to add some fun to software development?

A few days ago I gave a talk titled "10 ways to add fun to development process" at the ALM User Group in Microsoft Raanana. I would like to thank Elad Avneri, the group organizer, for inviting me to the group. During the talk I mentioned some tools and extensions and in this post I will summarize them.

For those of you, who missed the session, here a brief overview of it:

The development process is tedious and complex, we are trying to solve problems in different domains in limited time frames. So a little bit fun and sense of humor can relax the atmosphere in the team and make the work more productive.

Here are some tools that may help you to add some fun to your development process: