Параметры можно рассматривать как некоторый способ неявной передачи данных из одной программы в другую. Нечто вроде “MEMORY ID”, только с более человеческим лицом.
Сортировка почты без почтового клиента
Сортировка почты – вещь ну просто необходимая при большом потоке писем. Есть куча методов и подходов к сортировке.
например, продвинутым моментом я считаю такую настройку, при которой письма сами раскладываются по папкам, на основании заголовков и адресной книги. То есть так, чтоб при этом не надо было постоянно подкручивать правила сортировки – по правилу “один раз настроил – и работает”.
Ещё есть интересные моменты скриптования прямо на сервере – это называется Sieve.
Пишешь скриптик, и он работает в моменты, когда происходит обработка писем на сервере.
Например, я пока повесил на один из ящиков скрипт:
require ["reject"];
if address :is ["To", "Cc"] ["contact@sample.com"] { }
else {
reject "Banned";
stop;
}
Здесь contact@sample.com – адрес ящика, на который я повесил этот скрипт, а “Banned” – текст в отлупе.
Скрипт делает следующее: реагирует отлупом на все письма, которые направлены не напрямую в этот ящик (спам, рассылки и подобные письма). Проходят только письма, у которых этот ящик указан в полях Кому(To) и Копия(CC), но не в Скрытой/Слепой Копии (BCC).
Пока поставил, поживём – увидим, что будет дальше.
Справочники большие и маленькие
Отдельная таблица
Целый спектр возможность открывается, если использовать Z-таблицы в качестве справочников. Однако, если дать разработчикам полную свободу, то засилье Z-таблиц рано или поздно приведёт к “мусорке”, в которой трудно найти что-либо нужное.
Здесь самое главное предварительно определиться, действительно ли нужен отдельный справочник в конкретном случае. Во многих случая допустимо:
Управление городами
Справочник городов является настроечными данными. Новые создаваемые города попадают в запрос.
Основной таблицей этого справочника является ADRCITY. Средство поиска для собственного употребления – например: CITY_NAME.
В SPRO есть раздел Города в Управлении адресами – SPRO:F999CC4C918CD21197EA0060B0672A3C
Основные транзакции по созданию/изменению/просмотру городов – это SR10/SR11/SR12.
Вот пример, как выглядит окно изменения:
Надо только определиться с диапазоном номеров (подобрать оптимальный подход) – внешний(согласовать формат) или внутренний.
Если вдруг вам нужно удалить город, то тут не всё так просто – есть отчёт SE38:RSADRLSM01, который удаляет в рамках страны все данные (города, индексы, улицы).
Определение корреспонденции в главной книге
Сталкивался с ручной интерпретацией определения корреспонденции.
- Для определения допустимой и запрещённой корреспонденции
- Для получения отчётов по корреспонденции (журнал-ордер)
- Для передачи документов в систему, в которой используются только пары Дт-Кт
До этого такие функции я видел только в Z-разработках, но есть, оказывается, в стандарте кое-что вокруг этого.
Защищено: Мой социотип
Пример с радио-группами
Сегодня — формулировка об унификации селективных экранов. О, да… это тоже борьба с энтропией.
Исключающие параметры
Часто бывает, что некоторые параметры образуются в некоторые взаимоисключающие группы. То есть в данном примере: следует заполнять или первое+второе поле, или третье+четвёртое поле.
В дополнение к таком селективному экрану можно написать обработчик, который будет выдавать ошибку вида “параметры А и Б не следует заполнять при заполненных параметрах В и Г”. Вариант суров и неоднозначен.
В качестве более красивого решения можно предложить разбавить эти параметры с помощью радиогруппы.
Параметры к параметру
Вот чуть-чуть другой пример. Радиогруппа уже есть, но некоторые параметры имеют смысл только для определённых пунктов.
Реализация
Во-первых, следует сделать пару добавок в описание селективного экрана:
Добавка “USER-COMMAND flag” требуется только для первого элемента в группе. Цель этой добавки – срабатывание PBO при выборе опции (щелчок мыши).
Добавка “MODIF ID OP1” требуется для группировки полей, чтобы “отвязаться” от количества и имён полей в обработчике экрана.
А во-вторых, добавляем обработчик экрана:
Этот обработчик по сути говорит:
- Для группы полей OP1: При включенной опции rg_opt1 – требуется включить ввод, иначе — выключить ввод
- Для группы полей OP2: При включенной опции rg_opt2 – требуется включить ввод, иначе — выключить ввод
Ничего сложного, а пользователю, надеюсь, будет немного понятней.
Впрочем, это только один из вариантов…
Между Гуглом и Яндексом
Я давно уже отмечаю, что эти два монстра друг на друга похожи, но никогда не сравнивал их.
Очень многие сервисы повторяют друг друга:
- Почта и поисковик – это только основная открытая часть
- ГуглТолк против Я.Онлайн
- Метрика Яндекса против Гугловой Аналитики
- Лента Яндекса против Гуглового Ридера
- ЯндексДирект против “как-эта-штука-называется-у-гугла”
- Фотки Яндекса против ГуглоПикасы
- Ютуб против ЯндексВидео
- и так далее…
Часто используются не только похожие принципы, но и похожая реализация. Различие кроется в деталях.
Вот можно, например, детально сравнить Ленту с Ридером:
- Яндекс имеет рекламный блок, у Гугла всяческая реклама отсуствует
- Яндекс имеет прокрутку по полной странице, Гугл имеет прокрутку по вложенным спискам
- Гугл имеет полный AJAX, а у Яндекса он, похоже, только частичный.
- Яндекс использует постраничное разбиение списка новостей, а Гугл использует прокрутку и динамическую подгрузку
- Гугл имеет колаборативные сервисы “нравится, общие, комментарии”, а у Яндекса есть только репостеры в ЖЖ, Твит и иже с ними
- Гугл умеет оперировать статистикой подписки – причем как серверной, так и юзерной, а у Яндекса такие возможности почти отсуствуют – можно посмотреть только количество подписчиков
- Рекомендации Гугла основываются на текущей подписке, но вот откуда сложились рекомендации у яндекса – для меня загадка
- Гугл позволяет лепить дополнительные теги на новости, а классификация Яндекса останавливается на папках
- Возможности настройки интерфейса у Гугла более серьёзные, нежели у Яндекса
- …
В разрезе данного сервиса мне видится преимущество Гугла несомненным.
Когда автоматизированная версия хуже бумажной
Пробегают мимо меня разные мелкие игрушки. Вот и пробежали “Японские кроссворды”, которые Акелла издаёт в России, а делают эту игру какие-то малоизвестные и малопрофессиональные немцы.
Кодекс чести
Перевод статьи Code of Honour за авторством Jens Steckhan (SAP).
Что общего между самураем, клингонцем и работником SAP?
Кодекс чести.
Я хочу написать об элементах, которые приносят удовлетворение и радость в мою жизнь разработчика.
Я открыл для себя, что большинство людей, с которыми я имел честь работать, придерживаются неписанного кодекса, немного похожего на Кодекс самурая. Позвольте мне его изложить: