Доречі, про системи контролю версій.
Вчора вперше за п'ять років знайомства з git мені згодився reflog. По роботі.

Картіна маслом.
Запушив коміт з двома новими файлами у свою feature-гілку. Дивлюся - а один з них мені і не потрібен. Видалив його, а потім, щоб не створювати нового коміту та не залишати непотрібний файл в історії, роблю
1. git commit --amend
2. git push --force origin my-feature

Здогадайтеся, чи той файл я видалив?..
Отож. Не той.
Маємо: В локальномі репозиторії файла нема (бо amend). У віддаленому - теж (бо force push). А у файлі був SQL строчок на п'ятнадцять, що шліфувався зо дві години.
Перша секунда після: йо...
Друга секунда: о, в мене ж є reflog, я про нього і на мітапі розповідав.

1. git reflog
2. знаходжу хеш того коміту, в якому був потрібний файл
3. git checkout хешКоміту -- шлях/до/файлу
(тільки не загубіть пробіли до і після двох дефісів)
4. маю "втрачений" файл в локальному репозиторії
5. ???
6. профіт!

Мораль.
Git ніколи сам по собі не видаляє дані. І навіть після переписування історії можна знайти "втрачене" (але поки gc на репозиторії ніхто не запускав).

#git

TRUE, FALSE, NULL, fn(NULL)

Булєва логіка - штука логічна. Але в реляційних базах є старий добрий NULL.

Так, ми пам'ятаємо, шо nullable поле тре перевіряти на IS NULL (IS NOT NULL) і ніяк не на =NULL (<>NULL), бо в результаті замість бажаного true або false завжди отримаємо NULL.

Так, ми пам'ятаємо, шо якийсьОператор(NULL) та NOT якийсьОператор(NULL) знову таки дають одне й те саме - NULL (звісно, якщо якийсьОператор не з тих, що вміють поводитися з NULL - IFNULL, COALESCE...).

Ще ми пам'ятаємо, шо NULL є такимсь "третім елементом" у булєвій логіці РСКБД:
true OR NULL —> true
false OR NULL —> NULL
true AND NULL —> NULL
false AND NULL —> false
(принаймні в PostgreSQL та MySQL)

Цікаво, правда?

Та ОСОБЛИВО це, млять, стає цікавим, коли в nullable полі лежить масив і вам треба чекнути щось по типу "чи є значення у цьому масиві": value=ANY(arrayField).
Причому цей предикат ще пов'язаний через AND або OR з іншими. Якось по типу

( condition OR NOT value=ANY(myArray) )
AND
( condition OR NOT value=ANY(myArray) )

Мораль.
Не завжди nullable поля-массиви це зручно. Зробіть NOT NULL та зберігайте пустий масив замість NULL.
І тоді ANY(myArray) поверне канонічне true або false, яке прозоро може бути поєднано з іншими предикатами. І буде вам щастя.

За мотивами написання SQL-міграції, в якій фігурує nullable поле-массив.

... або просто юзайте
COALESCE(arrayField, '{}')

Zombicide.
Цікава гра, атмосферна. Для тих, хто полюбляє зомбі-апокаліпсис.
#boardGames

А ви знали, що знак питання в RegEx-ах має аж чотири контексти?

1. Квантифікатор "нуль або один".
2. Перемикач жадібності квантифікаторів (в тому числі і самОго себе, див. пункт 1).
3. Ознака того, що зміст круглих дужок запам'ятовувати не треба.
4. Ознака ретроспективної перевірки та перевірки, що випереджає.

#regex

Тут було побажання додати пояснень та прикладів до попереднього повідомлення. Тож додамо:

1. Квантифікатор "нуль або один".
Квантифікатор - це символ (або комбінація), що показує, скільки разів повинен повторюватися вираз, що йому передує.
а? - нуль літер "а" або одна літера "а",
(агр)? - нуль фрагментів "агр" або один фрагмент "агр".

2. Перемикач жадібності квантифікаторів.
Квантифікатори бувають жадібні та нежадібні (greedy, non-greedy). Це не всі типи, але зараз про інші не будемо.
Жадібні намагаються охопити якомога більше символів, що задовольняють їм. Нежадібні намагаються обійняти мінімальну кількість.
Довідка: квантифікатор + означає "один або більше".
а+ - жадібний варіант, на зразку "ааагр" він жадібно охопе "ааа",
а+? - нежадібний варіант, на зразку "ааагр" він охопе тільки першу "а".
Так, останній варіант може охопити всі "а", але кожну окремо, тобто це буде три окремих співпадіння.

3. Ознака того, що зміст круглих дужок запам'ятовувати не треба.
При звичайному використанні дужок їх контент запам'ятовується в спеціальні змінні (і може бути використаний декількома способами):

(агр)

А якщо запам'ятовувати не треба, то:

(?:агр)

4. Ознака ретроспективної перевірки та перевірки, що випереджає.
Ці дві перевірки - спосіб перевірити (так, Кеп), чи є перед/після регулярки інший фрагмент, не включаючи його у співпадіння.
На прикладі ретроспективної перевірки:
ааагр - без перевірки, співпаде "ааагр",
(?<=ааа)гр - з перевіркою, співпаде "гр", перед яким є "ааа".

#regex

Колодач, "Варвар". Дуууууже колоритний керамбіт. Але трохи не під мою руку.
#knives

Деякий час використовуємо в тестах на проекті штуки під назвою "генератори".
Сьогодні один хлопець з команди пише, що світла нема, але він сидить на генераторі.
Репліка в чатику: "генераторы в тестах, генераторы дома - консистентность !"

Чай - це як програмний продукт.
Ті, хто збирають його та висушують, розкладають по пакетах - то програмісти.
Чай в пакетиках - це сорці програми. Ось, у джаві навіть термін такий є - package. В пекаджах знаходяться файли з кодом.
Приготування окропу в чайнику, насипання чаю у пусте горнятко - це збірка проекту.
Заливання чаю окропом - деплой. Через декілька хвилин чай задеплоєно - він готовий до використання.
- Ти що там на кухні робиш?
- Як що? Чай деплою.

Мій улюблений спосіб виправити ситуацію "Трясьця йому, я не в ту бранчу закоммітив!"

#git

Доречі, на "Сталевій Грані" я вперше доторкнувся до творчості "Колодача" (місто Вінниця). Ножі, сокири, кукрі, мачетє... Уууух! Біля їх стенду я провів сумарно десь дві години, перемацав майже все та нарешті вибрав ось цього красеня.
Знайомтеся, "Добер". Колоритний та, як показав час, досить практичний.
#knives

В далекі-предалекі часи ми зі співробітником надумали створити один проект.

Кодова назва - "phone", мета - спростити комунікацію між співробітниками досить великого підприємства. Така собі розширена концепція телефонного довідника з плюшками. На той момент я працював вже десь рік, а до цього - ще півтора року студентом. І якоїсь подібної штуки мені ду-у-у-уже не вистачало.

Базку проектував я. Це був мій перший нештучний проект за участю РСКБД, і я не до кінця ще розумів, що до чого.
Дано: співробітник, що має одну чи більше посад. Посади можуть бути "стандартними" (вони винесені в окрему таблицю) та "нестандартними" (вони вносяться в спеціальне поле).
"Зроблю отак..." - сказав я і додав звичайне текстове поле, в яке будуть записуватися приблизно такі дані:
"+4|+1|Досить головний спеціаліст".

Відчуваєте усю дикість підходу, ага?
Вказано цілих ТРИ посади (нормальні форми? нє, не чув). Вони розділені вертикальною рискою. 4 та 1 - це айді "стандартних" посад. "Досить головний спеціаліст" - "нестандартна" посада.

Спочатку програма розбиває строку по "|", а потім прискіпливо дивиться на кожен отриманий фрагмент: якщо перший символ "+", тре його відкусити, а з числом, що залишилося, чимчикувати в таблицю "стандартних" посад. Якщо ні - то беремо, як є.

Щоразу, як це пригадую, виникає бажання надавати собі по пальцях важким підсвічником:)

P.S.
Проект тоді трохи загальмувався, його програмна частина досить довго припадала пилом. А потім все було переписано майже з нуля - дизайн, код, структура бази. Нащастя - вже з нормалізацією, за яку не соромно. Майже.
Він "вийшов у лайв" влітку 2014-го і дотепер живе в локальній мережі мого (вже колишнього) підприємства. Живе, функціонує і приносить користь. Що дуже приємно.
Нажаль, проект має постійні проблеми з актуалізацією інформації. Він не є офіційним. Так, пройшло майже шість років, та на папері його не існує. Проблема актуалізації частково вирішується за допомогою активних користувачів та добровільних модераторів, але таких небагато: мало хто хоче витрачати трохи часу та зусиль задля спільної користі. Але це вже зовсім інша історія...

P.P.S.
Ви - перші, кому я розказую про цей майже-фейл з минулого:)

SpaceX Crew Dragon пішов!