A highly compatible design with no ads, unnecessary images, videos, animations, scripts that goes straight to point delivering you exactly the information you need and nothing else? Something that’s easily accessible even with old feature phones allowing older people to get information easily?
Simply something that loads instantly and just works?
I’m currently working on a little project that’s interesting to me (a low-spoiler walkthrough system for adventure games) and after a lot of back and forth, I decided to cut all of JS out of the picture. Just get rid of all of it, and do good old 90s server-side rendered HTML with modern CSS placed on top of it.
And that’s, honestly, a joy. The first draft of a page looks like the first screenshot, then you add some semantic classes to the html and throw some simple CSS at it and it looks acceptably neat. And I could get rid of so much janky toolchain I just fail to understand.
yeah, just css is enough.
you don’t need js unless you need to fetch data dynamically.
you can do all of your animations, dropdowns and transitions in css.
like this menu i made. no js in sight.
Does Discord now offer the ability to save/fav comments to find them again? When I used it the last time, i was amazed how everything just scrolls by without a possibility to hold on to something.
How is that the same than a favorite? I can also use a searchengine to find a website, but a bookmark is sometimes better. I can also search through all tweets on twitter, but having some marked as favorites come in handy sometimes. I use favorites and save lists in youtube quite a lot. Even though I could use the yt search bar each time.
Since being forced to use this terrible communication method in my teams and groups, I’ve been copy-and-pasting good Q&A threads into text files that I push to an enterprise GitHub repo for perma-store. At least that way other engineers and myself can either use GitHub’s search or clone the repo locally, grep it, and even contribute back with PRs. Sometimes from there, turn into a wiki, but that’s pretty rare. My approach is horribly inefficient and so much stuff is still lost, but it’s better than Discord’s search or dealing with Confluence.
At my job we bought an entire different product (glean) and are paying them a ton of money every month just because they can search our confluence wiki effectively lol
Next hardware reset and automatic reorientation for Voyager 2 is October 15th. Yes the device automatically resets itself about four to five times a year. Communications are expected to be reestablished then.
My amusement comes from the fact that in most cases a gender input field is just an invasion of privacy, juxtaposed against these ridiculous over implementations. My favourite is the gender fluid one.
What bugs me is: why in the fuck are they asking for people’s gender? Other than medical questions (where you specify your birth gender), I think for the vast majority of cases the question should not be relevant.
Read… instructions? I love teaching people that git very often prints out what you should do next.
git: “to continue, resolve conflicts, add files, and run rebase —continue”
dev: …time to search stack overflow
All that said… just use lazygit. It does help to know CLI git first to put things in context, but if you do, no need to punish yourself every day by not using a UI.
I’m quite aware… basically it means that novice devs can create a table in camelCase and query in camelCase… but you can clean it all up as long as they didn’t realize you needed double quotes.
Fair point. I always disliked the design because ORMs pretty much always use quotes, so an entity-first approach can create a lot of tables with capital letters if you’re not careful, which is then really annoying if you need to use raw SQL for anything.
It’s an English literacy thing - we have several non-native English speakers and using only singular avoids making those folks’ lives harder. Besides it’s really nice to autopilot that categoryid is a foreign key to the category table. It also simplifies always plural words… I haven’t yet written CREATE TABLE pants but if I ever do there’s zero chance of me creating a pantid.
I tend to use underscores on join tables so table foo_bar would have a fooid and a barid. I have somewhat soured on this approach though since there are a lot of situations where you’ll have two m-m relationships between the same two tables with a different meaning… and having a fixed formula for m-m tables can make things ugly.
If I get to design another greenfield database I’ll probably prefer using underscores for word boundaries in long table names.
I believe this has been proven. It’s because capital letters all have the same shape whereas lower case letters do not. So your brain can take shortcuts to reading lower case but cannot with upper case.
Also most if not all editors will highlight SQL keywords so it’s probably not too hard to discern SQL commands and everything else in modern day.
Sorry, to clarify, not everything is in all caps. I’ll append my prefered syntax below
<span style="color:#323232;">WITH foo AS (
</span><span style="color:#323232;"> SELECT id, baz.binid
</span><span style="color:#323232;"> FROM
</span><span style="color:#323232;"> bar
</span><span style="color:#323232;"> JOIN baz
</span><span style="color:#323232;"> ON bar.id = baz.barid
</span><span style="color:#323232;">)
</span><span style="color:#323232;">SELECT bin.name, bin.id AS binid
</span><span style="color:#323232;">FROM
</span><span style="color:#323232;"> foo
</span><span style="color:#323232;"> JOIN bin
</span><span style="color:#323232;"> foo.binid = bin.id
</span>
The above is some dirt simple SQL, when you get into report construction things get very complicated and it pays off to make sure the simple stuff is expressive.
I’ve seen both approaches and I think they’re both quite reasonable. An indented join is my preference since it makes sub queries more logically indented… but our coding standards allow either approach. We’ve even got a few people that like
<span style="color:#323232;">FROM foo
</span><span style="color:#323232;">JOIN bar ON foo.id = bar.fooid
</span><span style="color:#323232;">JOIN baz ON bar.id = baz.barid
</span>
I understand it as an attempt to get very basic, manual syntax highlighting. If all you have is white text on black background, then I do see the value of making keywords easy to spot by putting them in all caps. And this probably made sense back when SQL was first developed, but it’s 2023, any dev / data scientist not using a tool that gives you syntax highlighting seriously needs to get with the times
Well then use all-caps keywords whenever working on those systems, I don’t care. But an edge case like that shouldn’t dictate the default for everyone else who doesn’t have to work on that, that’s all I’m saying.
There are several cases where you'll be limited to console only, or log files, or many many other situations. Good coding practices just makes life easier all around.
JetBrains IDEs - IntelliJ, WebStorm, PyCharm, GoLand, etc., all support highlighting SQL embedded in another source file or even inside markup files like YAML. Does your IDE not support this?
As the other commenter said, the Jetbrains IDEs do this perfectly fine. Although I’d also argue that if you’re working with SQL from within another language already, a DSL wrapper is probably gonna be the better way to go about this.
Unfortunately RustRover is still garbage for actual usage. And I refuse to use an ORM when I can just write the SQL in a more common syntax that everyone understands across every language instead of whatever inefficient library-of-the-week there is. Raw SQL is fine and can be significantly more performant. Don’t be scared.
I’m not talking full blown ORM here, not a fan of those either. I’m talking about some light weight wrapper that basically just assembles SQL statements for you, while giving you just a little more type safety and automatic protection against SQL injection, and not sacrificing any performance. I’m coming from the JVM world, where Jooq and Exposed are examples of that kind of thing.
I’m currently using SQLx which you write raw queries in and it validates them against a currently-running db, using the description of the tables to build the typing for the return type instead of relying on the user. It makes it pretty hard to write anything that supports injection
Happens at compile time! It’s relatively quick. You can also run a command to write the query results to file for offline type checking which is mostly useful for CI
My ide isn’t limited to color when it comes to highlighting, so being color blind generally shouldn’t be a problem. Set keywords to underlined, bold, italic, whatever works for you.
Your other examples I can see, but at least at my work those are rare edge cases, and I’d rather optimize for the brunt of the work than for those. Of course at other places those might be much more of a concern.
Partially, yes. I personally use an IDE with excellent syntax highlighting and those have been around for at least two decades. You are, however, often transplanting your SQL between a variety of environments and in some of those syntax highlighting is unavailable (for me at least) - the all caps does help in those rare situations.
More importantly though it helps clearly differentiate between those control keywords (which are universal) and data labels (which are specific to your business domain). If I’m consulting on a complex system that I only partially understand it’s extremely helpful to be able to quickly identify data labels that I’m unfamiliar with to research.
I got volunteered to fix printer driver issue for a family member. The had one printer, and got another bcz the first one broke. New printer wouldn't work so they just kept installing the drivers. The software gladly let them. Thankfully only took 15 mins to fix, but I told them printers are for bitches, me and my home print at the library.
programmerhumor
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.