Do you know you can run MystNode from your phone or computer to contribute your idle internet connection and earn a little MYST with it?
I've been trying MystNode for quite a while - from Android phone, to the Chrome browser extension, until I finally settled on running it 24/7 with a Raspberry Pi.
From my experience, Raspberry Pi is the most convenient way to run it. I barely need to care about it, the device itself is cheap to keep on 24/7, and it's always there doing its job.
Running it on Android or computer feels more manual. Sometimes it goes offline for unknown reasons, possibly due to connection issues, and MystNode may turn itself off automatically. That means you need to check and reactivate it again.
Don't put too much expectation on how fast you can earn.
At first, I kept checking the earnings again and again until I eventually gave up, because the manual upkeep just didn't work well for me mentally. I had to be disciplined enough to keep it running properly. Switching to Raspberry Pi completely changed my view of the whole earning experience.
The earning rate is heavily geography-dependent. Nodes in countries with higher traffic demand naturally have more earning potential than those in lower-demand countries. So if you're running a node from a lower-demand country, it's better not to expect too much.
That said, I came back to it because of curiosity and experimentation. The journey wasn't very smooth, but I eventually understood better how it works, accepted the lower earning rate in my region, and honestly felt the experience itself was more valuable than the actual returns.
If you're curious, it's worth trying at least once.
MystNodes has also just released a new rewards system. From what I understand, you can now earn points in multiple ways, including by holding at least 100 MYST in your linked wallet. Running MystNode also contributes through uptime and shared internet traffic, so you may end up benefiting from more than one source at the same time.
I only found out about this new rewards system today, and since it was launched only a few days ago, I can't say yet how much the final result will be after one month. That part still needs time to see.
I am excited to share that my new Chrome extension, DevStorage, is officially live.
This started as a small side project. Not a startup idea. Not a big launch plan. Just a tool I built because I kept running into the same annoying workflow issue during local development.
If you have worked on modern web apps for a while, you probably know the feeling. You are testing authentication. You are toggling feature flags. You are simulating user states. And at some point, you end up deep inside Chrome DevTools trying to inspect or edit localStorage.
It works, technically. But it is not smooth.
You switch tabs. You open Application. You expand Storage. You scroll through keys. You copy and paste JSON. You clear everything when you only meant to delete one item. Then you start over.
After repeating that cycle enough times, I decided to fix it for myself. That is how DevStorage was born.
DevStorage is a lightweight Chrome extension that makes working with localStorage faster and less frustrating.
It lets you view keys clearly, edit values quickly, remove specific entries without wiping everything, and clean up storage without digging through DevTools every time.
The goal was simple: reduce friction.
I did not want to replace DevTools. I just wanted something that feels more direct when you are in the middle of debugging and need to adjust storage quickly.
When we are building SPAs, storage becomes part of the debugging loop. Tokens live there. Feature flags live there. Temporary state lives there. Having fast access to that data saves time, especially when you are jumping between environments or testing edge cases.
Why I decided to ship it publicly
Originally, this was just a small internal helper. I built it to make my own workflow cleaner.
But after using it for a while, a teammate asked how I was managing storage so quickly. That is when I realized it might actually help other developers too.
Shipping it publicly forced me to polish things properly. Clean up the UI. Double-check permissions. Make sure performance stayed tight. Write clearer descriptions. Remove things that only made sense to me.
That process alone was valuable. It reminded me that even small tools deserve thoughtful design.
What I focused on while building it
I kept the scope intentionally narrow.
The first version does one thing well: it gives developers clean, fast control over localStorage.
I avoided adding too many features. No analytics. No cloud sync. No complicated dashboards. Just a focused interface that shows your storage clearly and lets you manage it without noise.
One thing I learned is that simplicity takes effort. My early versions had more buttons and more UI states. It looked powerful, but it felt heavy.
So I asked myself a basic question: what do I actually use every day? Anything that did not serve that answer got removed. That decision made the extension better.
What building this taught me
Even though this is a relatively small extension, it reinforced a few lessons for me.
Chrome extension architecture matters more than you think. Understanding permissions, background scripts, and storage APIs early saved me from messy refactors later.
UI clarity is harder than writing logic. The functionality worked early on. Making it intuitive took longer.
And most importantly, developer tools should feel invisible. When you click the extension icon, you should not have to think. You should just see what you need and move on.
That was the benchmark I kept testing against.
Who this is for
DevStorage is useful if you regularly work with localStorage during development.
If you debug login flows, test feature flags, simulate user states, or often need to reset specific keys without clearing everything, this will probably save you time.
If you rarely touch browser storage, you might not need it. And that is fine. I would rather build something focused that genuinely helps a specific group of developers than something broad and generic.
What is next
Now that it is live, the real work begins.
I am paying attention to feedback and watching how people actually use it. There are ideas I am considering, like adding search, supporting sessionStorage, or allowing export and import of storage snapshots.
But I do not want to guess what developers need. I would rather improve it based on real workflows.
If something feels awkward or unnecessary, that is exactly the kind of feedback I want.
Final thoughts
DevStorage started as a small fix for a daily annoyance. It turned into a public Chrome extension that I am genuinely proud of.
It solves a real problem in my workflow. That alone makes it worth building.
If you spend time debugging browser storage, give it a try. And if you are building small tools of your own, I would encourage you to ship them. You do not need a huge idea to create something useful. Sometimes removing a tiny bit of friction is enough.
If you try DevStorage, let me know what you think. I am always open to improving it.
Simple systems tend to last because they're easier to maintain, explain, test, and recover.
Complexity can create short-term speed, but simplicity builds long-term trust.
When a system grows, break it into smaller chunks (modules/services) so changes stay local and safer.
Give each chunk a single purpose and clear boundaries, so it can be understood and evolved independently.
(Not "isolated forever" - just intentionally scoped.)
Keeping chunks small and maintainable is one of the most reliable strategies in system design -
not a universal law, but a principle that keeps paying rent.
Every time I touch GIS coordinates, I hit the same trap: sometimes coordinates are written as
latitude then longitude, and sometimes they are longitude then latitude. Both look valid, both are common,
and the mistake often does not throw an error. Instead, the point quietly lands in the wrong country,
or worse, in the ocean.
This post is my quick reference: first the mental model (why the order differs),
then the technique I used in my own project to stop the confusion from spreading.
A picture of the classic bug
When lat and lon get swapped, a real point often ends up "somewhere in the ocean."
(If you are adding an image here, upload it to Blogspot first, then insert it into this section.)
A swapped coordinate pair often becomes a pin in the ocean, with no error messages.
The two worlds that collide
There are two different coordinate traditions that keep clashing:
1) Human geography tradition: (latitude, longitude)
Most people learn latitude and longitude in school as:
Latitude: north or south (up and down)
Longitude: east or west (left and right)
So a location is commonly written as:
(lat, lon)
Example for Kuala Lumpur (approx):
(3.1390, 101.6869)
This feels natural because we say "latitude and longitude" in that order.
2) Mapping and GIS tradition: (x, y) which becomes (longitude, latitude)
Most mapping engines and GIS systems think in Cartesian terms:
X axis is horizontal
Y axis is vertical
When coordinates are mapped into (x, y):
X corresponds to longitude
Y corresponds to latitude
So in GIS engine terms the same point becomes:
(lon, lat)
Same Kuala Lumpur example:
(101.6869, 3.1390)
This is not random. It is the consistent "x first, y second" rule.
The most important practical rule: GeoJSON is strict
If I am dealing with GeoJSON, there is almost no debate:
GeoJSON Point coordinates are always [longitude, latitude]
If I swap them to [lat, lon], the data is still valid JSON, but the point ends up in the wrong place.
That is why this bug can be so annoying.
Databases and spatial functions usually follow x, y too
Many spatial databases and geometry constructors follow:
(x, y) = (lon, lat)
Even if a library accepts different input types, the underlying geometry model is still "x then y."
Why this confusion keeps happening
People say "lat/long" in that order for decades, so apps and UIs follow it.
GIS engines and geometry models prefer "x/y," which becomes lon/lat.
Some libraries try to be helpful and auto-swap depending on context.
Some standards define axis order, but older systems may ignore it, so behavior varies.
The technique that stopped it in my codebase
The conceptual explanation is useful, but it does not prevent bugs.
What actually helped was enforcing one simple rule:
never manually swap coordinate order scattered around the code.
Instead, I introduced a single conversion layer that acts as the boundary between:
Frontend map UI (Leaflet), which naturally works with (lat, lng)
Storage and backend models, which I keep aligned to (lng, lat) / (x, y)
Concept: "Coordinate conversion layer"
In my project I called it CoordinateConversionService, but the important part is not the name.
The idea is: create one dedicated place that converts between formats, and make every other part of the app
call into it. This turns a messy convention problem into a controlled interface.
Typical responsibilities of this conversion layer:
Convert Leaflet coordinates (lat,lng) to GeoJSON coordinates (lng,lat) for saving.
Convert GeoJSON (lng,lat) back to Leaflet (lat,lng) for rendering.
If the backend stores GPS as x,y, keep x=lng and y=lat consistently.
Concept: "Update direction guard" (to avoid feedback loops)
A second practical issue appears in map editors: there are two ways a coordinate can change.
User drags a marker on the map, and the form fields must update.
User edits the coordinate fields, and the marker must move.
If both directions trigger each other, the app can end up in a loop or jittery updates.
The simplest fix is to track the source of the current update.
In my project I used a flag named isUpdatingFromMapDrag. Again, the name is not the point.
The concept is: when the map drag handler is actively pushing values into the form,
temporarily ignore form-driven map updates (or vice versa).
This guard makes the editor stable and prevents accidental recursion.
A small but important rendering detail
When only a marker position changes, I update the existing marker in place
(for example, Leaflet's setLatLng) instead of clearing and re-adding layers.
This avoids flicker and "marker disappeared" bugs.
My cheat sheet
Human-friendly display: often (lat, lon)
GIS engine, GeoJSON, storage: usually (lon, lat)
Practical rule: keep one conversion boundary and forbid manual swapping elsewhere
Editor stability: use an update-direction guard to avoid feedback loops
Final note to future me
If a point suddenly appears in a completely wrong place and there are no errors, check coordinate order first.
If the codebase has a conversion layer, the bug is usually that some new code bypassed it.
