This is part of my series on “best practices in practice” where I talk about best practices and related tools I use as an open source software developer and project maintainer. These can be specific tools, checklists, workflows, whatever. Some of these have been great, some of them have been not so great, but I’ve learned a lot. I wanted to talk a bit about the usability and assumptions made in various tools and procedures, especially relative to the wider conversations we need to have about open source maintainer burnout, mentoring new contributors, and improving the security and quality of software.
If you’re running Linux, usually there’s a super easy way to check for updates and apply them. For example, on Fedora Linux `sudo dnf update` will do the magic for you. But if you’re producing software with dependencies outside of a nice distro-managed system, figuring out what the latest version is or whether the version you’re using is still supported can sometimes be a real chore, especially if you’re maintaining software that is written in multiple programming languages. And as the software industry is trying to be more careful about shipping known vulnerable or unsupported packages, there’s a lot of people trying to find or make tools to help manage and monitor dependencies.
I see a lot of people trying to answer “what’s the latest” and “which versions are still getting support” questions themselves with web scrapers or things that read announcement mailing list posts, and since this came up last week on the Mailman irc channel, I figured I’d write a blog post about it. I realize lots of people get a kick out of writing scrapers as a bit of a programming exercise and it’s a great task for beginners. But I do want to make sure you know you don’t *have* to roll your own or buy a vendor’s solution to answer these questions!
At the time that I’m writing this, the website claims it’s monitoring 313030 packages, so there’s a good chance that someone has already set up monitoring for most things you need so you don’t need to spend time writing your own scraper. It monitors different things depending on the project.
It’s backed by software called Anitya, in case you want to set up something just for your own monitoring. But for the project where I use it, it turned out to be just as easy to use the API.
What are the supported versions?
My favourite tool for looking up “end of life” dates is https://endoflife.date/ (so easy to remember!). It also has an API (note that you do need to enable javascript or the page will appear blank). It only tracks 343 products but does take requests for new things to track.
I personally use this regularly for the python end of life dates, mostly for monitoring when to disable support for older versions of Python.
I also really like their Recommendations for publishing End-of-life dates and support timelines as a starting checklist for projects who will be providing longer term support. I will admit that my own open source project doesn’t publish this stuff and maybe I could do better there myself!
Conclusion
If you’re trying to do better at monitoring software, especially for security reasons, I hope those are helpful links to have!
This is part of my series on “best practices in practice” where I talk about best practices and related tools I use as an open source software developer and project maintainer. These can be specific tools, checklists, workflows, whatever. Some of these have been great, some of them have been not so great, but I’ve learned a lot. I wanted to talk a bit about the usability and assumptions made in various tools and procedures, especially relative to the wider conversations we need to have about open source maintainer burnout, mentoring new contributors, and improving the security and quality of software.
I was just out at Google Summer of Code Mentor Summit, which is a gathering of open source mentors associated with Google’s program. Everyone there regularly works with new contributors who have varying levels of ability and experience, and we want to maintain codebases that have good quality, so one of the sessions I attended was about tools and practices for code quality. Pre-commit is one of the tools that came up in that session that I use regularly, so I’d like to talk about it today. This is a tool I wouldn’t have thought to look for on my own, but someone else recommended it to me and did the initial config for my project, so I’m happy to pay that forwards by recommending it to others.
Pre-commit helps you run checks before your code can be checked to git. Your project provides a config file of whatever tools it recommends you use. Once you’ve got pre-commit installed, you can tell it to use that file, and then those checks will run when you type `git commit` with it halting if you don’t pass a check so you can fix it before you “save” the code. By default it only runs on files you changed and can be tuned by the project maintainers to skip files that aren’t compliant yet, so you don’t generally get stuck fixing other people’s technical debt unless that’s something that the maintainers chose to do.
Under the hood there’s some magic happening to make sure it can install, set up, and configure the tools. It does tell you what’s happening on the command line, but it’s worlds better than having to install them all yourself, and it puts it into a separate environment so you don’t have to worry about needing slightly different versions for different projects. Honestly, the only time I’ve had trouble with this tool was when I was using it in a weird environment behind a proxy and some combination of things meant that pre-commit was unable to set up tools for me. I think that’s more of a failure of the environment than of the tool, and it’s been shockingly easy to set up and use on every other development machine where I’ve used it. One command to install pre-commit, then one command to set it up for each project where I use it.
I’m sure there are some programmers who are incredibly disciplined and manage to run all required checks themselves manually, but I am not the sort of person who memorizes huge arrays of commands and flags and remembers to run them Every Single Time. I am the sort of person who writes scripts to automate stuff because I will forget. Before pre-commit I would have had a shell script to do the thing, but now I don’t have to write those for projects that already have a config file ready for me. Thus, pre-commit speaks to the heart of how I work as a developer. I got into computers because I could make them do the boring stuff.
Image Description: A photo of the package locker in a US shared mailbox. A label around the keyhole reads “open” with arrows and then says “key will remain in lock after opening door” — it’s a great example of design that doesn’t rely on users remembering to do the right thing (in this case, giving back the key for future use)
Pre-commit also speaks to the heart of my computer security philosophy: any security that relies on humans getting things 100% right 100% of the time is doomed to fail eventually. And although a lot of this blog is about knitting and fountain pens and my hobby work, I want to remind you that I’m not just some random person on the internet when it comes to talking about computer security: I have a PhD in web security policy and I work professionally as an open source security researcher. Helping people write and maintain better code is a large portion of my day job. A lot of the most effective work in security involves making it easy and “default” for people to make the most secure choices. (See the picture above for a more physical example of the design philosophy that ensures users do the right thing.)
Using pre-commit takes a bunch of failure points out of our code quality and security process and makes it easier for developers to do the right thing. For my current work open source project, we recommend people install it and use it on their local systems, then we run it again in our continuous integration system and require the checks to pass there before the code can be merged into the main branch.
As a code contributor:
I like that pre-commit streamlines the whole process of setting up tools. I just type pre-commit install in the directory of code I intend to modify and it does the work.
I can read the .pre-commit-config.yaml file to find out a list of recommended tools and configurations for a project all in one place. Good if you’re suspicious of installing and using random things without looking them up, but also great for learning about projects or about new tools that might help you with code quality in other projects.
It only runs on files I changed, so the fixes it recommends are usually relevant to me and not someone else’s technical debt haunting me.
It never forgets to run a check. (unless I explicitly tell it to)
It helps me fix any issues it finds before they go into git, so I don’t feel obliged to fuss around with my git history to hide my mistakes. Git history is extremely obnoxious to fuss with and I prefer to do it as infrequently as humanly possible.
It also subtly makes me feel more professional to know that all the basic checks are handled before I even make a pull request. I’ve been involved in open source so long that I mostly don’t care about my coding mistakes being public knowledge, but I know from mentoring others that a lot of people find the idea of making a mistake in public very hard, and they want to be better than the average contributor from the get-go. This is definitely a way to make your contributions look better than average!
It gives me nearly immediate, local feedback if my code is going to need fixes before it can be merged. I like that I get feedback usually before my brain has moved on to the next problem, so it fits into my personal mental flow before I even go to look at another window.
It can get you feedback considerably faster than waiting for checks to run in a continuous integration system. If you’re lucky, a system like github actions can get you feedback within a few minutes on quick linter-style checks, but if the system is backed up it or if you’re a new contributor to a project and someone has to approve things before they run (to make sure you’re not just running a cryptominer or other malicious code in their test system!), it can take hours or days to get feedback. Being able to fix things before the tests run can save a lot of time!
As a project maintainer:
Letting me configure the linters and pre-checks I want in one place instead of multiple config files is pretty fantastic and keeps the root directory of my project a lot less full of crap.
It virtually eliminates problems where someone uses a tool subtly differently than I do. If you’re not an open source project maintainer who works with random people on the internet you may not realize how much of a hassle it is helping people configure multiple development tools, but let me tell you, it’s a whole lot easier to just tell them to use pre-commit.
Endlessly helping people get started and answering the same questions over and over can be surprisingly draining! It’s one of the things we really watch for in Google Summer of Code when trying to make sure our mentors don’t burn out. Anything I can do that makes life easier for contributors and mentors and avoid repetitive conversations has an outsized value in my toolkit.
Being able to run exactly the same stuff in our continuous integration/test system means even if my contributors know nothing about it, I still get the benefits of those checks happening before I do my code review.
It saves me a lot of time back-and-forth with contributors asking for fixes so it lets me get their code merged faster. A nicer experience for all of us!
I can usually configure which files need to be skipped, so it can help us upgrade our code quality slowly. Or I can use it as a nudge to encourage people changing a file to also fix minor issues if I so desire.
What gets run with pre-commit will obviously depend on the project, but I think it’s probably helpful to give you an idea of what I run. I talked about using black, the python code formatter in a previous best practices post. For my work open source project, it’s only one of several code quality linters we use. We also use pyupgrade to help us be forward-compatibile with python syntaxes, bandit to help us find python security issues, gitlint to help us provide consistency in commit messages (we use the conventional commits format rules), and mypy to help us slowly add static typing to our code base.
Usually before installing a new pre-commit hook, I make sure all files will pass the checks (and disable scanning of files that won’t). Some tools are pretty good at a slow upgrade if you so desire. One such tool for us as been interrogate, which prompts people to add docstrings — I have it set up with a threshold so the files will pass. The output when pre-commit runs generates a report with red segments in it if there’s missing docstrings for some functions, even if the check passes so you don’t have to fix them. Sometimes that means someone working in that file will go ahead and fix those interrogate warnings while they’re working on their bugs, and that’s incredibly nice.
I’ll probably talk about some of these tools more later on in this best practices in practice series, but that should give you some hints of things you might run in pre-commit if you don’t already have your own list of code quality tools!
Summary
Pre-commit is a useful tool to help maintain code quality (and potentially security!) and it can be used to slowly improve over time.
I only found out about pre-commit because someone else told me and I’m happy to spread the word. I don’t think tools like pre-commit attract evangelists the way some other code-adjacent tools do, and it’s certainly not the sort of thing I learned about when I learned to code, when I got involved in opens source initially, or even when I was in university (which was long after I learned to code and got into open source). I’m sure it’s not the only tool in this category, but it’s the one I use and I like it enough that I haven’t felt a need to shop around for alternatives. I don’t know if it’s better for python than for other languages, but I love it enough that I could see myself contributing to make it work in other environments as needed, or finding similar tools now that I know this is an option.
As a project maintainer, I feel like it helps improve the experience both for new contributors who can use it to help guide them to submit code I’ll be able to merge, and for experienced contributors and mentors who then don’t have to spend as much time helping people get started and dealing with minor code nitpicks during code reviews. As an open source security researcher, I feel like it’s a pretty powerful tool to help improve code quality and security with easy feedback to developers before we even get to the manual code review stage. As a developer, I like that it helps me follow any project’s best practices and gives me feedback so I can fix things before another human even sees my code.
I hope other people will have similar good experiences with pre-commit!
It was likely inevitable that I’d start thinking seriously about having some travel-specific fountain pens. I’m no longer the world traveller I was in my 20s when writing papers and going to conferences to present them was a key part of my job, but I have a certain amount of travel-specific stuff in my life. (I’ve been cataloguing and reviewing some of my favourite travel gear here on the blog.)
Image description: My travel stationery setup: Field Notes notebook, Pikachu mechanical pencil & 2 pikachu gel pens from Zebra, Platinum Preppy Wa with koi, Pilot Kakuno in purple, a teensy pencil crayon set, an eraser in a orange case with ears, Burt’s Bees lip balm, a Fisher space pen, Lanisoh lanolin, all packaged with two Tom Bihn ghost whale pouches and a key strap to clip them into my bag.
For pens, I didn’t want to have something that only got used a few times per year, so I decided my travel pen(s) would need to do double-duty in my backpack for out and about jotting down of notes and doodling in restaurants/airports/cars to keep my kid amused. The picture above shows my travel setup except that I forgot to include the Traveler’s Notebook calendar that I’m currently using for tracking headaches, etc. Sometimes I carry all of that in my backpack, sometimes I slim it down and only carry the pencil and eraser, depending on how much I expect to be on my feet vs sitting. Most of this I already had for my summer trip, the fountain pens are the only part that’s actually new.
Before making any decisions on fountain pens, I read up on a lot of really solid recommendations on types of fountain pens that tend to be better for travel:
Vacuum filling and Japanese-style eyedropper pens are less likely to leak in flights despite their larger capacity.
Smaller pocket pens could be lighter for toting around, and might be less of a mess in case of a pensplosion because they had less ink.
Finer nibs use less ink, if you need what you’ve got to last.
And then some tips for just travelling with what you’ve got:
Travelling with a full pen or a fully empty one both made air pressure changes less risky.
Having pens nib-up during flight would reduce risk of ink blooping out since air could escape more easily.
Having the option to use cartridges instead of bottle-filling could be convenient and less messy.
I’m really not sure about the cartridge thing — sure, it’s convenient on the way out, but for short trips I’m highly unlikely to finish a cartridge and there’s no way to stopper most of them, so I felt like I’d still be stuck flying with an open reservoir on the way home. But I guess it works for some people who either write more or are more willing to throw away a half-filled cartridge than I am?
After much internal debate and online shopping, I decided I wasn’t ready to buy a more expensive vacuum filling pen (yet) or even a nicer “sport” or “pocket” pen. I felt like buying an expensive pen would undercut my plan for handing this to my kid for distraction and doodles. But I also hadn’t loved my existing stub-nibbed pens with my travel notebook so I didn’t want to just travel with what I had again. So I went the $10-15 starter pen route instead for my trip to Google Summer of Code mentor summit in October.
Pilot Kakuno
First on my travel list was a Pilot Kakuno. I already had the converter for this since I’d intended to try it in my Pilot Metropolitan eventually. I went with the medium nib for personal ergonomics reasons and also because I was still fussing with the Metropolitan CM nib so this gave me an excuse to use the medium and have the option to swap them later if I never got the hang of the CM. The CM and are are getting along fine now, but I did this purchase earlier in September before I was reasonably confident with it. The medium is significantly less fussy than the CM, so much so that my kid and I didn’t have much difficulty drawing stuff with it.
Image Description: A doodle of a Corgi ready to dig in to a plate of bacon and eggs with a fork and a knife. This was a quick copy of some cute artwork we bought in San Jose Japantown.
I really like this pen. Since it’s plastic, it feels absurdly light compared to the Metropolitan, and that was absolutely a feature rather than a drawback for a pen I intend to carry a lot. The medium nib is more user-friendly than the CM (not that CM would have been an option on this pen, just that it’s what I was used to). I chose better on my ink, which also helped. I’ve got Jaques Herbin Violette Pensée in there because it matched nicely and because I knew I’d want a purple ink in my October planner palette anyhow.
Image Description: Pilot Kakuno pen disassembled to show the CON-40 converter I’m using and the fact that after the trip I’ve got more than 1/3 of a tank of ink left.
The CON-40 converter that I have is pretty small (it’s one of the big complaints about it), but for a weekend trip with two pens getting rotated this was more than enough. And having a smaller reservoir does mean less risk in case of total pen failure at altitude.
Platinum Preppy Wa
Second was a Platinum Preppy Wa. I could have chosen a cheaper, less fancy edition of the Preppy, but then I wouldn’t be me. (It wasn’t that much more expensive anyhow.) It also amuses me greatly that this is the “Wa” edition as my kid decided when he was learning to speak that “wa time” was his term for nursing, so I spent quite a lot of time hearing that syllable even though it’s obviously a different word. Add on the “Koi no Taki-Nobori” fishy pattern being associated with the koi banners flown for children’s day and, well, clearly this particular pen was the one for me.
Image Description: Platinum Preppy Wa Koi no Taki-Nobori version with koi fish in silver on a dark blue barrel. The cap is off so you can see the spring mechanism a bit more clearly.
Like the Kakuno, the Preppy Wa feels absurdly light compared to the others in my collection and that’s a definite advantage for my purposes. I got a fine rather than medium nib so this would be different (and also because it’s what was in stock) and while I definitely don’t love the fine nib as much for writing, I was really happy to have it for drawing:
Image Description: My drawing of a Western Conifer Seed Bug, done mostly in fountain pen with some pencil for shading.Image Description: A Western Conifer Seed Bug sitting on a green poinsettia leaf. It’s a large elongated shield-shaped bug with long antennae and a pattern on the back that looks like a sketch of a mountain range.
The fine nib is also undeniably nice in my smaller travel notebook and on my calendar, though I mostly use pencil in the calendar anyhow.
I also was amused to see that the patented cap design mentioned in their ad copy includes a spring that’s pleasantly visible through the clear plastic cap, so I can watch it clip into place. Very satisfying. The artwork on the barrel is also raised and textured. I find it pleasant to touch but I do worry that it may get rubbed off over time. I guess I could make/find a sleeve for it?
I don’t own a converter for the Preppy Wa and I’m currently planning to try refilling the cartridge with a syringe. I don’t know that I’d feel super comfortable flying with a cartridge that had been refilled many times (I assume after a while they probably wouldn’t seal as well against the nib) so I’ll likely either buy a converter or a fresh cartridge for the next plane flight. We’ll see how I feel about it once I’ve actually tried a refill.
Flying with the pens
I tried to learn from my experience flying with the TWSBI Eco-T where I did have a leak, so I was more careful about making sure that I tightened the piston before my pens were packed, which probably helped. I also moved things around in my bag so my ebook reader (which I always pull out before takeoff) was sitting next to the pens so I wouldn’t forget to move them to be upright.
I flew to California with the Kakuno very full of purple ink using the converter and the Preppy Wa without a cartridge installed. I managed to put the Kakuno in my pen case upside down, so I flew with it nib *down* (pretty much the least recommended position) instead of the nib-up that I’d planned, but I suffered no leaks anyhow. Though the idea of making sure the air is at the top for pressure changes makes some sense, this makes me wonder how much it really matters in a modern pen. There are ball bearings in that converter to limit flow when it’s nib-down, for example, so my particular setup may not have been hugely different than a ballpoint when nib down. If you’ve ever heard of someone doing a proper scientific experiment on fountain pen orientation vs leakage in flight, I’d love to know about it! (If I had a lot of pens and a pressure pot I’ll bet I could design something…)
I flew back with the Kakuno less full and the Preppy Wa with the original black cartridge installed. This time I was a bit more careful about my pen orientation so they both flew tip up, and again no leaks. Yay!
Image Description: A Platinum Preppy Wa (Koi pattern) and Pilot Kakuno (purple) sitting on my notebook, which is open to a page with info about the Clapotis shawl I’ve started knitting, written in purple ink. The notebook is being held open with help from a brass clip/stencil ruler from Midori
In conclusion…
Both pens worked out great for writing, drawing, and even for amusing my kid. They both flew with no leaks and have tootled around town in my backpack being useful with no incidents before and after the trip. They weigh hardly anything because they’re plastic.
One mild surprise was that I used a lot more ink in the Kakuno than I expected, largely because I wrote more than expected. That does give me an excuse to look at pens with larger reservoirs if I’m planning to be gone for more than week or if I expect to take more notes. But with a larger reservoir would come more weight, so a vacuum filler might wind up in a different niche in my collection — airline travel and journalling at home rather than airline travel and backpack pen.
Though I still do want to try some fancier pens, I don’t feel like I need to get a vacuum filler or japanese eyedropper before I jump on a plane again. With the magic of zipped plastic bags I don’t really feel worried about taking these two on a plane. I don’t really expect leaks, but no harm in being cautious.
In short, these worked out well for both air travel and around town use! Almost too well because now I have less excuse to buy more pens, but I can live with that.
Honestly, I mostly bought this pen because I wanted a glowing pen for October. I usually keep this one by my bed so I can see it glow, rather than in the case with the rest of the pens I intend to use for the month. Perhaps there is a deep psychological insight that can be gained from the fact that I choose to see a glowing fountain pen just before I fall asleep, but honestly glowing things are just cool and I like getting them for myself instead of just my kid. (I have some cool glowing stickers from an artist I like also near my bedside, and I’ve made two quilts that glow.)
Image Description: TWSBI Eco Fountain pen, glowing just a little in half-shaded light.
My daily journal setup is very similar to the travel stationery setup I showed in my travel bags post, so if I left it in the pen case it’d hardly ever get any light! It does mean I sometimes have to walk upstairs to get it if I decide that is the pen I need for the moment, but I can handle that in exchange for GLOW PEN.
From a functional writing perspective, there’s not much new to say about this versus my other TWSBI pens, except that I went with a medium nib this time so this could serve as a replacement for my mystery wood pen. Some kind folk made good suggestions on how I could fix the mystery wood pen when I’m ready, but I’m tired of fighting with it and decided I just wanted a pen that was easier to use. (I still intend to fix it eventually, but I’m waiting until I’m feeling more excited about the experience, so for now the pen is cleaned out and put away.)
The medium nib here is noticeably thicker than on my original pen (see image below), which is closer to the Pilot medium than the TWSBI medium. It might have been a fine nib if it had a label, but it didn’t, so I’m guessing. The bigger nib works for me: as I mentioned previously, it’s ergonomically easier for me if I write bigger and the wider nib helps encourage me to do so.
Image Description: My green glow-in-the-dark TWSBI Eco sits on a small notebook open to a page where I’ve written samples from a bunch of different pens/inks. The relevant part is that the TWSBI Eco sample at the bottom is thicker than the mystery wood pen writing at the top of the page, but you can also see samples from a couple of pilot medium nibs (both thinner than the glow pen), a pilot CM nib (similar width to the glow pen but more line variation), and the 1.1 stub nibs from my other TWSBI pens (both thicker than the glow pen).
I’m really happy with this pen: I love the glow. I can write long journal entries with it just like I do with the stub nibs without any weird hand twinges, and I don’t have to be careful with it the way I have to with my Pilot <CM> to make sure I don’t lose the ink flow. (Though the Pilot Metropolitan <CM> is getting more instinctual as I practice now that I’ve got more compatible ink in it, so the difference in writing with it may be moot eventually.) I’m glad to focus more on what I’m writing than how I’m writing it. I don’t think I prefer the medium nib over my existing 1.1 stub ones, but I like having the variety available when I go to pull a pen out, especially for doodling, so I’m glad to have this one in my collection.
The Glow Pen is a lovely replacement for my original pen and what it lacks in history and character, it makes up in being incredibly easy to use and did I mention it glows? I don’t think I can mention that enough.
Fountain pens make me think a lot about Don Norman’s Design of Everyday Things, the konmari “does it spark joy?” question and especially a follow-up study I read about the “pretty things are more usable” effect that I’m too lazy to find a link for right now but the gist of it was “sure, Japanese people find pretty things more usable, but surely Israeli users wouldn’t see this effect” but then the results of the study were that even their study participants found the pretty ATM interface more usable and I loved the way the researchers reported this faithfully with such gentle grumpiness about their results. Which is all to say that science says that my love of the glow probably makes this pen work better for me, and I’m happy to lean in to that effect!
As expected, I finished my bullet journal, just barely managing to fit an entry for Sept 30th, 2024 on the last page. It was started on January 1, 2023, so it lasted just under 2 years. The corgi design is from Kela Designs, and I bought it for myself on the condition that I actually *use* it and not have it wind up in the unused notebook stash.
Image Description: A pair of A5 journals and a clear writing board. On top is my new journal, a Rhodia softcover, and underneath is my hardcover corgi journal from Kela Designs. Both are sitting on a quilt a friend made for my wedding.
I’d never actually done a bullet journal when I started this, though I’d written short journal entries on and off since I was a kid. I hadn’t really made much effort in tracking stuff but it seems like such a part of bullet journal culture that I figured I’d try it out, and some of it worked for me and other parts didn’t. It was great treating each month as a new event where I could set up different pages and iterate rather than sticking with a layout preset for the whole year. Those big blank pages also gave me more space for doodling, stickers, washi tape and eventually fountain pens.
Image Description: A doodle of a husky dog with hearts, drawn in fountain pen with some pencil for colour. It is surrounded by some red text from a journal entry.
Mostly my journal is for me and me alone, but in celebration of this one getting filled up I thought I’d share some doggust doodles and other marginalia as a bit of a send off. Most of these were drawn from random cute dog pictures I found via image searches.
Image Description: Doggust drawings from 2023. Doggust is a “draw a dog every day in August” art prompt series. Here I’ve pasted in a dog drawn on a scratch-off note card, and a painting of rainbow spotted dalmations.Image Description: A doodle page in my bullet journal with fountain pen drawings. It features a corgi, miscellaneous house items, leaves, stars and abstract shapes, a copying of an alphabet/number font, and another small dog.Image Description: A small cartoon potted plant with a happy face on the pot. It is drawn in green and purple fountain pen, and is surrounded by other text in my bullet journal.
And a bonus: my kid’s first fountain pen drawing! He wanted to try my new glow in the dark pen, although alas I don’t have glow in the dark ink.
Image Description: A small smiling sun drawn in green fountain pen by my then 6 year old kid. His first time using a fountain pen! If you look closely you can see where he made a dent in the paper instead of a line near the top of the sun.
While half of the “bullet journal method” wasn’t for me, I’ve found that I do love the dot grid format, and I’ve got a new journal set up to go for October now! My post about auditioning new bullet journals can tell you about how I chose my new notebook, and I also talked about the calendar part of my bullet journal journey in I hate the “future log” of my bullet journal. So this time I’ve got a smaller calendar and a listing of my fountain pens/inks for October!
Image Description: A beginning of the month page in my new journal, featuring halloween themed stickers, a small calendar, and a list of pens and inks. There’s a green TWSBI Eco fountain pen with a glow in the dark green cap propped against the next cream coloured bullet journal page.
I’m excited about my new setup and thankful for my first journal for the past two years together!
