When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
Serious, though: Is this actually a real problem? We have a lot of HP and Xerox color printers at the office, everything from 11x17 lasers up to 44" inkjets, and a large number of them are low of some color or another at any given time, and yet they all do their best to reproduce whatever you send them.
Unrelated:
None of the "people" depicted in this video are actually human.
^Not bad, you know what I find more insane? That the code powering the Oracle Database architecture...............more than 27 million lines of code. Tens of thousands of tests to make sure the smallest change doesn't break something.
^Not bad, you know what I find more insane? That the code powering the Oracle Database architecture...............more than 27 million lines of code. Tens of thousands of tests to make sure the smallest change doesn't break something.
It's mind boggling.
That is insane. Tens of thousands of tests aren't enough.
That is insane. Tens of thousands of tests aren't enough.
I spent about eight years as "the guy who is ultimately responsible for black-box testing this specific family of embedded code, and working with the developer to fix all of the hilariously complex flaws that I find."
And that is the absolute wrong way to develop robust code.
You develop robust code by authoring a full definition of the implementation up front, breaking that down into a group of atomic modules, describing the means by which each module interacts with another (keeping in mind such issues as race conditions and resource contention), and then developing and testing each module individually before combining them into a full-blown application.
I know that this sounds like a tie-wearing, 1950s IBMer answer, but as someone who has learned product development the very, very hard way, it is the absolute truth for any product sufficiently complex that its development involves more than two people.
You do NOT develop robust code by giving a vague description of the application to a developer, letting them run wild for six months with no supervision, and then spending the next seven years trying to brow-beat the monstrosity which they came up with into something which actually works.
This is the exact, specific thing which resulted in the failure and bankruptcy of Pacific Research & Engineering in 1999, and then AGAIN in 2013 after having been acquired by Harris and left unsupervised to make the same mistakes again.
Location: Detroit (the part with no rules or laws)
Posts: 5,677
Total Cats: 800
Originally Posted by Joe Perez
I spent about eight years as "the guy who is ultimately responsible for black-box testing this specific family of embedded code, and working with the developer to fix all of the hilariously complex flaws that I find."
We pay a monthly fee for the continuous development of some software we have here.
We literally make changes monthly. Most of the time it doesn't work right the first time and sometimes it bricks the system. It's great
I spent about eight years as "the guy who is ultimately responsible for black-box testing this specific family of embedded code, and working with the developer to fix all of the hilariously complex flaws that I find."
And that is the absolute wrong way to develop robust code.
You develop robust code by authoring a full definition of the implementation up front, breaking that down into a group of atomic modules, describing the means by which each module interacts with another (keeping in mind such issues as race conditions and resource contention), and then developing and testing each module individually before combining them into a full-blown application.
I know that this sounds like a tie-wearing, 1950s IBMer answer, but as someone who has learned product development the very, very hard way, it is the absolute truth for any product sufficiently complex that its development involves more than two people.
You do NOT develop robust code by giving a vague description of the application to a developer, letting them run wild for six months with no supervision, and then spending the next seven years trying to brow-beat the monstrosity which they came up with into something which actually works.
This is the exact, specific thing which resulted in the failure and bankruptcy of Pacific Research & Engineering in 1999, and then AGAIN in 2013 after having been acquired by Harris and left unsupervised to make the same mistakes again.
Ideally yes. But when you are talking about a company this old, and this size, that literally does BILLIONS of dollars in sales per month........things don't always work how you want or think they should.
It's really impressive to think about just how many people are involved in all this stuff. Just the Commerce portion of NetSuite (who I work for acquired by Oracle Jan 1, 2017 for nearly $10 billion) has something like 20 full-time software developers. That doesn't include all the other areas. I think in total we have something like 6,000 employees, more than 40,000+ customers (which we have to make sure all changes don't break any of their stuff).
^Not bad, you know what I find more insane? That the code powering the Oracle Database architecture...............more than 27 million lines of code. Tens of thousands of tests to make sure the smallest change doesn't break something.
It's mind boggling.
trying working on jquery applications, and someone changes one thing.
Back about 20 years ago, I was into the demoscene. This has it's roots in people who hacked copy protection on games and put an intro demo to play before the game started. Since this was in the time of floppy disks and space was limited, these intros started out as 4kb files. Later on they grew into 8kb, 64kb, and beyond. There were also platform specific versions for Sega, Atari, Commodore, etc. Eventually this evolved into competitions that would be held live. This one was done at a competition in 2000, and the final version is 63.5kb
Ive always thought the demoscene was pretty cool. Unfortunately, it doesnt seem like its very popular anymore, or at least its been a while since Ive seen anything new come out of it.
Ive always thought the demoscene was pretty cool. Unfortunately, it doesnt seem like its very popular anymore, or at least its been a while since Ive seen anything new come out of it.
I was a big fan back in the C-64 and Amiga era, mostly because the groups were doing amazing audiovisual things which seemed to defy the capabilities of the hardware (and disk space.)
These days, the average low-end personal computer is easily capable of editing cinema-quality video, doing ray-tracing in real time, etc. There's so much computational horsepower available for cheap that demos just aren't impressive (by comparison) anymore.
What I do find interesting, however, is that there's a whole scene of folks developing new, original titles for ancient platforms like the Atari 2600. Some are distributed only as .bin files, but a few folks actually produce physical ROM cartridges and sell them in OEM-style boxes, with OEM-style manuals, etc.
This one, for instance, is a modern impression of what a movie tie-in game for Ready Player One would have been:
That stuff is pretty wild. Have you ever seen super mario brothers on 2600? Its gotta be one of the best looking 2600 game Ive ever seen. No idea how they managed to do so much with he hardware.
09-11-2019, 09:48 PM
2
