Моя лента

• засилье KPI с последующей деградацией продукта, которое по менеджерской логике должно увеличивать DAU;
  
• деградация корпоративной культуры из-за офисных интриг и карьеризма;
  
• снижение продуктивности разработчиков из-за бесконечных совещаний, созвонов, отчётности и использования ПО для «повышения эффективности» (таск-трекеры, тайм-трекеры, календари и проч.);
  
• цифровое истощение и выгорание сотрудников.

Московский мировой суд оштрафовал мессенджер WhatsApp за отказ соблюдать правила деятельности в России. Об этом сообщает ТАСС со ссылкой на пресс‑службу Таганского суда Москвы.

Меня зовут Камиль Калимуллин, я — IT-предприниматель, основатель компании AdvantShop и крупнейшей региональной IT-конференции «Стачка».

Ежегодно на «Стачке» собирается более 3 000 специалистов — разработчики, маркетологи, дизайнеры, руководители и собственники IT-компаний. Более 50% аудитории конференции — специалисты с большим опытом решения технических задач и стажем работы 5-10 лет. И если для начинающих доступно множество ресурсов для роста: школы программирования, образовательные курсы и менторы, то что делать, если вы уже «крепкий миддл» или «опытный сеньор»?

В 2023 году с докладом «Как расти миддлу и сеньору» на конференции выступил Александр Сычев — руководитель мобильной разработки «Тинькофф Страхование» | KTS. Делюсь видео и основными тезисами выступления.

По умолчанию Google будет хранить переписку пользователей с чат-ботом Gemini в течение трёх лет, следует из документа поддержки сервиса для браузеров, Android и iOS. Разговоры с Gemini будут сохраняться вместе со «связанными данными», включая язык, устройства и местоположение.

VK выкупила 70% в юрлице ООО «Много приложений», которое принадлежит российскому разработчику цифровых решений red_mad_robot, обнаружил «Ъ» в ЕГРЮЛ.

Привет! На связи Тёма Логинов, шеф агентства контент-маркетинга. Делюсь приёмами, которые помогают реанимировать переписку с потенциальными клиентами

Чем ярче разгораются костры знания, тем больше тьмы открывается нашим изумлённым глазам
Теренс Маккена

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

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

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

В начале февраля 2024 года состоялся релиз системы для захвата, хранения и индексации сетевых пакетов Arkime 5.0. Проект предоставляет инструменты для наглядной оценки потоков трафика и поиска информации, связанной с сетевой активностью. Исходные коды Arkime опубликованы на GitHub под лицензией Apache 2.0.

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

Оба шифра оставались неразгаданными 75 лет. Скорее всего, виной тому оказался тот факт, что они находились в архивных хранилищах Калифорнийского технологического института, а не из-за их чрезвычайной сложности. Однако не стоит забывать, что в момент своего появления они не были вскрыты Ричардом Фейнманом, а после и его аспирантом Крисом Коулом. Разумеется, с тех пор криптоанализ существенно продвинулся и обзавёлся новыми возможностями автоматизации и вычислительными мощностями.

Здравствуйте, меня зовут Александр, я backend-разработчик. В данной публикации хочу поделиться опытом настройки мониторинга NATS JetStream. Рассказать для чего в принципе это может понадобиться. А также  привести пример необходимого стека сервисов поднятых в docker для мониторинга. В статье не рассматриваются настройки dashboards в Grafana, принципы и особенности работы NATS.

Может возникнуть вопрос для чего же требуется мониторинг, особенно для программного продукта, который в принципе является рабочим. Т.к. мониторинг не является бесплатным – для него требуется настройка и поддержание нескольких сервисов. Однако для оптимизации, добавления новых фич, требуется понимание того, как в реальности используется функционал приложения. И именно метрики могут нам в этом помочь. Метрика — эта численная мера, некоторого свойства или поведения программного обеспечения. В отличии от логов, метрики собирают не все детали, а только готовую выжимку: например, количество запросов к сервису.

В заключительной части исследования эксперты СайберОК сравнивают предоставление информации ASM-системами с точки зрения пользователя. Прочитать первую часть можно тут, а вторую тут.

Из новостей: Disney инвестирует 1,5 миллиарда долларов в Epic Games, вышел Stride 4.2, студия Evil Empire перестанет выпускать обновления Dead Cells.

Из интересностей: Solver2D и эксперименты, как симулировать различные типы песка в Houdini, разбираем по фреймам Syndicate, разработчик PlateUp делится рецептом успеха.

Российский производитель смартфонов, компьютеров, планшетов и другой электроники «Аквариус» начал разработку собственной мобильной операционной системы на основе открытого кода AOSP (Android Open Source Project), пишет «Ъ» со ссылкой на источник. По словам одного из собеседников издания, компания установит ОС на свои смартфоны и планшеты для продажи в государственном, корпоративном и потребительском сегменте.

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

При этом тестировать современный фронтенд сложно: неуправляемая асинхронность (событийная модель браузера), различие браузеров, тяжелое окружение — это лишь малая часть сложностей. Можно ли все возложить на ручных тестировщиков или исправлять баги после жалоб пользователей? Однозначно нет. В большинстве случаев такой подход в скором времени приведет к оттоку пользователей: не все пишут о багах, просто уходят к конкурентам. Безусловно, ручное тестирование остается важным элементом разработки, но тестировщики не могут держать сотни или тысячи сценариев, которые нужно пройти перед релизом или запуском новой фичи. Так где нам получить гарантии, что ключевые сценарии приложения работают корректно? Автоматическое тестирование.

Всем привет! Меня зовут Миша, работаю фронтэнд‑разработчиком в VK в команде Облака Mail.ru, и я хочу разобрать различные виды тестов, дать их сравнительный анализ и применимость. Сразу скажу, тут не будет практики написания тестов. Потому что это нереально сделать внутри одной статьи, необходимо разобрать: теорию тестирования, классов эквивалентности, различие подходов/методов к тестированию, комбинаторику состояний, правильное использование моков и стабов, понимание чистых функций, знание архитектуры приложения. Поэтому предлагаю сконцентрироваться на видах тестирования и начать с «идеального теста».

Я обучил небольшой (порядка 10 миллионов параметров) трансформер по превосходному туториалу Let’s build GPT: from scratch, in code, spelled out Андрея Карпати. После того, как он заработал, я захотел максимально глубоко понять, как он устроен внутри и как создаёт свои результаты.

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

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

Если вы знакомы с трансформерами и хотите сразу узнать вывод, то он таков: каждый блок трансформера (содержащий слой многоголового внимания и сеть с прямой связью) изучает веса, связывающие конкретный промт с классом строк, найденных в обучающем корпусе. Распределение токенов, соответствующее этим строкам в обучающем корпусе, и есть приблизительно то, что блок выводит как прогноз для следующего токена. Каждый блок может ассоциировать один и тот же промт со своим классом строк обучающего корпуса, что приводит к другому распределению следующих токенов, а значит, и к другим прогнозам. Окончательный результат работы трансформера — это линейное сочетание прогнозов каждого блока.

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

Подборка мероприятий на неделю.

Диффузионные методы генерации видео по тексту

• 14 февраля (среда)
• онлайн
• бесплатно
• Последние несколько лет можно назвать расцветом генеративных моделей, работающих в самых разных модальностях. Доклад будет посвящён одной из самых трудоёмких и сложных задач этого направления — синтезу видео по текстам на естественном языке (text-to-video), а также подходам к решению этой задачи на основе диффузии.
  В рамках доклада будут обсуждаться теоретические аспекты диффузионного процесса, его преимущества и недостатки. Также участники поговорят об архитектуре Kandinsky 3.0, особенностях обучения этой модели, нюансах сбора, фильтрации, хранения данных для обучения и полученных результатах.