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

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

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

Перевод совсем не шлакрвый, хотя как я заметил у издателя Символ+ совсем шлаковых не бывает (ну ладно, почти не бывает)
Одним словом рекомендую для прочтения всем менеджерам проектов не осилившим pm book :-)

ISBN: 978-5-93286-160-8

Итак «Джоэл о программировании» и «Джоэл. И снова о программировании».

Что можно сказать об этих двух книжках…

Они очень хорошо написаны. Основное и главное достоинство книг Джоэла – прмая и доступная для всех мысль и хороший слог. Собственно во второй книге автор об этом и говорит «хорошему программисту надо уметь хорошо излагать свои мысли».

Надо понимать, что это не книги в общем-то, это наборы статей из блога joelonsoftware.com. Именно по этому автор затрагивает очень большое количество аспектов менеджмента и разработки ПО. Статьи кнечно сгруппированы по направлению, но не ищите в них развернутых материалов по какойто то теме.

Скажу прямо, мне книжки очень понравились, они достаточно интересно написаны, поднимаются  распространенные и сложные темы и в книгах есть ответы на некоторые вопросы. Да и стиль узложения автора неподражаем.

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

Те кто любит сухие факты, книги наверное не понравятся. В них (особенно во второй больше) достаточно много воды и спорных идей, которые автор выдвигает как неприложные истины. Особенно это касается вопросов связанных с подбором персонала, у меня при прочтении некоторых глав, посвященных этой тематики, выворачивало наизнанку. Если у Джоел с таким рвением подбирает себе разработчиков и если его продукт так хорош, то почему так мало распространен.

Особо хочется отметить перевод – он на удивление хорош. Хотя и есть некоторые ляпы, но смысл от них материал не меняет.
Можно по разному относится к персоне автора, но книги, имхо, обязательны к прочтению. Проведите аналогию с товарищем А. Лебедевым, так вот Спольских такойже Лебедев но от программирования. Интересная и неоднозначная личнось с более чем 20 летним опытом разработки и менеджмента ПО. В любом случае, что то новое узнаете. А если не узнаете то хотябы повесилитесь.

ISBN: 5-93286-063-4 (первая книга)

ISBN: 978-5-93286-144-8 (вторая книга)

Занимается она тем, что склеивает через сепаратор значения из определенного столбца таблицы. Лучше всего это показать на примере.

Допустим, что у нас есть таблица со следующей структурой:

CREATE TABLE `section_firms`(

  `sid` int(11) NOT NULL,
  `fid` int(11) NOT NULL,
);

В таблице хранятся соотношения одной сущности (sid) к другой (fid), в данном случае many-to-many.

Нам нужно в результате запроса получить все fid со всеми связанными с ней sid. Как раз для этого и существует функция GROUP_CONCAT. Она возмет все строчки указанного столбца и склит их в одну строку. Запрос для этого будет выглядит так:

SELECT fid, GROUP_CONCAT(sid) as sid
FROM section_firms
GROUP BY fid

Результат будет таким:

Как видим функция «свернула» столбец в строку.

А как обстоят дела с ней в PostgreSQL ? А никак. (Как мне правильно указал Alexander Korotkov - я ошибаюсь по поводу PostgreSQL, функция такая есть) Это специфичная только для MySQL  функция. Но можно написать аналогичную процедуру для PostgreSQL, чуть сложнее конечно, но можно положить в библиотеку (а еще лучше в свой шаблон базы данных) и таскать из проекта в проект.

Функция собственно:

create aggregate array_accum (
sfunc = array_append,
basetype = anyelement,
stype = anyarray,
initcond = '{}'
);

Пример запроса с этой процедурой:

select fid, array_to_string(array_accum(sid), ',')
from section_firms
group by fid;

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

Более подробно про реализацию под PostgreSQL можно почитать тут.

Надеюсь, что данная информация сможет быть интересной.

import sys, os
sys.stdout = open(os.devnull, 'w')

В этом случае, весь вывод (например командой print) будет перенаправлен в /dev/null. Естественно, если нужно перенаправить в файл то вместо os.devnull следует подставить название текстового файла куда будет перенаправлен вывод.

Если вам нужно переключать контексты вывода и перенаправлять не всегда в файл но и, в зависимости от ситуации, в консоль – то можно сделать так:

old_stdout = sys.stdout
sys.stdout = open(os.devnull, 'w')
# ...
print "перенаправленный вывод в файл"
#....
sys.stdout = old_stdout # Сменили контекст
#...
print "в стандартный вывод (обычно консоль)."

Что же нам сулит мобильный рынок с точки зрения трудозатрат на разработку? По сути –  ничего хорошего.

Сейчас уже сложился достаточно большой лагерь разработчиков под iOS, есть специалисты по Андроиду, но на порядок меньше, кто то тыкал палочкой в Маемо и почти никто не видел WebOS или Blackberry. C каждой из платформ связаны свои технологии, стандарты, гайдлайны. Наверное самой сложной можно считать разработку под iOS, так как ни тебе нормального (сорри, привычного) языка разработки, ни вольностей по UI да и разработку на пустом месте не начнешь – нужен как минимум Mac OS. А про сложности выхода в маркет – лучше умолчу. (надо уточнить что это мое IMHO)

Но не бросать же этот, достаточно жирный, рынок только из за сложностей разработки. Да и есть как минимум два, на данный момент, решения способных сильно облегчить жизнь разработчика. Конечно с ограничениями, но и со своими плюшками. Забегая вперед надо заметить, что адепты нативного программирования под любую из платформу будут плевать ядовитой слюной и кричать что это «не тру» и «не айс» и автор редкостный _____еб ! Таких товарищей попрошу удалиться – дальше статья не для вас.

Итак, на рынке есть два решения которые позволяют сильно облегчить написания приложений для мобильных платформ. Это Titanium Appcelerator и PhoneGap. Принцип работы обеих систем достаточно прост – и то и другое это кросплатформенные движки, которые позволяют запускать веб приложения с доступом к специфичному API системы (звук, камера, геолокация, звонки и т.д.)

То-есть вам не нужно знать ни ObjectiveC ни Java для написания приложения. Единственные знания которые от вас требуются – JavaScript на досточном уровне. Более того – написав приложение, например, для iPhone вы его сможете собрать и для Android не изменив ни строчки. Единственное, что остается – это подобрать соответствующие иконки и значки под требования ОС. Для простых программ – этого достаточно. Это достигается за счет  того, что платформы реализуют в себе UI самой системы – создав например Tab он будет выглядить нативно для целевой системы.

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

Какая из систем лучше – я пока не могу определиться. У обоих есть свои плюшки и какашки.

Давайте рассмотрим работу с одной из систем поближе. Сегодня хочу рассказать про Titanium, в следующий раз про PhoneGap.

С чего начать. Начать с того что зарегистрироваться на http://www.appcelerator.com/

Пару слов о лицензиях. Есть community лицензия – бесплатная, есть Indy и Proffesional – платные. Различаются набором модулей самого фреймворка, фичей Debug в IDE (за время написания статьи стала доступна и в бесплатной версии), естественно поддержкой и доступом к системе аналитики.

После регистрации – качаем Titanium Studio. К слову сказать – компания appcelerator некоторое время назад купила компанию Aptana с их продуктом Aptana IDE, вместе они допилили Аптану до состоянии синергии с титаниумом и теперь это штатная IDE для Titanium Appcelerator. Естественно ничего оттуда не выкинули – Ruby и PyDev из коробки на месте и… OMG!! они добавили поддержку цветовых тем из TextMate!!!

Скачав IDE, распаковав и запустив – вам нужно залогиниться под аккаунтом appcelerator`а.

Для быстрого старта я рекомендую слить с github пример под названием Kitchen Sink. Это большой пример использования самых различных подсистем ОС, начиная от простых кнопок, заканчивая доступом к камере и медиатеке.

Пару слов про требования к системе – они описаны тут, но в двух словах: работает на Windows, Linux, Mac OS. Под Android можно разрабатывать на всех трех системах, под iOS только в Mac OS X (ну а как же иначе) Также, требуются Androind SDK и iOS SDK. Ну и сам компьютер должен быть хоть немного шустрым – а то эмуляция дело такое, не для слабонервных ПК (особенно касается эмуляции Android). Еще дополнение – для работы с Android SDK нужно еще отдельно поставить ADP

Давайте в качестве примере напишем простой сервис, который будет выполнять следующие действия:

• Осуществлять поиск по названию компании в удаленной БД (через JSON);
• Отображать список найденных компаний;
• По клику на компанию отображать ее на карте;

Дизайн приложения будет максимально простой:

New -> Titanium Mobile Project

FindOnMap

org.example.findonmap

Отмечу  основные моменты:

• По структуре проекта – основной код и ресурсы находятся в каталоге Resources. В зависимоти от платформы используются разные ресурсы из каталогов android и iphone. Так-же в этих каталогах находятся ресурсы для разных устройств, как пример splash screen для iPhone, iPhone 5 (Retina) и iPad называются  Default.png, Default@x2.png и Default-Landscape.png (Default-Portrait.png) для iPad (в зависимоти от положения при запуске). С андроидом сложнее так как разрешений экранов для него больше. В принципе отдельно готовить ресурсы для каждого не обязательно – будет сжимать сам, но качество потеряется и надо учитывать, что соотношение стороно бывает разное;
• файл app.js – основной файл проекта. Логики он несет совсем мало, но мне удобнее было оставить его;
• main.js – содержит описания UI для приложения;
• events.js – события на ввод поисковой фразы и нажатия на табличку для выбора компании.
• Сервер отдает в формате JSON (кому интересно то такм Python+Django+Mongo)

Из особенностей Titanium Mobile которыми я пользовался:

• Ti.include(‘…’) – подключение внешнего файла;
• Ti.API.info (‘…’) – вывод в консоль отладочной информации;

Ну и скриншоты приложения на последок:

Иногда бывает нужно по быстрому набросать XML для какого-нибудь очередного экспорта во внешний мир. Кто эанимался созданием XML налету, тот наверное разделит мое мнение о том, что пустяковая задача превращается в рутину и кучу кода по управлению предками и детьми (parent nodes, childrens, etc.).

Для себя, я решил эту проблему посредством шаблонов. Обычных (в моем случае джанговских) шаблонов. Собственно вся идея в том, что шаблонизатору абсолютно по барабану что обрабатывать, будь то XHTML, HTML, SVG, JSON (для сособо одаренных) и естественно он ничего не имеет против XML.

Собственно вот пример:

Шаблон

<?xml version="1.0" encoding="windows-1251"?>
<discounts>
    <operator>
    <name>{{ operator.name }}</name>
    <url>{{ operator.url }}</url>
    <logo>{{ operator.logo }}</logo>
    </operator>
    <offers>
        {% for offer in offers %}
        <offer>
            <id>{{ offer.id }}</id>
            <bonus>{{ offer.bonus }}</bonus>
            <name>{{ offer.title }}</name>
            <url>{{ offer.url_full }}</url>
            <description>{{ offer.title }}</description>
            <region>{{ offer.region }}</region>
            <beginsell>{{ offer.start_date }}</beginsell>
            <endsell>{{ offer.expire_date }}</endsell>
            <beginvalid>{{ offer.start_date }}</beginvalid>
            <endvalid>{{ offer.expire_date }}</endvalid>
            <picture>{{ offer.front_647x427 }}</picture>
            <price>0</price>
            <discount>{{ offer.min_discount.0 }}</discount>
            <discountprice>0</discountprice>
            <pricecoupon>{{ offer.min_discount.1 }}</pricecoupon>
            <supplier>
                <name>{{ offer.company.name }}</name>
                <url>{{ offer.company_url }}</url>
                <tel>{{ offer.company_phone }}</tel>
                <addresses>
                    <address>
                        <name>{{ offer.company_address }}</name>
                        <coordinates>{{ offer.geo_data }}</coordinates>
                    </address>
                </addresses>
            </supplier>
        </offer>
        {% endfor %}
    </offers>
</discounts>

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

Вот код который все это безобразие обрабатывает:

def xml(request):
 operator = get_operator(request) discounts = DiscountFOE.objects.filter(....)

    ...
    t = get_template('exporters/kuponator.xml')
    xml = t.render(Context({
                            'operator':operator,
                            'offers':discounts,
                            }))

    xml = xml.encode('windows-1251')
    return HttpResponse(xml, mimetype="text/xml")

Но как и в любом решении есть подводные камни.

По умолчанию – говоря о XML мы подразумеваем, что кодировка у нас UTF-8, но на практике это может быть и CP1251  и KOI-8-R (а кто работал с системой РЖД Экспресс 3 – тем привет из KOI-7-R). Решение в лоб – перекодировать каждую строку в нужную кодировку – не прокатило. Строки либо бьются еще хуже, либо вообще отваливаются. Ответ подсказал товарищ – перекодировать уже готовый результат. Собственно предпосленяя строка этим и занимается.

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

Понимаю что тема очень простая, но вдруг кому-то сможет пригодится.

import datetime

def daterange(start, stop, step=datetime.timedelta(days=1), inclusive=True):
    # inclusive=False to behave like range by default
    if step.days > 0:
        while start < stop:
            yield start
            start = start + step
    elif step.days < 0:
        while start > stop:
            yield start
            start = start + step
    if inclusive and start == stop:
        yield start

Как юзать ? Вот например так:

from datetime import timedelta,date

end_date   = date.toady()
start_date = date.today()-timedelta(days=365)
dates = [x for x in daterange(start_date,
                              end_date,
                              step=timedelta(weeks=1),
                              inclusive=True)]

Надеюсь, что кому либо пригодится.

PS: Автор изначального генератора: Roger Pate с ресурса stackoverflow.com