1. В этом случае (продукты-конструкторы с кучей настроек) разделяют настройку и использование. Настройкой может заниматься профессионал по настройке (и никто легкую работу не обещал), а вот использование должно оставаться легким.
2. Делают специализированные продукты (условно CRM для малых отелей): в этом случае количество настроек уменьшается на порядок. Опять же настройки и использование должны оставаться разными процессами.
3. Есть так же системы типа Basecamp: там минимум настроек, простой UI, но обучающие видео как доступные инструменты применить в своем бизнесе (фактически настройки на основе договоренностей).
Мне кажется, что лучше развиваться в профессиональном плане: разговаривать как носитель языка — с одной стороны невероятно сложно для иностранца, с другой стороны низко ценится, т.к. легко найти таких людей.
Да, это понятно, все-таки о миллиардах финансирования идет речь. Но это все-таки лишь университет, должно быть достаточно много независимых от него людей и компаний.
А без бумажного письма статья здесь не лучше разговора в курилке. Жалко, что автор никак не прокомментировал.
> Читаем в разделе про американский опыт, видим:
> Так что нет такого ограничения.
Стадия «экспансия» проходит уже не в технопарке. Сначала выход на один какой-то рынок, потом на другие. На более ранних стадиях попытка выйти на несколько рынков сразу скорее уменьшит вероятность на успех, чем увеличит. Или вы про то, что международная компания может сидеть в технопарке? Я бы не хотел, чтобы компании, достигшие подобного уровня, продолжали получать поддержку от государства в виде Технопарка.
> У вас явно «местечковый» менталитет. Для примера Google выросло из аспирантской работы со студентами, Paypal, SpaceX, Apples и Microsoft из гаражных стартапов — и вполне себе глобальный охват.
Американский рынок — один из крупнейших в мире. На нем можно много заработать для выхода на другие рынки. Там же отработанный институт финансирования подобных выходов. Ничего такого, насколько знаю, нет на дальнем востоке. Даже из Москвы особо глобальный рынок не завоюешь. Отличный пример — Яндекс. Развились бы они в США — были бы глобальны, а сейчас гораздо меньше Гугла.
> Если бы нынешней власти была нужна обратная связь…
> Помните анекдот про бабушку с яйцами?
Это как с блокировками IP-адресов: если не писать, то будет очень легко сказать что других вариантов и не было, все были согласны. А если написать, то уже нужно будет что-то отвечать. Есть вероятность, что что-то из списка примут. Я исхожу из того, что автору все-таки не все равно. А вот пост здесь никак не изменит ситуацию. Официальное письмо — уже хоть что-то. Вода камень точит.
1. Напишите это же полпреду президента в виде бумажного письма. Нужно немного переоформить, чтобы были четкие и отдельные пункты предложений. Еще лучше, если найдете заметное количество заметных людей, которые так же под ним подпишутся. От поста здесь вряд ли что-то изменится, а у письма есть хоть какие-то шансы.
2. Меня несколько насторожила фраза «Небольшие компании… вряд-ли могут себе позволить нанимать маркетологов по каждому рынку»:
— на каждый рынок нужно продукт адаптировать, т.к. предпочтения, условия и сложившаяся практика (конкуренты) другие
— следовательно, небольшая компания может выходить только на 1 рынок, больше уже после технопарка
— построение продукта — ключевая компетенция бизнеса, поэтому тут не может быть особой надежды на внешних людей
— если хочется какой-то рынок (московский, азиатский и т.п.), то нужно физически туда ехать, чтобы разбираться с потребностями и особенностями продаж. Поэтому дальневосточный технопарк — это все-таки больше для местных продаж (что по идее тоже неплохо, но явно не захват «всемирного» рынка).
Как по мне у дизайнера Фотошоп все равно будет. Вопрос только в том использовать/покупать дополнительно Фигму или нет. Как я понимаю, ее скорее со Скетчем нужно сравнивать.
kubeadm хорош тем, что ставит кластер уже внутри ОС, а за предварительное развертывание не отвечает. Т.е. с его помощью можно строить свои CI pipelines. Пробовали еще kops, но его возможностей не хватило даже для AWS, не говоря уже о других площадках.
В целом, думаю, all-in-one победят, но позже, пока что они сыроваты (как и многое в Kubernetes, даже kubeadm в альфе/бете в зависимости от компонента).
Наверное, автор знает, но для тех, кто только разбирается, может быть интересно:
— рабочие ноды и поды прекрасно работают без живых мастеров: мастера нужны только чтобы менять конфигурацию кластера
— на мастерах всё состояние хранится в etcd
— etcd можно бекапить и восстанавливаться из бекапа
— если кластер совсем маленький и тестовый, то и на мастерах тоже можно размещать рабочую нагрузку: `kubectl taint nodes --all node-role.kubernetes.io/master-`
Т.е. если у вас мало динамики изменения структуры кластера, то, скорее всего, и одного мастера c ежечасными бекапами etcd хватит. Лучше, конечно, 3: тогда восстановления будут практически автоматические. А вот 5 и больше — такие случаи бывают, но редко когда нужно.
Другое дело, сколько кандидатов на это согласится. Обычно считается, что лучше не нанять хорошего разработчика, чем нанять плохого. Поэтому, если после включения опции тестового задания остается достаточно людей хорошего качества, то ok. Вполне есть такие конторы как международные, так и локальные. Если просчитались, то появляются истории, как в других комментариях, что и без задания брали, т.к. просто других вариантов не было.
Я, наверное, все-таки про хороших регуляров и лучше писал. Такие требования по стажу как раз пытаются отсеить юниоров.
1 год что-то показывает, но тоже зависит от конторы. 2+ уже не особо: человек может не особо прогрессировать, а, иногда, даже регрессировать (отказываться принимать текущие best practice платформы).
Не факт, легко может оказаться, что человеку будет тяжело даваться git после svn (да, в текущем году).
Я не говорю, что нужно было делать то задание. Мое мнение — не больше одного вечера по времени и очевидность тестовости задачи.
Ответ был про другое: что тестовые задания как инструмент вполне имеют право на жизнь (и для профессионалов даже больше, чем для студентов). А то, что потом перезвонили — у них реально не было потока кандидатов, а без него тестовые задания все-таки лишние.
Хорошие тестовые задания выполняются сильно больше 100 раз. У них (по идее) есть с чем сравнивать.
Дальше общие рассуждения. Качество кода (читабельность, соотв. best practices платформы, обработка ошибок) часто крайне важны в обычной работе и недооцениваются авторами тестовых заданий.
Непонятно как те у кого были проблемы с тестовым заданием устроились. Как по мне, тестовое задание достаточно сложно готовить, но это правильное направление: по итогам нужно менять тестовое, чтобы больше раскрывало кандидатов.
Несколько тезисов:
* Стаж мало что показывает: мы же хотим понять кто из условных 10 соискателей лучше пишет код и нанять 1.
* Класс из большого проекта тоже: что-то написано другими, что-то обусловлено архитектурой.
* Open source не особо показывает скорость/качество реальной работы, насколько человек может делать code review и прочее (может и показать, но уже слишком сложный случай, мало у кого такое есть).
* Чужие тестовые задания — лучше, чем ничего, но как сравнивать с результатами других кандидатов?
* Испытательный срок — мне, как кандидату, все-таки лучше иметь какую-то уверенность, что подхожу на позицию, а не вылечу на след. день, т.к. на старое место вряд ли вернешься, а семью содержать надо
* Если кандидатов реально мало и особо не повыбираешь, то тут что угодно можно зачесть как «проверку» кандидата
* По мне лучше сделать 1 тестовое задание и 1-2 собеседования, чем 5 раз собеседоваться в разные дни по часу и больше (бывало). Другими словами нужно смотреть на полные затраты трудоустройство, а не только на часть тестового задания.
Все-таки домашнее тестовое задание — хороший инструмент. Только его тоже нужно уметь готовить:
— подготовленный стартовый проект на тех же технологиях, что и работа потом
— несколько часов работы как если бы уже полгода на этих технологиях работаешь (это будет 2-4х для человека, который немного другим занимался)
— явно заявить сколько компания ожидает работник будет тратить на эту задачу через 2 недели, т.к. скорость работы — один из важных показателей
— явная учебность задачи, а то параноиков реально много (может и не зря)
— ограничение на срок сдачи (например, сутки), если ищется готовый специалист, а не на обучение
— если позиция не просто регуляр, то можно добавить code review тестового проекта или еще что будет от человека требоваться (только не увлекаться, чтобы длительность оставалась разумной)
— давать понятную обратную связь по заданию
— наверняка еще какие-то детали
Делать без оплаты или нет? С одной стороны есть тезис, что любая работа должна быть оплачена, но это, скорее, про трудовые отношения, которых еще нет. С другой при продаже очень часто «попробывать» — бесплатно. Т.е. я думаю что, если можно сделать за 1 вечер, то бесплатно. Понятно, что в итоге это не бесплатно: кандидат смотрит разницу с текущей зп, учитывает вероятность и длительность трудоустройства, время на других потенциальных работодателей и принимает решение выгодно в такое ввязываться или нет.
Все-таки смена работы — достаточно редкое явление (не фрилансер, который ищет заказы каждый день). Если от интересной работы отделяет только долгое тестовое задание, то не особо проблема, а если работодатель/вакансия не очень, то и не надо тратить время.
3 причины:
— в зависимости от проекта бывает очень тяжело предсказать что будет дальше, хотя, в отличие от тупых продакт менеджеров разработчик уже знает
— есть большая вероятность написать что-то лишнее, а все лишнее нужно поддерживать (об этом статья)
— преждевременно написанный код: если написать код, который в общем виде понадобится в будущем релизе, а не текущем. такое явно нужно согласовывать, т.к. может быть приоритеты другие.
Про Java добавлю, что в последних версиях (начиная с 7/8) разработчики языка довольно много переносят из сторонних библиотек в основную. Сейчас ту же Guava довольно редко когда приходится использовать.
С основным посылом полностью согласен: довольно много некачественного кода пишется как новичками, так и «бывалыми» (всегда так работал и было норм). А вот про рецепты… Все-таки главное читабельность, а не количество кода (видел прилично компактых нечитаемых примеров в жизни). Хотя метрика «кол-во кода» проще автоматизируется. Просто, этого недостаточно.
Да и не будут это читать «бывалые». А если прочитают, то не согласятся. Иначе бы уже давно исправились. Нужны организационные изменения. Какие — зависит от конкретной организации. Где-то достаточно обязательных code review. Где-то можно внедрить роботов, которые блокируют PR, если там слишком плохой с формальной точки зрения код. Где-то еще что-то.
2. Делают специализированные продукты (условно CRM для малых отелей): в этом случае количество настроек уменьшается на порядок. Опять же настройки и использование должны оставаться разными процессами.
3. Есть так же системы типа Basecamp: там минимум настроек, простой UI, но обучающие видео как доступные инструменты применить в своем бизнесе (фактически настройки на основе договоренностей).
cloud.google.com/free
Еще посмотри через Firebase: там другие тарифы, вполне подходит для многих кейсов.
firebase.google.com/pricing
А без бумажного письма статья здесь не лучше разговора в курилке. Жалко, что автор никак не прокомментировал.
> Так что нет такого ограничения.
Стадия «экспансия» проходит уже не в технопарке. Сначала выход на один какой-то рынок, потом на другие. На более ранних стадиях попытка выйти на несколько рынков сразу скорее уменьшит вероятность на успех, чем увеличит. Или вы про то, что международная компания может сидеть в технопарке? Я бы не хотел, чтобы компании, достигшие подобного уровня, продолжали получать поддержку от государства в виде Технопарка.
> У вас явно «местечковый» менталитет. Для примера Google выросло из аспирантской работы со студентами, Paypal, SpaceX, Apples и Microsoft из гаражных стартапов — и вполне себе глобальный охват.
Американский рынок — один из крупнейших в мире. На нем можно много заработать для выхода на другие рынки. Там же отработанный институт финансирования подобных выходов. Ничего такого, насколько знаю, нет на дальнем востоке. Даже из Москвы особо глобальный рынок не завоюешь. Отличный пример — Яндекс. Развились бы они в США — были бы глобальны, а сейчас гораздо меньше Гугла.
> Если бы нынешней власти была нужна обратная связь…
> Помните анекдот про бабушку с яйцами?
Это как с блокировками IP-адресов: если не писать, то будет очень легко сказать что других вариантов и не было, все были согласны. А если написать, то уже нужно будет что-то отвечать. Есть вероятность, что что-то из списка примут. Я исхожу из того, что автору все-таки не все равно. А вот пост здесь никак не изменит ситуацию. Официальное письмо — уже хоть что-то. Вода камень точит.
2. Меня несколько насторожила фраза «Небольшие компании… вряд-ли могут себе позволить нанимать маркетологов по каждому рынку»:
— на каждый рынок нужно продукт адаптировать, т.к. предпочтения, условия и сложившаяся практика (конкуренты) другие
— следовательно, небольшая компания может выходить только на 1 рынок, больше уже после технопарка
— построение продукта — ключевая компетенция бизнеса, поэтому тут не может быть особой надежды на внешних людей
— если хочется какой-то рынок (московский, азиатский и т.п.), то нужно физически туда ехать, чтобы разбираться с потребностями и особенностями продаж. Поэтому дальневосточный технопарк — это все-таки больше для местных продаж (что по идее тоже неплохо, но явно не захват «всемирного» рынка).
В целом, думаю, all-in-one победят, но позже, пока что они сыроваты (как и многое в Kubernetes, даже kubeadm в альфе/бете в зависимости от компонента).
— рабочие ноды и поды прекрасно работают без живых мастеров: мастера нужны только чтобы менять конфигурацию кластера
— на мастерах всё состояние хранится в etcd
— etcd можно бекапить и восстанавливаться из бекапа
— если кластер совсем маленький и тестовый, то и на мастерах тоже можно размещать рабочую нагрузку: `kubectl taint nodes --all node-role.kubernetes.io/master-`
Т.е. если у вас мало динамики изменения структуры кластера, то, скорее всего, и одного мастера c ежечасными бекапами etcd хватит. Лучше, конечно, 3: тогда восстановления будут практически автоматические. А вот 5 и больше — такие случаи бывают, но редко когда нужно.
Другое дело, сколько кандидатов на это согласится. Обычно считается, что лучше не нанять хорошего разработчика, чем нанять плохого. Поэтому, если после включения опции тестового задания остается достаточно людей хорошего качества, то ok. Вполне есть такие конторы как международные, так и локальные. Если просчитались, то появляются истории, как в других комментариях, что и без задания брали, т.к. просто других вариантов не было.
1 год что-то показывает, но тоже зависит от конторы. 2+ уже не особо: человек может не особо прогрессировать, а, иногда, даже регрессировать (отказываться принимать текущие best practice платформы).
Не факт, легко может оказаться, что человеку будет тяжело даваться git после svn (да, в текущем году).
Ответ был про другое: что тестовые задания как инструмент вполне имеют право на жизнь (и для профессионалов даже больше, чем для студентов). А то, что потом перезвонили — у них реально не было потока кандидатов, а без него тестовые задания все-таки лишние.
Дальше общие рассуждения. Качество кода (читабельность, соотв. best practices платформы, обработка ошибок) часто крайне важны в обычной работе и недооцениваются авторами тестовых заданий.
* Стаж мало что показывает: мы же хотим понять кто из условных 10 соискателей лучше пишет код и нанять 1.
* Класс из большого проекта тоже: что-то написано другими, что-то обусловлено архитектурой.
* Open source не особо показывает скорость/качество реальной работы, насколько человек может делать code review и прочее (может и показать, но уже слишком сложный случай, мало у кого такое есть).
* Чужие тестовые задания — лучше, чем ничего, но как сравнивать с результатами других кандидатов?
* Испытательный срок — мне, как кандидату, все-таки лучше иметь какую-то уверенность, что подхожу на позицию, а не вылечу на след. день, т.к. на старое место вряд ли вернешься, а семью содержать надо
* Если кандидатов реально мало и особо не повыбираешь, то тут что угодно можно зачесть как «проверку» кандидата
* По мне лучше сделать 1 тестовое задание и 1-2 собеседования, чем 5 раз собеседоваться в разные дни по часу и больше (бывало). Другими словами нужно смотреть на полные затраты трудоустройство, а не только на часть тестового задания.
Все-таки домашнее тестовое задание — хороший инструмент. Только его тоже нужно уметь готовить:
— подготовленный стартовый проект на тех же технологиях, что и работа потом
— несколько часов работы как если бы уже полгода на этих технологиях работаешь (это будет 2-4х для человека, который немного другим занимался)
— явно заявить сколько компания ожидает работник будет тратить на эту задачу через 2 недели, т.к. скорость работы — один из важных показателей
— явная учебность задачи, а то параноиков реально много (может и не зря)
— ограничение на срок сдачи (например, сутки), если ищется готовый специалист, а не на обучение
— если позиция не просто регуляр, то можно добавить code review тестового проекта или еще что будет от человека требоваться (только не увлекаться, чтобы длительность оставалась разумной)
— давать понятную обратную связь по заданию
— наверняка еще какие-то детали
Делать без оплаты или нет? С одной стороны есть тезис, что любая работа должна быть оплачена, но это, скорее, про трудовые отношения, которых еще нет. С другой при продаже очень часто «попробывать» — бесплатно. Т.е. я думаю что, если можно сделать за 1 вечер, то бесплатно. Понятно, что в итоге это не бесплатно: кандидат смотрит разницу с текущей зп, учитывает вероятность и длительность трудоустройства, время на других потенциальных работодателей и принимает решение выгодно в такое ввязываться или нет.
Все-таки смена работы — достаточно редкое явление (не фрилансер, который ищет заказы каждый день). Если от интересной работы отделяет только долгое тестовое задание, то не особо проблема, а если работодатель/вакансия не очень, то и не надо тратить время.
— в зависимости от проекта бывает очень тяжело предсказать что будет дальше, хотя, в отличие от тупых продакт менеджеров разработчик уже знает
— есть большая вероятность написать что-то лишнее, а все лишнее нужно поддерживать (об этом статья)
— преждевременно написанный код: если написать код, который в общем виде понадобится в будущем релизе, а не текущем. такое явно нужно согласовывать, т.к. может быть приоритеты другие.
С основным посылом полностью согласен: довольно много некачественного кода пишется как новичками, так и «бывалыми» (всегда так работал и было норм). А вот про рецепты… Все-таки главное читабельность, а не количество кода (видел прилично компактых нечитаемых примеров в жизни). Хотя метрика «кол-во кода» проще автоматизируется. Просто, этого недостаточно.
Да и не будут это читать «бывалые». А если прочитают, то не согласятся. Иначе бы уже давно исправились. Нужны организационные изменения. Какие — зависит от конкретной организации. Где-то достаточно обязательных code review. Где-то можно внедрить роботов, которые блокируют PR, если там слишком плохой с формальной точки зрения код. Где-то еще что-то.