The pattern was always the same. Something interesting would happen, I’d think “I should write about this,” and then I’d open a browser tab, navigate to my CMS, stare at an empty editor, and close it twenty minutes later with nothing to show for it. Not because writing is hard. Because the setup before the writing was just enough friction to kill the momentum.

My blog runs on Jekyll. Publishing meant creating a markdown file with the right frontmatter, running Jekyll locally to check how it looked, fixing whatever was off, and pushing to GitLab. Each step is trivial on its own. Together, they added up to a ritual I kept skipping.

I run a personal AI assistant on a VPS, basically a remote Claude Code session I can connect to from any device. A few weeks ago I decided to treat blog publishing as a first-class workflow inside that environment rather than something I’d do separately.

The result is three commands.

/blog-draft is where it starts. I describe what I want to write, or say “blog this conversation,” and Claude drafts the full post, saves it to my Jekyll drafts folder, and tells me the file path. The post exists on disk in under a minute.

/blog-preview is the one that actually changed my behavior. It spins up Jekyll locally with the --drafts flag, then opens a Cloudflare Tunnel that gives me a public URL. No port forwarding, no ngrok setup. I can open that link on my phone and see exactly how the post will look to a reader before anything is committed. Jekyll’s watch mode means edits I make rebuild automatically, so I can tell Claude to tighten a paragraph, refresh the browser, and see the change immediately.

/blog-publish moves the draft to _posts/, commits, and pushes to GitLab. Cloudflare Pages picks it up and the post is live within a minute.

What surprised me was how much the preview step mattered. I used to skip previewing entirely and just publish, which meant occasionally shipping posts that looked wrong on mobile. Now I read every post at the preview URL the way a visitor would, on an actual device, before it goes anywhere. That one change has made me more confident about hitting publish.

The workflow is not magic. It is just friction removal applied in the right places. The ideas were always there. They needed a shorter path to the page.

What tasks do you keep putting off not because they’re hard, but because the setup before them is annoying enough to make you stop?

Exploratory space for options is vast. Taking variables of call, put, strike prices and expiry dates, there are more than 1k+ option contracts for each underlying asset. This results in explosion of exploratory space if you consider all the option contracts available in market. At any given point of time, there are more than 100k+ live option contracts.

What better way to explore and scan this space than using custom code? There are multiple ways to get insights or devise your algorithmic startegy or backtest your strategy for option contracts. You can use snasphots for backtesting or getting insights. However, in this post, we will focus on real time or near real time option data. We start with analysis of data provider for real time options for hobbyists. This blog isnt focused on data provider APIs for instituions or enterprises, but focuses more on hobbyists and hackers who are on limited budget.

Before we start to analyze different data providers, let me setup provide context on requirements through which lens I will analyze these data providers. These requirements are based on one of the option strategy I experimented with.

Requirements lens

Freshness: Realtime or Near-realtime options data. I consider 15 mins delay as near-real time data.

Blanket API for Option chain I should be able to get all option contracts of underlying ticker with a single API call. The API shouldnt restrict me to only get option contracts of a ticker for single expiry.

[Nice to have] Websocket feed for Option contracts For streaming information, getting live feed is preferred. Its fragile architecture to call option chain API every 5 mins and do processing. In longer run, I would like to use streaming feed for option chain.

Price This will be deal breaker. I am hobbyist. I will be more conservative and say maximum I am willing to pay for Options API is $50 per month. Tbh, once you put your strategy in production, $50 is dirt cheap.

Backtesting How would you gain confidence in startegy, if you cannot backtest? There must be support of historical option chain API to help backtest

Option Entities as part of API call 1. Option ticker
2. Expiry 3. Call or Put
4. OHLC 5. Last transaction price 6. Strike price 7. Greeks 8. IV 9. Underlying instrument price 10. Open Interest and Volume

Ease of implementation I would classify this as Low/Medium/High

Getting all these requirements for $50 is hard find. We will explore some data providers, and try to maintain balance between API features and requirements.

Data providers comparision:

1. Thetadata

Notes

• Thetadata is more suited for algo traders focusing on volatility and requiring millisecond updates.
• Thetadata requires to setup Theta Termina which is constantly running. I havent looked into how it works with details but that could add more complexity

1. MarketData

Some of the Marketdata features:

Notes

• Their credit based pricing model isnt much favorable for option chains. Everytime one ticker(option contract) is included in the response, its considered one credit. Lets say, we get an option chain with 40 option contracts data. This will be considered as usage of 40 credits. Credits can be exhausted really quick in this manner.
  • There is an option to retrieve cached feed vs live feed. If you use cached feed, you are only charged 1 credit per response irrespective of number of quotes returned. Using cached feed is a premium feature.

Playing around with Option Chain API

• Option Chain API only support a single expiration date per call. It cannot support multiple expiration date. ie. The filters need to resolve to single expiration date
• I am running the code on 07/04/2024. If no paramater is specified, it returns option chain on 07/19. Not sure, why?
• If I set “weekly” to “true”, it returns option chain of immediate week. This makes sense. If I set “weekly” to “false”, it returns option chain on 07/19. Why is it not returning 07/12 option chain?
• Setting “monthly” to “true”, doesnt return monthly option chain. It still returns 07/19 option chain for some reason.
• For my usecase, I should call the expiration endpoint first. Take top x dates and call option chain endpoint simultaneously.

When you put MS Todo side by side with other task management applications like Todoist or TickTick, it’s clear that MS Todo falls short in terms of features. Despite this, I’ve continued to use MS Todo for its simplicity. Over time, I’ve entered over 6000 tasks into the Microsoft Todo app. Moreover, the effort and time required to adapt to a new task management app are substantial, and in my view, the cost of switching and habit formation doesn’t justify the benefits. However, it appears that Microsoft’s focus isn’t so much on developing MS Todo as a standalone application but rather on enhancing its integration within the broader Microsoft 365 ecosystem.

In my automation workflows, I frequently utilize IFTTT and Zapier to capture tasks into the MS Todo Inbox. For several months, I’ve been dealing with a persistent bug in MS Todo that seems to have gone unnoticed by many MS Todo users and their integration partners. This issue came to my attention while setting up an IFTTT Applet and using “Create task in task list” MS Todo action. Despite having more than 20 task lists, it only displays the “Flagged email” task list for me. At first, I suspected the problem was with IFTTT, so I contacted their support team. However, after a month of back-and-forth communication, we still didnt reach conclusion.

I noticed similar issues with Zapier and when using the MS Todo Alfred workflow. This made it crystal clear that the problem lies with the Microsoft Graph APIs themselves, rather than with their client-side implementations.

My curiosity piqued and I started going through their API documentation. It appears that Microsoft offers two similar APIs for retrieving all Task lists: List task lists and Get task list delta. The former appears to be more definitive, while the latter is preferred for clients that wish to stay synchronized with the server to enhance performance. To examine the API responses, I utilized the Microsoft Graph Explorer to make calls to both APIs. Below are my findings:

List task lists API

Request

https://graph.microsoft.com/v1.0/me/todo/lists/

Response

{
"value": [

		{
		"@odata.etag": "dummyTag",
		"displayName": "Flagged Emails",
		"isOwner": true,
		"isShared": false,
		"wellknownListName": "flaggedEmails",
		"id": "dummyID"
		}
	]
}

Even though I have 20+ lists in Microsoft Todo, it only gets me “Flagged Emails list”. This is a bug

Get Task Lists API

Request https://graph.microsoft.com/v1.0/me/todo/lists/microsoft.graph.delta()

Response

{
	"displayName": "Flagged Emails",
	"isOwner": true,
	"isShared": false,
	"wellknownListName": "flaggedEmails",
	"id": "dummy"
},

{
	"displayName": "Tasks",
	"isOwner": true,
	"isShared": false,
	"wellknownListName": "defaultList",
	"id": "dummy"
},

{
	"displayName": "List A",
	"isOwner": true,
	"isShared": false,
	"wellknownListName": "none",
	"id": "dummy"
},

{
	"displayName": "List B",
	"isOwner": true,
	"isShared": false,
	"wellknownListName": "none",
	"id": "dummy"
}

This correctly displays all my lists in MS Todo. I’m uncertain whether the Delta API was recently introduced or has been available since the beginning. However, it’s clear that the initial requests from the list taskLists API and the list taskLists delta API follow different patterns.

I found only a single mention of this problem online. Microsoft has yet to notice the issue, which negatively impacts the user experience for some customers. One reason this problem might have remained under the radar is that it primarily affects power users who have multiple task lists, numerous tasks, or have been using MS Todo for an extended period. Regular customers with minimal use of MS Todo are not affected by this issue.

Microsoft doesnt expose easy way to submit bug reports for Microsoft Graph API. However, I have submitted feedback here in Microsoft Graph portal.

Cascading effect

Incorporating abstractions undoubtedly offers benefits in terms of speed and convenience, yet it also introduces costs related to maintenance and traceability. Within a web of API integrations, a single bug at the system’s core can ripple through to all its clients and, ultimately, impact the business. Furthermore, the cost of diagnosing errors becomes significant when integration partners are in the dark about the root cause of an issue. As a customer, my instinct would be to report a problem to IFTTT, never suspecting that the real issue lies within the Microsoft API itself. When a minor bug occurs in a tool designed for further abstraction, it’s like tossing a pebble into a pond: the resulting ripples extend broadly, influencing not just an individual user but the entire network of those connected to the system.

This makes me wonder and appreciate how automation tools(eg. IFTTT, Zapier, Make, Tray.io) runs their operations while maintaining more than 5k+ API integrations accross more than 800+ different SaaS services.