суббота, 23 августа 2014 г.

Рекомендации хорошего стиля css/js

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

  1. Минимизировать использование модификаторов absolute и zindex, что очень сильно упрощает поиск и изменение стиля и дизайна ведь порядок элементов внутри страницы совпадает с ее внешним видом;
  2. Стараться не использовать фиксированные размеры элементов, и только если это действительно нужно фиксировать только одно направление чтобы было куда увеличивать элемент автоматически не ломая верстку;
  3. Если нужно отредактировать чтобы какой-то элементов стал шире - расширять и родительский если он был фиксированным;
  4. Оставлять достаточный размер по бокам от текста, чтобы было место если будут проблемы с начертанием текста;
  5. Использовать загружаемые шрифты с внешних ресурсов подобных Google fonts с указанием замены из системных шрифтов на случай проблем с сетью;
  6. Грузить библиотеки с cdn (Google cdn) с проверками ошибок и загрузки с локального домена в случае проблем;
  7. Стараться писать стили и разметку максимально структурировано с использованием максимально конкретного описания классов в css и js - на случай если вдруг на странице окажется больше каких то элементов чем вы ожидали и вы сломаете чью то логику и дизайн;
  8. стараться минимизировать обьем js/css кода внутри html кода, так как этот код часто повторяется на других, на страницах и его сложно минимизировать и избегать побочных эффектов;
  9. Не перекрывать чужие классы своими - только дополнять с указанием специфичного для вашего случая класса, так как возможен случай что на странице будут оба типа элементов ваш и оригинальный и вы получите бардак на странице.


среда, 6 августа 2014 г.

Права на домашний каталог в debian

Debian стал очень ориентированным на домашних пользователей как и остальные дистрибутивы поэтому права на домашние папки стали 755(rwxr-xr-x), что не очень хорошо если смотреть со стороны безопасности - пользователи на компьютере могут просматривать рабочий стол и документы у других пользователей. На google chrome, настройки и ssh ключи это не распостраняется, так как там стоят более безопасные права. 
Чтобы это решить для новых пользователей нужно запустить: dpkg-reconfigure adduser

суббота, 22 марта 2014 г.

Обновление hboot/radio разделов

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

Для этого нужно заблокировать загрузчик:
$ adb reboot bootloader
$ fastboot oem lock

Иначе обновить не получиться, можно получить ошибку вида:
FAILED ( remote: 99 unknown error)

Перепроверяем версию обновления:
Смотрим на modelid в выводе:
$ adb reboot bootloader
$ fastboot getvar all

Распаковываем обновление(OTA_*.zip) и смотрим файл firmware.zip/android-info.txt Если номера совпали значит можно продолжать.

Устанавливаем обновление:
$ adb reboot bootloader
$ fastboot oem rebootRUU
$ fastboot flash zip firmware.zip 

В консоли может появиться:
FAILED (remote: 90 hboot pre-update! please flush image again immediately)
При эом нужно повторить последнюю команду.

После этого ждем пока в консоли не закончиться выполнение, и перегружаем телефон. Шкала прогресса на экране может не дойти до конца пару процентов, но это нормально.

Разблокируем загрузчик:
fastboot flash unlocktoken unlock_code.bin

Код разблокировки можно получить с официального сайта.

понедельник, 10 марта 2014 г.

cm11 recovery for z4u

Удалось преодолеть первый шаг на пути создания собственной прошивки для z4u. Теперь можно использовать recovery раздел по назначению:-) Можно ставить новый прошивки и делать бекап для текущей прошивки. 
Ранее recovery имел следующие недостатки: 
  • прыжки изображения на экране при смене пункта меню что было не критично, но все же было недостатком (благодаря комиту); 
  • после подсказки в обсуждении разработки recovery и сравнения файлов используемых как fstab на разных версия cyanogenmod - удалось исправить этот файл, который поменял синтаксис для новых версий и теперь все грузится без проблем. Ранее экран просто мигал несколько раз каждую минуту и не показывал никакого меню. 


На данный момент в автоматически сгенерированной конфигурации нужно исправлять: 
  • fstab - по данным из /proc/emmc - данный файл отличается для 10.1 и 11 версии cyanogenmod 
  • BoardConfig: BOARD_*_SIZE - для указания реальных размеров разделов, TARGET_ARCH_VARIANT_CPU, TARGET_BOARD_PLATFORM, TARGET_BOARD_PLATFORM_GPU - для указания реальных значений процессора и видеокарты.

Далее нужно создать прошивку которая способна грузиться в обычном режиме загрузки телефона.

четверг, 27 февраля 2014 г.

Мобильные ядра

Состояние исходных кодов ядра linux мобильных устройств на примере z4u: 

  • Отсутствие документации и комментариев в файлах. Частично решаемо запуском скрипта, который проводит маленькую интеллектуальную работу над исходным кодом удаляя все комментарии и документацию из кода, и сравнивает с исходным кодом, прошедшим точно такой же фильтр, но уже из официальных исходных кодов ядра близкой версии(msm-3.4(aurora), 3.4(kernel.org)). Если все прошло нормально код заменяется на официальный. Но это помогает лишь частично так как при изменении кода скрипт не признает его как подобный. Посмотреть на результаты можно в данном репозитории
  • Изменения в в системном разделе заблокированы, что легко решается изменением конфигурации
  • Код ядра базируются на старом коде, если смотреть по некоторым файлам, то исходные коды уже на год полтора отстают от текущего состояния, и может содержать гигантское количество уже исправленных ошибок и не содержать новых улучшений. Что возможно и является причиной отсутствия документации, ее просто тогда не существовало, когда код писался. Как пример arch/arm/common/dmabounce.c находиться в состоянии между 0703ed2a6b260cd743adf49a8281eb064d728832 (04 Jul 2011) и 1dc8f0065cb2a274785fac9da61417908e22e0b9 (15 Aug 2012), если судить по msm-3.4.

воскресенье, 9 февраля 2014 г.

Сборка recovery под новое устройство

Последовательность действий такова:

Подготовка окружения для сборки:
  • curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo
  • chmod a+x ~/bin/repo
  • mkdir cm10.1 && cd cm10.1
  • ../repo init -u git://github.com/CyanogenMod/android.git -b cm-10.1
  • ../repo sync

Версия 10.1 предпочтительна, так как с следующей версии возможны проблемы с загрузкой.

Генирируем заготовку для сборки:
  • cd vendor/cm
  • ./get-prebuilts
  • make otatools
  • PATH=$PATH:`pwd`/out/host/linux-x86/bin/
  • build/tools/device/mkvendor.sh htc z4u recovery.img
Вместо htc z4u используем имена производителя и модели, но можно использовать любые значения, так как эти значения используются только как название каталогов. Образ recovery.img изначальный образ recovery с официальной прошивки не обязательный параметр, но позволяет заполнить часть значений в конфигурации. После этого в сгенерированной папках нужно поменять значения в BoardConfig.mk и в fstab. Как подсказку для заполнения последнего файла можно использовать список разделов из файла /proc/emmc или в выводе mount.

После обновления конфигурации, можно пересобрать ядро для чистоты эксперимента, конфигурацию ядра можно получить из /proc/config.gz и попытаться пересобрать ядро из исходников подобного устройства c aurora для qualcomm или другого репозитория. Наиболее удобным вариантом может быть скачать исходника с сайта разработчика устройства, пересобрать и заменить файл в сгенерированом каталоге.
  • make CROSS_COMPILE=../arm-eabi-4.6/bin/arm-eabi- SUBARCH=arm ARCH=arm z4u_defconfig 
  • make CROSS_COMPILE=../arm-eabi-4.6/bin/arm-eabi- SUBARCH=arm ARCH=arm -j 4
  • cp {каталог с ядром}/arch/arm/boot/zImage device/htc/z4u/kernel
Затем можно пересобрать recovery в каталоге 10.1:
  • source build/envsetup.sh
  • lunch cm_z4u-eng
  • . build/tools/device/makerecoveries.sh cm_z4u-eng или make recoveryzip -j 4
  • fastboot flash recovery out/target/product/z4u/recovery.img
Результаты запуска нового recovery при ошибках можно попробовать посмотреть в /proc/kmsg и /proc/last_kmsg. Необязательно там что-то будет, но попробовать стоит.

Дополнительно можно посмотреть:

суббота, 4 января 2014 г.

Proxy и маршрутизация

Нет предела совершенству.

Оптимизация трафика на уровне прокси имеет несколько ограничений, если верить данным с chrome beta на мобильном телефоне, он смог уменьшить затраты трафика на 65% для сайтов благодаря тому что пропускал трафик через свои сервера и минимизировал его. Недостатков я не заметил, но если верить статистике с httparchive - крупные сайты достигли 77 пунктов в pagespeed - что достаточно не плохо на уровне среднего уровня оптимизации и с сравнение трафика пропущенного с оптимизацией с чистым трафиком покажет достаточно не плохие результаты, подобные двойному уменьшению объёма трафика.

Но все же они тоже не спасут - если присутствует большой объем данных описывающих состояние передающихся на каждый запрос, как противоположность передачи только существенных изменений - никакая оптимизация не поможет, так как если разбить трафик на такие части: 
  • анонимные данные, не зависящие от клиента, 
  • данные специфичные для клиента, 
  • информация о смене состояния. 

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

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

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