Over Macho Grande

AWS Lambda and I have a love/hate relationship.  There is much about Lambda to like, but there are also some very sharp edges operationally. One of the cool things is that you get a new CloudWatch Log Group for every new Lambda function without any effort on your part.  Less cool is that it has unlimited retention.  If you haven't yet followed Yan Cui's advice , then you can use some Bash/CLI magic to fix retention on your existing Log Groups. First, get a list of all your default Lambda log groups:  aws logs describe-log-groups --log-group-name-prefix "/aws/lambda" | grep logGroupName | cut -d : -f 2 | cut -d \" -f 2 > /tmp/lambda_logs Read that into a Bash array:  readarray -t log_groups < /tmp/lambda_logs Then, add a 7 day retention policy to all those log groups:  for i in "${log_groups[@]}"; do aws logs put-retention-policy --log-group-name $i --retention-in-days 7; done It's a hack, but if you're going to put in th

First of, let me start by acknowledging that you're no longer supposed to use NuGet restore (with the .nuget) as of NuGet 2.7.  Then again, to quote Mick Jagger, you can't always get what you want. The biggest problem I have with this is the "HintPath" in the project file.  It took some experimentation (and a couple of wrong turns) to work out that HintPath is relative to the project directory even when it's part of a multi-project solution . You'll know that your HintPath is wrong when the NuGet package is installed but can't be found by the compiler.  Drop into the directory containing your project and confirm that you've got a valid HintPath.  One of my wrong turns was not verifying that I had a correct path (there was an extra 'lib' in the definition. You may also see this as a busted reference in Visual Studio.

I'm in the "winding down" phase of my time here in Noumea.  One of my cornerstone achievements is migrating a buggy MS Access app into a shiny new MVC3 (and then MVC4) web application. I've been working on it off and on for most of my time here (maybe 18 months) and one of my co-workers asked me to document some of the design decisions.  The app kind of grew organically, so I don't have a software spec to point to like I would have had at my prior engagements.  I felt a series of blog posts would be an appropriate way of documenting this.  It's an open source app, so the blog posts are my defense when someone digs into the app and finds some awful hack that migrated from a short-term fix to a permanent solution. I've got nothing more today, but next time I'll dig into the choice of data access layer. TUBS on GitHub

Okay, so this is something of a rant, but given my experiences with the laptop, how can I not? Backstory:  Corporate IT maintains a list of acceptable portables, all of which are made by Toshiba.  After looking over the list, it looked like the best choice was the Portege R830.  It had the best possible CPU and it wasn't a giant clunker that looked my back-in-the-day 15 pound Inspiron 7000.  As a bonus, it was available with a reasonably priced docking station. My first conception that something was wrong when, after first boot, I checked free memory.  Physically, 4GB is installed, but windows says that only 2.7GB is available.  The Intel HD3000 video setup is eating the rest (1.3GB!).  Okay, no big deal.  I can reboot and change that in the BIOS.  Oops.  No option.  Well, maybe it's just some old drivers.  Nope.  Drivers are latest from Toshiba.  They're not particularly new, so maybe the generic Intel ones will fix it.  Damn!  Toshiba has crippled the video so that it

I _really_ like Twitter's Bootstrap.  It saves me from making any number of questionable content design choices.  I'm using it in an MVC3 project and one of the things that bugged me was the inability to get Microsoft's unobtrusive validation working with the fancy form control states in Bootstrap. Well, after looking around on StackOverflow and poking and prodding MVC, here's what I've got: If you correct the error, the state changes away from error and you get this: I hacked this into place by inserting a shim error placement function.  It saves a handle to the original Microsoft implementation, changes the class on the nearest div with a CSS class of "control-group" and then calls the Microsoft implementation to display the actual error text. $(document).ready(function () {             var esettings = $.data($('form')[0], 'validator').settings;             // Get a handle to the original errorPlacement function             var

I'm pretty impressed with Microsoft's System.Speech API.  It took less than 3 days to throw together a proof-of-concept application.  The hardest part was probably coming up with the grammar -- documentation for that is pretty thin on the ground. Anyways, here's the application source code on GitHub if anyone wants a look: ObserverLengthSampler project If nothing else, I'd recommend it as a starting point for someone needing a number recognition SRGS grammar in an XML format.