HN user
[ my public key: https://keybase.io/schaedle; my proof: https://keybase.io/schaedle/sigs/VVXPqoVhOGpmKWccDtYNVBfwSA0H1v9dWwiVEnIOSJs ]
The Voyager Company is truly worthy of study if you are at all interested in a vision for hypermedia before the internet.
- Collected media https://the-next.eliterature.org/collections/2
- A catalog introducing this software to a print audience https://archive.org/details/voyager-360-catalog/mode/2upa
Would also recommend https://types.kitlangton.com/ as a companion — sometimes many examples can illustrate the point more succinctly than text.
Both ProseMirror and the newer version of CodeMirror have a pretty elegant solution to this: each modification to the document is modeled as a step that keeps track of indices instead of node/text identities, and uses a data structure called a "position map" that the buffered steps can be mapped through to create steps with updated positions, which are then applied to your document.
In practice, it works quite well. Here's more info:
https://marijnhaverbeke.nl/blog/collaborative-editing.html https://marijnhaverbeke.nl/blog/collaborative-editing-cm.htm...
Github's https://primer.style/product/getting-started/ does a good job of making a cohesive design language that works just as well for server-rendering Ruby views and "upgrading" parts of the ui to React views when you need more interactivity. That's a constraint that I wish more of the Rails ecosystem design tooling would attempt to solve for.
You're not alone. There's been an effort to transparently update the UI to a React implementation over the past year or two, and while I understand the benefits to that approach, they have introduced some flakiness in moving away from a the server-rendered pjax/html-pipeline/simple web components approach that was so cohesive and battle tested over the decade before it.
The convention on desktop and mobile is not to have a submission at all. If you click one of these "mercury" buttons, you can always have up-to-date state.
Forms and submissions are mostly a web convention. I too think that's more natural, but there are a lot of existing contexts like settings where the expectation is that making the selection doesn't require an explicit "save" step.
I'm not very excited about the product itself, but if you are at all interested in spatial computing, it's worth reading through Apple's design and developer resources:
Designing for visionOS - https://developer.apple.com/design/human-interface-guideline...
Inputs: Eyes - https://developer.apple.com/design/human-interface-guideline...
Principles of spatial design - https://developer.apple.com/videos/play/wwdc2023/10072/
Create accessible spatial experiences - https://developer.apple.com/videos/play/wwdc2023/10034/
While I don't think there will be a mass adoption by people willing to put on goggles throughout the day, it's clear that a lot of Apple's ecosystem is being directed toward environmental and situational computing, and the SDK backs that up. Using gaze detection to focus on more than one device in a room, surfacing certain interactions in specific rooms, and low-lag screen mirroring from devices are all pretty high-cost investments that are likely to find uses in other products. I look forward to what kinds of "continuity" type features this tech introduces.
If you have one of the newer magsafe iPhones, you can attach one of these to the wall (front camera) or the back of your monitor (back cameras):
https://www.shopmoment.com/products/wall-mount-for-magsafe/s...
33 years, if you go by the patent. Lots more fun facts in Tim Hunkin's excellent Secret Life of Machines:
https://www.exploratorium.edu/ronh/SLOM/0301-The_FAX_Machine...
For instance, with Diagram Maker, application developers can enhance the experience for end customers by enabling them to intuitively and visually build cloud resources required by cloud services such as Workflow Engines (AWS Step Functions) or Infrastructure as Code (AWS CloudFormation) to get the relationships and hierarchies working.
Does this mean that Step Functions and CloudFormation will adopt this library? Both already have similar visualizations.
I meant it more as a testament to how far you can get with a Rails app before needing to consider using the power tools :^)
I hope to hear more in the future!
Do you envision any extension points to the way engines are implemented that could better enforce boundaries? In our engines, there was nothing that referenced another engine's resources, leaving the main application to handle route mapping and ActiveRecord associations between app models and engine's models.
I feel like the use-case for engines has long been around supporting framework like functionality (Devise, Spree, etc), but I wonder if there are changes to be made that better support modularization for large apps.
A number of years ago, I worked on a team (~20 engineers in total) that successfully carved off two relatively independent portions of a large Rails app using engines. I'm happy to see that Shopify is also using that strategy.
I'm curious to know more what sorts of challenges they have around managing dependencies across engines — I think what we were doing was fairly vanilla Rails, and we didn't have the opportunity to run into those sorts of issues.
Webpack-based projects are heavy. A Rails app comes with a Webpack-based Javascript scaffold out-of-the-box.
I wonder if something like Rollup or NCC could be used to create a single-file Javascript dependency in the general case that is only used for vanilla Webpacker builds, and relying on the individual packages could be something left for when you need to customize the Webpacker build.
Judging by some of the Hey developments, it's possible we could see a much more lightweight JS integration in Rails in the future:
It is worth considering why a government would not have such a law.
I gotta say, the "installing" workflow is pretty opaque and confusing. Why do I need to both authorize GitHub _and_ install a GitHub app? If I elect to only authorize it for specific repos (instead of read/write access to all of my repos), why do I need to install it first for some empty project before GitHub can create the repo for the course I'm trying to access?
Reminds me of some of the excellent advice in Bret Victor's essay about global warming:
http://worrydream.com/ClimateChange/
The investment is not only in the machinery, but in tools to model, observe, and predict efficiency.
It would seem that https://github.com/atom/atom-languageclient is still under active development. Hopefully this means that the core Atom team will continue to work on language server features.
There's https://github.com/google/zoekt which provides a pretty straight-forward and memory-efficient implementation. Their design document goes a bit into what makes it fast:
It's true that macros exist in languages like Nim and Elixir, even C. They either use something more akin to string templates (expanding a macro fills in the holes) or a DSL for manipulating the AST (something new to learn to write code that writes code).
One reason Lispers find macros so beautiful is the simplicity of writing macros using the exact same list processing functions. The code-is-data thing is reinforced through the fact that the AST is one-to-one with the syntax.
Swimming along, sometimes at great speed, sometimes slowly and leisurely, sometimes resting and exchanging ideas, sometimes stopping to sleep, it took them a week to reach Amos's home shore. During that time, they developed a deep admiration for one another. Boris admired the delicacy, the quivering daintiness, the light touch, the small voice, the gemlike radiance of the mouse. Amos admired the bulk, the grandeur, the power, the purpose, the rich voice, and the abounding friendliness of the whale.
It doesn't get much better than William Steig — all of his books give kids the tools and analogs to confront complex emotions and overcome fears. Amos and Boris is my favorite, The Real Thief is excellent if they're a little older.
I for one fully support Musk's efforts to hurl himself into space.
I for one fully support Musk's efforts to hurl himself into space.
It's likely less about meter than flow.
Another compelling use-case of React is the ability to use it as a better templating language ― treating HTML as a data structure instead of a string, better composability of the units of your UI, and the ease of rendering to a string.
It's an interesting question whether the tendency to overcomplicate a largely static site by implementing it as a single-page app should be attributed to the average developer or to the creators of the library though.
http://eloquentjavascript.net/ is another fantastic book in the same vein (and free!).
React is full of declarative code. Something I'd recommend whole-heartedly is Michael Fogus' Functional Javascript book. It shares a lot in common with POODR in that it's conscious of why functional techniques are useful and how to think in a data-oriented way. The book is self-aware of the beginner's mindset in absorbing that information and is very well-layered.
Personally, I feel the best way to learn is by experience and by exposure. By seeing similar code in different contexts, you can learn why React programs tend to rely on certain patterns. To that end, working through something like How To Design Worlds (http://world.cs.brown.edu/1/) or the Elm guide (https://guide.elm-lang.org/) will give you points of comparison that will help you better articulate what you decide to do in React.
I feel like one day I'm going to land on Hacker News and I'll read Team of Ravens Beat Lee Sedol 4-1 in Latest Go Championships
It works!!! Thank you for creating this resource. I'm on the hunt for research around this topic, especially on the various manifestations of Oberon.