83 posts tagged with "programming"

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.

A lightweight performance test harness for Windows console apps: PerfTestHarness on GitHub. Includes some fun use of C# 6 property initializers, string interpolation, nameof(), and expression bodied functions.

I've been misunderstanding .NET's List<T> for years.

Two incidents this week have driven home the value of being able to study the source code of frameworks I code with. One the one hand, I was using NServiceKit.OrmLite for database access, and needed to understand how it constructs its SQL. Through study of the code, I was able to find and remediate a limitation in the wildcard handling*.

Last year I read Jurgen Appelo's Management 3.0: Leading Agile Developers, Developing Agile Leaders. Despite taking many useful notes, I did not have the time to write up a full review / collect my thoughts on it. Overall impression: this books has tremendous value, and I recommend it highly to anyone in IT management / leadership (whether operations or software).

I look forward to re-reading it in the near future. For now, I will satisfy myself by re-collecting and re-pondering a few of those notes, starting with the topics of Knowledge and Diversity (from Ch 4 - The Information-Innovation System)

Over the weekend I had what at first appeared to be a small challenge: send out a few hundreds e-mails for a non-profit's outreach campaign. MailChimp and other mailings lists were not a good fit, as these messages were of the cold-call variety, and a formal mailing list felt too spammy. Initially I wrote a utility in .NET, but ended up solving with Node.js instead due to timeouts experienced with SmtpClient.

Desiring to learn about both Node.js (particularly as an API server) and ASP.Net Web API, I decided to throw one more technology in the mix and see which one is faster at relaying messages to a service bus, namely, RabbitMQ.

• Part 1: Test Runner
• Part 2: Initial Node.js Code
• Part 3: Web API Code
• Part 4: Enhanced Node.js code

Time to turn that Node.js test green. In Part 2, I succeeded in publishing a message to RabbitMQ using Node.js. However, my automated test failed: the .Net test runner could not handle the generated message. Three key elements were missing, which are required for the MassTransit .Net library to interpret the message correctly: