Projects on csMACnz's Blog

Vibe Coding up a Vibe Blogging Machine

Tue, 07 Apr 2026 01:11:00 +0000

Introducing VibeBlog, my playground for exploring GitHub’s agentic workflows (that’s the whole AI-powered automation thing everyone’s talking about). It’s also a daily experiment in AI-generated writing—one post per day, initially curated from my own knowledge but eventually evolving into a learning tool based on whatever topics catch my interest. The goal? Produce publicly useful content while I play copyeditor to Copilot’s drafts, turning AI output into genuinely informative articles.

Seriously, as a learning exercise in various Github Copilot features, it has been great fun to build out a daily generated blog site with minimal human-in-the-loop vibes.

What follows is a bit of a diary of the development and how I got here.

The Setup

I didn’t start by “writing posts.” I started by building a machine that could publish them reliably.

When creating a repository in GitHub, you can start with an initial prompt, So I did.

A static site generated blog. Articles will be written and stored as markdown and rendered as a static site. Uses GitHub Actions to build and publish. Agwntic instruction files will support copilot agent tasks to write the posts.

C# is the preferred language for any code used in this repository

Yeah, I went with what I know, C#. I could have left it up to the AI but I did want to at least feel confident that what it produced was valid, safe and maintainable code.

While I did review what it created, I left this as the first prototype and commited without change. As I went on, reviews often fell into more of a YOLO camp, but I did try to stick to a couple of guardrails:

Read everything before it gets merged
Don’t produce any commits directly

(I only had a couple of late-stage exceptions to that second rule, due to trying to save a few premium session tokens on one-lineer changes.)

This PR was complete enough that will a few extra clicks to enable GitHub Pages, I had a live blog with a working generator and deploy pipeline within minutes of creating the repo. From there, I just iterated on the codebase and the agentic workflow, with the goal of making it more robust and more automated over time.

From this point on, every PR started as an agentic session prompt, and proceeded as a Pull Request collaboration workflow.

I went straight into a CICD mindset and added automated tests, especially leveraging playwright, and some GitHub Actions for doing more robust build and deploy. The first prompt out of the gate did manage to provide a build and deploy which was great.

It looks like we gave no tests. We should add some xunit and playwright .net tests for both the generator app and the generated site. These tests should be part of the github actions, and verified against pull requests too.

Fortunately for me, I was able to give a very vague prompt for CI and it ran with it, producing more and better that I probably would have even thought to ask for.

Review the github actions for build and test and offer improvements

I went through a short manual testing and feedback phase at this point, where I identified some bugs. Since I was already using a custom domain for GitHub Pages, it did require a little bit of change to make the expected relative paths work, but that was a quick fix. From this, I layered on some extra integrity checking of the site as well.

I managed to even get it to scrape my styles from the existing blog for consistency. This was a lesson on the Github copilot Firewall configuration. It wasn’t perfect, but it got the job done with a bit of iteration.

Updating site design to align with parent blog

The style of the site needs updated. Id like to follow the style of the existing parent site blog.csmac.nz Ensure the pull request has a screenshot of the design attached as a comment. Please make sure you also download background images referenced in the css for reuse in this site as well

As I went, I tried to add additional improvement to both avoid regression, and add automation to catch the same or similar issues from resurfacing. Each time it did something wrong, I would correct it, but ask it to “remember” essentially.

Please fix this articles title length.

Please also update the agent prompts to always enforce this, even if the title provided is too long, enforce a shorter alternative title to the suggested one. This restriction is higher priority than keeping the suggested title.

Becoming a publishing platform

The foundations were set, now the writing could begin.

This went through a couple of refining phases:

Updating Copilot agent instructions toward the actual writing style

Take a look at my site https://github.com/csMACnzBlog/csMACnzBlog.github.io and improve the writing style guidance to match my writing style in github copilot markdown instructions

Enhance blog-post-writer style guide with patterns from csMACnzBlog

I would like a review of the writing style from the articles on blog.csmac.nz compared with the writing style used in this VibeBlog so far. I would like to enhance the style guides in this repository with any missing refinements or details for producing future posts.

This improved the voice of the articles. These two prompts together did a great job of refining the style and tone of the writing, and I was pretty happy with the results. It was able to pick up on some of the nuances of my writing style that I hadn’t explicitly called out in the instructions, which was great. The final blog-post-writer.md agent is now pretty detailed and specific, and I think it will do a good job of maintaining a consistent voice across future posts.

Robustness phase

I followed up by adding some more robustness to the publishing process, with a focus on making sure that the quality gates were in place and that the agent instructions were well-defined and versioned. This included:

Featured image support: PR #20 (merged 2026-02-27)
https://github.com/csMACnzBlog/Vibeblogging/pull/20
Adding baseline validation steps to that setup flow: PR #102 (merged 2026-03-28)
https://github.com/csMACnzBlog/Vibeblogging/pull/102
Pagination (15 posts/page): PR #62 (merged 2026-03-18)
https://github.com/csMACnzBlog/Vibeblogging/pull/62
Search page via lazy-loaded modal iframe: PR #64 (merged 2026-03-19)
https://github.com/csMACnzBlog/Vibeblogging/pull/64
Search UX fixes + tag focus/order: PR #66 (merged 2026-03-19)
https://github.com/csMACnzBlog/Vibeblogging/pull/66
Clicking a tag opens search pre-filtered: PR #103 (merged 2026-03-29)
https://github.com/csMACnzBlog/Vibeblogging/pull/103

Image Generation

This took a few iterations to get working but I was able to leverage some python and the Hugging Face API to get some blog images being generated for me as part of the build process. This was a fun one to iterate on, and I had to learn a bit about how to use the Hugging Face API and how to handle credentials in GitHub Actions. I tried out the familiarity of Powershell to start with but in the end went with what the models know best - Python. I also had to iterate on the prompt a bit to get it to generate images that were actually relevant and looked good. I ended up with a pretty good prompt that I can reuse for future image generation tasks as well. Maybe as a reduction exercise I’ll see if I can migrate what I have back to Powershell, but for now I’m happy with the Python solution.

Image generation pipeline moved from PowerShell → Python + HuggingFace client: PR #21 (merged 2026-02-27)
https://github.com/csMACnzBlog/Vibeblogging/pull/21

It did take a bunch of trial-and-error to get the credentials and API calls working correctly, but I got there in the end. The images are now being generated and uploaded to the site as part of the PR generation lifecycle process, which is pretty cool. Most of my drama came from fighting different environment sandboxes and differences between Copilot, and Workflow.

I even did a bit of experimenting with the new https://github.github.com/gh-aw/. It is pretty cool, but wasn’t the right tool for this particular job, since the repository sits public in the open. But I have some ideas for how I might be able to leverage it in the future for some of my more private repositories, so it was worth playing around with it a bit.

Finishing the automation

I had a pretty good workflow going at this point, but I wanted to get to the point where I could just merge a PR and have it go live without any manual steps. This involved making sure that all the quality gates were in place and that the agent instructions were well-defined.

I was still triggering and reviewing the daily post generation manually, but I wanted to get to the point where it was fully automated. So I tried a few different strategies and landed on the following approach:

In another repository, I trigger the creation of a new Issue into the repository, and assign it to Copilot to work on
Copilot then creates a new branch, and starts working on the post in that branch, using the agent instructions and style guide to produce the content
Once the post is ready, it creates a PR from that branch into main, and assigns it to me for review
Another automation checks over the PR for quality gates (links, accessibility, etc) and if it passes, it merges the PR automatically, which triggers the build and deploy process to publish the new post

I read every post daily. So far I haven’t really had to make any changes to the articles, and find them both accurate and interesting to read.

I even followed up with an automation that can investigate a topic suggestion and raise a more detailed Issue. If one of these is present, it uses that to assign to copilot instead of the generic “write a post about X” issue. This allows me to have a bit more control over the topic and the direction of the post, while still leveraging the automation to do the heavy lifting of writing and publishing.

A working system

By early April 2026, the engineering arc looks like this:

A C# generator that deploys cleanly to Pages (PR #1)
CI + testing from day one (PR #2, PR #4)
Deployment correctness handled early (subpath link fix) (PR #9)
Publishing quality gates baked in (PR #10, PR #105)
Agent instructions + setup treated as versioned system components (PR #5, PR #6, PR #24, PR #102)
Media pipeline with real-world credential iteration (PR #20, PR #21, PR #88, PR #92)
Scale features (pagination + search) (PR #62, PR #64, PR #66, PR #103)
A daily agentic publishing workflow that’s been battle-tested through break/fix cycles (PR #68, PR #79–#86, PR #77/#87)

Towards this later couple of weeks I’ve been focusing more on the main site and blog, trying to tie this new part into the larger site more seamlessly. This has identified many opportunities to apply similar learnings back to the way I opperate in the rest of the site’s development.

What’s Next?

Well I’m pretty well set up for the moment. At some point topic choice might get interesting, and I don’t know what the LLM is going to do. I do have my mechanism to generate topics and topic notes, so perhaps that feeds it for a while. It is one I am very interested to watch.

Otherwise, I just need to keep an eye on the daily workflow and make sure it doesn’t break. I have a good sense of what the failure modes are, so hopefully I can catch and fix them quickly if they come up. And since it runs on GitHub workflows, I get notifications when it fails, so that should help me stay on top of it.

Security is always a concern, but since this is a public repo with no sensitive data, the main risk is someone trying to break the workflow or inject bad content. I’ll need to monitor for that and be ready to revert if necessary. Hopefully I’ve locked down enough of the accesses that it is resilient to obvious attack vectors.

Appendix

Some of the PRs are referenced directly for your interest and further reading.

An almost seamless transition from Ghost to Hugo

Tue, 10 Aug 2021 20:30:00 +0000

Well, I finally did it. Ghost has been sitting on an older version for a long time, my certs were expiring, and I did something about it.

TL;DR;

My blog engine and hosting were deteriorating fast, so I moved to GitHub Pages, Hugo, and Static Site Generation, (mostly) without losing or breaking anything.

Synopsys

Years ago I moved from WordPress to Ghost. This let me get on with writing and not worrying about the hosting. I moved it to Azure and even added a dynamic SSL certificate rotator using Lets Encrypt.

Eventually, the cert rotator broke, and the blog engine got enough major versions behind to make the upgrade path non-trivial to fix. Not to mention Google Ads decided my site wasn’t good enough for them and so disabled any ads that could have shown up. Hosting costs on Azure, while small, were a factor to think about too.

Around the time I decided to do something about it, I also started paying attention to other people using static site generation to host their blogs. It didn’t take long to find a few really great articles that showed how simple this was going to be. The simplest of which seemed to be Hugo on GitHub Pages. So that is the path I went down.

What went well

My initial research was well-founded, and I very easily found the tool jbarone/ghostToHugo designed for the job.

Initially, everything was super simple, and I had my content in Hugo in under an hour. Mainly I was following youngkin’s article: Create a Free Blog Site Using GitHub Pages and Hugo, and then using ghostToHugo for my content.

Install Hugo CLI locally
create basis repository setup with the suggested theme youngkin
export my Ghost backup
install ghostToHugo tool
run ghostToHugo to migrate posts into the site
run locally to test

(I’m not repeating details here, because youngkin has it nailed.)

Getting this running on GitHub Pages was easy following that article too. Even setting a CNAME and DNS (a temporary subdomain while testing of course) was nice and easy to get working. (I use DNSimple.) Job done. Right?

What went wrong

RSS. My RSS feed has been a bit of an issue really. I knew it would probably break, and it wasn’t even available out of the box on Hugo either. So I fevered away adding RSS generation to the site generation and getting a fair approximation of my old feed. I knew it wouldn’t be perfect, but I learned a bit about how the templating engine worked along the way. And when that hot cutover day came, it certainly failed. I had a few bugs to fix and all 50 people who have added this blog to their feed probably got a bit of a noisy mess. But hopefully, as they now read this article they now understand why. Also, there are now sub-categories with sub-category RSS feed URLs linked to from the right-hand sidebar now.

Custom Theming. I built my custom theme way back when I moved to Ghost. And I didn’t really feel like losing it. So I painstakingly mapped it from the Ghost templating engine to the one Hugo uses. This sucked. and it took ages (weeks) to get it right. Along the way, I probably did make some improvements that will be valuable later, like fixing the sidebar and better image handling possibilities. But this was probably the most time-consuming part of the whole process. In the end, retrologs’ Creating a Hugo Theme From Scratch was super useful at figuring out what went where, but I don’t actually understand some parts of the collection lookup code I wrote in some places yet. But it worked. At the very least, my CSS appears to have held the test of time (surprisingly!).

Permalinks. Turns out Ghost had a few permalink redirect capabilities. And also the default URLs in Ghost were /slug-for-page/ while Hugo is /post/slug-for-page/. Luckily the Aliases feature in Hugo allowed me to add both the draft/preview link (/p/<GUID>/) as well as the old URL so that hopefully, no one loses my content, and instead get bounced to the right place.

Disqus. See the comments at the bottom? I’ve been using Disqus to make them available. Turns out this was quite useful in moving to a static hosted solution. For the most part, this went well, because Disqus actually have a migration tools feature available to use to move the URL associated with a page. The what went wrong part was that I prepared all the pages that looked like the normal post URL (/slug-for-page/) before I cut over my DNS, but didn’t map any of the preview URLs (/p/<GUID>/) across. I think what happened is that Ghost provided an id to Disqus as well as a URL, and it uses the first URL it sees as the identifying one. When I preview drafts, that preview URL is the one it saves. Since Hugo is just using the actual URL and not the id anymore, I lost my mapping over a few pages which I neglected to migrate. (My incorrect assumption was the draft ids didn’t have comments 😢.) I was without comments on some pages while I remedied that across a couple of evenings. It wasn’t too bad to put together a new CSV file for that though in the end.

Google Ads. Turns out they are still not happy with my website (and neither am I to be fair) so there is a bit more work to get them reenabled. It barely makes dollars a month, to be honest, but with it not working it makes a lot less of course.

Content. I spent far too much time looking at my content. While Ghost had tags, Hugo has both Tags and Categories. I went through every historic post (193 over 13 and a half years if you can believe it) and updated many tags (deleting a bunch, adding a few) and creating categories for my content. I could have spent days (and still might) tidying up some of the content that never had any attention since coming out of WordPress and getting auto-converted to markdown all those years ago. But I held back, since I wanted to actually get this process done and back to writing. There was a little bit of work migrating some of the image functionality over too, but for the most part that was fine, too.

Summary

Would I choose to do it again? Yes. I am certainly in a better place. So far, I think I’ve backed the right horse in Hugo. The workflow seems about as good as it was before, and I am aware of a few tools such as CloudCannon for better CMS management workflows if I desire. I might miss the Ghost app for drafts, but I mostly write on my desktop anyway. And since it is in GitHub, anything that can commit markdown to there is a way to draft.

Now that I have that done, the next step is likely to repeat the whole process with csmac.nz as well and fix its certs, ads, and content. (That last one has been bugging me since I moved to Ghost to be fair… ¯\_(ツ)_/¯)

Time-tracking Analysis - Parsing and Presenting a Heatmap of your working week from Toggl Data

Mon, 27 Aug 2018 06:00:00 +0000

As a remote worker, I need to keep myself honest. This is as much “Make sure I do my hours” as it is “Don’t overwork!”. Anyone who has worked from home or remotely for a period of time understands what I mean completely.

To monitor this, I use Toggl. Toggl is time-tracking as a service, which includes cloud tracking data storage, annotating time against projects and clients, and Client applications for most if not all platforms including web, mobile and desktop. Tracking is even done server side so you can start your timer on one device, and stop it from another. As I say, you can annotate your time with Client, Project, even custom tags.

Toggl has a bunch of advanced time-coding features to produce reports against different projects. If you pay for their starter plan, it can even handle Billable Time. I don’t use any of that. I use their Windows Desktop client (which includes idle time detection to easily clear AFK time) and their online data storage, to hold onto my data for me.

I created this little tool to help me visualise my work patterns as a bit of a heatmap. This was a way for me to answer the question “What are my ‘office hours’” as well as an indication of my work patterns for my team.

The instructions

Exporting Data

Using the Toggl Reports, I can select a time period of data I want to have access to. (Instructions here.) I select a range, say the last year, and then export as CSV.

Make sure that you are Exporting a Detailed report. Your file will be named like “Toggl_time_entries_2016-01-01_to_2016-12-31.csv”.

The format of this file should be like this:

User,Email,Client,Project,Task,Description,Billable,Start date,Start time,End date,End time,Duration,Tags,Amount ()
First Last,first.last@email.address,,,,"",No,2016-05-04,10:00:00,2016-05-04,13:00:00,03:00:00,,
First Last,first.last@email.address,,,,"",No,2016-05-04,14:00:00,2016-05-04,16:00:00,02:00:00,,

In theory, anyone could create a CSV in this format and this tool will work just fine for them too. I only use the Start date,Start time,End date,End time,Duration fields anyway.

Process the data

Now that I have a local CSV file, I can process it through my application.

I have made this available as a dotnet tool, so you can easily install it globally and run it from anywhere.

# install globally
dotnet tool install -g TogglHeatmap

# if installed globally, this should just be available on your path
TogglHeatmap <args>

# install into a local folder
dotnet tool install TogglHeatmap --tools-path tools

# if installed into a tools path, you can run it from there.
.\tools\TogglHeatmap <args>

For those new to tools, there is also an update option if newer versions come available, as well as a version parameter if you require a specific version:

dotnet tool install -g TogglHeatmap --version 1.0.0
# update doesn't support version but instead gets the latest
dotnet tool update -g TogglHeatmap
# to replace with a specific version, first uninstall, then install with specific version required specified.

At this stage, the args for the application are as follows (subject to change, check TogglHeatmap --help for latest):

# Start and End dates
TogglHeatmap dataFile.csv 2018-01-01 2018-06-01

# Start and week count
TogglHeatmap dataFile.csv 2018-01-01 26

This should produce a nice report of numbers to the console output:

> TogglHeatmap Toggl_time_entries_2017-08-15_to_2018-08-15.csv 2018-1-1 2018-08-15
Data from 1/1/18 0:00:00 to 15/8/18 0:00:00
First day: Monday
Number of weeks: 32
----
Time,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday
00:00,0,13,0,11,0,0,0
00:30,0,8,0,8,0,0,0
01:00,0,4,0,5,0,0,0
01:30,0,2,0,2,0,0,0
02:00,0,0,0,0,0,0,0
02:30,0,0,0,0,0,0,0
03:00,0,0,0,0,0,0,0
03:30,0,0,0,0,0,0,0
04:00,0,0,0,0,0,0,0
04:30,0,0,0,0,0,0,0
05:00,0,0,0,0,0,0,0
05:30,0,0,0,0,0,0,0
06:00,0,0,0,0,0,0,0
06:30,0,0,0,0,0,0,0
07:00,0,0,0,0,0,0,0
07:30,0,0,4,0,0,0,0
08:00,0,0,5,3,4,0,0
08:30,3,5,10,7,6,0,0
09:00,4,10,12,13,6,0,0
09:30,8,17,16,18,10,0,0
10:00,19,22,27,23,26,0,0
10:30,24,20,27,24,23,0,0
11:00,24,21,28,28,22,0,1
11:30,24,20,29,28,22,0,0
12:00,23,22,28,27,21,0,0
12:30,21,20,27,27,21,0,0
13:00,23,20,25,23,21,0,0
13:30,23,21,26,23,23,0,0
14:00,23,23,28,24,22,0,0
14:30,24,24,25,25,24,0,0
15:00,22,25,27,23,25,0,0
15:30,22,24,26,26,24,0,0
16:00,23,27,27,26,24,0,0
16:30,22,25,27,24,24,0,0
17:00,19,21,20,21,16,0,0
17:30,11,18,16,16,7,0,0
18:00,11,19,10,13,6,0,0
18:30,9,13,3,12,5,0,0
19:00,3,9,2,6,5,0,0
19:30,2,9,4,3,3,0,0
20:00,7,4,9,5,2,0,0
20:30,8,7,12,6,2,0,0
21:00,11,6,15,6,2,0,0
21:30,22,6,18,5,1,0,1
22:00,22,4,21,3,1,0,1
22:30,19,1,21,1,1,0,1
23:00,18,1,19,0,0,0,0
23:30,13,1,14,0,0,0,0
----

Copy the data above into a CSV file to make it pretty in a spreadsheet

We have our heatmap data, and we can copy and save it to a CSV file. Now we can do whatever makes sense to us to present it.

Spreadsheet UI

For instance, you may want to pull it into a Google Sheet. This should be similar for Excel if that is your office suite of choice instead.

First, create a new Sheet.

Take your CSV file of data you created before from the output. You can import that file into Sheets. Simply go to File->Import... menu, and in the popup and locate your file. Once you have located, uploaded and selected your file, you will get the second dialogue. In this dialogue Select where you want the data to go (for example Insert new sheet, or Replace current sheet) and choose Comma for the Separator type.

Once imported, you may want to conditionally colour the numbers. Select cell range from B2 to H49, Select Format->Conditional Formatting... from the menu. In the sidebar that opens on the right, select the Color scale from the tab at the top, ensure Apply to range is set to B2:H49 as selected before, And select the colours you want from the drop-down labelled Preview.

Click done to finish and enjoy your pretty picture.

Analysis

For me, this ‘graph’ above gives me interesting insights, such as that my day is 10am-5pm then Monday nights and Wednesday nights 9:30 pm until 1 am, But I am really working anytime from 8:30 am till midnight early in the week, 8 am till 11 pm later in the week. There is also no correlation for when I take lunch, but dinner break is some time between 6:30 pm and 8 pm.

These insights are easier to presume from the visual graph, and I can compare these graphs for different periods of the year to see how these insights change.

Conclusion

I’ve got a bunch of ideas to improve the CLI interface for TogglHeatmap. Including just using all the data as the date range without requiring entry. It might happen at some point, who knows? One of my other projects is working on an args parser library so this might be just another testbed for that at some point.

The source code is on Github at github.com/csMACnz/TogglHeatmap. Issues welcome.

Hopefully, someone other than me finds this useful. If not, I have found it useful to document the evolution of my working hours.

Beefeater - Guard your methods' Ins and Outs.

Mon, 06 Aug 2018 06:00:00 +0000

A little while back I started paying attention to Rust and got all inspired to have a bit of that it C#. The result was this library I called Beefeater.

This library contains helpers to add semantics to the optionality of your parameters and results from method calls. I built it on NetStandard1.0 for maximum compatibility.

Some of this will soon become obsolete with C# 8 features such as the C# 8 nullable reference types, but much of it gives you the power you need right now.

You can install the NuGet package using Install-Package Beefeater or by heading to the Nuget Package Page.

Last week I released version 0.5.0.

The basic idea is similar to the Nullable<T> type that exists for value types. But extend this into semantic markup around method arguments and return types.

The approach is to allow you to write declarative code, and let the library determine which part gets called.

To make this seamless, I’ve leveraged a few features of C#, namely the Implicit Casts, and Generics.

But just declaring optionality isn’t enough, so the goal is to go further and provide functions to write better safer code using these types.

The bits

The library is made up of a few different utilities and ideas.

Option<T> - declare a reference type as possibly null (C# 8 makes this obsolete, but implicit casts to/from the new syntax might work)
NotNull<T> - so you can declare something is certainly never null (or crash immediately rather than on dereference)
Result<TValue, TError> - Represents either a success result or an error (Modelled after Rust’s std::result)
Either<TValue, TError> - a more generic concept of a two-part Union type

There are implicit casts to and from (where sensible) these types when they are in use, so you only need to explicitly declare them in contracts, and occasionally in return types. Although, a bunch of work has been put in to avoid return types most of the type.

These classes have some consistent methods to help out:

Match - a function or action that is provided lambda Funcs/Actions respectively to cover both known states of the object.
HasValue - similar to the Nullable<T>
ValueOrDefault - to ensure you certainly get back a value
IsSuccess - a similar pattern to Nullable<T> applied to Result<,>

There was a theory of making an enum match but it wasn’t achievable. However again C# 8 might solve this with new pattern matching too.

There is also Resharper definitions provided to work with and be trusted by the Resharper Null static analysis.

Show me the code!

Option

As a simple example you may have a method like this:

public string Modify(string first, string second)
{
    if (first == null)
    {
        throw new ArgumentNullException(nameof(first));
    }
    if (second == null)
    {
        return null;
    }
    return first + second;
}

Typical code. A bit of error checking, and some switch logic based on an optional argument.

I don’t know about you, but it is hard for me to know that first is required, but second is optional. At least not without comments, or a thorough inspection of the code. Shouldn’t the signature tell me this? (C# 8 says it will.)

Lets take a look at this using Beefeater:

public Option<string> Modify(NotNull<string> first, Option<string> second)
{
    return second.Match(
        v => first + v,
        () => Option<string>.None);
}

var x = Modify("Hello", "World");
var y = Modify("Hello", null);

That is very clean to me. First, the signature tells us everything we need to know.

And when we look at the calling syntax, it is seamless. it works exactly as you expect. With one difference.

x and y in the example are both Option<string> type. This means you cannot pass this to a method that requires NotNull<string>, or even string itself.

Why? Well, clearly you have no idea if that result is safe. You know it is either a Nothing or a non-null string. (Is it both? Schrodinger’s Option<T>?)

The only sensible thing to do is to check, right? It would be unsafe not to. Thus the value of the library is revealed.

That check can use the Match method, too.

var x = Modify("Hello", "World");

var outputMessage = x.Match(
  some: value => $"The result is {value}",
  none: () => "There wasn't anything to report");

Console.WriteLine(outputMessage);

Your code will start to become very functional, but you will also get compile-type checks to ensure you are handling error cases correctly.

If you really want to live dangerously, though, there is an explicit cast back to the original type, that will throw a PanicException. This is basically the library equivalent to the NullReferenceException, but should normally throw earlier in your code when the Null is first observed, rather than late at dereference.

Much like async/await, this library is contagious and will ripple through your code, just FYI.

Result<TValue, TError>

Apart from Option<T>, the other most useful is the Result<TValue, TError>.

Again, you might have written:

public bool Create(string filePath, string second)
{
    if (filePath == null)
    {
        throw new ArgumentNullException(nameof(filePath));
    }
    if(second == null)
    {
        return false;
    }
    using (FileStream stream = File.OpenWrite(filePath))
    {
        using (var writer = new StreamWriter(stream))
        {
            writer.WriteLine(second);
        }
    }
    return true;
}

Again, a little cruft. Optionality unclear. But there is more. This method can and will throw a bunch of exceptions. FileNotFound, UnauthorizedAccess, and others. Your calling code is either going to handle many exceptions, or the app will crash. We could put the logic into the method, and the code would get complex. But how do we handle the return? returns true, false or Throws exception, how do you translate that into a concise return type of true, false or FileNotFound or Unauthorized or Other?

Beefeater says like this: (Rust too, actually…)

public enum ErrorResult
{
    UnknownError,
    FileNotFound,
    Unauthorized
}
public Result<bool, ErrorResult> Create(NotNull<string> filePath, Option<string> second)
{
    FileStream stream;
    try
    {
        stream = File.OpenWrite(filePath);
    }
    catch (UnauthorizedAccessException ex)
    {
        return ErrorResult.Unauthorized;
    }
    catch (FileNotFoundException ex)
    {
        return ErrorResult.FileNotFound;
    }
    catch (Exception ex)
    {
        return ErrorResult.UnknownError;
    }
    using (stream)
    {
        return second.Match(
            v =>
            {
                using (var writer = new StreamWriter(stream))
                {
                    writer.WriteLine(v);
                }
                return true;
            },
            () => false);
    }
}

To me, the business logic is very easy to read from this code. Again the signature is clear what to expect and how to use the result.

var result = Create("myfile.txt", someVar);
var outputMessage = result.Match(
  isCreated => isCreated
    ? "The file was created with someVar"
    : "The file was not created because someVar",
  error => 
  {
      switch(error)
      {
          case FileNotFound:
              return "File Not Found";
          case Unauthorized:
              return "The file is secure and you can't get it.";
          case UnknownError:
          default:
              return "An unknown Error occurred";
      }
  });

Console.WriteLine(outputMessage);

Just like that, every code-branch/edge-case has to be covered, or it will not compile. (Enum notwithstanding.)

Either

Either<T1, T2> is very similar to Result, except the semantic meaning differs. It allows a method to return either one type or another type.

public Either<long, double> DivideByTwo(int aNumber)
{
    if (aNumber % 2 == 0)
        return aNumber / 2;
    return aNumber / (double)2;
}

var x = DivideByTwo(10);
var x = DivideByTwo(5);

Recursion?

You could even nest these things:

Either<Option<string>, NotNull<int>>
Option<Either<Foo, Bar>>
Result<Option<string>,CustomError>
Result<Unit,string>

Different combinations will provide different value in different situations.

Unit? Yeah. When you go functional, representing void as a type is much helpful. I have another library where I get my Unit from, but there are literally dozens on Nuget.

C# 8

I’ve hung a lot of stuff on C# 8 in this article. At some point, I should cover what is coming (though at this stage nothing is certain). Basically, though, this library has been hanging around for a while, before nullable reference types was even being discussed publicly. So whether nullable reference types happens in 8, 8.1 or C# 9, this library is here today and can get you started thinking about different states of optionality in your code today.

Performance?

About that….

So I haven’t actually spent any time profiling to see if this is damaging your code. For most LOB apps, this will not be the bottleneck compared to IO. But it is a valid point and does need further investigation and optimisation.

From a development performance point of view, I do go slower to go faster. I think about and code up the edge cases up front, rather than doubling back when something goes wrong.

Attention!

So that’s Beefeater. I’ve started using it slowly on utilities and simple console apps. Hopefully, you find it interesting and it inspires you to think about how you handle your code yourself.

If you don’t like the ideas in this library, remember a Result<,> is just a tuple, a (string, ErrorEnum) if you wish. The rest is just boilerplate code you could write yourself. (Though I do handle all the error and state checking for you so you can just provide the Actions 😉 )

Coveralls.Net 1.0.0 Release

Mon, 04 Jun 2018 07:00:00 +0000

Christmas 2014. I was building out projects on GitHub in open source. The obsession with open source even went on to spawn a Series of Blog Posts. Each tool or library I was building lead onto another tool or library to make the build pipeline, or development process better. Often putting down one project while I sorted out another one first. This has continued at a slow pace for the last 3 years.

Back in January 2015 I Announced Coveralls.Net. This is a code coverage publisher for publishing your coverage results to the coveralls.io API. Coveralls.io is a coverage tracking service, which is free for open source projects, with a paid service for private use, and now an Enterprise version as well. There was a bunch of python and ruby versions, but I wanted fewer dependencies on those runtimes so built my own. I even managed to get it listed as one of the two recommended .Net coverage integrations on the coveralls.io docs.

While development has been a slow work of labour over the last three years, the announcement of dotnet CLI tools (proper npm-style tools, not the weird interim dotnet-tool stuff…) with dotnet SDK 2.1, I had to jump in and get on board.

Announcing 1.0.0

Which brings me to announcing Coveralls.Net 1.0.0. This is a dotnet CLI tools compatible version of csmacnz.Coveralls. Easier to install. Easier to update. And a whole bunch new features, including more coverage options, and better autodetection processes in AppVeyor.

# install globally
dotnet tool install -g coveralls.net --version 1.0.0

# if installed globally, this should just be available on your path
csmacnz.coveralls <args>

# install into a local folder
dotnet tool install coveralls.net --version 1.0.0 --tools-path tools

# if installed into a tools path, you can run it from there.
.\tools\csmacnz.Coveralls <args>

Now, I’ve been struggling a bit with beta 0.8.0. It hasn’t been easy to find time to test the new stuff I added, get others to test, and be happy to call it a stable release. But there was a bunch of new stuff and fixes in there. These have all rolled forward into the 1.0.0 Release now. (I might go back and call 0.8.0 stable now since it still works the old way. But for now the old way still works with stable 0.7.0 and 0.8.0-beta003.)

Still not happy/comfortable with using CLI tools? Not using 2.1? That’s ok. I’ve used the power of the self-contained app to provide a windows, linux and osx native version (Linux targets the cross-compat Linux target) in a zip file under the Releases folder on GitHub.

For windows in PowerShell you would use it something like this:

# The TLS change was necessary on my development machine
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

$zipDownloadPath="https://github.com/csMACnz/coveralls.net/releases/download/1.0.0/coveralls.net.1.0.0-windows.zip"
Invoke-WebRequest -UseBasicParsing $zipDownloadPath -OutFile coveralls-windows.zip
mkdir coveralls-windows
Expand-Archive .\coveralls-windows.zip coveralls-windows

.\coveralls-windows\csmacnz.Coveralls.exe

I hope to get more details added on the GitHub Wiki for linux and mac usage of the self-contained app, as well as updating all the samples over at Coveralls.net-Samples.

More targets

Since the first release, targeting OpenCover coverage files (the most popular at the time), this has been expanded to include Visual Studio Coverage, monocov, Report Generator, Chutzpah javascript coverage, lcov, NCover and Coverlet cross-platform .Net coverage (via its opencover file format).

What’s Next?

I’ve already started working on 1.1.0 while the dotnet 2.1 tools have been working towards stable.

Better autodetection functionality (including Travis and TeamCity)
dotcover support
parallel build support
add native coverlet support
Bug fixes that didn’t make it to 1.0.0
Complete and test Enterprise support

Hopefully, it won’t be soon before long that you will see an Announcing 1.1.0 Post.

Interested in following progress on this? I have a twitter account @coverallsdotnet That I am trying to be more proactive with. You can also track progress on the GitHub Project. Contributions welcome, though I hear I’m a bit of a stickler for quality and such. C’est la vie.

The irony of a coverage publishing tool only having 42% coverage wasn’t lost on me, so I got it up to 74%. Soon enough I should get that to 100%. Probably just in time for a version 2.0.0.

Need more?

Issues, feature requests or feedback? Just write up an issue on GitHub. I would love to hear your experience of using the tool, and I would love to expand the supported coverage formats to include your favourite tool.

Thanks for using it! It makes me more inclined to make it awesome.

New Projects - Consolable, ConcurrentConsole & t4tinytypes

Sun, 14 Aug 2016 21:51:20 +0000

I’ve been working on some new projects, so thought I would do a quick elevator pitch for each.

Consolable

I was having an issue with environment variables as arguments, and with PowerShell replacing "text" with text (stripping double-quotes) and how these interacted with my command line arguments. Especially when the environment variable was empty, the error messages were just not clear enough.

So I’m building yet another CLI parsing library, but with a primary focus on error messaging. It should work well to provide the developer the arguments from the user, but should also provide the user with better help on where the mistake they have made is.

Follow my progress here on GitHub.

ConcurrentConsole

I was wanting to build a chatbot. So naturally as a test harness I need a console app to test with. But it turns out my bot is asynchronous (I can keep talking, while it keeps thinking and returning new messages to an existing thread). It turns out that concurrently printing text and allowing text entry is not an Out-Of-The-Box feature.

Introducing ConcurrentConsole, a wrapper over System.Console to allow multithreaded writes while a thread is still reading from the user. Maintain your existing typed text, and even define your own prompt text (which can also be dynamically updated at runtime).

Check it out on GitHub and NuGet.

t4tinytypes

Something I have been meaning to do for a while was to automate my tiny types. It can get tedious to build and maintain many small wrapper types, and creating the right definition while in the flow of building out your code can be distracting.

t4tinytypes is a NuGet package of t4 templates that can be used with Visual Studio or the command-line (for dotnet cli) to generate and regenerate tiny types, simply, easily and flexibly (not to mention extensible). I’m still working on testing samples to show all the ways it can be used, but it should be published as an early alpha release soon.

While you’re at it…

That’s what’s new, feel free to influence me on what the think you would find valuable to have me finish first. But don’t forget the other little projects I’ve already put out there and would love feedback on, too.

Beefeater - “Guard your methods’ Ins and Outs.” - return and optionality semantics helper library
coveralls.net - a publisher for .Net code coverage to coveralls.io
BCLExtensions - extensive extensions and helpers for primative types
coveritypublisher - a publisher for Coverity Scan static analysis results

Feedback appreciated :)

Introducing PublishCoverity

Sun, 08 Mar 2015 17:34:21 +0000

As part of my open source development tooling investigation, I came across Coverity Scan Static Analysis. And thanks to Arkfps’ post I could automate the process of submitting the results. And now Appveyor includes Coverity on it’s images. But I decided to take his work one step further, and so I built a small utility to compress and submit the results.

PublishCoverity is available on NuGet, and has two use cases: Compress and Publish.

Compress takes a directory and compresses it to produce an output zip file.

Signature:
    PublishCoverity compress [-o <file>] [-i <folder>] [--overwrite] [--dryrun]

Example:
    PublishCoverity compress -o results.zip -i cov-int

Publish takes that file and some of your project data and posts it off to Coverity for you.

Signature:
    PublishCoverity publish -t <token> -e <email> [-r <name>] [-z <file>] [-d <desc>] [--codeVersion <version>] [--dryrun] [--nologo]
    
Example:
    PublishCoverity publish -t COVERITYTOKEN -e example@example.com -r MyUser/MyProject -z results.zip -d "my project" --codeVersion 0.1.2.3

Although this is still evolving, the gist of what is above will be available to compress and/or publish your results to Coverity Scan. The idea is that anything that I can reasonably determine for you I will try and make optional. Such as your repository name from the AppVeyor Build Environment variables.

I’ve already had a request to add some guards around the results to ensure they are valid and complete before sending, but right now version 0.9 is available on NuGet for you to install and use, and the source is available on GitHub All feedback and features requests welcome as GitHub issues, or just comment on this post.

Enjoy!

Introducing BCLExtensions

Sun, 15 Feb 2015 15:25:45 +0000

It has been a pipe-dream of mine for a while to have my very own C# extensions library. Well now I do. I’ve been chipping away at a library on github for ages (my init commit was 15 Sep 2012!) and it is finally a real thing! I’ve got a V1.0.0, a Nuget package, and even 100% coverage. I even have the coverity report running, although it’s taken so long that I don’t have anything to worry about right now. So far there are 24 Extensions available to use.

As a bonus, my library is a PCL using profile 328, which pretty much means it will work with any C# application you are writting. I even have it building and running all my test on Travis-CI (252 tests and counting).

Please feel free to grab the nuget at nuget.org/packages/BCLExtensions and check the source as github.com/csMACnz/BCLExtensions.

Next steps: keep knocking out the extensions from my wishlist, get resharper’s inspectcode.exe command-line tool running, and tidy up all the documentation onto the wiki and maybe on of the docs services.

Have suggestions? Or are there extensions on my list that you want me to prioritise? Open an issue and let me know.

Introducing Coveralls.net

Sat, 24 Jan 2015 14:33:48 +0000

So I’ve built an (almost MVP) code coverage publisher for coveralls.io from C# code, using opencover coverage results. Checkout the github repo and nuget packages if you want to use it. I’m even dogfooding it on appveyor as part of my psake build tasks.

So how do you use it? Well luckily I used docopts.net to give you a bit of a command line experience while you use it, but the gist is this:

csmacnz.Coveralls.exe --opencover -i opencovertests.xml --repoToken "abcdefghijklmnopqrstuvwxyz" --commitId $env:APPVEYOR_REPO_COMMIT --commitBranch $env:APPVEYOR_REPO_BRANCH --commitAuthor $env:APPVEYOR_REPO_COMMIT_AUTHOR --commitEmail $env:APPVEYOR_REPO_COMMIT_AUTHOR_EMAIL --commitMessage $env:APPVEYOR_REPO_COMMIT_MESSAGE --jobId $env:APPVEYOR_JOB_ID

This will locate the xml file opencovertests.xml as a result from running opencover on your c# project, and publish it to your coveralls project based on the repoToken “abcdefghijklmnopqrstuvwxyz” (using your repo token found on your coveralls.io project page) along with the git commit and branch details pulled out of appveyor.

So what does this mean to you? How will you use it? Well you can replace the appveyor environment variables above with the actual values found in your build server, get your repo token from coveralls.io, and plus this in on top of your existing opencover coverage CI.

If you don’t currently have opencover hooked up, there are tutorials all over the place for your specific build server, I’ll leave you to figure out the best way to get this running.

Don’t use/want to use opencover? The next steps for me is to get other coverage reports working with coveralls.net so stay tuned, or go +1 some of my features listed in the repository issues.

For me, the next steps is to test this works on my other projects so that I will be in the same situation as anyone else who wants to use it.

Hey, I found this thing called Coveralls.io

Sun, 14 Dec 2014 19:50:47 +0000

In my pursuit to find a build task runner for my code coverage I stumbled on this whole other side of the internet I didn’t know about (from a .Net developer’s perspective). I’ve been using AppVeyor.com for my open-source CI build, which is a great option for anyone with a project on the Microsoft Stack. The cool thing about this (and other similar services) is that if you have an open source project on GitHub, you can use these services with your project for free!

I’m aware this isn’t new, and there are others like Travis-CI.org which run all the other platforms, but I didn’t realise how prolific it really was! Especially how exclusive of microsoft languages they all are. Travis-CI for instance, doesn’t seem to support .Net by looking on their docs page, though there does seem to be mono support in beta (and that didnt exist when i looked a week ago, so will keep an eye on this).

But my main reason for this post, is that I found this cool new (to me any way) Continuous Code Coverage host called coveralls.io. With a cool name like that, and a badge for my project, I’m sold. But wait, lets check those docs again. Yip as I thought, no C# support. They even have C/C++, this is wrong!

Ah but whats this? They have an api? And they want you to add missing support? I think I have to help with this. So now I have looked at the java and python implementations, a little bit of the api documentation, and I now have a project placeholder to support C# from various Code Coverage xml output formats to post that data up to coveralls, at coveralls.net on github. I’ve even got my badges, for coveralls.io ready to go.

So fastforward another week and I have a working prototype done. It’s even showing coverage on coveralls.io, supporting opencover xml format.

So whats left now? finish building it to be reusable by my other projects, publish it to nuget and chocolately and wherever else I need to, and start getting people integrating it into their .Net builds. Probably build out other C# coverage report formats as well, so your not forced to use opencover. Wish me luck!

small side note

So I also found this other continuous code quality metrics thing for python called landscape.io. When will we see this type of thing available for .Net as well? Turns out right now. Check out Coverity Scan Static Analysis (mine needs you to create an account to use, but no permissions to view.)

And two more for fun: waffle.io & readthedocs.org

Gulp vs .net

Sun, 07 Dec 2014 17:41:40 +0000

I wanted to add continuous code coverage to my little extension library project, and so realised i would need to run one of nCover, dotCover or openCover from the command line on my build server. This calls for a task based build automation library!

Because I’m started to learn more about this nodejs thing as a .Net developer, I figured I should give one of the build automation projects from there a go, even though my project is a .Net library and I dont need node (even if it is a PCL).

A Few Hurdles

So the first major problem is node itself. not a current dependancy from any of the project, so that needed to be installed. Not a big deal, i did have to hack around with powershell to set up node so that npm was recognised, but thats a once off per machine. Then I had to add a package.json file, that was that.

Next up was gulp, again, not too bad except that I did have issues getting gulp recognised as a command, but a few powershell restarts and some new PATH variables and that was fine too.

Now to get gulp to build and run my tests. Luckily there is a gulp-msbuild task that I could install, which works without much trouble. Unfortunately, there was no gulp-mstest. after much trial and error, I found and used the node package mstest, and jumped some extra hoops to do a manual gulp task for that. I notice that there is a grunt-mstest available, and a gulp-nunit, so not too big a deal for others that might be following a similar path.

I even managed to get a AssemblyInfo rewritter build step as well, which was a nice, but unnecessary bonus at this stage.

About now, after several hours mucking about, I realised that I had achieved the following:

Introduced an unnecessary dependancy on nodeJS
Added new node-module dependancies to the setup of my build tasks that need downloading
Require you to spin up an entire node environment, just to shell out to command line applications to build and test my .Net project.

I haven’t even got to code coverage and already feel I’m breaking ground, and will need to build my own node libraries for gulp to run my tests and code coverage. At this point I also realise since ive been doing the whole thing in powershell, I should just install psake and be done with it.

Conclusion

If you’ve got a web application in .Net and you will need a pipeline for less/sass/typescript/coffeescript/javascript , gulp is a nice way to go, and can even do the build, run the test, package to a zip and/or deploy to your environments for you. But if all you have is a .Net library with no web requirements whatsoever, I recommend psake, with a little chocolatey for environment dependancies thrown in.

For your interest

You can check out the changes in the following Commit (I’m pretty sure it’s going to become psake pretty soon.)

7 Lessons from Building a WP7 Game in 7 days

Tue, 05 Jul 2011 18:00:00 +0000

This is a companion post for my talk at Wellington’s SLAMD user group on 6 July 2011.

Recently I took part in Nigel Parker’s “Release an App for Windows Phone 7 in 7 Days for a Chance to Win a New HTC 7 Trophy Phone” competition, with the intent of winning a Windows Phone 7 device. Although I didn’t manage to win the device, I did get a free 1 year subscription to the App Hub, allowing me to develop and submit apps that I build, had fun doing it, and learned a few lessons along the way. This was my first exposure to the WP7 development ecosystem, as well as my first excursion onto a mobile platform in general.

So what follows is a few lessons that I would like to pass on about developing a windows phone application. First though, I will give a quick overview of what exactly I built. The brief was simple, build an application, and have it live on the marketplace by the 6th of June. Not that big of a task, really. The point of this exercise was to both boost awareness of the new development tools, and to increase the footprint of New Zealand-built apps on the marketplace.

‘7 days’ was a bit of a guideline really, as the competition ran from the 16th May, but this gave time after your 7 days to get it through the approval process, get your account validated and active, and still have time to fix anything that stopped it getting approved first time around. So I came up with a great idea, for a spacies-type game where the main character was a bottle of sauce, defending his kitchen against an invasion of bacon. Bacon Vaders was born. With an idea in hand, the very next thing to do, of course, was to grab all of the developer tools and sdk. This brings me to Lesson number 1.

1) Tools only work on Windows Vista and Windows 7

This was a bit of a problem for two reasons. The first is that my primary portable solution is my EeePC. It is perfectly practical for taking my development with me, and has been my PC of choice for presentations. The only catch is that it is running Windows XP. I am keen to find out if it can handle windows 7 and still be a functional dev machine, but the cost of upgrading when XP works perfectly fine has held me back. Lucky for me, my girlfriend also has a Netbook, a newer one, and it has Windows 7. Portability problem solved. Problem 2, this restriction means that it also doesn’t work on Windows Server 2008 R2. If anyone was wondering, that is the OS running on my office machine.

Hmm, so can’t do any dev at work either in my lunch break or before I head home. I’m sure I’m not the only developer who thinks that developing on a Server makes heaps of sense, but I guess they don’t expect that developers of web applications, deskop applications and web services ( + any database solutions) will want to develop for the WP7. Well its lucky that my gaming machine is running Windows 7 then, so I can use that for the majority of my coding and testing.

So with the environment set up I was ready to start coding. With the help of my sister creating the graphical images and characters, I had a playable version of the game working by the end of 5 days made up of a weekend, and a couple of late nights after work. But as with anything new, there were a few bugs and oddities that had to be worked through to make it presentable for the marketplace.

2) Tombstoning

If you had been following any development blog or message boards around Windows Phone 7, you would have heard the term ‘Tombstoning’. This is the way Window Phone 7 handles not having multitasking (at least for the first release, Mango improves upon this model). There are several scenarios where this occurs. The simplest way to demonstrate the tombstoning behavior is to press the windows key on the device while your application is running. This puts it into an out of processor state. If memory is needed, then your application will be closed completely. This is tombstoning. If you come back before this happens, everything is exactly were you left it. If you come back after tombstoning, you get to come back to the same page or screen, but you will have to do some work to continue where you left off.

Luckily, you can be notified when your application is tombstoned, and write code to save any important information, that you might need to use to bring it back up again. After much trial and error, I was able to get my game to behave how I wanted it to. rather than rely of specific Tombstoning information, I decided that if you were playing the game, and you left the in game screen in anyway, the current level state would be saved. Then, whenever you return to the page, either with resume from the menu, or using the back button, the level would resume itself. Even if tombstoning hadn’t occurred, the same code can be used to refresh the page, and then resume the game.

After tombstoning, the rest of the application came together pretty easily, since it was simply Silverlight, and I have plenty of experience building silverlight apps. I wasn’t using any networking, any complex configuration, saving or loading. I wasn’t even doing anything overly complex with the game loop. The next lesson didn’t crop up until closer to the end of the project.

3) Games vs Apps

As you might know, the phone allows for two categorisations of Applications, apps, and games. Both can be pinned to the tiles screen, but the first appears in the applications list (to the right of the tiles screen) and the latter is on the Games Hub. So how do we get it there? Here comes a three part lesson learned.

Part 1, how to set where your application ends up? In the solution, when you create a new Silverlight project, the file WMAppManifest.xml is created in the Properties folder with the setting Genre=“apps.Normal”. If you set this to apps.games, your application will be place inside the games hub. Alternatively, when you create a WP7 XNA application, you will have apps.games, and by changing to apps.normal, you will no longer be placing you xna application in the games hub. One thing to note here, is that this does not affect the categorisation of you application, this is done during the submission process.

This brings me to part 2 of the apps verses game lesson: icons. When you create a silverlight wp7 application, you get an image in the project called ApplicationIcon.png, with a resolution of 62x62. This is the size of the icon in the applications list. However, when you create an xna application, you get a GameThumbnail.png, which is 173x173. There is a really good reason for this: in the Game Hub, games get bigger icons. This means that if you start with a silverlight application, and change its genre to apps.games, you get a distorted icon, as the phone tries to stretch the 62x62 icon to the 173x173 size. So you need to make sure that you make the image for the icon a 173x173 image, if its a game.

A side note here is that a separate image is used for the tile background, but this too is 173x173. What makes this a bit of a problem is part 3 of the lesson. In the emulator, you only get a subset of the phones functionality. The emulator doesn’t include the Games Hub for instance. This means that once you set the application to become a game, you can no longer launch it from the phone, without starting it through Visual Studio. This relates to the last bit, because without looking on an actual device, you might not notice you need to change the icon size. This is what happened to me before I tested it on an actual device. The next lesson is also as a result of finally testing on an actual device.

4) Performance

There are a few things to know about the emulator. 1, it performs better on the cpu then the actual device will. 2) sometime graphics processing will be better on the device then on the emulator. This all comes down to a very simple lesson, always test on a real device. I noticed that my application was not running smoothly on a real device, and made a few enhancement to improve this.

I was ready to submit. I filled out all the details, had a activated account, sent through all my verification details, and submitted my first draft of Bacon Vaders. After a few days I had my response and my next lesson. I failed validation.

5) Contrast

If you have played with the phone, or the emulator, you would see that there are two basic themes to the device, light and dark. From silverlight, this theme is used for the font color, and backgrounds. many theme resources are available to use when you need to set the colour of something, including the accent colour. Unfortunately, I didn’t use these. I failed the validation because when you put the phone in light mode, you couldn’t read some of the text, since I had made a few rectangles with either black or white translucent colours, instead of using the provided theme resources. So I quickly fixed this up, and got my application resubmitted. This time it passed, and now my app is available on the marketplace. For more information about the specifications that are tested against, check here.

6) Silverlight for Games

There are a few issues with the current version of my game. I have some performance issues with my game loop. This brings me to my second to last lesson, building games in silverlight. If you are building a simple game, without any real-time processing, or a nominal gameloop, you can build games in silverlight, especially if you want to rely on the animations, UI dynamic layouts and simple 2D graphics that it provides in a nice API . If you need a gameloop, however, XNA can do all the heavy lifting for you. And if you want to do 3D on the phone, you will certainly want to use XNA. Of course, now you can get the best of both world with using XNA and silverlight together on WP7 Mango. If I built this again, I would most likely use XNA to do it, but for this short build-time project, I had to go with what I knew.

7) Tasks on the emulator

Some things I have come across since finishing, while trying to add a few tasks to my application, such as rating, links to my website, and integrated sending feedback/bug reports, have been interesting discoveries. This relates to the Tasks in the API, and to the hubs and built in applications. I wont go into too much detail, but you can basically use the tasks as a backdoor to access the hidden hubs. From there, you can set up an email account or two, as well as a few other settings, and then get a lot more functionality out of the tasks. More about this can be seen on this blog post.

So there you have it. 7 lessons from 7 days developing an application for Windows Phone 7.

Time for an update

Fri, 10 Sep 2010 08:33:12 +0000

So I really should have posted something sooner, but I’ve been so busy with other things. Anyway, Change should soon be coming, I have a whole backlog of things i need to post about, and I’ve started using Twitter, which should result in this post being tweeted about due to a new plugin (fingers crossed). So here is my mental note, to myself and perhaps also a promise to the wider public, of what i hope to get done to this site over the next few months (I hope this is realistic enough :-) ).

Finish Photo Album Application
Restyle the site
Add twitter and Social Networking to my site
Post about the HTML bridge
Post about DataTemplateSelector
Post about Attached Behaviour and default item selection
Post about Blend and UI Styling
Create a Silverlight frontend for WordPress
Create Silverlight Tag Cloud

And if i manage to get through all that I can probably afford to skip another month of not posting! lets see how we go aye?

Playing with Silverlight

Mon, 21 Sep 2009 22:54:49 +0000

I’ve just started to experiment with silverlight, well, silverlight 2 to be exact. Its an interesting combination of C# and xml markup, but i like it none-the-less. So far if made a series of buttons that change elements on the screen, nothing special, but am keen to get stuck into something more substantial. Maybe if i get my traffic simulator working in C++ ill port it over to silverlight? We shall see.

My First YouTube Post

Sun, 15 Feb 2009 22:31:58 +0000

Well here is the YouTube movie I promised, 6 weeks work to make, and im really proud of it.

This was made using Blender for the animation, and GIMP to prepare the stop motion frames. Be sure to keep posted for the second installment of Fred. :)