860 karma · joined June 4, 2013
At least one person had brought their extension cable and was charging via their cabin's electrical outlet.
It's not uncommon for me to interview him on almost every ticket, writing extensive notes with clarifications on his instructions and to fill in gaps.
I don't see anything necessarily wrong with having to write notes. I think that's part of a healthy work process. I just think it happens too often.
It's partly due to the fact we do not have a very organized system, but also due to him not valuing writing as a tool to enhance his work.
I believe the average developer should care somewhat about performance, and depending on their industry they might need to care a lot, but I'm not so convinced for the average case.
The average developer is not working on FAANG-sized codebases. Also, I'd imagine any large systems built up over the years that are refactored would likely see great performance gains. That's just the nature of long-term software.
CREATE TABLE data_a AS (SELECT 'a' AS test_case, 1 AS value);
CREATE TABLE data_b AS (SELECT 'b' AS test_case, 2 AS value);
CREATE TABLE data_prod AS (SELECT NULL AS test_case, prod_table.value FROM prod_table);
CREATE VIEW data AS (SELECT * FROM data_a UNION ALL SELECT * FROM data_b UNION ALL SELECT * FROM data_prod);
CREATE VIEW complicated_query AS (SELECT test_case, value+1 FROM data);
-- when testing
SELECT * FROM complicated_query WHERE test_case = 'a';
SELECT * FROM complicated_query WHERE test_case = 'b';
-- when in 'production'
SELECT * FROM complicated_query WHERE test_case IS NULL;I distinctly remember in previous versions watching the AI aircraft bounce off the ground repeatedly in an attempt to reach an incorrect flight level given to them by the ATC. That kind of ruined the illusion for me.
It's a great sim, overall, I think it has a different set of priorities from MSFS, which is totally fine. I only wish I could have the best of both worlds.
I've been car-free for at least five years. To be fair, I live in a city that is friendly towards alternate transportation. I bike or use my own electric scooter. I plan ahead and book a rental when I know I'll need a car. So far it's been cheaper than owning, and has saved me thousands of dollars.
It's these sorts of shenanigans that I'm glad I don't have to deal with. Paying outrageous amounts for insurance is another. Not to mention parking headaches, the constant threat of high-speed, potentially fatal, accidents, or expensive maintenance.
For instance, a "top 10" function that could be re-used on any table (apologies for my pseudo types and code):
selectTop10 : Column -> Table -> Table
selectTop10 orderByColumn table =
SQL.selectAllFrom table
|> orderDescBy orderByColumn
|> limit 10
limit : Int -> Table -> Table
limit n rows =
SQL.limitBy n rows
orderDescBy : Column -> Table -> Table
orderDescBy orderByColumn rows =
SQL.orderBy [orderByColumn] SQL.Ordering.Desc rowshttps://www.theweathernetwork.com/gh/news/article/stronger-j...
Okay, well, you just said it doesn't work, but you still want (simpler) testing?
I have nicely tiled widgets with CSS grid that displays real-time bus arrivals and current hourly weather forecast. I'm going to add live streams from my IP cameras around my place. Some kind of calendar widget would be nice too, to remind me of important events at a glance.
For a maintenance programmer, they may already understand how everything works. They aren't following a particular code path, necessarily. Maybe they're working on a new feature and they need to re-familiarize themselves with previous chapters. It that case, it's nice to jump to a file that concerns itself with things grouped together.
I genuinely can't tell if you're being serious or not. If you are, do you also like to read books written as one giant chapter? Or entire chapters as one giant paragraph?
So I was hoping PRQL might have some sugar like that.
It'd be nicer for my brain if I could treat any select like a function that transforms a set. Instead, even with PRQL, I'm stuck examining source tables and fully understanding them before being able to understand the query.