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

Что нового в Angular 4? Наконец, когда обновленная технология предстала перед нами, мы можем приступить к ее изучению! То, что новый представитель семейства Angular приобрел новый номер, свидетельствует об инновационных изменениях. Но все же встает вопрос: почему Angular 4, а не 3? Все достаточно просто: так как пакет маршрутизатора был уже представлен в версии 3.x, вместо того, чтобы вносить все нововведения в версию 3.0, а маршрутизатор перенести в 4.0, разработчик решил объединить все в версии 4.0. Не стоит волноваться касательно обновления Ваших приложений к новой версии Angular: так как тех самых инновационных изменений в принципе оказалось не слишком много, процесс установки не занял больше нескольких минут. Ничего особо страшного. Среди дополнительных требований стоит упомянуть версию TypeScript 2.1 или выше (раньше требовалась только 1.8+). К тому же некоторые элементы интерфейса были изменены или вовсе упрощены (редко используемые OpaqueTolen или SimpleChange). Плюс, TypeScript 2.1 и 2.2 приобрел целый ряд прекрасных особенностей, которые теперь поддерживаются в Angular 4. К примеру, в скором времени Вы сможете использовать TypeScript-опцию stringNullChecks. Итак, что именно позволяет нам новая версия Angular? Давайте углубимся!   Ahead of Time (AoT) компиляция: обновленный движок представлений Пожалуй, это наиболее значимое изменение, пусть даже Вы, как разработчик, не ощутите разницы. Как Вы, наверно, знаете, в режиме AoT Angular компилирует Ваши шаблоны во время сборки, после чего генерирует JavaScript код (в отличие от режима Just in Time, когда компиляция происходит во время выполнения приложения). Режим AoT обладает целым рядом преимуществ, например, в случае неправильного построения шаблона ошибка возникнет во время сборки, а не во время работы приложения, как раньше. Эта методика позволяет ускорить запуск приложения, так как генерация JS-кода уже произведена. Также Вам не нужно отправлять Angular-компиляторы пользователям, что в теории должно уменьшить размер пакетов. Почему в теории? Потому что, как правило, обратная сторона медали в том, что сгенерированный JavaScript-код обычно больше, чем нескомпилированные HTML-шаблоны. Таким образом, в большинстве приложений с использованием AoT размер пакета де-факто увеличивается. Разработчики Angular хорошо поработали над новым движком представлений, что позволило производить меньше кода при использовании Ahead of Time компиляции. Эффект на больших приложениях не заставил себя ждать. Без падений производительности. Ежели говорить в цифрах, размер пакета стал: С 499 КБ до 187 КБ (или с 68 КБ до 34 КБ после gzip) С 192 КБ до 82 КБ (или с 27 КБ до 16 КБ после gzip) Достаточно большая разница! Интересно отметить, что в своих дизайн-документах команда Angular сравнивает производительность (как в контексте времени выполнения, так и в контексте нагрузки на память) с базовой имплементацией (лучшим «дефолтным» кодом JS, который они только могут написать) Angular 2.x и InfernoJS (быстрая React-подобная имплементация). Универсальность Масса работы была проделана над универсальным проектом, позволяющим производить серверный рендеринг. Когда раньше этот тип проекта поддерживался в основном силами сообщества, теперь, начиная с Angular 4, поддержка приобрела официальный характер. Анимации Анимации теперь обзавелись собственным пакетом @angular/platform-browser/animations (одна из вещей, которая может быть изменена в процессе обновления). Что это значит? Это значит, что Вам больше не нужно нагружать пакеты ненужным кодом, если вы не используете анимации. Шаблоны ng-template вместо template Тэг template устарел. Вместо него используйте ng-template. Хотя и первый вариант все еще работает. Вообще, было немного странно использовать template, так как это реально существующий HTML-тэг. Теперь же Angular обзавелась собственным ng-template. В случае, если вы используете устаревший template, будет выдано соответствующее предупреждение: это в значительной мере упростит обнаружение подобного кода в проектах. Else С новой версией Angular 4 появилась возможность использовать оператор else: <div *ngIf="races.length > 0; else empty"><h2>Races</h2></div> <ng-template #empty><h2>No races.</h2></ng-template> As Еще одно синтаксическое нововведение. Ключевое слово as позволяет упростить синтаксис let. As позволяет хранить результат переменной шаблона для дальнейшего использование в элементе. К примеру, сия особенность может быть достаточно полезной для хранения коллекции: <div *ngFor="let pony of ponies | slice:0:2 as total; index as i">   {{i+1}}/{{total.length}}: {{pony.name}} </div> Или даже более полезной, если один раз использовать pipe с async. Вместо плохого и некрасивого: <div>   <h2>{{ (race | async)?.name }}</h2>   <small>{{ (race | async)?.date }}</small> </div> Вы можете использовать: <div *ngIf="race | async as raceModel">   <h2>{{ raceModel.name }}</h2>   <small>{{ raceModel.date }}</small> </div> Различные виды pipe Titlecase Angular 4 презентует новый pipe: titlecase. Он позволяет переводить первую букву каждого слова в верхний регистр: <p>{{ 'ninja squad' | titlecase }}</p> <!-- will display 'Ninja Squad' --> Http Задание параметров поиска Http-запроса было упрощено: http.get(`${baseUrl}/api/races`, { params: { sort: 'ascending' } }); Раньше вам необходимо было произвести следующее: const params= new URLSearchParams(); params.append('sort', 'ascending'); http.get(`${baseUrl}/api/races`, { search: params }); Test Переопределение шаблона во время теста также было упрощено: TestBed.overrideTemplate(RaceComponent, '<h2>{{race.name}}</h2>'); До этого мы обычно писали так: TestBed.overrideComponent(RaceComponent, {   set: { template: '<h2>{{race.name}}</h2>' } }); Сервисы Meta Для получения содержимого или обновления meta-тэгов был введен новый сервис: @Component({   selector: 'ponyracer-app',   template: `<h1>PonyRacer</h1>` }) export class PonyRacerAppComponent { constructor(meta: Meta) {     meta.addTag({ name: 'author', content: 'Ninja Squad' });   } } Формы Валидаторы Новый валидатор позволит объединить существующие required, minLength, maxLength, и pattern. email позволит провести валидацию e-mail адреса (если Вы планируете просто обойтись подходящими регулярными выражениями – удачи в поисках). Сравнение выбранных опций Для сравнения выбранных опций была добавлена новая директива: compareWith: <select [compareWith]="byId" [(ngModel)]="selectedPony">    <option *ngFor="let pony of race.ponies" [ngValue]="pony">{{pony.name}}</option> </select> byId(p1: PonyModel, p2: PonyModel) {    return p1.id === p2.id; } Маршрутизатор ParamMap Для представления параметров URL был введен новый интерфейс: ParamMap. Вместо использования params или queryParams, отныне Вам стоит использовать paramMap или queryParamMap, так как они позволяют выбрать между get() для получения значения или getAll() для получения всех значений (так как параметры запросов могут иметь несколько значений, к примеру). const id = this.route.snapshot.paramMap.get('ponyId'); this.ponyService.get(id).subscribe(pony => this.pony = pony); Или как здесь:   .map((params: ParamMap) => params.get('ponyId'))   .switchMap(id => this.ponyService.get(id))   .subscribe(pony => this.pony = pony); CanDeactivate Интерфейс CanDeactivate теперь обзавелся дополнительным опциональным параметром, содержащим следующее состояние (то, куда Вы собираетесь перейти). Теперь можно реализовать «умную логику», когда пользователь может покинуть текущий компонент в зависимости от того, куда он или она направляется. I18n Интернационализация также медленно, но верно улучшается. К примеру, ngPlural теперь упрощен: <div [ngPlural]="value">   <ng-template ngPluralCase="0">there is nothing</ng-template>   <ng-template ngPluralCase="1">there is one</ng-template> </div> А теперь давайте сравним с тем, что было раньше: <div [ngPlural]="value">   <ng-template ngPluralCase="=0">there is nothing</ng-template>   <ng-template ngPluralCase="=1">there is one</ng-template> </div> Только что мы добавили целую главу к нашей электронной книге, включая несколько юз-кейсов и прочее! Подведем итоги Релиз Angular 4 привносит множество улучшений и действительно востребованных инноваций в сферы размера генерируемого кода, сохраняя в целом концепцию предыдущей версии Angular. Благодаря этому обновление технологии не должно вызвать затруднений. Автор перевода: Евгений Лукашук Оригинал статьи

SQL Server 2017 – это огромный шаг вперед на пути к платформе, универсальной для многих языков, типов данных, онпремисного софта и облачных хранилищ, доступной как для Linux и Linux Docker-контейнеров, так и для традиционной Windows. В этой статье мы расскажем о ключевых особенностях обновленной технологии и поделимся полезными ссылками на дополнительные материалы. Загрузить новинку вы можете здесь.   Обратите внимание! Помимо приведенных ниже изменений, также были выпущены кумулятивные патчи, которые привносят свои улучшения.   Обновленный движок Движок SQL Server 2017 включает множество новых возможностей, улучшений и оптимизационных алгоритмов. CLR сборки, в качестве аналога функции clr strict security, описанной в CTP 2.0, теперь могут быть спокойно добавлены в вайт-лист. Кроме того, такие Transact-SQL сборки, как sp_add_trusted_assembly, sp_drop_trusted_assembly и sys.trusted_assemblies (RC1), больше не вызывают конфликтов с безопасностью. Восстановление построения индекса возобновляет процесс построения индекса с места предыдущего сбоя (к примеру, по причине недостаточного места на диске и т.д.) или приостанавливает работу и возобновляет ее через определенное время (ALTER INDEX). IDENTITY_CACHE – отличная новинка для ALTER DATABASE SCOPED CONFIGURATION, которая позволяет избежать пропусков между значениями колонок идентификации на случай, если сервер внезапно перезагрузится или произойдет сбой в работе с вторичным сервером. Новое поколение улучшений в механизме обработки запросов, адаптирующих оптимизационные стратегии к вашему приложению прямо во время выполнения (run-time режиме). Первая версия семейства адаптивной обработки запросов содержит три значимых новшества: batch mode, adaptive joins и batch mode memory grant feedback. Кроме того, не стоит также  забывать про последовательное выполнение многооператорных табличных функций. Автоматическая калибровка базы данных позволяет предотвратить вероятные падения производительности запросов, предлагает решения и, помимо прочего, может автоматически исправить обнаруженные неполадки. Новые возможности графов для моделирования множественных связей включают обновленный синтаксис CREATE TABLE, предназначенный для генерации таблиц ячеек и граней. Также в комплекте поставляется новое ключевое слово MATCH для запросов. С целью обеспечения безопасности CLR сборок опция sp_configure под названием clr strict security теперь включена по умолчанию. Появилась возможность устанавливать максимальный размер временных файлов tempdb до 256 ГБ (262,144 МБ) на один файл. Однако если размер превысит 1 ГБ (без IFI), будет выдано соответствующее предупреждение. Колонка modified_extent_page_count в sys.dm_db_file_space_usage отслеживает изменения в каждом файле базы данных, позволяя применять возможности «умного бэк-ап’а».  «Умный бэк-ап» в свою очередь проводит частичный или полный бэк-ап страниц, исходя из процента внесенных изменений. Поддержка возможности кросс-транзакции между базами данных с Always On Availability Group – даже внутри одного и того же представления. Синтаксис T-SQL SELECT INTO теперь поддерживает загрузку страницы прямо в FileGroup при помощи специального слова – ON. Обновленный функционал Availability Groups включает в себя безкластерную поддержку, настройки Minimum Replica Commit Availability Groups и Windows-Linux кроссплатформенные миграции и тестирование. Новые возможности динамического управления: sys.dm_db_log_stats демонстрирует общие уровневые атрибуты и содержимое файлов транзакции, необходимое для мониторинга состояния транзакционного лога. sys.dm_tran_version_store_space_usage отслеживает использование места на диске отдельно для каждой базы данных, что, безусловно, помогает предугадать возможный размер временных файлов. sys.dm_db_log_info позволяет мониторить, оповещать и предотвращать потенциальные ошибки транзакции благодаря обработке VLF-информации. sys.dm_db_stats_histogram - новая опция мониторинга для анализа статистики. sys.dm_os_host_info предоставляет оперативную системную информацию Windows и Linux. Database Tuning Advisor (DTA) – или «советник по калибровке базы данных» – получил целый спектр дополнительных настроек и улучшений производительности. Оптимизация работы с памятью включает в себя поддержку вычисленных колонок в оптимизированных таблицах, полную поддержку JSON-функций и CROSS APPLY оператор. STRING_AGG функция обзавелась таким полезным опционалом, как CONCAT_WS, TRANSLATE, TRIM и WITHIN GROUP. Новые опции bulk-доступа (вроде BULK INSERT и OPENPOWSET(BULK…)) для CVS и блоб-файлов Azure. Оптимизация объектов: внедрение sp_spaceused, отказ от 8-индексных ограничений оптимизированных таблиц, sp_rename для оптимизированных таблиц и органически внедренные T-SQL модули. Помимо прочего стоит указать CASE и TOP (N) WITH TIES для упомянутых выше T-SQL модулей. Теперь хранение, бэк-ап и заливка оптимизированных таблиц на Azure не составит труда. DATABASE SCOPED CREDENTIAL - это новый класс защищенных, поддерживающих CONTROL, ALTER, REFERENCES, TAKE OWNERSHIP и VIEW DEFINITION разрешений. Работа с операциями bulk-администрирования может происходить прямо из sys.fn_builtin_permissions. Добавлен уровень совместимости 140.   Службы интеграции (SSIS) Новая особенность Scale Out может похвалиться следующими инновациями: Scale Out Master теперь стал более доступным для использования. Благодаря усовершенствованию Scale Out Workers подверглась изменению система ведения логов на случай отказа работы сервера. Параметр runincluster процедуры [catalog].[create_execution] для большей совместимости и читабельности был переименован на runinscaleout. Для поддержки выполнения SSIS-пакетов в стандартном режиме SSIS-Каталог обзавелся соответствующими глобальными свойствами. Благодаря новой особенности Scale Out для SSIS, Вы можете легко использовать Use32BitRuntime во время работы приложения. Сервисы интеграции SQL Server 2017 теперь поддерживают SQL Server и для Linux. Новый программный пакет позволит Вам работать с SSIS прямо из командной строки. Помимо прочего, Scale Out for SSIS значительно упрощает запуск SSIS-пакетов на нескольких машинах. Отдельно стоит упомянуть об OData Source и OData Connection Manager, обеспечивающих подключение к Microsoft Dynamics AX Online and Microsoft Dynamics CRM Online.   Обновление служб Master Data Значительное улучшение и повышение производительности в сравнении с предыдущими версиями. Хотите просмотреть список сборок, коллекций и иерархий веб-приложения? Что может быть проще! Новая страница Explorer легко позволит Вам это. Благодаря использованию специальных процедур хранения данных внесение записей стало значительно более оптимизированным. Улучшение производительности во время развертывания папки Entities в Manage Groups, так как страница Manage Groups перемещена в секцию Security.   Обновленные службы анализа (SSAS) Сервисы анализа (в дальнейшем – SSAS) SQL Server 2017 представляют множество новых возможностей и улучшений для табличных моделей. А именно: Табличный режим в качестве опции по умолчанию. Объектная защита метадаты табличных моделей. Взаимозависимость данных для упрощения создания зависимостей полей. Внедрение нового ресурса Get Data и поддержка М-запросов для существующего DirectQuery. DAX Editor для SSDT. Кодировка подсказок для оптимизации обновления данных таблиц в памяти. Поддержка таблицами уровня совместимости 1400. Если Вы желаете создать новые или обновить существующие таблицы к уровню совместимости 1400, загрузите и установите SQL Server Data Tools (SSDT) 17.0 RC2. Поддержка Get Data нового уровня совместимости 1400, упомянутого выше. Новое свойство Hide Members позволит Вам скрыть пустые сущности поврежденных иерархий. Новые действия – Detail Rows и Show Details – для совокупной информации. Внедрение функций SELECTCOLUMNS и DETAILROWS для создания Detail Rows – выражений. Оператор DAX IN для задания множественных значений.   Обновленные службы отчетности В новой версии SQL Server 2017 службы отчетности не поставляются по умолчанию. Загрузить их Вы можете здесь. Для повышения уровня читабельности кода и упрощения командной разработки была внедрена поддержка комментариев. Также Вы можете прикреплять к ним дополнительные файлы. Используя последнюю версию Report Builder и SQL Server Data Tools, Вы можете создавать нативные DAX-запросы – в противовес таблицам служб анализа. Все, что Вам для этого нужно – лишь переместить желаемые поля в дизайнер запросов. Благодаря поддержке интуитивного RESTful API, используя последнюю версию SQL-инструментария, Вы без труда сможете разрабатывать современные приложения и проводить их последующую кастомизацию.   Машинное обучение В новой версии приложения R-службы сменили название на Службы Машинного Обучения SQL Server (SQL Server Machine Learning Services), что подчеркивает поддержку как языка R, так и набирающего популярность Python. Благодаря этому работа с такими языками не составит труда. Впрочем, можно обойтись и без SQL Server: упомянутые Службы Машинного Обучения не требуют его наличия на ПК. С этими значительными новшествами разработчики SQL получили колоссальное преимущество в виде отменных библиотек Python ML и AI, которые, помимо прочего, могут похвастаться открытым исходным кодом. Итак, что же мы имеем? Revoscalepy – Python`овский эквивалент RevoScaleR. Включает в себя параллельные алгоритмы линейных и логистических регрессий, дерево решений, усиленные деревья и рандомные леса. Также стоит упомянуть богатый набор API, крайне полезных при обработке и манипуляции данными, удаленными вычислениями и информационными ресурсами. Microsoftml – воистину настоящее произведение искусства в сфере алгоритмов машинного обучения. Включает в себя проработанные нейронные сети, быстрые деревья решений и леса и, конечно же, оптимизированные алгоритмы линейных и логистических регрессий. В Вашем распоряжении также оказываются заготовки на базе моделей ResNet, весьма удобные, когда речь заходит об извлечении картинок или их анализа. Взаимодействие Python с T-SQL – что может быть проще? Все, что Вам нужно – это лишь задеплоить Python-код при помощи процедуры sp_execute_external_script! Ощутите настоящую скорость передачи данных между SQL и Python-процессами. Свободно используйте MPI кольцевую параллелизацию. Нативное оценивание – даже если язык R не установлен, благодаря функции Predict Transact-SQL можно легко провести оценивание в любой сущности SQL Server 2017. Все, что Вам необходимо, – это настроить модель, используя один из алгоритмов RevoScaleR или revoscalepy, сохранив модель в новом компактном бинарном формате. Управление пакетами – обновленный T-SQL обладает поддержкой команды CREATE EXTERNAL LIBRARY, что упрощает работу с R-пакетами. Контролируйте приватность пакетов, устанавливайте доступ, сохраняйте их и делитесь с другими пользователями. Улучшения производительности – благодаря оптимизации процедуры sp_execute_external_script была включена поддержка batch-режима для информации в столбцах. Автор перевода: Евгений Лукашук Источник

Автор статьи: Влад Кобылянский, архитектор программного обеспечения, разработчик и консультант по технологиям малого бизнеса (Майами, Флорида).   Вопрос: Что сегодня происходит с PHP фреймворками? В феврале 2017 года я так ответил на этот вопрос: «В основном все крутится вокруг двух PHP фреймворков -  Laravel и Symfony. Особой нужны в использовании CakePHP, Zend, CodeIgniter, Yii и т. д. нет, если вы начинаете новый проект. Только если вы уже знаете эти фрэймворки или у вас в команде есть разработчики которые привыкли работать с ними, тогда причины их использования обоснованы. Когда начинается реальная разработка, вы должны иметь возможность находить инструменты, плагины, ответы на общие проблемы. С сообществами Laravel и Symfony, с постоянным развитием новых «модулей» или функций, не будет ощущения, что вы остались «в стороне». Одни Laracast (даже если вы не работаете в Laravel) чего стоят! Они просто фантастичны. Когда заходит речь об интеграции с iron.io или другими SaaS сервисами, поддержке широкого спектра источников данных или о среде разработки – Laravel и Symfony и их расширения намного более продвинуты. Еще одним достоинством  Lumen, является быстрая разработка и прототипирование API для Laravel. При этом это никак не ограниченно для построения больших приложений.Вообще говоря, сегодня мы определенно видим переход к контейнерной архитектуре, где MVC играет гораздо меньшую роль. Все это касается микросервисов, оркестровки и создания приложений как «функций» (AWS Lambda и подобных сервисов). Возможно, пришло время освежить наши навыки Node/JS и GoLang?»   Хотя я в целом доволен этим ответом, сейчас я думаю, что некоторые моменты пришло время пересмотреть. Прежде чем перейти к таким странным темам, как GoLang, давайте взглянем на тенденции PHP MVC фреймворков. Я бы сказал, что тенденции, которые мы наблюдали в прошлом, остаются. Laravel продвигается вперед, в то время как большинство остальных фреймворков отстает. В популярности Symfony наблюдается небольшой всплеск, вероятно, из-за долгожданного выпуска Symfony 3. Я попробовал более конкретные поиски для сравнения, такие как «CakePHP 3» или «ZF2», однако они не привели к статистически значимым тенденциям. На этот раз я добавил CodeIgniter, потому что он оказалася очень популярным. Я получил ряд вопросов о CodeIgniter. Если коротко, CI сейчас не в конкуренции, потому что это не 100% фреймворк MVC. Иначе, чем организованной коллекцией POPO, я это не назову. Для наглядности представляю вам цитату из руководства CodeIgniter: «CodeIgniter имеет довольно свободный подход к MVC, поскольку не требуются Models. Если вам не нужно дополнительное разделение или вы обнаружите, что поддерживающие Models требуют большей сложности, чем вы хотите, вы можете их проигнорировать и создать свое приложение с помощью Controllers и Views.» Когда дело доходит до построения структуры, я просто не согласен с таким подходом. Возможно, это достойный шаблон (отсюда и популярность CodeIgniter), однако должна быть какая-то дисциплина, навязанная фреймворком, иначе конечный продукт в итоге превращается в беспорядочный спагетти-код, завернутый в какой-то «шаблон». Далее, Symfony 3 привнес некоторые достойные улучшения в разработку и целый ряд новых «фич». Как и многие аналоги PHP, теперь он предлагает микро-фреймворк. ZF3, к примеру, добавил ряд улучшений, таких как поддержка PHP7 (наконец!) и даже стал микро-фреймворком... но, в их руководстве так и говорится: «Для пользователей Zend Framework 2 MVC, различия с ZF3 незначительны...» Я действительно надеялся, что они скажут, что различия есть, что было замечательное архитектурное усовершенствование, замечательные новые модули, которые помогают вам разрабатывать все по-современному. Но, увы, по большей части ZF3 по-прежнему похож на ZF2. Long Story Short Вот как я вижу мир PHP фреймворков сегодня: Symfony или Laravel (выбор зависит от того, какую задачу вам нужно решить) Все остальное Laravel на первом месте. Объем доступной информации, Laracasts, таланты разработчиков во всем мире, простые реализации шаблонов, интегрированные наборы инструментов тестирования, активная реализация записей в форме Eloquent, облегченная версия в Lumen, развитие Homestead (Vagrant) – все перечисленное способствует фреймворку действительно выделяться и для новых, и для опытных разработчиков. Однако модели Eloquent могут стать непослушными и довольно большими по размеру, а сервисов Laravel (не путать с микросервисами) можно создать очень много, и вот тут люди начинают думать о реализации Repository, которому здесь не место. Так родился Monolith. Если вам не нравится активный шаблон записи и вам нужна дополнительная гибкость в репозиториях, или, возможно, вы видите слишком много независимых анонимных функций, тогда используйте Symfony + Doctrine. Рассматриваю ли я Symfony как шлюз для монолитных приложений? В какой-то степени, да. В целом, я бы не назвал это резким изменением с прошлого года. Тем не менее, нам нужно взглянуть на общую картину: правильно разработанное приложение выходит за рамки чистого MVC; речь идет об инфраструктуре, конвейере развертывания, разъединённой архитектуре. Все это может быть достигнуто в стеке MVC, но нужно быть внимательным, чтобы избежать Monolith. Приход микросервисов Раньше я упоминал о распространенности микросервисов и необходимости улучшать навыки GoLang или Node. А в статье о PHP MVC было бы глупо не упомянуть о явно растущем движении к микросервис-ориентированной архитектуре (MOA); и это движение набирает обороты, поверите вы или нет. Хотя эти два понятия не являются взаимоисключающими, не нужно находить параллели между ними, ведь они действительно представляют собой разные философии. В качестве примера, размещение вашего приложения MVC в одном контейнере и MySQL в другом, а затем объединение их вместе, не обязательно представляет собой надлежащую MOA. Это, безусловно, лучший подход, чем пытаться установить MAMP, XAMPP или что-либо еще, чтобы заставить ваш компьютер работать с приложением. Кроме того, это может решить некоторые проблемы, такие как простота запуска локальной среды на разных платформах и, возможно, в некоторых случаях стратегии развертывания, но вы застрянете с монолитным MVC в вашем приложении/контейнере. Уничтожение Monolith Микросервисы – это как раз о «разрушении». В то время как MVC обращается к вашей структуре кода и организации, обеспечивая надежный подход к разделению проблем, эта концепция еще больше расширяется контейнерами/сервисами/MOA. Вместо того, чтобы просто отделять виды (Views) от моделей (Models), вы теперь разделяете каждый «кусок» или логическую единицу вашего приложения на индивидуальную службу, предназначенную для правильной работы с собственными обязанностями. Если у вашего MVC-приложения есть контроллер «Поиск», действия и соответствующие методы модели, то у нас уже есть пример монолитного приложения. Напротив, используя подход MOA, у нас будет сервис для каждого из этих процессов. В качестве примера: Router сервис Request сервис Query сервис DataSource сервис Response сервис Но не все эти «сервисы» являются частью стека MVC? Конечно нет. Они являются строительными блоками нашего Monolith. С MOA каждый сервис работает в рамках собственной среды, а мы, как архитекторы, можем разработать лучший подход к решению конкретного запроса. В качестве примера, если я должен был бы написать службу обработки изображений в среде Laravel, я использовал бы что-то вроде расширения PHP-GD2, что может быть не самым эффективным способом обработки изображений. Служба C++, которая обрабатывает мои запросы в обработке изображений, может быть намного быстрее и определенно более надежной при масштабировании. И мы могли бы сделать вывод службы обработки изображений и отправить ее в службу DataStore, службу CloudStorage и службу Queue Email. Решение этой же задачи с кучей скрытых заданий и, возможно, нескольких отдельных приложений MVC и пользовательских сценариев – это то, как разработчики делали это раньше (2 года назад). Время двигаться вперед. Масштабируемость Здесь возникают проблемы (или заканчиваются, в зависимости от того, куда вы держите курс). С одной стороны, очень сложно масштабировать Monolith: если вы создадите все больше и больше логики в одном и том же наборе MVC, вы застрянете с хорошо структурированным приложением ужасной сложности. С другой стороны, если вы построите тысячу микросервисов на разных языках, как вы будете управлять этим беспорядком? Существуют различные инструменты компоновки контейнеров (например, Kubernetes, Swarm, Mesos), услуги по развертыванию контейнеров (GKE и AWS ECS), однако лишь немногие предприятия используют архитектуру Docker. Есть удачные истории в построении инфраструктуры с использованием Docker или других контейнерных технологий (т. е. GKE). Большинство из этих историй исходят от компаний, которые могут позволить себе тратить ресурсы на архитекторов, дефолтов, администраторов баз данных и инженеров. Тем не менее, сейчас идут бесчисленные дискуссии о том, как развернуть хорошо организованный и элегантный MOA. В любом случае, вы не решите эту проблему самостоятельно, и пока вы не достигнете относительно большого масштаба, эта проблема действительно нуждается в решении. Может быть, сейчас не самое время усердствовать. Золотая середина на сегодняшний день (даже для тех, кто занимается приложениями меньшей сложности или не такими требованиями к трафику) заключается в том, чтобы разгрузить многие типичные сервисы сторонним провайдерам. Почти все доступно сейчас как сервис. Фоновые задания, обработка изображений, аутентификация, аналитика данных, ведение журнала, отправка электронной почты, системы очереди не обязательно должны строиться в одном стеке MVC, а архитектор должен подумать о том, что может быть выгружено в систему SaaS за небольшую ежемесячную стоимость (т.е. поиск Algolia) или, возможно, специально созданную докерную службу, работающую в облачном пространстве, которая выполняет эту обработку изображений. Я думаю, важно, чтобы вы не начали перепроектировать весь проект с начала, не сбрасывать все, что у вас уже есть, а выпускать докеры, где это можно сделать. Существуют способы постепенного развертывания вашего проекта/продукта путем разъединения, изучения узких мест в системе (и т.д.) и последующим применением разделения проблем в этих проблемных областях. Вывод 2017 год принес нам много дискуссий и производственных развертываний, основанных на контейнерах и MOA. Мои размышления о Docker, используя GoLang или Node, не означают, что PHP «умирает» или что-то в этом роде ... Я считаю, что разработчикам нужно оставаться в тренде. Если микросервисы и дальше будут развиваться в том же русле, в котором это происходит сейчас, то почему бы не изучить GoLang? Он идеально подходит (из-за низкой занимаемой площади, скорости и параллельной обработки) для разработки небольших контейнерных приложений. Node и GoLang позволяют создавать небольшие сервисы, которые являются частью более крупного проекта, связывают созданные сервисы и выпускают их как контейнеры Docker, если это необходимо в вашей работе. Тем не менее, все эти передовые решения и языки не уменьшают значимость и востребованность языка PHP. Разработчикам еще нужны будут стеки MVC и работа с  API. MOA пока не помогает решить архитектурные проблемы на стороне frontend, UI или Views, хотя при этом контейнеры помогают нам избежать работы с Monolith на backend. Мы можем создать чрезвычайно надежное backend-приложение, но оно среагирует на JSON, который каким-то образом должен быть представлен в клиентском приложении. Имеет ли значение, если результирующий объект ответа поступает из РНР кода, URL или от модулей принятия решений и обработки, разделенных интерфейсом обмена сообщениями? Это зависит от Ваших потребностей и требований к вашему приложению. Мой совет: в этом году учите Laravel, следите за Docker, GoLang и фокусируйтесь на конвейере развертывания. Продвижение от локального небольшого проекта к продакшену должно быть достаточно плавным, особенно при создании приложений MVC.   Оригинал статьи

Full stack разработчик, который может создать из прототипа полноценный MVP (минимальный жизнеспособный продукт), часто считается тем, кто берется за все, но ничего толком не умеет, и не без оснований. Чтобы определить современного разработчика как full stack, нам сначала нужно сосредоточиться на том, кем был разработчик full stack. Full Stack разработчики «тогда», раньше Давным-давно, около 2000 года (в интернет-времени 17 лет – это очень давно), full stack разработчиком был тот, кто мог: - создать веб-страницу в некоторых инструментах Adobe, таких как Photoshop или Fireworks - превратить этот дизайн в HTML, CSS и горячие точки на изображениях (помните их?) - написать некоторые базовые сценарии PHP 4.0 (тогда объектно-ориентированного PHP не было и на горизонте) для обработки серверной части логики - хранить все динамические данные в MySQL, возможно, немного оптимизировать - загружать все на сервер по FTP и собирать оплату. Обратите внимание, о каком PHP здесь идет речь: у full stack Flash или Coldfusion разработчика был другой (но не очень отличающийся) рабочий процесс. Это были простые времена, жизнь была хорошей. Агентства, состоящие из одного человека, были весьма распространены, и люди все еще успевали проводить время с семьей после работы. Что же сейчас? Что же должен знать Full Stack разработчик сейчас? В наши дни мы сталкиваемся с такими ситуациями:  Чтобы преуспеть в современном насыщенном рынке, разработчики, которые часто являются перфекционистами, не решаются делегировать процессы и работу и часто живут под девизом «если вы хотите что-то сделать правильно, то сделайте это сами». Это загоняет специалиста в угол, где он обязан и должен знать все. Таким образом, сейчас Full Stack разработчик - это: Server Admin / Devops Разработчик должен знать, как выполнять базовое управление сервером. Это включает, но не ограничивается: - подключение к удаленным серверам через терминал, в среде без GUI - основные сценарии оболочки - управление пользователями и группами на сервере - управление серверными программами, такими как Apache и Nginx для обслуживания приложений - управление брандмауэрами и разрешениями - установка нового программного обеспечения и обновление дистрибутива Помимо этих основ, разработчик должен знать, как создавать хорошие, здоровые, изолированные среды разработки, как в Docker, так и на виртуальных машинах, таких как Vagrant. Также разработчик должен быть хорошо знаком с системами контроля версий, чтобы иметь возможность создавать резервные копии и совместные коллективные коллекции кода, отслеживать изменения во времени. В наши дни не существует современного рабочего процесса разработчиков без использования контроля версий. Облако Помимо реальных управляемых или виртуализированных серверов, разработчик должен знать об облаке – хостинге на таких платформах как Heroku, Google Cloud, Azure, AWS и других. Существует справедливое мнение о платформах и инструментах, которые являются более привлекательными, чем полезными, но знакомство с сервисами, о которых все говорят, может пригодиться в долгосрочной перспективе – клиент может потребовать переключения провайдеров в любой день, и он платит за готовность. Back End Что касается back end, помимо знания выбранного языка – например, PHP и его множества фреймворков и CMS – Full Stack Developer должен быть знаком с: - веб-серверами, такими как Nginx и Apache, которые связаны с Devops (смотрите описание выше) - NodeJS для компиляции JS, CSS и других активов в статически хранимые. Хорошие новости в том, что есть способы избежать NodeJS с помощью PHP - такими инструментами, как Composer для управления пакетами и зависимостями в самом PHP – никакая среда современного разработчика не будет завершенной без него - хорошим дизайном API, поскольку большинство новых веб-сайтов сегодня основаны на API и просто говорят об отдельном интерфейсе (подробнее об этом ниже) - поисковыми систеамиы, такими как ElasticSearch, ведь они действительно важны для производительности - cronjobs и фоновыми заданиями с помощью таких инструментов, как Gearman или библиотек, таких как Crunz - знанием о кешировании с помощью Varnish, Redis и аналогичных мощных инструментов, которые значительно снижают расходы на хостинг, часто создают или разбивают проект. Базы данных Базы данных представляют собой отдельный раздел, потому что, помимо хорошего понимания реляционных баз данных, схема которых не часто изменяется (например, MySQL или PostgreSQL), разработчик должен знать о базах данных noSQL, таких как MongoDB, Redis или Cassandra, не говоря о графовых базах данных, таких как Neo4j. Что еще хуже, все это находится на сервере, под контролем разработчика. Есть также несколько удаленных решений, таких как Mongo-like RestDB или Firebase, принадлежащая Google, и т.д. Front End Здесь вообще полный хаос. Вот довольно исчерпывающий обзор того, что необходимо для здорового рабочего процесса front end: - NodeJS и NPM - Yarn - Препроцессоры и транспиллеры (такие как Babel) для таких вещей как Typescript, ES6, LESS, SCSS, SaSS - Builders and task runners like Grunt и Gulp - Фреймворки как VueJS, React, Angular - Module bundlers, такие как Webpack, Browserify, Rollup Дизайн В дизайне разработчик должен знать, как набросать прототип приложения, прежде чем преобразовать его в пригодный для использования формат, такой как HTML и CSS. Затем может быть добавлен интерактив с ложными JS включениями и только после того, как оболочка приложения будет завершена, а user experience дизайн и дизайн интерфейсов будет готов, начнется настоящая разработка. Это само по себе является огромной стартовой работой и требует специального набора инструментов, таких как: - Photoshop и/или Illustrator или альтернатива с открытым исходным кодом, например Gimp/Inkscape - хороший, быстрый редактор, такой как Atom или Sublime Text - подборщики рисунков, такие как подклассы и подборщики цветов, которые подбирают цвета, подходящие друг другу - сетчатые системы для CSS - все от Front End до имитации JavaScript - способы развертывания прототипа онлайн для клиентов, чтобы они могли увидеть его и дать вам отзывы (например, Ngrok). Логирование Чтобы эффективно следить за здоровьем приложения, разработчик должен иметь возможность отслеживать ошибки, иметь доступ к журналам и извлекать из них ценную информацию. Он должен иметь возможность распознавать и отмечать тенденции, а также уведомлять о всплесках в использовании процессора или ввода-вывода для предотвращения простоев - вовремя. Это немного связано с Devops, но требует своего определенного набора навыков. Разработчик может создавать свой набор инструментов, который поможет получить все необходимое для всех задач ведения журнала. Например, ElasticSearch для поиска журналов, Logstash для их сбора и Kibana для панели, в которой они отображаются для удобного мониторинга. Mobile Наконец, мобильная разработка. Webview как на iOS, так и на Android становится все более и более эффективным, появились PWA (прогрессивные веб-приложения), а нативные приложения уже теряют свое очарование из-за сложного процесса их разработки. Таким образом, разработчик полного стека должен быть знаком с PWA или переходить на что-то вроде React Native или полностью на webview, например, NativeScript, Tabris, Cordova, Phonegap, или другую реализацию, чтобы получить хорошее «клиентское приложение» для своего API (см. back end раздел выше). Так стоит ли становиться Full Stack разработчиком? Итак, после всего, стоит ли стараться? Прежде всего, следует отметить, что очень немногие full stack разработчики являются такими full stack – многие сосредотачиваются только на большинстве из этих технологий и аспектов, а не на всех, просто потому, что нельзя полностью все взять во внимание. Во-вторых, знание хотя бы небольшой части всего не сделает вас мастером определенного ремесла, но позволит вам понять, что входит в проект, и какие из этих технологий действительно нужны проекту. Это бесценный навык при делегировании, открытии агентства или просто перенаправлении существующей команды с утраченного пути на конкретный вектор работы. Возможно, я не JavaScript rockstar, Elasticsearch ninja, гуру MySQL, Devops маньяк или мобильный ретранслятор, но в моем случае full stack позволяет мне расправлять мои крылья, тестировать различные технологии и предлагать альтернативные, необычные решения для моих клиентов на фрилансе. Деньги могут приходить со всех сторон, и я могу заключать контракты от работы на серверной стороне до разработки плагинов WP и всего между ними, потому что я умеренно знаком со всеми этими вещами. Для меня full stack определенно стоит того. Если сравнивать с моими Flash-днями, когда я получал огромное удовольствие от работы (без JavaScript!), то зарплата была ниже, а проекты – гораздо сложнее получить.   Источник: https://www.sitepoint.com/full-stack-developer/

Для получения качественного кода, мы должны выполнять тестирование во время его написания (если не использовать TDD). Однако, трудно сделать выбор среди такого широкого круга PHP инструментов тестирования. Эта статья посвящена самым широко распространенным инструментам тестирования. В ней собрана обновленная информация по состоянию QA инструментов в 2017 году. PHPUnit PHPUnit  - это фреймворк PHP для тестирования. Он был разработан Себастьяном Бергманом (Sebastian Bergmann) в 2004 и является одним из многих доступных средств тестирования моделей РНР в процессе разработки. Сейчас доступна 6 версия фреймворка, требующая PHP 7. Cucumber Cucumber -  это фреймворк для создания тестирования по спецификациям. Он известен своими описательными сгенерированными текстами, которые очень удобно и просто читать. Официальной реализацией PHP для Cucumber является Behat. Ниже приведен пример из документации, который хорошо отображает выразительность фреймворка. Atoum Atoum – еще один фреймворк для тестирования PHP. Это автономный пакет, который можно установить через GitHub, Composer или исполняемый файл PHAR. Тесты Atoum очень читабельны, имеют выраженные имена методов и взаимосвязи. Selenium Selenium  - это инструмент для автоматического браузерного тестирования (интегрированное и приемочное тестирование). Он преобразует тесты в команды API браузера и утверждает ожидаемые результаты. Selenium поддерживает большинство доступных браузеров. Мы можем использовать Selenium с PHPUnit, используя расширение. Вот простой пример: Dusk Dusk из Laravel – еще один инструмент автоматизации браузера. Он может использоваться автономно (с chromedriver) или с Selenium. Он имеет простой в использовании API и охватывает все возможности тестирования, такие как ожидание элементов, загрузка файлов, управление мышью и т.д. Вот простой пример: Kahlan Kahlan – это полнофункциональная среда тестирования Unit & BDD, которая использует описательный синтаксис. Из приведенного выше синтаксиса видно, что он похож на тесты Behat. Kahlan поддерживает Stub-инг и Mock-инг (stubbing and mocking out of the box) без зависимостей, покрытия кода, отчетности и т.д. php_testability Последний пакет, о котором мы упомянем здесь – PHP Testability. Это инструмент статического анализа, который рассказывает о проблемах с тестируемостью в вашей программе и генерирует подробный отчет. Пакет в настоящее время не имеет помеченного релиза, на который можно полагаться, но вы можете безопасно использовать его в разработке. Вы можете установить его через Composer: Затем запустить его следующим образом: Сервисы непрерывной интеграции (CI) Важная часть в предоставлении кода при работе с командами – это возможность автоматически проверять код до его объединения с официальным репозиторием проекта. Большинство доступных сервисов/инструментов CI предоставляют возможность тестировать код на разных платформах и конфигурациях, чтобы убедиться, что ваш код безопасен для слияния. Существует множество сервисов, которые предлагают доступные цены, но вы также можете использовать инструменты с открытым исходным кодом: • PHPCI: (с открытым исходным кодом) • TravisCI: (бесплатно для проектов с открытым исходным кодом) • SemaphoreCI: (бесплатно для проектов с открытым исходным кодом) • Jenkins   Заключение Принять культуру тестирования кода сложно, но она понемногу развивается с практикой. Если вы заботитесь о своем коде, вы должны его протестировать! Перечисленные в этой статье инструменты и ресурсы помогут вам разобраться и начать работу.   Оригинальная статья на английском языке

Верстальщик сайтов – это специалист, который занимается созданием веб-страниц. Его работа заключается в том, чтобы при помощи различных элементов языка разметки веб-страницы перевести графические элементы дизайна (рисунки, шрифты, таблицы и т.д.) в понятный для браузера формат, то есть сверстать сайт. Работа верстальщика не очень сложная, но требует определенного уровня подготовки и большого внимания к деталям. На хороших специалистов практически постоянно существует большой спрос. На ITVDN все, кто заинтересован в изучении технологий для верстки веб-страницы, найдут необходимые видео уроки и материалы. А также курсы для «прокачки» практических навыков верстки сайта и Тренажер для навыков написания кода. Курсы записаны сертифицированными разработчикам и тренерами Microsoft. ITVDN рекомендует проходить обучение в такой последовательности:    HTML & CSS, автор Александр Петрик How to HTML & CSS, автор Сергей Раздобудько Photoshop. Базовый курс для web-разработчика, автор Сергей Воропаев JavaScript Essential, автор Дмитрий Охрименко How to JavaScript, автор Валерия Прокопенко Основы использования Git, автор Александр Пономаренко Twitter Bootstrap 3, автор Сергей Швайцер Создание адаптивного сайта с Bootstrap 3, автор Александр Пономаренко WordPress Starter, автор Артем Кондранин Практический курс по верстке лендинга, автор Сергей Рубец HTML5 & CSS3, автор Дмитрий Охрименко Также вас могут заинтересовать записи вебинаров ITVDN (все в свободном доступе): Верстаем сайт правильно Photoshop: зачем он нужен веб-разработчику? WordPress: создаем блог за час Скоростная верстка, или как упростить себе жизнь с Bootstrap 3 Интеграция верстки лендинга на CMS WordPress Адаптивный веб-дизайн: типы адаптивных макетов Семантика HTML5, создаем змейку, используя canvas Что надо знать для веб разработки. (реальная разработка + обзор вакансий) Создание веб-приложения с Angular 1.5, Firebase и Gulp Как решить проблемы верстки с помощью HTML5 Web Components Если вы планируете свое обучение с нуля, тогда наилучшим решением будет приобретение подписки ITVDN сроком от 3 месяцев. Это оптимальный срок, за который вы сможете научиться создавать красивые сайты, мастерски владея современным инструментарием  верстальщика.