Ever wanted to delete all your likes/favorites from Twitter but only found broken/expensive tools? You are in the right place.
setInterval(() => {
for (const d of document.querySelectorAll('div[data-testid="unlike"]')) {
d.click()
}
| image: jangrewe/gitlab-ci-android | |
| variables: | |
| ANDROID_COMPILE_SDK: "27" | |
| APP_NAME: "NameOfYourApp" | |
| cache: | |
| key: ${CI_PROJECT_ID} | |
| paths: | |
| - .m2/ |
This guide was written because I don't particularly enjoy deploying Phoenix (or Elixir for that matter) applications. It's not easy. Primarily, I don't have a lot of money to spend on a nice, fancy VPS so compiling my Phoenix apps on my VPS often isn't an option. For that, we have Distillery releases. However, that requires me to either have a separate server for staging to use as a build server, or to keep a particular version of Erlang installed on my VPS, neither of which sound like great options to me and they all have the possibilities of version mismatches with ERTS. In addition to all this, theres a whole lot of configuration which needs to be done to setup a Phoenix app for deployment, and it's hard to remember.
For that reason, I wanted to use Docker so that all of my deployments would be automated and reproducable. In addition, Docker would allow me to have reproducable builds for my releases. I could build my releases on any machine that I wanted in a contai
| // node.js versions pre-v0.18.0 do not support the fetch api and require a polyfill | |
| // const fetch = require('node-fetch'); | |
| fetch( | |
| 'https://discordapp.com/api/webhooks/738983040323289120/mzhXrZz0hqOuUaPUjB_RBTE8XJUFLe8fe9mgeJjQCaxjHX14c3SW3ZR199_CDEI-xT56', | |
| { | |
| method: 'post', | |
| headers: { | |
| 'Content-Type': 'application/json', | |
| }, | |
| body: JSON.stringify({ |
| /* | |
| Hoje iremos MUDAR a vida da pessoa que não te responde no whatsappp... | |
| Que tal enviar mensagens pra ela até obter uma resposta?! | |
| Sensacional não acha?! Mas, somos devs, correto?! Então vamos automatizar esse paranauê! | |
| Para utilizar: | |
| - Abra o web.whatsapp.com; | |
| - Selecione a conversa que você quer; | |
| - Abra o console e cole o código que está no gist; |
Your Service Worker script will need to import in Workbox and initialize it before calling any of the routes documented in this write-up, similar to the below:
importScripts('workbox-sw.prod.v1.3.0.js');
const workbox = new WorkboxSW();
// Placeholder array populated automatically by workboxBuild.injectManifest()
Run each of the following lines, replacing yourdomain.com and codehere with your details:
now dns add yourdomain.com @ TXT google-site-verification=codehere
now dns add yourdomain.com @ MX ASPMX.L.GOOGLE.COM 1
now dns add yourdomain.com @ MX ALT1.ASPMX.L.GOOGLE.COM 5
now dns add yourdomain.com @ MX ALT2.ASPMX.L.GOOGLE.COM 5
now dns add yourdomain.com @ MX ALT3.ASPMX.L.GOOGLE.COM 10
now dns add yourdomain.com @ MX ALT4.ASPMX.L.GOOGLE.COM 10
| ;; React supports "refs" as a way for a component to get a | |
| ;; handle to its children. Classically, refs were string-based. | |
| ;; Recent versions of React support callback attributes as a | |
| ;; more elegant variant of accessing DOM notes or components. | |
| ;; | |
| ;; This example uses a Form-3 component as per | |
| ;; https://github.com/Day8/re-frame/wiki/Creating-Reagent-Components | |
| ;; | |
| ;; For callback refs, see React's documentation | |
| ;; https://facebook.github.io/react/docs/more-about-refs.html |
$ uname -r