The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I have bought one t-shirt and still wear it. I've also made donations of $5, $10, and $30 USD to different vloggers over the years and did a 1 month Patreon for $5. I did this to support their work as I felt they had gone above and beyond. The funny thing is I got thanked for the contribution for the $5 and $10 donation, but not the $30. And of those 3 contributions, only the $10 guy still makes videos today for YouTube. The $30 guy only makes videos for his private website. And lastly, the Patreon guy turned into a bitter troll; so I quit his Patreon and unsubscribed from his YouTube channel.
I've heard they make between $1 and $3 per 1000 views; so they do make a little cash if they're monetized.
Our clicks give them money too... Why should we buy more?
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
well... good question... hahah
though it does offer those "content creator" an expression medium with a wide reach...
but when it cancel the monetisation or even take it away..
at the very least it's unethical...
I compare the "state" of YT with the Music-Production in the Ninties.
The "democtratization" of Selling CDs and "cheap productions", lead to a oversaturation and the disruption of the Market.
The same is Happening to YT.
For me, the most annoying Part, it is all about "begging" for Money...
If the Channel is BIG, it is only selling Stuff.
If it is too small, it is "grinding" for any Penny, Nickle or how the smallest Coin in Your area is called...
And so Parteon comes too the rescue... Wait a moment... it is just too grind somewhere else... hmmmm...
So the similarity to the Music-Producer and the "Content-Creator", ist there.
Only the "hyped" and "pushed" can earn Money, all the rest is investing, just to keep it running.
And here is what YT was "giving" away, free Money for "the Creative" ones.
"But now, the free Lunch is over..."
You can see it on the YT, how Creators went to "extrimism" too stay in the Business.
Likes are bought, shady secondary Markets opened up...
For me Patreon is more a secondary Market for YT.
YT, as a Platform, is well established, now all the little ones can ask for Money, but keep it going is another Story.
BTW in Germany there is a Profession named "Content-Creator/Mediengestalter", who is capable to use all sorts of Industrial Application to manipulate "Pixels" and such...
I like to call them "Pixel-Schubser".
Translates to "Pixel-Pusher".
I saw it in real live... It was really hard to Push a Red Pixel, one by one to the right...
I can´t do this Work, my bad Spine... It is too hard...
Personally, I tend to disagree, particularly with the pluralized resource name and occasionally I find exception to the "noun" vs. "verb" rule, especially when I'm using a POST to provide a bunch of structured data for a GET (yes, it happens, particularly in my case when writing CC/ACH payment API's) and since GET is not supposed to have a body, and I don't want all that data in the URI, I revert to a POST with an endpoint like "getServiceFee".
But I'm curious what y'all think about how sticky the "guidelines" in that post should be.
Caveat: I don't have enough experience in this area to be qualified to pass judgment.
When consuming someone's API, I prefer explicitness. So, I think I like your approach of "getServiceFee".
However, that's a property of some larger entity, so I could certainly see the argument that one should just get the entity and look for ServiceFee within that. That scales; as new properties are added, the API has to change in the method you're describing.
As to the plural versus the singular, the author's examples give it away: to get the collection, you use plural; but then tacking on an id gives you companies/xxx, which returns a single company and seems clumsy.
I suspect the answer is just pick one and be consistent. I guess I prefer the pluralized version slightly, because it's more like this is a search API: get me all companies which qualify under the provided parameters (or lack thereof). I might even argue that companies/XXX should return a collection, even though we certainly expect only one to qualify, because it is a search.
But my lack of experience in this area probably means I'm filtering through the wrong lens.
Singular vs Plural is todays Tabs vs Spaces war. Both are correct for different reasons. I (we) tend to stay with singular unless there is a compelling reason to go plural. Primarily due to how some words pluralize (Person vs People).
This was an extremely lightweight article. The problem set is broader. Like, you have /populace endpoint. Do you return 300 million results or paginate the results? You need to incorporate security aspects. Do you have access to ALL the /populace (as a federal agency), or only some (as a state/province agency)? Even then, do you have access to all the data within a populace resource or only a limited set?
The problem I often see is thinking of the REST API like a programming API. It is not. If you go that way, you are building a RPC, and will have scaling issues at some point. You have to step back and really think resource. getServiceFee is communicative, but so is GET /serviceFee. But /serviceFee is not a "resource". It is part of a larger resource. Depending on access rights, it might be one of only a few elements available in the returned resource.
Bottom line, good REST is not simple or easy. It takes a lot of up front effort and then discipline to implement well. Even with that said, I (we) still got it wrong multiple times. Just less disasterously.
The cure to boredom is curiosity. There is no cure for curiosity. -- Dorothy Parker
I have to do so much processing to the codedom just to get VB to choke it down.
Why? The language is STUPID. That's why. There's no more succinct and accurate way to put it.
The grammar is stupid.
The runtime is stupid.
The language overall, is stupid.
You have two different equality operators you have to use depending on whether you're comparing reference types or value types. Because of that I have to visit every damned == and != in the tree, do type resolution on both sides of the expression (slow) and then based on that determine whether I should say "=" or "is"
You have to explicitly name your public implementation types for a method. So if i want to implement IEnumerator<t>.Current I have to also have Implements IEnumerable(of T)
This means for every public method you declare i have to go through all the base types of its declaring class, resolving each one (slow) to see if it matches the method signature (slow) of the declared method, so i can add Implements.
And don't get me started on the bugs in the VB codedom
It has taken me 2 hours just to fix all that crap
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
You have two different equality operators you have to use depending on whether you're comparing reference types or value types.
You use Is to compare for reference equality, and = to use the overloaded equality operator. But unlike C#, VB.NET won't fall back to using reference equality if the equality operator hasn't been overloaded.
Reference type vs value type is irrelevant, other than the fact that reference equality for value types will always be False.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer