Рубрика «задача»

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

Читать полностью »

С 1966 года во всем мире 20 июля отмечают Международный день шахмат. В честь недавно прошедшего праздника мы решили написать статью о шахматных задачах из курсов "Поколение Python".

Так получилось, что шахматные задачи являются одной из главных визитных карточек наших курсов. Мы любим эти задачи потому, что они учат строить алгоритмы, находить закономерности, а также позволяют отточить работу с условными (if-else) и логическими (and и or) операторами.

В общем случае шахматные задачи имеют следующий вид:

Даны две различныеЧитать полностью »

Как я создал архиватор из задачки с техсобеса: сжатие файлов с помощью RLE - 1

Привет, меня зовут Рома. Я работаю в KTS на позиции Python backend-разработчика. 

Однажды мне взбрело в голову написать собственную имплементацию алгоритма сжатия RLEЧитать полностью »

Моя любимая задача для собеседований по программированию - 1


В сети есть уйма постов и видео, где разбираются ответы на вопросы LeetCode. Но обычно рассмотрение в них происходит с позиции соискателя, а не работодателя. В этой же статье я приведу разбор собственной задачи по программированию, которую использовал при приёме людей на работу в Amazon, Google и Microsoft. Читать полностью »

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

Что будет, если от разработчиков не отстать: умирающая команда - 1
Источник

15 человек, из них — один руководитель проекта, три фронта, два бэка, три аналитика, девопс. Симптомы обычные: процессы всем не нравятся, соседи — козлы, потому что не то и не так делают, а как нужно — не знают, ответственности ни на ком толком нет ни за что.

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

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

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

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

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

Читать полностью »

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

После столетий поисков получено точное решение задачи о козе на привязи - 1

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

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

По сей день «никто не знал точного ответа на базовый вопрос», — сказал Марк Мейерсон, математик из академии военно-морского флота США. «Решение всегда было приблизительным».
Читать полностью »

Хакатон на 200 человек — что нужно для организации - 1

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

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

Это понимали мы и понимало руководство СИБУРа, нашего мощного промышленного партнёра, который помогал с проведением и организацией хакатона. Надо было устранять зазор между тем, что уже сделано и тем, что можно и нужно сделать по автоматизации. Для этого мы решили собрать на одной площадке сразу четыре стороны:

  1. Крупнейшие промышленные компании страны.
  2. Вендоров технологий с меняющихся рынков.
  3. Молодых разработчиков.
  4. ИТ-инженеров с опытом работ в сфере или в конкретных нужных технологиях.

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

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

Свиноматка кормит поросят до 26-го дня. За это время она может на них прилечь, что приведёт к тому, что поросят станет чуть меньше, чем было в самом начале. Чтобы этого избежать, используются вот такие станки, как на фото, которые исключают её повороты и хождение по загону. У одной свиноматки — от 10 до 15 поросят. На первой неделе поросята ещё не понимают, что эта туша опасна, и могут не уйти из опасной области, когда она ложится. Когда это происходит, поросёнок громко визжит примерно в половине случаев. Часть поросят можно спасти, если вовремя поднять свинью. Задача — детектировать такие случаи и вызывать сотрудника.

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

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

Когда представитель MARS сказал, что принесёт обучающую выборку, мы не думали, что это будет четыре коробки шоколадок Twix Minis. Читать полностью »

Быстрая проверка десятков гипотез: как мы вырываемся из рутины и устраиваем себе обсуждение в другом городе - 1

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

У такой системы, кроме кучи плюсов, есть два очевидных недостатка:

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

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

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

Поэтому мы три раза уже выезжали в какой-нибудь иностранный город и работали там.Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js