Правила жизни в ИТ проектах

За все время работы в ИТ я принимал участие в различных сферах деятельности. Я был и тимлидом, и разработчиком и менеджером проекта. Вел крупные и не очень проекты, среди них были как успешные, так и не очень. Я работал как с профессионалам высочайшего класса (по крайней мере именно такими я считал и считаю этих людей до сих пор) так и с не очень опытными коллегами. Я сотрудничал как с людьми проработавшими в ИТ всю свою жизнь, так и с теми — чьи интересы и деятельность лежит в совершенно других сферах.
Все это время я чему-то учился и продолжаю учится по сей день.

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

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

Чем проще решение тем оно надежней

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

Не стоит изобретатель велосипеды

Если есть готовый фреймворк, или библиотека который Вы можете использовать — используйте его. Не стоит писать свой.

Логику и типы данных лучше выносить в отдельные сборки

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

Open Source надо использовать с умом

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

Не стоит сразу писать платформу

Лучше решать поставленную задачу. Многие разработчики (и я в том числе иногда страдаю этим же подходом 🙂 ) сразу стремятся написать универсальное решение для всего и сразу. Не стоит этого делать. Чаще лучше решить конкретную задачу и получить результат. Потраченное на создание универсального решения время может не окупиться, и часто не будет востребовано в будущем. Кроме того, чем универсальнее решение, тем чаще оно получается сложнее и ограниченное в использовании.
Зачастую такой подход бывает у начинающих разработчиков, поэтому совет относится в первую очередь к ним — прежде чем начинать писать такое решение — посоветуйтесь со старшим товарищем в команде — будет ли оно полезно и востребовано. И только если получите положительный ответ — стоит начинать такую работу.

CMS не панацея

Мне часто доводилось видеть веб-проекты, которые начинались с того, что ставилась какая-то популярная CMS и продукт развивался путем «накручивания» на нее кода. В результате получался неповоротливый механизм который процентов на 10% использовал функционал CMS, а 90% кода были перегружены и нечитаемы, так приходилось учитывать структуру самой CMS и структуру ее БД.
Гораздо эффективнее писать решение конкретной задачи, чем пытаться приспособить для этого неповоротливую CMS.

Предметная область важнее всего

Во всех проектах соблюдайте приоритет: Предметная область -> Архитектура -> Административные задачи
Продукт создается для клиента, а не для разработчика, или системного администратора.
Мне приходится встречать ситуации, когда администратор начинает рассказывать разработчикам как им лучше писать API для продукта. Так же встречались разработчики, которые предлагали клиенту отказаться от функционала, так как его не поддерживает CMS с которой разработчик умеет работать. Такой подход недопустим, если вы действительно хотите создать качественный продукт.
Решение создается в первую очередь для клиента, а не для программиста, или администратора.

Оптимизация нужна только там, где нужна

Иногда встречаю разработчиков которые говорят «Я не буду использовать Entity framework, он генерирует не эффективный SQL», или «Использование linq — это синтаксический сахар! Циклы и перебор лучше.» Да, иногда не все вещи которые удобны — будут максимально эффективны в плане быстродействия. Но стоят ли проценты производительности снижения уровня удобства разработки и увеличения объема кода?
Часто бывает достаточно выделить две три «тяжелые» функции в хранимую процедуру и обвернуть ее вызов через Entity Framework, или провести оптимизацию конкретных узких мест в коде, чем полностью отказываться от тех преимуществ которые дают новые технологии.

Читаемый код, лучше переоптимизированного

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

Инструмент должен быть удобен

Бывает так, что выходит новая технология, появляется инструмент, или продукт, который получает широкую огласку и восхищенные отзывы. Но по сути инструмент еще не готов технологически. Внедрение такого инструмента, несмотря на кажущуюся перспективность и технологичность может негативно сказаться на продуктивности работы команды. А преимущества могут не перекрыть недостатки.
Инструмент должен в первую очередь удобным и решать задачу.

ТЗ должно быть

Даже плохое ТЗ лучше чем отсутствие какого либо.
Мне также встречались и такие проекты где документацию по проекту отсутствовала вообще и очень многое находилось на уровне устных договоренностей. При этом размеры таких проектов были самые разные — как мелки, так и достаточно крупные.
Даже если вы в отличных отношениях с заказчиком и полностью ему доверяете — все пункты необходимо фиксировать. И даже это не всегда помогает. Понимание одних и тех же терминов и описаний может кардинально различаться у различных участников проекта.
Так мне доводилось быть на встрече, на которой несколько часов обсуждалось только основное понимание терминов предметной области. Разработка при этом еще даже не начиналась.

Лучше применять готовый продукт, чем писать свой

Есть много ситуаций, когда разработчик, или клиент решают что стоит написать свое решение. На самом деле, где-то в половине случаев так поступать не стоит.
Разработка — это всегда длительный и дорогой процесс. Поэтому, даже если кажется что написать свой аналог проще и дешевле — в 90% это только иллюзий.
Если на рынке есть аналогичное решение — лучше приобрести его. Оно уже есть и уже работает. Здесь и сейчас.
Писать свое решение стоит только в том случае, все участники проекта осознают риски, понимают что процесс будет длительным и дорогим.
Явные признаки того, что лучше купить и внедрить чем писать:

  • существует продукт который покрывает предполагаемый сценарий использования
  • существует продукт который покрывает предполагаемый сценарий использования после определенной конфигурации
  • существует несколько продуктов которые при взаимодействии и интеграции покрывают предполагаемый сценарий использования
  • существует продукт который можно расширить определенным функционалом (дописать модуль для CRM) и после этого он покроет сценарий использования

Когда есть смысл писать свой:

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

Кроме ИТ есть еще много чего в жизни

Этот совет последний по списку, но не по важности. Я не просто так поставил в начале статьи фотографию из ONE ☆ LIFE Everest Expedition организованной Артемием Суриным. Для очень многих в нашей профессии ИТ стало не только работой, но и самой жизнью. Я и сам довольно много времени провожу за экраном ноутбука/планшета/телефона. Но кроме этого есть вещи которые так же доставляют многим из нас немало удовольствия. Для кого-то это дельтапланеризм, для кого-то чтение книг, спорт, путешествия, общение с новыми людьми, коллекционирование, рисование сочинение.

Хочется пожелать всем — не только работайте, но и живите!

P.S. Отдельное спасибо MarcusAurelius — за предварительное ознакомление со статьей и дельные замечания.

ссылка на оригинал статьи http://habrahabr.ru/post/174859/

Назад в будущее или основные этапы развития учета в истории

В предыдущей статье я проиллюстрировал созревший момент для смены диграфической парадигмы в учете, которая является сегодня основополагающей во всех компьютерных системах учета. Тема очень глубокая. Попробую разобрать ее подробнее.
Третий закон диалектики утверждает, что «в поступательном движении происходит возврат назад, в новом повторяются черты старого»
Иногда, чтобы понять грядущие революционные изменения достаточно внимательно посмотреть в прошлое.
Тенденции же к возникновению прорывов можно усмотреть в критическом накоплении количественных изменений в рамках одной из существующих парадигм. (Второй закон диалектики)
Если мы упомянули два из трех законов диалектики, то не оставим без внимания оставшейся. Первый закон диалектики утверждает, что развитие идет через решение взаимоисключающих противоречий.
Вот теперь можно применить все три закона в рассмотрении предмета учета в бизнесе вчера, сегодня и возможных будущих форматов.
Для рассуждений возьму три параллельных и взаимосвязанных процесса:
— Бизнес
— Информационные технологии
— Учет
И рассмотрим их сквозь мглу веков.

Бизнес

Люди всегда что-то производили и продавали, оказывали друг другу услуги. Начало использования электричества, двигателя внутреннего сгорания и прочих великих открытий, привело к быстрому изменению структуры бизнеса и требований к нему.
В одном вебинаре В.П. Савчук (партнер нашего проекта, мой учитель по фин. Менеджменту, автор замечательных книг) представлял изменение требований к бизнесу на временной шкале.
После я, по аналогии с пирамидой иерархии потребностей человека господина Маслова, преобразил эту визуализацию в пирамиду иерархии потребности бизнеса.

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

Информационные технологии

Рассмотрим информационные технологии с точки зрения носителя информации.
Когда-то люди наносили информацию на камни, деревянные дощечки. Потом были варианты с папирусом.
Но действительным прорывом (революцией) технологии носителей информации стало возникновение бумаги и печатного станка. Это произошло в середине 15 –го века. Т.е. некий великий качественный скачек. В десятки и сотни раз уменьшается размер хранилища информации и трудоемкость оперирования ей.
Далее на протяжении пяти веков идет развитие информационных технологий в рамках бумажной парадигмы. Совершенствуются способы изготовления бумаги, которая соответственно дешевеет. Так же совершенствуются способы нанесения информации на бумагу, а так же способы структурирования информации в рамках новых исключительных (по сравнению с каменными плитками) возможностей.
Но что происходит в конце 20-го века? Возникает новый вид носителя информации. Назовем это ЭВМ или компьютер, для простоты. Даже не надо говорить, что теперь городская библиотека может поместиться в 1 квадратный миллиметр. А возможности занесения информации, хранения, поиска, обработки и прочее? Сложно определить количество нулей порядка увеличения качества.
В большой степени скачек качества информационных технологий определил скачек требований к бизнесу. Мы же говорим о взаимосвязанных вещах.
На графике выделю два глобальных скачка качества информационных технологий:

Учет

Конечно, в данном случае рассматриваем учет как попытку отразить происходящие явления в бизнесе в виде цифр и других записей. Я люблю давать определение: Учет – это цифровое отражение жизни. В нашем цифровом мире такое определение дает возможность проводить адекватные аналогии. К примеру, проведем аналогию фотографии и учета. Учет должен отражать состояние на различные моменты времени. Фотография способна зафиксировать (записать) видимое состояние на момент времени. Иногда баланс в учете называют фотографией состояния. В современном бухгалтерском учете куча условностей, которые знают только специально обученные специалисты, а нормальному человеку все кажется, очень сложно и запутано. Условное отражение – это не фотография, а рисунок. Вот такая аналогия получается. Раньше когда не было цветной фото (техническое ограничение фотографии), художники разрисовывали красками черно-белые фотографии (думаю у многих найдутся такие экземпляры, оставшиеся от бабушек). Вот наша бухгалтерия – это не точное цифровое отражение действительности, а черно-белая фотография, разукрашенная специалистом по условным изображениям.
Закончили с лирикой и посмотрим, как технологии учета развивались в истории.
Забавно, что первое документальное подтверждение использования двойной записи попадает в одно десятилетие с изобретением печатного станка.
Вообще в науке принято, что существует три основные парадигмы учета:
— Униграфическая (без использования двойной записи)
— Диграфическая (с использованием двойной записи)
— Камеральная (распил… бюджета , а еще и по чистому ддс, ее в расчет брать не будем).
Кому интересно вот ссылка на хорошую статью касательно парадигм.
Двойная запись – это базовый принцип регистрации данных. Он очень прост (математика пятый класс) и является базой для различных структурных систем, на входе которых первичные документы, а на выходе отчеты о состоянии и результатах (баланс и отчет о доходах расходах). Такие структурные системы в науке называют формами счетоводства. Т.е. форма счетоводства (набор определенно взаимосвязанных табличек) — это некое техническое устройство, ограниченное уровнем используемой техники (это важно, поскольку бумага и способы нанесения на нее информации – это уровень информационных технологий), внутри которой используется тот или иной способ записи, обработки и извлечения данных (специально перевожу все на язык современного IT).
Можно представить, что до изобретения двойной записи учет развивался, так или иначе, в рамках униграфической парадигмы, после, соответственно, в рамках диграфической парадигмы.
А именно параллельно совершенствованию технологий изготовления бумаги и технологий нанесения на нее информации, возникали различные системы (формы счетоводства), которые оптимизировали учет, но в рамках все одной диграфической парадигмы.
Пришло время весь график нарисовать.

Вот теперь видна полная взаимосвязь и то, к чему я тут все веду.
Во-первых, видна взаимосвязь потребностей бизнеса и соответствующих его требований к учету, которые развиваются в рамках ограничений накладываемых уровнем информационных технологий.
Во-вторых, видно, что качественный скачек информационных технологий порождает качественный скачек базовой технологии учета.
Ну и наконец, понятно, что должна возникнут новая парадигма учета, соответствующая новым качественным возможностям информационных технологий. При этом становится понятно, что то, что называется в современном мире управленческим учетом, работает исключительно в рамках униграфической парадигмы и не может реализовать такой прорыв.
Вся эта статья сильно теоретизирована, но другим способом не получится оторвать внимание от практических проблем, решаемых повседневно специалистами по учету и автоматизации. Эти проблемы в большинстве своем являются лишь следствием или цепочкой следствий ключевой проблемы, которая, в свою очередь, лежит вот на таком теоретическом уровне. А если решить ключевую проблему, то будет решены и все проблемы, которые являются следствием. Так гласит здравый смысл и теория ограничений (ТОС) Ильяху Голдратта. Также Голдратт утверждает, что если в период действия ограничения были сформированы практические правила, то даже если будет снято само технологическое ограничение, то эти правила сами станут ограничением.
Все, что он говорит про правила, очень сильно относится к учету, ведь пятивековая история развития в режиме ограничения бумажных информационных технологий сформировали огромное количество правил и стереотипов. А, как известно, наступать на горло стереотипам дело крайне сложное.
В заключение признаюсь, что мы совершили данный прорыв. Нам пришлось потратить несколько лет, чтобы разрушить стереотипы в собственных головах (хорошо, что их было не много). Но теперь мы столкнулись с проблемой внешнего недопонимания, т.е. с еще более сложной задачей – разрушить стереотипы в чужих головах.
Надеюсь, данная статья, хоть она и слишком теоретизирона, хотя бы заставить задуматься и более внимательно и беспристрастно (поверх стереотипов и правил) взглянуть на разработанные нами технологии и методологии.
Желаю всем успехов и процветания, а способность контролировать собственный бизнес или себя лично, как бизнес, обязательно к этому приведет.
p.s. В тексте просматриваются второй и третий закон диалектики. Каким местом тут первый закон диалектики, можно будет понять из будущей статьи по поводу, почему происходит деление финансового и управленческого учета.

ссылка на оригинал статьи http://habrahabr.ru/company/rtit/blog/174893/

Первое апреля в Интернете-2013

По традиции собираем весёлости, найденные на просторах сети первого апреля. Кидаем ссылки в комментариях, можно скриншотить, дабы осталось в памяти. Кому лень — просто ссыльте. Я добавлю скриншоты.

Начну с форума своего вуза, где на этот раз добавилось немного гарлем шейка. Заскриншотить это довольно трудно, в общем весь сайт «шатает». Дабы не нарушить функционал — есть кнопка отключения шалости.

Ссылка | Картинка

С днем Смеха, не попадитесь на удочку в первый понедельник апреля 😉

ссылка на оригинал статьи http://habrahabr.ru/post/174891/

О Почте России замолвите слово…

Сразу скажу, я к Почте России не имею отношение. Точнее имею, но как постоянный клиент. У меня интернет магазин и я лично раз-два в неделю превращаю свое отделение в филиал ада на земле в частном порядке сгружаю в ее чрево по паре десятков посылок на протяжении вот уже 4 лет. Эпично закладывая окошко почты своими коробками как кирпичной кладкой 🙂 И посему у меня есть ряд наблюдений и некоторая статистика за последние четыре года.

Я конечно понимаю, что 99% процентов возмущений приходится на долю интернет шоперов ждущих посылки из всяких ебаев-китев, и проблемы там действительно есть. Но моя цель не дать несчастной почте еще одного пинка, а все же сказать что-то позитивное. И дать пару советов по правильному обращению с почтой ну и зажечь тусклый светодиодик в конце тоннеля. Потому я буду рассказывать только про хождения отправлений внутри страны и из России в дикие земли 🙂 И речь пойдет, по большей части, про так называемый «Первый класс». Т.к. я пользуюсь преимущественно им.

Итак:

Надежность
Начиная свое дело, я боялся, что будет ад и кошмар и отправления будут уходить в никуда и придется возмещать клиентам потери и нести дикие расходы за счет повторных отправок, а посылочки у меня по несколько тысяч стоят. В реальности же все оказалось куда как более вменяемо. За эти 4 года мы отправили несколько тысяч посылок из которых процентов 10% зарубежные.

Итак, за все время:

  • Безвозвратно потерялось — 2 (ДВЕ штуки). Причем одну украли и приехала пустая коробка с огромной дырой в боку и остатками упаковки внутри, без вложения. Зачем какому то вору-гопнику потребовалась моя демоплата и что он с ней собрался делать я бы сильно хотел знать. Неужто решил сменить квалификацию? 😉
  • Вернулись обратно, не дождавшись вручения — 3. Видимо отправитель ждал извещения, а его не принесли.
  • Посылок считавшихся потерянными (т.е. шедших более двух месяцев и потребовавших повторную отправку товара), но потом дошедшими — 2
  • Были смертельно повреждены, что потребовали гарантийной замены — 1
  • Незначительные обратимые повреждения, что потребовало усиления упаковки, решившей эту проблему — 10…15.
  • Международных посылок (Россия -> ***) потеряно — 0
  • Международных посылок считавшихся потеряными, но потом дошедших — 1

Т.е. за 4 года количество проблем принесших мне геморрой и финансовые проблемы можно пересчитать по пальцам.

Логистика и сроки
На удивление, со сроками доставки внутри страны у Почты России все хорошо. ПО крайней мере от отделения до отделения почта ходит в среднем 5-12 дней. Это замеры по трекам и сообщениям клиентов из от Калининграда до Владивостока, города миллионники и мелкие села которые на областной карте то не найти.
С иностранными клиентами тоже проблем практически не было. Один раз наркоконтроль Молдавии докопался до укуренной сопроводительной документации к моей демоплате (кто получал тот в курсе :))) остальным не скажу, не буду обламывать), да посылка в Израиль пришла такой, словно ей в футбол играли. А так даже в Сирию нормально заехала (еще до того как Асада начали мочить). В общем, из России слать зарубеж можно относительно без напряга.

Филиалы ада
Где же ад? А ад в отделениях. Почта может пулей пролететь все сортировки и промежуточные пункты и на долгие недели застрять в отделении. Особенно если это крупное отделение относительно большого города. Людей не хватает, обработка посылок требует огромного количества операций, технологии позапрошлого века и никакой автоматизации. Потому если вы живете в крупном городе и ждете посылку, то ваша надежда дождаться извещения или изменения трекинга стремится к нулю. Но можно прийти в отделение лично и затребовать посылку и с вероятностью в 70% ее найдут. Проверено на многочисленных клиентах.
Пишут мне в панике, что извещения нет, трекинг потерялся сразу после Челябинска. Успокаиваю и рекомендую сходить на почту и спросить — помогает практически всегда.

Ну, а если вы живете в малом городе, то проблем с вашим отделением скорей всего нет вообще. Например, я в прошлом году, в Кургане объехал около 30 отделений, скупал почтовые коробки (они там дешевле в два раза чем в Челябинске) — очереди не было НИ В ОДНОМ отделении. Там же был забавный прикол — в одной обычной хрущебе, с разных торцов было два разных почтовых отделения.

Полезные советы
При получении посылки из России не ждите извещения или обновления трекинга, а после 10-12 дней ожидания топайте в отделение и спрашивайте свою посылку. Скорей всего она уже будет в отделении.

ОЧЕНЬ ВАЖНЫЙ МОМЕНТ! Спрашивать надо КОНКРЕТНЫЙ ТИП отправления. Т.е. если вам пришла бандероль, а вы спросите посылку, то вам с покерфейсом скажут, что посылки вам нет. Видимо это у них профдеформация какая-то, иначе это не обьяснить. Да и бумажки на разные типы отправлений лежат в разных местах у них. Так что обязательно узнайте у отправителя каким именно видом отправления было заслано ваше вложение и спрашивайте именно его. Часто тип пишут в трекинге. Обязательно также указывайте класс отправления. Если пришло первым классом, то так и спрашивайте иначе могут не найти. Из за бугра, если отправление меньше 2кг, то это скорей всего мелкий пакет. Особого стимула тщательно рыть все отделение у них нет. Так направьте их сразу в сторону правильной полки.

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

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

В качестве упаковки может служить любая коробка, лишь бы она была без какой либо маркировки вообще и по пропорциям и габаритам походила на стандартные почтовые коробки. Ну и была прочной как сейф. Будут отпираться, можно потыкать их в правила оформления почтовых отправлений. Там ни слова нет о том, что коробка должна быть исключительно фирменная. Если много шлёте, то купите коробки у стороннего поставщика, их много. Обойдется раза в 3-4 дешевле.

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

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

Возмездие
Не стеснятесь катать жалобы. На сlient@russianpost.ru На них реагируют очень оперативно. Так, например, после первой же заявы в зале отделения 454080 были подключены кондиционеры, которые были смонтированы, но не запитаны и висели просто так пол года. А после еще парочки заяв заработала электронная очередь и вернули стулья в зал ожидания. Потом, конечно, опять пришли смешные отписки от администрации почты, но результат был достигнут. (То же самое касается, кстати, любой госконторы. Вам, конечно, придет гнилая отписка, но саму контору при этом начинают жестко дрючить сверху. Моя мама как то раз так анально покарала местную поликлинику, что теперь при ее виде у главврача нервный тик начинается. А делов то было в интернет-приемную к мадам Арбидол накатать заяву.)

З.Ы.
Почту может сильно спасти доскональная переработка техпроцесса обработки почты в отделении. Дело даже не во внедрении всякой техники. А в стандартизации процесса, уменьшении лишних операций и процедур и отработки эргономики всего этого. Я как то подсчитал, что на отправку обычной посылки оператору надо совершить 15 операций из которых половину можно смело выкинуть. При этом она еще мечется с посылкой от стола к столу. В то же время, для отправления бандероли первого класса того же размера и веса оператор делает на 5 операций меньше, которые тоже можно сильно сократить. То же касается прием платежей, выдачи посылок/пенсий и кучи всего другого, что происходит на почте.

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

ссылка на оригинал статьи http://habrahabr.ru/post/174889/

Во Франции тестируют доставку газет дронами

Во Франции в ближайшее время может стать реальной футуристичная картина — к дому подлетает компактный дрон, аккуратно сбрасывает прикреплёный пакет с газетами на зелёный газон и, чуть слышно шурша пропеллерами, летит к следующему дому.

Французская почтовая служба «La Poste Groupe» начала тестирование службы доставки утренних газет дронами типа Parrot, который представляет модификацию из уже известного ранее на Хабре квадрокоптера стоимостью около $300 и которым можно управлять при помощи iOS или Android-устройств. Только в данном случае вариант применения устройства выглядит более серьёзным и практически ценным — Parrot.com заключила официальное соглашение с почтой Франции.

Правда, пока у дронов существуют серьёзные ограничения — крайне небольшой радиус действия (50 метров) и всего получасовая работа от батареи. Также не вполне понятно как именно будет происходить доставка: будет ли дрон полностью автономным — то есть, будет ли он знать куда и в какое время подлететь или им реально будет управлять почтальон со своего айпада. Также любопытна механика того, как именно будут «сбрасываться» газеты.

Тестирование назначено на май и всего в проекте будет участвовать солидная партия дронов — 20 штук.

В полёте «дрон-почтальон» выглядит таким образом:

[Источник]

ссылка на оригинал статьи http://habrahabr.ru/post/174887/