Раз вам ненужно обосновывать свое субъективное мнение — тогда, пожалуйста, не придирайтесь к моему.
Рад, что мы пришли к консенсусу по одному из вопросов.
Для того, чтобы понять, на какой вопрос отвечает статья на ваш взгляд, мне понадобилось провести с вами довольно длительное общение. Подозреваю, что я не являюсь вашей аудиторией, поэтому от предоставления своих презентаций вам я воздержусь, спасибо.
Хорошо, тогда, пожалуйста, обоснуйте ваше утверждение про то, что ваш тезис ясно выражен.
Возможно, презренные трюки и рюшечки, о которых вы писали, направленны именно на это?
Мы снова возвращаемся к тому, что проблема не продемонстрирована. В статье нигде нет уточнения про то, что она касается только презентаций, претендующих на управление. Слово «управление» задействовано единожды — в определении риторики.
Хорошо, тогда ваше утверждение о том, что тезис ясно выражен, тоже безосновательно и является субъективным.
Управление людьми во время лекции про теорему — не дать им заснуть и заставить разобраться в материале. В свою очередь спрошу: а почему вы решили, что все презентации айтишников нужны для управления людьми? Есть и технические доклады, которые от лекции в университете не сильно по сути отличаются. Получается, что ваши советы подходят только для абстракного впаривания продукта инвесторам? Тогда вы не по адресу — это для больше маркетологов.
Из тех наблюдений, которые доступны мне (комментаторы) — тезис выражен неясно.
Судя по всему, мы вкладываем разное значение в слова «лекция» и «оратор».
Меня немного настораживает необходимость раскрывать тезис про то, что «лекцию про какую-нибудь теорему математическую» можно прочитать (преподнести) по-разному. У вас все лекторы в университете были одинаково хорошие/плохие? Попробую доказать от обратного — зачем тогда в вашем понимании лекторы в университете, если вся информация есть в учебнике/интернете?
Тогда вы, видимо, не понимаете аудитории, к которой обращаетесь. На Geektimes, согласно описанию сайта, «пользователи размещают информацию преимущественно научно-популярного характера».
Насчет лекции в университете — категорически не согласен. Один и тот же факт можно подавать по разному, и хороший лектор должен быть хорошим оратором, чтобы грамотно донести материал, сделать акцент на необходимом, зацепить аудиторию, повторить выжимку.
Вот вы написали стандартную структуру речи, в ней есть тезис, весь ваш посыл стать — про то, что должен быть один четкий тезис. А в статье он не выражен. Весьма странно и выглядит нелогичным.
Дополню, что факт «в ваших презентациях отсутствует тезис» наглядно не продемонстрирован. Хоть бы несколько живых примеров показали. Насколько я представляю, «ИТ-аудитория» не любит голословных утверждений. Возможно, вам стоит подкрепить свои тезисы исследованием (в идеале — научным и с экспериментом).
Голосование вряд ли бы помогло, т.к. оно подразумевает ограниченный набор вариантов. Лично я думал, что тут основной упор идет на то, что надо понимать и знать свою аудиторию.
Возможно, тезис в презентациях есть. Но вот возьмем в качестве примера презентацию к лекции по какому-либо предмету в университете — там тоже должен быть один тезис?
Для меня такая схема — не журналистская, а научная. А какая структура у «стандартной»?
Не согласен, что этот тезис здесь был очевиден. На мой взгляд, комментаторы его хоть и похоже, но тем не менее по-разному восприняли.
Проблема наглядно не продемонстрирована — по вашему описанию я не могу понять, плохие ли мои презентации или нет. (Ок, вы говорите, что плохи, но не описываете четких критериев).
Касательно письменных текстов с вами полностью не могу согласиться. Есть аннотация/текст до ката, чтобы читатель понял, интересно ли ему вообще будет читать статью. Кроме того, один из стандартных шаблонов текста — введение, постановка задачи/описание цели, «мясо», заключение, причем тезис там должен фигурировать как минимум в заключении.
Я был на конференции как человек, который пришел послушать "про инструменты", причем про Big Data, а не про ML. От Data science я далек, но, не смотря на это, из от нехардкорных докладов по этой теме тоже получил полезную информацию. И, разумеется, я скажу: "Больше докладов про spark, yarn, clickhouse и т.д." и буду отвечать с точки зрения этой колокольни.
1) Я считаю, что в формате, где две области сразу — это имеет свой плюс, но надо явно отмечать доклады по двум критериям (наука/инструменты). Это уже и в чатике телеграмма обсуждалось и еще где-то.
2/6) Spark, Kafka, ClickHouse, Qubole, Yarn, Ignite…
3) О том, чем хорош их продукт. И обязательно о том, где он плох/где не стоит использовать. Если он везде хорош — значит что-то не так.
4/5) Честно, я не варюсь в этой области и не знаю, кто эти люди искренне в этом раскаиваюсь и готов принять за это кару небесную
7) Считаю, что это особо не важно. Главное, чтобы кейсы были интересные.
8) Ничего.
9) Лучше провести эксперимент и собрать обратную связь.
10) Нужны.
Я подозреваю, что это частично связано с тем, что там внизу Java, частично с тем, что потенциально будет проблемно построить иерархию сообщений/ответов — ведь есть еще служебные сообщения и сообщения жизненного цикла.
Если посмотреть в реализацию актора, возврат там вообще только проверяется на null и все.
Да это и в Akka тоже реализовано из коробки, тогда уж целесообразнее на scala это писать. На совсем новой экосистеме наш проект делать было бы довольно затратно — все-таки у erlang философия сильно отличается от Java (на мой взгляд).
Конечно, это решается пунктом "тюнинга", но первая пачка кандидатов пройдет в никуда. Как уже писали выше, это ок, если поток большой, но плохо, если поток кандидатов маленький (хотя такие очевидные ошибки надо выявлять самостоятельно)
Еще неплохо бы убедиться, что задания не содержат ошибок.
В частности, пример кода с вставкой строки не будет работать, если массив составлен из отрицательных чисел. Это вызовет негативную реакцию у внимательного кандидата.
Рад, что мы пришли к консенсусу по одному из вопросов.
Для того, чтобы понять, на какой вопрос отвечает статья на ваш взгляд, мне понадобилось провести с вами довольно длительное общение. Подозреваю, что я не являюсь вашей аудиторией, поэтому от предоставления своих презентаций вам я воздержусь, спасибо.
Возможно, презренные трюки и рюшечки, о которых вы писали, направленны именно на это?
Мы снова возвращаемся к тому, что проблема не продемонстрирована. В статье нигде нет уточнения про то, что она касается только презентаций, претендующих на управление. Слово «управление» задействовано единожды — в определении риторики.
Управление людьми во время лекции про теорему — не дать им заснуть и заставить разобраться в материале. В свою очередь спрошу: а почему вы решили, что все презентации айтишников нужны для управления людьми? Есть и технические доклады, которые от лекции в университете не сильно по сути отличаются. Получается, что ваши советы подходят только для абстракного впаривания продукта инвесторам? Тогда вы не по адресу — это для больше маркетологов.
Судя по всему, мы вкладываем разное значение в слова «лекция» и «оратор».
Меня немного настораживает необходимость раскрывать тезис про то, что «лекцию про какую-нибудь теорему математическую» можно прочитать (преподнести) по-разному. У вас все лекторы в университете были одинаково хорошие/плохие? Попробую доказать от обратного — зачем тогда в вашем понимании лекторы в университете, если вся информация есть в учебнике/интернете?
Насчет лекции в университете — категорически не согласен. Один и тот же факт можно подавать по разному, и хороший лектор должен быть хорошим оратором, чтобы грамотно донести материал, сделать акцент на необходимом, зацепить аудиторию, повторить выжимку.
Вот вы написали стандартную структуру речи, в ней есть тезис, весь ваш посыл стать — про то, что должен быть один четкий тезис. А в статье он не выражен. Весьма странно и выглядит нелогичным.
Возможно, тезис в презентациях есть. Но вот возьмем в качестве примера презентацию к лекции по какому-либо предмету в университете — там тоже должен быть один тезис?
Для меня такая схема — не журналистская, а научная. А какая структура у «стандартной»?
Проблема наглядно не продемонстрирована — по вашему описанию я не могу понять, плохие ли мои презентации или нет. (Ок, вы говорите, что плохи, но не описываете четких критериев).
Касательно письменных текстов с вами полностью не могу согласиться. Есть аннотация/текст до ката, чтобы читатель понял, интересно ли ему вообще будет читать статью. Кроме того, один из стандартных шаблонов текста — введение, постановка задачи/описание цели, «мясо», заключение, причем тезис там должен фигурировать как минимум в заключении.
Продемонстрируйте, пожалуйста, а как ваши же советы работают на вашем тексте.
Я был на конференции как человек, который пришел послушать "про инструменты", причем про Big Data, а не про ML. От Data science я далек, но, не смотря на это, из от нехардкорных докладов по этой теме тоже получил полезную информацию. И, разумеется, я скажу: "Больше докладов про spark, yarn, clickhouse и т.д." и буду отвечать с точки зрения этой колокольни.
1) Я считаю, что в формате, где две области сразу — это имеет свой плюс, но надо явно отмечать доклады по двум критериям (наука/инструменты). Это уже и в чатике телеграмма обсуждалось и еще где-то.
2/6) Spark, Kafka, ClickHouse, Qubole, Yarn, Ignite…
3) О том, чем хорош их продукт. И обязательно о том, где он плох/где не стоит использовать. Если он везде хорош — значит что-то не так.
4/5) Честно, я не варюсь в этой области и не знаю, кто эти люди искренне в этом раскаиваюсь и готов принять за это кару небесную
7) Считаю, что это особо не важно. Главное, чтобы кейсы были интересные.
8) Ничего.
9) Лучше провести эксперимент и собрать обратную связь.
10) Нужны.
Т.е. вся суть статьи — "забей"?
Смотрел, но на тот момент (kotlin 1.0.6) они были в зачаточном состоянии, и пришлось бы акторы реализовать самостоятельно.
Я подозреваю, что это частично связано с тем, что там внизу Java, частично с тем, что потенциально будет проблемно построить иерархию сообщений/ответов — ведь есть еще служебные сообщения и сообщения жизненного цикла.
Если посмотреть в реализацию актора, возврат там вообще только проверяется на null и все.
Но выглядит не очень, согласен.
Да это и в Akka тоже реализовано из коробки, тогда уж целесообразнее на scala это писать. На совсем новой экосистеме наш проект делать было бы довольно затратно — все-таки у erlang философия сильно отличается от Java (на мой взгляд).
Либо я тупой, либо по заголовку "Чем занимается Product Marketing Manager в JetBrains" очень тяжело понять это
Да, что-то я тупанул. Не прошел бы я ваше собеседование...
Конечно, это решается пунктом "тюнинга", но первая пачка кандидатов пройдет в никуда. Как уже писали выше, это ок, если поток большой, но плохо, если поток кандидатов маленький (хотя такие очевидные ошибки надо выявлять самостоятельно)
Еще неплохо бы убедиться, что задания не содержат ошибок.
В частности, пример кода с вставкой строки не будет работать, если массив составлен из отрицательных чисел. Это вызовет негативную реакцию у внимательного кандидата.