matt7340

This is what Angular does, where an Angular component is typically rendered as a custom tag. I find it to be one of the (very) few nice things about Angular, as it can be helpful to track down components in a large codebase. I haven’t used React for many years, but makes me wonder if custom tags as a convention would be similarly useful.

Great nostalgia! I fondly remember QuickBasic, and how excited I was to compile my BASIC code. And the rarely mentioned gem I thought was amazing at the time: Visual Basic for DOS!

All true, but glosses over a lot of nuance and wide variety of contexts, particularly B2B.

We’re likely going to switch to Cognito because maintaining OIDC auth has been a pretty big cost for a small company. IdP configurability in particular is painful both technically and in customer support.

One downside to Cognito/etc though is while they’ll handle the tech side (Okta notwithstanding), it’s still up to you to troubleshoot and configure and integrate correctly. Lots of opportunities to “solve” the security risks, but hurt customer and user experience in the process.

I really like the Decoders library for this. Similar in function to Zod, but a more Elm inspired approach - https://decoders.cc/

I've read that Angular is also extensively used for Google internal projects. How do the teams choose between Angular and Lit?

PDF processing seems like a security minefield. What are folks doing to mitigate that problem prior to (or as part of) processing? Or as part of any system that accepts PDFs with the intent that they’re shared with other systems and users.

Nice overview, especially for those of us working long term projects and locked into whatever framework the originals devs chose. I wish I had time to try all these things out, but it’s tough to keep up.

Interesting that angular, and especially angular 2, only gets a passing mention.

This seemed like a really great explanation. But I have no idea if it actually is, or it if it just feels that way because I finally have some Haskell coding time under my belt.

Regardless I enjoyed the read and found it a useful way to think about monads

This has absolutely been my experience as well. The one thing to be careful about is losing sight of the content while making it entertaining. I've swung a little too far a few times, and risked my tech talk looking more like a standup routine.

I’m all for culture of writing, but that feels too easy.

Like another pointed out, what about a culture of reading? And further, what are these cultures of writing doing to help individuals improve their writing? Understanding audience, valuing brevity, tone, structure, knowing when not to write, etc are all important skills that the vast majority of people in business (probably including me) lack.

Further, writing takes time. How do you evaluate what writing is worth it, that the time you take away from e.g. coding still adds business value? It certainly may, but that feels very hard to quantify.

I’ve always felt that quality of writing is one of the best signs of a good candidate for hire, well before tech skills, and is something I factor heavily while hiring. But now that you mention it, our candidate projects generally are just code focused plus discussion, which is unfortunate, and probably worth revisiting.

I could rant for a while, but a few things off the top of my head: over-architected, overly complex, sometimes bad tooling (karma, protractor), tons of old issues (though they’ve been working to clean this up lately), big time inner platform effect (the templating feels like a language to itself), slow compilation, RxJS is generally overkill, Reactive forms is untyped(!) and clunky, and the “included batteries” are sometimes later removed leaving you to figure it out yourself, such as with protractor and eslint. If I’m just gonna figure it out, why not use React anyway and get a much simpler framework?

That said, for a team or teams with lots of apps where a consistent structure provides real benefits in getting up to speed, I can appreciate that some of angular’s enforced structure could be helpful.

I think I’ve reached the point where I simply don’t mention most nits. I’m most business software it just doesn’t seem worth it. If the code works, isn’t utterly obtuse, and abides by automated formatting etc, then is the nit really worth it?

Granted I’m probably biased towards high churn SaaS apps, which is what I work on.

I agree with the spirit of this, but the async nature of code review seems to prevent it.

Social and power dynamics in async code review can make things very difficult.

Funny to see these new incarnations of the old ASP.NET UpdatePanel. I despised WebForms back in the day, but always had a soft spot for the UpdatePanel, seemed like a great idea. Especially when the alternative was manually building and managing UI on the client using ASP.NET AJAX.

I’ve been considering switching from karma to jest for our angular project, this certainly brings a new angle to that decision.

Frustrating. I guess I get crappy karma “supported” by google, or the much better jest that’s maintained by one person with almost no backing.

I’ve noticed that often this is an area where WIP is not limited, and the efforts are least likely to be well managed and documented (unsurprisingly, it can take a lot of work to keep up).

I’ve also noticed numerous long term migrations that don’t tie back to a strong long term value proposition. And when the claim is that it does, it’s often just overly optimistic gazing into the crystal ball. Just as dubious as multi-year product roadmaps, for most businesses a ton of unpredictable things will occur.

I like these recommendations, especially around decorators, maybe I’ll start following them

reviews Angular app

oh

IndexedDB on Safari has had issues it feels like since day one. IIRC there was a full rewrite somewhere along the way too, and still problems seemingly every Safari release. My favorites were the iOS upgrades that simply deleted all IDB data.

Super frustrating, makes me glad I’m not currently building anything that relies on significant local storage.

The web could fill so many needs instead of using apps, but with crap like this it’s no surprise that it still doesn’t.

I definitely agree with this in general, but there are exceptions where it’s still a quagmire. Angular, for example.

Not a fan of ORMs at all, especially ActiveRecord style. They just bring a costly new layer of complexity and not enough value to justify it.

I do very much like the object hydration that ORMs bring though. I think libraries like Dapper hit the perfect balance of manual everything vs automagic complexity.

It obviously doesn't matter that much if you can or can't. We all google all day long.

But through my career at various times I've been able to say yes, usually after spending multiple years on a project and the platform/tech its built with.

Speaks to the really enjoyable side effect of productivity and unencumbered expressiveness that comes with being immersed in a platform or technology for a longer period or time.

My experience with junior (and sometimes not junior) developers has been that the lack of understanding leads to confusion about what they're trying to test. I think the ambiguity leads to a tendency toward mocks, which leads to tests that are focused on collaboration and implementation rather than output. Sometimes that makes perfect sense, but I've also seen where it encouraged more tests that are too implementation reliant.

Nothing wrong with mocks of course, sometimes they are absolutely required. I just favor isolation using stubs, and using mocks sparingly and only when absolutely needed.

> ...in reality every mock needs to act as a stub I disagree. In fact a collaborator method call that doesn't return a value is a great candidate for mocking. Conversely, a collaborator that does return a value can usually be stubbed.

> ...when you stub you can also go ahead and add code to verify some behaviors (mock) to get some extra coverage Entirely dependent on context of course, but to generalize, this feels risky. In many cases adding extra coverage via mocks might be making tests more brittle, for little to no value gain. Further if every method you mock is returning a preset value, there's no reason to verify expectations on it, because it's a stub that will allow verifying expectations on the output of the object/function under test.

As far as library naming, it's just a pet peeve stemming from "mock" somehow becoming synonymous with "test double". If people use a "mocking" library for stubs... well... that's good! :)

Classic article, and important distinction. I’ve found that those who aren’t familiar with the distinction tend to be less aware of what and how they’re testing. Lack of awareness or understanding tends to lead to thing like excessive mocking.

Poorly named libs (e.g. mockito) just exacerbate this problem.