david-cako

seems like a great step for Rust adoption in the Linux community!

True, and I do like this a lot. There's a great ecosystem, and the examples are usually pretty good.

But it's also just as easy to get stranded with missing features or features that aren't on both Android and iOS. I did a bunch of geolocation and mapping a while back and I had to write my own support for things like heatmaps. This was eventually merged into the react native maps library, but it is something that can happen if you're doing anything slightly exotic.

That's the thing, it's all still there, but it's abundantly clear based on the pages and the list of supported OSs/platforms whether you can use it, and what the new API is.

https://developer.apple.com/documentation/assetslibrary

Apple seems like they are willing to double down on SwiftUI/UiKit with Catalyst.

It's getting less simple for new APIs/features but at least Apple's docs have straightforward hierarchy, even with two separate languages. Duplicate APIs usually get deprecated, like the old ALAssets photo library API.

Try building an app in .NET. There are dozens of different breadcrumbs you can follow on the MS docs for varying versions of .NET, Windows, and frameworks with radically different feature parity and UI systems. Virtually everything you google when building a .NET app has to suffixed with a bunch of identifying information for which libraries and versions you are targeting.

Open source has a serious advantage in this regard because communities tend to congregate around project and documentation styles that are consistent with similar projects, so you already have an intuition for how to navigate a new repo. I find React Native documentation especially easy to parse, although sometimes missing features or examples.

OSs have it tough because their docs aren't tailored specifically to each framework and domain space. But maybe they should be. I think if engineers felt more like they owned their product's documentation, layout, and structure like at smaller companies, they'd be more inclined to make it just right. The SwiftUI specific tutorials are great.

In cloud software at least, sales engineers/solutions architects work with the account manager to drive adoption of services. A lot about evaluating a customer's problem space or existing architecture, and proposing possible cloud-native architectures.

Sales engineers also do educational sessions and service-specific "immersion days" for the platform, which usually tie into the customer account manager's sales and advocacy for the platform, and helps to build relationships with the customer's engineering team.

I worked in a customer facing role for a while it gave me a better sense for vendor relationships. I say it's worth it if you are curious.

Encapsulated state. In large enough projects, it's easier to throw a new query into a component than to pass the needed information down from an enclosing component. Now "suggested playlist" owns its own reference to video metadata, rather than receiving it from the page root. I don't like this pattern, and it's a downside of component-style development if developers aren't encouraged to lift state.

GraphQL/Apollo and others are supposed to fix this by ensuring that any queries for a given object ID are cached, so if a bunch of different components request overlapping attributes on an object, they are hitting cache.

Without automated caching like this, I typically try to pass all data from the nearest owning data source. For instance, if I was building a video player and needed an attribute on a video object, I would find the nearest parent component that owned the page's video and pass it down from there. But that's not necessarily the typical/preferred way for software projects where tons of people are working on the same page in tandem. Personally, I see a lot of web apps where different components are loading at different times. It doesn't make for a nice experience.

As for people saying "it's not that much data/duplication", sure, but if the requests aren't cached, it could be increasing latency. In the OP, they said all 14 references are from one request, but there still could be duplicated queries in the server logic that is hydrating the data; I don't know how YouTube handles this and didn't look at how the app works. This is something they've likely made opaque to developers with a data fetching cache between the request handlers and the backing data, but it's no guarantee.

If you don't have a caching layer on the client and/or the server, I say be particular about lifting state and passing it into components. It's fun when you can just throw a React component into a page and it works without any hook-up, but it's also easy to pass a few props into a component.

Hahahaha, my interpretation of this is that palm prints are proprietary and require less widely available technology to make use of them.

The unencapsulated thing is exactly the feeling I got. I am most confused with others' code when there is implicit imports or declarations of any sort. "Where did this come from??? Why is this working???"

I had the same thoughts about React hooks although perhaps I don't correctly understand the motivations. Class components have extremely clear, compartmentalized lifecycle functions, and now the advice is... make everything a function-scoped closure? Let redux do some opaque context sorcery to update your components?

React (and others) hit the paradigm right on the head the first time, IMO. It's change for change at this point, which is fine I suppose.

I agree that you gain a lot from having Apple involved in quality control, but I am not sure I agree that 30% of all in app transactions is fair. Especially when they've already started playing fast and loose with Amazon Prime Video.

True, but there are other places to buy things than Walmart.

The internet is reasonably open and accessible on iOS, but utilizing the full capability of an iOS device requires the App Store.

Stallman spent a ton of time crusading about how some things are appliances, and other things are computers; those things that are computers should offer flexibility (and ideally openness) in terms of what software you can run on them. In this case, the largest manufacturer of computing devices and software wants 30% of every transaction from native software run on their devices.

Epic was basically looking for preferential treatment, but now they're stepping up to the plate and saying the App Store is not market-friendly. It seems like they could be right, seeing as large as Apple is, and what role they actually have in computing.

Wild times we live in. Steve would be proud.

True, Apple has a big advantage by having a sense for the baseline-level of computing power on client devices, which is pretty high across the board.

The uniformity of UX is worth the glacial rate, IMO. The more ScrollViews with arbitrarily laid out content (Photos seems to have these increasingly), the less intuitive I find apps. In Photos, I find it hard to get a sense for what menu-depth I'm at. Apple has a very logical master-detail layout across most apps, and I hope with Mac Catalyst that Apple continues to enforce consistent UI practices.

The more freedom developers are given to put any old layout, the more apps start feeling the way Windows Forms, WPF, and UWP feels on Windows; it's like you have to start thinking about "Okay, when was this app designed?" to figure out how to use it.

I suppose my point, more specifically, is that functions return errors instead of opaquely throwing them. Most languages expect you to know where they're going to occur and catch them as close to their occurrence as possible, in Go you are explicitly carrying them along the whole way. Some people don't like this, I prefer it.

True, if you completely ignore the function's return values, you can throw errors away, but then you wouldn't be using the language in the way that makes it powerful to me; that there are simple and clear interfaces that you interact with.

It's really hard to point at studies to evaluate these types of hyped development paradigms. Some thoughts, as someone who loves static typing and microservices:

My favorite thing about static typing is that it makes code more self-documenting. The reason I love Go specifically is because if you have 10 people write the same thing in Go, it's all going to come out relatively similar and use mostly built-in packages. Any API requests are going to be self-documenting, because you have to write a struct to decode them into. Any function has clear inputs and outputs; I can hover a parameter in my IDE and know exactly what's going on. You can't just throw errors away; you always are aware of them, and any functions you write should bubble them up.

Typescript addresses this somewhat, but basically offsets that complexity with more configuration files. I like Typescript in use, but I can't stand the fact that Javascript requires configuration files, transpilers, a million dependencies. Same for Python and mypy.

Yes, I could just look at class members in a dynamic language, but there's nothing that formally verifies the shape of data. It's much more annoying to piece apart. I don't use static analyzers, but my guess is that languages like Go and Rust are the most compatible with them. Go programs are the closest thing to a declarative solution to a software problem, of any modern language IMO. As we continue experimenting with GPT-generated programs, I think we're going to see much more success with opinionated languages that have fewer features and more consistency in how finished programs look.

Microservices are also great at making large applications more maintainable, but add additional devops complexity. It's harder to keep track of what's running where and requires some sort of centralized logging for requests and runtime.

Kabbalistic Judaism also addresses the capacity for somethingness to emerge from nothingness. Very interesting interpretations of these metaphysical puzzles.

https://en.wikipedia.org/wiki/Ayin_and_Yesh

Tzimtzum, "contraction", proposes that the physical world is infinite somethingness/nothingness (essentially equal representations of one thing) made manifest in the realm of light/waves and distinctions.

https://en.wikipedia.org/wiki/Tzimtzum

In a Lacanian sense, the role of the analyst is to be filled up with the images and ideas of the patient. https://nosubject.com/Discourse_of_the_analyst

Some may find the Greek term "kenosis" interesting, meaning "emptying". https://en.wikipedia.org/wiki/Kenosis

I agree that SSC being separate from his psychiatry is pretty important. I like SSC, and at the same time I would find it difficult to go to therapy knowing Scott is behind SSC. It would cause me to fixate on obsessional traits in myself, knowing that he is predisposed to the same thing.

True, however at AWS at least, customers are specifically told "multi-cloud doesn't allow you to fully leverage the benefits of AWS", whatever that means.

It makes sense that cloud companies are inclined to keep customers from giving money to competitors, but they way they sell it and structure services, reserved instances, and enterprise discounts is such that you basically are putting all of your eggs in one basket.

Apple's got a lot of surface area, and a pretty damn good track record.

Who else is doing what they're doing? No other consumer hardware company goes top-to-bottom from the software to the chip, and no other company has such a cohesive ecosystem. Google EOLs a product once a week, Microsoft is making some nice stuff these days, but is nowhere near the same experience ("Windows is like a bundle of drivers", as in the article).

There is value to being prescriptive over their platform. It gives them skin in the game to make things good; they are much less willing to just blame a vendor.

or... as with many other technologies, Apple leading the way will subsidize the proof of concept for everyone else. The iPhone didn’t stop people in poorer countries from getting mobile service and smartphones for pennies on the dollar. In fact, it did the exact opposite. 3rd world countries went and built better mobile networks than we had in the US at the time.

Moreover, if the existing medical industry is evidence of anything, prices are jacked up in developed countries to foot the bill of R&D, and the same medications are sold elsewhere for next to nothing.

Apple giving away health technology to disadvantaged communities seems like a good next step. Perhaps existing medical companies aren’t as incentivized to do that because they don’t have the shiny brand to advertise.

Apple has a talent for putting themselves right at the center of important technologies. I wonder if this strategy plays out as integrated medical devices and a full-blown healthcare platform. Their reputation for top-notch hardware, good UX, and their shift towards in-house SoCs gives them a serious edge there. Everything about their brand feels well suited for healthcare, and IMO they still don't have a killer enterprise app. This could be what Watson was promising to be.

Good luck with this wiffle-ball strategy. :)

Perhaps this was the “actual price” of the produce anyway, including the wasted and donated food. Delivery means there’s more reliable metrics about the average quality of food stocked and expected by shoppers (in a given area). This is a good thing if they make it so customers can easily post reviews and request refunds.

macOS has quite a few built-in antivirus features:

https://support.apple.com/guide/security/app-security-overvi...

IMO, you have to pick a security vendor to trust (only as far as you can throw them). Apple is incentivized to provide better end-user experiences as a matter of having end to end authority for their products. They’ve built a robust (albeit prescriptive) security/sandboxing ecosystem to avoid just pointing at software vendors if a customer is unhappy.

I like these features, but the fact that they’re not always optional is frustrating. Note also that soon macOS will be running on Apple ARM SoCs; similar trade off.

Buy any other computer, and you now have Microsoft or Google, a CPU vendor, a consumer hardware vendor, and possibly also an antivirus company installing background services.

Haha, I love the drawings.

True, but having a 3 letter domain name that sounds fast and a separate checkbook may have actually been important to growing their e-commerce business. The crazy discounts they offered when they first started and the purple boxes all had the effect of signaling to consumers (and investors) “we’re trying something new”, and now they rolled everything they learned (things lots of e-commerce sites are learning all at the same time) into their core e-commerce strategy.

This is awesome advice. Taking incremental steps towards what you want to do makes a big difference. If you already have a domain, hosting, and DNS set up, you’ve got something cool and tangible to work with.

I actually trust less descriptive domain names. When I see biketours.com, I more often expect blog spam and ads. When I see GoSojourn.com, I expect an actual business providing bike tours. It’s also peculiar to me when I see local contractors with domains like MyCityElectrician.com putting “Denver Electrician” in big text and hiding their brand name. I recommend a branded domain name and relying on good page titles and descriptions for ads and SEO.

Natural philosophy and alchemy were names for science before science. Alchemy had a connotation of being very ceremonial; knowledge had to spread by group gatherings and word of mouth.

Cutting edge science today would have been called alchemy historically. Artificial intelligence, gene editing, etc. Fortunately scientists have a pretty good reputation now, where alchemists of the past had to research and convene in secret.

The claim made in the article is that ignoring UX and SEO conventions tells you all about the company. That is the “human centered” message behind the site design.

A website with a bunch of responsive elements, meta tags, and fonts spent a lot of time thinking about how they are going to convert clicks.

I prefer slides-only to watching a talk, but the spoken content often supplements and extends what is on screen with detail and examples. People who like the spoken content will gain “new features” by having it skeuomorphicized (i.e, “made more familiar”).