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.
One of the projects I’ve spent the past month working on is a system called Foundation that will eventually become the company’s one stop shop for automation and workflow management. It’ll keep track of everything from services to environments, and the resources they are using underneath in our private cloud and public cloud provider.
In the process of learning Code First Entity Framework for the first time (all previous provides were Data First), I came across an interesting event that you could use to prepare entities before they are committed to the database. For example, you have some entity properties that need to be checked at last minute and possibly changed. You could do the following without having to layer in an abstract DbContextBase between your own context implementation and DbContext that overrides SaveChanges() to perform the same work before calling the same method off the base class…Continue reading
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.
Unless you have some really great connections, every type of debt I have ever had the displeasure of dealing with has come with some sort of interest payment. If your company has adopted Agile software development methodologies (Scrum, Kanban, XP, etc), but is only delivering software on a quarterly basis (or less often), chances are that you are paying a ‘release debt’ with interest.
If the concept of ‘technical debt’ could be overly simplified as ‘stuff that you’ve been meaning to fix‘, then you could easily view release debt as ‘stuff that you’ve been meaning to deploy‘.Continue reading