Да, такой вариант я упустил. Но там будут те же проблемы, что и с вариантом №2 (надо будет дублировать часть функциональности RM) и потенциально могут быть проблемы с авторизацией.
Раз вам ненужно обосновывать свое субъективное мнение — тогда, пожалуйста, не придирайтесь к моему.
Рад, что мы пришли к консенсусу по одному из вопросов.
Для того, чтобы понять, на какой вопрос отвечает статья на ваш взгляд, мне понадобилось провести с вами довольно длительное общение. Подозреваю, что я не являюсь вашей аудиторией, поэтому от предоставления своих презентаций вам я воздержусь, спасибо.
Хорошо, тогда, пожалуйста, обоснуйте ваше утверждение про то, что ваш тезис ясно выражен.
Возможно, презренные трюки и рюшечки, о которых вы писали, направленны именно на это?
Мы снова возвращаемся к тому, что проблема не продемонстрирована. В статье нигде нет уточнения про то, что она касается только презентаций, претендующих на управление. Слово «управление» задействовано единожды — в определении риторики.
Хорошо, тогда ваше утверждение о том, что тезис ясно выражен, тоже безосновательно и является субъективным.
Управление людьми во время лекции про теорему — не дать им заснуть и заставить разобраться в материале. В свою очередь спрошу: а почему вы решили, что все презентации айтишников нужны для управления людьми? Есть и технические доклады, которые от лекции в университете не сильно по сути отличаются. Получается, что ваши советы подходят только для абстракного впаривания продукта инвесторам? Тогда вы не по адресу — это для больше маркетологов.
Из тех наблюдений, которые доступны мне (комментаторы) — тезис выражен неясно.
Судя по всему, мы вкладываем разное значение в слова «лекция» и «оратор».
Меня немного настораживает необходимость раскрывать тезис про то, что «лекцию про какую-нибудь теорему математическую» можно прочитать (преподнести) по-разному. У вас все лекторы в университете были одинаково хорошие/плохие? Попробую доказать от обратного — зачем тогда в вашем понимании лекторы в университете, если вся информация есть в учебнике/интернете?
Тогда вы, видимо, не понимаете аудитории, к которой обращаетесь. На 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 (на мой взгляд).
Конечно, это решается пунктом "тюнинга", но первая пачка кандидатов пройдет в никуда. Как уже писали выше, это ок, если поток большой, но плохо, если поток кандидатов маленький (хотя такие очевидные ошибки надо выявлять самостоятельно)
Да, такой вариант я упустил. Но там будут те же проблемы, что и с вариантом №2 (надо будет дублировать часть функциональности RM) и потенциально могут быть проблемы с авторизацией.
Рад, что мы пришли к консенсусу по одному из вопросов.
Для того, чтобы понять, на какой вопрос отвечает статья на ваш взгляд, мне понадобилось провести с вами довольно длительное общение. Подозреваю, что я не являюсь вашей аудиторией, поэтому от предоставления своих презентаций вам я воздержусь, спасибо.
Возможно, презренные трюки и рюшечки, о которых вы писали, направленны именно на это?
Мы снова возвращаемся к тому, что проблема не продемонстрирована. В статье нигде нет уточнения про то, что она касается только презентаций, претендующих на управление. Слово «управление» задействовано единожды — в определении риторики.
Управление людьми во время лекции про теорему — не дать им заснуть и заставить разобраться в материале. В свою очередь спрошу: а почему вы решили, что все презентации айтишников нужны для управления людьми? Есть и технические доклады, которые от лекции в университете не сильно по сути отличаются. Получается, что ваши советы подходят только для абстракного впаривания продукта инвесторам? Тогда вы не по адресу — это для больше маркетологов.
Судя по всему, мы вкладываем разное значение в слова «лекция» и «оратор».
Меня немного настораживает необходимость раскрывать тезис про то, что «лекцию про какую-нибудь теорему математическую» можно прочитать (преподнести) по-разному. У вас все лекторы в университете были одинаково хорошие/плохие? Попробую доказать от обратного — зачем тогда в вашем понимании лекторы в университете, если вся информация есть в учебнике/интернете?
Насчет лекции в университете — категорически не согласен. Один и тот же факт можно подавать по разному, и хороший лектор должен быть хорошим оратором, чтобы грамотно донести материал, сделать акцент на необходимом, зацепить аудиторию, повторить выжимку.
Вот вы написали стандартную структуру речи, в ней есть тезис, весь ваш посыл стать — про то, что должен быть один четкий тезис. А в статье он не выражен. Весьма странно и выглядит нелогичным.
Возможно, тезис в презентациях есть. Но вот возьмем в качестве примера презентацию к лекции по какому-либо предмету в университете — там тоже должен быть один тезис?
Для меня такая схема — не журналистская, а научная. А какая структура у «стандартной»?
Проблема наглядно не продемонстрирована — по вашему описанию я не могу понять, плохие ли мои презентации или нет. (Ок, вы говорите, что плохи, но не описываете четких критериев).
Касательно письменных текстов с вами полностью не могу согласиться. Есть аннотация/текст до ката, чтобы читатель понял, интересно ли ему вообще будет читать статью. Кроме того, один из стандартных шаблонов текста — введение, постановка задачи/описание цели, «мясо», заключение, причем тезис там должен фигурировать как минимум в заключении.
Продемонстрируйте, пожалуйста, а как ваши же советы работают на вашем тексте.
Я был на конференции как человек, который пришел послушать "про инструменты", причем про 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" очень тяжело понять это
Да, что-то я тупанул. Не прошел бы я ваше собеседование...
Конечно, это решается пунктом "тюнинга", но первая пачка кандидатов пройдет в никуда. Как уже писали выше, это ок, если поток большой, но плохо, если поток кандидатов маленький (хотя такие очевидные ошибки надо выявлять самостоятельно)