а вот вам любопытное – бенчмарк веб-серверов https://www.techempower.com/benchmarks/

ищите свой любимый фреймворк, берите названия фреймворков для изучения и тыканья в них палочкой. но имейте ввиду: там есть не все. как минимум, там просят добавить некий плюсовый Drogon, которого в бенчмарке нет

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

#benchmark #link #webServer

немного полезностей вам

говорить ниже будем про Линукс/Мак

бывают такие команды, которые я вам рекомендую НЕ сохранять в истории. например, ввод пароля в открытом виде

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

history

и увидев ваш пароль

небольшое отвлечение: в целом, конечно же, лучше вообще не передавать пароли в утилиты/скрипты в открытом виде. предпочитайте этому промпты самих утилит, тк обычно они вообще не отображают их на экране

ну например, вместо изменения пароля пользователя в постгре таким способом

ALTER USER <user_name> WITH PASSWORD ‘<password>’;

используйте команду внтури psql

sudo -u postgres psql

postgres=# \password postgres

ну так вот, если все же вам приходится отдавать пароль в голом виде, то начните команду с пробела. и тогда она не будет сохранена в истории 😉

вот такой лайфхак. проверяйте!

#terminal #hint #security #postgresql

какая гадость эта ваша динамическая типизация… 😅

#humour #python

захотелось мне что-то пофилософствовать и порассуждать про работу по найму. на самом деле, размышления на эту тему были еще в прошлом году, и вот сейчас созрел поделиться

в общем, речь пойдет про вопрос «когда пора уходить из компании?»

помимо привычного ряда причин я задумался над одной не самой очевидной…

когда тебе нечему научиться у коллег

как так получается? очень просто. обычно ты чему-то постоянно учишься у коллег

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

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

когда сеньор, начинаешь учиться у тим-лида декомпозировать, оценивать сроки, давать задачи джунам и помогать мидлам, смотришь, как он разруливает конфликты, как ведет митинги, как ведет себя в команде, коммуницирует, и все также прокачиваешь технические скилы. у того же тим-лида или архитектора учишься дизайнить АПИ, интегрироваться со сторонними системами и соседними командами

когда ты тим-лид, ты учишься у коллег тим-лидов решать тим-лидские вопросы: в основном по коммуникациям внутри команды, разруливать сложные ситуации в межличностных отношениях, увольнять, нанимать, строить планы на команду и взаимодействовать с соседними отделами, планировать с другими тим-лидами общую активность. у юнит-лида или Head of R&D учишься планировать в долгосрок, разруливать сложные проектные треугольники «время-качество-деньги», знакомишься с ФОТом и бюрократией, учишься мыслить стратегически на горизонте 3-5 лет

когда ты Head of R&D или CTO, ты учишься уже у собственника бизнеса или топ-менеджмента: здесь больше про бизнес, переговоры, освоение рынка, занятие новых ниш, куда двигаются технологии и индустрия, как управлять большим «кораблем» с огромным экипажем, когда одно твое движение даст видимую отдачу через месяцы, учишься ждать и принимать решения, которые скажутся на N людях…

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

и вот тут получается тупик. и тогда понимаешь – тут дальше уже бессмысленно

#работа #философия

о полезности чтения чужих исходников

я кажется уже упомниал, что крайне полезно читать чужой код. благо, его как говна за баней очень много на ГитХабе: по любой тематике, любого качества, на любом языке

через это ты не только учишься быстро понимать и вникать в код (а это тоже навык), но самое главное – можешь учиться новому (к вопросу про мой предыдущий пост, кстати☝️), перенимать какие-то фишки, приемчики или даже узнавать новые конструкции языка или используемые бибилиотеки. ну а где-то, наоборот, можешь понять, почему ты бы написал лучше и чем данный код плох, какие есть минусы и почему его сложно читать (=поддерживать)

это, кстати, касается и код-ревью: важно читать и перенимать чужой опыт и фишечки написания кода

так вот… читаю я сегодня на досуге код OpenShot (это такой видеоредактор). а что примечательно – его ГУЕвая часть написана на связке Python+Qt

читаю-читаю, и натыкаюсь в разделе инициализации логов на такую конструкцию:

#
# Create rotating file handler
#
if os.path.exists(info.USER_PATH):
    fh = logging.handlers.RotatingFileHandler(
             os.path.join(info.USER_PATH, 'openshot-qt.log'),
             encoding="utf-8",
             maxBytes=25*1024*1024, backupCount=3)
    fh.setLevel(info.LOG_LEVEL_FILE)
    fh.setFormatter(file_formatter)
    log.addHandler(fh)
else:
    class DummyHandler:
        def setLevel(self, level):
            return True
    fh = DummyHandler()

и узнаю, что в питоне, оказывается, из коробки есть log rotation (об этом в другой раз; вкратце, это когда лог пишется до определенного момента в файл, после чего начинает писаться в следующий файл, чтобы файлы не разрастались)

поглядел в доке: так там целая поляна всевозможных лог хендлеров, от null до отправления UDP-датаграмм

так что в очередной раз даю совет: читайте чужой код!

#python #log #sourceCode #опыт

кто недавно присоединился, вот рекомендую посмотреть интересный пост, где на коленке накидан производственный календарь на голом HTML и нативном питоновском веб-сервере

только что проверил – для текущего года тоже работает 😃

жиза

#scrum #humour

… а вообще, хочется в очередной раз сказать, что Scrum, как и в целом Agile – это в первую, и самую главную, очередь, про изменение подхода в голове! это про иной майндсет и другое восприятие разработки! это про более высокий уровень зрелости команды 🚀

а всякие формальности вроде настройки доски в Джире, количество столбцов и переходы между статусами – это 100500-е дело…

жаль, что очень многие этого не понимают и гордо заявляют «у нас Скрам», продолжая работать в проектом подходе. а еще многие воротят нос и жалуются на свой скрам, где он на самом деле неправильный и превращен в формальности (например, отчитаться на дейлике 🤮)

#scrum

CTO vs. VP Engineering

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

казалось бы: две таких похожих должности и вроде про одно и то же 🤷‍♂️ однако, есть разница

CTO отвечает за стратегическое развитие компании в плане технологий и направления движения разработки. он своего рода двигатель и идейный вдохновитель технической и продуктовой стороны компании. он понимает тренды развития технологий и с учетом этого выстраивает стратегию развития компании и направляет компанию в разрезе средне- и долгосрочного планирования

зачастую CTO стоит у истоков компании и является одним из основателей и учредителей. да, в крупных и очень крупных компаниях, корпорациях все больше вероятность, что это будет и наемный человек совсем со стороны

VP Engineering же, находясь под CTO, занимается вопросами деливери, соблюдения сроков, оценки производительности команд и пипл-менеджментом. то есть он скорее про более «приземленные» вещи. однаяко, при этом его роль очень высока и он конечно точно также планирует работу всех команд и отделов

проще говоря, CTO отвечает за куда, тогда как VP Engineering – за как и в срок

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

также, оба эти человека дополняют друг друга и плотно взаимодействуют друг с другом

зачастую в стартапах, ессно, есть только CTO, который выполняет обе роли. роль же VP Engineering уместна обычно в больших компаниях с сотнями и тысячами разработчиков/тестировщиков/прочих ИТ-спецов

вот такой сегодня у меня рассказ о том, какие бывают роли (очень высокие роли) в мире разработки ПО

#management #career #roles #профессии #cLevel

создал организацию в ГитХабе для учебных проектов, которые бы лежали не как сейчас, в одной репе, а каждый проект – в отдельной репе в рамках одной группы

велком смотреть 🙌 скоро будет наполняться 🚀

https://github.com/The-Real-Coding

#gitHub #news

как-то так может выглядеть по мнению ИИ логотип для компании test.it 🤔

что ж… допустим…

#humour #ai

человек вон с 69-го в ГитХаб контрибьютит ☝️

пишите в коментах свои догадки, в чем тут дело

кто хочет сам проверить – https://github.com/rcarmo?tab=overview&from=1969-12-01&to=1969-12-31

#gitHub #fun #bug

неплохо JetBrains придумали – дают готовый шаблон обращения к тимлиду за тебя, чтобы обосновать приобретение ИДЕ

#jetBrains #ide

Напомню про еще один тематический канал, куда дропнул первую запись – про медиа и все с этим связанное

Подписывайтесь, делитесь, если есть интерес 🙌

Выпилился недавно полностью с запрещенной в РФ соцсети для самолюбования и выеживания перед друзьями, равно как и из вэкашки

Вместо этого есть такой @dipaolo_live мой канальчик с моими мыслям и разным жизненным за пределами ИТ

#неТехническое

Со всех щелей слышу про ентот ваш Vibe Coding… ох уж эти зумеры 😅

Признавайтесь, вайбкодите? Как впечатление?