If you don't know what fast-live-reload is you should probably see this video. TL;DW: unlike any other live reload tool on the planet, fast-live-reload can build execution pipelines (probably the only one still from the command line), serve folders, proxy sites, etc. Truly a Swiss army knife.
More than once when monitoring folders, I wanted to execute commands for the specific files that would change.
A good example that comes to my mind is AsciiDoc. When I monitor a folder where I have a bunch of asciidoc files, I want to run asciidoctor individually. For that file. So far that was not really possible. What I would do would be, decide upfront on what file I would work, and run:
"Superb", I know.
Finally, since version 2.6.0, if in the executed command the variable $FILE is defined, the command will be executed for each changed file, and the FILE environment variable will be passed to the script. Thus the previous example would be:
If you want this tool, you need node and just:
Originally published at the project's site: http://www.germaniumhq.com/2016/07/03/2016-07-03-What-Do-We-Learn-from-the-Broken-Firefox-WebDriver-Support/
With the new release of Firefox 47, the WebDriver support was left in limbo. On one hand, the old WebDriver API was not accessible anymore, on the other hand the new API (Marionette) explicitly didn’t support it. Kid you not, they actually used the word explicitly when saying they don’t support version 47, despite Mozilla telling on the release notes to use it.
“Go use it, it’s broken” [probably someone at Mozilla]
Of course, this lead to the Mozilla team releasing a hotfix for Firefox, namely 47.0.1 which fixed, you guessed it, allowing the old WebDriver API to work. The only small problem is that Mozilla knowingly introduced a bug that nuked all the WebDriver Firefox tests. For 3 weeks. Between June 7 and June 28.
Now that we know this might happen, how do we mitigate this?
The answer is containers. Docker containers.
Germanium, out of the box, comes into two flavours. One one hand it’s the library itself that we know and love and that gets tested against a set of browsers.
Now, for Firefox and Chrome, also docker images are automatically built, that guarantees such changes in infrastructure aren’t destroying your tests stability. For Firefox, since version 47 wasn’t running anymore using WebDriver, the container used Firefox 46 and the old API (the Marionette support is at this stage abysmal).
Of course, this means we’re not on the bleedingest of edges of the browser version, but that is OK. In the Continuous Integration system, we want to be sure we don’t get all our tests failing just because WebDriver has a bug now, especially since the API itself it’s still coagulating, so this is bound to happen some more. The key is to lock the moving parts of the testing environment, and Germanium does that by default.
Also these images themselves are used to test Germanium itself. So you know that all the API calls that are documented there are running as expected.
The simple girlfriend that doesn't really get you. Whenever you go to a new place, she doesn't want to go. Goes if you really insist, but causes a scene there.
The borderline insane girlfriend. One mistake, and she goes bonkers. Tries to be friends with all of your friends, even if no one likes her.
Your true love, but you know deep inside you two won't last. She's nice, but whenever you want something from her she's nowhere to be found.
Boring as hell. You pity her and you think you should like her more. You just can't get yourself to do it. She keeps trying to make it work.
The slightly prettier sister of Java, with all the mental issues of C++.
The beast from Beauty and the Beast. Reasoning with her is like talking with a grizzly bear.
She always hungers for human flesh. Congratulations, you're dating a zombie.
Originally published on the Germanium's project website: http://www.germaniumhq.com/2016/06/02/2016-06-02-Germanium-1.7.11-Is-Released/
This version has a far better implementation of the wait() function, that has the following guarantees:
Here’s the canonical simple google search with our wait in action:
Today I checked again, and to my surprise I got:
For the first time segment (273 days period) I averaged 5.98 IP bans a day. From that day to today I got: 5853-1633 = 4220 new bans. The time period from November 2014 to today is 573 days.
That means in the last year the banning grew to 7.36 bans a day (~20% increase). And we need to remember that this is also with the previous backlist.
So today, beside applauding fail2ban's relentless work, I changed the port of the SSH server.
To my surprise from this morning, until now, there is radio silence from the fail2ban new bans. I guess most scanners don't do a port scanning first, and they just try to find default or weirdly configured SSH servers.
So here's my second tip. Change your SSH server port.
The one to rule them all. The browsers that is.
SharpKnight is an Android chess game.
MagicGroup is an eclipse plugin.