halloween, costumes comments edit

It was raining again this year and that definitely took down the number of visitors. Again this year we also didn’t put out our “Halloween projector” that puts a festive image on our garage. In general, it was pretty slow all around. I took Phoenix out this year while Jenn answered the door so I got to see what was out there firsthand. Really hardly anyone out there this year.

Trick-or-Treaters

2015: 85
trick-or-treaters.

Average Trick-or-Treaters by Time Block

The table’s also starting to get pretty wide; might have to switch it so time block goes across the top and year goes down.

Cumulative data:

  Time Block
Year 6:00p - 6:30p 6:30p - 7:00p 7:00p - 7:30p 7:30p - 8:00p 8:00p - 8:30p Total
2006 52 59 35 16 0 162
2007 5 45 39 25 21 139
2008 14 71 82 45 25 237
2009 17 51 72 82 21 243
2010 19 77 76 48 39 259
2011 31 80 53 25 0 189
2013 28 72 113 80 5 298
2014 19 54 51 42 10 176
2015 13 14 30 28 0 85

Costumes

My costume this year was Robin Hood. Jenn was Merida from Brave so we were both archers. Phoenix had two costumes - for trick-or-treating at Jenn’s work she was a bride with a little white dress and veil; for going out in the neighborhood she was a ninja.

The finished Robin Hood costume

Costume with the cloak closed

I posted some in-progress pictures of my costume on social media, but as part of the statistical breakdown of Halloween this year I thought it’d be interesting to dive into more of exactly what went into the making outside of the time and effort - actual dollars put in.

On my costume, I made the shirt, the doublet, the pants, and the cape. I bought the boots, the tights, and the bow.

Accessories and Props

Let’s start with the pieces I bought:

Total: $99.10

The Shirt

The shirt is made of a gauzy fabric that was pretty hard to work with. The pattern was also not super helpful because you’d see “a step” in the pattern consisting of several actions.

Confusing shirt pattern

I did learn how to use an “even foot” (sometimes called a “walking foot”) on our sewing machine, which was a new thing for me.

Even foot on the sewing machine

  • Shirt, doublet, and pants pattern - $10.17
  • Gauze fabric - $6.59
  • Thread - $3.29
  • Buttons - $5.99
  • Interfacing - $0.62

Total: $26.66

The Pants

I don’t have any in-progress shots of the pants being made, but they were pretty simple pants. I will say I thought I should make the largest size due to my height… but then the waist turned out pretty big so I had to do some adjustments to make them fit. Even after adjusting they were pretty big. I should probably have done more but ran out of time.

  • Shirt, doublet, and pants pattern - (included in shirt cost)
  • Black gabardine fabric - $23.73
  • Thread - $4.00
  • Buttons - $1.90
  • Eyelets - $2.39
  • Ribbon - $1.49
  • Interfacing - (I had some already for this)

Total: $33.51

The Doublet

The doublet was interesting to make. It had a lot of pieces, but they came together really well and I learned a lot while doing it. Did you know those little “flaps” on the bottom are called “peplum?” I didn’t.

I hadn’t really done much with adding trim, so this was a learning experience. For example, this trim had a sort of “direction” or “grain” to it - if you sewed with the “grain,” it went on really smoothly. If you went against the “grain,” the trim would get all caught up on the sewing machine foot. I also found that sewing trim to the edge of a seam is really hard on thick fabric so I ended up adding a little margin between the seam and the trim.

Putting trim on the body of the doublet

These are the peplums that go around the bottom of the doublet. You can see the trim pinned to the one on the right.

Sewing peplums

Once all the peplums were done, I pinned and machine basted them in place. Getting them evenly spaced was a challenge, but it turned out well.

Pinning peplums

After the machine basting, I ran the whole thing through the serger which gave them a strong seam and trimmed off the excess. This was the first project I’d done with a serger and it’s definitely a time saver. It also makes finished seams look really professional.

Serging peplums

To cover the seam where the peplums are attached, the lining in the doublet gets hand sewn over the top. There was a lot of hand sewing in this project, which was the largest time sink.

Slip-stitching the doublet lining

Here’s the finished doublet.

The finished doublet

  • Shirt, doublet, and pants pattern - (included in shirt cost)
  • Quilted fabric (exterior) - $15.73
  • Brown broadcloath fabric (lining) - $5.99
  • Thread - $8.29
  • Eyelets - $8.28
  • Trim - $23.95
  • Leather lacing - $2.50
  • Interfacing - $6.11

Total: $70.85

The Cape

The cape was the least complex of the things to make but took the most time due to the size. Just laying out and cutting the pattern pieces took a couple of evenings.

As you can see, I had to lay them out in our hallway.

Cutting the exterior cape pieces

I learned something while cutting the outside of the cape: The pattern was a little confusing in that the diagrams of how the pattern should be laid out were inconsistent with the notation they describe. This resulted in my cutting one of the pattern pieces backwards and Jenn being kind enough to go back to the fabric store all the way across town and get the last bit of fabric from the bolt. I was very lucky there was enough to re-cut the piece the correct way.

I used binder clips on the edges in an attempt to stop the two fabric layers from slipping around. It was mildly successful.

Cutting the cape lining

I found with the serger I had to keep close track of the tension settings to make sure the seams were sewn correctly. Depending on the thread and weight of the fabric being sewn, I had to tweak some things.

To help me remember settings, I took photos with my phone of the thread, the fabric being sewn, and the dials on the serger so I’d know exactly what was set.

Here are the settings for sewing together two layers of cape lining.

Cape lining serger settings

And the settings for attaching the lining to the cape exterior.

Serger settings for attaching lining to cape exterior

I took a shot of my whole work area while working on the cape. It gets pretty messy, especially toward the end of a project. I know where everything is, though.

You can also see I’ve got things set up so I can watch TV while I work. I got through a couple of different TV seasons on Netflix during this project.

My messy work area

One of the big learning things for me with this cape was that with a thicker fabric it’s hard to get the seams to lay flat. I ironed the junk out of that thing and all the edge seams were rounded and puffy. I had to edgestitch the seams to make sure they laid flat.

Edge stitching the cape hem

  • Green suedecloth (exterior) - $55.82
  • Gold satin (lining) - $40.46
  • Dark green taffeta (hood lining) - $5.99
  • Interfacing - (I had some already for this)
  • Thread - $11.51
  • Silver “conchos” (the metal insignias on the neck) - $13.98
  • Scotchgard (for waterproofing) - $5.99

Total: $133.75

Total

  • Accessories and props - $99.10
  • Shirt - $26.66
  • Pants - $33.51
  • Doublet - $70.85
  • Cape - $133.75

Total: $363.87

That’s probably reasonably accurate. I know I had some coupons where I saved some money on fabric (you definitely need to be watching for coupons!) so the costs on those may be lower, but I also know I had to buy some incidentals like more sewing machine needles after I broke a couple, so it probably roughly balances out.

I get a lot of folks asking why I don’t just rent a costume. Obviously from a money and time perspective it’d be a lot cheaper to do that.

The thing is… I really like making the costume. I’m a software engineer, so generally when I “make something,” it’s entirely intangible - it’s electronic bits stored somewhere that make other bits do things. I don’t come out with something I can hold in my hands and say I did this. When I make a shirt or a costume or whatever, there’s something to be said for having a physical object and being able to point to it and be proud of the craftsmanship that went into it. It’s a satisfying feeling.

home comments edit

At home, especially after a long day, I’ve noticed my phone may be low on power even though I’d like to continue using it. All of our chargers are in rooms other than the living room where we spend most of our time and I didn’t want to move one into the living room because I didn’t want cords all over the place or a bajillion different things to plug in.

I finally figured out the answer.

Materials

Charger, cables, and adhesive

Assembly

Use one of the Command strips to affix the USB charger under the lip on the back of your end table. I went with Command strips because they’re reasonably strong but generally won’t ruin the finish on your table because they can be easily removed.

Plug one or more of the one-foot cables into the charger.

If you get the Sabrent USB cables I mentioned earlier, they have a little bit of Velcro on them you can use to your benefit. Put a little Velcro under a nearby area of the table and push the Velcro tie on the USB cable to the end. You can then attach the end of the cable in easy reach from your couch using the Velcro.

Charger attached to the back of the table

Usage

The nice thing about this is it’s entirely unobtrusive. Charge your phone on the end table while you’re sitting and watching TV, but when you’re done you can drop the cable back behind the table (it’s only a foot long so it won’t drag on the ground or look messy); or if you have the Velcro you can affix the cable under the lip of the table in easy reach for the next usage.

Charging a phone

dotnet, aspnet, build, autofac comments edit

We recently released Autofac 4.0.0-beta8-157 to NuGet to coincide with the DNX beta 8 release. As part of that update, we re-added the classic PCL target .NETPortable,Version=v4.5,Profile=Profile259 (which is portable-net45+dnxcore50+win+wpa81+wp80+MonoAndroid10+Xamarin.iOS10+MonoTouch10) because older VS versions and some project types were having trouble finding a compatible version of Autofac 4.0.0 - they didn’t rectify the dotnet target framework as a match.

If you’re not up on the dotnet target framework moniker, Oren Novotny has some great articles that help a lot:

I’m now working on a beta 8 compatible version of Autofac.Configuration. For beta 7 we’d targeted dnx451, dotnet, and net45. I figured we could just update to start using Autofac 4.0.0-beta8-157, rebuild, and call it good.

Instead, I started getting a lot of build errors when targeting the dotnet framework moniker.

Building Autofac.Configuration for .NETPlatform,Version=v5.0
  Using Project dependency Autofac.Configuration 4.0.0-beta8-1
    Source: E:\dev\opensource\Autofac\Autofac.Configuration\src\Autofac.Configuration\project.json

  Using Package dependency Autofac 4.0.0-beta8-157
    Source: C:\Users\tillig\.dnx\packages\Autofac\4.0.0-beta8-157
    File: lib\dotnet\Autofac.dll

  Using Package dependency Microsoft.Framework.Configuration 1.0.0-beta8
    Source: C:\Users\tillig\.dnx\packages\Microsoft.Framework.Configuration\1.0.0-beta8
    File: lib\dotnet\Microsoft.Framework.Configuration.dll

  Using Package dependency Microsoft.Framework.Configuration.Abstractions 1.0.0-beta8
    Source: C:\Users\tillig\.dnx\packages\Microsoft.Framework.Configuration.Abstractions\1.0.0-beta8
    File: lib\dotnet\Microsoft.Framework.Configuration.Abstractions.dll

  Using Package dependency System.Collections 4.0.11-beta-23409
    Source: C:\Users\tillig\.dnx\packages\System.Collections\4.0.11-beta-23409
    File: ref\dotnet\System.Collections.dll

  (...and some more package dependencies that got resolved, then...)

  Unable to resolve dependency fx/System.Collections

  Unable to resolve dependency fx/System.ComponentModel

  Unable to resolve dependency fx/System.Core

  (...and a lot more fx/* items unresolvable.)

This was, at best, confusing. I mean, in the same target framework, I see these two things together:

  Using Package dependency System.Collections 4.0.11-beta-23409
    Source: C:\Users\tillig\.dnx\packages\System.Collections\4.0.11-beta-23409
    File: ref\dotnet\System.Collections.dll

  Unable to resolve dependency fx/System.Collections

So it found System.Collections, but it didn’t find System.Collections. Whaaaaaaa?!

After a lot of searching (with little success) I found David Fowler’s indispensible article on troubleshooting dependency issues in ASP.NET 5. This led me to the dnu list --details command, where I saw this:

[Target framework .NETPlatform,Version=v5.0 (dotnet)]

Framework references:
  fx/System.Collections  - Unresolved
    by Package: Autofac 4.0.0-beta8-157

  fx/System.ComponentModel  - Unresolved
    by Package: Autofac 4.0.0-beta8-157

  (...and a bunch more of these...)


Package references:
* Autofac 4.0.0-beta8-157
    by Project: Autofac.Configuration 4.0.0-beta8-1

* Microsoft.Framework.Configuration 1.0.0-beta8
    by Project: Autofac.Configuration 4.0.0-beta8-1

  Microsoft.Framework.Configuration.Abstractions 1.0.0-beta8
    by Package: Microsoft.Framework.Configuration 1.0.0-beta8

  System.Collections 4.0.11-beta-23409
    by Package: Autofac 4.0.0-beta8-157...
    by Project: Autofac.Configuration 4.0.0-beta8-1

  (...and so on.)

Hold up - Autofac 4.0.0-beta8-157 needs both the framework assembly and the dependency package for System.Collections?

Looking in the generated .nuspec file for the updated core Autofac, I see:

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
  <metadata>
    <!-- ... -->
    <dependencies>
      <group targetFramework="DNX4.5.1" />
      <group targetFramework=".NETPlatform5.0">
        <dependency id="System.Collections" version="4.0.11-beta-23409" />
        <dependency id="System.Collections.Concurrent" version="4.0.11-beta-23409" />
        <!-- ... -->
      </group>
      <group targetFramework=".NETFramework4.5" />
      <group targetFramework=".NETCore4.5" />
      <group targetFramework=".NETPortable4.5-Profile259" />
    </dependencies>
    <frameworkAssemblies>
      <!-- ... -->
      <frameworkAssembly assemblyName="System.Collections" targetFramework=".NETPortable4.5-Profile259" />
      <frameworkAssembly assemblyName="System.ComponentModel" targetFramework=".NETPortable4.5-Profile259" />
      <frameworkAssembly assemblyName="System.Core" targetFramework=".NETPortable4.5-Profile259" />
      <frameworkAssembly assemblyName="System.Diagnostics.Contracts" targetFramework=".NETPortable4.5-Profile259" />
      <frameworkAssembly assemblyName="System.Diagnostics.Debug" targetFramework=".NETPortable4.5-Profile259" />
      <frameworkAssembly assemblyName="System.Diagnostics.Tools" targetFramework=".NETPortable4.5-Profile259" />
      <!-- ... -->
    </frameworkAssemblies>
  </metadata>
</package>

The list of failed fx/* dependencies is exactly the same as the list of frameworkAssembly references that target .NETPortable4.5-Profile259 in the .nuspec.

By removing the dotnet target framework moniker from Autofac.Configuration and compiling for specific targets, everything resolves correctly.

What I originally thought was that dotnet indicated, basically, “I support what my dependencies support,” which I took to mean, “we’ll figure out the lowest common denominator of all the dependencies and that’s the set of stuff this supports.”

What dotnet appears to actually mean is, “I support the superset of everything my dependencies support.”

The reason I take that away is that the Microsoft.Framework.Configuration 1.0.0-beta8 package targets net45, dnx451, dnxcore, and dotnet - but it doesn’t specifically support .NETPortable,Version=v4.5,Profile=Profile259. I figured Autofac.Configuration, targeting dotnet, would rectify to support the common frameworks that both core Autofac and Microsft.Framework.Configuration support… which would mean none of the <frameworkAssembly /> references targeting .NETPortable4.5-Profile259 would need to be resolved to build Autofac.Configuration.

Since they do, apparently, need to be resolved, I have to believe dotnet implies superset rather than subset.

This appears to mostly just be a gotcha if you have a dependency that targets one of the older PCL framework profiles. If everything down the stack just targets dotnet it seems to magically work.

If you’d like to try this and see it in action, check out the Autofac.Configuration repo at 14c10b5bf6 and run the build.ps1 build script.

autofac, dotnet comments edit

As part of DNX RC1, the Microsoft.Framework.* packages are getting renamed to Microsoft.Extensions.*.

The Autofac.Framework.DependencyInjection package was named to follow along with the pattern established by those libraries: Microsoft.Framework.DependencyInjection -> Autofac.Framework.DependencyInjection.

With the RC1 rename of the Microsoft packages, we’ll be updating the name of the Autofac package to maintain consistency: Autofac.Extensions.DependencyInjection. This will happen for Autofac as part of beta 8.

We’ll be doing the rename as part of the beta 8 drop since beta 8 appears to have been pushed out by a week and we’d like to get a jump on things. For beta 8 we’ll still refer to the old Microsoft dependency names to maintain compatibility but you’ll have a new Autofac dependency. Then when RC1 hits, you won’t have to change the Autofac dependency because it’ll already be in line.

You can track the rename on Autofac issue #685.

powershell, vs, dotnet comments edit

I love PowerShell, but I do a lot with the Visual Studio developer prompt and that’s still good old cmd.

Luckily, you can make your PowerShell prompt also a Visual Studio prompt.

First, go get the PowerShell Community Extensions. If you’re a PowerShell user you should probably have these already. You can either get them from the CodePlex site directly or install via Chocolatey.

Now, in your PowerShell profile (stored at %UserProfile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1) add the following:

Import-Module Pscx

# Add Visual Studio 2015 settings to PowerShell
Import-VisualStudioVars 140 x86

# If you'd rather use VS 2013, comment out the
# above line and use this one instead:
# Import-VisualStudioVars 2013 x86

Next time you open a PowerShell prompt, it’ll automatically load up the Visual Studio variables to also make it a Visual Studio prompt.

Take this to the next level by getting a “PowerShell Prompt Here” context menu extension and you’re set!