DEV Community: Jurijs Kovzels

Browsers are not designed for the next larger context.

Jurijs Kovzels — Wed, 21 Apr 2021 20:05:08 +0000

We pick pages to open based on the short search term we type into search engines, link text, sometimes page description, and your attitude to the person sharing the link. That is it, that is the entire context. And even this context is lost almost immediately. Of course, you still have your internal context, in your memory, and consciousness, but it is too fluid and fragile. We switch tasks, we leave the things unfinished. This context will not do much for you the day or two after.

World-famous architect Eliel Saarinen once said:

“Always design a thing by considering it in its next larger context — a chair in a room, a room in a house, a house in an environment, an environment in a city plan.”

Browsers are not designed this way. Search engines are not designed this way either. Browsers display the pages well. Search engines serve results for your search query reasonably well.
None of this is our true goal when we use browsers and search engines. Use them to do the research, solve a technical problem, learn something view. This is what 'larger context' is, and think we are lacking tools designed to support this context and goals.

Follow me on Twitter @ykovzel for more.

Juri out.

photo by @DTeychenne

61 Tabs and Picking What Not To Learn

Jurijs Kovzels — Tue, 20 Apr 2021 18:52:57 +0000

I use search engines a bunch because I learn a bunch. Since I learn a bunch I use what I call the "Learn, not Learn" model inspired by Dave Geddes in his post. It goes like this while looking for a solution for whatever you are doing at the moment, you encounter a bunch of options. Since it is not possible to learn and know everything, you choose what you want to know, and deliberately pick what not to learn. Learn React, not Vue. Learn Figma, not Sketch. Learn about anime, not Quantum Physics.

Dave Geddes' mind map of what not to learn. source

Then you stick to it, and in your search, you encounter things from the 'not going to learn' category - you close the tab and move to the next one. It is can be vividly illustrated with competing technologies in front-end development, and I'm sure this can be applied to multiple areas of knowledge.

My "Lean, not Learn" framework for Figma because I use Figma for everything.

At this very moment, I have 61 tabs open in the browser. Result of my investigation into GraphQL + Azure + Typescript data storage solution. All 3 are in my 'to learn' category. As a result, I've added Cosmos DB and Appolo Server to the 'learn' column and things like MongoDB, TypeGraphQL, and .Net.Core to the 'not going to learn' category.

As a result, out of 61 pages, probably a good 30% are not relevant for me because of the choices I've already made.

What if I could easily understand which tabs are relevant and which can be closed? What if the browser could know about my "Learn, not Learn" framework, and what do I have in each category?

What if I could say "This thing is nay, I do not want to read about it, please warn me if the page talks about it" before I've read half of the page?

What about the browser extension for that? 🤔

What about I build one.

Follow me on Twitter @ykovzel for more ✌

Gddamn it, persons!

Jurijs Kovzels — Wed, 24 Mar 2021 16:43:40 +0000

Will try to give some context. The thing I'm building is a browser plugin (because the browser is a new OS and you need to be where your clients already are). I expect that users might have a couple of instances running simultaneously in different tabs. Plus, updates might come from the server, as your collection can be edited by someone else.

I'm struggling to make sense of the JS zoo you people created in 6 short years while I was moving rectangles in Sketch and Figma!
When I was leaving my IDE and magnetic keyboard behind, I was thinking: "jeez, this webpack thing makes me want to lick post stamp for leaving, I'm outa here!".

And now I do not even know where to start my 'nmp', 'yarn' or yank it all together!

Library fatigue is settling in on me.

I understand the purpose of GraphQL, it's SQL for cool kids and you do not need to create a gazzilion of endpoints. Then I need to have something on the backend. I think I can get away with JSON file in azure storage and call it a day. One file per user, yank it to the client-side on first request, and then update as needed. I'm not expecting it to be huge. Later I will figure out something more sophisticated, cos I want to have a change history so that users could roll back the changes. Can I do that with GraphQL? Btw, who should deal with auth?

Then I need something to consume, as one might say, that GraphQL API. Rxdb looks promising, tick a lot of boxes, but then 'React Query' shows its face in my browser and is like 'hey kid, wanna read this 42 articles'.

How do you decide on libs, bruh?

I'm not looking for a 'batteries included' solution, that would be nice though. I can deal with some 'assembly required', but boy this is a lot!

Does anyone have a solution? People? Anyone?

Help, I need help.