nah the term sequel way predates MSSQL. SQL was *originally* SEQUEL and they removed the extra letters to make SQL

Hmm...Structured English QUEry Language. According to wikipedia changed because SEQUEL had a trademark for something else.

When I first started using SQL in the early 90s the pronounciation was very much a UK/US divide (with the UK in the ess-queue-ell camp).

Is this some US specific thing?

I can't remember anyone ever pronouncing it sequel, not in a professional context nor in university. It's simply been taught as S-Q-L aka Structured Query Language here.

Anyone use nestjs? Proly gonna get to build a small app with it as backend. Kinda excited.

Looks kinda like Spring on top of node/express?

I like it a bit for typescript apps although I always feel like the injection stuff is a bit much in node. Checkout foalts for a much smaller one

If you guys ever have a REST in/REST out node orchestration layer and want to try my framework, I will be your personal advisor in getting it up and running. It's very minimal and pretty sweet imo. Battle-tested in our production app for many years.

Although I just realized I spelled gaur wrong. Ugh.

So that's essentially just for a gateway service to join all data sources into one for the client?

I'm currently building a similar use case in graphql

Yeah basically - it can make the back end REST calls in parallel, or in sequence, or a mixture of both.

I started a plugin system to add in other kinds of asynchronous back-end data gathering - mainly various DBs. But I never had a concrete use case so I never finished it.

Graphql makes a lot of sense if you can control the data sources. I'm not sure it makes as much sense if you don't own the back-end data APIs. Although maybe it works there too.

So here's something that is just mindblowingly frustrating. It's friggin 2019 and there's no way for JavaScript to open the print dialog for ie11 and edge.

Printing was made illegal in 2017

I get an anxiety attack every time I have to print something at work.

I finally remembered which printer it goes to most of the time. But the printer's new trick is to not print until I stand over it and tell it to use the tray that it knows has letter in it. So for the first few times I assumed my (usually sensitive personal item) must have gone to another printer, and went scrambling around the office to find it.

Now I know the printer's clever game, so it's just one extra step. But it still annoys me to no end for some reason. YOU KNOW THERE IS LETTER PAPER IN THAT TRAY - WHY IN THE **** DO I HAVE TO CLICK A BUTTON TO TELL YOU TO USE IT EVERY SINGLE TIME???

I don't even try to print things at home anymore. I know the printer I never use will be out of cyan - which will send me into an instant blind rage and ruin my day. I just print things at work or go to kinkos if I have to.

When I first started working at home (and thus couldn’t use work printers) someone gave me the good advice of going with a black and white laser printer. It saves so much money because cartridges last for years. And honestly, who actually needs to print in colour?

I wish I'd gotten that advice.

All these jackass startups trying to disrupt workout shorts, toothbrushes and hoodies on my FB feed. How about disrupting printers? Hey here's a printer that doesn't suck and isn't just a scam to sell ink! I'd buy that **** in a heartbeat.

I had a workhorse of a B&W laser for many years, an HP 4MP that I bought in grad school. It finally died last year and honestly was probably repairable.

But new color lasers are only like 300 bucks so I got one of those. It works great, replacement toner is cheap and lasts a long time. Only downside is that the wifi on it sucks so it needs to be power cycled once a week or so. It also does copying/scanning.

ok heres a dumb hot take. unit tests are stupid and not necessary.

I mean, I learned a ton from wasting literally days trying to get a unit test to pass or creating a unit test that mimics the real state of my apps usage of observables. I am a much better programmer bc I have always had good unit test discipline and written every test I could possible think of.

but its not worth it. its very time consuming and it takes a lot of effort to maintain for the next dev to come thru.

and for the most part it just amounts to massaging the test so that true=true or 2=2 or whatever.

now this is undoubtedly my arrogrance talking bc as I said, I learned more from writing unit tests than any other endeavor. but, at this point in my angular/typescript/javascript, it is a complete waste of time for me to write any. but from a business standpoint, its hard for me to advocate for entire programs of devs to write a bunch of tests when the main value is that some devs get a better understanding of Javascript and rxjs.

1. some devs already know it
2. some defs are too dumb to understand even if they write the tests
3. some devs dont come across the interesting edge cases that push intuitive understanding.

now, in a perfect world, end to end tests would be awesome. but when you consider how many iterations there are for an e2e, it hits infinity like yesterday. and also they are super expensive. protractor is the most common framework and it takes like an hour to run 150 tests.

so I have no good answers. I feel that I have personally outgrown jasmine unit tests. I also feel that it taught me intuitive understanding of angular and javascript observables more than anything else.

oh and devs love to cheat. for a long time if there was some decent amount of logic in a TS method, the code reviewer would tell the dev to write some tests for it. the devs got around this by simply moving all of the logic the friggin html. ugh, sooo unreal ugly.

(and fwiw, myself and another dev helped get rid of this idiocy by figuring out how to do so called "shallow" tests which use testBed and allow the framework to test html logic. they are expensive and dumb for the most part but if you are gonna try to put like 8 nested ifs in the htm then I am gonna call you on it.)

and that kind of brings to me when unit tests are good. say you are bringing in some sort of complex data type (or more than one) and you want to manipulate it in some way where you return something else. thats a good spot of a unit test. in fact, thats one of the main ways that a TDD should happen imo.

I surely dont know how to combine 2 arrays and match up this one value type so that a new array returns. and I dont want to create all this data and then fire up the whole app to make sure it works. this is why tests are awesome.

they are not awesome when I have a method that calls another method and the test is to assert that the method was called.

I agree. I cant state it articulately but i feel like they dont add a ton of value to a test infrastructure. Obv code coverage is good but blackbox tests tend to expose a broader range of bugs a user is likely to experience.

Ha, I was just discussing this in another thread about testing Vue apps. Front end testing just sucks so much overall. Backend is so much smoother.

We are building a green field Vue app, and we def have more than 1:1 time spent on tests vs impl, which I contend seems insane when you are trying to find a market for a new product. But not testing thoroughly wouldn't be "proper" or w/e most people's contentions are.

I was discussing it with a freelancer, he basically said he is pretty far along in the product development process before he even considers adding a test, since things change so much it just doubles your dev time.

Prob my backend privilege talking, but yeah I like tests. I also just came from a company where our test coverage was garbage and we got along ok, so shrug.

Random anecdote: caught a dumb bug in my Python code thanks to unit tests (I work mostly in C++ but sometimes have to modify Python, and I am not an expert Python programmer) yesterday. I wrote something like:

I did not realize that an empty dict evaluates as falsy in Python (which I think is the opposite of JS), so my code was not in fact doing stuff with it. Yay tests!

I have been at my company for two years and I'm currently looking. Just finished my first onsite at a company that I failed previously 2 years back.

I think I *did* better than last time. Spent more time explaining the algorithm I was going to implement before diving into coding it.

Though I had a very interesting situation with one of the interviewers which we butted heads a bit. This person asks me the same exact question that I got from the last onsite. I figure I be honest since they have a committee who actually looks at the questions that were asked previously and it would had been weird if I didn't say anything about it.

Once he finished explaining the question to me, I mention to him that I'm pretty sure I was asked this question before. He said, it's fine just keep going.

I explain my approach and I started coding it. I goofed up one small thing in my algorithm and I mentioned we needed two sets for it. At that point he asked me why we needed two sets which made me second guess myself and I ended up erasing the set I wrote on the whiteboard. He eventually said "You probably seen a similar question for this, and right now it seems like you are trying to shoehorn the solution to this question. Don't do that, try and forget everything about it." At that point, I'm thinking damn, this guy fhking hates me now.

To double check I didn't misunderstood the question, I ended up walking through the problem again, step by step on how I would solve it. Spent a good 5 mins doing that until he was satisfied and said go ahead and code it. As I went back to coding, he said "Does that change your approach a bit?", I said "No, it did not", wrote back in the 2nd set that I previously erased continued to finish it.

Anyways, I ended up wrapping it up. He made me re-write one of the sub-routines recursively, which I did. The interview ended abruptly since they usually ask me for time-complexity and give me an opportunity for follow-up questions about the company.

Was it the same problem? I didn't protest since he seemed adamant that I was thinking of another problem so I gave him the benefit of the doubt. After the interview, I can confirm with 100% certainty that it was.

Unit tests are always going to take more time than actual dev by something like 2-1 imo. Also a failing unit test is like 10-1 to be a legit code change vs. an actual bug. TDD fixes that though obv.

With or w/o TDD there's an art to writing your unit tests to not be so brittle that any change to say a complex object from the back end breaks them. In your mocks and stub objects - only focus on the parts of the object that drive divergent behavior in your component.

However, when you want to refactor something - you'll be absolutely thrilled you have a solid set of unit tests. You'll be much more confident to refactor, which means you'll be much more likely to refactor, which makes for much much better code.

The other huge thing is unit tests define the contract your component makes with the outside world. If you change something that breaks your unit test, you have to also ask if this is going to affect any of the other components or systems which interact with your component.

They're a pain but totally worth it imo.

At least all the way to the front end. The optimist in me thinks solid front-end unit testing can be done, but I've never actually seen it in practice. Seems like it would take a react/vue/angular/etc guru with a borderline obsessive passion for testing. If anyone knows or works with someone like that - hold on to them for dear life imo.

So instead we have some quick and dirty selenium/Cucumber tests I wrote to regression test all the stuff on our app we aren't currently working on (like sign in, registration, change password, contact us form, etc.) Once the major features that we're currently developing are mature I'll add them.

I can run those and feel very confident that at least we didn't break any of the non-obvious stuff. I don't try to use them as any kind of CI/CD gate - because they can fail for so many reasons. But I know which failures I should look into and which are just because of something like Gmail is rejecting my Pop3 test client again. Maybe some day they'll be solid enough to actually block a build. Baby steps. For now I'm just happy to be able to run them manually after a big push from say dev to stage.

I also have some API integration tests I wrote with good old supertest that at least confirm all our API endpoints are up and running (if not every edge case). Same concept on those. I can usually tell when they fail if it's just because some object has a few new properties - vs. something more serious I should look into.

Stuff like selenium e2e tests and API integration tests are more coarse-grained. IE - you're not trying to capture every edge case like you would with unit tests.

But you still need to be smart and capture stuff that doesn't happen often but is important not to blow up the system - like say your back end CRM system is down and your C# lambda that talks to it throws an exception. This is stuff that you'll never catch in a smoke test but you need to make sure still results in a nice "Oops our system is down please try again in a bit" or w/e on the client.

At my old job, we had a case where our error handler was broken. So when one of the back end systems out of our control barfed, which happened fairly often - instead of gracefully handling it, our app sent a full stack trace to the end user. That's the stuff you want to find a way to simulate and make sure is being handled correctly - via an e2e test. Because it doesn't come up during any kind of human smoke testing or just general devs, testers or internal stakeholders banging on the app.

With solid back end unit tests, plus a good set of "Are all the lights on?" and "rare disaster" e2e and integration tests, you can feel super confident in the app.

Not a not take. Writing tests is like flossing, everyone agrees its a good idea but who has the time.

(@ my previous post, my edit window expired)

For the first time in my career I've designed an app like this - with lots of testing from the get go. My boss hired me with that mandate so I pretty much had to lead by example.

The # of back end bugs our front end devs have found - while developing - are like 1/10th what I remember happening in past projects. I've caught soooo many things before they did.