Личное мнение - идти в тимлиды - тупиковая ветвь развития для программиста. Зачастую, ищут тимлида, где Продакт менеджер не обладает техническими компетенциями. Пришел из бизнеса. За клиента. Но проблема с базой: метрикой, инструментами, процессами разработки, безопасность кода и инфраструктуры, сети, почему мы должны платить за git/intellij/любой-инструмент-который-делает-процесс-разработки-быстрее. А еще каждый раз доказывать ему, что ты не шланг, так как на выходных, друг или родственник айтишник, рассказал, что в другой компании, они все делают по другому.
Лучше всего, развиваться как Senior Dev. Не тот синьор-помидор, который за 3 года и в лиды. Синьором и на пенсию выйти не стыдно. А еще быть таким Синьором, который может мотивировать и вести за собой команду, погрузится в предметную область, контрибьютить в библиотеки с которыми работает, может декомпозировать задачи - одним словом, быть 10х Dev, который просто на опыте и на мудрости спасает команду, мыслит вне рамки кода.
И новую работу найти будет просто. Искать не надо. Такого рекомендовать будут всегда. И удовольствие от работы больше, так как четко понимаешь, за какой фронт работы несешь ответственность, и где твои результаты.
Если же “Блин, мне надо сделать столько дел, а я валяюсь на диване” и ничего не может с этим поделать — то это прокрастинация
Прокрастинация, это не когда лежишь на диване, вместо дел, а моешь посуду, чинишь стул, стираешь шторы, наводишь порядок на книжной полке, сортируешь заметки по Алфавиту, затем по темам, оптимизируешь свой гардероб, одним словом, занимаешься чем угодно, но не работой, которую надо сделать.
Соглашусь с комментаторами - автор собрал компиляцию из интернета, даже не погрузившись в проблему.
Если же делиться опытом, то никогда нельзя себя награждать за работу. Иначе, уровень дофамина будет расти и расти, и со временем, чтобы сделать маленькую работу, подправить конфиг, сверстать что-то, поменять скрипт - уровень награждения (дофамина) будет неподъемным для организма, ибо результат такой мелочной работы - низкий. И от этого и копится прокрастинация!
Решение? Учиться просто работать. Получать удовольствие от процесса работы. Не награждать себя. Покупать всякие приятные штучки как новые наушники, просто ни за что, рандомно. Все.
Если прочитать статьи оригиналы про увольнения в Твиттер, там как раз пишут, что сократили на 90% Штат в Индии. А это как раз модераторы контента. Ручной труд. Который никак не имеет отношения к айти сектору
Если прочитать статью, то можно увидеть, что под сокращение попало 50% сотрудников, но не программисты в первую очередь. Учитывая что пошел под нож штат в Азии, Индии, Канаде и тд - то режут именно модераторов. Которых можно заменить ИИ. Тогда не будет персональных банов (Трамп), а все будут решать алгоритмы.
Часто встречаю туториалы по OAuth2. Но, не показываются альтернативные способы авторизации. Что еще можно использовать, если предпологается наличие SPA и нативное мобильного клиента?
да что вы все во круг айти так замкнулись. не будем говорить о медиках. вы видели ставки юристов? вот упоминаете, что в других странах, у айтишников не топ ЗП. возьмём Австрию. или похожею европейскую страну, с лютой бюрократией. там адвокаты, чтобы просто составить бумагу и подписать, берут лютые деньги. а про бухгалтеров молчу. в Британии удивляются, что у нас в СНГ, очень много бухгалтеров - женщины. говорят, как так? это же сложная работа! на самом деле, не столько как сложная, а доходная.
«Я придумал термин «объектно-ориентированный», и могу сказать, что я не имел в виду С++». Алан Кэй, конференция OOPSLA, 1997.
«Я сожалею о том, что давным-давно придумал термин «объекты» для этого явления, так как его использование приводит к тому, что многие люди уделяют основное значение идее, которая не так важна, как основная. Основная идея — это обмен сообщениями». Алан Кэй
Потому да, я также считаю, что изучать С++ для Объектно-ориентированного программирования - вредно.
Автор упоминает, что собеседовался он как Data Engineer, а не как Software Engineer, и Фейсбук ставит "опыты", и в конкретно в случаи автора, в команде не было синьорити.
Instagram написан на Python и Django. Хоть у Python и есть проблемы с CPU-intensive задачами, но зачастую, в веб приложениях, ориентированных на контент, основная нагрузка это - I/O intensive задачи. К тому же, большая часть проблем, решается за счет уровней кеша, CDN и тд.
ЗЫ: основная часть DropBox также на Python, но на 2-й версии. И сам Гвидо долгое время работал на них.
Тензор это Tensorflow? Он написан в основном на С++. И у него есть реализации API под другие языки программирования, и самый популярный из них - Python. По сути, Python выступает в роли Wrapper.
Судя по статье, они создали и внедрили 5 проектов за последний год. Некоторые проекты могли быть на Python, некоторые на Kotlin. К тому же, в статье описывается, что при микросервисной архитектуре, в зависимости от Domain, микросервис можно реализовывать на любом языке, зависит от задач, и имеются ли библиотеки, для решения. Пример же автор приводит интеграции, что здесь лучше всего использовать Apache Camel.
То есть, он не пишут на разных языках, в одном проекте, в одном монорепозитории, в разных модулях и тд. А на уровне микросервисов, или же проектов.
Давно практикую наличие нескольких резюме. Одно резюме для ботов - где в Linkedin например, в заголовке пишу основную технологию. Например Java Developer.
Второе резюме, это уже то, что отправляю HR. Оно чаще всего переделывается под компанию, или проект.
ЗЫ: Как стал IT менеджером, hr перестали стучаться и предлагать вакансии. Когда был Java разработчиком, писали как минимум 2-3 раза в неделю.
Что вы думаете о Global Interpreter Lock? Это проклятие или преимущество?
А ведь ответа на вопрос не было.
Вы собираетесь увеличивать скорость Python, например, как PHP?
Кэрол Виллинг: Я думаю, мы достаточно подробно обсудили производительность и скорость.
Нет, не подробно. Просто решили не отвечать на прямой вопрос.
И да, ребята прямо говорят, что не хотят развивать ядро языка, а выпиливать из него. И просят сообщество сконцентрироваться на экосистеме, и пилить больше проектов/библиотек для сообщества. И хотят тормознуть релизный цикл, видишь ли, научным сотрудникам (Enterprise) сложно обновлять кодовую базу и зависимые модули и библиотеки.
Получается, что ребята пошли по пути "старой" Java, а Java решила стать модной и молодежной.
С настоящими пользователями они начали отъедать много памяти. Тут стоит громко сказать: «не верьте официальной доке gunicorn!». Количество воркеров нужно ставить в зависимости от вашего приложения и проведенных тестов, а не на основе формулы которая дана в доке.
DO NOT scale the number of workers to the number of clients you expect to have. Gunicorn should only need 4-12 worker processes to handle hundreds or thousands of requests per second.
Gunicorn relies on the operating system to provide all of the load balancing when handling requests. Generally we recommend (2 x $num_cores) + 1 as the number of workers to start off with. While not overly scientific, the formula is based on the assumption that for a given core, one worker will be reading or writing from the socket while the other worker is processing a request.
Obviously, your particular hardware and application are going to affect the optimal number of workers. Our recommendation is to start with the above guess and tune using TTIN and TTOU signals while the application is under load.
Always remember, there is such a thing as too many workers. After a point your worker processes will start thrashing system resources decreasing the throughput of the entire system.
Что мы видим? В документации, ясно указывается, что формулу надо использовать как отправную точку, но в зависимости от типа нагрузки и профиля использования (CPU Bound vs IO Bound, long-polling и т.д.) нужно выставлять данные параметры самому. Нету универсального способа. И в самом начале указывается, что в целом достаточно иметь 4-12 воркеров, и что ненужно иметь их много.
так Абрамов бомбит от всяких state'ов. он наоборот, пропагандирует использование чистого JavaScript в проектах, а React использовать только как библиотеку для работы над DOM
Да, это круто, но что ты будешь делать, когда твоё хранилище перестанет влезать на один сервер или в один дата-центр? Тогда ты захочешь распределённое хранилище. Хорошо, если Django умеет поддерживать транзакционный механизм с распределённым хранилищем.
Преждевременная оптимизация - зло. А если такой проблемы в будущем не будет?
Как люди жили до этого? Как решали такие проблемы?
Почему такую проблему должен решать Django. Да, он фреймворк, но он не все силен. Это уже задача/проблема масштабирования Базы Данных.
Личное мнение - идти в тимлиды - тупиковая ветвь развития для программиста. Зачастую, ищут тимлида, где Продакт менеджер не обладает техническими компетенциями. Пришел из бизнеса. За клиента. Но проблема с базой: метрикой, инструментами, процессами разработки, безопасность кода и инфраструктуры, сети, почему мы должны платить за git/intellij/любой-инструмент-который-делает-процесс-разработки-быстрее. А еще каждый раз доказывать ему, что ты не шланг, так как на выходных, друг или родственник айтишник, рассказал, что в другой компании, они все делают по другому.
Лучше всего, развиваться как Senior Dev. Не тот синьор-помидор, который за 3 года и в лиды. Синьором и на пенсию выйти не стыдно. А еще быть таким Синьором, который может мотивировать и вести за собой команду, погрузится в предметную область, контрибьютить в библиотеки с которыми работает, может декомпозировать задачи - одним словом, быть 10х Dev, который просто на опыте и на мудрости спасает команду, мыслит вне рамки кода.
И новую работу найти будет просто. Искать не надо. Такого рекомендовать будут всегда. И удовольствие от работы больше, так как четко понимаешь, за какой фронт работы несешь ответственность, и где твои результаты.
Прокрастинация, это не когда лежишь на диване, вместо дел, а моешь посуду, чинишь стул, стираешь шторы, наводишь порядок на книжной полке, сортируешь заметки по Алфавиту, затем по темам, оптимизируешь свой гардероб, одним словом, занимаешься чем угодно, но не работой, которую надо сделать.
Соглашусь с комментаторами - автор собрал компиляцию из интернета, даже не погрузившись в проблему.
Если же делиться опытом, то никогда нельзя себя награждать за работу. Иначе, уровень дофамина будет расти и расти, и со временем, чтобы сделать маленькую работу, подправить конфиг, сверстать что-то, поменять скрипт - уровень награждения (дофамина) будет неподъемным для организма, ибо результат такой мелочной работы - низкий. И от этого и копится прокрастинация!
Решение? Учиться просто работать. Получать удовольствие от процесса работы. Не награждать себя. Покупать всякие приятные штучки как новые наушники, просто ни за что, рандомно. Все.
Если прочитать статьи оригиналы про увольнения в Твиттер, там как раз пишут, что сократили на 90% Штат в Индии. А это как раз модераторы контента. Ручной труд. Который никак не имеет отношения к айти сектору
Если прочитать статью, то можно увидеть, что под сокращение попало 50% сотрудников, но не программисты в первую очередь. Учитывая что пошел под нож штат в Азии, Индии, Канаде и тд - то режут именно модераторов. Которых можно заменить ИИ. Тогда не будет персональных банов (Трамп), а все будут решать алгоритмы.
Часто встречаю туториалы по OAuth2. Но, не показываются альтернативные способы авторизации. Что еще можно использовать, если предпологается наличие SPA и нативное мобильного клиента?
да и
WebSecurityConfigurerAdapterdeprecated.там же указывается, что такое интервью проводят не один раз. а скорее всего два раза - итого 90 мин - полтора часа.
обычно в faang интервью проходит в 5 этапов: 2 на алгоритма, 2 на систем дизайн, 1 поведенческое. все конечно зависит, на какую позицию идете.
Для baseline - .NET Core
да что вы все во круг айти так замкнулись. не будем говорить о медиках. вы видели ставки юристов? вот упоминаете, что в других странах, у айтишников не топ ЗП. возьмём Австрию. или похожею европейскую страну, с лютой бюрократией. там адвокаты, чтобы просто составить бумагу и подписать, берут лютые деньги. а про бухгалтеров молчу. в Британии удивляются, что у нас в СНГ, очень много бухгалтеров - женщины. говорят, как так? это же сложная работа! на самом деле, не столько как сложная, а доходная.
Потому да, я также считаю, что изучать С++ для Объектно-ориентированного программирования - вредно.
у QT проблема с лицензией, с 5-й версией они решили периеграть лицензию, и выпускать на ней коммерческий продукт стало не выгодно.
Автор упоминает, что собеседовался он как Data Engineer, а не как Software Engineer, и Фейсбук ставит "опыты", и в конкретно в случаи автора, в команде не было синьорити.
Instagram написан на Python и Django. Хоть у Python и есть проблемы с CPU-intensive задачами, но зачастую, в веб приложениях, ориентированных на контент, основная нагрузка это - I/O intensive задачи. К тому же, большая часть проблем, решается за счет уровней кеша, CDN и тд.
ЗЫ: основная часть DropBox также на Python, но на 2-й версии. И сам Гвидо долгое время работал на них.
Тензор это Tensorflow? Он написан в основном на С++. И у него есть реализации API под другие языки программирования, и самый популярный из них - Python. По сути, Python выступает в роли Wrapper.
Судя по статье, они создали и внедрили 5 проектов за последний год. Некоторые проекты могли быть на Python, некоторые на Kotlin. К тому же, в статье описывается, что при микросервисной архитектуре, в зависимости от Domain, микросервис можно реализовывать на любом языке, зависит от задач, и имеются ли библиотеки, для решения. Пример же автор приводит интеграции, что здесь лучше всего использовать Apache Camel.
То есть, он не пишут на разных языках, в одном проекте, в одном монорепозитории, в разных модулях и тд. А на уровне микросервисов, или же проектов.
Давно практикую наличие нескольких резюме. Одно резюме для ботов - где в Linkedin например, в заголовке пишу основную технологию. Например Java Developer.
Второе резюме, это уже то, что отправляю HR. Оно чаще всего переделывается под компанию, или проект.
ЗЫ: Как стал IT менеджером, hr перестали стучаться и предлагать вакансии. Когда был Java разработчиком, писали как минимум 2-3 раза в неделю.
А ведь ответа на вопрос не было.
Нет, не подробно. Просто решили не отвечать на прямой вопрос.
И да, ребята прямо говорят, что не хотят развивать ядро языка, а выпиливать из него. И просят сообщество сконцентрироваться на экосистеме, и пилить больше проектов/библиотек для сообщества. И хотят тормознуть релизный цикл, видишь ли, научным сотрудникам (Enterprise) сложно обновлять кодовую базу и зависимые модули и библиотеки.
Получается, что ребята пошли по пути "старой" Java, а Java решила стать модной и молодежной.
А теперь заходим в документацию (https://docs.gunicorn.org/en/stable/design.html) и читаем:
Что мы видим? В документации, ясно указывается, что формулу надо использовать как отправную точку, но в зависимости от типа нагрузки и профиля использования (CPU Bound vs IO Bound, long-polling и т.д.) нужно выставлять данные параметры самому. Нету универсального способа. И в самом начале указывается, что в целом достаточно иметь 4-12 воркеров, и что ненужно иметь их много.
так Абрамов бомбит от всяких state'ов. он наоборот, пропагандирует использование чистого JavaScript в проектах, а React использовать только как библиотеку для работы над DOM
Преждевременная оптимизация - зло. А если такой проблемы в будущем не будет?
Как люди жили до этого? Как решали такие проблемы?
Почему такую проблему должен решать Django. Да, он фреймворк, но он не все силен. Это уже задача/проблема масштабирования Базы Данных.