Привет! Меня зовут Саша Шутай, я руководитель направления PHP в AGIMA. Мы с командой подготовили большой разбор научных взглядов двух великих ученых: Алана Тьюринга и Курта Гёделя. Подумали, что будет интересно сравнить их биографии и подходы к искусственному интеллекту. Если тема зайдет, будем и дальше рассказывать об истории математики и разработки.

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

Кажется, что из этих двоих Тьюринг — «хороший полицейский»: Тьюринг-полнота утверждает, что любая задача разрешима, даже если ты программист на Brainfuck. А Гёдель в этой парочке, соответственно, плохиш: его теорема говорит, что некоторые вещи не доказать совсем никак, и в свое время она конкретно обломала программу Гильберта по формализации всея математики. Все ли так однозначно? В чем на самом деле фундаментальное различие между их взглядами? Искусственный интеллект в заголовке — это кликбейт? Ответы на эти и другие вопросы ожидают вас под катом.

Меня зовут Михаил Гелемеев, я лидер команды сопровождения Platform V Pangolin в СберТехе.

Platform V Pangolin — реляционная система управления базами данных. Она основана на свободно распространяемой версии PostgreSQL и содержит ряд доработок, обеспечивающих соответствие повышенным требованиям к безопасности данных, доступности, надежности, а также удобству эксплуатации. Наш продукт помогает получить функциональные возможности реляционной СУБД, включая построение кластеров высокой доступности, резервирование данных, снятие и восстановление резервных копий.

В январе мы выпустили новую версию — Platform V Pangolin 6.1. В ней появились обновления для работы с большим объёмом данных. Если вкратце — работать с секциями стало проще и быстрее: дешевле доступ к данным в секционированных таблицах, и для них можно гибко создавать уникальные глобальные индексы. Теперь можно предотвратить высокое потребление CPU и RAM пользовательской сессией, это улучшает доступность сервиса. Мы также добавили инструмент диагностики текущей активности для детального понимания процессов сессии, так работа СУБД становится более прозрачной.

В статье подробнее расскажу о каждой из доработок. Их можно условно разделить на две части: для пользователей и для администраторов/инфраструктуры.

Всем доброго дня!

Наша компания занимается разработкой ПО для госсектора и постоянно сертифицирует свои программы для обработки гос. тайны. А это накладывает определенные ограничения и самое главное из них: мы должны предоставить все исходные коды нашего проекта и если попросят суметь объяснить, что делает каждая строчка. Проблема в том, что если используешь готовые компоненты, то их исходники тоже нужно предоставлять и уметь все про них рассказать. Поэтому мы решили сделать свой фреймворк, ведь про него мы будем знать все. Фреймворк мы сделали и назвали его "Platform". Он продолжает развиваться и все свои проекты мы делаем на нем. Проблема заключается в том что, после выпуска продукта и его сдачи мы вынуждены его замораживать и не можем в него вносить больших изменений - только исправлять баги, а большинство багов обнаруживается как раз в самом фреймворке и в результате мы вынуждены иметь версии фреймворка для каждого сданного проекта (ну или для группы одновременно выпущенных продуктов). В итоге, нам пришлось придумать свой набор правил и схему ветвления в GIT для разработки Platform. Схема приведена ниже вместе с примером работы по ней:

Ну что, уже успели прочитать восхищения небывалым качеством видео от нейросетки SORA у всех блогеров и новостных изданий? А теперь мы вам расскажем то, о чем не написал никто: чего на самом деле пытается добиться OpenAI с помощью этой модели, как связана генерация видео с самоездящими машинами и AGI, а также при чем здесь культовая «Матрица».

Привет, Хабр! Я Владимир Хрыпун, руководитель центра компетенций по развитию BPM-систем в Первой грузовой компании. Сегодня разберем с вами, чем бизнес-аналитик отличается от системного и почему для проектов цифровой трансформации вам нужно два специалиста. Статья будет полезна менеджерам, продуктам, руководителям проекта. Всем кому надо объяснять, или кто сам хочет разобраться, в чем отличие бизнес и системных аналитиков. 

Часто всем участникам проекта хочется оптимизировать трудозатраты и бюджет. И очень светлая мысль, которая возникает у каждого второго продукта или РП: “А давайте у нас будет один аналитик, который сделает всё!”. У руководителей более высокого уровня, топов и собственников это идея возникает в 9 случаев из 10. В результате сроки сорваны, бюджет превысили в два раза. Почему так происходит и будет происходить разберем ниже. 

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

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

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

Привет! Меня зовут Михаил Черешнев, я работаю в компании Swordfish Security, где занимаюсь вопросами внедрения DevSecOps. Сегодня мы в команде много внимания уделяем направлению Software Supply Chain Security. Если заглянуть в Рунет, можно найти в нем немало статей, рассказывающих о проблемах в обеспечении безопасности цепочки поставок. Но о том, что с ними делать и какое решение применять, ничего нет. И в этой статье мы постарались восполнить этот пробел. Рассказываем все о Chainloop: верхнеуровневая архитектура, преимущества, то какие проблемы закрывает. Поехали!

Философия интеграции методов безопасности в процесс DevOps

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

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

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

В новом году продолжаю серию блицинтервью с контент-специалистами. Коллеги отвечают на 9 вопросов: как создают и продвигают контент в своих компаниях. Ирина Лазарева, редактор MAXMA.com, поделилась своих опытом в этом интервью.

Меня зовут Влад Мотрошилов. Я B2B-маркетолог, автор и редактор.

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

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

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

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

Привет! Меня зовут Андрей Гладилин, я работаю в Swordfish Security над составлением технической документации для ИТ-решений. Нравится нам это или нет, но она сопровождает каждый этап разработки и эксплуатации ПО. Работая над десятками и сотнями описаний ежедневно, я отметил ряд особенностей и сделал полезные выводы. И здесь постарался разобрать все ключевые аспекты, влияющие на качество технической документации, и дать практические рекомендации по его повышению. Этот материал поможет техническим писателям, менеджерам и разработчикам создать документацию, которая точно будет работать.

Сейчас набирает популярность относительно новый вид лидерства: secure base или «надёжная база». Этот подход в большей степени отражает контекст и потребности людей в вопросах построения карьеры и коммуникаций на работе. Во времена неопределенности важно, чтобы лидер мог воодушевить и поддержать команду, одновременно развивая потенциал людей и сосредотачивая на достижении KPI. Но как с учетом удалёнки и негативного внешнего контекста поддерживать доверительную атмосферу и создавать благоприятные условия для развития и роста? Или формировать в команде привычку делиться своими успехами и неудачами и работать сообща с другими командами?

Меня зовут Артём Каледин, я руководитель по анализу данных в команде геоаналитики в билайне. Эта статья написана по следам моего выступления на конференции Saint TeamLead Conf 2023. Я расскажу о новом типе лидерства — «надежной базе», формате, который помогает развиваться лидеру и растить сотрудников вокруг себя. В статье будет не только теория, но и мои примеры и идеи о лидерской роли и построении карьеры. Возможно, я смогу натолкнуть вас на размышления о дальнейшем развитии в лидерстве. 

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

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

Привет Хабр!

Меня зовут Альмира Фатихова, в Innostage я работаю техническим писателем и занимаюсь проектированием СЗИ. Как вы поняли, я та самая девушка в IT, которая смогла. Своей историей я не хочу в 100 500 раз поднимать вечные вопросы мужских и женских профессий. Но буду рада, если она вдохновит девчонок без лишних опасений и предубеждений пойти работать в IT‑сферу.

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