Готовы ли вы к внедрению инноваций в ваши веб-приложения в 2019 году? Представляем вам последние тренды веб-разработки, которым, безусловно, стоит следовать! Стандарты веб-разработки часто меняются быстрее, чем их успевают внедрять. Чтобы всегда быть на шаг впереди, важно сосредоточиться на тенденциях, методах и подходах, которые только набирают популярность. Мы проанализировали тренды в разных отраслях, чтобы сформировать этот окончательный список тенденций в веб-разработке на 2019 год. В качестве бонуса, вам также представлен топ лучших стеков веб-технологий, достойных вашего внимания в следующем году. Не будем тратить время на долгие вступления. Все тренды здесь:   Голосовой поиск В настоящее время мы наблюдаем начало эры голосового поиска. Каждый смартфон уже оснащен цифровым голосовым помощником (Siri для iPhone, Google Assistant для телефонов на базе Android). Более того, набирают популярность умные колонки с искусственным интеллектом. В чем причина такого внимания к голосовым интерфейсам? Простота использования. Голосовое общение - это то, что нам не нужно изучать. Таким образом, дети и пожилые могут взаимодействовать с голосовыми интерфейсами без каких-либо сложностей в  обучении. Доступность. Цифровые голосовые помощники уже стали привычной функцией смартфона. Интеллектуальные колонки пока не так распространены, но цена от 50 долларов - отличная предпосылка для экспансии. К 2020 году ожидается, что 50% всех поисковых запросов будут осуществляться посредством голоса. Внедрение голосового поиска сейчас является одной из основных тенденций в e-commerce. Тем не менее, это также применимо к любому другому бизнесу в Интернете. Если вы хотите, чтобы ваше веб-приложение было найдено, оптимизируйте его для работы с голосовым поиском как можно скорее. Также мы рекомендуем рассмотреть возможность разработки собственного приложения для умных колонок. Это даст вам еще один канал для формирования лояльной аудитории и увеличения продаж.   WebAssembly   При создании веб-приложения производительность приложения обычно является компромиссом с кроссплатформенностью. Ограничения JavaScript делают тяжелые вычисления медленными, и это существенно влияет на производительность для пользователя. Именно поэтому большинство популярных игр и мощных приложений доступны только в качестве десктопного приложения. Формат WebAssembly может быть применен, чтобы изменить эту ситуацию. Этот новый формат ориентирован на нативную производительность среди веб-приложений. С помощью WebAssembly, код на любом языке программирования может быть скомпилирован в байт-код, который запускается в браузере. Код WebAssembly выполняется быстрее, чем код на JavaScript. В результате использования WebAssembly, вы сможете писать критически важные для приложения части на наиболее подходящем языке (C / C ++ / C # / Rust / Kotlin и т. Д.). WebAssembly сам позаботится о выполнении кода в браузере. Нативные приложения теперь можно запускать сразу в браузере. Это означает доступ к большему количеству пользователей, благодаря предложенной им сопоставимой с десктопной производительностью в сети без дополнительных затрат на разработку! Основная проблема с WebAssembly заключается в том, что еще не все браузеры поддерживают его. Однако скоро это изменится. Веб-приложения становятся более мощными с WebAssembly. Эту технологию определенно стоит попробовать. Машинное обучение в веб-разработке Технологии искусственного интеллекта, включая машинное обучение, уже давно влияют на наше поведение в Интернете, хотя, зачастую, это происходит незаметно для нас. Это основной момент применения машинного обучения – улучшение взаимодействия пользователя с приложением. Машинное обучение - это способность программного обеспечения повышать производительность без непосредственного участия разработчиков. По сути, программное обеспечение анализирует входящие данные, выявляет закономерности, принимает решения и улучшает свою работу. К примеру, компания Airbnb применила машинное обучение для настройки результатов поиска потенциальными гостями мест поселения. С помощью специфического алгоритма, компания хотела повысить вероятность того, что владелец жилья примет запрос от потенциального гостя. Алгоритмы машинного обучения должны были анализировать решения о принятии запросов каждого владельца. Пользуясь итогами такого анализа, компания смогла предоставить клиентам результаты поиска, которые стали полезными им с большей вероятностью. A / B-тестирование показало увеличение конверсии на 3,75%. В результате все запросы от пользователей Airbnb теперь обрабатываются в соответствии с этим алгоритмом, который повышает удовлетворенность клиентов и увеличивает доход. Отличный пример внедрения, не правда ли? Но это еще не всё! Применение естественного языка и распознавания изображений могут улучшить общие впечатления пользователя от использования сервиса. Машинное обучение позволяет компьютеру правильно интерпретировать данные и принимать обоснованные решения. Машинное обучение уже используется в веб-приложениях в различных отраслях, таких как здравоохранение, финансы, образование, сельское хозяйство и т. д. Эта технология предлагает существенные усовершенствования, которые было бы трудно достичь без технологий ИИ. Машинное обучение становится важной частью любого веб-сервиса. Важно, чтобы и вы попробовали найти применение для этой технологии в своих сервисах! Анализируйте поведение посетителей вашего веб-сайта и настраивайте под них отображаемый контент. Они никогда не узнают, что вы применяете к ним некий алгоритм, но их возросшая удовлетворенность контентом приведет к увеличению их вовлеченности и к увеличению конверсии! Машинное обучение может стать вашим секретным оружием, чтобы переиграть ваших конкурентов!   Безопасность данных Чем больше данных обрабатывает ваше веб-приложение, тем больше оно привлекает внимание киберпреступников. Они стремятся нарушить работу ваших сервисов и украсть данные ваших пользователей или внутреннюю информацию компании. Это может дорого обойтись и вам, и вашей репутации. Безопасность вашего веб-сервиса должна стать вашим главным приоритетом. Итак, чтобы сохранить пользовательские данные в 2019 году, следуйте этим советам: Никогда не пренебрегайте тестированием безопасности. Тестирование безопасности должно проводиться уже на этапе разработки, благодаря чему оно может предотвратить утечку данных. Каждое изменение в вашем веб-приложении должно быть явно протестировано. Используйте инструменты мониторинга сайта. Алгоритмы анализа поведенческих факторов помогут вам постоянно отслеживать все запросы, а также выявлять и квалифицировать подозрительные действия. Своевременное выявление угрозы позволит вашей команде вовремя среагировать и защитить веб-приложение от преступников. Тщательно выбирайте сторонние сервисы. Программное обеспечение SaaS (англ. software as a service — программное обеспечение как услуга, прим. переводчика) становится все более популярным, поскольку делает разработку приложений проще и быстрее. Однако вы должны убедиться, что поставщик услуг, с которым вы работаете, заслуживает доверия. Шифрование конфиденциальных данных. Даже если преступник сможет получить доступ к вашей базе данных, он не сможет извлечь какую-либо пользу из конфиденциальных данных, хранящихся там в зашифрованном виде.     Блокчейн в веб-разработке Несмотря на то, что блокчейн утратил часть доверия к себе из-за нестабильности обменных курсов криптовалют, мы должны признать - эта технология уже бесповоротно вошла в нашу жизнь. И хотя эта технология впервые была применена в сфере настольных компьютеров - блокчейн уже уверенно проникает и в WEB. Blockchain кошельки переместились с нативных настольных приложений в веб-приложения. Они идеально подходят для хранения небольших сумм криптовалют и предлагают улучшение удобства использования. Поскольку популярность веб-кошельков продолжает расти, вам следует рассмотреть и применение этой сферы технологий. Другая реализация технологии блокчейна называется dapps или децентрализованные приложения. Уникальная особенность таких приложений - хранение логики сервера и базы данных в блокчейне. В результате ни одна организация не может контролировать приложение (например, Facebook, Google и т. д.). Dapps изначально работали как настольные приложения. Но в настоящее время они тоже переходят в WEB. Во всем мире сеть стремится к децентрализации, поэтому популярность dapps, скорее всего, возрастет. Ethereum, самая популярная платформа с открытым исходным кодом для блокчейн-проектов, выпустила библиотеку JavaScript web3.js. Эта библиотека позволяет легко разрабатывать клиентов, которые взаимодействуют с блокчейном Ethereum различными способами, такими как: создание интеллектуальных контрактов, запись и чтение данных из смарт-контрактов, передача криптовалюты между двумя учетными записями и многое другое. Библиотека Web3 также доступна для других языков программирования, включая Python, Java, PHP, Swift, Scala и т. д. Таки образом создание децентрализованных приложений с удобными веб-интерфейсами становится проще. Очевидно, что пик ажиотажа вокруг технологии блокчейна уже прошел. Но это значит только, что пришло время приступить к серьезной разработке мощных решений, которые смогут использовать большинство преимуществ этой технологии. Может быть, именно ваш проект станет следующим ньюсмейкером?     Прогрессивные веб-приложения (PWA) и ускоренные мобильные страницы (AMP) Google отдает приоритет тем веб-приложениям, которые быстро загружаются на мобильных устройствах. Именно поэтому вам следует рассмотреть возможность внедрения PWA или AMP, которые являются уникальными технологиями, сокращающими время загрузки веб-страницы. Прогрессивное веб-приложение (PWA) - это веб-страница, которая воспроизводит привычный мобильный интерфейс. Это технология работает быстро, может работать как постоянно онлайн, так и с плохим подключением к интернету, и является относительно дешевой. PWA поддерживает взаимодействие, позволяя пользователям наслаждаться высококачественными возможностями приложений, даже не осознавая, что они используют их через браузер. Приложения E-commerce являются частым примером использования этой технологии. Ускоренная мобильная страница (AMP) работает только для статического контента, но загружается быстрее, чем обычный HTML. AMP пропускает все модные элементы и отображает только важную информацию - текст, изображения и т. д. Этот подход отлично подходит для блогов и новостных изданий. Нужно ли вам применять PWA или AMP, зависит от вашего конкретного случая. Тем не менее, вам следует начать рассматривать эти технологии прямо сейчас. Наряду с улучшением качества предоставляемой услуги, у вас есть шанс значительно поднять свой рейтинг в результатах поиска.     Интернет вещей Какие устройства вы в основном используете для доступа в интернет? Скорее всего, это ноутбук и смартфон. Тем не менее, сегодня подключаться к Интернету может гораздо большее количество устройств. Да, мы имеем в виду Интернет вещей или IoT, для краткости. В настоящее время многие устройства оснащаются экраном. Благодаря такой тенденции, веб-приложения, оптимизированные для отображения данных на смарт-часах, холодильниках, интеллектуальных колонках и т. д., станут более востребованными. Адаптированность к мобильным интерфейсам больше не является трендом, уже являясь обязательным элементом работы приложения. Тенденция 2019 года - адаптация веб-приложений для маленьких экранов. Motion UI Motion Design - один из главных трендов веб-дизайна будущего года. Минималистичный дизайн, в сочетании со сложными взаимодействиями, выглядит стильно и привлекает внимание пользователя. Переходы в хедере страницы, удобные подсказки, анимированные диаграммы, фоновая анимация и модульная прокрутка. Эти, и многие другие элементы, помогут вам отобразить свой уникальный стиль и завлечь пользователя, улучшая поведенческие факторы и помогая вашему веб-приложению занять более высокое место в результатах поиска.     Стэк технологий для разработки веб-приложений   Крайне важно работать с последними проверенными технологиями. Таким способом вы сможете гарантировать, что разработанное программное обеспечение соответствует требованиям рынка и остается актуальным в течение нескольких лет. А вот и самые популярные технологии 2019 года:   Технологии front-end   Ангуляр Впервые мы услышали об AngularJS в 2010 году. Уже через 6 лет, в 2016 году, фреймворк был полностью переписан и вышел под названием Angular 2. На конец 2018 года последней стабильной версией является Angular 7. Angular - это фреймворк Model-View-Controller (MVC). Три отдельных компонента позволяют писать хорошо структурированный и простой в поддержке код. Двунаправленная привязка данных удобна для простых приложений - любые изменения в модели будут немедленно внедрены в представление и наоборот. Однако если вы работаете над сложным проектом, однонаправленная привязка данных сэкономит ваше время и ресурсы. Чтобы использовать Angular максимально эффективно, вам придется использовать Typescript. Вам также следует помнить, что фреймворк работает только с обычным DOM, что создает некоторые ограничения. Стек MEAN – является одним из самых популярных. Он включает в себя: MongoDB - база данных; Express.js - веб-фреймворк; Angular – фронтэнд фреймворк; Node.js – бэкенд. Очевидным преимуществом этого стека является то, что все его компоненты используют JavaScript. В результате собрать команду разработчиков (или нанять одного разработчика full-stack JavaScript) не будет проблемой.   React.js В описанном стеке Angular часто заменяется на React - библиотеку Javascript. Стек MERN является относительно молодым, но растущая популярность React поспособствовала быстрому росту его популярности. React превосходит по своим возможностям Angular благодаря виртуальному DOM, который позволяет быстрее и проще вносить изменения. Однако, поскольку React является библиотекой, а не фреймворком, что ограничивает основные функциональные возможности, разработчикам приходится работать со сторонними сервисами. Также стоит упомянуть, что React использует JSX - модификацию JavaScript, которая обеспечивает бесшовную совместимость компонентов. Таким образом, знание JSX является предпочтительным, если вы хотите максимально использовать стек MERN и особенно React.   Vue.js Vue.js является более молодым JS фреймворком, но за последние несколько лет он продемонстрировал невероятный рост популярности. Частично это связано с тем, что это облегченное решение. По сравнению с монолитом, подобным Angular, он предлагает только базовую функциональность «из коробки». Используя сторонние сервисы, эта функциональность расширяется. В результате нет необходимости обрабатывать избыточный код, как в случае с Angular. Как вы, вероятно, догадались, Vue.js также используется вместе с MongoDB, Express.js и Node.js как часть стека MEVN.     Технологии Back-end: Как правило, сложно выбрать между пользовательской конфигурацией бэкенд разработки и backend-as-a-service. Оба варианта имеют свои плюсы и минусы, и выбор зависит от деталей проекта. Мы не будем сейчас вдаваться в подробности, так как существуют отдельные статьи, сравнивающие mBaaS и пользовательский бэкенд - ознакомьтесь с ними, чтобы узнать больше по этой теме. Здесь мы рассмотрим самые популярные решения для пользовательского бэкенда.   Node.js Node.js является важным компонентом всех вышеописанных стеков веб-разработки. Это среда выполнения приложений, которая используется для создания приложений на стороне сервера. Работа с Node.js требует знания JavaScript. По этой причине он часто используется в стеках вместе с инфраструктурой внешнего интерфейса JS.   Django Django - это веб-фреймворк Python. Он может использоваться в основном с любым фронтенд фреймворком (включая описанные выше). Он также является хорошим решением для любых типов веб-сайтов из-за множества доступных сторонних пакетов. С ростом популярности Python стоит рассмотреть Django для серверной части вашего веб-приложения.   Laravel PHP -  широко используемый язык программирования бэкенда, а Laravel - один из самых популярных PHP фреймворков. Laravel отлично работает с Vue.js. Тем не менее, Angular и React также хорошо подходят для разработки веб-приложений с Laravel.   Заключение Попытки угнаться за последними трендами могут показаться излишне сложными, так как тренды меняются очень быстро. Но почему бы не попробовать? Следуя последним тенденциям в веб-разработке, вы сможете порадовать своих пользователей контентом мирового уровня, повысить рейтинг ваших веб-приложений и открыть для своих услуг новые рынки! В течение следующих нескольких лет голосовой поиск укрепит свои позиции и заставит поставщиков услуг адаптироваться к новой реальности. Подходя к этому с умом, вы можете оказаться в числе первых компаний, которые обращаются к вашим клиентам с помощью голосового поиска. Звучит заманчиво, не правда ли? Безопасность пользовательских данных уже давно вызывает сомнения. Это проблема, которой нельзя пренебрегать, если вы хотите быть лидером рынка. Блокчейн - это технология со многими приложениями в веб-разработке, так почему бы не исследовать ее возможности на ранней стадии ее появления? Говоря в общем, каждый тренд 2019 года заслуживает вашего внимания. Некоторые из них будут актуальными в течение нескольких лет, а некоторые станут обыденностью уже через несколько месяцев. Так что не стесняйтесь начинать реализовывать их как можно скорее. Автор: София Меренич, технический и бизнес писатель. Источник

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

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. Надеюсь, вы найдете их полезными! Автор перевода: Евгений Лукашук Источник

Каков Ваш код на... запах? Как люди мы имеем огромное количество различных желез на теле. Как у программистов у нас есть множество строчек кода в проектах. Как у людей некоторые наши железы выделяют запах - хороший или не очень. Как у программистов некоторые наши строчки кода также могут иметь своеобразный "запашок". В мире программирования "запашок" недопустим. Подобно тому, как неприятный запах может свидетельствовать о различных медицинских проблемах организма, плохо организованный код также может быть симптомом плохо построенной архитектуры приложения. Итак, должны ли мы беспокоиться при наличии "запаха" у нашего кода? "Запах" кода - это не то же самое, что и баг. Если коротко, "запах" кода - это та ситуация, когда вроде бы нам не очень нравится код, который мы написали, но не так, чтобы его исправлять или переписывать... Это как раз таки фатальная ошибка. Рост кода подобен по своей природе росту дерева. Отсекание некошерных веток важно, чтобы дерево оставалось в добром здравии. Если этого не делать, ветки становятся все длиннее и длиннее - и, как следствие, процесс сбора плодов также становится затруднительным. Без рефакторинга поддержка кода может стать затратным вложением. Дурной запах кода усложняет поддержку, так как любой код требует поддержки. Вообще, "запах" кода был классифицирован в зависимости от сценария, который он представляет. Эта статья - краткий взгляд на различные виды несовершенств кода, чтобы мы могли понять, на что стоит обратить внимание в разрабатываемых продуктах. И давайте быть честными по отношению хотя бы к самим себе: если не сейчас, то никогда. Что же, начнем! "Дух" плохих методов Первое, на что стоит обратить свое пристальное внимание, - это название метода. Также не стоит забывать и о названиях и общей длине параметров. Вот типичный "идеальный" метод: Название четкое и ясное Не длиннее 30 строчек и принимает не более 5 параметров Реализация - простейшая из возможных, нет "мертвого" кода Здесь представлен список возможных несовершенств:   Название Описание 1 Мертвый код метод не используется. 2 Ленивый объект метод делает очень мало работы. 3 Посредник все, что делает этот метод, - это вызывает другой метод. 4 Божественный метод метод исполняет слишком много обязанностей. 5 Длинный список параметров не забываем про рекомендацию в 5 параметров. 6 Перекрученная сложность слишком сложная реализация простых операций. 7 Цикличный ад злоупотребление циклами и условными конструкциями. 8 Излишняя близость метод очень сильно зависит от особенностей реализации другого метода. 9 Завистливый объект метод полагается на данные другого объекта больше, чем на свои. 10 Черная овечка метод сильно отличается от других методов класса. "Запашок" класса Проверяйте название класса и то, насколько реализуемый классом контракт отвечает его сути. Как правило, идеальный класс прекрасно отображает назначение различных сущностей на уровне бизнес-логики и реализует ее в рамках архитектуры, выбранной для самой бизнес-логики. Вот список возможных несовершенств, связанных с классом:   Название Описание 1 Ленивый объект класс выполняет слишком мало работы. 2 Посредник класс ничего не делает, просто вызывает объекты другого класса. 3 Божественный объект класс слишком много о себе возомнил. Реализует слишком много операций. 4 Узколобое мышление слишком примитивная реализация типов с особым назначением. 5 Шпион на допросе реализуемый классом интерфейс не сообщает достаточное количество информации, чтобы понять назначение объекта. 6 Эксгибиционист необязательное раскрытие внутренних деталей реализации. 7 Излишняя близость класс слишком сильно зависит от реализации объектов, на которые он ссылается. 8 Жадинка класс наследует поведения объекта, тогда как на самом деле классу нужны лишь некоторые его фрагменты. 9 Неопределенность разработка класса становится слишком сложной из-за вороха фич, которые "когда-то" будут доведены до ума. 10 Непостоянство класс содержит член данных, не характерный для всего времени жизни объекта. Общее впечатление о коде Рассматривая более высокий уровень абстракции, стоит также упомянуть несколько немаловажных аспектов:   Название Описание 1 ​Утраченный смысл код не совсем точно реализует требуемую от него задачу. 2 Выбирай, что хочешь та же самая проблема уже решена - причем несколькими способами. 3 Комбинаторный взрыв различные участки кода делают одно и то же, но с разным набором параметров. 4 Не копируй себя много идентичного кода. 5 Сложность слишком сложная реализация простых вещей. 6 Размазня нет единого глобального класса. Ответственность размазана по целому вороху промежуточных классов. 7 Подводный айсберг изменения внешне не связанных компонентов затрагивают слишком много вещей.  8 Спагетти-код изменение одного компонента требует множество мелких изменений в других местах. 9 Пиар-комментарии классные комментарии в плохом коде. 10 ​Информационный комок группа переменных почти всегда передается вместе. Стоит также уделить минутку своего внимания комментариям в коде. В то время, как комментирование назначения метода будет полезным для всех, кто читает его, комментирование реализации метода - достаточно спорное решение. Риск состоит в том, что по неосторожности можно использовать упомянутые "пиар-комментарии" к тем строчкам, которые этого отнюдь не заслуживают. Отличный код таков, что нуждается в малом количестве комментариев, так как его реализация становится понятной интуитивно. Комментарии стоит использовать, когда мы комментируем особенности технических решений, вещи, оставленные для рассуждения или будущие этапы разработки. Как бы это странно ни прозвучало, но комментарии никогда не должны рассматриваться в качестве обязательных для написания. Также не стоит забывать о различных тестах (в особенности о тех, которые не пишутся просто для повышения процента покрытия кода). Стереотипы Конечно же, куда без них. Кто-то может утверждать, что подобные тонкости коддинга начали выделять с прогрессом информационной индустрии. Мол, "запашок" кода очень часто является следствием "плохих привычек" написания или же в силу определенных обстоятельств. Подобные оправдания звучат несколько неубедительно и говорят о тараканах в голове разработчика: каждый уважающий себя программист должен стараться писать хороший код абсолютно всегда. По умолчанию! Другой стереотип, о котором также стоило бы упомянуть, - это избыточная вера в рефакторинг. Что же, рефакторинг как процедура переписывания кода также может быть выполнен из рук вон плохо. Излишняя цикличность, слишком сложные решения и прочее-прочее запросто может быть добавлено в проект из лучших побуждений - особенно в том случае, если по принципу организации исходный код не сильно отличается от здорового клубка спагетти. В итоге все разработчики могут "запачкать" свой код. Что хуже, часто это бывает под давлением внешних обстоятельств, особенно у "временных" разработчиков для хотфиксов. Проверки качества кода должны происходить всегда сразу после быстрых релизов. И в заключение Большинство из тех проблем, с которыми мы сталкиваемся, часто связаны с логическим промежутком, пропастью между уровнем абстракции выбранного языка программирования и языком бизнеса. Чем больше нам удается отстранится от "самовыражения" посредством языка программирования к бизнес-целесообразности, тем более читабельным и поддерживаемым будет наш код. Гранулярность, модульность, разделение задач и все те прекрасные теоретические концепции, о которых мы могли слышать до этого, становятся конкретными и вещественными, когда мы загораемся желанием следовать концепции делового прагматизма и утилитарности. Источник Переводчик: Евгений Лукашук

Дмитрий Охрименко – один из создателей 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 и культивировать освоение тех частей этой библиотеки, которые необходимы для работы в проекте. Тимлидер может составить список докладов, и каждый сможет их проводить, будет общая копилка тех тем, по которым разработчик может провести мастер-класс и сделать расписание – это будет наиболее эффективный способ поделиться знаниями в команде. Также как способ - экстремальное программирование, вместе работать с одной задачей. Кто-то один знает процесс и диктует, а второй набирает код. Экстремальное программирование никто не отменял, но не в каждом проекте оно может примениться, чтобы более опытный специалист смог передать свои знания.

Об авторе Юрий Думов работает архитектором программного обеспечения в 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 хорош во всем, что касается адаптивности, так как вам не нужно ничего менять в вашей разметке, чтобы работать с новым, качественными фреймворком. Удачи в разработке! Автор перевода: Евгений Лукашук Источник

Коротко про мене Мене звати Зел, я розробник-фрілансер із Сінгапуру. У вільний від роботи час я люблю розбиратися в коді і принагідно публікувати у своєму блозі ті цікавості, які я виявив чи вивчив. Вступ Швидше за все вам уже доводилося чути про такий термін, як REST API, особливо якщо ви стикалися з необхідністю отримання даних з іншого джерела (такого як Twitter або GitHub). Але що ж все-таки це таке? Що ми можемо робити з цим і як ми можемо це використовувати? У цій статті ви дізнаєтеся все про REST API для того, щоб працювати з ними та читати пов'язану з ними документацію. Що ж таке REST API? Давайте уявимо, що ви намагаєтеся знайти фільми про Бетмена на YouTube. Ви відкриваєте сайт, вбиваєте у форму пошуку слово «Бетмен», тиснете «Окей» і бачите список фільмів про супергероя. Так само працює і WEB API. Ви шукаєте щось і отримуєте список результатів від ресурсу, до якого здійснюєте запит. Дослівно API розшифровується як Application Programming Interface. Це набір правил, що дозволяє програмам спілкуватися одна з одною. Розробник створює API на сервері та дозволяє клієнтам звертатися до нього. REST – це архітектурний підхід, що визначає, як API мають виглядати. Читається як "Representational State Transfer". Цьому набору правил і слідує розробник під час створення свого застосунку. Одне з цих правил каже, що при зверненні до певної адреси ви повинні отримувати певний набір даних (ресурс). Кожна адреса - маршрут, пакет даних - запит, у той час як результуючий ресурс – відповідь. Анатомія запиту Важливо розуміти структуру запиту: Маршрут відправки. Тип методу. Заголовки. Тіло (або дані). Маршрут – це адреса, за якою надсилається ваш запит. Його структура приблизно така: Root-endpoint - це точка прийому запиту на стороні сервера (API). Наприклад, кінцева точка GitHub - https://api.github.com. Шлях визначає ресурс, до якого здійснюється запит. Це щось на кшталт автовідповідача, який просить вас натиснути 1 для одного сервісу, 2 для іншого і так далі. Для розуміння того, які саме шляхи вам доступні, вам слід переглянути документацію. Наприклад, припустимо, ви хочете отримати список репозиторіїв для конкретного користувача на Git. Згідно з документацією, ви можете використати наступний шлях для цього: Вам слід підставити під пропуск ім'я користувача. Наприклад, щоб знайти список моїх репозиторіїв, ви можете використати маршрут: Остання частина маршруту – це параметри запиту. Технічно запити не є частиною REST-архітектури, але на практиці зараз все ґрунтується на них. Тож давайте поговоримо про них детальніше. Параметри запиту дозволяють використовувати у запиті набори пар «ключ-значення». Вони завжди починаються знаком питання. Кожна пара параметрів після чого розділяється амперсандом (щось подібне до цього): Як тільки ви намагаєтеся отримати список репозиторіїв для користувача, ви додаєте ці три опціональні параметри і після чого отримуєте наступний результат: Якщо ж ви бажаєте отримати список моїх недавно запушених репозиторіїв, вам слід ввести наступне: Отже, як же зрозуміти, що маршрути робочі? Що ж, настав час перевірити їх на практиці! Тестування за допомогою Curl Ви можете надіслати запит за допомогою будь-якої мови програмування. JavaScript може використовувати методи на кшталт Fetch API або JQuery`s Ajax Method. Рубі використовує інше. І так далі. У цій статті я використовуватиму таку утилітку, як Curl. Справа в тому, що вона вказана в офіційній документації для веб-сервісів. Якщо ви зрозумієте, як використовувати цю утиліту, ви зрозумієте, як працювати з API. Після чого ви можете робити запити будь-якою зручною для вас мовою. Перед тим, як продовжити, слід переконатися, що Curl встановлений на вашій машині. Якщо ж він не встановлений, саме час встановити. У такому разі ви отримаєте помилку "command not found". Для того щоб використовувати утиліту, необхідно ввести наступне (за прикладом): І як тільки ви підтверджуєте введення, ви отримуєте відповідь (на зразок цього): Щоб отримати список користувацьких репозиторіїв, вам слід змінити запит за тим же принципом, який був обговорений раніше. Наприклад, щоб отримати список моїх репозиторіїв, вам слід ввести наступне: Якщо ж ви бажаєте включити параметри запитів, переконайтеся, що ви їх екрануєте. Справа в тому, що без екранування знаки питання і рівності розцінюються системою як спецсимволи і виконання команди відбудеться з помилкою. Також спробуйте інші команди та зробіть запити! В результаті ви отримуєте схожі відповіді. JSON JSON – JavaScript Object Notation – загальний формат для надсилання та прийому даних за допомогою REST API. Відповідь, що відправляється Github, також міститься у форматі JSON. Зміст об'єкту цього формату приблизно наступний: Повертаємось до анатомії запиту. Ви вивчили, що запит складається із чотирьох частин: Маршрут відправки. Тип методу. Заголовки. Тіло (або дані). Тепер давайте спробуємо розібратися з рештою. Тип методу Метод позначає тип запиту, який здійснюється; де-факто він є специфікацією операції, яку повинен здійснити сервер. Усього існує п'ять типів запитів: GET POST PUT PATCH DELETE GET – використовується для отримання з боку серверу певного ресурсу. Якщо ви здійснюєте цей запит, сервер шукає інформацію та відправляє її вам назад. По суті, він здійснює операцію читання на сервері. Дефолтний тип запитів. POST – необхідний для створення певного ресурсу на сервері. Сервер створює в базі даних нову сутність та сповіщує вас, чи був процес створення успішним. По суті, це операція створення. PUT та PATCH – використовуються для оновлення певної інформації на сервері. У такому разі сервер просто змінює інформацію існуючих сутностей у базі даних та повідомляє про успіх виконання операції. DELETE – як і випливає з назви, видаляє вказану сутність із бази чи сигналізує про помилку, якщо такої сутності в базі не було. Сам же API дозволяє вказати, який метод має бути використаний у певних контекстних ситуаціях. GET запит у цьому випадку необхідний, щоб одержати список всіх репозиторіїв зазначеного користувача. Також можна використовувати curl: Спробуйте надіслати цей запит. Як відповідь ви отримаєте вимогу про аутентифікацію. Заголовки Заголовки використовуються для надання інформації як клієнту, так і серверу. Взагалі, їх можна використовувати для багато чого; наприклад, та сама автентифікація та авторизація. На офіційній сторінці MDN можна знайти список доступних заголовків. Заголовки являють собою пари ключів-значень. Приклад: Також приклад із використанням curl: (Примітка: заголовок Content-Type у випадку Github для роботи не є обов'язковим. Це всього лише приклад використання заголовка в запиті, нічого більше). Для перегляду надісланих заголовком даних можна використовувати наступне: Тут зірочка відноситься до додаткової інформації, наданої за допомогою curl. > відноситься до заголовків запиту, а <, відповідно, - до заголовків відповіді. Щоб надіслати інформацію з curl, використовуйте наступне: Для відправки множинних полів ми можемо використати декілька подібних конструкцій: Також, якщо необхідно, ви можете розбити ваш запит на декілька ліній для забезпечення більшої читабельності: Якщо ви знаєте, як розгорнути сервер, ви можете створити власний API та протестувати свої запити. Якщо ж ні, обов'язково спробуйте. Існує безліч інформації, присвяченої цьому. Якщо ж бажання розгортати свій сервер немає, спробуйте безкоштовну опцію Request bin. Після чого ви отримаєте адресу, яку спокійно зможете тестувати. Переконайтеся, що ви створюєте власний request bin, якщо ви хочете протестувати саме ваш запит. Зважайте на те, що дефолтний час існування request bin – 48 годин. Тому ті приклади адрес, які я тут наводжу, на момент прочитання статті давно застаріли. Тепер спробуйте надіслати деяку інформацію, після чого оновіть свою сторінку. Якщо все пройде успішно, ви побачите наступне: За замовчуванням curl відправляє дані так, ніби вони були відправлені за допомогою полів форм. Якщо ви бажаєте надіслати дані через JSON, ваш Content-Type повинен дорівнювати application\json, внаслідок чого вам необхідно відформатувати дані у вигляді JSON-об'єкту. По суті, це все, що вам необхідно знати про структуру запиту. Тепер давайте згадаємо про аутентифікацію. Що ж це таке і навіщо вона потрібна? Аутентифікація Ви б не дозволили нікому чужому отримати доступ до вашого банківського рахунку без спеціального дозволу, чи не так? За таким же принципом розробники не дозволяють неавторизованим користувачам робити на сервері все, що їм заманеться. Оскільки POST, PUT, PATCH, DELETE запити змінюють базу даних, розробники повинні завжди бути на варті неавторизованого доступу до них. Проте іноді GET запити також вимагають аутентифікації (наприклад, коли ви хочете переглянути стан вашого банківського рахунку). У випадку з вебом існує два способи представитися системі: Через нік і пароль (базова автентифікація) Через секретний токен Секретний токен дозволяє представити вас системі через соцмережі на кшталт Github, Google, Twitter і так далі. Тут же я розгляну лише базову автентифікацію. Для виконання базової аутентифікації ви можете використовувати наступне: Спробуйте залогінитися під свій профіль за запитом, вказаним вище. Як тільки ви успішно увійдете у свій профіль, ви побачите відповідь "problems parsing JSON". Чому? Все просто: системі ви представилися, але - от біда - нічого корисного їй не надали. Усі типи запитів потребують певної інформації. Тепер же давайте поговоримо про статус-коди та можливі помилки. Статус-коди та можливі помилки Деякі з повідомлень, наведених вище, якраз і належать до кодів помилок. Логічно, що вони з'являються лише тоді, коли щось іде не зовсім так, як було заплановано. Що ж до статусу кодів, вони дозволяють вам пізнати успіх (або невдачу) під час виконання певного запиту. Бувають статус-коди від 100 до 500+. Загалом їх можна поділити на такі групи: 200+: запит успішний 300+: запит перенаправлений на інший маршрут 400+: помилка на стороні клієнта 500+: помилка на стороні сервера Ви можете відлагодити статус відповіді за допомогою –v або –verbose. Наприклад, я спробував отримати доступ до певного ресурсу без авторизації. Відповідно, я спіймав помилку: У випадку ж, коли запит невірний через помилку в самій інформації, що передається, ви отримуєте статус-код 400: Версії API Час від часу розробники оновлюють свої API. Іноді оновлення можуть бути такими сильними, що розробник бажає здійснити реліз нової версії. У такому випадку, якщо ваш застосунок ламається, це відбувається через те, що ви писали код з урахуванням старого компонента, тоді як новий дещо відрізняється в плані реалізації. Запросити поточну версію API можна двома шляхами. Через маршурт Через заголовок Наприклад Твіттер використовує перший спосіб. На момент написання версія Twitter API була 1.1. Водночас GitHub використовує інший спосіб: На закінчення У цій статті ми розглянули, що таке REST API і як його можна використовувати спільно з curl. Крім того, ви також вивчили, як залогінитись за допомогою запиту і що таке статус-код. Я щиро сподіваюся, що ця стаття дозволила вам підвищити свій рівень загальних і не дуже знань щодо такого важливого аспекту веб-розробки. Буду радий будь-яким вашим коментарям тут. Автор перекладу: Євген Лукашук Джерело Ще більше матеріалів на цю тему: ASP.NET Core Web API. Практичний курс ASP.NET WEB API 2 REST API в Node.js  JAX-RS Client API. Asynchronous REST Створення API на PHP та JavaScirpt

В свое время я работал и продолжаю работать сейчас разработчиком. Начал в качестве веб-программиста в 2004 году, перешел на полный стек в 2009 году, начал разработку для iOS в 2013. Я начал свой путь программиста с прочтения трех книг: одна была про HTML, другая – про CSS и третья, соответственно, об SQL. Прочие знания я получил из Google, Stack Overflow и блогов. Вообще, Интернет – прекрасная штука. Каждый день я прочитывал по 5 или больше тематических статьей. И, что самое главное, все эти знания были бесплатны. В основном мои знания о программировании были получены из университета и опыта работы. Как-то так. Действительно, получается, что большая часть из того, что вы изучаете о программировании, были получено в основном во время решения определенных практических задач. То, что меня также интересует – это чтение различных специализированных книг. Увы, но размеры списков по типу «Обязательных к прочтению для разработчиков» выходят далеко за рамки адекватных. Ситуация со сжатым списком из этого списка также ненамного лучшая… Каждая из книг хороша по-своему, но и целой жизни будет мало, чтобы прочитать все это. Лично меня это всегда несколько сбивало с толку, так как выбрать первую книгу для изучения становится весьма проблематично. Потому я и решил немного покопаться в списках и создать один «универсальный» список, в котором будут включены книги, общие для всех рассмотренных списков. Конечно, прочтение всех этих книг не сделает из вас профессионального программиста, но использование того, что было выучено из книг на практике – сделает. Лично я для себя решил выработать привычку прочитывать по крайней мере одну книгу в два месяца. Полный список содержит 139 книг. Все книги, которые вы увидите в этом списке, находятся на вершине популярности рассмотренных списков. В этом списке вы не найдете книгу о том, как стать Java-разработчиком, но вы можете увидеть книги, которые используют язык Java для приведения практических примеров, рассматриваемых тем. Вы сможете найти книгу, направленную на один конкретный язык программирования, но которая также пригодится и для разработчиков на других языках. Также я включил здесь книги, не связанные с разработкой непосредственно, но которые в то же время считаются неплохими для развития особого «программного» мышления. Короче говоря, без лишних слов – я рад представить: Список лучшей литературы для разработчиков 7 упоминаний: Паттерны проектирования: Элементы повторного использования программного обеспечения «Классическая книга, прочтение которой ознакомит читателя с различными паттернами программного проектирования, а также раскроет некоторые секреты наиболее популярных из них.» Джон Сонмец «Еще одно произведение классики, содержащее в себе огромную коллекцию различных паттернов программирования.» Лик Бун Код: Скрытый язык аппаратного и программного обеспечения «Должна быть в закладках у каждого, кто так или иначе связан с программной индустрией, не важно при этом – программист ли он али нет.» Вуди Леонхард «После прочтения этой книги вы поймете, что на самом деле выполняет ваш код и как на самом деле этот код исполняет процессор. Это одновременно и весело, и полезно.» Джон Сонмерц 8 появлений: Эффективная работа с правильным кодом «Я обожаю эту книгу, так как рано или поздно в один прекрасный момент программисту придётся заниматься поддержкой и разработкой уже существующих комплексных систем.» Джейсон Роял «Если вы принимаете участие над работой с большим объемным кодом более пяти лет, эта книга, вероятно, станет вашей новой Библией. Прочтите это и примите в свои сердца.» Джон Сонмерц Люди: Продуктивные проекты и команды «Эта книга оказала на меня наибольшее влияние в свое время. Пожалуй, я могу сравнить ее с эффектом от прочтения Манифеста Анти-Дилберта.» Джоел Сполски «Если вы желаете носить гордое звание тим лидера на практике, нежели на словах – эта книга определенно для вас.» Джеф Атвуд 9 упоминаний: Паттерны разработки корпоративных приложений «Книга очень полезна при разработке массивных приложений, так как она предлагает детальное объяснение ситуаций, когда нужно использовать определенный программный паттерн (а когда наоборот - нет). Даже не могу назвать примерное количеств раз, сколько мне приходилось обращается к данной книге.» Род Хилтон «Обеспечивает читателя каталогом качественных проверенных корпоративных паттернов и ситуаций, советует, когда эти самые паттерны стоит использовать.» Иан Джойс 11 упоминаний: Вступление в алгоритмы «Пожалуй, это лучшая книга для понимания и использования алгоритмов (которые де-факто являются основным инструментом разработчика программного обеспечения).» Вуди Леонхард 12 упоминаний: Чистый код: Пособник мастера программного обеспечения «Если вы пожелаете прочитать книгу, связанную с программированием, определенно – вам стоит обратить свое внимание на эту.» Роберт Грайнер «Это еще одна книга, которой удалось полностью изменить стилистику написания моего кода. Я могу ясно разделить свою жизнь на период до прочтения книги и после.» Джон Сонмерц Рефакторинг: Улучшение дизайна существующего кода «Книга, строго рекомендуемая к прочтению для каждого, кто желает улучшить качество кода.» Деепак Карантх «Обязательна к прочтению каждому, кто так или иначе принимает участие в работе с объектно-ориентированными языками программирования.» Дэниель Рид 14 упоминаний: Мифический человеко-месяц, или Как создаются программные системы «Это классика, но недавно исправленная и дополненная. В высшей степени поразительно то, как она тесно связана с разработкой программного обеспечения. Если вы принимаете участие в программировании, определенно эта книга – обязательна к прочтению.» Джейсон Роел «Бесспорно, единственная классика, посвященная программированию. Позор всякому, кто еще не прочитал ее.» Джеффри Атвуд 15. упоминаний: Прагматичный программист: От новичка к мастеру «Насколько революционна эта книга? Пожалуй, достаточно для того, чтобы развернуть целую издательскую кампанию. Если вы все еще не прочитали ее – это, бесспорно, большое упущение с вашей стороны.» Род Хилтон «Эта книга не только изменит ваш код: она изменит вас как программиста. Наполненная практическими советами по улучшению вас и вашего кода, бесспорно, является отличным приобретением для каждого, кто хочет стать лучшим в сфере разработки программного обеспечения.» Деепак Карант 16 упоминаний: Идеальный код: Практическое пособие по программной архитектуре «Сделайте для себя приятное. Пусть это будет первой книгой, которую вы прочитаете – и первой книгой, которую вы посоветуете другим.» Джеффри Атвуд «Эта книга потрясла меня больше всего. Определенно, после ее прочтения то, как я писал код, и то, что я думал о программировании в целом, претерпело серьезные изменения.» Джон Сонмец   Полный список содержит в себе 139 книг. При желании на языке оригинала его можно рассмотреть здесь. Автор перевода: Евгений Лукашук Оригинал статьи

Мой первый опыт переноса .NET приложения под .NET Core Совсем недавно я портировал .NET 4.5.2 – приложение под .NET Core 2.0. Хочу сразу отметить, что эта статья не является гайдом, и тем более это не перечень того, что может во время процесса пойти «не так». Однако она призвана дать общее понятие операции, мои впечатления от перехода на Core – стандарт и вообще, а стоит ли это делать. Приложение Приложение, которое я портировал, импортирует и обрабатывает информацию от ресурса SurveyMonkey. Проект DataPersistence – это уровень для взаимодействия с базой данных, в моем случае – через Entity Framework 6.2. Логика взаимодействия с SurveyMonkeys и преобразования данных так же, как и различные администрирующие функции, помещены в библиотеке ImporterCore. Importer – это небольшое консольное приложение, которое инкапсулирует определенную функциональность из ImporterCore, позволяя запустить ее в качестве запланированной Windows-задачи. Проект Explorer является веб-приложением ASP.NET MVC 5 для анализа информации. Проект Tests (на диаграмме не представлен) построен с использованием nUnit3 и обновляет все проекты к 5 версии. Кратко о процессе Сам порт занял у меня около двух дней. В конце концов картинка была следующая: Более 80 процентов усилий были затрачены на чтение блогов, логов ошибок и, конечно же, употребление кофе. Но только после всего этого я смог собой гордиться. Впрочем, если бы мне пришлось повторить порт снова, сейчас бы он занял у меня всего лишь одну четвертую от того времени, которое я потратил. Итак, касательно порта я могу сказать следующее: Просто погуглите готовые решения и применяйте их до тех пор, пока все это дело не заработает снова. Для всех компонентов, кроме, собственно говоря, самого веб-проекта, обновите csproj-файлы к более новому и упрощенному VS15-формату, который все еще поддерживает версию .NET 4.5.2. Я подумал, что лучше сделать это вручную, чем пересоздавать проекты с нуля. Выгрузите все проекты из решения отдельно от DataPersistance, которая была в основании пирамиды приложения. Соберите для .NET Core – стандарта. Обновите все пакеты библиотеки DataPersistence к последним версиям, поддерживаемым .NET Core. В некоторых исключительных случаях (наподобие работы с Entity Framework) полностью замените пакеты программ на .NET Core – аналоги (в нашем случае это будет Entity Framework Core). Просмотрите все провальные билды и исправляйте все изменения api до тех пор, пока проект не скомпилировался. Повторите шаги 2-4, добавляя дополнительные пакеты к приложению (по одному за раз). Чтобы заставить заработать веб-проект после порта, мне пришлось бы столько всего фиксить и исправлять, что я просто предпочел создать новый пустой проект и просто скопировал папку контроллеров, моделей и представлений + различные статические файлы в виде JavaScript и CSS. Перенос сайта на новый проект вместо исправления старого было определенно правильным решением. Запустите тесты. Запомните, что «построение того же самого, что и раньше» - это не то же, что «делать то же самое, что и раньше». Исправьте баги шага 7. Проведите мануальные тесты. Упущения К сожалению, далеко не все прошло так гладко, как хотелось бы. В основном замеченные ошибки были связаны с не совсем правильным выполнением шагов 7 и 8. Несовместимые библиотеки Дело в том, что ImporterCore зависела от библиотеки, которую я написал несколько лет назад и которая не поддерживает стандарт .NET Core. Она использует WebClient, который не существует в рамках .NET Core 1.0 / 1.1. К счастью, уже в версии 2.0 появилась поддержка WebClient, что значительно упростило обновление системы – нужно всего лишь внести некоторые изменения в csproj, AssemblyInfo и nuspec – файлы. Однако в случае, если вы все же сильно зависите от неподдерживаемых библиотек, порт приложения будет невозможен. Entity Framework Эта вещь заняла больше всего времени. Дело в том, что Entity Framework 6.2 в .NET Core не поддерживался, а его аналог – Entity Framework Core – значительно различается, что делает процесс порта достаточно трудоемким. А именно: Маппинг В конце концов EF Core мне понравился больше, чем EF 6.2. Здесь я привожу пример оригинального файла маппинга для оригинального объекта – Survey. Здесь Entity Framework получает информацию об именах колонок для всех свойств, названия таблицы, ключевом свойстве. В EF Core при преобразовании свойства производится маппинг к соответствующей колонке (разве что вы не укажете другую логику маппинга). Также считается, что если в вашем классе вашей сущности есть свойство Id или SurveyId, это будет считаться свойством-ключом (опять же, если вы не укажете обратное). Так что мне удалось избежать написания около 1000 строк лишнего кода, что достаточно круто.   Большинство из оставшихся нюансов маппинга могут быть настроены через аннотации, композитные ключи и так далее.   Изменения в API Здесь также есть целая серия замечательных изменений. К примеру, для конфигурирования «иностранных» ключей мы писали следующий код: Однако в EF Core метод HasRequired() заменился на HasOne(). Также раньше для тестов приходилось использовать context.Database.Create() и context.Database.Delete(), которые в EF Core были заменены на context.Database.EnsureCreated() и context.Database.EnsureDeleted().   Наложение Немного больше усилий пришлось приложить, чтобы настроить кастомную работу со значениями типа DateTime. Приложение всегда сохраняет значения типа DateTime в базе как Utc, но когда EF читает это, указанный тип не распознается, таким образом он маркируется как DateTimeKind.Unspecified, что в последствии может приводить к нежелательным последствиям. В рамках предыдущей версии EF я использовал возможности фичи – Intersection, которая, увы, больше не доступна в полной мере в раках EF Core. Впрочем, я смог решить проблему при помощи использования инструмента EntityMaterializerSource.   Лично меня сводит с ума то, что ни одна версия Entity Framework – технологии не поддерживает в нормальном виде работу с UTC – форматом. Lazy Loading Это было наибольшее разочарование: EF Core не поддерживает Lazy Loading. Да, в грядущей версии EF 2.1 эта опция должна появиться, но на данный момент решения не существует. В свое время я написал немного горькой правды о производительности Entity Framework, потому использование возможностей Lazy Loading было бы разумным решением. Отследить правильность работы с базой во время построения приложения невозможно. К счастью, при помощи некоторых тестов мне удалось вовремя заметить, что EF Core не использовал возможности Lazy Loading, но представьте себе, что было бы, если бы я этого не заметил и выпустил приложение в продакшн. Конечно, решение использовать Eager Loading вместо Lazy Loading не стало концом света, но оно вынудило писать большее количество тестов, усложнило код (в основном из-за использования вложенных Include() и ThenInclude() - конструкций) и слегка замедлило работу. Возможно, с релизом EF Core 2.1 я все же верну все так, как было. Конфигурация В то время, как .NET Framework хранит все записи о конфигурации в виде xml в app.config / web.config – файлах, .NET Core использует appsettings.json. Лично мне это понравилось, но вместе с этим мне пришлось внести некоторые изменения. Хостинг на IIS Оригинальный веб-сайт Explorer развернут под IIS. ASP.NET Core использует Kestrel, который запускается в качестве отдельного от IIS – процесса. Вам необходимо установить .NET Core Windows Server Hosting Bundle, что позволяет Kestrel непосредственно работать с кодом, а IIS – отвечать за безопасность и некоторые задачи администрирования. Также необходимо настроить пул приложения для запуска неуправляемого кода. К несчастью, деплой подобного в продакшн – сложный и трудоемкий процесс. Пришлось ждать помощи от дружественно настроенного сисадмина. Упс. Вердикт По сути, я не встретил ничего особо страшного. Только парочку незначительных багов, каждый из которых потребовал немного времени на устранение. Для отслеживания подобных багов я советую использовать Portability Analyzer, который значительно упростит вам работу. Я портировал небольшое приложение – всего лишь 5 проектов с несколькими десятками тысяч строчек кода. Если я буду делать что-то подобное вновь, весь процесс должен занять у меня намного меньше времени, чем пара дней. А в целом перед портированием больших приложений я все же советую пока попрактиковаться на маленьких. Вообще, если говорить о целесообразности перехода на стандарт .NET Core, я был вынужден это сделать только потому, что нам предстоит взаимодействовать с другими приложениями этого же стандарта. А так, безусловно, новая технология ASP.NET Core заслуживает своего внимания. Автор перевода: Евгений Лукашук Источник