Pull to refresh
  • by relevance
  • by date
  • by rating

Работа с клиентом или «почему вы не сделали то, что мы просили?»

Website development *
Sandbox

Предисловие


Нельзя сказать, что я очень прямо вообще такой матёрый веб-девелопер, но за свой очень насыщенный год в качестве профессионального разработчика прошёл сквозь огонь, лёд, пламя, медные трубы, и код в базе данных в исполнении индусов. Особенно большие впечатления от индусов. Но всё это меркнет по сравнению с заказчиками. Как выяснилось, самое сложное в разработке — это угодить всем тем людям, которые нанимают тебя и даже платят тебе деньги. Ты можешь до невозможности гордиться своим детищем, но ему то всё равно, чем вы там гордитесь. И за это время я узнал множество лайфхаков и тонкостей. До определенного момента времени думал, что все крутые парни знают все эти фичи, но в последнее время всё чаще убеждаюсь, что некоторые вещи всё же следует донести до масс.
Читать дальше →
Total votes 61: ↑48 and ↓13 +35
Views 34K
Comments 34

Обзор процесса разработки программного обеспечения

Website development *
Sandbox

Введение


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

Я работаю в IT последние 15 лет, хотя программированием начал заниматься значительно раньше. Основное направление моей деятельности как системного архитектора была организация разработки программ, разработка концепций и верхнеуровневой архитектуры и контроль выполнения концепции на протяжении проекта. Кроме управления разработкой ПО и создания архитектуры, я время от времени занимаюсь решением сложных технических проблем и написанием некоторых критически важных участков кода, где необходимо не только знание самого языка и среды разработки, но и их внутренней организации, иногда преподносящей неприятные сюрпризы.

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

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

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

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

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

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

Другая сторона наших заказных проектов – высокие требования к функциональности. Это и высокая нагрузка на все системы, и большая географическая распределённость, и высокие требования к точности вычислений при очень ограниченных временных рамках. Часто в наших проектах появляются элементы исследовательской работы и творческого поиска, направленного на решение нетривиальных проектных задач. Иногда нам приходится комбинировать в рамках одного процесса разработки разные методологии, например, вставляя в общий процесс, близкий к RUP, один или несколько этапов почти чистого scrum, порождая что-то вроде проекта в проекте. Это позволяет нам сохранять невысокий уровень вовлеченности пользователей, связанный с природой проекта, с гибкостью разработки в условиях высокой неопределённости требований. В этом плане для меня важен именно подготовительный этап, во время которого можно выбрать необходимую методологию и выстроить оптимальный процесс разработки. Один из примеров применения гибкой методологии я описал в статье «Применение agile при разработке проекта для государственного заказчика».

В качестве примера работы над инвестиционным проектом я могу привести разработку комплексной системы безопасности, которую мы создавали как «коробочный» продукт. Под моим руководством было выпущено последовательно четыре версии этой системы, пользователями которой стали самые разные коммерческие и государственные организации, включая мэрию Москвы, АФК «Система», банки, бизнес-центры и, конечно, наш собственный офис. Первая версия была не очень успешной, но у нас была стратегия развития, которая позволила нам успешно захватить рынок и пережить сложные времена кризиса. Опыт работы над этим и ещё несколькими инвестиционными проектами тоже был учтён при формировании используемого мной процесса разработки.

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

Важно понимать, что переход процесса от одного этапа к другому не имеет чёткой границы. Как правило, работы следующего этапа начинаются по мере выполнения 80-90% работ по предыдущему этапу. Особенно это касается разработки требований, когда в ряде случаев снятие неопределённости происходит лишь к концу проекта. Безусловно, наличие такой неопределённости в проекте является существенным риском и должно находиться под постоянным контролем.
Читать дальше →
Total votes 19: ↑13 and ↓6 +7
Views 149K
Comments 45

Пирамида Маслоу в аспекте разработки ПО

Website development *Programming *
Sandbox
Предлагаю читателям «Хабрахабра» перевод заметки «Maslow's Hierarchy of Needs of Software Development», которую я нашел в блоге Скота Ханселмана.

Я тут немного экспериментировал со своей диетой и думаю перейти на «палео»-диету. Впрочем, это очень самонадеянно c моей стороны, вот так вот, в корне, изменить свое отношение к еде. В наше время только весьма обеспеченные люди могут позволить себе в полной мере экспериментировать в этой области.

Человек не склонен заботиться о благах высокого порядка до тех пор, пока не удовлетворены потребности более низкого порядка. Ниже пример пирамиды потребностей по Маслоу:

image

Недавно я общался с заказчиком, где один хороший человек большей частью был озабочен стилем кода: расположением фигурных скобок, применением проверенных решений («best practices») в дизайне интерфейсов и еще кучей важных, но едва ли критичных вещей. В то же время в их организации не было поставлено модульное тестирование («unit-testing»), развертывание («deployment») проводилось вручную, а сборки были слабо верифицируемыми («verifiable build»).

Говоря иначе, он был сосредоточен на проблеме «достаточно ли я потребляю витамина А?», упустив из виду проблему «есть ли у меня вообще что приготовить к ужину?».

Я подумал: что если спроецировать пирамиду потребностей Маслоу на нашу предметную область — разработку ПО? Под катом пример того, что у меня получилось (благодарю Фила Хаака, Джона Галлоуэя, Джонатана Ванагела и Пола Стовела за участие в «мозговом штурме»).
Читать дальше →
Total votes 20: ↑19 and ↓1 +18
Views 20K
Comments 7

Подготовительный этап разработки программного обеспечения

Website development *
Если вы не знаете, в каком направлении развивать проект, то он вряд ли выберет нужный путь самостоятельно.
Стив Макконнелл

Введение


В предыдущей статье «Обзор процесса разработки программного обеспечения» [1] я рассказал о самом «верхнем уровне» процесса разработки, сложившегося в моей практике на текущий момент. Во введении к «Обзору» я постарался сформулировать используемые термины и привёл примеры некоторых проектов, в которых использовался рассматриваемый процесс.

Сегодня я расскажу, как мы проводим подготовительный этап разработки ПО. У подготовительного этапа есть два коллективных действующих лица: заказчик и исполнитель. У каждой стороны есть свои интересы и свои цели в рамках этапа. Описывая подготовительный этап, я постараюсь представить обе точки зрения, их взаимосвязи и возможные конфликты интересов.

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

Для достижения поставленных целей заказчику и исполнителю совместно нужно решить ряд вполне определённых задач:

  1. На основе исходной идеи сформулировать цели и задачи будущего проекта.
  2. Разработать некоторое исходное видение – концепцию проекта.
  3. Провести анализ востребованности будущего продукта.
  4. Провести предварительную оценку рисков будущего проекта.
  5. На основе концепции и списка предварительных рисков подготовить предварительное техническое решение.
  6. Выбрать методологию разработки и подготовить предварительный план работ.
  7. Провести предварительную оценку трудозатрат и необходимых ресурсов.
  8. Провести анализ реализуемости продукта.
  9. Провести независимое рецензирование технического решения.
  10. Принять решение о том, стоит ли продолжать работы.

Читать дальше →
Total votes 12: ↑9 and ↓3 +6
Views 42K
Comments 0

Чеклист для творческих процессов

Usability *


Чеклист это такой костыль для человеческой памяти, который помогает не забыть что-то сделать или проверить что бы не ошибиться при какой-либо активности. Хотя я думаю что все хотя бы примерно понимают о чем идет речь.

В компании Wild Apricot, где я работаю, мы используем чеклисты как один из инструментов для контроля качества релизов достаточно широко. У нас это список действий, которые надо обязательно выполнить что бы фича ушла в релиз. У нас есть чеклисты разработчика, тестировщика (о!.. сколько у тестировщиков тест-листов...), и даже чеклист аналитика и дизайнера. Сравнительно недавно я занимался его переработкой и хотел бы поделится уроками, которые при этом получил.
Читать дальше →
Total votes 8: ↑6 and ↓2 +4
Views 11K
Comments 0

Немного о сборке мобильного приложения

Mail.ru Group corporate blog Website development *Development of mobile applications *Development for Android *Mobile applications testing *
image

Я помню то замечательное время, когда сборка релизной версии мобильного приложения сводилась к тому, что нужно было выставить debug = false и запустить экспорт apk-файла. Проходит 2 минуты, пока пыхтит IDE, и все готово. Все усилия сосредотачивались на необходимости указать данные сертификата подписи. Это было совсем недавно. Cейчас процесс сборки того самого приложения разросся настолько, что, если мне, вдруг, потребуется выполнить все операции самостоятельно, и даже если я все вспомню и проделаю безошибочно (во что я не верю), то это займет не час, который сегодня кажется непозволительно долгим, а, скорее всего, сутки, после чего терапевт обязан будет прописать мне больничный по усталости недели на две.

Итак, процесс сборки мобильного приложения. Попробую рассказать, из чего он у нас состоит — не потому, что в последнее время стало модным катать посты о CI той или иной мобильной команды (с покером, русалками и прочими обязательными атрибутами), а потому, что это отличный опыт, который я получил, работая над Почтой Mail.Ru для Android, и потому, что этой возможности, вероятнее всего, не было бы, работай я в другой команде, над другим проектом или в другой компании.
Читать дальше →
Total votes 25: ↑23 and ↓2 +21
Views 24K
Comments 18

Почему и зачем писать open-source код?

Website development *Open source *Programming *Open data *
image

Под катом интересный опрос

Возможно, заголовок этой статьи покажется Вам не корректным, ”Как можно писать open-source код? И что это за код такой?” — спросите Вы.

Чем open-source код отличается от “просто-кода”? Open-source проект — это ответственность за качество кода, за покрытие его тестами, за документацию, за своевременные ответы на вопросы и реагирование на bug репорты, за обработку pull-request’ов. Ваше поведение и мысли во время написания open-source кода, который увидит мир будут другие, соответственно и код на выходе получается другой.

Open-Source проект живет своей жизнью — жизнью сообщества, которое образуется вокруг проекта. Идеи, отзывы, bug репорты, обсуждение и благодарности от других членов сообщества влияют на Вас и проект напрямую, и стимулируют написание кода — понятного, документированного и покрытого тестами.
Читать дальше →
Total votes 43: ↑33 and ↓10 +23
Views 28K
Comments 65

J.A.R.V.I.S. — невидимый помощник Leo

Lingualeo corporate blog Website development *
Рано или поздно IT-проекты сталкиваются со сложностями поддержания высокого качества кода и/или увеличивающимся временем доставки изменений в production. Lingualeo испытала на себе все проблемы роста и готова поделиться своей историей повышения эффективности разработки. О том, как это происходило, рассказал teamlead инфраструктурой команды Lingualeo Михаил Кабищев.
image

Как и любая другая технологическая компания, Lingualeo проходила через несколько этапов:

  • Начало разработки продукта. Разработка и отладка происходит на одном-единственном сервере, где запущено все, что нужно проекту. Ошибки бывают часто, но это не страшно, т.к. это все лишь прототип, и живых пользователей там еще нет.
  • Появление первых пользователей. Компания начинает ощущать цену ошибок и проблем на продакшене. Уже нельзя править все на продакшене, приходит понимание того, что нужно мыслить релизами. Разработчики внедряют workflow для работы с кодовой базой, появляется что-то вроде stage-сервера, на котором тестируются релизы.
  • Рост проекта и команды. В разработке одновременно находится большое количество задач. Требования к процессу и качеству кода сильно возрастают. За всем очень тяжело следить: кто-то забывает запустить юнит-тесты, кто-то не знает, куда и как нужно задеплоить очередную задачу для тестирования.

В итоге рутинные операции начинают отнимать очень много времени, и компания думает, как автоматизировать эти процессы.
Читать дальше →
Total votes 17: ↑14 and ↓3 +11
Views 14K
Comments 20

«30 day challenge» по веб-программированию

Studying in IT


Я не программист. Я немного знаю PHP (проходил курсы около 20 часов), но больше 15 строк кода никогда не писал. Но недавно, вдохновленный экспериментом Мета Каттса, я решил провести над собой похожий эксперимент. Мне стало интересно, смогу ли я создать хотя-бы небольшой готовый продукт за 30 дней и параллельно подучить PHP. Проверить насколько сложно заставить себя делать что-то не обычное каждый день. Также я решил периодически делать заметки о том, как продвигается моя работа и вот, что из этого получилось.
Читать дальше →
Total votes 16: ↑14 and ↓2 +12
Views 6.5K
Comments 7

История одного бота

Self Promo

Всем привет! Последние 4 месяца я занят разработкой некоммерческого бота для Telegram. Сейчас в него ежедневно играет от одной до четырех сотен людей и для меня это большой успех. Если вам интересна история разработки, то прошу под кат.


Читать дальше →
Total votes 45: ↑40 and ↓5 +35
Views 18K
Comments 58

Четыре НЕ — секретные советы Штирлица

System Analysis and Design *Designing and refactoring *
В данном праздничном обзоре, посвященном Дню Защитника Отечества, будут рассмотрены четыре критичных ошибки управления процессами проектирования информационных систем.

image

Создавая современные интернет-инструменты для роста прибыли, необходимо максимально глубоко внедриться в сферу интересов заказчика и выведать множество специфической информации. Затем перевербовать заказчика на свою сторону, расколоть его на истинные цели и заполучить доступ к секретнейшему документу любого бизнеса — его бизнес-плану. Сложно, но для настоящих Штирлицев 21 века это возможно, но только при условии соблюдения тактики “Четырех НЕ”.
Читать дальше →
Total votes 19: ↑11 and ↓8 +3
Views 6.1K
Comments 2

Статический анализ как часть процесса разработки Unreal Engine

PVS-Studio corporate blog Open source *C++ *Game development *Game testing *
PVS-Studio & Unreal Engine

Проект Unreal Engine развивается — добавляется новый код и изменятся уже написанный. Неизбежное следствие развития проекта — появление в коде новых ошибок, которые желательно выявлять как можно раньше. Одним из способов сокращения количества ошибок является использование статического анализатора кода PVS-Studio. Причем анализатор также быстро развивается и учится находить новые паттерны ошибок, некоторые из которых будут рассмотрены в этой статье. Если вас заботит качество кода ваших проектов, то эта статья для вас.
Читать дальше →
Total votes 27: ↑22 and ↓5 +17
Views 9.1K
Comments 1

Как мы починили свой процесс и стали меньше отвлекаться

Development Management *GTD *Agile *
В прошлом году наша команда прошла через жесткий слом процесса разработки, но смогла восстановить его и сделать еще лучше: понятней, приятней и продуктивней.

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

Читать дальше →
Total votes 18: ↑16 and ↓2 +14
Views 13K
Comments 19

Начальник, хочу работать из дома

Development Management *Personnel Management *
Sandbox
Несколько лет назад примерно с такой фразой ко мне пришел один из ведущих программистов. Давайте назовем его Иваном (все персонажи вымышленные, а любые совпадения случайны). Он собирался переехать жить за город и каждый день ездить в офис ему стало неудобно. У Ивана был приличный послужной список, несколько лет работы в компании и большой вагон доверия. Тогда мы договорились, что Иван будет работать удаленно понедельник и пятницу, а вторник-четверг он приезжает в офис с утренним графиком.
Читать дальше →
Total votes 157: ↑150 and ↓7 +143
Views 62K
Comments 370

Анализ статьи «Начальник, хочу работать из дома»

Development Management *Personnel Management *
Недавно наткнулся на Хабре на статью «Начальник, хочу работать из дома». В ней автор рассуждает, какие преимущества имеет удаленная работа из дома, над работой в офисе и приводит аргументы в пользу этой практики. Причем аргументы в защиту такого подхода, на мой взгляд, не очень убедительные. Но об этом чуть позже.

Статья привлекла меня 3-мя интересными на мой взгляд аспектами: 1) сама тема очень злободневна и статья получила множество комментариев, 2) публикация набрала рейтинг более 100, 3) при этом она не несет в общем-то никаких реальных объяснений, а построена на очень спорных аргументах — лозунгах.
Читать дальше →
Total votes 76: ↑39 and ↓37 +2
Views 13K
Comments 216

Анализ v_2.0 статьи «Начальник, хочу работать из дома»

Development Management *Personnel Management *
Недавно я предпринял попытку провести анализ статьи «Начальник, хочу работать из дома», опубликованной на Хабрахабр. Ключевые аспекты выбора статьи – это высокая востребованность самой темы и высокий рейтинг статьи, в частности.

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

В итоге, рейтинг мой статьи разделился почти пополам 37 «против» и 39 «за», собрав больше 200 комментариев, что само по себе подтвердило, что тема в тренде.

Прежде всего хочу выразить благодарность всем принявшим участие в обсуждении.
Читать дальше →
Total votes 17: ↑9 and ↓8 +1
Views 8.6K
Comments 20

Пулл-реквесты с эмпатией

MobileUp corporate blog Programming *Designing and refactoring *Industrial Programming *
Translation


В компании Slack считают, что эмпатия — это суперспособность, и у разработчиков она должна быть включена по максимуму.

Разработка высококачественных программ сильно зависит от того, насколько качественное ревью кода делают коллеги. Это помогает обнаружить ошибки, избежать двойной работы и в целом обеспечить лучшее качество кода с меньшими усилиями. Код ревью — это критически важная часть процесса разработки.
Читать дальше →
Total votes 11: ↑11 and ↓0 +11
Views 6.2K
Comments 8

Команда разработчиков Renga: как мы достигли идиллии, работая без менеджеров

АСКОН corporate blog CAD/CAM *Development Management *Agile *IT career
7 команд и ни одного менеджера – думаете, такое возможно? Мы построили процесс, в котором показываем на каждом демо по 1-2 фичи от команды, проводим ретро команд, ретро релизов и при этом получаем реальное удовольствие от работы. Хотите организовать свою работу так же? Тогда добро пожаловать под кат.



Мы, компания Renga Software, занимаемся разработкой программных продуктов для проектирования зданий и сооружений в соответствии с технологией информационного моделирования (BIM). Идем спринтами, выпускаем релизы каждые 3-4 месяца. Пользователей системы с каждой неделей становится всё больше. Продукт совсем молодой, поэтому бэклог переполнен важными, а главное, интересными задачами. Но как в короткие сроки разработать продукт, который будет использоваться для проектирования жилых домов, детских садов, больниц и театров?
Читать дальше →
Total votes 25: ↑24 and ↓1 +23
Views 19K
Comments 29

Как мы достигли идиллии, работая без менеджеров. Часть 2. Тайная комната

АСКОН corporate blog CAD/CAM *Development Management *Agile *IT career
Привет тебе, дорогой читатель! В предыдущей статье я рассказывал о том, как 28 разработчиков смогли выстроить рабочий процесс, в котором нет роли менеджера. Мы продолжаем с удовольствием работать и выпускать сложные фичи одну за одной. Скоро нам предстоят бессонные ночи перед выпуском релиза. И затем самый приятный этап — технический спринт и проведение ретро релиза, а также мероприятия по планированию следующего релиза.

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


Читать дальше →
Total votes 34: ↑32 and ↓2 +30
Views 19K
Comments 27

Организация процессов производства информационных систем. Часть 1. Отправная точка

System Analysis and Design *IT Infrastructure *Industrial Programming *Development Management *Business Models

I Вступление

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

Исходя из всего вышесказанного, мне показалось, что будет весьма полезно собрать и описать структуру процесса производства программных продуктов (ну хотя бы основных вариантов), при этом не вдаваясь глубоко в специфические детали, а фабулу изложить в формате, предельно доступном для широкого круга лиц. Естественно данная публикация – это лишь мой взгляд на предмет.
Читать дальше →
Total votes 12: ↑12 and ↓0 +12
Views 7.5K
Comments 4