Добро пожаловать в наш небольшой сборник советов от ведущих разработчиков на платформе Node.JS! Цель сей статьи – обобщить все те знания, которые были в свое время опубликованы в различных обучающих постах или журналах. Автор статьи – Йони Голдберг, независимый разработчик и консультант Node.JS. Итак, начнем! 1) Мониторинг Что это: мониторинг – это такая интересная игра в «найти баг быстрее, чем это сделают твои пользователи». И, помимо прочего, эта игра обладает беспрецедентной важностью. Современный рынок переполнен всеми видами предложений - на любой вкус. Учитывайте: вы должны строго следовать заданной концепции, не переполняя ее различными «доп. фичами». Подберите для себя такое решение, которое удовлетворяет всем требованиям. В противном случае - провал. Разочарованные клиенты. Все просто.   2) «Умное логгирование» - Ваш друг Что это: логи, как правило, очень быстро превращаются в свалку утверждений и записей всех видов и типов. Однако при должном подходе, логи являют собой образец чистоты, легко дающие понять всю необходимую информацию, связанную с программой. Планируйте ведение логов с самого начала: как они будут собираться, храниться и анализироваться. Убедитесь, что желаемая информация (такая, как частота возникновения ошибок и прочее) в любой момент может быть легко извлечена. В противном случае: вы окончите бесконечными копаниями в нечитабельных логах и, в конце концов, потратите уйму времени на «костыли», дабы понять хоть что-то из написанного.   3) Сваливайте все возможные задачи на обратный прокси Что это: увы, но Node.JS ужасен, когда речь заходит о выполнении ресурсоемких задач на центральном процессоре (такие, как g-zip упаковка, SSL-терминация и прочее). Используйте вместо этого промежуточные middleware-сервисы, такие как nginx, HAproxy или облачные. В противном случае: Ваша невинная однопоточная операция займет процессор на длительное время. Как следствие, ваше устройство будет уделять больше времени различным промежуточным задачам, нежели непосредственно Node.JS-приложению. Не буду говорить о производительности.   4) Блокируйте зависимости Что это: код должен быть идентичен для всех сред. Однако, на удивление, можно обнаружить, что NPM творит с зависимостями что-то неимоверное – как только Вы попытаетесь установить пакет в различных средах, программа пытается использовать последнюю версию, характерную для конкретной среды, что, безусловно, вносит свои особенности. Дабы избежать этого, используйте файлы конфигурации. npmrc. Они настраивают NPM таким образом, чтобы тот сохранял текущую версию пакета, не последнюю. Как вариант Вы можете использовать “shrinkwrap”-опцию, так как NPM5 блокирует зависимости по умолчанию. В противном случае: во время тщательного теста QA пропустят версию, которая в продукции будет вести себя неожиданным для разработчика образом. Даже хуже, разные серверы одновременно в том же кластере будут исполнять разный код.   5) Выбирайте правильные инструменты: экономьте время Что это: процесс должен выполняться и перезапускаться в случае ошибок. Возможно, в обычной ситуации в качестве рестартера может сгодиться и что-то наподобие PM2, но в современном мире, где правит балом Докер и его приспешники, все подобные инструменты должны быть подобраны особенно тщательно. В противном случае: использование десятков приложений с сотнями своих инструментов в конце концов приведет к хаосу.   6) Убедитесь, что вы используете только лучшие практики отлавливания багов Что это: как правило, анализ ошибок – наиболее затратная по времени и устрашающая процедура в поддержании стабильности Node.JS-среды. В основном, причина этому – однопоточная модель приложений и отсутствие выработанной стратегии по отношению к ошибкам в многопоточной среде. Быстрых решений не существует, Вы должны в полной мере осознать и приручить это багнутое чудовище.   7) Используйте все ядра процессора Что это: в своей стандартной ипостаси приложения Node.JS используют только одно ядро процессора, в то время как остальные в задаче никакого участия не принимают. Ответственность за утилизацию всех ядер лежит только на Вас. К примеру, для небольших и средних приложений Вы можете использовать Node Cluster или PM2. Для более полновесных программ обратите внимание на репликацию процесса при помощи Docker-кластера (такие, как K8S, ECS) или деплоймент-скрипты на базе инициализации Linux (system – как вариант). В противном случае: Ваше приложение, скорее всего, будет использовать только 25 процентов доступных вычислительных ресурсов (!) или даже меньше. Заметьте, типичный сервер минимум 4-х ядерный, наивный деплой обычного NodeJS использует лишь одно (даже если Вы используете PaaS сервисы наподобие AWS beanstalk)!   8) Разумно планируйте диагностику Что это: работайте с системной информацией как с количеством используемой памяти или REPL и специальных защищенных API. Хотя полагаться на стандартные инструменты и надежней, некоторую ценную информацию и некоторые операции лучше извлекать и производить напрямую в коде. В противном случае: в один прекрасный момент Вы обнаружите, что тратите очень много информации на деплой – поставляя код в продукцию просто затем, чтобы получить некоторую информацию для диагностики.   9) Используйте APM-программы Что это: программы мониторинга вроде APM, чтобы активно оценивать кодовую базу. Посему и их действия могут выходить за рамки действий простых программ мониторинга. К примеру: некоторые APM подсвечивают проблемные транзакции, которые могут вызвать падения производительности на стороне клиента и предполагают причину подобных проблем. В противном случае: Вы можете провести тонны времени на анализ производительности и поиски проблемных мест. Вероятно, Вы так никогда и не будете уверенными, что именно замедляет работу Вашего приложения больше всего и как приложение будет вести себя в «реальном мире».   10) Завершенный код – завершенный продукт Что это: «только идеальный код может быть выпущен в продукцию». Запомните это с самого первого дня разработки. Возможно, это и звучит как что-то из репертуара законченного перфекциониста, но, поверьте, результат того стоит. В противном случае: IT-сообщество вряд ли оценит и сохранит для потомков плохо написанную систему.   11) Обращайте внимание на защиту Что это: Node.JS включает в себя некоторые уникальные защитные механизмы. Понятно и без слов, что более «защищенная» система требует больше времени на ее анализ. В противном случае: что может быть хуже, чем брешь в защите, когда продукт уже в производстве? Просто банальная проблема, которую Вы забыли исправить.   12) Отслеживайте и контролируйте память Что это: Node.JS достаточно неоднозначно работает с памятью: движок v8 обладает ограничением в виде 1.4 ГБ, и были известны случаи, когда код был излишне «памятозатратным». Потому и контроль над использованием памяти – вопрос отнюдь не тривиальный. В небольших приложениях Вы можете настраивать работу с памятью, время от времени используя команды оболочки. Однако в проектах больших масштабов позаботьтесь о выводе состояния памяти в  надежную систему мониторинга. В противном случае: вы обнаружите ежедневную «утечку» памяти в несколько сотен мегабайт, как это произошло с Walmart.   13) Разделяйте клиентскую и серверную часть Что это: для фронт-енд части используйте такие middleware компоненты, как nginx, S3, CDN и прочие. Выполнение подобных задач на Node.JS-сервере очень плохо сказывается на его производительности. Причина этому: обработка великого множества статических файлов в однопотоковой модели. В противном случае: Ваш единственный Node.JS-поток будет занят обработкой сотен html/изображений/angular/react-файлов вместо того, чтобы заняться непосредственно обработкой динамического контента. Или, другими словами, того, для чего и была разработана технология Node.JS.   14) Храните данные вне сервера Что это: сохраняйте любую информацию – будь то пользовательские сессии, кэш, загруженные файлы – на внешнем накопителе. Представляйте, как будто Ваш сервер будет регулярно «падать». Используйте «безсерверную» платформу (например, AWS Lambda). В противном случае: «падение» конкретного сервера в результате приведет не только к утилизации нерабочей машины, но и к падению производительности самого приложения. Более того, зависимость от конкретного сервера значительно уменьшит гибкость всей системы.   15) Используйте инструменты с автоопределением уязвимостей Что это: даже такие проверенные временем зависимости, как Express и другие, имеют бреши, которые время от времени могут ставить всю систему под угрозу. Однако подобное можно легко обойти, если использовать различные бесплатные или коммерческие продукты, которые постоянно проверяются на предмет уязвимостей и могут быть мгновенно исправлены в случае необходимости. В противном случае: держать код в чистоте и без уязвимостей в случае неиспользования соответствующих инструментов затребует постоянного отслеживания новостных сводок и обновлений. Немного напрягает.   16) Присваивайте каждой записи лога свой TransactionId Что это: присваивайте уникальный идентификатор каждой записи в логе. Подобный подход в значительной мере упростит работу и поиск ошибок. К сожалению, из-за асинхронной природы Node.JS реализовать подобное – задача отнюдь не тривиальная. В противном случае: Поиск производственных ошибок будет достаточно длительным. Как следствие, Вы закопаетесь в логе ко всем чертям.   17) NODE_ENV = production Что это: устанавливайте переменной окружения NODE_ENV значение production или development. Это нужно для того, чтобы указать NPM, включить ли оптимизацию или нет – так как многие подобные сервисы обладают опцией автоопределения состояния среды. В противном случае: игнорирование этого нюанса может сильно замедлить производительность. К примеру, если проигнорировать NODE_ENV, используя Express для серверного рендеринга, производительность упадет в три раза!   18) Развертывайте приложение быстро Что это: исследователи отмечают, что команды, которые проводят большее количество Node.JS-размещений, имеют меньший риск столкнуться с целым рядом проблем. Быстрые и автоматизированные размещения, не требующие рискованных ручных этапов и сервисов, в значительной мере ускоряют процесс размещения. Возможно, Вам стоит обратить свое внимание на Docker в комбинации с CI-инструментами. В противном случае: длительное размещение -> падения производительности и человеческие ошибки -> неуверенность команды -> меньшее количество размещений и, как следствие, потенциальных фич.   19) Помещайте NPM-версию в каждое размещение Что это: с каждым новым релизом указывайте в package.json-версию текущего NPM. Это внесет ясность в работе с приложением. Сей фактор важен, так как, к примеру, в среде MicroService некоторые сервисы могут обращать внимание на версию Вашего NPM. Вы можете использовать команду “npm version”, которая укажет версию автоматически. В противном случае: достаточно часто разработчики пытаются исправить баг, часто в конце обнаруживая, что они ищут его не в той версии, в которой стоило бы.   20) Следите за актуальной информацией Традиционное: отслеживайте последние обновления Node.JSб NPM и прочих технологий, с которыми Вы работаете. До новых встреч! Автор перевода: Евгений Лукашук Источник

10 отменных советов как стать лучшим Node.JS разработчиком 2018 года от автора Азата Мардана. Эта статья содержит в себе собранный и тщательно отфильтрованный опыт писателей и спикеров технологии всего Веб-сообщества. Заметка: первоначально заголовком статьи должно было быть «Лучшие практики Node.JS от Гуру Технологии». Эта статья охватывает не «новые» и «лучшие» практики 2017-2018 года, а тщательно выверенные и проверенные временем и практикой паттерны, которые стопроцентно приведут к успеху. И хотя многие из проверенных практик Вам определенно пригодятся в 2018, 2019 и даже более поздних годах, статья не включает в себя такие новшества, как async/await и прочее. Почему? Потому что эти фичи не включены в состав, собственно говоря, кода Node.JS-ядра или кода таких популярных проектов как npm, Express и прочие. Полноценно заниматься разработкой на Node.JS я начал в 2012 году, когда присоединился к Storify. С тех пор я никогда не жалел о принятом решении и не ощущал, как будто я многое потерял, закинув Python, Ruby, Java или PHP – языки, с которыми я работал на протяжении предыдущего десятилетия. Работа в компании Storify для мня оказалась достаточно интенсивной. В отличии от большинства компаний, все приложения Storify работают исключительно на JavaScript. Как вы понимаете, большинство компаний, особенно такие крупные как PayPal, Walmart или Capital One, используют Node.JS только для конкретных определенных задач. Как правило, это gateway API. Однако, с точки зрения программиста, ничего не может быть лучше, чем работа и погружение с головой в одну определенную технологию. Краткая сводка: Избегайте нагромождения – пытайтесь разбивать свой код на столько мелких составных частей, насколько это вообще возможно. И даже больше. Используйте асинхронный подход – избегайте синхронное программирование словно чумы. Избегайте блокировки потоков – помещайте ВСЕ требуемые утверждения в начало файла, ибо они синхронные и, следовательно, будут блокировать программу. Require должен быть закеширован – считайте, это такая фича в Вашем коде. Или баг. Как Вам угодно. Всегда проверяйте свой код – ошибки – это не вышивание, которое можно выбросить в любом момент. Никогда не упускайте обнаруженные ошибки! Используйте try…catch только в синхронном потоке – try…catch бесполезен в асинхронном коде. Кроме того, v8 никогда не оптимизирует try…catch-код. Возвращайте значения или используйте if…else – просто на всякий случай: возвращайте значения что бы остановить выполнение участка кода. Обращайте внимание на события ошибок – почти все Node.JS-классы или объекты реализуют паттерн-наблюдатель и производят события-ошибки. Не стоит пропускать их. Познайте свой npm – устанавливайте модули с ключами –S или –D вместо –save или –save-dev. Используйте текущие версии в package.json – при работе с npm он по-тупому просто добавляет верхнюю скобочку по умолчанию при использовании вместе с ключом –S. Дабы избежать этого, просто вручную блокируйте версии. Никогда не доверяйте semver в своих приложениях, но доверьтесь ему в модулях с открытым исходным кодом. Бонус – используйте разные зависимости. Помещайте то, что требует проект только в процессе разработки в devDependencies. После этого используйте npm i –production. Чем больше ненужных зависимостей используется, тем больше риск возникновения уязвимостей.   Давайте разберем некоторые из этих пунктов поподробнее: Избегайте нагромождения Взгляните на некоторые модули, написанные Исааком З. Шлейтером, создателем npm. К примеру, use-strict включает «строгий» режим написания JavaScript-модульного кода. Включается эта опция всего лишь в три строчки: Но почему-же все-таки стоит избегать нагромождения кода? Одна известная фраза американского воздушного флота гласит: «все должно быть просто до идиотизма». И на это существуют свои причины. Человеческий разум не может держать в памяти больше чем от 5 до 7 вещей одновременно. Это просто как факт. Разбивая код на небольшие составные части, Вы и другие разработчики легко сможете разобраться в нем и понять, для чего он предназначен. Так же упрощается процесс тестирования. Вот пример:   Или еще: Уверен, большинство из Вас отдадут предпочтение второму примеру, когда имена переменных сразу же делают понятной их суть. Конечно, в процессе написания кода Вы можете думать, что Вы понимаете, как он работает и так. Возможно, Вам даже захочется продемонстрировать свою смекалку и сообразительность, объединив несколько методов вместе в одну строку. Пожалуйста, пишите так, как если бы Вы были более неопытны. Как если бы Вы не смотрели в код на протяжении 6 месяцев, или очень устали и, кроме того, еще и выпили. Если Вы пишете код на пике своей ментальной активности, Вам будет труднее понимать его позже, не говоря уже о Ваших коллегах, которые даже не знакомы с ходом Ваших мыслей. Держать все в относительной простоте единственно верный метод – особенно в рамках Node.JS-технологии, где используется асинхронный подход. Другими словами, преимущества от использования подхода малых частей значительно более перевешивают недостатки. Помимо прочего, они позволяют значительно быстрее исправить различные ошибки, которые могут возникнуть по разным причинам в процессе работы с Node.JS-приложением.   Используйте асинхронный подход Синхронный код мало где используется в нынешнем Node.JS. Как правило, он находит свое применение в написании CLI-команд или скриптов, не связанных с веб-приложениями. Что же касательно веб-разработки, Node.JS программисты предпочитают использовать асинхронный подход, так как это позволяет избежать блокировки потоков. К примеру, синхронный код будет приемлем, если мы строит скрипт для работы с базой данных, не системы для обработки параллельных/конкурентных задач: Но, в случае веб-приложения, лучше использовать следующее: Отличительная особенность состоит в том, пишите ли вы долго исполняемый конкурентный код или небольшой скрипт с малым временем жизни. А вообще, лучше запомните одно хорошее правило: всегда пишите асинхронный код в Node.JS.   Избегайте блокировки require S обладает простой системой загрузки модулей, которая использует общий формат CommonJS. Самый простой способ подключить модули, разбросанные по отдельным файлам – использовать встроенную функцию require. В отличии о AMD/requirejs, Node/CommonJS синхронна. По сути, функция работает согласно следующему принципу: Вы импортируете то, что было экспортировано в виде модуля или файла. О чем большинство разработчиков даже не догадывается, так это о том, что require кэшируемая. Потому, до тех пор, пока нет заметных изменений зарезервированного имени файла (и, в случае использования npm-модулей, их нет), код модуля будет выполнен и подгружен в переменную только единожды (для обработки). Подобная методика позитивно сказывается на оптимизации. Однако, даже с кэширование, лучше сначала попробуйте обойтись без require. Попробуйте использовать axios-модули. Путь /connect в свою очередь будет медленнее чем требуется, ибо импорт модулей происходит после генерации запроса: Гораздо лучше будет загрузить модули тогда, когда сервер еще даже не определен, не в маршруте: Require должен быть закэширован Хотя я и упоминал о том, что require может быть закэширован, но что так же интересно, так это то, что мы можем поместить код вне module.exports. К примеру: Зная, что некоторые участки кода могут быть запущены только один раз, подобная реализация окажется более чем полезной.   Всегда проверяйте свой код Node.JS – это Вам не Java. В Java Вы выкидываете исключения потому как в большинстве случаев Ваше Java-приложение не должно продолжать работать в случае ошибки. В Java для этого Вы просто используете try…catch. В случае Node.JS история обстоит несколько по-иному. Так как технология выполняется в асинхронном режиме, контекст ошибки всегда будет отделен от любого перехватчика (такого как try…catch) в случае возникновения самой ошибки. Этот код в Node.JS будет просто-напросто бесполезен: Но! Привычный try…catch все еще может быть использован в синхронном режиме. Вот более действенный рефакторинг предыдущего участка кода: Если мы не можем обернуть request-вызов в блок try…catch, ошибка будет не перехвачена. Однако, это легко решается при помощи callback-аргумента error. Кроме того, Вам нужно всегда вручную отлавливать error в каждом и каждом callback`е. Проверяйте наличие ошибки (и убедитесь, что она не равна null) и затем, или демонстрируйте содержание ошибки пользователю или клиенту и потому логируйте ее, или отправляйте ее обратно в место вызова при помощи error-callback`а. В качестве небольшого фокуса Вы можете использовать библиотеку okay. Применяйте ее как наведено ниже что бы обойти ручной проверки на ошибки: Возвращайте значения или используйте if…else .JS – параллельный. Эта особенность может привести к багам, если не отнестись к ней с должной осторожностью. Что бы обезопасить себя, останавливайте выполнение участка кода при помощи ключевого слова return: Избегайте бессмысленной работы (и ошибок) из-за неостановленного вовремя исполнения: Просто убедитесь, что return всегда будет стоять на страже целесообразности работы Вашего кода.   Обращайте внимание на события ошибок Почти все классы/объекты Node.JS реализую паттерн-наблюдатель, который порождает событие-ошибку. Это прекрасная возможность для разработчика отловить особо подлые ошибки и придушить их до того, как они устроят хаос. В качестве полезной привычки было бы неплохо создавать программы-прослушиватели событий-ошибок при помощи использования .on(): Познайте свой npm Многие Node.JS и front-end событийные разработчики знают, что –save (для npm install) не только установит модуль, но так же и создаст запись в package.json с упоминанием текущей версии модуля. Для аналогичных целей существует и –save-dev, опция для модулей, которые нужны только во время разработки. Но знаете ли Вы, что вместо этого можно спокойно использовать –S и –D? Теперь да. И пока Вы в режиме установки модулей, удаляйте символ ^, который будут порождать команды –S и –D. Эти значки могут быть особенно опасными, так как они позволят npm автоматически обновить модуль к последней незначительной версии (вторая цифра в семантике версирования). К примеру, с версии 6.1.0 до версии 6.2.0. Команда NPM полагается на semver, но Вы не должны. Я хочу сказать, что они используют авто обновления к промежуточным версиям модулей с открытым исходным кодом, так как они полагают, что никаких радикальных изменений в этих самых промежуточных версиях не будет. Мой вам совет: не стоит слишком в это верить. Более того, используйте npm shrinkwrap. Команда создаст новый файл с текущими версиями зависимостей зависимостей. И в заключение В этом посте мы охватили много всего: от работы с callback'ами до работы с асинхронными потоками, проверки на ошибки и снятия блокировки зависимостей. Надеюсь, Вы нашли для себя что-то новое и познавательное здесь. Немного об авторе Азат является техническим консультантом и менеджером в Capital One. JavaScript/Node.js-эксперт, автор различных онлайн-курсов. Издатель более чем 12 книг, посвященных теме, включающие такие хиты продаж как Full Stack JavaScript, React Quickly, Practical Node.JS и Pro Express.js и другие. В свое свободное время Азат читает о технике на Webapplog.com, проводит конференции и работает над продуктами с открытым исходным кодом. До того, как стать экспертом Node.JS, работал в федеральных правительственных агентствах США, принимал участие в небольших старт-апах и больших корпорациях, имея дело с такими технологиями, как Java, SQL, PHP, Ruby и прочие. Азат обожает все, что связано с технологиями и финансами, так же увлекается инновационными способами обучения и просвещения людей. Автор перевода: Евгений Лукашук Источник

Так как 2017 год совсем недавно остался позади, наша команда решила сделать небольшой новогодний подарок в виде разбора лучших сред автоматического тестирования, обладающих, помимо прочего, открытым исходным кодом. 1. Robot Framework Robot Framework – это фреймворк для приемного тестирования (Acceptance Testing) и, помимо прочего, так называемого ATDD (Acceptance Test-Driven Development). Среда написана на языке Python, но также может быть развернута в рамках Jython (Java) и IronPython (.NET). По сей причине считается кроссплатформенной, ибо поддерживает Windows, Linux и MacOS соответственно. Достоинства: Упрощает автоматическое тестирование благодаря использованию подхода keyword-driven тестирования, в значительной мере помогая тестерам в создании читабельных, легко производимых тестов.  Простота в использовании «тестового синтаксиса». Имеет в наличии отменную среду, включающую в себя богатый набор различных инструментов и библиотек, выполненных в виде отдельных проектов. Огромное количество различных API делает систему очень гибкой. Хотя и не в виде встроенной функции, однако Robot Framework позволяет проводить параллельные тесты при использовании библиотеки pabot или Selenium Grid. Недостатки: Трудно настроить структуру html-отчетов. Примечание: эта среда будет очень полезной, если Вы нацеливаетесь на Keyword-Driven тестирование – и обширная база библиотек и расширений вряд ли заставит Вас в этом усомниться. Однако, чтобы добавить новые ключевые слова (RF test library API) базовые познания Java/Python/C программирования обязательны. 2. JUnit JUnit – это среда для проведения юнит-тестов для приложений, написанных на языке Java. Достоинства: Тесты пишутся при помощи чистейшего Java – одного из лидирующих языков программирования современности. Поддерживает TTD. Позволяет создать свой собственный пакет для юнит-тестирования. Прекрасно интегрируется в различные инструменты разработчика (к примеру – Maven) или среды разработки (к примеру, IntelliJ). Благодаря достаточно высокой популярности поиск документации не составляет труда. Недостатки: Если необходимо использовать возможности mock-объектов, пользователь вынужден прибегать к помощи сторонних библиотек (Mockito или другие). Чтение тестов у людей без технического образования может вызвать затруднения, так как, к примеру, имена методов в JUnit ограничены условностями языка Java. Примечание: для тех разработчиков, которые желают писать юнит-тесты для собственных Java-приложений JUnit, пожалуй, лучшее из того, что можно бы пожелать. Однако, в случае если речь идет о функциональном тестировании программ, написанных на других языках, вероятно, Вам стоит выбрать другую среду. 3. Spock Spock – это среда тестирования и спецификации для приложений, написанных на языках Java или Groovy. За основу взята среда JUnit. Достоинства: Позволяет создавать читабельные тесты с поддержкой чисто английских предложений, без необходимости следовать ограничениям языков программирования. Предоставляет информативный контекст возникнувшей проблемы. Плюс, дает легко понять, что необходимо сделать, дабы исправить обнаруженный недостаток. Имеет встроенную поддержку mock и stab объектов. Поддерживает DDT (Data-Driven Tests). Недостатки: Требует базовых знаний языка программирования Groovy. Примечание: идеально подойдет, если Ваше приложение базируется на JVM, плюс, Вы нацеливаетесь на BDD автоматическое тестирование с DSL. 4. NUnit NUnit – среда для юнит-тестирования языков .NET виртуальной машины. Имевшей однажды огромное влияние JUnit, среда NUnit была полностью написана на C#. Помимо прочего, в арсенале так же имеется целый спектр новых возможностей, позволяющих использовать все преимущества языков .NET. Достоинства: Быстрая инициализация и выполнение теста. Использует методы типа Assert с поддержкой аннотаций. Позволяет проводить параллельное тестирование. Поддерживает TDD. Недостатки: Так как использует только языки .NET стандарта, не является кроссплатформенным. Интеграция в среду Visual Studio не представляется возможной. Использование NUnit означает больше расходов на сопровождение проекта. Примечание: прекрасный фреймворк юнит-тестирования для C# с открытым исходным кодом, долгой историей и проверенной репутацией. Однако, в случае, если вы уже активно работаете с .NET языками, обратите свое внимание на MSTest. 5. TestNG TestNG – сервис автоматического тестирования для Java. По сути, это те же JUnit и NUnit, но с улучшениями и новым функционалом (ибо NG читается как «новое поколение» - Next Generation). Среда была разработка для покрытия всех видов тестирования, которые только могут понадобится. А именно: юнит-тестирование, функциональное тестирование, тестирование интеграции и прочее. Достоинства: Прост во внедрении в проект. Позволяет разработчику писать гибкие и всеобъемлющие тесты. Поддерживает DDT. Простые в понимании аннотации. Простота в группировании тестовых кейсов. Позволяет создавать параллельные тесты. Недостатки: Так как поддерживает только Java, Вы должны иметь хотя бы базовые познания этого языка. Установка и калибровка среды тестирования занимает время. Примечание: если вы работаете с Java, ищите инструмент для мульти задачного тестирования и можете уделить некоторое время на установку программы – TestNG определенно для Вас. 6. Jasmine Jasmine – среда для юнит-тестирования JavaScript. Так же известен как Behavior Driven Development (BDD) подход JavaScript тестирования. Идеально подходит для веб-сайтов, проектов Node.js и вообще для всего, где JavaScript может найти свое применение. В основном используется в связке с AngularJS. Достоинства: Кроме JavaScript, так же может быть применен по отношению к Python или Ruby. Чрезвычайно полезен, если Вам нужен один сервис тестирования как для клиентской разработки, так и для серверной. Поддерживается множеством CI (Codeship, Travic и прочее). Имеет встроенный Assert-синтаксис. Недостатки: В большинстве сценариях требует прогонщика тестов (такого как Karma). В случае с асинхронным тестированием возникают трудности. Примечание: Jasmine может оказаться прекрасным решением, если Вы нуждаетесь в унифицированном (клиент-серверном) сервисе юнит-тестирования. 7. Mocha Mocha – это еще один сервис JavaScript юнит-тестирования с занятным для русскоязычного сектора названием и отнюдь не банальным функционалом. Используется на NodeJs, в основном часто применяется в связке с ReactJS. Достоинства: Обладает встроенным тестовым прогонщиком. Поддерживает асинхронное тестирование. Позволяет большую гибкость, так как Вы спокойно можете использовать любую Assert-библиотеку (Chai, expect.js, Must.js прочие), которая будет отвечать Вашим требованиям (как замена стандартной NodeJs функции «assert»). Недостатки: Относительно новый сервис (появился в 2012 году), что означает он в активном развитии и некоторые аспекты технологии могут быть не до конца задокументированными. Предоставляет только базовую структуру тестов, плюс требует дополнительную ручную установку и конфигурацию (для кого-то может быть плюсом). Примечание: если Вы ищите независимую среду юнит-тестирования для JavaScript, Mocha – Ваше все! А какую среду автоматического тестирования используете Вы? Что хорошего и что не очень Вы могли бы о ней сказать? Пожалуйста, приобщайтесь к дискуссии в комментариях! 😊 Автор перевода: Евгений Лукашук Оригинал статьи

Все мы знаем простую формулу: быстрый сайт = счастливые пользователи, высокая оценка Google-статистики и увеличение количества переходов. Возможно, Вам и кажется, что Ваш сайт работает настолько быстро, насколько ему позволяет быть быстрым WordPress – Вы же видели те списки лучших практик настройки сервера, улучшения производительности кода и так далее – но всё же, разве это предел? Используя динамические базы данных сервисов типа WordPress, в конечном итоге перед Вами предстанет проблема: запросы к базе замедляют работу сайта. В рамках этого поста я постараюсь научить Вас определять проблемные места, понимать их причину и предложу некоторые быстрые решения и другие программные подходы для ускорения работы. В качестве примера мы будем использовать действующие примеры работы с базой, замеченные на одном из сайтов.   Идентификация Первый шаг на пути повышения производительности - это обнаружение проблемных SQL-запросов. И на сцену выходит Query Monitor – по-настоящему незаменимый плагин для мониторинга работы запросов. Особенность его в том, что плагин показывает детальную информацию о каждом запросе, позволяя к тому же отфильтровать их, исходя из порождающего участка кода (включается подсветка дублированных запросов). Если же по какой-то причине Вы не желаете устанавливать отладочный плагин, вы можете в качестве опции включить MySQL Slow Query Log, логирующий все запросы, требующее длительное время для выполнения. К тому же конфигурация и настройка места логирования относительно проста. Так как это серверное дополнение, падение производительности будет заметно в меньшей мере, чем если бы вместе с отладочным плагином непосредственно на сайте. Однако по мере отсутствия необходимости, MySQL Slow Query Log стоит отключать.   Понимание Как только вы находите затратный по времени запрос, который было бы неплохо улучшить, встает следующий вопрос: почему он работает медленно? К примеру, во время разработки одного сайта был обнаружен запрос, работающий целых 8 секунд! Для поддержки магазина плагинов мы использовали WooCommerce и кастомизированную версию WooCommerce Software Subscriptions плагина. Задача приведенного выше запроса была получить все подписки пользователя, оперируя его идентификационным номером. WooCommerce обладает своеобразной комплексной моделью данных, при использовании которой наблюдалось следующее: хотя  запрос и хранится как пользовательские пост-типы, идентификатор пользователя хранится в пост-мета данных, а не в post_author, как должно было бы быть. Также было найдено несколько связок с пользовательскими таблицами, созданными плагином. Итак, как же нам уберечь себя от подобных ошибок?   MySQL – Ваш друг MySQL обладает весьма полезным выражением DESCRIBE, которое используется для вывода информации о структуре таблицы (такой, как столбцы, типы данных, дефолты). К примеру, если Вы выполните команду DESCRIBE wp_postmeta, Вы увидите следующий результат: Это, конечно, хорошо, но, возможно, Вы уже знали об этом. Но знали ли Вы, что DESCRIBE также может быть использован в качестве префикса для SELECT, INSERT, UPDATE, REPLACE и DELETE? Широкой общественности это так же известно, как синоним EXPLAIN, который дает нам детальную информацию, как именно та или иная команда будет выполнена. Вот результат для нашего проблемного запроса: На первый взгляд, понять это не слишком-то просто. Однако при более детальной расшифровке задача упрощается. Наиболее важной колонкой считается type, так как она описывает связь между таблицами. Если вы замечаете слово ALL, это значит, что MySQL читает всю таблицу с диска, нагружая центральный процессор. Сие также известно под термином «полное сканирование таблицы» - позже мы вернемся к этому. Колонка row также хороший индикатор того, что нужно, собственно говоря, MySQL сделать. Эта колонка наглядно демонстрирует, сколько рядов было прочитано, дабы найти результат. Ключевое слово EXPLAIN также дает более полную информацию, полезную для дальнейшей оптимизации запросов. К примеру, таблица pm2 (wp_postmeta) говорит нам о том, что мы используем Using filesort, так как нам нужно отсортировать результаты по возрастанию (ORDER BY).   Визуальное изучение Здесь стоит упомянуть о таком полезном инструменте, как MySQL Workbench. Так как для баз данных, работающих на версии MySQL 5.6 и выше, результаты EXPLAIN формируются в виде JSON, MySQL Workbench конвертирует JSON в визуальное представление. Утилита автоматически обращает Ваше внимание на проблемные запросы. На картинке мы ясно можем видеть, что wp_woocommerce_software_licences вызывает негодование.   Решение Упомянутая часть запроса проводит полное сканирование таблицы, чего Вам, собственно говоря, по мере возможности стоит избегать. К тому же тут используется неиндексированная колонка order_id в качестве ссылки между таблицами wp_woocommerce_software_licences и wp_posts. Подобная ситуация – общая причина большинства «медленных» запросов. Которая, однако, решается просто.   Индексы Order-id - достаточно важная часть идентификационной информации. Потому, если мы строим запрос подобным образом, мы должны иметь при себе индекс колонки. В противном случае MySQL в буквальном смысле просканирует ВСЕ рядки таблицы, пока не найдет нужный. Давайте добавим индекс и проверим, что из этого получится:   Невероятно, но нам удалось урезать порядка 5 секунд выполнения запроса!   Знайте свой запрос Проверяйте запрос – команда за командой, подзапрос за подзапросом. Не делает ли он того, чего нам не нужно? Можем ли мы что-то оптимизировать? В этом случае, ограничивая пост-типы shop_order, мы связываем таблицы лицензий с таблицами постов при помощи order_id. Повышая интеграцию данных, подобным образом мы убеждаемся, что используются только корректные порядки записей. Однако на самом деле это только внешняя часть запроса. Довольно опасно иметь строку software license в таблице, владеющей связанным с порядком WooCommerce order_id в пост-таблицах. Причина этому – связка с PHP-кодом плагина. Давайте удалим зависимость и посмотрим на результат: Конечно, это не очень много, но теперь запрос работает до 3 секунд вместо 8!   Кэшируйте все, что только можно! Если на Вашем сервере не установлен MySQL query caching, тогда пора установить его. Это позволит MySQL вести запись всех исполняемых команд – совместно с их результатом. Кэш же, в свою очередь, не «устаревает», так как MySQL обновляет кэш при изменении таблиц. Query Monitor обнаруживает, что наш запрос запускается 4 раза на одной странице. И, хотя query caching – полезная штука, дублирующие запросы должны быть удалены. Статическое кэширование в PHP – это достаточно простое и эффективное решение проблемы. По сути, Вы просто перехватываете результат чтения из базы и заносите его в статическое свойство класса. Когда будет вызван определенный подзапрос, вы просто используете уже загруженную информацию из статического свойства: Кэш имеет такое понятие, как время жизни запроса. Если же Вам необходимо иметь постоянную информацию из кэша, тогда, возможно, Вам стоит воспользоваться постоянным Object Cache`ом. Однако в этом случае Ваш код должен сам описывать работу с кэшем.   Отказывайтесь от шаблонного мышления! Помимо этих, существует великое множество других техник по улучшению производительности запросов, которые потребуют операции посложнее, чем просто правка запроса или дописывание индекса. Одна из наиболее медленных операций нашего запроса – это необходимость связывать покупателя с таблицей товаров, причем для каждого покупателя. А что, если просто один раз связать все, что нам нужно, и не заморачиваться этим в дальнейшем, просто загружая из таблицы всю информацию, связанную с покупателем? Мы можем создать таблицу, которая будет содержать в себе информацию о лицензии, вместе с идентификаторами пользователей и товаров для всех лицензий. При необходимости нам нужно будет только дать запрос для одного пользователя. Для этого Вам предстоит пересобрать таблицу при помощи MySQL triggers на базе INSERT/UPDATE/DELETE. Однако подобная операция заметно увеличит производительность системы в целом. Подобным образом, в случае если количество связей замедляет выполнение запросов, возможно, Вам стоит разбить запрос в два или больше предложений и исполнять их раздельно при помощи PHP. После чего просто собрать и отфильтровать полученную информацию внутри кода. Что-то подобное реализовано в Laravel при помощи eager loading в Eloquent. WordPress иногда может замедлять запросы на wp_posts таблице, в случае если у Вас хранится много информации и разных пользовательских пост-типов. Если Вы считаете, что пост-типы замедляют запросы, возможно, Вам стоит задуматься об использовании кастомных таблиц.   Подведем итоги При помощи подобных нехитрых приемов оптимизации запросов нам удалось снизить время работы запроса с 8 до примерно 2 секунд. К тому же было снижено количество вызовов запрос с 4 до 1. Искренне надеемся, что сей гайд будет полезным для работы с запросами. Внешне оптимизация может казаться чем-то устрашающим, но как только Вы попробуете это сделать, Ваши маленькие победы развеют подобные суждения. Автор перевода: Евгений Лукашук Источник

Я работал с .NET Core около года и сейчас могу сказать, что был очень впечатлен. Поскольку наша компания создает приложения для разработчиков, которые базируются на .NET Core, я ощущаю нас причастными к тому, что сейчас происходит. Каждый день мы общаемся с клиентами, которые уже используют .NET Core в своих разработках. .NET Core быстро завоевывает популярность, и я уже предсказываю огромную потребность в разработчиках на C# и .NET Core в 2018 году. Согласно индексу программирования TIOBE, C# уже входит в пятерку наиболее популярных языков программирования. 6 вещей, которые стоит знать о C# и .NET Core Узнайте, почему .NET Core возводит C# в топ списка наиболее популярных языков программирования. 1) Простота в изучении Если вы уже работали с С, Java или даже JavaScript, синтаксис C# покажется Вам довольно знакомым. Сам синтаксис достаточно прост в понимании и чтении. Исходя из индекса TIOBE, приведенного выше, уже сейчас большинство разработчиков могут легко перейти с Java или C. В сети существует много онлайн-ресурсов для изучения C#. Большинство из них – бесплатные, другие же можно использовать за умеренную плату. Pluralsight – Отличный обучающий контент за доступную цену Microsoft Virtual Academy – Бесплатные видео и оценивание Microsoft Getting Started with C# - Бесплатные интерактивные туториалы 2) Современные возможности языка .NET существует на протяжении длительного времени и за последние 15 лет достаточно сильно преобразился и улучшился. На протяжении лет я отмечал такие прекрасные нововведения как MVC, обобщения, LINQ, async/await операторы и многое другое. Как человеку, который лично посвятил себя изучению языка, я рад наблюдать, как он модернизируется. Многое претерпело изменения с появлением .NET Core. Взять тому примером стек технологий ASP.NET. Все эти 15 лет язык C# был с нами, и он продолжает совершенствоваться. Вот некоторые наиболее примечательные особенности: Строгая типизация Качественные библиотеки классов Асинхронное программирование – шаблон async/await Сборка мусора, автоматическое управление памятью LINQ – интегрированный язык запросов Обобщения – примером List<T>, Dictionary<T, T> Управление пакетами Общие бинарные файлы для разных платформ и фреймворков Простота в использовании фреймворков для создания MVC веб-приложений и REST API. 3) Универсальность: веб, мобильные, серверные, настольные приложения Одним из наиболее значимых плюсов C# в частности и .NET в целом, я считаю, является его многогранность. Я могу писать программы для ПК, вести веб-разработку, создавать фоновые сервисы или даже мобильные приложения (спасибо Xamarin!). Кроме того, все, что мне нужно знать, дабы скомпоновать все UI-коды вместе (чего я все же стараюсь избегать), это, кроме C#, всего лишь немного JavaScript’а (+ TypeScript). Шаблоны ASP.NET Core в свою очередь при создании клиентских библиотек даже используют макеты Бутстрапа и npm. Универсальность языка - довольно весомый плюс, так как ваш вклад в его изучение может найти применение в широком спектре возможностей. Ваши навыки очень мультиплатформенные. Если пожелаете, Вы можете легко «перескочить» с разработки веб-приложений на мобильные. Пожалуй, это уникальное отличие от других языков, заточенных только под серверную часть. Не стоит забывать о первоклассной поддержке Microsoft Azure. Нужно задеплоить проект на облако? Нет ничего проще: сия операция осуществляется всего лишь в пару кликов. Поддержка Docker-контейнеров также присутствует, что значительно упрощает деплой приложений на AWS или другие хостинги на Ваше усмотрение. 4) Качественные инструменты разработчика Visual Studio всегда считалась одной из лучших сред разработки. Это прекрасный редактор кода, поддерживающий такие фичи, как компиляцию, отладку, профилирование, git-репозиторий, юнит-тестирование и многое другое. Плюс, за вами всегда остается возможность писать коды для .NET Core в любом текстовом редакторе в виде обычных текстовых файлов. Вы также можете использовать Visual Studio Code на любой ОС в качестве отличного редактора кода. Даже те из нас, кто никогда не желает расставаться с этим Vim или Emacs, могут вести разработку на C#. Можно также установить плагины для Visual Studio и добавлять свои «горячие клавиши». Вся экосистема .NET изобилует прекрасными инструментами. К примеру, вряд ли я смогу представить жизнь без Resharper`а или JetBrains. Существуют десятки классных инструментов, включая смеси открытого кода и коммерческих продуктов. 5) Обобщение навыков .NET обладает очень хорошим набором базовых библиотек. В отличие от Node.js, такие простые строковые функции, как LeftPad(), уже встроены. Подобное разнообразие стандартных библиотек значительно уменьшает потребность в сторонних пакетах. Также благодаря вмешательству Microsoft, мы можем использовать такие технологии, как JSON.NET и прочее. Microsoft обеспечивает качественный набор шаблонов и их реализаций на .NET. К примеру, сервис для работы с данными (Entity Framework) и MVC уже встроены. Большинство разработчиков именно ими и пользуется. Подобный подход значительно упрощает взаимодействие между командами и ускоряет понимание, как проект работает. Благодаря этому, Ваши знания и навыки становятся более универсальными. 6) Код .NET Core в свободном доступе Одним из наиболее значимых событий, которое когда-либо происходило на .NET, является публикация исходного кода. Теперь каждый на GitHub’е может просматривать, вносить правки и дополнять его. Пожалуй, большинство людей даже никогда не думали о том, что подобное может когда-либо произойти. Как разработчику, время от времени Вам необходимо «заглядывать за ширму», дабы понимать, как на самом деле работает код. К примеру, раньше я мог только гадать, закрывает ли вызов метода Dispose() на базе данных соединение или нет. Если же Вы можете заглянуть в исходный код, большинство схожих вопросов отпадает. Даже если Вы не дополняете исходники, так или иначе Вы получаете пользу от тех, кто это делает. Проблемы и возможные улучшения быстро обсуждаются, реализуются и публикуются в свободный доступ. Прошли теперь те дни, когда на ожидание сколь-либо значительных улучшений или незначительных правок уходили годы. Заключение На протяжении лет я читал о программистах-полиглотах и о новых классных языках. В разное время люди писали на Ruby, Python, Scala, Go, Node.js, Swift и прочем. Приятно видеть, что Microsoft, сообщество сделали с .NET Core и как он вознесся в ранг первоклассной платформы. Я даже портировал .NET приложения на Maрc! Проблемой многих существующих языков программирования является то, что они узкоспециализированы. Ruby и PHP прекрасно подходят для веб-приложений. Swift или Objective C лучшего всего использовать для IOS или MacOS. Если нужно написать серверное приложение, можно использовать Python, Java и так далее. Пожалуй, кроме C#, только JavaScript и Java могут считаться языками широкого профиля. Мне бы было трудно применить навыки для решения различных задач, если бы я был вынужден работать со многими языками программирования. Это ограничивает возможности. Мне нравится универсальность C#, нравится то, что его можно использовать для разных типов приложений. Теперь, поскольку .NET Core так же подходит и для MacOS и Linux, больше нет никаких лимитов на его применение. Автор перевода: Евгений Лукашук Источник

C# занимает лидирующие позиции во всех рейтингах языков программирования. Так как рынок труда активно развивается, программисты, которые хорошо знают C# и технологии .NET, являются очень востребованными. На ITVDN вы найдете все необходимое, чтобы выучить C# с нуля до профессионального уровня. Курсы записаны сертифицированными разработчикам и тренерами Microsoft. Мы рекомендуем проходить обучение в такой последовательности:    C# Starter, автор Александр Шевчук Выполнение домашних заданий по C# Starter, автор Константин Черный How to C# Starter, автор Богдан Бондарчук Тренажер по C# Starter Visual Studio Tips & Tricks, автор Дмитрий Охрименко  C# Essential, автор Александр Шевчук Выполнение домашних заданий по C# Essential, автор Константин Черный How to C# Essential, автор Богдан Бондарчук Тренажер по C# Essential C# Универсальные шаблоны, автор Николай Мельничук  Unit Тестирование в C#, автор Дмитрий Охрименко  Асинхронное программирование в C# 5, автор Олег Кулыгин C# для профессионалов, автор Александр Шевчук  How to C# Professional, автор Константин Черный Что нового в C# 6.0-7.0, автор Александр Ткаленко Также вас могут заинтересовать записи вебинаров ITVDN: С# - с чего начать и как идти дальше? Работа с Microsoft Word на C# Если вы планируете свое обучение C# с нуля, тогда наилучшим решением будет приобретение подписки ITVDN сроком на 3 или 6 месяцев.

Настало время для прогнозов по безопасности и новым технологиям на следующий год. Ведь 2016 год стал еще одним годом, когда киберпреступность достигла новых высот, превысив прошлогодний набор угроз. Увеличение количества хакеров, новых технологий и выделение незначительных бюджетов для безопасности компаний создает идеальный плацдарм для более сложных хакерских механизмов. Одно можно сказать наверняка: вся эта буря, в свою очередь, привела к повышению осведомленности об угрозах кибербезопасности и появлению методов смягчения этих угроз. Компании поняли, что, придерживаясь одинаковых стратегий безопасности, они не могут ожидать разных результатов. Их неспособность влиять на ход киберпреступности внутри организации является явным индикатором потребности в изменениях. В лучшем случае, самые везучие смогли замедлить и даже перенаправить атаки, но не остановить или значительно уменьшить их. Правительства и компании, наконец, признали важность кибербезопасности и начали вкладывать большие деньги в защиту данных. Одно можно сказать наверняка: 2016 год был хорошим годом для признания кибербезопасности, поскольку была признана ее значительность. Руководители отделов кибербезопаснсти, CISOs – Chief Information Security Officer, перешли к более активному подходу в этой сфере и сосредоточились на областях, которые могут контролировать. Главные их инициативы кибербезопасности в 2016 году (в США): Источник: Исследование кибербезопасности Deloitte-NASCIO за 2016 год В общей сложности 29% американских руководителей отделов IT-безопасности концентрируются на идентификации и управлении доступом (IAM), наиболее приоритетной является многофакторная аутентификация – 77%. Угрозы, направленные на сотрудников, такие как фишинг, фарминг, социальная инженерия и ransonware, больше всего беспокоят руководителей IT-безопасности. И хотя задачи IT-безопасности являются первоочередными, CISOs по-прежнему сталкиваются с рядом преград при внедрении решений IAM внутри компании: затраты, законодательство, приоритеты компании и т.д. Источник: Исследование кибербезопасности Deloitte-NASCIO за 2016 год Тенденции аутентификации на 2017 год Gartner определяет «аутентификацию пользователя» как подтверждение в реальном времени заявленной цифровой идентичности человека с подразумеваемым или условным уровнем доверия. Рынок аутентификации пользователей включает в себя несколько типов продуктов и услуг, которые позволяют реализовать множество методов проверки подлинности, которые направлены на сопровождение или удаление полностью классических систем на основе паролей. Существуют 3 основных метода аутентификации: Однофакторная аутентификация Двухфакторная аутентификация Многофакторная аутентификация 1. Однофакторная аутентификация (SFA) Наиболее распространенной формой однофакторной аутентификации является аутентификация на основе пароля. Пароли существуют с первых дней работы компьютеров, около 55 лет. Пароль представляет собой непостоянную последовательность символов, используемых для определения того, что пользователь компьютера, запрашивающий доступ к компьютерной системе, действительно является конкретным пользователем. Естественно, что в такой быстро развивающейся среде, того, что использовалось 55 лет назад, уже недостаточно. Пароли действительно являются самым слабым звеном в цепочке безопасности, и это связано с: Невозможность людей придумать надежный пароль (они склонны недооценивать способность хакеров угадывать их пароли). Склонность пользователей использовать один и тот же пароль для нескольких учетных записей (имея не менее 50 разных учетных записей, никто не может запомнить 50 разных паролей). Способность хакеров взламывать их в считанные секунды. Конечно, есть много менеджеров паролей, но даже эти инструменты иногда оказываются уязвимыми. Интерес к паролям не уменьшается -  в целом поиск Google по слову «пароль» достаточно популярен, а это означает, что они по-прежнему являются основным методом аутентификации для большинства пользователей и систем. Несмотря на последовательный интерес, на пароли охотятся сами создатели WWW, которые также создали консорциум под названием World Wide Consortium. Эта инициатива направлена на замену паролей более безопасными способами входа в веб-сайты, так как: «Сильная аутентификация полезна для любого веб-приложения, которое хочет поддерживать текущие отношения с пользователями». Учитывая все эти факты, мы заключаем: Прогноз 2017: аутентификация на основе пароля будет переживать стагнацию. Общая тенденция: стагнация. Почему это может произойти: - Рост заинтересованности людей в защите их частной жизни приведет к ускорению внедрения альтернативных аутентификационных механизмов. - Пароли неэффективны в защите пользовательских аккаунтов. - Как следствие разработки более сложных и безопасных систем аутентификации. - Традиционный пароль будет ориентирован на более биометрический подход. - Веб-сайты переходят к более безопасным механизмам входа. Почему это может не произойти: - Обычные пользователи в основном имеют базовые компьютерные знания и считают свои текущие пароли достаточно сильными. - Все больше пользователей используют менеджеры паролей, сохраняя таким образом привычки входа с помощью паролей. - Основная масса населения не считает свои данные «стоящими» усилий хакеров. - При создании веб-сайтов используется классический механизм аутентификации пользователь/пароль. 2. Двухфакторная аутентификация (2FA) Двухфакторная аутентификация – это в основном переход на традиционную аутентификацию на основе пароля, в результате которого добавлен дополнительный шаг к процессу входа в систему (второй фактор). Двухфакторная аутентификация (2FA), часто называемая двухэтапной аутентификацией, представляет собой процесс безопасности, в котором пользователь предоставляет два фактора аутентификации, чтобы подтвердить, что он является тем, кем является, в отличие от однофакторной аутентификации (SFA), где пользователь предоставляет только один фактор – обычно пароль. 2FA существует уже довольно давно, но пользователи не выделяют ее как другую, иную систему аутентификации. Интерес к этому типу аутентификации растет довольно резко, поскольку поисковые запросы Google для термина «двухфакторная аутентификация» растут, особенно во второй половине 2016 года. Одной из наиболее распространенных форм двухфакторной аутентификации является форма, основанная на SMS, поскольку она во многом используется большинством финансовых учреждений. Широко распространенная версия 2FA на основе SMS теперь считается небезопасной из-за того, что они отправляются через различные небезопасные системы и существует риск перехвата SMS-сообщений со стороны нежелательных сторон. Национальный институт стандартов и технологий Министерства торговли США опубликовал проект, содержащий новые рекомендуемые стандарты аутентификации. В этом проекте предлагаются другие методы проверки подлинности, кроме основанных на SMS: «OOB с использованием SMS устарел и больше не будет разрешен в будущих версиях этого руководства». Прогноз 2017: использование двухфакторной аутентификации будет возрастать. Общая тенденция: увеличение. Почему это может произойти: - Переход от аутентификации с помощью пароля к двухфакторной аутентификации сравнительно легок, так как это добавляет один проверочный шаг в процесс. - Главные компании, такие как Apple, Google и Facebook, уже внедрили ее, познакомив своих пользователей с этой новой технологией и ускоряя внедрение. - Так как 2FA будет получать большую поддержку во внедрении, уязвимости будут ликвидированы и число компаний, внедряющих эту технологию, будет расти. Почему это может не произойти: - Двухфакторная аутентификация по-прежнему основана на паролях для аутентификации, к которым добавляется дополнительный проверочный шаг. - Так как аутентификация с помощью SMS теряет популярность как небезопасная, это может повлиять на общий рост 2FA. - Пользователи стойки к 2FA системам до их внедрения, что часто заставляет их менять используемые сервисы. Однако, как только система внедрена или становится обязательной, стойкость значительно падает. 3. Многофакторная аутентификация (MFA) Более надежной альтернативой двухфакторному механизму аутентификации является многофакторная аутентификация. Многофакторная аутентификация (MFA) – это система безопасности, которая требует более одного метода аутентификации из независимых учетных данных для проверки личности пользователя при входе или другой транзакции. MFA создает многоуровневую систему защиты, которая усложняет работу хакеров, поскольку им придется взломать все независимые учетные данные: То, что пользователь знает (пароль) То, что у пользователя есть (маркеры безопасности) Что-то от пользователя (биометрическая проверка) В поиске Google термин «многофакторная аутентификация» не имеет резкого увеличения, как в случае с 2FA, но видна устойчивая ритмическая эволюция. В отчете, опубликованном Markets And Markets, показано, что рынок мультифакторной аутентификации по прогнозам превысит 9,6 млрд. долл. США, применяемый в разных областях (путешествия и иммиграция, правительство, банковское дело, оборона, коммерция, безопасность, бытовая электроника, здравоохранение). Источник: MarketsandMarkets Помимо высокого уровня безопасности, многофакторная аутентификация обеспечивает определенную степень гибкости, позволяя компании устанавливать желаемый уровень безопасности в зависимости от профиля пользователей и потребностей. Прогноз 2017: многофакторная аутентификация будет неуклонно расти. Общая тенденция: увеличение. Почему это может произойти: - Так как проблемы безопасности возрастают, компании и правительства будут искать более сложные аутентификационные системы, такие как MFA. - MFA намного безопаснее, чем 2FA, которая до сих пор сильно зависит от паролей для аутентификации. - Учитывая уровень безопасности, который имеет MFA, она превосходит по удобству 2FA. - Законодательство – это важный фактор, который положительно влияет на рост рынка MFA, так как появляются законодательные требования по охране данных. - Правительства выделяют крупные суммы для создания продуктов кибербезопасности. Почему это может не произойти: - Осведомленность о кибербезопасности все еще низкая среди компаний и сотрудников. - Организации имеют ограниченный бюджет, навыки и ресурсы для усиления кибербезопасноти, что замедляет ее внедрение. - Длинные и часто сложные финансовые процессы компаний, ориентированных на кибербезопасность и создающих аутентификационные продукты. Поскольку мир все больше озадачен сохранением конфиденциальности и защиты данных из-за повышения количества взломов, компании и правительства вынуждены придумывать более эффективные инструменты кибербезопасности. На эволюцию рынка этой отрасли влияют несколько факторов: удобство использования, осведомленность о безопасности и спрос на нее, бюджеты и законодательство. Источник: https://www.upwork.com/hiring/for-clients/authentication-trends/

В течение последних нескольких лет JavaScript изменялся. И вот 12 новых фичей, которые вы можете начать использовать уже сегодня! 1.    История JavaScript Новые дополнения к языку называются ECMAScript 6. Они также упоминаются как ES6 или ES2015+. Начиная с концепции 1995 года, JavaScript развивался медленно. Новые дополнения выходили раз в несколько лет. ECMAScript появился в 1997 году, чтобы указать путь JavaScript. Были выпущены такие его версии: ES3, ES5, ES6 и другие.   Как вы заметили, между ES3, ES5 и ES6 существуют промежутки в 10 и 6 лет. Новая стратегия состоит в том, чтобы делать небольшие постепенные изменения каждый год. Вместо того, чтобы делать большие изменения сразу, как это случилось с ES6. 2.    Поддержка браузеров Все современные браузеры и среды программирования уже поддерживают ES6!   Chrome, MS Edge, Firefox, Safari, Node и многие другие уже имеют встроенную поддержку большинства функций JavaScript ES6. Таким образом, всё, что вы собираетесь изучить в этом туториале, вы можете начать использовать прямо сейчас. Давайте начнем с ECMAScript 6! 3.    Основные функции ES6 Вы можете проверить все эти фрагменты кода на консоли своего браузера.   Так что не верьте мне на слово и тестируйте каждый пример ES5 и ES6. 3.1. Блочная область видимости переменных В ES6 мы перешли от объявления переменных с var на использование let/const. Что не так с var? Проблема var – это утечка переменной в другой блок кода, например, в циклы for или if-блоки.   Для test(false) вы ожидаете возвращения outer, но нет, вы получаете undefined. Почему? Потому что даже при том, что if-блок не выполняется, выражение var x в строке 4 «поднимается». Поднятие переменных: var является переменной области видимости. Она доступна во всей функции даже до того, как её объявят. Выражения «поднимаются». Так что вы сможете использовать переменные до их объявления. Инициализация НЕ поднимется. Если вы используете var, ВСЕГДА объявляйте ваши переменные наверху. После применения правил подъема, мы можем лучше понять, что же случилось.   ECMAScript 2015 идёт на помощь:   Изменение var на let приводит к тому, что всё работает так, как и ожидалось. Если блок if не вызывается, переменная x не поднимается из блока. Взглянём на поднятие и «временные мёртвые зоны»: В ES6 let будет поднимать переменную наверх блока (НЕ наверх функции, как это происходит в ES5). Однако ссылка на переменную в блоке перед объявлением этой переменной приводит к ReferenceError. let – переменная области видимости. Вы не можете использовать её, пока она не будет объявлена. «Временные мёртвые зоны» – это зоны в начале блока и до того места, где объявляется переменная. IIFE (Immediately-Invoked Function Expression) Перед объяснением IIFE взгляните на пример:   Как вы видите, появляется private. Для того, чтобы удержать его, вам необходимо использовать IIFE (немедленно-вызываемое выражение функции):   Если вы посмотрите на jQuery/lodash или другие open source проекты, то заметите, что они используют IIFE во избежание загрязнения глобальной  среды и определения только глобального, например _,$ или jQuery. ES6 гораздо проще, нам больше не нужно использовать IIFE, когда мы просто можем применить блоки и let:   Const Вы также можете использовать const, если не хотите, чтобы переменная изменялась вообще.   3.2. Литералы шаблонов Нам больше не нужно встраивать конкатенации, когда у нас есть литералы шаблонов. Взгляните: Сейчас вы можете использовать кавычку (`) и строковую интерполяцию ${}:   3.3. Многострочные строки Нам больше не нужно конкатенации строк + \n по типу:   В ES6 мы снова можем использовать кавычку для решения такого примера:   Оба фрагмента кода будут иметь точно такой же результат. 3.4. Назначение деструктуризации Деструктуризация в ES6 очень полезная и точная. Получение элементов с массива   То же самое:   Обмен значений   Так же:   Деструктуризация для нескольких возвращаемых значений   В строке 3 вы также можете вернуть ее в массив подобный тому, что на примере (и сохранить некоторые, набрав код):   Но потом необходимо подумать о порядке возврата данных.   В ES6 вызывающий выбирает только те данные, которые ему нужны (строка 6):   Обратите внимание: В строке 3 есть некоторые другие функции ES6. Мы можем сжать { left: left} только до { left}.Посмотрите, насколько это компактнее по сравнению с версией ES5. Разве не круто? Деструктуризация для параметров согласования   Так же, но короче:   Deep Matching   Так же, но короче:   Это также называют деструктуризацией объектов. Как видите, деструктуризация весьма полезна и способствует хорошему стилю программирования. Практический опыт: Используйте деструктуризацию массива для получения элементов или замены переменных. Это избавит вас от создания временных ссылок. Не используйте деструктуризацию массива для нескольких возвращаемых значений, вместо этого примените деструктуризацию объекта. 3.5. Классы и Объекты С ECMAScript 6 мы перешли от «функции-конструктора» к «классам». В JavaScript каждый отдельный объект имеет прототип, который является другим объектом. Все объекты JavaScript наследуют свои методы и свойства от своего прототипа. В ES5 мы использовали объектно-ориентированное программирование (ООП), применяя функцию- конструктор для создания объектов, следующим образом:   В ES6 имеется некий синтаксический сахар. Мы можем делать то же самое менее шаблонно и с новыми ключевыми словами, такими как class и constructor. Также обратите внимание на то, как мы определяем методы constructor.prototype.speak = function () vs speak():   Как видим, оба стиля (ES5/6) дают одинаковые результаты и используются одинаково. Практический опыт: Всегда используйте синтаксис класса и избегайте прямого манипулирования прототипом. Почему? Потому что это делает код более кратким и понятным. Избегайте наличия пустого конструктора. Классы имеют конструктор по умолчанию, если он не указан. 3.6. Наследование Опираемся на предыдущий класс Animal. Предположим, мы хотим расширить его и определить класс Lion. В ES5 это большей частью связано с прототипическим наследованием.   Я не буду описывать все детали, но заметьте: В строке 3 мы явно вызываем конструктор Animal с параметрами. В строках 7-8 мы назначили прототип Lion прототипу Animal. В строке 11 мы вызываем метод speak из родительского класса Animal. В ES6 у нас есть новые ключевые слова extends и super.   Посмотрите, насколько разборчиво выглядит этот код ES6 по сравнению с ES5, и они работают одинаково! Практический опыт: Используйте встроенный способ наследования с extends. 3.7. Native Promises Мы перешли от callback hell к promises.   У нас есть одна функция, которая при done получает обратный вызов для выполнения. Мы должны выполнить этот вызов дважды один за другим. Вот почему во второй раз мы вызываем printAfterTimeout. Правда, это может пойти наперекосяк, если вам нужен третий или четвёртый обратный вызов. Давайте посмотрим, как мы можем сделать это с промисами:   Как видите, мы с промисами мы можем использовать then, чтобы сделать что-либо после выполнения другой функции. Больше не нужно хранить вложенные функции. 3.8. Стрелочные функции ES6 не удалил выражения функций, но добавил новые функции – стрелочные. В ES5 были некоторые проблемы с this:   Вам нужно использовать временное this для ссылки внутри функции или использовать bind. В ES6 вы можете использовать стрелочную функцию.   3.9. For…of Мы перешли от for к forEach, и потом к for…of:   В ES6 for...of также позволяет нам делать итерации.   3.10.  Параметры по умолчанию Мы перешли от проверки того, была ли переменная определена, к присвоению значения параметрам по умолчанию (default parameters). Вы делали что-то подобное раньше?   Вероятно, это обычный шаблон для проверки того, имеет ли переменная значение или присваивает значение по умолчанию. Однако заметьте, что здесь есть некоторые спорные вопросы: В строке 8 мы задали 0, 0  и получили 0, -1 В строке 9 мы задали false, но получили true. Если в качестве параметра по умолчанию задано значение boolean или это значение равно нулю, то оно не будет работать. Знаете почему? Все расскажем после примера ES6. С ES6 вы можете писать код лучше и короче! Обратите внимание на строки 5 и 6 – мы получаем ожидаемые результаты. Пример ES5 не работает. Сначала мы должны проверить undefined, поскольку false, null, undefined и 0 являются фальшивыми значениями. Мы можем выбраться с такими цифрами:   Сейчас всё работает так, как и должно, когда мы проверяем undefined. 3.11. Rest-параметры Мы перешли от аргументов к rest-параметрам и spread-оператору. Получать произвольное количество аргументов на ES5 довольно неудобно:   Мы можем сделать то же, используя rest-оператор . . . .   3.12. Spread-оператор  Мы пришли от apply() до spread-оператора. Опять на помощь приходит . . .: Напоминание: мы используем apply () для преобразования массива в список аргументов. Например, Math.max () принимает список параметров, но, если у нас есть массив, мы можем использовать apply, чтобы заставить его работать.   Как мы видели ранее, мы можем использовать apply для передачи массивов в виде списка аргументов:   В ES6 вы можете использовать spread-оператор:   Кроме того, мы пришли от использования массивов contact к использованию spread-оператора:   В ES6 вы можете сглаживать вложенные массивы, используя оператор spread:   4.    Заключение JavaScript прошёл через множество изменений. В этой статье описываются основные функции, которые должен знать каждый разработчик JavaScript. Кроме того, в статье есть примеры из практического опыта, которые помогут сделать ваш код более кратким и простым для понимания. Материал подготовлен на основе статьи из блога Adrian Mejia

Ваша цель - стать Junior Java developer в кратчайшие сроки? Что, если мы скажем вам, что её можно достичь всего за шесть месяцев? Хотите узнать - как? Внимательно читайте статью и следуйте рекомендациям. Мотивация  Итак, первый и, наверное, самый важный шаг – это мотивация. Как всем известно, под лежачий камень вода не течёт. Так что нужно чётко сформулировать свою цель и уже сейчас начать что-то делать для её достижения.  Но прежде чем начинать действовать, честно спросите себя: «Зачем я делаю это? Действительно ли  мне это нужно?».  Ведь без понимания значимости того или иного занятия, не будет и желания работать. Не можете понять, действительно ли это ваша цель? Лучшим мерилом того, насколько вы хотите получить желаемое, является то, что вы готовы отдать за него. Готовы ли вы тратить, допустим, 10 или 20 часов в неделю на изучение Java? Если ответ отрицательный, то с рациональной точки зрения вам следует отказаться от этой цели. Потому что, если вы уделяете этому по 5-7 часов в неделю, вы просто тратите время впустую. Аналогично и с деньгами: если вы не готовы тратить их на изучение Java, скорее всего, вы не сильно верите в то, что вам это нужно. Так что чётко определяйте цель, осмысливайте её значимость для вас и начинайте действовать!   Периоды В становлении джава-программиста условно можно выделить три периода: До резюме Во время резюме После резюме «До резюме» - это тот период, когда ещё не следует рассылать свое резюме, но создать его нужно. Резюме – своего рода рекламный буклет, в котором записаны ваши цели и желания. То есть в нём вы даёте себе чёткую задачу того, чего хотите. И чем раньше вы поймёте свои желания, тем быстрее вы получите результат. «Во время резюме» - это период, когда вы уже имеете достаточно знаний и рассылать резюме можно. На данном этапе вам следует пересмотреть ранее созданное, адаптировать его и обновить. Вообще такие действия с резюме стоит проводить раз в одну-две недели. И прежде чем отсылать резюме, его, конечно же, нужно привести в как можно более актуальное состояние. Важно отметить, что именно в этот период вы набираетесь бесценного опыта. Так как в это время вы начинаете ходить на собеседования и набивать свои первые шишки, без которых никак не обойтись. «После резюме» - период, когда вы уже устроились на работу и ни о чём не беспокоитесь. Не забываем об eXtreme Practices Для монетизации себя как специалиста, вам просто необходимо познакомиться с экстрим-практиками. «Что же это за практики такие экстремальные?» - спросите вы. Экстремального с точки зрения опасности для жизни в этих практиках очень мало. Одними из самых популярных практик считаются TVD, парное программирование, непрерывная интеграция, рефакторинг и другие. Но вы можете вырабатывать и свои практики. Просто попробуйте понаблюдать за собой в процессе работы и отметьте, что сильнее всего вам помогает в достижении конкретной цели. На базе этих наблюдений вы сможете создать практику, которая подойдёт вам наилучшим образом. Ещё один хороший способ улучшить свою работу – ретроспектива. Регулярно проводите её и анализируйте свои действия в профессиональной сфере. Пересматривайте вопросы, задаваемые вам на собеседованиях, и свои ответы на них. Это нужно делать для того, чтобы проверять себя на соответствие потребностям рабочего рынка. Вводите метрики рабочих часов, пройденных курсов или тем из них. Благодаря этому вы сможете видеть и контролировать то, сколько своих ресурсов вы потратили на обучение. Такой подход покажет вам честную картину вашей работы. Как учиться? Для освоения чего-либо существует множество возможностей. Вам только нужно найти свой способ и приступать к обучению. Давайте детально разберём несколько методов, чтобы вы смогли понять, какой из них подойдёт вам лучше всего. Онлайн тренинг В последнее время большой популярностью пользуются онлайн-тренинги. Главный их плюс состоит в том, что для них создана конкретная программа, и вы имеете доступ к ней в любое время в любом месте. Но к выбору тренинга нужно подходить с большой ответственностью. Стоит очень внимательно выбирать программу и учитывать, кто ведёт тренинг. К минусам такого метода обучения, во-первых, можно отнести большую вероятность того, что вы не пройдёте тренинг до конца, а во-вторых - отсутствие общения с тренером и такими же учащимися, как и вы. Если вы всё же решили обучаться таким способом, то верным вариантом не забросить это дело будет найти кого-то, перед кем можно будет отчитываться о проделанной работе или проходить тренинг в паре с другом. Также вы можете заключить пари с кем-то из знакомых или в социальных сетях, и тогда вам будет сложно отвертеться от начатого. Офлайн тренинг Такие тренинги ограничены местом и временем, что бывает не очень удобно, а также в большинстве своём они платные. Но посещая их, вы лучше и быстрее усваиваете материал, так как общаетесь с тренером вживую. На офлайн тренинге вы имеете возможность работать в команде над проектом, который в дальнейшем можно будет разместить, например, на GitHub и создать некую точку контакта с рекрутерами. Хотя в этом плюсе есть свои минусы, потому что если вы пропустите несколько занятий, то вам будет сложно успевать за командой. Обучаясь на офлайн тренинге, вам нужно будет готовиться к встречам, выполнять задания и приходить с вопросами к тренеру – так вы получите максимальную пользу от учёбы. На тренинге вы также имеете возможность найти напарника, с которым идти по пути к цели будет проще, или целую команду, что дает надежду на работоустройство после окончания обучения.  Платные курсы Сам факт того, что вы платите кому-то деньги, должен гарантировать некий стандарт качества и честность оказания услуг. Обычно учебные центры, в которых создаются эти курсы, заинтересованы в качестве и поддержании своей репутации. Поэтому такой способ обучения достаточно эффективен и, к тому же, существует большая вероятность того, что вы окончите курс, так как уже заплатили за него. Если вам подходит такой метод, то к выбору курса стоит отнестись осознанно и трижды подумать, прежде чем отдавать деньги. Учтите, что оплата – это благодарность авторам курса, ответственность за результат всё равно лежит на вас. Ведь каким бы хорошим не был тренер на курсе, в его обязанности не входит учиться за вас, вы должны делать это сами. Собственный проект Учиться, создавая собственный проект – это очень смело, и очень круто. Но вы должны быть готовы к любым трудностям.  Используя этот метод, для достижения успеха вам необходимо решать актуальные задачи. Начните создавать, например, консольный проект с мыслью о том, что он скоро станет веб-интерфейсом. Реализовывайте в этом проекте всю полученную вами информацию по этой теме, оттачивайте свои умения! Помните, что главное – не результат, а процесс. Потому как именно в процессе вы набираетесь знаний и опыта. Персональный коучинг При таком способе обучения с вами работает более квалифицированный специалист и решает вашу конкретную задачу. Занимаясь персонально, вы получаете индивидуальный, сделанный под вас план и выгодное знакомство. Согласитесь, никому не помешает знакомый человек из той сферы, в которой вы хотите реализоваться. Правда, у этого метода есть один минус – нанимать личного тренера зачастую стоит больших денег. Но если вы настроены серьезно и верите в поставленную перед собой цель, то это не должно быть преградой. Тренинг в компании Обучаясь в компании, вы получаете максимальный результат минимальными усилиями. Такие тренинги, как правило, бесплатные, а после их успешного окончания вы получаете возможность устроиться на работу в эту же компанию. Программы тренингов всегда адаптированы под компанию, что убережёт вас от изучения ненужного и бесполезного. Но на эти тренинги всегда очень большой конкурс, и при отборе вам необходимо проявить себя наилучшим образом. Самостоятельно Этот способ требует минимальных инвестиций и максимальной отдачи. Перед тем, как приступать к самостоятельному обучению, стоит составить учебный план. Распишите все курсы и темы, которые вы хотите пройти, распределите их по пунктам и приоритетности. Не забывайте вести учёт времени по каждому из пунктов и следить за статусом каждого из них. Выбрав самообучение, вы становитесь на непростой путь и рискуете не дойти до конца. Тем более, что сегодня вы имеете доступ к огромному количеству информации, среди которой очень просто потеряться. Но если вы всегда готовы к борьбе с трудностями и не привыкли отступать, то сможете научиться чему-либо самостоятельно. Систематически занимайтесь, создавайте свои проекты, найдите себе напарника по учёбе, и вы обязательно добьетесь успеха. Каким должен быть JavaJunior? Естественно, джуниор должен хорошо знать язык и решать алгоритмические задачи. Вы должны понимать ООП и уметь моделировать. Знание коллекций, input/output и умение писать юнит-тесты только приветствуется. Также неплохо было бы выучить какой-то из фреймворков и понимать веб-сервисы. Но это всё от вас потребуется не сразу. Некоторые из вышеперечисленных и другие навыки вы получите непосредственно в ходе самой работы.  Создание и распространение резюме В интернете вы можете найти множество советов по составлению резюме, но всё же давайте обговорим некоторые моменты, что касаются этого дела. Итак, при написании резюме вам необходимо придерживаться порядка, который присущ данному виду документа и, конечно же, писать грамотно. Свой опыт работы стоит записывать в обратном хронологическом порядке и указывать только правдивую информацию, хотя слегка её приукрасить можно.  То, что резюме нужно составлять в деловом, корректном стиле - понятно само собой. Хорошо, вы написали резюме. Теперь, чтобы начать поиск работы, вам необходимо его разослать. С этим у вас не должно быть проблем. Присылайте свое резюме известным и не очень IT-компаниям. Поместите его на сайтах поиска работы, благо сейчас таких много. Не стесняйтесь использовать социальные сети и разные сообщества для поиска работы. Главное -  быть настойчивым и не лениться, тогда всё сложиться так, как вы того хотите. Техническое собеседование Отлично! Ваше резюме подошло, и вас позвали на собеседование в компанию. Как же к нему подготовиться? В первую очередь, вы должны соответствовать требованиям вакансии и показать навыки, описанные в резюме. По возможности, просите проведения собеседования утром, так как за целый день можно забить себе голову всяким и под вечер прийти никаким. Тем более доказано, что в первой половине дня человеческий мозг работает лучше. И да, в день собеседования не вздумайте доучивать то, что не выучили раньше - это только навредит вам. Будьте спокойны, не паникуйте. Ведь беспокойство сбивает с толку и уничтожает пунктуальность. Поэтому расслабьтесь и наберитесь уверенности. На собеседовании общайтесь грамотно. Согласитесь, что человек, разговаривающий грамотно, вызывает больше доверия и вести беседу с ним приятнее. Кстати, немного о ходе беседы. Не загоняйте себя в глухой угол, не стоит говорить о тех вещах, в которых вы не разбираетесь. Этим вы можете ухудшить ситуацию и произвести неправильное впечатление.  Также следует внимательно слушать своего собеседника. Таким образом вы покажете, что умеете прислушиваться к людям и работать в команде. Вывод Всё только начинается! Если вы дочитали эту статью до конца – поздравляем! Значит, вы решительно настроены и собираетесь достичь поставленной перед собой цели.  Будьте Человеком-Решением, а не Человеком-Проблемой, и тогда перед вами откроется множество дверей. Не сворачивайте с намеченного пути, продолжайте учиться и развиваться. Помните, что всё в вашей жизни зависит только от вас. Так что уж постарайтесь сделать всё наилучшим образом.

Интернет, а соответственно и сфера веб разработки, быстро и постоянно изменяется. Если ты front-end разработчик, тогда скорее всего, ты знаешь, что нужно быть в курсе новостей (уж поверь!), уметь работать с новыми инструментами, тенденциями и бизнес-процессами. Все самое важное ты сможешь найти в Интернете, но будь осторожен, поскольку в сети много ненужного мусора. Какие же блоги по front-end технологиям наилучшие? Ежедневно публикуются сотни постов и статей. Все они беспорядочны и можно сойти с ума, пытаясь поспеть за всем. Прочитать их все просто невозможно. Более того, не нужно читать все в подряд.  Именно поэтому я попросил людей из компании Merixstudio выделить лучшие технические блоги по front-end разработке, которые стоит читать, и они собрали лучшие ресурсы новостей и тенденций в мире веб разработки. Ранее я уже публиковал статью о самых влиятельных блогах, ориентированных на технологии и веб разработку в целом. На этот раз буду подробно рассказывать о лучших front-end ресурсах (порядок сайтов случайный). Speckyboy Сайт позиционирует себя как журнал веб дизайна, но Paul Andrew – основатель Speckyboy – концентрируется не только на дизайн-ресурсах, но также предоставляет полезную информацию о новейших веб технологиях. Блог, безусловно, является отличным источником информации для ежедневного использования front-end разработчиком – блог предлагает отличные посты, справочники, разные источники информации и мотивирующий контент со всего мира. • #11,771 по рейтингу Alexa Rank* • 54,143 подписчиков на Facebook • 75,150 подписчиков на Twitter CSS-Tricks Если ты хочешь улучшить свои навыки в области веб дизайна и веб разработки, тебе стоит подписаться на CSS-Tricks, который ведет интернет-гуру Chris Coyier. Это кладезь знаний по веб разработке, который непременно повысит уровень представляемого тобой веб контента. CSS-Tricks в основном фокусируется на темах, связанных с CSS. Блог предоставляет фрагменты кода, «прорывные» статьи, видео, учебные курсы, подкасты и многое другое. • #1,253 по рейтингу Alexa Rank* • 67,776 подписчиков на Facebook • 298,126 подписчиков на Twitter Codrops Codrops можно назвать одним из самых новых и быстро растущих сайтов с документацией в сфере информационных технологий. Каждый front-end разработчик и веб дизайнер может найти много полезных материалов и фрагментов кода на Сodrops. Он также охватывает  общие темы веб-разработки и веб-дизайна. Блог ведется всего лишь двумя дизайнерами – фанатами своего дела – Manoela Ilic и Pedro Botelho. Ко всем преимуществам блога можно добавить красивое оформление сайта. Этот блог стоит посещать, чтобы обучаться новым хитростям и тенденциям в индустрии. • #3,197 по рейтингу Alexa Rank* • 89,619 подписчиков на Facebook • 164,845 подписчиков на Twitter Todd Motto’s blog Todd работает на позиции Developer Advocate в компании Telerik. Todd – основатель Ultimate Angular, а также Developer Expert в Google, спикер на конференциях и сторонник проектов с открытым кодом. В целом, он пишет на Angular и JavaScript. Его самоуверенный гид по командному стилю работы с AngularJS приобрел очень большую популярность на Reddit и Hacker News. Его блог отличный ресурс для подпитки собственных знаний, особенно, если ты заинтересован именно в таких технологиях, как Angular и JavaScript. • #44,788 по рейтингу Alexa Rank* • 1140 подписчиков на Facebook • 30,396 подписчиков на Twitter Очень важно, чтобы ты нашел свой собственный, уникальный способ отслеживать нужную тебе информацию. Так что, читай книги, журналы, отслеживай в Twitter людей, которые создают новые тенденции, смотри видеоматериалы, посещай конференции, общайся с единомышленниками и создавай новое! *Alexa Rank – глобальный рейтинг трафика, учитывающий, как число посетителей, так и число просмотров страниц. Предоставляется компанией Alexa Internet. Оригинал: www.merixstudio.com.