За сравнительно небольшое время генеративный искусственный интеллект (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.

По большому счёту, самая первая и самая важная оптимизация, которую можно применить к любой современной системе машинного обучения, заключается в том, чтобы реализовать в этой системе пакетную обработку данных (batching). Для того чтобы получить результат работы системы (inference, инференс) в пакетном режиме — ей, вместо одного элемента входных данных, отправляют N таких элементов. Чаще всего никаких дополнительных нагрузок на систему это не создаёт. Формирование инференса для каждого из элементов, входящих в пакет размера N, занимает в точности столько же времени, сколько нужно для обработки одного элемента входных данных. Почему это так? На первый взгляд может показаться, что обработка пакета данных не может обойтись без некоторых накладных затрат ресурсов. В конце концов — оборудованию приходится выполнять в N раз больше действий.

Если прибегнуть к простейшей модели работы нейронной сети, то получится, что некоторая дополнительная нагрузка на систему, всё же, создаётся. Для выполнения пакетных вычислений нужно выполнить в N раз больше операций. И, на самом деле, если попробовать это на CPU, то окажется, что так оно и есть (среднее время формирования вывода для ResNet-50, Colab).

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

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

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

На сотрудников нельзя положиться?

Приходиться переделывать за ними работу?

Если хочешь сделать что-то хорошо, сделай это сам.

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