Link to a few sample outputs of different assets that were not used during its development - https://www.linkedin.com/pulse/technical-analysis-62-st13-py...
144 karma · joined February 18, 2017
I left banking to do these open-source automation stuff full-time a year ago, partly out of interest and partly to dedicate time for self-directed learning. Tomorrow, I'll be moving back to full-time job at AI Singapore (https://www.aisingapore.org). It's a government initiative to build up AI capabilities locally. During my role there, integrating the tool (in its current form or a new form) with AI and ML capabilities will be part of my job scope.
Here's the current set - Bengali, Chinese, English, French, German, Hindi, Hungarian, Indonesian, Italian, Japanese, Korean, Polish, Portuguese, Romanian, Russian, Serbian, Spanish, Tagalog, Tamil, Thai, Vietnamese.
Web automation basically reproduces manual interactions you have with websites so that the computer can do it repeatedly for you. Common use cases are automating manual workflows to improve business productivity, gathering data for business intelligence, and web testing for agile development.
Rates are competitive at $18, €15, S$24 for a simple automation project. The automation can be quickly developed off-site or live on a call / video. More details in the link. Competitors are welcome to post here to share their services or tips, and help bring the web automation domain forward.
My goal is to offer another option to the RPA (robotic process automation) industry practice which takes a top-down approach. Too much bloat in the production and delivery process which gets passed on as high costs to customers (and arguably over-promised expectations). That makes it only possible for very large companies to enjoy benefits of RPA.
Just went through your Friendscript syntax, the amount of work going into defining that language is impressive....
From a fundamental level though, my hunch would be how modern development takes modularization / abstraction to a type of extreme. Imagine a popular Node.js module and how many dependencies it has and how many dependencies its dependencies have.
It's not hard to imagine a lot more computing power is required to handle this. But that's ok to decision makers, computing power is cheap. Saving developers time by using modularized developments brings more cost/profit benefits, like what Dan said.
PS: the link on Visual Studio. Oh wow, what fond nostalgic memories it brings me :)
Being driven by a large commercial entity actually has a chance of making it work out. With the browser automation tool and the browser dev team being one team, there can be synergies not possible otherwise. When I spoke to CasperJS creator some time ago, I can understand why there will be burnout. Referring to the popular Chromeless project launched less than a month ago, there are already 150+ new issues and 100+ still open, and they already have enough pipelines for a few releases ahead. It can be a nightmare to manage.
There's just too many needs from a large user-base for such projects. I'm speaking from the context of test automation and general browser automation.
But resonated with your point that there are just so much codebase / automation assets already written. Usually exploring new tools happens when a new project happens, rather than recoding entirely an existing project. For the existing code base, unless contributors from the community writes a parser to translate those to Puppeteer API?
Default behavior by design is to block automated headless downloads for security reasons. But above issue tries to address this important use case.
Pre-internet era - people know little but do a lot and deeply
Post-internet era - people know a lot but do little and shallow
Yes perfectly, I believe for any one very serious about test automation or browser automation in general, they will make their own tool and bring it to market if there isn't already one that meets their needs. :)
https://medium.com/@kensoh/chromeless-chrominator-chromy-nav...
- "Do pretty much everything you've used PhantomJS, NightmareJS or Selenium for before".
The main features of those tools plus their ability to handle a large range of edge cases are built up over the years in production use and do not seem to be already in Chromeless. Also, Lambda costs can be a significant point of consideration for professional test automation with large volume.
Nevertheless, there's no turning back as flood gates have been opened and many developers are noticing Chromeless. I believe, with enough dedication from Chromeless maintainers, they may be able to channel the attention and contributions to shape Chromeless to be the main challenger to existing test automation approaches. That will really be a blessing to the open-source community!
The only catch I believe, is it may be easier for those existing tools to be made working in Lambda or implement a similar form of parallelism while still having their mature API, than for Chromeless to catch up to the state of maturity of those tools. But as they say, growth solves almost every problem, so issues like these may be ironed out through collaborative efforts from contributors/maintainers.
EDIT - above is assuming downloading a file by simulating a click event to perform the download. there may be other workarounds by script injection etc to use XMLHttpRequest() for downloading a resource directly.