The largest user-facing downside of nesting is over-nesting which is classed under “feature misuse”; it is best avoided by sticking to a BEM-like selector pattern and restricting yourself to sensible levels of nesting (1 or 2 levels) in most cases.

This lets you avoid writing overly-specific CSS, which in turn means you avoid unnecessary CSS bloat. The bloat comes because of a few reasons: overly-specific CSS is hard to reuse, which leads to repetition; and, to a lesser extent, the lengths of selectors can get extremely long and cause a lot of unnecessary work for the browser – in extra time to download, extra parse time, and more complicated application.

In terms of browser’s implementation of this, the most worrying seems to be the possibility of combinatorial explosion which is already being discussed.

Well, the nesting present in SASS is more ambiguous than this, so I believe there are cases that other people dislike that ambiguity, but with native nesting we’ll have a chance for it to be designed in a much better way.

Common criticisms of selector nesting are:

• it can make doing the wrong thing (building long, brittle selectors) much easier
• it totally changes the way CSS is read and written (which is no longer true if nesting is native CSS)
• many CSS-parsing tools will choke on code with nested selectors

Having a big change like this to CSS is going to break/change a lot of tooling that wasn’t originally designed to CSS’s syntax, but was instead built with an idea of what CSS was based on what it used to look like.

I’m not a personal fan of preprocessors or nesting, but having it come to CSS natively is a big change, and will totally change the way most people will write CSS. Exciting times!

Have you used Github’s GraphQL API yet? Personally, I’ve found using it to be a breath of fresh air in comparison to their REST API, which was easily one of the best REST APIs I’ve used and leagues ahead of most implementations. Give it a go, the RPC-like mutations are particularly wonderful.

Compliant with which RFC, exactly?

I can’t publish actual results for obvious reasons, but it does find a few servers in a short time (~15-30 minutes maybe, I wasn’t paying attention to the terminal)

Scanning the internet randomly in that way is not gonna lead to a lot of results, at least not in any reasonable time frame. If you instead look at sites that crawl the internet for a living, you get 17.000 results. Not all are actually Redis nodes and not all Redis nodes are completely open.

Attack vectors on Redis to compromise the whole system are known for quite some time, and Redis now has better defaults and a protected-mode by default. But people tend to not update it. We still reguarly have users coming into the IRC channel asking for help with cleaned/exploited Redis node.

I keep reminding people to not open up each and every service to the whole wide internet.

The idea is to have a dev environment that closely resembles your production environment.

Simply put: if environments don’t match, mistakes get made.

I’ve seen it time and time again - to give some examples: local dev using a mocked out in memory cache, prod using memcached/redis; or local dev using SQLite and prod using Postgres. Mistakes get made due to overlooking the differences between implementations.

No mock is as perfect as the real thing and it’s much nicer finding issues in development than at deploy time.

redis is not only a good replacement of memcached, it is a great pub/sub server, a leaderboard and has a geoip api. I need redis in development because I use redis to implement features that use the apis that redis provide.

On the other side, even if am not a huge fan of docker, docker is useful in many cases. For example I use Void Linux and OpenBSD as my desktop operating systems. In one of our client we store data in riak. riak is not available in Void Linux, neither in OpenBSD. Thanks to docker I can easily run riak in docker.

we basically needed a full time devops person.

This is exactly it, and why they can charge so much - I very much doubt a Heroku bill for a typical small company would ever grow larger than the annual salary of a decent ops engineer - and if it does, you know full well it’s time to move away! It would however be nice to have a little more comparable competition in the PaaS space. Heroku is simply king at the moment.

On IRC, spinda rued the fact that there was no ‘party pooper’ downvote option for your comment. I however appreciate your answering this post straightforwardly.

Thanks for the feedback!

I built F5Bot in only a couple hours, so I didn’t do a lot of research or planning. It appears that the ‘comment firehose’ you posted doesn’t even go back one second in time. Is that right? I’m not sure how I could realistically use that without hitting Reddit several times a second, and even then I would miss a lot when Reddit goes down (which is often, I now know). Also, when I posted to Hacker News, a couple commenters mentioned Reddit API limits.

So I just took the lazy/easy way by monitoring only the few subreddits that I actually cared about anyway. In this case, I can check back every couple minutes, and if sometime goes wrong I can check back even later without missing anything.

Would this be substantially more useful to you if it pulled all of Reddit, instead of the current subset?

It’s nice of you to say I could charge money for this. I think I’ll leave the current feature-set up for free. Realistically, it only took me a couple hours to build, so I don’t think it makes sense to monetize that. In fact, I was thinking about going the opposite way and open-sourcing it. I might add premium features in the future, but I’m not sure yet.

Just checked out trackreddit. You weren’t kidding about the interface! I guess maybe they were thinking to make it more powerful, but man, they did not optimize for the common use case at all.

I’ve never seen anything like it; it’s fascinating.

event is good for this sort of ephemeral thing. :)

The implementation is fairly small; it effectively adds the Github user’s public keys to the box’s authorized_keys file on startup and removes the keys on program termination. It relies on the fact that all Github users public keys are publically available at github.com/<username>.keys (e.g mine).

To use it you’d have to trust the individual, Github, your connection with Github and also that their key is theirs and theirs only.

That was my first thought, then I realised it’s no more dangerous than the rest of the unsigned binaries I install off the internet

This is valid criticism. My main focus was trying to find the parts in Rails that can be easily “translated” into Phoenix and explain those parts. I didn’t write much about BEAM and umbrella applications because there really isn’t an equivalent in Rails.

I just noticed that the title kind of suggests that the name of the framework is “Phoenix on Elixir”, which was not the intention. Sorry about that.

I don’t know the answer to your actual question but I have tried migrating a v1 project to Webpack 2 the other week but the ecosystem surrounding it just wasn’t there yet - lots of the loaders and plugins I was using had odd quirks under Webpack 2 or simply didn’t work at all with the new loader configuration format. It’ll take time for the system surrounding Webpack to play catch up, hopefully the official release will step that up a gear.

This is focusing on Mongo mostly because “no password, bind all” is the default setting for any mongo deployment as it assumes you have a working firewall.

I have a web service (forum) that uses a “no password” mongo, but I only make it bind to a loopback address which I can probe from the outside using SSH tunnels if needed (and if anything happens, I still have daily backups). Even if I didn’t modify the settings to let it bind to that port, my firewall would have stopped the server from being publicly accessible.

This is a deployment issue.

I thought this, so I read their Python Getting Started Guide - not a single mention of authentication.

You either have great documentation with big warning signs or safe secure defaults. Mongo currently has neither.

Personally, I would always advocate safe secure defaults, not everything can be solved with education.

I wouldn’t say it’s a deployment problem per se. I believe it’s more of a consequence of the industry valuing products that are “easy” above all else. Defense In Depth is a pretty standard security perspective and popular solutions such as Cassandra, Riak, MongoDB, and redis all prioritize making the default configuration very simple at the cost of security. But that’s what the people want.

I’m not saying it’s ok to open your database up to the world but just that this is expected if you look at the incentives users are giving authors of databases these days.

So this isn’t a Mongo-specific problem, this is a deployment issue.

It is Mongo specific in that the default settings of MongoDB are brain dead and stupid with respect to security.

It is very hard to believe that after this highly-mediatized rash of ransom attacks any database administrator won’t double-check to see if his MongoDB server is available online and if the admin account doesn’t use a strong password.

Ditto to this.

Again, this is somewhat Mongo specific because (a big IME here) MongoDB administrators are not usually at the same level as traditional DBAs. That’s why we’re seeing thousands of MongoDB instances compromised, and no mention of PostgreSQL, Oracle, MySQL, DB2, etc. Sure, this attack is possible with those databases, but they have more sane defaults, and their admins (again, IME) have a better idea of what they’re doing, so it’s not so much an issue there. Yes, now and then you’ll see some idiot leave his Oracle DB exposed, but you don’t see thousands and thousands of Oracle DBs exposed all at once for the same reason.

These “hackers” aren’t doing anything particularly intelligent, only targeting unsecured Mongo instances, so I don’t see where this statement is coming from. If everyone who publicly exposes Mongo to the Internet set the admin password, it sounds like the problem would be solved.

From the context it’s clear that “exposed to the Internet” in that statement is referring specifically to the MongoDB instances using the default setting of no password and no firewall.

I agree with you that it’s really low hanging fruit as far as “hacking” goes. The MongoDB community should be really embarrassed about this.

It seems it’s easy to hyper-inflate the impact or serious skill of a particular culprit behind acts like this. E.g., the Podesta phishing scandal & related events had the momentum of a US Presidential election behind their news cycle, even so it was highly over excitable in its attempt to paint the hacker a Mr. Robot Dark Army type person.

The problem isn’t “oh shit hackers are dangerous” it’s “people should learn fundamental cybersecurity concepts before deploying anything with even remotely identifiable or important information.”

Count me as a cynic, but if you don’t put a password on your internet-connected database administration account… then you can eat a plate of crow and stfu. Wake up tomorrow and start using better security practices. This is natural selection. We must expect and prepare for the worst, not just hope for the best.

As a long time Erlang user, one of the things that’s subtly nice about Elixir is that they fix some of Erlang’s warts. It’s not just the syntax. The string handling is better, for instance.

My least favorite part about Elixir is that it has become a “trendy” language among the web crowd.

Yup agreed, Rails bashing will not get the community anywhere. But becoming popular is not solely a negative thing - for a start, more jobs working with the language have started appearing at long last. It cannot be a successful language without a market for it and it’s very well placed now to take a large percentage of that web market.

As an aside, it’s so nice to be reading properly chained blog posts than trying to read conversational tweetstorms.

I’m kinda sick of the 4 slots the same conversation about Rust is taking up on the front page, especially when none of the articles is really that detailed or informative (barring the original post). Of course, everybody who’s ever heard of Rust is upvoting them (because of course they are, because marketing), but the lack of useful information is kinda a bummer.

1. What even is this question about? :)

2. Yeah a lot of dryers use a gas flame to provide the high heat needed for drying. That’s why it’s important to clean the lint trap, otherwise the pile of lint can catch fire. It’s freaky, but it is what it is.

gist of the post by Ezekiel Buchheit.

For others having the redirect issue.

It worked for me fine, and I don’t have one either.

… and someone else expanded it to include DigitalOcean, Vultr, Linode, OVH, and Scaleway:

https://gist.github.com/justjanne/205cc548148829078d4bf2fd394f50ae