Но важно помнить, что неправильная аудитория может быть обоснована очень разными нюансами. Например, как-то раз мой хардкорный доклад на узкую аудиторию вместо малого зала поставили в большой (спикер оттуда резко отвалился). В большом зале конференции стабильно собираются неопределившиеся: непонятно, на что идти, ну наверное в большом зале что-то интересное (и кресла удобнее). Итог: понравилось целевой аудитории, а вот все зашедшие случайно были в шоке.
Мораль тут только в формате «внимательно изучите условия вокруг доклада перед тем, как его хоронить/переделывать»
Фидбэк от докладов это боль, потому что он ужасно противоречив. Обычно, глядя на отзывы после конференции, я вижу одновременно несколько отзывов формата «слишком много воды, непрактично» и «какой классный практичный материал!». Все честные и искренние.
Советы примерно такие:
— Группировать отзывы. В массовых отзывах редко есть смысл исправлять что-то по отдельным отзывам, но вот три-четыре фидбека об одном и том же — это сигнал.
— Много тех, для кого доклад «не в тему, не интересно, слишком легко»? Подумайте, на ту ли аудиторию вы вещаете. Обычно если претензии именно к теме, вы рассказываете доклад не тем людям.
— Общайтесь с людьми. Текстовые фидбеки это прикольно, но хорошенько, со всех сторон обсудить доклад это намного полезнее. Особенно если это опытные ребята вроде ПК.
— Не «рвите» доклад, пытаясь исправить весь фидбек. У любого доклада есть недостатки, и часто это обратная сторона его же преимуществ. У интригующего доклада похуже структура, в хардкорный трудно вникать, доклад с личным опытом легко превратится в набор советов. Хаотичные исправления могут разрушить цельность доклада, нужно аккуратно следить, как доклад меняется после правок.
Идеальное — это сложно, не бывает таких. Скорее, бывают классные кандидаты в определенных номинациях.
Я много всякого упоминал в статье про публичные выступления. Мой любимый пример развлекательно-технического доклада — «Синдром серебрянной пули» от Хади Харири. Хардкорище отличное неоднократно получалось у Алексея Шипилева: у него есть важная для хардкора черта, его приятно слушать даже тогда, когда непонятно. Из практичных мои фавориты это Scott Wlaschin и, например, «Быстрорастворимое проектирование» от marshinov.
Правда надеюсь, что у нас получится все это вывезти и поддерживать. Очень хочется, чтобы такой формат прижился и компании не просто делали много хаотичных статей и митапов, а помогали сообществам вот такими полезными штуками.
Почти во всем согласен. Основная штука да, в том что бренд — это некоторый образ, а не просто характеристика, которая может быть лучше/хуже. «Тот чувак со смешными волосами, который про F#», «Рассказывающий про что-то перфомансное парень в синей рубашке» и так далее.
Во-первых, этот образ может оказаться не тем, что нужно рынку. Во-вторых, конкретный образ сужает поле возможностей. Он упрощает работу в той области, которой этот образ соответствует, но все остальные автоматически обращают на тебя меньше внимания.
Ну и да, это затратная штука. Тут никаких вопросов.
Не, доклады это плохой формат для гайдов, так что там кидаться тоннами информации нет смысла. А эта статья это именно сборник всей нужной информации по подготовке доклада.
Ну и оглавление сильно упрощает жизнь! Отдельные главы вполне независимы и читаемы отдельно друг от друга.
Зависит. Именно из-за знания концепций я легко пишу продакшеновый код на разных языках, когда этого требует проектная необходимость. Даже low-level штуки гораздо легче учить — опять же, там используются некоторые общие концепции. Хаки и те похожи.
Собственно, статья во многом об этом и как раз-таки о t-shaped. О том, что фул-стек должен обеспечиваться за счет понимания разных принципов, которые ты можешь комбинировать в своем арсенале. И это протиповопоставляется системе архетипов с жестко выстроенным скиллсетом.
Вопрос того, на чем ты фокусируешься. Изучать языки как функции и операторы действительно довольно бессмысленно, но вот концепции это совсем другое дело.
Если бы я не полез учить Haskell, мне было бы куда сложнее понять часть особенностей C# и многих других современных языков.
Если бы я не полез учить Python, то не почувствовал бы особенностей работы с динамической типизацией и рядом других особенностей.
Учить похожие general purpose языки достаточно бессмысленно, разумеется. Особенно бесполезно заучивать функции и операторы. А вот смотреть на разные языки и подходы, чтобы понять лежащие в их основе идеи и механизмы это как раз полезно и переиспользуемо.
Заметна. Но ребята из SkillFactory могут выбирать, какие статьи переводить. В моем понимании, переводить инструкцию по запуску нет особенного смысла, да и это не тот материал, который хотелось бы видеть на Хабре.
У меня возникло ощущение, что статья была выбрана по принципу «звучит хайпово, а переводится быстро». Поэтому ворчу :)
Вот и всё. Мы обсудили пошаговое реальное применение модели SkinDeep для удаления татуировок с кожи.
Что обидно — нет, не обсудили. Вы дали код и инструкцию по его запуску, а пояснений, как это чудо техники работает не дали нисколько. Альтернативы не обсудили, плюсы и минусы. Это инструкция по развертыванию решения, а не пояснение или дискуссия.
На самом деле, каждая версия дотнета исправляет большое количество ошибок и это радует.
Хотя каждая и добавляет новых. Например, в чате DotNetRu рассказали, что кое-где новая версия дотнета вызвала заметное падение производительности.
Кроссплатформенный GUI обещают в .NET 6, MAUI. Но да, не в этой версии.
Кстати, можно поучиться у тех самых nodejs Electron программистов и пользоваться Electron.NET. На все той же .NET Conf был неплохой доклад про это.
Но важно помнить, что неправильная аудитория может быть обоснована очень разными нюансами. Например, как-то раз мой хардкорный доклад на узкую аудиторию вместо малого зала поставили в большой (спикер оттуда резко отвалился). В большом зале конференции стабильно собираются неопределившиеся: непонятно, на что идти, ну наверное в большом зале что-то интересное (и кресла удобнее). Итог: понравилось целевой аудитории, а вот все зашедшие случайно были в шоке.
Мораль тут только в формате «внимательно изучите условия вокруг доклада перед тем, как его хоронить/переделывать»
Фидбэк от докладов это боль, потому что он ужасно противоречив. Обычно, глядя на отзывы после конференции, я вижу одновременно несколько отзывов формата «слишком много воды, непрактично» и «какой классный практичный материал!». Все честные и искренние.
Советы примерно такие:
— Группировать отзывы. В массовых отзывах редко есть смысл исправлять что-то по отдельным отзывам, но вот три-четыре фидбека об одном и том же — это сигнал.
— Много тех, для кого доклад «не в тему, не интересно, слишком легко»? Подумайте, на ту ли аудиторию вы вещаете. Обычно если претензии именно к теме, вы рассказываете доклад не тем людям.
— Общайтесь с людьми. Текстовые фидбеки это прикольно, но хорошенько, со всех сторон обсудить доклад это намного полезнее. Особенно если это опытные ребята вроде ПК.
— Не «рвите» доклад, пытаясь исправить весь фидбек. У любого доклада есть недостатки, и часто это обратная сторона его же преимуществ. У интригующего доклада похуже структура, в хардкорный трудно вникать, доклад с личным опытом легко превратится в набор советов. Хаотичные исправления могут разрушить цельность доклада, нужно аккуратно следить, как доклад меняется после правок.
Идеальное — это сложно, не бывает таких. Скорее, бывают классные кандидаты в определенных номинациях.
Я много всякого упоминал в статье про публичные выступления. Мой любимый пример развлекательно-технического доклада — «Синдром серебрянной пули» от Хади Харири. Хардкорище отличное неоднократно получалось у Алексея Шипилева: у него есть важная для хардкора черта, его приятно слушать даже тогда, когда непонятно. Из практичных мои фавориты это Scott Wlaschin и, например, «Быстрорастворимое проектирование» от marshinov.
Обязательно будут, на Ютубе и ссылка на них в репозитории.
Я думаю, что у нас вообще будет отдельный блок «для начинающих», с самыми-самыми базовыми материалами.
Правда надеюсь, что у нас получится все это вывезти и поддерживать. Очень хочется, чтобы такой формат прижился и компании не просто делали много хаотичных статей и митапов, а помогали сообществам вот такими полезными штуками.
Во-первых, этот образ может оказаться не тем, что нужно рынку. Во-вторых, конкретный образ сужает поле возможностей. Он упрощает работу в той области, которой этот образ соответствует, но все остальные автоматически обращают на тебя меньше внимания.
Ну и да, это затратная штука. Тут никаких вопросов.
Ну и оглавление сильно упрощает жизнь! Отдельные главы вполне независимы и читаемы отдельно друг от друга.
Собственно, статья во многом об этом и как раз-таки о t-shaped. О том, что фул-стек должен обеспечиваться за счет понимания разных принципов, которые ты можешь комбинировать в своем арсенале. И это протиповопоставляется системе архетипов с жестко выстроенным скиллсетом.
Если бы я не полез учить Haskell, мне было бы куда сложнее понять часть особенностей C# и многих других современных языков.
Если бы я не полез учить Python, то не почувствовал бы особенностей работы с динамической типизацией и рядом других особенностей.
Учить похожие general purpose языки достаточно бессмысленно, разумеется. Особенно бесполезно заучивать функции и операторы. А вот смотреть на разные языки и подходы, чтобы понять лежащие в их основе идеи и механизмы это как раз полезно и переиспользуемо.
У меня возникло ощущение, что статья была выбрана по принципу «звучит хайпово, а переводится быстро». Поэтому ворчу :)
Что обидно — нет, не обсудили. Вы дали код и инструкцию по его запуску, а пояснений, как это чудо техники работает не дали нисколько. Альтернативы не обсудили, плюсы и минусы. Это инструкция по развертыванию решения, а не пояснение или дискуссия.
Хотя каждая и добавляет новых. Например, в чате DotNetRu рассказали, что кое-где новая версия дотнета вызвала заметное падение производительности.
Кстати, можно поучиться у тех самых nodejs Electron программистов и пользоваться Electron.NET. На все той же .NET Conf был неплохой доклад про это.
А вообще — я и впрямь не вижу ничего особо впечатляющего в C# 9. Приятные мелочи, не более.
Обзор кроссплатформенного GUI для .NET от Миши Романова
Страдание над новыми фичами Авалонии от Никиты Цуканова
И эффективное кэширование от Саши Якунина