88 posts tagged with "programming"

This release candidate nearly wraps up the user management and volunteer work tracking functionality. There are a small few "should have" features that will be added in a future release. So what's new?

The .NET projects for FlightNode were created in several different Git repositories, thus giving us several small, well-contained, and re-usable projects. These small projects would be installed into the Service project as NuGet packages, which also makes for a faster compile in each discrete solution:

1. FlightNode.Common
2. FlightNode.DataCollection
3. FlightNode.Identity

But… this has approach has caused problems.

The first beta release of FlightNode is now alive and in the hands of testers. So what's been delivered?

Wow, you'd think nothing had been happening for the past two months. But that's not the case at all. There are now 6 different GitHub repositories (perhaps a few too many). November and December were heads-down coding months. But now the product is almost ready for an MVP launch... and that has me thinking about error handling. Specifically, logging.

Originally I decided to look into NLog for .NET logging, a product I've never used before. I have experience with the Enterprise Library logging block and with Log4Net, and find them both to be useful but not as... pleasant... as I would like. They don't have the interface I would prefer. But they work. It turns out NLog has basically the same interface, and the same tedious configuration.

In order to run FlightNode locally:

1. Retrieve all Repositories​

Make local copies of all the repositories mentioned in the Architecture page. Be sure to configure an upstream remote and follow the workflow described in Git Tutorials, Workflow, and GUI.

2. Start the Identity API​

Open the FlightNode.Identity solution in Visual Studio 2015. Open the Package Manager Console (menu: Tools > NuGet Package Manager > Package Manager Console).

The general problem, succinctly stated:

As human-dominated land uses replace native landscapes across North America, there is growing concern about the impacts this habitat loss will have on native bird populations. With many migratory bird species in decline, it is essential to assess the effectiveness of our conservation initiatives [1].

Of course, this applies around the world, not just in North America. There are hundreds of organizations and researchers working to understand the characteristics of current bird populations, and our impact on sustaining and growing those populations. The need for this work grows ever more pressing for those who recognize the value of maintaining diverse and vibrant ecosystems, especially in light of climate change [2].

Citizen-science: meet open source software. I'm starting an open source project called FlightNode, which will be a platform for citizen science bird conservation monitoring projects.

This project builds off the IbaMonitoring.org project I took on in 2010. I've been approached by a conservation organization here in Texas, asking for my help to build something similar to that site, but tailored for their purpose (I need to get their permission before using their name). What they want and need is more than I can provide in my "spare time." And I know of other programs that would be interested in using components of these projects.

The news has been going around: "refactoring doesn't work," say researchers. Code quality does not improve. It isn't worth the time and effort. Here's why I don't buy it — why the research is fundamentally flawed and real software groups should ignore it.

Does Visual Studio Code measure up to its close kin, Atom?

A friend asked me what I thought of Code. When I installed it a few weeks ago, my first reaction was: this is nice, if you're not used to Atom already. Never satisfied with a simple gut reaction, I thought for a moment, and realized that I had not looked closely at Microsoft's additions – particularly, debugging.

"Project T" is a temporary codename for a web application that I have begun developing off hours. Having just read The Phoenix Project, and now reading Continuous Delivery, I realized that the first step in creating a minimum viable product is to have a minimum viable process for continuous delivery, with no financial budget for that process. The solution combines a Microsoft Azure VM, GitHub, TeamCity, NuGet, Bower, Grunt, MSDeploy, and SoapUI. The result is this: as soon as I commit code to the version control system, it starts an automated chain reaction that ends with a complete install on my integration test servers.