Русский
Русский
English
Статистика
Реклама

Инструменты

Иван Чашкин Мне нравится, что OpenStreetMap это открытые данные, которые доступны всем и всегда

17.06.2020 12:21:27 | Автор: admin

Иван Чашкин web-программист и владелец небольшого интернет-магазина из Нижнего Новгорода. Но после работы он волонтер. Причем в абсолютно разных проектах: он и куратор Добрых крышечек в своем городе и опытный картограф OSM, который сделал несколько интересных инструментов. Почему он кайфует от JOSM, зачем надо отмечать подъезды и как лучше всего это сделать обо всем этом он рассказал в интервью.

Когда и как вы познакомились с проектом OpenStreetMap?

10-15 лет назад был проект Пробковорот, который строил карту пробок. Я им активно пользовался. И то ли он в какой-то момент перешел на OSM, то ли сразу его использовал. Но вот через это приложение я и узнал про существование OSM.

Почему вы начали редактировать карту в OSM? Как это случилось?

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

Сложно ли вам было влиться в проект, изучить его теги, структуру, архитектуру?

Нет, не сложно, так как я увлекаюсь программированием. По мне так, OSM спроектирован достаточно логично. К тому же, есть WikiOSM, где все подробно написано практически о каждом теге. Если чего-то нет на русском, то это точно есть на английском языке. Если же все равно остались вопросы, всегда можно зайти на форум и попытать его обитателей, которые сразу же подскажут направление.



Сейчас продолжаете картографировать?

Продолжаю, но, в основном, отмечаю подъезды с номерами квартир, иногда магазины, а также, если иду или еду по незнакомой для меня территории и вижу какие-то интересные POI или нестандартное дорожное ограничение, то ставлю точку в навигаторе с комментарием. Потом уже дома, когда доходят руки, сверяюсь с OSM и вношу если необходимо правки. Помимо этого, если еду куда-то далеко или когда бываю в небольших деревнях, стараюсь всегда записывать GPS-треки, а после загружать их в OSM, чтобы потом по ним можно было выровнять спутниковые карты. А вообще есть идея сделать сервис, который бы показывал, где треков нет или они уже устарели и неплохо бы съездить туда ещё разок.

Как вы картографируете? Поделитесь своими секретами? Какие используете программы, как собираете информацию и пр.

Сейчас много правок вношу через мобильный навигатор Maps.Me. Он позволяет делать простейшие правки, в том числе оставлять заметки. Иногда использую Keypad-Mapper_3 это мобильное приложение, с помощью которого удобно собирать информацию, а именно номера домов. Треки пишу в OSM Tracker, когда это делаю, параллельно запускаю приложение Tower Collector, которое сопоставляется координаты с сигналом сотовой связи для проекта OpenCellId. Также как-то пробовал снимать панорамы улиц для Mapillary и OpenStreetCam, прикольная штука. Рекомендую. Неплохо так упрощает картирование.

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

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

Все-таки, почему подъезды?

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

К тому же, их достаточно просто отмечать: идёшь по улице и записываешь с табличек номера подъездов и квартир в них. Обычно я это делаю через Maps.Me: ставлю в нем маркер и делаю к нему подпись вида 3:21-40 это означает, что здесь находится подъезд 3, в котором располагаются квартиры с 21 по 40. Когда дом более-менее стандартный, то можно записывать только последнее число, например, 1:-20, -40, 3:-60 и т.д. Сейчас мне также периодически приходится ездить развозить заказы по адресам и если есть номера квартир в подъезде, то сразу можно построить маршрут к финишу и даже приблизительно прикинуть этаж квартиры. Кстати, недавно мне пришла мысль попробовать сделать геокодер, который бы по адресу выдавал бы координаты места с точностью до подъезда, сделал небольшой прототип и сейчас тестирую когда есть время.



Вы автор многих полезных валидаторов. Самый известный из которых валидатор подъездов. Ни одна картоакция в сообществе, связанная с номерами подъездов, не обходится без него. Расскажите о них. Как они создавались? Зачем их делали?

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

Как я выбираю то, что отображать? Исходя из личных потребностей. С чем я часто работаю в OSM или сталкиваюсь в жизни, то под это и делаю очередную версию визуализатора. Начал картировать подъезды сделал инструмент, который их показывает, чтобы понимать, где они еще не отмечены.

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

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

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

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

Исходный код всех моих визуализаторов или карт есть на GitHub, в основном это JavaScript, минимум серверной части на PHP и да, если нужно, можно свободно использовать для своих целей.



Что вам нравится в OSM? Что не нравится? Что бы сделали лучше?

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

Мне нравится редактор JOSM. Многие его ругают, а я от него кайфую. Сколько лет в OSM, а до сих пор узнаю про него что-то новое, то оказывается, что у него есть эта функция, то другая. К тому же, его можно использовать не только для OSM, но и для других ГИС-задач. У него куча плагинов и невероятная гибкость.

Мне нравится ширина и глубина OSM. Это чуть больше, чем просто карта. Многие говорят, что это база данных, но это цифровая модель мира. Поэтому в нем хранится гораздо больше, чем вы видите на первый взгляд. В нем есть место, как информации о качестве дорог, так и даже 3D.

Не нравится, когда люди не понимают суть проекта и портят данные. Сообщество все равно вернет всё назад, но жалко потраченного времени. Так было с покемонами, так сейчас происходит с переписью населения. Зачем это делать? Ведь эти данные в любом случае удалят.

Что бы сделал лучше? Наверное, я пожелаю разработчикам многочисленных программ, которые есть в мире OSM, терпения, сил и ярких идей. Мы пользуемся вашими наработками почти каждый день и хотим, чтобы они были еще лучше! Например, я очень жду, когда Maps.Me начнет показывать полосы на дорогах и перекрестках. Я их вношу, вношу, а он их всё не показывает.



Какие бы вы порекомендовали проекты, инструменты, приложения, которые как-то связаны с OSM?

Если говорить про мобильные навигаторы, однозначно рекомендую Maps.Me и OsmAnd. Первый вам пригодится, если вы собираетесь путешествовать по городам, второй если вас ждет поход, у него есть крутые функции, например, водная навигация. Недавно видел отличный проект OpenRecycleMap ребята из Пскова сделали карту на базе OSM, где можно найти или добавить контейнер для раздельного сбора мусора.

Что бы вы сказали тому человеку, который сомневается: использовать данные OSM или нет; участвовать в проекте или нет?

OSM это как Википедия или волонтерство. Ты, как и многие другие участники, делаешь свой небольшой вклад в общее дело, а в итоге получается, что проделана большая работа. Лично мне приятно чувствовать себя сопричастным к таким проектам, которыми пользуется большое количество людей. Вроде бы ты в удовольствие что-то делаешь и для себя, а в итоге это приносит пользу всем :-)



Используете данные OSM по работе? В личной жизни?

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

Что скажете в завершении беседы?

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



Общение российских участников OpenStreetMap идёт в чатике Telegram и на форуме.
Также есть группы в социальных сетях ВКонтакте, Facebook, но в них, в основном, публикуются новости.

Присоединяйтесь к OSM!



Подробнее..

Сочетать карьеру agile-коуча и стендап-комика? Легко и приятно! Рассказывает Илья Якямсев

30.04.2021 22:19:48 | Автор: admin

В этом году в секции Team на DUMP выступит agile-коуч компании Wiley Илья Якямсев. Мы поговорили с Ильей о его докладе, злом стендапе и о том, как сценический опыт помогает вести тренинги.

Илья, привет! На DUMP ты выступишь с докладом Говорите, пожалуйста! Как построить эффективную коммуникацию в команде. А еще ты выступаешь как стендап-комик. Мы не будем тебя просить шутить в нашем интервью, а будем просто задавать вопросы тебе-менеджеру, и тебе-комику.

  • Расскажи подробнее, о чем будет твой доклад? Можно немного спойлеров:)

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

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

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

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

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

  • Где ты учился взаимодействию в команде (или с этим рождаются?) и как прокачивал этот полезный скилл?

Я всегда старался брать обратную связь от всех людей с кем работал и старался хоть маленько изменять на практике своё поведение. И ещё я много читаю и смотрю видео как работают другие люди.

Да, важно - мне это нравится.

  • Как на работу твоей команды повлияла пандемия? Что изменилось?

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

Частично и об этом буду говорить в своём докладе.

  • С чего начиналась твоя карьера agile-коуча? Что считаешь твоим (командным) успехом, а что - провалом?

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

Труднее всего не давать советы и не пытаться прямым действием исправить систему. К этому пытаюсь привыкнуть.

  • Как ты пришел к своему увлечению стендапом? Какой момент стал поворотным?

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

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

  • Какие комики тебя вдохновляют? А проекты и команды?

Меня вдохновляют комики с идеями, где кроме шуток есть интересные точки зрения и/или не банальная литература. Даг Стенхоуп, Джордж Карлин, Саймон Амстел, Эдди Изард, Стюарт Ли.

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

  • Где ты берешь материал для шуток? Как его отрабатываешь и проверяешь? Кто герои твоих выступлений?

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

  • Что ты чувствуешь, когда стоишь на сцене, слышишь смех в зале? А когда выступаешь на конференциях? А прорывается наружу стендапер?

Быть стендап комиком на конференциях - помогает. Гораздо проще выступать перед людьми, когда тебе не обязательно получать регулярный смех. Рекомендую всем хотя бы немного повариться в этой культуре.

Чувствую удовольствие. Иначе бы не занимался.

  • Шутишь ли ты про работу со сцены? И наоборот - привносишь ли опыт комика в работу?

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

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

Ну и тренинги мне из-за этого опыта вести легко и приятно.

  • Есть вероятность, что тебе надоест карьера в Wiley и ты будешь собирать залы?

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

  • Представь, что ты вернулся на 10 лет назад в прошлое, что посоветуешь себе?

Не метаться, идти в одну сторону, и если пошёл, то не пытаться в трудные минуты вернуться обратно. Но вряд ли это получилось бы у меня десятилетней давности, это наживное.

Да, ещё хороший совет - не бросать основную работу пока не нашёл другую основную работу.

  • А кем видишь себя еще через 10 лет?

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

Мне очень нравится удалёнка.

  • На DUMPе ты мы увидим твой полезный доклад для менеджеров разработки. А где можно посмотреть твой стендап (вживую - мы все очень соскучились по офлайну)?

У меня будет концерт в Екатеринбурге, его организуют местные ребята в лофте Место. Вечер 14 мая в 22:00 (после конференции). Приходите, если что.

А послушать Илью как спикера секции Team можно 14 мая в конгресс-центре ЭКСПО оффлайн или в нашей онлайн-трансляции. Билеты выбирай здесь!

Увидимся на DUMP!

Подробнее..

Agile-коуч Илья Якямсев об эффективной коммуникации в команде, докладе на конференции DUMP и пользе стендапа

05.05.2021 10:13:29 | Автор: admin

В этом году в секции Team на DUMP выступит agile-коуч компании Wiley Илья Якямсев. Мы поговорили с Ильей о его докладе, злом стендапе и о том, как сценический опыт помогает вести тренинги.

Илья, привет! На DUMP ты выступишь с докладом Говорите, пожалуйста! Как построить эффективную коммуникацию в команде. А еще ты выступаешь как стендап-комик. Мы не будем тебя просить шутить в нашем интервью, а будем просто задавать вопросы тебе-менеджеру, и тебе-комику.

  • Расскажи подробнее, о чем будет твой доклад? Можно немного спойлеров:)

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

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

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

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

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

  • Где ты учился взаимодействию в команде (или с этим рождаются?) и как прокачивал этот полезный скилл?

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

  • Как на работу твоей команды повлияла пандемия? Что изменилось?

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

Частично и об этом буду говорить в своём докладе.

  • С чего начиналась твоя карьера agile-коуча? Что считаешь твоим (командным) успехом, а что - провалом?

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

Труднее всего не давать советы и не пытаться прямым действием исправить систему. К этому пытаюсь привыкнуть.

  • Как ты пришел к своему увлечению стендапом? Какой момент стал поворотным?

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

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

  • Какие комики тебя вдохновляют? А проекты и команды?

Меня вдохновляют комики с идеями, где кроме шуток есть интересные точки зрения и/или не банальная литература. Даг Стенхоуп, Джордж Карлин, Саймон Амстел, Эдди Изард, Стюарт Ли.

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

  • Где ты берешь материал для шуток? Как его отрабатываешь и проверяешь? Кто герои твоих выступлений?

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

  • Что ты чувствуешь, когда стоишь на сцене, слышишь смех в зале? А когда выступаешь на конференциях? А прорывается наружу стендапер?

Быть стендап комиком на конференциях - помогает. Гораздо проще выступать перед людьми, когда тебе не обязательно получать регулярный смех. Рекомендую всем хотя бы немного повариться в этой культуре. Чувствую удовольствие. Иначе бы не занимался.

  • Шутишь ли ты про работу со сцены? И наоборот - привносишь ли опыт комика в работу?

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

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

  • Есть вероятность, что тебе надоест карьера в Wiley и ты будешь собирать залы?

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

  • Представь, что ты вернулся на 10 лет назад в прошлое, что посоветуешь себе?

Не метаться, идти в одну сторону, и если пошёл, то не пытаться в трудные минуты вернуться обратно. Но вряд ли это получилось бы у меня десятилетней давности, это наживное.

Да, ещё хороший совет - не бросать основную работу пока не нашёл другую основную работу.

  • А кем видишь себя еще через 10 лет?

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

Послушать Илью как спикера секции Team можно 14 мая в конгресс-центре ЭКСПО оффлайн или в нашей онлайн-трансляции. Подробнее о программе.

Подробнее..

Современный фронтенд без ошибок и костылей. 8 полезных докладов конференции DUMP

20.04.2021 22:19:53 | Автор: admin

Привет, Хабр!

На связи IT-конференция DUMP и программный комитет секции Фронтенд: Полина Гуртовая (frontend-разработчик в Evil Martians) и Егор Ходырев (тимлид, full stack-разработчик в Кнопке)

Кто согласен, что современный фронтенд это сложно? Ради чего мы мучаемся с настройкой Webpack? Почему реализация SSR требует писать столько кода, и нужен ли он нам вообще такой ценой? Кто виноват и что мы, как разработчики, можем сделать?

В этом году вместе с нашими спикерами постараемся максимально чётко ответить на эти и сотни других вопросов в секции Frontend.

Со своими идеями и решениями выступят:







Алексей Охрименко из Яндекс.Музыки выступит с докладом ''Трасси... что?''

Отладка приложения занимает 99% нашего времени. Кто-то пользуется Chrome DevTools, кто-то обходится обычным console.log, кто-то использует профайлеры. Зачастую этих инструментов более чем достаточно. Но есть еще один, не особо известный и популярный в JavaScript мире.
Трассировка процесс пошагового выполнения программы. В режиме трассировки программист видит последовательность выполнения команд и значения переменных на данном шаге выполнения программы, что позволяет легче обнаруживать ошибки.

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







Григорий Петров из Evrone представит доклад ''Нужен ли нам N(e/u)xt.js?''

Современный фронтенд это сложно. Если легаси проекты ограничены, то для новых приложений, кроме настройки Webpack и Babel, у нас есть HMR, SSR, code splitting, routing, кеширование, stream rendering и это, не считая фронтенд фреймворка и бэкенда, CI/CD и деплоя.

HMR "ломается" на приложениях сложнее hello world, настройку SSR в интернетах хором называют "адски сложной", ну, а роутинг, в уважающей себя связке фронт+бэк, можно неправильно организовать десятью конкурирующими способами.

Вся эта сложность породила новое направление jamstack, и такие решения, как Next.js и Nuxt.js "opinionated фреймворки", где все настроено за нас.

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








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

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







Андрей Гончаров из Hazelcast и тема его доклада, которая звучит так: Lifting state up is killing your app.

Слышали ли вы про lifting state up? Может ли одна из двенадцати ключевых концепций в официальной документации React приводить к плохой производительности? В рамках доклада мы сделаем простейший grid на React. Поэтапно разберем возникающие проблемы производительности. Увидим, что иногда и O(1) - это недостаточно быстро. Будем профилировать и рефакторить до тех пор, пока приложение не станет работать быстрее, чем вы успеете сказать React.






Леонид Семенов из InvestEngine выступит с докладом про Е2Е тесты в браузеры. Когда Cypress, а когда не очень.

Что делать если ошибки в проде смертельны, а релизы идут каждый день?
Как спастись от бессонных ночей, панической боязни сломать прод, и не страдать при этом от тестирования?

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






Роман Лысов из Semrush расскажет, ''Как создавать React компоненты, которыми будет приятно пользоваться''.

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







Людмила Мжачих из Mail.Ru Group в докладе ''Как тестировать фронтенд без тестировщиков и спать спокойно'' объяснит, почему процесс разработки не может обойтись без багов и как сводить их к минимуму. Это становится возможным только когда разработка и тестирование начинают жить вместе.

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









Полина Гуртовая из Evil Martians выступит с докладом ''RTC и Франкенштейн', в котором расскажет об особенностях использования WebRTC для боевых задач, опишет проблемы, которые поджидают разработчиков, и покажет способы их преодолевать.

Услышим и обсудим опыт наших спикеров 14 мая в форматах онлайн и офлайн. Полная программа конференции DUMP и билеты на сайте.

А пока спикеры готовятся к выступлениям, посмотри ТОП-3 выступлений секции фронтендеров с нашей прошлой конференции >>>

1. Виталий Дмитриев и его "Реактивное программирование. Как мыслить реактивно, а не проактивно"

2. Александра Шинкевич поделилась болью разработчика в докладе "Как внедрить стандарты разработки, чтобы никто не пострадал"

3. Вадим Макеев и 15 лет опыта: от создания и экспорта графики до оптимизации и вставки в его выступлении "Делайте из слона муху"

Подробнее..

Перевод 10 инструментов для повышения продуктивности React-девелоперов в 2020 году

22.07.2020 18:16:54 | Автор: admin

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

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

Итак, взглянем на итоговый список.

ESLint



ESLint может многое изменить для любого JavaScript-разработчика, включая поклонников React. Сервис предлагает умные алгоритмы, которые быстро анализируют код, выискивая возможные баги.

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

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

  • Встроенная поддержка библиотеки React (например, поддержка правил использования хуков).
  • Фокус на лучших практиках.

ESLint must-have для любого проекта, а конфигурация от Airbnb одна из моих любимых. Я кое-что добавил в нее, но 90% осталось от начальной конфигурации.

Bit



Bit предоставляет такую нужную для React-разработчиков вещь, как платформа совместной работы. Она позволяет командам работать вместе над отдельными компонентами.

Это утилита командной строки, которая позволяет повторно писать используемый код. У Bit полностью открытый исходный код, и это одна из причин его популярности.

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

Create React App



Будучи React-разработчиком, вы хорошо знаете, сколько времени уходит на то, чтобы начать новый проект. Для экономии времени разработчики Facebook предложили Create React App.

Это начальный конструктор, который дает возможность сосредоточиться на разработке, а не настройке React. Все, что нужно сделать, выполнить команду npx create-react-app my-app. После чего у вас есть полностью настроенное приложение для проекта.

Create React App значительно повысит вашу эффективность, если вы работаете в качестве React-фрилансера одновременно для нескольких заказчиков.

React Cosmos



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

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

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

React Toolbox



В начале статьи я упоминал, что использую Material UI для большинства проектов. Тому есть причина: мне нравится Material Design, и Material UI то, что меня полностью устраивает.

Но есть и альтернативы. Одна из них React Toolbox. Это набор часто используемых компонентов, разработанных с помощью Material Design. В нем применяются CSS-модули для большей гибкости.

На момент написания статьи React Toolbox включает 28 компонентов. Вот некоторые из них: Панель приложений, Выбор даты, Переключатель и Снэк-бар.

React Bootstrap



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

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

Решение пакет с открытым исходным кодом React Bootstrap. Все его Bootstrap-компоненты модифицированы специально для разработчиков React.

React Slingshot



Хотите ускорить разработку приложений React? Попробуйте оценить React Slingshot. Это шаблон, который объединяет React, Redux и Babel.

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

Reactide



Говорят, разработчик настолько хорош, насколько хорош его редактор. Может, это и не совсем так, но редактор очень помогает в нашей работе. Лично я большой поклонник JetBrains и WebStorm. Мой выбор IDE, но время от времени я пробую и альтернативы.

Например, я нашел Reactide это IDE для React. Я был очень удивлен этой находке и попробовал инструмент.

Оказалось, что у него есть интересные особенности. Например, вы можете визуализировать компоненты вашего проекта прямо в IDE. Также есть встроенный сервер Node.js, который интегрирован с симулятором браузера.

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

React Testing Library



Сначала тесты! то, что я твержу постоянно.

Другими словами, иметь набор инструментов для тестирования важно. React Testing Library это небольшая библиотека. Она позволяет проверить код React без особых проблем. Библиотека проста в использовании и добавляет возможности стандартным библиотекам вроде react-dom и react-dom/test-utils.

Отличная документация с несколькими хорошими примерами позволит быстро приступить к работе.

Storybook



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

Storybook достаточно гибкий, чтобы работать с любым основным фреймворком JavaScript. Например, React, Vue.js, Angular, Svelte, Marko и даже с необработанным HTML.

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

  • google-analytics (добавляет поддержку Google Analytics для компонентов);
  • jest;
  • storyshots(проверка компонентов с использованием снепшотов);
  • viewport (изменение разметки для адаптивных компонентов)


Надеюсь, вы оцените этот список. Если вы пользуетесь другими классными инструментами, которые не упомянуты в тексте, напишите о них в комментариях!
Подробнее..

Как решить нестандартные задачи в Backend и не проиграть. Расскажут спикеры конференции DUMP

29.04.2021 22:15:20 | Автор: admin

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

Ты только посмотри, какие спикеры нам в этом помогут!

Михаил Беляев из Прософт-Системы с докладом Проблемы embedded или как мы от sqlite ушли

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

Андрей Цветцих из EPAM представит доклад Чистая Архитектура на практике. Вот что он рассказал нам о своем выступлении:

С момента выхода книги Дяди Боба Clean Architecture прошло уже достаточно времени. Кто-то ее прочитал, а кто-то только смотрел доклады на youtube. Но все эти доклады идейные. У их авторов обычно нет практического опыта создания больших проектов по данной архитектуре (как и запуска этих проектов в production). А все примеры слишком простые! На практике все равно остается много вопросов. Больше года назад мы начали 2 новых проекта, в которых применяли принципы, описанные в книге. Это корпоративные приложения на C# (API, backend). Enterprise, который еще не успел стать кровавым :) Но этого вполне достаточно чтобы получить первые результаты и поделиться опытом.

Роман Неволин из Контура выступит с докладом про Функциональные языки для бизнес-разработки

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

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

Евгений Пешков из JetBrains с докладом Клиентский HTTP в .NET: дорога по граблям от WebRequest до SocketsHttpHandler

На первый взгляд кажется, что отправить HTTP запрос это очень просто. Тем не менее, даже HTTP/1.1 достаточно нетривиален RFC на него содержит более 150 страниц, кроме того браузеры уже поддерживают HTTP/2 и HTTP/3. Это не оставляет никакого выбора: стандартный клиент в платформе должен быть реализован на высоком уровне.

На пути от .NET Framework 1.0 к .NET 5 клиентские API для работы с HTTP и его реализации претерпели множество изменений. В некоторых версиях они были удачными, в некоторых же провальными и явно временными.

В докладе Евгений расскажет о истории развития клиентского HTTP API в .NET, его особенностях, о миграции приложений с Framework на Core с их учётом. Также разберет некоторые хаки, полезные при работе с ним. Заглянем в NuGet и рассмотрим представленные в нём обёртки над HTTP API с точки зрения эффективности и кроссплатформенности.

Александр Поляков из Яндекса расскажет Как Яндекс.Афиша 2 раза переезжала на GraphQL

Этот доклад о том, как мы переписали API Я.Афиша с REST на GraphQL на node.js + Python. А затем, в рамках оптимизации, избавились от node.js + Python и переписали весь GraphQL на Java.

Разберемся со следующими вопросами:

почему мы выбрали технологию GraphQL

какие проблемы и задачи решали с ее помощью

расскажем и покажем, как эволюционировала наша архитектура

для каких команд и проектов подходит наше решение, а для каких нет и почему

А также дадим несколько практических советов по тому, как лучше всего начинать работать с GraphQL

Фагим Садыков из SpectrumData представит нам свой доклад Kotlin как основной язык разработки бэкенда и обработки данных

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

В компании SpectrumData Kotlin используется как основной (и по факту единственный) продуктовый язык разработки на платформе JVM для самого широкого круга задач: работа с данными, реализация микро-сервисной архитектуры, реализация бэкенда. История успешного применения Kotlin в компании длится уже 4 года с версии языка 1.1. Для SpectrumData характерно полноценное применение в своей кодобазе всех возможностей и рекомендованных практик по данному языку.

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

Про Аспектно-ориентированное программирование на C# и .NET вчера, сегодня и завтра расскажет Денис Цветцих из Invent

Аспектно-ориентированное программирование (АОП) позволяет без дублирования кода добавлять инфраструктурный функционал вроде кеширования и логгирования на разные слои вашего приложения. И все это не меняя уже написанный код! Это очень мощная, удобная а также редко используемая техника. Отчасти это оправдано, 10 лет назад инструменты для реализации аспектов были не развиты, поэтому за АОП закрепилась слава подхода, используемого только энтузиастами. Но с тех пор мир изменился и сегодня АОП можно увидеть даже в веб-фреймворках, важно только уметь его распознать.

В своем докладе Денис поделится 10-летним опытом использования АОП на C# и .NET. Расскажет о подходах к реализации АОП, а также покажет, как менялись инструменты для разработки аспектов вместе с языком программирования и платформой. Естественно, он предложит наиболее оптимальный на сегодня вариант реализации аспектов. И вместе подумаем, какими хотелось бы видеть инструменты для разработки аспекты в будущем. Примеры будут на C# и .NET, но идеи доклада будут актуальны для любой платформы.

А под занавес программный комитет поставил Антона Шишкина из SKB LAB с докладом Рекомендации и фичи первой свежести . Здесь Антон расскажет про свой опыт построения рекомендательной системы от offline расчетов до online. И отдельно про то, как обеспечивается актуальность фичей для онлайн расчетов. Будут разобраны "допущения", благодаря которым фичи сохраняют свою "свежесть", при этом обеспечивается высокая доступность хранилища признаков.

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

А здесь можно выбрать билеты в онлайн и офлайн формате.

Подробнее..

Перевод Создание PDF-документа на Python с помощью pText

19.05.2021 18:19:31 | Автор: admin

Один из самых гибких и привычных способов сгенерировать pdf написать код на LaTeX и воспользоваться соответствующей программой. Но есть и другие способы, которые могут оказаться проще и понятнее, чем LaTeX. Специально к старту курса Fullstack-разработчик на Python представляем перевод статьи о том, как для генерации PDF можно воспользоваться библиотекой pText; эта статья написана Йорисом Схеллекенсом разработчиком pText.


В этом руководстве мы будем использовать pText библиотеку Python, предназначенную для чтения, обработки и создания PDF-документов. Он предлагает как низкоуровневую (позволяющую получить доступ к точным координатам и макету, если вы решите их использовать), так и высокоуровневую модель (где вы можете делегировать точные расчёты полей, позиций и т. д.). Мы рассмотрим, как создавать и проверять PDF-документ в Python, используя pText, а также как использовать некоторые LayoutElement [элементы макета] для добавления штрих-кодов и таблиц.

Portable Document Format (PDF) не является форматом WYSIWYG (что видишь, то и получаешь). Он был разработан как платформенно-независимый, не зависящий от базовой операционной системы и механизмов рендеринга.

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

  • Установить шрифт Helvetica.

  • Установить чёрный цвет обводки.

  • Перейти к (60,700).

  • Нарисовать глиф "H".

Это объясняет несколько вещей:

  • Почему так сложно точно извлечь текст из PDF.

  • Почему сложно редактировать PDF-документ.

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

Установка pText

pText можно загрузить c GitHub или установить через pip:

$ pip install ptext-joris-schellekens

Примечание. На момент написания статьи в версии 1.8.6 по умолчанию не устанавливаются внешние зависимости, такие как python-barcode и qrcode. Если появится сообщение об ошибке, установите их вручную:

$ pip install qrcode python-barcode requests

Создание PDF-документа на Python с помощью pText

pText имеет два интуитивно понятных ключевых класса Document и Page, которые представляют документ и страницы в нём. Это основная структура для создания PDF-документов. Кроме того, класс PDF представляет собой API для загрузки и сохранения создаваемых нами документов. Имея это в виду, давайте создадим пустой файл PDF:

from ptext.pdf.document import Documentfrom ptext.pdf.page.page import Pagefrom ptext.pdf.pdf import PDF# Create an empty Documentdocument = Document()# Create an empty pagepage = Page()# Add the Page to the Documentdocument.append_page(page)# Write the Document to a filewith open("output.pdf", "wb") as pdf_file_handle:    PDF.dumps(pdf_file_handle, document)

Большая часть кода здесь говорит сама за себя. Мы начинаем с создания пустого документа, затем добавляем пустую страницу в документ с помощью функции append() и, наконец, сохраняем файл с помощью PDF.dumps().

Стоит отметить, что мы использовали флаг "wb" для записи в двоичном режиме, поскольку мы не хотим, чтобы Python кодировал этот текст. Это даёт нам пустой PDF-файл с названием output.pdf в вашей файловой системе:

Создание документа Hello World с помощью pText

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

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

С этой целью Document является экземпляром самого низкого уровня в иерархии объектов, а Paragraph экземпляром самого высокого уровня, размещённым поверх PageLayout и, следовательно, страницы. Давайте добавим абзац на нашу страницу:

from ptext.pdf.document import Documentfrom ptext.pdf.page.page import Pagefrom ptext.pdf.pdf import PDFfrom ptext.pdf.canvas.layout.paragraph import Paragraphfrom ptext.pdf.canvas.layout.page_layout import SingleColumnLayoutfrom ptext.io.read.types import Decimaldocument = Document()page = Page()# Setting a layout manager on the Pagelayout = SingleColumnLayout(page)# Adding a Paragraph to the Pagelayout.add(Paragraph("Hello World", font_size=Decimal(20), font="Helvetica"))document.append_page(page)with open("output.pdf", "wb") as pdf_file_handle:    PDF.dumps(pdf_file_handle, document)

Вы заметите, что мы добавили 2 дополнительных объекта:

  • Экземпляр PageLayout, более конкретный через его подкласс SingleColumnLayout: этот класс отслеживает, где контент добавляется на страницу, какие области доступны для будущего контента, каковы поля страницы и какие ведущие (пространство между объектами Paragraph) должно быть.

Поскольку здесь мы работаем только с одним столбцом, мы используем SingleColumnLayout. В качестве альтернативы мы можем использовать MultiColumnLayout.

  • Экземпляр Paragraph: этот класс представляет блок текста. Вы можете установить такие свойства, как шрифт, font_size, font_color, и многие другие. Дополнительные примеры вы можете найти в документации.

Код генерирует файл output.pdf, содержащий наш абзац:

Проверка созданного PDF с помощью pText.

Примечание: этот раздел является необязательным, если вас не интересует внутренняя работа PDF-документа.

Но может быть очень полезно немного узнать о формате (например, при отладке классической проблемы почему мой контент теперь отображается на этой странице). Обычно программа для чтения PDF читает документ, начиная с последних байтов:

xref0 110000000000 00000 f0000000015 00000 n0000002169 00000 n0000000048 00000 n0000000105 00000 n0000000258 00000 n0000000413 00000 n0000000445 00000 n0000000475 00000 n0000000653 00000 n0000001938 00000 ntrailer<</Root 1 0 R /Info 2 0 R /Size 11 /ID [<61e6d144af4b84e0e0aa52deab87cfe9><61e6d144af4b84e0e0aa52deab87cfe9>]>>startxref2274%%EOF

Здесь мы видим маркер конца файла (%% EOF) и таблицу перекрестных ссылок (обычно сокращённо xref).

Внешняя ссылка ограничена токенами startxref и xref.

Внешняя ссылка (в документе может быть несколько) действует как справочная таблица для программы чтения PDF-файлов.

Он содержит байтовое смещение (начиная с верхней части файла) каждого объекта в PDF. Первая строка внешней ссылки (0 11) говорит, что в этой внешней ссылке 11 объектов и что первый объект начинается с номера 0.

Каждая последующая строка состоит из байтового смещения, за которым следует так называемый номер поколения и буква f или n:

  • Объекты, отмеченные буквой f, являются свободными, их рендеринг не ожидается.

  • Объекты, отмеченные буквой n, используются.

Внизу xref мы находим словарь трейлеров. Словари в синтаксисе PDF разделяются символами << и >>. В этом словаре есть следующие пары:

  • /Root 1 0 R

  • /Info 2 0 R

  • /Size 11

  • /ID [<61e6d144af4b84e0e0aa52deab87cfe9> <61e6d144af4b84e0e0aa52deab87cfe9>]

Словарь трейлеров является отправной точкой для программы чтения PDF-файлов и содержит ссылки на все другие данные. В этом случае:

  • /Root: это ещё один словарь, который ссылается на фактическое содержание документа.

  • /Info: это словарь, содержащий метаинформацию документа (автор, название и так далее).

Строки типа 1 0 R в синтаксисе PDF называются ссылками. И здесь нам пригодится таблица xref. Чтобы найти объект, связанный с 1 0 R, мы смотрим на объект 1 (номер поколения 0). Таблица поиска xref сообщает нам, что мы можем ожидать найти этот объект в 15-м байте документа. Если проверить это, то обнаружим:

1 0 obj<</Pages 3 0 R>>endobj

Обратите внимание, что тот объект начинается с 1 0 obj и заканчивается endobj. Это ещё одно подтверждение того, что мы на самом деле имеем дело с объектом 1. Этот словарь говорит нам, что мы можем найти страницы документа в объекте 3:

3 0 obj<</Count 1 /Kids [4 0 R] /Type /Pages>>endobj

Это словарь /Pages, и он сообщает нам, что в этом документе одна страница (запись /Count). Запись для /Kids обычно представляет собой массив с одной ссылкой-объектом на страницу. Мы можем ожидать найти первую страницу в объекте 4:

4 0 obj<</Type /Page /MediaBox [0 0 595 842] /Contents 5 0 R /Resources 6 0 R /Parent 3 0 R>>endobj

Этот словарь содержит несколько интересных записей:

  • /MediaBox: физические размеры страницы (в данном случае страница формата A4).

  • /Contents: ссылка на (обычно сжатый) поток операторов содержимого PDF.

  • /Resources: ссылка на словарь, содержащий все ресурсы (шрифты, изображения и так далее), используемые для рендеринга этой страницы.

Давайте проверим объект 5, чтобы узнать, что на самом деле отображается на этой странице:

5 0 obj<</Filter /FlateDecode /Length 85>>streamxR@\<`aw3T0!K3Benl7'999E9)!Y(!8yT*endstreamendobj

Как упоминалось ранее, этот поток содержимого сжимается. Вы можете определить, какой метод сжатия использовался, с помощью записи /Filter. Если мы применим распаковку (unzip) к объекту 5, то мы должны получить фактические операторы содержимого:

5 0 obj<</Filter /FlateDecode /Length 85>>stream            q            BT            0.000000 0.000000 0.000000 rg            /F1 1.000000 Tf                        20.000000 0 0 20.000000 60.000000 738.000000 Tm                        (Hello world) Tj            ET                        Qendstreamendobj

Наконец, мы находимся на уровне, где можем декодировать контент. Каждая строка состоит из аргументов, за которыми следует их оператор. Быстро пройдёмся по операторам:

  • q: сохранить текущее графическое состояние (помещая его в стек);

  • BT: начать текст;

  • 0 0 0 rg: установить текущий цвет обводки на (0,0,0) rgb. Это чёрный;

  • /F1 1 Tf: установить текущий шрифт на /F1 (это запись в словаре ресурсов, упомянутом ранее) и размер шрифта на 1.

  • 20.000000 0 0 20.000000 60.000000 738.000000 Tm: установить текстовую матрицу, что требует отдельного руководства. Достаточно сказать, что эта матрица регулирует размер шрифта и положение текста. Здесь мы масштабируем шрифт до размера 20 и устанавливаем курсор для рисования текста на 60 738. Система координат PDF начинается в нижнем левом углу страницы. Итак, 60 738 находится где-то рядом с левым верхом страницы (с учётом того, что высота страницы составляет 842 единицы).

  • (Hello world) Tj: строки в синтаксисе PDF разделяются ( и ). Эта команда указывает программе чтения PDF-файлов отобразить строку Hello world в позиции, которую мы указали ранее с помощью текстовой матрицы, в шрифте, размере и цвете, которые мы указали в командах перед этим.

  • ET: конец текста.

  • Q: извлечь состояние графики из стека (таким образом восстанавливая состояние графики).

Добавление других элементов макета pText на страницы

pText поставляется с широким спектром объектов LayoutElement. В предыдущем примере мы кратко исследовали Paragraph. Но есть и другие элементы, такие как UnorderedList, OrderedList, Image, Shape, Barcode и Table. Давайте создадим чуть более сложный пример с таблицей и штрих-кодом. Таблицы состоят из TableCells, которые мы добавляем в экземпляр Table. Штрих-код может быть одним из многих типов штрих-кода мы будем использовать QR-код:

from ptext.pdf.document import Documentfrom ptext.pdf.page.page import Pagefrom ptext.pdf.pdf import PDFfrom ptext.pdf.canvas.layout.paragraph import Paragraphfrom ptext.pdf.canvas.layout.page_layout import SingleColumnLayoutfrom ptext.io.read.types import Decimalfrom ptext.pdf.canvas.layout.table import Table, TableCellfrom ptext.pdf.canvas.layout.barcode import Barcode, BarcodeTypefrom ptext.pdf.canvas.color.color import X11Colordocument = Document()page = Page()# Layoutlayout = SingleColumnLayout(page)# Create and add headinglayout.add(Paragraph("DefaultCorp Invoice", font="Helvetica", font_size=Decimal(20)))# Create and add barcodelayout.add(Barcode(data="0123456789", type=BarcodeType.QR, width=Decimal(64), height=Decimal(64)))# Create and add tabletable = Table(number_of_rows=5, number_of_columns=4)# Header rowtable.add(TableCell(Paragraph("Item", font_color=X11Color("White")), background_color=X11Color("SlateGray")))table.add(TableCell(Paragraph("Unit Price", font_color=X11Color("White")), background_color=X11Color("SlateGray")))table.add(TableCell(Paragraph("Amount", font_color=X11Color("White")), background_color=X11Color("SlateGray")))table.add(TableCell(Paragraph("Price", font_color=X11Color("White")), background_color=X11Color("SlateGray")))# Data rowsfor n in [("Lorem", 4.99, 1), ("Ipsum", 9.99, 2), ("Dolor", 1.99, 3), ("Sit", 1.99, 1)]:    table.add(Paragraph(n[0]))    table.add(Paragraph(str(n[1])))    table.add(Paragraph(str(n[2])))    table.add(Paragraph(str(n[1] * n[2])))# Set paddingtable.set_padding_on_all_cells(Decimal(5), Decimal(5), Decimal(5), Decimal(5))layout.add(table)# Append pagedocument.append_page(page)# Persist PDF to filewith open("output4.pdf", "wb") as pdf_file_handle:    PDF.dumps(pdf_file_handle, document)

Некоторые детали реализации:

  • pText поддерживает различные цветовые модели, в том числе RGBColor, HexColor, X11Color и HSVColor.

  • Вы можете добавлять объекты LayoutElement непосредственно в объект Table, но вы также можете обернуть их объектом TableCell, это даёт вам некоторые дополнительные параметры, такие как col_span и row_span или, в данном случае, background_color.

  • Если font, font_size или font_color не указаны, Paragraph примет значение по умолчанию Helvetica, размер 12, чёрный.

Код сгенерирует такой документ:

Заключение

В этом руководстве мы рассмотрели pText библиотеку для чтения, записи и управления файлами PDF. Мы рассмотрели ключевые классы, такие как Document и Page, а также некоторые элементы, такие как Paragraph, Barcode и PageLayout. Наконец, мы создали несколько PDF-файлов с различным содержимым, а также проверили, как PDF-файлы хранят данные под капотом.

Документ PDF приятен глазу и достаточно удобен для того, чтобы использовать его в электронном документообороте, для генерации разнообразных счетов и отчётов, особенно актуальных в крупных организациях и в их внутренней сети, поэтому разработка крупных и сложных веб-проектов часто сопряжена с генерацией PDF. Если вам интересна работа со сложными веб-проектами и не хочется выбирать между бэком или фронтом, то вы можете присмотреться к курсу Fullstack-разработчик на Python.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Карта дизайна организационных систем и бизнес-процессов

12.02.2021 18:18:50 | Автор: admin

Приветствую, уважаемые хабровчане. Это мой первый пост на этой площадке, хотя в качестве читателя с вами уже, наверное, 10 лет. Я не являюсь специалистом в IT, хотя имел отношение к запуску небольшого количества стартапов. Можете называть меня практикующим теоретиком запускаю продукты, занимаюсь управлением проектами, помогаю компаниям улучшать процессы, внедрять всякие гибкие управленческие штуки, немного преподаю в ВШЭ. Но всё это делаю не столько, чтобы заработать денег, а чтобы удовлетворить собственное любопытство в том, как устроены системы и держать голову в тонусе.

Этот пост был написан пару лет назад на vc.ru, в правилах сообщества не запрещено публиковать контент с других площадок. С вашего позволения, здесь опубликую его снова, но с небольшими корректировками. Надеюсь, найдёте материал и инструмент, о котором пойдёт речь, полезными.


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

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

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

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

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

Аннотация

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

  • начать что-то добывать;

  • начать что-то производить;

  • начать что-то перепродавать;

  • вклиниться в процесс, выступив посредником;

  • захватить один из транзакционных каналов рыночного процесса.

Несколько тезисов

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

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

  3. На основе ресурсной базы участников процесса формируется культура поведения.

  4. Нечто, с помощью чего предприниматель вклинивается в существующие рыночные потоки, называется продуктом.

  5. Прибыль извлекается с помощью бизнес-модели.

  6. Возникающие денежные потоки дают предпринимателю (предприятию) возможность для развития.

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

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

Общая схема устройства рыночных процессов и уровней организацийОбщая схема устройства рыночных процессов и уровней организаций

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

Описание мега-процессов, процессов и задач одного из уровнейОписание мега-процессов, процессов и задач одного из уровней

Качество операций влияет на процессы, являясь узкими местами. Качество процессов влияет на качество уровней. А качество уровней в совокупности влияет на совокупные результаты и характеризует состояние компании на рынке.

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

Эта карта существенно сократит ваш цикл обучения на личном опыте. Она наглядно показывает все ключевые бизнес-процессы вне зависимости от рода коммерческой деятельности.

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

Ссылка на карту в Miro: https://miro.com/app/board/o9J_kxviOm0=/

P.s. Этот материал изначально писался два года назад. На текущий момент фреймворк используют приличное количество менеджеров в приличном количестве довольно известных компаний в разных странах СНГ. Если он пригодится в вашей работе буду счастлив.

Подробнее..

Инженерия для муравьев как не утонуть в сиропе

16.10.2020 10:22:46 | Автор: admin


Насекомые удивительные создания. Многие из них обладают крайне необычными свойствами и умениями. Кто-то испускает свет, кто-то может пережить ядерный удар, а кто-то бегает так быстро, что вынужден останавливаться, чтобы понять свое местоположение. Уникальностей много, как и семейств насекомых. Муравьи же уникальны своей численностью, организованностью и беспрекословной верой в монархию (Боже, храни Королеву). Разные виды муравьев проявляют те или иные навыки в зависимости от среды обитания и гастрономических предпочтений. К примеру, красные огненные муравьи (Solenopsis invicta) используют собственные тела для постройки живого плота, чтобы пережить наводнения. Однако этот метод спасения от смерти через утопление не является единственным, так как муравьи вполне способны использовать инструменты, чтобы избежать гибели. Ученые из Британского экологического общества (Лондон, Великобритания) выяснили, что черные огненные муравьи используют песок при сборе жидкой пищи, чтобы не утонуть. Как именно муравьи используют песок, меняется ли их поведение в зависимости от ситуации, и насколько эффективен такой навык выживания? Ответы на эти вопросы мы найдем в докладе ученых. Поехали.

Основа исследования


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


Документальный фильм о муравьях (BBC, Дэвид Аттенборо).

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

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

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


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

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

К 2010 году было зафиксировано порядка 50 случаев использования орудий труда у 30 различных родов насекомых. Среди них были и муравьи, а именно подсемейство Myrmicinae (виды: Pogonomyrmex badius, Solenopsis invicta Buren, Novomessor albisetosus и несколько видов из рода Aphaenogaster).

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

И тут возникает вопрос могут ли муравьи менять инструменты и свое поведение в зависимости от ситуации?

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

Муравьи, собирающие пищу за пределами гнезда, должны эффективно выполнять свою задачу, параллельно выживая в условиях окружающей среды, где опасность заключается не только в хищниках, но и в самой местности. Даже сама пища может быть опасной. К примеру, экстрафлорный нектар (EFN от extrafloral nectar), выделяемый растениями, и медвяная падь (секрет насекомых, питающихся соком растений) являются важнейшим источником углеводов для развития колоний многих видов муравьев. Но из-за своего небольшого размера муравьи могут запутаться и утонуть в жидкости во время добычи пищи.


Главные герои исследования рабочие муравьи вида Solenopsis richteri Forel.

Возникает весьма любопытный вопрос осознают ли муравьи риски, связанные с добычей жидкой пищи, в том числе риск утонуть? Как оказалось, осознают. Ученые установили, что муравьи вида Solenopsis richteri Forel (черные огненные муравьи) могут распознавать увеличение риска утопления и соответственно корректировать свою стратегию использования инструментов.

Подготовка к опытам


Колония муравьев, участвующих в опытах, была собрана в округе Туника (штат Миссисипи, США). В специальных тестовых камерах (55х44х12 см) поддерживались необходимые для нормальной жизнедеятельности условия: температура 26 2 C, влажность 45% и неограниченный доступ к пище и воде (замороженные сверчки, 15% водный раствор сахара и дистиллированная вода).

Одним из аспектов, которые хотели проверить ученые, было поверхностное натяжение жидкости. Чтобы определить связь между риском утопления S. richteri и поверхностным натяжением жидкой пищи, была проведена оценка доли утонувших муравьев и степень сложности их спасения при различных концентрациях поверхностно-активного вещества (ПАВ).

Водный раствор сахара (15% по массе) использовался в качестве источника пищи на протяжении всего исследования. Подопытные муравьи могли спокойно плавать на поверхности раствора чистой воды с сахаром, возможно, из-за гидрофобных углеводородов на их кутикуле и высокого поверхностного натяжения раствора. Следовательно, чистый водный раствор сахара должен был представлять минимальный риск утопления для муравьев. Однако добавление ПАВ (TWEEN 80: 0%, 0.05%, 0.1%, 0.5%, 1% и 2%) снижает степень поверхностного натяжения, тем самым увеличивая риск утопления.

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

Во время опыта 1 мл водного раствора сахара с различными концентрациями ПАВ переносили в небольшой пластиковый контейнер (2.5 см в диаметре). Один рабочий муравей помещался в центр контейнера. Если муравей опускался на дно контейнера и не мог сбежать в течение 40 минут, его считали утонувшим. Для тех муравьев, которым удалось уцелеть, фиксировалось время, необходимое для спасения. В ходе данного опыта было использовано по 10 рабочих муравьев из каждой колонии (10 колоний всего).

На поведение муравьев может влиять и само ПАВ, используемое в опытах, а точнее его запах. Для оценки этого был использован ольфактометр с Y-образной трубкой. Две трубки вели к двум разным камерам. В одной присутствовал чистый воздух и жидкость с разной концентрацией ПАВ, в другой воздух с запахом TWEEN 80. В начало Y-трубки было помещено 80 особей, после его в течение 20 минут измерялось число особей, вошедших в ту или иную камеру на 3 см и глубже.

Далее были проведены тесты, связанные с риском утопления и формированием стратегии использования инструментов у подопытных муравьев. В тестовой камере был выбор инструментов: крупицы песка разного размера (крупные > 1.19 мм; средние 0.7071.19 мм и мелкие < 0.707 мм). Во время каждого теста была задействована колония муравьев из одной матки, 3 г муравьев и 0.2 г личинок. Каждую колонию переносили в пластиковый лоток (55х44х12 см) с искусственным гнездом.

В ходе данного опыта было 24 комбинации размера песка (крупный, средний, мелкий и смешанный) и концентрации поверхностно-активного вещества (0%, 0.05%, 0.1%, 0.5%, 1.0%, 2.0%), каждая из которых тестировалась отдельно по 12 заходов.

Через два часа после того, как песчинки были помещены в лоток, три пищевых контейнера (диаметром 2/5 см, каждый из которых содержал 1 мл раствора сахарной воды или сахарной воды с определенной концентрацией ПАВ) были помещены между песчинками и колонией муравьев.

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

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

Для оценки эффективности столь необычной постройки муравьям были предоставлены песчинки разного размера (всего 12 г). Муравьи строили свою конструкцию для откачки жидкой пищи, после чего их убирали из тестовой камеры. Конструкцию сушили, а затем контролированно добавляли в нее 1 мл сахарной воды с 1% ПАВ. В ходе данного испытания измерялось время, необходимое для откачивания сахарной воды. Спустя 10 минут насыпь песка вне контейнера с пищей взвешивали и сушили. Разница веса до и после сушки показывала количество водного раствора сахара, содержащегося в структуре песка.

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

Результаты опытов


Сначала было оценено влияние поверхностного натяжения на степень риска утопления. При увеличении концентрации ПАВ поверхностное натяжение водного раствора сахара значительно снизилось с 77.17 0.24 до 43.28 0.24 мН/м (1A) и, соответственно, доля утонувших муравьев значительно увеличилась ().


Изображение 1

Что касается утонувших муравьев, то время их побега из сахарной воды увеличивалось с увеличением концентрации поверхностно-активного вещества (1C). Следовательно, наблюдалась очевидная отрицательная корреляция между временем, необходимым чтобы выбраться из сиропа, и поверхностным натяжением воды (1D).

Анализ поведенческих изменений на добавление ПАВ TWEEN 80 показал, что S. richteri не проявляют каких-либо явных предпочтений относительно TWEEN 80 (2A опыты без запаха ПАВ; опыты с запахом ПАВ). Следовательно, добавление или удаление этого вещества не влияет на их поведение (с точки зрения реакции на запах вещества).


Изображение 2

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

Концентрация поверхностно-активного вещества, размер песчинок и их взаимодействие показали очевидное влияние на количество использованных песчинок (Таблица 1).


Таблица 1

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

Что касается эффекта концентрации поверхностно-активного вещества, то добавление 0.05% ПАВ к сахарной воде привело к использованию большего количества песчинок в пищевых контейнерах по сравнению с контрольной группой и другими вариантами концентрации ПАВ (3D).


Изображение 3

Анализ данных со всех пищевых контейнеров с разными размерами песчинок показал, что число песчинок, использованных за пределами контейнера, практически не меняется в зависимости от концентрации ПАВ выше 0.05% (3E).

Любопытно, что при использовании песчинок разного размера и ПАВ 0.05% муравьи использовали больше песка именно внутри пищевого контейнера. Но комбинация песчинок любого размера с ПАВ больше 0.05% приводит к тому, что муравьи раскладывают песок вне контейнера.

Размер песчинок и концентрация ПАВ оказали значительное влияние на смертность муравьев (таблица 2).


Таблица 2

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

При этом доля утонувших увеличивалась по мере увеличения концентрации ПАВ (3F). Самая численная смертность наблюдалась в случаях, когда концентрация ПАВ была выше 0.1% вне зависимости от размера песчинок.

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


Изображение 4

Когда концентрация ПАВ была выше 0.05%, муравьи начинали строить уникальные песчаные сооружения, чтобы соединить песчинки, размещенные внутри и снаружи контейнера (4A-4E).

Любопытно, что при концентрации ПАВ ровно 0.05%, муравьи размещали большую часть песчинок на внутренней стенке контейнера. Подобные конструкции наблюдались только при использовании поверхностно-активного вещества в сахарной воде.

Факт того, что муравьи строят разные песчаные конструкции при разных концентрациях ПАВ, подтверждает гибкость муравьев вида S. richteri в выборе стратегии использования инструментов.

А теперь стоит детальнее рассмотреть эти уникальные песчаные сооружения. Для изучения песчаных сифонов были сделаны записи строительства 13 таких структур.

На начальном этапе строительства муравьи просто питались сахарной водой внутри, когда ее только добавили в контейнер. Спустя 4-10 минут несколько особей утонули в сахарной воде, а другие начинали собирать и складывать песчинки внутри и снаружи контейнера.

Через 1.5 часа за пределами контейнера с пищей было больше песчинок, чем внутри (4A, 4B, 4E, видео ниже).




Муравьи приклеивали песчинки к стенке контейнера (снаружи и внутри), чтобы создать песчаную дорожку, соединяющую жидкость внутри и кучу песка снаружи.

Благодаря такой конструкции жидкая пища перемещалась из контейнера по песчаной дорожке, обеспечивая более безопасный сбор пищи (4A-4D).

Чаще всего к одному контейнеру подходила одна песчаная дорожка, а внешние песчаные насыпи располагались достаточно близко. Но в редких случаях дорожка была 11 см в длину (4E). Также была распространена практика строительства нескольких песчаных дорожек к одной насыпи. В строительстве данной конструкции муравьи использовали песчинки всех имеющихся размеров.

В среднем почти половина сахарной воды (49.67%) была перенесена в насыпь песка в течение пять минут (4F, видео ниже).




При наличии песчаных сифонов на 30 минуте наблюдений 89.87% из всех муравьев находились за пределами контейнера, а на 60 минуте 87.85% (4E, 4G, 4H).

Вполне ожидаемо, что наличие песчаных конструкций сильно повлияло на уровень смертности муравьев (таблица 3).


Таблица 3

При наличии песчаного сифона муравьев, питающихся внутри контейнера, было значительно меньше (5A и 5B). Данный показатель практически не менялся по отношению к концентрации ПАВ (5E и 5F).

Наличие сифона повысило эффективность сбора пищи на 8% (5C): без сифона 10.69 мг и с сифоном 11.54 мг. Этот показатель немного снижался при увеличении концентрации ПАВ (5G).

При наличии сифонной структуры наблюдалась меньшая доля утонувших муравьев, которая увеличивалась пропорционально увеличению концентрации поверхностно-активного вещества (5H).

Для более детального ознакомления с нюансами исследования рекомендую заглянуть в доклад ученых и дополнительные материалы (ссылка для скачивания файла .docx) к нему.

Эпилог


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

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

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

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

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

Пятничный офф-топ:

Юмористическое, но правдивое видео о мутуализме среди муравьев.

Офф-топ 2.0:

Как бы сказал Эрмак из Mortal Kombat: We are many, you are but one

Благодарю за внимание, оставайтесь любопытствующими и отличных всем выходных, ребята! :)

Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Боли менеджера. Обсудим опыт, факапы и успехи в секции Product на DUMP-2021

08.04.2021 14:12:31 | Автор: admin

Начинаем рассказывать детали про секции DUMP. Встречайте впервые на конференции будет отдельная секция Product.

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

Поэтому у нас появилась отдельная большая секция - 8 спикеров, 320 минут концентрированной пользы (с перерывами, конечно :) и общением.

О чем мы будем говорить?

  • О продуктовых компетенциях: какие хардскиллы и софтскиллы нужны продактам (и продуктовым командам!) в зависимости от целей

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

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

  • Поговорим и про тренды. Про поколения Z и А - вы задумывались о них? А продукты для них создаете? А планируете? Это не просто абстрактные вопросы, это интересная тенденция развития рынков, о которой стоит подумать уже сейчас, чтобы через несколько лет быть на коне. Инсайты гарантированы!

Для кого эта секция?

Для всех, кто развивает продукт!

Это продуктовые/бизнес аналитики, продакты и те кто хочет им стать, менеджеры по развитию продуктов, product owner'ы, владельцы собственного бизнеса или носители стартаперских идей. Полезно и интересно будет всем!

Нам самим уже не терпится послушать выступления и задать вопросы.

Билеты на офлайн и онлайн уже на сайте!

Присоединяйся к DUMP-2021!

Подробнее..

Разбор секции DESIGN на DUMP куда расти и развиваться?

12.04.2021 20:16:10 | Автор: admin

Дизайн - одна из самых заметных и посещаемых секций на конференции DUMP. Здесь стоит вспомнить доклад Алексея Кулакова про обратную связь. На прошлой конференции он затронул очень важные и близкие каждому дизайнеру вопросы:

В этом году нам с вами тоже есть, что обсудить. Поговорим и зоне развития дизайнера.

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

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

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

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

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

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

Присоединяйся к DUMP-2021!Билеты на офлайн и онлайн уже на сайте

Подробнее..

Перевод Turbolift инструмент для масштабного рефакторинга

08.05.2021 16:18:41 | Автор: admin

Системы Skyscanner сложно назвать маломасштабными. Наш сайт и приложение каждый месяц используются миллионами путешественников, мы обрабатываем умопомрачительные объёмы запросов, используя микросервисную архитектуру, которая сама по себе далеко не маленькая.В общей совокупности у нас задействовано несколько сотен микросервисов и микросайтов (веб-приложений, поддерживающих определённую часть нашего сайта), обслуживаемых сотнями экземпляров AWS Lambda и библиотек. Каждое из этих средств хранится в своём собственном репозитории GitHub, что даёт некоторые преимущества с точки зрения разделения задач, но имеет и свою цену: когда одно и то же изменение нужно выполнить во всех этих репозиториях, как это можно осуществить?


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

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

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

Долгое время мы разрабатывали свою внутреннюю систему под названием Codelift. В первую очередь это была система пакетной обработки, которая в ночное время применяла написанный на Python сценарий изменения для каждого из сотен репозиториев, отправляя предложения на изменения кода в чужих репозиториях (PR-предложения) для всех таких изменений. Но, как оказалось, очень сложно написать такой сценарий, который бы надёжно отрабатывал со всеми репозиториями. Главным узким местом была потребность в квалифицированных специалистах, которые требовались для проверки этих сценариев изменений. И самим сценариям часто требовалось несколько раундов настройки, чтобы преодолеть неизбежные сбои. Система Codelift постепенно выводилась из эксплуатации, но потребность в ней оставалась.

Появление Turbolift

Система Turbolift это переосмысление процесса внесения массовых изменений.

  • Прежде, чтобы написать надёжно работающий сценарий внесения изменения в системе Codelift, инженерам приходилось создавать локальные копии (клоны) многих или даже всех задействованных репозиториев только для проверки работоспособности этого изменения. Но если инженеры в любом случае собираются создавать локальные копии репозиториев, почему не сделать это частью процесса?

  • Подготовка сценариев изменений на Python накладывала свои ограничения: иногда самым простым способом реализации изменения является просто вызов команды из оболочки или запуск более специализированного инструмента рефакторинга, такого как codemod или comby. Иногда предпочтителен вызов редактора или интегрированной среды разработки это будет хоть и тяжеловесным, но самым верным способом. А иногда самым простым вариантом выполнения будет автоматическое изменение, которое сработает для 95 % репозиториев с последующей ручной настройкой для нескольких репозиториев, где такая настройка потребуется.

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

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

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

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

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

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

Как инструмент Turbolift помог нам

  • При приближении момента, когда истечёт срок действия какого-либо внутреннего SSL-сертификата, наша команда сопровождения промышленной платформы использовала Turbolift для выполнения PR-предложений сотен репозиториев, в которых были ссылки на истекающий сертификат.

  • Turbolift применяется нашей командой веб-поддержки для стандартизации версий и тестирования библиотек на наших микросайтах.

  • Наша команда сопровождения промышленной платформы использовала Turbolift для исправления ошибки, которую когда-то допустили в шаблоне кода, а затем растиражировали по множествам репозиториев.

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

В целом за последние три месяца, используя Turbolift, мы отправили свыше 1200 внутренних предложений на изменения кода в чужих репозиториях. Каждый из этих случаев означает устранённую проблему или исправленную техническую недоработку, которые в противном случае превратились бы в создаваемые вручную PR-предложения. Мы надеемся, что инженеры в Skyscanner и других компаниях в полной мере ощутят преимущества от упрощения рабочего процесса при выполнении масштабных изменений.

Turbolift написан на Go компилируемом языке от Google, который вы за год освоите с нуля на курсе Backend-разработчик на Go от ключевых понятий в IT, основ Linux и до применения Go для DevOps. Мы используем модель фундаментального образования, поэтому вы получите не только практические навыки, но и крепкую теоретическую базу, научитесь мыслить по-новому и в этом вам помогут эксперты в своём деле и менторы, которые с удовольствием ответят на ваши вопросы и передадут вам свои знания.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

7 Кругов SPM или как сделать модульное приложение на Swift Package Manager

28.03.2021 20:06:28 | Автор: admin
Спасибо Jackie Zhao @jiaweizhao за фото на Unsplash Спасибо Jackie Zhao @jiaweizhao за фото на Unsplash

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

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

  • С помощью SPM мы избавляемся от .xcodeproj файлов (забываем про конфликты в них);

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

  • Нет альтернатив для проектов под разные операционные системы Linux/Windows;

  • Пакеты не требуют xcode для разработки.

Как выглядит сам процесс?

Для начала создаём Package.swift файл, в котором будут храниться все необходимые зависимости и информация о том, что из себя этот модуль представляет.

Пример файла с параметрами, с которыми вы скорей всего столкнётесь при работе:

import PackageDescription let package = Package(    // 1. Название нашего пакета    name: "Resources",    // 2. Платформы, которые поддерживаются нашим пакетом    platforms: [        .iOS(.v11),    ],    // 3. То, что другие программы будут брать в себя    // Продуктов может быть огромное колличество, хороший пример для этого Firebase SPM пакет    products: [        .library(            name: "Resources",            // Динамический или статический продукт          // по дефолту значение nil - SPM сам будет понимать что лучше подходит            //  преференция скорей всего будет отдаваться .static            type: .dynamic,            targets: ["Resources"]),    ],    // 4. Зависимости необходимые для работы нашего пакета,  // здесь они просто загружаются, добавляются они в targets    dependencies: [        // name - это название пакета(пункт 1), здесь нельзя указать кастомное название, необязательный параметр        .package(name: "R.swift.Library", url: "https://github.com/mac-cain13/R.swift.Library", .branch("master")),        // Пример подключения локального пакета        .package(path: "../Core")    ],    targets: [        // Это то из чего мы будем складывать наш продукт        // Для таргета обязательно нужно создать папку       // в Sources/имя_таргета для его работы      // либо если мы не хотим размещать его в Sources, можем указать "path:"        .target(            name: "Resources",            dependencies: [                // Здесь мы указываем зависимости которые мы хотим использовать в таргете                // name(пункт 3), package(пункт 1)                .product(name: "RswiftDynamic", package: "R.swift.Library")            ],            resources: [                // Все ресурсы которые мы хотим использовать нужно явно указать                // Путь к ним относительный от Sources/имя_пакета/то_что_мы_указали                // Если указываем папку, поиск идет рекурсивно                .process("Resources")            ])    ])

После создания модуля, подключаем его к проекту (либо к другому модулю, если модуль который вы делали лишь вспомогательный для других). Для удобства можно добавить пакет в workspace, просто drag and drop корневую папку с пакетом в Project navigator.

Введение на этом можно закончить и перейти к основной части статьи, где мы рассмотрим проблемы, с которыми вы можете столкнуться. На момент написания статьи мною использовались swift-tools-version:5.3, Xcode Version 12.2

Круг 1. Небольшое комьюнити.

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

Круг 2. Отсутствует фаза скриптов SPM пакета.

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

Круг 3. R.swift и SPM.

Так как у нас нет .xcodeproject файла, вызвать R.swift скрипт для генерации не получится, для этого нам нужно этот файл создать.

Для создания можно использовать XcodeGen и его аналоги. Либо swift package generate-xcodeproj, стандартного скрипта для генерации .xcodeproj файла в SPM.

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

error: [R.swift] Project file at 'file:///Users/.../Resources.xcodeproj/' could not be parsed, is this a valid Xcode project file ending in *.xcodeproj?

Чтобы локализовать проблему и найти почему файл проекта не может распарситься нужен XcodeEdit фреймворк который R.swift использует для парсинга. Билдим его и получаем exec файл, которому нужно передать .xcodeproj. Вызываем его:

pathtoexec/XcodeEdit-Example Resources.xcodeproj

и видим

Fatal error: 'try!' expression unexpectedly raised an error: XcodeEdit_Example.AllObjectsError.fieldMissing(key: "buildRules"): file XcodeEdit_Example/main.swift, line 21

Вот как можно это решить:

sed -i '' -e 's/isa = "PBXNativeTarget";/isa = "PBXNativeTarget";buildRules = ();/' Resources.xcodeproj/project.pbxproj

К сожалению, на этом проблемы не заканчиваются. generate-xcodeproj не добавляет файлы ресурсов в проект. То есть R.swift будет парсить .xcodeproj/.pbproject, но нужных файлов ресурсов там нет.

Это можно решить подключением ruby gem xcodeproj, с помощью которого можно добавить необходимые файлы. Но всё же такой подход более трудозатратный, и лучше вернуться к варианту с .xcodeproj генераторам по типу XcodeGen.

Пример минимального конфиг файла для XcodeGen:

# Название генерируемого xcodeprojname: Resourcestargets: Resources:   # Не важно что вы тут укажите, но это обязательные параметры   type: framework   platform: iOS   # Root folder с которого начинать генерировать   sources:     - Sources

Команда которая создаст .xcodeproj файл:

xcodegen generate --spec Resources.yml

Проблема с .xcodeproj решена, вот пример полного скрипта для генерации R.swift:

# Создание xcodeprojgenerateXcodeProject() { xcodegen generate --spec Resources.yml} # Получаем buildSettings с помощью логов xcodebuild команды, лучше проверять, создан ли этот файл# Чтобы сократить время скрипта и не билдить каждый разgetBuildSettings() { xcodebuild -project "Resources.xcodeproj" -target "Resources" -showBuildSettings > buildSettings.txt} # Создание enviroment переменных без которых R.swift скрипт работать не будетparseEnvironmentVariables() { export SRCROOT="$(cat buildSettings.txt | grep -m1 "SRCROOT" | sed 's/^.*= //' )" export TARGET_NAME="$(cat buildSettings.txt | grep -m1 "TARGET_NAME" | sed 's/^.*= //' )" export PROJECT_FILE_PATH="$(cat buildSettings.txt | grep -m1 "PROJECT_FILE_PATH" | sed 's/^.*= //' )" export TARGET_NAME="$(cat buildSettings.txt | grep -m1 "TARGET_NAME" | sed 's/^.*= //' )" export PRODUCT_BUNDLE_IDENTIFIER="$(cat buildSettings.txt | grep -m1 "PRODUCT_BUNDLE_IDENTIFIER" | sed 's/^.*= //' )" export PRODUCT_MODULE_NAME="$(cat buildSettings.txt | grep -m1 "PRODUCT_MODULE_NAME" | sed 's/^.*= //' )" export TEMP_DIR="$(cat buildSettings.txt | grep -m1 "TEMP_DIR" | sed 's/^.*= //' )" export BUILT_PRODUCTS_DIR="$(cat buildSettings.txt | grep -m1 "BUILT_PRODUCTS_DIR" | sed 's/^.*= //' )" export DEVELOPER_DIR="$(cat buildSettings.txt | grep -m1 "DEVELOPER_DIR" | sed 's/^.*= //' )" export SOURCE_ROOT="$(cat buildSettings.txt | grep -m1 "SOURCE_ROOT" | sed 's/^.*= //' )" export SDKROOT="$(cat buildSettings.txt | grep -m1 "SDKROOT" | sed 's/^.*= //' )" export PLATFORM_DIR="$(cat buildSettings.txt | grep -m1 "PLATFORM_DIR" | sed 's/^.*= //' )" export INFOPLIST_FILE="$(cat buildSettings.txt | grep -m1 "INFOPLIST_FILE" | sed 's/^.*= //' )" export SCRIPT_INPUT_FILE_COUNT=1 export SCRIPT_INPUT_FILE_0="$TEMP_DIR/rswift-lastrun" export SCRIPT_OUTPUT_FILE_COUNT=1 export SCRIPT_OUTPUT_FILE_0="$SRCROOT/Sources/Resources/Generated/R.generated.swift"} # Вызов скрипта для генерацииrswift() { R.swift generate --accessLevel public "$SCRIPT_OUTPUT_FILE_0"} # Заменяем бандл в котором R.swift пытается найти ресурсы по дефолту# Bundle.module - расширение генерируется SPM, если вы в пакете указываете для таргета ресурсные зависимостиreplaceRSwiftHostingBundle() { sed -i '' -e 's/Bundle(for: R.Class.self)/Bundle.module/' ./Sources/Resources/Generated/R.generated.swift} mkdir Sources/Resources/GeneratedgenerateXcodeProjectgetBuildSettingsparseEnvironmentVariablesrswiftreplaceRSwiftHostingBundle

Круг 4. Cocoapods зависимость в SPM пакете.

Основная сложность в том, что нет нативного способа подключения к пакету Pod или fat фреймворков, а некоторые разработчики свои библиотеки на SPM переводить не торопятся. Здесь нам поможет proxy пакет-обертка с XCFramework. Если Pod, который нужно подключить к SPM опенсорсный, то можно скачать исходный код библиотеки и собрать XCFramework по этому гайду.

Если Pod распространяется как собранный бинарник через .framework, то придется действовать немного по-другому.

Как и в предыдущем случае, нужно собрать XCFramework. Для начала из fat фреймворка, который поставляется Pod-ом необходимо собрать 2 фреймворка для симулятора и для девайса. После этого объединим их в универсальный фреймворк. Вот скрипт, который делает XCFramework из фремворка с архитектурами arm64 и x86_64. Узнать архитектуры, которые поддерживает фреймворк можно с помощью команды lipo -info pathtoframework.

# Делаем 2 копии фреймворка для симулятора и устройстваcp -a YandexMapsMobile YandexMapsMobile_simcp -a YandexMapsMobile YandexMapsMobile_device cd YandexMapsMobile_sim/YandexMapsMobile.framework/Versions/A# Здесь мы выбираем какая архитектура нам нужна из fat фреймворка и выносим ее в отдельный фреймворкlipo -thin x86_64 YandexMapsMobile -output YandexMapsMobile_x86_64# Создание universal framework-a для симулятора# Если вы хотите собрать не под одну архитектуру симулятора# а под несколько (i386), для этого нужно будет сделать два раза thin# и соединить их в createlipo -create YandexMapsMobile_x86_64 -output YandexMapsMobile_simrm -rf YandexMapsMobile YandexMapsMobile_x86_64mv YandexMapsMobile_sim YandexMapsMobilecd ../../../.. # Просто дублирование кода, но сборка под девайсcd YandexMapsMobile_device/YandexMapsMobile.framework/Versions/Alipo -thin arm64 YandexMapsMobile -output YandexMapsMobile_arm64lipo -create YandexMapsMobile_arm64 -output YandexMapsMobile_devicerm -rf YandexMapsMobile YandexMapsMobile_arm64mv YandexMapsMobile_device YandexMapsMobilecd ../../../.. # Объединяем в xcframeworkxcodebuild -create-xcframework -framework YandexMapsMobile_sim/YandexMapsMobile.framework -framework YandexMapsMobile_device/YandexMapsMobile.framework -output YandexMapsMobile.xcframework

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

let package = Package(    name: "YandexMapsMobileWrapper",    platforms: [        .iOS(.v11),    ],    products: [        .library(            name: "YandexMapsMobileWrapper",            type: .static,            // Используем таргет обертку над XCFramework и его зависимостями            targets: ["YandexMapsMobileWrapper"]),    ],    dependencies: [    ],    targets: [        // Подключаем наш фреймворк локально, также его можно добавлять и через url        .binaryTarget(name: "YandexMapsMobileBinary", path: "YandexMapsMobile.xcframework"),        // обертываем наш фреймворк зависимостями        .target(            name: "YandexMapsMobileWrapper",            dependencies: [                .target(name: "YandexMapsMobileBinary"),            ],            linkerSettings: [                .linkedFramework("CoreLocation"),                .linkedFramework("CoreTelephony"),                .linkedFramework("SystemConfiguration"),                .linkedLibrary("c++"),                .unsafeFlags(["-ObjC"]),            ]),    ])

Круг 5. Краш при попытке получить бандл SPM пакета (Bundle.module).

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

private class BundleFinder {}  // Это копия автосгенерированого SPM расширения, есть 2 отличияpublic extension Bundle {        // Отличие 1, другое название, чтобы не было конфликтов    static var resourceBundle: Bundle = {         let bundleName = "Resources_Resources"        let candidates = [            Bundle.main.resourceURL,            Bundle(for: BundleFinder.self).resourceURL,            Bundle.main.bundleURL,            // Отличие 2, еще один путь где может лежать бандл с ресурсами            Bundle(for: BundleFinder.self).resourceURL?.deletingLastPathComponent().deletingLastPathComponent(),        ]        for candidate in candidates {            let bundlePath = candidate?.appendingPathComponent(bundleName + ".bundle")            if let bundle = bundlePath.flatMap(Bundle.init(url:)) {                return bundle            }        }        fatalError("unable to find bundle named \(bundleName)")    }()    }

Круг 6. Блокирующая Resolve Swift Packages стадия.

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

Круг 7. Other Linker Flags и SPM.

Может возникнуть ситуация, когда пакет должен линковаться со специальными флагами. Частый пример это ObjC флаг. Эти флаги для линковщика можно указать с помощью likerSettings: [.unsafeFlags([ObjC])] в таргете вашего пакета. К сожалению, если ваш пакет использует unsafeFlags, то его нельзя подключить к проекту напрямую, только через прокси-пакет, и только с указанием его как локальной или branch зависимости.

Вывод

Swift Package Manager удобный и интуитивно понятный нативный менеджер зависимостей. Однако, если вы планируете использовать его для разбивки приложения на подпроекты-пакеты, то нужно быть готовым к временным рискам и проблемам. К счастью, почти любая проблема связанная с SPM имеет свой workaround, но готовы ли вы идти на них и искать их?

Надеюсь решения проблем, с которыми я столкнулся помогут вам!

Подробнее..

Перевод Как отвечать на собеседовании, чтобы побудить нанять вас

28.04.2021 20:06:12 | Автор: admin

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


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

Безотчётное чувство тревоги и ожидание чего-то плохого часто приводят к тому, что программисты приходят на собеседование в заторможенном состоянии. Любой самый невинный вопрос сбивает их с толку. Они ведут себя, как плохие певцы, которым не хватает воздуха уже на первом куплете.

Боязнь прямого общения с незнакомыми людьми не единственная их особенность. У них начисто отсутствует практическая смётка. Когда программисты выходят на собеседование по Zoom с выключенными камерами и отключённым микрофоном, мне остаётся только развести руками. Через десять минут после начала собеседования они внезапно вспоминают, что у них выключен звук и начинают его настраивать. А после того как прошло уже достаточно времени и со звуком вроде бы разобрались, передо мной на экране возникает какая-то тёмная фигура, главное желание которой не вылезать из своей норы.

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

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

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

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

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

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

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

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

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

Как же это было по-человечески, как же прекрасно! Он влюбил меня в себя с первого взгляда.

Но на этом сюрпризы не закончились, каждый его новый ответ поражал меня всё сильнее. Судите сами: вот как мой новый сотрудник отвечал на каждый вопрос.

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

Если и есть что-то, что я записываю во время собеседования, так это ответ на этот вопрос.

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

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

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

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

И я сразу стал представлять, как этот человек мог бы работать в команде.

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

Как вы обычно развлекаетесь?

Никак!

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

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

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

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

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

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

Как вы изучаете новые технологии?

Высококлассные специалисты знают, что учиться никогда не поздно.

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

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

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

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

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

Нарисуйте схему последней архитектуры, над которой вы работали

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

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

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

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

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

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

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

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

Не со всеми тезисами автора можно согласиться, но в чем автор точно прав так это в том, что учиться никогда не поздно. Даже более учиться необходимо на протяжении всего карьерного пути IT-специалиста. Если хочется оставаться востребованным, если хочется создавать новое и получать максимум возможностей. И чтобы обучение не доставляло боль нужно сделать его максимально приятным, как раз этим и занимаемся мы, дополняя наши программы поддержкой опытных менторов, внутренними хакатонами и другими вещами, которые делают обучение интересным. "Поверните ключ", выбрав программу по душе и полетели! :-)

У нас много программ для специалистов со стажем и совсем новичков:

Другие профессии и курсы
Подробнее..

Recovery mode Как компании выбрать инструменты для дата-инженеров и не превратить всё в технологический зоопарк опыт PROFI.RU

21.08.2020 12:12:17 | Автор: admin
Редактор Нетологии побеседовала с тимлидом команды BI в Profi.ru Павлом Саяпиным о том, какие задачи решают дата-инженеры в его команде, что за инструменты для этого используют и как же всё-таки правильно подойти к выбору инструментария для решения дата-задач, в том числе нетипичных. Павел преподаватель на курсе Дата-инженер.

Чем занимаются дата-инженеры в Profi.ru


Profi.ru это сервис, который помогает встретиться клиентам и специалистам самых различных сфер. В базе сервиса более 900 тысяч специалистов по 700 видам услуг: репетиторы, мастера по ремонту, тренеры, мастера красоты, артисты и другие. Ежедневно регистрируется более 10 тысяч новых заказов всё это даёт порядка 100 млн событий в день. Поддерживать порядок в таком количестве данных невозможно без профессиональных дата-инженеров.

В идеале Data Engineer развивает культуру работы с данными, с помощью которой компания может получать дополнительную прибыль или сокращать издержки. Приносит ценность бизнесу, работая в команде и выступая важным звеном между различными участниками от разработчиков до бизнес-потребителей отчётности. Но в каждой компании задачи могут отличаться, поэтому рассмотрим их на примере Profi.ru.

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


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


Место процесса Data Quality в общей структуре хранилища данных

Важное значение отводится пояснительной документации по работе с данными. Это упрощает работу и дата-инженера (не отвлекают вопросами), и пользователя данных (может сам найти ответы на свои вопросы). В Profi.ru такие документы собраны на внутреннем форуме.

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

Тот же Tableau с точки зрения конечного пользователя дашборда не позволяет вывести все возможные измерения. Пользователь довольствуется теми фильтрами, что сделал разработчик дашборда. Это порождает два сценария:

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

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

Аккумулируют данные со всех источников в одном месте


Источники данных могут быть внутренними и внешними. Например, у кого-то бизнес зависит от погодных сводок, которые нужно собирать и хранить, от внешних источников.

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

Делают дашборды


Визуализацию данных лучше делать в профессиональном инструменте например, в Tableau.

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

Качественная визуализация данных позволяет легче и быстрее принимать решения.

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


Пример продакт-дашборда Profi.ru (один из листов). В целях конфиденциальности информации названия метрик и осей скрыты

Примеры реальных задач


Задача 1 перелить данные из исходных (операционных) систем в хранилище данных или ETL


Одна из рутинных задач дата-инженера.

Для этого могут использоваться:

  • самописные скрипты, запускаемые по cron или с помощью специального оркестровщика типа Airflow или Prefect;
  • ETL-решения с открытым кодом: Pentaho Data Integration, Talend Data Studio и другие;
  • проприетарные решения: Informatica PowerCenter, SSIS и другие;
  • облачные решение: Matillion, Panoply и другие.

В простом исполнении задача решается написанием YML-файла строк на 20. Занимает это минут 5.

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

В Profi эта простая задача при отлаженном процессе состоит из следующих шагов:

  • Выяснить у заказчика, какие нужны данные и где они лежат.
  • Понять, есть ли доступы к этим данным.
  • Если доступов нет, запросить у админов.
  • Добавить новую ветку в Git с кодом задачи в Jira.
  • Создать миграцию на добавление данных в якорную модель через интерактивный Python-скрипт.
  • Добавить файлы прогрузок (YML-файл с описанием того, откуда данные берутся и в какую таблицу записываются).
  • Протестировать на стенде.
  • Залить данные в репозиторий.
  • Создать pull request.
  • Пройти код ревью.
  • После прохождения код-ревью данные заливаются в мастер-ветку и автоматически раскатываются в продуктив (CI/CD).

Задача 2 удобно разместить загруженные данные


Другая частая задача разместить загруженные данные так, чтобы конечному пользователю (или BI-инструменту) было удобно с ними работать и не приходилось делать лишних движений для выполнения большинства задач. То есть построить или обновить Dimension Data Store (DDS).

Для этого могут применяться решения из 1-й задачи, так как это также ETL-процесс. В самом простом варианте обновление DDS осуществляется с помощью SQL-скриптов.

Задача 3 из разряда нетипичных задач


В Profi зарождается стриминговая аналитика. Генерируется большое количество событий от продуктовых команд записываем их в ClickHouse. Но там нельзя вставлять записи по одной в большом количестве, поэтому приходится объединять записи в пачки. То есть писать напрямую нельзя нужен промежуточный обработчик.

Используем движок на базе Apache Flink. Пока порядок действий такой: движок обрабатывает входящий поток событий складывает их пачками в ClickHouse на ходу считает количество событий за 15 минут передаёт их сервису, который определяет, есть ли аномалии сравнивает со значениями за аналогичные 15 минут с глубиной в 3 месяца если есть, кидает оповещение в Slack.


Схема для фронтовой аналитики (часть загрузки)

Фреймворк Apache Flink гарантирует доставку как минимум один раз. Тем не менее появляется вероятность дубликатов. В случае с RabbitMQ это можно решить, используя Correlation ID. Тогда гарантируется единичная доставка целостность данных.

Считаем количество событий опять же с помощью Apache Flink, выводим через самописный дашборд, написанный на NodeJS, + фронт на ReactJS. Быстрый поиск не дал похожих решений. Да и сам код получился простым написание не заняло много времени.

Мониторинг скорее технический. Смотрим аномалии, чтобы на ранних стадиях предотвращать проблемы. Какие-то существенные глобальные метрики компании в мониторинг пока не входят, поскольку направление стриминговой аналитики находится на стадии формирования.

Основные инструменты дата-инженеров


С задачами дата-инженеров более-менее понятно, теперь немного об инструментах, которые используются для их решения. Конечно, инструменты в разных компаниях могут (и должны) отличаться всё зависит от объема данных, их скорости поступления и неоднородности. Также может зависеть от пристрастности специалиста к какому-то одному инструменту только потому, что он с ним работал и хорошо его знает. В Profi.ru остановились на таких вариантах

Для визуализации данных Tableau, Metabase


Tableau выбрали давно. Эта система позволяет оперативно анализировать большие массивы данных, при этом не требует затратного внедрения. Для нас он удобен, красив и привычен часто в нём работаем.

Про Metabase знают немногие, между тем для прототипирования он очень хорош.

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

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

Инструментов очень много просто найдите свой :-)

Для хранения данных ClickHouse, Vertica


ClickHouse бесплатный быстрый инструмент для хранения продуктовых событий. На нём аналитики сами делают обособленную аналитику (если им хватает данных) или дата-инженеры берут агрегаты и перезаливают их в Vertica для построения витрин.

Vertica крутой удобный продукт для отображения конечных витрин.

Для управления потоками данных и проведения вычислений Airflow


Данные мы грузим через консольные инструменты. Например, через клиент, который идёт с MySQL, так получается быстрее.

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

Основной язык программирования Python


У Python намного ниже порог вхождения + в компании есть компетенции по этому языку. Другая причина под Airflow DAGи пишутся на Python. Эти скрипты просто обёртка над загрузками, основная работа делается через консольные скрипты.

Java мы используем для разработки под аналитику в режиме реального времени.

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


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

Технологический зоопарк это инструменты, которые выполняют одни и те же функции. Например, Kafka и RabbitMQ для обмена сообщениями или Grafana и Zeppelin для визуализации.


Карта технологий и компаний в сфере данных и ИИ видно, как много дублирующих решений может быть

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

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

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

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

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

Не стоит использовать технологии ради технологий. Лучше всего к вопросу подходить прагматично: задача набор инструментов, которые могут эту задачу решить.

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

Выбор инструмента наполовину прыжок веры, наполовину личный опыт. Нет полной уверенности, что инструмент подойдёт.

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

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

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

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

Если говорить о подходе к выбору, то в Profi придерживаются таких принципов:

  • Не принимать решение в одиночку. Когда человек что-то выбирает, он автоматически убеждён в своей правоте. Другое дело убедить других, когда нужно привести серьёзные доводы в защиту. Это помогает в том числе увидеть слабые стороны инструмента.
  • Советоваться с главным специалистом по данным (диалог по вертикали). Это может быть главный дата-инженер (Chief Data Engineer), руководитель BI-команды. Топы видят ситуацию более широко.
  • Общаться с другими командами (диалог по горизонтали). Какие инструменты они используют и насколько удачно. Возможно, инструмент коллег может решить и ваши задачи и не придётся устраивать зоопарк решений.


Внутренние компетенции как эффективная замена внешнему поставщику услуг


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

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

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

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

В Profi внедрение BI было in-house. Основная сложность была в том, что бизнес хотел запустить BI быстро. Но на построение такого проекта требовалось время: нарастить компетенции, залить данные, построить удобную схему хранилища, выбрать инструменты и освоить их.

Основная горячая фаза, когда всё строилось и кристаллизовывалось, длилась где-то год. А развивается проект до сих пор.

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

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

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

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

В подобных историях важную роль играют так называемые early adopters те, кто готов пробовать новое, среди топ-менеджеров, аналитиков, продакт-менеджеров. Чтобы сырая тема взлетела, нужны первопроходцы, которые подтвердят, что всё работает и этим удобно пользоваться.

Если кто хочет поделиться решением третьей задачки из описанных выше welcome :-)
Подробнее..

Мой топ полезных инструментов для Unity разработчика

09.01.2021 14:22:36 | Автор: admin

Всем привет! Меня зовут Григорий Дядиченко, и я всё ещё разрабатываю проекты на юнити под ключ. Сегодня хочется поговорить про полезный инструментарий для Unity разработчика. У меня давно на эту тему есть свой топ ассетов или софта, которые используются почти в каждом проекте, плюс несколько своих утилит. Не будем касаться слишком широких и банальных инструментов типа adb, а составим некоторый набор того, что можно использовать почти в каждом проекте.

В разработке я около 7 лет, большую из которых провёл в инди или аутсорс/фрилансе. Поэтому речь пойдёт про инструменты для себя, а не про CI&CD пайплайн, или что неплохо было бы знать и докер с кубером. Это действительно крутые и полезные инструменты (хотя не основная экспертиза юнити разработчика от слова совсем), но речь по инструменты для ускорения/удобства домашней разработки коммерческих проектов. Чтож начнём.

Graphy

Как и написано в описании. Ультимативный FPS каунтер. Очень удобен для дебага на устройствах и тестирования перфоманса. Простой в интеграции - просто закинуть префаб, но при этом отображает всё и даже больше. Фпс, память, график производительности, а также информацию об устройстве вроде OS, объеме оперативной памяти, поддерживаемом графическом апи, уровне шейдеров и т.п. Это, пожалуй тот ассет, который используется практически в каждом проекте.

https://github.com/Tayx94/graphy

Lunar Unity Mobile Console

Даже на фри версии, очень удобный ассет, особенно на IOS. Позволяет смотреть, по сути, Unity лог на устройстве. Используется реже, так как в большей части нужно для тестеров, которым неудобно использовать логи adb, хотя на IOS читать логи в консоли менее удобно, чем в лунаре. Но основное удобство в про версии - это кнопки и переменные, которые из неё можно включать для тестирования, начисления себе игровой валюты и многого другого. Конечно, такое пишется не особо долго, но зачем изобретать велосипед, когда есть что-то готовое?

https://github.com/SpaceMadness/lunar-unity-console

Desmos Calculator

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

https://www.desmos.com/calculator?lang=ru

NGINX

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

https://nginx.org/

Simple Build Server

Моя личная небольшая утилита для пересылки файлов или билдов на тестовые устройства или же другие ПК в локальной сети. В основном я пользуюсь ей на андроиде, так как adb установка не скажу, что сильно удобнее, но что важнее с телефонами xiaomi нельзя устанавливать билды через adb, если в телефоне не стоит сим карта. Которая мне абсолютно не нужна. В отличии от того же autoindex nginx данный сервер mobile friendly. Потому что в стандартном autoindex nginx слишком маленькие кнопки. Для файлов конечно можно использовать shared folder или ftp, но в целом стандартный веб интерфейс для меня получился в разы удобнее и проще в конфигурации.

https://github.com/Nox7atra/SimpleBuildsServer

Odin - Inspector and Serializer

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

https://assetstore.unity.com/packages/tools/utilities/odin-inspector-and-serializer-89041

KinoGlitch

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

https://github.com/keijiro/KinoGlitch

JLs Unity Blend Modes

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

https://github.com/penandlim/JL-s-Unity-Blend-Modes

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru