Презентации появляются здесь www.slideshare.net/geekfamilyrussia в течении дня зальем все оставшиеся презентации.
Видео будет гораздо позже после обработки его. Что-то это медленный процесс оказывается.
Мы сделали записи докладов, пока не успели обработать. Сегодня сделаем на нашем сайте доступ к слайдам презентаций. По секции «Карьера» — мы планируем опубликовать одну или две статьи, где изложим самые важные тезисы.
Более чем легко. Он говорит очень четко, медленно и с интонациями. Только когда начинает рассказывать истории из жизни, его несколько заносить в сторону увеличения скорости произношения. В остальном он использует самые простые слова и старается донести все очень простым языком.
Как-то совсем мало. Прямо даже и не видно примеров как было «грязно» и как стало хорошо с Rx.
Понятно, что с переводчика взятки гладки, но для популяризации и привлечения внимания к Rx можно было бы что-то более интересное найти.
А так же воткнуть отсебятины и ссылку на официальный сайт www.introtorx.com/
Да, спрашивают общие вещи на понимание. Как объекты переходят из поколение в поколение. Как происходит Dispose, что там и как происходит, сколько объект может висеть в очереди на удаление. Как можно потыкать палочкой GC.
Достижимость, корни, как объекты живут на стеке и когда оттуда уходят.
Сборщик мусора в .net один и везде, насколько я помню, утверждается, что тюнить его и работать с ним надо в последнюю очередь. Так как себе дороже может оказаться со всем этим возиться. Единственное что порой рекомендуется делать, явно указать профиль работы: standalone или server (как-то так кажется. )
Сборщик мусора еще немного меняется от версии к версии самой платформы и изменения особенно не афишируются.
Много чего вы написали правильно, но может быть ограничение по времени сыграет свою роль? Я был на многих конференциях как слушателем, так и докладчиком. Обычно хронометраж выступления укладывается в 40-70 минут. И это очень много. Но для раскрытия темы хватает минут 10, если по существу. Просто стоит обратить внимание на то, как идет обмен знаний в коллективе рабочем. Вряд ли кто-то растекается мыслью по древу на протяжении даже 20 минут. Ему просто скажут: «Давай резче, Уася! Ты чего сказать-то хочешь?»
Вот было бы реальной пользой, если бы организаторы конференций не давали разбежаться или попрятаться докладчикам.
Уже подтолкнула к тому, чтобы покопать интернет на счет таких проверок. Для .NET нашел наиболее свежий\живой проект портирования QuickCheck. Так что буду исследовать тоже, смотреть, что можно с этим делать в условиях близких к продакшену.
Спасибо за статью! Очень интересно и познавательно.
Сразу после прочтения возникают вопросы о тестировании методов с более сложными объектами, интересно, как это может выглядеть, если вообще возможно. Просмотр презентации, в некотором роде раскрывает области применения, так что часть вопросов снимается.
Дальнейшее гугление показало, что QuickCheck не рассматривается как альтернатива юнит-тестированию, а как дополнение к общему массиву тестов. Например, основные 80% сценариев легче и быстрее возможно покрыть обычными тестами, и только потом уже дописать теории. Так как описать ограничения на свойства тестируемого объекта несколько сложнее. В силу хотя бы того, что непривычно и нет большого пула примеров, что ли.
На одной из фотографий видны блики на «мониторе заднего вида». Да и само по себе свечение монитора может утомлять глаз, в условиях переменной освещенности дороги. Навигаторы, к слову, будут поменьше размерами и вроде как не на таком уровне.
При ночном вождении будет интересно посмотреть как это будет выглядеть с дальним светом обгоняющего автомобиля. Какие фильтры наложат и как затенится изображение.
Такие статьи могут сподвигнуть на «попробовать технологию». Но для совсем-совсем новичков, все статьи такого толка страдают одним общим изъяном: куда всё это записать и как запустить?!. Плюс, в статье как-бы невзначай приплетается серверная сторона проекта, создается впечатление, что она магическим образом получилась.
После чего они, чертыхаясь, забивают на конкретную статью и идут разбираться как вообще организовать проект, указать зависимости, и всё такое прочее.
Это без претензий к переводчику, если что, а вообще к такому виду «туториалов»
Но… открыв оригинал я вижу, что пропущены первые вводные строки текста:
As we already know, AngularJS doesn’t come with an out of the box solution for data modeling. In the most abstract way, AngularJS lets us use JSON data as a model in the controller.
Которые сразу намекают на некоторую степень подготовленности читателя. И сразу претензии к тексту снимаются. В текущем же виде перевод напоминает выдранную главу из большого туториала «от и до», где хотелось бы видеть ссылки на начало процесса
К слову, энтерпрайз решениям важно движение данных и их история, которое лучше всего делается на анемичном домене. DDD Фаулера — для работы с состояниям объектов. Как-то так мне видится это.
На эту тему уже высказывались очень многие известные люди помимо Фаулера и компании. Тут ведь все зависит от того, какая идея лежит за самим приложением, какая архитектура используется. Например, есть такой подход CQRS. Сам по себе он говорит только о разделении команд и запросов. Но на практике такая система начинает часто сопрягаться с EventQueue и MessageBus и так далее. И как раз в такой системе Anemic (больше нравится «бескровный») Domain Model как раз кстати.
CQRS известна давно и это не ноу-хау последней пятилетки. Просто такие системы сложнее проектировать и поддерживать. Но у них есть своя ниша. Большинству же приложений хватит «стандартного» подхода, т.е. того который описывается у Фаулера. И в этом плане статья очень полезная, так как смешение ответственностей в классах огромная проблема. И решается она только опытом, когда уже начинаешь понимать, что оставить в доменном объекте, а что унести в сервис.
Видео будет гораздо позже после обработки его. Что-то это медленный процесс оказывается.
Спасибо за перевод!
Понятно, что с переводчика взятки гладки, но для популяризации и привлечения внимания к Rx можно было бы что-то более интересное найти.
А так же воткнуть отсебятины и ссылку на официальный сайт www.introtorx.com/
Достижимость, корни, как объекты живут на стеке и когда оттуда уходят.
Сборщик мусора в .net один и везде, насколько я помню, утверждается, что тюнить его и работать с ним надо в последнюю очередь. Так как себе дороже может оказаться со всем этим возиться. Единственное что порой рекомендуется делать, явно указать профиль работы: standalone или server (как-то так кажется. )
Сборщик мусора еще немного меняется от версии к версии самой платформы и изменения особенно не афишируются.
Вот было бы реальной пользой, если бы организаторы конференций не давали разбежаться или попрятаться докладчикам.
Сразу после прочтения возникают вопросы о тестировании методов с более сложными объектами, интересно, как это может выглядеть, если вообще возможно. Просмотр презентации, в некотором роде раскрывает области применения, так что часть вопросов снимается.
Дальнейшее гугление показало, что QuickCheck не рассматривается как альтернатива юнит-тестированию, а как дополнение к общему массиву тестов. Например, основные 80% сценариев легче и быстрее возможно покрыть обычными тестами, и только потом уже дописать теории. Так как описать ограничения на свойства тестируемого объекта несколько сложнее. В силу хотя бы того, что непривычно и нет большого пула примеров, что ли.
При ночном вождении будет интересно посмотреть как это будет выглядеть с дальним светом обгоняющего автомобиля. Какие фильтры наложат и как затенится изображение.
После чего они, чертыхаясь, забивают на конкретную статью и идут разбираться как вообще организовать проект, указать зависимости, и всё такое прочее.
Это без претензий к переводчику, если что, а вообще к такому виду «туториалов»
Но… открыв оригинал я вижу, что пропущены первые вводные строки текста:
Которые сразу намекают на некоторую степень подготовленности читателя. И сразу претензии к тексту снимаются. В текущем же виде перевод напоминает выдранную главу из большого туториала «от и до», где хотелось бы видеть ссылки на начало процесса , чтобы было видно как приложение растет.
К слову, энтерпрайз решениям важно движение данных и их история, которое лучше всего делается на анемичном домене. DDD Фаулера — для работы с состояниям объектов. Как-то так мне видится это.
CQRS известна давно и это не ноу-хау последней пятилетки. Просто такие системы сложнее проектировать и поддерживать. Но у них есть своя ниша. Большинству же приложений хватит «стандартного» подхода, т.е. того который описывается у Фаулера. И в этом плане статья очень полезная, так как смешение ответственностей в классах огромная проблема. И решается она только опытом, когда уже начинаешь понимать, что оставить в доменном объекте, а что унести в сервис.