moca

Both Google and Microsoft have published their API design guidelines, which are very much RESTful. Both companies have applied their guidelines to broader set of products at very large scale. At least, we have not seen alternatives that would be applicable or scalable to companies at Google or Microsoft scale.

API design is like UI design or car design or clothes design. It is a form of craft, which does take time and skills. API design is for customers to have best experience, it was never meant to save time or work for the designers.

Disclosure: contributor of Google API Design Guide.

This guide has been in use since 2014, including recently launched Cloud Spanner API.

Disclaimer: co-author of the design guide.

Many Google APIs were created before this guide. New APIs published at https://github.com/googleapis follow this guide. Having the same API available via both REST and gRPC is very valuable, as gRPC often provides 10x performance.

Thanks for the comment. The error handling chapter will be published in a few weeks. For now, you can reference https://github.com/googleapis/googleapis/blob/master/google/....

Disclaimer: I am one of the co-authors.

The proxy is packaged as a docker image, it can run anywhere docker is supported. For performance and convenience, the proxy and the server typically run next to each other, but that is not required.

Have you considered to use a centralized configuration storage (such as S3 and anything else) with access control and audit trail? That is easier to update configs without restarting all the servers.

Agree. If you use any SDK built on top of Application Default Credentials library, it should work automatically and transparently across different environments. The complexity is handled by the library.

[0] https://cloud.google.com/docs/authentication

If we look at how much technologies have advanced over last decades, the economy produces more than enough output for basic needs, which can be distributed to everyone without much burden.

We can simply offer basic income for everyone, then we can get rid of most special rules, such as food stamps, minimum wage, all kinds of deductibles, flexible spending, childcare. We can tax all incomes at fixed rate and be done with it. All these can be trivially tracked by simple computer system, the only thing needed is identify verification once a year or two.

We would have a much greater society and economy, and avoid the need of "job creation like Walmart".

For consumer applications, you are limited by the ecosystems, such Android or iOS or Windows, so you can't choose kernel anyway.

For cloud applications, what is more important is the system architecture, not the kernel. If we assume docker is the preferred way to deploy an app. We only need very limited features from kernel:

- If I specify the CPU and RAM requirements, the kernel simply allocates them to the container. There is no need for complicated dynamic scheduling and balance.

- Network within the same data center has much lower latency than hard disk (<<1ms vs 10ms). We will be much better of using network storage or database.

- If we assign network address to each container, the kernel can deliver network packets to container, and the container uses its own CPU and RAM to process the network traffic. This will avoid the situation that kernel spend a lot of CPU/RAM to process network traffic for all containers and find the correct way to charge the cost.

If we do all above, there is not much kernel features are needed by cloud applications, as such features will be replaced by cloud services like cloud storage/database. It will make develop and deploy cloud services easier and more productive.

A single disk seek takes a few milliseconds. If you need to do any kind of disk verification, it will take longer than a few milliseconds.

I have seen this kind of problems many times in real life. By start writing design doc and prototype code from very beginning, you demonstrate effort and progress. You most likely get hold of the project and eventually deliver it along with all the incremental complexity during the process.

On the other hand, if you spend 2 months iterate through the requirements and alternative design choices, you are far more likely to come up better design, but your manager (or the entire company) would have no patience to watch you thinking in your head. As the result, I have seen software designs could have been 10x or even 1000x better, but most people prefer to get something out first (this is especially necessary for startups).

Another random comment is LoC per day. I worked at a few large companies. The statistics show the residual code is about 6-16 lines of code per business day per software engineer. A lot of time goes into design, debugging, testing, iterations, redesign, refactoring.

SpaceX would drive the product and Google will be a great partner and investor. It is a good match. If Google drive the product, that would raise a lot of concerns across many governments - like EU - as if they didn't have enough problems already.

Your statement is incorrect. HTTP/2 essentially sends HTTP requests/responses through a multiplex channel. The semantics is nearly identical to HTTP/1.1. SPDY has approved it in real world for several years, and many major companies adopted SPDY long time ago (like Amazon Kindle).

HTTP/1.1 is nowhere near simple or elegant. The current spec has 6 RFCs, and a real world implementation is totally non-trivial. RFC1945 is HTTP/1.0, which nobody uses it.

Unless someone proposes an acceptable better solution (Microsoft tried), the world needs to decide on something and move on.

> Bandwidth is cheap.

Bandwidth is just one problem. If you use HTTP/1.1 to download large files, you won't have much problem. If you try to design a memcache-like protocol based on HTTP/1.1, the result will be terrible. You simply can't afford to parse text at 100+k QPS and wait for previous request to finish before sending next one. HTTP/2 is not designed to solve bandwidth issue. It is about latency and throughput in real world.

I have used several Xiaomi products (phone, box, MIUI). I can say their product design and quality are very good. Obviously, they copied hardware design from Apple, but they have proved that they can build high quality products at very low prices, and they are selling phones, tablets, TV boxes, real TVs, earphones, routers. Very few companies in the world can achieve it (Google tried it and didn't go anywhere, remember Nexus Q). It is only matter of time Xiaomi to catch up on their original design capability.

For reference, Smartisan T1 had very good product design. It was done by a English teacher founder with less than $20M funding. All it took was to find a good design firm to help out. While I don't like their copycat, but they are very likely to succeed in the long run.

Among major companies, Apple did a better job with supporting old devices. Google Nexus devices become completely out of date after 2 years (too slow to run latest software, and too hard to get hardware repair support). Software wise, Apple could have done a better job as the newer version of iOS is indeed bloated and doesn't run well on old devices. On the other side, Microsoft did great job on supporting Windows XP for over a decade with wide variety of hardwares.

Java tried green thread since day one in 1995, and it never worked out well and was dropped long time ago (around 2000). Go did a good job with its gorountine at certain cost, for example embed Go library is much harder than C library, so Go application is typically a standalone static binary.

It is really great to see Rust drops the mixture of green and native threads, and reduce the runtime to minimum. It will make Rust stand out in many environment that no other languages would work well (besides C).

Since iPhone 4, iPhone design seems going downhill. With the same display size, iPhone 6+ is much bigger and heavier than LG G3. Its quality is so much better than others, especially on camera and battery life.

Today Alibaba has more sales than eBay and Amazon combined. One important factor was Alibaba had enough capital to outrun competitors, considering it offered free service in its early years and how strong Tencent and Baidu were China. Jack Ma paid the cost to ensure the long term success. I wouldn't consider it is a big mistake, and certainly not early (Yahoo deal came at much later time).

iOS apps use fixed layout, so they can't scale up/down with different display sizes. Since iOS only did double density once so far before iPhone 6 Plus, apps are quite easy to handle it. Android has way more variety, which is a pain for app developers.

Android UI system still uses pixel in many places, such as MotionEvent.getX(). It should just use DIPs everywhere, which would significantly cut coding complexity.

I have worked with Internet services for many years. I think we have missed quite some opportunity to build great web app platform.

For example, we could package web apps in .apk/.jar package, so they can run like native apps without worrying about missing a resource during offline. JS engine can have more freedom optimizing the code and cache the result.

There is no need to install web app like Chrome Web Store does. All we need is bookmarking and implicit app cache (with smart caching policy). Most people don't use more than 100 apps on regular basis, so 1GB app cache is enough for most people. One major mistake with installable web apps like Chrome Web Store is they often come with security permissions, which defeats major value of web, security and privacy.

Offline can be done with smart API design. For example, browser can let web apps create cache files that sit next to cached .apk and share the same lifespan, then web apps can use sqlite to work with such files for storage. It is essentially the same model as Android/iOS native apps. All these can be done without any app install or security permission. The only risk would be you will lose data if an app is purged during offline, therefore it doesn't have chance to sync the state back to server. If you really about data loss, browser can support pinned apps, so they never get purged by caching policy. That pretty much solves the fundamental problem with web app model.

PS: the usability of JavaScript, web APIs and performance are separate issues. That would also need to solved.

TI stopped developing OMAP chip 2 years ago. The natural assumption would be the project was started before that. Due to the complex, it should take more than 2 years for a large company to develop it (startup might do it faster). NOTE: iPhone => iPad also took roughly 2 years, and we all know iPad was started way earlier than that.

The reason is obvious. Moto must have worked on this thing for years, but couldn't make it work well enough. This is the first time that Moto or Google can build something that is marketable. It will take 1-2 generations to be really solid much like Android itself.

In a company like Amazon, only one person can push for such a product, eg Jeff Bezos himself. For whatever reason, he just liked the product idea. Very few people would appreciate such a product as sales number shows. It is just a worse version of New Coke without Classic Coke.

This redesign is for the sake of redesign, or promotion, or nothing. I don't see much, if any, value to a real user. Just waste of time.

It is easy to explain no manual control. Google will include insurance cost into the service itself. If there is any accident, Google's insurance plan will cover it. If there is manual control, the insurance cost will be a mess, since you have to factor in the driving record of the person who is in the car. This alone would be a show stopper.

For those people who complain about $250 annual fee, just think about how much a plain old phone line would cost.

Regarding the $750 hardware cost, if you build 15-way video conference system and sell it with $200 operating margin and one year hardware warranty, good luck if you can hit $750 price point. The price will surely go down over time, but it is way cheaper than anything else on the market.

This is largely a showcase of stupid economy in United States. If you look back past 20 years, there really isn't any meaningful economy growth except the high tech industry. In most cases, you simply higher price for the same house, transportation, education, healthcare, food, lawsuit, and other BS. Instead of encouraging people and companies to do great things that actually improve living quality, the current economic and political system simply drags everything down.

American voters stuck too much with personal values and elect a congress that does not do anything and gets 10% approval rate. Now we have to deal with this kind of stupidity. #thanksobama

Tariffs is a meaningful way to adjust trade balance. Whether it works in specific situation is up to debate. This is similar to how U.S. uses income tax cut/raise to adjust economy growth and deficit, and the result is hard to predict.

As far as I can see, Chinese government has been pretty successful using all kinds of economic tools to manage its growth over past 30 years. Import tariffs is one of the tools. I think it would be fair for US to have some tariffs against China to balance the trade. The real problem is such policy has not political appealing at this time. If raising tariffs help future US businesses to compete against China, since such businesses don't exist today, there is no immediate political or economical return, so it is unlikely to happen.