"Конечно отдельная!", — ответит большая часть читающих. Такой ответ укладывается в их картину мира, потому что “так работали всегда”. 

Так работали всегда

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

Компания понимает, что обойтись без страховочной сети нельзя, поэтому создается QA-отдел, который обычно не обеспечивает качество продукта, а лишь контролирует его. С QA-отделом разработчик может спокойно заниматься любимым делом — писать код, ведь ответственность за качество теперь несет выделенный отдел! Происходит классическое “перебрасывание кода через стену” в отдел тестирования:

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

Сегодня большая часть работы выглядит так: есть некий деловой человек-владелец бизнеса, который нанимает людей для делегирования им каких-то видов деятельности.
Цель дельца — заработать на машину/дом/яхту/остров и т.п. в зависимости от амбициозности.
Нанятые сотрудники — это винтики в механизме, создатель механизма не очень-то заинтересован в том чтобы винтики возомнили себя бизнесменами, поэтому старается не перегружать никого информацией о всех тонкостях бизнеса (некоторая разновидность принципа «разделяй и властвуй»).

Золотое правило управления: В каждой фирме всегда есть один человек,
который понимает что происходит на самом деле, вот его-то и нужно
уволить в первую очередь.

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

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

Perl — это когда-то бывший популярным для веба, но ныне умирающий, язык. Умирающий вполне обоснованно, поэтому хотелось бы слезть с него на что-то массово востребованное (Java).

Проблема

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

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

Целью этой статьи является предоставление гайдлайнов и реализации для определенных непрерывных переходов между фрагментами ОС Android. Мы продемострируем, как реализовать переход из картинки в RecyclerView в картинку внутри ViewPager и обратно, используя "общие элементы" (shared elements) чтобы определить, как и какие элементы участвуют в переходе. Мы также обработаем сложный случай перехода обратно в сетку после листания на странице к элементу, который в сетке изначально был за пределами экрана.

Вот результат, которого мы хотим добиться (анимированная версия под катом).

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

От переводчика. Далее будет довольно много кода и гифок (по прикидкам, мегабайт на 20).

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


В 2016 году психолог и бизнес-коуч из США Сьюзан Дэвид обобщила свой двадцатилетний опыт консультирования и теоретические наработки в книге «Эмоциональная гибкость: Как научиться радоваться переменам и получать удовольствие от работы и жизни». Концепция, представленная в этом труде, стала одной из самых обсуждаемых новинок и собрала немало регалий: Amazon объявил его лучшей книгой 2016-го, а само понятие «эмоциональная гибкость», введенное в обиход исследовательницей, удостоилось звания идеи года по версии Harvard Business Review. В двух словах эту идею можно выразить так: успех предопределяется тем, как мы выстраиваем взаимодействие со своим внутренним миром и, в первую очередь, эмоциональными откликами. На первый взгляд звучит, как нечто крайне абстрактное на тему личностного роста, но на деле многие тезисы универсальны и вполне годятся для ежедневного применения на работе и в быту. Мы прочитали и законспектировали основные мысли для тех, у кого мало времени, но много мотивации.

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

Суть проблемы

Продажа – самое начало проекта и ошибки на этом этапе – самые страшные. Не проработаете ожидания клиента или промахнетесь с оценками и вас ждет «путь камикадзе». Перезаложите бюджет – потеряете клиента или у него сложится ощущение обманутости.

Чтобы хорошо продавать ПО необходимо обладать солидным опытом как в разработке (технологиях, менеджменте и процессах), так и в продажах. Эти компетенции крайне сложно совместить в одном человеке, а когда они совмещаются, такой человек называется «основатель компании» или «исполнительный директор». Я знаю примеры компаний, в которых директор проводит первичную обработку всех заказов на разработку. Обычно потолок роста такой компании 25-30 человек, а директор – перегружен.

Альтернативный вариант – делегировать оценку техническому директору (CTO). Обычно, это второй по перегруженности человек в компании. Кроме того, у технического директора вагон и маленькая тележка других задач. Таскать его на каждый pre sales – не вариант. Я искренне убежден, что любой нетривиальный проект можно разрабатывать только итеративно и только с прототипами. Такой подход до сих пор сложно принять многим клиентам на территории СНГ. Все хотят на берегу зафиксировать сроки и бюджет. К сожалению, это желание не сопровождается техническим заданием, на основании которого можно было бы работать. Хотя с точки зрения клиента конечно задача поставлена чётко и ясно.

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

Трем программистам предложили пересечь поле, и дойти до дома на другой стороне. Программист-новичок посмотрел на короткую дистанцию и сказал, «Это не далеко! Это займет у меня десять минут». Опытный программист посмотрел на поле, немного подумал, и сказал: «Я мог бы добраться туда за день». Новичок посмотрел на него с удивлением. Гуру-программист посмотрел на поле и сказал. «Кажется минут десять, но я думаю пятнадцати будет достаточно». Опытный программист рассмеялся.

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

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

Гуру программист пустился в путь, и пошел прямо через поле. Целеустремленно и прямо. Он достиг цели всего за десять минут.
«Как тебе это удалось?» — спросили двое других — «Как ты умудрился не зацепить ни одной мины?»
«Легко» — ответил он. «Я не закладывал мины на своем пути».

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

Вот уже около трех лет я использую в работе принципы Spec By Example, Domain Driven Design и CQRS. За это время накопился опыт практического применения этих практик на платформе .NET. В статье я хочу поделиться нашим опытом и выводами, которые могут быть полезными командам, желающим использовать эти подходы в разработке.

Детектив по материалам IT. Часть вторая

В этой части я покажу как изначально выглядело деление пользовательского интерфейса и что из себя представляли Вид и Контроллер. Попробую рассказать почему в современных GUI библиотеках используется их объединение и какие вообще интересные решения можно найти в этой области на сегодняшний день. Ссылки на первоисточники приведены в начале первой части.

Начну с Вида. Не смотря на то, что Вид определяется как модуль, отображающий Модель – "а view is a (visual) representation of its model", на практике к Виду, как правило, просто относят все графические элементы GUI, то есть Видом считается все то, что мы видим на экране ЭВМ.

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

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

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

Меня всегда занимал вопрос, как создаются компании и организации, как образуются те центры самоорганизации, на которые осаждаются сотрудники и ресурсы из совсем даже не насыщенного «раствора» внешней среды.

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

«Почему ж всё так плохо?» — каждый раз я задаюсь этим вопросом, когда приходится иметь дело с очередным кодом, продуктом или API, созданными для внутренних нужд в непрофильной организации.

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

И деньги ничего не решают: ужасный код и ужасные продукты пишут как маленькие бедные ВУЗы, у которых денег хватает только на рабский труд аспирантов, так и крупные и богатые компании, включая IT-компании, включая зарубежные: несколько раз сталкивался с кодом, который писали зарубежные подрядчики и каждый раз от него хотелось рыдать и биться головой об стену.

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

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

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

Тем, кто знаком с криптографией с открытым ключом, наверно известны аббревиатуры ECC, ECDH и ECDSA. Первая — это сокращение от Elliptic Curve Cryptography (криптография на эллиптических кривых), остальные — это названия основанных на ней алгоритмов.

Сегодня криптосистемы на эллиптических кривых используются в TLS, PGP и SSH, важнейших технологиях, на которых базируются современный веб и мир ИТ. Я уже не говорю о Bitcoin и других криптовалютах.

До того, как ECC стала популярной, почти все алгоритмы с открытым ключом основывались на RSA, DSA и DH, альтернативных криптосистемах на основе модулярной арифметики. RSA и компания по-прежнему популярны, и часто используются вместе с ECC. Однако несмотря на то, что магия, лежащая в фундаменте RSA и подобных ей алгоритмов легко объяснима и понятна многим, а грубые реализации пишутся довольно просто, основы ECC всё ещё являются для большинства людей загадкой.

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

I Вступление

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

Эдгар Аллан По

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

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

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

Итак, поехали…

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

С частью 1 можно ознакомиться, перейдя по ссылке.

III Через взаимопонимание к эффективным взаимоотношениям

Для успеха в жизни — умение общаться с людьми гораздо важнее обладания талантом
Джон Леббок

Итак продолжим… Оттолкнувшись от вопроса взаимопонимания в отношениях, давайте разовьем тему общения и расширим рамки исследования.

Для того, чтобы четко понимать основы эффективного взаимодействия с людьми, рассмотрим под разными углами принципы Коммуницирования. Для этого можно вспомнить какие-то известные вам события из жизни или обратиться к источникам информации. Например, интернету. Лично я выбрал для себя следующие темы:

1. Дознаемся об эффектах коммуникации

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

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

Помните трюк с курилкой из фильма «Москва слезам не верит»:

―А я вот в научный зал Ленинской библиотеки пропуск достала.
―Зачем?
―Представляешь, какой там контингент? Академики, докторы, философы.
―Ну и что, будешь смотреть, как они читают?
―Много ты понимаешь. Там еще курилка есть…

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

С частью 1 можно ознакомиться, перейдя по ссылке
С частью 2 можно ознакомиться, перейдя по ссылке

IV Подбор методов управления отношениями с людьми

Теперь, когда мы определили из чего же складываются взаимоотношения и выяснили факторы, регулирующие их, перейдем к действиям, позволяющим ими эффективно управлять. Иначе говоря, выяснив «ЧТО ДЕЛАТЬ», теперь определим «КАК ДЕЛАТЬ» и таким образом еще на шаг приблизимся к поставленной цели.

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

1. Детализация сложных явлений и событий

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

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

Пробная версия этой статьи ранее уже публиковалась мною.

I Вступление

Я хочу поделиться теорией, которую недавно создал.
Агент Смит (Фильм «Матрица»)

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

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

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

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

С частью 1 можно ознакомиться, перейдя по ссылке

III Механизмы построения социального организма

Примешь синюю таблетку — и сказке конец.
Ты проснешься в своей постели и поверишь, что это был сон.
Примешь красную таблетку — войдешь в страну чудес.
Я покажу тебе, насколько глубока кроличья нора.
Морфеус (Фильм «Матрица»)

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

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

Для удобства, пойдем сверху вниз по списку функций, указанных а разделе 6 предыдущей главы.

С частью 1 можно ознакомиться, перейдя по ссылке
С частью 2 можно ознакомиться, перейдя по ссылке

IV Обеспечение жизненного цикла социального организма

Давно не живу планами. Они не всегда сбываются, ведь в них участвуют люди, что срывает любые гарантии. Ничто никогда не идет по плану. Лучше уж импровизация.
Эльчин Сафарли. («Мне тебя обещали»)

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