any chance you know if they plan to support Apple M1 hevc as well?

I still have no idea how to use this.

The "simple" project is a bunch of files ... with no instructions on how to use it.

Javascript ecosystem as a whole.

Well he did said

> fell apart without me

Is uMatrix something you use instead of uBlock, or in addition to? Also is there a guide on how to use it somewhere

I use both, but sometimes it's a bit a pain in the ass with capchas and and embedded iframes etc. A lot of trial and error which scripts are needed. But it's great to know most of the crap, including cookie/consent banners are blocked.

Does this not blow/up or block most logins for apps?

The first time I log into a website I often need to do a few rounds of "allow this script; refresh; allow this script; refresh" to get captcha/cdns working. But then I save for that site and don't think about it again. It can be a bit of a pain sometimes, but I find it interesting having to acknowledge where different sites pull resources from.

To answer my own question, it's a bit redundant but I need both.

uMatrix handles network stuff (blocking css, js, media, etc).

uBlock also handles network stuff, but the difference is that uBlock can also block specific elements on the page, eg, divs by id or class.

The Stylus extension is great for that. Firefox's style editor lets you test CSS edits in real time. Then copy those CSS rules into Stylus and the browser will remember them. I use it to turn off all CSS animation too.

If you block all JS and CSS with umatrix, you can still read articles by pressing the "reader view" button in Firefox.

https://addons.mozilla.org/en-US/firefox/addon/styl-us/

https://chrome.google.com/webstore/detail/stylus/clngdbkpkpe...

uMatrix can do the later too by now

The author is the same as uBlock Origin; here is the repo: https://github.com/gorhill/uMatrix

From the wiki page, there are many useful FAQ/ guides/ docs. Specifically, there is a link to a decent guide:

http://adamantine.me/index.php/2015/11/18/umatrix-desperatel...

edit: using both is redundant

If you want something a little simpler try scriptsafe[0]. Still lets you whitelist JS you want to trust, enable temporarily or for a set time. I find it rather clearer than uMatrix.

In fairness to gorhill it's a couple of years since I last looked at uMatrix so it may be much improved.

[0] https://github.com/andryou/scriptsafe

Not sure if you're aware, but the vue-webpack template actually switched over to webpack-dev-server just last week

https://github.com/vuejs-templates/webpack/releases/tag/1.2....

I'm looked at previous version. So I'm not awared.

the problem then is when they ask for multiple security questions

"potato" "potato" "potato"

then they tell you that you cant use the same security answer for multiple questions

...... and thats when i nope out

Just curious, how do you handle the vanilla-JS stuff?

1) inline with your view files

2) write them in separate js files and include them depending on the page

3) concat them into one big js file which gets included on every page

4) something else?

Yes, we do a lot of inlining at the end of a view. In every case when the javascript is only usable for that view we find this very clean, every developer can immediately see what javascript is running on that particular view.

We have our own small library for the more common operations, for small things like more effecient navigating of the DOM three or more complex "components" that for example convert a select element to a nicer selectbox with built in full text search. That library is included for every view. This library weight around 50kb gzipped.

Some companies go for that 'disciplined javascript' style. It's a nice paradigm to follow, but every time you'd want to make it slightly more advanced (as the app grows) you'd have to implement tooling on your own.

You turn off wifi when you know that you won't be using it, eg, when you go outside of work/home.

Some people will not want their phone connecting to WiFi because they don't want tracking, eg around the supermarket.

This was my first thought. I definitely wouldn't risk my client's privacy going through a third party like this.

I usually seed dev and test databases with fake data. Emails are usually a sequence like userN@example.com Sending mail to that is usually not a problem, unless the content of the mail is somewhat sensitive. Again, fake data helps. When I work with Ruby I use the faker gem.

If you have to import production data then, yes, that would be annoying. Anonimizing data sometimes is not easy.

uh no. that's the id of the blog post

https://github.com/blog/2105 https://github.com/blog/2106 https://github.com/blog/2107

Aw, it looked so much like a minor mistake with the Y-M-D date format considering it happened on 2016-january-28th!