Yea, fair enough. My point was mostly: backend requirements are usually at least objective. "Json xml comes in", "CSV goes out by email", "The request must be processed under 100 ms", "API should not return 400 on feetpics" - these are still mostly objective requirements.
Frontend requirements can be very subjective "The user should have a great user experience with the frontend"
4.2 (5 ratings)
5 ratings... doesn't really seems like anyone is actually using this. The $20/user/month is probably a hail mary of "Lets throw this product out there, and if just one company with like 100 users accidentally enables this thing, we're good"
Backend Requirements: "When x,y goes in, I want x+y to come out!" - Okay
Frontend Requirements: "Well it needs to be more user-friendly, and have this rockstar wow effect" - Yea wtf are you even talking about? You want me to add random glitter explosions, because I found a script for that, that's pretty 'wow effect' right?
and, perhaps more critically, some Chinese GPU makers from utilizing CUDA code with translation layers.
Like that ever deterred China from violating copyright claims to trademarks. Maybe if they're huge companies that want to export, but if they're just making in-country chips, especially if it's useful for the Chinese government, these companies are not going to change anything based on some license warning
A scope is already implied by brackets. For example, a namespace, class, method, if block are also scopes.
So I don't really see why you'd want an explicit scope keyword inside methods, when all other scopes are implied... That just creates an inconsistency with the other implied scopes
It depends on the language, since you mentioned you don't want to do manual testing -
Start with a mono-repo, as in, 1 repo where you add every other repo as a git submodule
Then, every time something changes you run that repo though the build server, and validate that it at least compiles.
If it compiles, you can go a step further, build something that detects changes, for example by parsing the syntax tree of everything changed, then check the syntax tree of the entire project which other methods / objects might be affected. In dotnet you'd do this with a Roslyn Analyzer
What if you do it ironically? Like calling yourself a Code Ninja Jedi 10x Rockstar 🚀?
I've never really needed to use rebase, but my workflow is probably kinda weird:
git checkout -b new_feature_branch, and so move my changes to a different branchgit reset head~10 meaning all 10 commits are reverted into staged changesgit push -f the new commit back to origin (of feature branch)It works pretty well for me, but I was told its weird, and I should rebase instead
- He doesn’t mention performance impacts, but I suspect this would impact performance.
It looks like he's using an Analyzer to generate interceptors. More detailed on how those interceptors works is pretty good explained here: https://www.youtube.com/watch?v=91xir2oUQPg
So performance wise, this shouldn't change the performance impact any more than manually wiring in loggers on every level. - It might slow down the compile time by a little bit though.
A project that does something very similar but for Mediators is Mediator.SourceGenerator - an alternative to MediatR - but that project does it for Mediators instead of logging
The "original" way of doing something like this was by using Castle DynamicProxy, and creating an interceptor at runtime. Which would affect runtime performance more than doing it compile time
And another alternative way of doing the same thing would be using Fody - Creating logging attributes or interfaces, and then using Fody to wire in logging. Though Fody would be doing it during post-compile though an IL Weaver.
So this Roslyn Source Generator weaving approach is basically the best way to approach this
I think I couple of those points come down to the tech-lead to write a "Definition of Done"
1 - This is useful for junior members or new members to know what to expect. For example, "Definition of Done" would include that a new function should be documented, it should be refactored into clean code by the code standards, it should be tested by QA, there should be unittests covering the function, the function should be released to production to be marked as done - etc
2 - When giving managers that don't know anything about coding an estimation - either by you, or by someone in your team - they can take the Definition of Done" as a reference point. If a manager asks how long something will take, you don't just consider "Oh, I guess I can build this in a couple of days". Yea ok sure, you can build it to meet the managers minimal requirements for the function to kinda work but its messy code and untested - so if you keep in mind that there are loads of other meta-things to do besides just building code, you can pretty much double your initial estimation
Otherwise you just accumulate more and more technical dept, and at some point your "just build it" estimation gets inflated because for every change you have to touch lots of 1000 line files, figure out what broke by the changes, fix that, see what failed now, etc etc
And it would have been better in the long run if you would have spend more time on it while you were working on the function
Are you actually trying to use apple_pay, or it that just an irrelevant error you’re not expecting?No, like I said, apple_pay is disabled ( willingly ) in the stripe dashboard, so I don’t know why the error mention even apply_pay…
Well it wasn't clear whether you were trying to use apply_pay and it magically worked in firefox, but not in Chrome, or Chrome incorrectly things you're trying to use apply_pay...
Have you explicitly declared which payment methods are allowed to be used in your script? Maybe if you haven't declared anything the browser just infers it somehow, and Firefox and Chrome might have a difference in inferring default value
Hahah, well as a primarily backend developer, that's what I think as well.
If that button doesn't work, that sounds like a frontend problem to me.. ;)
But yea, as you mentioned, it probably comes down to experience. As the meme from this post depicts. When I dabble in frontend and make a WinForm for my devtool, people just look at me and are like "Uhhh, can you make it better?"
No sir, clearly I can not. And I have no idea what you mean with "better".