[Chrome] Проблемы со сглаживанием шрифтов

Для разрабатываемого нами приложения мы решили использовать шрифт с разным начертание по толщине (или как еще говорят, по насыщенности). Минимальная толщина шрифта, которую мы используем, это 300 (font-weight: 300). Шрифт подключаем через @font-face с указанием на хост, от куда его нужно брать и при этом используем два формата шрифтов — WOFF и TTF. Все это должно помочь нам достичь единства отображения шрифта на разных окружениях. И да, это, конечно же, работает, но тут, как всегда, возникла небольшая неприятность — в браузере Chrome для Windows шрифт при небольших размерах и толщиной 300 отображался «рвано», что делало его плохо читаемым.

В сети я нашел несколько топиков с обсуждением похожих проблем, где в качестве альтернативного решения предлагалось отказаться от использования шрифтов в формате WOFF, с которым по умолчанию работает Chrome, и использовать только TTF, но в данном случае мне это все равно не помогло.

А потом мне попалось обсуждение, где люди пишут, что проблема связана с багом в Chrome, и что она уже исправлена в версии Chrome 38. И действительно, в новых версиях браузера проблема со шрифтами уже не стоит так остро:

[Chrome] Проблемы со сглаживанием шрифтов

[Android] Перехват HTTPS-трафика с помощью прокси-сервера

Эта заметка является продолжением той, в которой я расписал, как можно проанализировать незащищенный трафик, исходящий от мобильного приложения к серверу. Теперь настало время поговорить о защищенном трафике. Далее будем считать, что сетевой обмен происходит по протоколу HTTPS.

Как и раньше, помочь нам в этом деле могут такие известные и популярные прокси-серверы, как Charles, Fiddler, Burp Suite. Fiddler работает только под ОС Windows (ибо написан на .Net), а Charles и Burp Suite являются кроссплатформенными инструментами, работающими как под Windows, так и под Mac.

Для того, чтобы эти прокси-серверы могли взаимодействовать с защищенным трафиком, необходимо в систему (в данном случае в Android) установить их доверенный сертификат. К слову, это еще не успех, т.к. часто бывает, что приложения все равно отвергают липовый сертификат (и правильно ведь делают!).

В моем случае я использовал Fiddler с его сертификатом, и трафик от части приложений был виден (Facebook, Fourquare…), но к сожалению не для тех приложений, которые мне действительно были нужны для анализа.

И тут на помощь пришел Burp Suite. Его сертификат был «скушен» недоверчивыми приложениями и таким образом я смог получить доступ к защищенному трафику и впоследствии проанализировать его. Возможно, сертификат от Charles тоже помог бы в этом, но, честно сказать, я еще не пробовал.

SSL-сертификат в Burp Suite

[macOS] Ограничение скорости Интернета

Есть несколько способов, чтобы ограничить скорость сетевого трафика в Mac OS (бывает полезно для тестирования ПО в условиях медленного Интернета). Наиболее интересным вариантом является графическая утилита Network Link Conditioner от самой Apple, которая имеет ряд уже встроенных профилей различных скоростей сетевого соединения (3G, DSL, Edge и пр.)

Скачать данную утилиту можно непосредственно на сайте разработчика в разделе «Downloads» (https://developer.apple.com/downloads/), которая входит в состав пакета «Hardware IO Tools for Xcode». После установки утилита будет доступна через оснастку  «System Preferences».

Network Link Conditioner

Обновление ASUS WL-520GU на прошивку DD-WRT

На днях перепрошил свой старенький, но тем не менее, работающий верой и правдой, маршрутизатор ASUS WL-520GU. Перешел со стокой прошивки (последняя версия 7.0.1.45) на стороннюю DD-WRT. Причина — более продвинутые возможности и настройки + вечное желание пощупать чего-то новенького 🙂

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

Вот что нужно сделать (инструкция для Mac OS):

  1. Скачать этот архив. Он содержит три файла — «легкую» (устанавливается первой) и стандартную версию прошивки DD-WR (v24-sp2), а также стоковую прошивку ASUS WL-520GU (на случай форс-мажора, чтобы можно было откатиться назад).
  2. В настройках роутера установить для него IP-адрес 192.168.1.1.
  3. Перевести роутер в режим восстановления — для этого отключаем роутер, зажимаем углубленную кнопку «Reset» (черного цвета) и включаем роутер в сеть. Кнопку «Reset» удерживать до тех пор, пока индикатор «Power» не начнет мигать с частотой один раз в секунду. Также советуют отключить от роутера все сетевые кабели, за исключением того, что связывает его с компьютером.
  4. Теперь в сетевых настройках Mac OS нужно указать IP-адрес 192.168.1.2 (маска 255.255.255.0, шлюз 192.168.1.1). Теперь неплохо бы убедиться, что компьютер видит роутер — нужно пропинговать IP-адрес 192.168.1.1. Если видит, то можно переходить к следующему пункту. Если нет, значит где-то есть ошибочка.
  5. Настало время залить в роутер «легкую» версию прошивки DD-WR. Делается это через TFTP, который по умолчанию уже имеется в Mac OS. Открываем терминал, переходим в папку, куда распаковали архив с прошивками, и вводим следующие команды:
  6. tftp
    tftp> connect 192.168.1.1
    tftp> binary
    tftp> rexmt 1
    tftp> timeout 60
    tftp> put dd-wrt.v24_mini_asus.trx
  7. Прошивка должна отправится в роутер. После чего нужно подождать минуты три и выключить роутер, а затем снова его включить. Опять подождать, когда он загрузится. Теперь в браузере ввести http://192.168.1.1, должна открыться страница вашей новой прошивки DD-WR.
  8. Через интерфейс DD-WR залить стандартную прошивку (dd-wrt.v24-17990_NEWD_std-nokaid_usb.bin).

Включение цветовой схемы в Git

Было:

git_whitout_color

Хочется видеть:

git_with_color

Для того, чтобы задействовать цветовую схему, в файле .gitconfig (если работаете из под root’а, то находится в директории /root) нужно лишь добавить следующие строчки:

[color]
ui = auto

Белый экран в приложении Adobe Creative Cloud

Решил перейти на платную подписку Adobe Creative Cloud для фотолюбителей, которая включает в себя Photoshop и Lightroom (+ Lightroom Mobile). Цена годовой подписки составляет 3588 рублей, что в общем-то, не так и много.

Первым делом установил Creative Cloud, через которое уже осуществляется вся работа с приложениями Adobe. Ага, установил, но после запуска и авторизации мне отобразилась белая страница и дальше ничего. Перезапускаю — проблема остается. Эй, Adobe, я же был готов вам даже деньги заплатить, а тут такой фейл с вашей стороны — я даже не могу приступить к нормальной работе!

Полез читать форум поддержи Adobe и нашел тред с соответствующей проблемой. Решение, которое мне помогло (для Mac OS):

  • Открыть директорию Library/Application Support/Adobe/OOBE/
  • Удалить файл opm.db
  • Перезапустить Creative Cloud

После перезапуска приложение заработало нужным образом.

Проблемы с установкой Adobe Flash Player

При попытке установить Adobe Flash Player получаю следующее сообщение:

«Потеря связи. Попытка повторного соединения…»

Screen Shot 2014-06-28 at 14.23.40

Причина проблемы оказалась в том, что в «блэк-листе» файла hosts были указаны ряд серверов Adobe (даже не спрашивайте, зачем это было сделано!), которые, как оказалось, также используются и установщиком Flash Player. Удалил записи из hosts, перезапустил установщик — все заработало!

Часто используемые команды Git

В последнее время приходится более активно работать с Git-ом, активнее, чем просто посмотреть список изменений через тот же GitHub’e (хотя, в принципе, для тестировщика этого вполне достаточно).

Далее следует небольшой список активно используемых мной команд (шпаргалка на будущее!):

  • git branch – показать список локальных веток
  • git branch -r – показать список удаленных веток
  • git branch -a – показать список всех веток (локальных и удаленных)
  • git checkout <branch> / <commit> – переключиться на ветку / коммит
  • git checkout -b <branch> – создать новую ветку
  • git branch -D <branch> – удалить существующую ветку
  • git push origin :<branch> – удалить удаленную ветку на сервере
  • git fetch – взять изменения с сервера
  • git pull – взять изменения с сервера и смержить их с текущей локальной веткой
  • git pull origin – взять изменения с сервера и смержить их о всеми локальными ветками
  • git reset —hard origin/<branch> – возврат к изменениям, актуальным на удаленным сервере
  • git status – показать существующие изменения (текущее состояние репозитория)
  • git log – показать историю коммитов (q – выход из режима просмотра)
  • git log -p <file> – показать историю файла (с просмотром изменений)
  • git log —stat —graph — показать историю изменений веток (визуальное представление)
  • git add . – добавить все произведенные изменения в индекс
  • git add -p . – интерактивный режим добавления изменений в индекс (можно указывать, что нужно добавить в коммит, а что нет)
  • git diff —cached – показать различия между индексом и последним коммитом
  • git rm <file> – удалить файл
  • git commit -m «Commit name» – сделать коммит
  • git commit -a -m «Commit name» – добавить изменения в индекс и сделать коммит
  • git push origin <branch> – залить коммиты на удаленный сервер в указанную ветку
  • git push origin – залить коммиты всех веток на удаленный сервер

Связка iMessages и Facebook

Какое-то время назад у меня отвалилась связка iMessages с Facebook на Mac OS. Настраивал я это дело, кажется, больше года назад, и тогда все работало.

Чат Facebook’а может использовать протокол XMPP, поэтому сложностей с подключением тогда его к iMessages не возникло. В то время время опция «Automatically find server and port» не работала и для корректного подключения к Facebook пришлось вбивать параметры сервера подключения вручную. По видимому, сейчас данные параметры изменились, потому что с ними уже невозможно подключиться. Однако опция «Automatically find server and port» на данный момент заработала и я смог вновь подключиться Facebook.

Связка iMessages и Facebook Связка iMessages и Facebook

Auto pull при каждом коммите в GitHub

Разработчик пишет код, коммитит, пушит в GitHub… И для некоторых задач весьма хочется, чтобы эти изменения сразу появлялись на нашем тестовом сервере. Т.е. по сути нам нужно, чтобы при комитте происходил автоматический вызов команды ‘git pull’ на тестовом сервере.

В сети есть несколько решений тому, как эту функциональность реализовать. Свой выбор становил на скрипте «Github Auto Pull«, который умеет еще отправлять алерты на указанную почту. Все бы ничего, но я столкнулся с проблемой — строчка shell_exec('git pull') ни как не хотела правильно выполняться. Стоит оговориться, что мне пришлось изменить строку вызова команды на следующую: shell_exec('cd /path-to-git-project && git checkout %branch% && git pull');

И так, я начал искать причину проблемы. Для начала попытался выполнить скрипт через CLI, оставив в нем лишь строчку с shell_exec:

php github.php — так все работает

Хм, следующее, что пришло на ум, это возможная проблема с пользователем, которому принадлежит скрипт (мол, выполнять команды в shell-оболочке запрещено). Переключился на этого пользователя, вновь запустил «php github.php» и что вижу:

Could not create directory '/var/www/.ssh'.
The authenticity of host 'github.com (192.30.252.128)' can't be established.
RSA key fingerprint is 15:27:ac:a5:76:29:2d:36:63:1b:56:1d:eb:da:a6:58.
Are you sure you want to continue connecting (yes/no)? yes
Failed to add the host to the list of known hosts (/var/www/.ssh/known_hosts).
Permission denied (publickey).
fatal: The remote end hung up unexpectedly

Т.е. проблема была в том, что осуществлялась попытка установить RSA-ключ, в несуществующую для этого пользователя директорию. Создал директорию, скопировал содержимое из /root/.ssh и все заработало.

Еще одна победа!