Все потоки

Решил я написать помощник миграции из Vue 2 (options-api) в Vue 3 (composition-api) с авторазделением на композиции с помощью алгоритма Косарайю по поиску областей сильной связности

Меня зовут Евгений Тупиков, я ведущий PHP-разработчик в Badoo и Bumble. У нас в команде более 200 бэкенд-разработчиков, которые работают над сотнями модулей и отдельных сервисов в наших приложениях. Но поначалу всё было не так масштабно. В 2006 году это был один проект, над которым работала небольшая команда. Каждый разработчик хорошо понимал, как всё устроено: легко ориентировался в коде, знал, какие есть сервисы и как они взаимодействуют между собой. Однако по мере роста проекта всё больше времени занимал поиск «хранителей знаний» — тех, кто отвечает за ту или иную функциональность и к кому можно обратиться с вопросом или предложением. 

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

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

Вы уже наверняка читали новость о самой большой утечке паролей в истории интернета и (мы надеемся) на всякий случай сменили пароли в своих основных аккаунтах. Однако данные пользователей далеко не в первый раз уплывают в сеть. Исследователи кибербезопасности из Agari решили проверить, как быстро хакеры попытаются получить доступ к скомпрометированным аккаунтам.

Все юристы работают с текстами. Читают, пишут, изучают, трактуют, убеждают в своих трактовках. Программисты — работают с текстами. Читают, пишут. Убеждают компилятор в своей правоте. Я — разработчик.

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

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

Некоторые любят ездить велосипедах, а некоторые любят их изобретать. Я отношусь к тем, кто изобретает велосипеды, чтобы на них ездить. Пару лет назад я уже писал на Хабр про этот свой "велосипед" - контейнер внедрения зависимостей (DI container) для JavaScript. Последующее обсуждение принципов работы DI-контейнеров и их отличие от "Локатора Сервисов" достаточно сильно продвинуло меня в понимании работы моего собственного "велосипеда" и вылилось не только в ряд статей на Хабре (раз, два, три, четыре), но и в значительной доработке самого "велосипеда".

Под катом - описание работы DI-контейнера (@teqfw/di) по состоянию на текущий момент. Ограничения: контейнер написан на чистом JavaScript (ES2015+), работает только с ES2015+ кодом, оформленным в ES-модули с расширением *.mjs . Преимущества: позволяет загружать и использовать одни и те же модули как в браузере, так и в nodejs-приложениях без дополнительной транспиляции.

В своей предыдущей статье я устраивал вопрос о том, стоит ли рассказывать о данном продукте от ПФР. Перевес оказался существенным, но я из-за смены должности, режима работы, отсутствия отпуска за 2019/2020 года и частых переездов по региону так и не написал данную заметку. Поэтому выполняю данное обещание и предлагаю на моём личном опыте понять, как у нас в России делаются подобные IT проекты и какими средствами.

Мы запустили блог на «Хабре» совсем недавно, и в комментариях к первой же статье было много вопросов о том, когда и как мы планируем устранять проблему с логином на сервисах AliExpress. И сегодня я расскажу, что вообще пошло не так, как мы чинили баг(и), с чем уже удалось справиться, а что будет улучшено в будущем.

Данная статья представляет личное мнение автора по теме необходимости техлидов в командах разработки.

Нужен ли TechLead? Как много вреда эта позиция принесет? Почему лучше отказаться от какого либо технического лидера в команде? Обсуждаем в статье и комментариях.

Первоначальное назначение ключевого слова inline состояло в том, чтобы служить индикатором для оптимизатора, что встроенная подстановка функции предпочтительнее вызова функции, то есть вместо выполнения команды CPU для передачи управления в тело функции, копия тела функции выполняется без генерирования вызова. Эта оптимизация (inline expansion) основана на идее, что выполнение вызова функции является относительно дорогостоящим: оно требует перехода к новой подпрограмме, передачи аргументов функции и копирования возвращаемых значений. Inline expansion подавляет вызов функции путем копирования инструкций функции непосредственно в тело вызывающего объекта.

Всем привет!

На сегодняшний день данные и всё связанное с ними (ML, AI, DataMining, etc) это самый хайповый тренд в IT-индустрии. Все - от ритейлеров до компаний Илона Маска работают (или пытаются работать) с данными. Нас в Леруа Мерлен эта волна не обошла стороной - data-driven подход к принятию решений является одним из основных в компании. Следуя ему, мы создали свою платформу данных, которой на данный момент пользуется около 2 тыс.человек, а в минуту обрабатывается примерно 1800 запросов. В этой статье мы (Data-команда Леруа Мерлен Россия) расскажем, как за 2 года построили платформу данных в компании с большим количеством оффлайн-процессов, об ее архитектуре и опыте, который мы получили в процессе создания.

Привет, Хабр! В этом обзоре я расскажу вам про 17-дюймовый игровой ноутбук ROG Strix G17 (модель G713QM), в котором установлена новая графика NVIDIA GeForce RTX 3050 Ti, представленная в мае 2021 года.

Портфельная теория Марковица(далее ПТМ) (Modern portfolio theory) — разработанная Гарри Марковицем методика формирования инвестиционного портфеля, направленная на оптимальный выбор активов, исходя из требуемого соотношения доходность/риск. Сформулированные им в 1950-х годах идеи составляют основу современной портфельной теории.

Основные положения портфельной теории были сформулированы Гарри Марковицем при подготовке им докторской диссертации в 1950—1951 годах.

Рождением же портфельной теории Марковица считается опубликованная в «Финансовом журнале» в 1952 году статья «Выбор портфеля». В ней он впервые предложил математическую модель формирования оптимального портфеля и привёл методы построения портфелей при определённых условиях. Основная заслуга Марковица состояла в предложении вероятностной формализации понятий «доходность» и «риск», что позволило перевести задачу выбора оптимального портфеля на формальный математический язык. Надо отметить, что в годы создания теории Марковиц работал в RAND Corp., вместе с одним из основателей линейной и нелинейной оптимизации — Джорджем Данцигом и сам участвовал в решении указанных задач. Поэтому собственная теория, после необходимой формализации, хорошо ложилась в указанное русло.

Представьте себе, что вы студент, изучающий современные фичи C++. И вам дали задачу по теме concepts/constraints. У преподавателя, конечно, есть референсное решение "как правильно", но для вас оно неочевидно, и вы навертели гору довольно запутанного кода, который всё равно не работает. (И вы дописываете и дописываете всё новые перегрузки и специализации шаблонов, покрывая всё новые и новые претензии компилятора).

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

Сперва преподаватель (то есть, я) минимизировал код вот до такого: https://gcc.godbolt.org/z/TaMTWqc1T

Недавно я решил немного привести в порядок несколько своих .NET pet-проектов на GitHub, настроить для них нормальный CI/CD через GitHub Actions и вынести всё в отдельный репозиторий, чтобы все скрипты лежали в одном месте. Для этого пришлось как следует изучить документацию, примеры и существующие GitHub Actions, выложенные в Marketplace.

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

Статья в первую очередь рассчитана на начинающих, тех, кто никогда не использовал GitHub Actions, но хотел бы быстро начать. Тем не менее, даже если у вас уже есть подобный опыт, но вы, например, не использовали ncc, то, возможно, и для вас в ней будет что-то полезное.

23 июня DINS проводит бесплатную онлайн-конференцию Java Meeting Point. Наша цель — объединить инженеров из разных городов на одной площадке, дать возможность обсудить новые технологии, подходы в разработке и все, что с этим связано. Спикеры конференции — инженеры крупных IT-компаний.    

Мы решили познакомить вас с людьми, которые выступают на конференции в серии интервью. Наш первый герой — Андрей Когунь, ведущий Java Meeting Point, руководитель группы Java-разработчиков в  «КРОК» и основатель jug.msk.ru. Андрей рассказал, почему его вдохновляют митапы, как он успевает совмещать работу и конференции и сложно ли управлять московским сообществом из Кипра.

Ключевой мотивацией для написания данной статьи является факт сильного недостатка информации (особенно в русскоязычном сообществе) по использованию cgo и Dart FFI для использования Go из языка Dart.

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

В случае если можно можно избежать экспорта go кода в Dart, то лучше воспользоваться такой возможностью, однако могут возникать случаи, когда использование уже написанного на go кода - является оптимальным решением (например вы уже знакомы с Go и Dart, и не хотите писать код на C, в таком случае есть смысл задуматься об использованием cgo и Dart FFI).

В данной статье на простом примере будет показано как можно повторно использовать код написанный на Go в языке Dart (например в приложениях на Flutter).

Что должно быть установлено: