Python. Developer/QA Automation.
Цель этой статьи — показать как мы можем сконфигурировать два и более контейнеров, чтобы они могли взаимодействовать друг с другом. В этой статье мы сделаем следующее:
Создадим образ Docker используя простой веб-сервис с использованием Python и Flask.
Запустим два отдельных контейнера
Создадим сеть в Docker
Объединим контейнеры используя созданную сеть
Роберт Мартин представил принципы SOLID в 2000 году, когда объектно-ориентированное программирование стало настоящим искусством для программистов. Каждый хочет создать что-то долговечное, которое можно использовать повторно, насколько это возможно, с минимальными изменениями, которые потребуются в будущем. SOLID - идеальное название для этого.
Фактически, объектно-ориентированное программирование работает лучше всего, когда мы можем отделить то, что останется, от того, что изменится. Принципы SOLID помогают разделять это.
Мне лично нравится идея, лежащая в основе принципов SOLID и я многому из нее научился.
В этой статье вы узнаете:
Что такое Cypress и когда его стоит использовать.
Основы тестирования с использованием Cypress.
Расширенные команды Cypress.
Взаимодействие с элементами пользовательского интерфейса.
Лучшие практики с использованием Cypress.
В этой статье мы изучим полиморфизм, разные типы полиморфизма и рассмотрим на примерах как мы можем реализовать это в Python.
Что такое полиморфизм?
В буквальном значении полиморфизм означает наличие разных форм.
Полиморфизм — очень важная идея в программировании. Она заключается в использовании единственной сущности(метод, оператор или объект) для представления различных типов в различных сценариях использования.
Давайте посмотрим на пример:
Пример 1: полиморфизм оператора сложения
Вы можете любить или ненавидеть их, но вы не можете игнорировать их.
В течение моей профессиональной карьеры я работал с множеством различных типов разработчиков. Мне нравилось работать с некоторыми из них, но в работе с другими я только надеялся закончить проект и больше никогда не работать вместе.
В этой статье я перечислю некоторые типы этих разработчиков.
1. Продавец дыма
Этот тип разработчика всегда что-то кому-то обещает — заказчикам, вашим начальникам или другим разработчикам. Но когда что-то действительно нужно сделать, то если он может, он сбегает в другой проект или пытается спихнуть всю работу другим разработчикам. Продавец дыма очень опасен, так как может привести вас к серьёзным проблемам. Он продаёт продукт, который он и не собирается делать, с технологиями, которые никогда не использовал.
Если вы не знаете продавцов дыма, вы подумаете, что они знают всё, о чём говорят и что могут помочь вам. Но скоро вы поймёте, что это ложь и вы не можете рассчитывать на них.
2. Мультизадачный разработчик
Неплохой разработчик. Обычно этот тип обладает классными техническими навыками, но так занят, что никогда не фокусируется на чём-то одном и вы никогда не можете рассчитывать на него в проекте среднего размера. Получить его внимание довольно тяжело и хотя он иногда имеет блестящие идеи, требуется много усилий, чтобы убедить его что-то закончить.
3. Специалист с сертификатами
У меня пока нет большого опыта работы с данным типом разработчика, который всё измеряет своими сертификатами. Я думаю, что необходимо иметь хорошую базу с глубокими знаниями в области вашей работы. Я не против сертификатов. Но в большинстве случаев иметь сертификат, если это не подтверждено реальным опытом, не стоит многого.
Быть веб-программистом это тяжёлая работа. Долгие часы, связанные с тем, что мы не получили ничего кроме проблем, могут сделать нашу работу невыносимой. Не говоря уже о дедлайнах и неразумных заказчиках. Ах, и том факте, что все мы будем жертвами нескончаемой войны браузеров.
Так почему же мы делаем то, что мы делаем? Мы любим программирование, мы любим создание функциональных, виртуальных миров где люди могут получать информацию, размещать картинки и встречать других людей. Мы любим принимать правила и обходить их. Мы любим публиковать коллекции кода, который в какой-либо день может стать настолько прибыльным как, например, Facebook или Digg.
Со всем тем вознаграждением, которое приходит к вам как к программисту, ваша работа может также подавлять вас. Справляться со стрессом который создаёт ваша работа — это важное умение. Я, как программист, составил для вас перечень способов, которые помогут вам остаться в здравом уме.
В стандартной библиотеке питона содержится специализированный тип "namedtuple", который, кажется, не получает того внимания, которое он заслуживает. Это одна из прекрасных фич в питоне, которая скрыта с первого взгляда.
Именованные кортежи могут быть отличной альтернативой определению классов и они имеют некоторые другие интересные особенности, которые я хочу показать вам в этой статье.
Односторонние зеркала являются элементами фильмов, ТВ-шоу и юзабилити-лабораторий.
Одностороннее зеркало (или двустороннее, зависит от того, кого вы спрашиваете) является постоянным инструментом допросов, психологических экспериментов, фокус-групп и юзабилити-тестов.
Одностороннее зеркало представляет собой специальный кусок стекла, освещённый с одной стороны, чтобы позволить наблюдать за людьми, находясь по другую сторону от стекла.
Эта технология, на самом деле, является достаточно старой и идущей от "прозрачного зеркала", запатентованного в 1903 году.
Исследователи однажды решили, что одностороннее зеркало является необходимым в работе, но в последние несколько лет я вижу, что компании уходят от его использования. Здесь некоторые преимущества и недостатки одностороннего зеркала.
Когда я говорю людям, что многоточие (…) это самый поразительный символ из всех, то большинство людей смотрят на меня как на сумасшедшего. Прежде чем вы тоже окрестите меня сумасшедшим, позвольте мне попытаться объяснить.
В течение десятилетий дизайнеры интерфейсов использовали многоточие, чтобы выражать все важные для пользователей детали. Как вы скоро увидите, эти 3 точки могут собрать довольно много значений в их небольшом пространстве.
Давайте посмотрим на 5 различных путей, в которых многоточие было использовано в дизайне интерфейсов, сквозь годы их развития. К концу рассказа, вы, может быть, обретёте новое восприятие этого маленького, впечатляющего символа.
На этой неделе мы приветствуем Katie McLaughlin(@glasnt)! Она является ключевым разработчиком проекта BeeWare. Вам следует воспользоваться моментом и заглянуть на её профиль на гитхабе, что бы узнать в каких интересных проектах она принимала участие. Кэти также имеет небольшой, забавный вебсайт и была докладчиком на PyCon 2016. Давайте познакомимся с ней поближе!
Можешь рассказать нам немного о себе?(хобби, образование, что-то ещё):
Добрый день! Я австралийка, родилась в Брисбене, но сейчас живу в Сиднее. Я получила степень бакалавра информационных технологий и нахожусь в ИТ-индустрии почти 10 лет. Я побывала во множестве ролей и была связана с кучей разных технологий, но в большинстве своём это были сферы веб-хостинга и облачных технологий. Когда я не за компьютером или не на конференции, я наслаждаюсь кулинарией и изготовлением гобеленов.
Добро пожаловать в советы по Scrapy от профессионалов! В этом месяце мы поделимся несколькими уловками, чтобы помочь ускорить вашу работу связанную с веб-скрапингом. Как ведущие мэйнтейнеры Scrapy мы сталкиваемся с каждыми препятствием, которое вы можете себе представить. Так что не волнуйтесь — вы в надёжных руках. Не стесняйтесь контактировать с нами в твиттере или фейсбуке с любыми предложениями для будущих статей.
В эру одностраничных приложений и тонн AJAX-запросов на одной странице множество веб-сайтов заменили кнопку навигации "вперёд/назад" на причудливый механизм бесконечной прокрутки страницы. Веб-сайты использующие этот механизм загружают новую сущность каждый раз, когда пользователь достигает конца страницы при вертикальной прокрутке(вспомните Twitter, Facebook, Google Images). Даже несмотря на то, что UX-эксперты утверждают что механизм бесконечной прокрутки предоставляет чрезмерное количество данных для пользователей, мы видим увеличивающееся количество веб-страниц прибегающих к предоставлению бесконечного списка результатов.
Мне очень захотелось поделиться опытом и я хотел бы поговорить о том, почему важно проверять значения возвращаемые функцией. В качестве примера возьмём python и ctypes. Некоторое время назад я столкнулся с достаточно интересным багом суть которого сводилась к тому, что при запуске скрипта на Linux-системе были неправильные данные, но не было трэйсбэка, а на Windows-системе сразу же получали трэйсбэк. Исследование кода показало, что виноваты были некорректные данные даты приходящие в функцию strptime(). Теперь, давайте, посмотрим на пример работы с функцией strptime() в питоне.