I often use my side projects for experimenting with concepts and one area of interest is onboarding. Too often there are major hurdles and complexities in getting started contributing or developing web projects.
With Cuttlefish the goal is to be as approachable as possible and be productive after running a single command.
So I’m happy to say today I landed a few PRs in the main branch that add zero configuration project tooling in the guest when using vagrant🎉
Dependency management, linting, pre commit hooks etc are all ready to go after a vagrant up. I’m pretty chuffed.
It’s optional so you can still bring your own tooling and use the built in PHP webserver.
Hopefully that should make it easy to get up and running and contribute.
Cuttlefish is my hackable web/blog framework. I’m doing most of the hacking and eventually you might blog.
Rubber ducking a bit. Working on the coupling of the controller name being linked to the content structure. For example /posts/x loads the post controller with the post model and content from content/post/x.md.
It felt intuitive but I’m not happy deriving a path literally from a class name. In Particular the post archive is an archive controller with a post model. Also feeds/post vs feeds/auctions or something.
Originally I went with contentpath being based on a controller name property. But because the model already specifies the fields available in the content that didn’t seem right
So doing some work around each model having a content path property but not 100% if that’s the right relation.
Feels like It’s doing two things. Routing and content types.
For instance if I want a /blog I’d probably create a blog controller with a post model with records loaded from content/blog.
Looks like the controller is registered to a path via the router and it dictates the content path after all.
Made a strategic change in Cuttlefish to make it as simple as possible, instead of as a test bed for tooling tech. So I removed Docker and PHPDox support.