This media is not supported in your browser
VIEW IN TELEGRAM
🎓 Июнь - время защит в учебных заведениях.
И я хотел вам сказать, что на презентации лучше показывать заранее записанное видео работы программы вместо того, чтобы запускать саму программу... Но потом вспомнил, как у меня однажды и видео не завелось 😅
Поэтому нечего мне вам посоветовать 🤭
А у вас случались факапы на презентациях?
😁 - ага
👍 - нет, повезло
🤷♂️ - не выступал
И я хотел вам сказать, что на презентации лучше показывать заранее записанное видео работы программы вместо того, чтобы запускать саму программу... Но потом вспомнил, как у меня однажды и видео не завелось 😅
Поэтому нечего мне вам посоветовать 🤭
А у вас случались факапы на презентациях?
😁 - ага
👍 - нет, повезло
🤷♂️ - не выступал
😁6👍4🤷♂1
Остаться в живых... после увольнения
Немного необычный пост. Эта информация, наверное, не пригодится ни мне, ни вам. Но будем знать 🙂
Дочитал недавно книгу Беккера "Дар страха". Это одна из тех, которые про выживание.
Информации там много, но остановимся на увольнении.
Увольнение сопровождается стрессом. Стрессом для обеих сторон. Хорошо, когда работник увольняется сам, а работодатель не против.
Но если есть конфликт?
Мне случалось увольняться, когда работодатель не хотел отпускать, и увольнять, когда сотрудник не хотел уходить. И это точно не то, что хотелось бы повторять.
Но Беккер рассматривает гораздо более сложные ситуации, когда увольняемый... себе на уме, опасный. Когда от него исходит явная угроза жизни и здоровью: как для бывшего руководителя, так и для оставшихся коллег. В книге описано много жутких примеров, даже не хочется их приводить.
Какого-то универсального способа увольнения опасного сотрудника Беккер не дает. Но описывает целый ряд правил, которые могут снизить вероятность нежелательных последствий.
Вот выжимка:
- Увольнять сразу, не растягивать процесс увольнения (испытательным сроком, например).
- Увольнять в конце дня и в конце недели, чтобы человек пошел домой как обычно, а не оказался дома в непривычное для себя время.
- Быть максимально прямым и не вести переговоры, не читать лекции при увольнении. Уже поздно для нотаций.
- Говорить о будущем, не говорить о прошлом.
- Лучше, чтобы увольнял не прямой начальник, а кто-то повыше.
- Брать на увольнение кого-то из руководства, кто в хороших отношениях с увольняемым, чтобы тот чувствовал себя спокойнее и постеснялся вести себя некорректно.
- Не брать на увольнение охрану, полицию и т.п.
Список не полный, но суть, думаю, ясна. Повторюсь, по большей части это касается увольнения опасных сотрудников.
Теперь знаете, куда при случае сходить за советом)
А у меня всё, и так вас утомил 😉
—
📍 Гэвин де Беккер - Дар страха. Как распознавать опасность и правильно на нее реагировать
#КнижнаяПолка
Немного необычный пост. Эта информация, наверное, не пригодится ни мне, ни вам. Но будем знать 🙂
Дочитал недавно книгу Беккера "Дар страха". Это одна из тех, которые про выживание.
Информации там много, но остановимся на увольнении.
Увольнение сопровождается стрессом. Стрессом для обеих сторон. Хорошо, когда работник увольняется сам, а работодатель не против.
Но если есть конфликт?
Мне случалось увольняться, когда работодатель не хотел отпускать, и увольнять, когда сотрудник не хотел уходить. И это точно не то, что хотелось бы повторять.
Но Беккер рассматривает гораздо более сложные ситуации, когда увольняемый... себе на уме, опасный. Когда от него исходит явная угроза жизни и здоровью: как для бывшего руководителя, так и для оставшихся коллег. В книге описано много жутких примеров, даже не хочется их приводить.
Какого-то универсального способа увольнения опасного сотрудника Беккер не дает. Но описывает целый ряд правил, которые могут снизить вероятность нежелательных последствий.
Вот выжимка:
- Увольнять сразу, не растягивать процесс увольнения (испытательным сроком, например).
- Увольнять в конце дня и в конце недели, чтобы человек пошел домой как обычно, а не оказался дома в непривычное для себя время.
- Быть максимально прямым и не вести переговоры, не читать лекции при увольнении. Уже поздно для нотаций.
- Говорить о будущем, не говорить о прошлом.
- Лучше, чтобы увольнял не прямой начальник, а кто-то повыше.
- Брать на увольнение кого-то из руководства, кто в хороших отношениях с увольняемым, чтобы тот чувствовал себя спокойнее и постеснялся вести себя некорректно.
- Не брать на увольнение охрану, полицию и т.п.
Список не полный, но суть, думаю, ясна. Повторюсь, по большей части это касается увольнения опасных сотрудников.
Теперь знаете, куда при случае сходить за советом)
А у меня всё, и так вас утомил 😉
—
📍 Гэвин де Беккер - Дар страха. Как распознавать опасность и правильно на нее реагировать
#КнижнаяПолка
🤯3🤔2😁1
#include <iostream>
void foo(int& value1, const int& value2) {
value1 += value1 + value2;
}
int main() {
int a = 1, b = 2;
foo(a, b);
std::cout << a << b << std::endl;
return 0;
}
Вместо latex - typst
Да и вместо markdown, чего уж там! 😅
Начал на выходных собирать руководство пользователя для нового релиза YouTube Analyzer. Раньше делал всё тупо в Google Docs. Большего и не нужно было. Но проект развивается и стало скучно в очередной раз собирать юзер-гайд в гуглодоках.
Рассматривал изначально только latex и markdown. С ними в основном и работал. Но где-то у кого-то услышал про typst и... мне понравилось)
Действительно, typst - это что-то между latex и markdown. Не очень сложно, но и не очень просто. Можно работать через плагин в VS Code. Превью шустро генерируется на ходу, различий по скорости с превью markdown не заметил. Но, справедливости ради, документ у меня пока маленький, десятка два страниц.
Планирую записать видео с подробностями. Надо зафиксировать знание. Покажу как работать с текстом, как организовать структуру, а может и выложу шаблон, почему бы и да 😉
А вы где свою документацию пишете?
—
📍 Typst: Compose thesespapers faster
Да и вместо markdown, чего уж там! 😅
Начал на выходных собирать руководство пользователя для нового релиза YouTube Analyzer. Раньше делал всё тупо в Google Docs. Большего и не нужно было. Но проект развивается и стало скучно в очередной раз собирать юзер-гайд в гуглодоках.
Рассматривал изначально только latex и markdown. С ними в основном и работал. Но где-то у кого-то услышал про typst и... мне понравилось)
Действительно, typst - это что-то между latex и markdown. Не очень сложно, но и не очень просто. Можно работать через плагин в VS Code. Превью шустро генерируется на ходу, различий по скорости с превью markdown не заметил. Но, справедливости ради, документ у меня пока маленький, десятка два страниц.
Планирую записать видео с подробностями. Надо зафиксировать знание. Покажу как работать с текстом, как организовать структуру, а может и выложу шаблон, почему бы и да 😉
А вы где свою документацию пишете?
—
📍 Typst: Compose thesespapers faster
Баллы на ЕГЭ
Видел в сети посты от школьников, расстраивающихся своими результатами ЕГЭ. Основной посыл:
"Я писал пробники на 80+ баллов, а в итоге вытянул только на 75. Жуть какой сложный экзамен".
И с одной стороны да, для поступления каждый балл на счету. Но с другой стороны, отклонение по баллам не такое уж и большое. Около 10%.
Сейчас объясню ⤵️
🏎 Аналогия из кольцевого автоспорта. Мы наматываем круги по треку. Каждый пройденный круг - это попытка, результатом которой является время. И если посмотреть на разброс времени круга при каждой попытке, то можно убедиться, что там мало стабильности.
Из личного опыта. Заезды на дорожной машине очень стабильные. На 3 боевых круга разброс бывает в пределах 1%. А вот если взять картинг, то там "болтанка" времени круга увеличивается до 5% и выше. Дорожная машина мягче и дает больше шансов исправить ошибку. А картинг жёсткий. Из-за этого потеря управления происходит резко и развивается стремительно.
И вот представьте, что попытки в практически не меняющихся условиях на треке дают разброс результата до 5%. Что же говорить про ЕГЭ, где каждая попытка - это большое количество новых условий, влияющих на результат?
Это как выехать на новый трек и, изучив только его схему, с первого круга попытаться показать хорошее время... Только нужно добавить еще сильный стресс. Например, если попытка не удастся, то на год станешь пешеходом 😅
Поэтому на мой взгляд, писать пробники на 85, а потом реальный экзамен сдать на 75 - это ок. Дай этому же человеку еще пару попыток и он точно выскочит за 80 баллов)
Но реальность другая. Попытка одна и каждый балл на счету.
—
Помню, я в свое время как писал пробники ЕГЭ середнячком, так и экзамены сдал. Без потрясений.
Видел в сети посты от школьников, расстраивающихся своими результатами ЕГЭ. Основной посыл:
"Я писал пробники на 80+ баллов, а в итоге вытянул только на 75. Жуть какой сложный экзамен".
И с одной стороны да, для поступления каждый балл на счету. Но с другой стороны, отклонение по баллам не такое уж и большое. Около 10%.
Сейчас объясню ⤵️
🏎 Аналогия из кольцевого автоспорта. Мы наматываем круги по треку. Каждый пройденный круг - это попытка, результатом которой является время. И если посмотреть на разброс времени круга при каждой попытке, то можно убедиться, что там мало стабильности.
Из личного опыта. Заезды на дорожной машине очень стабильные. На 3 боевых круга разброс бывает в пределах 1%. А вот если взять картинг, то там "болтанка" времени круга увеличивается до 5% и выше. Дорожная машина мягче и дает больше шансов исправить ошибку. А картинг жёсткий. Из-за этого потеря управления происходит резко и развивается стремительно.
И вот представьте, что попытки в практически не меняющихся условиях на треке дают разброс результата до 5%. Что же говорить про ЕГЭ, где каждая попытка - это большое количество новых условий, влияющих на результат?
Это как выехать на новый трек и, изучив только его схему, с первого круга попытаться показать хорошее время... Только нужно добавить еще сильный стресс. Например, если попытка не удастся, то на год станешь пешеходом 😅
Поэтому на мой взгляд, писать пробники на 85, а потом реальный экзамен сдать на 75 - это ок. Дай этому же человеку еще пару попыток и он точно выскочит за 80 баллов)
Но реальность другая. Попытка одна и каждый балл на счету.
—
Помню, я в свое время как писал пробники ЕГЭ середнячком, так и экзамены сдал. Без потрясений.
👍2
Нужно ли рисовать указатели и ссылки в UML?
❌ Нет, не нужно.
UML (Unified Modeling Language) - это язык моделирования. С его помощью создается модель, схема, проект, но никак не реализация.
В UML мы работаем исключительно в пределах объектной модели. Не надо перегружать диаграммы реализацией в деталях языка программирования.
В C++ такими деталями могут быть:
- указатели,
- ссылки,
- ключевые слова
- специфика стандартной библиотеки и т.п.
Я обычно исхожу из того, что моя UML-диаграмма, например, классов должна быть реализуема на любом языке программирования с поддержкой ООП. А где взять указатели в том же python? Правильно, нет их там. Поэтому и на диаграмме они не нужны.
Но, честно говоря, я нет-нет да и влеплю бывает какую-нибудь закорючку
—
Работаете с UML?
🔥 - ага
👍 - нет, я код пишу
🤷♂️ - эээ, ничего не понятно, но очень интересно
UML (Unified Modeling Language) - это язык моделирования. С его помощью создается модель, схема, проект, но никак не реализация.
В UML мы работаем исключительно в пределах объектной модели. Не надо перегружать диаграммы реализацией в деталях языка программирования.
В C++ такими деталями могут быть:
- указатели,
- ссылки,
- ключевые слова
const, override, explicit ...,- специфика стандартной библиотеки и т.п.
Я обычно исхожу из того, что моя UML-диаграмма, например, классов должна быть реализуема на любом языке программирования с поддержкой ООП. А где взять указатели в том же python? Правильно, нет их там. Поэтому и на диаграмме они не нужны.
Но, честно говоря, я нет-нет да и влеплю бывает какую-нибудь закорючку
& на схему 😁 Привычка, чтоб её...—
Работаете с UML?
🔥 - ага
👍 - нет, я код пишу
🤷♂️ - эээ, ничего не понятно, но очень интересно
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6🤷♂1
🔼 Разнёс варианты ответов как можно дальше во времени, чтобы легче было отвечать навскидку.
Как справились?
🔥 - 100% успех
👍 - частичный успех
🤷♂️ - всё мимо
Как справились?
🔥 - 100% успех
👍 - частичный успех
🤷♂️ - всё мимо
👍8🔥4
Нужно ли указывать virtual для переопределенного метода в C++?
❌ Не нужно.
Сейчас объясню.
Иногда встречаю код по такому шаблону:
🔼 Здесь в классе-наследнике
Ничего криминального в этом нет, код корректно сработает. Но слово
Когда-то давным-давно, когда в стандарте не было
С появлением
—
Мало C++? Тогда можно вспомнить про литералы
Сейчас объясню.
Иногда встречаю код по такому шаблону:
class Base
{
public:
virtual void func() { /* ... */ }
};
class Derived : public Base
{
public:
virtual void func() override { /* ... */ }
};
🔼 Здесь в классе-наследнике
Derived у переопределенного метода func() повторно указан virtual.Ничего криминального в этом нет, код корректно сработает. Но слово
virtual здесь лишнее. Никакой смысловой нагрузки оно не несёт.Когда-то давным-давно, когда в стандарте не было
override, повторное указание virtual было оправдано. Просто так легче читать. Сразу видно, что метод виртуальный.С появлением
override необходимость в этом отпала. Слово virtual нужно указывать один раз в базовом классе метода. Вот так ⤵️class Base
{
public:
virtual void func() { /* ... */ }
};
class Derived : public Base
{
public:
void func() override { /* ... */ }
};
—
Мало C++? Тогда можно вспомнить про литералы
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
Выше дан код C++. Какой вывод будет у программы?
Anonymous Quiz
17%
(1, 1) (2, 2)
72%
(1, 2) (2, 4)
11%
(1, 2) (3, 4)
0%
(1, 2) (3, 6)
Синтаксис или семантика
Синтаксис — это правила языка, его орфография.
Семантика — это смысл кода, его логика.
Если написать одну и ту же программу на разных языках программирования, то синтаксически код будет разным, но семантически - одинаковым.
Оба термина можно встретить в контексте статического анализа кода. Анализаторы, благодаря строгим правилам языка, легко находят синтаксические ошибки. Сематические ошибки найти сложнее. Например, здесь в C++:
🔼 Синтаксически вопросов нет. Но по смыслу это операция присваивания, а не сравнения. Но может быть программист как раз и хотел присваивать? Не понятно. И в этом сложность.
—
Ранее в сериале #Словарь 👉 Эмулятор или симулятор
Синтаксис — это правила языка, его орфография.
Семантика — это смысл кода, его логика.
Если написать одну и ту же программу на разных языках программирования, то синтаксически код будет разным, но семантически - одинаковым.
Оба термина можно встретить в контексте статического анализа кода. Анализаторы, благодаря строгим правилам языка, легко находят синтаксические ошибки. Сематические ошибки найти сложнее. Например, здесь в C++:
if ( x = 5 )
// ...
🔼 Синтаксически вопросов нет. Но по смыслу это операция присваивания, а не сравнения. Но может быть программист как раз и хотел присваивать? Не понятно. И в этом сложность.
—
Ранее в сериале #Словарь 👉 Эмулятор или симулятор
👍2
Почему в CLI есть короткие и длинные ключи
При работе с командной строкой вы наверняка замечали, что у многих опций есть два формата:
- Короткий (например,
- Длинный (например,
🔸 Зачем это нужно?
Очевидно, что короткие ключи (
Длинные ключи (
Пример:
🔸 Тогда какой вариант использовать?
Короткие ключи используем при непосредственной работе с командной строкой. Здесь важна скорость и удобство.
Длинные ключи используем в скриптах. Скрипты, как и другой код, мы чаще читаем, чем пишем. Поэтому лучше, чтобы наша "писанина" была понятной.
—
В тему CLI еще можно вспомнить про путаницу в командах git.
При работе с командной строкой вы наверняка замечали, что у многих опций есть два формата:
- Короткий (например,
-h) - Длинный (например,
--help) 🔸 Зачем это нужно?
Очевидно, что короткие ключи (
-h, -v) обеспечивают быстрый ввод. При частом использовании самое то.Длинные ключи (
--help, --version) уже быстро не введешь, но они более понятные и читаемые.Пример:
# Короткая запись
ls -l
# Длинная запись
ls --format=long
🔸 Тогда какой вариант использовать?
Короткие ключи используем при непосредственной работе с командной строкой. Здесь важна скорость и удобство.
Длинные ключи используем в скриптах. Скрипты, как и другой код, мы чаще читаем, чем пишем. Поэтому лучше, чтобы наша "писанина" была понятной.
—
В тему CLI еще можно вспомнить про путаницу в командах git.
❤3
А Филосо́ф - Без огурцов
У Крылова есть басня "Философ и огородник", где мужик-огородник сажает огурцы, а философ-огородник над ним смеется, мол, не по науке всё. Но пока философ читает книжки, думает, прикидывает и вымеряет, огородник - работает на земле. В итоге "у огородника взошло всё и поспело", "а философ - без огурцов".
🔽
Не знаю как вы, но я постоянно балансирую между "философом" и "огородником". Хочется посидеть, подумать как лучше, чтобы раз - и готово. Но опыт говорит: "Делай!"
Фишка в том, что разработка - это сложно. Редко получается учесть всё сразу. Да и получается ли вообще? Нет, позитивный сценарий возможен, если текущая задача очень похожа на какую-то из предыдущих. Но так бывает не всегда. А в инновациях - практически никогда. Поэтому приходится думать, планомерно превращаясь в "философа" и рискуя "огурцами".
Конечно, "философ" и "огородник" - это крайности. А в нашем интеллектуальном труде нужен баланс.
💡 Зная о своей склонности пофилософствовать, я стараюсь балансировать, придерживаясь цикла: "подумал - сделал - оценил". И чем короче цикл, тем лучше.
Да, после оценки будут коррекции. Да, какие-то идеи не прокатят. Да, из-за этого будет казаться, что если бы подольше подумал, то получше бы придумал...🙄 Не придумал бы. Лучшая идея как раз и пришла в голову от того, что предыдущую ты уже попробовал и оценил.
Поэтому когда в очередной раз повиснете в мыслях над своей лучшей задачей, вспомните про "филосо́фа - без огурцов" и спокойно переходите к делу 😉
—
Текст басни оставил в комментах. Палец вверх тому, кто найдет строки про навязчивое желание переписать проект на новомодную технологию!
#КнижнаяПолка
У Крылова есть басня "Философ и огородник", где мужик-огородник сажает огурцы, а философ-огородник над ним смеется, мол, не по науке всё. Но пока философ читает книжки, думает, прикидывает и вымеряет, огородник - работает на земле. В итоге "у огородника взошло всё и поспело", "а философ - без огурцов".
🔽
Не знаю как вы, но я постоянно балансирую между "философом" и "огородником". Хочется посидеть, подумать как лучше, чтобы раз - и готово. Но опыт говорит: "Делай!"
Фишка в том, что разработка - это сложно. Редко получается учесть всё сразу. Да и получается ли вообще? Нет, позитивный сценарий возможен, если текущая задача очень похожа на какую-то из предыдущих. Но так бывает не всегда. А в инновациях - практически никогда. Поэтому приходится думать, планомерно превращаясь в "философа" и рискуя "огурцами".
Конечно, "философ" и "огородник" - это крайности. А в нашем интеллектуальном труде нужен баланс.
Да, после оценки будут коррекции. Да, какие-то идеи не прокатят. Да, из-за этого будет казаться, что если бы подольше подумал, то получше бы придумал...
Поэтому когда в очередной раз повиснете в мыслях над своей лучшей задачей, вспомните про "филосо́фа - без огурцов" и спокойно переходите к делу 😉
—
Текст басни оставил в комментах. Палец вверх тому, кто найдет строки про навязчивое желание переписать проект на новомодную технологию!
#КнижнаяПолка
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4