The Dell Precision brand and 3000/5000/7000 series numbers are used for both laptops and desktops.
2,192 karma · joined August 8, 2012
All digital content (premium features, game coins, file storage, music or video libraries) accessible within the app must be charged through Apple, and the user must not be able to find an alternative payment method from within the app.
> EDIT: some research later indicates that it's possible allowing a user to sign up outside the app (and outside a webview initiated by the app) skirts around the policy, since the user can return to the app and log in, then use their account for payments.
Depending on the precise details of your signup page, this may or may not get banned by Apple if they notice it. It's allowed to sign up users and accept external payments outside the app - but then you must not have links to this payment page from within the app. If the user already has an external paid account, then they can use it, but any first-time users must only see IAP or nothing.
Some time ago Apple threatened to ban Dropbox, because they had a webview for signups, and it was possible to upgrade to a premium account within that webview.
Instead of base64, sensible databases and libraries store UUIDs as "base256". Actual binary strings of 128 bits = 16 bytes, not printable ASCII. That is the shortest possible representation, with zero wasted space.
The hexadecimal representation is only used for displaying UUIDs to humans. It doesn't have to be efficient, it has to be helpful.
For UUID version 1, the dashes separate clock, counter and MAC address parts in the data. With hex encoding it is easy to convert to/from binary and for "popular numbers" even to decimal in your head without running it through a baseXX converter.
For UUID version 4, where the data is all completely random, it's less useful. All you can do with it is compare two UUIDs. So there perhaps the human-friendly representation could do without dashes and use a larger base.
A sneakier difference is query latency. RedShift is scalable for queries that scan through very large amounts of data - but there is overhead for each query. One complicated JOIN can be faster than 50 small queries that ORMs and web apps like to make.
Instead, people should start splitting up the monolith into sensible modules and libraries. Instead of a "user accounts microservice", start with a "user accounts library" with a well-documented API that stays in the main codebase and is deployed as part of the rest of the app.
All sorts of business and development process tracking software has existed for decades. JIRA, FogBugz, PivotalTracker, MS Project, and so on.
Trello got rid of 90% of their features, and just kept "list of lists of short text snippets". That makes it great for planning small software projects, but also shopping lists, travel plans, or sales pipelines.
On Android, if you unlock the hidden Developer Options, there is a toggle for "Aggressive WiFi to mobile handover".
But I wonder why the setting is hidden and not a default.
Which is the best selling point of Dropbox. It doesn't try to be an office app suite, a photo editing solution, a cloud collaboration platform, etc. It just syncs files between computers and phones, and has simple UX because of it.
In all patent troll cases I've seen, a patent exists, and the defendant is actually infringing the patent. So there is some merit to the lawsuit.
The problem is that the "inventions" in the patents:
* are not novel, or
* are not non-obvious, or
* have not been described in sufficient detail to replicate without further research, or
* a combination of all of the above for various claims in the patent.
so the patent should never have been issued in the first place. But invalidating the patent in court is a tedious and expensive process. You need many expert witnesses debating what is novel, what is non-obvious, and what is sufficiently detailed, it's not something a judge can decide in 10 minutes.
So why are helicopters still relatively rare, and what is different in a "flying car" that people dream about? It's not 4 tiny wheels after all (and you can get a helicopter with tiny wheels).
* Price: helicopters are expensive to buy, and very expensive to maintain. You need about 1 hour of maintenance for every 10 flight hours.
* Fuel cost: vertical thrust for lift is very energy intensive.
* Difficult to pilot: needs professional training.
* Noise and airspace restrictions: many cities do not allow personal helicopters to fly low or land in urban areas due to noise and fear of accidents.
"Difficult to pilot" is the only area where I see significant possible improvements in the near future, if autopilot gets good enough to remove the pilot altogether.
But there is no obvious engineering breakthrough on the horizon that will improve the maintenance, energy use or noise issues. Maybe if there is a breakthrough in battery technology, then electric helicopters could improve on both the energy and maintenance costs, but that is not really up to people working on "flying cars".
I do the same, 95% of my development with a Macbook Pro with 2 big screens, keyboard and mouse attached. Don't even touch or move it on most days.
A desktop would be much cheaper - but I would still need a decent laptop for the 5% time when I'm not at my desk, so the savings aren't that much any more. And keeping development environments, VMs, config files, keyboard layouts, etc syncronized on two separate computers is too much extra work.
People repair and modify their cars every day - and these are driven on public roads among other drivers and pedestrians. Farm equipment is operated on private property and among workers who are mostly aware of the risks. In the end, if the vehicle is unsafe, the driver is responsible.
There is a major benefit to UUIDs besides server-side scaling concerns: you can generate them offline in mobile apps and other client-side applications.
With serial primary keys, you are often stuck between waiting for a server round trip before saving data locally, or inventing complicated solutions for referring to not-yet-uploaded data locally.
That is often true, but the efficiency comes from competition in a free market, not the ownership of the service provider.
The government usually has a monopoly, so there is little pressure to be efficient other than the personal motivation of some government employees to improve life in their city.
If there are instead 5 service providers who compete for customers, then they are forced to be efficient or lose their business.
But if there is just one commercial company with an effective monopoly - due to mergers between all providers in an area, poorly structured contracts, or plain old corruption - then there is no pressure to be efficient either.
That is a good starting point for calculating the default "optimal UI scaling", but there are going to be adjustments needed for the FoV of the whole screen area (not per pixel) too.
With large screens, for example 24-30" on your desk, just the per-pixel FoV measure will probably be good enough. You have plenty of "space" for windows and content, and want to get the optimal scaling.
But once you get to very small screens like phones, there is a tradeoff between keeping font and UI sizes comfortable, and being able to actually fit enough content on the screen without endless scrolling. I am willing to strain my eyes with smaller font sizes on my phone than on my laptop, just so that I can see more than 5 sentences of text at the same time.
As a bonus, you get a small candy bar or similar "sorry we bothered you" gift if the check does not find any errors.
* It's backed by usual pounds by the treasury, which means only they get to issue new coins (no public mining rewards).
* Court judgements must be able to block, reverse or force transactions. This means either the government gets a copy of all private keys, or simply has master keys for the system.
* UK government would probably want to attach names to all accounts, so new wallets could probably be only generated on some gov.uk site, or participating businesses like existing banks.
In the end, the blockchain is wasteful and inefficient when you could just have a big-ass server somewhere with an API.
A "well-designed monolith's" code architecture would be very similar to microservices - with separated modules, but in-process function calls instead of remote API calls.
If you do large-scale integration tests that cross module boundaries in the monolith, then you should also have the same tests of the full deployment with microservices. If you test each microservice independently, then you could also run tests for each module independently.
If you updated stat() to write 64bit values into a different struct, any existing program calling it with a pointer to an old struct would get garbage data (and a potential buffer overflow).
Renaming the function also makes debugging easier - after statx() is in widespread use, stat() could be replaced with a placeholder that raises the SIGTRAP signal, and immediately detects epoch-unsafe programs still in use.
There already is an app for this, with over a billion existing users: Google Maps.
If you search for directions in London, there's a "ride hire" tab next to public transport. It gives you price estimates for Uber, London official taxis, and Hailo - all booked with a button from Google Maps, never having to open the Uber/Taxi/Hailo app.
I see the "Uber is a bet on self-driving cars" coming up in every discussion about their business plan. But even if that's true, why is there an assumption that Uber would have a monopoly on self-driving cars?
Google, every car manufacturer, and a whole series of startups and universities are working on self-driving technology. If for example Google perfects it first, they will sell licenses to car manufacturers, who in turn will sell cars to Uber, Lyft, and every taxi company in every city of the world. Even if Uber develops the technology first and keeps it to themselves - then others cannot be too far behind, the potential payoff is just too great.
In the end the situation is just the same as now.
> You want to have a model that basically reads old data, but that very aggressively approaches "new data only" in order to avoid the situation where you have basically the exact same tree state, just _represented_ differently.
> That way everything "converges" towards the new format: the only way you can stay on the old format is if you only have old-format objects, and once you have a new-format object all your objects are going to be new format - except for the history.
As soon as there is one new-hash commit in a repo, all users of it will have to upgrade their git client - and that git client will (probably?) default to writing new-hash commits.
Mandatory helmets protect cyclists from injury - but make cycling less popular. Fewer people cycling means they get less exercise and increase other health risks. On average it's a health benefit to cycle without a helmet, compared to driving - and of course people are still welcome to add helmets if they don't mind them.
It is a bit unpolished and still a work in progress, but has some features that are useful for data science workflows that most software build tools do not cover:
* Steps can produce multiple named outputs (for example full.csv and summary.csv), dependency graph can branch in both ways,
* Outputs that are directories with many files,
* Built-in input/output file sharding (for example by date or month) and HDFS support,
* Lots of control over which steps to execute: not just "rebuild target X and any required upstream dependencies". Can select a target and all that depend on it downstream (if you know that a remote file changed), skip rebuilding some steps, etc,
* Can put very short (text processing) scripts directly in the Drakefile in Python, Ruby.
Dispatch via app is a solid improvement over the old phonecalls or street pickup, automatic credit card billing is an improvement over cash, and in cities with shady taxi drivers, GPS tracking is an improvement over potentially hacked taxi meters.
So there is an obviously valuable business model for "taxi dispatch app" here even without a moonshot - just perhaps smaller than Uber's dream of being the only provider of personal transportation in the world.
Like in many technology fields, you have high fixed costs that are distributed over all of your customers, and economies of scale. It is much cheaper for Google to add 10 000 new servers to their datacentres, compared to starting up a new hosting company, building small datacentres on five continents, and rewriting all the software that Google Cloud offers on top of servers.
So seems plausible that a highly concentrated industry with a few big companies each having >10% market share is more efficient (and can offer lower prices) than a market with thousands of small artisanal hosting companies with <0.1% market share.
It is too easy (and satisfying) to prioritise 10 small urgent tasks, complete and check them off, and feel productive. But this can lead to indefinitely postponing long-term important tasks that aren't a top priority for this week on any week.
Tasks like keeping in touch with old friends and new potential clients, learning a new skill, checking that your backup-restore system works, planning a holiday, and so on.
Error detection allows you to:
* Discover and replace bad hardware (like the author of the article),
* Avoid unknowingly using invalid data for calculations or program code,
* Stop using the system and corrupting more data over time,
* Restore files from backup while still in the retention period of your backup service.
I once had a computer with a bad disk that somehow corrupted 1 bit out of about 150MB written, and probably only in some regions. I only found out after the GZip checksum of a very large downloaded file mismatched, and it took a while to figure out the real cause. By that time I had been using it for months, so it's unclear to this day what other files might have been corrupted.