Чем это (работа в серую/чёрную) плохо, если оно по обоюдному согласию работника и работодателя?
Предложений с полностью белой ЗП кратно меньше серой, поэтому согласие работника зачастую вынужденное - кредиты, аренды и т.д. не ждут.
Белая ЗП ниже. Конечно, гарантий больше в случае проблем, но - см. п. 1
При серой схеме весь ТК летит в трубу со свистом. "Сегодня пиши заявление по собственному и завтра тебя здесь быть не должно. Не хочешь? Ок, будешь два месяца работать за 20к, а мы будем внимательно смотреть, облажешься - уволим по статье"
Есть другая сторона - какой-то объём спецов может быть "размазан" по другим отраслям и не был учтены в "области информации и связи". Поэтому все цифры весьма размыты. Но, в любом случае, это масса, которую невозможно игнорировать и она только растёт.
Дополню комментарий: по мнению минтруд в области информации и связи у нас занято 1.4 млн человек и это не только ИТР, а вообще все. А уехало в прошлом месяце 70к человек, в текущем ожидают 100к. То есть за два месяца ~ 10%. Очевидно, что поток резко снизится в ближайшее время, однако уже ситуация катастрофическая.
Это вопрос средне- и долгосрочного планирования, тренд эмиграции виден невооружённым глазом и если сейчас это может не быть проблемой, то ситуация изменится в течении года.
Страна становится закрытой, а значит востребованность в ИТР специалистах будет в ближайшее время расти, но потребности закрыть не получиться - мало того, что у нас нет для таких спецов "кузницы кадров", так они ещё и массово "сваливают".
Непосильная задача стоит пред правительством - надо не выпускать из страны тех что есть и усиленно завлекать, тех, кто на "чужбине". Сложно будет звать работать в страну, из которой скорее всего не выпустят.
Не раз сталкивался с ситуацией, когда не удаляется Namespace со всеми подами - висит пустой в статусе удаления, хотя если сначала удалять поды руками, то всё ок. С какими внутренними механизмами связано такое поведение?
Программные вставки расширенного синтаксиса на языке реализации ... любой код на C/C++
А после раскрутки компилятора необходимость в %{ ...%} отпадёт или там всё равно будет С++? Или раскрутка не планируется?
В эпоху машинного обучения тензоры являются основными элементами вычислений
Сейчас, не менее востребованным, является многопоточное выполнение, которое очень хорошо может работать с тензорами. Какие есть планы на доступ к данным из разных потоков, синхронизацию, обмен сообщениями?
($ для локальных объектов и @ для глобальных)
Продолжая предыдущую мысль: глобальные объекты в многопотоке - боль.
Вот мне в этом случае и непонятна целевая аудитория подобного решения, она получается очень узкой - начинающие разработчики на Django, которым надо быстро поднять простой сайт с небольшим набором сложно-сочинённых страниц и чтобы не городить весь этот огород ради небольшого объёма очень удобно использовать streamfield.
Причём, надо заметить, матёрые разрабы на Django уже имеют привычный набор батареек, который позволяет быстро поднять "стандартный сайт".
Здесь было бы уместно упомянуть Django CMS - у неё тоже есть подход к редактированию страниц блоками (или виджетами), но они являются более тонкой прослойкой к Django и не изобретают собственную структуру хранения данных, скорее строят свой редактор контента, который, кстати работает "внутри сайта", без отдельной админки.
Ведь например в вашем примере с рецептами структура рецептов заранее известна, там гибкость стримфилда не нужна.
На мой взгляд, очень удобно было бы использовать именно sf на фронте - есть рецепт и пользователь его наполняет: выбрал блок видео - добавил, выбрал текст - добавил, фото, снова видео, блок ингредиентов для теста, блок ингредиентов для начинки и т.д. - самое оно!
Да и в бэкэнде я бы наверно для рецептов не задействовал стримфилд.
Тогда зачем Wagtail? Джанга сама всё умеет. Там тоже есть вложенные формы. Да, не в такой удобной обёртке, но всё же.
Wagtail хранит весь контент, по сути, в блобах - текстовое поле с JSON. Таким образом взаимодействие с отдельными полями контента будет затруднено - каждый виджет имеет свой формат. Как будет выглядеть SQL запрос выборки значений из страниц с вложенными streamfields и произвольным наполнением контента в них, страшно представить. Но, скорее всего, никак не будет выглядеть - вам придётся строить отдельный бэкенд обработки полей, как это сделано для поиска - для дублирования информации в отдельных таблицах и уже нормальной работой по ним. Поэтому использование elasticsearch "из коробки" выглядит ни разу не фичей, а провалом архитектуры.
Не вижу никаких преимуществ по сравнению с любым SSG, которые позволяют гибко настраивать поля и имеют собственную админку для редактирования контента, например Pelican, если мы говорим про Python или множество других на разных ЯП.
Ещё непонятно как использовать streamfields на фронте - например я хочу сделать сайт с рецептами - чтобы пользователи могли добавлять рецепты, используя streamfields с ограниченным набором кастомных полей (текст, картинки, тэги, ингредиенты и т.п.). Админку, я, во-первых, им давать не хочу, во-вторых, это всё должно быть в интерфейсе сайта, по фэншую. Ну и плюсом надо построить списки по срезам: тэги, ингредиенты, лента. С поиском понятно, а как с остальным решаются вопросы в Wagtail?
На сеньёре тоже технический уровень не заканчивается — дальше техлид, дальше — principal (не знаю как принято называть подобный уровень по русски). Специалисты уровня principal вполне себе востребованы на рынке — пару дней его консультаций может сэкономить недели, а то и месяцы работ команды. Кстати тут тоже может быть вилка в специализации — кто-то идёт в архитекторы, прокачиваясь "в ширину", кто-то глубже погружается в нюансы и особенности реализации тех или иных аспектов технологии.
И зарплаты для таких специалистов тоже уже не "сеньёрские".
PS: А про сантехников, это вы зря. Не знаю как в Америке, но в России найти крутого сантехника — задача не легче поиска хорошего "айтишника", кто имел дело с ремонтом, меня поймёт. И платить ему в два раза выше рынка жаба вообще не душит.
Часто роли тимлида и техлида смешивают в той или иной пропорции, что усложняет дискурс о зонах ответственности. Если рассматривать "чистого" тимлида, то он, в первую очередь, строит процессы. Например, процесс разрешения конфликтов или процесс формирования архитектуры.
Представь, что ты "прокачанный" бэкенд, пришёл тимлидом в команду, где есть бэк, фронт и мобилка и у команды приложения для iOS возник технический конфликт, как ты его собираешься лично разруливать, если ни сном ни духом в их стеке? Очевидно, твоя задача — организовать процесс решения в рамках компетенции и ресурсов команды. Задача максимум — сделать так, чтобы в следующий раз коллеги сами применили этот метод, не отвлекая других участников.
А магия "правильных ключевых решений" часто строится на оценке ситуации — что у нас есть, что надо получить, как это можно получить, сколько это займёт времени и т.д. Чем проработанней будет оценка, тем проще принять решение.
Предложений с полностью белой ЗП кратно меньше серой, поэтому согласие работника зачастую вынужденное - кредиты, аренды и т.д. не ждут.
Белая ЗП ниже. Конечно, гарантий больше в случае проблем, но - см. п. 1
При серой схеме весь ТК летит в трубу со свистом. "Сегодня пиши заявление по собственному и завтра тебя здесь быть не должно. Не хочешь? Ок, будешь два месяца работать за 20к, а мы будем внимательно смотреть, облажешься - уволим по статье"
Есть другая сторона - какой-то объём спецов может быть "размазан" по другим отраслям и не был учтены в "области информации и связи". Поэтому все цифры весьма размыты. Но, в любом случае, это масса, которую невозможно игнорировать и она только растёт.
Кем бы ни были люди, уехавшие из России - это актив, люди, которые могут приносить деньги, даже если не будут заняты на внутренних проектах.
И они платят (платили) нологи!
Встреча - за гаражами, приходите один
Мой коммент выше - жопа уже.
Дополню комментарий: по мнению минтруд в области информации и связи у нас занято 1.4 млн человек и это не только ИТР, а вообще все. А уехало в прошлом месяце 70к человек, в текущем ожидают 100к. То есть за два месяца ~ 10%. Очевидно, что поток резко снизится в ближайшее время, однако уже ситуация катастрофическая.
Вот более реалистичный список:
Изобрести левитацию
Изобрести телепортацию
Северная корея успешно эти идеи претворяет в жизнь.
Это вопрос средне- и долгосрочного планирования, тренд эмиграции виден невооружённым глазом и если сейчас это может не быть проблемой, то ситуация изменится в течении года.
Страна становится закрытой, а значит востребованность в ИТР специалистах будет в ближайшее время расти, но потребности закрыть не получиться - мало того, что у нас нет для таких спецов "кузницы кадров", так они ещё и массово "сваливают".
Непосильная задача стоит пред правительством - надо не выпускать из страны тех что есть и усиленно завлекать, тех, кто на "чужбине". Сложно будет звать работать в страну, из которой скорее всего не выпустят.
Не раз сталкивался с ситуацией, когда не удаляется Namespace со всеми подами - висит пустой в статусе удаления, хотя если сначала удалять поды руками, то всё ок. С какими внутренними механизмами связано такое поведение?
А после раскрутки компилятора необходимость в %{ ...%} отпадёт или там всё равно будет С++?
Или раскрутка не планируется?
Сейчас, не менее востребованным, является многопоточное выполнение, которое очень хорошо может работать с тензорами. Какие есть планы на доступ к данным из разных потоков, синхронизацию, обмен сообщениями?
Продолжая предыдущую мысль: глобальные объекты в многопотоке - боль.
Да, хороший вопрос, спасибо, положу в копилку )
Я всегда задаю вопросы по темам выше. Не именно в таких формулировках, они "западные", если можно так выразиться, но по смыслу - аналогичные.
Мне всегда интересно:
каким образом оценивается результативность сотрудников, как сотрудники узнают о результатах оценки;
есть ли индивидуальный план развития сотрудника, если нет, то каким образом можно его сформировать и кто будет давать мне обратную связь по нему;
как и когда происходит повышение в должности, как и когда повышают зарплату;
какие конкртено хард и софт скиллы востребованы у сотрудников в компании в целом и для моей позиции в частности;
какие процессы и правила "прибиты гвоздями", а какие - отдаются на откуп команде и лично разработчикам;
что в компании считается неприемлимым;
как компания способствует повышению компетенций сотрудников - обучение, митапы, конференции, литуратура, курсы и т.д.;
есть ли институт наставничества и что он из себя представляет;
как происходит погружение в компанию/команду;
как происходит процесс разрешения конфликтов - полный цикл, от появления проблемы до её разрешения;
примеры конфликтов в команде, в компании, результаты;
как оценивается работа руководителей подчинёнными;
график работы, а так же больничные, отгулы;
как часто бывают переработки, почему они происходят, как компания с этим борется;
сколько людей за последний год "выгорело", почему, что сделано, чтобы не повторялось;
почему ищут человка на эту должность;
был ли другой человек на ней, куда он делся и почему;
какова текучка в компании и почему обычно сотрудники увольняются;
чем больше всего сотрудники в компании недовольны;
Некоторые вопросы я задаю не по одному разу - от разных сотрудников можно услышать разные ответы )
Вот мне в этом случае и непонятна целевая аудитория подобного решения, она получается очень узкой - начинающие разработчики на Django, которым надо быстро поднять простой сайт с небольшим набором сложно-сочинённых страниц и чтобы не городить весь этот огород ради небольшого объёма очень удобно использовать streamfield.
Причём, надо заметить, матёрые разрабы на Django уже имеют привычный набор батареек, который позволяет быстро поднять "стандартный сайт".
Здесь было бы уместно упомянуть Django CMS - у неё тоже есть подход к редактированию страниц блоками (или виджетами), но они являются более тонкой прослойкой к Django и не изобретают собственную структуру хранения данных, скорее строят свой редактор контента, который, кстати работает "внутри сайта", без отдельной админки.
На мой взгляд, очень удобно было бы использовать именно sf на фронте - есть рецепт и пользователь его наполняет: выбрал блок видео - добавил, выбрал текст - добавил, фото, снова видео, блок ингредиентов для теста, блок ингредиентов для начинки и т.д. - самое оно!
Тогда зачем Wagtail? Джанга сама всё умеет. Там тоже есть вложенные формы. Да, не в такой удобной обёртке, но всё же.
У Drupal хранение контента основа на реляционной БД, что в корне отличается от хранения данных в блобах у Wagtail, о чём я написал ниже
В Drupal 8 поменяли половину ядра, поэтому "вернуться обратно" будет затруднительно из-за высокого порога входа.
Судя по миграции:
Wagtail хранит весь контент, по сути, в блобах - текстовое поле с JSON. Таким образом взаимодействие с отдельными полями контента будет затруднено - каждый виджет имеет свой формат. Как будет выглядеть SQL запрос выборки значений из страниц с вложенными streamfields и произвольным наполнением контента в них, страшно представить. Но, скорее всего, никак не будет выглядеть - вам придётся строить отдельный бэкенд обработки полей, как это сделано для поиска - для дублирования информации в отдельных таблицах и уже нормальной работой по ним. Поэтому использование elasticsearch "из коробки" выглядит ни разу не фичей, а провалом архитектуры.
Не вижу никаких преимуществ по сравнению с любым SSG, которые позволяют гибко настраивать поля и имеют собственную админку для редактирования контента, например Pelican, если мы говорим про Python или множество других на разных ЯП.
Ещё непонятно как использовать streamfields на фронте - например я хочу сделать сайт с рецептами - чтобы пользователи могли добавлять рецепты, используя streamfields с ограниченным набором кастомных полей (текст, картинки, тэги, ингредиенты и т.п.). Админку, я, во-первых, им давать не хочу, во-вторых, это всё должно быть в интерфейсе сайта, по фэншую. Ну и плюсом надо построить списки по срезам: тэги, ингредиенты, лента. С поиском понятно, а как с остальным решаются вопросы в Wagtail?
На сеньёре тоже технический уровень не заканчивается — дальше техлид, дальше — principal (не знаю как принято называть подобный уровень по русски). Специалисты уровня principal вполне себе востребованы на рынке — пару дней его консультаций может сэкономить недели, а то и месяцы работ команды. Кстати тут тоже может быть вилка в специализации — кто-то идёт в архитекторы, прокачиваясь "в ширину", кто-то глубже погружается в нюансы и особенности реализации тех или иных аспектов технологии.
И зарплаты для таких специалистов тоже уже не "сеньёрские".
PS: А про сантехников, это вы зря. Не знаю как в Америке, но в России найти крутого сантехника — задача не легче поиска хорошего "айтишника", кто имел дело с ремонтом, меня поймёт. И платить ему в два раза выше рынка жаба вообще не душит.
Часто роли тимлида и техлида смешивают в той или иной пропорции, что усложняет дискурс о зонах ответственности. Если рассматривать "чистого" тимлида, то он, в первую очередь, строит процессы. Например, процесс разрешения конфликтов или процесс формирования архитектуры.
Представь, что ты "прокачанный" бэкенд, пришёл тимлидом в команду, где есть бэк, фронт и мобилка и у команды приложения для iOS возник технический конфликт, как ты его собираешься лично разруливать, если ни сном ни духом в их стеке? Очевидно, твоя задача — организовать процесс решения в рамках компетенции и ресурсов команды. Задача максимум — сделать так, чтобы в следующий раз коллеги сами применили этот метод, не отвлекая других участников.
А магия "правильных ключевых решений" часто строится на оценке ситуации — что у нас есть, что надо получить, как это можно получить, сколько это займёт времени и т.д. Чем проработанней будет оценка, тем проще принять решение.