In this post I’d like to show you how I ported an Azure Classic Cloud Service application (which cost me $16 USD a month by the way) to a .NET Core Azure Function, and now host it in Azure for $0 a month! That’s right - Azure Functions are both awesome and (usually) free! Introducing realDonaldTron So back in late 2016, when our dear leader was elected president, I decided to have a little fun at his expense.
It’s been a while since I changed things up, so I decided on a new Twitter handle and blog domain. This site is now hosted at davidhaney.io and called “David Haney” which in my opinion is a much better (and more descriptive and maybe even more egotistical) domain than haneycodes.net and the old name of “Haney Codes .NET” Don’t worry - haneycodes.net deep links will redirect properly for years to come, so you won’t miss anything at all.
A few weeks back I wrote this tweet: I did a presentation / speaking thing last week that got me thinking: would it be useful to blog about how to build a resume as someone new to tech, from the perspective of a hiring manager? I might whip that up today or tomorrow if people like the idea. — David Haney (@haneytron) July 9, 2018 43 likes later, it’s clear to me that this topic is in-demand.
Well I failed badly in my mission to blog every week of 2017. I guess life and stuff just got in the way in the end. I’ll try to be more consistent in the second half of 2018. Anyway, I bring some news: I have a new blog engine, and we are hiring at Stack Overflow! New blog engine I was previously using WordPress but had many issues and concerns with it.
This post is for those of you who hire developers, and also junior developers who want to be hired. Let’s talk about how developers are just like individual stocks in the stock market. Time for a little role-playing: you’re now a stock market investor. As a financial advisor, your company has given you $2,000,000 USD to invest in the stock market. It’s made very clear that the future of the company depends on the return on investment (herein called ROI) – “gains” – that your investments bring to the company.
In case you missed the big news in the industry this week, a GitLab employee accidentally deleted a ton of production data and took their platform down for hours. It was only when everything was on fire and they were in deep trouble that they turned to their backup systems… only to find that none of them actually worked. Backup Prod Data Regularly Not exactly a groundbreaking statement, right? Everybody knows this.
In part 2 of my series on dev team interactions, I’d like to talk about conducting good code reviews. Most dev teams will find themselves in a situation where code reviews are necessary, and in my experience many do them very poorly. I’ve even worked in companies that had such a negative code review culture that people left the review sessions upset, even considering quitting. With a few easy adjustments, you can quickly learn to conduct excellent and positive code reviews with your team.
As a developer working for a company, you probably work on a team. The interactions on these teams are sometimes pleasant, and other times hostile. What’s interesting to me is that a lot of the time, a hostile interaction could have been a pleasant one if only approached differently. Hostile teams are created by the actions of the people on them, not by the situations they encounter. One such hostile action is blame.
If you’re working on an application built using ASP.NET MVC, you’re hopefully aware of the OutputCacheAttribute attribute which can be used to statically cache your dynamic web pages. By adding this attribute to a controller or action method, the output of the method(s) will be stored in memory. For example, if your action method renders a view, then the view page will be cached in memory. This cached view page is then available to the application for all subsequent requests (or until the item expires out of the cache), which can retrieve it from the memory rather than redoing the work to re-create the result again.
Well, I’ve utterly failed to blog at regular intervals, writing only three posts in 2016. Ouch. To be fair, one of those posts is insanely famous (the one about NPM and left-pad.js), but still, I’ve really let my readers – and myself – down. So, I resolve to write a blog post every single week of 2017, starting today. This will probably mean that I write slightly shorter posts, and maybe even multi-part series posts.