What i am working next: is actually the next version of that eval. The assessments can be improved in lots of ways and there are much more cases coming.
At Symflower we do, one of us has it as its main editor and it looks extremely productive. As a former VIM hardcore user i enjoy the pair programming sessions. I guess these sessions must feel the same way when a non-VIM user watches a VIM hardcore user.
Its a nice and short introduction to SAT and especially SMT with a real world example written in SMTLIB. If anybody is interested or has any questions, let me know. We are planning to post more about SAT and SMT as they are part of our core technology.
As someone who is in the business of software, infrastructure and especially testing for now almost 20 years, i can underline the fact that people often still think of (automated) software testing as something that is not needed. "I tried it, it works, so let's merge it without automated testing." is one of the sentences i heard so many times in my work-life, but even more often i hear "But it worked, yesterday". What is your favorite quote about testing? One of mine is now definitely "testing code and automating things should require the same care and skill as working on your product" as stated by the article. I can fully stand behind that quote. Worth reading!
Just read through the article and was wondering if anybody had experience with migrating from Cypress to Playwright, or Playwright in general?
Before Cypress i was used to working around problems of Selenium/Webdriver. Now it seems with Cypress there are less workarounds but still some problems. The article really talked to me e.g. grouping of tests is a major painpoint IMHO.
One of the funniest articles i have read in a while. Know the author's journey really well, the dailies were funny as heck. Getting rid of a "/" is really hard work, you need to dig deep. Worth reading even if you don't do Angular, digs also into HTML and the JS History API
Yep. I have that practice too and i thought that was good enough but with git-autofixup and my posted alias i am down to under one second. So it will save you 1-14 sesconds of your life with every fixup you do... unless it cannot be done automatically. Try it and let us know what you think :-)
Totally agree. I guess what i am trying to say is that learning rebase is a must and powerful tool but if you are doing the same things again and again you should think about automating them and use your thinking-power and time for non-automated things.
I/we do but sometimes you just overlook something especially if there are a lot of changes. But having someone else review what you do almost completely removes that problem.
I usually do not look through all commits again when a basic review already happend and i "just" integrate the review comments. That is where for me personally these problems happen that git-autofixup is sometimes wrong but in over a few thousand commits in the last months this happend only thrice. Which for me just speaks for the tool IMHO. Ow the original author big time :-)
Learning rebasing is one thing but wasting hours every week on rebasing because you are doing the same thing over and over again is another. When i do a one line fixup i just do not want to figure out the correct commit and then rebase i just want it to happen because i already know how i would rebase that: you just use git-autofixup or other similar tools discussed here to get it done.
What i am working next: is actually the next version of that eval. The assessments can be improved in lots of ways and there are much more cases coming.