jbarber
I guess whether AI written code means you can't build a theory of a program is an open question - but I don't see why you can't have AI written code that keeps the system knowable and extendable, in the same way that any long lived program or system can be. It's _just_ a question of being disciplined in the same way you'd need to be with developing and maintaining any long lived artefact.
It's also hard to convey to the testing system what is an acceptable level of change in the UI - what the testing system thinks is ok, you might consider broken.
There are quite a few companies out there trying to solve this problem, including my previous employer https://rainforestqa.com
Rainforest QA is an on-demand QA solution. It’s our mission to enable development teams to deliver bug-free software while moving at the speed of continuous delivery. We are truly a global team, allowing us to bring together the best and most diverse talent. Our commitment to the distributed team model and to our company values has earned us multiple culture and workplace awards (https://www.rainforestqa.com/about) and helped us build a diverse team of individuals working toward the same goal: change the way QA is done.
Here are our open roles:
- Senior Backend Engineer: https://jobs.lever.co/rainforest/fc829b24-1c98-4ccf-af03-e54...
- Senior Frontend Engineer: https://jobs.lever.co/rainforest/6bf86ef0-1fdc-41f9-8ea5-fe4...
Tech Stack: Ruby-on-Rails, Javascript (React), Python, Golang, Elixir, PostgreSQL, k8s, GCP/AWS
View all open roles at https://www.rainforestapp.com/jobs
Rainforest QA is an on-demand QA solution. It’s our mission to enable development teams to deliver bug-free software while moving at the speed of continuous delivery. We are truly a global team, allowing us to bring together the best and most diverse talent. Our commitment to the distributed team model and to our company values has earned us multiple culture and workplace awards (https://www.rainforestqa.com/about) and helped us build a diverse team of individuals working toward the same goal: change the way QA is done.
Here are our open roles:
- Senior Backend Engineer: https://jobs.lever.co/rainforest/fc829b24-1c98-4ccf-af03-e54...
- Senior Frontend Engineer: https://jobs.lever.co/rainforest/6bf86ef0-1fdc-41f9-8ea5-fe4...
Tech Stack: Ruby-on-Rails, Golang, Elixir, PostgreSQL, React, k8s, GCP/AWS
On older systems, the leading '-' can be replaced by '+' in the obsolete option syntax with the same meaning as in counts, and obsolete usage overrides normal usage when the two conflict. This obsolete behavior can be enabled or disabled with the '_POSIX2_VERSION' environment variable (*note Standards conformance::).because it requires less typing. The ISO 8601 standard format.
-Is, -Im, -Ih, and -Id allow you to change the displayed resolution.
Bizarrely, this doesn't seem to be documented in my version of date (coreutils 8.10).
I haven't had any problems with the mezzanine cards, but I do have problems with the VirtualConnect Flex-10 - applying configuration changes seemed to take an increasingly long time the more devices in the configuration. The other big annoyance with the VC is that the blade needs to be off to add more virtual NICs - so now I normally just add them all when I provision the blade and leave them disconnected.
The c7000's also seem quite picky about the versions of firmware installed on the various components.
I believe you can chain several c7000's together for management to reduce the pain a little. And you can always invest in HP's management software.
A plus for the c7000's is the flexibility of the blades: you can get HPUX versions (if you're unlucky enough to need HPUX), half and double height versions. Using the different sized blades does require some planning, as they impose some constraints - but even with this it does introduce some flexibility.
I used Dell's bladecenters a few years ago and they were okay, I know IBM/Fujitsu/ have them as well, so I wouldn't say there is no competition in the market.
I played with a UCS system (just one chassis) in our lab (~6-12 months ago), and I can't say I was hugely impressed. The documentation wasn't what I expect given my experience with Cisco's switch gear, and we had to update the firmware a couple of times to get past bugs. Maybe this is no longer the case. I didn't play with the API.
It's my understanding that if you want to do multihop FCoE then you have to stick with the same vendor for your switches, due to the different ways they implement FCoE.
IMHO I think the UCS cost is a big turnoff, maybe if you're in a huge environment (100's of chassis) the API is enough of a win to overcome the high cost - or maybe you can get a big enough discount.
WRT to Cisco staying in the market, I think they will for two reasons. The first is it increases their ability to sell more switch gear - you want FCoE or better link utilisation then, you need data center ethernet, which means you need new switches - and Cisco can now sell you both. Secondly it allows them to push FCoE and disrupt the FC market, which means they can sell more switches again.