CSS спрайты – это не новинка. С того момента, как их популяризовали на «A List Apart» в 2004, простые спрайты стали основной техникой в наборе инструментов большинства веб-разработчиков. Но, несмотря на то, что преимущества скорости спрайтов вполне понятны, их использование в современной веб-разработке редко обсуждается. Принцип остается тем же: это комбинирование нескольких изображений в один «основной» графический элемент, из которого в каждый момент времени отображаются только определенные части.

В этой статье мы рассмотрим простой способ создания отзывчивых CSS спрайт-анимаций, которые мало весят, хорошо отображаются на мобильных устройствах и даже интерактивны. Вам не нужны никакие специальные графические редакторы, а только немного понимания CSS и JavaScript. Приступим.

Продолжение перевода неофициальной документации Selenium для Python.
Перевод сделан с разрешения автора Baiju Muthukadan.
Оригинал можно найти здесь.

Содержание:

1. Установка
2. Первые Шаги
3. Навигация
4. Поиск Элементов
5. Ожидания
6. Объекты Страницы
7. WebDriver API
8. Приложение: Часто Задаваемые Вопросы

О Python на Хабре было много хороших статей. Как об особенностях реализации, так и о прикладных фичах, отсутствующих в других мейнстримных языках. Однако я с удивлением обнаружил (поправьте, если не прав), что есть одна важная тема, не раскрытая ни на Хабре, ни в русскоязычном интернете вообще. Эта статья будет посвящена такой штуке, как stack frame. Скорее всего она не скажет ничего, ну или может с учетом последнего пункта почти ничего нового опытным python-разработчикам, однако будет полезна новичкам (а может и вредна, но все примеры ниже).

Я постарался написать статью так, чтобы её было удобно читать, открыв параллельно repl и бездумно копировать туда код эксперементируя. Поэтому по возможности большая часть примеров имеет вид «однострочники в интерпретаторе».

Начнем мы немного издалека, с того что заметим, что Traceback это тоже объект, а потом найдем где там стековый кадр и уже перейдем к делу.

Сегодня объекты используются очень активно, хотя это трудно было предположить после выхода PHP 5 в 2005 году. Тогда я ещё мало что знал о возможностях этого языка. Пятую версию PHP сравнивали с предыдущей, четвёртой, и главным преимуществом нового релиза стала новая, очень мощная объектная модель. И сегодня, десять лет спустя, около 90% всего PHP-кода содержит объекты, не изменившиеся со времени PHP 5.0. Это убедительно говорит о том, какую роль сыграло внедрение объектной модели, неоднократно улучшавшейся на протяжении последующих лет. В этом посте я хотел бы рассказать о том, как всё устроено «под капотом». Чтобы люди понимали суть процессов — почему сделано так, а не иначе — и лучше, полнее использовали возможности языка. Также я затрону тему использования памяти объектами, в том числе в сравнении с эквивалентными массивами (когда это возможно).

Я буду рассказывать на примере версии PHP 5.4, и описываемые мной вещи справедливы для 5.5 и 5.6, потому что устройство объектной модели там почти не претерпело изменений. Обратите внимание, что в версии 5.3 всё не так хорошо с точки зрения возможностей и общей производительности.

В PHP 7, который пока ещё активно разрабатывается, объектная модель переработана не сильно, были внесены лишь незначительные изменения. Просто потому что всё и так хорошо работает, а лучшее — враг хорошего. Были добавлены возможности, не затрагивающие ядро, но здесь об этом речи не пойдёт.

В последние месяцы проблематика миграции работающих систем на open-source решения для хранения данных захватила умы отечественных разработчиков. Особой популярностью в роли целевой платформы пользуется PostgreSQL. Причин тому можно назвать несколько:

1. Пребывающая у всех на слуху политика импортозамещения, внедряемая правительством;
2. Популяризация PostgreSQL силами энтузиастов и развитие российского сообщества благодаря таким мероприятиям как PG Day и PGConf;
3. Расширение функциональных возможностей PostgreSQL, позволяющих разработчикам строить гибкие и «schema-less» приложения, не теряя при этом всех преимуществ СУБД, таких как честные транзакции, отказоустойчивость, возможности масштабирования и др.

Нам удалось убедиться в эффективности PostgreSQL несколько лет назад. Внедрение СУБД позволило ликвидировать серьезный технологический кризис на одном из крупных проектов компании. Подробный рассказ об этой success story состоялся на PG Day’14 Russia, прошедшем в прошлом году в Санкт-Петербурге. С тех пор нам довелось попробовать базу данных для решения широкого спектра проблем.

Занимаясь изучением алгоритмов обнаружения событий электрокардиограммы для исследовательской части дипломной работы, я обнаружил, что длительность R-R интервала кардиограммы, вычисленная даже с точностью до второго знака после запятой, достаточно точно характеризует сердечнососудистую систему конкретного человека. Поскольку я уже довольно давно увлекаюсь фрактальной геометрией, в моей голове моментально родилась мысль, как можно придать «личных» качеств какому-нибудь простейшему фрактальному объекту.

Так появилось «Электрокардиографическое дерево Пифагора».

Сегодня все больше приложений создается сразу для нескольких мобильных платформ, а приложения, созданные изначально для одной платформы, активно портируются на другие. Теоретически можно полностью писать приложение «с нуля» для каждой платформы (т.е. фактически «кроссплатформенной» оказывается только идея приложения). Но это означает, что трудозатраты на его разработку и развитие будут расти пропорционально количеству поддерживаемых платформ. Если же многоплатформенность изначально заложить в архитектуру приложения, то эти затраты (плюс, в особенности, затраты на поддержку) могут существенно сократиться. Вы разрабатываете общий кроссплатформенный код один раз — значит используете его на текущих (и будущих) платформах. Но в этом случае сразу возникает несколько взаимосвязанных вопросов:

• Должна ли быть граница между общим (кроссплатформенным) и нативным (специфичным для данной платформы) кодом?
• Если да, то где и как провести эту границу?
• Как сделать так, чтобы кроссплатформенный код было удобно использовать на всех платформах, как на тех, что надо поддержать сейчас, так и на тех, чья поддержка, вероятно, может потребоваться в будущем?

Конечно, ответы на эти вопросы зависят от конкретного приложения, предъявляемых к нему требований и накладываемых ограничений, поэтому универсальный ответ найти, по всей видимости, невозможно. В этой статье мы расскажем, как мы искали свои ответы на эти вопросы в процессе разработки мобильного клиента Parallels Access для iOS и Android, какие архитектурные решения были приняты и что в итоге получилось.

Хочу сразу предупредить, что букв в этом посте много, но дробить тему на куски не хотелось. Поэтому запаситесь терпением.

Эта статья является попыткой ответа на старый вопрос для собеседований: «Что же случается, когда вы печатаете в адресной строке google.com и нажимаете Enter?» Мы попробуем разобраться в этом максимально подробно, не пропуская ни одной детали.

Примечание: публикация основана на содержании репозитория What happens when...

Представленный контент изобилует большим количеством терминов, в переводе некоторых из них могут присутствовать различные неточности. Если вы обнаружите какую-то ошибку в нашем переводе — напишите личным сообщением, и мы всё исправим.

Мы перенесли перевод в репозиторий GitHub и отправили Pull Request автору материала — оставляйте свои правки к тексту, и вместе мы сможем значительно улучшить его.

Часть 1. Введение. Создание класса и добавление свойств. Расширение класса С++ с помощью Blueprint.
Часть 2. Классы геймплея. Структуры. Отражение (reflection) в Unreal. Object/Actor итераторы. Менеджер памяти и сборщик мусора.
Часть 3. Префиксы в именах классов. Целочисленные типы. Типы контейнеров. Итераторы контейнеров. Цикл For-each, хеш-функции.
Часть 4. Бонусная. Unreal Engine 4 для Unity разработчиков.



Эта статья является переводом части документации по UE4. Оригинальную статью вы можете найти пройдя по это ссылке.

Думали ли вы когда-нибудь о том, что однажды слишком быстро втянулись в веб-программирование на PHP? И вот уже прошло много лет, у вас хороший опыт, и вы не думаете ни о каких других способах „делать“ веб, кроме как на PHP. Может быть, у вас возникают сомнения в правильности выбора, однако непонятно, как найти способ быстро его проверить. А хочется примеров, хочется знать, как изменятся конкретные аспекты деятельности.

Сегодня я попробую ответить на вопрос: «А что если вместо PHP писать на Python?».

Сам я долгое время задавался этим вопросом. Я писал на PHP 11 лет и даже являюсь сертифицированным специалистом. Я научился его «готовить» так, чтобы он работал в точности, как мне надо. И когда я в очередной раз читал на Хабре перевод статьи о том, как всё в PHP плохо, я просто недоумевал. Однако подвернулся случай пересесть на Ruby, а потом и на Python. На последнем я и остановился, и теперь попробую рассказать вам PHP-шникам, как нам питонистам живётся.

Не так давно зарелизилась новая версия Python 3.4 в changelog которой вошло много «вкусностей». Одна из таких — модуль asyncio, содержащий инфраструктуру пригодную для написания асинхронных сетевых приложений. Благодаря концепции сопрограмм (coroutines), код асинхронного приложения прост для понимания и поддержки.

В статье на примере простого TCP (Echo) сервера я постараюсь показать с чем едят asyncio, и рискну устранить «фатальный недостаток» этого модуля, а именно отсутствие реализации асинхронного HTTP сервера.

Улучшаем наш распределённый хостинг картинок. В этой части мы поговорим о конфигурировании приложения и подключим защиту от csrf. Затем, на примере создания миниатюр картинок, научимся работать с блокирующими задачами, запускать корутины параллельно и обрабатывать возникающие в них исключения.

Впервые слышите о tornado? Слышали, но боялись асинхронности? Смотрели на него более полугода назад? Тогда я посвящаю эту статью вам.

В последнее время в вебе идет тенденция к «утончению» сервера и «утолщению» клиента. С каждым днем вакансий Full-stack разработчиков становится все больше, а чистого бэкенда все меньше. Последние 2 года я работаю разработчиком Ruby on Rails и в скором будущем без работы остаться не хотелось бы. Поэтому я начал рассматривать варианты изучения клиентского фреймворка.

Вариантов было несколько:

• Meteor
• Angular
• Ember

Но остаться должен только один. Meteor предлагает интересную концепцию – общий код клиента и сервера, но он пока сыроват и мне не хотелось оставлять прекрасный язык Ruby. Поэтому Метеор отпал. Так как Ember был похож на Rails (магия, convention over configuration), то был выбран именно он. Помимо этого, очень симпатично выглядел шаблонизатор Handlebars по сравнению с директивами Angular.

Выбор сделан. Вот тут и начались проблемы.

Идея игры

У меня было давнее желание разработать полноценную игру для социальных сетей, но не было интересных идей. Однажды я увидел в аппсторе игру в слова, которая была только на английском языке. Мне захотелось сделать аналогичную с русским словарем.

Смысл игры – составлять слова из соприкосающихся гексагонов. В игре 3 режима:

• игра против времени (при поиске слов добавляется 1 секунда за кажду букву);
• найти выход за отведенное время (найти слова и тем самым проложить путь к выходу из центра);
• свободный режим (поиск слов и завершение в любое время).

Привет, Хабр!

Наш прошлый перевод нетрадиционного обзора React многим понравился, и, конечно, люди стали сравнивать Реакт с популярным AngularJS. Сегодня мы публикуем перевод статьи «An Unconventional Review of AngularJS» от того же автора (Джеймса Шора, ведущего проекта Let’s Code: Test-Driven JavaScript). Поклонникам Angular просьба сохранять спокойствие.



AngularJS это все, что я ожидаю от фреймворка. И это не хорошо.

В ноябре, декабре и январе я обозревал AngularJS для серии «front-end frameworks» в рамках проекта Let’s Code JavaScript. Суммарно я провел 40 часов изучая, программируя и решая задачи. Как обычно, моей целью было изучить AngularJS создавая приложение.

Angular это, наверное, самый популярный фронт-энд фреймворк сейчас. Его разрабатывает команда из Google, что сразу внушает доверие. Он настолько популярен, что входит в акроним. Angular это часть так называемого стека «MEAN»: MongoDB, Express, AngularJS, Node.JS. Самая что ни на есть передовая технология.

Angular описывает себя как инструмент для улучшения ХТМЛ. Он позволяет расширить ХТМЛ новыми определениями — директивами — которые превращают статичный ХТМЛ-документ в динамический шаблон. Директивы могут быть атрибутами или тегами (или даже комментариями или классами, но это уже не совсем обычная история), и они превращают статичный ХТМЛ-документ во что-то живое и дышащее, на первый взгляд без добавления JavaScript.

Вечер добрый, хабр. На прошлой неделе стартовал курс «MongoDb for developers» от 10gen, о котором уже писали на хабре. Если вы смотрели уроки, то можете смело проходить мимо. Остальным — добро пожаловать.

В этой статье будет изложен основной материал первой недели обучения. Если аудитория проявит интерес — то подобные посты будут выходить в конце каждой недели.

Мы вкратце рассмотрим, что представляет собой MongoDB, сравним разницу в структурах данных между монго и реляционными базами для простого веб-приложения, поиграемся с шеллом, и немножко покодим на пхп и питоне.

Зачем эта статья? Предвижу подобный вопрос. Не все успели записаться на курсы, не у всех есть достаточно свободного времени, не у всех хорошо обстоят дела с восприятием устной английской речи. Ну и для гуглящих подобный материал не помешает.

Всем привет! Меня зовут Сергей, и в Яндексе я работаю в команде автоматизации тестирования сервисов монетизации. Перед каждой командой, которая занимается задачами автоматизации тестирования, встает вопрос: «Какой [фреймворк|инструмент] выбрать для написания своих тестов?» В этом посте я хочу помочь вам на него ответить. Если быть конкретнее, речь пойдет об инструментах тестирования на языке Python, но многие из идей и выводов можно распространить на другие языки программирования, поскольку подходы часто не зависят от конкретной технологии.



В Python существует множество инструментов для написания тестов и выбор между ними неочевиден. Я опишу интересные варианты использования PyTest и расскажу о его [плюсах|минусах|неявных возможностях]. В статье вы найдёте развёрнутый пример использования Allure, который служит для создания простых и понятных отчётов автотестов. Также в примерах будет применяться фреймворк для написания матчеров — Hamcrest для Python. Надеюсь, что в итоге, те, кто сейчас в поиске инструментов для тестирования, смогут на основе изложенных примеров быстро внедрить функциональное тестирование в своем окружении. Те же, кто уже использует какой-то инструмент, смогут узнать новые подходы, варианты использования и концепции.

Продолжение перевода статей о Django с сайта effectivedjango.com. Наткнулся я на этот сайт во время изучения данного фреймворка. Информация размещенная на этом ресурсе показалась мне полезной, но так как нигде не нашел перевода на русский, решил сделать сие доброе дело сам. Этот цикл статей, как мне думается, будет полезен веб-разработчикам, которые делают только первые шаги в изучении Django.

Введение

В статье хотелось бы поднять вопросы отличия использования Python для web-разработки по сравнению с оной на PHP. Надеюсь, статья не приведет к холиварам, так как она вовсе не о том, какой язык лучше или хуже, а исключительно о технических особенностях Python.