The only problems I’ve ever seen a coworker or myself encounter with docker is not knowing it well enough. Admittedly it has a strong learning curve. There are things that will not work unless you know certain underpinnings of docker, dns/networking, etc. But to say it doesn’t work and goes haywire doesn’t make sense. It’s an extremely stable piece of software.
Coming from someone who probably is your average HN reader (programmer, power user, technically oriented), I've been enjoying Windows 10 more and more. They have put a huge effort into creating a better experience for developers. WSL was a great start, and I'm excited to see what a full Linux kernel will bring. Windows Terminal is in preview and is the terminal emulator that I would want on Windows. I already use VSCode on mac as well.
I disagree. Rigorous code standards are just as necessary on front-end code as back-end. In my experience, no code review, poor design or documentation, and lax standards lead to jittery experiences. For example, people write complex blocking code that causes the page to freeze for moments while that processing is happening. People write event handlers that execute too often and slow user interaction.
My point was though, that such issues can be quickly picked up just by using the application, and you can usually elicit the causal factors by prodding at it. Often times such issues in non-UI code can go for years without it being noticed.
But broadly speaking yes I agree, but one or two of my line managers in the past would not.
While social networks should make improvements to facilitate healthier communication, mean comments and pitchforking is not exclusive to social networks in any way.
If you were on a forum and said a racist comment like the one in the article, if people didn't like it you would probably be put on blast and have ruined your reputation on that forum as well. Difference is that it's not your face. If you feel like it's okay to say racist things, you probably are not going to realize your mistake unless called out by someone.
So to me it seems like social media is just piggybacking on the proclivity of people's desire to be seen and heard.
Except social media is engineered to make everyone a public figure, so you aren't just going to be rebuked by the crowd; your family and employment get targeted.
This is why social networks in their current form are a lousy way of expressing original thought. Even if you don't say things particularly controversial, if they're not in line with the lowest common denominator, the chance you'll see any legitimate engagement is slim.
Forums, on the other hand, are largely anonymous. You'll definitely be put on blast for what you say, but the inherent anonymity helps to deter the angry crowd from shutting down conversation by default. Of course, it depends on who is running the forum. Reddit, as much of a cesspool as parts of it are, is a modern example of how anonymity leads to far more productive conversation than one may ever see on the likes of Facebook or Twitter. Yes, Reddit shuts down subreddits it doesn't like on occasion, but it's overall more hospitable to an exchange of ideas. Good luck having those same conversations on social media, even if you manage to use a pseudonym.
I'm honestly sick of people wanted to be heard. Almost nobody has anything interesting to say. It's all noise for attention. Just like my post here I guess.
That and people being enraged by just about everything. There's a lot in the world to be troubled by, but to always have visceral reactions towards things happening around the world must be taxing on one's health. I don't think a day goes by where I don't see a post by someone making a banal statement about some issue... and I'm supposed to "like" that they've managed to think the same things millions of average Joes and Janes already believe.
People wanting to be heard and feeling part of a community is a basic human need. We receive it in many different ways, and while social media is not always the healthiest way, it is one of them. People become depressed without being heard.
That makes me think a little bit differently about filter bubbles. Filter bubbles aren't new. They're just changing from physical proximity into ideological or emotional response (as best as an algorithm can tell) proximity.
Why is there a limit at all? When you hash the password, it should be a fixed size no matter the password length. Make sure you're not just storing the password on its own.
I recently discovered that some password hashes take time proportional to the length of the password times the number of rounds. E.g. if bcrypt work factor is set to 16 and you have a 1M byte password then the time is proportional to `1000000 * 2^16`
Why it doesn't first hash the password so it's `1000000 + len(hash) * 2^16` is beyond me, and something a crypto expert will have to answer.
In practice this means that setting an arbitrarily high limit on password size would open you up to a DOS attack via (effectively) quadratic time password hashing.
Thank you for that. Note: the trouble is that if you use a password manager it will create arbitrarily long and very secure passwords for you that _far_ exceed what you would expect for a "normal" limit.
5.1.1.2: "Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length." [1]
I use a common password manager and its max generated password length is 64, so it's in agreement with NIST. That said I am able to manually add characters to increase beyond 64.
Yeah, you should be storing the password hashes in the DB, not the passwords. The hashes are going to be the same length regardless of the password's length.
If you wanted to get real fancy, hash the password once on the client side (reducing it to a known length), then again on the server. You should also be using a per-user salt to prevent a rainbow table from being generated if your DB is leaked.
I understand wanting to show off your latest project, but comparing a large framework like Rails to your couple hundred lines of crystal is not an honest comparison, not even taking into account the concerns of startup time as others mentioned.
One thing to consider is that at larger companies, we already have a difficult enough time testing all of our site with JavaScript enabled. Netflix building a version that works without JavaScript is like asking them to build a second website, especially from a QA perspective. When you look at your users and find that .5% of them are not running JavaScript, how do you justify spending the money for that few of people?
The NoScript extension is the 5th most downloaded extension for Firefox (https://addons.mozilla.org/en-US/firefox/extensions/?sort=us...). If you want to show a blank screen or a broken website to those users, that's up to you. Some of them may really want to see your site, so they might try to figure out which of the twenty domains they should enable, and which of the thirty they should enable after that one doesn't help them. Most will likely click on the back icon and see what's next on the list.
Yes, and Firefox is the 3rd of 4th most used browser at less than 10% (which is bad). So the subset of actual Firefox users that use NoScript is absolutely not worth supporting.
How do you know the percentage. Some stuff you may just never know. I very consciously avoid websites I know use a lot of JS or are bloated on mobile. Mostly news websites.
I often read in subway, where I need to load the page in 3-4 seconds or I'm in the tunnel again without the signal. In some stations I only get 50kbit/s or so.
Most websites don't cut it so I don't even bother. Those who cut it though, I get engaged with more, because I can't go anywhere else without a signal.
In a nice world I would write a scrapper + alternate website that hosts only the content and some simple navigation over plain HTML, preferably with as little CSS as possible. There's the annoyance of copyright though, so no way of making this public.
The reason is mobile. While only .5% of your users may be non Javascript users it's highly likely a significant percentage of your users are on mobile and not optimizing for progressive enhancement means a significantly degraded experience for all of them at various times when it fails to load or loads too slowly on a mobile connection.
I can stand slow loads, my phone has wifi after all. But js bloatware doesn't even allow me to scroll without seconds lags and random misclicks due to delayed event dispatch. Me turned js off not because of security concerns, but because most js-only sites are not scrollable beyond the first screen anyway.
To help our (internal) customers better troubleshoot, we're adding HTML responses to our HTTP (web) services. Add a header, a footer, maybe some HATEOS... Starts looking like a barebones web site.
Netflix is one of those sites that makes we want to run noscript. I regularly makes firefox unresponsive and eventually popup a "this script is using too many resources". When a large tech company can't create working javscript for a minimally interactive interface then something is seriously wrong.
Less javascript would be an improvement for everyone, not just the noscript users.
Try doing some automated testing, it'll take care of most of the non-JS testing and a lot of the JS enabled testing as well. Explority testing is another thing, that QA really does need to be involved with, but if you can't test static content without human intervention, you have other problems that are nothing to do with whether you have JS turned on or off.
They can't justify the cost. I wouldn't want them to, anyway. It would mean fewer improvements for their non-crippled site as resources are diverted for the sliver of people who like to be contrarian.
You're probably already thinking this, but in the future don't do a project without a contract. I'd agree with pedalpete that you should take a stand for yourself if he chooses to run anything negative.
