Yeah I built one of these for .NET specifically for this, with DB-specific drivers to extend the API, especially for Postgres. It just tries to be a dead simple representation of the query, then provides a command API to do mapping and execution, some unit of work support. Really happy with it so far, especially compared to an ORM.
Every cool new revolutionary, game changing, disruptive tech I can think of has had some kind of “killer app” that lead the way to widespread pubic awareness. Peer to peer had Napster, AJAX had Google Maps, microservices had services of large scale tech giants, and even blockchain originally had Bitcoin. In each case people were doing some cool new thing and we approached the technology trying to figure out how it was accomplished. I am not aware of a single such example for Web3 nor has anyone I’ve asked been able to name one. The killer Web3 apps are at best hypothetical imaginings of what someone could build with it someday, and even that take is quite generous. It is a technical buzzword in search of funding which is not a proven solution for anything at all.
Haha, maybe not? Since their car would tend to go underneath, although the footage I've seen always shows the other vehicle hitting from the side with the hood sliding slightly beneath the Mercedes...it does seem from watching that would give other vehicle slightly more space to dissipate the impact energy.
Now if they had only bought a Mercedes as well, they could have chosen the self-breaking option to avoid the collision in the first place.
Mercedes has a system on the S-class that uses the sensors to detect a potential impact (e.g. an rapidly approaching vehicle while the car is stationary) and uses the active suspension to "jump" raising the car a few inches just at the moment of impact, apparently slightly reducing the potential for injury.
Many cars and especially planes & spaceships are have tons of systems like this.
I worked on a system that did things like in response to a primary datasource being offline would switch the queries it used to a different database to include substitute data and pass this back to be used instead until the primary store came back online. Three years after it was put in production this happened on one of the company's biggest and most important days of the year, and our SREs were sitting there calmly trying to solve the issue, ended up waiting until late at night to deploy a fix. It would have been reasonable for this service to just rely on the primary source, but we would have been offline for hours if this little trick hadn't been put in place.
Not a specific piece of software, but a characteristic of a limited percentage of anonymous internal systems--one of the most beautiful things to witness in the realm of design is a system undergoing catastrophic stress when the designers anticipated and planned for such events, and in usually a very short period of time you see the results of extensive planning spool out, design features hidden from view and unappreciated until this moment, kick in and recover/compensate in ways that feel almost magical.
For obvious reasons it is much more common to see this level of design in physical, life-critical systems like aerospace or automotive technology, but you do see it sometimes in software. Well designed services that under heavy load, various kinds of infrastructure failure, attack, or other kinds of scenarios well outside the bounds of normal expected operations intelligently compensate while signaling alerts with precise, useful information, and attempt whatever kind of recovery is possible.
This is hard to anticipate and often thankless to build in advance. It's always a stressful time when this behavior is visible, but it gives me a feeling of admiration for the perhaps long gone employees who built it.
> Uber charges drivers 25-30 percent without coming close to covering their actual costs
I mean this is it, right? This is the big one. All these "tech" companies that are not actually selling software taking huge cuts off the top line, this can't be sustainable.
You can own the market for a while, but sooner or later someone is going to come along and disrupt you.
Yeah, no. Companies that care about costs absolutely track what they’re spending and where. I’ve seen plenty of merely questionable expenses a fraction of this caught and called out at very large companies.
Hell no. Also if this is your expectation you’re absolutely insane if this isn’t automated…also this kind of sounds like QA to me. My presumption is the base functionality requirements are met, I’m looking for potential performance issues, code standards, sound architecture, etc.
I am always amazed at how many repetitive tasks folks want to load up developers with. I think there’s a tendency among developers-turned-managers to see their job as crafting the perfect “program” of processes for their developers to follow, instead just automating these tasks. Like they say, the cobbler’s children have no shoes.
I am afraid that the last few minutes of life will be like a confusing and disoriented nightmare. That has always seemed to me to be the most likely scenario as your brain is shutting down.
Right, nobody who has a bad experience with agile is doing it right. I am very familiar with this line of argument.
Fact remains though that back when everything was waterfall (proudly) and we shipped physical media to clients, when a bug often meant flying a support engineer out to the customer’s office, software was generally delivered more completed and vetted, and the QA group wasn’t allowed to report to the same org as developers because it was considered a conflict of interest. Now some software companies don’t even have a QA organization, we are inventing new organizational and technical structures to ensure that the developers are perpetually on call to resolve issues, and there is definitely a school of thought that says delivery of a complete product is an anti-pattern because after all every feature is just an experiment that you are testing on your users. But whatever, two different times, two different needs, two different practices, and to my point now we seem to be entering a new post-COVID era where just as waterfall doesn’t scale to a continuous delivery paradigm, “you build it, you run it” as practiced today is going to struggle with an “always on” business which has no “after hours” due to more flexible working schedules.
Are there companies today that run true 24/7? Sure, plenty, but they tend to be larger and have the staff to cover this. A great deal of business software today is still very fragile operationally and has deployment, management, and maintenance tied to the 9-5, M-F business schedule. I think it is going to have to evolve.
It seems that with these types of changes, I mean with more and more of the workforce working on schedules that don’t overlap, it is going to become more and more important for business software to run autonomously without anyone there to babysit it, but it seems to me we have been moving in precisely the opposite direction for some time now.
Specifically “doing agile” seems to encourage this, I always see lots of supporting infrastructure being skimped on so a new feature can be delivered faster, with some hand wavy plans to fix it in some future sprint.
I recently received a copy of a letter with some information about my ancestors from the 1700s. Apparently they owned an inn in a small village in France (it is still there and looks like a relatively nice place to me, so…I guess they were doing ok?). They had 10 children, of whom 6 died before the age of 3. The mother died at age 39, in the last 8 months of her life 3 of her children died.
I think many of us, myself included, have been conditioned to be paranoid—just because I can’t think of/don’t know of any way some data could be abused doesn’t mean I’m going to make it public.
Most revolutionary/generational tech has started with an implementation or at least a proof of concept of something new and novel that subsequently drove interest in how it worked. Like Google Maps use of AJAX for infinite scrolling or Napster and peer to peer networks, or even Bitcoin and blockchain. I’m not aware of any such example for Web3.
So…in case you plan to not pay for it but still keep it anyway?
I am really struggling to understand the mindset here of what I assume are mostly well paid professional software developers. If I defaulted on a car loan (I don’t know the details exactly off the top of my head, but this entails more than just missing a payment) I’d be quite ashamed of myself and return the car myself with an apology. I cannot understand the mindset of someone who would feel justified keeping the car, much less getting angry at the method used by the bank to reclaim their property.
It’s not like this is a cheap car either where you’re threatening someone’s livelihood who is not going to be able to get to work.
Usually takes about two hours every two weeks, but I figure we’d have lost that time in offline code reviews anyway. I’ve had people point out that I have a small team. They have a point, I’m not sure how this would scale to a large team—but maybe if a team is too large to review their code together they could be split into smaller groups.
Also, I think these help replace what might have been other meetings as well. Sometimes product people like to sit in and listen so they know exactly what's being released--I don't think they'd ever participate or get much value from a normal code review.
Yes, actually there are two small additional repos, but we only very occasionally change and review. I think it would be a bit more difficult with many repos. Perhaps you could make it work, but it’s quite convenient to pull up everything in a single diff in an IDE. On the other hand, I usually treat a repository as a “deployable unit“ more or less, so I guess releases would be scoped to a repository as well.
Also, I’ve done this with smaller teams, 5-6 people. If you had three or four times as many that might make for a long meeting.
I have been doing this for years. I have my team push changes directly to master (they have the option to use a feature branch and code review if they feel it is necessary of course). Once per release cycle, we have meet, I put the diff off all changes since the last release and we review every change going out as a group, we talk about what is being changed, why, and people can explain their changes. Sometimes something needs to be fixed, and we can fix it right there.
- The quality of these reviews is better than any code review I’ve seen on feature branch reviews
- We review the whole collection of changes going out, on rare occasions when two changes conflict, you catch these
- Everyone keeps up to date with what is changing in the code base and why
- If for whatever reason there’s an issue after the deployment, it’s easier to fix because everyone has fresh in their head what has changed in this release