I’ve been working on a side project at home the last few days to snipe hard to find restaurant reservations and came across a weird issue I’ve never experienced before while using the .NET framework.
The API I’m calling to find these opportunities returns a DateTime value in the format “2016-11-21T23:00:00-05:00” which could be read as “November 21st, 2016 11:00pm (EST)”. Now while we’ve read the “-05:00” as the timezone offset which equates to the Eastern Time Zone, it appears the .NET framework in the DateTime.Parse() method, takes that as a hint to adjust the value relative to the local timezone instead to “November 22nd, 2016 4:00am”. Can’t imagine any restaurant that is hard to get is open at 4am in the local time.
While on my laptop (using EST) it was working just fine, deploying this to say… an Azure instance (using UTC) introduces just enough frustration to want to kick puppies and pop a small child’s balloon in passing.
I’ve seen it for years in the intellisense popup in Visual Studio without ever looking at it, and now I know why it’s there. The lifesaving DateTimeOffset type works just like the DateTime type, but when fed the value I needed parsed instead sees the timezone value as an offset (thus the type’s name), not an adjustment hint.
Hopefully you see this before you do anything horrible to a young canine or child. For the record, doing either is mean. Asshole.
I want to start off by saying that having a monolithic application isn’t always a bad thing, and this article may not necessarily be for you. Yet. It just comes down to the correct timing of using microservices when it make sense and then diving into that work at the moment it’s needed, and not a moment later. Utilizing a microservices architecture too soon will hold you back and slow the development process back, whereas waiting too long to perform the migration makes the refactoring effort very painful.
- If you have a single product that was designed well, is easily maintainable, and carries minimal technical debt, you may not have a lot of reasons to invest into a microservices architecture. Or certain areas are becoming areas of concern for performance and scalability, then you may slowly split those areas out.
- If you’re like the rest of us dealing with multiple products through acquisitions, mergers, or reorganizations that were originally built in a time long ago before best practices existed for online services, there is little hope that it is maintainable or carrying minimal technical debt.
I haven’t touched the Spek project in a few weeks and decided to give it some attention tonight. In playing with Java, Ruby, Python, and Node.js over the past couple of months, I’ve wondered what sort of additional syntax or overall languages changes I should consider before finishing the grammar.
The Spek language is pretty much a duplicate of the Axum language developed by Microsoft back in 2009. I’ve only made a really small change to the syntax for how a developer would interact with a channel and possible network operators, but the rest of the language is exactly the same so far.Continue reading
In my daily browsing of stackoverflow.com topics, I stumbled across a conversation on ‘coined programming jargon’. The conversation is well on it’s way to go beyond the 8 pages and appears to have started somewhere in or before February. I’m not sure how I managed to miss this one, but the terms coined are quite amusing. I might just have to go and start using them in my projects for when I need a lift.
Here are my personal favorites…
- Pokemon Exception Handling – For when you just have to catch em all.
- Yoda Conditions – The act of using if(constant == variable) instead of if(variable == constant), like if(4 == foo). Because it’s like saying “if blue is the sky” or “if tall is the man”.
- A Duck – A feature added for no other reason than to draw management attention and be removed, thus avoiding unnecessary changes in other aspects of the product.
- Hindenbug – A catastrophic data destroying bug.
- Bloombug – A bug that accidentally generates money.
- Schrödingbug – A problem that some people see when they look and others can’t find at all. Often tied to the execution environment in a surprising way (or a cat).
- Heisenbug – A computer bug that disappears or alters its characteristics when an attempt is made to study it.
- Barack Obama – An [account or queue] that we assign our most aspirational tickets. Like stuff we’d really like to do with a project but will probably never get approval for.
- Fear Driven Development – When project management adds more pressure by firing someone or something else of similiar shock factor.
- Higgs-Bugson – A hypothetical bug predicted to exist based on a small number of possibly related event log entries and vague anecdotal reports from users, but it is difficult (if not impossible) to reproduce on a dev machine because you don’t really know if it’s there, and if it is there what is causing it.
- Chunky Salsa – A single critical error or bug that renders an entire system unusable, especially in a production environment.
- Hooker Code – Code that is problematic and causes application instability (application “goes down” often).
- Hydra Code – Code that cannot be fixed. Attempts to fix any single bug will causes two new bugs to appear. In the end, it should be rewritten.
- Ninja Comments – Comments that doesn’t exist in code where someone would normally find them
- Code Slush – The date after which no changes will be accepted, except of course, all the changes that management will ask for at the last minute. Like Code Freeze but accepting of the fact that some changes will still get in.
Update 9/15/2014: Link is now dead, so it’s just you and me now. If you know about a longer list of these somewhere, let me know.
I thought I might talk about my pre-blogging days of trying to learn PowerShell when I was trying to avoid learning the VBScript language (I don’t care much for the synatic qualities of the language).
I personally love the PowerShell language as I’m familiar with both C# and PHP, and (at least to me) it looks like a bastard child of the two. The creation and intialization of objects or variables are done the same way as in PHP and has the same method and property accessors that you’d come to recognize in C#. It took me about an hour to pick up the basics of the language, but I just needed to learn how to create classes so I could start causing some damage.
Unfortunately one of the lacking items in PowerShell, even after version 2 is the lack of native classes. The strength of the .NET framework has always been behind the PowerShell language, but it’s never been directly accessible unless you’ve built cmdlets that allow you such power, so your reliance on custom classes have required you to compile them using Visual Studio. Until such time comes around, there are at least a couple of workarounds.
I had pinged a few people around Microsoft to see if it might be possible after reading this blog entry regarding the CTP3 release of PowerShell v2 if the method in how one would dynamically compile C# code into an console application could be used in other ways. It evidently wasn’t quite clear from the original post, so James Brundage from the PowerShell team posted this blog entry showing how you can use the same technique to compile C# based classes on the fly in a script. Pretty neat!
If you’re not a blogger, but know PowerShell pretty well, let me know about any hidden or not-so-known tricks in PowerShell that you know of and I can make an entry for you. Credit will be given!