And github != git, which we're still wrestling with over a decade in to its life. Yet, for some people 'github===git' so that just compounds the issue.
533 karma · joined February 6, 2019
I bet no one even considered the idea that someone in Canada might pay in USD dollars.
I had to... discuss... with someone the possibility that if we were recording money received from a bank, we might do well to record the currency type as well, because... banks can deal with multiple currencies. "No, banks don't do that. That's not possible". This US company was getting ready to expand their services over to Europe, and I couldn't understand why no one could understand that this might be a necessary item to record.
Someone using this system in France to help finance a project in New York, for example, might want to know whether Euros or USD were the subject of the project. This was sort of a PM tool to note the cost of a project and how much was left in a budget - it wasn't moving money directly. We had a system to choose specific banks and note that 'person X moved Y currency units to the project' but... no ability to select the currency units. If it was from a UK bank, it would be GBP. A US bank, USD, etc. I was voted down as not understanding how banks worked.
Months later, a demo was presented right before launch to the people who were financing the project, and they asked how someone would know the currency being used for each project. Back came a work ticket "high priority" because we were already late for launch and multiple screens now had to accommodate this "new" requirement.
I know at least some of this is how I present info, but... being 'nice', being 'inquisitive', raising issues up the chain of command, etc.. rarely work. These sorts of extremely obvious things get ignored until the actual end users bring up the same concern. Somehow I wasn't supposed to know this sort of info because "you're a developer, you're not some international banker". Insane...
> scan disparately located CSS files anyway
usually, I encounter CSS in one of two ways:
1. a main base css file or set of files (from a framework, maybe), and then an override css file. Single override file can get hairy to look through, admittedly, but it's typically in one spot. I rarely come across projects with dozens of standalone css files.
2. 'style-in-components' - primarily in vue, because vue sfc encourages scoped styling - structure, code, style in a single file. Whether that's bootstrap styling ('btn btn-primary', etc) or tailwind doesn't make too much of a difference.
Where I've hit more maintenance issues is coming in to projects with tailwind in say, react or vue - with the 'style in components' - is that "text-xs px-1 rounded-sm bg-gray-200 inline-block text-gray-600 mb-1" repeated across multiple components, is harder to find when I want to replicate something vs just "class='tooltip'"
Of course, we're all doing it wrong, and if we all just 'think different' all the time, and spend loads of time rewriting "wrong" stuff from other people - things will be just fine. But the world I live in, and the world I see a lot of people in - is not greenfield, but brownfield, and we have to live with the decisions others made. Tailwind does not make my life any easier that way, and generally introduces more cognitive overhead earlier in a project when it comes to visual stuff.
class="btn btn-primary" is also pretty easy to read. But in the last couple weeks I've have to deal with both class="bg-blue-500 hover:bg-blue-600 text-white font-bold py-2 px-4 rounded-md shadow-md" style buttons and <LinkButton4 /> and <LinkButton7 /> components, both of which still seemed to be affected by another wrapping container that decided to "text-xs" everything below it, but which wasn't obvious. Trying to simply add a 'button' that had the same styles around it was far more work than it should have been.
No doubt, I'm somehow in a minority of switching between projects/codebases more often than other people. But this was much less of a problem with bootstrap and related definitions.
> your engineer should just encapsulate all the “ridiculous” styling into a <Button /> element.
When you want, say, most things to share some common color/style definitions, you will still end up repeating a lot of stuff (same long string for buttons, and for headers, etc). The tailwind system gives you the option of @apply, but the tw docs are also relatively strongly against it, for ... I can't really understand the reason why.
https://tailwindcss.com/docs/reusing-styles
> If you’re going to use @apply, use it for very small, highly reusable things like buttons and form controls — and even then only if you’re not using a framework like React where a component would be a better choice.
There's some reasons listed on that page justifying "don't use @apply!" but... they don't ring all that useful to me. They do say "well, you could do it for reusable things like buttons", but those are the very things that most tailwind examples use longhand examples for.
> Yes, HTML templates littered with Tailwind classes are kind of ugly. Making changes in a project that has tons of custom CSS is worse.
There's a balance between the 'ugly' (their words) and 'tons of custom css'. Everyone's balance is different, I get it, but I'm usually having to come in after someone who was jazzed about tailwind has moved on and left me the 'ugly' (their words) mess. If every link should have "text-dark font-bold font-xs"... @apply that with an understandable name. Or document your design decisions...? But that conflicts with "ridiculously fast to build". Documenting them in an '@apply' way would let me see how you want some styles grouped together without having to scan through dozens of your components looking for a pattern.
possible good news is that we'd been forced to use more machines a few years ago due to some IT policy about databases not being colocated on the same physical instance as the application(s) accessing it, which forced multiple servers when fewer were needed. I was told that's not a hard requirement any longer, which may allow us to consolidate some pieces during a rebuild.
Their 'support' largely consists of
a) giving ridiculously small and unchangeable /home and /usr partition sizes,
b) randomly logging in at unannounced times to add more logging and monitoring tools in to /home and /usr (then rebooting, also unannounced),
c) sending sporadic emails telling us to clean up our system because we are dangerously low on drive space in /home and /usr.
Got a message the other day stating that they power down our machine in 2 days unless we freed up drive space because 'low drive space can impact system availability and security'. Powering it down also impacts availability, but that point seemed lost on them.
EDIT: Realizing now that ... our RHEL 7 will expire at end of month. We've had 0 communication from them about this. Annoyed because when I'd requested this machine back in 2021, asking for RHEL 8, I was told "we don't officially support that", and now we're going in to EOL territory because of RHEL 7. I'm expecting an "hair on fire" email in early July indicating our machines will be shut down shortly without an immediate upgrade, that we will be forced to do ourselves (because upgrades fall outside 'support').
Interesting. I came of age before debuggers were a 'thing' available to common kids at home (80s BASIC, etc). As I've worked in various environments over the years, debuggers are nice when available, but they're not always available. Code is only running in production, you don't have full access to a debuggable environment, company won't pay for tool X, etc. print/log statements always work, regardless of what tool/language you're working with. Or... 'always work' enough of the time that it's not surprising it's a common theme.
I jump between client projects relatively often (consulting) and while I do use debuggers, I don't use them exclusively (perhaps no one does?). The longer I'm in a codebase, the more likely it will be that I'll end up with a full debugger setup and get comfortable stepping through all the bits.
I've not been in many companies over the years - mostly worked independently - but in the companies I've been in, that was never on the cards. Ever. I don't doubt it exists, someplace, but never saw it in person. Bit of a shame, as it sounds nice.
Yes... it's a bit /s, and perhaps is a bit much, but... this "my language has no defects!" attitude from everyone crapping on PHP is tiresome. I've been programming as a hobbyist since the 80s, and professionally since the early 90s. Nothing is perfect, everything has warts, the holy wars suck. I've been with PHP since early 96, and have worked in ASP, .NET, Python, Ruby, Java/JVM, Node/JS, and a couple other stacks. They all suck in more than a few ways.
For those of you who only ever work in one tech for years without needing to touch anything else... and get to perfect your parameter-order-fu down to a reflex... great. I'm routinely having to switch between different SQL and various server-side languages, and even then ... 'obvious' things like array/string handling have different syntaxes I have to jump between in a single day. (postgresql arrays are 1-based, not 0-based, IIRC). You know what? I deal with it and move on. IDEs/tools help. Memory helps. Nothing is perfect.
Public libraries? With easy access?
Every time I've been in a group where nosql was desired, it was because they saw it at a conference, or watched a youtube video, or read some blog extolling nosql virtues, and... yeah - that second option. They'd either never actually used nosql, or didn't realize what they were getting into, possibly because even if they'd used it, the larger architecture had SQL in it someplace, just outside what they could see.
Umm... why would you not choose a relational engine to start with? This isn't said with the benefit of hindsight. I worked with Lotus 123 back in the early 90s. I get that there's value in document databases, but even then, there were limitations, and the need for the ability to have structured/related data in an engine that easily allowed for ad-hoc queries out of the box was apparent.
I watched the entire nosql/mongo movement arise and evolve over time, and it rarely made sense to me. Even when mongo made sense for a problem... it only makes sense for that problem, and not as the primary basis for your entire application. Relational/SQL, with nosql/mongo/etc as secondary/ancillary data store has always made the most sense (imo).
JSON columns in major databases now tend to provide a pragmatic balance of "good balance for many use cases". Justifying something other than that as a starting point is possible, but I've rarely seen cases where it makes sense to avoid a decent SQL engine as the core data store for your business apps.
1. It can save a lot of repetitive boilerplate code
2. You can keep validation rules in one spot.
I've been working with some toolkits like these after years of 'backend api, frontend vue/react/angular' and it definitely can save a lot of time. It's not always the best fit, but there isn't one approach to all applications that is the best fit. Everything has tradeoffs.
I've tended to think this way, but it's all relative. Plenty of people who've never had a $50k job will treat the $100k job as the baseline/minimum, and wouldn't ever think of going the extra mile like you do. For you (and me?) - yeah, you're paying "a lot", I'll make sure I do a bit extra/more when needed. But if you've never had less, that $100k is your bottom, and you might only consider doing 'extra' for a $200k job.
But the collection and remittance of the taxes to the specific taxing authorities is a whole other ballgame. Whether or not you see "$499 + $17 + $12 + $34" or you see "$571" on an item... the 'correct' amounts need to be identified, accounted for and sent to the specific taxing authorities. Doing that well enough, at scale, is not trivial, depending on where you're selling to, and how much.
The biggest issue we've seen in software was the 2017 tax act, affecting software R&D starting in 2022. Depending on how you classify those expenses, you could have a sizeable tax bill, even without any 'profit'. But even hardware - that's typically going to be amortized over minimally a few years.
Bring in $200k in revenue. Spend $20k on hardware. You may only get to deduct $4k of that hardware expense in each of the next 5 years.