Рассказать всё 📢 (
от автора "вспомнить всё" и "записать всё")
Как говорил ранее, один из факторов успешного собеседования заключается в умении рассказать о своём опыте и знаниях. Именно рассказать. Вслух!
Помимо освежевания знаний, надо практиковаться в устном ответе на вопросы. Прям вслух проговаривать свой ответ под запись🔴
На первых порах можешь очень сильно удивиться, как много в твоей речи лишних звуков. А ещё во время рассуждений "про себя" мозг работает немного по-другому, и в этом режиме может выдать нужную информацию, а вот "вслух" куда-то вдруг всё пропадает🤔
Тут можно подмечать свои ошибки во время рассказа или при прослушивании записи, а еще её можно транскрибировать и передать полученный текст, конечно же, нейронке, чтобы получить от неё фидбек по твоему ответу. У ChatGPT😺 вообще есть режим созвона, в котором прям в реальном времени она может устроить тебе тех-скрининг, но у меня она в этом режиме как будто чаще ошибалась.
Ну а дальше, уже получив желанный оффер, не останавливайся, продолжай практиковаться в пересказе своих знаний и регулярно освежай их: пиши статьи и посты в канальчик, выступай на внутренних митапах и внешних конференциях, ментори кого-нибудь. Поддерживай этот навык тёплым 🔥, он тебе во многом пригодится и после собеседований.
И записывай это всё в достижения, конечно же🧠
#поиск_работы
от автора "вспомнить всё" и "записать всё")
Как говорил ранее, один из факторов успешного собеседования заключается в умении рассказать о своём опыте и знаниях. Именно рассказать. Вслух!
Помимо освежевания знаний, надо практиковаться в устном ответе на вопросы. Прям вслух проговаривать свой ответ под запись
На первых порах можешь очень сильно удивиться, как много в твоей речи лишних звуков. А ещё во время рассуждений "про себя" мозг работает немного по-другому, и в этом режиме может выдать нужную информацию, а вот "вслух" куда-то вдруг всё пропадает
Тут можно подмечать свои ошибки во время рассказа или при прослушивании записи, а еще её можно транскрибировать и передать полученный текст, конечно же, нейронке, чтобы получить от неё фидбек по твоему ответу. У ChatGPT
Ну а дальше, уже получив желанный оффер, не останавливайся, продолжай практиковаться в пересказе своих знаний и регулярно освежай их: пиши статьи и посты в канальчик, выступай на внутренних митапах и внешних конференциях, ментори кого-нибудь. Поддерживай этот навык тёплым 🔥, он тебе во многом пригодится и после собеседований.
И записывай это всё в достижения, конечно же
#поиск_работы
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4
Forwarded from C# Short Posts 🔞
🗄 Оперативное 1: shared_buffers — личный кэш Postgres
В обзорном посте про оперативку постгресса мы насчитали трёх «едоков» памяти. Начнём с первого: shared_buffers. Разберёмся, что это такое и почему он всегда выглядит занятым.
😂 Что это вообще
Как многие знают, Postgres не бегает на диск в каждом запросе. У него есть свой кэш — кусок оперативки, куда он складывает страницы (напомню, что это кусочки по 8 Kb), которые недавно понадобились, чтобы в следующий раз взять их из памяти. Вот этот кэш и есть shared_buffers.
Слово shared («общий») тут ключевое: буферы общие для всех соединений. Один запрос читает страницу с диска и кладет в shared_buffers, а следующий возьмёт её уже из памяти и диск не тронет.(Напомню, что даже на самых мощных SSD разница скорость чтения 10-20 микросекунд, тогда как из оперативки это 50-60 НАНОсекунд, то есть капец как дешево)
📏 Сколько его
Размер задаёт параметр shared_buffers, и фиксируется он при старте сервера. По умолчанию в Postgres это всего 128 MB — наследство времён, когда памяти было мало. На боевом сервере его обычно поднимают примерно до четверти всей оперативки. Текущее значение покажет команда SHOW shared_buffers;
⚙️ Почему он всегда «занят»
Эти 128 MB (или сколько ты выставил) Postgres резервирует под кэш сразу при запуске и держит за собой всё время работы. Поэтому в мониторинге shared_buffers всегда показывает себя занятой памятью. Это не утечка и не повод хвататься за сердце😰 : память заранее отведена под кэш и работает на тебя.
🔬 Что внутри
Что именно сейчас лежит в shared_buffers, показывает расширение pg_buffercache (его надо один раз подключить командой CREATE EXTENSION pg_buffercache).
На прогретой таблице users из миллиона строк (прогретой — значит по ней уже погоняли запросы, и её страницы успели осесть в кэше) у меня вышло так:
🟢 сама таблица заняла 47 MB
🟢 индекс по email — 39 MB
🟢 индекс первичного ключа — 21 MB.
Два индекса вместе съели больше кэша, чем данные! Это частый сюрприз: спрашиваешь «куда ушла память под базу», а ответ нередко оказывается простым — в индексы.
🅰️ Что унести с собой
🟢 shared_buffers — это собственный кэш Postgres в оперативке, общий для всех соединений.
🟢 Его размер фиксируется при старте: по умолчанию 128 MB, на проде обычно около четверти RAM.
🟢 Он всегда выглядит занятым, и это нормально: память заранее отведена под кэш.
🟢 Индексы живут в том же кэше, что и данные, и порой занимают даже больше места.
#бд #postgresql #инженерныештучки #heavywednesday
В обзорном посте про оперативку постгресса мы насчитали трёх «едоков» памяти. Начнём с первого: shared_buffers. Разберёмся, что это такое и почему он всегда выглядит занятым.
Как многие знают, Postgres не бегает на диск в каждом запросе. У него есть свой кэш — кусок оперативки, куда он складывает страницы (напомню, что это кусочки по 8 Kb), которые недавно понадобились, чтобы в следующий раз взять их из памяти. Вот этот кэш и есть shared_buffers.
Слово shared («общий») тут ключевое: буферы общие для всех соединений. Один запрос читает страницу с диска и кладет в shared_buffers, а следующий возьмёт её уже из памяти и диск не тронет.
📏 Сколько его
Размер задаёт параметр shared_buffers, и фиксируется он при старте сервера. По умолчанию в Postgres это всего 128 MB — наследство времён, когда памяти было мало. На боевом сервере его обычно поднимают примерно до четверти всей оперативки. Текущее значение покажет команда SHOW shared_buffers;
⚙️ Почему он всегда «занят»
Эти 128 MB (или сколько ты выставил) Postgres резервирует под кэш сразу при запуске и держит за собой всё время работы. Поэтому в мониторинге shared_buffers всегда показывает себя занятой памятью. Это не утечка и не повод хвататься за сердце
🔬 Что внутри
Что именно сейчас лежит в shared_buffers, показывает расширение pg_buffercache (его надо один раз подключить командой CREATE EXTENSION pg_buffercache).
На прогретой таблице users из миллиона строк (прогретой — значит по ней уже погоняли запросы, и её страницы успели осесть в кэше) у меня вышло так:
Два индекса вместе съели больше кэша, чем данные! Это частый сюрприз: спрашиваешь «куда ушла память под базу», а ответ нередко оказывается простым — в индексы.
🅰️ Что унести с собой
🟢 shared_buffers — это собственный кэш Postgres в оперативке, общий для всех соединений.
🟢 Его размер фиксируется при старте: по умолчанию 128 MB, на проде обычно около четверти RAM.
🟢 Он всегда выглядит занятым, и это нормально: память заранее отведена под кэш.
🟢 Индексы живут в том же кэше, что и данные, и порой занимают даже больше места.
#бд #postgresql #инженерныештучки #heavywednesday
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
Кажется, #ИИшница постепенно убирает естественные барьеры между работой и отдыхом 🚧
Раньше, если ты идешь обедать, то просто обедаешь, смотришь видосики🟥 , кайфуешь. Пока ешь — не пишешь код. Чтобы программировать, нужно сесть за компьютер и сосредоточиться.
Теперь можно есть и одновременно смотреть, как Клавдий😒 пишет код. Иногда что-то ему подсказать, написать пару строк самому, дать следующее задание — и снова вернуться к обеду. Вроде бы отдыхаешь, но одновременно работаешь.
Ещё появилась возможность упралять AI-агентом с телефона. Он выполняет задачи на твоём компьютере, пока ты находишься где угодно: на кухне, в постели, на скамейке в парке. В любой момент можно открыть телефон, дать новую команду, посмотреть результат, что-то поправить.
То же самое происходит и с другими паузами в течение дня. Раньше они были настоящими перерывами. Сейчас почти любой из них можно превратить в ещё несколько минут работы.
В результате появляется странный эффект😳
Кодить ты действительно начинаешь больше. Но полноценно отдыхать — меньше. Работа всегда находится на расстоянии одного сообщения. Даже сидя в кресле-коконе, ловишь себя на мысли, что думаешь не о том, как отвлечься и перезагрузиться, а о следующей задаче.
Не уверен, хорошо это или плохо. Наверняка правильный ответ, как обычно, "зависит". Возможно, мы просто учимся использовать время эффективнее.
Но есть ощущение, что эти «пустые» промежутки были нужны не просто так. Именно в них мозг успевал переключиться, а вместе с этим часто приходили новые идеи и решения⚡️
Похоже, теперь отдых тоже становится навыком, который надо уметь вовремя применить
Раньше, если ты идешь обедать, то просто обедаешь, смотришь видосики
Теперь можно есть и одновременно смотреть, как Клавдий
Ещё появилась возможность упралять AI-агентом с телефона. Он выполняет задачи на твоём компьютере, пока ты находишься где угодно: на кухне, в постели, на скамейке в парке. В любой момент можно открыть телефон, дать новую команду, посмотреть результат, что-то поправить.
То же самое происходит и с другими паузами в течение дня. Раньше они были настоящими перерывами. Сейчас почти любой из них можно превратить в ещё несколько минут работы.
В результате появляется странный эффект😳
Кодить ты действительно начинаешь больше. Но полноценно отдыхать — меньше. Работа всегда находится на расстоянии одного сообщения. Даже сидя в кресле-коконе, ловишь себя на мысли, что думаешь не о том, как отвлечься и перезагрузиться, а о следующей задаче.
Не уверен, хорошо это или плохо. Наверняка правильный ответ, как обычно, "зависит". Возможно, мы просто учимся использовать время эффективнее.
Но есть ощущение, что эти «пустые» промежутки были нужны не просто так. Именно в них мозг успевал переключиться, а вместе с этим часто приходили новые идеи и решения
Похоже, теперь отдых тоже становится навыком, который надо уметь вовремя применить
Please open Telegram to view this post
VIEW IN TELEGRAM
Последние три дня был в Самаре, приехал по делам.
Поймал себя на интересной мысли: каждый город можно представить как платформу. Если он реализует определённый интерфейс, то становится совместимым с моим образом жизни🥁🧑💻
Какие методы должны быть у такого интерфейса?
🔹
🔹
🔹 Ну и базовые методы вроде
Если все эти «эндпоинты» реализованы, то для меня город становится совместимым. Я могу жить в нём почти так же, как дома: работать, репетировать, отдыхать, не ломая привычный распорядок.
В прошлом году у меня было такое же ощущение в Батуми🇬🇪 Другой город, другая страна, но все нужные «ручки» оказались на месте. В итоге я продолжал работать в привычном режиме и почти не чувствовал, что нахожусь вдали от дома🏠
Получается, что я не так сильно привязан к конкретному месту. Скорее, я привязан к интерфейсу. Если новый город его реализует, то моя жизнь и работа просто продолжают выполняться без изменений✨
Поймал себя на интересной мысли: каждый город можно представить как платформу. Если он реализует определённый интерфейс, то становится совместимым с моим образом жизни🥁🧑💻
Какие методы должны быть у такого интерфейса?
🔹
RehearsalBase() — должна быть репетиционная база, чтобы можно было подготовиться к выступлению.🔹
Workspace() — место, где можно спокойно поработать: удобный стол, стабильный интернет (Wi-Fi или хороший мобильный): коворкинг или просто удачный номер в отеле.🔹 Ну и базовые методы вроде
Sleep() и Eat(). Без них тоже никуда.Если все эти «эндпоинты» реализованы, то для меня город становится совместимым. Я могу жить в нём почти так же, как дома: работать, репетировать, отдыхать, не ломая привычный распорядок.
В прошлом году у меня было такое же ощущение в Батуми🇬🇪 Другой город, другая страна, но все нужные «ручки» оказались на месте. В итоге я продолжал работать в привычном режиме и почти не чувствовал, что нахожусь вдали от дома
Получается, что я не так сильно привязан к конкретному месту. Скорее, я привязан к интерфейсу. Если новый город его реализует, то моя жизнь и работа просто продолжают выполняться без изменений
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4🫡1
❤2
Декомпозировать всё 🧩
Это уже не столько про #поиск_работы, сколько в целом про полезный навык💪
Не знаю, как в других профессиях, но в разработке часто встречается понятие декомпозиции — разделения одной большой задачи на множество маленьких. Это про то, что можно съесть слона по кусочкам🖥
В идеале, эти кусочки должны представлять собой инкремент (прирост) функциональности и измеряться какими-нибудь метриками📈
Когда я готовился к смене работы, этот подход помог мне подступиться к такой большое задаче и разделить её на несколько более простых и понятных:
🧩 написать резюме (инкремент: артефакт в виде резюме, метрика: наполненность ключевыми навыками)
🧩 регулярно откликаться на вакансии (инкремент: отклик, метрика: кол-во моих откликов и ответов на них)
🧩 последовательно освежать знания (инкремент: знания, метрика: насколько подробно и уверенно отвечаю на вопросы по теме: субъективно, но всё-таки измеримо)
Последний пункт тоже надо было декомпозировать: тем для повторения было много, поэтому я отсортировал их по уровню работы, от низкоуровневых (ОС, проц, память) до верхнеуровневых (архитектурные паттерны) и проходил одну за другой. Не пытался охватить всё сразу - просто двигался шаг за шагом👣
Точно так же, кстати, учу новые песни на барабанах🥁
Сначала разбираю основные ритмы, потом прорабатываю сложные места. Дальше размечаю структуру песни, и после этого собираю всё вместе. По сути, песня - это тоже набор небольших блоков: ритмы, сбивки, переходы, повторяющиеся паттерны. Когда каждый кусочек уже освоен, остаётся соединить их и отточить исполнение✨
Ещё декомпозиция зачастую является тем самым первым шагом, который надо сделать, чтобы подступиться к сложной задаче, после которой она уже не кажется такой большой и страшной😱
Иногда самый важный прогресс — это не сделать всю работу сразу, а правильно разделить её на части и составить план работы
Это уже не столько про #поиск_работы, сколько в целом про полезный навык
Не знаю, как в других профессиях, но в разработке часто встречается понятие декомпозиции — разделения одной большой задачи на множество маленьких. Это про то, что можно съесть слона по кусочкам
В идеале, эти кусочки должны представлять собой инкремент (прирост) функциональности и измеряться какими-нибудь метриками
Когда я готовился к смене работы, этот подход помог мне подступиться к такой большое задаче и разделить её на несколько более простых и понятных:
🧩 написать резюме (инкремент: артефакт в виде резюме, метрика: наполненность ключевыми навыками)
🧩 регулярно откликаться на вакансии (инкремент: отклик, метрика: кол-во моих откликов и ответов на них)
🧩 последовательно освежать знания (инкремент: знания, метрика: насколько подробно и уверенно отвечаю на вопросы по теме: субъективно, но всё-таки измеримо)
Последний пункт тоже надо было декомпозировать: тем для повторения было много, поэтому я отсортировал их по уровню работы, от низкоуровневых (ОС, проц, память) до верхнеуровневых (архитектурные паттерны) и проходил одну за другой. Не пытался охватить всё сразу - просто двигался шаг за шагом
Точно так же, кстати, учу новые песни на барабанах🥁
Сначала разбираю основные ритмы, потом прорабатываю сложные места. Дальше размечаю структуру песни, и после этого собираю всё вместе. По сути, песня - это тоже набор небольших блоков: ритмы, сбивки, переходы, повторяющиеся паттерны. Когда каждый кусочек уже освоен, остаётся соединить их и отточить исполнение
Ещё декомпозиция зачастую является тем самым первым шагом, который надо сделать, чтобы подступиться к сложной задаче, после которой она уже не кажется такой большой и страшной
Иногда самый важный прогресс — это не сделать всю работу сразу, а правильно разделить её на части и составить план работы
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1🔥1
Forwarded from C# Short Posts 🔞
🗄Оперативное 2: Кэш ОС — ещё один уровень кэша, которым Postgres не управляет
Второй едок памяти из обзорного поста — кэш операционной системы. Именно с ним связана классическая паника «на сервере с базой вся оперативка занята, памагити, ААА!»😂
📚 Откуда он берётся
shared_buffers — это кэш самого Postgres. Но есть ещё один уровень кэша, который живёт своей жизнью. Когда любая программа читает файл с диска, операционная система запоминает прочитанные блоки в свободной оперативке. В следующий раз тот же файл прилетит уже из памяти, без похода на диск. Этот общесистемный кэш называется страничным кэшем (или же page cache) 📃
Postgres читает свои файлы — и кучу с данными, и файлы индексов — как все, через операционную систему. Значит, его страницы попадают ещё и в кэш ОС. Получается двойное кэширование: одна и та же страница может одновременно лежать и в shared_buffers, и в страничном кэше ОС📄
🍽 Почему «вся память занята»
Операционная система не любит, когда оперативка простаивает впустую, поэтому забивает всё свободное место кэшем файлов. На Linux, например, при помощи утилиты🧠 )
Пугаться этого не нужно. Память под кэшем ОС считается освобождаемой. То есть, правильно говорить не «память кончилась», а «сейчас память используется под кэш, но как только она понадобится другому приложению, система тут же готова уступить оперативку по первому требованию, чесслово💯 »
🔗 read ≠ чтение с диска
Напомню, что в посте про чтение страниц мы видели в плане запроса слово
🅰️ Что унести с собой
🟢 Кроме кэша Postgres есть кэш операционной системы: он общий для всей машины, и Postgres им не управляет
🟢 Одна страница может лежать сразу в двух кэшах — это и есть двойное кэширование
🟢 Когда вся память используется под файловый кэш — это нормально: такая память освобождается по первому требованию других приложений
🟢
🧑💻dp🥁
#бд #postgresql #инженерныештучки #heavywednesday
Второй едок памяти из обзорного поста — кэш операционной системы. Именно с ним связана классическая паника «на сервере с базой вся оперативка занята, памагити, ААА!»
📚 Откуда он берётся
shared_buffers — это кэш самого Postgres. Но есть ещё один уровень кэша, который живёт своей жизнью. Когда любая программа читает файл с диска, операционная система запоминает прочитанные блоки в свободной оперативке. В следующий раз тот же файл прилетит уже из памяти, без похода на диск. Этот общесистемный кэш называется страничным кэшем (или же page cache) 📃
Postgres читает свои файлы — и кучу с данными, и файлы индексов — как все, через операционную систему. Значит, его страницы попадают ещё и в кэш ОС. Получается двойное кэширование: одна и та же страница может одновременно лежать и в shared_buffers, и в страничном кэше ОС
🍽 Почему «вся память занята»
Операционная система не любит, когда оперативка простаивает впустую, поэтому забивает всё свободное место кэшем файлов. На Linux, например, при помощи утилиты
free (которая показывает, как используется ОЗУ и пространство подкачки (swap) в системе) зачастую можно увидеть, что свободной памяти почти не осталось, а здоровенный кусок помечен как buff/cache (если, конечно, в системе активно происходит чтение файлов Пугаться этого не нужно. Память под кэшем ОС считается освобождаемой. То есть, правильно говорить не «память кончилась», а «сейчас память используется под кэш, но как только она понадобится другому приложению, система тут же готова уступить оперативку по первому требованию, чесслово
🔗 read ≠ чтение с диска
Напомню, что в посте про чтение страниц мы видели в плане запроса слово
read — «страницы не было в shared_buffers, пришлось дочитывать». Там же мы выяснили, что read не обязательно означает поход на диск: страница вполне могла быть прочитана из кэша ОС. Поэтому read иногда оказывается почти таким же быстрым, как hit (чтение из shared_buffers, то есть, по сути, тоже из оперативки).🅰️ Что унести с собой
🟢 Кроме кэша Postgres есть кэш операционной системы: он общий для всей машины, и Postgres им не управляет
🟢 Одна страница может лежать сразу в двух кэшах — это и есть двойное кэширование
🟢 Когда вся память используется под файловый кэш — это нормально: такая память освобождается по первому требованию других приложений
🟢
read в плане запроса значит «не нашлось в shared_buffers», а не обязательно прочитано с диска»🧑💻dp🥁
#бд #postgresql #инженерныештучки #heavywednesday
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4
This media is not supported in your browser
VIEW IN TELEGRAM
Продолжаю нерегулярную рубрику лайфхаков для барабанщиков 🥁
Рассказываю важный и полезный лайфхак про барабанный стул🪑 , смотри до конца👆
Рассказываю важный и полезный лайфхак про барабанный стул
Please open Telegram to view this post
VIEW IN TELEGRAM
😁4🔥1
#RocknMob в Москве состоится 22 августа!
Москва, Северный речной вокзал, 14:00
Сет-лист:
PINK FLOYD – Another Brick in the Wall
BLACK SABBATH – Paranoid
LINKIN PARK – The Emptiness Machine
БРАВО – Любите девушки
Для участия регистрируйся по ссылке:
https://rocknmob.com/rocknmob-moscow-12/
#движ
Москва, Северный речной вокзал, 14:00
Сет-лист:
PINK FLOYD – Another Brick in the Wall
BLACK SABBATH – Paranoid
LINKIN PARK – The Emptiness Machine
БРАВО – Любите девушки
Для участия регистрируйся по ссылке:
https://rocknmob.com/rocknmob-moscow-12/
#движ
🔥1
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3😱2❤1