Random question… RPI, in my jargon, stands for role-play intensive, and it’s a category of MUD engines… are you working on such a project? Because I’m probably in the commit history, and that’d tickle me.
My wife got prescribed Ambien a few weeks ago. She took one, completely forgot about it, and 45 minutes later had a glass of wine with me while watching Taskmaster.
She then became convinced that she was actually on the show and went around the house asking me to time her doing random stuff. Th next morning she had zero memory and was floored when I showed her the video.
I’m in my first professional role and the first project was completed and aside from my boss I was the only other dev. So I was naturally excited for their (clients) feedback on it.
Well fast forward a couple of months where they really didn’t interact with the application much and then came the queries and then not understanding how to use it. Find boss sets aside 10 days for me to write some documentation with screenshots of all the journeys (free of charge).
Again, tumbleweeds. Then all of a sudden it’s boom emails a plenty.
Can you fix this, this is a major bug kinda emails. Like it isn’t a bug, you don’t know how to use it.
Now we are dumbing down the software to make it more align with what the business is used to, which is fine but even my boss has said (as I over think and want to reply to things instantly) that just because they have come to life doesn’t mean we drop everything else to tend to them now.
that just normal software development with contacts and waterfall. usually with agile it’s meditated to some extend, because with agile the customer is on board and cannot say afterwards i didn’t want it.
Welcome to the professional world where everything is iterative and and 95% of your clients (internal or external) are data illiterate and don’t want to learn whatever self service tools you build.
Yeah it’s going to wild I can already tell. I know your right to as it’s only a small company I work for, less than 10 of us and they all complain about stupid things the clients do.
I have a colleague who is the contact for a dude that takes a picture of a site with his phone, so he photographs the monitor. Which I know isn’t that unusual, but wait.
He then emails this to himself, perhaps to have it on his desktop. Proceeds to print off the image, but not just the image, but the image as it appears in the email. THE ACTUAL EMAIL.
Then he will annotate the printout and I shit you not, will take another photo, but this time of the printout. Inception level shit.
Behind every ❗️❗️❗️🚨🚨🚨URGENT🚨🚨🚨❗️❗️❗️ there is a person who’s about to miss a deadline and, instead of working on themselves to prevent that from happening in the future, makes it the developer’s deadline to miss
And the data they want is the entire FY, is 3,000,000 records and they need every single data attribute making the file like 250 MBs. Then you put it in their SharePoint and they get mad they can’t just view it in the browser despite the giant “This file is too large to view online, download it” message.
Newspaper: Hackers are announcing a trove of personal data leaked from [company] after a forwarded spreadsheet inadvertently contained more data than the sender realised.
A view is a saved query that pretends it’s a table. It doesn’t actually store any data. So if you need to query 10 different tables, joining them together and filtering the results specific ways, a view would just be that saved query, so instead of “SELECT * FROM (a big mess of tables)” you can do “SELECT * FROM HandyView”
Basically scripts you can run on the fly to pull calculated data. You can (mostly) treat them like tables themselves if you create them on the server.
So if you have repeat requests, you can save the view with maybe some broader parameters and then just SELECT * FROM [View_Schema].[My_View] WHERE [Year] = 2023 or whatever.
It can really slow things down if your views start calling other views in since they’re not actually tables. If you’ve got a view that you find you want to be calling in a lot of other views, you can try to extract as much of it as you can that isn’t updated live into a calculated table that’s updated by a stored procedure. Then set the stored procedure to run at a frequency that best captures the changes (usually daily). It can make a huge difference in runtime at the cost of storage space.
It can really slow things down if your views start calling other views in since they’re not actually tables
They can be in some cases! There’s a type of view called an “indexed” or “materialized” view where the view data is stored on disk like a regular table. It’s automatically recomputed whenever the source tables change. Doesn’t work well for tables that are very frequently updated, though.
Having said that, if you’re doing a lot of data aggregation (especially if it’s a sproc that runs daily), you’d probably want to set up a separate OLAP database so that large analytical queries don’t slow down transactional queries. With open-source technologies, this is usually using Hive and Presto or Spark combined with Apache Airflow.
Also, if you have data that’s usually aggregated by column, then a column-based database like Clickhouse is usually way faster than a regular row-based database. These store data per-column rather than per-row, so aggregating one column across millions or even billions of rows (eg average page load time for all hits ever recorded) is fast.
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.