This is a huge achievement - props to the Gradle maintainers for delivering so much with such careful adherence to backcompat! I’ve had two enableFeaturePreview lines in my repos for a few weeks now and it made upgrading to Gradle 5.0 a zero manual action upgrade!
Backcompat is important, but even better is using the new features Gradle 5.0 ships with, e.g. the production-ready Gradle Kotlin DSL 1.0 which you can convert to (from Apache Groovy) if you want code completion, error highlighting, and simple refactoring when you write your build DSL's.
We require all teams to use semver and usually define the Conjure API in the same repo as the server that implements it (so they are versioned together). Most of the time teams want to preserve wire-format back compat (i.e. only add optional fields to requests and don’t remove things from responses). Devs are pretty good at this, but we actually run a conjure-backcompat checker as part of CI to catch any unintended breaks they might have missed.
When it comes to intentional breaks, teams save up a bunch of carefully documented changes and then tag the next semver major version (i.e. 2.0.0). This is safe to do because all microservices and frontends we build actually contain embedded minimum and maximum version constraints on the backend services they require. Our deployment infrastructure knows about all these constraints and can then ensure that new major releases will only be rolled out in production when all their callers have explicitly declared support.
The deployment infra constraints mentioned in parent post are generally managed by tooling we also publish[1]. The encoding ends up similar to Helm’s, but happens through this tooling just by virtue of taking a dependency on a published jar, npm package or conda package, and that removes a lot of programmer error/guess work/maintenance. (I think we’d be open to also emitting Helm’s formats in our packaging tools, if that’s interesting to someone reading this feel free to open an issue on our repo and reference my post.)
It's definitely not as elegant as Scala or Haskell, but I think their justification is very reasonable. The current implementation is maximally compatible with existing usages of tagged unions (e.g. Redux actions), because it allows you to choose whatever discriminant you like ('type', 'kind', whatever). Keeping very close to JS seems to be a core tenet of TypeScript and is quite valuable in my opinion. It means they can adopt new ECMAScript syntax without clashes and also ensures that newbies have a smaller learning curve. Also, they can always add in some syntactic sugar later if they want to!
Yeah, the key here is JS-compatibility. Unfortunately, that does mean that TypeScript is sort of a dead end in terms of how far you can go wrt. the fabulousness of your code. (Of course, once everything is statically typed you'll have a much easier time just converting everything to $OTHER_STATICALLY_TYPED_FRONTEND_LANGUAGE, perhaps Scala.js, perhaps PureScript, perhaps js_of_ocaml, perhaps even GHCJS if you're adventurous.
(Aside: I'm moderately disappointed the 'fabulousness' was not in my Chromium's spell checker dictionary. It is now.)
If by «fabulousness» you mean in terms of static typing, the language may not meet your expectations, but it seems to me it's a bit harsh to say it's a dead-end, considering it's on par with many other languages, and still improving.
Also, sorry if you meant something else, «fabulousness» is a very subjective term, not unlike «elegant» (as in «elegant code»), and because it does not have a specific and commonly shared meaning (what is fabulous to you may not by fabulous to others), it's not something I'm very comfortable discussing, although I think I have understood what you meant by it, but with a low level of certainty.
I usually want to keep an eye on my Selenium tests so I can debug them if they get stuck. When I don't have enough space to leave the selenium VNC window open, I put it underneath a semi-transparent terminal window which allows me to keep working.
Nicely comprehensive blog post, Zorium looks like it is the result of a lot of hard work!
Since this looks like a serious library (rather than a personal dev exercise), I'm curious about why you decided not to go with React:
1. The React source is definitely intimidating - what extensions did you feel it needed?
2. Animations are a tough problem, but I was under the impression that the communication isn't usually the problem, it's meshing a declarative representation with a mid-transition DOM. How is the Zorium approach better than the React one?
3. Flux, JSX and mixins are all completely optional and not compulsory to write a frontend in React; why did these motivate you to write a new library from scratch?
I hope these don't come across too critical, I have a lot of respect for anyone who can even finish a project like this, let alone document it. I've heard lots of good things about React, so I'm curious to hear other perspectives!
This is something we considered as the project evolved. Initially Zorium was very different from React, but over time took more ideas from React (some of their work is quite excellent).
1. The biggest difference is definitely the RxJS observable support, which solves a lot of model problems in an elegant way.
2. I wish I had some examples published (we have a few internally), but having RxJS observables actually do a phenomenal job of dealing with the animation problem (think .delay() state and bi-directional communication). I hope to be able to update the docs soon with more details.
3. Aside from those you mentioned, performance was another big problem. React is slow (not as bad as Angular), but more importantly because the code was so complex I was unsure if we could modify it to meet our needs. At Clay.io we push the boundaries of what Mobile-web can do, and performance is absolutely critical. I realize this answer is still sub-par, and I agree, Zorium was mostly build off of Mithril and just happened to look like React in the end.
Edit: It's also worth mentioning that API design (in z.router) and application structure are what took the most time. Because Zorium is built on virtual-dom there isn't really much custom code.
There are a few interesting answers in the 'Startup Traction' topic on Quora [1].
Lots of them mention having a great product that solves a real problem, having a content-rich blog to drive traffic, inviting friends and some PR. (Maybe the friends one isn't so applicable to an ad network!)
Someone got a Linux image that could run `ls` down to 6.12MB by intercepting file accesses and deleting anything unused... See "How I shrunk a Docker image by 98.8%" (https://news.ycombinator.com/item?id=9438323)
It's an overly simple method but a good start. Will work if the dependencies are static and load at runtime. I don't know enough about the tool to say if it works for more dynamic applications.
I was expecting the patent [1] to describe some kind of Amazon Echo, stuffed into a teddy bear with responses and a personality.
Instead, it seems to turn the toy into a glorified TV remote that sends "media device commands to a media device, instructing the media device to change state".
Shame about the click-baity article, I though this had potential for an interesting discussion about AI around children.
I tried the name `~SnapSwap` to actually get into this app. (I found this from a 'Popular Gateways' page [1].)
The blank input field isn't a super friendly way to show people your product if they haven't encountered Ripple before (like myself)... a little blog post about what Ripple is and why you made ledgermonitor would be cool!
