• commit and push changes on personal branch, tell someone ready for merge.
    • any other team member reviews and merges into stable and pushes to the stable repo.
    • CI runs make deploy which will run tests, builds and then deploys it.

    Personal Projects:

    • make deploy does the right thing.

    We use Makefile as our entry point into our projects, make is everywhere, and it’s mature, well tested software, the warts are well known, etc. make test will just work, regardless of the language or tools actually used to run the tests, etc. i.e. for Rust code, we use cargo to run tests, for Python code we use pytest w/ hypothesis, but you don’t have to remember those details, you just remember make test.


      The GUI and menu systems dont phase me but the sheer complexity of the game and the number of things that can go wrong fun is just overwhelming.


        Well, it’s hard to say anything about LISPs in general since the span is so vast and academic, and especially for me, since my contact with any LISP is quite limited. But, from my understanding of the common usage of LISP, it doesn’t qualify.

        First of all, I think dropping static analysis is cheating, but I don’t intend to tap into an eternal flame war here. What I mean when I say “the properties of the current languages” is no implicit allocations, borrow-checking and inline assembly like in Rust, purity and parametricity like in Haskell, capabilities-security like in Pony etc. etc. , and not only the semantics of these, but also compilers taking advantage of these semantics to provide static assistance and optimizations (like using the stack instead of the heap, laziness & strictness analysis etc.).

        And I’m also not just talking about being able to embed these into a given language; you should also be able to write code such that if it’s simple enough, it should be usable in many of them. For instance, it’d be hard to come up with some language semantics in which the identity function cannot be defined, so the identifier id x = x should be usable under any local semantics (after all every category needs to have identity morphisms). You should also be able to write code that interfaces between these local semantics without leaving the language and the static analysis.

        I know you can embed these things in LISP, expose enough structure from your LISP code to perform static analysis, get LISP to emit x86 assembly etc. etc. But, IMHO, this doesn’t make LISP the language I’m talking about. It makes it a substrate to build that language on.


          I think your office was featured in this scene of a movie at least one American in Russia thinks was historically accurate despite talking about future events. ;)


            When you get the hang of it, you’ll start seeing how similar it is to The Sims: Goblin Seige Edition.


              Taking a break. It’s the weekend. Give yourself a moment away from the computer.


                It’s funny, because I googled “why women pants no pocket” to figure out why this is the case and the first result says that it’s because men who dominate the fashion industry don’t want women to have pockets.

                Why don’t all the women who want pockets get together, start a company to make highly-pocketed pants, tap this unmet demand and make billions? You know, scratch your own itch and all.


                  I am working on CI based releases.

                  • Dev work goes in feature branches
                  • Test manually in a QA environment for a faked login process of provisioned auth users.
                  • If everything looks good manually release to Prod infrastructure.

                  … I haven’t had to rollback any releases yet … So yay! (In 5+ years)

                  Prod has Grafana graphs and internal audit reports of the live system.


                    I signed up for WintellectNOW and am watching Bruce Dawson’s courses on Event Tracing for Windows.


                      I love to see how both Google and Samsung completely miss the mark with the size of their mobile phones. There were clearly not enough woman involved in the development of those phones.

                      How did they miss the mark though? Their phones sell very well and people clearly want the bigger size. It’s the pants companies that missed the mark or maybe the consumers who keep buying pants that don’t suit their needs.


                        Not if the pocket is deep enough. I have pants that I can fit my phone in the pocket and it’s no issue because the phone sits lower on my leg.

                        1. 5

                          It’s probably a disconnect between what people complain about and what they buy. I heard fake pockets make pants look slimmer so when a designer adds large pockets they sell less of that design even though thats what people say they want.


                            I found this article really interesting since I had no idea the problem existed. I think maybe the suppliers dont either. The stuff they make that’s slimmer or lighter in pockets sells the most. When Im in Walmart or Target, the heavier stuff isn’t what people are trying on. They might have noticed this eventually modifying supply practices to sell attributes majority were buying.

                            Another thing thing comes to mind is that each piece of clothing has multiple attributes. Women probably buy something that looks and feels nice despite smaller pockets they don’t like. However, a simplistic analysis of purchasing data might count those sales as a yes to all three. They mighy think small pockets are in demand even though they didnt matter. Then, start putting them on more clothing.

                            In any case, there’s certainly an unserved need in the market. Smaller suppliers with a proven design/style should consider making a version of each with bigger pockets. A big uptick in sales of those might cause larger suppliers to follow suit.


                              That shirt is awesome! Might even trick programmers that see it into learning to avoid it. They Google it but find no rainbows. ;)

                              1. 6

                                Your comment doesn’t answer the OP’s questions and doesn’t contribute anything to the discussion. Please write something useful instead. I’m disappointed that several people thought this one-word comment should be upvoted.


                                  Probably pretty vanilla but it works:

                                  • every PR gets tested by jenkins (integration tests and codestyle)
                                  • after a merge the pr is being packaged into linux packages and pushed to pulp
                                  • we manually trigger a job that will copy the package to our dev repository
                                  • our infrastructure orchestration will try to update packages every couple of minutes
                                  • we keep track of errors on a grafana dashboard, if everything is ok we de trigger a deploy to acc
                                  • etc… untill drp is online

                                  We don’t have a massive volume of activity so the manual actions are something we can live with. We’re working on using containers for the next version, but deploying to dev, acc, … probably will always be a manual action.


                                    Mastering C Pointers: Tools for Programming Power has several four-star reviews on Amazon uk.

                                    So? One of the dangers of picking the wrong textbook is thinking it’s great, and using it to evaluate subsequent works in the field, without knowing it’s shit. Per hypothesis, if it’s your first book, you don’t know enough to question it, and if you think it’s teaching you things, those are the things you’ll go on to know, even if they’re the wrong things. It’s a very pernicious bootstrap problem.

                                    In this case, the book is objectively terrible. Other books being bad don’t make it better.

                                    I do agree that Schildt’s book is also terrible.


                                      I don’t want to sound arrogant but just stating ‘Painful.’ doesn’t seem to be helpful imho… Care to explain why it’s painful en what actions you have taken/you will take to make it less painful?


                                        Roughly thousands of manhours of manual testing all over the world. Requires a few months and millions of dollars. Details vary depending on the customer.

                                        For the developers there is continuous integration testing for each pull request done via x86 simulation and on target device. Code reviews for each pull request. Sometimes manual full system testing by developers but mostly by a special integration team.

                                        I’m working for an automotive supplier so our processes are probably not applicable to you. The contrast might be interesting though. ;)


                                          At $job:

                                          1. Announce roll out in the common chat channel. We have about 50 ish things that can be rolled out and concurrent rollouts are the norm.
                                          2. Roll out like 5 minutes later tops.
                                          3. Monitor graphs, the common error tracing, and the chat while in vanguard.
                                          4. Declare success 15 minutes later and deploy to the rest of the hosts.

                                          Abort and revert if anyone signals a problem during that process.

                                          The first action taken when a rollout is suspect is to revert, if it’s been live for less than a day. That’s not a hostile action and as the rollout system is uniform across the company anyone knows how to revert or rollout any system.

                                          It sounds janky, but is remarkably efficient in practice.