kyloon

I can confirm the same experience too (my company uses both AWS and Google Cloud) where most of the human touch points related to startup credits are with the sales team for Google Cloud instead of an account manager (we still don't have one after about a year now) if you manage to get pass their usual generic responses.

Agree on FHIR APIs are becoming ubiquitous especially with Apple Health pushing its adoption in consumer facing applications, not so much on the legacy enterprise side from what I've seen thus far (I work primarily in the clinical trials side of things) and we prototyped our own integration stack to help with wrangling with different standards (more like the lack thereof). It is worth actually building that ourselves in the early days as we have learned so much about the challenges to integrate with our partners and will at some point looking into interoperability partners as we scale.

Also a visualized summary of all the clinical trials conducted by 10 of the largest pharma companies in a digestable format:

https://www.aerodatalab.org/birds-eye-view-of-research-lands... https://www.statnews.com/2019/07/18/clinical-trials-birds-ey...

The scientific process typically involves making inferences and conclusions based on an observation, whereby the result often include biases and in some cases even ill-constructed hypotheses that are caused by assumptions and imperfect information.

One way to reduce 'fraud' and also increase accountability of the individuals and organizations is to secure raw data at its source which the veracity of the data that will be subsequently used to support downstream conclusions can be easily verified and attributed to its source. I'd say a bottom up approach here is more holistic as it incentivizes people to produce high quality research that future work can then be reliably be built on top of.

Love the format and illustration, though I feel having a high-level comparison between different Hyperledger projects (especially Fabric versus Sawtooth) is probably important here. Happy to contribute/collaborate on this.

Faust looks really cool with its native Python implementation. How does this compared with Apache Beam or Google's Dataflow as they have recently rolled out their Python SDK?

One of the core tenets of decentralized applications is the notion of using programmatic models (i.e. smart contracts) to enforce trust between multiple digital entities that maintain relationships that are often adversarial in nature, which are very common in enterprise businesses – think vendor/client relationship where the obligated parties are bound by legal contracts to fulfill a set of predefined responsibilities where the vendor expects a payment for the services provided to the client and the client expects to receive a reasonable quality of the service rendered by the vendor.

This doesn't mean we should put every legal contracts into the blockchain, but rather implementing blockchain-based solutions starting with the lowest hanging fruit problems that will reduce inefficiencies in the short term. The benefits derived from this will then induce a paradigm shift in how we build businesses and applications that can further leverage the benefits of the increased efficiency (capital liquidity, faster/cheaper transactions, etc.), which will eventually give rise to novel business models and use cases that are not possible and fathomable today.

https://www.wired.com/story/how-the-blockchain-is-redefining...

Excellent work. Do you have plans to open source the scripts/implementation details used to reproduce the results? Would be great if others can also validate and repeat the experiment for future software updates (e.g. TensorFlow 1.8) as I expect there will be some performance gain for both TPU and GPU by CUDA and TensorFlow optimizations.

Sidenote: Love the illustrations that accompany most of your blog posts, are they drawn by an in-house artist/designer?

Official announcement from Google: https://developers.googleblog.com/2018/03/tensorrt-integrati...

Basically the finance industry is trying to shoehorn their legacy business systems into blockchain, which of course will not make any advantage obvious other than finding out it is much more difficult to reimplement what is already working with a different system. My view on this is that blockchain ought to find a very specific problem (e.g. trust as a service) that cannot be achieve with existing technology.

Really love what Gusto is working on bringing high quality HR solutions to very early stage startups. It especially helps with reducing toil on the founders trying to figure out how to run a company for the first time, as well as bridging the expectations for employees that are used to more sophisticated HR systems in large companies.

It is also important to tease out if the demand is actually because of pricing your product too low which can sometimes be perceived as achieving product-market fit. Nothing wrong with that if cost efficiency is what you are trying to solve, but in most cases this is a sign of underestimating the true value of the product.

This is great news, was just wondering when TensorFlow would support this after reading about PyTorch.

It is probably transfer learning has become more of a technique used for training neural network models (such as Adam being one of the most commonly used optimizer) whereas most of the excitement stems from new and/or complex neural network architectures rather than the technique or tools that made training those neural networks possible.

This is amazing news as using Keras is my opinion the best way to start building models in TensorFlow for most people (and also having support for Theano is definitely a plus).

In terms of deploying trained models, you can probably get away with using TensorFlow Serving and let Kubernetes handle the orchestration and scaling part of the job. I do agree that there is certainly a need to have a tool that glues all these different bits and pieces together for improving the process of taking a model from development to production.

Thanks for the update. Most of the queries I am testing now are 'mean' and 'group by' aggregation for downsampling and visualization in Grafana. Looks like the problem is CPU bound as I see all 8 cores got maxed out when processing the queries. Currently there are about 50 series and 5B data points in total.

I had another go at this new release after failing to get any of the 0.9.x releases to suit my use case of massively high volume writes. Now that I managed to get some of my data in it, aggregation queries seem to be lagging in speed, I would like to know more about what is actually being done currently to improve the query speed rather than waiting out for the v0.11 release as I am deciding whether InfluxDB is the way forward for my use case.

This reminds me of MapD (http://www.mapd.com), though I am not sure which database MapD builds their stuffs on.

It would be interesting if there is an intentional hidden vulnerability within the code that NSA could use as a backdoor into companies that end up implementing the tool into their system.

I concur, the entire Opal/Tcard fiasco is already a good example of how things are done by the NSW Government.