Я вот при верстке кучу раз не копирую хедеры. Давно ещё сделал небольшой простой сборщик на SSI, пототому дублирование сведено к минимуму. Все основные блоки (header, footer, content, sidebar) меняются из одного места.
Потом результат сохраняется, как зеркало с локального сайта и отправляется.
А вы думаете у операционистов в отделении есть интернет, чтобы это посмотреть?
Сколько не глядишь через стойку, у них DOS-овский черный экран с программой и никакой графики.
У нас люди пытались положить деньги на телефон через перевод средств.
Кстати раньше можно было отказатся от печати чека и съэкономить природе чуток буммажки, а теперь нет.
В прошлой версии ПО банкомата была веселая вещь: банкомат с задержкой спрашивал уже после возврата карты владельцу «Печатать чек?». И следующий человек мог допечатать чек предыдущего и ознакомится с финансовфм положением другого.
Раньше собирали вручную проект, могли случайно услать копию разработчика, но это быстро надоело и мы сборку автоматизировали.
Подготовку релиза необходимо автоматизировать изначально.
На винде, я пишу командный файл, который вычищает все временное и ненужное, собирает проект.
В самом проекте тоже предусмотрена «защита от спешки», да-да именно в спешке чаще всего выходят казусы с кодом. У нас в коде вставлены условия, не дающие проекту собраться, если он в режиме отладки.
«Все методы, реализующие интерфейс — обязательно protected и невиртуальные»
Это почему так важно?
Выходит этот код опасен чем-то? Не пойму, где могут от этого неприятности быть. TCommand = class(TInterfacedObject, ICommand, IInfoCommand)
private
FInfo: TInfo;
protected
procedure DoExecute; virtual; abstract;
function GetName: WideString; virtual; abstract;
function GetPriority: TCommandPriority; virtual; abstract;
public
constructor Create(const AШтащ: TInfo);
destructor Destroy; override;
procedure Execute;
function GetMux: TMuxInfo;
end;
Была еще такая лекция яндекса bit.ly/dBqAkb о фреймворках.
Я с ними согласен, пытался изучать какой-то фреймворк, но понял — бессмысленно тратить время. Свой наработанный материал приятнее и понятнее. И цель быстрее достигается.
Спасибо.
Понравилась идея именования веток с использованием номера задачи — стало гораздо яснее и проще выполнять задачи, потому что сразу видно номер задачи и не стремишься сюда пихнуть решение еще одной «вкусной».
Да и время жизни веток сократилось. До этого они жили долго и порой сильно уходили от корней.
p.s. применяем SVN, пока не удалось без граблей сделать экспорт в Git (
Сам себе и ответил — вот тебе и смысл: проверка настолько проста, что введение методов Get/Set это излишество, если ты просто задаешь для разных свойств диапазон значений.
При большом числе таких свойств сократиться избыточность кода.
А хороший борщ просто не сваришь — нужно много подготовить.
Потом результат сохраняется, как зеркало с локального сайта и отправляется.
Сколько не глядишь через стойку, у них DOS-овский черный экран с программой и никакой графики.
Кстати раньше можно было отказатся от печати чека и съэкономить природе чуток буммажки, а теперь нет.
В прошлой версии ПО банкомата была веселая вещь: банкомат с задержкой спрашивал уже после возврата карты владельцу «Печатать чек?». И следующий человек мог допечатать чек предыдущего и ознакомится с финансовфм положением другого.
Подготовку релиза необходимо автоматизировать изначально.
На винде, я пишу командный файл, который вычищает все временное и ненужное, собирает проект.
В самом проекте тоже предусмотрена «защита от спешки», да-да именно в спешке чаще всего выходят казусы с кодом. У нас в коде вставлены условия, не дающие проекту собраться, если он в режиме отладки.
Это почему так важно?
Выходит этот код опасен чем-то? Не пойму, где могут от этого неприятности быть.
TCommand = class(TInterfacedObject, ICommand, IInfoCommand)
private
FInfo: TInfo;
protected
procedure DoExecute; virtual; abstract;
function GetName: WideString; virtual; abstract;
function GetPriority: TCommandPriority; virtual; abstract;
public
constructor Create(const AШтащ: TInfo);
destructor Destroy; override;
procedure Execute;
function GetMux: TMuxInfo;
end;
Я с ними согласен, пытался изучать какой-то фреймворк, но понял — бессмысленно тратить время. Свой наработанный материал приятнее и понятнее. И цель быстрее достигается.
Понравилась идея именования веток с использованием номера задачи — стало гораздо яснее и проще выполнять задачи, потому что сразу видно номер задачи и не стремишься сюда пихнуть решение еще одной «вкусной».
Да и время жизни веток сократилось. До этого они жили долго и порой сильно уходили от корней.
p.s. применяем SVN, пока не удалось без граблей сделать экспорт в Git (
Аскетичный простой интерфейс и солидный банк иконок.
IComparable есть с Delphi 2009
При большом числе таких свойств сократиться избыточность кода.
Забота о пользователе — дело программиста. Как позаботишься так и будет — нет разницы какая IDE или язык использован в приложении.