Fair enough. My point in penning the article was simply: "sea level rise to date has been not much, sea level rise yet to occur is a lot". I don't disagree with your argument, that "a whole lot more sea level rise" may be the least of our problems. Although, sea level rise is interrelated with many of the other effects that you mentioned. It will result in a loss of land (duh). A lot of that lost land will be once-very-fertile land. So it will be a big part of the food insecurity picture. Increased salinity will be another bad one, and most of that extra salt will come from the risen-up sea getting into fresh water tables. And that in turn will be a big cause of fresh water scarcity. So, sea level rise is about much more than just "millions of houses (and some entire countries!) will be under water".
Author here. That was definitely not my intent! How can a sea level rise of potentially 1.6 metres (approx 5 feet) within the next 75 years, possibly put you at ease, or sound "very manageable"?!
Author here. No, unfortunately there aren't any such photos that I know of, and that's because even though sea level rise to date is verifiable via reliable measurements, in most of the world the sea level hasn't risen enough to be discernible to the human eye.
In the article, I linked to a number of fact checks of "then and now" photos, that claim to be evidence that sea level rise isn't real, and that have been determined to be false claims.
You should do, and I usually do, both "pure" unit tests (with all I/O - database calls, reading/writing local files, 3rd party API calls, etc - being mocked), and integration tests (with ideally all I/O really happening). More of the former, and less of the latter, in line with the "testing pyramid" approach.
There is value in testing "assuming that the database returns 3 rows with Foo IDs and Foo Descriptions, my code should serve a JSON response containing the Foo IDs and the Foo Descriptions concatenated together". And there is also value in testing "when my code executes SELECT id, description FROM foo LIMIT 3, the real database should return 3 rows with Foo IDs and Foo Descriptions". Granted, there's also a big advantage in that the former can run much faster, with zero environment setup / teardown complexity required. But my main point is, different test suites should test different things.
However, if you're unable or unwilling to write two different test suites, and if you're able to easily and reliably have a database available in dev / CI, then ok, I concede, just write integration tests.
Plus, perhaps the biggest complexity of all is that the currency rates are often not free, particularly if you want "live pricing" (updated every few seconds), and particularly if it's for commercial use. And, the fact that they may or may not be free, also illustrates well the fact that there are no definitive rates, there are only "rates according to X".
Good on you for open sourcing the code. Its destiny may yet be as a hidden gem that makes some peoples' lives better. In which case, not what I'd call a failure.
Feels like OP is basically implementing exceptions and exception handling at the application level. If this is what you want, then why not just switch to one of the many other languages that has exceptions built in at the language level?
Indeed. The central Sydney locality of Haymarket is that in name only. Same for Wheat Road and The Goods Line. Wholesale fresh produce has all been in Homebush / Flemington for years now, barely accessible to anyone without a semi-trailer and the willingness to purchase a truckload. Shipping also long gone from the central spots of Walsh Bay / Barangaroo / Darling Harbour, all now relegated to Container City aka Port Botany.
Relax, folks, entities have plenty of other options, there still won't be support for Do-Not-Shoot, Do-Not-Rape, Do-Not-Stone, fun for the whole family.
Despite the apparently glowing write-up from the time, hailing it as a success, no doubt there were constant cringeworthy "technical issues", of crackly lines, poor volume, calls dropping off, etc - I can well imagine the organisers saying: "we pulled it off once, for the lolz, but only just... Never again!"
Ummm... driving out of my metro area, in any direction, on a work day: zero traffic! Doing so at the start of a long weekend / during Xmas - New Year: horrendous traffic! Is that not the case for you?
Only some of these are really Postgres specific (use "text" / "timestamptz"; make psql more useful; copy to CSV). Most of them apply to relational databases in general (learn how to normalise!; yes, NULL is weird; learn how indexes work!; locks and long-running transactions will bite you; avoid storing and querying JSON blobs of doom). Not that that detracts from the usefulness of this article - pretty much all of them are important things to know when working with Postgres.
I typically try to take annual leave and to travel exactly on the opposite dates to what this tool recommends. That's because I care more about avoiding the significant extra expense, traffic, and crowds of travel over public holiday periods, than I do about getting a few extra "free days" of leave. No free lunch!
The military operates that way with 99% of their personnel, who are grunts, expected to only ever follow orders, to never think for themselves. They're expendable cannon fodder - think of them as pieces of hardware in a software company. But with the 1% at the very top (basically just generals), I'd say the bus factor comes into play, same as in any other organisation - certain individuals have all the knowledge of certain domains, and if enough of those individuals are taken out, the wheels grind to a halt. That's why targeted assassinations happen to the top brass.
Speed cameras have been privatised in NSW, and the rumour is that the private operator is now the one deciding how many of them to install and where to put them. So, forget about all pretence of them being for road safety, they're putting in more of them purely to make money!
Sydney's rollout was definitely not smooth! NSW spent a decade (late 90s - late 00s) trying to launch the "Tcard", after which time they had absolutely nothing to show except wasted $$ millions. Unlike Melbourne, Sydney still had ancient paper tickets well into the 2010s, which weren't even consistent across modes of transport (destination specific "one way / return from x to y" single use tickets for trains, zoned "travel ten" tickets for buses, etc), and which often had to be paid for with exact change in coins (and which often couldn't be purchased in advance). Opal only soft launched in 2012, it wasn't actually available on all modes of transport, for all ticket types, etc, until end of 2014.
Over the years my coder colleagues have been about 95% male and 5% female. Of them, I rate about 80% of the males as producers of quality code, and about 95% of the females as such. That's just my experience and my subjective scores.
It's sad if "lost cities" are becoming so common, that they're losing their romantic-exotic-intrepid charm. If lost cities ain't got it no more, what in this world does?
We could start by at least processing our own steel (we still process some, but not nearly as much as we used to). Newcastle Steelworks, just north of Sydney, was back in the day one of the biggest in the world, but it closed down in the 90s. Nowadays, we ship iron ore (our number 1 export) to China, and literally ship that same material back to Australia as steel. Insane!
Thanks for that nugget of advice! I probably already know it deep down inside, but seldom remember it, and seldom act with that mindset. But yeah, so true. Don't try to make someone give a shit about something that they have no reason to give a shit about. Instead, tell them what's in it for them, then negotiate so there's still something in it for you.
Can / does asterisk-BSD share many hardware drivers with Linux? IMHO that's the only way asterisk-BSD is to have any hope of catching up in the laptop space.
I spent several years in South America, and down there (it varies by country, but by and large) it's totally normal for people to play music on loudspeaker on public transport, walking down the street, in the park, etc, nobody bats an eyelid. The same behaviour in most western countries is met with disdainful looks, and often with someone else blatantly telling the "offender" to put on headphones. So, yeah, it does depend on the culture.
Also Taco Bell, which was absent here in Australia for many years, due to a long-running legal battle[1] with local chain Taco Bill. The first Taco Bell only opened in inner Sydney about 3 years ago (after decades of failed attempts).