Comments by "" (@grokitall) on "Continuous Delivery" channel.

  1. Unfortunately that is not a realistic option. What you are basically talking about there is having a micro kernel design and forcing everything else into user space. The problem with that is that they have been looking ever since it was first designed for ways to mitigate the high costs of working this way, and literally every suggestion which improved micro kernel performance could also be done with a monolithic kernel, so it does not provide any additional benefit. You will always have code which needs to run in kernel mode. This can be due to speed constraints for interrupt handlers and drivers, because it needs higher level security access like with malware detection and mitigation, or for multiple other reasons. The key is to split the code so that the bit which absolutely must be in the kernel is minimal, and everything else is in user space, where it can crash to its hearts content and only kill itself. Then you just have to pay the price for jumping between the two. It is cheaper than not paying it and increasing the kernel footprint too much.
    1
  2. ​ @eltreum1 no, if it ever gets to court we will definitely find out. Their primary defense seems to be to try and claim contractual limitations to liability, but published legal analysis has pointed out that this only holds if they were not negligent. Their secondary defense seems to be to try and throw their programmers under the bus, but management already had multiple experiences of this type of issue, so that fails the knew or should have known willful blindness test. Their programmers will get called to testify, and cross examination will be brutal. Sales will also be called, as there was a disconnect between what they were promising customers, and what was actually going on.
    1
  3. No, they see unit testing as cumbersome because they don't write the tests first, then write legacy code which is not designed to be tested, and then write implementation dependent tests which are fragile against the newly written legacy code. All testing of legacy code is cumbersome, a total pain, and an exercise in frustration. This is why you write the test first, so you do not write the legacy code in the first place. However this is a skill, and as Dave pointed out, when you first try it you try and write the test for the imaginary legacy code, and find you are not getting the advantages.
    1
  4. ​ @manuelgurrola basically your functional tests check that your code does what you expect it to do, and belong in the ci system. thing like memory footprint, speed of response, etc are acceptance tests, and go in the cd system.
    1
  5. ​ @lapis.lazuli. from what little info has leaked out, a number of things can be said about what went wrong. first, the file seems to have had a big block replaced with zeros. if it was in the driver, it would be found with testing on the first machine you tried it on, as lots of tests would just fail, which should block the deployment. if it was a config file, or a signature file, lots of very good programmers will write a checker so that a broken file will not even be allowed to be checked in to version control. in either case, basic good practice testing should have caught it, and then stopped it before it even went out of the door. as that did not happen, we can tell that their testing regime was not good. then they were not running this thing in house. if it was, the release would have been blocked almost immediately. then they did not do canary releasing, and specifically the software did not include smoke tests to ensure it even got to the point of allowing the system to boot. if it had, the system would have disabled itself when the machine rebooted the second time and had not set a simple flag to say yes it worked. it could then have also phoned home, flagging up the problem and blocking the deployment. according to some reports, they also made this particular update ignore customer upgrade policies. if so, they deserve everything thrown at them. some reports even go as far as to say that some manager specifically said to ship without bothering to do any tests. in either case, a mandatory automatic update policy for anything, let alone some kernel module is really stupid.
    1
  6. The problem with your three ring circus is that the middle ring does not gain you anything, which is why no operating system that I know of implements it. The windows kernel had a flag which enabled crowdstrike to require their code to always run in order for windows to boot. This is possibly a good thing for security software and critical drivers, but the problem is that on reboot after the crash, nothing done by windows kept any record of which mandatory drives actually completed booting. If it had, it could have flagged the crowdstrike broken driver as buggy, and booted without it. Crowdstrike also claimed to have stuff in their code which identified buggy updates, but either it did not exist, or was never tested, but if it worked as they told their customers it did, it also could have flagged the 291 update as broken, and rolled back to the previous version until a new update was released. Because it did not work, this never happened.
    1
  7. If you are talking about delta, they were doing exactly that based on the promises given to them by cloudstrike. If you are talking about cloudstrike, they actively subverted the promises they provided to both Microsoft and their customers, which is why they are being sued a lot.
    1
  8. not really, we all know how hard it is to fix bad attitudes in bosses. in the end it comes down to the question of which sort of bad boss you have. if it is someone who makes bad choices because they don't know any better, train them by ramming home the points they are missing at every oportinity until they start to get it. for example if they want to get a feature out the door quick, point out that by not letting you test, future changes will be slower. if they still don't let you test, point out that now it is done, we need to spend the time to test, and to get it right, or the next change will be slower. if they still did not let you test, when the next change comes along, point out how it will now take longer to do, as you still ha e to do all the work you were not allowed to do before, to get it into a shape where it is easy to add the new stuff. if after doing that for a while, there is still no willingness to let you test, then you have a black boss. with a black boss, their only interest is climbing the company ladder, and they will do anything to make themselves look good in the short term to get the promotion. the way to deal with this is simply to get a paper trail of every time you advise him of why something is a bad idea, and him forcing you to do it anyway. encourage your colleagues to do the same. eventually one of the inevitable failures will get looked into, and his constantly ignoring advice and trying to shift blame to other will come to light. in the worst case, you won't be able to put up with his crap any more, and will look for another job. when you do, make sure that you put all his behaviour in the resignation letter, and make sure copies go directly to hr and the ceo, who then will wonder what is going on and in a good company will look to find out.
    1
  9.  @jimhumelsine9187  because testing is not really taught, and people don't design with testing in mind, having to test the legacy code can be a pain, so some developers don't like it, but it still comes back to management. either the company cares about tests, or it does not, and if you do care, then everyone needs to write and not break tests. testing is like version control, it only works if everyone does it, and you cannot do continuous integration without it.
    1
  10. there are plenty of cases of management by metrics where it only leads to 2 outcomes. 1, managers valuing fast workers who produce buggy features that nobody likes over careful workers who produce quality features a bit slower. 2, clever programmers gaming the system to subvert the metrics. both of these just annoy the good developers, which is why it has never worked in software and other creative industries.
    1
  11. at the very least, there should have been some sort of smoke test to see if it even got as far as completing booting, and disabled itself if that failed.
    1
  12. microsoft allowing a bad driver update to stop you from doing a full reboot, no, nothing to do with microsoft.
    1
  13. ​ @Storytelless so you write a test tool to run all of your cross platform stuff against which reports when some piece of code will cause a problem in a particular supported browser. This linter will initially just parse the code, but as you find nasty browser specific corner cases, you flag them up, and run this linter over your code before checking in the change. I've done this with html since windows 95, reporting browser specific problems, so the code just does not get checked in in the first place.
    1
  14. I think that what we need here is a test like jez humble's continuous integration test, but for tdd. Most of the criticisms I see can be sumerised as "I write legacy code and don't get the testing pyramid, unit testing or regression tests, so why would test first regression testing make sense". As they don't get regression testing, they also fundamentally don't get refactoring, continuous integration or technical debt. Time for them to learn some of the basics of the industry wouldn't you say?
    1
  15. ​ @SteveBurnap have fun with flags. set a flag when you download the update. if the flag is not update or booted, leave the driver and have it disable itself if it is updated change the flag to say it started if it has started do the minimum work to show it boots, then change the flag to say it booted at this point, either it worked, or it got out of the way next reboot. suddenly the problem did not occur in production, and everything else is solved by testing and canary releasing.
    1
  16. While it might make sense to test the internals of functions in systems programming languages, it still makes more sense to write functional tests of the function API until you absolutely need to test the internals, and then only test those bits you absolutely must test.
    1
  17. but as the systems could be rebooted, all you need is for the os vender to block drivers which were updated prior to the reboot, and the os boots and can start recovery procedures.
    1
  18. no, if you are corporate scale, you have on call tech support whenever your business is open.
    1
  19. Yes doing tdd slows down the initial delivery speed, but unless you absolutely need first move advantage to capitalize on the network effect, not doing it usually comes with a much crappier result, and becomes increasingly slower until you move to a test first design. So in that specific use case, you can get some advantage from being first to market, but you are usually better served even in this case doing test first with a minimal viable product and incrementally adding more features.
    1
  20. ​ @evgenyamorozov no, it won't compile, but you are designing the public api, so it does not need to. Once you have an api call which is good enough, you have your failing test, which fails by not compiling, so you create a function definition which meets that api, and a minimal implementation which returns whatever value your test requires, thereby compiling and passing the test. Then you come up with another example which returns a different result, which then fails, and make just enough changes to the implementation to pass both tests. Then keep doing the same thing.
    1
  21. If you need two tests, write two separate tests, but remember that their purpose is different. Unit tests and integration tests are part of the continuous integration stage, and check that the code does what the programmer understood was needed. Acceptance tests are part of the continuous delivery pipeline, and check that the code does what the user actually intended. They tend to be written at different times and sometimes by different people for different purposes.
    1
  22. we have known how to do man rated systems since the moon landings, and this is not how. the last time the nhs in the uk was brought down, it was embedded medical devices using windows xp years after end of life mixing with current machines.
    1
  23. ​ @mallninja9805 that quote describes the development philosophy, not the release philosophy. How it works in practice is you do iterative development to develope new capabilities at speed, then you use ci/cd testing to make sure you do not release garbage.
    1
  24.  @ChristianWagner888  i was not aware that the efforts in mac os and linux were further progressed than capabilities and potentialities. thanks for the information. you cannot stop bugs in kernel level code from taking down the kernel. the issue here is how the os responds to it after a reboot. boot looping until someone comes along and manually fixes it shows that in this case the answer is not well. having as little code in kernel space as possible is obviously the best answer, which is why the idea of microkernels was so popular, but in practice there are some things you need to do which must be done in kernel space. the key there is to do as little as possible, and expect things to break, planing to mitigate the side effects.
    1
  25. One of the points of test first is that it gradually migrates the code you write into a more testable format, which naturally produces a more functional design, especially when you can make them pure functions with no side effects. Dave made the point in other videos that testable code and legacy code look very different. This is because the legacy code is not designed to be testable, and thus is a total pain to test. It is like trying to retrofit security into an insecure application, you can do it, but it is not pleasant.
    1
  26. ​ @vanivari359 what you described is no more tdd than long lived feature branches which are seldom integrated are Ci. What you are describing is a lot of mandatory testing of the internal api's of internal functions, whereas tdd works in an implementation independent method against the public api's of public functions. You then get the code coverage that your system needs not by testing the internal functions, but by using them from the public api, and having them return results that make sense. The bits which do not get used are then either potential dead code, or part of a more general implementation of a library that you only need some of the functions provided. In either case, as you are working at the public api, you are completely free to totally change how the stuff behind the curtain works. If it is a problem, either you are testing implementation, or you are not coding to pass the tests, in which case you are not doing tdd.
    1
  27. ​ @tongobong1 I would say you can have multiple assets if it is defining a complex precondition, but that this is the only time, and should be discouraged, as this is usually the code smell that you have not done enough upfront thinking about the testing. It is usually better to move all of those assets into separate tests with clear error messages. This is one of the benefits of tdd, in that it naturally moves the logic of the code under test to a more modular form so it ends up easier to test. You only have to test the logic of the module rather than having to muck about testing all of the surrounding glue logic describing where and how to get your test data. It also makes your code more functional, and makes more of it into pure functions which are easy to test.
    1
  28. no, this is what happens when you push a kernel module to everyone at once without any testing. code review or push to master was not relevant to the failure mode. a simple test deployment and canary releasing would have caught this even if you were doing waterfall development.
    1
  29.  @ansismaleckis1296  the problem with branching is that when you take more than a day between merges, it becomes very hard to keep the build green and pushes you towards merge hell. the problem with code review and pull requests is that when you issue the pull request and then have to wait for code review before the merge, it slows everything down. this in turn makes it more likely that the patches will get bigger, which take longer to review, making the process slower and harder, and thus more likely to miss your 1 day merge window. the whole problem comes from the question of what is the purpose of version control, and it is to do a continuous backup against every change. however this soon turned out to be of less use than expected because most backups ended up in a broken state, sometimes going months between releasable builds. this made most of the backups to be of very little value. the solution to this turned out to be smaller patches merged more often, but the pre merge manual review was found not to scale well, so a different solution was needed, which turned out to be automated regression tests against the public api, which guard against the next change breaking existing code. this is what continuous integration is, running all those tests to make sure nothing broke. the best time to write the tests was before you wrote the code, as then you have tested that the test can fail and pass. this tells us that the code does what the developer intended it to do. tdd adds refactoring into the cycle, which further checks the test to make sure it does not depend on the implementation. the problem with not merging often enough is that it breaks refactoring. either you cannot do it, or the merge for the huge patch needs to manually apply the refactoring to the unmerged code. continuous delivery takes the output from continuous integration, which is all the deployable items, and runs every other sort of test against it trying to prove it unfit for release.if it fails to find any issues, then it can then be deployed. the deployment can then be done using canary releasing, with chaos engineering being used to test the resilience of the system, performing a roll back if needed. it looks too good to be true, but is what is actually done by most of the top companies in the dora state of devops report.
    1
  30. alpha beta and releasable date back to the old days of pressed physical media, and their meanings have changed somewhat in the modern world of online updates. originally, alpha software was not feature complete, and was also buggy as hell, and thus was only usable for testing what parts worked, and which parts didn't. beta software occurred when your alpha software became feature complete, and the emphasis moved from adding features to bug fixing and optimisation, but it was usable for non business critical purposes. when beta software was optimised enough, with few enough bugs, it was then deemed releasable, and sent out for pressing in the expensive factory. later, as more bugs were found by users and more optimisations were done you might get service packs. this is how windows 95 was developed, and it shipped with 4 known bugs, which hit bill gates at the product announcement demo to the press, after the release had already been printed. after customers got their hands on it the number of known bugs in the original release eventually went up to 15,000. now that online updates are a thing, especially when you do continuous delivery, the meanings are completely different. alpha software on its initial release is the same as it ever was, but now the code is updated using semantic versioning. after the initial release, both the separate features and the project as a whole have the software levels mentioned above. on the second release, the completed features of version 1 have already moved into a beta software mode, with ongoing bug fixes and optimisations. the software as a whole remains in alpha state, until it is feature complete, and the previous recommendations still apply, with one exception. if you write code yourself that runs on top of it, you can make sure you don't use any alpha level features. if someone else is writing the code, there is no guarantee that the next update to their code will not depend on a feature that is not yet mature, or even implemented if the code is a compatability library being reimplemented. as you continue to update the software, you get more features, and your minor version number goes up. bug fixes don't increase the minor number, only the patch number. in general, the project is moving closer to being feature complete, but in the meantime, the underlying code moves from alpha to beta, to maintainance mode, where it only needs bug fixes as new bugs are found. thus you can end up with things like reactos, where it takes the stable wine code, removes 5 core libraries which are os specific, and which it implements itself, and produces something which can run a lot of older windows programs at least as well as current wine, and current windows. however it is still alpha software because it does not fully implement the total current windows api. wine on the other hand is regarded as stable, as can be seen from the fact that its proton variant used by steam can run thousands of games, including some that are quite new. this is because those 5 core os specific libraries do not need to implement those features, only translate them from the windows call to the underlying os calls. the software is released as soon as that feature is complete, so releasable now does not mean ready for for an expensive release process, but instead means that it does not have any major regressions as found by your ci and cd processes. the software as a whole can remain alpha until feature complete, which can take a while, or if you are writing something new, it can move to beta as soon as you decide that enough of it is good enough, and when those features enter maintainance mode, it can be given a major version increment. this is how most projects now reach their next major version, unless they are a compatability library. so now code is split into 2 branches, stable and experimental, which then has code moved to stable when ci is run, but it is not turned on until it is good enough, so you are releasing the code at every release, but not enabling every feature. so now the project is alpha (which can suddenly crash or lose data), beta (which should not crash but might be slow and buggy) or stable (where it should not be slow, should not crash, and should have as few bugs as possible). with the new way of working, alpha software often is stable as long as you don't do something unusual, in which case it might lose data or crash. beta software now does not usually crash, but can still be buggy, and the stable parts are ok for non business critical use, and stable software should not crash, lose data or otherwise misbehave, and should have as few known bugs as possible, thus making it usable for business critical use. a different way of working with very different results.
    1
  31. one additional point i failed to mention. when someone looked at 5 releases of red hat linux and the thousands of packages on it, they found that 70% of the code had not changed over the multiple years covered by the study. that code was so stable that it had not even needed a bug fix. most features in modern projects follow a similar dynamic, where most of the churn happens in a small amount of the code, with an increasingly stable long tail on the graph. this graph looks exactly the same whatever language the project is written in.
    1
  32. Actually they are mostly complaining about having to start writing regression tests and having to write testable code when they could previously write untestable garbage and force q & a to have to deal with it. Regression testing shines a light on how bad your code is, and they don't like it as they like to think that due to spending some time programming they must be good at it. Test first they hits you in the face with how bad you are at testing, which is not taught, and tdd's refactoring step shows just how much copy past coding is in your code base. Understandably a lot of people who never had to do testing don't like it and push back, mostly with comments which can be paraphrased as "I only know how to write legacy garbage, so it doesn't work for me", not realizing that this is what they are saying.
    1
  33. I do know that when they write the code for the space shuttle they used the fact that they had multiple machines that had to agree to put the contract out with multiple companies. When they got it back they analyzed it, and found that a lot of the code had the same assumptions and blindspots in them, which just goes to show that it is much harder to get completely redundant implementations of the same specifications than you think. I'm sorry, but I don't remember the names of the reports and papers which covered it in detail.
    1
  34. the problem with the idea of using statistical ai for refactoring is that the entire method is about producing plausible hallucinations that conform to very superficial correlations. to automate refactoring, you need to understand why the current code is wrong in this context. this is fundamentally outside the scope of how these systems are designed to work, and no minor tweaking can remove the lack of understanding from the underlying technology. the only way around this is to use symbolic ai, like expert systems or the cyc project, but that is not where the current money is going. given the current known problems with llm generated code, lots of projects are banning it completely. these issues include: exact copies of the training data right down to the comments, leaving you open to copyright infringement. producing code with massive security bugs due to the training data not being written to be security aware. producing hard to test code, due to the training data not being written with testing in mind. the code being suggested being identical to code under a different license, leaving you open to infringement claims. when the code is identified as generated, it is not copyrightable, but if you don't flag it up it moves the liability for infringement to the programmer. the only way to fix generating bad code is to completely retrain from scratch, which does not guarantee fixing the problem and risks introducing more errors. these are just some of the issues of statistical methods, there are many more.
    1
  35.  @ThomasTomiczek  i do not underestimate the potential of ai to help with all sorts of programing tasks, only the implausability of getting there using the currently popular statistical ai systems, the whole point of which is that you throw a lot of data at them and they do not create a model of the system, just a bunch of plausible corellations each of which could be noise. you could have a swarm of symbolic ai's each looking at the code base and figuring things out which other parts could then make use of, which in turn could help take legacy code from an untestable big ball of mud to a much better design, but to do that, it needs to have some clue as to what the existing code is doing, why, and how to move it in the direction of something better.
    1
  36.  @ThomasTomiczek  the whole approach is based on not modeling the problem and looking for ever larger numbers of low level correlations, which be purely coincidental and hoping it can come up with something which is good enough. when you point out this problem, the suggested solution is just to throw more of the same at the issues, which will somehow magically solve problems caused by how the tech works. turtles all the way down does not work in philosophy, and it does not work in software.
    1
  37. Lots of people bash Microsoft over this, and they are not completely blameless, but this is a kernel mode issue. Anything running in kernel mode can crash the system, no matter who writes the code. The question is what happens on reboot. Ebpf is still code, and if it is run in kernel mode it can still crash the machine. The same thing could also happen with your proprietary video drivers under Linux.
    1
  38. ​ @ContinuousDelivery this is exactly the correct analogy to use. In science what you are doing is crowd sourcing the tests based upon existing theories and data, and using the results to create new tests, data and theories. Peer review is then equivalent of running the same test suite on different machines with different operating systems and library versions to see what breaks due to unspecified assumptions and sensitivity to initial conditions. This then demonstrates that the testing is robust, and any new data can be fed back into improving the theory. And like with science, the goal is falsifiability of the initial assumptions. Of course the other problem is that there is a big difference between writing code and explaining it, and people are crap at explaining things they are perfectly good at doing. Testing is just explaining it with tests, and the worst code to learn the skill on is legacy code with no tests. So people come along and try to fit tests to legacy code only to find that the tests can only be implemented as flaky and fragile tests due to the code under test not being designed for testability, which just convinces them that testing is not worth it. What they actually need is to take some tdd project which evolved as bugs we're found, delete the tests, and compare how many and what types of bugs they find as they step through the commit history. If someone was being really nasty they could delete the code, and reimplement it with a bug for every test until they got code with zero passes, and then see what percentage of bugs they found when they implemented their own test suite.
    1
  39. Tdd comes with a number of costs and benefits, and so does not doing tdd or continuous integration. The cost of doing tdd is that you move your regression tests to the front of the process, and refactor as you go and it can cost up to 35 percent extra in time to market.. What you get back is an executable specification anyone can run to reimplement the code in the form of tests, a set of code designed to be testable with very few bugs, and the combination is optimized for doing continuous integration. You also spend very little time on bug hunting. it also helps with areas that are heavily regulated as you can demonstrate on an ongoing basis that it meets the regulations. All of this helps with getting customers to come back for support, and for repeat business. Not doing tdd also comes with benefits and costs. The benefit Is mainly that your initial code dump comes fast, giving a fast time to market. The costs are significant. As you are not doing incremental testing, the code tends to be hard to test and modify. It also tends to be riddled with bugs which take a long time to find and fix. Due to the problem of being hard to modify, it is also hard to extend, and if they have to get someone else to fix it it can sometimes be quicker to just reimplement the whole thing from scratch. This tends to work against getting support work and repeat business. As for the snowflake code no one will touch, it will eventually break, at which point you end up having to do the same work anyway, but on an emergency basis with all the costs that implies. Testing is like planting a tree, the best time to do it is a number of years ago, the second best time is now. The evidence for incremental development with testing is in, in the dora reports. Not testing is a disaster. Test after gives some advantages initially, while costing more, but rapidly plataus. Test first cost a very little more than comprehensive test after, but as more code I covered you get an ever accelerating speed of improvements and ease of implementation of those improvements, and it is very easy for others to come along and maintain and expand the code, assuming they don't ask you to do the maintenance and extensions.
    1
  40. I doubt it, but you do not need them. If you look at history you can see multitudes of examples of new tech disrupting industries, and project that onto what effect real ai will have. Specialisation lead us away from being surfs, automation removed horses as primary power sources, and changed us from working near 18 hour days seven days per week towards the current 40 hour 5 day standard. Mechanisation also stopped us using 98 percent of the population for agriculture, moving most of them to easier, lower hour, better paying work. This lead to more office work, where wordprocessors and then computers killed both the typing pool and the secretarial pool, as bosses became empowered to do work that used to have to be devolved to secretaries. As computers have become more capable they have spawned multiple new industries with higher creative input, and that trend will continue, with both ai and,additive manufacturing only speeding up the process. The tricky bit is not having the industrial and work background change, but having the social, legal and ethical background move fast enough to keep up. When my grandfather was born, the majority of people still worked on the land with horses, we did not have powered flight, and the control systems for complex mechanical systems were cam shafts and simple feedback systems. When I was born, we had just stepped on the moon, computers had less power than a modern scientific calculator app on your smartphone, and everyone was trained at school on the assumption of a job for life. By the time I left school, it became obvious that the job for life assumption was on it's way out from the early seventies, and we needed to train people in school for lifelong learning instead, which a lot of countries still do not do. By the year 2000, it became clear that low wage low skilled work was not something to map your career around, and that you needed to continually work to upgrade your skills so that when you had to change career after less than 20 years, you had options for other, higher skilled and thus higher paid employment. Current ai is hamstrung by the fact that companies developing it are so pleased by the quantity of available data to train them with that they ignore all other considerations, and so the output is absolutely dreadful. If you take the gramarly app or plug in, it can be very good at spotting when you have typed in something which is garbage, but it can be hilariously bad at suggesting valid alternatives which don't mangle the meaning. It also is rubbish at the task given to schoolchildren to determine things like if you should use which or witch, or their, there or the're. Copilot makes even worse mistakes, as you use it wanting quality code, but the codebases it was trained upon have programmers with less than 5 years experience, due to the exponential growth of programming giving a doubling of the number of programmers every 5 years. It also does nothing to determine the license the code was released under, thereby encouraging piracy and similar legal problems, and even if you could get away with claiming that it was generated by copilot and approved by you, it is not usually committed to version control that way, leaving you without an audit trail to defend yourself. To the extent you do commit it that way, it is not copyrightable in the us, so your companies lawyers should be screaming at you not to use it for legal reasons. Because no attempt was made as a first step to create an ai to quantify how bad the code was, the output is typically at the level of the average inexperienced programmer, so again, it should not be accepted uncritically, as you would not do so from a new hire, so why let the ai contribute equally bad code? The potential of ai is enormous, but the current commercial methodology would get your project laughed out of any genuinely peer reviewed journal as anything but a proof of concept, and until they start using better methods with their ai projects there are a lot of good reasons to not let them near anything you care about in anything but a trivial manner. Also as long as a significant percentage of lawmakers are as incompetent as you typical magazine republican representative we have no chance of producing a legal framework which has any relationship to the needs of the industry, pushing development to less regulated and less desirable locations, just like is currently done with alternative nuclear power innovations.
    1
  41.  @gruntaxeman3740  because you cannot run the flight arrival status system an a desktop, it has to be where you can see it, which makes it hard to reach. same with kiosk type systems, and any type of system where you do not want the operator to have full access to the machine. anything working like an autopilot, where it matters that it does not fail while in use, and many other use cases.
    1
  42. ​ @AndrewSmithDev what you are doing there is exploratory testing to understand the external library. A well written library will separate the core functionality from the user interface, so you can write a test providing your input with your guess as to the output, and correct the test if the result does not match. If the same input gives different outputs to the same input, use a different library because the non-deterministic nature of the library code responses will cause nothing but problems. How will you know if your code using the returned value is correct if you don't know what the returned value will be? The only way around this is to log the input to the library and every respone, and then create lots of tests covering every response to make sure it does not return something daft, and then expect previously unreported values to be returned in production. For most tasks that is a level of risk that is just not worth the costs involved for the value provided.
    1
  43. ​ @astronemir yes, having a dead American comedian working with them will show their quality levels.😂 I think you mean Dave Farley.
    1
  44. ​ @nschoem that perception definitely exists, and is based upon intuitive feelings that writing tests with your code takes longer, which is true but not really relevant. What happens with feature addicted managers is that they start off saying get the feature to work and we can write the tests later. Then they prioritize the next feature over testing, resulting in no tests, and what few tests do get written are fragile because the only way to test most code that was not designed with tests in mind tend to rely on implementation details to work at all. This results in code with increasing levels of technical debt which gets harder and harder to debug and extend, making everything slower. The only way to fix this is by refactoring your way out of the problem, which needs tests, and test after tests are harder to write and fragile, so you end up writing tdd style tests for the refactored code so you can just delete those original tests as they cease being helpful. You still have to write the tests in either case if you have a long lived or large code base, but tdd style tests first tests tend to be API tests which don't depend on internal implementation details, and thus don't break much.
    1
  45. no this is a not doing ci or cd failure.
    1
  46. ​ @lucashowell7653 the tests in tdd are unit tests and integration tests that assert that the code does what it did the last time the test was run. These are called regression tests, but unless they have high coverage and are run automatically with every commit you have large areas of code where you don't know when something broke. If the code was written before the tests, especially if the author isn't good at testing, it is hard to retrofit regression tests, and to the extent you succeed they tend to be flakier and more fragile. This is why it is better to write them first. Assuming that the code was written by someone who understands how to write testable code, you could use A.I. to create tests automatically, but then you probably would not have tests where you could understand easily what the test failing meant due to poor naming. When you get as far as doing continuous integration the problem is even worse, as the point of the tests is to prove that the code still does what the programmer understood was needed and document this, but software cannot understand this yet. If you go on to continuous delivery, you have additional acceptance tests whose purpose is prove that the programmer has the same understanding of what is needed as the customer, which requires an even higher level of understanding of the problem space, and software just does not understand either the customer or the programmer that well either now or in the near future. This means that to do the job well, the tests need to be written by humans to be easily understood, and the time which makes this easiest is to write one test, followed by the code to pass the test. For acceptance tests the easiest time is as soon as the code is ready for the customer to test, adding tests where the current version does not match customer needs. Remember customers don't even know what they need over 60% of the time.
    1
  47. ​ @temper8281 this is the argument I've heard from everyone who can't write good tests, as well as from those who don't understand why testing matters. If you are just doing a little hobby project which nobody else is ever going to use, and is never going to be extended, then you can mostly get away with not having tests. As the project gets bigger, or more popular, or has more developers you need the tests to stop regressions, communicate between developers, spot coupling, and numerous other things, most notably to deal with technical debt. The more any of those factors rise, the higher the cost of shipping broken code, and thus the more the tests matter. By the time you need continuous integration you cannot do without the tests, but the harder it is to retrofit them to your existing legacy code base, so it is better to learn how to do testing earlier and add it to the project sooner.
    1
  48. I find that to be an easy question to answer. Write the test at the next level up only when you have tried to write it at the lower level and found it too hard. More importantly, if you later find that you can test the code using new lower level tests, remove those higher level tests that are redundant and therefore provide no added value. As you will perform new work using tdd,, the refactored new code will be more testable, moving the tests down the levels of the pyramid, until you end up with code using the higher lever tests which is little more than a translation layer to the new functions which exists only to support older code not moved to the newer, more testable API. At this point you can add development comments reporting that the API is deprecated and use whatever the new API is instead, further pushing refactoring of older code.
    1
  49. ​ @mallninja9805 numerous books and articles have pointed out that testing is vital. Testing the happy path is a necessary first step to get the code running with safe configuration options and inputs. Testing everything else is needed to get it so that the stuff is of release quality. Lots of analysis of good codebases has found that the happy path tests can be as high as 1/5 of the tests for simple code, and a much smaller amount for complicated code. The same reports show that the test code can be as large as the system under test. Unfortunately, test code can have bugs as well,
    1
  50. Testing works best for code which has no side effects, and ui work is basically founded on top of side effects, so you have to already have some skill at testing to even consider writing tests for ui stuff and expecting them to work as well as they do for pure functions. Learn tdd against some non ui coding project, and then apply what you learned to the ui work. This will encourage you to separate the true ui stuff from everything else, and make both easier to test. This is not to say don't test ui stuff, only that you need to get above a certain level of skill in testing to do it well.
    1