I have a website

Designing with Figma

During my 5+ years as a software engineer, I have often used Figma in Dev Mode to implement designs for various websites but have never experienced designing a website from scratch. I tried my hand at it with the free tier, and I can say it is difficult work especially as someone who has no eye for design (self-proclaimed) and have little to no idea about the design process.

Of course as a frontend-leaning software engineer there are many familiar concepts (like design system, theming, design tokens, components, etc.) but I find that being quite methodical, rigid, and structural about these concepts is way more beneficial for the design phase than actually implementing them in code. There was a lot of boilerplating to be done before I could confidently start with designing pages and views—which, now that I think about it, taught me why there is a lot of research that happens in this phase of software development. Changing one small thing like a brand color is not as easy as it would be in code.

I gave it up after finishing the light and dark mode for the mobile view. I figured I can learn it more deeply another time, and I could no longer wait to have something—anything—deployed to call my own.

Developing the site with Astro

I learned and used Astro for the first time. The documentation was very helpful and I have quite an expansive experience with Next.js so I was not a stranger to SSG and SSR. Currently, the whole site is fully statically generated.

At the start, I had opted for vanilla CSS for my styling but that went south pretty quickly. I am just a tiny bit smitten by the extra tooling that Sass provides, so pretty soon after my first few deployments I changed to using Sass. I also could have opted for Tailwind, but I am more used to “speaking” in CSS and Tailwind is exactly like not writing CSS.

Along the way I learned about CUBE CSS. In many ways I had already subscribed to this methodology without knowing it had a name. It is a good mental model to have, but I find it is much harder to stick to on a team setting (esp. for larger teams) unless there are tools that can enforce rules or everyone is aligned with everything all the time (impossible). I am currently in the process of refactoring my styles to use this methodology loosely.

Shoutout to Simon Dann whose website very loosely inspired the very early-stage design of this website. And also shoutout to Henry from Online for just existing—as a reminder to myself that beautiful websites still exist. I hope one day I can create something as pretty.

AT Protocol and the Atmosphere

This might sound like a digression but I swear it’s relevant.

When I first signed up for Bluesky back when all hell broke loose on X (okay, X was already a hellsite way before that), I did not know what the Atmosphere was. I recently started becoming more active on the platform after deciding I could use it as my primary source of tech news, and pretty quickly I started seeing more and more people talk about AT Protocol.

I read more about it, what it is and what problems it was trying to solve, and I’m interested enough in the tech that I decided to dip my toes a little and publish my write-ups on the Atmosphere. At the moment, I’m sure my process is still a little janky and immature but my current system is as described:

1. I have multiple publications. Currently: Field Notes, Changelog, and Against the Dying Light
2. Each publication is a content collection in Astro.
3. Blog posts in each publication is written in either Markdown or MDX.
4. Every time I publish a new blog post, I can decide to also publish it on the Atmosphere using Standard.site lexicons via a small CLI app that I wrote myself.

The CLI app is written in Node/TypeScript and only does three things: publish a site.standard.publication, publish a site.standard.document, and update a site.standard.document. I will improve it as time goes by and as needed, but right now it is enough for my process.

I have heard of Sequoia and astro-standard-site but I wanted to create my own because I wanted to customize the process to the way I like, and it helped me learn more about AT Protocol and the Atmosphere.

I admit it was a very confusing process, sometimes I wish the documentation was a little more informative and expansive—but I’m chalking that up to the simple fact that I don’t know what I’m doing. ChatGPT helped by answering a lot of my (probably stupid) questions.

Domain and deployment with Cloudflare

Also for the first time ever, I bought a domain. It was a fairly easy and straightforward process but I did have the urge to overthink my domain. In the end I went with riyana.dev, my first name with a .dev TLD.

The site is deployed in Cloudflare Pages - perfect for static sites and also free.

Plans for the future

There is a lot to be done. My website is very bare bones as of the moment, with only a homepage and my 3 publications. Some plans that are in line:

• Publishing my Against the Dying Light blog posts to AT Proto
• Adding a /tags/[my-tag] route to list my blog posts by tag
• Adding a /bookshelf - I’m not sure how this will look like yet

And of course, the design will probably be ever-evolving because I can never be satisfied with anything that I create.