tda

Add a Pms5003 and a bme280 and you can measure temperature, humidity, air pressure, CO2, and PM10 (particulate matter) all for about $45

I sometimes see biodegradable packing peanuts that resemble tasteless Cheese puffs used as alternative. So much better, I wonder why the styrofoam puffs are even still allowed.

Another side note, look at this sign that I've seen aboard vessels: https://vesselplacards.com/product/garbage-overboard-marpol-...

It basically states "Don't throw garbage overboard, You could be breaking the law" as if it being illegal should be the only reason not to dump your waste in the environment.

Either you know what you are talking about or read the article, as that is spot on

In postgres I would use tsrange to make it very explicit if I want to include the edges or not: '[2018-01-01 00:00:00, 2019-01-01 00:00:00)'::tsrange @> '2018-01-01 00:00:00'::timestamp

https://blog.constellation.com/2018/09/21/energy-efficient-d... gives a ballpark number:

"In order to be approved by ENERGY STAR®️, energy-efficient dehumidifiers must have an energy factor of at least 2.00, or an energy factor greater than 2.80 for dehumidifiers that remove more than 75 pints of moisture a day."

So 2-3 litres water extracted per kWh electricity consumed (And I'm guessing this is probably in best case damp conditions).

the link is about humidifiers, not dehumidifiers

That's not entirely true; slow (< 30 km/h) cyclists using the bike as utility to get somewhere almost never wear a helmet here. Spandex wearing speed cyclists almost always do though.

And the best ways to get rid of these errors is to visualize them like done here!

And even better, you can view the underlying data as a 3d point cloud here: (crashed my Firefox on mobile) http://potree.entwine.io/data/ahn.html

I'm guessing the cable has an esp8266 on board which you can get cheaply and is only a few mm2. It has WiFi and WiFi direct support and is powerful enough to run a webserver. Probably there are plenty chips that do the job, but the esp8266 (and its successor esp32) is very popular for custom hardware due to being cheap and easy to program

this are dev boards. Just look here for example: https://www.aliexpress.com/item/32656775273.html, the nodemcu dev with USB for 3,55. You can even get a fully working board with a webcam for under 5 bucks (though that does need a UART bridge, no usb included). Unmounted esp32 chips are going for as low as 2,10

Last year maybe, but I just bought a few for €3.80 each and €0.40 shipping from aliexpress.

Actually esp32's are quite fun and easy to program with micropython. Something like this project should be pretty straightforward and would arguably much easier than a pi. For micropython there is only the python code, no docker containers, Linux maintenance etc. And remote development can be done over a an http repl or even using jupyter notebooks (still have to try but just read about it). Doesn't get much better than that I think

If you grab something from an external service (say a cdn) then I believe by default the referrer will contain the url + query params, but not you X=supersecret header. Bit me once

Don't forget the $150 dlc, that is probably not included. And the base game is pretty minimal

Very nice article! Explores all the tricks I know of, and a few more. Never heard of the execute_values before, only a bit (3x in the example) slower than using copy but much simpler code.

For me the big advantage of doing more in docker and lees in the CIT environment is that I have less lock-in/dependency to whatever my CI provider does. I try to reduce my CI scripts to something like

    docker build
    docker run image test 

All complexities of building and collecting dependencies go in dockerfiles, so I can reproduce it locally, or anywhere else. And importantly, without messing with any system settings/packages. No more makefiles or shell scripts that make a ton of assumptions about your laptop that need to be set just right to build something from source; just docker build and off you go. Such a hassle when you need to follow pages of readme just to build something from source (plus a lot of installed dependencies that you have to clean up afterwards)

I have both a fast electric bike and a normal bike. For the electric bike it indeed takes a minute or three to unlock, enter pin code on bike, put on helmet etc. That's why I prefer my normal bike for short distances, takes me 10 seconds to lock, and I can usually park it within 10m of where I want to be. There is really no faster way to get around in any Dutch city for say <2km, than a plain old bike. If I would go to the local supermarket it would take me longer to find a parking spot that the entire bike ride there.

The solar roof for running a fan has been around since the 2010 prius.

It seems that is because an Iraqi oil engineer with the right foresight was at the right place at the right time. Fascinating story! https://news.ycombinator.com/item?id=19594153

Is it just me or are the climate change deniers a bit less vocal recently? I recall them being much louder on their denial, but this summer they seem to have become less mainstream

Interesting how the total installed capacity is pretty respectable at 96GW, even though there are only 5 turbines above 5MW. In Europe the 7,5 MW Enercon onshore turbine is fairly common, and offshore the 8-10MW turbines are very much in fashion. For reference, the EU has 179GW installed as of 2018 https://en.wikipedia.org/wiki/Wind_power_in_the_European_Uni...

They're east of NY, at the tip of long island

My kids get nervous as soon as they even see a hand dryer. They start crying when it's on. I thought they were exaggerating, it never occurred to me that sound levels for kids are different because they are smaller (though it makes complete sense). That, coupled with higher sensitivity to noise and more delicate hearing canals of youngsters kind of make me feel like a bad parent for trying to let them use the dryers anyway (Even though I have long since given up). This kids research proves my kids right, and I am not easily convinced ;) Great accomplishment for I should listen to my kids.

Already an impressive combination of curiosity and perseverance to get a scientific paper published for any non-academic, let alone a 13 year old!!

edit: The absolute worst things are these https://www.ehanddryers.com/hand-dryers/tap-hand-dryers, my kids just plain refuse to wash their hands out of fear of accidentally triggering the dryer

Here in the Netherlands at least standard onshore windturbines are in the 2-4MW range (but up to 8MW is installed), and offshore 7-10MW is now standard.

However the pandas source is not blackened, and I really miss not be able to just fix all formatting issues while working on a PR. After just a few months I am so used to black it just feels weird to not have it everywhere

I found the writings of Peter Hintjens (creator of ZeroMQ) very inspiring, where he describes the merits of Optimistic merging (OM). Quoting at length from http://hintjens.com/blog:106:

Standard practice (Pessimistic Merging, or PM) is to wait until CI is done, then do a code review, then test the patch on a branch, and then provide feedback to the author. The author can then fix the patch and the test/review cycle starts again. At this stage the maintainer can (and often does) make value judgments such as "I don't like how you do this" or "this doesn't fit with our project vision."

In the worst case, patches can wait for weeks, or months, to be accepted. Or they are never accepted. Or, they are rejected with various excuses and argumentation.

PM is how most projects work, and I believe most projects get it wrong. Let me start by listing the problems PM creates:

    It tells new contributors, "guilty until proven innocent," which is a negative message that creates negative emotions. Contributors who feel unwelcome will always look for alternatives. Driving away contributors is bad. Making slow, quiet enemies is worse.

    It gives maintainers power over new contributors, which many maintainers abuse. This abuse can be subconscious. Yet it is widespread. Maintainers inherently strive to remain important in their project. If they can keep out potential competitors by delaying and blocking their patches, they will.

    It opens the door to discrimination. One can argue, a project belongs to its maintainers, so they can choose who they want to work with. My response is: projects that are not aggressively inclusive will die, and deserve to die.

    It slows down the learning cycle. Innovation demands rapid experiment-failure-success cycles. Someone identifies a problem or inefficiency in a product. Someone proposes a fix. The fix is tested and works or fails. We have learned something new. The faster this cycle happens, the faster and more accurately the project can move.

    It gives outsiders the chance to troll the project. It is a simple as raising an objection to a new patch. "I don't like this code." Discussions over details can use up much more effort than writing code. It is far cheaper to attack a patch than to make one. These economics favor the trolls and punish the honest contributors.

    It puts the burden of work on individual contributors, which is ironic and sad for open source. We want to work together yet we're told to fix our work alone.

Now let's see how this works when we use Optimistic Merge. To start with, understand that not all patches nor all contributors are the same. We see at least four main cases in our open source projects:

    Good contributors who know the rules and write excellent, perfect patches.
    Good contributors who make mistakes, and who write useful yet broken patches.
    Mediocre contributors who make patches that no-one notices or cares about.
    Trollish contributors who ignore the rules, and who write toxic patches.

PM assumes all patches are toxic until proven good (4). Whereas in reality most patches tend to be useful, and worth improving (2).

Let's see how each scenario works, with PM and OM:

    PM: depending on unspecified, arbitrary criteria, patch may be merged rapidly or slowly. At least sometimes, a good contributor will be left with bad feelings. OM: good contributors feel happy and appreciated, and continue to provide excellent patches until they are done using the project.
    PM: contributor retreats, fixes patch, comes back somewhat humiliated. OM: second contributor joins in to help first fix their patch. We get a short, happy patch party. New contributor now has a coach and friend in the project.
    PM: we get a flamewar and everyone wonders why the community is so hostile. OM: the mediocre contributor is largely ignored. If patch needs fixing, it'll happen rapidly. Contributor loses interest and eventually the patch is reverted.
    PM: we get a flamewar which troll wins by sheer force of argument. Community explodes in fight-or-flee emotions. Bad patches get pushed through. OM: existing contributor immediately reverts the patch. There is no discussion. Troll may try again, and eventually may be banned. Toxic patches remain in git history forever.

In each case, OM has a better outcome than PM.

In the majority case (patches that need further work), Optimistic Merge creates the conditions for mentoring and coaching. And indeed this is what we see in ZeroMQ projects, and is one of the reasons they are such fun to work on.

If you really must use a mapping table, I think you could put a unique constraint on both of the foreign key columns too the mapped tables. That would enforce that every row in one table maps to at most one row in the other

If I understand correctly you are describing a one to one or one to many relationship. The canonical way to express that is 'don't use a mapping table'. Mapping tables are for many to many relationships. So why is there a mapping table in you example, and could you just get rid of it altogether?

Very excited to try this out! Would be so nice if you can just checkout some repo and have a completely ready to go development environment available directly. No more hassle with versions of linters, runtime or whatever to get a development environment set up, but be productive from the start.