В этой статье вы найдёте несколько полезных советов для тех, кто хочет стать программистом. Совет 1. Определитесь с языком программирования Выбор языка программирования — первая трудность, с которой встречаются новички. Сколько программистов — столько и мнений о языках, поэтому выделить «лучший» среди них нельзя. Почему? Каждый язык создан для определённой области разработки и решения определённых задач. Для выбора языка программирования, ориентируйтесь на ваши желания. Какие программы и сервисы вы хотите создавать? Делать игры на Unity? Сайты на HTML, CSS и JavaScript? Или, может быть, бизнес-приложения на С# или Java? Python широко используется в науке для быстрых вычислений. При выборе учитывайте порог вхождения языка (Python, например, изучается быстрее и легче С++) и ваши предрасположенности. Кроме того, перед изучением любого языка стоит изучить основы программирования. Разберитесь, что такое двоичный код, компилятор, познакомьтесь с алгоритмами и шаблонами проектирования. Совет 2. Применяйте метод дробления материала Если вы решили стать программистом, вам нужно будет очень мнрогое изучить и запомнить. Сделать это «с наскока» будет трудно. Не хваатайтесь за все сразу. Ставьте перед собой небольшие реальные, достижимые цели. Например, изучайте одну тему за 1 день. При изучении любого языка начинайте с самых основ, постепенно продвигаясь вперёд. Закрепляйте пройденный материал практикой, если есть какие-то небольшие пробелы в знаниях — двигайтесь дальше, возможно, вы заполните их потом. Но не оставляйте слишком много «белых пятен», иначе запутаетесь. На помощь в структурировании информации вам придут различные техники запоминания (ассоциации, карточки) и ваш собственный дневник обучения, в котором вы можете записывать усвоенный материал, как говорят, «своими словами», и затем проверять его на практике. Совет 3.  Не стесняйтесь использовать детские обучающие программы и курсы. В детских программах часто подают упрощенные знания, основы основ. Не стесняйтесь пробовать детские игры и курсы, в которых материал усваивается значительно легче. Кроме того, это бываает весело! Прослушав материал в упрощенном виде, вы сможете понять его, и дальнейшее изучение программирования будет даваться вам значительно легче. Кроме того, к временной помощи детских курсов можно прибегнуть, если какой-то участок материала даётся вам с трудом, и понять его вы никак не можете. Прослушав упрощенный материал, вы получите взгляд со стороны и, возможно, наконец сможете понять материал. Совет 4. Разбирайте чужой код Это больше относится к практике. Разбирая чужой код, вы начнёте понимать, почему программа работает или не работает. Перенимая чужой опыт, вы получаете новые знания и фишки, которые помогут вам в будущем. Читая код другого программиста, вы улучшите своё общее понимание программирования и убережете себя от ошибок. Кроме того, разбор чужого кода также может помочь вам сдвинуться с мёртвой точки. Если вам что-то не понятно, то вы можете просмотреть чей-то код и получить его советы. Таким образом, вы сможете понять, как сделать правильно и почему часть программы у другого человека работает правильно, а у вас — нет. Совет 5. Читайте полезную литературу Не смотря на то, что сейчас больше людей предпочитают литературе курсы, статьи и видео, чтение актуальных книг по программированию поможет вам глубже изучить программирование. Некоторые книги вообще являются признанной классикой, например книга Роберта Мартина «Чистый Код» детально описывает процесс создания чистого кода, и указывает на ошибки, которые могут возникнуть при написании красивого кода. Фактически, эта книга — «библия» для тех, кто стремится писать чистый код. Поискав в Гугле другие книги по вашему направлению, вы можете скомбинировать их со справочниками, и получить «универсальный набор» программиста, в котором вы найдёте ответы на большинство своих вопросов. Общепризнанную литературу можно читать в переводе, но большинство актуальной литературы выходит в мир на английском, и переводится на русский с опозданием в год-два, когда уже всё поменялось. Поэтому дополнительный совет: уделите внимание изучению английского языка! С английским вы всегда сможете получать актуальную информацию, общаться с зарубежными программистами, английский облегчит вам изучение программирования в несколько раз, и, возможно, в будущем вы найдете работу в зарубежной компании. Совет 6. Запишитесь на курсы Для некоторых людей самостоятельное изучение программирование может даваться с трудом, ведь рядом нет никого, кто мог бы в любой момент ответить на их вопросы. Многим не понятно, с чего начинать обучение и как структурировать информацию.С наставником и одногруппниками вы будете продвигаться в обучении быстрее. Если вы хотите начать изучать программирование, вам будет интересно посмотреть записи вебинаров ITVDN из серии «С чего начать?», и «Как стать программистом?» . Ваши вопросы вы можете задать, обратившись в службу поддержки ITVDN. Консультанты нашего образовательного ресурса будут рады помочь вам.

Сейчас трудно представить себе любого девелопера без использования фреймворков. Здесь вы найдёте 5 лучших и наиболее признанных фреймворков для Python-разработчиков. Что такое framework? Говоря простым языком, фреймворк — набор инструментов для программиста. Фреймворк существенно упрощает разработку за счёт готовых решений и чётко выделенной структуры разработки приложений, сайтов. При использовании фреймворка вы значительно сэкономите себе время, ведь вам не придётся тратить его на решение рутинных задач программирования. Вместо этого вы сможете уделить внимание непосредственно разработке, сократив потраченное время с нескольких недель до пары дней. При использовании framework’a вы будете совершать меньше ошибок из-за невнимательности, и ваш синтаксис станет лучше. Кроме того, каждый framework оснащён собственной системой безопасности, которая защитит вас от случайной поломки программы. Большинство фреймворков являются бесплатными и имеют открытый код, хотя некоторые придётся покупать. Представляем вашему вниманию 5 лучших фреймворков для разработки на Python. Django «Классический» Python-framework, Django серьезно упрощает разработку за счёт большого количества доступных функций и паттернов. Имеет открытый код и предлагает большое количество возможных решений. Django относится к так называемым full-stack фреймворкам, которые универсальны и содержат все стандартные функции и шаблоны. К ним относится: аутентификация, маршрутизация, миграция баз данных, ORM и прочие. Django можно использовать для администрирования содержимого сайтов, аутентификации, RSS. Он отлично подойдёт для создания сайтов. Фреймворк работает с основными БД: MySQL, SQLite, PostgreSQ, Oracle. При необходимости можно установить специальные драйверы для подключения других баз данных. В целом этот фреймворк можно считать универсальным для Python-разработчиков. Он имеет большую базу шаблонов и на ура справляется со стандартными задачами, а также может помочь в решении нестандартных. Имеет полностью переведённую на русский язык техническую документацию. С хорошим переводом. Flask Платный мини-фреймворк, который предоставляет прочную основу для создания веб-приложений. Вмещается в один файл и легко устанавливается, пригодится в создании мелких и средних проектов, но не подойдёт для крупных из-за недостатка шаблонов и готовых решений. Предоставляет готовые шаблоны для маршрутизации, поддержку безопасных кукисов, WSGI 1.0. Имеет встроенный дебаггер и сервер для HTTP-разработки. Сервер поддерживает fapws3, GAEM, CherryPy, BJoem. Pyramid Бесплатный фреймворк типа «всё включено», разработан для приложений на основе Питона. Универсален и подойдёт как для создания небольших, так и больших проектов. Легок в установке, понятен, не тормозит. Имеет минималистичный дизайн. Имеет большое количество готовых шаблонов, в основном рассчитанных на разработчиков API. Умеет генерировать URL, помогает при аутентификации и авторизации пользователей, удобен для создания однофайловых приложений. Отлично подходит для тестирования и отладки. Twisted Создан для решения специальных задач сетевых разработчиков.  Быстр, бесплатен, сокращает время разработки сервисов в несколько раз. Создан на базе Deferred, которая упрощает обслуживание сетевых запросов и обработку ошибок.  Одно из главных оружий сетевого разработчика. Не подойдёт для разработки типичных веб-приложений из-за своих шаблонов и структуры. Twisted используется для разработки небольших асинхронных программ. Поддерживает большинство сетевых форматов: TCP, UDP, SSL/TLS, Domain sockets; умеет работать с сетевыми протоколами: HTTP, NNTP, XMPP, IMAP, IRC, FTP, SSH и прочими. Ещё больше модулей и форматов можно подключить с помощью драйверов. Имеет дополнительные структуры: Unit test (с поддержкой системы Deferred), Processor pools и т.д. Tornado Асинхронный фреймворк и одновременно сетевая библиотека по типу Twisted. Справляется с классической проблемой С10k (то есть может обрабатывать свыше 10 000 поступающих сетевых запросов). Представляет из себя солянку из Django, Flask и Twisted, но при этом быстрее их. Имеет встроенные шаблоны для аутентификации и авторизации, с поддержкой внедрения других шаблонов (например, Google), не блокирующийся HTTP-клиент.  Справляется с длинными запросами (long polling’ами), имеет поддержку web-сокетов. Используется разработчиками, которые создают масштабные сетевые приложения с большой нагрузкой и высокими требованиями к производительности. Каждый год количество новых фреймворков постоянно растёт, но некоторые из них уже несколько лет держатся на плаву, периодически изменяясь. Эти пять уже признаны чуть ли не классикой, и начать изучение мира фреймворков стоит именно с них. Потом вы сможете перейти на более специфические, предназначенные для решения определённых задач. Если вы изучаете программирование на Python и хотите освоить самые популярные фреймворки, смотрите видеоуроки ITVDN для Python-разработчиков, а также смотрите записи вебинаров на YouTube канале ITVDN.

Хотя внимание разработчиков приковано сейчас к таким глобальным вещам, как дефолтная реализация методов интерфейсов, мы хотим поговорить с вами о нюансах новой версии популярного языка программирования С#. Новые операторы присвоения: &&= и ||= Начиная с самой первой версии, C# поддерживал комбинирования операторов присвоения с другими операторами. Существует поддержка всех бинарных операторов (а именно - +, -, & и так далее), кроме булевских && и ||. Теперь комбинации типа &&= и ||= дополнят этот список. Дословно-интерполируемые строки Дословные строки начинаются на @”. Интерполируемые строки используют $”. Но что, если нам нужно создать дословно-интерполируемую строку? Что нам писать - @$” или  $@”? Сейчас первый вариант работает, но второй выдает ошибку уровня компиляции, что может вызывать некоторые неудобства у многих разработчиков, так как обычно такие нюансы часто забывают. Суть нововведения заключается в том, что в новой версии можно использовать как первый вариант конструкции, так и второй. Впрочем, некоторые все равно находят это изменение лишним, так как оно может привести к некоторой фривольности кода и проблемам с единым стилем. Выражение using структурно соответствует IDisposable У компилятора C# интересное отношение к интерфейсам. Довольно часто вам не нужно на самом деле реализовывать абстрактный интерфейс для определенных фичей языка. Все, что вам нужно, так это просто реализовать в классе определенный публичный API, что по своей структуре повторяет абстрактный интерфейс. Классическим примером этого является foreach и IEnumerable. Если класс обладает методом GetEnumerator, возвращающим значение свойства Current и методом MoveNext, тогда вы можете использовать foreach. Сами типы возвращаемых данных не имеют значения, что позволяет таким классам, как List<T>, реализовывать более быстрые перечисления. Этот подход достаточно часто называется структурным соответствием. В рамках новой версии языка using также будет поддерживать структурное соответствие. На первый взгляд, это нововведение кажется лишенным смысла, так как мы вряд ли ожидаем увидеть класс для использования с using без реализации интерфейса IDisposable. Впрочем, мы упускаем такое нововведение как ref struct. Реализация интерфейса в данном случае невозможна, поэтому здесь нам на помощь приходит структурное соответствие. Методы расширения с foreach и using Как дополнение к предыдущему посту, теперь мы можем добавить GetEnumerator и Dispose в качестве методов расширения для работы с foreach и using соответственно. Опять же, здесь мы говорим об особенности, которая станет полезной в частном случае. К примеру, вы хотите добавить Dispose-расширение в COM-объект сторонней библиотеки (к примеру, дабы вызвать Marshal.ReleaseComObject). Впрочем, информация об этом еще неполная и мы можем упустить некоторые случаи использования данной фичи. Using неявной области видимости На данный момент выражение using может быть использовано только в рамках явной области видимости (в скобках). Если данное нововведение будет принято на вооружение, теперь вы можете писать конструкции следующего вида: Каждая из этих переменных будет автоматически очищена в конце текущей области видимости в реверсивном порядке. Функционально написанное выше эквивалентно этому, но гораздо более элегантно: Подобное может быть полезно в тех случая, когда в одно и то же время создается множество dispose-объектов. Теперь вы можете создавать подобные объекты даже внутри выражений в полной уверенности в безопасности данного типа объявлений. Возможный минус данного нововведения в том, что оно не совместимо с оператором goto. Автор перевода: Евгений Лукашук Источник

Красивый код — не просто абстрактное понятие, а вполне реально существующая вещь в среде программистов. Научившись писать красивый код, вы значительно сэкономите своё (и чужое) время, а ваши программы станут работать быстрее и стабильнее. Как научиться писать красивый код и каким нюансам стоит уделить внимание — узнаете в этой статье. Почему так важно писать красивый код? Код — штука тонкая, в которой эстетика и полезность тесно связаны, как в архитектуре. Полезный, но не эстетично выглядящий код будет трудночитаемым и в результате менее эффективным, чем мог бы быть. Каким образом? Трудночитаемый код сложно корректировать и тестировать возможные решения, поэтому он отнимает больше времени на корректировку, чем обычный код. Чистый код создан для людей, поэтому другие программисты, которые будут читать его, будут вам очень благодарны за красивый код. Благодаря чистому коду поиски одного бага могут сократиться с нескольких часов до нескольких минут, а программа будет работать стабильнее и не выдавать сюрпризов. Однако овладеть мастерством написания чистого кода с наскока не получится — до момента написания первого элегантного кода, вызывающего восхищение коллег, вы напишите ещё десяток не самых красивых кодов, от которых будут плеваться. Впрочем, если вы немного измените мышление и овладеете несколькими навыками, то успехи у вас будут значительно лучше, и к написанию красивого кода вы придёте значительно быстрее. Для начала определимся, как вообще научиться писать красивый код, и какие знания нужны для этого, а затем — с навыками, которые необходимо будет развить. Как научиться писать чистый код?  Прежде чем приступить к написанию красивого кода, запомните два основных принципа, которые вытекают из прошлой части статьи: Красивый код должен быть легко читаемым и понятным для других программистов. Красивый код должен работать, а если он не работает — легко фикситься. Для того, чтобы соответствовал этим требованиям, он должен быть коротким, а функции — линейными. Таким образом, при написании чистого кода вы должны ориентироваться на эти принципы. И постоянно практиковаться: пишите код каждый день, и каждый раз пытайтесь написать наиболее лучший вариант. Со временем у вас начнёт получаться. Не забудьте почитать книгу Clean Code под авторством Роберта Мартина. Эта книга — настольная библия для программистов, которые стремятся к совершенному коду. На 900 страницах расписано всё, что следует знать программисту, который стремится к чистому коду. Во время чтения книги можете также зайти на Хабру или другие сайты с полезными для прогеров статьями. Так вы сможете узнать ещё больше о чистом коде и позже закрепить свои знания практикой. Также вы можете пройти обучение по видео курсам ITVDN. Авторы видео курсов – сертифицированные разработчики. Они помогут вам научиться писать хороший код. Нужно ли изучать алгоритмы и паттерны? Изучение алгоритмов — дело ваше, но запоминание паттернов является обязательным для программистов, как изучение таблицы умножения для детей. Без паттернов найти решение типичной проблемы будет трудно, поскольку не будет готового решения. Впрочем, это не значит, что вы всегда должны использовать паттерны в каждой непонятной ситуации, иногда они не смогут помочь и вам придётся продумывать самостоятельное нестандартное решение, или обращаться за помощью к старшим коллегам. Но само изучение паттернов существенно упростит вам жизнь. Для желающих начать изучение паттернов рекомендуем великолепный курс Александра Шевчука. Изучение алгоритмов — чуть более глубокая сторона программирования. Сам алгоритм — это записанные в определённой последовательности команды, которые должны решить стоящую перед ними задачу. Если вы решили взяться за их изучение, то вам нужно не только знать сами алгоритмы, но и уметь их выводить, иначе от знаний не будет толку. Если вы решили изучать алгоритмы, то рекомендуем обратиться к школьному курсу информатики и статьям для программистов, где подробно рассказывают об алгоритмах. Если в статье вы встретили упоминания как минимум трёх основных видов алгоритмов (линейный, разветвлённый и циклический) — то вы на верном пути. Хорошим вариантом для старта будет статья Ворожцова А. В. «Что такое алгоритм?», затем знания можно углубить изучив курс Алгоритмы и структуры данных. С общими требованиями к красивому коду и необходимыми знаниями определились, теперь перейдём к навыкам. Какие полезные привычки необходимо завести? Для написания чистого кода необходимо развить следующие навыки: 1) Уделять внимание форматированию кода и стараться делать его как можно более линейным. Это сделает код более понятным и элегантным. Не стоит гнаться только за производительностью, если не хотите получить знаменитый «индусский код»: 2) Короткие методы и функции. Чем короче — тем понятнее, чем понятнее — тем лучше. Слишком длинные функции запутают любого программиста и он потратит кучу времени, пытаясь разобраться в функциях. Запомните золотое правило: одна функция — одно действие. 3) Удобные названия для функций. Это кажется нелепым, но придумать действительно хорошее название для функции — та ещё задачка, по сложности сравнимая с придумыванием имени для вашего персонажа в MMORPG. Совет, который может помочь, — при наименовании классов используйте существительные, а для методов используйте глаголы. Это сильно упростит понимание кода. Для примера можете взглянуть на два кода ниже и сказать, какой из них выглядит более понятно: первый (до переделывания) или второй (после).   До После Как видно на примере, в первом варианте код не так плох, но из-за непонятных названий труден для понимания. Во втором варианте он разбит на более мелкие блоки, а правильно придуманные названия («sendTOmAILsERVER, Client, Message) помогают понять его с первого взгляда.   4) Грамотная обработка ошибок. Даже если вы по каким-либо причинам не можете написать короткие функции и красивый код, вы всё ещё можете исправить ошибки. Ни одна программа не застрахована от сбоев, поэтому создать идеально работающую прогу не получится. Однако вы можете воспользоваться методом try-catch-finally. Сущность этого метода заключается в эдакой «страховке» от ошибок. При использовании этого метода, вы должны будете создать 3 блока: try, catch и finally. Затем, при запуске команды, она будет выполняться в блоке Try. Если что-то пойдёт не так, то она попадёт в блок catch, где вы сможете поймать ошибку и исправить её. Если же ошибки не было, или вы её исправили, то команда продолжит выполнение в блоке Finally, где и будет завершена. Такой метод является универсальным для поиска и исправления ошибок и его может написать даже джун. Это, кстати, будет лучше и элегантнее, чем грузить код лишними функциями и превращать его в лапшу. Написание красивого кода — дело непростое и требующее практики, но освоив эту методику, вы станете ещё на один шаг ближе к совершенству и завоюете больше уважения от коллег, а также сможете считаться уже более опытным программистом. Если вы хотите овладеть искусством написания красивого кода, изучайте программирование на ITVDN. Опытные наставники разложат всё по полочкам и после окончания обучения вы научитесь писать красивый чистый код. При условии конечно, если будете прикладывать и свои усилия.

Мы уже знаем особенности работы с памятью и доступные структуры данных в .NET приложениях, в этом посте мы разберем упаковку и распаковку, а также рассмотрим, как эти две операции влияют на производительность приложения.   Что такое упаковка и распаковка? Зачем нам задумываться об упаковке и распаковке? Разве это не обязанность .NET-среды, которая следит за управлением данных и, соответственно, сама "выбирает" наиболее оптимальный способ их хранения? На самом деле - нет. Что очень важно знать и понимать -  так это механизм перемещения данных из области стека в кучу - и наоборот. Помните: Когда любой значимый тип присваивается к ссылочному типу данных, значение перемещается из области стека в кучу. Эта операция называется упаковкой. Когда любой ссылочный тип присваивается к значимому типу данных, значение перемещается из области кучи в стек. Это называется распаковкой. К примеру, здесь мы имеем следующий пример упаковки: А вот состояние памяти в момент произведения операции: Чтобы сохранить значение "123" в виде объекта, в куче создается "упаковка", куда впоследствии и перемещаются данные. Когда же производится распаковка: Вот что происходит с памятью: Значение "123" было изъято из упаковки и помещено назад в область стека. Заметьте, что когда тип данных i упаковывается внутри объекта o, в стеке хранится лишь ссылка, в то время как само значение хранится в куче. Как только производиться распаковка, данные в куче обязаны быть скопированы в стек (переменная j). В обоих случаях наша цель - это работать с тем самым значением (123). Как вы можете себе представить, сии операции могут быть достаточно ресурсоемкими.   Давайте рассмотрим IL Когда мы производим подобный анализ производительности, часто бывает полезно заглянуть непосредственно в Intermediate Language (IL). Мы еще не рассматривали эту концепцию, но, как вы наверняка знаете, когда мы производим компиляцию в DLL или EXE, выходной файл на самом деле содержит IL - промежуточный код, который в последствии исполняется JIT и впоследствии - виртуальной машиной. Среда выполнения .NET обязана как-то знать, нужно ли упаковывать или распаковывать определенные переменные. Поэтому для обозначения этих операций также требуются дополнительные затраты памяти. Давайте создадим несложное .NET консольное приложение: Теперь скомпилируем приложение и при помощи утилитки ILSpy посмотрим его код внутри EXE. Как только EXE-файл будет открыт в ILSpy, пронавигируемся к методу Main, выбрав "IL with C#". Заметьте, что операция box выполняется только после присвоение ссылочному типу значения значимого. И наоборот: unbox.any - только после попытки присвоить ссылочному типу данных значимой переменной. Это де-факто способ, которым операции упаковки и распаковки представлены в IL.   Когда стоит производить упаковку и распаковку? Код в примере выше скорее всего вам покажется наивным, и вы можете подумать: "Эй, что за вздор! Я никогда не буду такого делать". Что же, в большинстве случаев это действительно так. Но данные в нашем приложении часто упаковываются и распаковываются, когда мы об этом даже не догадываемся.   Гетерогенные коллекции К примеру, старая школа до сих пор может похвастаться ArrayList. Метод добавления элемента здесь, как можно отметить, принимает object-параметр. Таким образом, и здесь производится наша излюбленная упаковка. Впрочем, подобное кануло в лету с приходом обобщений и обобщенных коллекций.   Конкатенация строк Другой интересный пример в виде конкатенации строк. Эта операция требует наличия метода String.Concat, который принимает два object-параметра. Дабы избежать подобных ситуаций, нам достаточно просто немного изменить код, используя на переменной типа int метод ToString (и здесь стоит проигнорировать сообщение ReSharper о том, что операция бессмысленна:) ). И все! Никакой упаковки больше нет. Вообще, это далеко не единичные примеры для демонстрации. Но цель нашей статьи - донести четкое представление о том, что такое упаковка и распаковка и когда они применяются.   Производительность Как мы уже говорили, упаковка и распаковка требуют определенных затрат производительности. В случае с конкатенацией строк, выигрыш от применения ToString весьма незначителен. Именно потому, как я упомянул выше, даже ReSharper не советовал нам делать подобное: В этом случае гораздо лучше сохранить читабельность кода без ToString. Целесообразность оптимизации появляется, как правило, тогда, когда операции упаковки и распаковки предстоит производить в цикле сотни и тысячи раз. В этом случае время выполнения кода с упаковкой может составлять порядка 150 процентов от времени исполнения кода без нее (вы можете сами создать тестовое приложение и сравнить требуемый промежуток времени). Упакованные значения могут также требовать больше памяти, чем значения в стеке. Копирование значений в/из стека также требует своих затрат. Согласно MSDN, упаковка может занимать порядка 20 раз больше времени, нежели простое присвоение. В то время как распаковка примерно в 4 раза медленней простого присвоения.   Итак... зачем же тогда вообще нужно использовать упаковку и распаковку? Несмотря на все недостатки в плане падения производительности .NET -приложения, концепции упаковки и распаковки были внедрены в .NET не просто так. И вот причины: .NET-стандарт обладает общей системой типов, что позволяет представлять и ссылочные. и значимые типы схожим образом - и все это благодаря упаковке. Коллекции можно было использовать для хранения значимых типов до появления обобщений. Упрощения кода, вроде конкатенации строк и так далее. Упаковка и распаковка настолько распространены, что мы не может избежать их полностью. Мы должны знать принцип их работы, чтобы минимизировать их использование, но к этому нужно подходить разумно. Не тратьте свое время на постоянную оптимизацию кода, частую проверку через IL, чтобы убедиться, дабы ни одна лишняя операция упаковки не была использована. Помните, что чистота и простота чтения кода иногда значительно более важна, нежели незаметное, мельчайшее ускорение работы программы.   Подведем итоги В сегодняшнем уроке мы рассмотрели, что такое упаковка и распаковка, как она представлена в IL-коде, и какое влияние на производительность они имеют. Искренне надеюсь, моя статья сумела прояснить некоторые общие концепции, хотя бы чуть-чуть. :) В грядущих статьях мы рассмотрим механизм сборки мусора. Если у вас есть идеи или пожелания касательно материала новых статьей - милости просим в комментарии!   Автор перевода: Евгений Лукашук Источник

10 полезных фич в Angular, о которых вы могли не знать Angular - это объемный фреймворк, и наверняка большинство из нас использует лишь небольшую его часть. Но за этим мы можем упускать некоторые весьма полезные его возможности, которые сделали бы нашу жизнь значительно проще. В этой статье я собираюсь разобрать около 12 полезных фич в Angular, о которых вы могли и не слышать. Одна из вещей, о которой часто забывают, но которая таит в себе множество полезностей, является Pipe. Итак, давайте поговорим о них. KeyValuePipe Это одна из ключевых особенностей Angular 6.1. До этого все, что позволяла директива *ngFor, так это проитерировать массив или другую счисляемую конструкцию. Что же в случае со свойствами объектов или элементов Map - перебрать их было задачей отнюдь нетривиальной. Это как раз тот случай, когда может пригодиться директива KeyValuePipe! Мы просто ставим pipe по отношению к объекту, который желаем проитерировать, и все остальное за нас совершает ngFor. К примеру:   Slice Pipe Отображение списка предметов и манипуляция большим объемом DOM-элементов - задача достаточно затратная, потому порой могут возникать ситуации, когда мы захотим уменьшить количество отображаемых элементов. Выполнить это можно многими способами, но Angular обладает прекрасным SlicePipe, который позволяет нам выполнить все это всего лишь как часть нашего ngFor - выражения. К примеру, давайте представим, что мы хотим отобразить только первые 10 элементов массива:   Decimal Pipe Этот pipe предназначен для форматирования чисел. Он может быть весьма полезен, когда мы желаем ограничить число цифр, которые будут показаны после точки. Впрочем, он также может быть использован, когда мы просто желаем представить определенное число в более "презентабельном" виде, с запятыми после каждой тысячи. Так, 1000 у нас станет 1,000. Кроме того, стоит также упомянуть еще об одной полезной фиче здесь. А именно, функции formatNumber, которая является частью @angular/common, что позволяет применять то же самое форматирование на программном уровне.   JSON Pipe Крайне полезный инструмент, особенно при отладке. Позволяет вам отобразить объект в виде строки в представлении. Подобный подход может стать неплохой альтернативой точкам остановки и командам отладчика в некоторых случаях. Просто добавьте JSON pipe объекту, который вы желаете отобразить:   Заголовок и мета-сервисы Становятся особенно полезными, когда мы работаем с поисковиками или соц. сетями (по типу Google, Twitter, Facebook и т.д.). Эти платформы для формирования контента, названия, его описания используют теги <meta>. К примеру, в нашем блоге для каждой статьи существуют свои заголовки, описания, картинки и так далее. Дабы убедиться в достоверности предоставляемой информации, мы можем поместить все необходимое в специальные мета-теги, как показано на примере ниже: Плюс у нас есть сервис Title, который, как вы понимаете, обновляет заголовок, отображаемый в окне браузера. Достичь этого можно просто и незамысловато: просто добавить значение тегу <title> в заголовке документа. Впрочем, здесь, увы, мы не сможем использовать стандартную Angular-привязку: <title>{{ myTitle }}</title>, так как <head> не находится внутри Angular-компонента. Поэтому здесь мы должны использовать сервис Title. Использовать его очень просто: Дабы позволить социальным сетям обнаружить эти мета-теги, они должны быть представлены на странице в момент ее загрузки (без использования JavaScript).   ng-container Пытались ли вы когда-либо поместить две структурные команды на один и тот же элемент, впоследствии обнаружив, что вы не можете это сделать? Или, возможно, вы применяете при этом ngTemplateOutlet, отмечая, что сие не позволяет в качестве дочернего, а лишь как родственный? Согласны, это может быть весьма утомительно, особенно если единственный способ решить сей ребус - добавить обертку в виде <div>, что, безусловно, может "замусорить" существующую DOM-структуру. К счастью, существует ng-container, что позволит вам избежать подобных проблем. Этот элемент, доступный при разработке, на самом деле не создает никаких новых элементов в структуре DOM-дерева и может быть прекрасным решением для обеих вышеназванных ошибок и даже более! К примеру, дабы использовать несколько структурных деректив, мы может просто сделать следующее: После чего просто применить существующий темплейт в качестве дочернего: Это лишь малая часть возможных применений сего инструмента, уверяю вас, при желании ng-container можно использовать и для более широкого круга задач. Декоратор атрибутов Все мы знаем, что свойства-декораторы @Input и @Output используются для привязки и порождения событий. Впрочем, существует другой, менее известный декоратор, @Attribute. Этот декоратор чем-то похож на @Input-декоратор, так как он может быть использован для передачи значения компоненту. Привязка атрибута чем-то похожа на scope-привязку AngularJS: Для начала, давайте изучим ограничения декоратора!             - Любые значения должны быть представлены строковым типом данных             - Значения статические и не изменяются, в отличие от привязок             - Мы не можем использовать синтаксис привязки [attribute] В то время, как существуют определенные незначительные ограничения, выигрыш от повышенной производительности будет более значимым. Они могут быть использованы точно так же, как и @Input-декоратор:   Мониторинг изменений профиля Я уверен, все мы знаем о функции enableProdMode, что будет вызвана в main.ts-файле любого проекта Angular CLI. Впрочем, здесь также существует функция enableDebugMode. Конечно, мы можем думать, что, мол, если я не работаю в прод-режиме, значит, я работаю в режиме отладки, но, кхм, все не совсем так. Вызывая эту функцию, мы получаем дополнительный инструмент - window.ng объект, что называют профилировщиком. Профилировщик имеет в своем арсенале функцию timeChangeDetection, при вызове которой выводится консольная информация о том, сколько произошло change-detection - циклов (а также о том, сколько времени они заняли). Может быть очень полезно при профилировании приложений с низкой производительностью. Для вызова функции добавьте следующее в коде bootstrap: Для запуска профилирования, введите в DevConsole следующее:   NgPlural Во многих приложениях бывают случаи, когда необходимо описать определенное число элементов, и в рамках нашего приложения нам нужно предусматривать различные ситуации. К примеру, рассмотрим следующие варианты:             - Предметов нет вообще             - Есть только один предмет             - Есть только два предмета Директива же ngPlural очень проста в использовании, и предназначена она для обработки подобных случаев:   ngPreserverWhitespaces & NgNonBindable Я решил сгруппировать две эти директивы, так как используются они в принципе в схожих условиях. В Angular 5 существовала опция preserveWhitespaces, добавленная в angularCompilerOptions. Если бы ее значение было равно false, оно бы позволило компилятору избавиться от пробелов, которые не считались существенными. Конечно, читабельность могла бы пострадать, но, с другой стороны, это позволило бы уменьшить размер пакета. Впрочем, бывают случаи, когда мы желаем сохранить пробелы. Если мы хотим оставить целый компонент нетронутым, нам необходимо просто использовать опцию в декораторе компонента: Впрочем, мы также можем желать оставить нетронутым пробел в определенном DOM-элементе. В таком случае мы можем использовать директиву ngPreserveWhitespaces. Также мы можем использовать {{ }} в нашем документе, впрочем, в любом случае Angular сочтет это за использование интерполяции и попытается оценить, что находится внутри ее. В таком случае нам придется кстати ngNonBindable.   Ну, вот и все! Здесь были описаны 10 вещей, которые вы могли не знать об Angular. Надеюсь, вы найдете их полезными! Автор перевода: Евгений Лукашук Источник

Дмитрий Охрименко – один из создателей ITVDN, автор видео курсов, консультант по построению распределенных и веб-ориентированных приложений, сертифицированный специалист Microsoft (MCTS, MCPD, MCT). Более 10 лет Дмитрий проводит корпоративные тренинги для IT специалистов в таких компаниях как 3Shape, GlobaLogic, Ciklum, Terrasoft, Simcorp и других. Мы попросили Дмитрия ответить на ряд вопросов, связанных с обучением IT специалистов и о том, в какой мере ITVDN может помочь в решении этих задач.   Как HR-специалисту узнать, какие новые технологии нужно изучить разработчику? Для этого есть много инструментов, которыми можно воспользоваться для определения действительно важных для разработчика тем. Так как бизнес должен зарабатывать деньги, то неправильно будет идти только на поводу у разработчика. Если говорить о мотивации, то все люди любят платить деньги за то, что приносит пользу, либо за то, что приносит удовольствие. Если брать разработчиков, то пользу им приносит все то, что может помочь в решении их повседневных задач. Если компания, например, разрабатывает какие-то веб-приложения, то, возможно, стоит обратить внимание на изучение их популярных библиотек, которые используются в проектах, на изучение разработки BackEnd-части. Это то, что можно отнести к пользе, которую получит разработчик. Если говорить об удовольствии, то все разработчики любят говорить, что они знают все самые последние технологии, что они имели опыт с последними версиями: C#, JavaScript, C++ и т.д.  Поэтому мотивация может заключаться в том, чтобы проводить обучение, может, не совсем полезное для проекта, но зато - это новые технологии, и разработчик будет чувствовать себя частью передовых технологий. Также необходимо проводить обучение для поднятия общего уровня знаний специалистов в проекте. По сути, как узнать, что нужно разработчикам? Лучше всего на этот вопрос ответит не сам разработчик, а тимлид или человек, который занимается организацией всей команды. Потому что четко понятно, что у этих ребят не хватает опыта работы с таким-то языком, инструментом и необходимо подтянуть именно эти навыки. Можно сделать, например, общий опросник для всех разработчиков и узнать, что они хотят. Как показывает практика, это обычно разбросанные требования: хочу учить С#, хотя человек пишет на Java, или хочу учить Python, хотя в проекте он не будет вообще использоваться. Для того, чтобы обучение мотивировало разработчиков и было полезно для самой компании, то HR-специалисту нужно собрать информацию не только от конкретных разработчиков, а еще и уточнить, что действительно необходимо для реализации тех задач, которые стоят перед командой в целом. Чтобы команда смогла поставить действительно качественный продукт.   Как происходит процесс построения корпоративного тренинга? Чаще всего компания понимает, что ей не хватает каких-то знаний в определенных направлениях. По своему опыту, если возникает какая-то задача у HR-специалиста или у тимлида, что команду нужно подтянуть по знаниям, например, по JavaScript, то мы просто приезжаем от Учебного центра CyberBionic Systematics и предоставляем перечень тех курсов и материалов, которые уже существуют. Если компании необходимо подготовить, допустим, Frontend-разработчиков, то мы приезжаем с теми наработками, которые уже есть. Также предварительно готовим конкретное предложение, если от компании уже поступили рекомендации, что, например, нужно сделать больший акцент на объектно-ориентированное программирование, на библиотеку, на определенные инструменты. То есть, мы подготавливаем предложение таким образом, чтобы высветлить те проблемы, которые возникают перед разработчиками и дополнительно добавляем какие-то материалы, которые могут поспособствовать дальнейшему росту специалистов. Мы проводим встречу с компетентными лицами. Собираемся с тимлидерами, с senior-разработчиками, они высказывают свои пожелания, они корректируют эту программу, и мы берем время на доработку дополнительных материалов. У нас очень много опыта по работе с киевскими компаниями. Очень часто компания Terrasoft заказывала именно абсолютно новую, индивидуальную программу. Они смотрели на то, что у нас есть, но вносили корректировки, которые требовали разработки 30-40 часов, под свои проекты. Чтобы обучение было действительно качественным и эффективным, чтобы компания получила из этого выгоду, специалистам компании необходимо озвучить, какие проблемы есть и в каком направлении нужно учить команду. В большинстве случаев тимлид и senior-разработчик понимают, что у его 10-ти мидлов, джуниоров и других специалистов не хватает опыта в определенных заданиях. Обычно это знания выборочные и их нужно подтянуть, или их просто нет, тогда нужно донести до слушателей. Наша задача понять, чего не хватает для того, чтобы специалисты были действительно продуктивными, и их работа была результативная. Для этого нужно подготовить программу, которая принесет пользу компании и специалисты будут удовлетворены. Мы расскажем им, что нужно знать и как нужно работать. Задачи компании будут решатся, а рабочих проблем должно стать меньше после того, как тренинг успешно закончится.   Какие формы обучения наиболее подходят для IT-специалиста? Чтобы обучение было максимально эффективным, я думаю, его необходимо комбинировать. Использовать обучение вместе с тренером, когда он будет своим примером мотивировать разработчика, заставлять что-то новое учить и двигаться дальше. Также комбинировать обучение необходимо с добавлением онлайн-составляющих, дополнительной литературы. Если брать корпоративное обучение, то максимально эффективное будет очное и онлайн, когда приезжает тренер или обучает через скайп и подобные ресурсы. Непосредственно взаимодействуют все группы слушателей и дополнительно к этому добавляется обучение в видеоформате. Для большинства проектов не всегда есть возможность оторвать людей от производственного процесса, есть определенные часы, в которые тренеру можно пообщаться с коллективом, рассказать теоретическую часть, но не всегда у разработчиков есть возможность полностью переключиться на подобного рода обучение. Обучения, когда в течение 5 дней в неделю по 5 часов учат определенную технологию, я считаю не очень эффективным, потому что информации очень много, не хватает времени, чтобы её освоить и закрепить. Я считаю, что обучение должно быть постоянным, интенсивным, но при этом в меру, чтобы была возможность переварить саму информацию. Чтобы был максимальный эффект, необходимо комбинировать очное и онлайн-обучение, когда тренер рассказывает материал и добавлять видеоформат обучения. Конечно, в идеале было бы перевести все на видеоформат и сделать так, чтобы слушатели только смотрели видеоматериалы, но у многих часто возникают вопросы. Если брать, например, проект ITVDN, то корпоративное обучение подразумевает еще и консультации, то есть команда может взять себе набор видеоуроков. Создатели и авторы курсов ITVDN хорошо понимают, что именно и в какой последовательности учить и какой эффект будет максимально достигнут. Мы можем составить индивидуальную программу, сделать временные метки и консультировать команду уже по ходу обучения, чтобы они смотрели все в видеоформате и не отрывались от рабочего процесса, при этом мы будем проверять результаты тестирования и отвечать на возникшие вопросы в ходе обучения. Мы открыты для диалога с компаниями, которые хотят мотивировать своих разработчиков и организовывать для них обучение. Наша команда готова разрабатывать индивидуальные программы, создавать индивидуальный график и подход к каждой компании в отдельности. У каждой компании свои собственные бизнес-процессы, своя корпоративная культура и всех под одну гребенку поставить не выйдет, поэтому мы готовы свои процессы подстроить под график конкретной организации.   Как ты посоветуешь "расшаривать" знания, делиться опытом внутри команды? Я считаю, что лучшего всего организовывать мастер-классы, когда сама команда для себя что-то полезное рассказывает. В команде всегда есть разработчики, у которых больше опыта. Неплохо было бы организовать день мастер-классов, составить график, где каждый разработчик должен выступить в течение 10-20-ти минут, рассказать о чем-то новом, показать технологию, сделать минимальную презентацию и просто поделиться знаниями, которые он получил на последнем проекте или вычитал, например, в статье. Польза в этом всем в том, что все понимают, над чем они работают, с какими сталкиваются задачами и технологиями, поэтому такие мастер-классы могут быть максимально эффективными для команды. Если компания пишет, например, используя Angular, то все мастер-классы нужно заточить под Angular и культивировать освоение тех частей этой библиотеки, которые необходимы для работы в проекте. Тимлидер может составить список докладов, и каждый сможет их проводить, будет общая копилка тех тем, по которым разработчик может провести мастер-класс и сделать расписание – это будет наиболее эффективный способ поделиться знаниями в команде. Также как способ - экстремальное программирование, вместе работать с одной задачей. Кто-то один знает процесс и диктует, а второй набирает код. Экстремальное программирование никто не отменял, но не в каждом проекте оно может примениться, чтобы более опытный специалист смог передать свои знания.

Вопросы, которые беспокоят каждого начинающего разработчика – смогу ли я найти работу после того, как пройду обучение? Какую специальность лучше выбрать, чтобы наверняка быть нужным? Есть, много субъективных факторов, которые влияют на возможность получить ту работу, о которой вы мечтаете. Это настойчивость, готовность рискнуть, черты характера, навыки представления себя потенциальному работодателю, умение правильно выбрать компанию и вакансию, соответствующие вашему уровню, умение проходить собеседование. При равных знаниях в программировании шансы кандидатов не равны. Однако, есть и объективные факторы, которые вы можете  (и должны!) учитывать. Один из них – конкуренция среди программистов, желающих занять определенную вакансию в IT компании. Самый простой способ взвесить свои шансы – посмотреть на количество вакансий, опубликованных в течение месяца и количество откликов на эти вакансии. Такая информация всегда в свободном доступе на сайте  сообщества программистов Украины DOU.UA.   Мы сделали небольшую выборку по десяти специальностям. Это информация за май 2018 года. Информация, представленная в этой таблице, говорит о том, сколько специалистов откликнулись на вакансии и какие специальности в нынешние время самые популярные. Из таблицы явно видно, что у начинающего C#/.NET разработчика шансы получить работу намного выше, чем у Java или FrontEnd разработчика. Смотрите, думайте. Желаем Вам стать профессионалом и работать в компании Вашей мечты! С более подробной информацией Вы можете ознакомиться на сайте DOU.UA.

Об авторе Юрий Думов работает архитектором программного обеспечения в SAP, имеет более 10 лет опыта в разработке веб и мобильных приложений. Прежде всего, давайте введем некоторые сокращения. Internationalization - достаточно длинное слово, поэтому предлагаю его заменить в нашем контексте на “intl”. Интернационализация в общем плане может быть разделена на следующие подпункты: Определение пользовательской локали Перевод UI-элементов, заголовков, подсказок и прочего Поддержка местных специфических сервисов, таких как даты, валюты и числа На заметку: в этой статье я заострю ваше внимание лишь на front-end части. Мы разработаем несложное универсальное React-приложение с полной поддержкой интернационализации. Для начала предлагаю воспользоваться моим репозиторием. Здесь у нас есть веб-сервер Express для серверного рендеринга, вебпак для построения клиентского JS, Babel для конвертации современного JavaScript в ES5. Также мы будем использовать npm-run, nodemon для запуска веб-сервера под средой разработчика и webpak-dev-server для ассетов. Нашей точкой входа в серверное приложение будет служить server.js. Здесь мы загружаем Babel и babel-polyfill для создания прочего серверного кода в современном стандарте JavaScript. В качестве бизнес-логики сервера мы используем src/server.jsx. Тут мы устанавливаем Express-сервер для прослушки порта 3001. Для рендеринга мы используем очень простой компонент components/App.jsx, который также является частью точки входа в универсальное приложение. Точкой входа в клиентский JS нам служит src/client.jsx. Тут мы фиксируем корневой компонент - component/App.jsx - для placeholder'а react-view в HTML-разметке, предоставляемой Express-сервером. Таким образом, сейчас мы склонируем репозиторий, запустим npm-install и выполним nodemon и webpack-dev-server одновременно в двух консолях. В первой консоли: И во второй: Наш веб-сервер должен быть доступен по localhost:3001. Откройте предпочитаемый вами браузер и убедитесь в этом сами! Итак, мы готовы начать. Определение пользовательской локали Существует два возможных решения этого вопроса. По какой-то причине большинство популярных веб-сайтов, включая Skype и NBA, используют гео-IP для определения местоположения пользователя, таким образом определяя его родной язык. Подобный подход не только является дорогим в плане реализации, но и еще не совсем точным. Сейчас очень много людей путешествует, по этой причине местоположение пользователя не является надежным ориентиром при выборе подходящего языка приложения. Вместо этого мы предпочтем второй способ решить данную проблему при помощи обработки на стороне сервера заголовка Accept-Language. Этот заголовок отправляется любым более-менее современным браузером.   -Language Этот заголовок предоставляет информацию о возможных вариантах языка, принятого в качестве ответа. Каждый язык обладает своим «приоритетом», показывая, как часто пользователь может его использовать. По умолчанию уровень «приоритетности» равен 1. К примеру, «Accept-Language: da, en-gb;q=0.8, en;q=0.7» означает «я предпочитаю датский, но могу также принять британский или другие виды английского».   (Также стоит упомянуть, что сей подход так же несовершенен. К примеру, пользователь может посетить ваш веб-сайт из интернет-кафе или публичного ПК. Лучше всего разработать виджет, при помощи которого пользователь на интуитивном уровне сможет поменять язык сайта.)   Реализация определения локали пользователя Вот пример кода веб-сервера Node.js. Мы используем пакет accept-language, что извлекает локали из http-заголовков и находит наиболее предпочтительные, исходя из поддерживаемых вашим веб-сайтом. Если таковые не были найдены, тогда сайт будет использовать свою дефолтную локаль.   Приступим к установке пакетов: После чего в src/server.jsx у нас будет следующее: Здесь мы импортируем accept-language и устанавливаем поддержку английских и русских локалей. Также мы реализовываем функцию detectLocale, что извлекает значение локали из куки. Если ни одна не была обнаружена, начинается обработка Accept-Language. Наконец, мы выбираем дефолтную локаль. После обработки запроса мы добавим заголовок Set-Cookie для обнаруженной локали в ответ. Это значение будет использовано для всех последующих запросов.   Перевод UI-элементов, заголовков, подсказок и прочего Здесь я собираюсь использовать React Intl-пакет. Это наиболее популярная и, так сказать, проверенная боем реализация интернационализации для React-приложений. Впрочем все библиотеки так или иначе строятся по одному принципу: они обеспечивают нас компонентами высшего порядка, что внедряют уже готовые функции интернационализации для обработки сообщений, дат, номеров, валют посредством специальных фич React.   Во-первых, мы должны установить провайдер интернационализации. Для этого мы немного изменим src/server.jsx и src/client.jsx. src/server.jsx:          здесь src/client.jsx: Так, теперь IntlProvider-дочерний компонент получит доступ к функциям интернационализации. Давайте добавим переведенный текст в наше приложение и клавишу для изменения локали. У нас есть два способа, как это можно сделать: через FormattedMessage или через formatMessage – функцию. Разница в том, что компонент будет обернут в span-тэг, что хорошо для текстовых данных, но не хорошо для значений HTML-атрибутов, таких как alt и title. Давайте опробуем и их!   Вот src/components/App.jsx: Отметьте, что атрибут id должен быть всегда уникальным для всего приложения в целом, так что было бы не лишним установить для себя некоторые правила именования сообщений. Я предпочитаю следовать формату «имяКомпонента.некийУникальныйИдентификатор». В качестве некой дефолтной локали будет использовано сообщение defaultMessage. Атрибут description предоставит некую информацию для переводчика.   Перезапустите nodemon и обновите страницу в браузере. Вы должны увидеть «Hello World». Но если вы открываете статью при помощи инструментов разработчика, вы увидите, что текст теперь внутри тэга span. В этом случае это не ошибка, но иногда мы предпочитаем просто получить текст, без никаких дополнительных тэгов. Для этого нам нужен прямой доступ к объекту интернационализации React Intl.   Давайте вернемся назад к src/components/App.jsx: Нам нужно написать гораздо больше кода, чем раньше. Во-первых, мы используем injectIntl, который «упаковывает» наш компонент приложения и внедряет intl-объект. Чтобы получить переведенное сообщение, нам нужно вызвать formatMessage и передать в качестве параметра message. Этот message должен иметь свой уникальный идентификатор и атрибуты defineMesasges из React Intl.   Лучшее, что есть в React Intl, так это его экосистема. Давайте добавим babel-plugin-react-intl к нашему приложению и построим словарь трансляции. Мы передадим этот словарь переводчикам, которым не нужно никаких задатков программирования для выполнения своей работы. .babelrc: Перезапустите nodemon, и вы увидите, что папка build/messages была успешно создана в корневой директории проекта, вместе с некоторыми другими папками и файлами внутри. Теперь нам необходимо собрать эти файлы в один JSON. Для этого вы можете использовать мой скрипт. Сохраните его как scripts/translate.js.   Теперь нам нужно добавить новый скрипт в package.json: Что же, попробуем! В конце вы должны увидеть файл en.json в build/lang. И все работает! Теперь пришло время для кое-чего поинтересней. На стороне сервера мы можем загрузить все переводы в память и, соответственно, выдавать их в зависимости от характера запроса. Однако на клиентской стороне этот подход неприемлем. Потому вместо этого мы будем один раз принимать json-файл со всеми переводами, а клиент автоматически определит, какой из текстов ему нужен.   Скопируем результирующий файл в public/assets. На заметку: если вы пользуетесь Windows, симлинки для вас недоступны. Таким образом, вам нужно будет вручную копировать команды каждый раз, как только вы будете перестраивать ваши переводы. public/assets/ru.json применим следующее: Теперь нам нужно повязать серверный и клиентский коды. Для сервера наш src/server.jsx должен выглядеть так: Здесь мы делаем следующее: Кэшируем сообщения и специфичный для данной локали JS для валют, DateTime, Number во время запуска приложения. Расширяем метод renderHTML так, что мы можем вставить специфичный для данной локали JS прямо в разметку. Предоставляем переведенные сообщения IntlProvider (все те сообщения теперь доступны в качестве дочерних компонентов). Что же касается стороны сервера, во-первых, нам нужно установить библиотеку для выполнения AJAX-запросов. Я предпочитаю использовать изоморфное обновление, так как, скорее всего, нам предстоит запрашивать данные из сторонних API, и изоморфное обновление очень хорошо с этим справляется. Вот src/client.jsx: Также мы должны затронуть src/server.jsx, чтобы Express предоставлял json с переводом на сторону клиента. Заметьте, что на продакшине вы, скорее всего, будете использовать что-то вроде nginx. После инициализации JavaScript, client.jsx возьмет локаль из куки и запросит JSON с переводом. Во всем остальном наше приложение будет работать, как и раньше. Пришло время проверить, как все будет работать в браузере. Откройте вкладку «Network» в панели разработчика и удостоверьтесь, что JSON с переводом был успешно получен нашим клиентом. Подведя итог, давайте добавим небольшой виджет для изменения локали в src/components/LocaleButton.jsx: И так же в src/components/App.jsx: Заметьте, как только пользователь меняет свою локаль, мы перезагружаем страницу, чтобы убедиться, что новый JSON-файл с переводом был успешно извлечен. Теперь же время протестировать! Окей, мы изучили, как определять локаль пользователя и как отображать переведенные сообщения. Перед тем, как двигаться в направлении заключительной части, давайте обсудим пару также немаловажных нюансов. Плюрализация и шаблоны В английском большинство слов могут принимать одну или две возможные формы: «одно яблоко», «много яблок». В других языках все намного сложнее. К примеру, русский имеет 4 различные формы. Надеемся, React сумеет справиться и с этим. Он также поддерживает шаблоны, так что вы можете предоставить переменные, которые могут быть подставлены в шаблон во время рендеринга. Вот как это работает. В src/components/App.jsx у нас есть: Тут мы определяем шаблон с переменной count. Мы напечатаем или «одно яблоко», если значение переменной равно 1, 21 и так далее, или «два яблока» в противном случае. Нам нужно передать все переменные в formatMessage. Давайте перестроим наш файл переводов и добавим русский перевод для теста. Вот наш public/assets/ru.json файл: Теперь все случаи предусмотрены! Поддержка местных специфических сервисов, таких как даты, валюты и числа Ваша информация будет представляться по-разному в зависимости от локали. К примеру, русская локаль нам покажет $500.00 и 12/10/2016.   Intl предоставляет React-компоненты для такого типа данных, которые автоматически обновляются каждые 10 секунд, если вы за это время не перезаписывали значения. это в src/components/App.jsx: Обновите браузер и проверьте страницу. Вам необходимо будет подождать 10 секунд, чтобы увидеть, как обновится FormattedRelative.   Круто, не правда ли? Что же, теперь мы можем столкнуться еще с одной проблемой – универсального рендеринга.   В среднем между формированием разметки и инициализацией JS проходит порядка 2-х секунд. Это значит, что все DateTime`сы, сгенерированные на странице, могут иметь разные значения на стороне клиента и сервера. Что, как следствие, разрушает универсальный рендеринг.   Вот src/server.jsx: вот src/client.jsx: Перезапустите nodemon и проблема почти исчезнет! Она может, правда, остаться в случае, если вы используете Date.now() вместо показаний, записанных в базе. Чтобы сделать пример более «жизненным», заменим в app.jsx Date.now() на последний таймштамп, что-то вроде 1480187019228.   (Впрочем, вы можете столкнутся с другой проблемой – когда сервер не в состоянии отрендерить DateTime в нормальном формате. Это потому, что 4 версия Node.js по умолчанию не поддерживала Intl.) Звучит слишком хорошо, чтобы быть правдой, не так ли? Мы как истинные фронт-енд разработчики всегда были на стороже того, что касается браузеров и платформ. React Intl использует нативный браузерный API для обработки форматов DateTime и Number. И, несмотря на тот факт, что подобная функциональность была представлена в 2012 году, до сих пор есть современные браузеры, которые ее все еще не поддерживают. Даже Safari поддерживает ее только частично. Вот таблица с детальной информацией: ​ Это значит, что если вы желаете покрыть большинство браузеров, которые не поддерживают Intl API на нативном уровне, polyfill для вас просто незаменим. Хвала Всевышнему, существует Intl.js. С одной стороны, кажется, вот оно – идеальное решение, но, как показывает мой опыт, всегда существуют свои недостатки. Во-первых, вам нужно добавить Js-bundle, что несколько ресурсоемко. Также для уменьшения размера вам нужно будет передавать ваш Intl.Js только для браузеров, у которых нет своей нативной поддержки. Конечно, все эти техники уже давным-давно известны, и существует великое множество статей, посвященных им. Но все равно, Intl.js – не абсолютное решение, так как все же представления DateTime и Number на стороне сервера и на стороне клиента могут несколько отличаться, что, разумеется, влечет за собой ошибки при серверном рендеринге.   Наконец, я пришел к своему собственному решению, которое хоть и имеет свои недостатки, но мои запросы в большинстве случаев оно устраивает. Я реализовал очень поверхностный polyfill, что имеет лишь небольшую часть из требуемой функциональности. В то время, как в большинстве случаев подобное решение непригодное, оно лишь добавляет лишние 2 КБ к размеру JS-файла, так что даже нет необходимости реализовывать динамическую загрузку кода для устаревших браузеров, что значительно упрощает решение в целом.   И в заключение Возможно, сейчас вас не покидает чувство, как будто здесь написано слишком сложное решение. Также, возможно, сейчас вы подумываете о том, чтобы реализовать все самим. Я бы не советовал этого делать. В конце концов, вы все равно придете к выводам, представленным в данной статье. Или, что хуже, зайдете в тупик одного решения и не сможете увидеть остальные. Вы можете подумать, что можно легко решить проблему с Intl API, используя вместо него Moment.js (я специально не рассматривал другие библиотеки, так как они либо неподдерживаемые, либо неиспользуемые). К счастью, я уже опробовал это, так что я могу сохранить вам много времени. Moment.js монолитен и очень тяжел, так что если для кого-то он и подойдет, то остальная масса пользователей будет неудовлетворенной результатом. Разработка собственного polyfill не звучит интригующе, так как вам наверняка придется выделить определенное время для борьбы с возникающими при этом багами. Подведя итог, могу лишь сказать, что не существует идеального решения касательно проблемы на данный момент: просто выберите то, что вам подойдет лучше всего.   Надеюсь, эта статья дала вам все, что нужно знать для создания интернационализируемого React front-end приложения. Теперь вы выучили, как определять локаль пользователя, сохранять ее в куки, писать виджет для изменения локали и многое другое! Также вы ознакомились с некоторыми возможными проблема и ловушками, в которые вы можете попасть в процессе написания приложения.   Удачи в разработке! Автор перевода: Евгений Лукашук Источник

Об авторе Сара Дрезнер - заслуженный спикер и senior разработчик в Microsoft, автор статьей о трюках и хитростях CSS. Нельзя просто так упустить все интриги, возросшие вокруг существующий JavaScript - фреймворков, но также не стоит забывать, что они явно не являются универсальными и каждый тип проекта требует что-то "свое". Возможно, вы не захотите устанавливать большое количество различных дополнений, чтобы просто реализовать небольшую абстракцию. Возможно, адаптация проекта под новые системы сборки, различные методы деплоя будет означать большое количество времени и усилий, которые вы будете не в состоянии включить в прайс клиенту. Возможно, вы не хотите писать в HTML JavaScript. Список может расти до бесконечности. Что многие люди могут не знать, так это то, что вы можете легко внедрить Vue.js в ваш проект точно так же, как вы внедряете jQuery. Не нужно ничего перестраивать. Vue достаточно гибкий - в том плане, что вы можете его использовать прямо в HTML. Итак, представим, что ваш код имеет следующий вид: Вы можете в буквальном смысле изменить скрипт-тег и продолжить использовать HTML & JS точно так же, как вы использовали его до этого. Вам не нужно ничего переписывать. Вам не нужно интегрировать веб-паки. И вам определенно не нужно устанавливать никаких криповых чудовищ. Вы можете заменить тэги и оставить разметку "как есть". Что радует, так это несказанная простота, гибкость и адаптируемость Vue.js, что вы можете увидеть на протяжении чтения данной статьи. Что же касательно размера, тут нас тоже ждет приятная особенность: всего лишь 86 КБ для версии 2.5.3 и 87 для более новой версии 3.2.1. Давайте рассмотрим некоторые наиболее распространенные примеры использования нового фреймворка и убедимся в его неоспоримых преимуществах. Перехват пользовательского ввода Наиболее распространенным примером использования JavaScript  является отлавливание введенной пользователем в веб-формы информации. В нашем примере для упрощения мы не будем рассматривать комплексные формы, но для понимания этого будет целиком достаточно. Чтобы отловить информацию, вводимую пользователем, мы можем сделать следующее: See the Pen 1 by Jeka Muzyka (@jeka-muzyka) on CodePen. See the Pen 2 by Jeka Muzyka (@jeka-muzyka) on CodePen. Я использую этот пример, потому что он наглядно демонстрирует некоторые сильные стороны Vue.js. Он реализует особенности react, что делает его очень чуствительным в плане изменений. Демонстрацию вы можете увидеть, когда попытаетесь ввести что-то. Как можно заметить, вся информация обновляется практически мгновенно. Вы также можете заметить это и в версии с JQuery - контролируя элементы DOM-дерева и работая с событиями, вызываемыми при изменении содержания его элементов. В версии Vue.js мы сохраняем состояние элемента. Если более детально, то мы привязываем к нашему конечному скрипту DOM-элемент напрямую. Особенность в том, что даже в случае изменения структуры DOM-дерева и HTML в целом, конкретный DOM-элемент будет надежно привязан к нашему Vue.js - событию. Де-факто, на вводе мы используем атрибут v-model, тем самым обозначая хранение информации этого поля в JavaScript. Однако это далеко не единственный способ хранения состояния. Потому двигаемся дальше. Хранение введенных данных в рамках индивидуального события Особенность работы Vue.js заключается в том, что нам не нужно думать об особенностях реализации конкретного DOM-события. По сути, мы уже знаем, что мы желаем "перехватить". Мы просто указываем событию, на который из элементов срабатывать. Тогда как с использованием JQuery мы жестко привязываемся к структуре DOM и прочим DOM-событиям. Увидеть разницу мы сможем в следующем примере: See the Pen new by Jeka Muzyka (@jeka-muzyka) on CodePen. See the Pen 4 by Jeka Muzyka (@jeka-muzyka) on CodePen. В этой версии JQuery был упрощен, так как нам не нужно было отлавливать события при каждом нажатии клавиши, но в то же время все остальные условия соблюдены. Наш код в jQuery также будет подобен этому: "Отловите элемент, просмотрите, что он делает, перехватывайте изменения, обрабатывайте полученные данные." Сравним: во Vue мы контролируем все изменения DOM-дерева. Мы привязываемся к конкретным элементам. По сути, мы имеем небольшую абстракцию под названием v-model.lazy. Vue тепер знает, что сохранять состояние данных до того, как были произведены первые изменения, нельзя. Отлично! Классы Следующая вещь, которую мы сейчас рассмотрим, является привязкой CSS-классов, так как наш всеми любимый и обожаемый Гугл сообщает, что это также наиболее популярный случай использования jQuery. See the Pen 5 by Jeka Muzyka (@jeka-muzyka) on CodePen. See the Pen 6 by Jeka Muzyka (@jeka-muzyka) on CodePen. Опять же, что мы здесь можем видеть, так это то, что в версии с jQuery мы храним состояние объекта в DOM-дереве. Элемент имеет свой класс, jQuery принимает решение на базе существующего класса, проверяющего привязку к DOM. В версии с Vue мы храним условие и применяем к нему стили в зависимости от состояния этого условия. Мы не обращаемся к DOM за этой информацией, мы храним ее сами. Мы храним active в данных, кнопка изменяет состояние условия и, в зависимости от условия, применяется к примеру .red. Даже состояния доступа, aria-pressed, сохраняются гораздо быстрее, так как у нас нет необходимости хранить все в vue-скрипте. Мы можем изменять состояние напрямую при помощи слова active. Если вы думали, что использование Vue породит большее количество кода, последние несколько примеров должны были заставить вас убедиться в обратном. Скрытие и отображение Другой общий случай использования jQuery является отображением и сокрытием элементов. jQuery всегда хорошо справлялся с этой задачей, потому давайте посмотрим, как все будет выглядеть со стороны Vue. See the Pen 7 by Jeka Muzyka (@jeka-muzyka) on CodePen. See the Pen 8 by Jeka Muzyka (@jeka-muzyka) on CodePen. Оба фреймворка успешно справляются с поставленной задачей, но все же и здесь есть свои причины, почему я отдаю предпочтение Vue.js. Vue обладает инструментом под названием Vue devtolls. Это не то же самое, что Chrome devtools, но когда я их использую, я получаю больше специфической информации, связанной непосредственно с Vue.js И в jQuery и в Vue элементы успешно скрываются и появляются вновь. Но что, если что-то пойдет не так? Что, если что-то в нашем коде работает не так, как это было задумано? В случае с jQuery для отладки мы бы скорее всего использовали console.log и были бы таковы. Это все, конечно, хорошо, но в случае с Vue он сам нам предоставит всю необходимую информацию о нем самом. На пикче ниже мы можем увидеть, как элемент скрывается\появляется и как изменяется его состояние в специальном окне. Если DOM по какой-то причине не будет работать так, как мы от него ожидаем, вся необходимая информация будет легко отображена во Vue. Что еще мне нравится, так это то, что v-if очень удобно принять в других случаях. Я могу использовать v-show, если вещь будет скрыватся и отображатся часто: v-if полностью "демонтирует" элемент, тогда как v-show просто изменит видимость. Это достаточно важно, так как позволяет улучшить производительность. Я легко могу установить целые каскады условий, в то время как повторить подобное с jQuery - слегка затруднительно. See the Pen 9 by Jeka Muzyka (@jeka-muzyka) on CodePen. See the Pen 10 by Jeka Muzyka (@jeka-muzyka) on CodePen. В этом примере значения с приставкой Vue реагируют на код достаточно натурально и с меньшим объемом кода. Однажды попробовав этот стиль, логику приложений, разработанных под Vue, использовать будет значительно проще. Передача формы Так уж исторически сложилось, что отправка формы посредством Ajax является наиболее "каноничным" примером использования jQuery. А потому мы просто обязаны рассмотреть альтернативу. На самом деле, Vue не обладает встроенными вещами навроде Ajax. Обычно вместо этого здесь используется Axious (js-библиотека для генерации http-запросов). Этот пример будет несколько более сложным, чем предыдущие. Мы собираемся произвести следующее: До начала ввода в форму клавиша будет серой. После чего она примет "активный" класс и станет голубой. Когда мы отправляем форму, страница не будет перезагружаться. Как только форма принята, мы отобразим ответ на странице. See the Pen 11 by Jeka Muzyka (@jeka-muzyka) on CodePen. Здесь за управление классом клавиши отвечают строки 2-10. Похоже на то, что мы делали ранее.  Мы передаем в параметр под названием событие форму и говорим event.preventDefault(), дабы запретить перезагрузку страницы. После чего мы собираем всю информацию с формы и отправляем через Ajax запрос (.done()). See the Pen 12 by Jeka Muzyka (@jeka-muzyka) on CodePen. В версии Vue мы биндим поля через v-model. Мы проверяем имена для связки с классом. Вместо передачи информации и загрузки страницы event.preventDefault(), нам всего лишь нужно написать @submit.prevent в нашем элементе формы. Для передачи запроса же мы используем Axious. Конечно, так же можно произвести и валидацию, отлавливание ошибок, тесты и так далее. Но для понимания логики работы с Vue, как мне кажется, достаточно и этих небольших примеров. И в заключение Нет ничего плохого в том, чтобы продолжать использовать jQuery. Цель этой статьи - всего лишь показать, что Vue так же хорош в качестве некой такой абстракции для небольших сайтов. Этот фреймворк оптимален в размерах, прост  в работе и освоении, достаточно тривиален и прекрасно интегрируется в HTML & JS без необходимости перестраивать приложение. Благодаря гибкости Vue передача кода на стадию билда и общая компонентная структура не являются чем-то сложным. На самом деле - это очень даже весело. Попробуйте сами! Вы можете скаффолдить весь Vue на уровне продакшена просто при помощи пары терминальных команд. Подобным образом вы можете работать с отдельными компонентами, не трогая HTML & JS. Вам не нужно менять конфигурацию вашего веб-пака, разве что вы не захотите сделать что-то специфическое. Vue хорош во всем, что касается адаптивности, так как вам не нужно ничего менять в вашей разметке, чтобы работать с новым, качественными фреймворком. Удачи в разработке! Автор перевода: Евгений Лукашук Источник