Mozilla unveils Apps Marketplace for Developers next year, - <AUTHOR> http://technozooo.com/2012/02/mozilla-unveils-apps-marketplace-for-developers-next-year-submissions-opening-upcoming-days/ ozilla, a not for profit company devoted to placing the energy of the Web in peoples' arms and fingers, these days declared that the Mozilla Industry will start for designers to publish Web applications at Cellular Community The summit. By developing on start Web technological innovation like HTML5... <comment><USER2> This is fantastic. I've always been enticed by the idea of selling apps for mobile platforms, but I knew it would mean setting the time aside to learn either Java or Objective C with some proficiency before I could make anything worthy of sale. The ability to construct an 'app' using the same languages and tools that I use to make sites is an incredible boon.

I can't wait until selling HTML5 apps is commonplace. We have the Chrome store already, and soon we will even be able to make Windows 8 apps in HTML5 (albeit with IE9, but still!). I think a solid contender from Mozilla will also be necessary for paid HTML5 apps to become a reality. With the major browser vendors all backing this concept we have a great chance of it becoming not only a reality, but a profitable alternative to selling native apps.

</comment><comment><USER3> The author is either a robot or speaks English as a second language. There are a ton of factual inaccuracies that aren't present in the linked source material.

</comment><comment><USER4> Official blog post: [http://blog.mozilla.com/blog/2012/02/22/mozilla- marketplace-...](http://blog.mozilla.com/blog/2012/02/22/mozilla-marketplace- opening-for-app-submissions-soon/)

</comment><comment><USER5> This is a step... albeit in the wrong direction. There shouldn't be one Marketplace per browser/OS. We have the power to make a single unified marketplace, why don't we. As a developer, I don't want to maintain an HTML5 app, and then have to submit it to 10 different marketplaces with 10 different codes of conduct with 10 different formats.

<comment><USER6> Agreed, and though you've not said specifically, this is what also bothers me about some of the "Software Center" type features (e.g. Linux Mint and Ubuntu).

Can we not agree to have a store-like repository/front-end available for all distros? e.g. Have one entry point where developers can submit source/apps; set the distros supported/unsupported; go through some kind of community approval process.

It's definitely not a small feat, but I think it would prove to be more helpful for _everyone_ than these per device/browser/OS markets.

</comment></comment><comment><USER7> > next year

The article itself says "later this year", so I assume that is wrong.</comment>


Common Mistakes To Avoid When Starting As A Freelance Developer - <AUTHOR> http://freelancersassistant.com/common-mistakes-avoid-starting-freelance-developer/

<comment><USER2> In general, and especially for people freelancing in Germany, I'd add: Not getting a tax consultant.

I'm pretty sure this is the same everywhere, but regardless, it's the first thing I tell people which they have to get in order so they don't get screwed later on. ;)</comment>


Wuhan coronavirus may remain contagious even after recovery from illness - <AUTHOR> https://www.nejm.org/doi/full/10.1056/NEJMc2001468 <comment><USER2> This is about the most f'd up thing I can think of. What is China going to do with all the people who got it and recovered?

<comment><USER3> As I understand it, this reportis saying the infected person was infecting others before that infected person even showed symptoms themselves.

<comment><AUTHOR> A pre-symptomatic contagious period is pretty widely acknowledged at this point I think. The bigger worry is that people may continue to spread it even after they have recovered:

> The fact that asymptomatic persons are potential sources of 2019-nCoV > infection may warrant a reassessment of transmission dynamics of the current > outbreak. In this context, the detection of 2019-nCoV and a high sputum > viral load in a convalescent patient (Patient 1) arouse concern about > prolonged shedding of 2019-nCoV after recovery. Yet, the viability of > 2019-nCoV detected on qRT-PCR in this patient remains to be proved by means > of viral culture.

<comment><USER3> Oh dear. Yeah missed that—sure hope is not true.</comment></comment></comment></comment>


gRPC-Web: Moving past REST+JSON towards type-safe Web APIs - <AUTHOR> https://spatialos.improbable.io/games/grpc-web-moving-past-restjson-towards-type-safe-web-apis#hn <comment><USER2> I first saw this one a few weeks ago, and have been trying to weigh up its pros and cons over GraphQL (my tool of choice).

gRPC-Web:

* Speaks protocol buffers, a fast and compact format compared to JSON

* Allows clients to use the same APIs as backend services.

GraphQL:

* Enables a client-centric view of the system. I have abstractions in my GraphQL server that only make sense to clients. It's a query-centric implementation of the Backend-for-frontend pattern, where the owners of the service are also the consumers.

* Enables an entire UI's requirements to be fetched in one go (or optionally split up, if some content is less important). To achieve the same level of aggregation performance in gRPC would require building something analogous to GraphQL.

The other benefits of gRPC-Web outlined in the article (generating typescript bindings) are equally possible with GraphQL (Relay Modern generates flow types, and is probably just one pull request from supporting TypeScript too)

The status code standardisation only makes sense for single-purpose endpoints/calls, once you're dealing with aggregations, the semantics of a downstream status code will vary depending on the use case the query fulfills.

I think both solutions have use cases, and can even happily co-exist. I don't believe gRPC-Web to be as much of a game-changer as GraphQL, but for certain scenarios (needing to rapidly fetch streams of data that don't have cross- dependencies) I can definitely see the benefits of a solution based on gRPC.

<comment><USER3> > Speaks protocol buffers, a fast and compact format compared to JSON

This is definitely important at Google-scale, but for the rest of us compressed JSON typically isn't that bad.

<comment><USER4> If your users access your website from their phones, the latency and CPU benefits of proto become important for them.

</comment></comment></comment><comment><USER5> I don't understand this, to be honest. What does type safety have to do with serialization formats or application protocols? I've used Servant (Haskell) to define the REST API for my backend, which gives me type safety, server stubs and generated client code for free. In my view, type safety is about what you internally use to represent your API, and has nothing at all to do with the underlying protocol(s). There's nothing about REST+JSON that prevents type safety, as far as I'm aware.

I plan to switch to protobuf3 for the serialization format, since this offers both a JSON and binary representation. Why would I want to choose gRPC+proto3 over REST+proto3?

<comment><USER6> > There's nothing about REST+JSON that prevents type safety, as far as I'm > aware.

Well, except for the fact that JSON is pretty much untyped? I don't understand what there is to not get. If you want type safe RPC you have to use an RPC system that at least _has types_! What stops me sending `{ name: 12, age: "Hello"}` to your JSON RPC system?

<comment><USER7> JSON is just a serialization format. Everything you send over the wire is just a bunch of bytes, including JSON and protobuf. JSON has types, and you can use it with a typed RPC system just fine. Whether or not clients can deserialize something you send them can't be known statically, even with protobuf.

> What stops me sending `{ name: 12, age: "Hello"}` to your JSON RPC system?

Nothing. And the same applies to a typed RPC. You don't have to use the typed client. Or you could be using an old version, or it could be misconfigured, etc. You can enforce schema on the server and client side, but you'll never really know if it works statically, since you don't compile and deploy the server and client atomically.

<comment><USER8> Yes you don't have the guarantees of statically compiled/linked code but the entire point of using protobufs is that if you use the generated interfaces, you'll end up with fast binary serialization/de-serialization with type safety. That's a lot better than just using JSON. Which is very verbose.

You could of course make your own protocol and type system and use JSON for transmission. Why bother when this is done for you and is likely going to have the best adoption when it comes to interface definition languages like protobuf or Thrift.

<comment><USER7> I agree, I love protobuf and JSONSchema and Thrift, I think they're great ideas that solve important problems.

But the hype is getting carried away--they aren't a silver bullet for distributed systems, they're just a way to manage schema. Define a schema in an IDL, and Protobuf/Thrift/whatever generate schema validators and serializer/deserializers for clients and servers. But they are not type safe across systems, and that they compile doesn't imply anything about whether they will actually work at runtime.

<comment><USER9> Sure, and gRPC doesn't guarantee that the server is turned on when the client makes a request. Some expectations are unreasonable.

On the other hand, if you publish one set of proto files and all clients & servers consume these artifacts, the system as a whole is more "typesafe" and reliable than if you just post swagger docs and expect all your developers to check them daily for updates.

gRPC means API changes stand a good chance of getting caught by build systems. That seems about as reasonable a definition of "type safe across systems" as can be expected.

<comment><USER7> I agree completely which is why I love proto.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> The reference implementation of gRPC on github[0] has 998 open issues and 215 open pull requests. Every time I've tried to use this package I have encountered a previously-reported issue which has remained unfixed for months.

If you need to interact with Google platform it's hard to avoid using gRPC, since many "official" libraries seem to be migrating towards this library, while it remains fragile and bug-ridden. My "days since gRPC problem" counter is currently on "2", after hitting an issue which /crashed my python interpreter/ and required altering apache config to workaround[1].

[0] [https://github.com/grpc/grpc/issues](https://github.com/grpc/grpc/issues)

[1] [https://github.com/grpc/grpc/issues/9223](https://github.com/grpc/grpc/issues/9223)

<comment><USER11> It is worth pointing out that the Python implementation is particularly bad. Perhaps gRPC is really pleasant to use with Java and Go, but the Python implementation is neither usable nor stable enough for it to be worth considering its use for one's own services.

<comment><USER12> My instinct would be that it'll be just inherently nicer to use in a statically-typed language.

<comment><USER11> Python can be statically typed.

</comment></comment></comment></comment><comment><USER13> I think I like gRPC, but have several reservations regarding replacing REST with it. REST web services often return multiple mime formats, not just pure structured data. Some services return images, others return HTML, and then you also have cache... Maybe I just don't know enough about gRPC, but I can already imagine many people passing images around as byte arrays inside protocol buffers and when we look back, we have reinvented SOAP, which reinvented Corba.

<comment><USER14> gRPC generates rpc server and client stubs based off a protocol buffer definition. Saying it's a replacement for REST makes little sense since it's possible to define a REST API within it. It's also possible to write a totally not RESTful API in a modern http api framework.

In fact that's what Google's API design guide does. Encourages RESTful API design then describes how to implement them using proto and gRPC.

The more interesting tradeoffs are proto vs json or other and how this restricts message patterns to request/response (rather than pub/sub or push/pull)

<comment><USER13> Interesting! When I first looked at gRPC I missed the option(google.api.http). Are you aware of the reason why REST mapped gRPC is not possible in GAE (http 1 only on the server end of our code)?

<comment><USER15> There's actually a stand-alone proxy that translates the REST mappings of `google.api.http` into gRPC requests. It relies on code-generation: [https://github.com/grpc-ecosystem/grpc-gateway](https://github.com/grpc- ecosystem/grpc-gateway)

This has been the way we've been shipping our REST services until now, but the need to recompile the proxy was a major hinderence to our development speed. Hence gRPC-Web implementation.

</comment></comment></comment></comment><comment><USER16> Stub generation? Remote access protocols? CORBA all over again?

So, now I know the next big thing. Portable distributed objects. :-P

<comment><USER17> CORBA tried to make remote calls look local. Making them look remote (and potentially even making some local calls look remote) is a very different design principle that leaks through almost every bit of the standard, and definitely leaks through to every bit of the implementation.

<comment><USER18> It's funny to complain about CORBA's local/remote muddling in 2017 when we have moved on to microservices that also talk to each other locally with TCP/IP.

</comment></comment></comment><comment><USER19> Everything old is new again, except tunnelled over HTTP.

<comment><USER20> You mean like SOAP?

<comment><USER21> Like CORBA, EJB, RMI, and a pile of other rpc libs and specs that died over the past 40 years.

</comment></comment></comment><comment><USER22> Another hammer to a multifaceted problem, keep in mind that people have a lot of different use cases where JSON REST API's are the lesser evil.

I only skipped through the spec for gRPC, but the protocol seems very limited. I dont like the 'gRPC status codes', where HTTP status codes at least can be grouped in ranges.

The abstraction from the technology/protocol should not be the issue compared to the abstraction from the core business logic. When handling multiple consumers, customers and technologies I tend to worry more about where logic is handled and where data is stored, compared to how its transferred.

</comment><comment><USER23> REST + JSON is simple, easy to debug, and it does the job. Web clients speak JSON, servers speak JSON, humans can read JSON usually. JSON can be gzipped so you get some benefit there.

gRPC is another large pile of foreign C code that's essentially a black box. If there is a buffer overflow there that your code hits only somehow, you'd have to know how to debug it and fix it.

Also chances are you are not Google, Facebook or Amazon , and you don't really do BigData just your know, regular data.

<comment><USER24>
       and it does the job.

It does _some_ jobs admirably. Because of the tooling and familiarity, it's often asked to do other jobs, and here the results are decidedly mixed.

</comment></comment><comment><USER25> Just saw this during the morning reading. Without a deep dive, this looks very promising. We have recently been moving to k8s and grpc for our node work and the last piece was how to get to the browser. If this ties it all as one straight protocol from db to browser it will be very welcome and could not have come at a better time. We were evaluating the alternative (GraphQL etc) but our experiences with node and grpc have been excellent so far.

Immediate evaluation planned.

<comment><USER15> That sounds very much what we're doing, except our microservice stack is in Go. For nodeJS you probably want to front your pods with grpcwebproxy ([https://github.com/improbable-eng/grpc- web/tree/master/go/gr...](https://github.com/improbable-eng/grpc- web/tree/master/go/grpcwebproxy))

If you hit any snafus, please file bug reports in [https://github.com/improbable-eng/grpc-web](https://github.com/improbable- eng/grpc-web) We're happy to help :)

<comment><USER25> Much thanks. I'll add it to the immediate list.

</comment></comment></comment><comment><USER26> The title ("by Google and Improbable") is a bit misleading since it implies a collaboration between the two, when it's actually Improbable's own implementation that they released ahead of Google's pending spec.

<comment><USER15> One of the authors here.

This is indeed our own implementation of the pending spec. We are in touch with the gRPC team to make sure that their (still unreleased) implementation is cross-tested with ours.

The benefit of our implementaiton is a relatively light-weight client-side lib for Typescript and >=ES5, and a "ready-to-go" Go middleware.

</comment></comment><comment><USER27> Unless I need high throughput, I am sticking with JSON Rest as it's good enough for most things and easier to debug by sticking a proxy in the middle or using ngrep.

</comment><comment><USER28> This kind of stuff couldn't happen soon enough. REST is so arbitrary and less than useful for building UIs. It's just bad.

I've got Relay talking to a GraphQL service built in graphql-java which then talks to a gRPC service layer. The gRPC service layer is a great fit for GraphQL. Some type safety all around, but there could always be more. And there could always be less JSON. Please, no more JSON. The only thing it's good for is debug logging.

</comment><comment><USER29> I'm using my own gRPC services and Google's speech recognition gRPC API and I absolutely love it. Protobuf/types, generated code, clear API contract.

</comment><comment><USER30> I'm not sure why you need to modify your serialization or protocol to get type safety.

I've been using NSwag ([https://github.com/NSwag/NSwag](https://github.com/NSwag/NSwag)) to generate TypeScript clients from .ASP.NET controllers and it works great. It can generate TypeScript request/response handlers, and interfaces or classes for any public facing models.

</comment><comment><USER31> Wikipedia: [https://en.wikipedia.org/wiki/GRPC](https://en.wikipedia.org/wiki/GRPC)

Src: [https://github.com/grpc](https://github.com/grpc)

Docs: [http://www.grpc.io/docs/](http://www.grpc.io/docs/)

</comment><comment><USER32> Personally I'd prefer a promise based api. eg. stub.QueryBooks(qbr).then(...)

A benefit of grpc coming to the web means someone will inevitably build a tool to parse a .proto file and generate a ui to test your microservices during dev. That will be cool.

<comment><USER33> Not exactly a promise, but grpc has an asynchronous API.

</comment></comment><comment><USER34> I acknowledge it could just be me and the specific projects I worked on, but I've never been encumbered by an API style. RPC, Rest, GraphQL, I almost find them all to simply differ in syntax.

I've managed to solve all my use cases using all three with equal effort, time and with comparable outcomes.

There's value in compression and faster serialization/deserializarion formats when and only when micro-performance becomes an issue. Other then that, I think programmers spend way too much time debating over these, where I don't see any one of them providing an ROI advantage over the others.

<comment><USER2> REST (in the pure sense) vs RPC is a valid comparison, but GraphQL solves a different problem. GraphQL is an alternative to other gateway API or backend- for-frontend solutions.

The benefits of a gateway API to both developers AND users are hugely significant. These are decidedly NOT micro-optimisation.

<comment><USER34> What's a gateway API? I acknowledge, I don't do a lot of frontend work. As I see it, GraphQL is just a query syntax that uses a JSON like language and where the query engine is built in code on the backend. You could replace all queries by REST requests, or build your own query language on top of JSON or RPC.

In my experience though, anything approaching a query language was too expressive for an API, and it was better to offer one API per query, and encapsulate the queries on the backend themselves.

<comment><USER2> Gateway APIs: [http://microservices.io/patterns/apigateway.html](http://microservices.io/patterns/apigateway.html)

Assuming you've read that then I'd add the following. If you don't have _something_ approaching a gateway, you're probably doing a big disservice to your users (assuming clients fetch data via API, rather than using a traditional render-on-the-server framework like Django or Rails).

The value proposition of GraphQL is based on the assumption you're already doing things right by users, and its possible to fulfill the data requirements for a single page or app screen in a single API call. What this probably means is:

* You have a custom endpoint per screen

* That endpoint to either a) be versioned or b) support as many historical versions of your app as are in production

* You might have a gateway per client (this is the full backend-for-frontend pattern)

* Every time you add functionality, or change existing functionality, you're adding to what quickly becomes a huge set of endpoints

What GraphQL promises (and delivers on) is the ability to get all the benefits of the backend-for-frontend pattern, without anyone ever having to write an endpoint specifically for a give client use case. The clients convert their data requirements into a query, and the GraphQL server returns the exact data you need, no more, no less. It requires some discipline when it comes to evolving the schema over time, but it works really really well. And when implemented intelligently has comparable performance to hand-crafted endpoints (I've written about how to approach this here: [https://dev- blog.apollodata.com/optimizing-your-graphql-requ...](https://dev- blog.apollodata.com/optimizing-your-graphql-request-waterfalls-7c3f3360b051))

When you experience the front-end workflow of using a library like Relay or Apollo (both are GraphQL clients) and having perfect synchronisation with UI and data, it's a really magical moment. You end up in a world where you can just get on with building UI, it's amazing.

</comment></comment></comment></comment><comment><USER35> Don't forget to protect against malicious user input! There are both pros/cons for 'non-human-readable' in the security department for sure.

 _Finding a $5,000 Google Maps XSS by fiddling with Protobuf_ | [https://news.ycombinator.com/item?id=13829925](https://news.ycombinator.com/item?id=13829925)

<comment><USER36> You can easily write an extension to in-browser Dev Tools to show human- friendly representation of any binary protocol for development/debugging purpose.

<comment><USER35> Nice. Are you aware of any Chrome extension for decoding Flash's 'application/x-amf' Action Message Format like Burp, Charles, and this Firefox extension do?

[https://addons.mozilla.org/en-US/firefox/addon/amf- explorer/](https://addons.mozilla.org/en-US/firefox/addon/amf-explorer/)

<comment><USER36> Nope, sorry! But Firefox addons will be soon switching to extension format compatible with Chrome, so you might get it for "free."

</comment></comment></comment></comment><comment><USER37> There is a reason why more and more people left RPC and use REST.

And for me "the next big thing" is something like GraphQL.

<comment><USER32> Imo it was mainly poor language / framework support for asynchronicity. That's not really an issue anymore.

<comment><USER38> So how is the modern way to work around issues like network partitions, servers not responding, going off and on on network connections, duplicate answers,....?

<comment> vertex-four Futures-oriented programming - helped by the "async" or "generators" support in quite a few modern languages. Wrap timeouts and retries around everything, and process the timeout errors accordingly.

RPC doesn't mean that a remote function call looks exactly like a local one. That was a mistake. Modern RPC systems return composable futures which make it trivial to do timeouts and retries, send off many requests at once and wait for all/some of them to return, and so on and so forth.

If you're doing something that shouldn't happen more than once, generate a transaction ID to identify it by.

</comment></comment></comment></comment><comment><USER39> One cautionary tale is to avoid generating code that exists at run time with Typescript. We managed to cause a severe page load regression for a while by generating Typescript for each DbObject and Projection (similar to a persistent GraphQL query).

My advice is to only generate types and interfaces if possible.

</comment><comment><USER40> There is also Google's own implementation of this that has been in the works for some time. See [https://github.com/grpc/grpc/issues/8682](https://github.com/grpc/grpc/issues/8682)

<comment><USER15> Yea, we actually work closely with the gRPC-Web team at Google to make sure our implementations are interoperable and we have plans for cross-integration- testing.

<comment><USER40> Awesome, thanks for sharing this.

</comment></comment></comment><comment><USER41> It is still a bit shocking to see how many people are not getting the distinction between an API and a RESTful service.

They are very different things and they have very different goals. The hint is in: how much do you value the client?

If you have full control over both client/server or if we don't care about any 3rd party developing a client library for your service, then go with something like GraphQL or gRPC or SOAP with a nice, typed spec you can generate your code from and optimize the heck out of the bytes coming through the tubes.

If OTOH you have an interest to create a RESTful service that is discoverable, that doesn't require constant client changes, that offer a wider variety of resource representations, that need to stand the test of time, then use HATEOAS and a RESTful architectural style.

gRPC is yet another ... RPC. Nothing good or bad about that. Just make sure you understand the consequences.

</comment><comment><USER42> But I always thought speaking HTTP with a server can be considered RPC. We can pack our message in XML, JSON, or whatever serialization we choose, passes on to the destination, unmarshall, do something, return.

</comment><comment><USER43> RPC has its own set of limitations, which if your application qualifies, might be a good fit:

* Coupled server and client. gRPC uses protocol buffers which have zero backwards compatibility.

* Zero discoverability. The client knows in advance what the server can do.

* No standards to follow. You make up your own specs, like Google did.

These constraints are orthogonal to REST, the architectural principles behind the web. What they're doing is tunneling RPC over the web, which is what most HTTP APIs are doing already. There are only superficial differences like the use of protobuf, lack of verbs and URIs, etc.

<comment><USER43> I made a small mistake in the first point, got downvoted to oblivion and people seemed to stop reading there: the binary serialization indeed has backwards and forwards compatibility. However, the textual serialization lacks this compatibility. I can't remember a petty detail of a vendor specification apparently. Pedants with encyclopedic knowledge of Google are out in full force today!

I should have stopped at "coupled server and client", the point is that they both rely on an agreed upon external schema since the messages are not self- descriptive.

<comment><USER44> Honestly: The other points are not better if your intention was to make grpc look worse than other HTTP based APIs:

\- For all of them you need to know the remote addresses (IP/hostname, port) upfront or use an external service discovery solution.

\- For both you can implement some service introspection, which delivers you a list of available services/methods. Afaik for grpc there even exists some standardized introspection mechanism. For other HTTP APIs you might want to download some swagger description from a well-known address. Or WSDL scheme. Or GraphQL schema.

\- Standards on which layer? On transport layer you are following the HTTP standard, independent of whether you are using grpc, GraphQL, json-rpc or some handmade REST API. On application layer you are mostly on your own anyway, there's not a lot things one could standardize. There are some exceptions, like the standardization of Webdav on top of HTTP, but most applications have their own specific set of requirements. If we are talking about standardization without meaning offical-standardization, then we can argue that grpc provides a more rigid (standardized) model for an application than the definition of some ad-hoc APIs: It is standardized how APIs and exchanged data types are defined (.proto files), how they can be accessed and how data is transferred over the wire (mapping to HTTP). All of that without the application developers on both sides needing to care for it.

<comment><USER43> Actually gRPC is about the same as other HTTP based APIs, it is just a more efficient RPC. All of them are lacking what made the web scalable in the first place.

\- HTTP APIs are worse than websites of the 90s. At least a browser could be expected to view a few websites. HTTP APIs require a custom client for each one.

\- Document media types, not APIs. This isn't such a novel concept, browsers (fancy HTTP clients) work because HTML is a standard.

\- Standards at the application layer, not specifications. You mentioned specs only.

Let me just clarify that RPC is a great fit if you are constrained to a single vendor and don't care about third-party clients. On the web, every browser is a third-party. For HTTP APIs to take off, they need to be built more like websites, or else vendor specs will fill every niche.

<comment><USER4> I don't understand your point about third-party clients. APIs defined in .proto files can have both clients and servers implemented by anybody.

<comment><USER43> APIs defined in XMLRPC, CORBA, SOAP, et al, can have clients and servers implemented by anybody.

Programmers don't seem to learn from history and struggle with thinking over time. These formats worked well in a time when a single party (or second party) controls the server and client, when services were very consolidated. Now that the web is becoming more and more centralized and closed, it follows that RPC is making a comeback: widespread interoperability is not much of a concern.

<comment><USER4> Sorry but you're not addressing your own point:

> RPC is a great fit if you are constrained to a single vendor and don't care > about third-party clients

If I'm not constrained to a single vendor, and care about third-party clients, what makes RPC a bad fit? In specifics, not vague historical comparisons.

</comment></comment></comment></comment></comment></comment></comment><comment><USER45> Is this SOAP 2.0 ?

</comment><comment><USER6> They sure do like spikes... whatever that means.

<comment><USER46> "A spike is a product-testing method that is used to determine how much work will be required to solve or work around a software issue." [1]

[1] [https://en.wikipedia.org/wiki/Spike_(software_development)](https://en.wikipedia.org/wiki/Spike_\(software_development\))

<comment><USER6> Ah, agile mumbo-jumbo.

</comment></comment></comment><comment><USER47> Scalakka devops represent!

</comment><comment><USER48> why not emulate an RPC using webpack?</comment>


Ask HN: Do people actually make money writing their own stock trading bots? - <AUTHOR> I read a lot about people writing their own stock trading bots. Do people actually make money that way or is that just a hobby? Anyone point me towards more reading?<p>I should clarify I mean individuals, not large corporations. <comment><USER2> I built a rather simplistic bitcoin trading bot for myself a year or so ago using a hacked together exponential EMA script. Did ok, turned $2.5k to about $10k, paid off a car loan with the profits after tax. It was definitely a hobby and I'm pretty sure I was extremely lucky. It felt like I was playing with monopoly money at the time so there was no stress.

Also, this is interesting... [https://www.udacity.com/course/machine-learning- for-trading-...](https://www.udacity.com/course/machine-learning-for-trading-- ud501)</comment>


Cell Phone Technology Should Have Been Available After WWII - <AUTHOR> https://medium.com/datadriveninvestor/cell-phone-technology-should-have-been-introduced-after-wwii-e3adcc4f79e4 <comment><USER2> Years ago I read several books by L. Neil Smith, a noted libertarian SF author. His North American Confederacy series posited that if the early US had been really libertarian (changing the Declaration of Independence to "derive their just power from the _unanimous_ consent of the governed") then technology and social rights would have been far in advance of what actually happened.

(Eg, peaceful end to slavery in 1820, Moon colonies by the 1940s.)

This comes across as the same sort of libertarian fantasy.

Let's consider "the 37 year incubation of the cell phone".

As [https://en.wikipedia.org/wiki/History_of_mobile_phones#The_c...](https://en.wikipedia.org/wiki/History_of_mobile_phones#The_cellular_concept) points out, there was more than just the proposal from the 1940s in order to get cell phones:

> At this stage, the technology to implement these ideas did not exist, nor > had the frequencies been allocated ...

> In all these early examples, a mobile phone had to stay within the coverage > area serviced by one base station throughout the phone call, i.e. there was > no continuity of service as the phones moved through several cell areas. The > concepts of frequency reuse and handoff, as well as a number of other > concepts that formed the basis of modern cell phone technology, were > described in the late 1960s, in papers by Frenkiel and Porter.

Which means the "handie-talkies" were far different than what we think of now for cellular technology.

The article argues that frequency allocation was the main issue, with fierce resistance by the TV broadcast industry for changing the allocation, and with internal inertia preventing new technology development.

To counter-balance that argument, we need only look outside the US. Again, from Wikipedia at [https://en.wikipedia.org/wiki/History_of_mobile_phones#Emerg...](https://en.wikipedia.org/wiki/History_of_mobile_phones#Emergence_of_automated_services) :

> The first fully automated mobile phone system for vehicles was launched in > Sweden in 1956. Named MTA (Mobiltelefonisystem A), ... MTA phones consisted > of vacuum tubes and relays, and weighed 40 kilograms (88 lb). In 1962, an > upgraded version called Mobile System B (MTB) was introduced. This was a > push-button telephone, and used transistors and DTMF signaling to improve > its operational reliability. In 1971 the MTD version was launched, opening > for several different brands of equipment and gaining commercial success. > ...

> In 1958 development began on a similar system for motorists in the USSR ...

> One of the first successful public commercial mobile phone networks was the > ARP network in Finland, launched in 1971. ...

(Not bad for the 'innovation famine' of Europe, eh?)

So there were multiple attempts, in multiple regulatory regimes. If cell phones were simple enough that we "should" have had them shortly after WWII, then it would have been done elsewhere.

Which to me strongly suggests that the explanation given here is too facile.</comment>


Lyft is ceasing scooter operations in six cities and laying off 20 employees - <AUTHOR> https://techcrunch.com/2019/11/14/lyft-is-ceasing-scooter-operations-in-six-cities-and-laying-off-20-employees/ <comment><USER2> It makes sense and I'm actually surprised more micromobility providers haven't pulled out of less-profitable markets already. There's so much competition in the space because the barrier to entry is quite low, leading to unit economics only making sense if a city is both 1) friendly to scooters in terms of regulations, and 2) an ideal use case for scooters in terms of density, weather, and demographics.

It will also get worse if gig economy workers get classified as employees in more markets since chargers might fall under that category, bumping up the operating costs quite a bit.

<comment><USER3> Lyft and Uber bought the scooters and bikes to kill them.

They're almost as good as driverless taxis. The only occupant of a bike or scooter is the passenger. Obviously they're not the same thing technologically but when a passenger chooses a scooter or bike there is no driver to pay, so it's economically very similar.

Jump could get you anywhere in the city, it outcompeted rideshare. Uber literally doubled the price and stopped maintaining the fleet, it is in their interest to kill it. Lyft scooters like all scooters have an intense enemy action (vandalism) problem so I'm less confident it's an embrace-extend- extinguish play. But how else could you rationalize wrecking a platform cheaper, more efficient and more convenient than cars that _eliminates the driver_?

Drivers are not at all competitive with micro mobility.

<comment><USER4> Strongly agree... I see they are pulling out of PHX.

With Lyft scooters _everywhere_ in Scottsdale Old Town where'd the' day launched this past spring, I was consistently able to get door to door from hotel to stores within ~2-3 miles in half the time on scooters vs. the latency of waiting for a car to show up.

Since the area is one giant strip mall, most trips I had finished my errand and come back on scooter before an Uber or Lyft would have 'completed prior ride' and eventually found its badly navigated Waze to me.

Local press reports how visitors love the scooters, locals (with cars) hated seeing them everywhere:

 _"Electric scooters aim to solve the last-mile problem—those gaps between public-transit stops and a person's final destination. Some locals consider them a nuisance, but for travelers, they offer a new sense of possibility."_

[https://apple.news/Arr73LXB6RK-ECfAnzZixSw](https://apple.news/Arr73LXB6RK- ECfAnzZixSw)

</comment></comment></comment><comment><USER5> I rode all sorts of scooters in San Diego (That city is just filled to the brim with scooters). Lyft's were the best by far. Easy to use app (already use it for car rides everywhere else) and the best hardware, those scooters are by far the fastest and smoothest compared to lime and bird.

</comment><comment><USER6> I'm a big fan of micromobility but I see scooters and the eletrics being better to own than to rent. They're much smaller than a bike, and can be carried on a bus to handle the last 1-5 miles between a bus stop and the destination in urban areas.

<comment><USER7> Counterpoint, I'd much rather rent than own. I don't have to worry about charging it, dragging it inside (and associated street scum), maintenance, battery lifetimes.

To paraphrase Eazy-E, "throw it in the gutter and go buy another" is the best route. Walk down the street and pick one of the dozens of scooters on the sidewalk.

<comment><USER8> The problem is that at current costs, you would have to pay close to $8 per ride for renting to break even for firms. And at that point you might as well get a lyft/uber.

<comment><USER9> And it's pretty worry free, just plug it in when you're not using it and stick it next to your desk or front door or something. They're not very big, and only the small wheels really get dirty, so it's really quite reasonable to own. If something breaks, you could throw it out and buy a new one for less than renting, and you don't need to worry about paying per use or finding a scooter if you're in an odd part of town. And if it gets stolen, go back to renting until a new one is delivered. Or keep two so you can ride with a friend occasionally and never worry about being out of a scooter for a couple days if one breaks or gets stolen.

<comment><USER7> These are all things that take more effort than just renting. Not everything in life is an economics decision.

</comment></comment></comment></comment></comment><comment><USER10> People may enjoy this piece on micromobility from Monday Note: [https://mondaynote.com/the-micromobility- mirage-a814e6e126be](https://mondaynote.com/the-micromobility- mirage-a814e6e126be)

</comment><comment><USER11> Bikes in the bay are next.

<comment><USER12> I'm curious to see the path to profitability for Uber and Lyft's multi-modal strategies (scooters, biking). Right now it's a land grab, but I'm unconvinced the land is worth more than the purchase price. Perhaps it's valuable as part of a larger strategy but I have my doubts those bike trips are profitable on their own.

<comment><USER13> They don't need to make the scooters profitable — they just need to make sure that the scooters don't displace Uber and Lyft rides. They just need to make sure the scooters are crappy, broken, and annoying to get the world to turn against scooters and stick with Uber and Lyft rides.

<comment><USER14> Given how non-motor vehicle unfriendly most roads are in the U.S., I don't see scooters take off in most places any time soon, even if managed as well as humanly possible.

</comment></comment></comment></comment><comment><USER15> Wtf is "micromobility"? That is some gross jargon. This stuff needs to stop.

<comment><USER16> Anything too far for walking and too close/annoying for car/public transports. What people used to own bikes for, but now, thanks to capitalism, you can endlessly spend money on inferior options and never own one, yay! Double yay! if you live in Europe and all that money is going to foreign companies which don't pay local taxes.</comment></comment>


Ask HN: How to open source game code, not assets - <AUTHOR>

I'd like to make a game I am working on available as open source. However I'd like to prevent people from re-using the game's artwork for other projects. There are also assets I do not control, for instance fonts. How can I host the entire game publicly while licensing things appropriately? <comment><USER2> There's the possibility that you may have to provide a code repository without the art assets. The code will be available to browse and adapt, but people won't be able to build and run a working game from it. I recall Id distributed some of their games this way--you had to go buy a retail copy to get the WAD files to actually play the game.

Otherwise, you'll have to rely on documentation that explicitly states which files are available under what licenses, and trust people to behave. This may not be an option for assets that you do not actually own.

A middle route might be to provide public-domain low-fidelity placeholder assets along with the FOSS version. If you are able to build a community around your project, you might get them to build these assets for you.

<comment><AUTHOR> Thanks, I may go this route. I was hoping to have a single repository... Perhaps I can find some way to automate the construction of the public repo so that non-open files are stripped.

</comment></comment><comment><USER3> While I appreciate the sentiment all you have to do is look at the huge numbers of ripoffs in the world (Particularly prevalent in IOS / Android) to see that your artwork will be stolen no matter what you do.

As for the font stuff you may not be allowed to post it anyway as it would count as redistribution. You will need to check the licenses for those.

the next question is why do you want to open-source it? If it is for teaching purposes for others you could replace the fonts with free/libre ones and replace your art assets with low resolution versions.

<comment><AUTHOR> Thanks for your input. On the matter of artwork being stolen on some level I am prepared for that in any case, as I know how easy it is to decompile a game and access the artwork. In this game the game is written with JavaScript / HTML5 and the artwork will be even easier to steal in production...

As for why open source, I thought it would be interesting for others to be able to browse and learn from the source code. Perhaps even contribute changes -- though that's likely a pipedream. Maintaining a separate open repository with separate assets may be the way to go, but means more work for me.</comment></comment>


Massive RedHat Perl performance issue - <AUTHOR> http://blog.vipul.net/2008/08/24/redhat-perl-what-a-tragedy/

<comment><USER2> One issue worth pointing out is that this slots nicely into the various "Why should we have to learn C?" discussions that pop up here from time to time.

This is why. Eventually, something dumb will happen inside your tools, and you'll need to figure it out. Blind faith in any of the software you rely on is bad, you need to know how it works. And to first approximation, all the software you rely on is written in C.

<comment><USER3> I don't disagree but diagnosing this particular problem didn't require knowing any C, just the perl profiler and another perl build.

<comment><USER2> Only if by "diagnosing" you mean "lucking out and finding a pre-existing bugzilla entry on the problem". Someone earlier had to identify the problem and crawl through the RH patch sets looking for it. The author, who doesn't want to think beyond perl, was stuck without this. Not everyone is so lucky.

<comment><USER3> Uh, no. Diving in to C was unnecessary to solve this problem any way you slice it. In fact, it would have been the most inefficient way to figure out that another perl build was needed.

</comment></comment></comment></comment><comment><USER4> They caused an order of magnitude slowdown without hitting the disk? That's impressive.

Apple totally fucked sqlite for awhile (it may still be, I compile from source now) by doing a full filesystem flush (not fsync) on every commit:

[http://adiumx.com/pipermail/adium- devl_adiumx.com/2008-April...](http://adiumx.com/pipermail/adium- devl_adiumx.com/2008-April/004823.html)

There was a (crazy-talk) rationale for it, though: fsync wasn't thought to be "reliable" enough, so the order-of-magnitude slowdown was for our own good. Doubt bless() really "needed" the slowdown for RHEL.

<comment><USER5> From the fsync man page on OS X 10.5:

         Fsync() causes all modified data and attributes of fildes to be moved to
         a permanent storage device.  This normally results in all in-core modi-
         fied copies of buffers for the associated file to be written to a disk.

         Note that while fsync() will flush all data from the host to the drive
         (i.e. the "permanent storage device"), the drive itself may not physi-
         cally write the data to the platters for quite some time and it may be
         written in an out-of-order sequence.

         Specifically, if the drive loses power or the OS crashes, the application
         may find that only some or none of their data was written.  The disk
         drive may also re-order the data so that later writes may be present,
         while earlier writes are not.

         This is not a theoretical edge case.  This scenario is easily reproduced
         with real world workloads and drive power failures.

It's still Apple's fault on some level (after all, they control everything from the fsync implementation to the hard drives they choose to ship in Apple hardware) but from the perspective of the guy configuring sqlite, the full filesystem sync makes sense.

</comment></comment><comment><USER6> This is a great example of why it's important to actually determine the root cause of a performance problem before making any decisions about how to fix it. Performance problems are very often something stupid and not at all what you would expect.

<comment><USER7> But I have to wonder how RedHat is compiling the packages. A few years ago I was bit with this, when the system supplied regex library I was linking against (I was writing a C program) was actually slower than a shell script with 20 greps in a pipe (<http://boston.conman.org/2003/01/12.1>). This took quite a while to track down and even then I found it hard to understand what RedHat did when compiling the library in question.

Way to go, RedHat!

<comment><USER8> It's pretty easy to find out by pulling down one of their srpms, or by looking at fedora cvs. Why don't you do that?

</comment></comment></comment><comment><USER9> I've found that a good practice for building systems is not to rely on the software that comes with the OS for the specific task the system is being built for. When I can I always build task specific software from source, not because the software with the OS is bad always, but because building from source gives you a lot more control over the software (compile time features, paths, etc). And you can also typically get a more recent release of the software when building from source since it doesn't have to go through the OS vendor.

<comment><USER10> This seems like a good idea on the surface, but it has some pretty serious negative consequences.

When you need to replicate your environment, you now have to build all of the custom bits exactly as they are on the production system, rather than simply running "yum install perl foo bar baz". Depending on the length of your dependency chain, and the dependency chain of all of those components, this could be incredibly time consuming, even _if_ you don't make any mistakes in the building process. Building a binary tarball of all the stuff you need is an option, but then compatibility issues with existing system libs and such are bound to happen, and that's pretty ugly from a paths and upgrades perspective.

You also make your environment less standard. A new hire is going to have to learn not only your application, but also all the crazy town details about your particular and very specific deployment (and setup their own copy of it on their own system). If everything except your app comes from OS-standard packages, you can expect someone familiar with RHEL/CentOS or Debian/Ubuntu or whatever OS you use to know where most things are right off the bat.

You'll probably do more things wrong with your build than the OS vendor did with theirs. In my business, I see a lot of custom PHP builds, for example, and almost every single one of them is broken in more than minor ways (and we end up hearing about it, and trying to figure out what they did wrong in their build). Your OS vendor version has a _lot_ of people banging on their builds and reporting bugs. I'd pretty much always bet that their build is better than yours from a reliability perspective.

It makes it harder to replicate your deployment, if something catastrophic happens to your production box. Packages are more resilient to library changes and such than a big ball of crud tarball of your binary builds. And you won't want to spend several hours rebuilding on the new target machine while you're offline. A complete system backup could be restored...I dunno if you've ever done that on a remote system before, I assure you it is non-trivial and stressful.

What I would instead recommend is to find out which components you need custom (I'm not denying that sometimes you really do need, for example, perl 5.10 and the OS has 5.8.8--it happens, and that's fine), and build new packages int he native format and dump them into a yum or apt repository. It takes an extra day or two, if you don't already know how to do it, but it'll save you many many times that amount of time in the future--and those hours in the future might be far more stressful hours than while you're first setting things up. Rebuilding a package from SRPM or a deb source bundle is usually pretty easy...bumping revisions in dramatic ways might not be trivial, but recompiling with specific options is no problem at all. And, one can usually find a source package of the latest and greatest in the devel branch of the OS, which makes even major revision bumps easy (though, because it is the devel branch, you're probably giving up some maturity in the package...far fewer testers on the devel versions).

<comment><USER9> I agree, if you don't know what you are doing then you can screw things up pretty good by building things from source. Although harder, you can still also screw things up installing software from OS vendors. Both approaches require care. I've found build/deployment automation and documentation to be the things that address most of the problems highlighted here. There's a lot of cool software out there in this area that helps. Building task specific software from source is definitely worth it, you've just got to know what you are doing.

</comment></comment></comment><comment><AUTHOR> The weird thing is, that open source vendors - for all their talk - are almost as bad as the closed source ones. Atleast there's a build from source solution, though.

<comment><USER11> Sure, but with open source vendors, you can fix it yourself if it's broken, and it's important enough. That's the essential difference.

All vendors suck to different degrees. Nothing ever works perfectly. Open source gives you the ability to do something if the suckiness affects you, though. With closed source, you're stuck until the vendor gets around to your bug. With larger vendors, this may take forever.

<comment><USER12> Also, you have transparency in what you are running, which is important from a rights perspective.</comment></comment></comment>