Comments by "" (@grokitall) on "ThePrimeTime" channel.

  1. because rust is basically c with constraints, so it can be done incrementally. most valid alternatives are not, so you would have to translate everything at once.
    1
  2. No, by definition you are wrong. In tdd the developer writes a failing test, writes just enough code to pass the test, and then uses the combination of the passing test and refactoring to incrementally decrease the amount of technical debt. This is then fed into your continuous integration system, which proves that the code does what the developer expected. What you are talking about are acceptance tests which plug into your continuous delivery system to prove that what your developer expected was what the customer needed, which can either be done by the developer, or by the system designer. Of course one of the advantages of tdd is that it does incremental development of the system giving you something to present to the customer regularly which enables exploratory testing of the developing system to identify such mismatches against working code.
    1
  3. it is not business ethics which require the shift your company policy, but the resiliency lessons learned after 9/11 which dictate it. many businesses with what were thought to be good enough plans had them fail dramatically when faced with the loss of the data centers duplicated between the twin towers, the loss of the main telephone exchange covering a large part of the city, and being locked out of their buildings until the area was safe while their backup diesel generators had their air intake filters clog and thus the generator fail due to the dust. the recovery times for these businesses for those it did not kill were often on the order of weeks to get access to their equipment, and months to get back to the levels they were at previously, directly leading to the rise of chaos engineering to identify and test systems for single points of failure and graceful degradation and recovery, as seen with the simian army of tools at netflix. load balancing against multiple suppliers across multiple areas is just a mitigation strategy against single points of failure, and in this case the bad actors at cloudflare were clearly a single point of failure. with a good domain name registrar, you can not only add new nameservers, which i would have done as part of looking for new providers, but you can shorten the time that other people looking up your domain cache the name server entries to under an hour, which i would have also done as soon as potential new hosting was being explored and trialed. as long as your domain registrar is trustworthy, and you practice resiliency, the mitigation could have been really fast. changing the name server ordering could have been done as soon as they received the 24 hour ransom demand, giving time for the caches to move and making the move invisible for most people. not only did they not do that, or have any obvious resiliency policy, but they also built critical infrastructure around products from external suppliers without any plan for what to do if there was a problem. clearly cloudflare's behaviour was dodgy, but the casino shares some of the blame for being an online business with insufficient plans for how to stay online.
    1
  4. ​ @MrSnivvel yes there will be rework, but you are talking the difference between preventative maintainence and emergency rework. the first is always cheaper a d performed better. its like the arguments about test first development, where you trade regression tests against bug hunting after the fact. same applies in many other fields of endeavor. there are often tradeoffs, which you then need to make a deliberate proactive choice about, rather than waiting until you are about to go over the cliff and only then thinking about what happens next.
    1
  5.  @MrSnivvel  what you are talking about is called resiliency planning, which a lot of people regard as making sure nothing can go wrong. unfortunately for them, it actually means planning for everything that can go wrong and putting preferably automated plans in place for gradual degradation and rapid recovery when it does. the way this is achieved is using something called chaos engineering, the most well known example of which is the simian army of tools at netflix. it has been rendered much more important due to the realisation of just how expensive not having it was in the aftermath of 9/11.
    1
  6.  @MrSnivvel  it did not seem to me like it was taking the import of the issue seriously enough. nothing you said was exactly wrong, but to me it came across more as "yeah its a good idea, but whenever is fine" and to me it is more like making sure that you have enough insurance on you billion dollar factory, or having a will when you have major assets. the but whenever approach is far to prevalent and tends to push my buttons.
    1
  7. ​ @373323 there are a number of companies who were running n-1 or n-2 versions of the driver, which crowdstrike support, but the issue here is that it was company policy as stated by the ceo to immediately push the signature files out to everyone in one go, without further testing. the information from crowdstrike is that the engineer in question picked up an untested template, modified it for the case in hand, ran a validator program against it which had not been updated to cover that template (and thus should have failed it), and once that passed, picked up the files, and shipped them out to everyone with no further testing, as per company policy. it then took them 90 minutes to spot that there was a problem, and do a 2 minute fix to roll back the update to stop the rollout and fix any machines with the bad update that had not yet rebooted. it took them 6 hours from the rollout to have a solution to the problem of how to fix the rebooted machines, but it only really worked on basic desktops which did not need security. at least one company reported spending 15 hours manually rebooting and fixing 40,000 machines. some were worse.
    1
  8. As it should be. Every book I have ever read on optimisations for compilers has made the point that compiler optimisations should change the speed and or memory usage, but not the behaviour of the program. This is explicitly stated when it comes to refactoring, where you optimise for readability and making the code more maintainable, but applies equally to every other form of optimisation as well.
    1
  9. If the change had occurred between major versions of the compiler, I would have agreed with you, but the user basically did the nightly update from the package repository to do bugfixes, and suddenly working programs broke. That is a bug. When a major version change occurs, you expect things like -Wall to throw lots more warnings, which is why people make a deliberate choice as to when in their workflow to make that move. If you are for example 3 days before the release of a 1 million lines of code piece of software you do not expect some clever programmer to do something dumb and break it silently when you are getting ready for release, potentially causing weeks worth of extra work. This is what the user was unclearly complaining about, and the compiler writer was ignoring the point that changes which break running code should not become the default as a surprise.
    1
  10. we now know what should have happened, and what actually happened, and they acted like amateurs. first, they generated the file, which went wrong. then they did the right thing, and ran a home built validator against it, but not as part of ci. then after passing the validation test they built the deliverable. then they shipped it out to 8.5 million mission critical systems with no further testing whatsoever which is a level of stupid which has to be seen to be believed. this then triggered some really poor code in the driver, crashing windows, and their setting it into boot critical mode caused the whole thing to go into the boot loop. this all could have been stopped before it even left the building. after validating the file, you should then continue on with the other testing just like if you had changed the file. this would have caught it. having done some tests, and created the deployment script, you could have installed it on test machines. this also would have caught it. finally, you start a canary release process, starting with putting it on the machines in your own company. this also would have caught it. if any of these steps had been done it would never have got out the door, and they would have learned a few things. 1, their driver was rubbish and boot looped if certain things went wrong. this could then have been fixed so it will never boot loop again. 2, their validator was broken. this could then have been fixed. 3, whatever created the file was broken. this could also have been fixed. instead they learned different lessons. 1, they are a bunch of unprofessional amateurs. 2, their release methodology stinks. 3, shipping without testing is really bad, and causes huge reputational damage. 4, that damage makes the share price drop of a cliff. 5, it harms a lot of your customers, some with very big legal departments and a will to sue. some lawsuits are already announced as pending. 6, lawsuits hurt profits. we just don't know how bad yet. 7, hurting profits makes the share price drop even further. not a good day to be cloudstrike. some of those lawsuits could also target microsoft for letting the boot loop disaster happen, as this has happened before, and they still have not fixed it.
    1
  11. If the code you have been inflicted with has no tests, read "working effectively with legacy code by Michael feathers", as it is the definitive work on how to deal with the problem.
    1
  12. ​ @notsojharedtroll23 arpa proposed the arpa net for two reasons. 1, incompatible machine conventions meant that having to pass data between incompatible systems was a real pain. 2, literally everything else on the books was taken away from them and shoved into nasa, leaving them scrambling around trying to prevent congress from declaring them irrelevant and killing their funding. with this, and a few other similarly big projects, they managed to stay afloat long enough to get back on track.
    1
  13.  @ChrisWijtmans  i think it should not be legal, but know of multiple cases where having become your authorised agent they charge very large fees to hand control back to you. with limited company formations, it is by delaying your ability to file your tax returns and company accounts, with domain management it is done by blocking you from updating the dns info. in both cases it is trying to use the nuisance value to extract wildly overinflated fees. most people either pay, or aband9n it and get a new one from a reputable company.
    1
  14. we have known not to put backups too close since the backups for the data centres in building 1 of the twin towers were in building 2, and both got taken out on 9-11.
    1
  15. That is just wrong. C was created for writing low level of code in a higher level language. It just happened to be used for teaching because of how well written the k&r c language book was compared to other languages of the time, and the prevalence of Unix and thus c in universities. It was also designed to be easy to write a compiler for. Pascal was the language written for teaching, and the difficulty of writing good compilers for it is a direct result of this being the only design consideration. The problem with Trying to write good c++ compilers is a different one, due to the huge size of the language definition.
    1
  16. the use of the term curated data refers to the fact that if the data is not tagged, lots of learning algorithms won't work at all. this is what is meant by supervised learning. the problem with getting a black box statistical ai to generate those tags is that the basics of the tech is about stacking plausible guesses on plausible guesses, eliminating almost all of the feedback loops needed to generate correct answers. this is the compounded with the overfiting problem. every statistical ai works by getting more and more data, shovelling it into a system that tries to best fit a statistical model with every higher numbers of free parameters, which takes ever longer to train. this is where the model generally fails. there is a limit to how many times you can double the size of the dataset used to train the model. there is a limit to how many extra free variables you can add to the model. there are limits to how fast the model stabilises as the number of variables goes up. this results in the compute requirements to do the training having an exponential growth term in the costs, to produce answers that are only a little better and only produce likely answers, not correct ones. then there is the general problem with all intelligence, that you can only solve new problems you can almost solve already.
    1
  17. the main problem here is that prime and his followers are responding to the wrong video. this video is aimed at people who already understand 10+ textbooks worth of stuff with lots of agreed upon terminology, and is aimed at explaining to them why the tdd haters don't get it, most of which comes down to the fact that the multiple fields involved build on top of each other, and the haters don't actually share the same definitions for many of the terms, or of the processes involved. in fact in a lot of cases, especially within this thread, the definitions the commentators use directly contradict the standard usage within the field. in the field of testing, testing is split into lots of different types, including unit testing, integration testing, acceptance testing, regression testing, exploratory testing, and lots of others, if you read any textbook on testing, a unit test is very small, blindingly fast, does not usually include io in any form, and does not usually include state across calls or long involved setup and teardown stages. typically a unit test will only address one line of code, and will be a single assert that when given a particular input, it will respond with the same output every time. everything else is usually an integration test. you will then have a set of unit tests that provide complete coverage for a function. this set of unit tests is then used as regression tests to determine if the latest change to the codebase has broken the function by virtue of asserting as a group that the change to the codebase has not changed the behaviour of the function. pretty much all of the available research says that the only way to scale this is to automate it. tdd uses this understanding by asserting that the regression test for the next line of code should be written before you write that line of code, and because the tests are very simple and very fast, you can run them against the file at every change and still work fast. because you keep them around, and they are fast, you can quickly determine if a change in behaviour in one place broke behaviour somewhere else, as soon as you make the change. this makes debugging trivial, as you know exactly what you just changed, and because you gave your tests meaningful names, you know exactly what that broke. continuous integration reruns the tests on every change, and runs both unit tests and integration tests to show that the code continues to do what it did before, nothing more. this is designed to run fast, and fail faster. when all the tests pass, the build is described as being green. when you add the new test, but not the code, you now have a failing test, and the entire build fails, showing that the system as a whole is not ready to release, nothing more. the build is then described as being red. this is where the red-green terminology comes from, and it is used to show that the green build is ready to check in to version control, which is an integral part of continuous integration. this combination of unit and integration tests is used to show that the system does what the programmer believes the code should do. if this is all you do, you still accumulate technical debt, so tdd adds the refactoring step to manage and reduce technical debt. refactoring is defined as changing the code in such a way that the functional requirements do not change, and this is tested by rerunning the regression tests to demonstrate that indeed the changes to the code have improved the structure without changing the functional behaviour of the code. this can be deleting dead code, merging duplicate code so you only need to maintain it in one place, or one of hundreds of different behaviour preserving changes in the code which improves it. during the refactoring step, no functional changes to the code are allowed. adding a test for a bug, or to make the code do something more happens at the stsrt of the next cycle. continuous delivery then builds on top of this by adding acceptance tests which confirm that the code does what the customer thinks it should be doing. continuous deployment builds on top of continuous delivery to make it so that the whole system can be deployed with a single push of a button, and this is what is used by netflix for software, hp for printer development, tesla and spacex for their assembly lines, and lots of other companies for lots of things. the people in this thread have conflated unit tests, integration tests and acceptance tests all under the heading of unit tests, which is not how the wider testing community uses the term. they have also advocated for the deletion of all regression tests based on unit tests. a lot of the talk about needing to know about the requirements in advance is based upon this idea that a unit test is a massive, slow, complex thing with large setup and teardown, but it is not how it is used in tdd. there you are only required to understand how to write the next line of code well enough that you can write a unit test for that line what will act as a regression test. this appears to be where a lot of the confusion seems to be coming from. in short, in tdd you have three steps: 1, understand the needs of the next line of code well enough that you can write a regression test for it, write the test, and confirm that it fails. 2, write enough of that line that it makes the test pass. 3, use functionally preserving refactorings to improve the organisation of the codebase. then go around the loop again. if during stages 2 and 3 you think of any other changes to make to the code, add them to a todo list, and then you can pick one to do on the next cycle. this expanding todo list is what causes the tests to drive the design. you do something extra for flakey tests, but that is ouside the scope off tdd, and is part of continuous integration. it should be pointed out that both android and chromeos both use the ideas of continuous integration with extremely high levels of unit testing. tdd fits naturally in this process, which is why so many companies using ci also use tdd, and why so many users of tdd do not want to go back to the old methods.
    1
  18. Tdd came about as a consequence of doing deliberate test first automated regression testing, and adding refactoring to the cycle. Comprehensive automated regression testing then forms part of the foundations of continuous integration. It works very well for exploratory design when you understand what you need the API to do, but are less sure about how the internals need to work, but does encourage early stabilisation of the public API of the code. If it is not public, it will either be exercised by your public API tests, or will be dead code to be deleted. In either case the implementation is not constrained by the API. Of course you are still free to break your public API right up to the point when you publish it for other code to use, at which point you are explicitly saying that the API documented in your header files won't break, supported by tests to make sure. If you break your API after this point, your users will rightly shout at you for it. Note: you do not have to add all of your functions and variables to your header files, making them public.
    1
  19. learn the way us older guys did, but easier. find open source project in the area you are interested in and learn how the code evolved using the gui to the version control system. especially concentrate on any commits that include bug fix in the comment, as the diff will show you what was wrong in the first version and how it was fixed in the second, then try and figure out why the first version was wrong and why the second version was better.
    1
  20. Code coverage is a measure of how happy you are to push crap to your users. The lower the percentage, the less you care about quality. Anyone writing a test just to up the numbers will write a bad and fragile test, which they will then be required to debug and fix when it breaks. Good testing only exercises the public API and tests it for stability. Everything else is either already covered by the API tests, is a sign of a missing test, or is dead code. As to coverage vs code review, code review doesn't scale, especially in agile workflows, like continuous integration and trunk based development. At that point you need automated regression testing, which you can combine with a ratchet test to take advantage of improvements while not allowing regressions in your coverage numbers. Remember you always start out with two guaranteed tests. 1, does it build without failing the build. 2, does it run the successfully built code without crashing. Anything better than that is an advantage you can build on top of.
    1
  21.  @jfftck  not quite right, great tests are self documenting executable specifications for the public api of the internal libraries of the code. while pair programming is demonstrably the best approach, it is not an option in a lot of use cases. in those cases, continuous integration is the only way to take up the slack. as regards the problem of bosses being idiots about pushing for ever more features, the dora metrics prove that features and tests when done well are a virtuous circle which increases both feature speed and test coverage. poor quality tests are trivially easy to spot, as it is non trivial to fix them when they break. the way to deal,with them is to force the guy who wrote them to fix them before they can write any new code. as the original code was usually written by the same guy, it then makes the guy feel the pain that they caused everyone else by writing such crappy code and tests. if they still don't want to fix their bad habits then they can be added to a group forced to fix all the broken tests with no current owners. of course to make it work you need to get buy in from the bosses, but you need that anyway to do testing properly.
    1
  22. ​ @k98killer not quite. Continuous integration attempts to find the foot guns before main testing using lots of fast automated unit and integration regression tests. This allows you to get something suitable for detailed long termed testing while at the same time attempting to spot any breakages with the regression tests before you even make the commit, and which results in tested code with no obvious regressions which does what the programmer understood it needed to do. The output of continuous integration is then used by the deployment pipeline to further prove that the code is not fit for purpose by running longer lasting tests which try and discover regression in performance, memory usage, etc. These additional foot guns are not always discovered at this point, but the end result is something which has already been deployed to testing, and which looks as fit as possible for deployment to production. Continuous deployment goes further and rolls out this new release to the load balanced server with the oldest codebase deployed, and gradually takes over the load from the next oldest, either succeeding, or discovering additional foot guns which don't show up until under heavy load, in which cae it is rolled back.
    1
  23. Every branch is essentially forking the entire codebase for the project, with all of the negative connotations implied by that statement. In distributed version control systems, this fork is moved from being implicit in centralized version control to being explicit. When two forks exist (for simplicity call them upstream and branch), there are only two ways to avoid having them become permanently incompatible. Either you slow everything down and make it so that nothing moves from the branch to upstream until it is perfect, which results in long lived branches with big patches, or you speed things up by merging every change as soon as it does something useful, which leads to continuous integration. When doing the fast approach, you need a way to show that you have not broken anything with your new small patch. The way this is done is with small fast unit test which act as regression tests against the new code, and you write them before you commit the code for the new patch and commit them at the same time, which is why people using continuous integration end up with a codebase which has extremely high levels of code coverage. What happens next is you run all the tests, and when they pass, it tells you it is safe to commit the change, this can then be rebased, and pushed upstream, which then runs all the new tests against any new changes, and you end up producing a testing candidate which could be deployed, and it becomes the new master. When you want to make the next change, as you have already rebased before pushing upstream, you can trivially rebased again before you start, and make new changes. This makes the cycle very fast, and ensures that everyone stays in sync, and works even at the scale of the Linux kernel, which has new changes upstreamed every 30 seconds. In contrast, the slow version works not by having small changes guarded by tests, but by having nothing moved to upstream until it is both complete and as perfect as can be detected. As it is not guarded by tests, it is not designed with testing in mind, which makes any testing slow and fragile, further discouraging testing, and is why followers of the slow method dislike testing. It also leads to merge hell, as features without tests get delivered with a big code dump all in one go, which may then cause problems for those on other branches which have incompatible changes. You then have to spend a lot of time finding which part of this large patch with no tests broke your branch. This is avoided with the fast approach as all of the changes are small. Even worse, all of the code in all of the long lived braches is invisible to anyone taking upstream and trying to do refactoring to reduce technical debt, adding another source of breaking your branch with the next rebase. Pull requests with peer review add yet another source of delay, as you cannot submit your change upstream until someone else approves your changes, which can take tens to hundreds of minutes depending on the size of your patch. The fast approach replaces manual peer review with comprehensive automated regression testing which is both faster, and more reliable. In return they get to spend a lot less time bug hunting. The unit tests and integration tests in continuous integration get you to a point where you have a release candidate which does all of the functions the programmer understood was wanted. This does not require all of the features to be enabled by default, only that the code is in the main codebase, and this is usually done by replacing the idea of the long lived feature branch with short lived (in the sense of between code merges) branches with code shipped but hidden behind feature flags, which also allows the people on other branches to reuse the code from your branch rather than having to duplicate it in their own branch. Continuous delivery goes one step further, and takes the release candidate output from continuous integration and does all of the non functional tests to demonstrate a lack of regressions for performance, memory usage, etc and then adds on top of this a set of acceptance tests that confirm that what the programmer understood matches what the user wanted. The output from this is a deployable set of code which has already been packaged and deployed to testing, and can thus be deployed to production. Continuous deployment goes one step further and automatically deploys it to your oldest load sharing server, and uses the ideas of chaos engineering and canary deployments to gradually increase the load taken by this server while reducing the load to the next oldest server until either it has moved all of the load from the oldest to the newest, or a new unspotted problem is observed, and the rollout is reversed. Basically though all of this starts with replacing the slow long lived feature branches with short lived branches which causes the continuous integration build to almost always have lots of regression tests always passing, which by definition cannot be done against code hidden away on a long lived feature branch which does not get committed until the entire feature is finished.
    1
  24. yes we would. this killed locked down machines, and with some specific systemd exceptions almost nobody uses, it requires administrator access to get them to reboot. this is why it took so long to get them back up. only high level technical support have the access to these systems to reboot them.
    1
  25. it clearly stated that the first email was saying there was a problem affecting the network, and when they turned up it was a meeting with a completely d8fferent department, sales, and that there was no problem. also no mention as to the enterprise offering being mandatory. at that point i would return to my company and start putting resiliency measures in place with the intent to min8mise exposure to cloudflare with the intent to migrate, but the option to stay if they were not complete dicks. the second contact was about was about potential issues with multiple national domains, with a clear response that it is due to differing national regulations requiring that. the only other issue mentioned was a potential tos violation which they refused to name, and an immedia5e attempt to force a contract with a 120k price tag with only 24 hours notice and a threat to kill your websites if you did not comply. at this point i would then have immediately triggered the move. on the legal view, they are obviously trying to force a contract, which others have said is illegal in the us where cloudflare has its hardware based. it is thus subject to those laws. by only giving 24 hours from the time that they were informed it was mandatory, they are clearly guilty of trying to force the contract, and thus likely to win. if they can win on that, then their threat to pull the plug on their business on short notice in pursuit of an illegal act also probably makes them guilty of tortuous interference, for which they would definitely get actual damages, which would cover loss of business earnings, probably get reputational damages, probably get to include all the costs for having to migrate to new providers, and legal costs. when i sued them, i would also go after not only cloudflare, but the entire board individually, seeking to make them jointly and severally liable, so that when they tried to delay payment, you could go after them personally. the lesson is clear, for resiliency, always have a second supplier in the wings which you can move to on short notice, and have that move be a simple yes or no decision that can be acted upon immediately. by virtue of this, don't get overly relient on external tools to allow the business to continue to be able to work to mitigate the disaster if it happens. also keep onsite backups of any business critical information. m9st importantly, make sure you test the backups. at least one major business i know of did everything right including testing the backup rec9very process, but kept the only copy of the recovery key file on the desktop of one machine in one office, with the only backup of this key being inside the encrypted backups. th8s killed the business.
    1
  26.  @NicoJuicy  while that might be plausible, the point is that cloudflare did not make that arguament until after shutdown, only offering it as one of the undeeded selling points of the upgraded offering. remember the whole flow was around trying to upsell while refusing to state that there was a specific problem with their existing service, which is why the potentially illegal forced contract come up.
    1
  27.  @NicoJuicy  yes they did, but not until the final day, and not as a requirement, only as an advantage to the upgrade.
    1
  28. because they all develope using ci, as do spacex, and most of the big name software companies. when hp implimented it for their printer division, they went from spending 5% of their time on new features to 45%, while merging all of their printer branches into 1 codebase, and using feature flags to enable funcions on specific printers
    1
  29. that is just not true. the agile manifesto was a response to persistently failing projects. those there were very experienced, and identified a small set of practices which the failures had in common, and basically said if you do this instead, it often works better, but tailor the specific things to what works best for you. the problem comes when someone takes that short list of things that often work better, and turn it into 300 page books, without even thinking about if or when it works better, and why it works when it does. that is not a problem with the manifesto.
    1
  30. Some things have to just work, and degrade and recover sensibly. An example prime would know about is Netflix, which when it gets overloaded starts gradually dropping functions like the recommendation engine so that the rest can keep working, just like the lunar lander did.
    1
  31. most kernels will not be rewritten, they are just too big. moving unix from assembler to c was an anomaly, as it would need to be ported, and c was written as a research project, so rewriting in c tested the design of c and made a lot of the code portable.
    1
  32.  @Isaac-wl6wu  but to prepare the case, you are not feeding the publicly disclosed and filed court documents, especially if you are the defense. you have a whole stack of documents you do not have to disclose until you use them in defense at trial. these may contain information which would benefit your opponent, but which as defense council you have a duty to not disclose under client confidentiality rules. a case could be made that you could use such a system in an offline only mode, but only if you can be certain that it does not phone home and share the confidential data. in any event, statistical ai still only creates a plausible response, not a correct one. that needs symbolic ai, with lots of manual work to populate it.
    1
  33. waterfall can work as described under exactly one scenario, when you know exactly what you need the specs to be, like in the nasa case mentioned in the video. the problem is that this is amazingly expensive when you can do it, and evidence going all the way back to the original paper point out that for something like 60% of projects even the customer does not know what they need, so it fails miserably. also, it cannot cope well with changing requirements. this lead to the myth of change control as a way to deal with those cases. this resulted in product being built, but they were increasingly wrong, as you could not react to the changing needs. when the manifesto was created, it was realised that it was not working, and that you needed to do incremental development, and the manifesto was a writeup of why it does not work, and what to do instead to work incrementally. if you do it properly like the companies in the dora state of devops report, agile works, but too many companies don't even learn enough about agile to be able to tell if they are really doing it, resulting in some sort of mangled waterfall process.
    1
  34. There is a reason that the testing pyramid was developed. The lower level you are, the smaller and faster your tests, and the less implementation details your test relies on. As you move higher up the pyramid, the more implementation details you are trying to infer, and hoping don't break your test when the code changes. The worst examples of this are end to end tests and UI tests, both of which tend to be rigid to get them to work at all, and thus brittle when the implementation details change. Using the testing pyramid answers your question. You should only use end to end and user tests for things which you cannot test with lower level tests, and the same applies for every other level of the pyramid. As a side effect of using the pyramid, you end up with more of your code being easier to test, and more modular.
    1
  35.  @dominikvonlavante6113  i don't know of anyone seriously doing continuous integration who does not use the testing pyramid with high levels of code coverage. as to tests higher up the pyramid, the testing pyramid being better, it depends how you define better. years of testing research have told us conclusively a number of things: 1, the higher you go, the slower you get, often by orders of magnitude. 2, the higher you go, the more setup and tear down you need around the actual test to be able to do it. 3, the higher you go, the more levels of indirection between the fact that the test broke, and why it broke. for example if you are testing the middle module in a three module chain in an end to end fashion, and the test broke, was it because module 1 broke its output to module 2, that module 2 broke its transform code, or did module three break its input api? as a consequence of these points, it is better to do thousands of unit tests against the stable api of your functions with known inputs and outputs than dozens of end to end tests which don't give you anything like as detailed feedback as the answer 'the change you just made caused this function to stop returning this value when give these parameters" this is before you even consider the fragility of end to end tests and the difficulty of testing new legacy code which was not designed with testability in mind.
    1
  36. @guymontag5084 of course you have. statistical ai fundamentally works by producing something plausible, not something correct. to go for correct you need symbolic ai, which can not only give you the output, but can tell you why and how it came to have that form, and can be taught what it got wrong if you disagree with it.
    1
  37.  @noblebearaw  it used all the points in all the images to come up with a set of weighted values which together enabled a curve to be drawn with all the images in one set on one side of the curve, and all the images in the other set on the other side of the curve. that is the nature of statistical ai, it does not care about why it comes to the answer, only that the answer fits the training data. the problem with this approach is that you are creating a problem space with as many dimensions as you have free variables, and then trying to draw a curve in that phase space, but there are many curves that fit the historical data, and you only find out which is the right one when you provide additional data which varies from the training data. symbolic ai works in a completely different way. because it is a white box system, it can still use the same statistical techniques to determine the category which the image falls into, but this acts as the starting point. you then use this classification as a basis to start looking for why it is in that category, wrapping the statistical ai inside another process, which takes the images fed into it, and uses humans to spot where it got it wrong, and look for patterns of wrong answers which help identify features within that multi dimensional problem space which are likely to match one side of the line or the other. this builds up a knowledge graph analogous to the structure of the statistical ai, but as each feature is recognised, named, and added to the model, it adds new data points to the model, with the difference being that you can drill down from the result to query which features are important, and why. this also provides extra chances for extra feedback loops not found in statistical ai. if we look at compiled computer programs as an example, using c and makefiles to keep it simple, you would start of by feeding the statistical ai with the code and makefile, and feed it the result of the ci / cd pipeline, determining if the change just made was releasable or not. eventually, it might get good at predicting the answer, but you would not know why. the code contains additional data implicit within it which provides more useful answers. each step in the process gives usable additional data which can be queried later. was it a change in the makefile which stopped it building Correctly? did it build ok, but segfault when it was run? how good is the code coverage of the tests on the code which was changed? does some test fail, and is it well enough named that it tells you why it failed? and so on. also a lot of these failures will give you line numbers and positions within specific files as part of the error message. if you are using version control, you also know what the code was before and after the change, and if the error report is not good enough, you can feed the difference into a tool to improve the tests so that it can identify not only where the error is, but how to spot it next time. basically, you are using a human to encode information from the tools into an explicit knowledge graph which ends up detecting that the code got it wrong because the change in line 75 of query.c returns the wrong answer to a specific function when passed specific data because a branch which should have been taken to return the right answer was not taken because the test on that line had 1 less = sign than was needed ad position 12, making it an assignment statement rather than a test, making the test never pass. it could then also suggest replacing the = with == in the new code, thus fixing the problem. none of that information could be got from the statistical ai, as any features in the code used to find the problem are implicit in the internal model, but it contains none of the feedback loops needed to do more than identify that there is a problem. going back to the tank example, the symbolic ai would not only be able to identify that there was a camouflaged tank, but point out where it was hiding, using the fact that trees don't have straight edges, and then push the identified parts of the tank through a classification system to try and recognise the make and model of the tank, this providing you with the capabilities and limitations of the identified vehicle as well as the presence and location. often when it gets stuck, it resorts to the fallback option of presenting the data to the human and saying "what do you know in this case which i don't", adding that information explicitly into the know,edge graph, and trying again to see if it altered the result.
    1
  38. There is some confusion about branches. Every branch is essentially a fork of the entire codebase from upstream. In centralized version control, upstream is the main branch, and everyone working on different features has their own branch which eventually merges back into the main branch. In decentralized version control who is the main branch is a matter of convention, not a feature of the tool, but the process works the same. When you clone upstream, you still get a copy of the entire codebase, but you do not have to bother creating a name for your branch, so people work in the local copy of master. They then write their next small commit, add tests, run them, rebase, and assuming the tests pass push to an online copy of their local repository and generate a pull request. If the merge succeeds, when they next rebase the local copy will match upstream which will have all of their completed work in it. At this point, you have no unsynchronized code in your branch, and you can delete the named branch, or if distributed, the entire local copy, and you don't have to worry about it. If later you need to make new changes you can either respawn the branch from main / upstream, or clone from upstream and you are ready to go with every upstream change. If you leave the branch inactive for a while, you have to remember to do a rebase before you start your new work to get to the same position. It is having lots of unsynchronized code living for a long time in the branch which causes all of the problems, because by definition anything living in a branch is not integrated and so does not enjoy the benefits granted by being merged. This includes not having multiple branches making incompatible changes, and finding out that things broke because someone did a refactoring and your code was not covered, so you now get to fix that problem.
    1
  39. Think of it another way. I started programming when spaghetti code and waterfall development were the norm, and waterfall was even taught as good design. Then it was noticed that if you moved to structured programming with meaningful names, proper loops, and procedural and functional code got rid of the spaghetti code problem, but it changed how you wrote programs. The problem is now writing a big ball of mud full of technical debt and breaking regularly resulting in new legacy code which is often a snowflake. The solution is to envelope it in lots of small deterministic and fast unit tests, which move the code structure away from writing hard to test code, especially if you do it test first, and even more so if you move to tdd as the design methodology. When you only test the public API of your internal libraries, you still maintain the benefits of being able to do rapid prototyping of your code as long as you don't break that API.
    1
  40. I think the other guy has it more right. You do not expect a major breaking change to become the new default on a minor version bump, and it is thus a bug in the compiler. The bug is not adding the code, nor giving it a flag to make it usable, but making it the new default silently against user expectations or a minor version update, and this is what he did not seem to understand.
    1
  41.  @ITSecNEO  according to the android website, the android kernel is a linux lts kernel with some patches which have not been upstreamed yet. given the resistance from the kernel community to take anything but c code for things c must depend on, the percentage of non c in the kernel must be minimal. while you can call c code from c++, and from rust, i am not sure how well it works the other way around.
    1
  42. The book "A practical approach to large-scale agile development" describes exactly how and why hp introduced systematic testing for their entire laser jet printer line, including their prior problems and how it got rid of them, including the testing of the embedded hardware involved. Well worth a read.
    1
  43. put some small amount of time into helping open source projects, then you can show your commit log as evidence of experience.
    1
  44. ​ @ProfessorThock using the calculator example, if you have a test called two times two equals four, and it fails, you know what you are testing, what the answer should be, and what code you just changed which broke it. After that, it is fairly easy to find the bug. If you write code using test first, first you prove the test fails, then you prove the code makes it pass. If you do tdd, you also prove that your refactoring didn't break it. Finally, when a new change breaks it, you know right away, how it broke, and the new code that did it. Much easier than having 18 months spent doing waterfall development, throwing the code over the wall, and hoping integration or testing departments can find all the bugs.
    1
  45. There were machines at the time which did not even have a keyboard, and some systems worked using the ansi or ebdic character set, rather than ascii. Also, the querty keyboard layout is only standard in English speaking countries. My amiga in the 1980s had a German keyboard which was not querty.
    1
  46. agile technology has found a number of things which make programming slower and harder. every piece of research says that the higher your level of technical debt, the more tricky it becomes to add a simple change, as you often have to fix that debt first. ci, tdd, and cd all build on top of that research to provide demonstrable ways that it can be handled, which speeds up development. i watched both of his crowdstrike reviews, and read everything from crowdstrike about how it happened. this basically comes down to them shipping the code without sufficient testing and monitoring. the response of everyone to this has been to say how it could have been detected before it even shipped, and shock that they did not do what even app developers do by default. he literally wrote the book on continuous delivery, so of course his channel is going to cover related issues.
    1
  47. ​ @shining_cross the point of a multi core server is that unlike in the old 8bit days, your computer is not just doing one thing. If you want your code to go fast on multi core, shard it, just like is done with databases. This is what microservices were invented for.
    1
  48. ​ @ameer6168 the only way to deal with such a client is to do continuous delivery based on incremental development, where you get sign off on acceptance tests with each new test cycle, combined with penalty fees for rework that needs to be done for excessive changes to already approved acceptance tests. This is what acceptance tests are designed for, and like with any customer, you have to make a choice about the value of working for them. If your rework fee is high enough then either you will stop them from keeping changing them, makes enough extra cash to be worth keeping them as a client, or you will know they are not worth the cost of keeping them.
    1
  49. Ada was not used because it did not exist. Having the compiler be a few years old and using multiple compilers is to catch compiler bugs. Also, c++, ada, and a lot of other kitchen sink style languages are too big to compiler, test, and understand easily, which is why there is so much bugger c++ code out there.
    1
  50.  @isodoublet  ada is basically 7 different special case languages shoe horned intl a common syntax. As to c++, I'm quoting some of the compiler writers when I say that the language is huge and complex, which does not really affect the standard cases, but makes all the odd corner cases a complete pain to locate, find the definitive documentation for, and test if the compiler gets it right for those odd cases. Also, it includes additional problems to do with how classes and inheritance interact which are not present in the c languages, which stops at abstract data types. And that is before you get into some of the funky ways core libraries have been implemented which make c++ badly suited for embedded and safety critical uses.
    1