🌐
Downloads Videos Blog About Series πŸ—ΊοΈ
❓
πŸ”‘
/troglovlog:
Troglodyne LLC video podcast

Audit::Log released to CPAN πŸ”— 1642470899  

🏷️ video 🏷️ blog 🏷️ programming 🏷️ perl
For those of you interested in parsing audit logs with perl.

Looks like I need to make some more business expenses if I want to be able to stream 4k video!

Never say Never πŸ”— 1628695077  

🏷️ video
Last time, bro thought he was done talking about organized irresponsibility. Instead, we had a "scrum" at lunch and iterated quickly upon yet more to talk about regarding this.

Organized Irresponsibility: why corporate does what it does πŸ”— 1628521896  

🏷️ video
Discussion of the "organized irresponsibility" in corporations, and how it kills the ability to take risks. How this destroys the ability to find meaning in corporate work.

The Big Shift πŸ”— 1623865865  

🏷️ video 🏷️ blog
People are wondering if the "Great Resignation" is real. I'm here to tell you that it is, and the consequences are farther reaching than you might suspect. #TheBigShift

I've already seen a number of job-hops by the most talented engineers at firms I'm in touch with here in flyover country, as they realize they can be paid better even at remote rates by joining a coastal firm.

This is a mirror of what is happening with people moving all over the country from the coasts to flyover country. The reasons for doing so are actually the same, however.

The nature of progressive taxation means that the most productive pay the most in, and as such the departure of this small minority of people has an outsized impact on tax base. The movement of these people from income tax states such as CA and NY to non income tax states such as TX and FL is having an outsized impact as such.

Similarly, the people leaving to get better remote work opportunities are those best capable of doing so; the most productive. Repeated study has shown that a minority of very productive employees do the vast majority of important work in the firm, so even a small number of high profile defections are going to have huge impact.

The question of course is "Why now?" Here, the reason for both is the same. Lockdown destroyed the inertia which was preventing movement -- the benefits of community which previously kept one from moving residence or firm were forcibly extinguished. This made all locales and firms roughly equal when it came to amenities, so you may as well just move to the highest paying and lowest taxing situation possible, as you can't exactly maximize for lifestyle anymore.

Now that people have actually pulled the trigger on movement they are realizing that those things keeping them where they were weren't that great in the first place, and actually little more than rationalizations for inertia. As such we can probably expect a de-emphasis on fringe benefits in the firm going forward.

As to the policy implications of this mass migration, it's sending an unmistakable message. Taxes are too high relative to what the citizenry of the coast get out of it, and have been for a long time. Unlike the firms, I don't expect they will adapt quickly enough to avert crisis.

Review BRO TIPS from the Troglodyne Bros! πŸ”— 1621381478  

🏷️ video
As always, dealing with the human equation is the more challenging technical problem. Sorry for the lack of video on Monday πŸ˜…

LSM Trees, Hypertables and other data structures πŸ”— 1620833779  

🏷️ video
Use the right tool for the job! Most of your program's performance is down to what data structure you use, so you need to be familiar with the data program you choose.

The fall of college and rise of the Atelier πŸ”— 1620416002  

🏷️ video
Colleges are generally experiencing a collapse everywhere they don't embrace this model. Direct feedback from the customer is key in any field of endeavor, and many colleges got fooled by cheap money into abandoning that. They are now being replaced by institutions that are built around the customer.

Article Mentioned here.

Cultural Fit: What's it really about? πŸ”— 1620310031  

🏷️ video
The culture described to new and prospective hires is almost always aspirational rather than actual, leading to conflict when expectations confront reality.

Playwright, Selenium and Perl πŸ”— 1617057517  

🏷️ video 🏷️ testing 🏷️ selenium 🏷️ blog

Last week Sebastian Riedel did some mojo testing using Playwright, I encourage you to see his work here. It would have been neat if he'd used my playwright module on CPAN (as it was built to solve this specific problem). He did so in a way which is inside-out from my approach.

That's just fine! TIMTOWTDI is the rule in Perl, after all. For me, this underlines one of the big difficulties for even a small OSS developer; If you build it, nobody will come for years if you don't aggressively evangelize it.

On that front, I've made some progress; playwright-perl got a ++ from at least one other PAUSE author and I got my first ever gratuity for writing open source software thanks to said module. This is a pretty stark contrast from the 100% thankless task of Selenium::Remote::Driver, which is a lot more work to maintain.

This is a good point to segue into talking about Sebastian's article. Therein he mentions that some of the tricks Playwright are using might end up being a maintenance landmine down the road. Having both worked at a place which has maintained patches to upstream software for years at a time and maintained a selenium API client for years I can say with confidence this is less of a problem than selenium has.

The primary trouble with selenium over the years has to do with the fact that it is simply not a priority for any of the browser vendors. The vast majority of issues filed on Selenium::Remote::Driver over the years have been like this one: In essence, the browser vendor issues a broken driver for a release and we either can ignore it as transient or have to add a polyfill if it persists across releases. Selenium::Remote::Driver is more polyfill than client at this point (partially due to the new WC3 selenium standard not implementing much of the older JSONWire spec).

Historically, Chrome has been the biggest repeat offender in releasing broken drivers. However post-layoffs, it appears Mozilla is getting in on this game as well. Add people frequently using drivers of versions which are incompatible with their browser and encountering undefined behavior, and you begin to understand why microsoft decided to micromanage the browsers the way they did in Playwright. In practice, you need this level of control to have your testing framework be less buggy than the system you want to test with it.

In the end, the reason selenium sticks to open protocols is because they don't have the resources to devote to proper maintenance. I regard a firm which maintains patchsets as a positive; this signals they are actually willing to devote resources to maintenance. They would not have written and shipped them had they not been willing to; most especially not at a firm like Microsoft which is well aware of the consequences.

Selenium's dark secret

While Sebastian didn't mention these, there are also a number of other drawbacks to selenium other than selenium sticking to open protocols. The most glaring of which is that most of the browser vendors do not support getting non-standard attribute values (such as the aria* family) which are highly relevant. You must resort to simply executing javascript code, which more or less defeats the purpose of 90% of the Selenium API. This is the approach pretty much all the polyfills in Selenium::Remote::Driver take.

Another huge controversy over the last half-decade was the "Element Overlap" check, which was buggy for years (especially when negative margin was involved) and still can't be turned off reliably. By contrast, Playwright's check is easy to turn off and has always worked correctly. It sounds like Microsoft learned the right lesson instead of being insensitive to the will of the vast majority of users.

The "Upgrade" to the WC3 protocol also removed a great deal of functionality, while giving us less new features than were removed from the JSONWire spec. Back then the drivers were even more unreliable than they are now; The primary point of the standards was to try and find a minimum set of functionality that they could reliably maintain, an effort which is a clear failure at this point.

Microsoft's approach of just letting the browser vendors do their thing and adapt to them rather than demanding they adapt to testers is far better. In my career this always works out the same way. Your life as a developer and tester gets a lot better when you take the software you work with largely as a given.

Why did playwright have to be made at all?

All the points above lead one to conclude the only thing you can rely on in selenium is the javascript interpreter. So why not just skip selenium and write tests with something like protractor? This is in fact what a number of organizations have done.

It's not like the WC3 API gives you anything above and beyond what the JS interpreter can give you, so it makes a lot of sense from a practical perspective. Playwright on the other hand gives you easy access to everything enabled by the DevToolsProtocol on every browser with a unified API. Selenium 4.0 offers the ability to talk to the DevToolsProtocol, but without a unified API. This is why I consider Selenium an obsolete protocol which has been leapfrogged entirely by Playwright.

Selenium's Enduring Strengths

This is not to say that Selenium does not have some features which are still not met by the Playwright team. In particular the built-in Selenium Grid which has been massively strengthened in Selenium 4.0. This is enabled by it being a server based approach, rather than just a library for talking to the browser.

Obviously, this is quickly solved with but another layer of abstraction. I did precisely that to accomplish the first Playwright client not made by Microsoft. The server-based approach I took would allow me to replicate Selenium's grid functionality in the future with Playwright... but that's probably not needed in our modern era of coverage reporters and containers. That's why my current project Pairwise is aimed at simplifying this workflow specifically.

The holy grail of acceptance testing

Back in the JSONWire days, Microsoft UI had the genius idea to unify desktop testing under the Selenium API with WinAppDriver. This unfortunately has been abandoned in favor of making VSCode a world-beater. This was clearly the right move for microsoft, as even I have been largely converted from my vim + tmux workflow. I still think this is an amazing idea, and (if nobody beats me to it) I want to make an equivalent for linux (using XTest) and OSX...and windows, but all using the Playwright API instead.

Working with Playwright as a client maintainer

Playwright also made another design decision which guarantees it will be easy to spread and write clients for. It ships with a machine-readable specification, while Selenium has never (and likely will never do so). Since SeleniumHQ's 4.0 JAR made breaking changes, I decided to make a new client Selenium::Client. I liked the approach of dynamically making classes based upon a spec, and did so for the next generation selenium client. However, this required that I parse the specification document, which was a nontrivial task (see Selenium::Specification).

The intention long-term is to replace the guts of Selenium::Remote::Driver with Selenium::Client to reduce maintenance burden; this will take some time given how difficult it will be to untangle due to the module being a big ball of mud.

Closing Thoughts

The rest of Sebastian's article goes over the practical points of embedding your perl application inside Node to test it. Much of these are the same concerns (ensuring the server is up before testing, bringing it down correctly, ensuring deps) which I had with the server. Similarly, build toolchain issues are about the same either way; you'll have to wrangle both cpan and npm one way or another. In the end it comes down to personal preference; do you want to write Playwright in perl or JS?

For guys like Sebastian and I who are as fluent in Javascript as Perl, his approach actually makes a lot of sense and is a lot less work than making a module like Playwright-perl. The path to scaling is also less work than building in a grid-like functionality to Playwright-perl; Kubernetes deployment of a bunch of containers each running some subset of tests and using a coverage reporter isn't exactly rocket science. That said, doing the same with scripts built atop playwright-perl won't exactly be difficult either.

For those of you more comfortable in Perl than JS, I think you'll be well served by playwright-perl. Feel free to give it a shot if this sounds like you. If you like it a lot, feel free to send me a gratuity, become a patron, or log some bugs if you don't like it so much.


Q2 2021 Retrospective πŸ”— 1616521494  

🏷️ video 🏷️ blog
6 Months in. Thoughts on where I need to keep developing and "Stacking the Bricks" that I should have done more of earlier in my Career.

Selenium::Client released to CPAN πŸ”— 1612566669  

🏷️ video 🏷️ blog 🏷️ selenium 🏷️ Selenium::Remote::Driver 🏷️ testing
I got a client which works with Selenium v4 and WC3 Selenium! I decided to make a new module rather than deal with some of the design decisions that made maintaining Selenium::Remote::Driver such a pain, and was freed up to bake in some nice features in the bargain.

I also go over the various "gotchas" with the new selenium and where we go from here with the module and Selenium::Remote::Driver.

Big changes coming to Selenium::Remote::Driver πŸ”— 1610589448  

🏷️ video 🏷️ selenium 🏷️ Selenium::Remote::Driver 🏷️ blog 🏷️ testing
Selenium v4 looks like some good stuff, so it's about time to bring it all to the Perl community since it's going mainstream this February.

Troglodyne Live! Hot Take Testing πŸ”— 1609527292  

🏷️ video
Wherein we give the YT streaming a shot, talking about "old news" but that still has the potential for huge implications.

TrogloVlog: Episode 26 - Core Values and Playing House πŸ”— 1609105671  

🏷️ video
Turns out, "Core Values" can be hugely important and valuable for your company. Too bad hardly anyone uses them in a way that makes sense. Book Discussed: "You Need More Money" by Matt Manero

TrogloVlog: Episode 25 - Cute Animal Bins to stuff your programmers in! πŸ”— 1607807220  

🏷️ video
Whee! This management stuff is easy! ...well, maybe not lol Probably not the best idea to compare your employees to zoo animals

TrogloVlog: Episode 24 - Atlassian kills self hosted! Woe unto these companies with that product? πŸ”— 1607803196  

🏷️ video
Nah, turns out they probably would have saved money and incurred less risk by just outsourcing that concern in the first place. Atlassian is spot on with the marketing here (and we're not even shilling!)

Press release discussed:
https://www.atlassian.com/migration/journey-to-cloud

TrogloVlog: Episode 23: Don't put Vault Doors on Crackhouses! πŸ”— 1607798051  

🏷️ video
Premature Optimization? Put down the pipe!

Troglovlog: Episode 22 - Codes of Comfort πŸ”— 1607797572  

🏷️ video
Part 2 of the last cast. Now that we've got inauthenticity and coercion out of the way, let's strike to the heart of the matter: Comfort is overrated!

Troglovlog: Episode 21 - Codes of Coercion πŸ”— 1607796599  

🏷️ video
Sometimes management at a firm will codify certain attitudes or practices that employees must hold or follow. Unfortunately, this guarantees inauthenticity. Don't make this mistake unless you want employees to gain cognitive dissonance about your corporate brand.

TrogloVlog: Episode 20 - MicroISV Hero discovers Economic Coordination and the Structure of Production! πŸ”— 1607795580  

🏷️ video

TrogloVlog: Episode 19 - Do Patents in the Software World make sense? πŸ”— 1607794454  

🏷️ video
Like all headlines with a question mark at the end, the answer is (unsurprisingly) NO. Most of the time patents are an excuse to not actually do the work required to get what you need done, instead validating your identity as "an innovator".

TrogloVlog: Episode 18 - Why Checklists Work in QA and Development πŸ”— 1607793591  

🏷️ video
Checklists are used often in many industries, but even to this day we still see a disturbing lack of checklisting in software. Don't make this mistake!

TrogloVlog: Episode 17 - The magic is Showing Up πŸ”— 1607757999  

🏷️ video
But how does one show up to work?? Search, of course. In this video we talk in general about how this all works.

Let's see if we can learn how to make magic internet money together!

TrogloVlog: Episode 16 - Why telling Stories is Important πŸ”— 1607757406  

🏷️ video
Not just for your business, but for ours as well!

Article mentioned:
https://ariyh.substack.com/p/attach-a-ritual-to-your-product

TrogloVlog: Episode 13 - Judging Risks and Rewards as a fellow traveler in Software πŸ”— 1607752097  

🏷️ video
This time we come in with an episode that tries to "bring it all back together" regarding things we've been talking about these past few weeks. We cannot stress enough the importance of judging risks and properly estimating expected rewards as it regards success both in software projects and your own life!

25 most recent posts older than 1607752097
Prev Size:
Jump to:
POTZREBIE
© 2020-2021 Troglodyne LLC