Идея этой статьи родилась во время задушевных разговоров на кухне и за утренним кофе с коллегами. Началось все с вопроса: «Что ты сказал бы себе прошлому, чтобы релизы стали легче, а спринты прекраснее?» Конечно, в тот момент я ничего дельного не ответил, но, кажется, наконец‑то сформулировал идеальную фразу: «Настоящий разработчик, Слав, это не тот, кто с сияющим макбуком и вкусным смузи. Разработчик — тот, кто делает то, что нужно сделать. И в легаси покопаться приходится, и memory leak дебажить, а он всё равно делает, потому что так надо».

Привет, Хабр! Меня зовут Вячеслав Чащухин, я — разработчик в МойОфис. Занимаюсь мобильной версией Squadus — цифрового рабочего пространства для совместной работы и деловых коммуникаций.

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

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

Трудно представить код современного React-приложения без таких функций как useState, useEffect, useRef и так далее.

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

Создание кастом-хуков это прекрасная возможность выделить часто переиспользуемый код в отдельные сущности.

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

Ниже мы рассмотрим примеры некоторых из них.  

Последние пару лет развитие языковых нейросетей как будто бы шло по принципу «больше, длиннее, жирнее»: разработчики пытались раздуть свои модели на как можно большее число параметров и прогнать через них максимальный объем тренировочных данных. 12 сентября OpenAI выпустили новую LLM, которая добавляет в это уравнение еще одно измерение для прокачки: теперь можно масштабировать объем «мыслей», который модель будет тратить в процессе своей работы. В этой статье мы разберемся, чему научилась новая GPT o1, и как это повлияет на дальнейшую эволюцию ИИ.

Привет! В этой заметке покажу, как можно использовать функцию inject на сто процентов.

Обычно ведь как: если функцией inject и пользуются, то только для того, чтобы заменить инжект через конструктор. Удобно, конечно. Но что, если я скажу, что это не всё, на что способна функция inject? Давайте посмотрим на паре примеров, как ещё её можно использовать.

Привет, Хабр! Меня зовут Сергей Соловьев, я разрабатываю интерфейсы международных платежей в Тинькофф Бизнесе. Уверен, многие хотят писать надежный, поддерживаемый, но при этом лаконичный код. Как найти баланс?

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

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

Продвинутая реализация Lodash функции get используя за основу базовую реализацию "Typed Get" type-challenge, а затем покрывая пограничные случаи: опциональные пути, массивы, кортежи. В самом конце типы добавляются к решению на JS.

Автор оригинала Скотт Чакон — сооснователь GitHub и основатель нового клиента GitButler. Этот клиент ставит во главу угла рабочий процесс и удобство разработки, в том числе код-ревью, и не является просто очередной обёрткой над CLI git.

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

• условной конфигурации;
• git blame и git log с диапазонами строк;
• git blame с отслеживанием;
• git diff по словам вместо строк;
• запоминании разрешения конфликтов.

Эта история началась в начале марта этого года. ChatGPT тогда был в самом расцвете. Мне в Telegram пришёл Саша Кукушкин, с которым мы знакомы довольно давно. Спросил, не занимаемся ли мы с Сашей Николичем языковыми моделями для русского языка, и как можно нам помочь.

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

После этого мы какое-то время продолжали какое-то время делать всё то же самое. Я потихоньку по инерции расширял rulm новыми наборами данных. Посчитав, что обучить базовую модель нам в ближайшее время не светит, мы решили сосредоточиться на дообучении на инструкциях и почти начали конвертировать то, что есть, в формат инструкций по аналогии с Flan. И тут меня угораздило внимательно перечитать статью.

Чтобы стать продуктивным разработчиком на Angular, потребуется понимание различных деревьев, из которых состоит приложение. На первый взгляд легко можно спутать дерево инжекторов DI и DOM-дерево непосредственных HTML-элементов и вьюх Angular. Они похожи и иногда имеют прямое соответствие, но далеко не всегда. В статье рассмотрим различия, научимся держать их в уме и освоим, как можно обойти возможные трудности, связанные с ними.

Мы в компании активно используем low-code платформы много лет. За время работы набрался опыт в преодолении проблем, связанных с этими платформами, и кристаллизовались подходы, которые хорошо себя показали.

В статье я разберу, что в low-code подходе помогает бизнесу, а что создаёт сложности. При рассмотрении проблем я предложу «лекарства», которые помогут вам нивелировать проблемы.

В конце статьи я составил чек-лист, по которому рекомендую проверять low-code платформу, прежде чем вы решитесь использовать её для решения своих бизнес-задач.

Статья состоит из шести разделов:

--- Обновление статьи 9 Августа 2023 ---

В течении последнего полугода в сфере текстовых нейронок всё кипит - после слитой в сеть модели Llama, aka "ChatGPT у себя на пекарне" люди ощутили, что никакой зацензуренный OpenAI по сути им и не нужен, а хорошие по мощности нейронки можно запускать локально.

Основная проблема в том, что всё это требует глубоких технических знаний.

Но в этой статье я расскажу, как запустить добротную нейросеть на домашнем ПК с 16ГБ ОЗУ в несколько кликов. Буквально в несколько кликов - копаться в консоли не придётся.

Интро: почему я написал эту статью

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

На своих серверах мы должны генерировать сотни миллионов уникальных страниц в сутки — это сложнее, чем просто отдавать одни и те же ресурсы. Генерация страницы не должна быть слишком требовательной к памяти сервера.

Разрабатывая проект на JavaScript (TypeScript, ClojureScript или каком-то другом языке, транслируемом в JavaScript), мы привыкли создавать объекты, массивы, строки и вообще писать код, как будто память бесконечна. Это не так. Я расскажу о видах проблем с памятью, о том, какие ограничения мы часто забываем и как их можно преодолеть. В ответ браузеры и пользователи скажут вам спасибо.

• Категории проблем с памятью
• Ограничения по памяти для разных типов данных
  　Heap
  　Buffer, TypedArray
  　String
  　Map, Set
  　Call stack
  　Типичные задачи, в которых можно наткнуться на ограничения по памяти
• Soft-утечки
  　Пример из продакшена
  　Как получаются soft-утечки
  　Как их обнаружить
  　Как найти причину
  　　1. Memory Allocation Timeline
  　　2. Техника трёх снапшотов
  　　3. queryObjects
  　　Тренируемся находить утечки
• Hard-утечки
  　Пример из продакшена
  　Как бороться
• Нестандартные оптимизации памяти в Node.js
  　Исходный код
  　Module._pathCache
  　Несколько версий пакета в node_modules
  　require('./data.json')
• Заключение

Плюсы микро-фронтенд архитектуры

• Автоматизация CI /CD. Поскольку каждое приложение интегрируется и развертывается независимо, это упрощает CI/CD. Так как все модули разделены, то не нужно беспокоиться обо всем приложении при внедрении нового модуля. Если в коде модуля есть ошибка, CI/CD прервет весь процесс сборки.
  Гибкость команд разработчиков. Многочисленные команды могут разрабатывать и развивать информационные системы, работая по отдельности.
• Единая ответственность. Каждая команда микро-фронтеда на 100% фокусируется на функциональности своего микро-фронтенд приложения.
• Возможность повторного использования. Микро-фронтенд приложение может быть повторно использовано несколькими командами в разных системах.
• Технологический агностицизм. Архитектура микро-фронтенд не зависит от технологии. Возможно использовать компоненты, разработанные на разных фреймворков веб-разработки (React, Vue, Angular и т.д.).
• Простой порог входа в систему. Небольшие модули легче изучать и понимать новым разработчикам, входящим в команды, чем монолитную архитектуру с огромной структурой кода.

Это перевод статьи, в которой Abdo Amin приводит 35 вопросов на собеседованиях JavaScript-разработчиков, которые он сам задает. К вопросам прилагаются и ответы.

Этим летом мы с Ромой запустили серию твитов с полезными советами и приемами по Angular. Сообщество тепло встретило эту инициативу, и я решил написать обобщающую статью.

Вот мои 5 рекомендаций, которыми хочется поделиться с разработчиками. Эти советы будут подкреплены конкретными примерами из моего твиттера. Они помогут вам поднять свои навыки или как минимум дадут пару практических приемов.

Алексей Миловидов делает ClickHouse и, конечно, знает его вдоль и поперек. В том числе и о том, как его можно использовать дополнительно к его штатным и всем хорошо известным функциям.

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

1. создать аккаунт в App Store для заказчика, если у заказчика его нет, или предложить
2. опубликовать приложение с нашего аккаунта;
3. подготовить маркетинговые материалы (иконка, скриншоты, текст, видео для предпросмотра приложения);
4. приложить к сборке сертификат цифровой подписи;
5. настроить оплату за пользование приложения;
6. Отправить сборку в App Store.