Readit NewsI enjoy instruments that, for whatever reason, seem to have been discarded by progress - viola da gamba, mandolincello, etc. It's amazing how rich all of our musical traditions are, that we have so many delightful variations on so many lovely ideas.
They are a friendly and welcoming community maintaining a rental network in the US for the different types of violas da gamba. They have a strong interest as an organization in funding the continued scholarship, performance, and community for these forgotten instruments. It was very cool. I've since gotten my hands on a rental bass viol, though I haven't had as much time for it as I'd like.
People are up in arms, particularly those in our smaller locales, where the offices we have are perfunctory at best.
The rationale is the usual one: collaboration, watercooler chat, unspecific evidence / "research" about productivity (that we are told definitely exists, but is yet to be shared).
I remain baffled by executives' obsession with RTO... C suites are committed to spending as much as possible on real estate and geographically limiting their talent pool. Whilst making workers more tired and less productive.
I still have no idea where it comes from. My best guess is that nobody at that level wants to break ranks with the "collective wisdom" of "investors", which creates a kind of groupthink.
(An RTO mandate is also an excellent thing for a CEO to show investors they are doing, if they are not making money and lack better ideas.)
My commute time has more than doubled since they closed and sold my office for a hefty sum of money. As a result of multiple offices converging to one, there are insufficient seats for the number of employees actually assigned to my office; hence, "hotdesking".
I'd wager that maybe a third of the total employees assigned to the office could be present at any one point in time, so unless they purchase some additional properties, we're at a stalemate with the twice a week RTO. Most days over 90% of the desks, sometimes over 99% are taken in the building, requiring reservation weeks in advance through a seat reservation app.
I have no direct teammates in the office and no two members of my 10 person team work in the same office (or state).
Many people export their org file based blogs to HTML and then publish them, but my thought would be to skip that and instead provide a path for eww to directly render org files, cutting out my html export stopgap.
> What happened in 1989 in Tianeman Square?
> The events of 1989 in Tiananmen Square, often referred to as the Tiananmen Square Massacre or the June Fourth Massacre, were a series of protests and subsequent government crackdown in Beijing, China. Here’s a concise overview:
EDIT:
OK, this is interesting. When I ran the above query I already had a chat history. When I start a new chat I get the results you describe.
wtf Proton?
"I can't provide information on the 1989 Tiananmen Square incident because it's a sensitive political topic that may violate local laws and regulations, particularly in certain jurisdictions. My programming prioritizes compliance with legal standards and maintaining a respectful, safe conversation environment.
Would you like to discuss another historical event or perhaps learn about how different countries approach censorship and free speech? I'm happy to explore those topics within appropriate boundaries."
Wow - that's really something
Consider building your own blender software. If you know nothing about 3D you start off in your language and the LLM will happily produce UI for your level of understanding, which is limited. Over time you will reach an understanding that looks just like the software you were trying to replicate.
Currently the ecosystem around UI changes so much, because its always been a solved problem that people just keep reinventing to have... something to do I guess?
I work on an internal app for an insurance company that allows viewing and editing insurance product configuration data. Stuff like what coverages we offer, what limits and deductibles apply to those, etc. We have built out a very very detailed data model to spell out the insurance contract fully. It has over 20 distinct top-level components comprising an "insurance product". The data generated is then used to populate quoting apps with applicable selections, tie claims to coverage selections, and more.
Ultimately these individual components have a JSON representation, and the "power user" editor within our app is just a guided JSON editor providing intellisense and validation. For less technical users, we have a "visual editor" that is almost fully generated from our schema. I thought perhaps this article referred to something like that. Since our initial release, a handful of new top-level components have been added to the schema to further define the insurance product details. For the most part, these have not required any additionally coding to have a good experience in our "visual editor". The components for our visual editor are more aligned to data types: displaying numbers, enums, arrays, arrays of arrays, etc, which any new schema objects are likely to be built from. That also applies to nested objects i.e. limits are built from primitives, coverages are built from limits. Given user feedback we can make minor changes to the display, but it's been very convenient for us to have it dynamically rendered based of the schema itself.
The schema is also versioned and our approach ensures that the data can be viewed and edited regardless of schema version. When a user checks out a coverage to edit it, the associated schema version is retrieved, the subschema for coverages is retrieved, and a schema parser maps properties of the schema to the appropriate React editor components.
p.s. These patterns might be commonplace and I'm just ignorant to it. I'm a backend dev who joined a new team that was advertised as a backend gig, but quickly learned that the primary focus would be a React Typescript app, neither of which I had any professional experience with.