This is the trouble with web dev. There are a million factors in play, and it's very tough to create tests for them all, not to mention potentially financially restrictive with the need for multiple browser testing VMs. You have to test cross-browser, make sure all the versions of IE you want to support play nicely with your JavaScript and CSS. The site also needs to be responsive and handle resizing gracefully. Then how about making your site accessible, making sure all the aria tags are where they should be, and that screen readers will read, or not read, your content properly. When there is time to polish, it's often in the form of CSS transitions or animations.
Making my site fallback to no-js gracefully affects so few people, that it falls by the wayside since there's so many other higher priorities that affect a lot more people.
The parent poster is most likely using a strategy to build web sites called “graceful degradation”, where one builds “fallback” code paths for specific scenarios. The result is something that you see on web sites that have a “desktop” (all features) and a “mobile” (not all features) version.
What the parent poster wrote about testing is only true as long as one chooses “graceful degradation” as the strategy to build web sites. Using the alternative strategy “progressive enhancement” means that one does not have to test as much. The reason is that with “progressive enhancement” the more complex functionality of a web site is built on top of the simpler (think “no JS”) layers.
It may seem counterintuitive, but choosing the right approach to build a web site can save a lot of testing effort – and even make sure that a site displays on browsers one did not even consider.
I chose to get 4 ST4000DM000 drives based on previous reports. Sure HGST drives never die, but it's cheaper to RMA or buy a single new drive if one fails, than the added cost of 4 reliable drives. Assuming only one fails, which is a risk I'm willing to take with my very non-mission-critical data.
I don't read this as 'which drive to buy' but more as 'which drive not to buy'.
Disclaimer: I work at Backblaze. I know you didn't mean that as an absolute, but I just want to point out 100% of drives fail. It's my OCD that makes me point this out. We have NEVER found a drive that lasted forever. There are two types of drives: 1) those that have already failed, and 2) those that are about to fail. For any data you would be annoyed to lose, you need three copies in three locations with three separate vendors (three different pieces of software that don't share any lines of code).
18 disk zpool with three raidz2 vdevs, with 2 disks from 3 different vendors per vdev, bought in two batches per vendor and evenly spread across the case. That's about as paranoid as I consider practical for the homelab/online part of my storage needs.
Also, not sure there are three pieces of storage software that I trust and are readily available to me.
To be somewhat similarly OCD, if your software is controlling storage to each of those drives, then there are many shared LOC involved; indeed, this is the reason why async replication into separate clusters is always recommended for data which can't be lost.
Isn't that along the lines of System 76 [1]? I haven't tried any of their machines, and they aren't exactly trying to compete with Apple, but they are Linux first.
It appears that they are essentially a reseller of Clevo / Sager laptops, though. On the plus side you are guaranteed good support for the hardware using most distros, the build quality looks to be a bit below, say, a Dell XPS, though.
40km per hour of charge time, 9 hours for a full charge.[1] It doesn't look like it has the ability to use superchargers, or charge quickly in any way.
For $750, Bolt buyers can opt for direct-current fast-charging capability via a Combined Charging System (CCS) port. As of September 1, 2016, there were 1061 CCS fast-charging connectors in the United States, versus 2010 Tesla Supercharger hookups. Most CCS stations charge at 50 kilowatts, and Chevrolet claims they can be expected to add 90 miles of range in 30 minutes of charging. Not bad, but that’s roughly half the rate of Tesla’s 120-kW Superchargers, and access to CCS chargers definitely isn’t included in the price of the Bolt.
The biggest drawback for me would be the inability to charge quickly.
With a Tesla you can take it on a road trip, as long you plan it around hitting supercharging stations. In the bolt, you can go 200 miles, but have to stop for the night to grab a full charge.
But if you aren't the type of person to drive more than 4 hours a day, or have an alternative vehicle for longer trips, this could be a great choice.
Before anyone says otherwise, there are already more CCS quick charge locations than there are Tesla Supercharger locations, before the Bolt has even gone on sale. The number grows every day. There were zero Superchargers when Tesla started selling its cars.
Not even close - there are roughly 2x as many SuperChargers as CSS stations. Also, CCS stations are clustered around population centers and not optimized for long road trips. Lastly, CCS charging can't be built in to the purchase price of the Bolt.
As a car driver, I've never taken or wanted to take a long road trip in any car. If it's more than 2 hours away, we fly or take a train. As an EV driver, the DCFC stations in population centers are what's needed. They're what let me drive to the next city over in my Leaf to shop, eat or visit people. The companies building these things are putting them where the demand is.
>>People don't take thousand mile road trips every day
Yes they do. Everyday thousands of tourist drive from BFE to Orlando, it's one of the reasons stretch of I-4 along the attractions is the deadliest in the US (too many tourist that all drive differently).
It may not be common in your region of the world, but it is extremely common in other regions.
And certainly many people routinely drive 200-300 miles or so for a weekend trip--to rural locations that aren't going to have much in the way of charging infrastructure.
If you're going from pretty much any major city to ski areas, mountain hiking, kayaking/canoeing, etc. you can easily be looking at a couple hundred miles or more. You may not do that but it's a very common weekend activity for many people in urban areas.
The challenge with the CCS stations is they are generally only one or two plugs. As CCS cars become more prevalent, they're going to need much larger setups, with 8, 10 or 12 plugs at each station. The wait to quick-charge is bad enough. It would be a lot worse if you had to wait 20 minutes just to get on the charger.
There are only one or two plugs because there are no cars to use them. BMW's sold just 22K i3's to date worldwide. Chevy's sold a few thousand Spark EV's. Tesla and Leaf don't use CCS. Most of the time the chargers sit completely idle. There's no need, nor financial projections to justify, building more CCS plugs per location. The ratio of CCS plugs to CCS-capable cars is probably better than the ratio of Supercharger plugs to Tesla cars. Tesla's locations are the ones known for the lines of waiting cars.
Keep in mind the Bolt hasn't gone on sale yet. Nobody's bought one, there are zero Bolt drivers available to pay money to Blink/CP/NRG that are laying out $50K+ to build each CCS charger. If they've built nearly 900 of them around the nation anyway, on the premise that the cars are coming, think about how fast the network can expand when there are actual cars on the road to justify doing so. Volkswagen is going to dump almost $2 billion into building CCS chargers as part of its settlement for the emissions scandal.
Like all technology, early adopters will suffer "just one or two plugs" for a while... or not, if you're in Pennsylvania like me, and the chargers are unused and available 100% of the time I check Plugshare... so that in a few years, when there are half a million or more EVs on the road... that is, potential customers... we will have created demand that led to those additional plugs being built.
Complaining that there are only 1579 fast charge plugs for the Bolt before it goes on sale is like complaining there weren't enough iPhone docks available before the iPhone came out. The accessories showed up after the customers that can buy them did.
Fair enough. I've seen full J1772 charger stations, but you're right that I haven't seen full CCS stations. As the number of CCS-capable cars increase, we should see improvements in station capacity and reliability.
This post didn't gain much traction, but XSS attacks are still pretty popular and Google awards up to $7500 for XSS attacks[1]. React and Angular may help prevent XSS attacks, and while I don't know specifics, they likely do have some ingrained tools to prevent it occurring. I wouldn't be surprised if a XSS exploit could find a way around client-size sanitization though. In a perfect world, all strings coming from your server would be pre-escaped.
Rails is 'immune' in the sense that it doesn't let you directly drop HTML onto pages from strings without escaping it first, and if you would like to do so, you have to explicitly mark the string as safe[2]. This isn't to say that XSS is no longer an issue though, Rails and other frameworks help prevent these occurrences in many cases in simple applications, but larger scale applications have a lot more code and a lot more ways to punch holes in that protection. In fact using Express with with Node.js doesn't sanitize your strings by default (as far as my quick research has shown), which leaves a potential attack vector.
While XSS is a very well known vector, XSS attacks are not uncommon in non-boilerplate web applications. Fortunately sanitization is easy and bugs can often be fixed quickly.
Browsers can prevent some methods of XSS, such as by preventing loading JS from a remote untrusted source. If you find a way to drop JS directly onto a page that the browser can't catch (such as the entire JS source being delivered by the server), there's still vulnerability.
OWASP tends to be the place to go to learn about web security[3]. They have lots of examples of potential exploits.
> If they can do that, what's to stop somebody else coming along and brute forcing a key for the same hostname.
The .onion URL is created by hashing the public key (and possibly more information), and then it is stored in Tor's database of hidden service descriptors as noted by this[1]. This would indicate to me that if there's a hash conflict, such as the NSA trying to take over FB's .onion URL, the database of hidden service descriptors would reject the duplicate insertion to the database.
He was a ThoughtWorks employee, it only makes sense they made a statement. I work there and they sent a company-wide email saying that they're having a remembrance day for Aaron on the 15th and they're taking time in every office to remember Aaron by discussing his work, his impact on the world, and who he is. This isn't a shameless promotion, this is showing respect for him and honoring his legacy.
not to mention the live townhall meeting done less than a month ago - put together a few days after it was found out that Aaron's trial was going to start on April 1st - organised by ThoughtWorks founder and others to explain Aaron's case and what colleagues worldwide could do to help (indeed I work there too).
Making my site fallback to no-js gracefully affects so few people, that it falls by the wayside since there's so many other higher priorities that affect a lot more people.