I love the references to Jacques Ellul's ideas, which I think are interesting to reflect on in an AI age. It helps make clear that what is fundamentally at stake in much technological "progress" is an (often only tacitly acknowledged) sublimation of "efficiency" to the place of highest value.
What's fascinating is that this value elevation seems to have gone largely unchallenged, despite being in essence an arbitrary value choice. Other choices are possible. And, I hope, still are possible, despite what the bigcorps declare must be the case in order to maximize shareholder returns.
Efficiency isn't even the best way to optimize for (expected) shareholder returns for an organization! Efficiency fundamentally trades-off against adaptability and resilience.
Efficiency is easy to measure. And whatever is measured becomes the goal.
It is harder to measure craft, care, or wonder. My best proxy is emails from real people, but those are sporadic, unpredictable, and a lot harder to judge than analytics screens that update every minute.
100%. This is what I posted about on Hacker News ([1] where it got no traction) and Reddit [2] (where it led to a discussion but then got deleted by a mod).
I found myself frustrated with Node’s child_process library. Some great primitives but a lot of boilerplate to do simple tasks like return a Promise when a subprocess is known to have started. So I built teen_process as a wrapper with a nicer async interface, helpful defaults, and all around cleaner ways of doing subprocess management with Node. https://github.com/appium/node-teen_process
(NB: once the project was determined to be useful we moved it to the Appium org and it has seen lots of contributions from others, not just me)
Thanks for your thoughts. The point of my article wasn't to deny that there are any counterexamples to my overarching theme. No argument involving society is going to be free of counterexamples.
I disagree with some things you've said here but will just say 2 things:
1. I'm grateful you give everyone an equal chance. I thought I did too until I uncovered what I now believe to be an ingrained sort of bias. If you're free from that, more power to you! Far be it from me to tell you who you are.
2. I do believe that racism is one of the hidden engines of society, and inhabits each of us more than we know for that reason. That's why I was proposing to move the dialogue from an existential proof of racism to a question of how exactly it has shaped us. It's not (or doesn't feel like) "pseudoempathy" as another commenter put it. It feels like moving past denial to a more productive mode of engagement with this gnarled issue.
I'm surprised there's yet another JS implementation of the webdriver protocol. I wonder what was lacking in the existing frameworks from the author's perspective?
+1 on appium support (disclaimer: I'm an appium contributor). Shouldn't be too hard for them to add since it supports real devices. Opens up the door to Selenium library support and compatibility, which would be a huge win IMO.
(disclaimer: I'm an appium committer) While Frank and Appium provide a similar set of solutions to a similar problem, we're driven by slightly different philosophies. Two of Appium's core tenets are (1) you shouldn't have to modify your source code or add 3rd-party libraries to test, and (2) it's better to leverage existing successful "driver" protocols. To that end, we've designed things so that all of the interaction takes place between Appium and your un-modified app, whereas Frank requires compiling in its own libraries for testing. Likewise, we opted to make Appium a Selenium WebDriver-compatible server, so that the thousands of developers who are already familiar with using their favorite WebDriver library can jump in and start writing tests without having to wrap their heads around a new automation model. Frank is an extremely impressive piece of technology, but we felt the need for an approach born out of a different philosophy.
Very cool. With Frank, Calabash and Zucchini already out there (to name just a few), the iOS UI automation space is getting pretty crowded. Having said that, it is definitely nice to see something that is not based on Cucumber. Any ETA on the Android?
You stating your philosophies won me over, mostly because I agree with them. I generally test using the builtin stuff, and only on models. Never controllers or views.
This could be useful.
What's fascinating is that this value elevation seems to have gone largely unchallenged, despite being in essence an arbitrary value choice. Other choices are possible. And, I hope, still are possible, despite what the bigcorps declare must be the case in order to maximize shareholder returns.
reply