An introduction to the C4 model

(Image source: The C4 Model for Software Architecture) This week, I was introduced to a new (to me) methodology called the C4 model. Now, in this context, C4 does not refer to the high explosive. In this case, C4 refers to a development methodology. Mostly, it refers to software development, but it has other applications … Continue reading An introduction to the C4 model

Improvement through rewriting

If you're an application developer (or at least you used to be one, like me), how many times have you come across an old piece of code that you wrote and said to yourself, "what the f*%k was I thinking?!?" You say to yourself, I can write that much better now than I did back … Continue reading Improvement through rewriting

Fixing the worst online job application

Earlier, I wrote about what may be one of the worst online job applications I've ever experienced (I'd suggest reading that article first; otherwise, this one might not make sense). It got me thinking: what if I had an opportunity to fix this horror show of an experience? Here's what I would do. My first … Continue reading Fixing the worst online job application

Quarterly Bar Hop at River Street Market, March 18 #NYTechLoop #Networking

CASSUG member Susan Lundberg and our friends at NY Tech Loop are hosting the Quarterly Bar Hop at the River Street Market, 433 River Street, Troy, NY, on Wednesday, March 18, 2020, 5:30-7:30 pm! Join us and other software professionals for beer, beverages, and networking! For more information, see http://bit.ly/32JYXKG

Better Comments

This is a reblog of a post by my friend, Steve Jones. I’ve often said that commenting code is a form of documentation, and needs to be done more.

Voice of the DBA

I assume most of your comment your code.

Well, you probably comment code most of the time.

I’d bet your comments have quite a bit of detail.

And you do this completely inconsistently.

That’s what I’d think, or maybe just what I want. Even the best developers I know will not consistently comment code. You can drift through any project on Github and see this. Those projects on GitHub might even be better documented because people know they are public. In most corporate environments I have worked in, I’ll find that when people get busy, or distracted, or even when they’re experimenting to find a solution, and they don’t write detailed comments. Usually only when someone fixes a bug, with a solution found quickly, do I get a really useful comment.

There are all sorts of ways that people think about commenting their code. I ran across a post from…

View original post 254 more words

My introduction to Docker

With my (still-relatively) new job comes an introduction to new (to me) technology. In this case, the technology in question is Docker. For those of you unfamiliar with Docker (like me), it is, in a nutshell, a tool for deploying and running an application within a container. It is an improvement over VM (virtual machine) … Continue reading My introduction to Docker

#SQL101: On data types

Previously, I talked about something I saw in the code that built the tables in my baseball database.  I wrote last time about primary keys.  In this article, I want to talk about data types. Let's revisit the code that builds the Batting table again. CREATE TABLE [dbo].[Batting]( [playerID] [varchar](50) NULL, [yearID] [varchar](50) NULL, [stint] … Continue reading #SQL101: On data types

Scary Deployments

My friend Steve Jones ‘blogged this, and this spoke to me enough that I thought it was worth a re-blog.

Voice of the DBA

I was listening to a web developer talk about some fundamental changes in a web platform. In this case, an older system was being replaced completely with a new one, and as one of the reasons, the developer showed some typos that had existed on the old site for years and hadn’t been fixed. The reason? This quote:

“Very few people understand how the entire system works that are still in the building … The thought of deploying [changes] brought people to tears.”

That can’t happen. Ever. We can’t be afraid to touch systems. When this happens we get paralyzed, and we don’t do good work. Or we’re not a good fit for a project. Or perhaps, we’ve got a bad attitude.

I’ve worked in a few companies where developers were afraid to touch a system. It’s amazing how quickly this attitude becomes contagious, even scaring management from considering change…

View original post 148 more words

My favorite PowerShell references

One thing I've been doing to improve my skill set is teach myself PowerShell.  For those of you who don't know what that is, here's my description in a nutshell: it's the command prompt on steroids. So far, I've come across some references, some good, some not so good, to guide me in this endeavor.  … Continue reading My favorite PowerShell references