Is it the word “lawyer” or spending some small amount of money?
Lawyers are bound by law and an ethical code to conduct business in a particular way. They also tend to have support infrastructure and continuity plans that private individuals do not.
If making sure something actually happens is important to you, this is the best option.
Douglas Crockford, author of “JavaScript: The Good Parts” has said:
“JavaScript is the only language in the world that people think they write without learning it first.”
I think this is a true statement (well, that and bash).
Programming and Software Engineering are related, but distinct fields. Programming is relatively easy, Software Engineering is a bit harder and requires more discipline in my opinion.
Writing fast unit tests will require some refactoring that could end up being pretty extensive.
For example, you mentioned “cloud storage” - if this is not already behind an interface one ticket could be to define an interface for accessing “cloud storage” and make it so that it can be mocked for most tests and the concrete implementation can be tested directly to confirm the integration works. Try to hone down that interface so that it’s as few methods as possible, only allow the parameters you’re actually using to be exposed and used in the interface. You can add more later if it’s absolutely necessary.
Do this for anything that does I/O and/or is CPU intensive.
So, to do tickets, I’d basically say, one per refactoring.
Going forward, writing “unit tests” should not be separate tickets, it should be factored into the estimates for the original stories, and nothing should go out without appropriate tests. The operational burden will decrease over time.
QA should have their own unit for how they want to test the application. Usually this is a suite per section of the app. If your app has an API, that is probably going to have a nice logical breakdown of the different areas that could each have their own ticket for adding QA-level test suites. The tests that developers write should only be additive and reduce the workload of QA. What you want to be sure of is that change sets are getting reviewed and through the entire pipeline without getting logjammed in any stage. Ideally, individual PRs are getting started and deployed in less than a week.
If you’re interested in more techniques, check out the book “Working effectively with legacy code.” It has a lot of patterns for adding tests to existing codebases.
You are really looking for architecture diagrams. These are extremely rare in most projects, open source or otherwise.
The reason you don’t see a lot of documentation on algorithms used or architecture is that most of the time the code is not actually novel. It’s like asking a plumber to describe the physical properties of the pipe they used on a job. They’d say “schedule 40” or “copper” and a dimension. They would not describe the manufacturing process or chemical composition of the pipe. The materials are pretty standard and only require special descriptions for when and why they deviate from those standards.
If these systems could only reorganize and regurgitate 1000 creative works, we would not be having this conversation. It’s literally because of the scale that this is even relevant. The scope of consumption by these systems, and the relative ease of accessibility to these systems is what makes the infringement/ownership question relevant.
We literally went through this exercise with fair use as it pertains to CD/DVD piracy in the 90’s, and Napster in the early 2000’s. Individuals making copies was still robbing creative artists of royalties before those technologies existed, but the scale, ubiquity, and fidelity of those systems enabled large-scale infringement in a way that individuals copying/reproducing them previously could not.
I’m not saying these are identical examples, but the magnitude is a massive factor in why this issue needs to be regulated/litigated.
I think the “learning” process could be similar, but the issue is the scale.
No human artist could integrate the amount of material at the speed that these systems can. The systems are also by definition nothing but derivative. I think the process is similar, but there is important nuance that supports a different conclusion.
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.
deleted by creator
deleted by creator
Just to add, I’d argue dotnet has one of the best sets of guidance on style. It goes beyond just naming and towards how to structure code for easier consumption and consistency. People love to dump on MSFT, but the dotnet platform is superb.
https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/
I generally find that writing code that requires a lot of “accounting” is very prone to mistakes that are easier to avoid with recursion. What I mean by this is stuff where you’re tracking multiple counters and sets on each iteration. It’s very easy to produce off by one errors in these types of algos.
Recursion, once you get the hang of it, can make certain kinds of problems “trivial,” and with tail-call recursion being implemented in many languages, the related memory costs have also been somewhat mitigated.
Loops are simpler for beginners to understand, but I don’t think recursion is all that hard to learn with a bit of practice, and can really clean up some otherwise very complicated code.
My general opinion is that we are all beginners for a short part of our journey, but our aim shouldn’t be to make everything simple enough that beginners never need to advance their skills. We spend most of our careers as journeymen, and that’s the level of understanding we should be aiming for/expecting for most code. Recursion in that context is absolutely ok from a “readability/complexity” perspective.
You should do some research on wasm.
You can run frickin’ docker containers in the browser now.
I don’t make the rules.
I believe the setting is user.email so maybe confirm that’s what you have set in both? Git will silently ignore settings that aren’t used/defined.
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).
It’s necessarily complexity that is easily encapsulated in methods.
If those methods are under test to verify their behavior, trivial typos can be detected instantly, without adding another dialect and more conceptual overhead to a project.
If those methods are not under test, then there’s a tiny bit of help by using a DSL if it can be compile-time checked.
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:
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.
Many of the “frivolous” lawsuits you’ve actually heard about are effectively smear campaigns against the plaintiffs.
The lawsuit against MacDonald’s for the hot coffee one is a great example.
Yes, people do dumb stuff, or fantasize that a situation could be their golden ticket, but that is the cost of having a civil judicial system. You either have to allow some crazy in, or prejudge and filter out what you’d consider legitimate cases. I just don’t have the energy, or care enough to be annoyed by inefficiency in the a system that I rarely interact with.
The criminal system is a different story, because the way we currently prosecute different kinds of crimes offends my basic sense of fairness.