Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn 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 -
Manager: Alright, we've decided we're gonna just going to accept PayPal and also credit card checkout through PayPal in the next two days!
Dev: ...
Manager: We can achieve this timeline, right?
Dev: ...
Manager: Alright, awesome to see your motivation! Let's do it!
Dev: YOU ANSWER PHONE CALLS, TALK TO PEOPLE AND 'STRATEGIZE' ALL DAY. YOU DON'T HAVE TO RELY ON THOUSANDS OF PEOPLE USING THE APP WITHOUT ERROR. THAT'S ON ME, NOT YOU, SO JUST SHUT THE FUCK UP!!!
Manager: ...
Dev: ...8 -
My sleep pattern is royally fucked. I searched around for alarm apps that can help me get back on track. I found one called Alarmy. The list of features was mindblowing. Fast forward a couple of weeks and I’m on vacation. I’m using my mobile data as a hotspot to browse and do research as there are no other internet options here.
My alarm goes off at 6 AM. Everyone besides me is sleeping. Here is where the first problem arises. The only way to turn the alarm off is by taking a picture of something I have at home (This is how I force myself out of bed). I start panicking. How the hell am I going to shut this damn thing off. I try to turn the phone off, and that’s when I realize I’ve made a huge error. The pro version of Alarmy has a setting that allows you to prevent yourself from turning it off at all. Genius me thought that was a good idea. I fumble with my phone as the 1 minute mute timer they give you is slowly ticking down, before all hell breaks loose. That’s when it hits me. I have an LG G3 with replaceable batteries. My violently pounding heart rate start to slow down as I take off the case and slamdunk the phone until the battery falls out. I did it. I’m saved. 5 minutes later I turn my phone on, start the hotspot and get back to my browsing.
BEEP F*CKING BEEP. Alarmy is not done with me yet. It turns out they’ve implemented a new feature that continues the damn alarm after a shutdown. At this point I have ran out of options. I take the battery back out, and now I’m sat here without no phone or internet for the rest of my vacation, and with no clue what to do.13 -
“PHP is evil” is not just a joke.
PHP is usually percieved as a language which is not so consistent and has some opinionated historical aspects but allows rapid development because it’s easy. They say PHP doesn’t focus on that “purist shit” such as concepts and “just gets things done”.
Hovewer, this is not true. PHP lures you in and lies to you promising saving time on development, but everything, and I mean EVERYTHING written in PHP is doomed to turn into a bloody mess sooner or later.
You have to be an AI to manage the growing PHP codebase and add features without breaking anything. With every feature it gets harder and harder. If you’re still a human managing a human team, you have to enforce guidelines. Automatic error preventon measures are made of code themselves so the cost of deploying them ona late stage can be ridiculous. And you never deploy them on early stage because you want to “save time”. Your people have to spend more and more time everyday checking on that guidelines. Your development process only becomes slower and slower. If you try to push things, your project will crumble to dust.
To make PHP at least decent, you have to figure out all this by yourself on an early stage. When you’re done, you spent a lot of time creating the buggy, ad-hoc, unspecified and unsupported alternative of what works out of the box in other languages. And you still code in PHP and still have all its disadvantages in your project’s DNA.
PHP is evil because it promises and never delivers. PHP is evil because it lies to you and it already fucked over so many of us.
If you want to code in PHP, do it under your pillow. Code your own silly projects.
If your project has the word “production” somewhere in its plans, PHP is not the way to go.
Amen.66 -
I propose that the study of Rust and therefore the application of said programming language and all of the technology that compromises it should be made because the language is actually really fucking good. Reading and studying how it manages to manipulate and otherwise use memory without a garbage collector is something to be admired, illuminating in its own accord.
BUT going for it because it is a "beTter C++" should not constitute a basis for it's study.
Let me expand through anecdotal evidence, which is really not to be taken seriously, but at the same time what I am using for my reasoning behind this, please feel free to correct me if I am wrong, for I am a software engineer yes, I do have academic training through a B.S in Computer Science yes, BUT my professional life has been solely dedicated to web development, which admittedly I do not go on about technical details of it with you all because: I am not allowed to(1) and (2)it is better for me to bitch and shit over other petty development related details.
Anecdotal and otherwise non statistically supported evidence: I have seen many motherfuckers doing shit in both C and C++ that ADMIT not covering their mistakes through the use of a debugger. Mostly because (A) using a debugger and proper IDE is for pendejos and debugging is for putos GDB is too hard and the VS IDE is waaaaaa "I onlLy NeeD Vim" and (B) "If an error would have registered then it would not have compiled no?", thus giving me the idea that the most common occurrences of issues through the use of the C father/son languages come from user error, non formal training in the language and a nice cusp of "fuck it it runs" while leaving all sorts of issues that come from manipulating the realm of the Gods "memory".
EVERY manual, book, coming all the way back to the K&C book talks about memory and the way in which developers of these 2 languages are able to manipulate and work on it. EVERY new standard of the ISO implementation of these languages deals, through community effort or standard documentation about the new items excised through features concerning MODERN (meaning, no, the shit you learned 20 years ago won't fucking cut it) will not cut it.
THUS if your ass is not constantly checking what the scalpel of electrical/circuitry/computational representation of algorithms CONDONES in what you are doing then YOU are the fucking problem.
Rust is thus no different from the original ideas of the developers behind Go when stating that their developers are not efficient enough to deal with X language, Rust protects you, because it knows that you are a fucking moron, so the compiler, advanced, and well made as it is, will give you warnings of your own idiotic tendencies, which would not have been required have you not been.....well....a fucking idiot.
Rust is a good language, but I feel one that came out from the necessity of people writing system level software as a bunch of fucking morons.
This speaks a lot more of our academic endeavors and current documentation than anything else. But to me DEALING with the idea of adapting Rust as a better C++ should come from a different point of view.
Do I agree with Linus's point of view of C++? fuck no, I do not, he is a kernel engineer, a damn good one at that regardless of what Dr. Tanenbaum believes(ed) but not everyone writes kernels, and sometimes that everyone requires OOP and additions to the language that they use. Else I would be a fucking moron for dabbling in the dictionary of languages that I use professionally.
BUT in terms of C++ being unsafe and unsecured and a horrible alternative to Rust I personaly do not believe so. I see it as a powerful white canvas, in which you are able to paint software to the best of your ability WHICH then requires thorough scrutiny from the entire team. NOT a quick replacement for something that protects your from your own stupidity BY impending the use of what are otherwise unknown "safe" features.
To be clear: I am not diminishing Rust as the powerhouse of a language that it is, myself I am quite invested in the language. But instead do not feel the reason/need before articles claiming it as the C++ killer.
I am currently heavily invested in C++ since I am trying a lot of different things for a lot of projects, and have been able to discern multiple pain points and unsafe features. Mainly the reason for this is documentation (your mother knows C++) and tooling, ide support, debugging operations, plethora of resources come from it and I have been able to push out to my secret project a lot of good dealings. WHICH I will eventually replicate with Rust to see the main differences.
Online articles stating that one will delimit or otherwise kill the other is well....wrong to me. And not the proper approach.
Anyways, I like big tits and small waists.14 -
I've spent a lot of time messing around with C, having struggled with object-oriented programming (due to not really knowing how best to structure things, not knowing when to apply certain design patterns).
When writing C code, I'd write OOP-esque code (pass around a struct to routines to do things with it) and enjoyed just making things happen without having to think too much about the overall design. But then I'd crave being able to use namespaces, and think about how the code would be tidier if I used exceptions instead of having every routine return an error code...
Working with Python and Node over the past couple of years has allowed me to easily get into OOP (no separate declaration/definition, loose typing etc.) and from that I've made some fairly good design decisions. I'd implemented a few design patterns without even realising which patterns they were - later reading up on them and thinking "hey, that's what I used earlier!"
I've also had a bit of an obsession with small executable files - using templates and other features of C++ add some bloat (on Windows at least) compared to C. There were other gripes I had with C++, mostly to do with making things modular (dynamic linking etc.) but really it's irrelevant/unreasonable.
And yes, for someone who doesn't like code bloat, working with Node is somewhat ironic... (hello, node_modules...)
So today I decided to revisit C++ and dust off my old copy of C++ in a Nutshell, and try to see if I could write some code to do things that I struggled with before. One nice thing is that this book was printed in 2003, yet all of its content is still relevant. Of course, there are newer C++ standards, but I can happily just hack away and avoid using anything that has been deprecated.
One thing I've always avoided is dynamic_cast because every time I read about it, I read that "it's slow". So I just tried to work around it when really if it's the right tool for the job, I might as well use it... It's really useful!
Anyway, now I've typed all this positivity about C++ I will probably find a little later on that I hit a wall with what I'm doing and give up again... :p
7 -
2 hour meeting to brainstorm ideas to improve our system health monitoring (logging, alerting, monitoring, and metrics)
Never got past the alerting part. Piss poor excuses for human being managers kept 'blaming' our logging infrastructure for allowing them to log exceptions as 'Warnings', purposely by-passing the alerting system.
Then the d-head tried to 'educate' everyone the difference between error and exception …frack-wad…the difference isn't philosophical…shut up.
The B manager kept referring to our old logging system (like we stopped using it 5 years ago) and if it were written correctly, the legacy code would be easier to migrate. Fracking lying B….shut the frack up.
The fracking idiots then wanted to add direct-bypass of the alerting system (I purposely made the code to bypass alerting painful to write)
Mgr1: "The only way this will work is if you, by default, allow errors to bypass the alerting system. When all of our code is migrated, we'll change a config or something to enable alerting. That shouldn't be too hard."
Me: "Not going to happen. I made by-passing the alert system painful on purpose. If I make it easy, you'll never go back and change code."
Mgr2: "Oh, yes we will. Just mark that method as obsolete. That way, it will force us to fix the code."
Me: "The by-pass method is already obsolete and the teams are already ignoring the build warnings."
Mgr1: "No, that is not correct. We have a process to fix all build warnings related to obsolete methods."
Mgr2: "Yes. It won't be like the old system. We just never had time to go back and fix that code."
Me: "The method has been obsolete for almost a year. If your teams haven't fixed their code by now, it's not going to be fixed."
Mgr1: "You're expecting everything to be changed in one day. Our code base is way too big and there are too many changes to make. All we are asking for is a simple change that will give us the time we need to make the system better. We all want to make the system better…right?"
Me: "We made the changes to the core system over two years ago, and we had this same conversation, remember? If your team hasn't made any changes by now, they aren't going to. The only way they will change code to the new standard is if we make the old way painful. Sorry, that's the truth."
Mgr2: "Why did we make changes to the logging system? Why weren't any of us involved? If there were going to be all these changes, our team should have been part of the process."
Me: "You were and declined every meeting and every attempt to include your area. Considering the massive amount of infrastructure changes there was zero code changes required by your team. The new system simply worked. You can't take advantage of the new features which is why we're here today. I'm here to offer my help in any way I can with the transition."
Mgr1: "The new logging doesn't support logging of the different web page areas. Until you can make that change, we can't begin changing our code."
Me: "Logging properties is just a name+value pair dictionary. All you need to do is standardize on a name and how you add it to the collection."
Mgr2: "So, it's not a standard field? How difficult would it be to change the core assembly? This has to be standard across all our areas and shouldn't be up to the developers to type in anything they want."
- Frack wads smile and nod to each other like fracking chickens in a feeding frenzy
Me: "It can, but what will you call this property? What controls its value?"
- The look I got from both the d-bags I could tell a blood vessel popped.
Mgr1: "Oh…um….I don't know…Area? Yea … Area."
Mgr2: "Um…that's not specific enough. How about Page?"
Mgr1: "Well, pages can cross different areas, and areas cross different pages…what do you think?"
Me: "Don't know, don't care. It's up to you. I just need a name."
Mgr2: "Modules! Our MVC framework is broken up in Modules."
DevMgr: "We already have a field for Module. It's how we're segmenting the different business processes"
Mgr1: "Doesn't matter, we'll come up with a name later. Until then, we won't make any changes until there is a name."
DevMgr: "So what did we accomplish?"
Me: "That we need to review the web's logging and alerting process and make sure we're capturing errors being hidden as warnings."
Mgr1: "Nooo….we didn't accomplish anything. This meeting had no agenda and no purpose. We should have been included in the logging process changes from day one."
Mgr2: "I agree, I'm not sure why we're here"
Me: "This was a brainstorming meeting as listed in the agenda. We've accomplished 2 of the 4 items. I think we've established your commitment to making the system better. Thank you all for coming."
- Mgr1 and 2 left without looking at me or saying a word.1 -
I'm having problems understanding ngrx (or simply rxjs...), once again.
I have a feature state called "World".
This state has three Actions: Init, InitSuccess and InitFailure.
Also I have other isolated feature states like "Mountains", "Streets", "Rivers".
They have actions like this and corresponding effects to fetch data: Load, LoadSuccess, LoadFailure.
Now I would like to add an effect to WorldActions.Init, which will dispatch Mountains.Load, Streets.Load, Rivers.Load one after another. So ideally an action log would look like this:
1. World.Init
2. Mountains.Load
3. Streets.Load
4. Rivers.Load
5. Mountains.LoadSuccess
6. Streets.LoadSuccess
7. Rivers.LoadSuccess
8. World.InitSuccess
Or when an error occurs:
1. World.Init
2. Mountains.Load
3. Mountains.LoadFailure
4. World.InitFailure
How could an effect pipeline for that look?
How can I dispatch World.InitSuccess only after all LoadSuccess-Actions have happened?
Or am I still trying to implement ngrx in a wrong/bad way?
PS: The reason I am putting everything into separate feature states is because "Mountains" etc. are standalone features on their own. Only in the context of a "World" they belong together. For this reason I can't create a monstrous effect "World.Load", without producing redundant code.10
Top Tags
Weekly Rant
View