Кіраванне задачамі праз час, энергію і ўвагу
#прадуктыўнасць #дзевынік

Я даволі доўгі час карыстаюся праграмай Things для вядзення сваіх асабістых спісаў задач. І што мне падабаецца ў ёй, дык гэта тое, што аўтары праграмы не сталі заганяць карыстальнікаў у нейкія межы, прымушаючы карыстацца праграмай пэўным спосабам.

Але часам такая свабода мае і адваротны бок, асабліва, калі распрацоўшчыкі не даюць ніякіх рэкамендацый, як карыстацца той ці іншай функцыяй. І для мяне такой функцыя аказаліся тэгі, якія можна дадаваць да любой задачы праекта, ці ўвогуле цэлай катэгорыі.

Я спрабаваў розныя падыходы адносна арганізацыі тэгаў, чытаў прыклады іншых людзей. Нехта ствараў сістэму падобную да кантэкстаў GTD Алена, нехта рабіў кола балансу праз тэгі (і я спрабаваў), але мне ўсё гэта не падыходзіла, пакуль цягам працяглых эксперыментаў не прыйшоў да сваёй сістэмы, якая не перашкаджае і дапамагае. Давайце пра яе і распавяду.

Мая сістэма складаецца з трох асноўных вектараў: час, энергія і ўвага. Па кожнаму з вектараў ёсць градацыя, дзе звычайна не больш за тры ўзроўні, але можна і больш, калі нехта мае патрэбу.

⏰ Час — тое, колькі задача патрабуе фізічна часу для яе выканання. Яна мае тры ступені, дзе максімальная з іх - палова дня. Для большай візуалізацыі я карыстаюся emoji з памідорамі.

🍅 – 30m – простая задача, на якую хапае аднаго "памідора" (25 хвілін працы з перапынкам на 5 хвілін)
🍅🍅 – 2h – больш складаная задача, калі патрэбна напісаць нейкі кавалак кода ці артыкул, напрыклад.
🍅🍅🍅 – ½d – задача, што зойме дакладна палову дня, напрыклад паехаць недзе і вырашыць нейкія пытанні.

Калі задача патрабуе больш часу, чым палова дня, яна павінна быць разбіта на больш малыя, каб імі можна было кіраваць.

🔋 Энергія — гэты вектар вызначае, колькі на задачу патрабуецца эмацыянальнай энергіі. Вызначыць дакладны ўзровень энергіі складана, таму што няма нейкага паказчыка, па якім можна яго вымераць, гэта хутчэй нейкія асабістыя пачуцці. Таму і ўзроўні даволі простыя: 🟢 – лёгка, 🟡 – сярэдне і 🔴 – складана.

Складана не ў сэнсе, што патрабуе шмат часу, а эмацыянальна складана. Прымусіць сябе напісаць артыкул можна быць значна складаней, чым выправіць памылку ў кодзе, які нядаўна пісаў.

🚨 Увага — вектар, які паказвае, якія задачы патрабуюць максімальнай канцэнтрацыі ці падвышанай увагі, калі іх выконваеш. Напрыклад, нейкія фінансавыя задачы, як то разлічыць падаткі, патрабуюць больш увагі. Тэгамі з гэтага вектара можна пазначаць і прыярытэт, то бок пазначыць задачы, які больш важныя. Я выкарыстоўваю ўсяго два варыянты: ❗️і ‼️.

Адзначу, што не ўсе абсалютна задачы я пазначаю тэгамі, але калі плануеш нейкі праект, то такія адзнакі могуць быць карыснымі, каб потым мець магчымасць выбраць тыя задачы, якія пасуюць асабістаму стану. Напрыклад, калі ёсць час, ніхто не перашкаджае, выспаўся і табе хапае энергіі - можна парабіць складаныя задачы, а ў іншы час выбраць іншыя, больш простыя.

Стаў 🔥 калі спадабаўся артыкул!

P.S. Я пачаў перакладаць дакументацыю NestJS на беларускую мову і буду вельмі ўдзячны за падтрымку.
https://www.buymeacoffee.com/ikbytech/w/38188

Метад PARA, Jamstack і тэхнічны разбор, ці анонс на бягучы тыдзень
#анонс #расклад

Вітаю, сябры! 🙋

Рассылка выйдзе наступным панядзелкам, таму сёння хачу падзяліцца з вамі анонсам допісаў, якія я запланаваў на гэты тыдзень. Калі яшчэ не падпісаліся на канал, то самы час, каб не прапусціць. Назвы магчыма падкарэктуюцца, але без змены сэнсу.

— Як як прыйшоў да выкарыстання метада PARA
— Што такое Jamstack і навошта генерыраваць сайты
— Як зроблены і працуе сайт pravilna.by

Дарэчы, учора атрымалася знайці трошкі часу і папрасіць дзяцей не шумець (складанасць узроўня Бог), каб запісаць прывітальнае відэа для YouTube-канала і іншых старонак.

Запрашаю паглядзець і падпісацца на канал, планую дзяліцца ведамі і досведам і ў відэа-фармаце.

https://www.youtube.com/watch?v=pmFD57YI1cc

Метад PARA і мой спосаб яго выкарыстання
#прадукцыйнасць #para

🙋‍♂️ Сябры, я паступова іду да мэты – 💯падпісчыкаў да канца студзеня. Я буду вельмі ўдзячны, калі вы падзеліцеся допісам з сябрамі, а так сама падтрымаеце падпіскай мой Twitter, там да першай сотні засталося ўсяго 4 чалавекі.

💡Калі я набыў праграму Things, я пачаў выбудоўваць сваю сістэму вядзення ўласных праектаў, каб неяк апраўдаць патрачаныя грошы. Я спрабаваў розныя падыходы, але зручней не станавілася. Я некалькі разоў спрабаваў гэта неяк упарадкаваць. У мяне нават доўгі час вісела задача "Навесці парадак у Things". 🙄

Адзін з падыходаў пратрымаўся пэўны час. Ён будаваўся на так званых кантэкстах, тых галінах майго жыцця, дзе я намагаўся нешта зрабіць. Нешта падобнае на кола балансу, дзе праекты з задачамі былі размеркаваны адпаведна галінам жыцця.

Такую структуру было цяжка падтрымліваць, таму што жыццё штука дынамічная, і прыярытэт можа змяняцца з часам, а тасаваць праекты кожны раз было складана. Таму я намагаўся спрасціць сістэму, каб яна дапамагала і патрабавала мінімум часу на абслугоўванне.

І пачаў я з доўгатэрміновых спраў, якімі я планую займацца бліжэйшым часам. У выніку ў мяне атрымаўся наступны спіс. Пра кожную з іх падрабязней я распавяду іншым разам.

👨‍💼 Alroniks Tech / Бізнэс
🎙 Іван Клімчук / Пра тэхналогіі
🔊 Ivan Klimchuk / Engineering
👨‍🎓 Вучоба і развіццё
🔬 Праекты і хобі
✍️ Стварэнне кантэнту
🏚 Дамаводства
👨‍💻 Open Source

Пераломным момантам для мяне аказалася думка, што калі рабіць праект "Іван Клімчук / Пра тэхналогіі" – гэта напэўна надоўга. Спачатку гэта быў звычайны праект, але калі я пачаў апісваць задачы для яго, стала зразумела, што мае сэнс разбіваць іх на асобныя праекты, у якіх ёсць пачатак і канец, адчувальны вынік. Бо прасцей скончыць нешта накшталт "Зрабіць курс па Git і GitHub з шасці ўрокаў", чым проста мець адну вялікую задачу расказваць пра тэхналогіі.

🤯 Ужо пасля таго, як я зрабіў такую структуру, я даведаўся пра метад PARA. Калі зусім коратка, то метад складаецца з чатырох галоўных аспектаў, па першых літарах якіх і названы. Гэта праекты, вобласці, рэсурсы і архіў. Праекты - гэта тэрміновыя праекты, дзе відавочны фініш, вобласці - доўгатэрміновыя заняткі, якімі вы плануеце займацца пэўны час, рэсурсы - усё, што можа быць карысным для працы над праектамі, архіў - усё, што больш не патрэбна з першых трох аспектаў.

Атрымалася, што ў праграме Things так сама ёсць вобласці і праекты і мая зробленая структура ідэальна падышла да першай часткі метаду PARA. Але што рабіць з архівам і рэсурсамі? Калі казаць пра праекты і задачы, то пасля завяршэння яны трапляюць у спецыяльны раздзел у Things – Logbook, дзе зручна адсочваць свой прагрэс па таму, што і калі было выканана. З рэсурсамі ж справа іншая. Рэсурсы я захоўваю ў асобнай праграме - Notion, пра якую так сама распавяду наступным разам.

👆Метад PARA насамрэч даволі ўніверсальны, таму што дазваляе выбудаваць сістэму без прывязкі да нейкіх пэўных праграм ці сервісаў. Вы можаце зрабіць карыстацца падыходам, проста расклаўшы тэкставыя файлы па адпаведных папках, ці нават раскладаць папяровыя нататкі па скрынях, калі зусім рабіць няма чаго. Рэкамендую азнаёміцца з ім падрабязней і паспрабаваць яго на практыцы.

Jamstack, ці навошта генерыраваць сайты
#канцэпт #сайты #web #cms

Калі заходзіць гаворка пра сайты, упэўнены, многія адразу ўспамінаюць пра дамен, хостынг і базу даных. Дамен, зразумела, патрэбны кожнаму сайту. А вось з хостынгам і базай даных могуць быць варыянты.

Складаным функцыянальным сайтам без іх не абысціся, але для блогаў, сайтаў з дакументацыяй і іншых, дзе няма вялікага ўзаемадзеяння, есць больш зручны варыянт. І што важна, амаль бясплатны.

Звычайна сайт працуе праз web-server і генерыруе змест старонкі кожны раз, калі яе запатрабаваў карыстальнік. Гэта патрабуе, каб праграма для апрацоўкі такіх запытаў працавала на серверы бесперапынна, што каштуе грошай. І ў свой час стваральнікі сервісу Netlify прыдумалі (але не яны першыя) іншы падыход і назвалі яго Jamstack.

🧐 Што такое Jamstack?

Назва – базворд, створаны ад першых літар тэхналогій, якія былі пакладзены ў аснову. “JAM Stack”, то бок JavaScript, API & Markup. Вось як тлумачыць назву сам аўтар:

“Сучасная архітэктура веб-распрацоўкі, заснаваная на кліенцкім JavaScript, паўторна выкарыстоўваемых API і загадзя створанай разметцы.” — Mathias Biilmann (CEO & Co-founder of Netlify)

Для блога базай даных можа быць набор файлаў з нататкамі, якія неабходна неяк упрыгожыць з дапамогай HTML і CSS. Па сутнасці Jamstack – гэта архітэктурны падыход, які аддзяляе ўзровень узаемадзеяння ад даных і афармлення. Але як гэта працуе на практыцы?

⚙️ Генерацыя сайтаў

Па сутнасці, спецыяльная праграма, генератар, збірае даныя з файлаў, выкарыстоўваючы тэму (набор HTML-шаблонаў і стыляў CSS), генерыруе старонкі будучага сайта і па пэўных правілах раскладвае іх у патрэбным парадку. Потым гэтыя гатовыя файлы старонак можна запампаваць на любы файлавы хостынг, напрыклад GitHub Pages, наладзіць туды доступ па спасылцы і сайт гатовы. У большасці выпадкаў гэта бясплатна!

Але Jamstack не абмежаваны толькі статычнымі старонкамі, яго архітэктура дазваляе выкарыстоўваць API з дадзенымі, каб некаторыя старонкі рабіць дынамічнымі і мець магчымасць рэагаваць на запыты карыстальніка. З гэтым дапамагаюць так званыя “безгаловыя” сістэмы кіравання зместам, больш падрабязна пра якія пагаворым наступным разам.

✅ Перавагі архітэктуры Jamstack

З-за таго, што вынікам генерацыі з’яўляюцца проста старонкі HTML, сайт не ўразлівы да хакерскіх атак. Рызыка з’яўлення памылак так сама мінімальная, таму што калі аўтаматычная генерацыя не спрацавалла, памылковая версія да хостынгу проста не дабярэцца. У адрозненне ад “жывых” сайтаў, дзе змены бачны амаль адразу.

Так сама простыя старонкі ў выглядзе файлаў вельмі хутка загружаюцца, таму што гэта не патрабуе дадатковых рэсурсаў на апрацоўку запытаў карыстальнікаў, ці чаканне адказу ад базы даных.

Больш падрабязна даведацца пра Jamstack можна на афіцыйным сайце, а каб не прапусціць допісы пра генератары сайтаў і “безгаловыя” CMS, падпішыся на канал!

Стаў 🔥 калі спадабаўся допіс!

Працяг пра Jamstack, падыход Zero Inbox, і рознае іншае
#анонс #расклад #рассылка

Вітаю, сябры!

З панядзелкам вас, калі не закідаеце памідорамі 🍅 :)

ℹ️ На гэтым тыдні працягну вас знаёміць з тэмай Jamstack. Планую распавесці больш падрабязна пра генератары сайтаў, расказаць, якія ёсць, якія самыя папулярныя, і што я абраў для сваіх праектаў. Так сама распавяду пра так званыя “безгаловыя” сістэмы кіравання зместам, якія можна выкарыстоўваць разам з генератарамі сайтаў. Пазней, калі асноўныя паняцці будуць растлумачаны, нарэшце распавяду пра тое, як зроблены сайт з правіламі беларускай мовы.

🔬 Дарэчы, на выхадных як раз эксперыментаваў з даволі вядомым рухавіком для блогаў – Ghost, які атрымалася запусціць праз Google Cloud Run, выкарыстоўваючы бясплатную базу даных і бясплатны хостынг ад Netlify. Ведаў назбіралася столькі, што адным артыкулам такое не апісаць. Больш падобна на сапраўдны міні курс, якім я займуся бліжэйшым часам.

📥 А заўтра, у прадукцыйны аўторак, чакайце допіс пра падыход Zero Inbox, да якога я доўга ішоў, але нарэшце прыйшоў і атрымліваю значныя выгады ад яго выкарыстання.

🗞️ З-за пэўных праблем сямейнага характару выпуск рассылкі давялося адкласці на заўтра. Там я паразважаў пра тое, навошта раздзяляць свае акаунты паводле сваіх віртуальных асоб. Таму каб не прапусціць выпуск, раю падпісацца на рассылку па спасылцы ніжэй.

https://ikbytech.substack.com/?showWelcome=true

📨 Zero Inbox і чаму ён важны

#прадукцыйнасць #zeroinbox #аўторак

Вітаю! 👋

Прадукцыйны аўторак і самы час пагаварыць пра электронную пошту, якая настолькі старая з’ява, што ўспрымаецца ўжо як электрычнасць ці інтэрнэт, але ў той жа час можа даволі моцна ўплываць на эфектыўнасць працы.

Бесперапынны паток лістоў з важнымі пытаннямі, паведамленні, лічбы не прачытаных лістоў – гэта ўсё тое, што прыцягвае ўвагу і адрывае ад сапраўднай працы, што робіць такую працу вельмі неэфектыўнай. І з гэтым патрэбна змагацца, на маю думку.

У пачатку 2000-х гадоў Мэрлін Мэн прапанаваў канцэпцыю Zero Inbox, якая яму дазволіла больш эфектыўна карыстацца электроннай поштай, паменшыць стрэс і павысіць агульную прадукцыйнасць. Але за кошт чаго? Давайце разбірацца.

📥 Zero Inbox – гэта падыход, які заклікае падтрымліваць сваю скрыню з уваходнай поштай поўнасцю ачышчанай. Гэта працуе не толькі з поштай, дарэчы. Дасягненню ж такога стану дапамагаюць даволі простыя прынцыпы.

1️⃣ Абавязковая апрацоўка – усе лісты апрацоўваюцца і па кожнаму павінна быць рашэнне, што рабіць далей. Можна стварыць задачу, ці сустрэчу праз каляндар, калі магчыма, ці даць просты непасрэдны адказ на ліст. Або выдаліць.

Ліст павінен знікнуць з уваходнай скрыні пасля апрацоўкі

2️⃣ Сістэма катэгорый – каб было зручней знаходзіць неабходную інфармацыю пазней, мае сэнс пазначаць важныя лісты адмысловымі тэгамі ці размеркаваць іх па катэгорыях.

3️⃣ Рэгулярная чыстка – неабходна час ад часу праглядаць крыніцы, адкуль дасылаюцца лісты і выдаляць непатрэбныя падпіскі і паведамленні.

4️⃣ Лімітаванне часу – на працу з поштай патрэбна адводзіць пэўны час і па магчымасці зменшыць магутнасць патоку ўваходнай пошты, пакінуць толькі самае важнае.

5️⃣ Аўтаматызацыя – некаторыя лісты, дзе не патрэбны адмысловы асабісты адказ, можна адразу пазначаць тэгамі і складаць у папкі, эканомячы ўласны час на апрацоўку.

Прынцыпы даволі простыя і калі іх прытрымлівацца і завесці сабе звычку мець скрыню заўсёды пустой, гэта вельмі значна можа паўплываць на вашую эфектыўнасць. Вось некаторыя выгады, якія можа даць выкарыстанне падыходу Zero Inbox:

🚀 Павышэнне прадукцыйнасці – калі важныя лісты размеркаваны па тэгах ці папках, гэта змяншае час, неабходны на пошук важных лістоў сярод непатрэбнай карэспандэнцыі.

😨 Зніжэнне стрэсу – перапоўненая пошта падтрымлівае высокі ўзровень трывогі, асабліва калі вы ведаеце, што ў вас ёсць не прачытаныя лісты, якія могуць мець важнае значэнне.

🤯 Паляпшэнне фокуса – без пастаянных паведамленняў аб новых лістах лягчэй сфакусіравацца на бягучых задачах.

🔢 Удасканаленне прыярытэтаў – рэгулярная практыка Zero Inbox дапамагае з вызначэннем значнасці і неабходнасці лістоў і вучыць прымаць правільная рашэнні.

Я карыстаюся падыходам ужо не адзін год і не ўяўляю, як можна працаваць з поштай па іншаму. Спадзяюся, што вы так сама паспрабуеце і знойдзеце падыход карысным для сябе, у першую чаргу. Пачаць жа я раю з выдалення ўсіх падпісак і паведамленняў ад розных сервісаў, бо для мяне гэта быў самы складаны і доўгі этап, таму што падпісак было вельмі шмат.

Стаў 🔥 калі спадабалася і пакажы сябрам!

Генератары статычных сайтаў
#канцэпт #паняцце #інструменты

Вітанкі! ☀️

Працягваем размову пра генератары статычных сайтаў. Без такіх генератараў прымяніць падыход Jamstack увогуле б не атрымалася. Менавіта таму такіх генератараў на сёння створана даволі шмат. На сайце сабрана калекцыя з 355 🤯 розных генератараў, на розных мовах праграмавання, што ўражвае. Амаль палова напісаны на JavaScript – 132 штукі. Адным словам, выбар на любы густ!

Што такое генератар статычных сайтаў

Гэта інструмент, які можна запускаць як частку зборкі для пераўтварэння кантэнту, даных і шаблонаў у файлы, якія можна разгарнуць на хостынгу ў якасці гатовага да абслугоўвання сайта. Галоўнае адрозненне ад звычайных сайтаў, дзе старонка запрашваецца і будуецца на кожны запыт да яе, тое, што генератары будуць такія старонкі загадзя, падчас зборкі.

Працэс можна параўнаць з кампіляцыяй праграмы, калі з коду праграмы ствараецца файл, які можна запусціць і ён выканае пэўную аперацыю. З дапамогай аўтаматызацыі зборкі сайта, падобна праграме, можна наладзіць аўтаматычную публікацыю сайта. Такім чынам праце хостынг Netlify, GitHub Pages і многія іншыя.

Як правільна выбраць генератар

Калі глядзець па колькасці зорак, то можа скласціся ўражанне, што самы папулярны – Next.js, але ўсё трошкі не так. Справа ў тым, што Next.js, як і Nuxt, VuePress ці SvelteKit папулярныя дзякуючы таму, што гэта вялізныя фрэймворкі, якія апроч іншага могуць і сайт генерыраваць. Рэсурсаў патрабуюць адпаведна больш.

Калі ж казаць пра сапраўдную папулярнасць і зручнасць выкарыстання, то ў мяне свой, больш справядлівы, на маю думку, рэйтынг:

📼 Jekyll — самы сталы і папулярны генератар, напісаны на Ruby і які быў адным з першых інструментаў для генерацыі падобных сайтаў. Быў створаны Томасам Прэстан-Вернерам і выкарыстоўваецца GitHub для генерацыі старонак для GitHub Pages і зараз.

🚀 Hugo — самы хуткі генератар сайтаў, напісаны на Go, да таго ж мае даволі вялікую калекцыю тэм афармлення, падтрымлівае сайты на розных мовах і многа чаго іншага. Але хуткасць – супер-здольнасць, для вялікіх сайтаў лепш нічога няма.

🛞 Eleventy — самы просты генератар сайтаў. Напісаны на JavaScript, мінімальны наколькі гэта магчыма, з-за таго так сама вельмі хуткі. Калі не шмат плагінаў выкарыстоўваецца, то прыблізна як Go. Тэм прыгожых мала, яго любяць збольшага праграмісты, якія робяць сайты з дакументацыяй ці не вельмі складаныя старонкі.

🎨 Gatsby — самы зручны генератар для тых, хто любіць React, бо менавіта гэтая бібліятэка там узятая за базу. Я не карыстаўся асабіста, але генератара даволі папулярны і многія інтэграцыі прапануюць шмат гатовага. Тэм так сама даволі шмат.

Персанальна для сябе я абраў у свой час Hugo, як самы хуткі з усіх, таму што ён напісаны на Go. З дапамогай яго я збіраю свае сайты і блогі, pravilna.by так сама зроблены з дапамогай яго. Магчыма генератары на Rust ці C++ будуць настолькі ж хуткімі, але яны не маюць усяго таго, што было зроблена ў Hugo.

І другім варыянтам для простых сайтаў, дзе не патрэбна нешта выдумляць з дызайнам, я абраў 11ty, як самы просты генератар без неабходнасці нешта дадаткова наладжваць у самым пачатку, а проста браць і карыстацца.

Вы для сябе можаце выбраць той, які вам больш да спадобы, які лепш пасуе да вашых задач, ці нават проста напісаны на той мове праграмавання, якую вы лепш ведаеце.

Напісанне артыкулаў займае шмат увагі і часу, таму я буду вельмі ўдзячны за вашую падтрымку ў выглядзе рэакцый 🚀🔥 ці ❤️‍🔥, рэпостаў ці нават кубачка кавы.

Што рабіць і як быць? 🤯
#апытанка

Сябры, надышоў час для важнага пытання. Тэмы, якія я намагаюся асвятляць для вас, не заўсёды атрымліваецца запісваць коратка. У цяперашні век чытаць доўгія допісы можа быць лянота. Разбіваць жа на часткі так сама не вельмі зручна, бо тады губляецца кантэкст.

Таму хачу спытаць, а што ж рабіць? Ці пакінуць фармат допісаў як ёсць, каб іх можна было адразу прачытаць праз Тэлеграм, ці пачаць рабіць допісы ў выглядзе ўводнай часткі і даваць спасылку на поўную версію на сайце?

Абярыце, калі ласка, варыянт, які вам больш пасуе.

Безгаловыя CMS для сайтаў (Headless CMS)
#канцэпт #паняцце #інструменты #cms #headless

Вітаю! Працягваем знаёмства з Jamstack і сёння пагаворым пра так званыя безгаловыя сістэмы кіравання зместам. Паглядзім, якія сістэмы і сэрвісы існуюць і якія магчымасці яны даюць.

У англійскай мове headless адносна рэчаў азначае, што рэч як бы не мае твару, ці правільней казаць – інтэрфейсу, нейкай візуальнай часткі. У той жа час, сістэма кіравання зместам (у нашым выпадку) спраўна працуе і выконвае свае задачы.

Такія сістэмы замест адлюстравання візуальнага зместу наўпрост (як WordPress, напрыклад), аддаюць даныя ў спецыяльным фармаце. Такія даныя потым можна неяк выкарыстаць з дапамогай іншай праграмы – генератара статычных сайтаў.

Генератары статычных сайтаў штука даволі тэхнічная і можа быць складана растлумачыць, як імі карыстацца людзям, якія будуць пісаць для сайтаў тэксты. І вось тут спалучэнне безгаловых CMS і генератараў сайтаў дае амаль неабмежаваныя магчымасці. Людзі карыстаюцца зручным інтэрфейсам для стварэння зместу, а як гэта адлюстраваць і даставіць да карыстальніка – займаюцца тэхнічныя спецыялісты.

Такім чынам, можна стварыць сваю структуру даных у такой сістэме, наладзіць аўтаматычную генерацыю сайта з дапамогай генератара сайта, пакласці гатовы сайт на хостынг і забыць на яго, бо гэта толькі файлы, а CMS карыстацца толькі калі яна патрэбна.

На сайце Jamstack сабрана 119 розных сістэм кіравання зместам, можна выбраць на любы густ і адпаведна патрэбам, але адзначу, што не ўсе з іх бясплатныя. Яшчэ важна разабрацца, якім чынам яны працуюць, таму што не кожная такая сістэма сумяшчальна з усімі генератарамі сайтаў.

Бываюць API-based і Git-based. API-based сістэмы аддаюць змест праз API-інтэрфейс, што даволі зручна, але патрабуе некаторай працы праграміста, каб гэтыя даныя спачатку атрымаць, а потым пераўтварыць у той від, які патрабуецца.

Git-based сістэмы працуюць наўпрост з файламі, а змест захоўваюць праз сістэму кантролю версій Git. Такі метад часам прасцей, але патрабуе завесці профіль на GitHub і стварыць там адмысловы рэпазіторый, месца, дзе гэтыя файлы будуць захоўвацца. Генератар Hugo, напрыклад, умее працаваць толькі з файламі.

Самая папулярныя з git-based, гэта Decap CMS (былая Netlify CMS), а з API-based – Strapi і бадай Ghost, хаця да абодвух ёсць пытанні адносна іх сумяшчальнасці з Jamstack, пра што я распавяду наступным разам. З платных можна адзначыць CloudCannon, Contentfull і Dato CMS.

З мінусаў такіх сістэм я б адзначыў той факт, што структуру зместу патрэбна распрацоўваць амаль з нуля, што можа быць складана на першы погляд. У некаторых выпадках такія налады робяцца праз спецыяльныя файлы, што вымагае дадатковага вывучэння. Але такую цану даводзіцца плаціць за неабмежаваную гнуткасць падыходу.

❤️‍🔥 – калі было цікава, ⚡️ – калі працягваць тэму #jamstack і генерацыі сайтаў.

P.S. Я зараз рыхтую некалькі выпускаў у відэа-фармаце для YouTube, таму прашу вас загадзя падпісацца на мой YouTube-канал, каб не прапусціць іх выхад.

Сайт з правіламі, магія лічбы 6174, Focused Week падыход
#анонс #расклад

Вітаю! Спадзяюся, у вас атрымалася адпачыць і вы гатовыя да новага працоўнага тыдня. Асабіста я не вельмі, але такі шлях!

Вырашыў не марнаваць час і публікаваць анонсы ў той дзень, калі я планую наступны тыдзень, то бок сёння, у нядзелю. І план на наступны тыдзень выглядае даволі цікавым, як па мне.

На гэтым тыдні нарэшце распавяду вам, як зроблены сайт з правіламі – pravilna.by і што я планую рабіць з ім далей. У аўторак зноў пагаворым пра прадукцыйнасць і я раскажу пра цікавы падыход мэтанакіраваных тыдняў, які я падгледзеў у інды-хакераў (пра іх раблю відэа для свайго YouTube-канала, дарэчы). Ну і раскажу, дзе можна ўзяць бясплатную базу даных для выкарыстання ў сваіх уласных праектах. А пачнем заўтра з цікавай лічбы 6174.

P.S. Хачу паспрабаваць пісаць пра нешта асабістае, свае нейкія хоббі ці захапленні, каб канал і блог не гублялі чалавечнасці. Таму на суботу планую допіс з рубрыкі "нефармат", дзе хачу распавесці пра тое, што такое брэветы, чаму яны мяне зачапілі і як я праехаў свой першы – на 200 кіламетраў. Пастаўце агеньчык 🔥, калі рубрыка #нефармат вам цікавая, каб я разумеў, ці мае сэнс яе развіваць.

Містычная матэматыка, ці магічны лік 6174
#цікава #факт #матэматыка

На маю думку, адной з абавязковых рыс паспяховых людзей, не толькі праграмістаў, з’яўляецца #дапытлівасць. Няспыннае жаданне дакапацца да праўды і вывудзіць нават самую маленькую кропельку інфармацыі з любой даступнай крыніцы.

На прошлым тыдні, чытаючы ліст рассылкі аднаго з ангельскамоўных інжынераў, натрапіў на цікавую спасылку пра лік 6174. На Вікіпедыі перакладу на беларускую мову няма, таму я вырашыў падзяліцца з вамі гэтым цікавым фактам тут.

Лік 6174 – натуральны лік, на першы погляд нічым не адметны, пакуль не пачаць яго вывучаць. Лік вядомы пад назвай пастаяннай Капрэкара, па імені вынаходцы – індыйскага матэматыка D. R. Kaprekar.

Лік 6174 вядомы цікавымі асаблівасцямі, калі выканаць наступныя крокі:

⓵ Вазьміце чатырохзначны лік, выкарыстоўваючы як мінімум дзве розныя лічбы (пачатковыя нулі дазваляюцца)
⓶ Расстаўце лічбы ў парадку змяншэння, а потым у парадку ўзрастання, каб атрымаць два чатырохзначныя лікі
⓷ Адніміце меншы лік ад большага
⓸ Вярніцеся на пункт 2 і паўтарыце

У выніку вы заўсёдны дацягнеце ліку 6174 не болей чым за 7 паўтораў. Гэты працэс вядомы, як аперацыя Капрэкара (у гонар таго ж матэматыка). Напрыклад для 1410 (год Грунвальдскай бітвы) працэс будзе выглядаць так:

4110 - 0114 = 3996
9963 - 3699 = 6264
6642 - 2466 = 4176
7641 - 1467 = 6174
7641 - 1467 = 6174

Для трохзначных лікаў аналаг пастаяннай Капрэкара – лік 495. Для любога трохзначнага ліку без паўтораў лічбаў патрабуецца не болей шасці ітэрацый. Для лікаў больш за 4 лічбы пераўтварэнне Капрэкара ў большасці выпадкаў рана ці позна прыводзіць да цыклічных паўтораў лікаў.

Існуе толькі два шасцізначныя лікі, якія з'яўляюцца нерухомымі кропкамі пераўтварэння Капрэкара (549945 і 631764). Для двух-, пяці- і сямізначных лікаў нерухомых кропак пераўтварэння Капрэкара не існуе.

Калі вам хтосці скажа, што магіі не існуе, смела адпраўляйце гэтага чалавека да матэматыкі. А я вас адпраўляю паставіць 👍 і падзяліцца з сябрам!

Мэтанакіраваны тыдзень, або focused week

Час ад часу я збіраю цікавыя падыходы, якія людзі прыдумваюць, каб неяк справіцца са стосам сваіх спраў. Звычайна гэта называецца #прадукцыйнасць, але па выніках усё зводзіцца да спроб зрабіць жыццё лепшым і лягчэйшым. На жаль, срэбнай кулі не існуе.

Калі ведаеш што і як рабіць, то пачаць даволі лёгка і ўсё цудоўна атрымліваецца. Вы і самі ведаеце. Каб такога дасягнуць, патрэбна ўмець планаваць загадзя. Аднак, куды важней ведаць і трываць у галаве галоўную мэту і ўмець на ёй сканцэнтравацца падчас працы.

Падыход з мэтанакіраваным тыднем на самой справе шмат хто апісвае ў кніжках, толькі называюць яго па рознаму, ці ўвогуле выкарыстоўваюць яго як частку нейкай іншай ідэі. Я ж хачу прывесці два прыклады, з якімі я сам асабіста пазнаёміўся.

Канцэнтрацыя

Адзін з варыянтаў апісваецца ў кніжцы “12-тыднёвы год” (The 12 Week Year), дзе аўтар настойвае на максімальнай канцэнтрацыі вакол задач і прапануе скарачэнне звычайнага перыяду планавання з аднаго году да 12 тыдняў. Самая ідэя 12-тыднёвага тыдня вельмі цікавая і я пра яе больш падрабязна планую распавесці ў наступным выпуску рассылкі ў панядзелак, таму мае сэнс падпісацца.

Дык вось, аўтар прапануе пры такім падыходзе вызначаць на тыдзень адну важную справу, ці нават мэту, вакол якой павінны будавацца план. Эфектыўнасць кожнага дня ён прапануе ацэньваць па таму, наколькі вы прыблізіліся да сваёй мэты.

Такая канцэнтрацыя дапамагае адсекчы розны шум і сканцэнтравацца толькі на выніковай дзейнасці. Калі лічыць, што кожны тыдзень будзе такі (малаверагодна), то праз 3 месяцы вы выканаеце 12 вялікіх задач, якія вы спачатку планавалі на цэлы год.

Я часам карыстаюся такім падыходам, збіраючы на пэўны тыдзень нейкую групу аднатыпных задач у межах праекту і максімальна шчыльна над імі працую, каб атрымаць адчувальны вынік. Але падтрымліваць такі тэмп пастаянна даволі складана з-за розных жыццёвых акалічнасцяў.

Цыклічнасць

Другі прыклад выкарыстання тыдня, як перыяду дзейнасці, я ўбачыў у аднаго даволі папулярнага інды-хакера, які адзін зрабіў некалькі паспяховых праектаў. У яго выпадку складанасць была ў тым, што яму аднаму патрэбна было як рабіць праект, так і неяк расказваць пра яго аўдыторыі і ён вырашыў чаргаваць такія перыяды актыўнасці.

Адзін тыдзень ён працуе над праектам наўпрост, то бок піша код і робіць іншыя тэхнічныя задачы, дадае новыя магчымасці да сваіх праграм і публікуе іх. А на наступным тыдні ён збірае ўсё тое, што зрабіў і расказвае пра гэта карыстальнікам. У канцы перыяду піша выпуск рассылкі, дзе дзеліцца гэтымі дасягненнямі і публікуе план на наступны тыдзень.

Такім чынам, адзін тыдзень яго для распрацоўкі, адзін для маркетынгу сваіх прадуктаў. Ён нават стварыў адмысловы сайт для такіх жа незалежных стваральнікаў, які паказвае, які зараз тыдзень – праграмавання ці маркетынгу.

Гэта толькі два прыклады, але на самой справе спосабаў планаваць свой час, энергію і ўвагу даволі шмат. Кожны падбірае для сябе той спосаб, які яму лепш пасуе. Я буду вельмі рады, калі прыведзеныя мной прыклады камусці дапамогуць хутчэй разабрацца з заваламі і вызвалены ад працы час правесці са сваімі блізкімі. ♥️

Як зроблены і працуе сайт з правіламі беларускай мовы (ч.1)
#інжынерства

Раней я ўжо расказваў пра Jamstack, генератары сайтаў і безгаловыя CMS, цяпер жа надышоў час нарэшце распавесці пра тое, як быў зроблены і працуе сайт з правіламі беларускай мовы – pravilna.by.

Спачатку трошкі гісторыі

Або чаму я ўвогуле вырашыў стварыць яго? Аднойчы я шукаў нейкае правіла адносна беларускай мовы і трапляў на спасылкі з тэкстам закона, дзе ўсё было апісана. Дзесці гэта былі вялізныя дакументы ў фармаце pdf ці doc, дзесці проста web-старонкі, але шукаць нешта ў вялікім дакуменце не вельмі зручна. І неяк мне на вочы трапіўся падобны сайт, але з правіламі рускай мовы і я вырашыў, а чаму б не зрабіць такі ж, але для нашай, роднай мовы?

Свае сайты я ўжо ў той час рабіў з дапамогай генератараў, таму што гэта было амаль бясплатна, а для некамерцыйнага праекту вельмі важна эканоміць рэсурсы. Я набыў толькі дамен, за які даводзіцца плаціць і цяпер. У якасці генератара я абраў Hugo, бо актыўна цікавіўся ў той час мовай праграмавання Go і было цікава скарыстацца інструментам, напісаным на той жа мове праграмавання.

Што сабой уяўляе сам сайт

Два вялікія раздзелы – арфаграфія і пунктуацыя, 11 падраздзелаў і 66 параграфаў з непасрэдна правіламі. Кожны параграф мае тлумачэнне і прыклады слоў ці моўных канструкцый. Самі параграфы дадаткова падзяляюцца на асобныя пункты, на якія можна асобна спаслацца. Па сутнасці гэта тэкст закону “Аб правілах беларускай арфаграфіі і пунктуацыі”, разбіты на часткі. Так, правілы беларускай мовы – гэта закон! 🙂

Тэхнічна гэта 66 асобных файлаў у фармаце Markdown, якія дадаткова пазначаны спецыяльным кодам Front Matter у якім пазначаны раздзел і падраздзел.

+++
title = "Агульныя правілы правапісу вялікай і малой літар"
chapter = "Правапic вялiкай i малай лiтар"
section = "Арфаграфія"
+++

У некаторых выпадках, каб палепшыць выгляд галоўнай старонкі, некаторыя параграфы спалучаны разам, дзе гэта мае сэнс. Напрыклад старонка “Перадача акання і якання на пісьме” апісвае параграфы §4 і §6, якія называюцца "Передача акання на пісьме" і "Перадача якання на пісьме" адпаведна, але кожны параграф усё яшчэ мае асобную старонку, на якую можна спаслацца асобна.

Усе гэта зроблена з дапамогай генератара Hugo і простага шаблону (ці тэмы) збіраецца ў сайт, які потым загружаецца на GitHub Pages і там захоўваецца. Змены ў кодзе ці тэкстах правіл аўтаматычна збіраюцца з дапамогай GitHub Actions і трапляюць на сайт. Увесь код даступны публічна, таму каму цікава пакорпацца, запрашаю на GitHub.

Як бачыце, сайт даволі просты, калі казаць толькі пра афармленне, старонкі і самі правілы, але вось з пошукам давялося добра так пасядзець і прыдумаць простае, зручнае і бясплатнае рашэнне, пра якое я распавяду ў другой частцы.

Як і заўсёды, буду ўдзячны за ❤️‍🔥 пад допісам і распаўсюд. І падтрымку 😇.

Веламатарам не нараджаюцца, ім становяцца
#нефармат #веласіпед

Суботнія веласіпедныя вітанкі! 🚴

Пад прошлым анонсам было 16 рэакцый у падтрымку новага фармату, таму сёння спецыяльны нефарматны допіс, у межах якога я хачу распавесці вам пра сваё захапленне веласіпедам.

Адкуль пайшло

Калі я быў малы, то кожнае лета на канікулы я ездзіў да бабулі ў вёску. Вёска знаходзіцца даволі далёка ад горада, дзе я жыў з бацькамі, таму паездка туды была падобна на экспедыцыю на востраў, бо мабільнай сувязі тады яшчэ не было, а звычайны тэлефон быў толькі ў суседкі праз тры дамы.

І вось у такім рэжыме палескіх рабінзонаў я бавіў там час з дзядзькам, які навучыў мяне арыентавацца ў лесе і балоце, лавіць рыбу і ўмець шукаць сляды жывёл. Лясныя абшары там даволі вялікія і пешшу не адолець, таму мы актыўна карысталіся веласіпедам. Ехалі, пакуль атрымлівалася, а калі сцежка зусім знікала, хавалі веласіпеды і далей ужо нагамі.

З тых часоў засталіся даволі яркія ўспаміны, да таго ж гэта дзяцінства, калі дарослых турбот няма і ўсё, што здараецца, новае, таму неверагодна цікавае. Думаю, гэта і паспрыяла таму, што паездкі на веласіпедзе для мяне – нешта такое, што вяртае мене ў тыя часы і супакойвае думкі. Нагадвае медытацыю.

Першы далёкі заезд

Калі я пераехаў у Мінск вучыцца, то зразумела, што ў інтэрнаце захоўваць веласіпед было немагчыма. Таму да веласіпеда я вярнуўся толькі на 4 курсе, калі пераехаў на асобную кватэру. Спачатку браў на пракат, а потым і свой набыў. Першыя паездкі былі не надта доўгія, але ж азарт пачаў разбіраць і хацелася заехаць усе далей і далей, праверыць, колькі змагу адолець.

І вось аднойчы я вырашыў паехаць у свой першы вялікі велапаход. У якасці маршрута я абраў шлях з Баранавіч да Лунінца, таму што амаль увесь час аўтамабільная дарога па маршруце ішла ўздоўж чыгункі. На выпадак, калі нешта здарыцца ці я моцна стамлюся, я ў любы момант мог сесці на “дызель” да Лунінца. Гэта была мая страхоўка.

Але 145 кіламетраў я пераадолеў даволі лёгка, вельмі моцна здзівіўшы бацькоў, калі нечакана з’явіўся дома. Цяжкімі былі можа быць першыя 40 хвілін, бо да Баранавіч я ехаў начной электрычкай і калі толькі выехаў з горада, было яшчэ зусім цёмна і нязручна.

Брэветы і медалі

Ужо пазней, калі я зноў прывёз свой веласіпед у Мінск, я пачаў шукаць маршруты, па якім было б цікава паездзіць. Дакладна не памятаю, якім менавіта чынам, але я патрапіў на форум, дзе абмяркоўвалі свае паездкі ранданёры. І там жа дазнаўся, што праводзяцца брэветы – спецыяльныя заезды, дзе няма гонкі за першае месца, але патрэбна выканаць пэўныя правілы, каб твой вынік залічылі.

Пачатковая дыстанцыя для сапраўдных брэветаў – 200 кіламетраў, якія патрэбна праехаць за адведзеныя 13 гадзін і 30 хвілін (сярэдняя хуткасць 15 км/г). Было боязна ехаць, але свой першы брэвет з залікам і медалём я праехаў 19 красавіка 2014 года за 12 гадзін 52 хвіліны. Другі паспяховы брэвет адбыўся 16 красавіка 2016 года з вынікам у 12 гадзін і 27 хвілін.

Была яшчэ спроба праехаць брэвет на 300 кіламетраў, але на пачатку маршрута трапіў у яму ў цемры і трошкі паламаў веласіпед (пагнуў колы і амаль не было задніх тармазоў), што запаволіла тэмп і давялося сысці з дыстанцыі, калі не паспеў на прамежкавы кантрольны пункт.

Потым пачалося сямейнае жыццё, дзеці і іншыя турботы, таму на некаторы час я выпаў з ранданёрскага руху, але па магчымасці выбіраўся на доўгія маршруты, калі дазваляў час. Але ж планую ў хуткім часе вярнуцца да брэветаў і актыўна трэніруюся, бо без падрыхтоўкі такую адлегласць не праехаць.

Калі вам цікава даведацца больш пра ранданёрскі рух у Беларусі, стаўце агеньчык 🔥, наступным разам распавяду і пакажу, дзе знайсці інфармацыю і далучыцца да супольнасці. Ну і праехаць свой першы брэвет, бо каляндар на гэты год ужо зацверджаны!

SSH і порт 22, правіла 1-3-5, цяжкасці працы і ранданёркі рух
#абнаўленні #анонс

Вітаю! 👋 Сёння нядзеля, а значыць час пазнаёміць вас з планам на наступны тыдзень.

Між тым я нарабіў тэм ажно на 4 тыдні наперад, засталося толькі напісаць змест да ўсіх. Працэс напісання і публікацыі ўдакладняю амаль кожны дзень, каб дасягнуць прадказальнай рэгулярнасці.

Таму чакайце гісторыю пра SSH і чаму менавіта 22 порт быў выкарыстаны, так сама пра цікавае правіла прадукцыйнасці 1-3-5. Яшчэ збіраюся распавесці пра асаблівасці працы з грашыма ў праграмах, паразважаць наколькі цяжка быць праграмістам і ў суботу распавесці пра брэветы і ранданёраў.

Акрамя гэтага планую некаторыя абнаўленні адносна ўзроўняў падтрымкі і нешта цікавае для тых, хто падпісаны на мяне праз Patreon ці BMC.

P.S. На выхадных запісаў некалькі кароткіх відэа пра тэхналогіі, якія планую апублікаваць на тыдні ў Instagram Reels, TitTok і YouTube Shorts, таму можаце падпісацца, дзе вам зручней.

Чаму SSH выкарыстоўвае менавіта 22-гі порт
#гісторыя #факты

Калі працуеш над Open-Source праектамі, прызвычайваешся, што многія рэчы, як і ў сапраўдным жыцці, вырашаюцца на ўзроўні звычайных чалавечых адносін. Так, дакладна можна напісаць Лінусу Торвальдсу з прапановай, які прафесійна затопча цябе ў гразь за недахоп ведаў, але па факце гэта будзе асабістая размова з легендай, няхай і праз інтэрнэт.

Калі тэхналогіі толькі пачыналі развівацца, многія рэчы рабіліся проста праз дамовы паміж людзьмі. Часам нейкія фармальныя працэдуры патрабаваліся, напрыклад напісаць RFC ці ліст да публічнай рассылкі, але ўсё было даволі проста – патрэбна было толькі папрасіць. Менавіта так і зрабіў у 1995 годзе Tatu Ylonen (яго Twitter/X).

Першапачаткова для сувязі паміж камп'ютарамі выкарыстоўваўся пратакол telnet, які быў зроблены ажно ў 1969 у першыя дні працы IP-сеткі. Пратакол не прадугледжвае ўбудаваных мер бяспекі і гэта робіць складаным яго выкарыстанне, калі ёсць нагоды не давяраць цалкам удзельнікам сеткі.

Для перадачы праз сетку файлаў у тыя часы ўжо існаваў пратакол ftp (File Transfer Protocol), які так сама не меў аніякіх сродках забеспячэння бяспекі. Таму Tatu Ylonen напісаў свой пратакол – SSH (Secure Shell). Ён распрацаваў SSH, каб замяніць як telnet (порт 23), так і ftp (порт 21). І так склалася, што порт 22 быў як раз паміж партамі ftp і telnet і быў свабодны. Tatu палічыў, што нумар можа быць адной з тых дробязяў, якія нададуць нейкую аўру даверу. Але патрэбна было неяк атрымаць гэты порт.

У той час асноўны працэс размеркавання партоў быў даволі простым, бо Інтэрнэт толькі пачынаўся. Нумары партоў выдзяляліся арганізацыяй IANA (Internet Assigned Numbers Authority). Кіраваў ёй у той час Jon Postel, рэдактар пратаколаў IP, ICMP і TCP. Напісаць чалавеку, які быў аўтарам галоўных дакументаў Інтэрнэту, было страшнавата.

І ўсё ж Тату напісаў ліст Джону, дзе распавёў пра асаблівасці сваёй новая праграмы ssh і папрасіў вылучыць для яе порт з дыяпазону ад 1 да 255, каб трапіць у WKS (Well-Known Services) – спіс давераных сервісаў, і спытаў, ці можна ўзяць нумар 22, бо ён ім ужо карыстаўся ў бета-версіі.

На наступны дзень 10 ліпеня 1995 года прыйшоў адказ: "Tatu, мы прызначылі порт 22 для ssh, дзе ты пазначаны як кантакт". Пасля гэтага, 12 ліпеня, аўтар афіцыйна напісаў сваім бета-тэсцерам і анансаваў першую версію ssh-1.0.0. Такім чынам порт 22 стаў звычайнай з'явай для тых, хто працуе з серверамі праз сетку. Такая вось гісторыя, цікавая і бадай непаўторная, хаця ўсё развіваецца і хто ведае, што будзе праз 100 гадоў.

Буду ўдзячны вашай падтрымцы і распаўсюджванню, як і заўсёды.