OK fair enough. There was some salesmanship and exaggeration going on for sure, but I thought the follow up quote clarified what he meant, or at least the way I read it, which is that code assistants will significantly reduce the amount of boilerplate coding that users are having to write by hand, which will give engineers more time to spend on the design part of the job. I didn't read this as saying your job is not safe because AI is coming, but maybe I am looking at this with tinted lenses
This is really cool! Found a small bug - when you add a second card, the second card displays a pill with the total time difference between the first card and second card. When you switch the order of the cards by dragging, the pill remains on the same card so it's basically showing the total time difference in reverse. Clearing the cards and starting over with the switched order but by creating each card again results in the pill being displayed on the correct card.
can you share more details about what's breaking? Is it a specific integration? Is it in general? What breaks? This is not consistent with most users' experience but it's hard to know without more specifics.
Wow, have a little heart why don't you. Sure, this isn't going to revolutionize anti-poaching, but it shows two things:
1. Teenagers can build cool things too! We need more kids interested in STEM and females are underrepresented, so these "puff" pieces are great inspiration for the next kid who happens to come across it.
2. All that was needed for her solution was a cheap FLIR camera connected to an iPhone 6, meaning you don't have to be rich/VC funded to experiment with hardware solutions.
This is Smithsonian Magazine, not the Wall Street Journal. I say bring on more stories like this!
I took down all cellular data traffic in Philadelphia for 2 hours.
I wrote the operating procedures for performing a backhaul upgrade in preparation for the launch of LTE. The upgrade was being performed on our primary routers which all traffic traversed. The operation had been performed several times successfully, but after the last implementation before the issue, I was informed that a couple of the lines were wrong (they had extra arguments). I did a find and replace all, shot the document off to the next team, and went about my day. The technician who was doing the upgrade called me on the afternoon of the upgrade (it was a Sunday) and asked if any of the initial steps were disruptive as he wanted to get started on the prep work ahead of the maintenance window. I said no and he proceeded. Mind you, this was also during the World Cup so I was out at a bar with my friends and not paying attention to my phone. About two hours later I looked at my phone and had multiple missed calls and voicemails from him, so I immediately ran to the MTSO. Turns out my find and replace changed some commands - the end result was that instead of adding additional VLANs to in-use interfaces, it replaced all of them with the new ones, which weren't carrying any traffic.
The fix was simple, we had failover routers and at some point after he couldn't get in touch with me the technician reached out to one of my peers who quickly told him to failover. He should have known to do that but he was also panicking. I called my boss and told him what happened and that it was my fault (and I genuinely believed it was. I wrote the bad procedure AND I approved activities outside of the maintenance window), and he told me to be at the office with the technician first thing in the morning the next day.
I couldn't sleep that night, this was early on in my career and I thought it was over. But that meeting ended up being one of the most transformative moments of my career. My boss's boss, a director, quoted the FAA's ethos of how a good system should have checks and balances, and if a mistake happens, the system is at fault, not any individual. We walked through the play by play and identified multiple opportunities to both avoid the issue that arose and to resolve the issue more quickly. We came up with an action plan as to how to make sure our "system" was more mistake proof for next time, and that was that.
That meeting has always stuck with me, and I always remind myself of that conversation whenever things at work don't go as planned. There is almost always something in the system that can be improved to account for human error, which should be expected.
Do you have any evidence to back up the claim that “a significant portion of the DC population constantly thinks someone is out to get them”? Admittedly anecdotal but I live in DC and I wouldn’t characterize myself or anyone I know in the area that way
Not OP but if you are willing to run HomeAssistant, I built a zoom integration [0] that uses web hook events from Zoom to tell HA when you are “busy”. This triggers anytime my calendar shows I’m supposed to be in a meeting, whether I am or not. But the HA Mac app also provides sensors for your mic and video so you could combine the three sources however it made sense to achieve this
Have you looked at AppDaemon [0] [1] or Node-Red [2] [3] as alternatives to using YAML to write automations? AppDaemon allows you to write automations in Python, and Node-Red allows you to do it in a visual workflow editor. I haven't made the switch from SmartThings to Home Assistant yet because I haven't been limited by SmartThings yet and it was simple to set up, but when I do switch, I will probably start with those tools since the paradigm is more familiar to me. You can't get away from YAML completely since you would still need to build your sensor and device definitions in YAML, but I think the YAML structure works better for that use case anyway.
I'd assume the parent comment is referring to the base package version of the Mazda 3. I was able to get a 2015 Mazda3 S Touring for ~$25k with all taxes and fees included, so I think $20k is a fair estimate if you assume the base package
Apple had more negotiating power than any other cell phone manufacturer had in the past. The first iPhone that supported the Verizon network was the iPhone 4. At that point it had already been proven to be wildly successful, and it was one of the few things that people could knock Verizon about (aside from price). I'm pretty sure Apple held all the cards in the negotiations to get the iPhone 4 on the Verizon network.
Contrast that with every Android OS based manufacturer:
1) The majority of them were companies that had been working with cellular providers for years already. They probably already had agreements in place with providers about how things would go (bloatware, extensive testing, etc.).
2) They were competing with each other for market share because the OS wasn't a differentiating factor (their bloatware/cosmetic overhauls were weak attempts to establish software differentiation).
3) Verizon made a big investment in Android with the Droid line, providing marketing, branding, etc. Any other manufacturers that were building Android phones had to compete with these devices and had to market on their own. Verizon had all of the cards.
It's slowly changing, but it boils down to:
1) Manufacturers trying to compete (they often add plenty of their own bloatware)
2) Verizon using a model they're familiar with from the feature phone era and manufacturers being used to the carriers having control
I hear you, and appreciate where you are coming from. I will say that Verizon cares a lot about its brand and about perceived quality. I believe that's why they try to maintain as much control over the "change" process as possible, because they see themselves as the ones on the hook when the quality of the experience is sub par.