I have had this idea\/theory for a while, that most software tools would benefit from a simple built in todo list built into the product directly. The main idea is for users to create jobs themselves or for the system itself to create jobs for the user to complete. The general thesis for this idea comes from a direct reference to the term "Jobs to be done". Any piece of software that gets used, exists to complete a job and do it better than the solution before it.<\/p>\n
Well over the last couple of months I have turned this idea into a reality inside Hamilton Rock, or at least the first version of it and so far it seems very promising. The general API design is a few custom signals, a model and some signal reciever functions for the custom signals. The rest of the project interacts solely through the custom signals Currently all jobs are created by the system and we have yet to directly expose them to our users, however there have been two interesting insights from where I have used them to date (onboarding & staff pages). First in onboarding it has created a flexible way to add\/remove steps for me as a developer and given that completing a job is part of the internal state rather than just a custom form or series of forms, the logic to visualise where users are stalling in our flow becomes easy to visualise. It's how many pending jobs at each step and how long have they been pending?<\/p>\n Second when an handled exception case occurs in the application which requires the attention of a staff user, instead of a log statement needing to be processed by some system and being perhaps overfilled with extra context, or there being extra noise in a developer tool such as Sentry, we simply create a job of the type we need. Then create a staff page to list and handle jobs of this type.<\/p>\n Finally this jobs architecture has enabled a central point to control how we send notifications (emails etc) from the system. Every notification is linked to a Job, which then means it forces notifications to not deal with too many actions at a time and again allows a natural tracking of which notifications have been actioned or not.<\/p>\n In future, I'm likely to expose these jobs to our users more directly, giving them a native solution to spend just the right amount of time in our product and no more, so what we build is simple & useful.<\/p>\n What do you think? Would you like this as a package for you to play with? Let me know and I may just break it out and release it!<\/p>","url":"https:\/\/softwarecrafts.co.uk\/100-words\/day-303","title":"Representing 'Jobs to be Done' in a project","summary":"An experiment in building out a new architecture for projects","date_modified":"2026-04-14T00:00:00.000Z","author":{"name":"Software Crafts"},"tags":["#100_words","#django","#jobsToBeDone","#systems_architecture"]},{"id":"https:\/\/softwarecrafts.co.uk\/100-words\/day-302","content_html":" I have recently been reading Swizec Teller's new book Scaling Fast<\/a> and in it he mentions architectural complexity, which reminded me of my desire for a tool that combines database dependencies between Django apps and import dependencies between Django apps. To date, I have used other tools such as graph models from Django extensions, import-linter<\/a> is the most recent one, and Why the Django app level, you ask? Primarily, I do find models good, but they can get a little too complicated and a little you get a few too many lines and doing imports at the module level within an app or like separating it all out, again, you lose it becomes there becomes too much noise to signal to really understand the logical relationship between different components in the system. I like to think that Django apps naturally represent logical representations of different parts of a project or a system. A project obviously is too large unless you're dealing with multiple projects, but within a single Django project, it's a good representation to have an app deal with one thing. You can I know you can structure Django projects & apps in many ways. So it'd be interesting to see this tool used on other's project structures that aren't one app for a single logical component.<\/p>\n So without further ado, here is Django Dependency Map<\/a>, which combines output from Django extensions The live map page has the following features:<\/p>\n My hope is twofold. One, it might reveal things about your projects that you didn't know about in terms of how fit how interlinked things are. And secondly, I hope it may change the way you build your Django apps. I'm hoping to have it open as another tab and just to watch as I'm building things to make sure out as I'm and maybe as an agent's building things see use it as a sense check of if it's doing things right or as I expect it to in terms of overall architecture rather than at the code level.<\/p>\n The pypi package is coming very soon, but you can visit the repo here: https:\/\/github.com\/softwarecrafts\/django-dependency-map<\/a><\/p>","url":"https:\/\/softwarecrafts.co.uk\/100-words\/day-302","title":"New Package: Django Dependency Map","summary":"Understanding the interaction between Django apps as you build","date_modified":"2026-04-08T00:00:00.000Z","author":{"name":"Software Crafts"},"tags":["#100_words","#django","#packages","#dependencies","#architecture"]},{"id":"https:\/\/softwarecrafts.co.uk\/100-words\/day-301","content_html":" The past few weeks have been both amazing and frustrating. If you listen\/read to my weekly in\u2011progress reports have already I mentioned some of this. In the last week of February, I appeared on the Django Chat podcast<\/a>, which was released to positive feedback. I considered that a personal win for my career, it was fun to chat with Will and Carlton and hope to do more like this in future. However, two days after the episode aired, I recieved news that a client had passed away, causing that income source to vanish overnight. My condolences go to their family and I was also in shock, personally and then from the perspecive of my business.<\/p>\n This was especially frustrating because I thought my cashflow for 2026 was solid, and I expected to be salaried before the end of year once Hamilton Rock secures funding, which we plan on doing this year. Generally from a business perspective, income can vanish overnight, and I accept this. This risk is inherent in running a business, unlike an employed job in the UK, which offers protections in this regard. The risk and potential downside has a counter of greater flexibility. I can work where and when I like, take long lunch breaks, and take holidays without needing permission\u2014aside from checking in with the wife!<\/p>\n However if you lose a job, all<\/strong> your income can disappear at once, it's the classic "all your eggs in one basket" scenario. With a business, there is the opportunity to diversify, so thankfully this lost income wasn't everything for me, but it doesn significantly shortern my cashflow runway. My next steps are to explore several options: revisiting Comfort Monitor Live and improving its marketing with the help of Claude, and experimenting with agents to generate additional revenue. Finally there is of course new freelance contracts or projects.<\/p>\njob_requested<\/code> and job_completed<\/code>. Each does as you would expect, job_requested<\/code> requests a job be created, job_completed<\/code> complete the related job to the model instance given. The core of the job<\/code> model has a status, type and a generic foreign key which forms the target related to the job. Jobs can auto-completed when a condition has been met, it's just a matter of firing off the completed signal. Example stub of the API is below.<\/p>\njob_requested =<\/span> Signal(<\/span>)<\/span>\njob_completed =<\/span> Signal(<\/span>)<\/span>\n\nclass<\/span> Job<\/span>(<\/span>models.<\/span>Model)<\/span>:<\/span>\n content_type =<\/span> models.<\/span>ForeignKey(<\/span>\n ContentType,<\/span>\n on_delete=<\/span>models.<\/span>CASCADE,<\/span>\n help_text=<\/span>_(<\/span>"The type of object this job is related to"<\/span>)<\/span>,<\/span>\n )<\/span>\n object_id =<\/span> models.<\/span>PositiveIntegerField(<\/span>\n help_text=<\/span>_(<\/span>"The ID of the related object"<\/span>)<\/span>,<\/span>\n )<\/span>\n target =<\/span> GenericForeignKey(<\/span>"content_type"<\/span>,<\/span> "object_id"<\/span>)<\/span>\n \n assigned_to =<\/span> models.<\/span>ForeignKey(<\/span>\n settings.<\/span>AUTH_USER_MODEL,<\/span>\n on_delete=<\/span>models.<\/span>SET_NULL,<\/span>\n null=<\/span>True<\/span>,<\/span>\n blank=<\/span>True<\/span>,<\/span>\n related_name=<\/span>"assigned_jobs"<\/span>,<\/span>\n help_text=<\/span>_(<\/span>"User this job is assigned to (default notification recipient)"<\/span>)<\/span>,<\/span>\n )<\/span>\n \n job_type =<\/span> models.<\/span>CharField(<\/span>\n max_length=<\/span>50<\/span>,<\/span>\n choices=<\/span>jobTypeChoices.<\/span>choices,<\/span>\n help_text=<\/span>_(<\/span>"The type of job"<\/span>)<\/span>,<\/span>\n )<\/span>\n \n status =<\/span> models.<\/span>CharField(<\/span>\n max_length=<\/span>20<\/span>,<\/span>\n choices=<\/span>StatusChoices.<\/span>choices,<\/span>\n default=<\/span>StatusChoices.<\/span>PENDING,<\/span>\n db_index=<\/span>True<\/span>,<\/span>\n help_text=<\/span>_(<\/span>"Current status of the job"<\/span>)<\/span>,<\/span>\n )<\/span>\n created_at =<\/span> models.<\/span>DateTimeField(<\/span>\n null=<\/span>True<\/span>,<\/span>\n blank=<\/span>True<\/span>,<\/span>\n help_text=<\/span>_(<\/span>"When the job was completed or cancelled"<\/span>)<\/span>,<\/span>\n )<\/span> \n updated_at =<\/span> models.<\/span>DateTimeField(<\/span>\n null=<\/span>True<\/span>,<\/span>\n blank=<\/span>True<\/span>,<\/span>\n help_text=<\/span>_(<\/span>"When the job was completed or cancelled"<\/span>)<\/span>,<\/span>\n )<\/span> \n completed_at =<\/span> models.<\/span>DateTimeField(<\/span>\n null=<\/span>True<\/span>,<\/span>\n blank=<\/span>True<\/span>,<\/span>\n help_text=<\/span>_(<\/span>"When the job was completed or cancelled"<\/span>)<\/span>,<\/span>\n )<\/span>\n expires_at =<\/span> models.<\/span>DateTimeField(<\/span>\n null=<\/span>True<\/span>,<\/span>\n blank=<\/span>True<\/span>,<\/span>\n db_index=<\/span>True<\/span>,<\/span>\n help_text=<\/span>_(<\/span>"When this job should be auto-cancelled if still pending"<\/span>)<\/span>,<\/span>\n )<\/span>\n metadata =<\/span> models.<\/span>JSONField(<\/span>\n default=<\/span>dict<\/span>,<\/span>\n blank=<\/span>True<\/span>,<\/span>\n help_text=<\/span>_(<\/span>"Additional job-specific data"<\/span>)<\/span>,<\/span>\n )<\/span>\n \n@receiver<\/span>(<\/span>job_requested)<\/span>\ndef<\/span> handle_job_requested<\/span>(<\/span> # NOQA: PLR0913<\/span>\n sender,<\/span>\n target,<\/span>\n job_type,<\/span>\n metadata=<\/span>None<\/span>,<\/span>\n idempotent=<\/span>False<\/span>,<\/span>\n assigned_to=<\/span>None<\/span>,<\/span>\n **<\/span>kwargs,<\/span>\n)<\/span>:<\/span>\n # Creates a Job<\/span>\n pass<\/span>\n \n@receiver<\/span>(<\/span>task_completed)<\/span>\ndef<\/span> handle_task_completed<\/span>(<\/span>sender,<\/span> target,<\/span> task_type,<\/span> metadata=<\/span>None<\/span>,<\/span> **<\/span>kwargs)<\/span>:<\/span>\n # Completes a Job<\/span>\n pass<\/span>\n<\/code><\/pre>\npyreverse<\/code> from Pylint. They all do bits of the job, but require manual stitching together to get a cohesive graph of everything overlaid in the right way. So I remembered about this, and so over the last couple of days, I've built a new package which combines all of this into a live view which updates as you build your app, a management command and a panel for Debug Toolbar.<\/p>\ngraph_models<\/code> and grimp, which is used by import-linter<\/code> to dynamically map the dependencies between your different apps and third-party apps. Initially, it was a management command, which then outputs a HTML file, which exists. I then added that into a live view, and there's an integration into Django debug toolbar.<\/p>\n\n