fro0116

I keep checking out Wire every once in a while because I _want_ to use it, but as far as I'm concerned, it's not truly multi-device in a useful way because new devices will not be see conversation history: https://support.wire.com/hc/en-us/articles/206998259-Why-can...

I was excited to hear they introduced history backup & restore a while ago, but to my dismay it doesn't work across platforms: https://support.wire.com/hc/en-us/articles/360000775549-How-...

> History can only be restored from a backup of the same platform. You will need a fresh login to restore your history from a backup.

So you can't for instance make a backup of your history on web and restore it on Android, or vice versa. Nor does it support automatically making encrypted backups to cloud storage, which makes the history backup & restore feature rather useless for my purposes.

In addition, just now, when I logged back into my wire account, I see the message "You haven’t used this device for a while. Some messages may not appear here." in place of where my actual messages should have been displayed, which is absolutely maddening, and there doesn't seem to be any interest in addressing the issue: https://github.com/wireapp/wire-desktop/issues/655

TL;DR: Wire is simply unable to handle message history in a sane manner. And that's a shame because I love pretty much every other aspect of Wire, but broken message history is a complete deal breaker as far as I'm concerned.

I don't disagree with the point you're trying to make, but I'm not sure if USB is the best example to make that point.

Case in point: when I used a USB DAC with my NUC there's an intermittent electrical noise that's actually quite audible and distracting (even when nothing is playing). I ended up switching to another cheap DAC that accepts optical input, and the noise completely disappeared. I'm not entirely sure what caused the electrical noise to begin with, but that it existed means there's some potential for USB to mess with the audio signal.

Well said. I'd wholeheartedly recommend anyone learning React to try manually converting a component written in JSX syntax into a bunch of React.createElement calls. The exercise itself is really easy and mechanical, but I find it very enlightening nontheless.

What people coming from a templating background often consider as "quirks" of JSX (such as the limitations around conditional branching and why properties need to be camelCase rather than kebab-case) become painfully self-evident after seeing how the equivalent JSX code would look like in the plain JS React.createElement form.

In fact, in my own projects I often prefer to import createElement, alias it as something short and use it directly to write rendering functions over using JSX because I find it removes a lot of the impedance mismatch involved with switching back and forth between JSX's psuedo html syntax and regular JS syntax in JSX expressions (and basically any other part of the codebase that's all written in JS). Plus, JSX syntax is actually generally _more_ verbose than the raw createElement calls when aliased due to things like requiring named closing tags for any component that takes children and needing to use `blah={blah}` over the `blah,` object property shorthand for passing through props.

Though in team settings I still resort to begrudgingly writing JSX because people are more familiar with it, and I'd probably have to pick a fight with every new team member to get them onboard with the idea, and I'd rather spend that political capital on less superficial issues.

I sometimes really wish the React folks never invented JSX, and just forced everyone to write createElement calls to begin with, then all of these points of confusion from people coming from templates could have been avoided (and we'd end up with only my preferred syntax as the one true way to write components, haha), but I do wonder if React would have taken off as it did if it didn't come with JSX to give people that sense of familiarity, even if it ends up causing much more undue confusion over the long term.

Curious if you could point to some solution for building apps outside of the web ecosystem that doesn't have this impedance mismatch you're talking about?

Pretty much all of the UI frameworks on any platform that I personally know of use some combination of an XML-based templating system for laying out components and a programming language to implement the logic behind those components, which is fairly analogous to how the web has HTML for templating and JS for implementing logic. Perhaps the impedance mismatch you're talking about lies in how the web handles styling, i.e. CSS itself and how it's not integrated into either the templating or the logic side like certain other frameworks but is rather a separate independent piece altogether?

Just trying to understand where you're coming from, because in my view React itself _is_ already a powerful abstraction over the DOM (in React you write components, and rendering those components to the DOM is an implementation detail involving an entirely separate library, react-dom, which can be seamlessly swapped with libraries dealing with the implementation detail of rendering to other targets like react-native, react-canvas, react-sketchapp, etc), and CSS-in-JS in the React ecosystem is itself a powerful abstraction over CSS for implementing styling as a function of state (though this abstraction hasn't yet been taken advantage of quite as much, the only notable exception I know of being glamorous-native, which implements glamorous's style as a function of state pattern on top of react-native's Stylesheet primitive rather than on top of CSS).

Apollo CLI isn't even coupled to Apollo Client though. You can use it to generate types for any graphql query as long as you can also provide a schema for it to infer types from.

The first thing that popped in my head was also how this compares to Apollo CLI's type generation (https://github.com/apollographql/apollo-tooling, formerly apollo-codegen).

On a cursory glance, it seems like with this tool, you write a JS object in the same shape as the query, manually specifying the type of each field in that object, and then it generates the query for you to pass to graphql clients, as well as the types associated with the result of that query for you to use in your app. Whereas with Apollo's codegen, you write the query in graphql syntax, then run a CLI command to generate the types associated with that query for you to import and use.

It seems with this tool, you'd still have to manually state the type of each field (when that information can be perfectly inferred from the schema as demonstrated by Apollo's codegen), and you'd lose the ability to take advantage of tools that work with the graphql syntax to provide things like autocomplete based on your graphql schema while you're writing the query itself (https://github.com/apollographql/vscode-graphql, for instance). Unfortunately I'm not yet able see any benefits you'd get over Apollo's codegen in return. Happy to be enlightened if I'm missing anything.

I'm not as well educated on these events as I'd like to be. Can anyone point to some unbiased (as much as possible) sources on what charges the Huawei CFO was arrested for, and what charges the Canadians in China were arrested for?

On the face of it the arrests read like blatent retaliation from China, but I'd like to know more about the full circumstances.

I don't see how this is relevant to the discussion at hand. I don't recall seeing any mention of the US in the above comments. Nor any connotations suggesting that it was OK for America to do the same.

Even if this wasn't completely off-topic, I'd still recommend reading up on whataboutism to understand why this post was not making a substantive argument: https://en.wikipedia.org/wiki/Whataboutism

Going to have to disagree with the comment on CSS-in-JS.

CSS-in-JS is one of my favorite parts of the React ecosystem. Style as a function of state is such a natural extension to React's programming model that I end up cringing a bit every time I have to go back to writing a bunch of different classes and applying them conditionally. Representing styles as data also means you have the full power of JavaScript at your disposal to compose and manipulate styles (not to mention access to a proper module system), whereas with plain CSS you're limited to a handful of mixins offered by whatever post-processor you choose, and those in turn are generally limited in terms of expressiveness themselves by nature of only being able to perform simple string interpolations, since that's the format they have to deal with.

I think these benefits are analogous to the benefits of HTML-in-JS a la JSX over traditional JS-in-HTML templates. I'm honestly struggling to see why someone would prefer HTML-in-JS but not CSS-in-JS.

My only major pain point working with flexbox have been gutters. With flexbox, implementing gutters often involves some kind of hack involving negative margins, which is both inelegant and can sometime result in strange layout issues in my expereince.

For instance, if you want to render a dynamic list of items that wraps if the number of items don't fit in 1 row using flexbox, and want to add equal vertical spacing to each row _only when the list wraps_ (i.e. without introducing any extra spacing on the first row), you'd need to add a margin-top to every item and then add a negative margin-top to the flex container to counteract that extra margin.

I originally found out about this trick in this StackOverflow question: https://stackoverflow.com/a/30891910. I'd love to be enlightened if anyone know of a better way of implementing this using flexbox.

Similarly, adding gutters for horizontal spacing between columns involves adding 1/2 the gutter width as margins to each item on both sides, and then setting negative margins of 1/2 the gutter width on both sides of the container.

With grid, we can simply set the row-gap and column-gap properties on the grid container without any additional ceremony.

Microsoft actually has this nifty thing meant for IT admins called App-V, that allows you to create immutable application packages that execute in an isolated environment where changes made to the local system default to copy-on-write and are redirected to a centralized location (including both filesystem changes and registry changes).

It's actually been integrated into Windows 10 Enterprise edition for quite a while now, and I personally use it to package up a lot of the apps I use on a daily basis, delivering the packages through a network drive and synchronizing the centralized state store with Syncthing for mostly seamless cross-device roaming. (You can download the App-V Sequencer from the Windows 10 ADK to package some apps to try it out for yourself, if you happen to have a copy of Windows 10 Enterprise: https://docs.microsoft.com/en-us/windows-hardware/get-starte...)

This actually works fairly well for most apps, but unfortunately the isolation isn't perfect, and some apps for inexplicable reasons manage to get around the App-V sandbox and read/write to the local filesystem directly (Especially apps that have some kind of licensing mechanism, where licensing state can't be properly isolated and synchronized. Though you could definitely argue that's the licensing mechanism working as intended, in my view it still represents a technical failure on the part of the sandbox that this can happen), forcing me to install them locally instead of keeping them as isolated App-V packages.

I was hoping this would basically be App-V but with better isolation through the lightweight virtualization layer they built for windows containers (and with less restrictive licensing. Seeing lots of valid criticism on licensing here, but from where I stand, Pro and above is still much more accessible than App-V's Enterprise-only), but looks like they can't quite serve the same use cases just yet.

App-V isolates state changes, but those isolated state changes are persisted on disk, so when properly configured, you can use an app across multiple sessions, closing and reopening at will without losing state, as if it was locally installed.

Sandbox also isolates state changes, but those state changes seem to be ephemeral and will be discarded upon closing the app. This means it's only useful for running apps that are mostly stateless or for experimenting with untrusted apps. There's nothing wrong with serving those use cases, but to someone who's been feeling the pain from App-V's poor isolation, and someone who's been watching immutable application ecosystems like Nix, Guix, Flatpak, Snaps, etc, flourish in the Linux world, it does seem like a missed opportunity. Definitely hoping they're planning to extend it to also support the same use cases as App-V in the future.

For one, delta-sync was built into the Dropbox client from the very beginning, and I'm getting the impression from this thread that Nextcloud still doesn't have it till this day: https://github.com/nextcloud/server/issues/417

This is a major contributor to sync UX, and by no means trivial to implement.

Another example is their file stubs implementation (Project Infinite) that works across platforms, which is also no small engineering feat, that afaik no other sync software has been able to replicate yet (OneDrive has this on Windows, but no other platforms).

The Dropbox client makes just about every other sync client look like toy projects in terms of technical sophistication, reliability, and general UX. There's a reason why they're so successful. And I say this as someone who doesn't even use Dropbox on a day to day basis (I use Syncthing as my daily driver).

This really seems like a matter of the OP not knowing what they're missing and then flaunting that ignorance.

You still can't actually change your billing country in Office 365 without starting over with a new account. Even support can't do it.

https://office365.uservoice.com/forums/273493-office-365-adm...

I don't disagree with your points around the public policy goals of currency, but suggesting that minimal balance / monthly fee requirements come from AML/KYC regulations is quite the stretch. I'd wager those come from greed, pure and simple.

The banks charge those fees because they can. If we got rid of AML/KYC regulations and reduced the banks' costs around regulatory compliance, do you think the banks will pass the savings onto customers or pocket the difference? I know where I'm putting my bet.

"Every time" for this use case is once per browser install, at the moment you perform the authentication with Firefox Sync, which is the same as the number of times you'd want to verify the binary right before authenticating.

The tradeoff they made here has essentially zero impact on the number of times you need to verify their code, it's just a matter of whether you'd have to verify browser native authentication code or authentication code delivered through a website written in JS, at the moment you authenticate.

A concern like the one raised in this thread is certainly valid for websites that have expiring sessions, where you can switch accounts and log in and out of. And we certainly do need better tools around signature verification and version pinning for websites like we do for binaries (content-addressed networks like IPFS may have good answers there).

But for this use case, it's not a practical concern by any measure, and all this alarmism seems really misdirected.

For this use case, authenticating is a one-time effort as well, per browser. If you're authenticating again, you're almost certainly doing it on a different device/browser, at which point you'd have to verify the new browser binary anyways.

Is the controversy here that the Commons Clause piggy backs on top of existing free software licenses and thus could mislead users to think that software using it is free software when it's in fact proprietary by their definitions?

As a part-time independent developer of software myself, I personally find the combination of a free software license + Commons Clause to be very compelling. I'm willing to grant to the user every right offered by free software licenses with the exception of rights to commercial use.

If that means my software has to be labeled as proprietary by the FSF, so be it, but at the same time I'd prefer not to mislead users into thinking my software is being offered under a vanilla free software license.

Is there a proprietary license I can release my software under, with the properties of a free software + commons clause license, that doesn't run the risk of misleading users? If not, I'll likely continue releasing my software under a free software + commons clause license, along with some kind of disclaimer above the license section in the project's readme.

When searching for jobs, I actually find the interview process of a company to be an extremely useful filter/signal.

I tend to outright reject companies who have interview processes like Google's.

At its best, it filters for a set of qualities that have little correlation with qualities of people whom I tend to enjoy working with professionally, and at its worst, can be easily gamed by anyone who's willing to play the interview prep game, which further reduces the quality of candidates that the process lets through.

This means even if I end up getting the job at a company with an interview process like Google's, I'm unlikely to be surrounded by people who I enjoy working with.

Even if I somehow get lucky and everybody at the company turns out to be amazing at the moment I join, the fact that their interview process is essentially a crapshoot means that wont stay true for very long as the company scales up and the law of large numbers kicks in.

You think this time big financial institutions are going to maneuver quickly enough to become viable competitors in this market before a startup establishes a decent foothold with a comfy moat?

That has literally never happened before to my knowledge. See online payments with Paypal, robo-investing with Betterment, crypto-currency with Coinbase, etc.

The more likely scenario would be other startups rising up to compete with them, but it seems like these guys have a decent head start with 100 million funding and what looks like a compelling product judging from their traction.

That seems to be one of the points of differentiation then.

It says right on the landing page "no personal guarantee": https://brex.com/

That sounds pretty compelling to me to be honest. Creating a business entity to limit your liabilities only to then put your personal credit history on the line for business spending seems pretty dumb now that I think about it.

If it's not tied to personal credit, that might also mean it'd be easier for international founders who don't have a credit history in the US.

The new chat is a huge improvement over the old one in terms of UX, but lack of persistent history is pretty pathetic considering the amount of resources Valve has available compared to a startup like Discord.

I've always wondered what rich people do when their savings/investments vastly exceed the FDIC/SIPC maximums of 250k per institution, because past a certain point, splitting among multiple banking institutions becomes logistically infeasible.

Do they tend to get some kind of private insurance against institutional failures for their entire balance? Or do they just not worry about it?

Exactly this.

A house _is_ an investment, regardless of how someone wants to think about it.

Buying a house involves a significant opportunity cost over renting since it requires locking up capital (a down payment, or the entire value of the house if buying in cash) in an illiquid asset that could have been invested in liquid assets like stocks (that have historically performed better than real estate over longer time horizons for most housing markets, and often more than makes up for the fixed costs of renting once maintenance costs, taxes, and mortgage interest rates are taken into account, but that's only tangential to the point I'm trying to make).

Also, most people buy their houses on mortgages, so they're investing with 5-10x leverage over the down payment and paying interest for that leverage. This level of leverage would be considered outright insane for any other long term investment, but most people won't even think twice before locking a large majority of their net worth behind a down payment. This puts their financial well-being at the mercy of the whims of the local real estate market due to the 5-10x amplified gains/losses, and practically removes their ability to meaningfully diversify and de-risk their portfolio.

Now of course I'm not saying buying a house can never make sense financially or otherwise, just that refusing to think of it as an investment can be dangerous because it can blind you to the nuanced risk/reward calculations involved in one of the most impactful financial decisions you can make in your lifetime.

For myself, the right time to buy a house would likely have to be when I've saved up enough money that the upfront investment for the purchase of the house is about 30% of my net worth if I'm buying with cash, or less than 10% of my net worth if I'm buying with a mortgage, to counteract the extra exposure to real-estate from the 5-10x leverage. That may mean that the time to buy a house in the Bay Area may never come for me, but I'm perfectly fine with that because the alternative would compromise my ability to keep my investments reasonably liquid and diversified, which could prove to be disastrous in these uncertain financial times ahead of us.

My previous employer eventually decided to limit hiring to North American time zones so there's a good amount of working hours overlap between team members for actual synchronous collaboration. Without that, we've found it's really hard for a remote team to match to the level of productivity of a fully-in-office team.

Clojure's multimethods covers all of the use cases for pattern matching and then some. I've never felt the urge to reach for pattern matching when writing in Clojure.

I don't think I'm doing anything particularly novel, but here are some examples:

- I live in a studio apartment in downtown San Francisco so I can minimize my commute (currently a 10 minute walk). San Francisco is a notoriously expensive city. However, most engineers in similar situations as myself (single, with slightly above market rate salary) can afford to close to work, but many end up choosing not to because they want to save more money on rent. I too could probably save a good $1000 more per month if I chose to live somewhere outside downtown and commute to work, but for me that's a small price to pay to get 5+ hours per week of my life back.

- Ordering food instead of cooking. I cooked my own meals a lot in college. It was definitely significantly cheaper than having meals at restaurants, but it was also ridiculously time consuming, especially when you take into account things like learning new dishes and grocery shopping. These days I almost exclusively order food for pickup when I leave work and for delivery on weekends. I also have a few boxes of Soylent stocked up for when I don't feel any craving for any particular taste. I also had an Amazon Fresh subscription for groceries for a while when I was transitioning between my cooking and ordering phases, so that could be a decent compromise if you still want to cook but are looking to save time off grocery shopping.

- Buying your own exercise equipment instead of going to the gym. Having a treadmill at home not only saved me commute time to and from the gym, it also had the nice side effect of reducing the activation energy for actually exercising, so I end up doing it much more often now because it's so easy to get started. I also don't have to feel self conscious sweating it out in a room full of other people, and I have my own private shower a few steps away to refresh myself when done. This one also happens to be a money saver in the long run because the treadmill pays for itself in gym membership fees saved.

These might not be practical for everybody, but I hope that was at least helpful as a starting point for brainstorming things that could work for you.

I actively try to find ways to spend money on things that can save me time on a variety of things in my life so I can spend more time doing things I enjoy.

Also somewhat related, I tend to not mind spending more money for things I spend a lot of time with. For instance, a fast computer, a comfortable chair and mattress, great sounding speakers/headphones/earphones, etc, etc, are all things I've splurged on, despite being relatively frugal with most other aspects of my life.

Can anyone point to some higher-level libraries or open-source apps built on top of libp2p?

> I think it's best to change your situation so that the right choice is the easiest to make.

Lowering the activation energy required to do cardio by getting my own treadmill in the living room really helped me get into the habit of doing cardio more regularly.

Now instead of paying every month for a gym membership I rarely used, I end up doing a good 3-4 hours of light cardio every week, opportunistically, because it's so easy to get started, and I can play music and watch shows while exercising without worrying about disturbing others, making it a much more enjoyable experience overall.

Do you have any recommendations for alternatives?