Все же так делают, не так ли?
Скуфа не пускают в IT?
Мне 37 лет и я скуф.
Будем считать, что пока да.
Я уже несколько месяцев не пью. И месяц как начал избавляться от лишнего веса.
В общем посмотрел я на все эти IT шные специальности, на солнечные острова, на нежные попы малолетних проституток из Юго-Восточной Азии, на свежий кокоин, собранный девственницами в Колумбии в лунную ночь.
И тоже захотел. А то вокруг мрачный Питер, денег хватает только на проституток из Средней Азии и на пиво по акции из Пятерочки.
Погуглил курсы, и понял, что ничего не понял. Кто то пишет восторг, был дурочком, прошел курс в Сайлент что то там, и уже на Бали. Типа берут сразу же, вокруг гарантии трудоустройства. И прочее. Ни работа, а мечта.
Но беда в том, что английский не мой вариант, в математике и написании кода. В общем не моя тема.
И решил пойти в продажи IT. Благо опыт в продажах есть.
Шлю всем резюме, написал сопроводительное письмо большое.
А отклика нет. Даже отказов.
В отпуске планирую позвонить сам. И всех достать с вопросом "почему скуфа в IT не пускает?"
Кто что посоветует
Олдскулы свело: операторы Собела и Канни
Операторы Собела и Канни, как мы писали в предыдущем посте, стали первыми мощными инструментами, сыгравшими огромную роль в развитии CV.
Почему?
Оператор Собела помогает выявить изменения яркости в изображении, что позволяет находить края объектов.
Как это работает? Допустим, у вас есть фотография, и вы хотите найти на ней границы всех объектов. Оператор Собела берет небольшие области изображения (обычно 3x3 пикселя) и проверяет, как меняется яркость в горизонтальном и вертикальном направлениях. Результат получается за счет применения специальных матриц, называемых фильтрами Собела, которые и выделяют эти изменения.
Оператор Канни — это уже более сложный инструмент для выделения границ. Разработанный Джоном Канни в 1986 году, этот метод до сих пор считается одним из лучших для выявления краев на изображениях.
Оператор Канни использует несколько этапов для достижения точного результата:
Фильтрация шума
Первым делом изображение сглаживается с помощью фильтра Гаусса, чтобы уменьшить шум.
Поиск градиентов
Затем вычисляются градиенты изображения, чтобы определить изменения яркости.
Подавление немаксимумов
Далее проверяется, какие из найденных границ являются локальными максимумами.
Двойная пороговая обработка
В конце применяется двойной порог для выделения сильных и слабых границ, а затем проводится соединение краев.
Даже сейчас операторы Собела и Канни остаются важными инструментами в арсенале ML-инженеров. Их эффективность и простота делают их незаменимыми для многих задач, от предварительной обработки изображений до анализа в реальном времени.
А примеры кода на Python для операторов Собела и Канни вы можете посмотреть по этой ссылке.
Кто чем занимается в разработке и как с ними общаться: подробный гайд
Из кого состоит команда разработки, кто в нее входит кроме программистов, за какие области отвечает каждый из участников и по каким поводам стучаться к ним в личку
Меня зовут Сергей Горшунов. Я веду блог о финансах
Однажды в жизни каждого человека наступает момент знакомства с такой сферой, как разработка. Причины могут быть совершенно разными: реклама во время подкаста на YouTube, устройство на работу в компанию, где есть IT-отдел, чтение новостей, приход нового человека в компанию друзей и так далее.
Не всем нужно знать, кто такие эти разработчики и чем они занимаются, но для тех, кому все-таки понадобилось понимание специфики работы этих людей, мы подготовили гайд. В нем расскажем об участниках команды разработки, их задачах, по каким поводам к ним обращаться и как понять, о чем они говорят.
Команда разработки в лицах
К счастью, у большинства проектов за все не отвечает один единственный человек, похожий на Шиву. Команда разработки на то и команда, что в ее состав входит целый коллектив.
Владелец продукта или PO (Product Owner) — это тот, кто занимается управлением продукта. Он является связующим звеном между заказчиком и командой, выступая за интересы первого. На нем лежит подготовка требований по функционалу, постановка задач в бэклог, определение приоритетности выполнения и так далее.
Проектный менеджер или PM (Project Manager) — это управляющий проекта, а не продукта, в отличии от РО. Он координирует действия команды, следит за сроками и контролирует выполнение проекта. РМ дает РО данные о проекте, а РО ему о продукте.
Тимлид — это руководитель команды разработчиков. Его задача в организации работы и контроле за происходящим. Так как он курирует процесс разработки, принимает ключевые решения и помогает подчиненным, то ему нужно понимать во всем. В его компетенции входит как фронт, так и бэк.
Фронтенд разработчик или фронтендер (frontend developer) — это тот, кто наводит красоту и делает нашу с вами жизнь лучше. Он отвечает за части сайта или приложения, с которыми взаимодействует пользователь. Фронтендер берет за основу работу дизайнера и превращает ее в визуальную часть сайта. Правильность отображения кнопок, текста, картинок и других элементов — ответственность фронтенд разработчика.
Бэкенд разработчик или бэкендер (backend developer) — это боец невидимого фронта, работающий над внутренней частью сайта или приложения. Он обеспечивает правильное выполнение команд от пользователя. Если фронт отвечает за правильное подсвечивание и отображение кнопки, то бэк за действие, которое произойдет при нажатии.
UI/UX дизайнер — это создатель плана сайта или приложения с точки зрения визуального наполнения. Дизайнер продумывает логику взаимодействия пользователя с продуктом, размещает контент и после передает свое творение разработчикам.
QA-инженер или тестировщик — это ответственный за проверку работы. Он ищет всевозможные ошибки и сообщает о них. Так как проблемы могут касаться разных частей сайта или приложения, то взаимодействует тестировщик практически со всей командой. Он даже может предложить новое решение для улучшения клиентского опыта или повышения продаж.
DevOps-инженер — это тот, кто упрощает взаимодействие между разработчиками, тестировщиками и менеджерами, ускоряет разработку за счет автоматизации части процессов. Девопс также отвечает за работу сервера и должен гарантировать непрерывность работы. Задача у него непростая, поэтому для понимания сути его работы желательно иметь базовые знания в программировании.
Этот список профессий далеко не исчерпывающий и может включать себя и других сотрудников, но мы остановимся на наиболее популярных и известных, ведь именно с ними проще всего столкнуться в реальной жизни.
Цикл разработки: кто, что и когда делает
Первое знакомство с командой прошло успешно, так что самое время посмотреть на ее жизнь в естественной среде.
Не вникая в процесс разработки, может показаться, что создание ПО происходит по единому скрипту. Однако все не так просто — методологий и принципов разработки существует достаточно много. Чтобы не углубляться в эти нюансы, мы пройдемся по верхам, сформируем общее понимание этапов разработки ПО и расскажем, кто и когда вступает в игру.
Подготовка и планирование
Владелец продукта:
собирает данные о клиентах, рынке и конкурентах;
получает информацию от заказчика;
готовит список целей и определяет задачи;
согласует план проекта с РМ.
Проектный менеджер:
систематизирует собранные данные;
фиксирует задачи и требования от РО и совместно с РО расставляет приоритеты;
согласовывает техническое задание;
готовит план проекта.
Тимлид:
консультирует РО и РМ по технической части;
определяет, что можно реализовать, а что нет;
участвует в формировании задач с точки зрения технической реализации;
определяет технологии и инструменты;
оценивает необходимые ресурсы и время для выполнения поставленных задач;
проверяет и утверждает техническое задание.
Проектирование
Тимлид:
определяет основу архитектуры;
консультирует других участников команды;
принимает ключевые решения по части разработки.
UI/UX дизайнер:
формирует прототип сайта;
готовит основные части;
наращивает дополнительные по мере внесения правок;
финализирует дизайн интерфейса.
Проектный менеджер:
следит за выполнением работ командой и соответствием установленным требованиям.
Разработчики:
помогают дизайнеру с подготовкой прототипа;
вносят правки с точки зрения возможности реализации прототипа.
Разработка
Фронтенд разработчик:
создает внешние части сайта по прототипу от дизайнера.
Бэкенд разработчик:
создает внутреннюю (серверную) часть сайта и работает с базами данных (БД).
Тимлид:
координирует работу разработчиков и помогает со сложными задачами.
DevOps-инженер:
работает над автоматизацией части процессов разработки и обеспечением ее непрерывности.
Тестирование
QA-инженер:
ищет ошибки и передает данные о них разработчикам.
Разработчики:
воспроизводят найденные тестировщиком баги;
исправляют ошибки.
Тимлид:
координирует работу разработчиков и тестировщиков;
помогает со сложными проблемами.
Развертывание
DevOps-инженер:
развертывает приложения на сервере — вывод ПО на сервер с локального хранения (без этого пользователи не смогут взаимодействовать с ПО);
настраивает инфраструктуру — подготовка к началу работы серверов и других технических компонентов;
управляет CI/CD процессами — обеспечение непрерывного процесса разработки, тестирования и развертывания.
Бэкенд разработчик:
принимает участие в настройке серверной части и настройке взаимодействия с базами данных.
Проектный менеджер:
контролирует работу команды и следит за процессами.
Тимлид:
следит за развертыванием, обеспечивает его корректность и помогает другим членам команды.
Поддержка и обновление
Разработчики:
исправляют баги;
разрабатывают и внедряют новые функции.
QA-инженер:
ищет ошибки и передает их разработчикам.
Тимлид:
помогает в решении сложных проблем, которые не удалось разрешить на уровне разработчиков и тестировщиков.
Владелец продукта:
дает обратную связь от заказчика и пользователей;
формирует задачи по новому функционалу;
определяет приоритетность задач.
Проектный менеджер:
организует работы по поддержке и обновлению ПО командой.
Документация
Тимлид:
создает и обновляет техническую документацию кода с описанием технологий, инструментов и библиотек.
Разработчики:
комментируют код и обновляют данные при изменениях.
Проектный менеджер:
следит за актуальностью документации и своевременным обновлением.
Владелец продукта:
готовит документацию для пользователей.
Кому и когда писать
Если в вашем проекте вы не состоите в команде разработки, но вам нужно коммуницировать с ней, то вы можете воспользоваться нашей шпаргалкой с темами и примерами вопросов, которые можно задать.
Тимлид
По техническим возможностям и ограничениям.
«Какие новые функции будут реализованы в будущем?»
«Какие метрики используются для оценки стабильности работы ПО?»
«Есть ли ограничения, которые нужно учитывать при планировании нового функционала?»
Владелец продукта
По функциям, приоритетам задач, дорожной карте и обратной связи от пользователей.
«Можно ли добавить функцию N?»
«Какие функции будут запущены в следующем квартале?»
«Когда будет реализована функция N»?
«Какой план развития у проекта?»
«Развитие каких функций сейчас в приоритете?»
Проектный менеджер
По срокам, графикам, обновлениям, статусам, координации задач и сотрудников.
«Какой сейчас график релизов?»
«Есть ли сейчас задержки по задачам и будет ли реализован новый функционал в срок?»
«Какой сейчас статус у разработки?»
Фронтенд разработчик
По изменениям визуала и интерактивных элементов.
«Можем ли мы поменять фото на главной на анимацию?»
«Как лучше реализовать всплывающие окна?»
«Насколько сложно будет поменять дизайн на сайте?»
«Сильно ли скажется на скорости загрузки внедрение новых анимированных блоков?»
Бэкенд разработчик
По новому функционалу и получению данных.
«Можем ли мы подключить новую аналитику?»
«Можно ли настроить выгрузку определенных данных о действиях пользователей?»
«Как долго будет устраняться баг?»
UI/UX дизайнер
По дизайну, брендингу и улучшению пользовательского опыта.
«Нужно ли нам адаптировать дизайн страницы для повышения конверсий?»
«Как нам оформить новые функции для выделения их среди старых?»
«Мы хотим добавить новый блок, будет ли он удобен для пользователей или нужно подкорректировать?»
QA-инженер
По тестированию новых функций, ошибкам, стабильности и качеству работы ПО.
«У нас запланирована рекламная кампания на следующей неделе, есть ли баги, которые еще не исправлены?»
«Есть ли ошибки, о которых нужно знать?»
«Сколько времени уйдет на тестирование новой версии сайта?»
DevOps-инженер
По стабильности работы сервера, мониторингу производительности системы.
«Выдержит ли сайт повышенную нагрузку при проведении маркетинговой кампании?»
«Можем ли мы настроить мониторинг для отслеживания производительности системы?»
«Что нужно сделать для повышения устойчивости к нагрузке при наплыве пользователей?»
Как понять IT-шника
Если вы раньше не общались с представителями IT-сообщества в разрезе работы, то в ходе беседы можете почувствовать себя иностранцем. IT-сфера наполнена собственной терминологией, которую сложно понять без надлежащего опыта. Для вас мы собрали краткий список с популярными словами, которые помогут не потерять нить разговора и стать своим хотя бы на базовом уровне.
Прод — рабочая версия продукта.
Релиз (залить на прод) — выпустить рабочую версию продукта.
Стейдж — среда для тестирования, которая полностью копирует прод.
Баг-репорт — отчет об ошибке.
Проджект — менеджер проекта.
Мок — имитация реального объекта при проведении тестирования.
Спека/дока — документ с техническими требованиями для разработки и тестирования.
Ассайнить — поручить задачу.
Аттач — файл, который прилагается к сообщению.
Грумить — приводить в порядок.
Деплой (развертывание) — совокупность действий, которые делают ПО готовым к использованию на сервере.
Коммит, коммитить — фиксация изменений кода в системе контроля версии (git).
Комплитить — завершить задачу.
Мерджить — объединять изменения от разных программистов в одном проекте.
Патч — временное дополнение к коду.
Пушить — загрузить код в git.
Ребут — перезагрузка.
Темплейт — шаблон.
Фича — функция.
Футер, подвал — элемент сайта в его нижней части.
Хедер — элемент сайта в верхней части.
Бэклог — список задач, которые нужно сделать в будущем.
Спринт — интервал времени, за который нужно выполнить определенный список задач.
Сторя — корневая задача.
Таск, таска — задача.
Апрув, апрувить — согласовать.
Пинговать — напоминать.
Сколько реально зарабатывают начинающие программисты 1С в компаниях фрончази в Москве?
Сколько реально зарабатывают начинающие программисты 1С в компаниях фрончази в Москве, насколько трудно туда устроиться и насколько велика загрузка?
Под начинающим я имею ввиду следующее - человек имеет базовые знания в 1С, имеет коммерческий опыт, 1 сертификат 1С профессионал, но, в целом, навыки далеко не на самом высоком уровне.
Если вы профи в своем деле — покажите!
Такую задачу поставил Little.Bit пикабушникам. И на его призыв откликнулись PILOTMISHA, MorGott и Lei Radna. Поэтому теперь вы знаете, как сделать игру, скрафтить косплей, написать историю и посадить самолет. А если еще не знаете, то смотрите и учитесь.
Даже гуру ошибаются: истории великих фейлов в ML
Все мы знаем, что учиться на ошибках — это часть процесса, и даже самые именитые эксперты в области ML не застрахованы от промахов.
Именно так Эндрю Ын, один из основателей Coursera и гуру deep learning, в начале своей карьеры столкнулся с проблемой, когда тестовые данные случайно включились в тренировочный набор. Модель выдавала потрясающие результаты, но на новых данных показывала себя просто отвратительно. Это заставило Эндрю внедрить более строгие методы валидации и часто напоминать себе и своим коллегам о важности корректного разбиения данных.
И он не одинок в своих проблемах. Джеффри Хинтон, легенда в мире DL, однажды создал слишком сложную архитектуру нейросети для простой задачи. Модель переобучилась и показала плохие результаты на тесте, что заставило его пересмотреть подход к выбору архитектуры. Хинтон осознал, что баланс между сложностью модели и задачей — ключ к успеху.
Следом за Хинтоном, Ян ЛеКун столкнулся с проблемой исчезающих градиентов в глубоких сетях. Эта проблема затрудняла обучение и приводила к неэффективности. Разработав методы использования ReLU активаций, ЛеКун решил эту проблему и понял важность выбора правильных функций активации.
Илон Маск, продвигая технологии автономного вождения в Tesla, тоже столкнулся с ошибками. Система распознавания объектов неправильно классифицировала дорожные знаки и пешеходов, что привело к инцидентам. Это заставило Tesla улучшить алгоритмы и добавить дополнительные уровни валидации, показывая, что тщательная проверка в реальных условиях необходима.
Заключает наш список Джефф Дин из Google, который работал над масштабируемостью ML-систем. В одном из проектов команда столкнулась с проблемами обработки big data, что привело к созданию новых распределенных систем, таких как MapReduce и TensorFlow. Так Дин понял, что для успешного внедрения ML необходимы масштабируемые системы.
Вот так вот. Даже гуру не застрахованы от промахов, но именно через них они и становятся гуру.