gm

Stopped reading and closed the tab at "JavaScript disabled by default. Websites should only be using JavaScript to enhance the overall user experience".

Good luck putting your thumb up in a try to eliminate the sun. Absolutely never gonna happen.

Either this project is someone's wishful thinking of what a perfect world looks like to them (in which case I'm not interested), or this is actually a serious attempt to enforce arbitrary rules on web sites, and the authors are trying to do it at the expense of the users, in which case I don't care either.

I think this would be a huge win for growing clout and usage of alternative search engines. Not sure if Google knows what it's asking for.

Now if Facebook follows suit, even so much better. It'd be a huge win for privacy.

Hmm, I record meetings with Camtasia instead of fumbling around with the built-in functionality (specially when it's a meeting you are not hosting). I wonder to what degree this that gets rid of these invisible watermarks.

Something was bothering me about this whole thing. I think I found what it is:

1) This is an entirely self-centered approach. "These are the tools that I like, and I code the way I'm productive, with the specific knowledge I've acquired, tailored to how I best work." That's a lot of "I" in there.

The idea of programming this way really bothers me because as someone who's hired freelancers, the best interests of your clients are nowhere in your calculus. Now, if you gave them the choice between lower cost code and code that anyone else can work on, it's your client's decision. But you are making that decision for them. If your clients are non-tech people who don't understand the ramifications of each choice, then you are doing them a disservice.

Nowhere in your article do you mention documentation or making your source easily understood by anyone else, so I rest my case.

It looks like if you are ever hit by a train, your client is screwed, and you've not thought about that.

2) I know that we, as engineers, love to reinvent the wheel, but when you start implementing stuff readily available you introduce bugs and security weaknesses. Maybe you trust yourself not to do that, but do your clients know you're not using industry standard code?

Anyway, your life, your choices. I'm not sure you've been on the client side inheriting code written like this that no new programmer can understand right away. Whoever inherits your code is going to have a lot of head scratching to do, and the only saving grace is that they will have your tests to validate any changes, and they will hope that your test coverage is appropriate.

But from the point of view of your own interests, everything you wrote is very beneficial.

Why would a market care about the language a product's written at? Maybe only programmers, and anal retentive ones at that.

LOL, yeah, recursive project names stopped being interesting to me after "GNU's Not Unix"

True, when I read the description, it looked to me like a bundle of smtp, email rules config utility, spam filter, and email client, all in one package you cannot reconfigure.

The road of tech is littered with the bodies of email replacements.

Some of them went on to thrive, but not as email replacements: Slack for one.

It looks great, but there's zero chance I'm going to replace my current SMTP with a new protocol no one (yet) uses. If there's a bug in all of this it's in laying out very clearly how to ease into this. Especially in a world of hosted email providers where everyone is using Exchange, Google Email, and even cPanel to host email for organizations, and none of them have a big incentive to support this.

EDIT: On thinking about it, I'd think this would have more chances if they phrased it as an augmentation of email's capabilities rather than an email killer.

I hate being the product as well, but it's pretty much inescapable now. Paying for a service does not opt you out of being marketed to other income streams as a product (ie, combined stats, being part of a test group, etc).

The best we can hope for by paying for a product is getting additional features and not being inconvenienced (ie, avoiding ads).

I was scammed through PayPal, PayPal did the same thing to me, basically gave me a "Looks good to us, case closed, go fuck yourself." The negation of my case was automated, too. I received the "resolution" a few seconds after submitting the case.

Thankfully, I had paid with a credit card as the PayPal funding source for that transaction, and I disputed the charge with my CC company, which found in my favor, and did a chargeback to PayPal.

After that, I immediately unlinked all of my funding sources from PayPal and closed my decade+ account. Never again. Not as a buyer, and certainly not as a seller.

That's exactly what my point is: This is way too complex to boil down to a simple rule of thumb to apply to all cases. There are arguments and counter arguments (and real-life examples and counter examples) ad-nauseum.

It's better to say: "Hey experienced people: How would you decide whether to introduce an external dependency or roll your own if the immediate requirement at hand seems small enough to write on your own in half a day?". Then we can get into a fun conversation that will boil down to "It depends."

No. Some reasons:

1) As everyone else has said, we are horrible at estimating.

2) We think we might only need 1% of an external dependency, until we do not. Case in point: By this criteria, no one needs a grid/datatable library.So we write it "in an afternoon". Then we're asked for an export to Excel. Later on we're asked for pagination with large data sets. And then an export to PDF. How many afternoons did that cost you?

3) Writing new code is an excellent opportunity to create new bugs and implement bad design because we're on hurry since it took nowhere near an afternoon of code to write and we cut corners.

Anyway, those are just three that come to mind immediately.

This is not an argument against the "afternoon rule", but is really an argument against making simple-sounding black and white rules to solve to problems that are inherently complex, and are thus, gray areas.

Good, now make it round-trip. In C# the hard part is not serializing, but deserializing robustly and type-safely.

Just so you all know, Twitter's going crazy with the apparent rampant inaccuracy of the database.

In that case, then the original problem (incorrect abstraction) does not exist, or at least does not get worse over time, and thus does not need fixing.

This advice just _feels_ very wrong. After thinking about it and seeing the other comments, some remarks:

1) It's fine to go back and duplicate code after you correct the abstraction. But it should be the _first_ phase in doing a larger pass to refactor code to fit the current business requirements. If you forgo the _second_ step, which should be to search for suitable abstractions again, you are absolutely guaranteed to be left with shit code that breaks in this situation, but not that other one, and no one knows why. I would absolutely only duplicate code as the prequel to deduplicating it again with updated abstractions.

2) If you do any of this without thorough unit tests you're insane. Keep the wrongly-abstracted code unless you have time to thoroughly fix the mess you will have made when you duplicate code again and introduce bugs (you're human, after all).

2a) If you are going to do this and there are no unit tests, create those unit tests before you touch the code initially (before the duplication).

3) Some of the comments saying you should wait until you implement something two or three times before creating an abstraction seem like comp sci 101 rules of thumb. It's way too simplistic a rule, way too general. Prematurely abstracted (haha!). The type of project and the type of company/industry will tell you what the right tradeoff is.

That is all.

Lol, the person you're replying to never said, nor implied that.

I'm not trying to knock you, but your comment reminds me of the type of exchanges where one person says says "men do a lot of work", and the other person replies "are you saying women are lazy?"

You'd be surprised how simple it is (but I like simple): It's a bunch of batch files (I'm that old) that basically run the "git clone --bare" command on each repo, and then uses 7z to create a single archive of all the repos, plus text file is included that tells me how to restore the backup to another server (git push --mirror <url>). I included that because I figure when I need it I'm gonna be sort of stressed, lol.

I specifically stay away from anything fancier than plain git commands because I do not want to be testing these backups all the time to make sure they're usable.

Since the 7z archives are just plain files, they are backed up with all of my other stuff via my normal cloud/offline backups that I have.

Sure. I just prefer to do it where I have 100% of control and not merely hand off from one third party to another. But whatever works. The point is to not be caught off guard when a critical provider decides to take unilateral action against you and then you're at their mercy.

This is why I regularly back up my github repos (via git clone --bare, then compress and archive). Mind you, I do nothing that even comes close to piracy, and the vast majority most of my repos are private, but it's a nightmare scenario to have your third party dictate when you have access to your source code and pop up surprises like this, whether by having some asshole try to extort you, or by the git repo having a data disaster with your repo.

I think it's a pipe dream. Non-experts making changes to a system an expert wrote will yield either: 1) very few little changes, such as changing the color of an item, etc. Or 2) disasters where it's better to throw away the changes and start over doing it "the right way".

Just look at automobiles: They are malleable indeed. We've all probably seen pics of modifications of all types, from the hillbilly type VM bug/truck combination to the amazing Cobra replica that few can tell from the real thing. In all cases, the craftsmanship level (and budget) of the person doing the modification directly affects the quality of the result. And how many cars are there whose modifications simply failed and the car never hit the road again?

The same in software. Give Annie in accounting the ability to modify the inventory system and you will have a disaster in your hands, especially if she does not know much about the architecture of the system and/or she's not a matter expert on inventory methods and procedures. In that case I'd much rather trust my company to a hard-to-change system than one where everyone can mess with and break it beyond repair.

I think the false premise here is that non-experts can build on the work done by experts. And I'm talking about both experts in programming who built the system in the first place (ie, add shitty architecture on top of good architecture), and experts in the domain the system is solving. If you get a smart your developer who is a solid coder to make changes to the aforemetioned inventory system, he will probably break the system (at least in the edge cases), albeit with beautiful, readable code.

I just don't see how it's possible unless the ability to expand the system is severely limited (ie, not a "malleable system").

Do you know by chance know if user-0defined filters take precedence over Google's spam detection? If so, I might go for it.

I say "might" because no matter what I program into it, I'll never be sure there's not an important false positive that got trapped, and so I'll forever be checking my spam anyway. It might be all for naught.

OMG, me too, and all I did was to tighten up cookies (disable 3rd party trackers, erase all cookies on close, etc).

Now I've got a PhD on solving "traffic light" and "crosswalk" Captchas as a result.

I started to resent Google for this, except now I think twice before going to a web site that will give me these hurdles, so it ended up helping me to focus on my work. Now I appreciate the extra work.

I think it should suffice to know that after one repeatedly trains the google spam filter with "report not spam" and "mark as spam", it should learn that well enough, no?

As an example: Some dumb ass Verizon customer gave them my email address as their own. I got a ton of communications from Verizon that I could not turn off (bill past due, thank you for you promise to pay, and all sorts of really annoying messages). I called Verizon, I was told that neither them nor I could do anything about it because I did not own the Verizon account, and I did not have the account PIN. Their official solution for this problem: Mark all the Verizon emails as spam and don't call them again (I kid you not).

The result: I marked about 100 Verizon emails as spam and Gmail learned that really well; now I do not see Verizon emails in my inbox. Why TF can't gmail do this with all the other emails I mark as spam and not spam?

I just got in the habit of firing up the hideous gmail app on my phone to go through my spam folder every day and vet out the non-spam out of there. I usually go though about 250 emails per day. I end up looking at all the spam, but it's far faster to fish out the good messages from spam than if I turned spam detection off altogether.

No matter how complex the problem to solve is, Google is failing at a level where even I could program it better, which is not a high bar at all.

They ask questions which imply "I'm sitting on my hands until you answer me".

"No expectation of immediate reply"? HA! I SO wish. Slack kills any async expectation. Specially if you install it on your cellphone. Then you're on the clock 24/7.

I guess the article also assumes different time zones when working remotely?

I filed the article under the "rubbish bin". I've worked remotely for several years, and maybe I live in a different planet, because "async" and remote work do NOT go hand in hand for me. If anything, Slack means people can reach me even when I'm taking a dump, and I'm expected to reply at that moment.

Amen, brother!

Google's spam algorithms are truly awful. I've had this problem on the receiving end for years. Reporting legitimate email as "Report not spam" does nothing except move the email out of the spam box. I find myself whitelisting legitimate emails over and over and over again, some of them verbatim copies of previously whitelisted emails (ie, "Your backup is completed" emails).

Google thinks its algorithms are better than me at detecting false positives on my own email account, and this is enragingly false.

Now, I periodically check all my spam to catch all the false positives. I used to get extremely pissed about this, but nowadays I just allocate time every day to the task, admitting defeat.

The Google spam algorithm simply has a mind of its own, it will not listen to suggestions.

I guess my replying here is aimed at letting you know you are not alone in your frustration.

Follow up question: Is there a framework for creating and maintaining these API docs, or is it hand-coded?