Fully agreed! A dedicated bike lane that separates riders from car traffic could make riding experience very enjoyable.
I was born in China during the 80s, when biking was the most common way of transportation. The term "Kingdom of Bicycles" [1] was used as a tag line for China in that era. Most roads had bike lanes which could be just as wide as car lanes. Between the lanes are physical separators: 3-4 ft high, made of metal, reliable and heavy-duty [2].
Now I live in the US, and still enjoy biking cause there're nice bike trails near my place. However, most city roads seem not safe for biking. Biking becomes a recreational activity, and no longer a transportation method for me. I appreciate the nicely maintained bike trails, but I hope the city build more physical bike lane separators, not only painted lines on the ground, that can actually stop some reckless drivers entering bike lanes.
We're Constructor customer, and use it to manage our open source projects. It's fast and simple, and does all we want.
In addition to all that, the founding team, esp. Seth, is a hidden feature! Every time I feel our team needs some extra functions, I book a time and talk to Seth. He asks very deep questions about our work flow and pain points. Some of the questions even helped me to reflect on our way of doing things, so we could use the opportunity to evolve.
Has anyone tried to develop anything with MSFT's Fluid Framework [1], which is used to build Loop? I have not got a chance to check details. But it seems quite nice. Any general remarks are welcome.
Particularly, I'm interested in understanding customizability of Fluid components, integration with React, and any concerns about Azure service lock-in.
[1] "The Fluid Framework is a library for building distributed, real-time collaborative web applications using JavaScript or TypeScript." https://github.com/microsoft/FluidFramework
I haven't used it, only read through documentation, but IMO Fluid's problem is not so much lock-in as an embrace of old-school columnar storage and handle-based object manipulation. An experienced Windows developer or game dev might feel entirely at home with the tradeoffs/footguns implied by https://fluidframework.com/docs/build/dds/#picking-the-right... ... but show that to a junior React developer and they're likely to be fundamentally confused, or worse assume that the only code example shown is a valid code example. (People writing documentation: please do not make one of the most prominent code examples in your Getting Started an example of what not to do!). And on the handle front, https://fluidframework.com/docs/build/data-modeling/#using-h... is similarly counterintuitive, to say the least.
Comparatively, I'm much more excited about Automerge https://github.com/automerge/automerge, which promises much friendlier developer ergonomics as simple as:
Contributor Martin Kleppman (of Designing Data-Intensive Applications fame) has great overview slides here: https://martin.kleppmann.com/2021/06/04/craft-conf.html . If anything, Automerge suffers from a "there's multiple ways to have a server backend, including P2P and centralized, and no one right way" anti-lockin problem, which is refreshing and also frustrating for people who just want to try something out. This is a solvable problem though!
I think you have to consider your use case. If you want to build pure online collaboration tool it is fine. But if you want to build something that supports offline collaboration it seems not to be ready yet:
> Clients do have to be connected to the Fluid service. Fluid can tolerate brief network outages and continue operating but eventually the promise of being able to merge local changes weakens. We are investigating ways to improve this using other merging techniques designed to reason over large deltas but no final solution is in place today.
However, what I do like about their approach that they support multiple modern front-end frameworks from React to Vue to Web Components.
Usually projects like this are meant to be used together with Office 365 or for extending Microsoft ecosystem.
Straight from the README, but maybe there are other limitations:
"This project may contain Microsoft trademarks or logos for Microsoft projects, products, or services. Use of these trademarks or logos must follow Microsoft’s Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship."
(Disclosure: Work at Microsoft, but I work in Azure and some open source stuff, not on or directly with Fluid/Office/etc.)
That's just a trademark clause for Microsoft logos and brands. The Fluid Framework itself is MIT licensed [0] and doesn't require exposing any of those logos/brands when you use it, so the framework itself is fairly open for usage.
I think the main thing that would slow down adoption for Fluid is that the only "production" backend is an Azure service, which isn't part of the open source Fluid Framework. Other open source backends[1] aren't recommended for productions. Until there are some open source ones, I'd assume adoption will be limited to folks in the Azure ecosystem.
I don't get your point? Doesn't that just mean if you fork the project you can't imply that it is sponsored by Microsoft? I have seen similar clauses in most open-source projects. This seems even more generous in that they don't demand you remove all the trademarks and logos just that you can't use the logo in a way that implies endorsement.
I am not saying whether you should or should not use this product. My point is that before using such products, you need to read really carefully where and how you can use it this product because of the included resources or intended purpose for using this. It is not sufficient to only read the README file and decide based on that.
The key part here is the second sentence "Use of these trademarks or logos must follow Microsoft’s Trademark & Brand Guidelines.". But there can be other such limitations also, just hidden somewhere else.
I believe, this is how scaling works, and exactly the price we pay to afford the top-notch. In any given field, company, pro sport team, there are top 10% labs/groups/players that matters the most. However, to make the 10% emerge, there has to be a pyramid where the rest 90% is responsible for forming a stable infrastructure. Then it comes down to how well we can design the pyramid. Our result should be evaluated not by how thin we cut down the infrastructure, but how easy we make top-players emerge.
On another note, I have seen small no-name labs published impactful scientific results, and then went back to stealth mode again. It's super cool. Science labs, unlike a business entity, should not be measured by recurrent revenue and growth.
So, usually when people say this about sturgeon's law type stuff, it's because we genuinely don't know how to determine what's crap and what's not overall. For example, if we're talking about 90% of academic papers are crap, ok, it's true, but we pay the cost because we don't apriori which 10% will be the good ones.
The issue is that in academics, we actually have a pretty good idea which programs produce the best and most impactful work. Now it doesn't seem like a cost we have to pay, but rather a conscious decision not to cut out the crap (or to keep funding the crap).
I think the ideal outcome is that the culture and resources of all programs are approximately the same, and each produces 90% crap, and 10% good stuff.
There's a difference between high-impact and high quality. You'd hope that the peer review process selects for high quality and then the impact is TBD by history, but it's usually the other way around.
> On another note, I have seen small no-name labs published impactful scientific results, and then went back to stealth mode again. It's super cool. Science labs, unlike a business entity, should not be measured by recurrent revenue and growth.
Did the individual contributors stay at these labs?
You don't understand the difference btw a research paper and a product launch. A paper is to provide inspiration. In this case, a high ZT p-type crystal may indicate a new mechanism that can be applied to searching / designing new thermoelectric materials. It's not for selling you a working device that can be put in your shopping cart.
(I did research in nano thermoelectrics and published a few papers in this field)
In defense of parent though it does not say “can” or “will” convert. News and views should have reflected that so it’s really not the fault of the original paper authors.
Why learn JS? I guess it’s because I think it’ll be a useful skill that will allow me to do more in the future, not just find a better way to embed 3D models in a notebook.
It might be useful to build tools for research projects, interactive elements for assessment etc.
The bulk of my coding is work Matlab and an increasing amount of Python. JS would allow me to to more web based stuff.
A reasonable request is not to shut all prestigious publishing monopolies down, but to ask/beg/fight them to be less greedy. As you mentioned, publishers run market places and sell distribution channels. They do not need that high margins to run the business. Where the profit goes to? Not the science community, but heir owners and executives high up on the rank who do not contribute much but get the most cash rewards. I believe this is what worth fighting for.
I would go even further and say that these prestigious institutions don't need any execs. They are just a pressure tool for corporate interests. There's no shutting down needed, just dismantling their bureaucracy. If there is one community where self-organizing is genre consensually known to work it's the academic community. There are already tons of fields where this is the case: some top-notch-international and most local conferences and journals alike in CS and math are already being run collegially by universities and unions. As always it's always where there are big corps that thing go awry (looking at you biology and medicine).
---
[1]: https://www.engraved.blog/building-a-virtual-machine-inside/