DEV Community: Martin Emmert

Devlog #01

Martin Emmert — Wed, 26 Aug 2020 23:09:23 +0000

27.08.2020

After bootstrapping my new application with my personal example NextJs application, I prepared the phrasing of test cases that should be passed to match the acceptance criteria of the first user story.

As a user, I want to write down my thoughts in a bullet list so that I can see them all in one place. #2

martinemmert posted on Aug 26, 2020

Acceptance criteria:

[ ] the document is initially empty
[ ] each bullet point has a unique id
[ ] pressing enter exits the editing of the current bullet point, creates a new one below and enters its editing mode
[ ] pressing escape discards the current changes, if nothing was written, the bullet point is removed

View on GitHub

After that, I added some actual tests and wrote the code needed to pass them.

👍

Finally, I updated the first test case with my expectations of what should happen if the 'Add' button is clicked twice.

I really like writing tests with the @testing-library. It gives the reader a clear picture of what to expect without going into the implementation details.

The implementation will be part of the next update.

Cover Photo by Volodymyr Hryshchenko on Unsplash

Hide RED console.error LOG WALL while testing errors with jest

Martin Emmert — Wed, 26 Aug 2020 15:34:42 +0000

While provoking errors on purpose during tests the red error logs can get really annoying and hide potential crucial information from your eyes.

Following a discussion on this issue leads to a nice solution by Kent C. Dodds.

Comment for #5267

kentcdodds commented on Jan 10, 2018

I decided to not use omitJSDOMErrors for two reasons:

The giant log I was seeing which resulted in #5227 also appears in the browser so it makes sense we see it in the JSDOM environment as well.
@domenic said: "jsdomErrors are fired for many other cases as well, besides JavaScript errors. E.g. failed CSS parsing or image loading."

Because #5227, the console JSDOM uses is the same one you have in your tests, so it's mockable now. So if you don't like the errors that are logged, you can simply do:

beforeEach(() => {
  jest.spyOn(console, 'error')
  console.error.mockImplementation(() => {})
})

afterEach(() => {
  console.error.mockRestore()
})

So I would recommend against making this change.

View on GitHub

tl;dr; A snippet to hide console.error logs during testing error messages.



beforeEach(() => {
  jest.spyOn(console, 'error')
  // @ts-ignore jest.spyOn adds this functionallity
  console.error.mockImplementation(() => null);
});

afterEach(() => {
  // @ts-ignore jest.spyOn adds this functionallity
  console.error.mockRestore()
})

Cover Photo by Markus Spiske on Unsplash

Defining the MVP

Martin Emmert — Mon, 24 Aug 2020 21:40:02 +0000

Starting a new project on Github, creating a new app with CRA, pushing your first commits, see the CI pipeline running and publishing your application feels great. Staying productive, making progress, keeping the focus after the first lines of code have been written, is also something that makes projects fun. Planning a few steps helps to achieve exactly that. Not every detail of each feature has to be laid out perfectly. Use the planning phase to draw rough sketches of what needs to be done. Go into details while being at it and do not put yourself into tight constraints upfront.

Describing the features of your app by using user stories does exactly that. It puts the focus on the what and postpones the how until the feature will be implemented.

It is often not easy to find abstract enough formulations to describe features, which are already floating around as implementation details in your head. Take your time and do not overcomplicate them. A change of the space around you (context) may be helpful, too.

The following template is often used to keep them in the same format.

As a <type of user>, I want <some goal> so that <some reason>.

To be fair; as I am sitting here, writing this post, I am also eager to get started already and skip the planning phase. But in the end, I also know that this process helps me building this application.

Some words of advice on shaping an MVP:

Do not wait until feature XY is ready, feature ABC reached a stable state and Max polished the designs for weeks.

The first impression counts and mostly it's the only chance given by most users. But if the first impression is postponed until the product is ready by your definition, you will miss out on the chance of getting valuable feedback of users that see something in your product and want to help to shape it.

I'll try to release something after each feature is implemented. Until the product is meant for production, stuff can and will break, data is lost and ideas change.

Finally, here are the user stories I'd like to implement first:

As a user, I want to write down my thoughts in a bullet list so that I can see them all in one place.

As a user, I want to organize my bullet points in a hierarchy so that I can create a meaningful order of my thoughts.

As a user, I want to freely move my bullet points within my list so that I don't have to think about any order while writing them down.

As a user, I want to delete any of my written down bullet points so that I can keep only what is meaningful to me.

You can find the user stories on the board of my Github project.

As I said earlier, I don't go into that much detail upfront and like to keep them short. As a Team, you normally would define subtasks and delimitations for each user story to split the work into smaller chunks. Doing that helps to share the work in a team.

Working solo on a project makes this an overhead, that I tend to skip ;-)

Cover Photo by Halacious on Unsplash

Readme of my endless document app experiment

Martin Emmert — Sun, 23 Aug 2020 20:26:20 +0000

Attempt to replicate the Workflowy endless document concept, extended with features I am currently missing.

My thoughts on workflowy

Overall I am really happy with what workflowy offers as a tool and I enjoy using it. I tried several of the bigger alternates to it. None of them could resemble the ease of use and often overwhelmed me with too many pointless features. Nevertheless, I miss some things, but these are mostly visual, little organizing helpers, or time savers.

There are a bunch of browser extensions that are recommended to enrich the experience with workflowy, but they don't appeal to me. Security and my privacy are the main reasons I don't want to use them. Also, it feels somewhat hackish to use them; like some of these DIY videos, where everything is done with hot glue.

What do I like using workflowy?

ease of use and limited feature set does emphasis the focus on the content
nearly everything can be used via keyboard shortcuts
it is fast, responsive and frictionless unlike its competitors
jotting down my thoughts as they come into my mind
the search is easy to use and search settings can be saved as a favorite
I am not constrained to a specific workflow and can do whatever works for me

What features am I currently missing in workflowy?

more text formatting options within a nodes description field
document structuring through headlines and sections
possibility to change the bullet icon of a node or coloring it
spacer elements to structure documents
linking to other nodes without using the title of the node automatically
automatically receiving the title of inserted links
coloring of tags
collection of used tags
grouping favorized searches in a tree structure
native extensibility

Cover Photo by Scott Graham on Unsplash

Recreating an endless document application

Martin Emmert — Sun, 23 Aug 2020 20:25:02 +0000

Writing about the stuff I do every day for more than 10 years in the tech industry, has always been something I wanted to do.

Today I created a new repository to work on an experiment and decided it was a good time to start scratching that itch of mine. I'd be happy if I can share some exciting things with you and keep you interested in following me along.

This will is an ongoing documentation of how I attempt to replicate the endless document concept of Worflowy and extend it with features I am currently missing.

Feedback is very welcome and highly appreciated.

Github Repository

martinemmert / endless-document

Replica of the Workflowy endless document concept.

Endless Document

Attempt to replicate the Workflowy endless document concept, extended with features I am currently missing.

My thoughts on workflowy

What do I like using workflowy?

ease of use and limited feature…

View on GitHub

Cover Photo by Scott Graham on Unsplash