Не знаю — нужно ли вступление к статье, посвящённой ускорению машинного обучения (Machine Learning, ML)?

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

Привет, друзья!

За свою практику программирования я успел написать множество малых, средних и крупных проектов, преимущественно в формате Telegram-ботов. Моя история началась с популярной на то время версии aiogram 2.24 (тех, кто в теме, поймут), а сейчас я полностью перешел на версию 3.x, о чем нисколько не жалею.

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

Сегодня мы научимся:

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

Часто ли нам приходится пользоваться записными книжками? Удобно ли это? Всегда ли
тот кусочек бумаги, на котором записано время и место встречи, под рукой? Насколько
 быстро можно записать необходимую информацию? Все эти вопросы не открывают
Америку, всем понятно, что цифровые планировщики гораздо практичнее, нежели
традиционные письменные. Но что может быть не так с электронными записными
книжками? Например, для внесения очередной записи необходимо произвести большое количество действий: от создания плана новой встречи до ручного ввода места и времени встреч в каждое отдельное поле. Казалось бы, пустяк, да и отнимает не так уж много времени. Но ведь нет предела совершенству! Как раз для улучшения данного аспекта: планирования повседневной (и не только) жизни, предназначен мой проект. Стоит отметить, что он будет полезен в основном для бэк‑офиса: поможет не опоздать на важную встречу, не пропустить совещание и не забыть про дедлайн. И так, перейдем от пустых слов, непосредственно к разработке. В последующей статье описан мой опыт по разработке такого рода проекта, а я это делал впервые, поэтому сильный хейт не принимается:‑)

Мир не такой уж солнечный и приветливый. Это очень опасное, жесткое место. И если только дашь слабину, он опрокинет с такой силой тебя, что больше уже не встанешь. Ни ты, ни я, никто на свете не бьет так сильно, как ЖИЗНЬ. Совсем не важно, как ты ударишь, а важно, КАКОЙ ДЕРЖИШЬ УДАР, как двигаешься вперед. Будешь идти – ИДИ, если с испугу не свернешь. Только так побеждают! Если знаешь, чего ты стоишь, иди и бери свое, но будь готов удары держать, а не плакаться и говорить: «Я ничего не добился из-за него, из-за нее, из-за кого-то»! Так делают трусы, а ты не трус! Быть этого не может!

За сравнительно небольшое время генеративный искусственный интеллект (Gen AI) превратился в одну из ключевых технических парадигм и уже породил отдельное направление в программной инженерии. Это происходит аналогично тому, как сначала это сделали СУБД, потом интернет с поиском и мобильными платформами. Gen AI несет в себе не меньший потенциал для решения и автоматизации ключевых бизнес-проблем.

Это вторая и последняя часть ответа нас двоих Gergely Orosz и Kent Beck:

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

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

Всем привет! 

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

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

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

Всем привет! На связи Юрий Шабалин, генеральный директор «Стингрей Технолоджиз». Вообще я сторонник технических материалов, статей с примерами кода или разбором технологий, но сегодня речь пойдет о другом. Меня всегда интересовало, почему в требованиях регуляторов в области ИБ не указываются проверки мобильных приложений на соответствие государственным стандартам или федеральным законам. И вот недавно, изучая материалы документа по сертификации процесса безопасной разработки, я наткнулся на упоминание мобильной составляющей, что, конечно, вызвало у меня интерес и желание разобраться. Если вы тоже хотите понять, каким образом приложения упоминаются в Профиле защиты Банка России, и какие проверки необходимо осуществлять, чтобы ему соответствовать, приглашаю погрузиться со мной в этот увлекательный мир.

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

Внедрение крупных программных систем подразумевает использование различных методологий имплементации, например: Accelerated SAP, Microsoft Dynamics Sure Steps или Oracle Unified Method. Прикладная методология, предлагаемая по умолчанию вендором программного продукта, детализирует одну из трех классических моделей имплементации: каскадную, итерационную или спиралевидную. Помимо этого существуют определенные правила по управлению проектами вне зависимости от его содержания, которые называют PMBoK (Project Management Body of Knowledge, свод знаний по управлению проектами) [1].

PMBoK подразумевает выделение в проекте ряда ключевых параметров, каждый из которых необходимо планировать, выполнять и осуществлять его мониторинг. Любые отклонения параметров от плановых значений требуют корректировочного действия. Свод знаний разработан американским институтом PMI и имеет длительную историю. На начало 2022 года в русскоязычной литературе доступна PMBoK шестой версии, а в англоязычной – седьмой. Каждая версия PMBoK дополняется новыми подходами, так ранее широкой огласке получили механизмы искусственного интеллекта в управлении проектами, сейчас же активно обсуждается применение принципов гибкой разработки Agile.

Для прочтения книга PMBoK весьма сложна. Определенно знакомство со сводом знаний необходимо начинать, предварительно реализовав хотя бы один проект, в противном случае вы не поймете посыл книжки. В контексте данной статьи, мы ограничимся рассмотрением ERP-проектов. Использование PMBoK в проектах имплементации корпоративных информационных систем выглядит выигрышным, по крайней мере, это позволяет структурировать характеристики проекта и вести их непрерывный контроль. Существенным упущением PMBoK является отсутствие рекомендаций по способам обработки отклонений, что противоречит циклу Деминга [2]. Вполне возможно, это было сделано сознательно, так как невозможно предложить универсальные механизмы для всех предметных областей проектов.

Привет! Меня зовут Дарина Кухтина, я руководитель аналитики в компании, которая разрабатывает мобильные игры, и собеседую аналитиков уже 4 года, а ещё я наставник на курсе «Аналитик данных» в Практикуме. В статье я расскажу, о чём важно помнить, чтобы интервью проходили спокойнее и проще.

Привет всем, меня зовут Никита, я начинающий backend-разработчик. Сегодня хочу вам рассказать про атаку, которая произошла при изучении новой технологии, а именно redis'а.

Привет! На связи Денис, RTE в компании «Автомакон».

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

Меня зовут Саша Назаров, я занимаюсь релиз-менеджментом в RuStore. 

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

Cегодня разовьём тему и поделимся опытом наших следующих шагов в управлении релизами.

Привет! Меня зовут Никита Грибков, я Flutter-разработчик в AGIMA. В сети море статей о различиях между SQL и NoSQL, но в большинстве из них много теории и почти совсем нет прикладных советов. Я пошел другим путем: ниже постараюсь внятно объяснить, какую систему и в каком случае выбирать. Спойлер: всё зависит от проекта и амбиций заказчика. Конечно, сосредоточусь на мобильной разработке, но основные принципы подойдут и в вебе.

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

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

CE поддерживает 69 языков, более двух тысяч компиляторов и широкий спектр архитектур, включая x86, arm, risc-v, avr, mips, vax, tensa, 68k, PowerPC, SPARC и даже древний 6502.