You joke, but Rails actually does make Integer do too many things lol. I’d argue they’re useful things, but it does so by patching the core Ruby Integer class :p
Computer guy, occasional gamer, shitty music producer. Denver, CO
You joke, but Rails actually does make Integer do too many things lol. I’d argue they’re useful things, but it does so by patching the core Ruby Integer class :p
Strings became ubiquitously used for a reason, they map really clearly to the way we think as humans. Most importantly, when you’re debugging, seeing string data is much friendlier than whatever data your symbols map to (usually integers, from enum structures)
No, obviously it’s not the most efficient thing in the world, but it hardly matters, and you’re not getting anyone to stop because you’re “technically right”.
I can assure you that Google, an ad tech company with a near monopoly on web browsers, has an interest in eliminating ad blockers in the browser that they have direct control of.
The JetBrains AI plugin wants to be activated so badly, but legal says we can only use GitHub copilot. The copilot plugin is really good so I don’t mind, but we all know the data is going to OpenAI regardless of the plugin. Data sovereignty will only be achieved by running these services locally.
This right here. Get good at navigating code of questionable quality that you didn’t write. If you can’t do it, start questioning your tools, and mastery of those tools. For the big boy jobs, you should be working with existing code much more than writing new code. Learn to get excited by tweaking existing systems with a few well placed, well researched changes, instead of being The Asshole that adds a new abstraction wart.
To me, a corporation cannot maintain quality code because requirements are ill defined, and there is no “done” state. With those two conditions present, unable to be changed, it’s not possible to form a coherent codebase. Those who try will make things worse, because their abstractions won’t fit in a year or two.
This is exactly the “messy code” people then leave behind. Bad code can come about for other reasons too, of course, but this is one of the more annoying reasons, because someone wrote it with self-righteousness, as if they were the only people to truly SEE the problem. Sigh.
It’s fine, this is how enterprise works. You can learn to navigate and make a living from it. You MUST internalize and accept that it is NOT the same as maintaining code for an open source library or whatever people think it’s going to be.
You have to listen to your heart, at least once in your career, to learn that grass on the other side is covered in just as much dog shit as it is over here.
It took me a long time to really grok iterative methods like this, but once it clicks, you will absolutely know and feel like you have unlocked a new super power.
It starts with completely understanding that you are just passing functions as arguments, and those functions are being invoked, in a loop, for each item in the collection. Once you have that concept internalized, you should then learn the difference between filter, map, reduce, etc. The general difference boils down to: 1. How the iterator function changes the value being iterated over (most don’t) 2. What does the iterator function itself return (i.e. map itself, not the function passed into map. map and filter both return a new list, reduce returns the data structure being reduced into)
I would skip trying to understand reduce at first, though it’s the method you can implement all other such iterative functions with. The derivations like map and filter are just easier to start with.
And again, seriously, it took me like 2 years to completely internalize all of this, even after CS classes.
Isn’t it that horrid ugly fucking foot
It’s always been one of my favorite ways of describing the job :)
It’s a huge faff, you will get a different answer from every person you ask. They’re used interchangeably, and it just doesn’t matter.
To entertain your prompt. Real world engineers (structural, etc.) aren’t entrusted the title because they “care” about what they build, it’s because they have to be correct, and as such, they follow extremely rigid process and take the time to never be wrong. Obviously I do not have real world structural engineering experience, but I think we can all agree on this from an outside point of view.
That’s not how software works most of the time, and it’s even heavily discouraged in a lot of the industry. We learn from failure, and the consequences of software failing are nil compared to the consequences of a bridge failing. This is a huge superpower of software, not a weakness, or some sign of deficiency. It is the key reason software evolves so quickly. Software engineers (or developers, alchemists, whatever) are allowed to fail, learn from mistakes, and improve. They can test completely new, never been done ideas, nearly for free, and nearly instantly.
Again, I don’t really care though what the industry wants to call it, developer or engineer. It doesn’t matter and it’s all made up anyway.
Eh, it’s obviously not for most people with that price tag. One huge win for Apple is those that can afford it are few, and extremely dedicated. This small but dedicated user base will be the beta testers for the yet unannounced plebeian version. Either that or they find that there is no money in VR and shut the whole thing down.
The one that comes with the IDE, because I don’t really care.
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’ve heard it much better described as a “distributed monolith”, which makes complete sense to me. It’s what you get when you “break up” a monolith into “services”, but the spaghetti is still there, it’s just distributed across services now. You have to actually eliminate tight coupling, define the correct boundaries, and vigilantly respect them. All of which should happen from within the monolith first, ideally, where you still have the massive luxury of one codebase to deal with as you make the huge refactors necessary before completely decoupling into services. Even better, do this required prerequisite work and discover that your monolith is actually… fine.
Sorry m8 didn’t expand the read more to see that. Good luck
Mistborn is great, less dragons and more alchemical science. Begins with a satisfying tale of overthrowing the government, and then tackles some of the “okay… now what” with tons more interesting stuff along the way
Like everyone has mentioned, because you want the data to persist across program runs. By all means, use in-memory state for truly ephemeral things like caches. You will need both for any real world task.
One more reason to use a database, even if the persisted set of data is small, is the query engine. SQLite is absolutely perfect for such small tasks. Writing SQL to query the data can save you from tons of wastefully repetitive app code.
The code is open source, you read it all, ensure that you download exactly the code you read, and you compile it yourself. That’s the only way, in general, to accomplish this.