Bill Blogs in C# -- humanitarianToolbox

Bill Blogs in C# -- humanitarianToolbox

Created: 11/18/2015 6:17:00 PM

One of the major challenges we faced with the AllReady app was building a custom kudu deployment script. There is incredible power in this system, but it takes a bit of research, and a bit of help to get all the pieces working.

Let’s start with the simple goal: to make testing easier, we wanted to deploy to a live site automatically whenever we merged a pull request into master.

Azure supports this by default, including for asp.net 5 sites. Using Kudu was an obvious choice.

Adding Web Jobs

Life got complicated when we added a web job to the project. We added a web job because one of the actions the Allreedy application performs is to send messages to all registered volunteers. We don’t want to tie up a thread running in the asp.net worker process for the duration of sending messages through a third party service. That could take quite some time.

Instead, we want to queue up the emails on a separate webjob so that the site remains responsive.

Complicating the Deployment

That’s where deployment got complicated. You see, when we started, webjobs aren’t supported under asp.net 5 yet. The webjob builds using asp.net 4.6, using Visual Studio 2015. We also have one interface assembly that contains the types that are shared between the web application (asp.net 5) and the web job (asp.net 4.6).

So our build now includes:

1. Build the assemblies that are part of the web application using DNX.

2. Build the assemblies that are part of the web job using MSBuild. (Note that this means building one assembly twice)

3. Deploy the web site.

4. Deploy the web job.

Those extra steps require creating a custom deployment script.

Creating the Custom Deployment Script

Here are the steps we needed for adding our own custom Kudu script. There were several resources that helped create this. First, this page explains the process in general. It is a shortened version of this blog series (link is to part 1).

The first task was to create a custom build script that performed exactly the same process that the standard build script process performs. I downloaded the azure tools for deployment, and generated a deployment.cmd that mirrored the standard process.

You need to have node installed so you can run the azure-cli tool. Then, install the azure-cli:

npm install azure-cli –g

Then, run the azure CLI to generate the script. In my case, that was:

azure site deploymentscript –aspWAP allreadyApp/Web-App/AllReady/AllReady.xproj –s allready.sln

Notice that I’m directing azure cli to generate a script based on my xproj file. But, notice that this does not build the .csproj for the web jobs.

Before modifying the script, I wanted to verify that the generated script worked. It’s a good thing I did, because the default generated script did not work right away. The script generator assumes that the root of your github repository is the directory where your .sln file lives. That’s not true for allready. We have a docs directory, and a code directory under the root of the repo.

So, the first change I had to make is to modify the script to find the solution file in the sub-directory. After that, the script worked to deploy the website (but not the webjobs). Doing that build required three changes. First, I needed to restore all the NuGet packages for the .csproj style projects:

call :ExecuteCmd nuget restore "%DEPLOYMENT_SOURCE%\NotificationsProcessor\packages.config" -SolutionDirectory "%DEPLOYMENT_SOURCE%" -source https://www.nuget.org/api/v2/

Getting this right got me stuck for a long time. In fact, I needed to get some product team support during our coding event from David Fowler. The version of nuget running in Azure needs to use the V2 feed when it’s restoring packages for a .csproj based project. *Huge* thanks to David for helping us find that.

Next, we needed to build the .csproj bsed projects:

call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\AllReady.Models\AllReady.Models.csproj"
IF !ERRORLEVEL! NEQ 0 goto error
call :ExecuteCmd "%MSBUILD_PATH%" "%DEPLOYMENT_SOURCE%\NotificationsProcessor\NotificationsProcessor.csproj"
IF !ERRORLEVEL! NEQ 0 goto error

The final step is to deploy the webjobs. This meant copying the web jobs into the correct location. This step happens after the build, and before the Kudu Sync process:

mkdir "%DEPLOYMENT_TEMP%\wwwroot\app_data\jobs\continuous\notificationsprocessor\"
call xcopy /S "%DEPLOYMENT_SOURCE%\NotificationsProcessor\bin\debug" "%DEPLOYMENT_TEMP%\wwwroot\app_data\jobs\continuous\notificationsprocessor\"

The deployment script and the .deployment config are in our repository, so if you want to explore, check it out. Our repository is here: http://www.github.com/htbox/allready. And, if you want to help, check out the issues and send us a pull request.

Created: 8/18/2015 6:39:52 PM

Last weekend, Humanitarian Toolbox held a very successful coding event at That Conference. We got quite a bit done on both the crisis checkin and the All Ready applications. Thanks to the organizers of ThatConference, and everyone that attended during the weekend. I’m always impressed by how many developers join us there, and by how much they contribute.

OK, enough of the public service announcement. I wrote this post to help with a common issue: Pull Requests vs. Commit Privileges.

All the Humanitarian Toolbox projects use the Fork & Pull model for development. It enables us to keep the core contributor teams small, and yet enables anyone that wants to contribute to make changes and submit them. I, sadly, didn’t announce that clearly enough to all the volunteers when we started our event. Many of the volunteers thought we were using the Shared Repository Model.

That meant that later in the event, I had a number of developers come to me with issues because they could not commit to the main repository. That’s because they didn’t have the rights.

Announcement: Don’t fix this by just giving commit privileges. It’s not necessary.

Announcement II: Don’t fix this by trying to copy your changes and merging by hand. It’s not necessary either.

Thankfully, this is really easy to fix, once you understand how git works. It does also require using the git command line. The git command line isn’t that hard, and it’s important to learn as you do more with git.  If you ever run into this issue, follow the instructions below to fix it.

What Happened to Cause this Problem?

Before I explain the steps to fix the problem, let me describe what happened, and why it’s a problem. Look at the image below. It’s a portion of the main window in my Github for Windows application. You can see that I have two copies of Crisis Checkin on my local machine. The top one is the clone of a fork that I made in my account. The bottom one is the clone of the master HTBox repository. These two copies have different remote repositories.

 

ForkVsClone

 

If I run ‘git remote –v’ in both directories, you can see the difference. Here’s the output from my fork:

 

C:\Users\billw\Documents\GitHub\TheBillWagner\crisischeckin [master]> git remote -v
origin  https://github.com/BillWagner/crisischeckin.git (fetch)
origin  https://github.com/BillWagner/crisischeckin.git (push)

Note the difference when I run the same command in the main repository:

C:\Users\billw\Documents\GitHub\HTBox\crisischeckin [master]> git remote -v
origin  https://github.com/HTBox/crisischeckin.git (fetch)
origin  https://github.com/HTBox/crisischeckin.git (push)

When you execute a ‘git push’, you’ll send your changes to the git repository identified by origin (by default).  If you cloned the main repository, git will try to push to that main repository. If you forked, and then cloned your fork, git will try to push to that forked repository.

How to Fix the Problem (and not lose your work)

The goal is to push the changes you made in your desktop to a fork of the repository where you have commit rights. The drawing below shows the relationship between the repositories, and the commands used to create each one.

FreshPaint-0-2015.08.17-02.48.48

To save your work, and create a pull request, you’ll need to create a fork, and push the work you’ve already done to that fork. The specific commands are as follows:

Create your fork:

I usually create a fork from the github.com website. (Just press the “fork” button in the upper right corner). That creates a copy of the main repository in your account. This copy is also located on the github servers, not on your drive.

This fork is where you want to push your changes.

Add Your Fork as a remote

Now, you need to configure your fork as a remote repository for your working directory. Looking at the image above, you want to push from your desktop (where you have made changes) to the fork (the upper right repository).

You add a remote by typing:

‘git remote add fork https://github.com/BillWagner/crisischeckin.git’

Replace ‘fork’ and the URL with a name you want to use and the URL of your fork. I use ‘fork’ as the name, because it’s easy for me to remember.

You can add new remotes as long as the additional remotes are related to the origin remote. (Unless you start forcing git to do things. That means you can’t accidentally push your changes to crisis checkin to a fork of the Roslyn project (for example).

Now, your local copy is configured with two remotes: The source for the application (owned by HTBox) and your fork (owned by you). These two remotes are named ‘origin’ and ‘fork’.

Push to your fork.

Now, you need to push your changes from your working area to your fork. That’s just a git push, and specify the fork as the remote:

‘git push fork’.

By adding the extra parameter to the push command, you specify the remote repository where you changes should go.

It’s that easy.

Unless it isn’t. If it has been a while since you cloned the original repository, you may need to sync your working directory with upstream changes. That’s documented here. It’s  variation of what I just described, but you should be able to follow it.

Open the Pull Request

After you’ve pushed your changes to your fork, you can open a pull request to discuss your changes and get them merged into the main repository.

After I’ve finished this work, I will often make a new clone of my fork for a given repository. That way, the default remote (referred to by ‘origin’) points to my fork, rather than the main project.

I hope that helps.

Created: 7/23/2015 8:53:43 PM

This past Monday, Microsoft released the production version of Visual Studio 2015. Let’s get right to the lead: Visual Studio Community edition is free (for independent and Open Source developers). You have no excuse not to get this.

I’m not going to repeat all the information about the release and the total set of new features. Soma did that on his blog quite well. Instead, I’m going to focus on my areas of interest, and some of the resources I’ve written that can help you learn about these new features.

New Language Features

There are a number of new features in C# 6. Members of the team have been updating this page on Github with information about the new features.

I’ve written a number of articles about C# 6 for InformIT. The first four are live:

I recorded a Microsoft Virtual Academy Jump Start on C# 6 with Anthony D. Green, one of the program managers on the Managed Languages team.

And finally, I’ve written quite a few blog entries on the new language features. You can see a list here.

Language Service APIs

This version is particularly exciting because of the new compiler services that are part of Roslyn. These are a rich set of APIs that enable you (yes, you!) to write code that analyzes C# code, up to and including providing fixes for mistakes or other poor practices.

I’ve written an article for InformIT about the analyzers. You can read it here. I also did a Jump Start for Microsoft Virtual Academy with Jennifer Marsman.  If you missed the live event, watch the Microsoft Virtual Academy home page for updates. The recording should go live soon.

You can also learn more by exploring some of the open source projects that contain analyzers and code fixes:

  • Code Cracker. This project contains a number of different analyzers for common coding mistakes in C#.
  • DotNetAnalyzers. This contains a set of projects for different analyzers. Some manage particular practices. Others enforce rules, similar to the Style Cop effort.
  • CSharp Essentials. This project is a collection of analyzers that make it easier to adopt C# 6. If you don’t want to build it yourself, you can install it as an extension in VS 2015.

Humanitarian Toolbox and the All Ready app.

Finally, I was thrilled at the contribution from members of the Visual Studio team to Humanitarian Toolbox. Several members from different parts of the Visual Studio team worked for three days to build the initial release of the allReady application. The application source is on Github, under the HTBox organization.

This application was requested by the Red Cross. It provides features to lessen the impact of disasters on familes and communities. You can learn more about the project here on the Humanitarian Toolbox website.

The Visual Studio 2015 launch event included a profile of the developers and the process for building the initial code for allReady. You can watch the entire event on Channel 9. If you are interested in just the allReady app, and how it was built with Visual Studio 2015, look for the “In the Code” segments. There may be more In the Code episodes coming as the application grows.

All of us at Humanitarian Toolbox are grateful for the contribution from the Visual Studio team.

As a developer, I’m also grateful for the great new tools.

Created: 8/26/2014 3:20:32 PM

We are back from ThatConference after hosting another successful codeathon. I'm always thrilled to see the participation we get from our friends in the upper midwest. A couple dozen developers gave up their entire weekend to write code for Humanitarian Toolbox on the Saturday and Sunday before ThatConference. 

I also must thank Falafel Software for their generous sponsorship that enabled us to host the event again. We greatly appreciate the support.

We worked on two different applications while there: Crisis Checkin and the Humanitarian Data Bus.

Crisis Checkin

We spent two days working on the mobile applications for Crisis Checkin, using the Xamarin toolkit.We had a UX designer at the event, so we made the most of the opportunity. At the end of the two days, we now have UI screens for all the major interactions on all the major mobile platforms. We have an API design for the server side code, and we're ready to start implementing the WebAPI services.

Humanitarian Data Bus

The Humanitarian Data Bus is a new project. The purpose of this application is to provide a common interchange mechanism for disaster relief organizations. There's a large amount of data that different organizations collect during recovery and rebuild. This application will enable those different organizations to share that data. It will mean that everyone involved has better information, and therefore makes better decisions during the recovery and rebuild operations. 

The overall architecture was created, and the initial shell of the application was coded. It's had a strong kick start, and we'll be getting that code on our github page soon. When it appears, we'll be ready for more work and more pull requests.

Again, I want to thank our hosts at ThatConference. They did a wonderful job to make our codeathon a success. They provided space, food, and got the word out to interested developers. We couldn't have done it without your support.

Created: 4/10/2014 12:54:59 PM

I’m glad that I was selected to speak at self.conference, coming to Detroit this May. 

The speakers and sessions are a strong mix of the technical community in this area. In addition to quite a few local speakers, other super smart folks from the midwest are apeaking.

I’ll be speaking about TypeScript, introducing web developers to this new language. I really enjoy working with TypeScript. It’s very much like working with JavaScript, except that I feel much more productive. I get more done in much less time.

I also want to point out Tony Surma’s talk on “Apps that work when nothing else does.” Tony is a fellow board member for Humanitarian Toolbox, a charitable organization that creates Open Source applications for disaster relief. I’m the president and a board member as well. We’d love to have your help developing these applications. And, as you’ll learn from Tony’s talk, there’s a lot of software product skills you’ll learn developing apps that have to run in a disaster zone.

Self.Conference promises to be a great, great event. Go to http://selfconference.org/ and register today.  See you in May.

Created: 9/16/2013 3:37:06 PM

Well it's been heaven, but even the rainbows will end.
Now my sails are fillin' and the wind is willin'.
And I'm as good as gone again.
I'm still walkin', so I'm sure that I can dance.
Just a Saint of Circumstance, just a tiger in a trance.

    - John Perry Barlow

 

My last post was looking back, this one looks forward. I am truly excited about how I spend my time now.

I'm concentrating my time on the activities I enjoy the most: creating software that helps people, and helping developers become better at what we do. There's four different activities that are part of this plan.

First, I'm working with a set of awesome colleagues to launch The Humanitarian Toolbox. We are working with the global developer community to create, deploy, maintain and support software applications that aid humanitarian relief efforts. These are especially important in times of crisis. I've been doing volunteer work with them since February. I've been learning about current disaster response practices, and how software can enable relief workers to spend more time on what's really crucial: helping the people affected by the disaster. We're working with global relief organizations to identify needs. We're scheduling events to launch teams on the most pressing needs. We're working on the deployment and maintenance plans. I'm truly inspired to work with such a great group of dedicated people with one simple goal: Save lives and reduce the impact of disasters.

Second, I'm creating courses for Pluralsight. I'm excited to be part of Pluralsight. I've spent my entire career developing software and teaching software development to others. Working with Pluralsight gives me a new way to reach developers world wide and help them become better software developers. But what's more exciting to me is the community of Pluralsight authors. The list of Pluralsight authors contains people I've known and respected for much of my career. It also contains many of the smartest, most energetic rising stars in our industry. I get incredible energy from this group. It's the most gifted, intelligent and hard-working community I've ever been a part of. Every morning I log into the Pluralsight Yammer network, and join a group of great minds. There are amazing conversations about everything related to software development. If you're not already a Pluralsight subscriber, you should be. It's a great way to learn from our industry's best minds.

Third, you'll see me at more conferences. Both activities (Humanitarian Toolbox and Pluralsight courses) enable me to attend and speak at more conferences. At many of them, I'll be running Humanitarian Toolbox hackathons. At many, I'll be speaking on developer topics I believe that will help you be a better developer.

Fourth, I'm not done writing books. I think books and online training are both valuable resources to learn software development. And, I enjoy creating both. I haven't signed a book contract at the moment, but I'm working on a couple outlines for topics.

I'm excited about the wealth of opportunities ahead. I'm going to spend more time on technology, and on helping other developers improve their skills. I get to spend almost all of my work time on the activities I'm most passionate about. I'll continue blogging here regularly, and I'm inviting my readers to join the conversation. What do you want to learn? Are you interested in helping humanitarian toolbox create software? Let me know in the comments.

Created: 8/1/2013 5:32:29 PM
That Conference

ThatConference is just around the corner. There are two parts of the event where I'll have a big presence.

First, The ThatConference GiveCamp. I'm one of the project leads, for the volunteer checkin system. Visit the link above and you'll get a great overview on what we are building. The GiveCamp / Hackathon takes place on Saturday and Sunday. Come join us, and build some code that can have a real impact on people. We can make humanitarian response more efficient, and literally save lives. The other project being developed at the ThatConference GiveCamp is the Mobile Based Emergency Training project that Humanitarian Toolbox started at DevTeach. Phil Japikse will be at ThatConference and leading that project again.

Also, a big thanks to Telerik for providing Humanitarian Toolbox with copies of their tools for the projects we are creating.

I'm also excited to be speaking there this year. My session will discuss the reasons to minimize the use of async void methods. Come join me on Monday afternoon and get your async on.

Finally, I'm going to be doing more work for Humanitarian Toolbox between other sessions. The main focus of Humanitarian Toolbox is to own the projects over time. We want them ready to deploy when disaster strikes. I'll be hanging out, adding more code to the crisis checkin tool. Please join me. I'll post on twitter where I'm coding.

If you're coming to ThatConference, join us.

Created: 5/23/2013 7:18:17 PM

I’m a bit late getting this up.  It’s been one of those months.  I’m attending and speaking at my first ThatConference this summer.

That Conference

My talk is on the dangers and misuses of void returning async methods in C# 5.  I’ll discuss the problems with that practice, and go over some of the practices that can be used to avoid that practice. It’ a wicked strong lineup of speakers and content, and I do hope you can make time to attend my talk.

Human-Toolbox_Logo_RGB

I’m also going to be running a hackathon/GiveCamp for the Humanitarian Toolbox. Right now, we’re working with disaster relief experts to pick the right project. If you want your software to make a difference the next time there’s a natural disaster, like the tornados in Oklahoma this past week, come to ThatConference the 10th and 11th to participate. Write some code. Change the world.

Created: 5/20/2013 8:19:15 PM

The Humanitarian Toolbox is hosting its next Hackathon at DevTeach in Toronto.

DevTeach2013-647x205-7

DevTeach is a fantastic community-led conference that is celebrating its 10th anniversary this year. Many of my friends in the MVP and RD communities are speaking there. It’s a fantastic way to learn more about software development, and grow your skills.

This year, you can give back as well.

HumanToolBox647x205

You can spend one evening (May 30th) using your skills to build software that makes relief workers more efficient when disaster strikes. Attend the Humanitarian Toolbox hackathon at DevTeach. Help build the next generation of life-saving tools to meet the needs of relief workers. Your skills can save lives.

We held our first hackathon at DevIntersections in April.  (You can read about the experience on my previous blog entries). We’re hoping to build on that momentum during a number of conferences this summer. DevTeach is our first chance to grow more. Richard Campbell (yes, that Richard Campbell) will be hosting this hackathon.  If you are going to DevTeach, please join us.

scheduling note: Due to family events (happy ones), I can’t make this conference. I’ll be at other upcoming events later this summer and fall.

Created: 4/11/2013 8:51:52 PM
Awesome. There's no other word. This was positively awesome. On the 10th, we built on the foundation we created on Tuesday. We spent the entire evening coding. The event was supposed to end at 10:00. Everyone asked for "15 more minutes to finish a couple cards". Two hours later, at 12:30 am, we finally left. The best part was that we had finished the key features we came to build. Tony Surma, Microsoft's CTO for disaster relief response said, "if a disaster hit tomorrow and I deployed this, it would get used already. It's better than what's in the field today." A lot of credit goes to some very dedicated people. First and foremost, credit goes to the conference attendees that were part of the hack a thon both nights. We didn't know what to expect, and as a result, we'll plan better in future. The folks were patient, and helped us drive the forward. We got great ideas, lots of energy, and most of all: Working Software. WP_20130410_009 Also, a quick tip of the hat to Aaron Skonnard and Pluralsight. Everyone that participated by making at least one checkin got a free month subscription to the entire Pluralsight library. Selfishly, I hope they learn more, and help us build more software for Humanitarian Toolbox. (Disclosure: I'm working on my first Pluralsight course.) Brian Randell did a lot of behind the scenes work to setup web hosted TFS for us. He also helped us test and work with the Git TF bridge so attendees could use whatever they felt most comfortable with. (And, he helped me get more familiar with TFS and it’s features.  He was a great help.) Three people deserve extra thanks: Ward Bell, Julie Lerman, and John Papa. The team wanted to apply what they were learning at the conference, and selected breeze, HotTowel, and Entity Framework Code First for this project. John, Ward, and Julie all gave up quite a bit of time to help. They paired with attendees, explaining as they coded, or guiding their pair (sometimes me) around the code and libraries involved. Pure bliss: Learning and building super useful software at the same time. WP_20130410_003 For examples of what they did, John told me he and Ward would "try to stop by for about 10 or 15 minutes" to help a bit. They were both helping for at least two hours. Julie stayed until she was in jeopardy of missing her flight. (She did make it). 756607639   We had quite the cast of characters show up and ask how they can get involved as this continues over time. At future events, you may see Phil Haack, Scott Hanselman, Damien Edwards and other familiar names helping out. All of those said they would have helped this time, had they known more about it earlier in the process. I can't close this "thank you" section without mentioning three other very important people. Mari Sessions took on every task that doesn't involve code (she's got a business background, not a developer background). I have no idea where she gets that much energy. She organized the room, promoted the event, walked up and down the halls asking random conference attendees if they wanted to participate. Arranged refreshments, made everyone feel welcome, and made the event happen. Tony Surma, Microsoft's CTO for Disaster Relief, kept us focused on the problem at hand. He's gone to disaster sites and written code while in the field. His experience and knowledge of disaster zones and the problems relief workers encounter in the field was invaluable. I'd be remiss if I didn't mention that he's also a super smart tech guy, and can just pitch in and make things work. Also, an extra hat tip to Microsoft.  They are providing free TFS hosting, Azure hosting, and other help supporting the effort. Furthermore, they are not mandating any technology decisions that we make. They are being a great partner to help us build software to solve real problems. And finally, without Richard Campbell, this doesn't get off the ground. I'm thrilled to be working with Richard on this. The reason is simple: when Richard gets behind an idea, things happen. Ideas turn into action. Tony started using the phrase "turn innovation into impact." That sums up Richard's contributions well. What we started only has meaning when it gets in the hands of real relief organizations during a (sadly) real disaster. When that happens, real lives are saved because those relief workers can do more. Richard brings energy, drive, and makes it happen. I'm glad he invited me to join. Finally, this last week can't be a one time event. It's got to be the start of long term commitments to create software that helps relief organizations respond to disaster events. Richard, Tony, Mari and I will be meeting in the coming weeks to go over what we learned. We're going to push code into release cycles. We're going to plan more events. We're going to create a plan to involve more people. Join us: When disaster strikes, code saves lives. If you're interested, signup at humanitariantoolbox.net and well keep you informed.
Created: 4/10/2013 4:23:43 PM
I’m really happy with the response we got from the first night of the Humanitarian Toolbox hackathon at DevIntersections. We’re creating innovations that have a real human impact. WP_20130409_001 We didn’t really know what to expect.  Would conference attendees give up a free night after a day of learning new technologies to build more software?  Thankfully, the answer was yes.  We had a great team of developers helping us start building a crisis checkin system for disaster relief workers.  I’m confident that if we get some of the right people to attend tonight, we have a chance to make significant progress on the user stories for our first sprint. It was great to see developers that hadn’t even met each other sit down, discuss designs, create code, and help us build software to make disaster response more effective. There were three key events that make me very excited about where this can go:
  1. We were starting from nothing, and this morning we have working software.
  2. The folks that came wanted to apply what they’ve learned at DevIntersections to this project (more below).
  3. We continued to get commits after we all left at 10:00 pm.
One of the main sessions yesterday was JavaScript Jumpstart, where he explained his HotTowel template to attendees.  Our first app is using the HotTowel template. Thanks to John Papa for creating a great framework, and inspiring the team. The big goal is that this is the start of something.  It’s not a one time event.  We need to continue building software, creating real applications that real relief workers have asked for.  We’re using innovation to create real impact in real disaster situations. We’ve got another session tonight at DevIntersections, where we plan to finish the user stories that are in progress. If you’re at DevIntersections, please come by and help.  If not, don’t worry.  After this hack-a-thon, we’re going to open the source control system and the task board to everyone. We’ve got a few tasks to get done to make that happen, but we’ll get it done. Overall, I’m really impressed with the beginning we made.  I’m constantly impressed by the commitment, dedication, and contribution the software development community will make.  We are asking developers to give up their free time to build software that aids relief workers. We are getting great response.  I’m excited to see what we’ll build next.
Created: 3/28/2013 7:50:04 PM

I've always found that developers are very interested in contributing their skills and their time to help others.

I'm excited to be part of a new opportunity for developers to help others: The Humanitarian Toolbox.

The Humanitarian Toolbox  is the brain child of Richard Campbell, of .NET Rocks fame. The concept is to have developers create Open Source software projects that solve real problems for disaster relief organizations. A group of people, including Richard and I, have been working with global relief organizations to determine what they need most. We've already got a list of more than a dozen application ideas.

It's time to start building. We've picked the first project: a relief worker check-in system. This system would enable relief workers and volunteers to check-in and check-out at a disaster site. The field coordinators would have better information about the skills and the availability of relief workers, enabling them to better deploy the people that have volunteered their time to help. Relief workers and volunteers would get assignments and locations directly on their smartphone. The end result will be that relief workers are more efficient while on site, and more lives are saved.

We need developers that want to build this app.

Humanitarian Toolbox is hosting a hack-a-thon at DevIntersections. I'm working to organize the event, and help organize developers (like you) interested in participating. We plan to create a small proof of concept for the relief worker check-in system during the hack-a-thon. After the initial hack-a-thon, we want to enlist the broader community to continue building the app.

What's our deadline? We'd like it in place before the next natural disaster happens. We don't know when that will be, so we'd like to keep building and have it ready as soon as we can.

If you're going to be a DevIntersections, join us. Contribute your talent and help relief workers save lives. If you're not going to DevIntersections, there's still plenty to do to help. Follow us on twitter: @htbox or the hash tag for the event: #HtBox. We'll have plenty more software to build after the hack-a-thon. For us to be successful, we'll need to keep building and enhancing software for relief workers to battle the next crisis.

Write some code, help the world. Contribute to Humanitarian Toolbox.

Current Projects

I create content for .NET Core. My work appears in the .NET Core documentation site. I'm primarily responsible for the section that will help you learn C#.

All of these projects are Open Source (using the Creative Commons license for content, and the MIT license for code). If you would like to contribute, visit our GitHub Repository. Or, if you have questions, comments, or ideas for improvement, please create an issue for us.

I'm also the president of Humanitarian Toolbox. We build Open Source software that supports Humanitarian Disaster Relief efforts. We'd appreciate any help you can give to our projects. Look at our GitHub home page to see a list of our current projects. See what interests you, and dive in.

Or, if you have a group of volunteers, talk to us about hosting a codeathon event.