4,390 karma · joined July 13, 2008
This account's password has been randomized, so if you see it commenting/updating in future.. that probably wasn't me :)
So long, and thanks for all the fish!
(that plus the ability to question and correct aspects of the project asynchronously could compare favourably to spoken meetings, where details could be forgotten or misinterpreted over time, and where bandwidth for audience feedback is usually limited)
My sense is that the functionality to provide those experiences resulted in a decrease in user security and privacy when they were introduced -- and that those risks were widely-discussed and well-understood.
It's weird (although not unexpected) to see the reversal of them touted as a selling point.
All I'll say for now is that arguably the shopping list should become an important nexus within the app. Like an accounting entry-book with both order history and also yet-to-be-filled orders, it could be used to approximate the kitchen inventory at points-in-time. That should become powerful when changes in inventory are used to feed back into current and future meal planning.
Separately: advice noted about testing with friends and family. My partner and I use the app at home once or twice a week, and following recent improvements it's probably time to reach out for more feedback from others.
I find maintaining a balance between asking for (re)evaluation of the app and a hope for regular everyday conversations a little tricky; but to be honest I've always found the latter challenging, probably.
One thing that does occur to me is that artificial lighting wouldn't be limited by the passage of the sun, so crop growth could potentially continue 24 hours a day.
It's a reputation and trust-building exercise, essentially - and that's one of the reasons that continuous integration is particularly useful. "Entities X, Y, Z all say that commit <ID> looks good".
> Either way, all my other points still stand. CI isn't going anywhere.
Agreed :)
Those acquirer-side incentives do seem rational (and to some extent traditional) in a business sense.
The risk-mitigation I mentioned was from the perspective of users, not so much of the acquisition target (although it could reassure their employees to know that the time and effort they invested continues to provide value).
[1] - https://www.rockbox.org/
Perhaps some of those teams and individuals are experts at determining the correct, minimal continuous integration suite to run on a per-commit basis to minimize time and energy expenditure without compromising correctness.
But I can guarantee that not all (in fact, not many) are, and that they pay maintenance and mental overheads to adhere to those practices.
It feels to me like there is a potentially massive opportunity to design an integrated language-and-infrastructure environment that only re-runs necessary checks based on each code diff.
- "Altered a single-line docstring in a Python file? OK, the data-flow from that infers a rebuild of one of our documentation pages is required, let's do that... done in 2ms"
- "Refactored the variable names and formatting within a C++ class without affecting any of the logic or ABI? OK, binary compatibility and test compatibility verified as unchanged, that's a no-op... done in 0ms"
- "Renamed the API spec so that the 'Referer' header is renamed 'Referrer'? OK, that's going to invalidate approximately a million downstream server and client implementations, would you like to proceed?"
(examples are arbitrary and should imply no specific limitations or characteristics of languages or protocols)
Doing this effectively would require fairly tight coupling between the syntax of the language, ability to analyze dataflows relating to variables and function calls, cross-package dependency management, and perhaps other factors.
Those properties can be achieved during design of a programming language, or they can iteratively be retrofitted into existing languages (with varying levels of difficulty).
Bazel[1] attempts to achieve much of this, although to my understanding it offloads a lot of the work of determining (re)build requirements onto the developer - perhaps a necessary migration phase until more languages and environments provide formats that have self-evident out-of-date status and dependency graphs.
We'll get there and the (sometimes uneasy) jokes will be about how often the software industry used to re-run huge continuous integration pipelines.
They probably frequently lead to competitive benefits (and increased market share / revenue) for the acquirer, but the discontinuation of products presumably leads to lost time, effort, and potentially money as the former customers of the product look for alternatives (in a diminished market).
I'll beat my usual drum and mention that free and open source software can mitigate some of the risks (but not, for example, support availability) for a software-based product, similar to having an agreed source-code escrow provision with a vendor.
As the article mentions, the problem generally isn't any one individual change - the concern is about the sense of direction for the overall project. The typical direction is from "simple software that helps people to achieve some goals" towards "product with features designed to increase revenue, data gathering, and stickiness" -- like the login-required anti-feature mentioned.
If those changes are gradual then users may not really notice the small differences as they introduced, and if anyone does complain, it becomes easy for supporters of the project to deflect complaints (as, arguably, you may be here -- not ostensibly trying to keep the author with the product, but trying to reduce their credibility and persuade others that there is no problem).
In many cases, free and open source software can help avoid a project falling into dark patterns because it's possible for people who disagree to fork it and maintain/promote their own alternative -- and then for other people to compare the original and the fork on their merits (which are transparent).
Yes, there's a bit of overhead to maintaining that, and it can fall out-of-sync with the code over time.. the key benefit, though, is that it provides useful context for reviewers, a bit like a geographic map does when navigating a new place.
The goal should be to make people feel like they understand more of the purpose and design of the project shortly after they arrive; as a result they'll be able to figure out what aspects of their own experience they can use to help review (and perhaps contribute changes to) the code, and where to go (in terms of files/directories/modules) to best apply that expertise.
> support splitting ingredients by typing a comma
That sounds sensible, yep; filed as https://github.com/openculinary/frontend/issues/210
> "Are there any ingredients that are not available?" ... I knew what you meant, the search will exclude recipes with those items, but it felt weird to read
That makes sense too. If I remember correctly, that prompt was most-recently rephrased during a pandemic-related lockdown (with subsequent unpredictable ingredient shortages), and so that context may have affected the choice of wording; either way, I agree that it's odd phrasing and should be updated.
Hopefully that'll be a relatively quick correction, although it will require internationalization (currently machine-translated without review by native language speakers, not ideal); it's filed as https://github.com/openculinary/internationalization/issues/...
> box around the search form has a huge gap to the right of the form inputs
> I'd probably expect to see filters for vegan/veggie/pescatarian / low gi etc but then maybe not
Two good points here, and possibly combinable. Perhaps those dietary recipe filters could be placed in the excess space available next to the search controls.
Today the search API does theoretically support filtering[1] on a few dietary properties -- but that functionality isn't yet visible and available to the user.
Feature tracker filed as https://github.com/openculinary/frontend/issues/211
- Shopping list feature ... your icons seem too small and fiddly, and I'd want a few buttons on screen of common things - so I can tap those instead of typing
The frequently-added-items shortcut idea is smart. The shopping list feature and the meal planner are under-attended components of the app relative to the recipe search/explore components, in my opinion. Let me think about this for a while, there are a few considerations and I'd like to be concise when responding about this in more detail.
[1] - https://github.com/openculinary/api/blob/72075f66cd6fda5b809...
I think the two largest challenges it has at the moment are:
- Developer experience / infrastructure setup: the service is Kubernetes-based, composed primarily of Python+Flask microservices, and although the setup steps are documented[1], they're not yet automated.
- User interface: my lack of user interface design skills are fairly apparent, I think. Having some clear UI goals to work towards would be helpful - there's likely some overlap with product design questions here (what should be the range of functionality that the the app offers?)
To be transparent: although I hope to offer compensation in future, the project is zero-revenue currently, and I don't feel ready to provide any monetary returns yet. If that hasn't put you off: any feedback is welcome, from discussion comments to pull requests to business model questions/critiques!
PS: Don't forget to mention one or two of your own side projects if there's anything you're looking for help with, too.
'Justice Clarence Thomas, in his opinion, wrote: "In future cases, we should reconsider all of this Court's substantive due process precedents, including Griswold, Lawrence, and Obergefell" - referencing three landmark decisions of the past on the right to contraception, the repeal of anti-sodomy laws, and the legalisation of same-sex marriage respectively.'
> The package name on the Play Store is org.openfoodfacts.scanner. For historic reasons, it's openfoodfacts.github.scrachx.openfood in the code and on F-Droid.
(quoting from the app project's readme at https://github.com/openfoodfacts/openfoodfacts-androidapp/)
https://trends.google.com/trends/explore?cat=60&date=all&q=r...
Edit: filtered link to category "Jobs"
(not a journey that I've experienced, so I can't answer questions about what it's like - it's just something I read about on the web a few years ago)
This reminds me of a code comment I wrote about some web crawling code that is intended to maintain a continuous web address "flow graph", matching any origin URL(s) (the 'water table' of a web page) down to the current location of that page on the web (the 'river delta').
This can be complicated because old URLs may be redirected (HTTP 301, 302) to different locations over time, often for SEO reasons or due to change of domain ownership.
Does the code comment linked below make sense? I'd really appreciate any feedback and improvements:
https://github.com/openculinary/backend/blob/5116c4f5d39dae1...
(and yes, I realize the ASCII art here pales in comparison to some of the visually appealing and clear diagrams shared in the article. I'm doing my best :))
The U.N. Human Rights Committee has a recent (2019) publication[1], "General comment no. 36, Article 6 (Right to Life)" that contains an entry that is relevant to this question.
Page two, item eight under "General Remarks":
"Although States parties may adopt measures designed to regulate voluntary termination of pregnancy, those measures must not result in violation of the right to life of a pregnant woman or girl, or her other rights under the Covenant. Thus, restrictions on the ability of women or girls to seek abortion must not, inter alia, jeopardize their lives, subject them to physical or mental pain or suffering that violates article 7 of the Covenant, discriminate against them or arbitrarily interfere with their privacy. States parties must provide safe, legal and effective access to abortion where the life and health of the pregnant woman or girl is at risk, or where carrying a pregnancy to term would cause the pregnant woman or girl substantial pain or suffering, most notably where the pregnancy is the result of rape or incest or where the pregnancy is not viable. In addition, States parties may not regulate pregnancy or abortion in all other cases in a manner that runs contrary to their duty to ensure that women and girls do not have to resort to unsafe abortions, and they should revise their abortion laws accordingly. For example, they should not take measures such as criminalizing pregnancy of unmarried women or applying criminal sanctions to women and girls who undergo abortion or to medical service providers who assist them in doing so, since taking such measures compels women and girls to resort to unsafe abortion. States parties should remove existing barriers to effective access by women and girls to safe and legal abortion, including barriers caused as a result of the exercise of conscientious objection by individual medical providers, and should not introduce new barriers. States parties should also effectively protect the lives of women and girls against the mental and physical health risks associated with unsafe abortions. In particular, they should ensure access for women and men, and especially girls and boys, to quality and evidence-based information and education on sexual and reproductive health and to a wide range of affordable contraceptive methods, and prevent the stigmatization of women and girls who seek abortion. States parties should ensure the availability of, and effective access to, quality prenatal and post-abortion health care for women and girls, in all circumstances and on a confidential basis."
Are you referring to MusicBrainz[1]?
[1] - https://musicbrainz.org/
The argument would be along the lines of: you as the user are the one who asked the eidetic programmer (nice terminology, @bencollier49) to produce code for your project; all we did is make the programmer available to you.
Is there information from the students about the reason(s) that they don't want to consume school-provided meals?
And is there a sense of how often this is occurring? (is it a particular problem in some locations and not others, or widespread?)
My biggest sense of loss is for someone who is still alive, and I think about them every day. I don't think I'd want to risk introducing synthetic samples of them into the already-probably-divergent (and sometimes painful, and embarassing) memories I have of the past.
At the same time: technology and the world around us are changing, and perhaps it's worth considering that future generations may have different norms and preferences.
Currently I don't think I'd want any of my personal or intimate communications to be used in generative models, and certainly not without clear and informed consent (potentially multiple rounds thereof). Workplace and public communications seem more reasonable - and match my bias towards open software and culture.
Where does this path lead? I don't know. It's worth discussing (and if necessary, regulating) though, rather than being surprised when corresponding technology products arrive.
(I haven't tried using the Windows version under Wine, sorry)
(self-response: maybe, if they're going to cut corners in some areas to provide a more popular but somehow value-compromised alternative)