The ambush of WWW::Mechanize::Chrome shows more fallout before the module itself
has been released. The module is one in a long line of browser automation
modules I wrote, starting with WWW::Mechanize::Shell,
reaching is breakthrough with WWW::Mechanize::Firefox
and continuing from WWW::Mechanize::PhantomJS to WWW::Mechanize::Chrome.
In April, Google announced that Google Chrome was finally supporting
at least on Linux and Mac OS. Back then, I noted to myself that
this might be a good time to revisit my rough prototype of
WWW::Mechanize::Chrome. According to Git, I had written a first
prototype of it in 2010 which used the old, raw socket protocol. But
time has progressed and the protocol now uses Websockets. My original
approach used AnyEvent, so I quickly replaced my own approach using
AnyEvent::WebSocket::Client, and the HTTP parts with Future::HTTP.
Do not ask what Perl can do for you, ask what you can do for Perl!
In my effort to bring the new signature back to older versions of Perl, I'm
a source filter that simply converts the signatures to the equivalent old-style
Perl code. That filter works surprisingly well for its simplicity and has caused
very little in problems.
I don't mind working with Spreadsheets. Much of my work consists of creating
Spreadsheets from SQL queries. Sometimes, the resulting spreadsheet should be
a pivot table, listing some values across the spreadsheet. For most of my
Spreadsheet-generation needs, Querylet
is sufficient, but it cannot create pivot tables.
In my long-term quest to host all of my data on my systems, one of the major
points is to replace the note-taking app Google Keep with something that allows
me to take my notes back to me. I've looked at various open-source apps for
taking and synchronizing notes, but they either feel like overdesigned monsters
that don't fit my workflow (Laverna) or don't have good synchronization from
mobile phone to the server.
While trying to get some more of my modules ready for release, I've been doing
drive-by patches to CPAN modules that I used for various reasons. While I'm not
exactly enthused about throwing a patch with a testcase over the fence, I think
it's still far better to have the problem and solution in some bug tracker
somewhere than having it only on my hard drive.
While putting off working on my Perl Advent Calendar submission, I was instead active in resolving bugs in App::ShaderToy and adding some interesting features. The three major features I added this week are, in order of implementation, loading of bitmap images, hot reloading of code and the feature to make the window stay always on top.
It is incredible how much joy quicker iterations bring me while toying around with shaders, tweaking the parameters to see if I can find new visuals.
The shader is a modification of a shader by Inigo Quilez, hacked up by Weyland.
After the initial rush of success, I spent this week working more on the UI side
of the app, putting off adding support for geometry generation for later.
Prima proves to be a solid UI toolkit and to me it feels closer to using Delphi or Visual Basic, API wise.
For a long time, I've wanted to actually make use of the modern hardware I have at home. The graphics card is capable of OpenGL and OpenGL now has a fancy little language to actually bring images to life. For example [https://www.shadertoy.com] has great so-called "shaders" that show off what can be done with them.
Because I also want to toy around with programming some shaders, I want to get a live environment running. So during the weekend, I took the Glew library, wrote a small Perl script to convert the header files to XS, and then fought with OpenGL until I had a driver that could run shaders from Shadertoy.com: