localstripe
entr
localstripe | entr | |
---|---|---|
1 | 47 | |
189 | 4,062 | |
- | - | |
6.4 | 6.8 | |
6 months ago | about 2 months ago | |
Python | C | |
GNU General Public License v3.0 only | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
localstripe
-
Pg_tmp – Run tests on an isolated, temporary PostgreSQL database
Anyway, I won't go as far as saying that mocks are useful, sometimes a mock is the easiest and best way -- but I can say that I spend most of my time writing E2E tests, and I trust them a lot and they give me trust in my codebase much more than mocks or unit tests do. I barely write unit tests anymore to check edge cases, because if I really cared I'd just generate them -- and I don't really have to care because I use strong type systems where possible (Typescript for JS, I avoid PHP/Python/Ruby, Rust, Haskell).
Here comes the hot-take -- unit tests (and their rise in popularity/necessity) is actually a direct reflection of the adoption of non-compile-time-type-checked dynamically interpreted languages, and burdensome class-based "type systems". Correct usage of good, expressive and concise (where possible) type systems encourages you to make invalid/nonsensical states impossible, and people got excited about how fast you could churn out code (compared to Java most things feel pretty productive) and they started having numbers where they thought they had strings, and negative numbers where they thought they had natural numbers. Good type systems make it easy to make these cases impossible. As for the business stuff (never store decimals for currency, make sure your amounts are natural numbers, etc), you have to learn that with time/intuition built over time -- you don't know to write that unit test unless it's bit you before (though sitting down to write unit tests might tease it out of you).
I write unit tests as regression tests basically now, but I find I rarely have to do that, since most of the time when a weird case has gone through it's an indicator that I was too lose with the types.
[0]: https://github.com/adrienverge/localstripe
entr
- Entr – tool for watching files and running commands
-
Meet entr, the standalone file watcher
entr ("Event Notify Test Runner"; GitHub), is a command-line tool written by Eric Radman that allows running arbitrary commands whenever files change.
-
How to build a website without frameworks and tons of libraries
I use something very similar on https://lunar.fyi and https://lowtechguys.com but I wouldn’t call this “simple” anymore.
They use Jinja templating, I prefer Slim (https://github.com/slim-template/slim#syntax-example) which has a more Pythonic syntax (there is plim [0] in Python for that)
I use Tailwind as well for terse styling and fast experimentation (allows me to write a darkMode-aware and responsive 100 line CSS in a single line with about 10 classes)
For interaction I can write CoffeeScript directly in the page [1] and have it compiled by plim.
I run a Caddy static server [2] and use Syncthing [3] to have every file save deployed instantly to my Hetzner server.
I use entr [4] and livereloadx [5] to rebuild the pages and do hot reload on file save. All the commands are managed in a simple Makefile [6]
———
You can already see how the footnotes take up a large chunk of this comment, this is not my idea of simple. Sure, the end result is readable static HTML and I never have to fight obscure React errors, but it’s a high effort setup for starters.
Simple for me would be: write markdown files for pages, a simple CSS for general styling (should be optional), click to deploy on my domain. Images should automatically be resized to multiple sizes and optimized, videos re-encoded for smaller filesize etc.
I have mostly implemented that for myself (https://notes.alinpanaitiu.com/How%20I%20write%20this%20blog...) but it feels fragile. I’d rather pay for a professional solution.
[0] https://plim.readthedocs.io/en/latest/
[1] https://github.com/FuzzyIdeas/lowtechguys/blob/main/src/rcmd...
[2] https://caddyserver.com/docs/command-line#caddy-file-server
[3] https://syncthing.net
[4] https://github.com/eradman/entr
[5] https://nitoyon.github.io/livereloadx/
[6] https://github.com/FuzzyIdeas/lowtechguys/blob/main/Makefile
- How to start a Go project in 2023
-
[Guide] A Tour Through the Python Framework Galaxy: Discovering the Stars
Try entr for fast reloading. Another one is hupper.
- Use entr when working on you rice for auto config refreshing
- The Unix process API is unreliable and unsafe
- How do you develop cloud-native applications locally on Kubernetes?
-
What are the not-so-obvious tools that you don't want to miss?
entr
- Test driven development is adhd dream
What are some alternatives?
testcontainers-go - Testcontainers for Go is a Go package that makes it simple to create and clean up container-based dependencies for automated integration/smoke tests. The clean, easy-to-use API enables developers to programmatically define containers that should be run as part of a test and clean up those resources when the test is done.
watchexec - Executes commands in response to file modifications
otj-pg-embedded - Java embedded PostgreSQL component for testing
nextjs-tailwind-ionic-capacitor-starter - A starting point for building an iOS, Android, and Progressive Web App with Tailwind CSS, React w/ Next.js, Ionic Framework, and Capacitor
integresql - IntegreSQL manages isolated PostgreSQL databases for your integration tests.
modd - A flexible developer tool that runs processes and responds to filesystem changes
flyway-spawn-demo - CI demo using Flyway and Spawn
swc-node - Faster ts-node without typecheck
rush - Production-driven prototyping. This starter is setup in a production-friendly way and will setup tests + dev environment exactly like a live project will work. Works the same both on your laptop or Github CI, so you can go from hacking on your laptop to a full gitops environment.
air - ☁️ Live reload for Go apps
vim-test - Run your tests at the speed of thought