DEV Community: Peter David Carter

Why Do Developers Argue Over Trivial Things?

Peter David Carter — Fri, 20 Sep 2019 18:52:47 +0000

Seems to me there are a few reasons for this.

The first is that sometimes seemingly trivial things really do matter.

The second is that some devs lack empathy and can't understand other's preferences.

Following on from these, to non-techies the one can look very much like the other.

Bad devs will often argue personal points on genuine trivia because it makes things nicer for them personally, and since there are likely few real world consequences they don't have to worry about being wrong. Or they just can't tell the difference between important and not anymore having found the things they previously didn't care about actually did affect the project...

Good and great devs will often still argue trivia for the reason outlined: non-techies and bad devs often can't tell the difference, and being seen to be knowledgeable in general can establish them in a position where they can improve the project as a whole, rather than deferring to bad or mediocre devs who would create an inferior product.

How I Hacked Big Data Using Only Google Chrome (and a little bit of Postman)

Peter David Carter — Mon, 16 Sep 2019 18:34:37 +0000

Ok, so, a little while ago I was looking over a website my friend works at. She's a Junior Developer and so clearly thinks I am magic and can hack anything. Of course I wanted her to think that, so I started poking around on the site she works on.

After a few failed, very obvious opening moves, (nmap seemed to show lots of open ports, but it was just a cluster) I noticed something odd. There were a bunch of requests -- a huge volume actually, with a particular signiture, let's call it 'cp5' to keep this anonymous. This struck me as odd so I looked through the network requests to see what was being sent. I noticed something even odder.

Nothing about the request seemed to include any proper validation information. It was clearly a big data collector that wanted to report everything I was doing on the website back to the owner. So I did what any normal person would do and crafted a packet telling it that I'd done something I hadn't.

200 OK.

Well then! Surely, I thought, if I send it thousands upon thousands of packets, all telling it I did things I didn't really do it would reject these as false.

Nope.

It accepts them and tells me everything is fine. There is nothing in the code-base that filters requests after that, unless they are badly crafted, which my fake data was not -- it was crafted to look like something it wasn't.

So I can tell a multi-million pound florist that vastly more people are navigating their website who aren't (not that I would; my data would have seemed like a blip, nothing more, and done no real damage to their business) and it just accepts my word as gospel.

So that's how I hacked big data with just Postman and Chrome. I'm not going to tell you all the details of which program it is, or how the owners of that program tell me it can't be fixed, even though they charge around $2000 a month for it, because then everyone would do what I did.

But... what is the thing you use to clear snow away?

Hhhhmmmm. I've said too much.

Angular Style Encapsulation: You're Doing It Wrong

Peter David Carter — Sat, 14 Sep 2019 08:31:54 +0000

Style encapsulation is a neat idea... I mean, we're banishing all those crazy collisions in the shared global, just putting your styles where you actually need them, right?

😂

The fact is, on any enterprise scale project you're likely to end up with a hodgepodge approach, with some stuff in the shared global, some in the component and some passed through into class bindings, or even in exceptional cases as dynamically generated and injected custom s/css objects. That's not necessarily bad, but in practice it often is.

The issue for those who see encapsulation as a magic bullet that's going to fix all your styling woes by forcing things into the correct place is that it absolutely won't do that. If you're lazy and don't think through your strategy at a big picture level it can and will bite you in the ass. Repeatedly. And you won't enjoy the process. You have to be strict, you have to be rigorous and you have to expect that switching encapsulation on will, far from reducing your cognative overhead, actually likely increase it. This is because you can't just place your styles in the component that needs them in every scenario. There are many, many different situations, each of which require a different approach.

Firstly, and this should I hope be obvious to everyone: if a styling is genuinely applied over the whole app, and particularly if you expect to change it globally, it belongs somewhere shared. Now, you can use shared global css/scss files for this. You can also create a shared component that contains the styles within in. In many ways the latter is preferable, since you get all those lovely reuse benefits, but something to consider when doing it is this: every time you want to customise your component on a per page basis, you're going to have to mess about with input variables and bindings which, in a really large application, could be as much as 3 or 4 or even more layers deep. How much are you going to be customising, and by doing things this way, how much hassle are you going to create for yourself vs the old-school approach of s/css shared over some or part of an application? This is something specific to your application and you should know as a professional developer what the best way is in each scenario. You have to go through that mental process if you want your application to scale correctly.

Secondly, you might think that the little component you're making is just for the page you're on, but is it really? If you want to use those styles elsewhere, they're now stuck in a box. Did you really want to do that? Maybe you did. If you're certain then encapsulating them to a single, per page component was the right call. Again, though, you need to understand the complete design, not just the little patch you're working on.

Thirdly, and probably most importantly, there are no absolute rules you can follow for using styling encapsulation but you absolutely cannot do things at random and hope for the best. What you'll end up with won't just be a spaghetti mess, it'll be a system that actively forces you to create a spaghetti mess that gets worse and worse each time.

Don't do that.

If there's one thing you take home from this article it's that every time you make a call about where to place a style, you should consider from every angle available what that will mean.