Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
codeCertain - Duolingo styled code learning platform that emphasizes learning by repetition. Be certain of your code. [more details]5
So today (or a day ago or whatever), Pavel Durov attacked Signal by saying that he wouldn't be surprised if a backdoor would be discovered in Signal because it's partially funded by the US government (or, some part of the us govt).
Let's break down why this is utter bullshit.
First, he wouldn't be surprised if a backdoor would be discovered 'within 5 years from now'.
- Teeny tiny little detail: THE FUCKING APP IS OPEN SOURCE. So yeah sure, go look through the code! Good idea! You might actually learn something from it as your own crypto seems to be broken! (for the record, I never said anything about telegram not being open source as it is)
- The server side code is closed (of signal and telegram both). Well, if your app is open source, enrolled with one of the strongest cryptographic protocols in the world and has been audited, then even if the server gets compromised, the hackers are still nowhere.
- Metadata. Signal saves the following and ONLY the following: timestamp of registration, timestamp of the last connection with the server (both rounded to the day so not on the second), your phone number and your contact details (if you authorize it) (only phone numbers) in HASHED (BCrypt I thought?) format.
There have been multiple telegram metadata leaks and it's pretty known that it saves way more than neccesary.
So, before you start judging an app which is open, uses one of the best crypto protocols in the world while you use your own homegrown horribly insecure protocol AND actually tries its best to save the least possible, maybe try to fix your own shit!
*gets ready for heavy criticism*20
Internship number two.
*walks downstairs to get a coffee*
*CTO (my guider) walks in*
CTO: (dead serious face) "linuxxx (not using my first name :P), come with me please"
*walks along to his office, starting to get reallly fucking nervous*
*CTO and me walk into his office, he sits down and looks at me very serious*
*I'm slightly shaking, nervous, sweating*
*oh yes here it is its gonna come I did something wrong fuck fml 😫😥😨😩*
CTO: "So you know quite some stiff around security/privacy. Could you tell me some stuff about why I'd want to use VPN and recommend me some good providers? 😀"
*nearly falls onto the ground from relief*
I explained him some stuff and sent him a list of good providers 😀30
De-google your life
-duck duck go look up the founder
-yandex (putin botnet)
-https://kek.gg/i/3g2z6d.png (superior list)
-https://kek.gg/i/67YQQx.jpg (for furfags)
-ether pad (eg: notes.typo3.org or etherpad.net)
-microsoft office online (lol)
-gnu social (for freedom loving patriots)
-mastodon (for proprietary loving gook pedos and sjws)
Google CDN avoidance
Ad and script blocking
Share links without gibbing clicks
How to hosts file (lol, just block google bro):
I'm currently rewriting perfectly clean and functioning Scala code in Java (because "Enterprise", yay). The amount of unnecessary boilerplate I have to add is insane. I'm not even talking big complicated code but two liners or the lack of simple things like a range from 5 to 10.
Why do I have to write
List<Position> occupiedPositions = placedEntities.stream()
.flatMap((pe) -> pe.occupiedPositions().stream())
instead of simply
val occupiedPositions = placedEntities.flatMap(_.occupiedPositions)
Why on earth does `occupiedPositions.distinct` suddenly become a monstrosity like `occupiedPositions.stream().distinct().collect(Collectors.toList())` where the majority of code is pure boilerplate? And this is supposed to be the new and better Java8 api which people use as evidence that Java is now suddenly "functional" (yeah no, just no).
Why do APIs that annotate parameters with @Nullable throw NullPointerExceptions when I pass a null? Why does the compiler not help prevent such stupidity? Why do we use static typing PLUS those annotations and it still crashes at runtime like every damn dynamic, interpreted language out there? That's not unfortunate, it's a complete waste of time.
Why is a simple idea like a range from x to 10 (in scala literally `x to 10`) not by default included in Java? There's Guava's version of Range which does not have a helper for integer ranges (even though they are the most used ones). Then there's apache.commons version which _has_ a helper for integers, but is strangely not iterable (wtf I don't even...).
Speaking of Iterable: How difficult could it be to convert an abstract Iterable<T> into a concrete List<T>? In scala it's surprisingly `someIterable.toList`. I found nothing like that so I took to stackoverflow where I found a thread in which people suggested everything from writing your own ListUtils helper class, using Guava (which is a huge dependency!) to using the new Java8 features inline (which is still about three lines long). I didn't know this was such a hard problem in computer science, TIL.
How anyone can be productive in this abomination of a language is beyond me now, even though I've used it for many years while learning to code (back then I didn't know there were much better ways to do things). The only good part is that I have to endure this nonsense for only about 3 days longer then I'm free again!12
5 Types Of Programmers
1.The duct tape programmer
The code may not be pretty, but damnit, it works!
This guy is the foundation of your company. When something goes wrong he will fix it fast and in a way that won’t break again. Of course he doesn’t care about how it looks, ease of use, or any of those other trivial concerns, but he will make it happen, without a bunch of talk or time-wasting nonsense. The best way to use this person is to point at a problem and walk away.
2.The OCD perfectionist programmer
You want to do what to my code?
This guy doesn’t care about your deadlines or budgets, those are insignificant when compared to the art form that is programming. When you do finally receive the finished product you will have no option but submit to the stunning glory and radiant beauty of perfectly formatted, no, perfectly beautiful code, that is so efficient that anything you would want to do to it would do nothing but defame a masterpiece. He is the only one qualified to work on his code.
3.The anti-programming programmer
I’m a programmer, damnit. I don’t write code.
His world has one simple truth; writing code is bad. If you have to write something then you’re doing it wrong. Someone else has already done the work so just use their code. He will tell you how much faster this development practice is, even though he takes as long or longer than the other programmers. But when you get the project it will only be 20 lines of actual code and will be very easy to read. It may not be very fast, efficient, or forward-compatible, but it will be done with the least effort required.
4.The half-assed programmer
What do you want? It works doesn’t it?
The guy who couldn’t care less about quality, that’s someone elses job. He accomplishes the tasks that he’s asked to do, quickly. You may not like his work, the other programmers hate it, but management and the clients love it. As much pain as he will cause you in the future, he is single-handedly keeping your deadlines so you can’t scoff at it (no matter how much you want to).
5.The theoretical programmer
Well, that’s a possibility, but in practice this might be a better alternative.
This guy is more interested the options than what should be done. He will spend 80% of his time staring blankly at his computer thinking up ways to accomplish a task, 15% of his time complaining about unreasonable deadlines, 4% of his time refining the options, and 1% of his time writing code. When you receive the final work it will always be accompanied by the phrase “if I had more time I could have done this the right way”.
What type of programmer are you?
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!190