401–410 of 416 posts
Earlier quoted context omitted.
Also, just get to know your shell. big timesaver: control-r basic but useful all over: for i in *.c; do cp "$i" "$i.bak"; done etc...
What does double quotes dollar do in the command?
Earlier quoted context omitted.
I hate makefiles. That said, I wholeheartedly agree with the comment. It's sad that something so central to a project and so useful and important to so many people seems like it hasn't advanced ... ever. Developers generally do the minimum with Makefiles and get out. They are similar to 1040 forms in popularity. I've always had a dream of a redesigned "make" system... with import statements, object oriented rules, cl…
> It's awesome that something so popular is so well engineered that it doesn't need changes. There, fixed it for you. In particular, I'm glad that the OO cancer hasn't spread to something as basic as a build system.
At the job I'm at, I've picked up three tools either for the first time, or in a very new way: 1. Makefiles. See @aequitas' comment for more. 2. Terraform. Seriously, just using this tool taught me [a lot of] devops. It's fantastic! 3. Docker (as a tool!) I'm going to go into the third one a bit - I feel like Docker is mostly thought of as useful for deploying things to the 'net (kubernetes, ECS, etc), but I think it…
I'm also occasionally using Docker t generate build artifacts (so +1 for that) - how do you pull the built blob out of the image? I've used `docker exec` plus `docker cp`, but it feels a little clunky.
Another way to do it would be to have the `docker run` / `docker build` script be given a mounted volume that maps to the system's, and then it would write the blobs to that volume, where (I think?) they'd then be accessible to the outer system.
Earlier quoted context omitted.
We're doing this, and I mostly love it. I haven't found a great way to do code re-use across projects yet, and I'm not super happy with the Make function syntax (but, maybe if it needs a function, I should turn it into a shell script that itself is called by the Make command...). All in all tho, it's a fantastic place to write down long CLI commands (ex: launching a dev docker container with the right networking and…
When using it in multiple projects and CI you also tend to develop some kind of Developer-API with common commands/targets. No matter what kind of project you run you always use the same target names to get started. No remembering which tool is used for this lanuage, just clone it, run `make` and you're off, `make test` to test, etc. Make does support includes ( https://www.gnu.org/software/make/manual/html_node/Incl…
Oh absolutely. It's fantastic for that. Our build pipeline actually relies on that; every project has a "release" target that is basically for the CI to use.
> Make includes
Yeah, I looked into that, and I think I had the same conclusion.
> scripts called from the Makefile
That's what I'm thinking is the way to level up this kind of system. Although then, why have `make init` instead of just `./bin/init` ?
Makefiles. I always dismissed them as a C compiler thing. Something that could never be useful for Python programming. But nowadays every project I create has a Makefile to bind together all task involved on that project. From bootstrapping the dev environment, running checks/test, starting a devserver, building releases and container images. Makefiles are just such a nice place to put scripts for these common tasks…
Makefiles. I always dismissed them as a C compiler thing. Something that could never be useful for Python programming. But nowadays every project I create has a Makefile to bind together all task involved on that project. From bootstrapping the dev environment, running checks/test, starting a devserver, building releases and container images. Makefiles are just such a nice place to put scripts for these common tasks…
I hate makefiles. That said, I wholeheartedly agree with the comment. It's sad that something so central to a project and so useful and important to so many people seems like it hasn't advanced ... ever. Developers generally do the minimum with Makefiles and get out. They are similar to 1040 forms in popularity. I've always had a dream of a redesigned "make" system... with import statements, object oriented rules, cl…
Earlier quoted context omitted.
When using it in multiple projects and CI you also tend to develop some kind of Developer-API with common commands/targets. No matter what kind of project you run you always use the same target names to get started. No remembering which tool is used for this lanuage, just clone it, run `make` and you're off, `make test` to test, etc. Make does support includes ( https://www.gnu.org/software/make/manual/html_node/Incl…
> common commands Oh absolutely. It's fantastic for that. Our build pipeline actually relies on that; every project has a "release" target that is basically for the CI to use. > Make includes Yeah, I looked into that, and I think I had the same conclusion. > scripts called from the Makefile That's what I'm thinking is the way to level up this kind of system. Although then, why have `make init` instead of just `./bin/…
In the `make init` example. It doesn't matter how many intermediate steps are involved `init` is the end-state I want to achieve. So in most of my Makefiles the `init` target will fan-out into requirements as wide and deep as it needs, including running apt to install missing system dependencies. But then the good part. If a dependency is already fulfilled Make won't have to run it again. Although sometimes its hard or clunky to convert some dependencies into 'files' so Make can do its dependency resolving work properly.
Earlier quoted context omitted.
If you're saying that it's possible to do testing badly, I agree, just like it's possible to write production code badly. Sometimes teams new to unit testing do it ritualistically, without really understanding the purpose. That can lead to all sorts of bad outcomes. E.g., lots of tests that look impressive and even generate good coverage numbers, but don't really test what matters. Or tests that are highly duplicativ…
What are some resources for “good testing”, test boundaries, and possibly antipatterns? (Ruby, Rails)
tl;dr:
- Focus on "automated testing", don't get obsessed with philosophising about "the true nature of a 'unit'", or other such dogma.
- Be empirical: base your rules on what works; don't base your work on "the rules".
- The goal of testing is to expose problems in our program: "test failure" is a success, because we've found a problem (even if that problem is with the test!). Anything else is secondary (e.g. isolating the location of failures, documenting our API, etc.). Avoiding this goal defeats the point (e.g. choosing to ignore edge cases).
- Focus on functionality rather than implementation details, e.g. 'changing a user's email address' rather than 'the setEmail method of the User class'. This improves reliability and makes failures more useful/meaningful (i.e. "this feature broke" vs "this calling convention has changed").
- Mocking is a crutch: it works-around problems that can usually be avoided entirely during design; it can still be very useful when a design can't be changed (e.g. adding tests to a legacy system).
- Testing a real thing is objectively better than testing a fake thing; we should only mock if testing the real thing is unacceptable.
- If two components always exist together, pretending that they're independent is a waste of time and complexity.
- Having some poor tests is better than having no tests. Tests can be added, removed and improved over time, just like anything else.
- "Property checking" is a quick way to find edge-cases and scenarios we wouldn't have thought of.
- Fast feedback loops are important. Reducing I/O and favouring pure calculation usually speeds up testing more than reducing the number or size of tests (e.g. "unit" vs "end-to-end"). Incidentially, this is also how we avoid having to mock.
Shell scripting for processing text. You can often get so much done with so little code and effort. Also on a semi-related note, I think as a self taught programmer, it's easy to get stuck on things that seem cool but are just procrastination enablers (I know, I've been guilty of it for 20 years). Like, if you're about to start a new project and you want to flesh out what it's about, you really don't need to spend 5…
- Shell scripting for running commands and managing files
- Unix utilities for processing text
These happen to complement each other nicely. It's not that bash is better at manipulating text than Python, it's that Python makes it painful to invoke commands (like those Unix utilities) and pipe data between them (e.g. https://news.ycombinator.com/item?id=17733865 ).
Being able to hypothesize ideas, measure conversion, engagement, retention, A/B test, slice by cohorts and validate whether an experiment validates your hypothesis. It makes you tackle problems very systematically.
Being able to measure both impact and effort. Always evaluating whether the impact was worth the effort and fine tuning it.
The product version or tree falling in the forest joke: If you build something and no one uses it, does it really exist?