I found out recently that Facebook is embedding tracking data in the form of IPTC metadata in images that you upload. This way the images can be tracked even after you download them.

Because I'm an anarchist and just want to watch the world burn a little, I made a tiny server to replace the id hash that they embed with a random one, just to see if I can't fuck with their algorithm a little bit.

You can check out the project here https://github.com/watzon/fbmdob

This is more just a note for younger and less experienced devs out there...

I've been doing this for around 25 years professionally, and about 15 years more generally beyond that. I've seen a lot and done a lot, many things most developers never will: built my own OS (nothing especially amazing, but still), created my own language and compiler for it, created multiple web frameworks and UI toolkits from scratch before those things were common like they are today. I've had eleven technical books published, along with some articles. I've done interviews and speaking engagements at various user groups, meetups and conferences. I've taught classes on programming. On the job, I'm the guy that others often come to when they have a difficult problem they are having trouble solving because I seem to them to usually have the answer, or at least a gut feel that gets them on the right track. To be blunt, I've probably forgotten more about CS than a lot of devs will ever know and it's all just a natural consequence of doing this for so long.

I don't say any of this to try and impress anyone, I really don't... I say it only so that there's some weight behind what I say next:

Almost every day I feel like I'm not good enough. Sometimes, I face a challenge that feels like it might be the one that finally breaks me. I often feel like I don't have a clue what to do next. My head bangs against the wall as much as anyone and I do my fair share of yelling and screaming out of frustration. I beat myself up for every little mistake, and I make plenty.

Imposter syndrome is very real and it never truly goes away no matter what successes you've had and you have to fight the urge to feel shame when things aren't going well because you're not alone in those feelings and they can destroy even the best of us. I suppose the Torvald's and Carmack's of the world possibly don't experience it, but us mere mortals do and we probably always will - at least, I'm still waiting for it to go away!

Remember that what we do is intrinsically hard. What we do is something not everyone can do, contrary to all the "anyone can code" things people do. In some ways, it's unnatural even! Therefore, we shouldn't expect to not face tough days, and being human, the stress of those days gets to us all and causes us to doubt ourselves in a very insidious way.

But, it's okay. You're not alone. Hang in there and go easy on yourself! You'll only ever truly fail if you give up.

This is my motivation.

Found this site today and want to share it. Algorithms explained Ikea style.

https://idea-instructions.com

JavaScript guys!! 🤣😅😅

Just found this website for Regular Expressions:
https://regex101.com/

In-case anyone struggles like I do

Why not have a game of DevSecOpoly? Doing DevOps and Security right!

Today, I learned the shortest command which will determine if a ping from your machine can reach the Internet:

ping 1.1

This parses as 1.0.0.1, which thanks to Cloudflare, is now the IP address of an Internet-facing machine which responds to ICMP pings.

Oh, you can also use this trick to parse 10.0.0.x from `10.x` or 127.0.0.1 from `127.1`. It's just like IPv6's :: notation, except less explicit.

"I'm almost done, I'll just need to add tests!"

Booom! You did it, that was a nuke going off in my head.

No, you shouldn't just need to add tests. The tests should have been written from the get go! You most likely won't cover all the cases. You won't know if adding the tests will break your feature, as you had none, as you refactor your untested mess in order to make your code testable.

When reading your mess of a test case and the painful mocking process you went through, I silently cry out into the void: "Why oh why!? All of this suffering could have been avoided!"

Since most of the time, your mocking pain boils down to not understanding what your "unit" in your "unit test" should be.

So let it be said:

- If you want to build a parser for an XML file, then just write a function / class whose *only* purpose is: parse the XML file, return a value object. That's it. Nothing more, nothing less.
- If you want to build a parser for an XML file, it MUST NOT: download a zip, extract that zip, merge all those files to one big file, parse that big file, talk to some other random APIs as a side-effect, and then return a value object.

Because then you suddenly have to mock away a http service and deal with zip files in your test cases.

The http util of your programming language will most likely work. Your unzip library will most likely work. So just assume it working. There are valid use cases where you want to make sure you acutally send a request and get a response, yet I am talking unit test here only.

In the scope of a class, keep the public methods to a reasonable minimum. As for each public method you shall at least create one test case. If you ever have the feeling "I want to test that private method" replace that statement in your head with: "I should extract that functionality to a new class where that method public. I then can create a unit test case a for that." That new service then becomes a dependency in your current service. Problem solved.

Also, mocking away dependencies should a simple process. If your mocking process fills half the screen, your test setup is overly complicated and your class is doing too much.

That's why I currently dig functional programming so much. When you build pure functions without side effects, unit tests are easy to write. Yet you can apply pure functions to OOP as well (to a degree). Embrace immutability.

Sidenote:

It's really not helpful that a lot of developers don't understand the difference between unit, functional acceptance, integration testing. Then they wonder why they can't test something easily, write overly complex test cases, until someone points out to them: No, in the scope of unit tests, we don't need to test our persistance layer. We just assume that it works. We should only test our businsess logic. You know: "Assuming that I get that response from the database, I expect that to happen." You don't need a test db, make a real query against that, in order to test that. (That still is a valid thing to do. Yet not in the scope of unit tests.)

For the privacy freaks of devRant, have a host file that blocks all Facebook owned domains:

Blocklist Facebook domains (2016) - https://github.com/jmdugan/...

(not mine, found on HN)

["hip","hip"]
(hip hip array)

!rant

After over 20 years as a Software Engineer, Architect, and Manager, I want to pass along some unsolicited advice to junior developers either because I grew through it, or I've had to deal with developers who behaved poorly:

1) Your ego will hurt you FAR more than your junior coding skills. Nobody expects you to be the best early in your career, so don't act like you are.

2) Working independently is a must. It's okay to ask questions, but ask sparingly. Remember, mid and senior level guys need to focus just as much as you do, so before interrupting them, exhaust your resources (Google, Stack Overflow, books, etc..)

3) Working code != good code. You are an author. Write your code so that it can be read. Accept criticism that may seem trivial such as renaming a variable or method. If someone is suggesting it, it's because they didn't know what it did without further investigation.

4) Ask for peer reviews and LISTEN to the critique. Even after 20+ years, I send my code to more junior developers and often get good corrections sent back. (remember the ego thing from tip #1?) Even if they have no critiques for me, sometimes they will see a technique I used and learn from that. Peer reviews are win-win-win.

5) When in doubt, do NOT BS your way out. Refer to someone who knows, or offer to get back to them. Often times, persons other than engineers will take what you said as gospel. If that later turns out to be wrong, a bunch of people will have to get involved to clean up the expectations.

6) Slow down in order to speed up. Always start a task by thinking about the very high level use cases, then slowly work through your logic to achieve that. Rushing to complete, even for senior engineers, usually means less-than-ideal code that somebody will have to maintain.

7) Write documentation, always! Even if your company doesn't take documentation seriously, other engineers will remember how well documented your code is, and they will appreciate you for it/think of you next time that sweet job opens up.

8) Good code is important, but good impressions are better. I have code that is the most embarrassing crap ever still in production to this day. People don't think of me as "that shitty developer who wrote that ugly ass code that one time a decade ago," They think of me as "that developer who was fun to work with and busted his ass." Because of that, I've never been unemployed for more than a day. It's critical to have a good network and good references.

9) Don't shy away from the unknown. It's easy to hope somebody else picks up that task that you don't understand, but you wont learn it if they do. The daunting, unknown tasks are the most rewarding to complete (and trust me, other devs will notice.)

10) Learning is up to you. I can't tell you the number of engineers I passed on hiring because their answer to what they know about PHP7 was: "Nothing. I haven't learned it yet because my current company is still using PHP5." This is YOUR craft. It's not up to your employer to keep you relevant in the job market, it's up to YOU. You don't always need to be a pro at the latest and greatest, but at least read the changelog. Stay abreast of current technology, security threats, etc...

These are just a few quick tips from my experience. Others may chime in with theirs, and some may dispute mine. I wish you all fruitful careers!

Helpful tip to all you freelancers or those with the authority:

Never let a client dictate anything in how you do your job, no matter how simple.

Even if they ask you to make yourself available at a specific time, don't. Instead, tell them times you have available so they have to work with you.

If you give a client an inch, they will always take a mile.

My "Coding Standards" for my dev team

1.) Every developer thinks or have thought their shit don't stink. If you think you have the best code, submit it to your peers for review. The results may surprise you.

2.) It doesn't matter if you've been working here for a day or ten years. Everyone's input is valuable. I don't care if you're the best damn programmer. If you ever pull rank or seniority on someone who is trying to help, even if it isn't necessarily valid or helpful, please have your resume ready to work elsewhere.

3.) Every language is great and every language sucks in their own ways. We don't have time for a measuring contest. The only time a language debate should arise is for the goal of finding the right one for the project at hand.

4.) Comment your code. We don't have time to investigate what the structure and purpose of your code is when we need to extend upon it.

5.) If you use someone else's work, give them the credit in your comments. Plagiarism will not be tolerated.

6.) If you use flash, you will be taken out back and shot. If you survive, you will be shot again.

7.) If you load jQuery for the sole purpose of writing a simple function, #6 applies.

8.) Unless it is an actual picture, there is little to no reason for not utilizing CSS. That's what it's there for.

9.) We don't support any version of Internet Explorer and Edge other than the latest versions, and only layout/alignment fixes will be bothered with.

10.) If you are struggling with a task, reach out. While you should be able to work independently, it doesn't make sense to waste your time and everyone else's to not seek assistance when needed.

11.) I'm serious about #6 and #7. Don't do it.

I just noticed that the UI theme picked by the client it's almost the same theme as Pornhub.

git blame
git fired
git depression
git divorce
git homeless
git commit
git job
git house
git wife --better
exit

Nobody can teach programming, programming teaches you...

We've started a new betting system in our office. Every time you lose a bet, you have to optimize atleast one project for Internet Explorer 😂

For me, an application that's in 'Beta' is just a developer's excuse for bugs

We do these things not because they are easy, but because we thought they were going to be easy