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/