Извините, но очередная перепечатка документации или первых двух глав из любой книжки по эйрфлоу. Никакой специфики и как перестать страдать нет. Вводите читателя в заблуждение, что нехорошо
Именно так. Говорю как человек который сам таких стажеров постоянно берет (примерно на таких условиях) и сын которого полгода назад в тот же Я на стажировку прошел, именно так 3 из 5 решил а на следующих этапах задачки легче были чем на тренажере.
Почему нельзя было использовать один из стандартных движков? Из описания выглядит как наколеночная поделка ради поделки. Про текстовые параметры подключения которые куда то вводятся и сохраняются... Если я правильно понял о чем это, так же просто нельзя делать...
Да очень легко. Сказать что это не первое место куда ты сходил и уже есть оффер но решил еще посмотреть. Кстати когда человек так говорит, в 90% это так и есть. Ну, мой опыт говорит об этом.
Спасибо что в самом начале статьи написали иерархию где тимлид после синьора, дальше можно было уже не читать :-) Да бывают исключения но обычно это совсем разные ветки развития, хороший разработчик ставший хорошим тимлидом это редкий зверь, а вот наоборот на каждом шагу
Хороший материал, НО маленькое замечание, ей бы не помешал спойлер, то есть в стиле встретили странную ощибку, нашли что проблема была в... искали так... Это единственное замечание, в остальном изложенл хорошо, примеры, последовательность действий, подходы, цитаты из доки все хорошо и уместно, плюс однозначно
Вопрос зачем? В будущей жизни программирование на скрач никак не поможет, ну если ребенок сам очень заинтересован то может можно... но как развлечение а не как будущая карьера. Раньше 8-9 класса лучше уделить время чему то другому (мой опыт 30+ лет в it, отца троих детей двое из которых работают в , мягко говоря, не последних it компаниях)
А почему так выборочно, только фантастов выкосило? Меня этот жанр не интересует, не слежу но вот мейнстримная литература особо не пострадала, целая россыпь молодых талантов, не буду до конкретных имен опускаться
Варианта всего два, реальный и фантастический. Реальный что прилетят марсиане и внедрят свой bi с бесплатной миграцией с текущего решения. И фантастический - если об этом расскажут на вебинаре :-) Более менее неплохие решения отечественных вендоров уже есть и уже можно их использовать, но сравнивать по эффективности с решениями условно большой тройки pbi клик табло...
Вы рассказываете, извините, сказки. При долгосрочном планировании работ никакие *команды" не простаивают. А сам waterfall которым всех пугают не существовал НИКОГДА. Это термин из статьи описывающей ГИПОТЕТИЧЕСКИЙ линейный процесс, теоретическую вымышленную ситуацию, но к сожалению, из статьи выдернули только термин, исказили смысл и дальше в клювиках понесли миру страшилки. А так то - некоторые из нас умеют играть в шашки тьфу в шахматы тьфу в разработку, а некоторые не умеют. И никакие ритуальные церемонии это не изменят :-)
Вас же не про архитектора спрашивали :-) К работе системного аналитика точно нет (про уровни сетевых стеков которые сугубо теория и в жизни не встречается - особенно прекрасно)
Проблема ВСЕях аналогичных статей много как и ничего о том для чего. Да понятно, много источников, много данных, плюс s3 для данных ml. Но к этому можно свести примерно все задачи, в том числе те для которых данная архитектура не подходит. Нет ничего о характере и демографии данных, нет ничего о способах обработки. Есть ли например потребность в массовых ad-hoc запросов, надо ли например над этим строить какую то сложную регуляную аналитику, есть ли потребность в ретроспективных выборках (получить данные по состоянию как было 3 мес. назад и так далее). Не скажу за всех, я ничего интересного не увидел
Потому что узкие тематики предназначены для специалистов, книга за время подготовки устаревает. Не очень понятен рынок такого рода изданий, он существует но его ценность сомнительна. Есть статьи, есть материалы конференций и документация на продукты. Книга нужна для систематизации базы, дальше ее ценность снижается по мере роста погруженности в тему.
У меня 50 человек в подчинении, собираю всех 2 раза в неделю, максимум по полчаса, из них 10 минут говорю я. Остальные рассказывают только про планы и конкретные проблемы. Команда получает постоянное понимание кто чемизанимается, там же набираются микрокоманды для решения проблем если они есть. Даже если человек работает над другими задачами все равно мог встречаться ранее с такой же или похожей проблемой. Остальные созвоны только точечные при крайней необходимости
Только в курилку бегали по желанию и во время которое сам выбрал лично для себя... 90% созвонов ненужная муть если команда профессионалов. Мое личное мнение
Извините, но очередная перепечатка документации или первых двух глав из любой книжки по эйрфлоу. Никакой специфики и как перестать страдать нет. Вводите читателя в заблуждение, что нехорошо
Именно так. Говорю как человек который сам таких стажеров постоянно берет (примерно на таких условиях) и сын которого полгода назад в тот же Я на стажировку прошел, именно так 3 из 5 решил а на следующих этапах задачки легче были чем на тренажере.
Почему нельзя было использовать один из стандартных движков? Из описания выглядит как наколеночная поделка ради поделки. Про текстовые параметры подключения которые куда то вводятся и сохраняются... Если я правильно понял о чем это, так же просто нельзя делать...
Да очень легко. Сказать что это не первое место куда ты сходил и уже есть оффер но решил еще посмотреть. Кстати когда человек так говорит, в 90% это так и есть. Ну, мой опыт говорит об этом.
Спасибо что в самом начале статьи написали иерархию где тимлид после синьора, дальше можно было уже не читать :-) Да бывают исключения но обычно это совсем разные ветки развития, хороший разработчик ставший хорошим тимлидом это редкий зверь, а вот наоборот на каждом шагу
Хороший материал, НО маленькое замечание, ей бы не помешал спойлер, то есть в стиле встретили странную ощибку, нашли что проблема была в... искали так... Это единственное замечание, в остальном изложенл хорошо, примеры, последовательность действий, подходы, цитаты из доки все хорошо и уместно, плюс однозначно
Вопрос зачем? В будущей жизни программирование на скрач никак не поможет, ну если ребенок сам очень заинтересован то может можно... но как развлечение а не как будущая карьера. Раньше 8-9 класса лучше уделить время чему то другому (мой опыт 30+ лет в it, отца троих детей двое из которых работают в , мягко говоря, не последних it компаниях)
Именно так
А почему так выборочно, только фантастов выкосило? Меня этот жанр не интересует, не слежу но вот мейнстримная литература особо не пострадала, целая россыпь молодых талантов, не буду до конкретных имен опускаться
Варианта всего два, реальный и фантастический. Реальный что прилетят марсиане и внедрят свой bi с бесплатной миграцией с текущего решения. И фантастический - если об этом расскажут на вебинаре :-) Более менее неплохие решения отечественных вендоров уже есть и уже можно их использовать, но сравнивать по эффективности с решениями условно большой тройки pbi клик табло...
Так это те же яйца только в профиль (про детей перестройки). Это как гороскопы, типа все одинаковые. Жизнь богаче :-)
Вот вот, это на солюшна очень похоже а не на системного аналитика
Вы рассказываете, извините, сказки. При долгосрочном планировании работ никакие *команды" не простаивают. А сам waterfall которым всех пугают не существовал НИКОГДА. Это термин из статьи описывающей ГИПОТЕТИЧЕСКИЙ линейный процесс, теоретическую вымышленную ситуацию, но к сожалению, из статьи выдернули только термин, исказили смысл и дальше в клювиках понесли миру страшилки. А так то - некоторые из нас умеют играть в шашки тьфу в шахматы тьфу в разработку, а некоторые не умеют. И никакие ритуальные церемонии это не изменят :-)
Я считаю, что нет. Автор считает иначе
Вас же не про архитектора спрашивали :-) К работе системного аналитика точно нет (про уровни сетевых стеков которые сугубо теория и в жизни не встречается - особенно прекрасно)
Проблема ВСЕях аналогичных статей много как и ничего о том для чего. Да понятно, много источников, много данных, плюс s3 для данных ml. Но к этому можно свести примерно все задачи, в том числе те для которых данная архитектура не подходит. Нет ничего о характере и демографии данных, нет ничего о способах обработки. Есть ли например потребность в массовых ad-hoc запросов, надо ли например над этим строить какую то сложную регуляную аналитику, есть ли потребность в ретроспективных выборках (получить данные по состоянию как было 3 мес. назад и так далее). Не скажу за всех, я ничего интересного не увидел
Потому что узкие тематики предназначены для специалистов, книга за время подготовки устаревает. Не очень понятен рынок такого рода изданий, он существует но его ценность сомнительна. Есть статьи, есть материалы конференций и документация на продукты. Книга нужна для систематизации базы, дальше ее ценность снижается по мере роста погруженности в тему.
Это верное уточнение
У меня 50 человек в подчинении, собираю всех 2 раза в неделю, максимум по полчаса, из них 10 минут говорю я. Остальные рассказывают только про планы и конкретные проблемы. Команда получает постоянное понимание кто чемизанимается, там же набираются микрокоманды для решения проблем если они есть. Даже если человек работает над другими задачами все равно мог встречаться ранее с такой же или похожей проблемой. Остальные созвоны только точечные при крайней необходимости
Только в курилку бегали по желанию и во время которое сам выбрал лично для себя... 90% созвонов ненужная муть если команда профессионалов. Мое личное мнение