С удивлением не обнаружил в выдаче поиска по Хабру публикаций по проблеме использования emoji в интерфейсе приложений публикуемых в App Store благословенной Apple. Так что заранее извиняюсь если всё-таки повтор.



Суть проблемы в том что Apple запрещает использование emoji в интерфейсе приложений. Судя по всему это началось примерно осенью 2018 (как минимум весной 2018). Но, возможно, и раньше я сильно не углублялся в хронологию проблемы. Интернет полнится сообщениями разработчиков, приложения которых отклонены по причине наличия emoji в интерфейсе приложения. Более того, заворачиваются даже обновления ранее опубликованных приложений! Некоторые сообщают об отказе публикации из-за наличия emoji в скриншотах приложения! Обычно отказ Apple выглядит как:

From Apple

Guideline 5.2.5 — Legal — Intellectual Property

Your app does not comply with the Guidelines for Using Apple's Trademarks and Copyrights. Specifically, your app includes:

— Apple trademark, emojis, imagery — or likeness

Согласитесь, довольно интересная позиция от компании, которая была одним из (если не единственным) основоположников популяризации emoji… Под катом я выдвину пару предположений о причинах и пару способов решения проблемы. В частности как я в итоге опубликовался в App Store с приложением в котором изначально emoji были основной идеей.

Поковырял ещё некоторое время в Dart, идея хорошая, но многие вещи, так скажем, не понятны.

Хочу обсудить концепцию метаданных. Которой я всё пытался найти применение и мне кажется в ней что-то есть, но реализация доступа к метаданным — из рук вон плоха. Особенно для нового языка, который должен был учесть существующий опыт и т.д. и т.п.

Version: 0.2

Возникла у меня потребность атомарного обновления в реальном времени страницы у некоторого количества пользователей в зависимости от действий других пользователей (не гербалайф чат). Понятное дело, можно всё выкинуть в помойку и, по-молодецки, запилить с нуля на tornado/twisted.web, но явно не самый продуктивный путь (да и я не мо́лодец ни разу) когда всё что надо — уже работает на Django и нужно всего-то чуть-чуть… Естественным образом, по сути своей, сюда просится WebSocket. И всё бы ничего но Django WSGI приложение, а этот стандарт не предполагает таких выкрутасов даже близко (пока). Гугления интернетов навели, в очередной раз, на труд известного python-гуру kmike (это без сарказма, т.к. его работы выручали меня лично уже не однократно, за что нижайший ему поклон!).

Итак если вы хотите скрестить ваш Django проект с websocket посредством js библиотеки socket.io или sockjs — вилькоммен!

Про БЭМ (методология написания CSS от Яндекс — Блок__Элемент_Модификатор ← наиболее правильная запись расшифровки) нынче можно услышать на каждом шагу. Дело оказалось благим и покатилось по миру. Яндекс даже полез в W3C (связано это или нет — не знаю, но надеюсь, что да — [на самом деле нет]).

Думаю многие, кто ещё не пробовал, но прочитал описание БЭМ, задаются справедливым вопросом: «какая практическая польза от всего этого действа?» На самом деле, не смотря на то самое развёрнутое описание, конкретно уловить основную «фишку» довольно сложно. Описано конечно много плюсов и общее ощущение от методологии положительное, и кажется, что вроде как и не плохо бы попробовать, но нехватает чего-то конкретного. Прямо вот примера на живом что ли. Вот у меня сайт, вот вёрстка не по БЭМ, почему я должен всё менять? Особенно, если учесть тот факт, что БЭМ в принципе отметает все селекторы кроме классов, неужто за это время столько умных мужей в W3C не осознали, что всё настолько неправильно?

За сим возьму на себя смелость привести несколько примеров с которыми вы (конечно если вы каким-то образом связаны с вёрсткой) сталкиваетесь, не побоюсь этого слова, ежедневно. И что изменится в таких ситуациях если бы вёрстка была изначально выполнена в БЭМ.

В процессе работы над текущими проектами возникла ситуация когда «вдруг» перестал парситься сайт трекингов Почты России. В интернетах даже немного побурлили по поводу «ужасной» новой защиты и т.п. В тех же интернетах всплыла тогда информация, что у Почты России имеется-таки API. Не совсем человеческий (т.е. по протоколу SOAP) но какой-никакой существует и кто-то им даже, якобы, пользуется. Я сообщил шефу, шеф написал письмо на Почту России (электронное, на удивление) и оказалось — да. Всё это действительно есть и вроде бы даже работает. Видимо создали сервис ещё тогда.

Под катом будет линк на рабочий класс клиента (на python) к API Почты России и немного подробностей работы с ним.

UPD: Обновлено для Ubuntu 13.10 x64 сам клиент SafenetAuthenticationClient придётся попросить у техподдержки Аладдин.

Случилось так, что я решил организоваться как самостоятельный разработчик и открыл ИП. Долго я маялся с выбором банка для расчётного счёта, т.к. нужно было что-то максимально платформо-независимое — сильно не хотелось заводить винду только для интернет-банкинга, походы же в отделение банка, естественно, не рассматривались в принципе, да и дороже это выходит. В итоге я остановился на ПромСвязьБанке, в надежде, что ключи шифрования у них можно получить в виде файлов/на обычной флешке, а не на eToken'е (дело происходит в Омске). Я даже честно пытался обзванивать банки, на которых остановился и узнать на каком носителе выдаются у них ключи, но день потрачен был зря — ни в одном банке добраться до вменяемого специалиста мне не удалось. В итоге в выбранном банке услуга создания ключей оказалась довольно муторной. При генерации ключей я попытался выбрать в качестве носителя флешку, а не полученный eToken, но позже я узнал, что в этом банке «главная» подпись может быть только на eToken а для отчётов можно генерить ключи на флешку. В общем далее руководство как пользоваться интернет-банкингом с eToken под Ubuntu 12.04 x64.

Сегодня неожиданно понял, что скрипты — это сила (спустя несколько месяцев использования fabric). На самом деле 30 минут потраченные на написание адекватного сценария избавляют от многих совокупных часов повторения ненужных действий. Для упрощения жизни адептов python'а существует такой прекрасный модуль как fabric. И я хочу поделиться парой кусков своего fab-файла как пример упрощения жизни девелопера.

Это будут функции: «умный» комментатор локальных файлов и git-коммитер.

Это шпаргалка раскрывающая раздел «Интеграция Selenium тестов» статьи Настройка Jenkins для django проекта с нуля. А именно как запускать Selenium тесты на удалённом сервере Jenkins у которого нет монитора и форточек.

Введение

В процессе разработки, создавая новый функционал, всё чаще широкими мазками стал задевать старый код чем разрушал логику его работы. Это заставило всё-таки написать юнит и интеграционные тесты для старого кода и автоматизировать их запуск, т.к. гонять руками все тесты как-то грустно. Как раз вспомнилось недавнее руководство по CI Django в Jenkins и довольно старое по Webtest в Django. В итоге была совершена попытка поднять Дженкинса, но он как-то на моей убунте не взлетел и я грешным делом вспомнил про TeamCity. «Раз уж пишу в PyCharm и нашёл к нему подход, то, наверно, и TeamCity осилю, ведь конторка-то одна!» — подумалось мне… В общем-то я оказался прав, и, пока мне позволяет карма, решил подарить вам ультраполезный (и мегаподробный), в отличие от моего предыдущего, мануал :)

Итого: кому требуется руководство по поднятию интеграционного сервера TeamCity, и тестирование в нём Django проектов c тестами nose и webtest в виртуальном окружении python с автоматическим его (окружения) обновлением — добро пожаловать под кат.

Осторожно! Для работы TeamCity требуется (согласно документации) sun/oracle версия JVM…

Небольшое HowTo для начинающих python-программистов о том как извне проверить некоторые переданные в функцию значения. На самом деле мне это понадобилось в Django, но ничего специфичного для фреймворка в этом нет и…

UPD Лирическое отступление: Изначально тут я написал много глупостей в силу своего кривого понимания работы декораторов. Теперь решение гораздо более правильное и прямое. Более того я даже внятно могу его объяснить, за что огромная благодарность комментаторам.

Вводная

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