For a working designer, a portfolio site sits in an awkward middle ground. It needs to look sharp, load instantly, and s

Kwa mbunifu anayefanya kazi, tovuti ya portfolio iko katika hali ya kati yenye changamoto. Inahitaji ionekane vizuri, ifunguke papo hapo, na ibaki ya kisasa bila kutumia saa nyingi za kazi zinazolipwa. Mpangilio wangu wa zamani ulikuwa kwenye Webflow, ambayo ilikuwa inafunga pengo kati ya wabunifu wa kuunganisha vitu kwa kuvuta na kuachia (drag-and-drop) na matokeo ya kitaalamu bora kuliko zana nyingi. Lakini ilipofika ilani ya kuhuisha na bili ya £300 kwa mwaka, ilinibidi nijiulize swali gumu: je, nilikuwa nalipia thamani, au urahisi tu?

Niliamua kujenga upya kuanzia mwanzo. Stack mpya ni Astro na Sanity. Baada ya kuitumia kwa muda, hapa kuna kile kilichofanya kazi, kile kisichofanya kazi, na jinsi inavyolingana na zana nilizotumia hapo awali.

Kwa nini Astro kwa ajili ya portfolio?

Framework nyingi za kisasa za wavuti hutuma JavaScript kwanza na kuuliza maswali baadaye. Astro inabadilisha dhana hiyo. Inatengeneza HTML ya kawaida ya static wakati wa ujenzi (build time) na hutuma JavaScript kwenye kivinjari (browser) pale tu sehemu fulani ya kiungo (component) inapohitaji. Wanaita hii "islands architecture", lakini matokeo yake kwa vitendo ni rahisi: kurasa za portfolio yangu hazina uzito wowote.

Routing inategemea faili, hivyo kutengeneza ukurasa mpya ni rahisi kama kuweka faili kwenye folda. Components hutumia sintaksi ambayo itakuwa ya kawaida ikiwa umewahi kugusa React, Vue, au Svelte. Silazimiki kutafuta mfumo mpya kila wakati ninapotaka kuongeza utafiti wa mradi (case study).

Hata hivyo, nisingetumia Astro kujenga programu ya wavuti tata. Ikiwa unaunganisha mifumo ya uhakiki (authentication), kusimamia hali ya kimataifa (global state), au kushughulikia data za wakati halisi (real-time data), utapata ugumu na framework hiyo. Lakini kwa tovuti za masoko, blogu, na portfolio, inafanya kazi bila usumbufu. Kurasa zinaonekana kuwa na kasi kwa sababu zina kasi kweli. Hakuna mzigo wa "hydration overhead" unaosubiri kutengeneza kichwa cha habari au aya.

Kutoka WordPress kwenda Sanity

Kabla ya ujenzi huu, chaguo langu la dharura lilikuwa kila mara WordPress pamoja na Advanced Custom Fields. ACF huipa WordPress uwezo mkubwa, lakini bado unakuwa unarekebisha nyumba ya mtu mwingine. Sanity inafanya kinyume chake. Unaandika schema kwenye kodi inayofafanua jinsi modeli yako ya maudhui inavyoonekana, na Sanity inajenga kiolesura cha kuhariri (editing interface) kulingana na maamuzi yako.

Nilitumia udhibiti huo kujenga "page builder" rahisi kwa kutumia "reusable blocks". Nilifafanua sehemu ya hero section mara moja. Nilifafanua testimonial carousel mara moja. Nilifafanua card grid mara moja. Sasa naweza kuunganisha kurasa mpya kwa kupanga vizuizi hivyo kwa mpangilio wowote bila kuandika kodi mpya au kugusa kiolezo cha ukurasa (page template).

Tofauti ya mtazamo ni muhimu. Katika WordPress, mara nyingi nilijihisi kama napambana na kifaa ambacho kilitaka kuwa blogu. Katika Sanity, nahisi kama ninajenga programu (software). Maudhui yanakuwa data safi iliyopangwa badala ya HTML iliyopambwa iliyochanganywa na shortcodes. Maelezo yangu ya miradi yanakuwa kama vitu vinavyohamishika (portable objects) ambavyo naweza kuviingiza kwenye programu ya simu au jarida la barua pepe (newsletter) nikipenda.

Mtiririko wa kuweka (deployment workflow) unaobaki safi

Mtiririko wangu wa zamani wa WordPress ulikuwa machafuko ya kupakia faili kwa FTP, subdomains za staging, na sasisho za plugin ambazo mara nyingi zilionekana kuharibika wakati mbaya zaidi. Nilikuwa na orodha ya mambo ya kukumbuka ili tu kurekebisha makosa madogo ya uandishi.

Mtiririko mpya ni mfupi:

• Nafanya mabadiliko ndani ya kompyuta yangu (locally) na kuyaona papo hapo.
• Nafanya commit kwenye GitHub wakati kodi inapokuwa sahihi.
• Vercel inachukua push hiyo na kuweka tovuti hewani (deploy) moja kwa moja.

Hakuna programu ya FTP. Hakuna hifadhidata ya staging ya kusawazisha (sync). Repository ndiyo chanzo cha ukweli (source of truth).

Maudhui yanafanya kazi kwa njia hiyo hiyo. Ninapochapisha au kuhuisha chapisho ndani ya Sanity, webhook inaiambia Vercel kujenga upya tovuti. Kurasa za static zinajengwa upya na maudhui mapya, na CDN inajisasisha bila mimi kugusa seva. Kila kitu kinabaki kimesawazishwa bila kunakili kwa mkono, kusasisha (exporting), au kuomba kwamba uhamishaji wa hifadhidata ya plugin (plugin database migration) ulifanya kazi kweli.

Kuunganisha usanifu na kodi kwa kutumia tokens

Moja ya mafanikio makubwa yasiyoonekana sana katika ujenzi huu ilikuwa kuweka mfumo mzuri wa tokeni. Ninatunza faili moja la JSON ambalo linamiliki kila rangi, kipimo cha maandishi (type scale), na thamani ya nafasi (spacing value) kwenye tovuti. Faili hilo ndilo bosi.

Ninatumia Token Studio kuvuta thamani hizo hizo moja kwa moja kwenye Figma. Faili langu la usanifu linaposema surface-default, linamaanisha namba ile ile inayotumiwa na kodi. Skripti ndogo inabadilisha JSON kuwa sifa maalum za CSS (CSS custom properties) wakati wa ujenzi, hivyo mitindo yangu ya CSS (stylesheets) inarejelea vigezo kama --color-surface-default badala ya hex codes zilizowekwa moja kwa moja.

Hapa ndipo inapojali katika vitendo. Ikiwa nitagundua kuwa rangi yangu nyekundu ya chapa (brand red) ni kali sana kwenye skrini za simu, ninabadilisha thamani moja kwenye faili la JSON. Maktaba ya Figma inajisasisha. CSS inajisasisha. Kila sehemu kwenye tovuti inajisasisha. Sihitaji kutumia grep