Это еще одно резюме, подобное тому, что я написал вчера. Как я уже сказал, компания, в которой я работаю, впервые отправила меня и всех наших старших разработчиков на DjangoCon в этом году. Так что не ожидайте, что это будет исчерпывающий обзор моего дня или дневника; это всего лишь краткое изложение тех разговоров, которые я слушал. Я сомневаюсь, что отдам должное некоторым разговорам, и, как всегда, это всего лишь мое мнение о том, что я слышал, так что просто имейте это в виду.
9:30 - Архитектура с каналами от @ andrewgodwin
На мой взгляд, это был основной лейтмотив всех выступлений, потому что многие другие люди определенно будут использовать этот пакет в будущем. Я пришел к этому докладу, зная много о каналах, во всяком случае не так хорошо, как Эндрю, но неплохо с тех пор, как проводил нагрузочное тестирование на нем. (Может, мне стоит написать, чем я занимаюсь.)
Самый большой вывод заключается в том, что это будет пакет, который позволит нам проявить гораздо больше творчества в наших архитектурах для решения конкретных проблем, которые мы пытаемся решить, потому что теперь мы будем освобождены от необходимости использовать HTTP / HTTPS. с одним сервером и db.
Если мы хотим делать это по-прежнему, потому что это отвечает нашим потребностям, мы все равно можем это сделать. Нам не нужно заниматься всем этим другим. Но каналы решают сложную проблему, заключающуюся в необходимости определить, как координировать работу большого количества серверов в производстве, чтобы использовать модель синхронного соединения, отличную от HTTP.
Для наших целей теперь у нас есть стандартизованный интерфейс, так что по мере появления других протоколов, таких как MQTT, мы не будем изобретать каждый заново колесо с тем, как взаимодействовать с остальной частью django.
Для ознакомления вот его слайды.
11:00 - уверенное развертывание активов от @scottburns
Это может показаться довольно редукционистским заключением, но в основном, если вы создаете SPA, вам нужно использовать webpack сейчас, потому что это то, что вы делаете. Конец истории. Вероятно, вам придется разделить команды или, по крайней мере, несколько отдельных сотрудников, и некоторые будут работать над внутренним интерфейсом, а другие - над внешним интерфейсом, и их согласованный интерфейс - это API. Статические файлы просто сбивают с толку фронтенд-инженеров. Так что, если вы не строите SPA, что по-прежнему довольно распространено, вам не нужно ничего делать. Вот его слайды.
11:30 - Приправка Django: Введение в Mezzanine CMS от @ je92rivas
Этот доклад был относительно простым: он должен был показать, как использовать Mezzanine. Поскольку я видел это раньше, для меня в этом не было ничего особенного, но я хочу получить еще один отзыв на тот случай, если я что-то пропустил. Возможно, вы почувствуете то же самое. Вот слайды для этого.
13:30 - Django поддерживает разработку игр для виртуальной реальности от @RudyMutter
Так что я не знал, чего ожидать от этого разговора. Поскольку я ни разу не сталкивался с виртуальной реальностью (я знаю, что я чудак) и не писал серьезного игрового кода, многое из того, о чем он говорил, пролетело у меня в голове. Буквально только дизайн конечной точки API и доставка ресурсов имели для меня смысл, потому что это было внутри моей рулевой рубки. Этот разговор заставил меня осознать, что существует целая область программирования, на которую я долгое время не обращал внимания. Так что это нужно изменить. Вот его фантастический набор слайдов.
14:20 - Высокая доступность Django от @FrankieDintino
В этом выступлении было множество конкретных предложений и деталей, которые помогли улучшить производительность сайта по сравнению с просто потерей трафика. Но в основном совет состоит в том, чтобы обязательно оптимизировать запросы, использовать прокси-кеш и использовать CDN. Но совершенно нормально и просто добавить больше машин для решения проблемы. Он добавил, что у Nginx есть какая-то проверка, чтобы узнать, возвращает ли сервер вашего приложения 200 с. Пока этого не произойдет, будет просто отображаться старый кеш. Очень полезно, когда тебя сильно ударили.
14:50 - Как произвести фурор в OpenSource от @ freakboy3742
Этот разговор был фантастическим. У меня было 3 важных вывода. (1) знать свою цель: вы просто хотите чем-то поделиться или хотите, чтобы другие люди часто этим пользовались? (2) Если вы хотите, чтобы другие использовали ваш материал, постарайтесь не создавать одноразовые инструменты, а постарайтесь создать что-то, что предназначено для расширения в остальную часть экосистемы, которую вы любите. (3) Если вы хотите, чтобы ваш материал использовался в течение длительного времени, вам нужно сообщество, а это означает, что вам нужно общаться гораздо больше, чем вы считаете необходимым.
15:50 - Прогулка по дороге A11y от @RadinaMatic
Мне нужно многое узнать о доступности. Раньше я думал о дальтонизме и структуре документа. А вот цветовой контраст и навигацию по клавиатуре я раньше не продумывал. Так что это была очень хорошая презентация, чтобы вывести эти вопросы на первый план.
16:40 - Angular 2 и ты от @pamasaur
Для меня весь этот разговор был очень простым. Раньше я возился с Angular 1, поэтому я хотел знать, что Angular 2 сделал по-другому. Она ответила на это очень быстро, а затем продемонстрировала, что это очень похоже на все другие SPA в их отношении к Django: то есть использовать API. Вот слайды!
17:10 - Я не знал, что наборы запросов могут сделать это от @charlierguo
Я так часто использую наборы запросов, что даже не ожидал, что узнаю что-нибудь новое из этого выступления. И, честно говоря, все представленное было тем, что я так или иначе видел раньше. Так что это было хорошим подтверждением того, что я ничего не упустил. Но если вы не так часто работаете с наборами запросов или если вы по какой-то причине помещаете их в списки Python и манипулируете таким образом, я обязательно посмотрю этот доклад, как только он появится на YouTube, потому что это фантастический одноразовый обзор для все queryset.
Выводы из большого тренда
Нас всех беспокоят масштабируемые архитектуры, и мы ищем способы их оптимизации, но все наши проблемы и приложения разные. Однако инструменты для решения этих проблем - это те же инструменты, которые у нас были всегда, поэтому мы просто становимся более зрелыми как сообщество в плане их регулярного внедрения.
Новые приложения не за горами, потому что с обработкой естественного языка, виртуальной реальностью и многофункциональными приложениями с бэкэндами API все только начинают быть на пороге повсеместного распространения, мы все вот-вот увидим гигантский сдвиг в каковы будут ожидания наших пользователей от их опыта. Осмелюсь предположить, что это будет где-то на уровне, вроде перехода от Web 2.0 к адаптивному использованию мобильных устройств около 5 лет назад.
Войны JavaScript только начинают разгораться. Сегодня я услышал о том, почему мы могли бы захотеть использовать Angular 2. И, в частности, использовать TypeScript для написания Angular 2. Это в дополнение к упоминанию Meteor и Vue ранее днем двумя другими спикерами. На данный момент я понятия не имею, кто победит, но ясно, что нас, как backend-инженеров, прямо сейчас просят выбрать сторону, хотя в конце дня они все будут просто разговаривать через REST API с Django. . (Хотя, похоже, еще предстоит обсудить, какую реализацию вы хотите использовать для этого. Лично я предпочитаю DRF.)
