Introduction to Modern AI 2024 Edition: Part 1

It's hard to believe it has been almost six years since I wrote my last article on Artificial Intelligence (AI), "Practical Artificial Intelligence." In that article, I gave an overview of the state of AI and Machine Learning (ML) and some popular usage and tools at the time. Since then, things have gotten crazy in the AI world: everyone is talking about tools like ChatGPT, but most people really don’t understand all the terminology and tools or what they are best suited for. In this article (part 1 of 2), I will attempt to give you an updated look at this ecosystem and try to explain things in “Joel” terms.

So let’s start off by defining all the key terms and look at some examples of each.
Introduction to Modern AI 2024 edition

The 10-Minute Read to Understanding DevOps Tools: Update for 2023

Hey everyone, this is by far my most read article, and given the changing landscape of DevOps tools, I thought nearly three years later and heading into 2023 it was worth a refresh! For those of you who read the original article, I have updated it with a few small changes to my categorization of tools list since last time and added new key players to most of those categories (along with a few I missed the first time). There are so many test tools across all the various tech stacks and DevOps stacks, that I can't possibly put them all in here, but this time I tried to add some tools used in different worlds (JavaScript, Kubernetes, Java, front end, etc). Before getting to the updated article, here is a summary of some key trends we have seen across our 30+ projects and from our friends at Rhythmic Technologies in the industry.

  • We have seen an explosion of tools around microservices, particularly in the Kubernetes space. Tools like Envoy provide layer 7 proxy, and Istio and Linkerd provide layer 7 service mesh. At this point I consider these tools more purely operational tools, so I have excluded them from my list, but this may change on the next update! 
  • For well-run shops we have seen a lot of “less is more” lately. A lot of simpler pipelines, smaller test suites, less stages, less environments. A lot more Docker. Not necessarily a unified approach to Docker, but more of it!
  • For mismanaged shops we have seen a significant growth of complexity, mostly around microservices; instead of DevOps being used to reduce and manage cloud spend, it seems to have the opposite effect in these shops.
  • Simplified CI/CD approaches are on the rise, more GitHub actions and Bitbucket pipelines.
  • Moving DevOps/IAC code into the repositories they support (yay!)
  • Code coverage for infrastructure as code has gone up dramatically in the last 2 years. Low-level infrastructure (VPCs, related networking, security config, IAM) coverage remains low but it has improved a bunch.

Last week a few of my very senior colleagues and myself were remarking about how many new DevOps tools are emerging and how it’s getting harder and harder every day to keep track of them and where they fit into the world. I asked several of them where these tools, Ansible, Terraform, Salt, Chef, Bamboo, CloudFormation, fit in. Why would I use one vs. the other? Are they even the same thing? Am I missing a major player? I got back the same blank stares/questions that I had. So, I thought I would do some research, read, and try to make sense of it for all of us so we could classify products into categories or uses to which we are all familiar.

React Helpful Hints Series: Volume 2

React is a popular JavaScript framework that was developed by Facebook and has gained a massive following among developers due to its simplicity, modularity, and reusability. In this series of short “bloglets,” our team will cover a wide array of React topics, including developer tips, issues, and experiences. We are hopeful that everyone from the beginner to the seasoned professional will find something useful in each post. 

Using React Context

By Jeff Schuman

Developers new to React have a tendency to over-use property propagation to nested child components. The term for this is prop drilling. Prop drilling is generally frowned upon as it inhibits clean, reusable, and DRY code.

React Helpful Hints Series: Volume 1

At Solution Street, we love helping our clients solve their business problems through technology. When it comes to building responsive, dynamic web applications, we are big fans of the React ecosystem. React is a popular JavaScript framework that was developed by Facebook and has gained a massive following among developers due to its simplicity, modularity, and reusability. 

In this series of short “bloglets” our team will cover a wide array of React topics, including developer tips, issues, and experiences. We are hopeful that everyone from the beginner to the seasoned professional will find something useful in each post. And if you’re looking to build an amazing web application, we at Solution Street would enjoy talking with you and seeing how we can help!

Is Blitz.js the JavaScript Framework I’ve Been Waiting For?

The year was 2007. I was about to leave corporate America and try my first startup. I had been a Java architect for the past 10+ years and was ready to try something new. A friend of mine introduced me to a framework called “Ruby on Rails.” She said it was amazing how fast you could build stuff. Here is a link to the original “How to build a blog engine in 15 minutes with Ruby on Rails” video where David Heinemeier Hansson (DHH) shows us how to build a blog using Rails. After watching the video, I was sold that it was worth a try. I spent most of the next year building my startup primarily programming in Ruby on Rails. It took me a while to climb the fairly steep learning curve of Rails, and also to really learn the Ruby programming language, but once I did, I could build stuff faster than at any point in my 20+ year career. Rails has a doctrine of what makes it great; you can look at the nine items here. Looking back, what made Rails great for me personally was a handful of key things:

  • Convention over Configuration – Now most frameworks follow this paradigm, but Rails was the first to bring it to the masses. No more struggling with configuration files to get your environment set up properly, everything works right out of the box, and if you follow the rules, it’s painless.
  • DRY Coding – (Do NOT repeat yourself) – The idea here is that you only need to code something in one place to get it done. You don’t need to copy and paste code into five different places to get something to work. 
  • Developer Happiness & Productivity – Rails came with generators to get you started. They would create all the code you need to CRUD (Create, Read, Update, Delete) your resources. Rails also came with a handy console where you could test and debug your code in a full working environment. You could also code everything in one language, Rails provided helpers to generate most of the JavaScript you would need. Rails eliminated the multiple layers upon layers of coding you used to have to do to get something done.
  • True Reuse – We have been looking for the ability to reuse code for 20+ years. We have tried many different approaches, but Rails, because it is a complete ecosystem, has done the best job at it. When you are building an app, you can find a “gem” (which is a library) to do just about anything you want. For example, authentication, authorization, uploading files, paginating results – all these things come for free by using “gems” that are open source.
  • Majestic Monolith – For most of the applications we build, having a fully integrated, simple, coherent platform, and structure is the easiest way to build things. Sure, microservices and serverless have their place, but for 80% of the applications out there, having everything set up in one platform is the easiest way to construct software. Rails comes with all you need to build your User Interface, API, business logic and database.

Also worth noting is that Enterprise Java was the “state of the art” application architecture before Rails. The architecture of Enterprise Java looked something like this:

Do’s and Don’ts for Software Engineer Job Interview

In my estimation, I have given over 2,500 interviews in my career, the bulk of them for Software Engineer positions. I have been interviewing Software Engineers for over 25 years and in my current role as CEO of Solution Street, I conduct, on average, two interviews a week. Solution Street has been evolving its interview process for over 18 years, and we feel like we offer a pretty robust and fair process. In this article, I will give you the tips you need to put your best foot forward and succeed in your next technical interview.

Do’s for a Software Engineer Job Interview

First, let’s talk about interview Do’s. Based on my experience, here is my list of the top seven things you should absolutely Do!

RPA, Low-Code, SaaS/COTS, Custom – Which Is Right for You?

The year was 1994. I worked full-time as a software engineer and went to graduate school part-time to get my master’s degree. One of my professors told us that we would not be writing software with code within the next five years. Fourth Generation Languages (4GL) will make it so anyone can build software, and visual drag-and-drop tools will let us build anything. Fast forward 26 years, and we are still writing code. Even in 2020, recent articles predict the end of custom software development. Coming soon, robots will be writing code for us using GPT-3.

The current state of software options to solve your business problems is quite complex, and it can often become overwhelming. You read articles about robotic process automation (RPA) saving the world, or low-code/no-code solutions saving 80% of your costs, or software as a service (SaaS) solutions like Salesforce, ServiceNow, and others being the answer to all your problems. What if none of these work for you? When is it time to build your own software?

Understanding DevOps Tools

Last week, a few of my very senior colleagues and I were remarking about how many new DevOps tools are emerging and how it’s getting harder and harder every day to keep track of them and where they fit into the world. I asked several of them where these tools — Ansible, Terraform, Salt, Chef, Bamboo, CloudFormation — fit in. Why would I use one versus the other? Are they even the same thing? Am I missing a major player? I got back the same blank stares/questions that I had. So, I thought I would do some research, read, and try to make sense of it for all of us so we could classify products into categories or uses to which we are all familiar.

Before we start to talk about DevOps tools and categories, let’s take a step back and discuss a few basic (but often overloaded) terms and what they mean.