kukkeliskuu

I use GitHub Pages for personal blogs. Connect it with your personal domain name in case later you want to run it somewhere else.

The article completely misses the point about the dating apps. It is not that the inferior product wins, but that if your product is so good that people only need one in their lifetime, you will quickly reach the limit on your sales. Planned obsolescence is a well-documented phenomenon in many fields.

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

Maybe your university is just using some commercial provider (such as Microsoft) that categorizes pages.

I am now not commenting on these specific prompts or participating in discussion about them, as I have not investigated how this project works in general, and whether their approach is legitimate in the larger context.

Specifically, I am not advocating for anything criminal and crimes against children are something that really bothers me personally, as a father.

However, in general terms, our thinking appears to be often limited by our current world view. A coherent world view is absolutely necessary for our survival. Without it, we would just wonder what is this thing in front of us (food), instead of just eating it.

However, given that we have a constant world view, how do we incorporate new information? People often believe that they will incorporate new information when provided with evidence. But evidence suggests that this not always necessarily so in reality. We sometimes invent rationalizations to maintain our world view.

Intellectual people appear to be even more suspect to inventing new rationalizations to maintain their world view. The rationalizations they make are often more complex and logically more coherent, thus making it harder to detect fallacies in them.

When we meet evidence that contradicts core beliefs in our world view, we experience a "gut reaction", we feel disgusted. That disgust can obviously be legitimate, like when somebody is defending crimes against children, for example. In such cases, those ideas are universally wrong.

But it can also be that our world view has some false core belief that we hold so dear that we are unable to question it or even see that we oppose the evidence because our core belief has been violated.

We cannot distinguish between these just by our emotional reaction to the subject, because we are often unaware of our emotional reaction. In fact, our emotional reaction appears to be stronger the more false our core belief is.

If you go deeply enough to almost any subject, and you compare it to the common understanding of it in general population, for example how newspapers write about it, there is usually a very huge gap. You can generalize this to any subject.

Most of this is due to just limited understanding in the general population. This can be solved by learning more about it. But it is not unreasonable to think that there may also be some ideas that challenge some basic assumptions people have about the subject. Hence the saying "if you like sausage, you should not learn how it is made".

What you appear to be suggesting is that as you cannot think of any subject that you believe the general population (or you specifically) has false non-trivial core beliefs bout, then such false core beliefs do not and can not exist, and people should not be morally or legally allowed to make a project like this.

You are asking for evidence of a core belief that you have a wrong belief about. But based on the above, if you would be presented with such an example, you would feel gut reaction and invent rationalizations why this example is not valid.

However, I will give you an example: this comment.

If you think the analysis in my comment is wrong, try to sense what is your emotional reaction to it.

While I agree with your your gut reaction to the prompts, it seems to me that you are rationalizing your gut reaction.

Your reasoning does not appear to be rational under more a careful scrutiny: even if you cannot invent anything bad actors could use LLM for (lets say a terrorist in designing a plot), that does not mean it could not potentially be used for such purposes.

Lyme disease seems difficult to understand, as it has features that challenge some basic assumptions how diseases work in general.

One such assumption is that borreliosis is always the same. But researchers have been able to capture on video the morphosis of borreliosis spirochets to biofilm, and also spirochets hiding inside red blood cells. Antibiotics apparently only work on some of these forms, thus if you are using antibiotics to cure yourself, you need long-term antibiotics to permanently kill borreliosis.

There is actually a whole subculture of hobbyists investigating their own blood samples, prepared in certain way, to capture on video how the borreliosis emerges when the red blood cells die.

Lyme is actually not a single disease but a syndrome of borreliosis together with some co-infections. These co-infections appear to work synergistically together. If you reduce the amount of one of them, others increase in numbers, weakening you so that the original co-infection can make a comeback.

Also, sometimes curing borreliosis or co-infections can make you feel worse. This is called the Herxheimer reaction. One of the reasons for this seems to be that sometimes the symptoms are actually not due to the co-infections themselves, but toxins that are released in your body when the co-infections die within the body. Thus, the more effective the cure, the more toxins, and you feel worse.

If I remember correctly, there are around 40 subspecies of borreliosis. The tests can recognize only few of these.

I also remember reading about research where random people (without symptoms) were tested for certain types of borreliosis. If I remember correctly, around 15% tested positive. This means that actually many of us may carry these diseases, but at a level that does not cause symptoms. But if our body is weakened, these diseases may become active.

The problem with antibiotics at least in some countries is that official guidelines take the position that chronic Lyme does not exist, and thus doctors are forbidden to write long-term prescription to antibiotics for Lyme. Short-term may not work, as research suggests that antibiotics works only on some phases of the life-cycle of borreliosis and only for some co-infections.

In my understanding (from some years back when I was researching this myself), Lyme takes multiple forms, and in some phase in their life cycle are able to hide inside red blood cells. Antibiotics work only for some of the forms.

Some researchers think that the difficulty in healing Lyme disease is related to the fact that Lyme changes form and antibiotics only target some of the forms. In some countries, doctors are forbidden to make long-term prescription for antibiotics based on the idea that chronic Lyme does not exist.

In completely unrelated news, Spain’s PM proposes mandatory Digital ID for social media users at Davos.

https://idtechwire.com/spains-pm-proposes-mandatory-digital-...

Many projects active.

(1) For one product I am working, I have been working on a custom reporting language for producing high quality PDFs. I used hy.py as a basis to make it LISP-like.

(2) I need to make a Django postgres site that I am running more reliable. Earlier I was experimenting with making static HTML renderings of the pages. That is certainly nice, but it took several hours to reproduce the site. I am currently prototyping making read-only replica of the database in SQLite (the database is only 1 MB) and hosting it on CDN, and then pulling that for the read-only replicas. The database export takes only some seconds.

(3) I vibe coded a iOS app using that same SQLite database that fetches it from the same location. It was surprisingly simple. It seems much simpler than using Flutter or React native.

I remember reading that no med schools in the U.S. use the actual Hippocratic Oath anymore, although it seens that most schools have sone form of oath.

In my experience you become a good generalist by learning deeply about many things. My real skill is learning the essence of a compoex topic quickly. It also becomes easier over time to learn deeply about a new subject.

I believe (I have done very little sales, so mostly as a buyer) that while all three (buyer-pull, seller-push, Cialdini-style mentioned in a comment below) can work, the best result comes from buyer-pull when you have empathy for the customer.

You try to understand the needs of the buyer, and see if what you are selling aligns with those needs. This is needed for effective buyer-pull, because they might not understand what they really need, or how what you are offering might fulfill those needs.

Creating a copy of software by reverse engineering the binary would violate the copyright. If you use LLM to analyze the UI and recreate the app, it might not.

The risk is that if I have created something propietary and novel, it becomes trivial for somebody else to recreate it in using Claude Code, if that same thing has been used to train the model that is being used.

Somebody (tm) will probably turn this against Anthropic and use Claude Code to recreate an open source Claude Code.

Let's say that I use LLM to develop novel software called X. Then my work is used to train the model. Then somebody uses the model to recreate a copy of the of the software X by prompt "create software that works just like X". My novel software is no longer unique. So how come I have not been deprived of anything?

Sounds quite interesting.

What is the more intelligent way you use to emulate fighters being hit in the stomach?

Why does saliva clean testosterone? How much saliva are you using?

Coincidentally, I have been implementing an ad pacing system recently, with the help of Anthropic Opus and Sonnet, based on PID controller

Opus recommended that I should use a PID controller -- I have no prior experience with PID controllers. I wrote a spec based on those recommendations, and asked Claude Code to verify and modify the spec, create the implementation and also substantial amount of unit and integration tests.

I was initially impressed.

Then I iterated on ihe implementation, deploying it to production and later giving Claude Code access to log of production measurements as JSON when showing some test ads, and some guidance of the issues I was seeing.

The basic PID controller implementation was fine, but there were several problems with the solution:

- The PID controller state was not persisted, as it was adjusted using a management command, adjustments were not actually applied

- The implementation was assuming that the data collected was for each impression, whereas the data was collected using counters

- It was calculating rate of impressions partly using hard-coded values, instead of using a provided function that was calculating the rate using timestamps

- There was a single PID controller for each ad, instead of ad+slot combination, and this was causing the values to fluctuate

- The code was mixing the setpoint/measured value (viewing rate) and output value (weight), meaning it did not really "understand" what the PID controller was used for

- One requirement was to show a default ad to take extra capacity, but it was never able to calculate the required capacity properly, causing the default ad to take too much of the capacity.

None of these were identified by tests nor Claude Code when it was told to inspect the implementation and tests why they did not catch the production issues. It never proposed using different default PID controller parameters.

All fixes Claude Code proposed on the production issues were outside the PID controller, mostly by limiting output values, normalizing values, smoothing them, recognizing "runaway ads" etc.

These solved each production issue with the test ads, but did not really address the underlying problems.

There is lots of literature on tuning PID controllers, and there are also autotuning algorithms with their own limitations. But tuning still seems to be more an art form than exact science.

I don't know what I was expecting from this experiment, and how much could have been improved by better prompting. But to me this is indicative of the limitations of the "intelligence" of Claude Code. It does not appear to really "understand" the implementation.

Solving each issue above required some kind of innovative step. This is typical for me when exploring something I am not too familar with.

I learned a lot about ad pacing though.

I have similar problem, but even more expensive. I have developed products that have lots of users so I cannot (and don't want to) abandon it, but monetization will require lots of investment -- actually setting up a different business altogether because the monetization I would like to buy as a service does not exist.

projectgraveyard.org seems to be available

Somebody should do a website for the graveyard of incomplete projects, so that if somebody wants to work on a certain idea, they can find a potential partner.

The context of the discussion is how to create apps extremely fast. If I would optimize for something else, it would be a different story.

That is on my list of things to learn. It is not high priority, though, because I don't think Phoenix LiveView is extremely boring technology at the moment. The user base is not large enough.

I assume you are talking about geographical distribution of the user base. I don't have experience implementing apps that require heavy geographical distribution, but why does REST/JSON work better for this?

I don't have experience with Wicket, but with HTMX, I have tried to make components very small. For example one switch button is one component. Loading that is very fast in my experience, as compared to reloading and rerendering all data with React etc.

Who could argue with the "right tool for the job"? I am not saying that there are no use cases for other approaches.

But when you say you had a "static view" (in singular, not plural) with HTMX, what do you mean? I am very interested in hearing what kind of complex interaction you had where that approach failed?

With HTMX, I have found the most useful approach is to build your pages from lots of very small components. Initially, I don't worry about reuse of those components, it is more about decomposition than reuse.

Of course, if you want to do "fast client data slicing", then HTMX makes no sense, because it pushes logic to the backend and by definition your solution wants to process data in the fronted. So if you start from that premise, HTMX is obviously the wrong tool.

If you want to use HTMX, you need to rethink your solution, i.e. question whether you really need "fast client data slicing". So why bring all the data to the frontend, and not just the slice you want to visualize?

One reasonable use case is reducing server load. I have one app where data is loaded from static generated pages (periodically updated, for performance, stability and reduced server load), and sorting is done on the frontend using Javascript, based on data attributes on the DOM.

I use django-components.

1. fly.io sells redis hosted by upstash. But you are correct in the sense that default fly.io PostgreSQL was unmanaged and probably subsidized, and recent PostgreSQL is probably more expensive. But while I think you cannot directly say that tenfold increase in price means tenfold increase in complexity, I am just saying that it is complex.

2. It is surprisingly common to see people preferring Lucene-based search engines over Postgres. I don't know about your alternatives and not saying anything about them.

Django background workers, backported as django-tasks library, the tasks being stored in my database (Postgres). Everything is started by honcho, which starts Superchronic and Django, and Superchronic runs django-tasks. All this (except the database) is running inside single fly.io app.

In my experience it works for a large variety of use cases.

As one of my side projects, I am running a website with 2M page views per month that has been implemented on Django, deployed to fly.io. Another side-project built-in tenant support, and several independent deployments as well.

Yes, those are moderate scale (for modern hardware), but in my experience very few sites really require "webscale". It is far more common to build prematurely for scalability than the opposite. If you have "webscale" problems, then you also have have a custom platform and team working on those.

The context of this discussion is how to build robust systems as fast as possible. My approach fits surprisingly large number of use cases.

I was using Redis and Celery but was not happy with the complexity.

But then I found out that background workers are being implemented to Django.

https://github.com/django/deps/blob/main/accepted/0014-backg...

This functionality has been backported as django-tasks library. You can use the database (i.e. Postgres) as the permanent storage.

For periodic jobs and running the django-tasks, I use Superchronic, which is a Docker-compatible cron. It is compatible with cron, with the added benefit that you can run jobs with sub-minute granularity. I have had no problems with running Superchronic inside my fly.io app.

I run Superchronic and Django with honcho and Procfiles.