qw

Kamelets and the Karavan UI in combination with k8s and Knative for "serverless" integrations looks interesting.

I am in the same situation. I tend to get messages on Slack after hours on work days due to the different work hours, but almost never on weekends and holidays. I assume that an extra long weekend would be more beneficial.

It's similar to how some development choices are made too. Examples: Rewriting the system in a new language, change a framework or create your own from scratch.

I have fallen into that trap myself. I have read about some exciting new tech in a blog and want to try it out in a POC. There may be some excitement around it and suddenly it becomes a MVP and placed into production. Eventually it evolves into "legacy code" that developers hate to touch. The right approach is sometimes to step back, and rewrite the POC in a language/framework that can be supported by others.

That's also why I can't stand some of the modern pixel-games. They are too blocky and doesn't work well on modern screens. Using blocky graphics is not "retro" at all. It's more an artistic impression of how they think old games looked like.

This is also a similar premise: It was not too bad actually:

https://www.imdb.com/title/tt2908856/

Jetbrains support offline activation, using a key. I don't know if it has an expiration date, but it could be a solution.

Web developers may not create their own frameworks as much as game developers, but many spend a lot of time switching frameworks, libraries or simply just rewriting existing applications. I see this tendency at work, where the relatively simple React app has been rewritten 4 times in a couple of years. The recent hires would rather rewrite it from scratch than to refactor / improve the existing one. Apparently, the 5th rewrite will solve all problems with the first 4...

  if (o instanceof String s) {
    var foo = s.indexOf("bar");
  }

Java 17 introduced a preview of the same feature for switch statements

  return switch (o) {
     case Integer i -> String.format("int %d", i);
     case Long l    -> String.format("long %d", l);
     case Double d  -> String.format("double %f", d);
     case String s  -> String.format("String %s", s);
     default        -> o.toString();
  };

Future versions will have improved support: http://openjdk.java.net/jeps/420)

Java's Duration is also useful for time units

    void foo(Duration duration);

    var result = foo(Duration.ofHours(2));

You can also do simple calculations easily

    var bar = Duration.ofHours(2).plusMinutes(30);

You can still get performance issues with a view if you "select *" on a large amount of data, or join with other views. By exposing the SQL to a web page, you also open up for DDoS attacks more easily, as you can write complex SQL queries

You can get the same problems with GraphQL or stored procedures too of course, if the queries are not optimized correctly

I agree with you on general basis, but in this case it seems that Stripe provides a dashboard containing key data. It's not unreasonable to expect that critical payment failures would be displayed as well.

It's always a risk to make assumptions, but I don't think this specific assumption was unreasonable.

Even if you solve the security issue, a query can easily bring down the server if it has a complex join query.

This could be solved by only exposing stored procedures, but that just moves the code to the database server instead of the REST service with the same problems as before.

I see your point, but managing state is not free on the client side either. Frontend frameworks usually come with some built in state management, but once it starts to be more complicated we often need to find a 3rd party library to manage it.

I agree that there are many cases where managing the state in the frontend is the preferred solution. Multi-page forms add complexity for both frontend and backend. Sometimes frontend is less complex, and other times the backend is simpler.

I'll add some comments on your statements regarding backend. I'm not saying it is a better solution than managing it on the frontend for all cases. My point is that although it adds complexity on the backend, it does not necessarily mean that managing state on the frontend is simpler. That depends on the use case, but I think a lot of developers "default" to handling state on the frontend that adds much more complexity than a simple backend solution.

> "rerender previous form pages over and over again, except hidden"

In that case, you would only render hidden <input> fields with the values, and not the complete form. The code for receiving "step x" of the flow, would simply read the parameters from the request and include the values in the html code.

> "have some token to track partial form data"

Using <input> fields for this is much simpler. The final page would just read all variables as if they where posted from the same form, without requiring to generate/parse any tokens

> "build up a DB to store a partially complete form"

Most frameworks have a built in "session" that abstracts this away. It may be stored in a database, file, memory etc. If you require distributed sessions, the framework often handles this transparently by just configuring the session manager to use something like Redis to store the data.

Another game he made, also has an epic soundtrack: https://www.lessmilk.com/gravity-snake/

Most people call it that, but the fund’s formal name is the Government Pension Fund Global

I think the numbers refer to age and not decade. If you are 50 years old and wakes up at 80 your quality of life has dropped dramatically.

NATO did not go to war in Iraq as an organization. That was done by an independent coalition. After Saddam's fall, they did however take part in training the new Iraqi military.

That was the intention of XHTML 2.0.

Header levels would have been derived from the document structure.

    <section>
        <h>Hacker News/h>
        <section>
            <h>Guidelines</h>
        </section>
        <section>
            <h>FAQ</h>
            <section>
                <h>...</h>
            </section>
        </section>
    </section>

You have a valid point, but the article states that they place darks stores in residential areas to decrease the delivery time.

There is a need for these services, but we also need to think about all those who are negatively impacted by this.

By placing the warehouse outside the residential area, they may increase the delivery time by 15-20 minutes. Isn't that a good enough compromise for the customers? Saving 20 minutes on grocery delivery is not worth the human cost.

IIRC they were worried that the private company would be able to patent the results and make the data proprietary.

"last modified" only works for static content, and not pages that are rendered dynamically or where the header is set based on cache settings.

Even for static content, the date may be wrong as the output may have been generated multiple times since it was first created.

> I reached out to a friend at Cloudflare and shortly thereafter, the penny dropped

Another advantage is his big network that he can ask for help. There's also a chance that his blog post will reach the right person in Azure and he'll get a reduced bill.

As someone who doesn't have the same network or the "fame", I am concerned about what would have happened to me in that situation.

As students, they probably have limited insights into what a role is worth. With this tool they can base it on data generated by the industry and get a fair starting point.

This is a great way to avoid ego conflicts. Now they can just refer to the software and say they follow best practice.

Date and time handling is one of the areas that is surprisingly difficult, for something that appears "simple". It tends to cause a lot of frustrations, and I can see this person struggling with all the different use cases and wants the readers to know it's not their fault. Otherwise it could generate questions in support forums.

i have seen some trash cans in Oslo with a separate cylinder for bottles that gives easy access to the bottles. I hope this becomes more popular, so that they don't have to dig through the trash cans.

That has several drawbacks for a business:

1. Due to demands from marketing/sales, the supplier tends to increase versions for what is actually a minor feature, just to justify a new payment.

2. A subscription process is the most honest way of selling software. Jetbrains is a good example of this, where you get to keep your "fallback" version when you stop the subscription.

3. You often have to wait a long time for the next release, if you don't want to register in an "early access" program with versions that break constantly (basically providing free test resources).

4. You need to justify the new version to your boss, so that you can get it covered and start the approval process higher up in the hierarchy.

5. Approval processes in large Enterprises are often complex and time consuming. This not only applies to approving the payment, but often need to involve central IT. With a subscription model, this is only done once.

The machine is completely optional and just there to save time if they get a lot of deposits. They can handle it manually if they want to.

There is a limit to how large the deposit can be for stores without a machine. If you come with a big trash bag with bottles/cans, they have the right to refuse and refer you to a place with a machine (most grocery stores have machines)

The mountain air was probably much dryer.

The air near ice free water will feel much colder due to the increased humidity.

If you have real time analytics, you probably have a way to count visits to that page in the last X minutes. If I was a visitor, that number would be good enough for me. If the site also made it clear that it was not an exact number, it would of course be even better ("10 to 20" or similar)