25 апреля 2013 г.

Требования к дизайн-макетам

Требования к формату файлов:

  1. Формат файлов — PSD, с режимом совместимости. Отдельные элементы (готовые для верстки) можно в PNG24.
  2. Должны быть осмысленные названия слоев, семантическая группировка слоев (можно на русском языке обзывать, только не «Слой 1», «Слой 2»)
  3. Не помешают дополнительные слои или просто комментарии (средствами Photoshop) с отображением названий используемых гарнитур, размеров шрифтов, ширин, высот, отступов разных элементов
  4. Все используемые пиктограммы должны быть представлены отдельными файлами или одним многослойным файлом. Можно спрайтом, но его нужно уметь правильно сделать.
  5. Если верстка идет с использованием не-Photoshop (Illustrator, Fireworks, CorelDraw(sic!)), то тогда кроме макета в PNG24 нужно предоставить все графические элементы отдельными файлами тоже в PNG24. Плюс документ с комментариями.

Требования к макетам:

  1. Единообразие размеров, отступов, шрифтов и т.п., чтобы можно было написать общие стили элементов, а не выравнивать каждый по отдельности.
  2. Как следствие — нужно придерживаться сетки, оптимально, если она будет 12-тиколонной (основа всех CSS-фреймворков)
  3. Отработка всех кейсов — например: ошибки валидации, состояния кнопок и ссылок при наведении и нажатии на них мышкой и т.п. Ошибки, диалоговые окна с предупреждениями и т.п. Часто это упускают из виду.
  4. Если верстка должна быть резиновый, то нужно предоставить три макета — самый широки, узкий и промежуточный. Желательно стрелками показать что куда двигается. Возможно потребуются комментарии.
  5. Если подразумеваются динамические элементы, то нужно в комментарии прописать, что именно должно быть. Совсем уж очевидные вещи можно, конечно, не описывать.
  6. Если подразумевается локализация, то нужно оставлять как минимум еще 30-40% места под текстовые элементы (кнопки, элементы меню и т.п.).
  7. Случаи, когда текст выводится не полностью, а обрезается (например при ресайзе элемента), тоже должны быть проработаны.

Ссылки по теме

22 июня 2012 г.

Cup of coffee, please!

  1. Скачать node.js для windows;
  2. Поставить с настройками по-умолчанию;
  3. Запустить консоль (cmd.exe) с админскими правами;
  4. Используя пакетный менеджер npm установить coffeescript
    npm install -g coffee-script
  5. Теперь в папке с *.coffee (или уровнем выше, как удобнее) создать coffee-watcher.cmd с примерно такой строчкой
    coffee -o js -cw .
    , где
    -o js указывает на папку, куда будут складываться готовые файлы *.js (структура каталогов сохраняется)
    , а
    -сw . значит компилировать с и следить w за всеми *.coffee файлами рекурсивно, начиная с текущего (.) каталога
  6. Все, можно запускать. Рекомендую встроить в шторм в качестве внешней утилиты.
P.S. watcher работает нормально, но бывает, хотя и крайне редко, что вылетает. В любом случае нужно поглядывать иногда в лог, т.к. синтаксические ошибки видно только там. Когда такая ошибка имеет место быть - файл *.js не изменяется.

21 июня 2012 г.

Планирование работ по проекту

Так, для себя, на будущее.

Часто забываю, что лучше придерживаться четкого порядка.


Универсальный план работ по любому веб-проекту:
  1. Тщательное изучение ТЗ, прояснение каких-либо неоднозначных мест;
  2. Обсуждение всех userstories (пользовательских историй);
  3. Составление макетов интерфейса;
  4. Составление WebAPI (адреса и форматы передачи данных);
  5. Создание архитектуры проекта;
  6. Планирование работ по реализации архитектуры (максимально подробное);
  7. Создание костяка проекта, отражающего скелет будущей архитектуры;
  8. Собственно реализация, кодирование (желательно через модульное тестирование);
  9. Внедрение системы безопасности;
  10. Внедрение логирования (в основном для разработчика: исключения, предупреждения и проч. важные сообщения);
  11. Сборка проекта (из разных модулей), интеграционное тестирование;
  12. Функциональное тестирование;
  13. Создание пользовательской документации;
  14. Создание дистрибутива, сдача проекта;
  15. Поддержка проекта, исправление ошибок и, возможно, доработка, если ТЗ было неполным.

По сути это каскадная модель. Возможно она уже и устарела, но, тем не менее, я считаю её полезной. Разве что добавил бы пункт "Корректировка планов по результатом выполнения работ" после каждого шага.

19 марта 2012 г.

Для новых работников

Для новых работников

Модель работы такая (в идеале):
  1. Разработка ведется двухнедельными итерациями. Конец каждой итерации - выпуск новой публичной версии.
  2. В начале итерации определяются задачи, которые должны быть выполнены. Обговариваются сроки и раскидываются между разработчиками. Некоторые задачи выполняются вместе (парное программирование). Все это отражается в системе управления проектами. Задачи должны быть примерно от получаса до 8 часов. Более мелкие группируются, крупные - разбиваются на подзадачи.
  3. В конце дня (или в течение дня, как удобнее) разработчик отмечает над какими задачами (тасками) он работал, сколько потратил времени (в часах), какие возникли проблемы и т.п.
  4. После выполнения каждого таска нужно коммититься. В конце дня - пушить все коммиты на центральный сервер (репозиторий). Подробнее я описал тут: http://www.khoden.ru/2012/02/mercurial.html
  5. В первую пятницу делается анализ того, что сделано, что еще осталось. Корректируется время и список задач.
  6. Во вторую пятницу проверяется, все ли таски закрыты, готовится версия на паблиш, мержатся данные при необходимости, тестируется на временном сервере, потом, если не было никаких проблем - переносится на боевой. Боевой при этом корректно положить с вывеской, что ведутся работы и с планируемым временем включения.
  7. Если столкнулся с какой-то проблемой и не можешь самостоятельно найти решения в течении 15-30 минут - лучше обратиться к более опытному коллеге, этим ты сэкономишь время (зачастую грабли одни и те же)

Важно: в конце дня пушить все изменения в центральный репозиторий и обновлять таски.

17 февраля 2012 г.

Английский - это сложно?

Сколько людей знают хорошо русский? Все правила, исключения, фразеологизмы, стилистику?
Я думаю только те, кто интересуется всем этим. А 99% на это плевать, они просто разговаривают, безо всяких правил.

Ребенок года в 4 уже может вполне сносно объясняться и слушать. Я по-английски, может знаю раза в полтора больше него (слов), но я не могу так складно и быстро строить предложения. К чему это я? К тому что, 4 года взрослому человеку (на самом деле 6 месяцев, если с погружением) достаточно, чтобы научится свободно излагать любые мысли.

При изучении языка есть 4 направления:
     1. Чтение
    Сначала нужно много читать, лучше начиная с адаптированных версий и детских книг. Главная ошибка - читают что-то неинтересное или уже ранее прочитанное на своем языке. Это путь в никуда. Таким образом снижается интерес и как следствие - мотивация.
    Благодаря чтению развивается лексический запас. Также следует посмотреть в сторону профессиональной литературы (ну в своей области). Подобная литература сильно проще живого английского. Используются одни и те же простые грамматические конструкции, ограничен набор используемых слов.


     2. Восприятие на слух (аудирование)
    Теперь, мы набрали минимальное кол-во базовых слов. Можно переходить к аудированию: слушать простые аудиокниги, профессиональные курсы (я, например, вообще был вынужден, других источников зачастую нет), смотреть фильмы и сериалы, в конце концов. (Кстати, часто, особенно в комедиях, в переводах упускают юмор, который построен на игре слов)
    Вовсе не обязательн стремится понять все (как и при чтении книг). Главное – улавливать общий смысл. Если совсем худо, прослушать еще раз.

     3. Письменная речь
    И только на этапе письменной речи нужно всерьез браться за грамматику. Просто вызубрить её и всё. Других способов нет.

    Есть специальные сборники упражнений, например Галицинский, он есть в любом книжном (он-лайн версия тут). Просто прорешиваем все упражнения и все.

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

     4. Устная речь
    Самое сложное – устная речь. Сложность в том, что нужно ставить произношение. Здесь без преподавателя не обойтись.

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

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

    Естественно, разделение не обязательно такое явное, можно смешивать.



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

    P.S. Материалы, которыми я в данный момент пользуюсь:

    16 февраля 2012 г.

    Религия Mercurial

    Обращение к новообращенному)

    Вряд ли ты ранее работал с системами контроля версий.

    Терминология:

    Репозиторий (Repository)
    Папка с вложенной папкой .hg, в которой хранится вся история проекта за все время. Все репозитории равнозначны в распределенных системах контроля версий (Mercurial, Git)
    Центральный репозиторий
    репозиторий, который принято считать центральным, на который обычно отсылают локальные изменения.
    Локальный репозиторий
    репозиторий проекта у тебя на компе.
    Коммит (Commit)
    снапшот текущего состояния файлов в локальный репозиторий, сейв.
    Ревизия (Revision, rev)
    результат коммита, имеет номер и уникальный хеш. Номер иногда может не совпадать, поэтому особо на него не расчитывай
    Пуш (Push)
    отсылка всех локальных ревизий на центральный сервер
    Бранч (Branch)
    ветка кода. Может идти отдельно, параллельно другой ветке. Как правило все бранчи равнозначны. Обычно ветка образуется, когда несколько человек работают над проектом. Бранчи - вещь очень мощная и меркуриал отлично с ними работает. Ничего специально делать не нужно, они создаются сами.
    Мержинг (Merge)
    Процесс слияния веток. Делается вручную, когда возникает необходимость слить изменения с другим разработчиком.
    Конфликт (Conflict)
    при совместном редактировании одной и той же строки или части файла двумя людьми, система не может определить, какой считать правильным. Такие ситуации решаются вручную с помощью инструментов сравнения. При правильном подходе возникает крайне редко. Обычно конфликты решаются автоматически.
    Пул (Pull)
    загрузка появившихся ревизий с центрального репозитория.
    Апдейт (Update)
    переключение между ревизиями. В один момент времени активным может быть только одна ревизия, либо последняя "Working Directory"

    Прими пару рекомендаций:

    1. Коммить локально после закрытия бага или выполнения таска. Ну или в любой ситуации, где, как в играх, хочется сохраниться.
    2. В конце дня, если последний коммит был удачным - пуш его в центральный репозиторий.
    3. Главное правило - все коммиты, и локальные и, тем более последний в пуше - ОБЯЗАТЕЛЬНО должны собираться и сильно желательно - запускаться и работать.
    4. Иногда возникает необходимость закоммититься локально, но проект не собирается. Тогда нужно это обязательно указать в комментарии к коммиту, типа: "Не собирается сборка такая-то, на ревизию не обновляться"
    5. К любому коммиту должен быть осмысленный комментарий, желательно с номером закрытого таска (или нескольких мелких). Такой, чтобы любой человек, работающий над проектом смог понять, что это за коммит. Первая строка в комментарии самая важная, старайся в ней отразить главный смысл. Последующие строки, если они потребуются, могут раскрывать суть более подробно.
    Во имя репозитория, коммита и корректного мержа, Аминь!

    11 февраля 2012 г.

    Старт проекта "Умная библиотека"

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

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

    Пока ТЗ не составлено, но в целом программа будет в виде веб-службы и клиента на ExtJS4.

    При разработке будем стараться использовать самые "правильные" технологии и подходы к проектированию. TDD, DDD, XP и прочие страшные слова.

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

    Цель проекта - прокачка скилов и получение опыта разработки на всех слоях и этапах.

    Адрес проекта : https://code.google.com/p/smart-library/

    3 декабря 2011 г.

    Фаулер, исходники примера из первой главы

    На днях начал плотное изучение книги Мартина Фаулера "Рефакторинг: улучшение существующего кода"

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

    Банально, но для закрепления теории нет ничего лучше практики. Вот так и родилась идея завести маленький проект в IntelliJ IDEA и попробовать там проделать то же самое. Ну и грех не поделится, может кому-нибудь будет полезен этот код.

    Проект на GoogleCode

    VCS: Mercurial

    Repository URL: https://code.google.com/p/fowler-book-chapter1/

    Небольшие изменения, которые привнес я (отличия от книги):

    1. Самое главное - написал тесты, которые в книге упоминаются, но не приводятся (сделал на JUnit4).
    2. В последних коммитах (а их всего девять) я заменил авторскую конкатенацию строк для формировании отчёта на более удобный метод String.format()
    3. Немного другая разметка HTML-версии отчёта (авторская показалась какой-то убогой)

    Загрузить проект в отличную от IntelliJ IDEA среду, я думаю, сможете без проблем. Тесты лежат в отдельном пакете "Tests".

    На текущий момент последняя ревизия — с подписью "Шаг 7 (заключительный в книге). Замена switch полиморфизмом. Создание класса Price с потомками."

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

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

    25 октября 2011 г.

    Анонс нового проекта

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

    15 мая 2011 г.

    Numeration - перевод в произвольную систему счисления

    Возникла мысль для передачи ID в ajax приложении кодировать числовые значения в 64-ричные. Накидал простенький скрипт. Интересная особенность - на вход можно подавать произвольный алфавит любой длины. Но это неразумно, т.к. при url-кодировании вся экономия сходит на нет. Поэтому имеет смысл использовать алфавит, подобный тому, который используется при Base64 кодировании.