Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mining my mailbox for top email service providers

obem.be

Post reply on HN
Print view View original

61–70 of 110 posts

Re: Mining my mailbox for top email service providers

#61

Post by kerkeslager »

lonelappde wrote: post #49
kerkeslager wrote: post #35

Earlier quoted context omitted.

I'm not sure I could count the number of 100-line long throwaway scripts that I wrote that are still being used in production systems before I realized how dangerous that idea is and stopped treating any code as throwaway code. If I show my code to another human, there's a chance it will end up in production. The Pragmatic Programmer says to throw away prototypes, but in practice it always seems easier to click the m…

Reverse-survivor bias. You aren't seeing the non-existence all the well engineered stuff you never had time to build "properly".

So?

If only 1 in 10 throwaway scripts survives, that can easily cost more in the long run than writing all 10 scripts in a sustainable way.

The open secret is that you almost always have time to do it properly. Doing it properly doesn't take that much more time, and most deadlines are self-imposed and artificial.

EDIT: Time isn't actually the most important cost. Not my code, but a coworker's throwaway script where he thought, "We'll just log this to a file for now" filled up a production DB server with log entries and took down a high-traffic e-commerce site for 6 hours. That easily cost more money than an entire career's worth of "doing it properly". There were obviously multiple mistakes that allowed that to happen, but removing the "we'll do this properly later" mistake would have prevented it.

Re: Mining my mailbox for top email service providers

#62

Post by 4cao »

isatty wrote: post #58
simias wrote: post #23

I must admit that I was a bit shocked when I realized that the author had used javascript for this task. At first I assumed that he was scripting some webmail interface but then I saw that he was using 'emailjs-imap-client'. I understand that people use what they're familiar with and there seems to be a vibrant ecosystem for JS outside of the browser but it'll never not be weird seeing it take over what would once ha…

It always annoys me when some general purpose utility or script is written in JavaScript because I refuse to install node on my computer.

What would have been a shell script in the 1980s, a Perl script in the 1990s, a Python script in the 2000s, is now a JS bundled with an outdated Chromium build aka an Electron app.

Re: Mining my mailbox for top email service providers

#63

Post by fireattack »

jaynetics wrote: post #30
volgar1x wrote: post #25

Earlier quoted context omitted.

who cares, it's just a 100-line long script that probably won't be maintained or used anymore

It would be more readable in almost any other widespread language, and I'm saying that as someone who does a lot of JS.

The biggest problem I have with JS in term of readability is IIFE. I know what it does, but it just looks ugly when you have hundreds of them in a program. The "semicolon in front" is even worse, needless to say.

There gotta be a better way to design syntax for an async language.. right?

Re: Mining my mailbox for top email service providers

#64

Post by [deleted] »

quonn wrote: post #27
simias wrote: post #23

I must admit that I was a bit shocked when I realized that the author had used javascript for this task. At first I assumed that he was scripting some webmail interface but then I saw that he was using 'emailjs-imap-client'. I understand that people use what they're familiar with and there seems to be a vibrant ecosystem for JS outside of the browser but it'll never not be weird seeing it take over what would once ha…

Modern JavaScript/TypeScript is fine. Especially when compared to Perl, of all languages.

[deleted]

Re: Mining my mailbox for top email service providers

#65

Post by pedrogpimenta »

isatty wrote: post #58
simias wrote: post #23

I must admit that I was a bit shocked when I realized that the author had used javascript for this task. At first I assumed that he was scripting some webmail interface but then I saw that he was using 'emailjs-imap-client'. I understand that people use what they're familiar with and there seems to be a vibrant ecosystem for JS outside of the browser but it'll never not be weird seeing it take over what would once ha…

It always annoys me when some general purpose utility or script is written in JavaScript because I refuse to install node on my computer.

I'm curious, why do you refuse to install node on your computer?

Re: Mining my mailbox for top email service providers

#66

Post by runlevel1 »

paulmendoza wrote: post #24
runlevel1 wrote: post #16

Earlier quoted context omitted.

A few years back, one of our (Twilio SendGrid's) developer evangelists created an open source Chrome extension to show the icon of the ESP who sent a message in Gmail. The last big Gmail UI update broke it, but most of the ESP identification strategies probably still work: https://github.com/nquinlan/Email-Intelligence/blob/master/c...

OMG, this sounds like a massive security risk. That nice developer could easily siphon off all the email to his backend server with this little extension. I install almost no extensions because they are too risky.

All Chrome extensions require trust. That should factor into your decision to install any of them.

This is no more risky than any other extension whose permissions include `https://mail.google.com/`. Anecdotally, that probably includes most extensions seeing as how most of the ones I come across request `` whether or not they need it (not that that's okay).

In any case it's open source, so you can download it, audit the code, and install it locally to prevent auto-updating.

Re: Mining my mailbox for top email service providers

#67

Post by amichal »

kerkeslager wrote: post #35
volgar1x wrote: post #25

Earlier quoted context omitted.

who cares, it's just a 100-line long script that probably won't be maintained or used anymore

I'm not sure I could count the number of 100-line long throwaway scripts that I wrote that are still being used in production systems before I realized how dangerous that idea is and stopped treating any code as throwaway code. If I show my code to another human, there's a chance it will end up in production. The Pragmatic Programmer says to throw away prototypes, but in practice it always seems easier to click the m…

And what utility did it provide while it was in production for the effort that was put into it? We had a nasty nasty 3k line Perl script “in production” at a former client for like 10 years. It was written in a couple of weeks by another outside vendor and did it’s job well enough. It had basically zero abstractions. Minimal dependencies. Did one thing and was well commented on intent. The investment vs utility made it last a long time. Yee, rewriting a decade later with minimal Perl knowledge wasn’t fun but the business rules had also evolved so we really used it as reference docs and did just fine

Re: Mining my mailbox for top email service providers

#68

Post by an_ko »

kerkeslager wrote: post #61
lonelappde wrote: post #49

Earlier quoted context omitted.

Reverse-survivor bias. You aren't seeing the non-existence all the well engineered stuff you never had time to build "properly".

So? If only 1 in 10 throwaway scripts survives, that can easily cost more in the long run than writing all 10 scripts in a sustainable way. The open secret is that you almost always have time to do it properly. Doing it properly doesn't take that much more time, and most deadlines are self-imposed and artificial. EDIT: Time isn't actually the most important cost. Not my code, but a coworker's throwaway script where h…

It sounds like the problem was really about failing to document technical debt.

> Doing it properly doesn't take that much more time

If you don't have a cutting board for a small thing, surely you wouldn't put your cooking on hold to drive out to the kitchen supply shop to buy a cutting board. You'd just use a stack of cardboard or something. (And make a note to buy a proper cutting board later, of course.)

Re: Mining my mailbox for top email service providers

#69

Post by throwanem »

hombre_fatal wrote: post #43

[Nitpick] Instead of this: ;(async function () { try { // All your code } catch (e) { console.log(e) } })() Just do this: ;(async function () { // All your code })().catch(console.error) Overuse of try/catch is probably the #1 mistake I see when people use async/await.

The point of async/await is to enable asynchronous code to participate in the same patterns synchronous code does, instead of being coerced into a promise-style interface. Using try/catch is part of that, and it's good practice here. If you're not going to take advantage of it, why bother with async/await at all, especially when using it at top level requires a workaround anyway?

Re: Mining my mailbox for top email service providers

#70

Post by throwanem »

runlevel1 wrote: post #66
paulmendoza wrote: post #24

Earlier quoted context omitted.

OMG, this sounds like a massive security risk. That nice developer could easily siphon off all the email to his backend server with this little extension. I install almost no extensions because they are too risky.

All Chrome extensions require trust. That should factor into your decision to install any of them. This is no more risky than any other extension whose permissions include ` https://mail.google.com/` . Anecdotally, that probably includes most extensions seeing as how most of the ones I come across request ` ` whether or not they need it (not that that's okay). In any case it's open source, so you can download it, aud…

Or use an email client that runs outside your browser, and reduce your threat surface considerably - yes, you still have to worry about other things you do in the browser, but compromising your email compromises all those too via password resets, which isn't the case for anything else if your password discipline is good.

Yes, Gmail makes it harder than it should be to use the email client of your choice. But that's not a problem with email clients. That's a problem with Gmail. It's far from the only one.

Post reply on HN