For the past few weeks I’ve been putting a lot of work into an app called “tinpig“. It’s a tool for creating projects out of custom templates. I’ve described it in a previous post and the readme file details how to use it in depth, so I’m not going to go to much into that here.

This past weekend I got tinpig to version 1.4.0 and I think it’s pretty stable and feature complete in terms of what I envisioned for it. At this point, I’m mainly thinking about fleshing out some of the templates that can be used with it. So this post is kind of a sales pitch on why you might want to think about using it.

If you’re an app developer, you probably create a project and then work in that project day in / day out for weeks, months, maybe years. There’s a good chance that the project you’re working in now was created by someone you don’t even know.

But let’s say you’re also a “creative coder” as I know a lot of you reading this probably are. Maybe you create a project or two per week, or maybe you try to crank out something on a daily basis. Each time you want to create something new, you have to set up that project. This might involve making a folder, creating some files and other folders in that folder, editing those files, importing libraries, setting up build scripts etc.

Chances are, after you’ve done that a few times you’ve worked out some shortcuts. Maybe you started by copying an earlier project and then going into it and changing some stuff. Eventually maybe you came up with a master project that includes all the stuff you generally use, set up the way you like to set it up. You copy the master project, then go in and change a few things here and there, then you’re ready to start writing code.

Well, that almost exactly describes what tinpig does for you. A tinpig template is that master project. All those initial tweaks you make to the master before you start coding – the project name, date, whatever – those get put into the template as tokens and you have a chance to give them values when you create the project.

But now you can have multiple different kinds of projects, different languages and platforms, etc. all easily accessible and creatable without hunting around your hard drive. Type tinpig, choose a template, give it token values if needed, and you have a new project.

Another common use case is when you are learning something new. In fact, that’s where I, personally, am getting a lot of use out of my own app currently. I’m learning the Go language and have been working through some tutorials and books and just reading documentation and figuring stuff out. Every time I start a new chapter that has a new project type, and every time I want to try out a new feature, I just type tinpig and select my Go template. It has no custom tokens, so it just creates a new folder with a main go file in it. That file has a package, the start of an import section and a `main` function. All ready to start learning the new thing.

One more example – another way I’ve actually used the app a couple of times. Say you are an app developer as described in the beginning of this post. You’re working in a big, complex project. But you run into something that’s not working the way you think it should. You don’t know if it’s a bug in the project code, or maybe you just don’t understand how that language feature works. So you want to isolate the code in question and do a quick test of the feature all by itself.

I do mostly web development at my job. I have tinpig templates ready for HTML/JS, NodeJS and Webpack/React. I can fire up one of those projects in just a few seconds (a bit longer to install the dependencies on the Webpack one) and test out the feature I’m working on in isolation. When you’re done, delete the project and go back to your main work.

This is also useful for experimenting with some new language feature before adding it to your project. I’ve been doing some major refactoring on this web project and thought that React React render props might simplify things in this code I was working on. But I didn’t have a clear concept of how they worked. I fired up a Webpack/React project in about a minute, figured out how they worked, and went back to my main code to continue the refactor.

Anyway, that’s my pitch. I won’t lose any sleep if nobody uses tinpig other than myself, but it’d be nice to know that other people find it as useful as I do.