]]>The real tragedy of modern technology is that it’s turned us into consumers. Our voracious consumption of media parallels our consumption of fossil fuels, corn syrup, and plastic straws. And although we’re starting to worry about our consumption of those physical goods, we seem less concerned about our consumption of information.
We treat information as necessarily good, and comfort ourselves with the feeling that whatever article or newsletter we waste our time with is actually good for us.
After years of iA Writer I recently switched to Obsidian. But this article isn't about tools—I'll will write about that in the future. Here, I want to talk about structure. How I structure notes isn't tied to a specific piece of hard- or software and can be applied in many contexts.
First I want to establish which kind of notes I take. If your note taking habits are completely different than mine, how I structure things might not be compatible. To me, "notes" are a mix of things I'm doing, things I've done, things I want to do, things I'm writing, and things I want to remember.
Things I'm doing & things I've done. I often switch context during work. Logging my process, progress, and microdecisions help me think. This is a great tool to pick something up where I left it off later on, or when doing a retrospective of a project that ran for a few weeks. These also contain notes I take during meetings. I often scribble during meetings and clean them up while they're still fresh.
Things I want to do. I like to keep a list of ideas for projects. This helps me prioritize what to work on next. When I finish a project, I often have a list of things I came across that don't fit in the scope or got cut. Those get collected in a separate note for the next time I pick up that project.
Things I'm writing. I like to keep drafts for articles close to my notes, no need for a separate app.
Things I want to remember. Quotes I like, thoughts on things, references to fall back to… Not necessarily related to a specific project.
Inspired by PARA, I organize my notes by actionability. Notes live in one of four folders: Now, Next, Notes, or Archive.
01 Now/ Drafts/ Introducing Our New JavaScript Integration Now Next Notes Obsidian Setup … Flare JavaScript Integration Ray Docs Redesign Sidekick Redesign …02 Next/ Drafts/ How to Build a Blog With Statamic Jumpable Guard Rails Never Skip Twice … Flare Laravel Event Sourcing Snapshot Assertions Update …03 Notes/ Hiring Setting Goals Quotes The Tao of Pooh …04 Archive/ 2024-01-08 Tabular Assertions 2024-01-31 Performance Review …
Each folder is prefixed with a number so they're logically sorted in the file system.
(For those who know PARA: the main difference is that I don't differentiate between Projects and Areas, as both coexist in Now or Next. Resources are stored in Notes, and Archive remains Archive.)
Now & Next contain notes about things I've done & things I want to do. They contain notes for projects I'm actively working on. Depending on the size & status of the project, a note could be for the entire project or a specific feature.
For example, when I'm not actively working on Mailcoach I'll probably only have one Mailcoach note. When I'm involved in a specific large body of work for the project, I'll create additional notes like Mailcoach Marketing Redesign.
Another example: I have a Laravel Event Sourcing note in Next to gather ideas for the package. When I decide I want to work on a new major version of the library, I'll create a Laravel Event Sourcing Next Version note with everything I want to tackle at the moment. Ideas I don't want to work on yet might stay in Laravel Event Sourcing . After finishing the Laravel Event Sourcing Next Version project, I'll gather thoughts & ideas I didn't implement and (re-)add them to Laravel Event Sourcing.
It could also happend that another, more important, project came up and I want to shelve the next version for a while. In that case, I'll just move Laravel Event Sourcing Next Version to Next until I'm ready to pick it back up again.
At least once a week—generally on Monday—I review the Now folder and move what I'm not actively working on to Next. The goal of Now is to have an explicit view on my current responsibilities. It's important that anything in Now is actively moving. If the list is too long at a given point in time, I'm probably spread too thin and need to reprioritize to manage expectations with myself and others.
I also store writing drafts in Now/Drafts and Next/Drafts. If I haven't touched a draft from Now/Drafts for a week or two, I'll move it to Next/Drafts until inspiration strikes again.
When a project is completed or becomes irrelevant, I prefix the note with the date it was completed and move it to the Archive folder, for example 2024-02-12 Laravel Event Sourcing Next Version . Writing drafts often get deleted instead of archived, as they're published elsewhere I don't need to hoard them in my note taking tool for future reference.
Notes contain notes about things I want to remember. Notes are more about general topics instead of projects. In theory, notes never move to archives, they're a knowledge base that grow over time. An example file in Notes is Quotes, where I keep a list of quotes I like.
That's pretty much all there's too it. The goal is to spend most of the time in Now, occasionally review Next, and dive into Notes and Archive when needed.
In future posts, I'll share how I structure the contents of a project note, and how I specifically use Obsidian.
]]>SQLSTATE[HY000] [2054] The server requested authentication method unknown to the client
It took some googling to find a solution that worked. Most solutions recommended changing the authentication method in MySQL, but this was already configured correctly for me. What I had to do was explicitly configure a socket for MySQL to connect with. I added the following to my .env
file:
DB_SOCKET=/tmp/mysql_3307.sock
Replace 3307
with the port number you configured your MySQL server to run on.
To repeat the words of Chris Coyier again:
Redesigning your personal website is one of life’s great pleasures.
↗ ped.ro
]]>Blogrolls are great. I have one too! But I don't think they're enough. The visibility of a blogroll is limited to people that visit your blog and are curious enough to poke around. The content of a blogroll is limited to blogs you consistently follow, but individual posts are worth sharing too.
Lots of blogs do this: Chris Coyier occasionally shares links his thoughts intertwined, Freek's blog is a mix of original articles and links, and I've come across a lot of unexpectedly interesting articles through larger blogs like Daring Fireball or Kottke. Some have a separate RSS feed for sharing content, like Jim Nielsen's notes.
In the same edition of Own Your Web, Matthias shared a link to an article titled Curation is the last best hope of intelligent discourse . Joan Westenberg argues that with the rise of AI and algorithms, human curation is more important than ever.
Human curators can distinguish between nuanced arguments, recognise cultural subtleties, and evaluate the credibility of sources in ways that algorithms cannot. This human touch is essential for maintaining the integrity of our information ecosystem. It serves not only as a filter for quality but also as a signal for meaningful and trustworthy content amidst the overwhelming noise generated by AI systems.
Aside from its importance, an algorithm is not going to surprise you. I could listen to Spotify's Discover Weekly recommendations all day, but my taste wouldn't widen.
So, go forth and multiply content! Share what you find interesting, start a conversation, surprise your readers, and let the small web flourish!
]]>Here's the good news: these days you can't really go wrong with any of the major frameworks—at least from a technical perspective. React, Vue, Svelte, Angular… all have incredible teams, contributors & ecosystems backing them. Your frontend framework will not be the limiting factor of your architecture.
Choose a framework based on the non-technical needs of your team. If scaling up your team is important, React might make more sense because of its popularity on the job market. On the other hand, if your team hates the mental model of React, don't feel pressured to use it regardless of its popularity. Choose your framework based on how it aligns with your team's programming values, not performance needs. (Unless you're building a Bloomberg terminal.)
My preference these days: I'm split between React & Svelte. (That is, when I'm working on a project I deem worthy of a JavaScript-heavy interface, for others I still prefer vanilla JS or Alpine.) I like them both because they each have a distinct direction. React is as JavaScript as a JavaScript framework can be, while Svelte stays as close to HTML & the DOM as possible. What they have in common is they've chosen a slice of the stack, and double down on enhancing it. I prefer tools with distinct directions.
]]>]]>We separate “I’m working” and “I’m playing.” We want to make everything extremely efficient, so we opt for going for a run alone instead of trying to link up with people along the way. We need to “be productive” so we don’t work from a coffee shop with friends.
$ composer require mockery/mockerymockery/mockery is currently present in the require-dev key and you ran the command without the --dev flag, which will move it to the require key.Do you want to move this requirement? [no]?
How cool! I didn't know you could hint Composer to suggest a dependency to be installed as a testing dependency.
After further inspection, Composer determines this based on the tags used for the package
If you add dev
, testing
, or static analysis
keywords to your package's composer.json
, Composer will prompt users to install it as a dev dependency.
{ "name": "spatie/tabular-assertions", "keywords": ["testing"]}
]]>
:has
selector in CSS yet, but this example from Chris Coyier piqued my interest.
With this query, you can dynamically filter a list with pure CSS!
body:has([name="filter"][value="bakery"]:checked) .card:not([data-category="bakery"]) { display: none;}
]]>