Turn school timetable screenshots into a complete weekly Skånetrafiken travel plan, including travel margins, route preferences, alternatives and shareable results.
Planning a school week around public transport is easy until every weekday starts and ends at a different time. Transit Planner is a new service in Tornevall Tools designed to turn a weekly schedule into a practical travel plan using Skånetrafiken.
Instead of manually checking journeys for every school day, Transit Planner combines the timetable with public transport data and builds a weekly overview.
From a screenshot to a weekly travel plan
A school schedule can be uploaded as one or several screenshots. The images are analysed together using OpenAI vision, allowing overlapping screenshots to be combined into one week.
The service reads the actual timed lessons for each day and produces a simple schedule:
The generated times remain editable before the journey search starts.
Skånetrafiken journey planning
Transit Planner then communicates with Skånetrafiken and searches for suitable journeys for every school day.
The planner takes into account:
the first lesson of the day
the final lesson of the day
a configurable travel margin
both the journey to school and the journey home
preferred bus or train lines
alternative journeys when several useful options exist
The same safety margin can be used in both directions.
The normal return journey is automatically based on the reverse of the morning route. If the journey home starts or ends somewhere else, a separate after-school route can be enabled.
Choose how you actually travel
Not every technically possible journey is equally useful.
Transit Planner can prefer specific services, such as a particular city bus, while still keeping other valid alternatives available. The selected journey also shows which train, regional bus or city bus is involved.
Additional journeys stay hidden until they are needed, keeping the weekly overview readable.
Searchable locations
Origin and destination fields use live searchable locations instead of requiring exact stop IDs or coordinates.
This makes it possible to search for places such as:
Klippan station Studievägen 2, Helsingborg
without knowing how Skånetrafiken internally identifies the location.
Share the finished plan
A completed weekly plan can be given its own shareable URL.
The shared view can restore the timetable, route configuration and journey results. Uploaded timetable screenshots can also be retained with the plan, making it possible to compare the generated journeys with the original schedule later.
Built for actual weekly use
Transit Planner is intended for situations where “just check the journey planner” becomes repetitive.
A changing school timetable is an obvious example, but the same approach can also be useful for recurring work schedules, courses and other weekly activities where departure and arrival requirements change from day to day.
Transit Planner is part of Tornevall Tools and is still being actively improved as real-world schedules and Skånetrafiken data expose new edge cases.
We have completed a set of server-side fixes for the Tornevall Networks DNSBL integration after identifying authentication and reliability problems affecting existing clients, including the currently released WordPress integration.
Existing WordPress installations remain supported
One of the most important requirements was that existing installations must continue working without forcing users to upgrade their plugin just because the server-side authentication model has evolved.
ToolsAPI therefore continues to recognize the authentication method used by released DNSBL clients. Existing DNSBL API keys remain valid through the legacy-compatible authentication path, while the newer DNSBL token model continues to work alongside it.
No API key rotation or WordPress plugin update should be required solely because of these changes.
Internal retries no longer lose authentication
We also found a separate problem in the DNSBL reliability system.
Failed DNSBL mutations can be buffered and retried internally. Those retries were executed inside an authorized server process, but the replayed request itself did not contain authentication in a form understood by the API controller.
The result could be misleading errors such as:
401 unauthenticated
even though the original operation had been properly authenticated.
The retry mechanism now carries a strictly internal, runtime-only authorization marker. It is accepted only while the trusted retry process is executing and cannot be reused as an external API credential.
Better handling of temporary DNS socket failures
Another source of failures was transient UDP socket conditions during direct DNS updates, particularly:
Resource temporarily unavailable
These conditions can occur while waiting for a DNS server response and do not necessarily mean that the DNS update itself is invalid.
The DNS update layer now recognizes transient conditions such as EAGAIN, EWOULDBLOCK and interrupted socket reads and performs bounded retries before treating the operation as failed.
Real DNS errors, authentication failures and TSIG errors are still reported normally.
Additional reliability improvements
The same operational review also uncovered a few related problems in ToolsAPI.
Transit Planner image uploads were too aggressively rate-limited for the intended multi-screenshot workflow. The upload limits have been adjusted while keeping abuse protection in place.
Deploy health reporting was also made page-wide instead of depending on a specific Statuspage component name, making recovery reporting more robust if components are renamed or reorganized.
What this means for users
For users of Tornevall Networks DNSBL integrations:
Existing released WordPress clients remain supported.
Existing DNSBL API keys continue to work.
Internal retry operations no longer fail simply because authentication context was lost.
Temporary DNS socket conditions receive bounded retries instead of immediately generating a server error.
Missing or genuinely invalid credentials still fail normally.
No new versioned API endpoint has been introduced.
The fixes were implemented in ToolsAPI and merged on September 27, 2026.
If you recently encountered unexpected 401 responses while adding or removing DNSBL records, or intermittent DNS update failures, the problem may have been related to the server-side issues addressed by this update.
On Sunday I was planning to write something reasonably detailed about the week that had just passed. The problem was that Sunday eventually turned into “still working on things from the week that just passed”, so I never really got there.
I have therefore decided to do what every responsible developer does when the documentation backlog becomes too large: make the documentation shorter. This is roughly what happened.
It started with a terrible Laravel idea
ToolsAPI was still running Laravel 8, which had been out of security support for quite some time. The sensible upgrade advice is to move through the major versions one at a time, dealing with package compatibility, framework changes, middleware, routing, PHPUnit and whatever else Laravel decided to move around between releases.
So naturally I upgraded directly from Laravel 8 to Laravel 13 because I didn’t care about the warnings. Instead, I trusted Copilot, I had very little time, and apparently this is how decisions are made now. It went almost well. At late evening, at 22, I was acutally passing thought last hell of caches. After that point it actually worked surprisingly well. Yes, production found some ancient cached Laravel state and briefly reminded me that software can remember things long after everyone involved would prefer it didn’t. But if just drop that little issue, everything was up again. Leaving copilot alone for 16 hours with destructive methods isn’t a very clever idea, so that was the first ruleset I had to add: DO NOT RUN DESTRUCTIVE CALLS IN PRODUCTION!
Because I did it in production…
What really happened
ToolsAPI – Laravel 13
The whole platform moved from Laravel 8 to Laravel 13, old compatibility baggage was removed, dependencies were modernized and Laravel Mix was replaced with Webpack 5. Production celebrated by throwing HTTP 500 errors because stale cache survived the upgrade, so deployment checks and cache handling were subsequently taught some manners.
GitHub Actions – “But did it actually work?”
The development flow became much more aggressively issue -> branch -> code -> test -> PR -> CI -> fix what exploded -> merge. Several integrations now perform real provider checks instead of receiving a participation trophy because a mock returned 200 OK. Problem is that I got some dumb integrity checks inside that system that practically ate my budget.
Error reporting – Fail loudly, please
Browser errors, API failures, workers, schedulers and other operational disasters can now report directly to #toolsapi, independently of ordinary audit settings. This has already proven useful because apparently software defects become much easier to fix once they stop hiding. Slack and massive Codex integrations really works nice! All errors are shown quickly and ChatGPT can read from those errors and fix them instantly!
Slack AI Bot – It has escaped into Slack
The Slack bot learned DMs, mentions, active thread continuation, images, multiple workspaces and a polling fallback for situations where Slack Events decides not to be particularly eventful. Public distribution also forced the polling logic to become considerably less enthusiastic about calling Slack’s API every ten seconds.
This wasn’t really planned, but since I was curious on other things, this is where I ended up.
Alert Engine – Scheduling things without creating a time paradox
A shared Alert Engine now handles recurring monitoring, runs, results, deduplication, notifications and history instead of every service inventing its own cron-shaped wheel. Real scheduler traffic immediately found stuck runs and overlaps, so locking, stale-run recovery and overlap protection were added before the scheduler could successfully fight itself.
Web Search Alerts – Google Alerts after drinking OpenAI
Web Search Alerts became considerably more serious: real OpenAI web search, source recovery, verification, deduplication, notifications, run history and better diagnostics. It also learned how to survive malformed output, incomplete provider responses and HTTP 403 results, because the Internet remains committed to being the Internet.
Job Search – Teaching AI what I don’t want
Job Search gained live progress, better search diagnostics, Alert Engine integration and profile-specific negative keywords. AI may suggest that “truck driver” is perhaps not the ideal result for a developer profile, but it still has to ask permission before permanently learning from its mistake.
Whisper – Please transcribe this somewhere else
Whisper gained multi-file uploads, better transfer progress, transcript-based titles and the ability to run speaker diarization after transcription. More importantly, transcription can now be handed to remote CPU/GPU workers using leases, heartbeats, progress reporting and capability negotiation, allowing the web server to concentrate on its traditional responsibility of having entirely different problems.
With that said, this is IF you have a GPU to run with. I really don’t. Besides, I’m trying to run with Diarization again.
Guestbook – Somehow this became a platform
What started as “let’s preserve some old guestbook data” turned into multiple owned guestbooks, imports, APIs, embeds, moderation and external client support. Public DNSBL badges were replaced with country flags, because publicly branding every visitor with internal abuse metadata turned out to be slightly more information than a guestbook actually needs.
WordPress – Tools has plugins now
The WordPress integration grew into a real Tools client with Guestbook support, direct Tools account pairing, DNSBL credential handling and proper Plugin Check coverage. The separate DNSBL plugin also started moving deeper into WooCommerce and fraud/event handling, because apparently DNS blacklists also needed a career change.
Security Advisory Watch – Because upgrading Laravel wasn’t enough security work
Products and technologies can now be monitored for advisories, CVEs and related security changes using the same search and notification foundations. It also gained dedicated GUI and regression coverage after discovering the classic enterprise security vulnerability known as “the form looks like shit”.
Security Probe Guard – The guard dog bit the owner
Automatic exploit-probe detection and temporary bans were added. Then an automatic ban managed to lock out the operator, which led to recovery routes, fail-open handling for old automatic bans and the revolutionary security concept of “maybe don’t automatically ban the administrator”.
SoundCloud – Zero is also a number
SoundCloud received OAuth reauthorization, chart fixes and several profile-insight repairs after real data demonstrated that a confidence value of 0 is perfectly valid and does not necessarily mean “the application should crash now”. This is why production data gets a vote.
SocialGPT gained for a long time ago a sidepanel instead of popup based requests. We haven’t realeased this extension for a while, so nobody knows about this yet.
Services – We have enough of them to need categories
/services was reorganized into actual categories because the previous architecture was rapidly approaching “here is a large wall of links, good luck”. A green forum-inspired theme called “Jessica” also appeared during all this, because clearly visual consistency was the urgent missing ingredient.
What is happening now?
Android Tools – SocialGPT leaves the browser
The Android app is gaining proper context capture, AI context cleanup, full context review, privacy-safe statistics, push notifications and the required Android/Google Play consent flows. The current objective appears to be turning “select some text and ask Tools” into “Tools is just there when I need it”, without turning the phone into spyware in the process.
Web Search Alerts – Apparently not finished being useful
Results are getting source exclusions, rejected-result inspection and restoration, searchable delegation, ownership transfers, location context and better source recovery through the shared SearchFactory. What used to be “search for this occasionally” is steadily becoming a small monitoring system with opinions.
Guestbook – Still refusing to remain a guestbook
Embed routing has been repaired after web servers managed to return a 404 status together with perfectly valid JavaScript, which is an impressively confusing achievement. Autosaved settings, ownership transfer, notifications, better pagination and visible service versioning are also being added around it.
Statuspage – Yes, another platform
Tools is getting its own proper Statuspage foundation with public status pages, components, incidents, owner management, administration and a public read API. The WordPress integration is already growing a Statuspage block, because displaying whether Tools is broken should ideally continue working even when Tools is broken.
Votech – BBVote’s successor is waking up
Votech now has its proper architecture and dedicated database/model foundation, with the old BBVote data treated as historical input rather than something we should continue poking with sticks. The GUI, voting flows, administration and integrations come next. And no, the API will not suddenly grow /v1/, /v2/ and seventeen generations of archaeological sediment.
We have an election running in a few weeks. I was thinking of making a BBVote clone – PoliticalVote. Or something like that.
SocialGPT – Again – Context, but only after consent
A consent-gated context-analysis endpoint is being built so SocialGPT can correlate page content, selected text and bounded browser observations without silently shipping everything it sees somewhere else. The extension is simultaneously learning more generic DOM/XHR correlation, which sounds innocent until you remember what modern websites look like internally.
AI accounting / Ko-fi – Computers have discovered money
AI usage accounting is being connected to users, providers, token consumption and eventually prepaid credit. Ko-fi is part of the payment direction, because once AI starts consuming measurable amounts of money it becomes surprisingly important to know whose money it is consuming.
The reason for why I do this is actually, if I release an android app into Google Play Store, I don’t want to pay for other peoples AI usage. So this is going to get real. And I probably need to register myself as a firm or something very soon now.
Tools versioning – The footer now knows what it is
The main Tools platform is finally getting an explicit semantic version that everybody can see, while administrators still get the extra Laravel/PHP diagnostic information. Considering how much changed before the platform got a visible 1.0.0, this is possibly the most backwards software-release story in the entire list.
Image generation and file storage
This is also a concept that I’m working with right now. Image generation should be a platform-global feature, to make sure BBVote/Votech and other stuff can get hold of a very nice AI feature. Also storing those files somewhere, is a plan for which Filestorage could be perfect.
… and possibly some MCP services. Who knows?
This is a very short list actually. The more I think, the more crap I produce and I throw it at tools. If you have any suggestions, please feel free to contact med. The platform already features a lot more than I just presented, since this is only the NEW stuff coming up. Oh, did I mention a suggestion box? That’s also in the agenda…
We are building a centralized connector framework for Tools. The goal is simple: make integrations reusable, secure and easier to extend. Instead of every service having its own custom integration, Tools will provide a common framework where connectors can be added and managed consistently.
The first AI connectors will be:
OpenAI Connector (Present)
Microsoft Connector (Entra / Copilot, hopefully upcoming)
Future connectors will expand into areas such as…
Social platforms
Messaging services
External APIs
Enterprise integrations
Each connector will have a standardized way of handling…
Authentication
Permissions
Configuration
Logging
API access
The foundation will support both internal services and user-owned integrations, where users can connect their own accounts and manage their own permissions.
The goal is to create an IFTTT-like integration layer, but built around something else where we keep expensive services separated from things that can be offered for free, AI services and enterprise authentication.
ToolsAPI is currently undergoing one of its larger platform upgrades.
The project has been running on Laravel 8 for several years. That version has long since reached the end of its official support lifecycle, while Laravel itself has continued through several major generations.
We’re therefore moving ToolsAPI directly from Laravel 8 to Laravel 13, the current generation of the framework.
This is significantly more than a version number change. The work includes updating and replacing dependencies, modernizing older application code, adjusting integrations, improving compatibility with current PHP versions and rebuilding parts of the test suite around the newer framework.
Security maintenance is naturally part of this work as well. Moving back onto a currently supported framework gives ToolsAPI access to ongoing upstream maintenance and security updates instead of relying on an obsolete framework generation.
The migration is being performed and tested in stages before it reaches the production environment. Existing ToolsAPI services are expected to remain available while that work continues.
Tools now has a working image-generation feature that is already in use and confirmed through the X-bot flow. It can generate images directly in Tools and store them in the project’s image archive for reuse in later workflows.
This is a practical feature for quick visual drafts, concept images, and supporting material without leaving the Tools environment.
Real use, not only a preview
The feature is not just a test setup. It is live and working in the current Tools setup, with generated images handled as background jobs so the request does not block the rest of the work.
That makes the feature useful both for normal web/API use and for X-bot-driven flows where an image is part of the response or follow-up content.
Easier to reuse and keep track of
Generated images can be saved in the built-in image archive and reused later, which helps when a concept or draft needs to be refined or referenced again. This makes the feature more useful than a one-off generation request.
Fair usage and responsible availability
AI image generation has a real cost per request. Access is therefore still managed with sensible limits and abuse protection so the service remains available for real users instead of being consumed by a single heavy script or workflow.
Support the project
Tools is kept available as a public service, but servers and AI usage still cost money. If you want to help keep the more expensive features running, donations and recurring support are very welcome.
ToolsAPI started as my personal toolbox: a place for utilities I knew I would actually use myself. That idea still exists. It has just developed a slight case of “THIS SHOULD PROBABLY GO INTO TOOLS TOO”.
What began with technical helpers is turning into a much broader collection of services for infrastructure, automation and ordinary everyday problems. The direction is starting to resemble the IFTTT-like integration platform I have also been exploring: different services, triggers and actions gradually meeting in the same place.
ToolsAPI now includes certificate distribution, DNS administration, assisted job searching and personal reminder services. These are quite different problems, but most of them have entered Tools for the same reason: I ran into something repetitive, awkward or easy to forget and thought, “I can probably automate that.”
Let’s Encrypt certificates in one place
One of the latest additions is central Let’s Encrypt certificate management.
Certificates created by Certbot can be published to Tools after issuance or renewal. Tools validates the certificate material, stores it privately and associates it with the account that should have access to it. The latest PEM bundle can then be downloaded manually or fetched automatically from another server using a protected token.
This is useful when the machine issuing a certificate is not the same machine that needs to use it. Tools can act as a small distribution point between Certbot, servers and the people responsible for the certificate.
Certificates keep the same public UUID across renewals, while access tokens can be rotated separately when needed. The interface also shows the domains included in a certificate, its current status, expiry and latest upload.
In other words: Certbot can keep doing what Certbot is good at, while Tools handles the “now how do I safely get this certificate over there?” part.
DNS administration is connected to certificate access
The certificate service is also connected to the DNS editor.
An enabled certificate assigned to a user can grant access to the matching DNS zone, so the same domain does not need a separate DNS permission entry just to be managed by the certificate owner.
The DNS editor itself makes it possible to work with zones and records from the web interface instead of editing zone files by hand. Access can be delegated per user, records can be searched and updated, and the same interface can work with zones backed by an external provider such as Cloudflare.
For locally managed zones, Tools can use cached zone data and refresh it from the authoritative source when needed. The API exposes the same basic operations for integrations and automation.
DNS is one of those things that works beautifully right up until the exact moment when you urgently need to change something. Having the records, permissions and certificate relationship visible in one place makes that considerably less entertaining.
A job search agent that can keep looking
Job hunting is another repetitive workflow that somehow found its way into the same toolbox.
The Job Search agent works from a personal search profile describing locations, types of work, keywords, exclusions and additional instructions. It searches for current listings on the web and performs additional checks on the result pages before they are accepted.
The service is intended to reduce repeated searching and cut down on listings that are already gone or clearly irrelevant.
Results can be reviewed in Tools, and unwanted listings can be dismissed so the same result is not repeatedly presented to the same account. Scheduled searches can reuse the profile and continue looking for new opportunities over time.
AI is used to help search, sort and compare results. The person using the service decides which listings are worth reading or applying for.
The basic idea is fairly simple: if finding a job is already work, there is no particular reason to manually redo exactly the same search every morning.
As a parent, I also wanted a simpler menstrual reminder
Then there are features that are considerably less server-shaped.
As a parent, keeping track of dates and remembering when the next period may be approaching is the kind of recurring everyday task where a small reminder can genuinely help. So, naturally, that ended up in Tools too.
The menstrual tracking service allows period starts to be registered and used to build a cycle history. From that history, Tools can show information such as average cycle length, the latest registered start and an estimated next start.
Optional SMS reminders can be enabled a selected number of days before that estimate. Accounts can also be linked so the same reminder can be sent to a parent. The menstrual profile belongs to the person being tracked, and delivery to each recipient is handled separately.
The service can also be used without SMS as a personal history of registered cycles.
It is probably not the first feature people expect to find next to DNS and Let’s Encrypt certificates, but that is increasingly the point of Tools: useful things do not always belong to the same category before they become useful together.
The toolbox is getting suspiciously large
There is still a personal-toolbox idea at the core of ToolsAPI. I tend to build things because I have an actual use for them, or because someone close to the project has a concrete problem worth solving.
The difference now is that the boundary has become much wider. Infrastructure tools can connect to account permissions. Certificates can connect to DNS. Search agents can run scheduled work. Reminder services can react to dates and user settings.
That is also why the IFTTT-like direction is interesting. Instead of treating every feature as an isolated application, more of Tools can eventually become reusable building blocks: something happens here, which triggers something useful over there.
At the current rate, the technical design principle may eventually just become: “Fine. Put it in Tools.”
ToolsAPI is actively developed, and suggestions are useful while this slightly overenthusiastic toolbox continues to grow. If something is missing, awkward or unnecessarily complicated, feedback and improvement ideas are welcome.
Att leta jobb kan lätt bli ett eget heltidsjobb. Samma sökningar ska göras om och om igen, annonser ska öppnas, arbetsgivare jämföras och gamla träffar sorteras bort. Därför finns Job Search i Tools – en personlig jobbsökningsagent som gör en stor del av det återkommande letandet åt dig.
Tanken är inte att agenten ska välja jobb åt dig. Den ska hjälpa dig att hitta sådant som faktiskt verkar relevant, så att du kan lägga mer tid på de annonser som är värda att läsa och mindre tid på att upprepa samma sökningar.
Du beskriver vad du letar efter
I Job Search bygger du upp en egen sökprofil. Där kan du tala om exempelvis vilka orter du är intresserad av, vilka typer av jobb du söker, vilka ord eller områden som är viktiga och sådant du helst vill slippa få träffar på. Det går också att ge agenten egna instruktioner. En sökning kan därför vara betydligt mer personlig än en vanlig lista med några nyckelord.
Du kanske söker arbetsledande jobb inom grönytor i nordvästra Skåne, men även kan tänka dig lager eller butik. Eller så är distansarbete intressant, medan vissa typer av tjänster inte alls är det. Sådana skillnader kan agenten ta hänsyn till när den söker.
Agenten söker på webben åt dig
När sökningen körs använder Tools din profil för att leta efter aktuella jobb på webben.
Agenten försöker inte bara hitta sidor där några av dina sökord råkar förekomma. Den bedömer också hur väl en träff stämmer med det du faktiskt har beskrivit att du söker.
Land, orter, yrkesområden, nyckelord, undantag och dina egna instruktioner följer med som en del av sökningen.
Träffarna kontrolleras innan de visas
Jobbsajter förändras snabbt. En annons kan tas bort, flyttas eller leda till en sida som inte längre innehåller jobbet som först hittades.
Därför gör Tools en extra kontroll av träffarna innan de godkänns. Målsidan ska gå att nå och grundläggande uppgifter som jobbtitel, arbetsgivare och plats ska gå att hitta.
Det minskar mängden döda länkar och märkliga träffar som annars lätt följer med automatiserade sökningar.
Du bestämmer vad som är intressant
På /job-search kan du öppna originalannonsen direkt och gå igenom de jobb agenten har hittat.
Om en annons inte är intressant kan du dölja den. Tools kommer då ihåg det för just ditt konto och försöker inte presentera samma annons för dig igen bara för att den dyker upp i en senare sökning.
Det påverkar inte andra användare. Job Search är byggd runt varje användares egen profil, historik och val.
Återkommande sökningar utan att börja om från början
En av poängerna med en agent är att du inte ska behöva göra exakt samma arbete varje dag.
Job Search kan köras återkommande och använda samma personliga sökprofil när nya jobb letas fram. När en schemalagd sökning är aktiverad kan resultatet sammanställas och skickas vidare som en rapport.
Systemet håller samtidigt reda på tidigare träffar och sådant du redan har valt bort, så att sökningen kan fortsätta där den förra slutade i stället för att hela tiden börja om från noll.
En agent som ska hjälpa – inte bestämma
Job Search använder AI och aktuell information från webben för att sortera, jämföra och kontrollera sökresultat. Det innebär inte att varje bedömning automatiskt är rätt.
Se därför agenten som ett extra par ögon. Den kan göra grovjobbet, hitta kandidater och minska mängden manuellt letande, men det är fortfarande du som avgör om ett jobb passar, om arbetsgivaren verkar intressant och om du vill söka tjänsten.
Att komma ihåg när mensen började senast, räkna fram ungefär när nästa period väntas och samtidigt hålla reda på när det börjar bli dags kan vara lättare sagt än gjort. Därför finns nu en menskalender i Tornevalls Tools som hjälper till att hålla reda på datumen och kan skicka en påminnelse innan nästa mens väntas börja.
Tanken är att verktyget ska vara enkelt att använda. Du registrerar när mensen börjar, och Tools använder de registrerade uppgifterna för att hjälpa till med planeringen framåt.
Få en påminnelse innan det är dags
Det går att ställa in hur många dagar före den beräknade mensen som en påminnelse ska skickas.
Påminnelsen skickas med SMS till användarens registrerade mobilnummer. Om tiden för den vanliga påminnelsen redan har passerat kan systemet i stället skicka den så snart som möjligt.
Det gör att tjänsten även kan användas utan att man behöver komma ihåg att gå in och kontrollera kalendern hela tiden.
Fler kan hjälpas åt
Menskalendern är inte begränsad till att endast personen som menstruerar behöver hålla reda på allt själv.
Det går även att koppla en annan användare till profilen, till exempel en förälder som hjälper sitt barn eller sin ungdom att hålla koll på när nästa mens närmar sig.
Påminnelserna hanteras för varje användare, vilket innebär att flera personer kan få information när det behövs.
Ett enkelt vardagsverktyg
Målet med menskalendern är inte att bygga en komplicerad hälsoapp fylld med funktioner som alla kanske inte behöver.
Grundfunktionen är betydligt enklare: registrera mensen, håll reda på cykeln och få en påminnelse när nästa period börjar närma sig.
Tjänsten är en del av Tornevalls Tools och kan fortsätta utvecklas efter hand.
Har du idéer på hur den kan bli bättre?
Mens och menscykler fungerar olika för olika personer, och det finns därför säkert funktioner eller situationer som vi inte har tänkt på ännu.
Om du använder tjänsten och saknar något, tycker att något borde fungera annorlunda eller har en idé som skulle göra menskalendern mer användbar, får du gärna höra av dig med förslag.
Även små förbättringar kan göra stor skillnad när ett verktyg ska fungera i vardagen.
Tornevall Networks is currently exploring a new integration layer for ToolsAPI called ToolsAPI Platform Bridge.
The basic idea is similar to services such as IFTTT: connect systems that normally operate separately, let an event in one system trigger something in another, and make those connections manageable from one place.
ToolsAPI already communicates with several external systems today, but many of those integrations have been built for one specific purpose. Platform Bridge would provide a common foundation instead.
Connecting more than social media
The original idea started around social platforms such as Facebook and Bluesky, but it quickly became clear that the same concept can be useful far beyond social media.
A platform could just as easily be Dropbox, OneDrive, Slack, Microsoft Teams, GitHub, Bitbucket, Jira or a forum.
ToolsAPI’s existing vBulletin integration is particularly interesting here. Instead of treating the forum as a separate system, Platform Bridge could make forum activity part of larger automated workflows.
A newly published WordPress article could, for example, create a forum thread, publish a post on Bluesky and Facebook, store related material in Dropbox or OneDrive and send a notification to Slack or Teams.
The flow could also start in the other direction. A new forum thread could trigger publication elsewhere, a GitHub pull request could result in a notification or another action, and changes in Jira or Bitbucket could be connected to other services.
Triggers, conditions and actions
The planned model is deliberately simple:
Something happens -> optional conditions are checked -> one or more actions are performed.
A trigger could be a new article, forum thread, uploaded file, received message, repository change or scheduled task.
Conditions could decide whether the workflow should continue. An automation may only apply to one forum section, a particular WordPress category, a specific repository or files placed in a certain directory.
Actions could then create a thread, publish a post, send a message, upload a file, create an issue or call another ToolsAPI service.
The individual services would still work very differently behind the scenes. Platform Bridge would provide a common layer so the rest of ToolsAPI does not need to understand every external API separately.
A growing list of possible platforms
Current candidates include Facebook, Instagram, WhatsApp, Bluesky, Slack, Microsoft Teams, Dropbox, OneDrive, vBulletin, WordPress, GitHub, Bitbucket and Jira.
Other services such as Discord, Telegram, Matrix, Mastodon, GitLab, Google Drive, SharePoint and generic webhooks are also natural candidates for later integration.
Not every service provides the same possibilities, and some integrations will inevitably be easier than others. The Bridge is therefore being designed around capabilities rather than assuming that every platform can perform the same operations.
Keeping track of what happened
Automation becomes considerably less useful when nobody knows why something failed.
Platform Bridge is therefore also intended to keep a history of events and individual actions. If one automation publishes to three services and one of them fails, the successful actions should remain successful while the failed action can be retried separately.
The same tracking can also prevent loops. If ToolsAPI creates a Facebook post from a forum thread, an incoming event for that Facebook post must not accidentally create another forum thread and start the same process again.
Connections between objects can also be remembered. ToolsAPI could know that a particular WordPress article belongs to a specific forum thread, Facebook post and Bluesky post, making future updates and cross-platform management possible.
Still at an early stage
ToolsAPI Platform Bridge is currently an architecture and development concept rather than a finished service.
The first work is focused on defining a common provider model, connections, triggers, actions, event handling and the database structure needed to support them safely.
The intention is to let existing ToolsAPI integrations gradually become part of the same system while leaving room for completely new platforms later.
In other words, the interesting part is no longer simply getting ToolsAPI to talk to another API.
It is getting all of those systems to talk to each other.
