Про два режима работы мозга.
На курсе "Учись учиться" первая тема о том, что новая информация усваивается только в рассеянном режиме работы мозга. Нужно расслабиться, дать мыслям течь свободно, а не последовательно. Именно так формируются новые нейронные связи.

На своём опыте мне известно давно: хочешь освоить сложную тему, действуй так.
1. Пробежаться по материалам: текст, схемы, графики и тд.
2. Озадачиться. Ну то есть, отметить то, что вызвало наибольший стресс у организма. Этот стресс надо усилить. Пройтись по самым жёстким моментам, задать себе вопросы. Зарядиться. Ответы на этом этапе не нужны. Когда начинает отрубать и чувствуешь, что плывёшь - начинается самый смак. Если чувствуешь, что вообще ничего не понимаешь - самый ценный процесс запущен.
3. Пробой и слияние. Минут 10-15, не меньше. Это самое ценное время. Ничего не понятно, мысли не связываются в цепочки. В идеале мысли не воспринимаются вообще, ощущение пустой головы. Здесь нужно блуждать по материалу в той последовательности, как несёт. Куда тянется взгляд и руки - на то смотрим. Уровень стресса довольно высокий, но стабильный. Задача - просто расслабиться, и быть в этом состоянии. Курпатов пишет, что только вот в этот момент происходит истинное мышление.
4. Основной этап: фоновая обработка. Отворачиваемся и уходим заниматься чем-то максимально далёким. В юности отлично работал на этом этапе алкоголь (как ни странно...). Сейчас я берегу себя и использую любой чилл. Прогулки, пробежки, подурачиться как угодно - попеть, потанцевать, покривляться. Поесть в красивом ресторане, почитать книжечку в кофейне. Это не безделье! Именно в это время идёт обработка информации. 2-3 дня для инфы объёмом в главу учебника по квантовой механике. Или какая-нибудь небольшая проблема уровня "на что потратить 200 млн"
5. Инсайт. Получение готового решения. Или готовая канва в мозгу, если это обучение. Ощущение: о, это ж так просто. Что там было непонятного!
6. Проверка , шлифовка, закрепление. Часто система укладывается с дефектами - где-то что-то допридумано, недопонято. Или решение понятно в главных моментах, а детали не проявлены. Надо с новым укладом порешать задачи или проблемы. Смоделировать проблемы в системе, попробовать разные исходные данные.
7. Профит! Система навсегда в мозгу. Можно пользоваться хоть в состоянии нестояния.

Вот так я получила красный диплом по физике. А одногруппники до сих пор говорят: как так? Катюха везде с нами веселится, на всех гулянках. А потом приходит на экзамен - у неё пять, первая написала и пошла, а мы сидим...
А я, в общем-то, особо и не понимала, что сложного-то. Ну повтыкай расслабленно час в учебник, испиши пару десятков листов каракулями, и иди гуляй... А оно само.

Как вам задача спроектировать хранилище под bi на 100 пб? На чём бы такое подняли? Был опыт? Сколько нервов денег стоило?

Разбираю полки, нашла вот что. Куда девать?
😇 В архив
🔥 Сжечь В переработку
😴 Читать перед сном

Что же на работе?
На работе пока ничего не началось. Пока придумала задачку на основе реальных событий. Есть база данных Oracle. Физически занимает 12 ПБ. Нужно перелить её в Hadoop. Сколько серверов и с какими характеристиками понадобятся для уровня BO и BC?
Жду от всех желающих предложений - хочу понять, как разные спецы видят сложности в этой задаче.

Ладно, попробуем решить задачку в лоб и двигаясь по чуть-чуть. Без конкретики точные оценки мы не дадим, поэтому можем дать серую оценку, чтобы прикинуть затраты.
Оценим размер дискового пространства.
Оракл имеет привычку сжимать данные. По собственным оценкам Оракл - до 1.5 раз. То есть объем несжатых данных можно оценить не глядя в 18 пб.
Далее хороший вопрос - что там за данные, насколько они важны. Потому что придётся поторговаться за фактор репликации hadoop. Допустим, для BO можно предложить 1, если это маловажная инфа, которую мы изредка можем без зазрения совести потерять. И фактор 3 для важной инфы. Для BC фактор может быть и выше, до 5 плюс резерирование в геораспределнный цод. И тут тоже есть о чём поторговаться.
То есть если откинуть сантименты, то оценка для BO - 54пб дискового пространства. Для BC - 108пб.

Итак, какие выводы я сделала из случая, когда моя система настолько кому-то отдавила денежный поток, что он решился на взлом?

1. Если можешь не писать - не пиши,
На этом можно было и закончить) это те самые 20%, которые дают 80% результата по закону Паретто
Но есть несколько второстепенных, облегчающих жизнь.

2. Всегда делай бэкапы и минимальное георезервирование. Режим параноика - это то, что нужно для данной задачи,
3. Исследуй теневые бизнес-процессы,
4. Если тебе что-то показалось - тебе не показалось. Ищи скрытых стейкхолдеров или скрытые мотивы,
5. Не заключай мутных сделок. Просто никогда не делай этого. Ни с кем. Нет ясности - нет сделки.
6. Пиши проектную документацию. Она делает проектные решения простыми и ясными. Не хочется, в голове все и так ясно-понятно? Ты единственный разработчик? Не обращай внимания на эти голоса в голове. Just do it. Сначала проектирование - потом код. Не наоборот.

Как вам название серверов для развертывания системы наблюдаемости: obser01, obser02?
Ну не ложится никак понятие наблюдаемости на русский язык. Ни калькой, ни транслитом...
Хоть тушкой, хоть чучелком - а не лезет.

Меня спрашивают, на каком языке я пишу.
А я в последнее время так преисполнилась мудрости, что могу честно признать: и русский до конца не освоила. Куда там до языков программирования.
А вот любопытно посчитать всё, на чём я написала хотя б несколько строк. Но не хэллоу ворд, и даже не какой-нибудь учебный проект. А прям промышленный работающий код, за который мне заплатили приносящий реальную бизнес-пользу.
Я ставлю на что-то между 15 и 20 языками. Будет время - сяду и посчитаю)

Итак, перечисляю языки, на которых я собственноручно куда-то продвинула бизнес.
Чтоб не растекается мысию по древу, три обязательных условия:
1. Писала я,
2. Код заработал на проде для решения реальной бизнес-задачи,
3. Мне за него заплатили.

Итак, поехали:
1. ASM (да, было и такое - модификация кода при утерянной кодовой базе),
2. Fox. Это было неизбежно... ,
3. C. Мои дети поют "Мама может Си 🙈" ,
4. Delphi (ну было),
5. Внутренний язык 1С (ну а че... зато я смогла соскочить) хотя это язык программирования вообще? или язык конфигурирования?,
6. Процедурные расширения SQL, их всех в один пункт, чего их считать,
7. Visual Basic и VBA, и, кстати, мне даже нравилось, этакий вайб детской игры,
8. Java. Топ 1 по количеству бессонных ночей, бессмысленно потраченного времени, но и топ 1 по стоимости строки 😂,
9. Groovy. Это просто опыт,
10. Python. Самый норм для беспроблемного зарабатывания денег, но никакой искры, никакой...
11. Javascript+Typescript а у кого его не было? ,
12. Встроенный язык wso2 Если уж встроенный язык 1С - это язык, то и этот нельзя не посчитать. Даже несколько люблю его. За что? За бесценный опыт, за необходимость рыться в индусских блогах,.. и за хорошие деньги, конечно,
13. Bash 😄,
14. PowerShell (тоже скриптовый язык, и очень даже),
15. R (тоже числится по разряду скриптовые языков). Да, было.

Языки запросов, конфигов, разметки и т.д. даже считать не хочу 😂 но могу как-нибудь прикинуть объем прочтённых спецификации.
Наверняка было что-то ещё, но в памяти остались эти проекты. Они были любопытными, значимыми, продвигали меня вперёд по граблям.
А если вспомнить то, что разбирала, ревьюила, оценивала, стендировала, писала учебные проекты, то там будет списочек в 2-3 раза больше. Там будет, наверное, всё на свете, кроме php 😂
Надо ли меня спрашивать, почему я больше не хочу кодить?
Когда-то меня это дело очень забавляло. А потом стало дико скучно и жалко потраченного времени. Мне стало казаться, что я видела всё. Мне очень понравилось, что я занимаюсь критичными и важными вопросами, а в это время кто-то другой разбирается, почему какая-то зараза не видит указанный порт или не проходит компиляцию.

Хотя в последнее время я поглядываю на haskell.
Он ни на что не похож. Он умный и смешной. Может быть, буду писать на нём шутки на пенсии.

Когда я слышу вопрос, какой язык программирования выбрать... я вообще не понимаю, о чём речь.
Хочешь денег в айти - выбирай глубокое понимание процессов в проектируемой системе на всех уровнях.
Тренируйся выделяй ключевые требования в проблеме заказчика. Научись в тоннах доков найти ровно то, что требуется в данном случае. Детально изучай специфику компонентов, мелкий шрифт тоже. Учись видеть узкие места и будущие проблемы. Считай стоимость поддержки. Учись собирать оценивать требования. А ещё лучше - изучай расстановку и интересы стейкхолдеров на проекте.
Общайся с коллегами, слушай их внимательно, они радостно делятся проблемами - и это бесплатно! Лучше любого вебинара.
Найди наставника, если надо всё это быстро, прям сейчас, желательно вчера.
А язык какой-нибудь возьми, любой, какой?... монетку кинь, я не знаю. Или дайс... И научись писать на нём базовые алгоритмы.
Они тебе больше никогда не пригодятся (ну почти)

По поводу стоимости навыков разработчика, обнаружила зависимость.
Чем меньше пишешь кода - тем выше твоя ставка оплаты. Как месячная, так и почасовая. И доля в проекте.
Пока я строчила килотонны кода с удовольствием, вообще никто не платил)
Самые высокие ставки же получаются, когда одним неоспоримым аргументом отговариваешь бизнес от какой-нибудь безнадёжной затеи.

Я вот пишу, мол, техника программирования никогда не пригодится...
Прорешай все задачи на leetcode, прочти "Искусство программирования" или что-то около.
А потом на реальном проекте все твои задачи - это перекладывание сообщений из кафки в БД.
Но, конечно, знать то, что зашито внутрь библиотеки, что и как работает под капотом у системы - дорогого стоит.
Это экономика ресурсов плюс умение предсказать проблемы плюс мгновенное понимание узких мест, а значит и фикс проблем из разряда "никто не понимает, почему у нас теряются сообщения". Или, например, почему мы заливаем систему ресурсами, а она работает всё медленнее?
Это похоже на использование калькулятора. Нужно уметь посчитать в столбик, чтобы понимать, как всё работает. Чтобы прикинуть быстро в уме. Или быстро найти ошибку. Или чтобы усовершенствовать расчёты.
Но в повседневных задачах ты просто забиваешь цифры в колоночку эксель.
Да, алгоритмы тебе никогда не пригодятся. Но они научат тебя понимать, как устроены инструменты. А при самом удачном стечении обстоятельств - научат думать и искать решение совершенно непонятных проблем.

Архитекторский кейс.
Стоит ли передавать файлы из БД в аналитическое хранилище в виде полей blob?
Есть книга, где автор утверждает, что хранить файлы в blob - это хорошая практика. Действительно, плюсы у такого решения есть.
Пусть файлы в нашем случае и хранятся в БД в поле типа blob.
А вот переливать в хранилище стоит ли их в таком виде?
Плюсы, минусы такого решения?

Я в большинстве случаев против хранения файлов в полях типа blob, если дело касается хранилищ.
Ниже - разбор для интересующихся.

Плюсы использования blob заметны для БД
- blob поле удаляется вместе с записью, что автоматом подчищается мусор.
Второе - меньше рисков нарушения целостности. Сюда же - проще делать бэкапы.
Но так ли это актуально для хранилища? В хранилище мы редко что-то удаляем. Если и удаляем, то это выполняется атомарными транзакциями. Обеспечение целостности данных лежит на etl-процессах.
А минусы велики:
- не всегда эффективная обработка движком больших объемов информации в blob полях;
- нужно глаз да глаз за тем, чтобы кто-то не написал запрос, который потянет тебе огромные ненужные блобы в рекордсет,
- при включении версионирования данных, опять же нужно внимательно смотреть, попадают ли туда блобы или нет, оправдано ли это,
- переливание из таблицы в таблицу, допустим при добавлении нового поля при непрерывной доставке, имеет шансы превратиться в ноев потоп для всей системы
и т.д.
Мы получаем головную боль на каждом шагу при обработке таблиц с блобами. Это дополнительная точка контроля, которая должна быть в поле зрения при любом дальнейшем решении.
К тому же, если есть требования к безопасности файлов, то тут добавляются риски. Нужно всё время считывать инфу из blob, прогонять через песочницы, антивирусы и прочие системы безопасности, а потом записывать назад.
Итого, в большинстве случаев, считаю, файлы лучше хранить в файловом хранилище, а использование blob в хранилищах данных жёстко ограничивать.
Это может неплохо сработать вначале, ускорить запуск. Но при развитии станет источником проблем.

Пришла в голову идея. Составить гайд по типичным решениями, которые разрабы закладывают, чтоб быстрее сбагрить систему с рук.
А при развитии эти решения становятся тормозом, тянут деньги, блокируют развитие.
Думаю, было бы круто. Но вот получится ли - надо осмотреться. Повыбираю кейсы из опыта.
И которые сама творила (и главное - почему). И которые разгребаю за другими.

В прошлом году я много путешествовала по России. И до этого несколько лет ехала куда-нибудь при первой же возможности.
Камчатка, Сахалин, Карелия, Калининград, Сочи, ЕАО, Приморье... Везде с трекинговыми кроссовками и тренировочным планом, включающим треки по 3-4 часа. А это значит, я каждый день открываю приложение с картами и строю пешие маршруты по любопытным местам.
Я люблю приезжать куда-то и попробовать жить, как местная. В разных городах, в разных районах городов, за городом - чем разнообразнее план, тем лучше. Работа на удалёнке позволяет так делать. Был бы интернет.
Терпеть не могу туристические места - они все на одно лицо.
К тому же я несколько лет думаю, куда могла бы переехать. Пока никуда не захотелось на постоянку, но было очень любопытно сравнивать ощущения от жизни в разных точках России.
Пока никуда не тянет.
Сейчас единственное, что вдохновляет - это Северный полюс. Круиз на ледоколе, бескрайние просторы. Небо, море, лёд.
Самое интересное - какие там звуки, какой запах, какой воздух на вкус?

О работе со смежниками.
Это самое сложное. Спроектировать систему, найти ошибки, риски - это всё просто. Писать код - просто, скучно и долго.
А вести производственные конфликты, переговоры, компромиссы - вот тут приходится поработать.
Несколько лет назад старшая дочка (а она хотела тоже пойти в разрабы) наблюдала за моей работой и сказала: мама, ты же программист, я не понимаю, как ты разрабатываешь. Ты только письма пишешь и по телефону говоришь 😂
А ей говорю: ну вот так я пишу. 10 строк за полгода, и то, если больше некому. Зато документашку читаю по 500 страниц в час.
Поначалу я думала, что со мной что-то не так. А потом оказалось, что это и было началом архитекторской жизни.

Довольно странно для такого упоротого ботана как я, но ролевые игры обошли меня стороной.
Не, я как-то в студенческие годы ездила на игруху по Толкиену. Мне дали деревянный нож и отправили на разведку.
Всё это было занятно. А шастать ночью по лесу я приучена с детства. Но я и друг приехали без палатки, в итоге спали ночью возле костра. И я это запомнила на всю жизнь 😂 Никому не посоветую, потому что одну половинку жгло костром, а вторая обледеневала, и мне приходилось крутиться каждую минуту, как бычку на вертеле. А другу было ещё хуже, потому что он поддерживал костёр, и не спал вообще.
Зато я точно представляю ощущения героев романтических квестов с ночёвками у костра. И от этого ещё приятнее читать их под тёплым одеялком.
А вот D&D и подобные НРИ почему-то вообще не появлялись на горизонте. Подозреваю, что в мою активную социальную жизнь просто не могла пробиться такая махровая нердятина.
Но вот сейчас до меня эта история дошла.
И это настоящее спасение при работе в режиме удалёнки. Я вижу коллег в основном в виде чёрных квадратиков с фамилиями, а то и без.
Мне впервые в жизни по-настоящему не хватает живых людей вокруг, когда я перешла на удалёнку! И вот уже 4 года я специально хожу и вписываюсь в живые встречи - клубы, завтраки, мастерские, походы, настолки. Это не на 100% удовлетворяет мои потребности в живом плотном динамичном общении, но всё ж это что-то.
У меня ещё есть плейбэк театр, но мы никак не можем наладить график репетиций. Поэтому встречи наши яркие, но слишком редкие, чтобы я могла на них рассчитывать.
А ролевки, похоже, претендуют занять особое место в сердце. Потому что там я можно добрать всего, что не подвозят на работе и семье.
Вот не зря всякого рода сисадмина, разрабы и прочий инфоинженерный люд любят D&D и прочие ролевки. Живые люди нужны, но нужную интенсивность и разнообразие эмоций попробуй ещё проживи... Опять же, и умище куда девать? Играть за компом после рабочего дня за компом - прастите...

Почему я не хочу уезжать с Дальнего Востока.
Вчера разговаривала об этом с таксистом - уроженцем Баку. Он живёт на ДВ 40 лет, и быстро начинает скучать по нашим местам в родном Баку. Почему наш непопулярный край так цепляет?
Одно время я рвалась отсюда, как все. Ну типа, образование так себе (это неправда, образование научило справляться с чем угодно на свете при помощи мозгов и паяльника, а педагоги искренне вкладывались в каждого студента). Вроде как скучно (скука - единственный мотиватор истинного творчества, я стала основателем нескольких отличных тусовок и навыдумывала кучу всяких штук для каждой из них). Вроде как нет работы (это неправда. Я поработала в Майкрософте, принесла лицензионное ПО как норму в регион. А как технарь поработала во всех компаниях, где хотела. К тому же благодаря удалённости от Москвы у меня везде было очень много самостоятельности и свободы, и сорвала нос везде. Всё я щупала на практике, а мои навыки траблкиллера отточились до толщины нанобритвы).
Теперь я могу хоть завтра сесть на самолёт и уехать в любой регион России одна или с семейством. И жить там хоть месяц, хоть год. Я могу приложить немного усилий и найти работу во многих странах мира. Но.
Я несколько лет ездила по всем местам, которые меня привлекали. Жила как местная - снимала квартиру, ходила в магазины и кафе. Работала в обычном режиме, а по вечерам и выходным развлекалась. Входила в местные тусовки, болтала с таксистами и официантами, избегала нахоженных туристами троп.
У меня есть свой топ мест для жизни в России. Важны климат, природа, доброжелательность и открытость окружающих, возможность небольших приключений и простая вкусная еда в лёгком доступе.
И оказалось, всё это есть у меня в 10 минутах от дома, притом в большом разнообразии.
В следующий раз напишу, почему я так и не нашла лучшего места для жизни, чем мой родной край. Что цепляет лично меня.

Работа DBA на проекте