Late 30's entering the dating scene for the first time was a shock. A couple 20-something's outright stating that they won't date "broke-ass" Android users.
Bitch, this flagship costs MORE than your piece of fruit.
PortableApps.com is where I started programming back when I was 11 years old in 2008.
The community completely changed my life. I learned a lot about writing software on forums and the IRC channel from numerous people that were just willing to give advice to a stranger. I'm glad this community is still alive.
I proudly say my first programming language is NSIS. (The Windows scripting language most wrappers on the site are written in.)
… and I proudly say that I saved another generation from having to wrangle with NSIS, and all the copying and pasting of obscure and buggy code that was endemic, by writing the PortableApps.com Launcher!
(I’d probably write the PortableApps.com Launcher in Rust these days, though you’d have to be careful to avoid things like bringing in Unicode tables, and put more effort than usual into shrinking things. Rust has been my favourite language since 2014 now. But I would consider Zig seriously too, though I’m not familiar with it or its Windows API interop. But as with almost all of the developers connected with the PortableApps.com project, once I got a bit older I seldom or never needed it, having a computer of my own, and so drifted away at last.)
My first job circa 2004 was writing an NSIS installer for a long-gone startup in the East Midlands, UK. It was not my first language, but I very much enjoyed it.
As of the date of this document (2013), no. This is technically not legal. The Library of Congress exempted phones from the DCMA but not video game consoles.
I don't believe the ruling has changed since 2015.
> The Register also confirmed that the exemption for gamers should not extend to jailbreaking of console software because such jailbreaking is strongly associated with video game piracy.
> If it doesn't have any absolutely positioned or floating child elements, wouldn't that imply contain: content?
I think the goal is to avoid analyzing child elements at all. So you can layout a given set of children at one layer of the DOM tree at once rather than having to dig deeper into one node to know where to put its sibling.
> And if you add overflow: auto or hidden, wouldn't that infer to contain: strict?
I think browsers would only be able to reasonable infer "contain: strict" on elements with both overflow auto/hidden and fixed width/height.
I'm guessing that "contain: strict" would allow you to avoid defining fixed height and width then? (That was just my first guess. There may be other reasons.)
overflow: hidden/auto does not guarantee that children won't be painted outside of the element's bounds, even if it has a fixed width & height: https://codepen.io/vincentriemer/pen/WNvwpvQ
If you add contain: strict to the container in the above example you'll see that it then successfully clips the child div.
I believe this would eliminate many uses of large list rendering libraries (such as react-virtualized/react-window). That's pretty neat.
The same caveats seem to be present for strict containment mode though. The width/height of a strictly contained element wont't update if its contents change.
3) The browser actually drawing the new state of the DOM/styles
#1 is your JS code. #2 is covered opaquely by React and peers. #3 is traditionally covered opaquely by the web browser.
Those libraries typically focus on optimizing step #1. The OP is a way of giving hints to #3 when that becomes your bottleneck (which is really pretty rare, but when it happens, it's extremely nice to have a recourse).
> For those driving without Autopilot, we registered one accident or crash-like event for every 1.92 million miles driven. By comparison, the National Highway Traffic Safety Administration’s (NHTSA) most recent data shows that in the United States, there is an automobile crash every 492,000 miles. While NHTSA’s data includes accidents that have occurred, our records include accidents as well as near misses (what we are calling crash-like events).
I'm not quite sure what to make of this data. How is it that Tesla cars (without autopilot) are in 4x less accidents than average?
Probably demographics. People who buy Teslas are probably less likely to be in an accident regardless of whether or not they're in a Tesla. Other things might matter too, like lane departure warning and blind spot detection, which would probably lead to less accidents on other newer cars with those features as well
94% of crashes were caused by drivers, 2% by vehicle failures. This implies that the age or state of the vehicle has minimal influence (only the 2% that actually failed) outside of the propensity for older vehicles to have less safety features.
And comparing the new safety features that reduce or mitigate the driver error to those of the average vehicle is exactly the point -- the difference in outcomes is large. This actually matters even across price ranges because people may be willing to pay more for a car if it's more than four times less likely to kill them or their family.
It would be nice to have a comparison separated by class as well (obviously that data would have to come from the government rather than Tesla), but the comparison to the average still has value because it at least informs you whether a more expensive car is worth it.
Would switching lanes into another vehicle be an accident caused by a driver? Blind spot warnings. These safety features do reduce accidents caused by drivers.
> Would switching lanes into another vehicle be an accident caused by a driver? Blind spot warnings. These safety features do reduce accidents caused by drivers.
That's the point.
The comparison to existing vehicles is valuable because the first requirement before someone is interested in a new car is that it be sufficiently better than their existing car. A difference of that magnitude is relevant.
That doesn't negate the point exactly because older vehicles have fewer safety features, and we know that those safety features prevent accidents. Take a look in https://en.wikipedia.org/wiki/Motor_vehicle_fatality_rate_in... and see that the fatality rate has dropped by a factor of 2 in the last 40 years. Features like ABS are a big chunk of that.
In 1982 the fatality rate per 100,000 people was: 18.969, in 2016 it was 11.59. By comparison Drunk driving fell from 9.1 per 100k to 3.3 per 100k in 2016.
As an approximation drunk driving is ~5.8 and everything else is ~1.58. (Clearly some of those non drunk driving related saved lives also saved drunk drivers, but it's still ~3x as important as everything else put together.)
I'd be curious to see if the crash rate is similar to the crash rate of other cars in the same class (BMW, Mercedes, etc). Is it possible that people tend to drive more cautiously in a more expensive car?
It's more like: people who can afford and buy expensive cars tend to be middle-aged, which means they are on the whole (i) more experienced drivers (without being at the stage of their lives where eyesight/hearing/reaction times might be failing without them realising) and (ii) less prone to risky behaviour of any sort vs (say) 16-25 year olds.
In addition, if you can afford an expensive car and choose a Tesla over (say) a sports car, I'd guess that probably means you aren't likely to be an aggressive driver which in turn means lower accident rates.
Probably because when you're off autopilot, Tesla drivers (including me) are much more alert and aware of what's going on compared to a normal car where you have to alert/aware the whole time and in so doing, tend to "zone out" when doing monotonous driving. I tend to use Autopilot for the monotonous driving parts .. and then take over myself if there is something that needs more attention (construction, weather conditions, crazy drivers, etc.)
> I tend to use Autopilot for the monotonous driving parts .. and then take over myself if there is something that needs more attention (construction, weather conditions, crazy drivers, etc.)
To me, this seems to imply that you're not paying attention when Autopilot is engaged.
Well, only if your UI allows dragging two items at once. If you reorder multiple items, well, I suppose you can resolve it by passing some relative position. If you want to squeeze something in-between reordered items, then -1 probably is not a good choice, but more like calculating some middle value between previous and next item.
What would the timestamp represent? Are you providing a timestamp which encodes the position somehow, or using CURRENT_TIMESTAMP? Updating the timestamp for all of the rows in the (sub) list? How does this permit you to reorder the items in the list?
Timestamp would only represent position and enables to put something in between, rather than an integer which adds +1. If put A (timestamp = 100) between B (timestamp = 200) and C (timestamp = 300), just set that order value to middle (150). Naive
It actually looks the same as "What about leaving room?" and, yeah, introduces complexity when you organize items for too long.
There may be other reasons, but here's one. The solution with fractions supports ORDER BY syntax. With the self-referential foreign keys, you would have traverse through from the beginning with multiple queries for that behavior.
It's also a lot harder to query results in order while specifying an offset.
I think one of the first design choices you have to make is: can preceded_by be NULL? The first item in the list has to do something with preceded_by. As a general rule making columns NOT NULL is prefereable; here I declared it NOT NULL, and the first row must reference itself as a result:
nworks=# create table todo (todo_id int primary key, task text, preceded_by int not null references todo (todo_id));
CREATE TABLE
nworks=# insert into todo values(1, 'do homework', 1);
INSERT 0 1
nworks=# insert into todo values(2, 'clean bedroom', 1);
INSERT 0 1
nworks=# insert into todo values(3, 'walk the dog', 2);
INSERT 0 1
nworks=# insert into todo values(4, 'call mom', 3);
INSERT 0 1
nworks=# select * from todo;
todo_id | task | preceded_by
---------+---------------+-------------
1 | do homework | 1
2 | clean bedroom | 1
3 | walk the dog | 2
4 | call mom | 3
(4 rows)
nworks=# update todo set preceded_by = 1 where todo_id = 4; -- call your mother first, it's more important
UPDATE 1
nworks=# select * from todo order by preceded_by;
todo_id | task | preceded_by
---------+---------------+-------------
2 | clean bedroom | 1
1 | do homework | 1
4 | call mom | 1
3 | walk the dog | 2
(4 rows)
I didn't do any operation to fix the sorting order once I updated item #4, so there's more work to do here. I don't think it's a practical solution.
If you’re using a surrogate key in the preceded_by column, you won’t be able to reorder items in the list without updating the relevant keys, which obviates the use of the surrogate key (which is meant to be immutable).
> I feel that this is exactly what web applications try to solve in the first place.
Yeah I think so too but I don't think it really did. Native apps are almost always so much better. The biggest issue is discovery and installation of native applications that make the web more approachable.
I'd love to see some better development frameworks that let me use native UI components to build an application that can share business login across iOS, Android, Windows, Mac OS X and even Linux. It's kind of a hard problem though.
Qt? It's your best shot for native win32/osx/*nix apps, and you can reuse lots of code for the android/ios versions (though you'll have to rewrite the views, of course).
Whoa, I've used Qt an very, very long time ago so I knew of its existence but I had no idea they had iOS and Android ports. I'm going to have to look into that. Thanks!
Yeah I expect re-writing of views. Honestly I think that's unavoidable and perfectly fine it would just be nice to keep the business logic everywhere I go.
It might change things a bit once the watch itself can actually run 3rd party apps. I think it would help sales a lot for Apple to allow the types of face customizations that Android Wear does and to make a ton of commercial faces available from major brands. Google is now starting to do that with Wear.
PS - Good to see you, too. I've been kicking around HN for a while.
