Tuesday, September 30, 2014
A Windows Phone App I really wish was better: TuneIn

I use this app everyday to listen to various things, both local and national radio (sports radio generally, and yes, there are good sports radio programs, but I digress). 

I also need to restart the app close to a dozen times a day, due to streaming failures mainly.  Or if it loses a signal, it fails to get it back without having to tombstone it, etc.

It’s not totally unusable, as I use it all the time, but only because I don’t know what to replace it with.

posted @ Tuesday, September 30, 2014 10:56 AM | Feedback (0)
Monday, September 22, 2014
Two best things about the Nokia Lumia 1520

Well, two really noticeable good things.

1)  Older eyes like mine love the larger screen.  So much easier on the eyes.

2) Battery life: there’s something nice about forgetting to charge the phone overnight, and it only losing 2-2.5% battery life an hour.

The few times I had looked at it before, it seemed too large, but after, I don’t know, a day, it was just fine. 

Of course, this means I probably can’t use a smaller phone ever again, but oh well.

posted @ Monday, September 22, 2014 2:21 PM | Feedback (0)
Wednesday, September 17, 2014
Something that can make a developer feel lonely….

When you run into an error message, search on Google for it, and get no exact hits.

posted @ Wednesday, September 17, 2014 4:22 PM | Feedback (2)
Sunday, September 07, 2014
Syncing large numbers of music files with a Windows Phone 8.1

I went through this over the last week or so, having picked up a Nokia Lumia 1520, and adding a 128 GB microSD card to it so that I could replace my beloved by slowly fading Zune player (yes, I know, Zune you say?  Are you nuts? No, not nuts.  It’s been a great player, very well built, fantastic form, but one can only keep running the Zune software for so long and expect things to still work).

I wanted to sync roughly 16,000 files.  Windows 8.1 has a Metro app that will allow you to add music (and photos and other things) to a phone.  But, like many a Metro app, it doesn’t work that well.  You select a huge number of directories to add (as you are likely to have a huge numbers of directories when syncing that many songs), click add, and then…..the Windows Phone app does something.  For a very, very, very long time.  After an hour or three, I gave up.

To get the files onto the phone (which doesn’t mean you can actually listen to them at that point, but I’ll get to that), I used the Windows Phone app for Desktop, which, for the most part, works at least okay well enough to get the job done.  It takes a hell of a long time, but you can at least see it start quickly, and get a running total of the number of tiles to copy, the number completed, the number remaining, you know, things you might consider important when syncing large numbers of files from a PC to a phone.  I was syncing both music and pictures so I don’t know how long it took to sync just the music files, but I’m going to estimate it at about 8 hours.

Great.  So, now all those files are on the phone, I can listen to the sweet sweet musi……um, why am I clearly not seeing all the songs?  Let me search on a specific artist….95% of the songs are not appearing in Xbox Music.  Now, we know XBox Music on Windows Phone sucks, so let’s try Mix Music….nope.  How about (insert randomly searched for Windows Store music player app)…nope.

Did the files really get copied?  Windows Phone 8.1 now has a file explorer, let me search for a specific song that isn’t appearing….yep.  There it is.  And I can play it from the file explorer.

Okay, let’s try shuffling my collection in XBox Music, since that seems to be the only way to figure out how many songs it recognizes (it appears in the Recent Plays list with number of songs)….4000 songs?  What the hell.

Come back a while later after not paying much attention….6000 songs.  Uh, okay.  So, it’s clearly indexing the files after they were added.  How, why, how to trigger this…..

What I discovered (and there may be other ways of doing it but this was what worked for me) was that I could shuffle my collection, start playing….and then walk away.  After quite some time, it even showed a “adding files” counter in the upper left.  It took…I don’t know.  4-6 hours?  It wouldn’t index the files unless the phone was actually in the XBox Music app. 

Wonderful functionality/usability.  Anyhow, I can now listen to all my tunes.  If I hadn’t also dealt with an entirely separate mass music sync involving iTunes and OSX, I’d rant a lot about XBox Music, but you can find enough of that elsewhere.

posted @ Sunday, September 07, 2014 9:34 PM | Feedback (0)
Tuesday, September 02, 2014
An Amazon delivery estimate you don’t see often

For an order placed September 1st, 2014:

Delivery estimate: October 16, 2014 - December 1, 2014 (More about estimates)

posted @ Tuesday, September 02, 2014 9:58 PM | Feedback (0)
Monday, August 25, 2014
Windows Forms: Why isn’t my Form_Load method being called?

This is just one of those things that I’m posting in case I see it again.

Was testing a Windows Forms app and, depending on which build configuration was being used, the Form_Load method wasn’t being called.  Huh?

I don’t understand the internal mechanics of it, but the non-working build configuration was set to x86, while the working one was set to Any CPU, and this was on a x64 machine.  Changed it to Any CPU for both, and we were fine.

posted @ Monday, August 25, 2014 1:02 PM | Feedback (0)
Wednesday, July 30, 2014
EF doesn’t really like bounded contexts

So, from the previous post on the subject, I randomly tried Phillip’s suggestion of dropping the models in different folders, and was rather surprised that it could now build.  Great!!!!

Except….no.  At run time, a new error surfaced:

System.Data.Entity.Core.MetadataException was unhandled
  Message=Schema specified is not valid. Errors:
The mapping of CLR type to EDM type is ambiguous because multiple CLR types match the EDM type 'Cart'. Previously found CLR type 'EF6CommonTable.Model.Checkout.Cart', newly found CLR type 'EF6CommonTable.Model.Shopping.Cart'.
The mapping of CLR type to EDM type is ambiguous because multiple CLR types match the EDM type 'CartItem'. Previously found CLR type 'EF6CommonTable.Model.Checkout.CartItem', newly found CLR type 'EF6CommonTable.Model.Shopping.CartItem'.

Uh, what the hell?

After doing some research, it appears that this is by design, and has been present in EF from the beginning, but since I was using the Legacy ObjectContext, I never ran into it.

It might be fixed in the future.

Basically, EF ignores namespaces, so it is failing because the class names are identical.  ‘Workarounds’ involve changing the names, putting each model in its own project (though I’ve read that might not always work from some comments), etc.

This……seems idiotic.

I’m not sure what I will do here.

posted @ Wednesday, July 30, 2014 1:12 PM | Feedback (0)
Tuesday, July 29, 2014
Were all file format interface definitions designed by people under the influence of alcohol or other substances?

This is largely a rhetorical question.

posted @ Tuesday, July 29, 2014 12:14 PM | Feedback (0)
Monday, July 28, 2014
Blameless Post-Mortems

I had never heard this particular phrase before.  I think of it as common sense.

The main goal is to find what, how and why and incident happened. The post-mortem must produce actionable items that will prevent the same thing to happen in the future.

posted @ Monday, July 28, 2014 9:22 AM | Feedback (0)
Friday, July 25, 2014
Still Stumped: Entity Framework 6 and ‘Bounded Contexts’

Ok, I still can’t figure out how to do this.  It has to be possible.  My Google-Fu is usually phenomenal, but it is failing me here. 

I’ve ‘dumbed it down’ to a very simple scenario.  Suppose I have two EF contexts.  Each one references two tables, the same two tables, from the same database, and I use the ‘Generate from Database’ option in EF 6.  In this case, I am mimicking  two bounded contexts, the shopping BC and the checkout BC.  Each one needs to reference the Cart and CartItem tables and generate those entities accordingly.  Here are some pictures to illustrate.

Shopping BC:


Here’s the Checkout BC:


What I expect, and what was possible using EF 5 and before, using the Legacy ObjectContext option, was that by adding custom namespaces, I could have, e.g., a Shopping.Cart object and a Checkout.Cart object, which will be created using different contexts, and used in different scenarios.  It should be obvious why this is important.

However, what actually happens is this:


Depending on I know not what (what file is in focus?  Barometric pressure?  The Yankees’ pitching staff’s ERA?), the Cart and CartItem classes will be generated by T4 either under or  Always together, but always under one.  They should be generated under both, with different namespaces.

As readers of this blog know, I am lazy, stupid, slow and old.  Something just out of the box should work here.  But, even though I am lazy, stupid, slow and old, I’m willing to hack some .tt files if needed to get this to work, as I don’t want to be ‘stuck’ using Entity Framework 5 for the rest of my fricking life. 

I was hoping, as has happened in the past, that by writing this blog post out, I would stumble upon the obvious solution.  I’m still hoping for that, as it often happens after the ‘publish’ button is pressed.

Why doesn’t this just work?

posted @ Friday, July 25, 2014 7:57 PM | Feedback (3)