vazamb

We are in a similar situation, both working from home. It very much depends on how lazy we are during the day. If musli bowls and lunch plates haven't been handwashed when we start cooking dinner it's a "dishwasher day". We have a half size one, which means one day's worth of dishes fills it up at least 3/4.

I suspect it might be more water efficient and energy efficient to do this instead of repeatedly heating up water, which takes 30s or so and wastes a lot of cold water / hot water that gets left to cool down in the pipes.

I am not a designer/UX person but still thought I would give it a go. I couldn't get through more than 30% of it because of how boring and repetitive it was.

Which also might solve the mystery of why it's only available in the Netherlands? No need to built a different keyboard.

What are the advantages of this over CDK? It's trivially easy to spin up a loadbalanced service https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws...

Petrol stations in Germany make almost no money on petrol. I think it was something along the lines of 2-3 cents/liter. I am quite sure that they will be happy to have customers stay in their shop for longer.

Why this being downvoted:

You need to use a process pool in Python, thread pools are for I/O bound tasks and cannot use more than 1 core.

I would love to know what the problem is. We do dozen of deployments every week with a ALB + ECS + Fargate setup. We upload a new container image, create a new task and launch as many tasks as desired (so if we want 2 containers running we launch 2, for a total of 4). ALB calls the /health endpoints on the new containers and if they pass the healthchecks it drains connections to the old containers and stops the tasks. This has worked seamlessly for a long time now without any downtime during deployments.

EDIT: I should mentioned that we are using AWS CDK for all of this. All it does is register a new task as the default task for a service and ECS/ALB does the rest.

PGMs also provide the intuition behind GANs and variational autoencoders.

I think the better scalability does not come from lambda itself but because you have to design for share-nothing concurrent executions from the start.

I think it is already through libraries. At least for lambda in python you have libraries (Zappa for example) that allow you to write basic flask and Django apps and then deploy them to lambda. These apps can still be deployed the "old" way with no or minor modifications

Hey, I just finished your book. Loved it! I am out of uni already and uses it to brush up.

I find it interesting that one of their major pain points was data schema. After having worked at places that use plain json and places that used protobuf I can highly recommend anyone starting an even mildly complex data engineering project (complexity in data or number of stakeholders) to use something like protobuf, apache arrow or a columnar format if you need it.

Having a clearly defined schema that can be shared between teams (we had a specific repo for all protobuf definitions with enforced pull requests) significantly reduces the amount of headaches down the road.

Taxpayers already pay quite a bit to keep the cash system running. I think it would make sense for the state to provide baseline infrastructure for electronic payments.

It is ridiculous how hard it is to get ANSI keyboards here (Germany). Laptops are ok (Macs, Lenovo and Dell) but external keyboards (especially mechanical ) and any other laptop brand are a huge hassle.

I am glad other people get that feeling too. A lot of pop-sci books are not terribly bad but could be cut down to 1/4 of their length. Another example for this is "Deep work" by Cal Newport. Great idea, something to actively think about. But not necessary to be spread out across 300 pages...

If you are into python I highly recommend Zappa. It turns your flask app endpoints into lambda functions + API gateway. The big benefit here is that it is trivial to test locally because before it gets transformed you can just do 'flask run' and use postman to test the endpoints

There are real-time sensors in the balls. Players are tracked with cameras and ,I think, also sensors in their shoes. We read about a systems developed by a German uni in an event processing class (they generated millions of events per minute) but I cannot recall the name right now.

What are you talking about? Google assistant is entirely ML driven text to speech and sounds great, wavenet by deepmind is almost indistinguishable from human speech.

Not to be confused with an 'Introduction to data science' book

Look at the new Nokia 'matrix phone' 8110. It is a dumb phone with some smart features and most notably 4G and WiFi hotspot functionality. At only 80 dollars or so. I am seriously considering getting one just as an experiment

I highly recommend "Avogadro Corp: The Singularity Is Closer Than It Appears" by William Hertling to anyone interested in some good AI scifi around computer worms/virus.

I honestly felt the same way about "The design of everyday things". The first few chapters are quite interesting but it gets insanely repetitive after a while. To be fair I feel that way about a lot of pop-sci books...

An so it begins... To anyone who has read Daemon by Daniel Suarez this sounds very creepy.

Flatshares ("WG" , Wohngemeinschaft) are extremely common in Germany. For anyone under 30 living in a major city it is absolutely normal to share a flat with 1-3 other people.

But what's to point? You will get a lot of applicants from non-cs backgrounds. Not only will they be unprepared for the job but also most likely very unhappy with their tasks.

I am a happy user of Telegram but I don't think re-inventing ethereum with a small team of developers is a great idea. But then again, using existing tech gives you fewer opportunities for cash grabs...

As far as I understand Wechat pay is more or less PayPal. So no crypto anything.

The parent literally explained how you meet people

You can definitely do non real time stuff in meteor. The server can return data to the client just like a normal express server. Only when you create publications for a query do they auto update. That being said it is still obviously not meant for mostly static websites that are public facing.

The team behind it released version 1.6 just a few days ago, so it is definitely still alive. I haven't used it since a few versions ago but I don't see we it wouldn't still solve the same use case as it did before: making it trivial to build real time collaborative web apps (that don't require extreme scale). With rethinkdb being an unsure bet and graphql not offering the same ease of development I am also not aware of a competing framework. Arguably meteor is getting better and better by integrating more with the broad node/Javascript community.

This sounds like a huge advertisment but I simply thoroughly enjoyed using meteor. If it fits your use case I'd say go for it. You can build the frontend in react and re-use it should you decide to move away from meteor. The amount of backend code you need to write to make all the realtime stuff work is significantly less than with other frameworks, so not much in terms of sunk cost there.