SkillsPHP, TypeScript, JS, HTML, CSS
Joined devRant on 1/13/2018
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
--- HTTP/3 is coming! And it won't use TCP! ---
A recent announcement reveals that HTTP - the protocol used by browsers to communicate with web servers - will get a major change in version 3!
Before, the HTTP protocols (version 1.0, 1.1 and 2.2) were all layered on top of TCP (Transmission Control Protocol).
TCP provides reliable, ordered, and error-checked delivery of data over an IP network.
It can handle hardware failures, timeouts, etc. and makes sure the data is received in the order it was transmitted in.
Also you can easily detect if any corruption during transmission has occurred.
All these features are necessary for a protocol such as HTTP, but TCP wasn't originally designed for HTTP!
It's a "one-size-fits-all" solution, suitable for *any* application that needs this kind of reliability.
TCP does a lot of round trips between the client and the server to make sure everybody receives their data. Especially if you're using SSL. This results in a high network latency.
So if we had a protocol which is basically designed for HTTP, it could help a lot at fixing all these problems.
This is the idea behind "QUIC", an experimental network protocol, originally created by Google, using UDP.
Now we all know how unreliable UDP is: You don't know if the data you sent was received nor does the receiver know if there is anything missing. Also, data is unordered, so if anything takes longer to send, it will most likely mix up with the other pieces of data. The only good part of UDP is its simplicity.
So why use this crappy thing for such an important protocol as HTTP?
Well, QUIC fixes all these problems UDP has, and provides the reliability of TCP but without introducing lots of round trips and a high latency! (How cool is that?)
The Internet Engineering Task Force (IETF) has been working (or is still working) on a standardized version of QUIC, although it's very different from Google's original proposal.
The IETF also wants to create a version of HTTP that uses QUIC, previously referred to as HTTP-over-QUIC. HTTP-over-QUIC isn't, however, HTTP/2 over QUIC.
It's a new, updated version of HTTP built for QUIC.
Now, the chairman of both the HTTP working group and the QUIC working group for IETF, Mark Nottingham, wanted to rename HTTP-over-QUIC to HTTP/3, and it seems like his proposal got accepted!
So version 3 of HTTP will have QUIC as an essential, integral feature, and we can expect that it no longer uses TCP as its network protocol.
We will see how it turns out in the end, but I'm sure we will have to wait a couple more years for HTTP/3, when it has been thoroughly tested and integrated.
Thank you for reading!27
I keep forgetting people's birthdays and thereby I forget to wish people, and wishing people everyday can become a chore. As somebody once said, if you do something more than once, automate it.
Spent two hours and ended up building a bot that consists of four functions: login, checkIfAuthenticated, postToProfile and getBirthdaysToday using mostly axios and cheerio.
Currently works perfectly and I've been thinking of writing a blog post about it for my 'Automating Your Life' series.
I'll post the link in the comments soon when I'm done with the blog post.40
The inevitable happened, the user that I've answered tons of questions about freelancing deleted his account, thankfully I took backups and will recreate it [together with a killed joke] in the comments below (should've just webarchived it, meh)
I'll keep adding questions & answers I come across to make this a useful resource for people that want to get into freelancing, want to ask me something in the comments, you name it.
Might compile it into a better searchable resource eventually (some sort of blog with TOC), but right now neither do I have the time nor will to do that.
Wish I could have taken over the link that has been now posted a lot, but every post has an ID and I doubt it's possible, will tag dfox to clarify though and also floydian and devtea, that have been so nice to always post a link to that one rant.52
Personlly, Seeing repo commit history in Gource is really mesmerizing and amusing yet scary. especially your own.11
Okay, story time.
This rant is about the many mistakes I made at the time, specifically the biggest – but not the first – of which: publishing some preliminary results very early on.
So I posted a sarcastic question to the Software Engineering Stack Exchange, which was originally worded differently to reflect my frustration, but was later edited by mods to be more serious.
You can see the responses for yourself here: https://goo.gl/poHKpK
Most of the serious answers were along the lines of "multithreading is hard". The top voted response started with this statement: "1) Multithreading is extremely hard, and unfortunately the way you've presented this idea so far implies you're severely underestimating how hard it is."
While I'll admit that my presentation was initially lacking, I later made an entire page to explain the synchronisation mechanism in place, and you can read more about it here, if you're interested:
But what really shocked me was that I had never understood the mindset that all the naysayers adopted until I read that response.
Because the bottom-line of that entire response is an argument: an argument against change.
Nexus does not and will not hold your hand. It will not repeat Node's mistakes and give you nice ways to shoot yourself in the foot later, like `process.on('uncaughtException', ...)` for a catch-all global error handling solution.
No, an uncaught exception will be dealt with like any other self-respecting language: by not ignoring the problem and pretending it doesn't exist. If you write bad code, your program will crash, and you can't rectify a bug in your code by ignoring its presence entirely and using duct tape to scrape something together.
Back on the topic of multithreading, though. Multithreading is known to be hard, that's true. But how do you deal with a difficult solution? You simplify it and break it down, not just disregard it completely; because multithreading has its great advantages, too.
Like, how about we talk performance?
How about distributed algorithms that don't waste 40% of their computing power on agent communication and pointless overhead (like the serialisation/deserialisation of messages across the execution boundary for every single call)?
How about vertical scaling without forking the entire address space (and thus multiplying your application's memory consumption by the number of cores you wish to use)?
Some will say that the performance gains aren't worth the risk. That the possibility of race conditions and deadlocks aren't worth it.
That's the point of cooperative multithreading. It is a way to smartly work around these issues.
If you use promises, they will execute in parallel, to the best of the scheduler's abilities, and if you chain them then they will run consecutively as planned according to their dependency graph.
If your code doesn't access global variables or shared closure variables, or your promises only deal with their provided inputs without side-effects, then no contention will *ever* occur.
If you only read and never modify globals, no contention will ever occur.
Are you seeing the same trend I'm seeing?
When someone says we shouldn't use multithreading because it's hard, do you know what I like to say to that?
"To multithread, you need a pair."18
Watch 3 videos about iOS/Swift on YouTube, and now I'm getting a frontpage full of recordings of app development events and iPhone reviews.
Listen to one kpop track on Spotify out of curiosity, and now the recommendation playlist is polluted with music I really don't like.
If we are going to hand our balls to AI and expect it to be a glorious fondling fest, don't cry if it suddenly realizes "nuts? aren't those supposed to be cracked?".
I mean what's fucking next? Where will this "smart" shit end up?
I accidentally click on a my little pony meme, and amazon will drone-strike me with 500 gallons of glitter? I drunkenly mumble "OK google how do kangaroos fuck" in the back of a self-driving Uber, I'm going to be dropped off in a shady alley and raped by a dozen walibis?
STOP FUCKING TRYING TO UNDERSTAND ME, INTERNET. I JUST WANT TO FUCKING USE YOU, NOT BE USED BY YOU, THIS WASN'T THE DEAL.
If you truly understood me, internet, I would probably not even give a fuck about privacy. But you are all building these profiles wrong.
You don't understand that I might be interested in juggling tricks today, tomorrow it might be all about crocheting a wool sweater for my penis, and the day after that I'm curious how many corpses it would take to fill up an olympic swimming pool.
NO I'M NOT ACTUALLY INTERESTED IN THAT QUORA, STOP SENDING ME RECOMMENDATION EMAILS ON HIDING MURDER VICTIMS, MY BOSS WILL THINK I'M WEIRD.
Yeah of course I could pulls some plugs, anonymize the shit out of my online life. I respect those who manage to just say "Fuck you Google, I'm sick of your shit, I'm going cold turkey".
But these platforms are feeding us heroin-laced candy.
All your coworkers friends and family with their oled-lit zombiefaces, staring at tiny screens, all absent-mindedly grasping your ankles whispering "aww take one more hit with us, check out this funny youtube clip, let me send it to you on whatsapp.... what you don't have whatsapp? You deleted your facebook? don't you love grandma anymore? Why do you hate your family?"
Before you know it, you watched ten episodes about cultivating cactuses, have a year subscription to brilliant, skillshare, squarespace and 3 different organic foodboxes are delivered to your door, Netflix is spamming you about a cupcake baking show, and you're thinking about same-day delivery for a baseball bat so you can just beat the crap out of every pretty glass display you see.
I want to break up with you, Internet.
I love you, but I hate you.
Since you passed 2.0, you have grown into a manipulative bitch.
I just don't know if I'm strong enough. It's all "let's just be friends" with you, but I know you'll be trying to reel me back in.
Before I know it, you're feeding me cookies once again, and I'll end up balls deep with your trackers stuck to my dick.21
Postman: We will stop supporting our Chrome app. Please download our "Native" app for better performance.
No motherfuckers.. Go die, alone, while your fucking family watch you bleed to death helplessly.
Electron is not native, don't mix true native development with lazy ass electron. Fuck you. A native postman would've been around 15MB in size but your "native" installer is 68MB so shut the fuck up and don't call it native or I will stick my native dick in your fucking throats.
I develop native apps So yeah, I'm pissed when web devs are starting to call electron and JS as native desktop apps... They are not... Now fuck off you smelly cunts.40
I was thinking today about a certain aspect of running a software startup and then it came to me...
Hank Scorpio, from the Simpsons, was right in his approach.
So many time I have seen people get hired only for the company to get a less-than-optimal performance from them.
But why is this? Of course, it is many factors but one of the major ones is...
Employers seem to lump employees in together and assume that since most developers operate in one way that the new devs should be the same way.
The problem with this seems to be that we are all pandering to the lowest common denominator.
Let's face it, most devs (like most people) are not good, and almost everyone is not living up to their potential because of a lack of understanding of themselves and how they can achieve more.
On top of that, most devs are just employees who will do what you tell them to.
Since those above developers are the norm (Reference Seinfeld "95% of people are undatable") we have to assume that there is a 5% who are exceptional.
The difference between the 5% and the 95% is NOT some built-in superiority but that the 5% has a good idea themselves and an understanding of how to get the most out of them. They set goals and then find the right path to achieve them. They don't coast.
By assuming these developers are the same as the others is REALLY hampering their potential and by doing this the company only hurts itself.
So, that's a lot of talking but what actionable things can be taken away from this?
Hank asks Homer "What is your dream?"
Well, employeers should take the time to identify which of these developers are in the 5%. A problem arises though when the 5% decide it is in their best interest to blend in.
Like when home says his dream is to "Work for you?" Hank shuts him down and wants to get to the truth. He makes Homer comfortable with not only vocalizing but achieving his dreams.
When an employer is looking for their types they should be looking for the following...
1. A real genuine desire to achieve
2. A real plan to get their goals done
3. Critical thinking and self-evaluation
But more importantly, when they identify these types they should be asking questions like...
- How can we help you be more productive?
- Is there anything about our current operating norm that is hindering you?
- How does your productivity workflow look?
3 difficulties arise though…
1. Most hiring managers are incompetent, and quite frankly, everyone thinks they are in the 5% and for those managers who delude themselves into this without putting in the work, they will have an impossible time actually identifying those who are actually good and productive employees.
2. Showing special treatment to these folks may upset the people below.
3. You will hear things you don’t like…
- That new fancy open-office that you got because it was the trendy thing to do, you might hear that this is a huge hinderance.
- These days people seem to treat devs like nomads, “just give him a laptop and a table and he is fine”!. You may hear that this is complete BS. Real achievers may want a dedicated desk with multiple monitors, a desk with drawers etc.
- This WILL cost you money. I know of developers who cannot work without a dedicated whiteboard. Buy them whatever they need.
- They may want BOTH a standing desk and a chair to sit on.
The point is that it seems to me to be a foolish strategy to tailor your entire company to force everyone into the same work habits. Really good employees have the self-awareness to develop their own productive practices and any keeping of them inside a box will NOT help.27
A brilliant article that talks on the state of internet
The Bullshit Web - https://pxlnv.com/blog/...
Tldr: as internet speed increased, page loading time did not decrease because the extra bandwidth is being stuffed with unnecessary big scripts and autoplaying videos.
AMP is nothing more than a business tactic by Google26
I found this amazing repository on github and just had to share it.
I've already built a document scanner.
There's enough tutorials to keep a dev busy for a lifetime 😄17
I get sucked in for 10 minutes through some news article, and my blood is boiling.
I think the platform does not even deserve to exist.
And I didn't think I would ever say that.
I used to be a staunch defender of the free & open internet, even with it's ugly and extreme sides, because I was convinced the good would outshine the evil.
I displayed the Pirate flag with pride on the mast outside of my house, I was intimately involved in the founding of their political party in my country. I was convinced of the power of the internet, I believed it would empower democracy and debate.
So why do simple tweets, even just the ones about technology, incite an endless stream of vile ultranationalist & misogynist hate?
How is it that those who are reasonable get drowned out?
That fucking character limit is a cancer.
The orator's wings are clipped. The richness of language is wilting before our eyes. All that remains are a bunch of caged chickens pecking every argument to death.
I will defend the right to free speech, even when it comes to the most disagreeable and controversial opinions.
But Twitter does not promote free speech. It's poison to free speech.
It's an endless torrent of non sequiturs, which constricts all reason and intellect. It replaces free speech by pretending to have equal value.
I really don't care if you are left or right, socialist or libertarian, globalist or nationalist.
You can argue to me that we should close all borders for immigrants, that Apple makes great products, that genocide has its pros, you could try to convince me that Heineken tastes acceptable (sorry AlexDeLarge), that Linux should be outlawed or that we should really try to bring this Eugenics thing back again.
Just be fucking rational -- and "Rationality implies the conformity of one's beliefs with one's reasons to believe"
You can NOT fit both your beliefs and their supporting reasons in 140 or even 280 characters.
So what's left is just your beliefs.
Stripped of all reason.
Repeat it often enough, keep spewing, keep throwing out incomplete arguments, and you'll train yourself to forego ratio in your convictions completely.
All social platforms should get a forced captcha for every spelling/grammar error, and a 1000 character minimum.
The world would be a slightly better place.6
Currently using Matomo instead of Google Analytics.
Definitely a good alternative!
Especially if you don't want a big company to track YOUR users.5
Today, I learned the shortest command which will determine if a ping from your machine can reach the Internet:
This parses as 22.214.171.124, 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.12
As a developer, sometimes you hammer away on some useless solo side project for a few weeks. Maybe a small game, a web interface for your home-built storage server, or an app to turn your living room lights on an off.
I often see these posts and graphs here about motivation, about a desire to conceive perfection. You want to create a self-hosted Spotify clone "but better", or you set out to make the best todo app for iOS ever written.
These rants and memes often highlight how you start with this incredible drive, how your code is perfectly clean when you begin. Then it all oscillates between states of panic and surprise, sweat, tears and euphoria, an end in a disillusioned stare at the tangled mess you created, to gather dust forever in some private repository.
Writing a physics engine from scratch was harder than you expected. You needed a lot of ugly code to get your admin panel working in Safari. Some other shiny idea came along, and you decided to bite, even though you feel a burning guilt about the ever growing pile of unfinished failures.
All I want to say is:
No time was lost.
This is how senior developers are born. You strengthen your brain, the calluses on your mind provide you with perseverance to solve problems. Even if (no, *especially* if) you gave up on your project.
Eventually, giving up is good, it's a sign of wisdom an flexibility to focus on the broader domain again.
One of the things I love about failures is how varied they tend to be, how they force you to start seeing overarching patterns.
You don't notice the things you take back from your failures, they slip back sticking to you, undetected.
You get intuitions for strengths and weaknesses in patterns. Whenever you're matching two sparse ordered indexed lists, there's this corner of your brain lighting up on how to do it efficiently. You realize it's not the ORMs which suck, it's the fundamental object-relational impedance mismatch existing in all languages which causes problems, and you feel your fingers tingling whenever you encounter its effects in the future, ready to dive in ever so slightly deeper.
You notice you can suddenly solve completely abstract data problems using the pathfinding logic from your failed game. You realize you can use vector calculations from your physics engine to compare similarities in psychological behavior. You never understood trigonometry in high school, but while building a a deficient robotic Arduino abomination it suddenly started making sense.
You're building intuitions, continuously. These intuitions are grooves which become deeper each time you encounter fundamental patterns. The more variation in environments and topics you expose yourself to, the more permanent these associations become.
Failure is inconsequential, failure even deserves respect, failure builds intuition about patterns. Every single epiphany about similarity in patterns is an incredible victory.
Please, for the love of code...
Start and fail as many projects as you can.30
"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.
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.)8
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.49
You think a junior dev pushing his code onto a production server is bad? Wait till you have that admin who is illegally mining Bitcoin on your production server. 😂
I went for a Cyber Security conference today with one of managers and this was one of the life experiences some of the speakers shared.18
Only site which helped me alot to get me started in advance git commands was : ohshitgit.com
It also helped me when i started contributing in open source
Check it out :)3
Yo dawg, check out my fresh pimped homeoffice!
I have been a developer since I was 13 and this is the first time ever I feel complete :) Wish all of you even a better one than mine!77
wk87 is a dangerous topic for me, i've been through a lot. I apologise for what I am about to inflict on this network over the coming week.
Most incompetent co-worker, candidate 1, "T".
T was an embedded C developer who talked openly about how he's been writing code since he was 14, knew all the C system libraries and functions like the back of his hand. For the most part, he did ... but not how to actually use them, as (based on his shocking ... well everything) he was inflicted by some sort of brain disorder not yet fully understood by medical science. Some highlights:
- Myself and the CTO spent 4 days teaching him what a circle buffer was and how to build one.
- His final circle buffer implementation had about 3 times as much code as he actually needed.
- When the code was running too slowly on the device, we didn't try find any performance improvements, or debug anything to see if there was anything taking too long. No not with T, T immediately blamed TCP for being inefficient.
- After he left we found a file called "TCP-Light" in his projects folder.
- He accused the CTO of having "violent tendencies" because he was playing with a marker tossing it up in the air and catching it.
- He once managed to leave his bank statements, jumper and TROUSERS in the bathroom and didn't realise until a building wide email went out.
- He once .... no hang on, seriously his fucking trousers, how?
- He accused us all of being fascists because we gave out to him for not driving with his glasses, despite the fact his license says he needs to (blind as a bat).
... why were his trousers off in the first place? and how do you forget ... or miss the pile of clothes and letters in a small bathroom.
Moving on, eventually he was fired, but the most depressing thing of all about T, is that he might not even be top of my list.
Tune in later for more practiceSafeHex's most incompetent co-worker!!!11