That said, making the 19 adapter is a whole new task, and I think these tests should be converted to RTL eventually, so the approach described in the blog post is still valuable.
Did you use Chat GPT 3.5 or Chat GPT 4? GPT 4 solves this correctly when I ran it (but admittedly, by nature of the way it works non deterministically, it might have failed for you but worked for me)
My takeaway: modeling problems in minizinc correctly is exceptionally difficult for non-trivial problems. You can model it correctly, but you'll likely still need to add additional "constraints" that improve the performance of the solver to the degree where it's even remotely usable to solve real problems.
It's a really interesting tool, but one of the reasons we thought it might be useful for this problem is so that non-technical people could easily change the constraints and play with the costs for different operations. I don't think it's particularly good for that, at least in this problem domain.
They do actually talk about this idea in the talk. The "shortest possible program" that can be used to describe the music is undecidable, but there is a short description, in the case you just described it's unknown to the listener.
Would it be possible to mitigate the CSS based fingerprinting using URLs, by having the client forcibly cache the fonts / urls? I think then on return to the site, there would be client cache hits, and no request to the server on return visits.
I imagine this would be a pain for browsing in general, but could help browsers in a privacy mode
Makes sense! I think I probably won't use it much yet, as the example you mentioned (messaging apps for link sharing) works pretty well, and often they also have a view where you can just look at all of the links sent. Some ideas of what would make it more likely for me to use:
* The ability to integrate with those messaging apps so I could use SeeLink, but then send out those links to friends via different messaging apps. I often send out the same links to multiple people on different platforms, it'd be neat to be able to track who I sent it to and catalogue them that way
* A feature like related links, or some form of automatic categorization of links based on tags.
I think Pinterest is great for discovery, so if this is more about link categorization and social sharing, you could take it in either of those directions
Congrats on the launch! This looks like a great project and I'm sure you learnt a lot from building it.
Some first impressions:
1. You used Pinterest as an example link in the guide, and it wasn't immediately clear how this was differentiated from Pinterest. If you could think about why it'd be better to use SeeLink rather than an existing tool, I'd be more interested in it
2. I think the red block colour you're using is too much (#FF0004). I'd consider changing it to a lighter red, or even white background with black text (it'd be easier to read)
3. It wasn't clear to me what the bookmark icon does – haven't I already bookmarked the link by adding it to my board? Is this feature for further filtering?
Overall, great job! It looks quite polished and I didn't see any bugs.
> 11. Cooking pollutes the air. Opening windows for a few minutes after cooking can dramatically improve air quality.
After bad bush fires where I live I invested in both a CO2 monitor and a particle air quality monitor (Dylos DC1100 Pro Air Quality Monitor). It shocked me just how much cooking (and other factors I can't quite determine yet) affected the air quality. Think 10 times more particles due to cooking, even with the fan on and windows open.
Another possible source of indoor air pollution are carpets and other manufactured things, interestingly.
CO2 was bad too, but opening my window has a greater impact on that. But it is shocking to see levels of ~800-900ppm inside with windows closed.
Often node modules need to depend on git to do developer experience things. Having it be available in node with no dependencies is really nice, you don't need to assume anything about the git in the environment your user is using.
It covers some pros and cos, the main advantages of using an app shell are
> whether your web app is best modeled as a single-page application (advantage: App Shell); and on whether you need a model that's currently supported across multiple browsers' stable releases (advantage: App Shell)
I think it's reasonable to argue that lots of sites that are SPA's don't need to be, if they can do this instead.
By this argument, JSX shouldn't be published to NPM either.
You might argue that you know what you're consuming if you're importing, say, a React component, and it's likely written in JSX, but it's really a categorization issue.
A standard field in the package.json indicating what the source is written in might be useful, but would probably be left unpopulated. Personally, I find it fairly straightforward to tell what a package is written in just by looking at the source.
I'd love it if there was some sort of "helper terminal" that could teach people things like git, and basic command line stuff as they went.
It could catch common errors and provide useful explanations. It could possibly even go as far as attempting to understand plain text commands, eg "delete the file file.txt" and suggest commands to do that.
Are there any popular implementations of immediate mode GUI for the web? It might be interesting to have one that could then "eject" into a stateful UI for when things start to get more complicated.
That's an interesting perspective. I think you're right that we don't have "correct" and standard answers because we don't assume total competency, but I think we don't assume total competency because software development (both the requirements and the practices) change fairly rapidly. I wouldn't be surprised if in 100 years, we're still trying to figure out standards, if the pace keeps up.
I did some work with this a while ago to try and use MiniZinc to calculate genome edit distances, which was quite interesting: https://github.com/jpnelson/genome-edit
The hardest part is certainly making constraints that don't have any holes in them, and then making it fast. Making the MiniZinc solver faster than a search algorithm required a bit of knowledge about how the solver works.
I can imagine there are some problems that are well suited to this, and this would be a good tool to solve them, but it's certainly not the best way to solve every problem (yet, anyway).
The contents certainly might be, but I think having a reference sheet like this is the absolute minimum for this sort of hearing, to maintain any sort of coherent argument. There's certainly enough to attack in the contents, rather than the fact that he had these notes or needed them.
You don't need to abstract this to that extent. You might be able to say in most cases it's a bad idea to use your company to express a political opinion, which I agree with, but this is going beyond that – this is a human rights issue.
In terms of "tearing apart groups of people", like you might do by voicing a political comment that your company partly disagrees with, I think that this particular ruling tears people apart to a much larger degree.
We've been communicating with them pretty closely actually! We're aiming to use the same polyfills so that the community can share the benefits of that.
With the imports it's a slightly different paradigm – in the way that you put it, Skate is more similar to React's approach where the template is embedded in the source.
That said, making the 19 adapter is a whole new task, and I think these tests should be converted to RTL eventually, so the approach described in the blog post is still valuable.