1. Key Takeaway
If you're doing a lot of writing, Grammarly in Free mode will save you a lot of time. Using Grammarly in Pro mode will save you even more time and make your work more professional. It's worth every penny.
When you use Grammarly in Dev.to, one or two tricks will make your life a lot easier. Once you've got the hang of these, you won't want to write your posts any other way.
2. Grammarly - background
I've been using Grammarly for so long that I've almost forgotten I used to do all my spell-checking with a dictionary. Grammarly is now embedded in my Chrome browser as an "extension," and its design is so subtle that I barely notice that I'm using it.
Until last November, I used Grammarly in "Free" mode, which provided spelling checks and synonyms. But cunningly, Grammarly began highlighting chunks of my prose that it thought could stand some improvement. In my own case, this was most of it.
At first, I used this arrangement simply as a cue to shape up and try harder. Sometimes, this worked, and the highlighting would go away. But frustratingly, I often simply couldn't see what Grammarly was getting at.
However, sometimes, they would give me a "free ride" and show me their suggested improvements. This was almost always far better. So, in November, I took advantage of a "Black Friday" deal and snagged a 12-month license for just £60. They've got me for life now!
3. Using Grammarly in Dev.to
In the past, I might have used a spell-checker extension in VSCode to build my markdown files. This method had the advantage of giving me a VSCode timeline facility that enabled me to back out changes when I messed up.
When I decided I wanted to switch to Grammarly, however, I had to leave VSCode behind and build my post using only the post-editing facility in Dev.to. This was fine, except that when I was doing some heavy editing, I found that continually toggling between Edit and Preview modes would make me dizzy. This was because when you enter Preview mode, the browser view resets you to the top of the file.
If you've been working at the bottom of a large post, scrolling down to recover the edit point makes your eyes boggle.
Fixing this would be a hard problem for the Dev.to the team, but I've developed my own workaround. It goes like this:
When working on a section that is going to require some heavy editing, I highlight a unique snatch of plain text at the top of the section (it's important to avoid markdown codes) and then ctrl-F this into the browser's text search pop-up.
Now I perform my edit, close the search popup and click preview. The page view will now reset to the top of the post
Finally, to recover my position and view my edit, I reinstate the search popup with another Ctrl-F and click the down arrow. The edit point is now back in view. Four clicks, and I'm done. After a while, it becomes automatic.
4. A Dev.to post "timeline"
It does worry me that I have no backup for my Dev.to posts. I'm pretty confident that dev.to won't lose the current version of a post, but from time to time, I find that it would be very useful to recover an earlier version. However, there's no post "timeline" in Dev.to.
A recent project saw me creating an "index" for a whole series of posts. You can see this at ngatesystems.com. A "curated" post series like this is useful in itself because it gives you two bites at getting your posts indexed by Google - once in Dev.to and once in your webapp. But, in this case, there's another benefit.
This is a pre-rendered Svelte project that creates an in-memory copy of the markdown for the posts referenced in the index. I use it in the webapp to provide a keyword search index for the post series.
The webapp itself is hosted on the Google Cloud App Engine and is rebuilt nightly using a Windows schedule. This is significant because Google retains deployment history so that, in an emergency, I can revert a faulty build.
Each of these deployments has, embedded within it, a snapshot of the markdown for the post state at that point. If I need a historic post, I can just temporarily reset the webapp to an appropriate point in the deployment history. Since the webapp is designed specifically to view the posts embedded within it .... Well, it's better than nothing ...
Top comments (0)