I don’t know if it’s “most people,” but I agree, there is no excuse for frameworks producing sloppy output - that being said, XHTML is a bit more chatty than HTML(5), so there is some minor benefit to not using the less verbose standard.
As an end result, maybe. But it also means that you get specific feedback on how to properly author it correctly and fix it before pushing it live.
IDK, I lived through that whole era, and I’d attribute it more to the fact that HTML is easy enough to author in any text editor by complete novices. XHTML demands a hell of a lot more knowledge of how XML works, and what is valid (and, more keystrokes). The barrier to entry for XHTML is much, much, higher.
And you can do the previous years of the coding challenge at any time.
I took some time off, and this was a good source of solving “real” problems, rather than trying to write something to optimize for l33tcode (which, is fine… just not a good measure for typical software engineering responsibilities, IMO).
Like I said in my other comment, I think people tend to lump all of MSFT's activities into the same bucket. DevDiv has always seemed pretty decent, and I am usually reminded of this comic when people talk about MSFT's "shady" activities.
Everything is temporary. If we were talking about a niche language, I might worry a little bit that it could just lose momentum and die. But TS is a juggernaut. The only way typescript “dies” is if JS integrates enough of its features to make it redundant.
Besides that, if Oracle managed to allow Java to continue to grow and flourish, I have confidence that MS can do at least that well. I also think lumping all of MS’s products into the same boat is a mistake. They have been pretty good stewards of their languages for decades.
I used to be full on the ORM train. Now I’m a little less enthusiastic. What I actually think people need most of the time is something closer to ActiveRecord. Something that can easily map a result set into a collection of typed objects. You still generally write parameterized SQL, but the work of translating a db decimal into the correct target type on a record object in your language is handled for you (for example). In .net, Dapper is a good example.
I also think most people overemphasize or talk about how other programmers “suck at SQL” waaayy too much.
IMO, for most situations, these are the few high-level things that devs should be vigilant about:
parameterize all sql.
consider the big-o of the app-side lookup/write methods (sometimes an app join or pulling a larger set and filtering in memory is better than crafting very complex projections in sql). This is a little harder to analyze with an ORM, but not by much if you keep the mappings simple and understand the loading semantics of the ORM.
understand the index coverage of queries and model table keys properly to maintain insert performance (monotonically increasing keys).
stop fixating on optimizing queries that run in a few seconds, a few times a day. Optimize the stuff that you run on every transaction - if you need to.
On most of those points, if you don’t have aggregate query counts/metrics on query performance on your clusters, starting to get cute with complex queries is flying blind, and there’s no way to prioritize what to optimize.
For the vast majority of cases, simple, obvious selects that don’t involve special db features are going to do the job for most applications. When the database becomes a bottleneck, there are usually much more effective ways to handle them than to try to hand optimize all the queries.
Lastly, I have a little bit of a theory that part of the reason people do/do not like looking at SQL in code is because it’s a hard context switch from one language to another, often requiring the programmer to switch to “stringly-typed” mode, something we all learn causes huge numbers of headaches in our first few months of programming. Some developers accept that there’s going to be different languages/contexts and not all of them are going to be as fluent or familiar, but accept that this is par for the job. Others recoil from the unfamiliar and want to burn it down. IMO, the former attitude is a lot more productive.
UTF-8, doubly so. One of the amazing/clever things they did was to build off of ASCII as a subset by taking advantage of the extra bit to stay backwards compatible, which is a lesson we should all learn when evolving systems with users (your chances of success are much better if you extend than to rewrite).
On the other hand, having dealt with UTF-7 (a very “special” email encoding), it takes a certain kind of nerd to really appreciate the nuances of encodings.
I'm a go n00b, but since the source code is available, I figured I'd look. TL;DR: it probably uses the shell's default globbing resolution to produce the file list.
You can probably learn what it's doing by running go generate -n or go generate -x, and I think you can also explicitly call go generate with a file pattern list, which would give you this control.
Otherwise, I think you can include more than one magic comment in a single file, so if you have some dependant generators, these could be placed in the same file, sequentially, and you'd get the expected result.
Another alternative would be to try renaming the relevant files so that they sort the way you want them to run, lexicographically.
Sure you could say it about “any language,” but I think you’re skipping a lot of nuance with your examples: python has notoriously had a long transition from 2 -> 3. C is 40+ years old, and the semantics and idioms of the language aren’t changing from month to month.
I think the parent comment is making the point that the pace of change and evolving idioms/features of Rust means that code you write today may need to be updated in a far shorter timespan than the typical timeline for working code (a few months, rather than several years). The bitrot is just a lot faster right now than other languages.
I’d rather they ask me a question on something for which I’m an expert (myself) and that I can prepare for, than to fire off leetcode question.
Yeah, it’s a little bit redundant, but it can break the initial tension and get the conversation going. You can also use the time to emphasize some specific aspect of your work history that you think matches up with the job req, or shows why you actually want to work there.
If they don’t ask this question/prompt, what question would you want them to ask?
It literally doesn’t matter. You can remove the word and the nature of the problem being discussed is still the same. What platform is being targeted has nothing to do with the example problem. Roblox is only mentioned to sensationalize it and get clicks.
It’s misleading because it’s irrelevant and makes it sound like a platform breach.
Try replacing Roblox with “Foozsplatz” and the implication of severity is completely different, even though the nature of what is being reported is unchanged.
I don’t know the specifics of the golf problems, but I’m mostly in c#, also notorious for “having too much boilerplate,” and it looks like it’s 3rd by char count.
My guess is that languages with comprehensive standard libraries can do more with less custom code. As you should expect.
Important/generalized patterns reveal themselves over time. I generally push for people to just write the specific thing they need for the given context and then if the same pattern shows up elsewhere, promote the code to a shared library. It’s really hard to anticipate the correct abstraction right from the start, and it’s easy to include a bunch of “just in case” parameterization that bloats the interface and adds a lot of conceptual overhead.
That being said, with low-leverage/complexity code like html views, repetition isn’t as problematic. Although, I do think that HTML components have matured enough to be the correct unit of abstraction, not CSS classes.
Demo videos are not “documentation.” They are “demos.”
If you want someone to repeat your steps, it should be code or CLI commands. You can write more descriptive text, but as soon as you reference pictures to show something, you’re introducing ambiguity that text/code can avoid.
UIs change faster than videos and screenshots, as you said, can’t be searched, and are generally less accessible than text.
The source files for documentation should also live side-by-side with the code in the repo. As soon as it goes anywhere else, it immediately goes out of date.
Yeah, -p can help with that. I’m not much for “commit grooming” - as long as a branch merges to main cleanly and passes tests, I don’t care about an “ugly” commit history.
I don’t know if it’s “most people,” but I agree, there is no excuse for frameworks producing sloppy output - that being said, XHTML is a bit more chatty than HTML(5), so there is some minor benefit to not using the less verbose standard.