The Tesla Dashcam

I was driving home from the mountains recently and witnessed an accident. I have proof.

This is part of a series that covers my experience with a Tesla Model Y.

The Dashcam

The Tesla Model Y (and all models) has a number of cameras built into the system. This is recording all the time, and if you use the USB they give you (or buy another), you have the clips saved for the future. I bought a USB drive, and it’s been in the car recording when I drive. I sometimes use it when parking, but often not since that drains the battery as the car can’t sleep.

While driving home, I was slowing as I came to a red light. I saw two cars cross in front, getting ready to turn left in front of me. One accelerated, right in front of a car coming from my left.

The car going South, from my left, likely didn’t see the turning car as there were two cars stacked up to turn. The result is below, with a collision.

I haven’t been contacted by the police or insurance as of yet, but if they call, I’ve got video.

I like that this is built in. With modern cars having all sorts of computer tech in there, and cameras relatively cheap, I’d really expect that more manufacturers would put these in their offerings in the next few years. Or insurance companies would ask for them.

One annoying thing is the UI in the Tesla for viewing these is really slow to read the SSD and pull them up. Grabbing this out of the car and plugging into my computer let me pull off the video in a minute or two.

The hard part then is remembering to put the SSD back into the car 😉

Posted in Uncategorized | Tagged , | Comments Off on The Tesla Dashcam

Building Recommended Software Practices

Many of us work inside an organization that has a process for building and deploying software. We may find our org doing this well, or we may feel our process is poor with lots of room for improvement.

A lot of the discussion around how to be better at building software in the last ten years has been around the philosophy of DevOps. This concept doesn’t really prescribe how to build software, but give you goals to aim for. That means you still need to take the ideas of flow, feedback, and learning and decide how you implement them with your staff. What practices do you follow to ensure you can deploy quickly anytime your code is done? These can include ensuring you’ve tested code, getting feedback from customers, and more.

I ran across a post on recommended software engineering practices for an organization. The list includes seven things you should do:

  1. Keep documentation in the code repo
  2. Have a mechanism for test data creation
  3. Use rock solid database migrations
  4. Create templates for new projects
  5. Automate code formatting
  6. Automate a process for new dev environments
  7. Automate preview environments

This is a set of things I often preach to customers as well, especially 2, 3, 6, and 7. I often focus on the database and having curated test data, migrations you can count on and easy setup is important. And, of course, with SQL Prompt, you don’t need formatting ;). Just kidding, that’s important, too.

These are solid practices, and none of them are that hard to set up, but they do require some discipline and willingness to work as a team and maintain your process across time. Each of these items needs some care and feeding across time to remain relevant and helpful to your staff.

Do you have good software engineering practices? Are you proud of them and would you bring them to a new position? Or perhaps you wish your team would adopt better habits and a different mentality towards building software.

Steve Jones

Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

Posted in Editorial | Tagged , | Comments Off on Building Recommended Software Practices

Daily Coping 16 Feb 2023

Today’s coping tip is to focus on being kind rather than being right.

This is one of the things that grows my wisdom over time. I don’t need to be right anymore, at least not often. I can try to guide and assist without winning over colleagues, friends, family, etc.

One of my kids was having a bad time, and it was because of a poor decision on their part. Rather than try to make sure they knew the problem, or that I knew it, I tried to support and listen.

It is helpful for me to remember that I’m really responsible for myself, and somewhat my wife, but no one else. That includes my adult kids.

This is a good coping skill that reduces stress in my life, when I can support, offer, assist, but not take ownership or become invested in another’s decision or action.

I started to add a daily coping tip to the SQL Server Central newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here. All my coping tips are under this tag.

Posted in Blog | Tagged , , | Comments Off on Daily Coping 16 Feb 2023

The Cost of the Cloud

Basecamp (formerly 37 Signals) is quitting the cloud. One of the founders gives some reasons, and he had some detail in a tweet on what they’ve spent in the cloud the last few years. Over USD$3mm on various services, though their costs in search seem very high. I don’t, and haven’t, run as busy a business as they do, so I don’t know if they’ve truly done a good job architecting things and setting up services. They say they have, though I’d expect everyone to say and think that.

However, I’ll assume they are correct and they can’t optimize things any more than they are currently. Their decision makes some sense, and I agree with it. I’ve been surprised at the growth of the cloud, both in size and how quickly people are moving to the cloud. I’ve also been saying for years that if you have a steady or known workload, the cloud is likely very expensive.

Maybe that’s worth it for your organization. Not dealing with physical resources, maybe having slightly less staff, maybe less CapEx vs. OpEx. Those are decisions for management and finance people. For most of us, the cloud both simplifies some tasks and makes others more complex. Provisioning, testing out Proof-of-concepts, and scaling are easy. Identity protocols, gaining (and keeping) knowledge of how various options work (networking, storage, etc.) , and keeping track of resources become more complex. Not to mention the world constantly shifting under your feet as cloud providers change how their platforms work.

There are costs in both hard dollars (or your currency of choice) and in the time your staff spends dealing with a new way of doing business. The calculation of whether this is a cost that makes sense is very dependent on your situation. I have customers that love the cloud and others that hate it. The value they get varies dramatically and some would never go back to data centers while others are ready to work long hours to leave the cloud. Overall the sentiment is the cloud is great, but like many decisions made by management there are particulars that baffle the technical staff.

The one thing I have learned about the cloud is that it takes a different sort of mentality from staff than on-premises resources. We have to learn to spin things up and down, scaling as needed. We need to better understand budgets and not look at costs as though they were personal expenses. We also need to be flexible with resources, understanding that machines that are idle are not sunk costs; they are ongoing costs.

The cloud is amazing, and I think it is very useful in lots of situations, but a blanket move to the cloud can be expensive. Make sure that everyone involved in moving to the cloud understands that.

Steve Jones

Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

Posted in Editorial | Tagged | 5 Comments