7 ms·

The time I accidentally spent a year combatting fraud

160 points by brightball 3y ago

ftxbro 3y ago
soon it's gpt fighting the fraud and doing the fraud
obviyus 3y ago
> One of the unfortunate things that happened is I was put in a situation where I had to choose between doing what was needed to save the company and the businesses who relied on it or listen to the daily change in priorities from inexperienced non-technical leadership. Learning to navigate this has been a skill in and of itself. Glad the intense effort worked out for the author
noisy_boy 3y ago
> While this was a shock in the moment, I would later learn that this attitude was fairly common among Rails developers at the time who were largely encouraged to treat their database as a dumb data store by convention and to let the application do the work. This is not a bad attitude depending on specifically what levels of "dumbness" you mean. IMHO, the golden rules for database setup are: - Spend a lot of time designing your schema. Then spend some more time. - Do not skimp on data integrity measures like proper primary/foreign keys - Pay attention to potential usage patterns and build indices for performance; this is not a one-time activity, keep observing the usage and look out for hot-spots Some other tangential points that are often overlooked: - Do not push all your business logic into a hairball of nested stored procs and triggers; debugging/testing all that is a bitch compared to writing unit/integration tests or dropping into debugger in an IDE. You can be a million times more expressive in a full-featured modern language like Java or C# etc. The main exception to this is when you need to push/transform tons of data around and all of it is on the database - a well tuned stored proc would be orders of magnitude faster. This is also not something is needed frequently and could be symptomatic of a bigger issue. - Tons of database trips are expensive; an efficient join instead can do wonders for the performance. If you are doing that all the time, maybe its time to put that behind a view. Also, cache what you can and be conservative about it. - If you are almost always including a filter clause in all your joins, maybe you can explore partitioning. Basically imagine the database like an appliance that does only a few things but those things are FUNDAMENTAL so we ensure that it does them very very well. Don't make it make your coffee too (though PostgreSQL probably can do even that efficiently). > There were other factors too, such as depending on Rails to validate uniqueness rather than the database. It resulted in a lot of messy data cleanup that I had to deal with which were causing hard to diagnose issues because race conditions will always happen. > Second, the database is the only place that can make guarantees about data integrity so use them. Thats what I meant.
- pyrale 3y ago
  > IMHO, the golden rules for database setup are: Typically, these rules are not what people mean when they say they use their DB as a dumb data store. What they mean is: - your "schema" is not that important. Sure, you spend a lot of time modeling data in such a way that your application always handles valid data. Once that's done, your DB is "just" a store for that data. - data integrity is enforced before data reaches the DB. pks/fks are mostly there to ensure fast queries. The idea is that data in your system should be in a sane state way before it reaches the database, and once it's sane, making more controls at DB level is just a layer of administrative checks done in a language that is not really well-suited for that.
  - noisy_boy 3y ago
    > Typically, these rules are not what people mean when they say they use their DB as a dumb data store. I see - for me and the folks I have worked with, that is what we meant i.e. it does its core competency very well and is "dumb" about business logic.
- brightball 3y ago
  Here's one example fwiw: https://news.ycombinator.com/item?id=36030033 https://news.ycombinator.com/item?id=36030033
krainboltgreene 3y ago
> When things eventually stabilized, the leadership was happy with the result but displeased with my obedience. During my annual review, I was told I wasn't working hard enough. [...] Over this month, I really was not productive for the first time in my entire career. [...] When emotions had settled, the owner told me I saved the company and thanked me for it. This is why I laugh when HN commenters tell me that the companies make reasonable choices when it comes to their employees.
- nicbou 3y ago
  This part was a punch in the gut. Stories like this one are a reminder not to pour your life into your work. The sacrifices don't always pay off.
  - flutas 3y ago
    > The sacrifices don't always pay off. The cynic in me wants to really say, typically the sacrifices never pay off. My example time: Company I was working for planned a promo on July 4th. This promo was in collaboration with a GIANT sports brand. Think of the most known sports brand (not sportswear) in the world. No real testing in our QA env due to (some reason I can't remember). Day of promo (July 4th) I get a frantic call "IT'S NOT WORKING." I spend my July 4th, stopped in my tracks right before I'm about to head out the door to the lake with some friends fixing a bug in this promo. My reward for doing frantic work to save probably 3 peoples assess above me even when I wasn't on call? "thanks" Not even the basic 2.5x daily rate that is mentioned in our company handbook. All this to say: The sacrifices hardly ever pay off in my mind.
  - brightball 3y ago
    It was one of the worst experiences of my life. I didn't appreciate what depression felt like prior to this. For a month or so, it honestly felt like I was on some type of drug that made me constantly tired, distracted and stressed all at the same time. You keep telling yourself to get moving and just...can't. It sucked. Hindsight is big on this project though. I got so much experience from this work that it truly did level up my career. I learned more as a side effect of getting deep into these issues than I ever expected too.
totetsu 3y ago
https://hometheaterreview.com/what-happened-to-audiogoncom-and-will-it-get-repaired/ https://hometheaterreview.com/what-happened-to-audiogoncom-a...
- pnw 3y ago
  I knew immediately on reading the article that it was about Audiogon.
  - sverhagen 3y ago
    >Even though this story took place 10 years ago, I won’t be naming the company or anyone involved. I have never heard of Audiogon, but reading the article I looked forward to my time in the comments section and seeing the mask pulled off. It seems such a naive thing to write for a guy who is clearly not an idiot. So much so that I guess that this line was more like a mandatory disclaimer kind of thing, while not intent at all on keeping things a secret? The company and timing of his employment are on their LinkedIn, which is linked from the article.
    - dmurray 3y ago
      I think it's fine. Polite not to "name and shame" the company to a casual reader, but he also shouldn't have to keep his employment history a secret. We haven't heard who are the Atlanta "Rails-r-Us" company, though it's probably similarly obvious to a motivated researcher.
      - brightball 3y ago
        That company was purchased a few years back fwiw.
    - brightball 3y ago
      It’s not a big deal anymore. Even 10 years later there are still a lot of things that happened that I couldn’t include in the story. For what is in the story though, it’s not a problem.
n0n0n4t0r 3y ago
Thank you for this story! It remind me of my first professional experience: the ship was sinking, it was hard, but I never ever again learned so much. Sometimes I'm nostalgic if the intensity I lived in, but I think I'm too old for this.
- brightball 3y ago
  I know the feeling. I couldn't imagine inserting that 24/7 type commitment into my life right now. It was crazy driving home from work, getting a call that a phishing email went out when they clearly waited until we wouldn't be around to take it down. Then getting home, opening up the computer, making Skype calls to an ISP in South Africa to notify their abuse teams for the take down.
sverhagen 3y ago
>Rails developers at the time who were largely encouraged to treat their database as a dumb data store by convention and to let the application do the work I've worked in a big enterprise once (hated it for all sorts of reasons) where the business logic was entirely in the database, I get that that could work too. But in the sort of environments where I've worked most, there's a lot of knowledge about the application programming language, and less about the database. No dedicated DBAs. And we all know our SQL, we build basic NOT NULL and foreign key contraints, maybe a simple uniqueness constraint in SQL, but otherwise concentrate all the application logic in... you know, the application. For better or worse, I guess it's a coping mechanism for application developers. (And then it becomes a habit, maybe for some, like the article said, dogma.)
- Fire-Dragon-DoL 3y ago
  It's pretty common for Rails developers to know very little about databases (sql specifically). It's very frustrating because right out of the gate, Rails pushes thinking of the db as a graph, leading to highly inefficient queries
  - sverhagen 3y ago
    My comment was based on Java environments, and it's the same. It's unacceptable to build poorly-designed schemas in any environment. But good schema design is something else than what I thought the article might have been referring to, which is building the entire business logic in SQL, using triggers and what not. I've seen enterprises with a database team doing that, for application layer people to come in and built their application on top of this "fait accompli" database. And this means you need two highly-skilled teams: the database and the application team. (Aside from a third, the infrastructure team.)
  - treeman79 3y ago
    It’s common for JR developers fresh out of college or code camps. It’s also good reason not to let the ratio of Junior to seniors get too far out of whack. I’ve had several jobs now, where I came in to clean up after they hired a bunch of juniors with no experience. Usually they were quite good at making things pretty. But fundamentals like N+1, foreign key, insane / broken build times, desperation of concerns, etc abounded. It’s sort of nice because you come in and be a hero for fixing everything up. Can really sucks because there are often good reasons things got to be that bad.
stareatgoats 3y ago
> To make matters worse, there was no going back. Tooling had only been built to transfer the data one way, from the Perl site to the Rails site. Yea, it's one of those hard learned experiences: a rollback must always be possible (if possible).
notTooFarGone 3y ago
Whenever I read something like "Increased revenues by 93% by balancing user and business priorities against available resources" in CVs I immediately disregard it. Maybe I've read it too much but doing the actual analysis of "what have I done and how was the impact" is a lot more than simply taking revenue beforehand and revenue afterwards and calling it a success. Also if I solve a bug that was discovered by QA, specified by PM that was hogging a lot of resources, did I really increase revenue? This trend in CVs is really annoying me as most of the time it's complete BS and only there because people watched a YT video on how to build your resume.
- faeyanpiraat 3y ago
  What is the problem here? The fact that the impact is generic, and you can not be sure about that the candidate's actions were the true cause? In this case would a more specific claim with a more solid reasoning help? Or are you dismissing all claims of potential positive impacts?
  - SiempreViernes 3y ago
    At a guess, they think claiming that an individual increased revenue by 93% using a simple balancing method is not very plausible, and as it is most likely just and outright lie can thus be discarded as hot air (which is actually pretty charitable). One objection is of course that 93% is very achievable if the numbers involved are very small, but in that case the statement might just be code for "selling the office sofa" which is often seen as less impressive.
    - brightball 3y ago
      In this case, the number was accurate. The company was in a tailspin with people actively trying to abandon it. We had to re-earn their business.
      - SiempreViernes 3y ago
        What meaning are you putting into the word "accurate" here? Are you sure you don't mean "precise"?
brightball 3y ago
Author here, happy to answer any questions I can. This was the capstone on a multipart blog series so some parts in here are intentionally vague because the other sections expand on them. Here are the others: Automatically Revering Account Takeovers https://www.brightball.com/articles/automatically-reversing-account-takeovers https://www.brightball.com/articles/automatically-reversing-... Combating Phishing with DMARC https://www.brightball.com/articles/combatting-phishing-with-dmarc-a-complete-guide https://www.brightball.com/articles/combatting-phishing-with... Deploying DMARC without Breaking Everything https://www.brightball.com/articles/deploying-dmarc-without-breaking-everything https://www.brightball.com/articles/deploying-dmarc-without-... Enterprise Challenges with DMARC Deployment https://www.brightball.com/articles/enterprise-challenges-with-dmarc-deployment https://www.brightball.com/articles/enterprise-challenges-wi... Waste Spammers Time to Kill Their Return on Investment https://www.brightball.com/articles/waste-spammers-time-to-reduce-their-return-on-investment https://www.brightball.com/articles/waste-spammers-time-to-r... How Microsoft Became Phishing's Biggest Enabler https://www.brightball.com/articles/how-microsoft-became-phishings-biggest-enabler https://www.brightball.com/articles/how-microsoft-became-phi...
- 8organicbits 3y ago
  > It showed us a chart of the verified and caught spammers, as well as how much time they were spending manually typing in messages while completing Captchas...that were never delivered. Our worst offender was doing this for 15 hours a day straight. Great reads! Thank you for sharing.
  - brightball 3y ago
    Thanks!
- commandertso 3y ago
  "I went from thinking this was the job to realizing it wasn't going to work and trying to figure out how to tell my wife that I was going to have to start the job hunt all over again." I just wanted to say - I have been there, and I feel you. When I read that, it was visceral - took me right back to the couple times I've had those moments. Good on you for keeping on, and using what the experience offered to make things better afterwards.
empathy_m 3y ago
I haven't heard the phrase "N+1 problem" before -- is this a Ruby-on-Rails-ism or do other communities use it too?
- detaro 3y ago
  General term, especially common around ORMs
- brightball 3y ago
  Simple example: You're using an ORM to query a record and as you're looping through the results you need to reference something in an association. You get one query that returns 50 results, then loop through those 50 results and trigger a one off query for every result in the loop. Now you're executing 51 queries instead of the original one. Now imagine you go another level deep or have multiple results from each of those sub queries to loop through. It can get out of control. In Rails and a lot of ORM's you can typically solve these by eager loading the nested associations with very little effort. The rest of the code will work the same but behind the scenes only 1 additional query will be triggered to fetch the records from the association.
- jarofgreen 3y ago
  It's a general ORM issue. I once took a Python API with SQL Alchemy and took 30% of the speed by adding an eager load instruction to a query. Python profiling showed a lot of time in the ORM & database, then turning on SQL logging made the issue obvious. Still feels like it should be called the "1 + N" problem tho. The 1 query happens first, then the N queries afterwards.
- ufmace 3y ago
  It's a general database access anti-pattern. It happens when you make one simple query to get a list of stuff. Then for every row, you fire off another query to get more details about that item. Instead of this, a single properly-designed query could have retrieved everything you need, and nothing you didn't. This can be highly detrimental to both application and database performance, especially if the number of initial results gets long or you have another layer of query loops after the first one. ORMs are notorious for making it easy to write this anti-pattern without noticing, though you can do it in raw SQL too. ORMs usually also have various helpers for eager loading of associations to try and prevent it. In raw SQL, it's on you to notice that you're doing it and write the correct query.
geocrasher 3y ago
Huge shout out to https://darknetdiaries.com/ https://darknetdiaries.com/ one of the most entertaining security podcasts I have heard. Some of my favorite episodes: ----- Jenny: https://darknetdiaries.com/episode/90/ https://darknetdiaries.com/episode/90/ The Beirut Bank Job: https://darknetdiaries.com/episode/6/ https://darknetdiaries.com/episode/6/ Black Duck Eggs: https://darknetdiaries.com/episode/21/ https://darknetdiaries.com/episode/21/ John and Brian's Big Adventure: https://darknetdiaries.com/episode/95/ https://darknetdiaries.com/episode/95/ ----- And this is just scratching the surface. There's some GREAT stuff.
rlawson 3y ago
Thank you for sharing this story! Lot's of insights both personal and technical. Like you I find Postgres to be a foundational technology.
albert_e 3y ago
Off topic: First time seeing this spelled as "combatting" (HN title, differs in original linked post) Curious if this is a common spelling that I missed noticing all along.
- lcnPylGDnU4H9OF 3y ago
  I think it's a difference between European English and American English. American English would spell it "combating". Which I kinda learned was wrong in an American school. "Swimming", "running", "batting" come from "swim", "run", and "bat", respectively. The present participle form doubles the consonant at the end of the word "as a rule" I was told. A single consonant would mean that there is a silent "e" at the end of the word which suggests a preceding long vowel (e.g., cure -> curing, compete -> competing, combate -> combating). Anyway, it's because nobody follows rules when writing and speaking English and as long as the other person understood your meaning, your grammar was correct.
- brightball 3y ago
  I actually had to look it up after publishing. I've always used "combatting" because it seems like it should maintain the proper "a" sound...but my spell checker flags it now. Apparently, both are correct. https://writingtips.org/combating-or-combatting/ https://writingtips.org/combating-or-combatting/

160 points by brightball 3y ago

soon it's gpt fighting the fraud and doing the fraud

> One of the unfortunate things that happened is I was put in a situation where I had to choose between doing what was needed to save the company and the businesses who relied on it or listen to the daily change in priorities from inexperienced non-technical leadership. Learning to navigate this has been a skill in and of itself. Glad the intense effort worked out for the author

noisy_boy 3y ago

> While this was a shock in the moment, I would later learn that this attitude was fairly common among Rails developers at the time who were largely encouraged to treat their database as a dumb data store by convention and to let the application do the work. This is not a bad attitude depending on specifically what levels of "dumbness" you mean. IMHO, the golden rules for database setup are: - Spend a lot of time designing your schema. Then spend some more time. - Do not skimp on data integrity measures like proper primary/foreign keys - Pay attention to potential usage patterns and build indices for performance; this is not a one-time activity, keep observing the usage and look out for hot-spots Some other tangential points that are often overlooked: - Do not push all your business logic into a hairball of nested stored procs and triggers; debugging/testing all that is a bitch compared to writing unit/integration tests or dropping into debugger in an IDE. You can be a million times more expressive in a full-featured modern language like Java or C# etc. The main exception to this is when you need to push/transform tons of data around and all of it is on the database - a well tuned stored proc would be orders of magnitude faster. This is also not something is needed frequently and could be symptomatic of a bigger issue. - Tons of database trips are expensive; an efficient join instead can do wonders for the performance. If you are doing that all the time, maybe its time to put that behind a view. Also, cache what you can and be conservative about it. - If you are almost always including a filter clause in all your joins, maybe you can explore partitioning. Basically imagine the database like an appliance that does only a few things but those things are FUNDAMENTAL so we ensure that it does them very very well. Don't make it make your coffee too (though PostgreSQL probably can do even that efficiently). > There were other factors too, such as depending on Rails to validate uniqueness rather than the database. It resulted in a lot of messy data cleanup that I had to deal with which were causing hard to diagnose issues because race conditions will always happen. > Second, the database is the only place that can make guarantees about data integrity so use them. Thats what I meant.

pyrale 3y ago
> IMHO, the golden rules for database setup are: Typically, these rules are not what people mean when they say they use their DB as a dumb data store. What they mean is: - your "schema" is not that important. Sure, you spend a lot of time modeling data in such a way that your application always handles valid data. Once that's done, your DB is "just" a store for that data. - data integrity is enforced before data reaches the DB. pks/fks are mostly there to ensure fast queries. The idea is that data in your system should be in a sane state way before it reaches the database, and once it's sane, making more controls at DB level is just a layer of administrative checks done in a language that is not really well-suited for that.
- noisy_boy 3y ago
  > Typically, these rules are not what people mean when they say they use their DB as a dumb data store. I see - for me and the folks I have worked with, that is what we meant i.e. it does its core competency very well and is "dumb" about business logic.
brightball 3y ago
Here's one example fwiw: https://news.ycombinator.com/item?id=36030033 https://news.ycombinator.com/item?id=36030033

krainboltgreene 3y ago

> When things eventually stabilized, the leadership was happy with the result but displeased with my obedience. During my annual review, I was told I wasn't working hard enough. [...] Over this month, I really was not productive for the first time in my entire career. [...] When emotions had settled, the owner told me I saved the company and thanked me for it. This is why I laugh when HN commenters tell me that the companies make reasonable choices when it comes to their employees.

nicbou 3y ago
This part was a punch in the gut. Stories like this one are a reminder not to pour your life into your work. The sacrifices don't always pay off.
- flutas 3y ago
  > The sacrifices don't always pay off. The cynic in me wants to really say, typically the sacrifices never pay off. My example time: Company I was working for planned a promo on July 4th. This promo was in collaboration with a GIANT sports brand. Think of the most known sports brand (not sportswear) in the world. No real testing in our QA env due to (some reason I can't remember). Day of promo (July 4th) I get a frantic call "IT'S NOT WORKING." I spend my July 4th, stopped in my tracks right before I'm about to head out the door to the lake with some friends fixing a bug in this promo. My reward for doing frantic work to save probably 3 peoples assess above me even when I wasn't on call? "thanks" Not even the basic 2.5x daily rate that is mentioned in our company handbook. All this to say: The sacrifices hardly ever pay off in my mind.
- brightball 3y ago
  It was one of the worst experiences of my life. I didn't appreciate what depression felt like prior to this. For a month or so, it honestly felt like I was on some type of drug that made me constantly tired, distracted and stressed all at the same time. You keep telling yourself to get moving and just...can't. It sucked. Hindsight is big on this project though. I got so much experience from this work that it truly did level up my career. I learned more as a side effect of getting deep into these issues than I ever expected too.

totetsu 3y ago

https://hometheaterreview.com/what-happened-to-audiogoncom-and-will-it-get-repaired/ https://hometheaterreview.com/what-happened-to-audiogoncom-a...

pnw 3y ago
I knew immediately on reading the article that it was about Audiogon.
- sverhagen 3y ago
  >Even though this story took place 10 years ago, I won’t be naming the company or anyone involved. I have never heard of Audiogon, but reading the article I looked forward to my time in the comments section and seeing the mask pulled off. It seems such a naive thing to write for a guy who is clearly not an idiot. So much so that I guess that this line was more like a mandatory disclaimer kind of thing, while not intent at all on keeping things a secret? The company and timing of his employment are on their LinkedIn, which is linked from the article.
  - dmurray 3y ago
    I think it's fine. Polite not to "name and shame" the company to a casual reader, but he also shouldn't have to keep his employment history a secret. We haven't heard who are the Atlanta "Rails-r-Us" company, though it's probably similarly obvious to a motivated researcher.
    - brightball 3y ago
      That company was purchased a few years back fwiw.
  - brightball 3y ago
    It’s not a big deal anymore. Even 10 years later there are still a lot of things that happened that I couldn’t include in the story. For what is in the story though, it’s not a problem.

n0n0n4t0r 3y ago

Thank you for this story! It remind me of my first professional experience: the ship was sinking, it was hard, but I never ever again learned so much. Sometimes I'm nostalgic if the intensity I lived in, but I think I'm too old for this.

brightball 3y ago
I know the feeling. I couldn't imagine inserting that 24/7 type commitment into my life right now. It was crazy driving home from work, getting a call that a phishing email went out when they clearly waited until we wouldn't be around to take it down. Then getting home, opening up the computer, making Skype calls to an ISP in South Africa to notify their abuse teams for the take down.

sverhagen 3y ago

>Rails developers at the time who were largely encouraged to treat their database as a dumb data store by convention and to let the application do the work I've worked in a big enterprise once (hated it for all sorts of reasons) where the business logic was entirely in the database, I get that that could work too. But in the sort of environments where I've worked most, there's a lot of knowledge about the application programming language, and less about the database. No dedicated DBAs. And we all know our SQL, we build basic NOT NULL and foreign key contraints, maybe a simple uniqueness constraint in SQL, but otherwise concentrate all the application logic in... you know, the application. For better or worse, I guess it's a coping mechanism for application developers. (And then it becomes a habit, maybe for some, like the article said, dogma.)

Fire-Dragon-DoL 3y ago
It's pretty common for Rails developers to know very little about databases (sql specifically). It's very frustrating because right out of the gate, Rails pushes thinking of the db as a graph, leading to highly inefficient queries
- sverhagen 3y ago
  My comment was based on Java environments, and it's the same. It's unacceptable to build poorly-designed schemas in any environment. But good schema design is something else than what I thought the article might have been referring to, which is building the entire business logic in SQL, using triggers and what not. I've seen enterprises with a database team doing that, for application layer people to come in and built their application on top of this "fait accompli" database. And this means you need two highly-skilled teams: the database and the application team. (Aside from a third, the infrastructure team.)
- treeman79 3y ago
  It’s common for JR developers fresh out of college or code camps. It’s also good reason not to let the ratio of Junior to seniors get too far out of whack. I’ve had several jobs now, where I came in to clean up after they hired a bunch of juniors with no experience. Usually they were quite good at making things pretty. But fundamentals like N+1, foreign key, insane / broken build times, desperation of concerns, etc abounded. It’s sort of nice because you come in and be a hero for fixing everything up. Can really sucks because there are often good reasons things got to be that bad.

stareatgoats 3y ago

> To make matters worse, there was no going back. Tooling had only been built to transfer the data one way, from the Perl site to the Rails site. Yea, it's one of those hard learned experiences: a rollback must always be possible (if possible).

notTooFarGone 3y ago

Whenever I read something like "Increased revenues by 93% by balancing user and business priorities against available resources" in CVs I immediately disregard it. Maybe I've read it too much but doing the actual analysis of "what have I done and how was the impact" is a lot more than simply taking revenue beforehand and revenue afterwards and calling it a success. Also if I solve a bug that was discovered by QA, specified by PM that was hogging a lot of resources, did I really increase revenue? This trend in CVs is really annoying me as most of the time it's complete BS and only there because people watched a YT video on how to build your resume.

faeyanpiraat 3y ago
What is the problem here? The fact that the impact is generic, and you can not be sure about that the candidate's actions were the true cause? In this case would a more specific claim with a more solid reasoning help? Or are you dismissing all claims of potential positive impacts?
- SiempreViernes 3y ago
  At a guess, they think claiming that an individual increased revenue by 93% using a simple balancing method is not very plausible, and as it is most likely just and outright lie can thus be discarded as hot air (which is actually pretty charitable). One objection is of course that 93% is very achievable if the numbers involved are very small, but in that case the statement might just be code for "selling the office sofa" which is often seen as less impressive.
  - brightball 3y ago
    In this case, the number was accurate. The company was in a tailspin with people actively trying to abandon it. We had to re-earn their business.
    - SiempreViernes 3y ago
      What meaning are you putting into the word "accurate" here? Are you sure you don't mean "precise"?

brightball 3y ago

Author here, happy to answer any questions I can. This was the capstone on a multipart blog series so some parts in here are intentionally vague because the other sections expand on them. Here are the others: Automatically Revering Account Takeovers https://www.brightball.com/articles/automatically-reversing-account-takeovers https://www.brightball.com/articles/automatically-reversing-... Combating Phishing with DMARC https://www.brightball.com/articles/combatting-phishing-with-dmarc-a-complete-guide https://www.brightball.com/articles/combatting-phishing-with... Deploying DMARC without Breaking Everything https://www.brightball.com/articles/deploying-dmarc-without-breaking-everything https://www.brightball.com/articles/deploying-dmarc-without-... Enterprise Challenges with DMARC Deployment https://www.brightball.com/articles/enterprise-challenges-with-dmarc-deployment https://www.brightball.com/articles/enterprise-challenges-wi... Waste Spammers Time to Kill Their Return on Investment https://www.brightball.com/articles/waste-spammers-time-to-reduce-their-return-on-investment https://www.brightball.com/articles/waste-spammers-time-to-r... How Microsoft Became Phishing's Biggest Enabler https://www.brightball.com/articles/how-microsoft-became-phishings-biggest-enabler https://www.brightball.com/articles/how-microsoft-became-phi...

8organicbits 3y ago
> It showed us a chart of the verified and caught spammers, as well as how much time they were spending manually typing in messages while completing Captchas...that were never delivered. Our worst offender was doing this for 15 hours a day straight. Great reads! Thank you for sharing.
- brightball 3y ago
  Thanks!
commandertso 3y ago
"I went from thinking this was the job to realizing it wasn't going to work and trying to figure out how to tell my wife that I was going to have to start the job hunt all over again." I just wanted to say - I have been there, and I feel you. When I read that, it was visceral - took me right back to the couple times I've had those moments. Good on you for keeping on, and using what the experience offered to make things better afterwards.

empathy_m 3y ago

I haven't heard the phrase "N+1 problem" before -- is this a Ruby-on-Rails-ism or do other communities use it too?

detaro 3y ago
General term, especially common around ORMs
brightball 3y ago
Simple example: You're using an ORM to query a record and as you're looping through the results you need to reference something in an association. You get one query that returns 50 results, then loop through those 50 results and trigger a one off query for every result in the loop. Now you're executing 51 queries instead of the original one. Now imagine you go another level deep or have multiple results from each of those sub queries to loop through. It can get out of control. In Rails and a lot of ORM's you can typically solve these by eager loading the nested associations with very little effort. The rest of the code will work the same but behind the scenes only 1 additional query will be triggered to fetch the records from the association.
jarofgreen 3y ago
It's a general ORM issue. I once took a Python API with SQL Alchemy and took 30% of the speed by adding an eager load instruction to a query. Python profiling showed a lot of time in the ORM & database, then turning on SQL logging made the issue obvious. Still feels like it should be called the "1 + N" problem tho. The 1 query happens first, then the N queries afterwards.
ufmace 3y ago
It's a general database access anti-pattern. It happens when you make one simple query to get a list of stuff. Then for every row, you fire off another query to get more details about that item. Instead of this, a single properly-designed query could have retrieved everything you need, and nothing you didn't. This can be highly detrimental to both application and database performance, especially if the number of initial results gets long or you have another layer of query loops after the first one. ORMs are notorious for making it easy to write this anti-pattern without noticing, though you can do it in raw SQL too. ORMs usually also have various helpers for eager loading of associations to try and prevent it. In raw SQL, it's on you to notice that you're doing it and write the correct query.

geocrasher 3y ago

Huge shout out to https://darknetdiaries.com/ https://darknetdiaries.com/ one of the most entertaining security podcasts I have heard. Some of my favorite episodes: ----- Jenny: https://darknetdiaries.com/episode/90/ https://darknetdiaries.com/episode/90/ The Beirut Bank Job: https://darknetdiaries.com/episode/6/ https://darknetdiaries.com/episode/6/ Black Duck Eggs: https://darknetdiaries.com/episode/21/ https://darknetdiaries.com/episode/21/ John and Brian's Big Adventure: https://darknetdiaries.com/episode/95/ https://darknetdiaries.com/episode/95/ ----- And this is just scratching the surface. There's some GREAT stuff.

rlawson 3y ago

Thank you for sharing this story! Lot's of insights both personal and technical. Like you I find Postgres to be a foundational technology.

albert_e 3y ago

Off topic: First time seeing this spelled as "combatting" (HN title, differs in original linked post) Curious if this is a common spelling that I missed noticing all along.

lcnPylGDnU4H9OF 3y ago
I think it's a difference between European English and American English. American English would spell it "combating". Which I kinda learned was wrong in an American school. "Swimming", "running", "batting" come from "swim", "run", and "bat", respectively. The present participle form doubles the consonant at the end of the word "as a rule" I was told. A single consonant would mean that there is a silent "e" at the end of the word which suggests a preceding long vowel (e.g., cure -> curing, compete -> competing, combate -> combating). Anyway, it's because nobody follows rules when writing and speaking English and as long as the other person understood your meaning, your grammar was correct.
brightball 3y ago
I actually had to look it up after publishing. I've always used "combatting" because it seems like it should maintain the proper "a" sound...but my spell checker flags it now. Apparently, both are correct. https://writingtips.org/combating-or-combatting/ https://writingtips.org/combating-or-combatting/