So, How is the Tesla Now? Part 1: 50,000 Miles in...

     So, I am trying this new format.  I have had some time to think, and I kept writing these massive walls of text; then I thought, ok, I'm sure everyone loves reading massive walls of text, but hear me out.  What if the wall of text had a 500-ish word limit?  So, I tried that over the weekend, and I'm scheduling posts for 10AM each day.  I don't know how well this works, but I'm trying it.  

     That being said, this post is Part 1 of a 3-part series following up on my 2023 Electrified Road Trip posts and The Test Trip V1 after three and a half years with our 2023 Tesla Model Y. It will take three posts to reach my final verdict in Part 3, because while this is easily the most fun vehicle I have ever owned, a few things over the past couple of years have left me genuinely conflicted. Today in Part 1, we are starting with why I suddenly parked the Tesla for a week right before hitting 50,000 miles; in Part 2, I will pull our real-world cost and trip telemetry out of Home Assistant and TeslaMate; and in Part 3, we will tackle Full Self-Driving, dealership games, and whether I would actually buy another Tesla today.

     Right now, the odometer in my TeslaMate dashboard sits at 49,862.8 miles; meaning I have exactly 137.2 miles left before the 50,000-mile basic factory warranty expires. After reading a couple of articles about Tesla owners who scheduled a detailed service inspection right before their warranty cutoff and caught multi-thousand-dollar suspension or hardware repairs while Tesla still had to foot the bill, we booked the $500 comprehensive inspection.

     Booking that appointment created a funny logistical problem: with under 200 miles of buffer left before our service date, we had to park the Model Y for the week so we wouldn't cross 50,000 miles early. Normally, my daily routine is dead simple. I set the charge limit to 60% and plug the car into our charger every night just like charging a cell phone. Daily school runs and local errands only drain the battery down to 55% or 50% (honestly, I could charge it on Sunday night and coast through the entire workweek without touching the cord, yet plugging it in nightly became an easy habit).

     To save those final 137.2 miles, we went cold turkey this past week and drove our 2018 Honda Odyssey everywhere - and boy, was that a rude awakening. Before the Model Y, I always drove a minivan (Chevy Astro, Pontiac Montana, Honda Odyssey) or a 2008 Honda Accord, so the Tesla was already the sportiest car I had ever owned by a long shot. When you drive a gas car every day, you never notice the delay; however, once your brain gets wired for an electric motor that moves the exact instant your foot touches the pedal, going back to a gas engine feels sluggish. You press the gas pedal in the Odyssey and wait a full eternity while the engine revs up and decides whether it actually wants to move the van. Any electric car will spoil you this way... and it makes me never want to drive a gas car again.

     Parking the Tesla also highlighted how differently the two vehicles handle maintenance and recalls. Over the past three and a half years, our Honda Odyssey has had eight separate factory recalls; every single one meant dropping the van off at the dealership overnight (or for two full days while we juggled family rides). By contrast, nearly every recall on the Tesla was an over-the-air software update that fixed the car in my driveway while I was asleep.

     Ironically, we did just get our very first physical hardware recall on the Tesla to replace the headlights. Just like an active Honda recall where we couldn't get the part, the replacement Tesla headlights are currently on back order; which makes me wonder what would happen if my headlights actually burned out tomorrow (would I just be stuck with a car I can't drive after dark... during a time of year with 4 hours of daylight per day?!??).

     Anyway... while the Model Y sits parked in the driveway saving its final warranty miles, Part 2 will open up my Home Assistant and TeslaMate database to see what 20,833 kWh actually cost us, how badly the Odyssey's usage collapsed, and how the car handled 30 mountain ski trips - all building toward my Part 3 verdict.

Later,

     SteveO

Part 3: From Xbox and Windows 95 to Today: Who Trains the Next Senior Engineer?

   This is Part 3 (the final installment) of my trilogy on agentic software development. In Part 1, we looked at the clash between slow corporate code reviews and live voice-driven prototyping; in Part 2, I walked through how I run a multi-agent team at home with FCI Operations and my Virtual Villa simulator. Now it is time to connect those dots and get to the final point I promised back in Part 1 - why this amazing new workflow leaves me genuinely conflicted about the future of our industry.

     In Part 2, I mentioned how running a multi-agent engineering pipeline changed the way I write requirements; specifically, how often I come up with performance requirements on the fly while actually using the software and realizing, "Hey, this button should not take this long to respond."

     We love to pretend in software engineering that we can sit down before writing a line of code and declare a blanket non-functional requirement like, "All UI interactions must complete within 500 milliseconds." That sounds wonderful in theory, but in practice, it falls apart the second your software meets unpredictable hardware.

     This is something I learned early on during my time at Microsoft working on Xbox 360. On a console, Microsoft has strict Technical Certification Requirements (TCRs). When a player launches a game or presses a button, the game has a hard time limit (down to the second) to display something on screen (even if it is just a spinning wheel or a loading bar) so the user knows the system didn't freeze. On an Xbox, enforcing that rule makes complete sense because every single customer is running the exact same hardware in their living room.

     Desktop and web software is a completely different animal. You have no idea if your user is running a high-end gaming rig or some $99 Walmart cheapo PC that barely boots the browser. The same unpredictability applies to the cloud backend too; you don't know if a request is hitting a warm Kubernetes pod or a serverless AWS Lambda function that just went into a cold reload - surprise, your half-second budget is already gone. Because of that, real performance tuning usually happens in the middle of testing a working prototype, when you feel the lag yourself and tell the agent to fix the bottleneck.

     However, watching how easy it is to let agents handle that heavy lifting brings me full circle to my biggest worry for our industry. Right now, a lot of developer burnout is coming from engineers trapped between two worlds: trying to satisfy slow, pre-AI corporate review processes while simultaneously being pushed to adopt high-speed agentic workflows.

     As the agentic model wins out, we are heading toward a world where one senior engineer leading a team of AI agents can comfortably do the work that used to take five or more developers. I love the velocity in my own homelab, yet I can't shake the obvious question: where do the next senior engineers come from?

     Think about how operating systems evolved over the last thirty years. Back in the Windows 95 era, you only had a tiny sliver of RAM and CPU, so engineers had to be incredibly disciplined and sparing with every megabyte. Today, a modern OS like Windows 11 will happily eat a gigabyte of RAM without a second thought, and then chew up another gigabyte just to draw the graphical user interface so you can finally run an application on top of it. Now, there are valid reasons for modern OS features, and I am certainly not arguing that we all need to go back to Windows XP here; however, cheap hardware made us lazy about resource discipline.

     I worry we are about to treat software engineering talent the exact same way. Right now, it is very tempting to just let the agents do everything because you can move so much faster when you don't have three humans staring at every line of AI-generated code. If the function does what it needs to do, the performance feels good enough, and a security auditing agent says the security is good enough, we ship it. Yet writing those routine tickets, breaking things, and debugging the mess is how junior developers learn what good code actually looks like. If nobody is doing the foundational work anymore, in ten years, who is going to have the deep systems knowledge required to review what the agents are building?

     Anyway... that is the full circle of my rant on agentic development. I am having a blast building with these tools, even if I am a little nervous about where the industry ladder goes next.

Later,

     SteveO

Part 2: Sleepy Tom, Baking Martha, and My Multi-Agent Homelab

      Welcome back to Part 2 of my 3-part series on agentic software development. In Part 1, I vented a little about how painfully slow traditional corporate code-review queues feel once you have seen real-time, voice-driven AI prototyping in action. Today, I want to show you what happened when I took that rapid-iteration philosophy and built my own multi-agent engineering pipeline at home; before we bring everything full circle in Part 3 to ask what this massive jump in solo productivity actually means for the future of software engineers.

     That homelab experiment turned into FCI Operations, a "Paperclip company" I created that combines local AI inference (using Hermes Agent and local models on vLLM) with frontier models like Google Antigravity, Claude, and Codex. Instead of having three humans stare at every pull request, I set up a pipeline where specialized agents write the code, build the test harnesses, and review each other's pull requests before I ever step in as the final human quality gate on `main`. I even have local agents that dispatch tasks to managed cloud agents like Google Jules, wait for Jules to open a pull request, review the diff, and approve the merge so the CI/CD pipeline can take over - all while I am off doing something else.

     Of course, if you are going to let AI agents write and review code at high speed, you can't rely on wishful thinking to know if the software actually works; you need serious automated verification (otherwise you are just generating bugs at the speed of light). In my case, I was building and testing an integration tying Home Assistant into an analytics cloud platform for senior care, and I hit 95% code coverage by building an end-to-end simulation engine called the **Virtual Villa** harness.

     The idea behind Virtual Villa was simple: Home Assistant thinks it is talking to a house full of real physical Z-Wave motion sensors, contact switches, and smart plugs, and the cloud platform thinks it is monitoring a real building. In reality, the whole thing is a simulated retirement community populated by synthetic resident personas that I created.

Each resident has their own daily routine and quirks:

• Sleepy Tom, who sleeps in late and moves at a glacial pace.
• Active Jane, who is up at the crack of dawn and out the door on a strict schedule.
• Antisocial Jack, who mostly stays holed up in his living room all day (honestly, I can relate on some weekends).
• Baking Martha, who spends practically her entire day moving around the kitchen.

     Having these virtual residents wander around their simulated homes (with a little randomization around activities) gives the system a baseline of daily human activity. Once that baseline is established, I can start injecting anomalies. For example, what happens if Active Jane doesn't get out of bed at 8:00 AM one morning? The harness lets me simulate that exact scenario end-to-end, feed the telemetry stream into the cloud analytics engine, and automatically verify whether the right alerts get triggered and sent to the right caregivers.

     Most of that simulation code, along with the unit and integration tests validating it, was written, reviewed, and refined by agents working in a loop. My role shifted from typing boilerplate to acting as the product owner and system architect; I use the tool, spot where the behavior or speed feels off, and set the requirements for the next pass. I watch the system resources, and tell the agent when it is using too much memory or CPU. Agents monitor the logs daily for error messages, and report to me with suggested next steps.

     Coming Up in Part 3 (The Conclusion): I have to admit, part of me feels like a wizard running a five-person engineering team out of my home office; however, the other part of me sees a huge warning sign in how this works. Discovering performance requirements on the fly exposed a classic trap I remember from my days testing games at Microsoft, and it points directly to the final conclusion of this series: if agents are writing and reviewing all the code, who is training the next generation of senior engineers? Let's wrap up the trilogy in Part 3.

Later,

     SteveO

Part 1: Move Fast and... Wait for Reviewers?

     I am back, after... years.  Trying some new formats, but today I am starting with a bit of a rant... I am going to schedule some follow up posts that hopefully have a more balanced feel than my original 2,000 word wall of text I wrote over the weekend, and this is a not-so-quick heads-up: this post is part of a 3-part series about where I think AI-assisted software engineering is actually taking us. This is one of those love/hate topics for any developer, and its hard to know where all of this lands. So, as promised, I will start today with a rant.  Its about the frustrating disconnect inside modern corporate engineering teams, then detour through my own multi-agent homelab tomorrow, and finally arrive at the big question in Part 3: when AI agents make one senior engineer as productive as a five-person team, where the heck do the next senior engineers come from?

     So, over the past several months, I have been watching a pretty fascinating contradiction play out across the software industry. On one hand, executives everywhere are handing down mandates to push the envelope with AI and crank up development velocity. Everyone wants to get back to that classic tech ideal of moving fast and breaking things - just without the part where anything actually breaks. On the other hand, those exact same organizations are clinging for dear life to pre-AI "Human in the Loop" bureaucracy; meaning an engineer uses AI to generate a fix in ten minutes, and then the ticket sits in a queue waiting for two human code reviewers to sign off before it can ever be closed.

     If you stop and do the math on a four-person engineering team, requiring the author plus two peer reviewers on every single AI-assisted ticket means three out of four people on the team are tied up touching the exact same unit of work (which is a hilarious way to define "high velocity"). Those two ideas are completely antithetical to each other. There is a massive disconnect between the way corporate leadership dreams things will get done with AI and the actual rules they enforce on the ground.

     Right now, the traditional enterprise loop still looks painfully familiar: write some code, read some code, review some code, review it some more, run a few tests, and then answer a long thread of inquiries about why a function was written a certain way. All of this happens before the change is ever deployed to a proper staging environment where someone can actually click around and use it; literally adding days of overhead to a change that took minutes to write.

A while back, I got a front-row seat to a completely different way of working while collaborating with my friend David. Watching the way he works with AI was a real lightbulb moment for me. Instead of treating AI like a slightly faster autocomplete inside an IDE, he literally talks to the AI (with his voice) to spin up a working prototype, and immediately deploys that prototype to an internal staging environment.

     From there, the real magic happens while we are actually using the tool. In real time, while we are testing the workflow from an end-user perspective and running into flaws, he just speaks to the AI. He tells it the exact problem we are seeing, explains why it is a problem, and contrasts what the app is currently doing against how he expects it to behave. While we are still sitting there testing, the AI updates the logic and redeploys the fix on the fly - no three-day pull request thread required.

     Sure, new bugs pop up as we push the prototype further; that is just the nature of software development (and honestly, half the fun). However, by working in that tight voice-to-staging loop, the development agent stops being a fancy text generator and becomes an actual engineering partner. You iterate rapidly until the product meets the functional requirements and the spirit of what the user actually needs, and then you can circle back to optimize the code afterward; or better yet, hand it off to a separate, adversarial AI review agent to audit test coverage and suggest improvements before anything merges to `main`.

     Coming Up in Part 2: Watching my friend David work that fast left me slightly obsessed. If voice-driven rapid prototyping works that well with one developer and a staging server, what happens when you build an entire multi-agent engineering organization around that philosophy at home? Next time, I will introduce you to FCI Operations, my Virtual Villa retirement community simulator, and how I put a crew of AI agents to work in my homelab (which sets up the bigger industry problem we will tackle in Part 3).

Later,

     SteveO

The Test Trip V1

 

     Over the past couple of months, we have been getting used to mostly driving an electric car.  It has become clear that our daily driving needs are more than met by having a Tesla and charging at home over night.  Our normal daily activity can actually be exceeded with a 110v 15 A mobile charger, but having a 220v 48A wall connector gives us flexibility to guarantee we can fully charge a completely drained battery over night.  So, at this point, I am trying to put myself into a situation where I need to charge;  technically, I didn't really do that yet, but I was a little nervous testing the limits of the battery while taking my family through a mountain pass with occasional drops in cell phone reception.

     So, to keep this kind of data focused, I created a Grafana Dashboard for the trip.  The dashboard itself was 99% created by TeslaMate, and I filtered the data from the time I parked my car the night before until I got home.  I included just a couple minutes of charging after I got home to make sure I had the final battery percentage in the tables.  I hope you enjoy!  

     So, moving to the trip, my original plan was to charge the battery to 100% over night, drive over a 4,000ft mountain pass to the village of Leavenworth that is about 100 miles away, charge at that location while hanging around town for the day, then drive home along the same route. It turns out, as soon as my kids learned they can watch shows on the screen while parked at a charger, they insist that we let them watch as soon as we plug in.  This was okay with me, as it gave me some time to get out, stretch my legs, and walk into a nearby market that actually had normally priced products.  There were 13 chargers at the station, and only about 5 of them were occupied by vehicles charging.  One was occupied by someone who parked their Tesla at the charging station but was not charging their car.  Very rude, and poor etiquette.

The total trip distance turned out to be 221 miles, and it cost me about $13.90 for electricity.  By contrast, if we had made the same trip in our Honda Odyssey, the 11 gallons of gas would have cost us about $55 based on local gas prices, which hover around $5/gal if you shop at Costco or a grocery store.  As I'll cover a little when going over the charging, you will see I could have cut nearly 25% off of the electricity costs if I were more aggressive with my battery.

 

     I had set the wall adapter to charge the car as slowly as possible the night before.  I don't know if this actually matters, but I have never charged the car to 100% before, and wanted to put as little stress on the battery for this first trip.  It ended up taking around 10 hours to charge, but I could have done it in 3 or 4 hours if I maxed out my Tesla Wall Adapter.  You may also notice that when I charged in Leavenworth, I added 30% capacity to the battery, and I returned home at the end of the day with 43% capacity.  This means I did not need to charge the car at all that day, and I could have either completed this trip on a single charge; meaning I could have saved $3 by charging at home compared to using the charger in Leavenworth.  Alternatively, I could have charged the battery to 80%, and put less wear and tear on the battery by not charging to 100%.  So, it turns out this trip, which apparently a lot of people think is too long for a day trip, 

 

     Here I take a look at my battery state of charge for the trip.  I had gone a couple days before the trip without charging, which is why the battery was under 40% the night before, and you can see I slowly charged the battery over night.  This was done by setting the charger Amperage to try and target my originally scheduled departure time of 8AM; as usual, the family did not like to wake up in the morning, so our actual departure time was a couple hours later.  Our power usage increased steadily as we traveled over the mountain pass, then leveled off after crossing Steven's Pass.  The majority of the time, we were traveling 55-60MPH the entire time, but I don't think anyone would be surprised to hear that mountains effect battery consumption.  We charged up in Leavenworth before parking and hanging around town for the day.  Finally, you can see on our way home, we used a lot of battery initially on our way up the pass, and actually regained about 3% going down the other side.  The weather was dark and fogging going down the west side of the pass, so we actually slowed down to around 45MPH.  Regenerative breaking was used to maintain speed, and this resulted in a little boost.

     Finally, here is the elevation chart.  I cut off the left side because it was a long line sitting at 387 feet.  You can see the mountain pass was about 4,000 ft high, and Leavenworth is about 1,100 ft in elevation.  you will also notice right around noon, we stopped at a rest area for the kids.  Like I have read many others report, we need to stop for bathroom breaks far more often then we need to stop and charge the car. You can also see while in Leavenworth, we moved the car down by the river at about 17:00 so the kids could play in the park for about an hour before we drove home. 

     In conclusion, the Tesla was perfectly suited for this type of trip.  I also have no doubt that most electric cars these days would have a similar experience.  There is an Electrify America charging station just a couple blocks away at a grocery chain across the river from the Tesla chargers, but I didn't actually investigate to see if it was good.  I will also noticed that several hotels in the area have destination chargers, which could be nice if you were staying overnight; however I have no experience with that.

     In hindsight, I think I should choose a slightly more challenging route for a road trip in preparation for our cross country journey.  Maybe something with an overnight stay that requires stopping to charge in both directions to reach our destination.  We also primarily drove 2 lane highways for this trip, and I've heard that Interstate highway travel uses more battery.  So, until the next phase in my electric car journey, I will go back and plan something.

   One final note about the driving experience.  As I commented to my wife at one point, the Tesla pretty much drove itself on Basic Autopilot for the entire trip.  I had my hand on the wheel, and there were 2 or 3 disengagements where I didn't like the way the car was handling some of the sharper turns, and I often found myself uncomfortable with how close to the center line the Tesla would drive.  I am confident it was just keeping the car centered in the lane, but I do prefer hugging the outside line when going 60mph on a 2 lane road; I just don't trust the other people to stay on their side that much.  However, the basic autopilot functionality did surprisingly well on those curvy mountain highways.

So, that's all for now.  I will start planning for a longer road trip, but I'm really starting to feel good about this cross country trip!

Later,

     SteveO

Anywhere You can go, I can go cheaper!

 

     I have been testing the waters more and more as I drive further in my Tesla; then today Tesla announced they built their 50,000th charging station.  Here is a link, if you care to see the interactive version of the map above.  So, looking at the availability of all these chargers and hearing testimonials from people who actually drive their Teslas across country makes me feel pretty confident about going on this trip this winter.  

     Certainly sounds much better than the horror story of Granholm's caravan blocking EV chargers with a gas car. This is an unethical practice called ICEing (verb, ICE = Internal Combustion Engine); in this case they ICEd a family with a baby when her advance team blocked a charger they planned to use for the caravan.  Although, part of her problem is that she had a fleet of cars traveling to showcase electric car usage.  Which was compounded by the fact that most private charging stations have issues (broken or vandalized chargers are huge problems here.)

     One reason using a tesla charger is generally a better experience is the lack of user interface on the machine itself.  When you plug the charger into your car, there is a data connection between the charger and the car, and the car itself initiates the charging session.  This means you don't need to install an app on your phone, or log into a server to start the charging session.

  This weekend, It went to Electrify Expo Seattle, and had some interesting conversations with the companies putting on the show.  I was surprised to find out that most of the bicycle vendors had little to no down time on their electric bicycle fleets as they offered test rides to an endless line of people eager to give the bikes a ride.  I was especially excited about the Riese & Muller cargo bikes; the ones with the big box in the front that can fit both of my daughters side by side in them.  Those were pretty fun to ride, especially the Load 75 which could actually fit 3 kids, but that $10,000 price tag will prevent me from getting it.

     The main focus at Electrify Expo is really the cars, and the test drive track!  It was fun to compare the acceleration on on the Model X Plaid to the Porsche Taycan; its close, but I think the Model X wins.  I was also excited to take a good hard look at the Ford F-150 Lightning, which is a pretty impressive truck.  While Ford is supposedly switching to NACS (aka the Tesla port), and they are working with Tesla to work out billing for charging, but right now they still use the CCS connector.  I think getting everyone on one charging port is really important, and because it seems like a lot of companies have agreed on NACS, we should just do that and move forward.

     So right now, I look at the map above, and feel like it would be easy for me to get across the country in a Tesla.  I also like seeing all those destination chargers (the gray dots), which are slower chargers at hotels that are intended for overnight charging while you sleep.  Those could be great for topping off if you drive ~50 miles past your charger before stopping for the night.

     The biggest "concerns" I hear are from people who don't have electric cars telling me that its not a good idea yet.  However, I think the majority of Tesla owners are confident in the Tesla super charging network.  Additionally, I'm hoping to find a couple of those new Flying J stations that have electric charging stations too, that could be pretty sweet!  So, getting closer to the drive, and I'm pretty excited about it!

Later,

     SteveO

Electrified Road Trip Part 2: Tracking with Teslamate

In preparation for my big road trip, I added Teslamate to my Home Assistant setup.  I have to say, I am sad that I didn't do this on day 1.  This little platform is amazing, and it not only gets a huge amount of data out of Tesla's cloud and on to my own hardware, but it also generates some wonderful Grafana dashboards too!  It is kind of a game changer compared to the way I have collected stats from my current car, and just using the unofficial Tesla Integration for home assistant.

So, the integration's main screen doesn't look like anything special.  The map shows the real time location of the car, along with some basic stats about the car.  You can also use Geo-fences to give common locations any name you like, and you can even set a charging price for the location.  This is particularly useful for charging at home because there is no receipt for purchasing power like you get from a charging station.  I will get into manually updating charge prices once I figure that out, but I rarely charge anywhere other than home, so it is a low priority task for me to sort out.

The real advantage comes with 2 backend features this plugin provides.  First, the plugin integrates with a database to log all your data about your car.  This data goes far beyond just what you see on the plugin page, and this is why Grafana is the real hero for this plugin.  The second feature is MQTT, which is just a protocol used by IoT devices to communicate updates.  Once you have these two features, you can create dashboards in Grafana to visualize the data and create reports, and MQTT sends the data to home assistant so I can trigger events based on the reported stats.

To the right I show MQTT explorer, which shows an example of the message data Teslamate sends to Home Assistant.  This data gets updated in real time, and one thing this does for me is update any time the car is unplugged from the charger immediately, rather than having to wait for the integration to poll Tesla for the data, which can take anywhere from no time to 5 minutes.  One problem this caused me a few times is that I would unplug my car, and have Home Assistant log the data to a google sheet; however, if the data didn't get logged immediately my car would not be at home when the data was logged, and my cost estimates would be off.  I guess Teslamate removes the need for this Google Integration too, which I appreciate reducing the number of cloud dependencies I have.

Possibly the best part of the this addon is Grafana Dashboards!  For those who don't know, Grafana is a web application that can collect data from databases and organize it into Dashboards, which are a collection of charts, graphs, and data.  It is somewhat popular for its ability to collect data from many places and combine it all together into a single screen/report that is full of pretty pictures.

Teslamate has a bunch of dashboard that is loads into Grafana if you set it up correctly.  Its a great way to visualize things like your most recent trip data and commute data.  For example, this image shows a track for everywhere I've driven this month. When I scroll down through the list of drives I've made, I can tell that I drive the same few routes over and over again, and it gives some nice summary information like how efficiently I drive (256 Wh/mi) and the fact I have paid about $13 to drive my car 265 miles (which is WAY cheaper than gas).  Just getting access to this data is a critical asset to accurately estimate my personal cost of driving the car, and having a few months of data under my belt will give me a clear picture of how far I can drive my car on a single charge.

For those interested in the process of getting this all set up, I added 3 home assistant add-ons using the instructions on the mat-FFFFFF github repository here.  If you are savvy with docker and have a spare raspberry pi laying around, I have to admit most of the troubleshooting resources online focus on putting everything into its own container.  However, its not too difficult to follow the directions and get it all setup, but maybe that could be a good thing to write about next.  Let me circle back around to that once I get around to refactoring a couple things for best practices.

Anyway, that's it for now.  Until next time.

Later,

SteveO