#программирование — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #программирование, aggregated by home.social.
-
НЕкурс про разработку безопасного программного обеспечения (РБПО)
Мы подготовили раздел материалов, посвящённых разработке безопасного ПО (РБПО) по ГОСТ Р 56939—2024. Теперь эти материалы представлены в виде бесплатного онлайн-курса из 28 уроков. Такая структура поможет, во-первых, распределить нагрузку при знакомстве с теорией, а во-вторых, проверить свои знания.
https://habr.com/ru/companies/pvs-studio/articles/1040592/
#гост_р_56939 #гост_р_569392024 #рбпо #разработка_безопасного_по #курсы #курсывебинары #обучение #программирование #разработка_по #качество_по
-
НЕкурс про разработку безопасного программного обеспечения (РБПО)
Мы подготовили раздел материалов, посвящённых разработке безопасного ПО (РБПО) по ГОСТ Р 56939—2024. Теперь эти материалы представлены в виде бесплатного онлайн-курса из 28 уроков. Такая структура поможет, во-первых, распределить нагрузку при знакомстве с теорией, а во-вторых, проверить свои знания.
https://habr.com/ru/companies/pvs-studio/articles/1040592/
#гост_р_56939 #гост_р_569392024 #рбпо #разработка_безопасного_по #курсы #курсывебинары #обучение #программирование #разработка_по #качество_по
-
НЕкурс про разработку безопасного программного обеспечения (РБПО)
Мы подготовили раздел материалов, посвящённых разработке безопасного ПО (РБПО) по ГОСТ Р 56939—2024. Теперь эти материалы представлены в виде бесплатного онлайн-курса из 28 уроков. Такая структура поможет, во-первых, распределить нагрузку при знакомстве с теорией, а во-вторых, проверить свои знания.
https://habr.com/ru/companies/pvs-studio/articles/1040592/
#гост_р_56939 #гост_р_569392024 #рбпо #разработка_безопасного_по #курсы #курсывебинары #обучение #программирование #разработка_по #качество_по
-
НЕкурс про разработку безопасного программного обеспечения (РБПО)
Мы подготовили раздел материалов, посвящённых разработке безопасного ПО (РБПО) по ГОСТ Р 56939—2024. Теперь эти материалы представлены в виде бесплатного онлайн-курса из 28 уроков. Такая структура поможет, во-первых, распределить нагрузку при знакомстве с теорией, а во-вторых, проверить свои знания.
https://habr.com/ru/companies/pvs-studio/articles/1040592/
#гост_р_56939 #гост_р_569392024 #рбпо #разработка_безопасного_по #курсы #курсывебинары #обучение #программирование #разработка_по #качество_по
-
Ecommerce на Laravel, или как мы собрали headless-слой для фронтов (6 часть)
В этой части собираем headless-слой для фронтов: Gateway, композицию API, SDK, ETag, SSR, идемпотентность и единые правила работы с запросами. Привет, хабровчане. Это снова Алиса, снова Laravel, Bitrix и попытка не превратить фронтенд в распределенный монолит. К этому моменту у нас уже есть быстрые доменные сервисы: каталог, корзина, цены, заказы, интеграции. Но фронту от этого не сильно легче. Ему все еще приходится ходить в десяток ручек, собирать ответы, следить за авторизацией и одинаково обрабатывать ошибки. Поэтому поверх доменных сервисов появляется Headless API Gateway — тонкий слой, который работает как BFF для фронтов. Он берет на себя JWT-cookie, CORS, rate-limit, кэширование, единый формат ошибок и композицию сценариев вроде листинга, карточки товара или чекаута. При этом Gateway не дублирует бизнес-логику. Его задача — валидировать входящие запросы, сходить в нужные сервисы, собрать ответ и вернуть фронту компактный JSON с ETag и нормальными HTTP-заголовками. Дальше собираем это на Laravel: CORS, middleware для JWT-cookie, rate-limit, единый формат ошибок, композиционные ручки для фронтов, кэш-заголовки и роутинг через Nginx.
https://habr.com/ru/articles/1037728/
#headless #laravel #битрикс #программирование #вебразработа #gateway #api #sdk #идемпотентность #ssr
-
Ecommerce на Laravel, или как мы собрали headless-слой для фронтов (6 часть)
В этой части собираем headless-слой для фронтов: Gateway, композицию API, SDK, ETag, SSR, идемпотентность и единые правила работы с запросами. Привет, хабровчане. Это снова Алиса, снова Laravel, Bitrix и попытка не превратить фронтенд в распределенный монолит. К этому моменту у нас уже есть быстрые доменные сервисы: каталог, корзина, цены, заказы, интеграции. Но фронту от этого не сильно легче. Ему все еще приходится ходить в десяток ручек, собирать ответы, следить за авторизацией и одинаково обрабатывать ошибки. Поэтому поверх доменных сервисов появляется Headless API Gateway — тонкий слой, который работает как BFF для фронтов. Он берет на себя JWT-cookie, CORS, rate-limit, кэширование, единый формат ошибок и композицию сценариев вроде листинга, карточки товара или чекаута. При этом Gateway не дублирует бизнес-логику. Его задача — валидировать входящие запросы, сходить в нужные сервисы, собрать ответ и вернуть фронту компактный JSON с ETag и нормальными HTTP-заголовками. Дальше собираем это на Laravel: CORS, middleware для JWT-cookie, rate-limit, единый формат ошибок, композиционные ручки для фронтов, кэш-заголовки и роутинг через Nginx.
https://habr.com/ru/articles/1037728/
#headless #laravel #битрикс #программирование #вебразработа #gateway #api #sdk #идемпотентность #ssr
-
Ecommerce на Laravel, или как мы собрали headless-слой для фронтов (6 часть)
В этой части собираем headless-слой для фронтов: Gateway, композицию API, SDK, ETag, SSR, идемпотентность и единые правила работы с запросами. Привет, хабровчане. Это снова Алиса, снова Laravel, Bitrix и попытка не превратить фронтенд в распределенный монолит. К этому моменту у нас уже есть быстрые доменные сервисы: каталог, корзина, цены, заказы, интеграции. Но фронту от этого не сильно легче. Ему все еще приходится ходить в десяток ручек, собирать ответы, следить за авторизацией и одинаково обрабатывать ошибки. Поэтому поверх доменных сервисов появляется Headless API Gateway — тонкий слой, который работает как BFF для фронтов. Он берет на себя JWT-cookie, CORS, rate-limit, кэширование, единый формат ошибок и композицию сценариев вроде листинга, карточки товара или чекаута. При этом Gateway не дублирует бизнес-логику. Его задача — валидировать входящие запросы, сходить в нужные сервисы, собрать ответ и вернуть фронту компактный JSON с ETag и нормальными HTTP-заголовками. Дальше собираем это на Laravel: CORS, middleware для JWT-cookie, rate-limit, единый формат ошибок, композиционные ручки для фронтов, кэш-заголовки и роутинг через Nginx.
https://habr.com/ru/articles/1037728/
#headless #laravel #битрикс #программирование #вебразработа #gateway #api #sdk #идемпотентность #ssr
-
Ecommerce на Laravel, или как мы собрали headless-слой для фронтов (6 часть)
В этой части собираем headless-слой для фронтов: Gateway, композицию API, SDK, ETag, SSR, идемпотентность и единые правила работы с запросами. Привет, хабровчане. Это снова Алиса, снова Laravel, Bitrix и попытка не превратить фронтенд в распределенный монолит. К этому моменту у нас уже есть быстрые доменные сервисы: каталог, корзина, цены, заказы, интеграции. Но фронту от этого не сильно легче. Ему все еще приходится ходить в десяток ручек, собирать ответы, следить за авторизацией и одинаково обрабатывать ошибки. Поэтому поверх доменных сервисов появляется Headless API Gateway — тонкий слой, который работает как BFF для фронтов. Он берет на себя JWT-cookie, CORS, rate-limit, кэширование, единый формат ошибок и композицию сценариев вроде листинга, карточки товара или чекаута. При этом Gateway не дублирует бизнес-логику. Его задача — валидировать входящие запросы, сходить в нужные сервисы, собрать ответ и вернуть фронту компактный JSON с ETag и нормальными HTTP-заголовками. Дальше собираем это на Laravel: CORS, middleware для JWT-cookie, rate-limit, единый формат ошибок, композиционные ручки для фронтов, кэш-заголовки и роутинг через Nginx.
https://habr.com/ru/articles/1037728/
#headless #laravel #битрикс #программирование #вебразработа #gateway #api #sdk #идемпотентность #ssr
-
Современный Angular: Заменяем жизненные циклы на сигналы
Если вы пишете на Angular, то наверняка часто используете хуки жизненного цикла вроде ngOnChanges , ngOnInit и ngOnDestroy . С появлением сигналов и концепции Zoneless (когда Zone.js уже не обязателен) у нас появились более элегантные и читаемые альтернативы. Давайте разберем, как современный подход позволяет упростить код и избавиться от "шумных" методов жизненного цикла.
https://habr.com/ru/articles/1040488/
#angular #javascript #typescript #signal #hooks #rxjs #программирование #вебразработа
-
Современный Angular: Заменяем жизненные циклы на сигналы
Если вы пишете на Angular, то наверняка часто используете хуки жизненного цикла вроде ngOnChanges , ngOnInit и ngOnDestroy . С появлением сигналов и концепции Zoneless (когда Zone.js уже не обязателен) у нас появились более элегантные и читаемые альтернативы. Давайте разберем, как современный подход позволяет упростить код и избавиться от "шумных" методов жизненного цикла.
https://habr.com/ru/articles/1040488/
#angular #javascript #typescript #signal #hooks #rxjs #программирование #вебразработа
-
Современный Angular: Заменяем жизненные циклы на сигналы
Если вы пишете на Angular, то наверняка часто используете хуки жизненного цикла вроде ngOnChanges , ngOnInit и ngOnDestroy . С появлением сигналов и концепции Zoneless (когда Zone.js уже не обязателен) у нас появились более элегантные и читаемые альтернативы. Давайте разберем, как современный подход позволяет упростить код и избавиться от "шумных" методов жизненного цикла.
https://habr.com/ru/articles/1040488/
#angular #javascript #typescript #signal #hooks #rxjs #программирование #вебразработа
-
Современный Angular: Заменяем жизненные циклы на сигналы
Если вы пишете на Angular, то наверняка часто используете хуки жизненного цикла вроде ngOnChanges , ngOnInit и ngOnDestroy . С появлением сигналов и концепции Zoneless (когда Zone.js уже не обязателен) у нас появились более элегантные и читаемые альтернативы. Давайте разберем, как современный подход позволяет упростить код и избавиться от "шумных" методов жизненного цикла.
https://habr.com/ru/articles/1040488/
#angular #javascript #typescript #signal #hooks #rxjs #программирование #вебразработа
-
Почему советские программисты не сделали GTA
Алексей Пажитнов написал «Тетрис» в 1984 году на «Электронике-60», работая в Вычислительном центре АН СССР, и эта игра до сих пор входит в любой список «самых влиятельных видеоигр всех времён». В том же 1984 году в США уже четвёртый год подряд продавался Pac-Man, а в Японии Nintendo готовилась к экспорту NES. В том же году два британских студента на ZX Spectrum написали Elite с процедурной генерацией восьми галактик в 22 килобайтах памяти. К 1991 году СССР закончился. «Тетрис» стал собственностью Nintendo через цепочку посредников, и никаких других советских игр мирового уровня за следующие десять лет так и не появилось, хотя отдельные студии делали хорошие проекты, я буду считать 90-е наследием советов. А вот вопрос, который мне кажется куда интереснее, чем «почему так получилось»: почему в одно и то же время одна и та же страна могла спроектировать систему наведения «Бурана» с автоматической посадкой по радиомаякам, но не могла сделать массовый игровой автомат уровня Space Invaders? В ответ часто слышал «не было рынка, не было капитализма, не было конкуренции». Я в это не верю. Не верю, потому что отсутствие рынка не мешало тем же людям спроектировать «Энергию-Буран», Ту-160 и атомный ледокол «Арктика». А вот качественный массовый телевизор «Рубин» в той же стране делать почему-то не получалось. И качественную массовую игру тоже. Не надо быть матёрым геймдизайнером и знать, что такое ECS и GOAP, достаточно понимать, что игра - это продукт, который собирается из кода, графики, звука, геймдизайна и тестирования, и что каждая из этих веток требует отдельных людей с отдельной экспертизой. Дальше будет немного арифметики и исторических примеров.
-
Почему советские программисты не сделали GTA
Алексей Пажитнов написал «Тетрис» в 1984 году на «Электронике-60», работая в Вычислительном центре АН СССР, и эта игра до сих пор входит в любой список «самых влиятельных видеоигр всех времён». В том же 1984 году в США уже четвёртый год подряд продавался Pac-Man, а в Японии Nintendo готовилась к экспорту NES. В том же году два британских студента на ZX Spectrum написали Elite с процедурной генерацией восьми галактик в 22 килобайтах памяти. К 1991 году СССР закончился. «Тетрис» стал собственностью Nintendo через цепочку посредников, и никаких других советских игр мирового уровня за следующие десять лет так и не появилось, хотя отдельные студии делали хорошие проекты, я буду считать 90-е наследием советов. А вот вопрос, который мне кажется куда интереснее, чем «почему так получилось»: почему в одно и то же время одна и та же страна могла спроектировать систему наведения «Бурана» с автоматической посадкой по радиомаякам, но не могла сделать массовый игровой автомат уровня Space Invaders? В ответ часто слышал «не было рынка, не было капитализма, не было конкуренции». Я в это не верю. Не верю, потому что отсутствие рынка не мешало тем же людям спроектировать «Энергию-Буран», Ту-160 и атомный ледокол «Арктика». А вот качественный массовый телевизор «Рубин» в той же стране делать почему-то не получалось. И качественную массовую игру тоже. Не надо быть матёрым геймдизайнером и знать, что такое ECS и GOAP, достаточно понимать, что игра - это продукт, который собирается из кода, графики, звука, геймдизайна и тестирования, и что каждая из этих веток требует отдельных людей с отдельной экспертизой. Дальше будет немного арифметики и исторических примеров.
-
Почему советские программисты не сделали GTA
Алексей Пажитнов написал «Тетрис» в 1984 году на «Электронике-60», работая в Вычислительном центре АН СССР, и эта игра до сих пор входит в любой список «самых влиятельных видеоигр всех времён». В том же 1984 году в США уже четвёртый год подряд продавался Pac-Man, а в Японии Nintendo готовилась к экспорту NES. В том же году два британских студента на ZX Spectrum написали Elite с процедурной генерацией восьми галактик в 22 килобайтах памяти. К 1991 году СССР закончился. «Тетрис» стал собственностью Nintendo через цепочку посредников, и никаких других советских игр мирового уровня за следующие десять лет так и не появилось, хотя отдельные студии делали хорошие проекты, я буду считать 90-е наследием советов. А вот вопрос, который мне кажется куда интереснее, чем «почему так получилось»: почему в одно и то же время одна и та же страна могла спроектировать систему наведения «Бурана» с автоматической посадкой по радиомаякам, но не могла сделать массовый игровой автомат уровня Space Invaders? В ответ часто слышал «не было рынка, не было капитализма, не было конкуренции». Я в это не верю. Не верю, потому что отсутствие рынка не мешало тем же людям спроектировать «Энергию-Буран», Ту-160 и атомный ледокол «Арктика». А вот качественный массовый телевизор «Рубин» в той же стране делать почему-то не получалось. И качественную массовую игру тоже. Не надо быть матёрым геймдизайнером и знать, что такое ECS и GOAP, достаточно понимать, что игра - это продукт, который собирается из кода, графики, звука, геймдизайна и тестирования, и что каждая из этих веток требует отдельных людей с отдельной экспертизой. Дальше будет немного арифметики и исторических примеров.
-
Почему советские программисты не сделали GTA
Алексей Пажитнов написал «Тетрис» в 1984 году на «Электронике-60», работая в Вычислительном центре АН СССР, и эта игра до сих пор входит в любой список «самых влиятельных видеоигр всех времён». В том же 1984 году в США уже четвёртый год подряд продавался Pac-Man, а в Японии Nintendo готовилась к экспорту NES. В том же году два британских студента на ZX Spectrum написали Elite с процедурной генерацией восьми галактик в 22 килобайтах памяти. К 1991 году СССР закончился. «Тетрис» стал собственностью Nintendo через цепочку посредников, и никаких других советских игр мирового уровня за следующие десять лет так и не появилось, хотя отдельные студии делали хорошие проекты, я буду считать 90-е наследием советов. А вот вопрос, который мне кажется куда интереснее, чем «почему так получилось»: почему в одно и то же время одна и та же страна могла спроектировать систему наведения «Бурана» с автоматической посадкой по радиомаякам, но не могла сделать массовый игровой автомат уровня Space Invaders? В ответ часто слышал «не было рынка, не было капитализма, не было конкуренции». Я в это не верю. Не верю, потому что отсутствие рынка не мешало тем же людям спроектировать «Энергию-Буран», Ту-160 и атомный ледокол «Арктика». А вот качественный массовый телевизор «Рубин» в той же стране делать почему-то не получалось. И качественную массовую игру тоже. Не надо быть матёрым геймдизайнером и знать, что такое ECS и GOAP, достаточно понимать, что игра - это продукт, который собирается из кода, графики, звука, геймдизайна и тестирования, и что каждая из этих веток требует отдельных людей с отдельной экспертизой. Дальше будет немного арифметики и исторических примеров.
-
Кодировка: почему « ё » оказалось не моё?
Решили с товарищем собрать систему, которая будет фотографировать деталь, анализировать и выводить сообщение — есть там в отверстии резьба или нет. Товарищ далеко от меня живет, работу разделили — мне аппаратная часть, ему программная.
-
Кодировка: почему « ё » оказалось не моё?
Решили с товарищем собрать систему, которая будет фотографировать деталь, анализировать и выводить сообщение — есть там в отверстии резьба или нет. Товарищ далеко от меня живет, работу разделили — мне аппаратная часть, ему программная.
-
Кодировка: почему « ё » оказалось не моё?
Решили с товарищем собрать систему, которая будет фотографировать деталь, анализировать и выводить сообщение — есть там в отверстии резьба или нет. Товарищ далеко от меня живет, работу разделили — мне аппаратная часть, ему программная.
-
Кодировка: почему « ё » оказалось не моё?
Решили с товарищем собрать систему, которая будет фотографировать деталь, анализировать и выводить сообщение — есть там в отверстии резьба или нет. Товарищ далеко от меня живет, работу разделили — мне аппаратная часть, ему программная.
-
Знания без практики — мертвы | Разница между «декларативной» и «процедурной» памятью у LLM
О том, что для нас есть большая разница между «заучить материал» и «натренировать мышечную память = обзавестись навыком» знают все. Каждый проходил это, ощущал это. В этой статье я подниму вопрос, почему вайб-кодинг буксует, что же мир и ИИ-сообщество делает не так. Я покажу, в каких компонентах LLM запрятана та самая декларативная и процедурная память. Да - она есть в LLM, и в конце статьи есть ссылки на общеизвестные исследования, которые это эмпирически подтверждают. И да, тут есть что-то полезное «на подумать». Я предложу путь / алгоритм, как собрать нужный датасет и научить LLM не просто «воспроизводить программный код», а привить навык «разработки программного обеспечения», хотя бы в базовом виде.
https://habr.com/ru/articles/1039936/
#llm #программирование #обучение_с_подкреплением #rlhf #git #дрессировка
-
Знания без практики — мертвы | Разница между «декларативной» и «процедурной» памятью у LLM
О том, что для нас есть большая разница между «заучить материал» и «натренировать мышечную память = обзавестись навыком» знают все. Каждый проходил это, ощущал это. В этой статье я подниму вопрос, почему вайб-кодинг буксует, что же мир и ИИ-сообщество делает не так. Я покажу, в каких компонентах LLM запрятана та самая декларативная и процедурная память. Да - она есть в LLM, и в конце статьи есть ссылки на общеизвестные исследования, которые это эмпирически подтверждают. И да, тут есть что-то полезное «на подумать». Я предложу путь / алгоритм, как собрать нужный датасет и научить LLM не просто «воспроизводить программный код», а привить навык «разработки программного обеспечения», хотя бы в базовом виде.
https://habr.com/ru/articles/1039936/
#llm #программирование #обучение_с_подкреплением #rlhf #git #дрессировка
-
Знания без практики — мертвы | Разница между «декларативной» и «процедурной» памятью у LLM
О том, что для нас есть большая разница между «заучить материал» и «натренировать мышечную память = обзавестись навыком» знают все. Каждый проходил это, ощущал это. В этой статье я подниму вопрос, почему вайб-кодинг буксует, что же мир и ИИ-сообщество делает не так. Я покажу, в каких компонентах LLM запрятана та самая декларативная и процедурная память. Да - она есть в LLM, и в конце статьи есть ссылки на общеизвестные исследования, которые это эмпирически подтверждают. И да, тут есть что-то полезное «на подумать». Я предложу путь / алгоритм, как собрать нужный датасет и научить LLM не просто «воспроизводить программный код», а привить навык «разработки программного обеспечения», хотя бы в базовом виде.
https://habr.com/ru/articles/1039936/
#llm #программирование #обучение_с_подкреплением #rlhf #git #дрессировка
-
Знания без практики — мертвы | Разница между «декларативной» и «процедурной» памятью у LLM
О том, что для нас есть большая разница между «заучить материал» и «натренировать мышечную память = обзавестись навыком» знают все. Каждый проходил это, ощущал это. В этой статье я подниму вопрос, почему вайб-кодинг буксует, что же мир и ИИ-сообщество делает не так. Я покажу, в каких компонентах LLM запрятана та самая декларативная и процедурная память. Да - она есть в LLM, и в конце статьи есть ссылки на общеизвестные исследования, которые это эмпирически подтверждают. И да, тут есть что-то полезное «на подумать». Я предложу путь / алгоритм, как собрать нужный датасет и научить LLM не просто «воспроизводить программный код», а привить навык «разработки программного обеспечения», хотя бы в базовом виде.
https://habr.com/ru/articles/1039936/
#llm #программирование #обучение_с_подкреплением #rlhf #git #дрессировка
-
Разработка эмулятора NES на отечественном микроконтроллере К1921ВГ1Т
Привет, Хабр! Сегодня мы поговорим о реализации базовой версии эмулятора консоли NES на отечественном микроконтроллере К1921ВГ1Т и даже поиграем на нём в игры. Съесть гриб и вырасти
-
Разработка эмулятора NES на отечественном микроконтроллере К1921ВГ1Т
Привет, Хабр! Сегодня мы поговорим о реализации базовой версии эмулятора консоли NES на отечественном микроконтроллере К1921ВГ1Т и даже поиграем на нём в игры. Съесть гриб и вырасти
-
Разработка эмулятора NES на отечественном микроконтроллере К1921ВГ1Т
Привет, Хабр! Сегодня мы поговорим о реализации базовой версии эмулятора консоли NES на отечественном микроконтроллере К1921ВГ1Т и даже поиграем на нём в игры. Съесть гриб и вырасти
-
Разработка эмулятора NES на отечественном микроконтроллере К1921ВГ1Т
Привет, Хабр! Сегодня мы поговорим о реализации базовой версии эмулятора консоли NES на отечественном микроконтроллере К1921ВГ1Т и даже поиграем на нём в игры. Съесть гриб и вырасти
-
После ИИ писать код руками ощущается уже не как норма
TL;DR: ИИ не заменяет инженерный контроль, но меняет базовую планку разработки. С ним проще удерживать скоуп, тесты, техническое качество и в режиме дедлайна. Главный риск - потерять ownership, поэтому уровень автономности должен зависеть от проекта, стадии и зрелости инженерного процесса. У меня есть один личный проект , где я полностью автоматизировал разработку и перестал читать код. Всё идёт практически без моего участия: я просто описываю в телеграмме своему боту что нужно сделать, что я хочу получить, а он выполняет, проверяет в цикле, коммитит, деплоит и сам проверяет логи. Единственное, заниматься своим проектом времени мало, потому движение всё равно медленное и хоть бот может сам брать тикеты из гитхаба и выполнять их, я всё же не разрешаю ему пушить код - хочу всё же в конце понимать что он сделал. Но проект я изначально писал сам, и только потом начал изучать как сделать работу автономной. Всё работает настолько хорошо, что я даже задумался: а не запустить ли новый проект вообще без моего участия? Описать только PRD, проверить сгенерированную документацию и список задач, а на выходе просто принимать готовые фичи. Я даже пробовал запускать так несколько личных проектов (один из них - простенькая игра): формировал всю документацию через ИИ, но на определенных этапах допускал ошибки в планировании и в итоге терял контроль.
https://habr.com/ru/articles/1039836/
#ИИ #разработка #программирование #AI_coding #code_review #тестирование #productivity #ownership #разработка_ПО #инженерный_контроль
-
После ИИ писать код руками ощущается уже не как норма
TL;DR: ИИ не заменяет инженерный контроль, но меняет базовую планку разработки. С ним проще удерживать скоуп, тесты, техническое качество и в режиме дедлайна. Главный риск - потерять ownership, поэтому уровень автономности должен зависеть от проекта, стадии и зрелости инженерного процесса. У меня есть один личный проект , где я полностью автоматизировал разработку и перестал читать код. Всё идёт практически без моего участия: я просто описываю в телеграмме своему боту что нужно сделать, что я хочу получить, а он выполняет, проверяет в цикле, коммитит, деплоит и сам проверяет логи. Единственное, заниматься своим проектом времени мало, потому движение всё равно медленное и хоть бот может сам брать тикеты из гитхаба и выполнять их, я всё же не разрешаю ему пушить код - хочу всё же в конце понимать что он сделал. Но проект я изначально писал сам, и только потом начал изучать как сделать работу автономной. Всё работает настолько хорошо, что я даже задумался: а не запустить ли новый проект вообще без моего участия? Описать только PRD, проверить сгенерированную документацию и список задач, а на выходе просто принимать готовые фичи. Я даже пробовал запускать так несколько личных проектов (один из них - простенькая игра): формировал всю документацию через ИИ, но на определенных этапах допускал ошибки в планировании и в итоге терял контроль.
https://habr.com/ru/articles/1039836/
#ИИ #разработка #программирование #AI_coding #code_review #тестирование #productivity #ownership #разработка_ПО #инженерный_контроль
-
После ИИ писать код руками ощущается уже не как норма
TL;DR: ИИ не заменяет инженерный контроль, но меняет базовую планку разработки. С ним проще удерживать скоуп, тесты, техническое качество и в режиме дедлайна. Главный риск - потерять ownership, поэтому уровень автономности должен зависеть от проекта, стадии и зрелости инженерного процесса. У меня есть один личный проект , где я полностью автоматизировал разработку и перестал читать код. Всё идёт практически без моего участия: я просто описываю в телеграмме своему боту что нужно сделать, что я хочу получить, а он выполняет, проверяет в цикле, коммитит, деплоит и сам проверяет логи. Единственное, заниматься своим проектом времени мало, потому движение всё равно медленное и хоть бот может сам брать тикеты из гитхаба и выполнять их, я всё же не разрешаю ему пушить код - хочу всё же в конце понимать что он сделал. Но проект я изначально писал сам, и только потом начал изучать как сделать работу автономной. Всё работает настолько хорошо, что я даже задумался: а не запустить ли новый проект вообще без моего участия? Описать только PRD, проверить сгенерированную документацию и список задач, а на выходе просто принимать готовые фичи. Я даже пробовал запускать так несколько личных проектов (один из них - простенькая игра): формировал всю документацию через ИИ, но на определенных этапах допускал ошибки в планировании и в итоге терял контроль.
https://habr.com/ru/articles/1039836/
#ИИ #разработка #программирование #AI_coding #code_review #тестирование #productivity #ownership #разработка_ПО #инженерный_контроль
-
После ИИ писать код руками ощущается уже не как норма
TL;DR: ИИ не заменяет инженерный контроль, но меняет базовую планку разработки. С ним проще удерживать скоуп, тесты, техническое качество и в режиме дедлайна. Главный риск - потерять ownership, поэтому уровень автономности должен зависеть от проекта, стадии и зрелости инженерного процесса. У меня есть один личный проект , где я полностью автоматизировал разработку и перестал читать код. Всё идёт практически без моего участия: я просто описываю в телеграмме своему боту что нужно сделать, что я хочу получить, а он выполняет, проверяет в цикле, коммитит, деплоит и сам проверяет логи. Единственное, заниматься своим проектом времени мало, потому движение всё равно медленное и хоть бот может сам брать тикеты из гитхаба и выполнять их, я всё же не разрешаю ему пушить код - хочу всё же в конце понимать что он сделал. Но проект я изначально писал сам, и только потом начал изучать как сделать работу автономной. Всё работает настолько хорошо, что я даже задумался: а не запустить ли новый проект вообще без моего участия? Описать только PRD, проверить сгенерированную документацию и список задач, а на выходе просто принимать готовые фичи. Я даже пробовал запускать так несколько личных проектов (один из них - простенькая игра): формировал всю документацию через ИИ, но на определенных этапах допускал ошибки в планировании и в итоге терял контроль.
https://habr.com/ru/articles/1039836/
#ИИ #разработка #программирование #AI_coding #code_review #тестирование #productivity #ownership #разработка_ПО #инженерный_контроль
-
Менеджер ресурсов
В прошлой статье я разбирал паттерны и необходимость компромиссов в реальной разработке, и там была одна мысль которую я намеренно оставил в стороне. Паттерны редко живут в одиночку, и любая реальная система это не один паттерн, а несколько, склеенных, скрученые, слепленных, и местами прибитых сбоку гвоздями, и каждый из них закрывает только часть проблемы. Менеджер ресурсов это, наверное, самый показательный пример такой склейки, потому что снаружи он обычно выглядит как пару строчек вида LoadTexture(" bark.dds ") , а внутри это кэш, политика дефолтов, механика восстановления после сбоя и ещё полдюжины вещей, каждая из которых прошла через пот, кровь и пиксели и осталась в архитектуре этой системы. Если открыть любую книгу по разработке игр или игрового движка и попробовать найти определение "игровой ресурс", то получится что ресурс - это набор данных, которые были загружены или созданы с конкретными параметрами. Любые уточнения вроде «текстура», «меш», «звук» или «шейдер» здесь уже будут лишними, потому что нам важна не природа данных, а что они существуют именно определенной форме. Понятие "определенная форма" тем не менее тоже звучит абстрактно, поэтому люди предпочитают использовать "текстуру", "меш", "звук" и т.д. Но одну и ту же текстуру wall.dds , которую можно загрузить в DXT5 со сжатием, sRGB и mip-фильтром box, а можно без сжатия, в линейном пространстве и с другим фильтром. Формально у нас был один файл на диске, но с точки зрения ресурсного менеджера теперь это два разных "ресурса", потому что их параметры различаются. Подмена одного ресурса другим в рантайме может сломать игру, потому что игра ожидает определенных данных для шейдера, которая изменилась после фильтра или определённую раскладку мипов, которой может не оказаться. Более явный пример для шейдеров будет, когда lighting.fx , скомпилированный с дефайном SIMPLE_BUMP_MAPPING , и lighting.fx , скомпилированный с PARALLAX_BUMP_MAPPING , физически выглядят в исходниках как один файл, но дают два разных пайплайна, со своими константными буферами и со своими ожиданиями к набору текстур, а если ресурсный менеджер этого не понимает, то он либо начнёт раздавать второй вариант, когда просят первый. С мешами история та же самая, и ship.mesh , загруженный в менеджере ресурсов, и тот же ship.mesh , лежащий в GPU это два разных объекта, у которых даже время жизни и поведение при потере устройства будут отличаться, не говоря уже о том, что первый мы можем менять, а в второй нет. Грузись текстурка, большая и маленькая
https://habr.com/ru/articles/1039266/
#с++ #программирование #разработка_игр #игры_и_игровые_консоли
-
Менеджер ресурсов
В прошлой статье я разбирал паттерны и необходимость компромиссов в реальной разработке, и там была одна мысль которую я намеренно оставил в стороне. Паттерны редко живут в одиночку, и любая реальная система это не один паттерн, а несколько, склеенных, скрученые, слепленных, и местами прибитых сбоку гвоздями, и каждый из них закрывает только часть проблемы. Менеджер ресурсов это, наверное, самый показательный пример такой склейки, потому что снаружи он обычно выглядит как пару строчек вида LoadTexture(" bark.dds ") , а внутри это кэш, политика дефолтов, механика восстановления после сбоя и ещё полдюжины вещей, каждая из которых прошла через пот, кровь и пиксели и осталась в архитектуре этой системы. Если открыть любую книгу по разработке игр или игрового движка и попробовать найти определение "игровой ресурс", то получится что ресурс - это набор данных, которые были загружены или созданы с конкретными параметрами. Любые уточнения вроде «текстура», «меш», «звук» или «шейдер» здесь уже будут лишними, потому что нам важна не природа данных, а что они существуют именно определенной форме. Понятие "определенная форма" тем не менее тоже звучит абстрактно, поэтому люди предпочитают использовать "текстуру", "меш", "звук" и т.д. Но одну и ту же текстуру wall.dds , которую можно загрузить в DXT5 со сжатием, sRGB и mip-фильтром box, а можно без сжатия, в линейном пространстве и с другим фильтром. Формально у нас был один файл на диске, но с точки зрения ресурсного менеджера теперь это два разных "ресурса", потому что их параметры различаются. Подмена одного ресурса другим в рантайме может сломать игру, потому что игра ожидает определенных данных для шейдера, которая изменилась после фильтра или определённую раскладку мипов, которой может не оказаться. Более явный пример для шейдеров будет, когда lighting.fx , скомпилированный с дефайном SIMPLE_BUMP_MAPPING , и lighting.fx , скомпилированный с PARALLAX_BUMP_MAPPING , физически выглядят в исходниках как один файл, но дают два разных пайплайна, со своими константными буферами и со своими ожиданиями к набору текстур, а если ресурсный менеджер этого не понимает, то он либо начнёт раздавать второй вариант, когда просят первый. С мешами история та же самая, и ship.mesh , загруженный в менеджере ресурсов, и тот же ship.mesh , лежащий в GPU это два разных объекта, у которых даже время жизни и поведение при потере устройства будут отличаться, не говоря уже о том, что первый мы можем менять, а в второй нет. Грузись текстурка, большая и маленькая
https://habr.com/ru/articles/1039266/
#с++ #программирование #разработка_игр #игры_и_игровые_консоли
-
Менеджер ресурсов
В прошлой статье я разбирал паттерны и необходимость компромиссов в реальной разработке, и там была одна мысль которую я намеренно оставил в стороне. Паттерны редко живут в одиночку, и любая реальная система это не один паттерн, а несколько, склеенных, скрученые, слепленных, и местами прибитых сбоку гвоздями, и каждый из них закрывает только часть проблемы. Менеджер ресурсов это, наверное, самый показательный пример такой склейки, потому что снаружи он обычно выглядит как пару строчек вида LoadTexture(" bark.dds ") , а внутри это кэш, политика дефолтов, механика восстановления после сбоя и ещё полдюжины вещей, каждая из которых прошла через пот, кровь и пиксели и осталась в архитектуре этой системы. Если открыть любую книгу по разработке игр или игрового движка и попробовать найти определение "игровой ресурс", то получится что ресурс - это набор данных, которые были загружены или созданы с конкретными параметрами. Любые уточнения вроде «текстура», «меш», «звук» или «шейдер» здесь уже будут лишними, потому что нам важна не природа данных, а что они существуют именно определенной форме. Понятие "определенная форма" тем не менее тоже звучит абстрактно, поэтому люди предпочитают использовать "текстуру", "меш", "звук" и т.д. Но одну и ту же текстуру wall.dds , которую можно загрузить в DXT5 со сжатием, sRGB и mip-фильтром box, а можно без сжатия, в линейном пространстве и с другим фильтром. Формально у нас был один файл на диске, но с точки зрения ресурсного менеджера теперь это два разных "ресурса", потому что их параметры различаются. Подмена одного ресурса другим в рантайме может сломать игру, потому что игра ожидает определенных данных для шейдера, которая изменилась после фильтра или определённую раскладку мипов, которой может не оказаться. Более явный пример для шейдеров будет, когда lighting.fx , скомпилированный с дефайном SIMPLE_BUMP_MAPPING , и lighting.fx , скомпилированный с PARALLAX_BUMP_MAPPING , физически выглядят в исходниках как один файл, но дают два разных пайплайна, со своими константными буферами и со своими ожиданиями к набору текстур, а если ресурсный менеджер этого не понимает, то он либо начнёт раздавать второй вариант, когда просят первый. С мешами история та же самая, и ship.mesh , загруженный в менеджере ресурсов, и тот же ship.mesh , лежащий в GPU это два разных объекта, у которых даже время жизни и поведение при потере устройства будут отличаться, не говоря уже о том, что первый мы можем менять, а в второй нет. Грузись текстурка, большая и маленькая
https://habr.com/ru/articles/1039266/
#с++ #программирование #разработка_игр #игры_и_игровые_консоли
-
Менеджер ресурсов
В прошлой статье я разбирал паттерны и необходимость компромиссов в реальной разработке, и там была одна мысль которую я намеренно оставил в стороне. Паттерны редко живут в одиночку, и любая реальная система это не один паттерн, а несколько, склеенных, скрученые, слепленных, и местами прибитых сбоку гвоздями, и каждый из них закрывает только часть проблемы. Менеджер ресурсов это, наверное, самый показательный пример такой склейки, потому что снаружи он обычно выглядит как пару строчек вида LoadTexture(" bark.dds ") , а внутри это кэш, политика дефолтов, механика восстановления после сбоя и ещё полдюжины вещей, каждая из которых прошла через пот, кровь и пиксели и осталась в архитектуре этой системы. Если открыть любую книгу по разработке игр или игрового движка и попробовать найти определение "игровой ресурс", то получится что ресурс - это набор данных, которые были загружены или созданы с конкретными параметрами. Любые уточнения вроде «текстура», «меш», «звук» или «шейдер» здесь уже будут лишними, потому что нам важна не природа данных, а что они существуют именно определенной форме. Понятие "определенная форма" тем не менее тоже звучит абстрактно, поэтому люди предпочитают использовать "текстуру", "меш", "звук" и т.д. Но одну и ту же текстуру wall.dds , которую можно загрузить в DXT5 со сжатием, sRGB и mip-фильтром box, а можно без сжатия, в линейном пространстве и с другим фильтром. Формально у нас был один файл на диске, но с точки зрения ресурсного менеджера теперь это два разных "ресурса", потому что их параметры различаются. Подмена одного ресурса другим в рантайме может сломать игру, потому что игра ожидает определенных данных для шейдера, которая изменилась после фильтра или определённую раскладку мипов, которой может не оказаться. Более явный пример для шейдеров будет, когда lighting.fx , скомпилированный с дефайном SIMPLE_BUMP_MAPPING , и lighting.fx , скомпилированный с PARALLAX_BUMP_MAPPING , физически выглядят в исходниках как один файл, но дают два разных пайплайна, со своими константными буферами и со своими ожиданиями к набору текстур, а если ресурсный менеджер этого не понимает, то он либо начнёт раздавать второй вариант, когда просят первый. С мешами история та же самая, и ship.mesh , загруженный в менеджере ресурсов, и тот же ship.mesh , лежащий в GPU это два разных объекта, у которых даже время жизни и поведение при потере устройства будут отличаться, не говоря уже о том, что первый мы можем менять, а в второй нет. Грузись текстурка, большая и маленькая
https://habr.com/ru/articles/1039266/
#с++ #программирование #разработка_игр #игры_и_игровые_консоли
-
Запихнули игровую приставку в короб и в первый же месяц продали на 3 млн
В конце прошлого года меня уволили с работы. Кризис наступает на пятки всем айтишникам, и я не стал исключением. Начал искать, чем можно занять освободившееся время, так с партнером и придумали идею нового проекта – игрового автомата на базе движений! Ну а дальше всё, как в тумане: железо, бэкенд, фронтенд, эквайринг, обкатка и первые реальные прод…
https://habr.com/ru/articles/1039472/
#игровой_автомат #raspberry #разработка #diy #программирование #игровые_консоли #вендинг #стартап #бизнес
-
Запихнули игровую приставку в короб и в первый же месяц продали на 3 млн
В конце прошлого года меня уволили с работы. Кризис наступает на пятки всем айтишникам, и я не стал исключением. Начал искать, чем можно занять освободившееся время, так с партнером и придумали идею нового проекта – игрового автомата на базе движений! Ну а дальше всё, как в тумане: железо, бэкенд, фронтенд, эквайринг, обкатка и первые реальные прод…
https://habr.com/ru/articles/1039472/
#игровой_автомат #raspberry #разработка #diy #программирование #игровые_консоли #вендинг #стартап #бизнес
-
Запихнули игровую приставку в короб и в первый же месяц продали на 3 млн
В конце прошлого года меня уволили с работы. Кризис наступает на пятки всем айтишникам, и я не стал исключением. Начал искать, чем можно занять освободившееся время, так с партнером и придумали идею нового проекта – игрового автомата на базе движений! Ну а дальше всё, как в тумане: железо, бэкенд, фронтенд, эквайринг, обкатка и первые реальные прод…
https://habr.com/ru/articles/1039472/
#игровой_автомат #raspberry #разработка #diy #программирование #игровые_консоли #вендинг #стартап #бизнес
-
Запихнули игровую приставку в короб и в первый же месяц продали на 3 млн
В конце прошлого года меня уволили с работы. Кризис наступает на пятки всем айтишникам, и я не стал исключением. Начал искать, чем можно занять освободившееся время, так с партнером и придумали идею нового проекта – игрового автомата на базе движений! Ну а дальше всё, как в тумане: железо, бэкенд, фронтенд, эквайринг, обкатка и первые реальные прод…
https://habr.com/ru/articles/1039472/
#игровой_автомат #raspberry #разработка #diy #программирование #игровые_консоли #вендинг #стартап #бизнес
-
[Перевод] В С неопределённое поведение повсюду
Если бы Кардинал Ришелье был программистом, он бы сказал: «Дайте мне шесть строк кода, написанных рукой самого профессионального C-программиста в мире, и я найду в них лазейку для вызова неопределённого поведения. Никто не может написать безошибочный код на С или C++. И я говоря об этом как человек, который пишет на этих языках почти каждый день около 30 лет. Я слушаю подкасты по C++. Я смотрю выступления про C++ на конференциях. Мне нравится читать и писать на этом языке. C++ послужил нам сполна, но на дворе 2026 год, и современная рабочая среда явно отличается от среды 1985 (C++) или 1972 (С). И я далеко не первый, кто об этом заговорил. Помню ещё с десять лет назад читал статью какого-то известного человека, в которой он утверждал, что использование C++ вполне обоснованно можно подвести под нарушение закона Сарбейнза-Оксли (SOX). И хотя с остальной его критикой я не был согласен (как и с тем, что он путал «its» и «it’s»), конкретно с этим пунктом я никогда не спорил. Мало того, со временем я всё больше убеждался в его истинности. На деле в С для возникновения неопределённого поведения (undefined behaviour, UB) есть гораздо больше возможных причин, чем вы могли предполагать. Все знают, что двойное освобождение памяти, её использование после освобождения, выход за границы объекта (например, массива) и чтение неинициализированной памяти — это UB. Как ни крути, но в контексте работы с памятью C и C++ безопасными не назовёшь. Тем не менее даже эти ошибки продолжают совершаться повсеместно раз за разом.
https://habr.com/ru/companies/ruvds/articles/1037992/
#ruvds_перевод #программирование #с++ #неопределённое_поведение #undefined_behavior #компиляторы #оптимизация_кода #си #легасикод
-
[Перевод] В С неопределённое поведение повсюду
Если бы Кардинал Ришелье был программистом, он бы сказал: «Дайте мне шесть строк кода, написанных рукой самого профессионального C-программиста в мире, и я найду в них лазейку для вызова неопределённого поведения. Никто не может написать безошибочный код на С или C++. И я говоря об этом как человек, который пишет на этих языках почти каждый день около 30 лет. Я слушаю подкасты по C++. Я смотрю выступления про C++ на конференциях. Мне нравится читать и писать на этом языке. C++ послужил нам сполна, но на дворе 2026 год, и современная рабочая среда явно отличается от среды 1985 (C++) или 1972 (С). И я далеко не первый, кто об этом заговорил. Помню ещё с десять лет назад читал статью какого-то известного человека, в которой он утверждал, что использование C++ вполне обоснованно можно подвести под нарушение закона Сарбейнза-Оксли (SOX). И хотя с остальной его критикой я не был согласен (как и с тем, что он путал «its» и «it’s»), конкретно с этим пунктом я никогда не спорил. Мало того, со временем я всё больше убеждался в его истинности. На деле в С для возникновения неопределённого поведения (undefined behaviour, UB) есть гораздо больше возможных причин, чем вы могли предполагать. Все знают, что двойное освобождение памяти, её использование после освобождения, выход за границы объекта (например, массива) и чтение неинициализированной памяти — это UB. Как ни крути, но в контексте работы с памятью C и C++ безопасными не назовёшь. Тем не менее даже эти ошибки продолжают совершаться повсеместно раз за разом.
https://habr.com/ru/companies/ruvds/articles/1037992/
#ruvds_перевод #программирование #с++ #неопределённое_поведение #undefined_behavior #компиляторы #оптимизация_кода #си #легасикод
-
[Перевод] В С неопределённое поведение повсюду
Если бы Кардинал Ришелье был программистом, он бы сказал: «Дайте мне шесть строк кода, написанных рукой самого профессионального C-программиста в мире, и я найду в них лазейку для вызова неопределённого поведения. Никто не может написать безошибочный код на С или C++. И я говоря об этом как человек, который пишет на этих языках почти каждый день около 30 лет. Я слушаю подкасты по C++. Я смотрю выступления про C++ на конференциях. Мне нравится читать и писать на этом языке. C++ послужил нам сполна, но на дворе 2026 год, и современная рабочая среда явно отличается от среды 1985 (C++) или 1972 (С). И я далеко не первый, кто об этом заговорил. Помню ещё с десять лет назад читал статью какого-то известного человека, в которой он утверждал, что использование C++ вполне обоснованно можно подвести под нарушение закона Сарбейнза-Оксли (SOX). И хотя с остальной его критикой я не был согласен (как и с тем, что он путал «its» и «it’s»), конкретно с этим пунктом я никогда не спорил. Мало того, со временем я всё больше убеждался в его истинности. На деле в С для возникновения неопределённого поведения (undefined behaviour, UB) есть гораздо больше возможных причин, чем вы могли предполагать. Все знают, что двойное освобождение памяти, её использование после освобождения, выход за границы объекта (например, массива) и чтение неинициализированной памяти — это UB. Как ни крути, но в контексте работы с памятью C и C++ безопасными не назовёшь. Тем не менее даже эти ошибки продолжают совершаться повсеместно раз за разом.
https://habr.com/ru/companies/ruvds/articles/1037992/
#ruvds_перевод #программирование #с++ #неопределённое_поведение #undefined_behavior #компиляторы #оптимизация_кода #си #легасикод
-
[Перевод] В С неопределённое поведение повсюду
Если бы Кардинал Ришелье был программистом, он бы сказал: «Дайте мне шесть строк кода, написанных рукой самого профессионального C-программиста в мире, и я найду в них лазейку для вызова неопределённого поведения. Никто не может написать безошибочный код на С или C++. И я говоря об этом как человек, который пишет на этих языках почти каждый день около 30 лет. Я слушаю подкасты по C++. Я смотрю выступления про C++ на конференциях. Мне нравится читать и писать на этом языке. C++ послужил нам сполна, но на дворе 2026 год, и современная рабочая среда явно отличается от среды 1985 (C++) или 1972 (С). И я далеко не первый, кто об этом заговорил. Помню ещё с десять лет назад читал статью какого-то известного человека, в которой он утверждал, что использование C++ вполне обоснованно можно подвести под нарушение закона Сарбейнза-Оксли (SOX). И хотя с остальной его критикой я не был согласен (как и с тем, что он путал «its» и «it’s»), конкретно с этим пунктом я никогда не спорил. Мало того, со временем я всё больше убеждался в его истинности. На деле в С для возникновения неопределённого поведения (undefined behaviour, UB) есть гораздо больше возможных причин, чем вы могли предполагать. Все знают, что двойное освобождение памяти, её использование после освобождения, выход за границы объекта (например, массива) и чтение неинициализированной памяти — это UB. Как ни крути, но в контексте работы с памятью C и C++ безопасными не назовёшь. Тем не менее даже эти ошибки продолжают совершаться повсеместно раз за разом.
https://habr.com/ru/companies/ruvds/articles/1037992/
#ruvds_перевод #программирование #с++ #неопределённое_поведение #undefined_behavior #компиляторы #оптимизация_кода #си #легасикод
-
Как я строил ИИ-стартап, или Новые архитектурные риски 2026
За последние годы я выучил наизусть классический набор инженерных рисков — упадёт сервер, отвалится канал к ДЦ, крешнется хард, потеряются бэкапы — и набор готовых решений под них. Это азбука, которая казалась исчерпывающей. Но 2026 год преподнёс мне сюрприз. Создавая свой ИИ-стартап, я понял, что мир изменился, и в нём появился целый новый класс архитектурных рисков — таких, о которых в моей азбуке не было ни строчки. И ровно об эти новые риски я и пошёл спотыкаться. Итак, усаживайтесь поудобнее и слушайте историю — историю про путешествия… путешествия нашей инфраструктуры и о реалиях разработки современных ИИ-стартапов из Москвы. Я расскажу вам о настоящем инженерном приключении, которое со мной произошло в процессе построения сервиса Mimirjotun.ru.
https://habr.com/ru/articles/1038248/
#ии #ииагенты #saas #saasсервис #mvp #стартап #стартапы #ai #программирование #разработка
-
Как я строил ИИ-стартап, или Новые архитектурные риски 2026
За последние годы я выучил наизусть классический набор инженерных рисков — упадёт сервер, отвалится канал к ДЦ, крешнется хард, потеряются бэкапы — и набор готовых решений под них. Это азбука, которая казалась исчерпывающей. Но 2026 год преподнёс мне сюрприз. Создавая свой ИИ-стартап, я понял, что мир изменился, и в нём появился целый новый класс архитектурных рисков — таких, о которых в моей азбуке не было ни строчки. И ровно об эти новые риски я и пошёл спотыкаться. Итак, усаживайтесь поудобнее и слушайте историю — историю про путешествия… путешествия нашей инфраструктуры и о реалиях разработки современных ИИ-стартапов из Москвы. Я расскажу вам о настоящем инженерном приключении, которое со мной произошло в процессе построения сервиса Mimirjotun.ru.
https://habr.com/ru/articles/1038248/
#ии #ииагенты #saas #saasсервис #mvp #стартап #стартапы #ai #программирование #разработка
-
Как я строил ИИ-стартап, или Новые архитектурные риски 2026
За последние годы я выучил наизусть классический набор инженерных рисков — упадёт сервер, отвалится канал к ДЦ, крешнется хард, потеряются бэкапы — и набор готовых решений под них. Это азбука, которая казалась исчерпывающей. Но 2026 год преподнёс мне сюрприз. Создавая свой ИИ-стартап, я понял, что мир изменился, и в нём появился целый новый класс архитектурных рисков — таких, о которых в моей азбуке не было ни строчки. И ровно об эти новые риски я и пошёл спотыкаться. Итак, усаживайтесь поудобнее и слушайте историю — историю про путешествия… путешествия нашей инфраструктуры и о реалиях разработки современных ИИ-стартапов из Москвы. Я расскажу вам о настоящем инженерном приключении, которое со мной произошло в процессе построения сервиса Mimirjotun.ru.
https://habr.com/ru/articles/1038248/
#ии #ииагенты #saas #saasсервис #mvp #стартап #стартапы #ai #программирование #разработка
-
Как я строил ИИ-стартап, или Новые архитектурные риски 2026
За последние годы я выучил наизусть классический набор инженерных рисков — упадёт сервер, отвалится канал к ДЦ, крешнется хард, потеряются бэкапы — и набор готовых решений под них. Это азбука, которая казалась исчерпывающей. Но 2026 год преподнёс мне сюрприз. Создавая свой ИИ-стартап, я понял, что мир изменился, и в нём появился целый новый класс архитектурных рисков — таких, о которых в моей азбуке не было ни строчки. И ровно об эти новые риски я и пошёл спотыкаться. Итак, усаживайтесь поудобнее и слушайте историю — историю про путешествия… путешествия нашей инфраструктуры и о реалиях разработки современных ИИ-стартапов из Москвы. Я расскажу вам о настоящем инженерном приключении, которое со мной произошло в процессе построения сервиса Mimirjotun.ru.
https://habr.com/ru/articles/1038248/
#ии #ииагенты #saas #saasсервис #mvp #стартап #стартапы #ai #программирование #разработка
-
[Перевод] Спустя 5 лет и $5 миллионов: почему создание нового языка для веб-разработки оказалось ошибкой
В Wasp мы создаём фулстек-фреймворк — наподобие Rails или Laravel для JS, только ещё и расширенный на фронтенд. Мы с моим братом-близнецом начали этот проект в 2021 году, когда успешно прошли программу Y Combinator. За всё это время в общей сложности нам удалось привлечь $5 миллионов инвестиций. Изначально мы хотели создать язык программирования, который бы абстрагировал типичные паттерны веб-приложений и в то же время позволял углубиться в любой стек (мы начали с React, Node.js и Prisma). Что-то вроде Terraform, но для стека веб-приложения, а не облачной инфраструктуры. Теперь же, спустя пять лет стараний, мы поняли, что это было ошибкой. Создавать новый язык есть смысл под конкретные задачи и предметную область. В нашем же случае он людям не зашёл и создал больше проблем, чем принёс пользы. В этой статье я расскажу, почему нам эта идея казалась перспективной, какие уроки мы вынесли и почему заменяем свой язык на TypeScript при том, что сам Wasp внутренне остаётся всё тем же.
https://habr.com/ru/companies/ruvds/articles/1037366/
#ruvds_перевод #программирование #wasp #react #typescript #фронтенд #бэкенд #фреймворки_для_разработки
-
[Перевод] Спустя 5 лет и $5 миллионов: почему создание нового языка для веб-разработки оказалось ошибкой
В Wasp мы создаём фулстек-фреймворк — наподобие Rails или Laravel для JS, только ещё и расширенный на фронтенд. Мы с моим братом-близнецом начали этот проект в 2021 году, когда успешно прошли программу Y Combinator. За всё это время в общей сложности нам удалось привлечь $5 миллионов инвестиций. Изначально мы хотели создать язык программирования, который бы абстрагировал типичные паттерны веб-приложений и в то же время позволял углубиться в любой стек (мы начали с React, Node.js и Prisma). Что-то вроде Terraform, но для стека веб-приложения, а не облачной инфраструктуры. Теперь же, спустя пять лет стараний, мы поняли, что это было ошибкой. Создавать новый язык есть смысл под конкретные задачи и предметную область. В нашем же случае он людям не зашёл и создал больше проблем, чем принёс пользы. В этой статье я расскажу, почему нам эта идея казалась перспективной, какие уроки мы вынесли и почему заменяем свой язык на TypeScript при том, что сам Wasp внутренне остаётся всё тем же.
https://habr.com/ru/companies/ruvds/articles/1037366/
#ruvds_перевод #программирование #wasp #react #typescript #фронтенд #бэкенд #фреймворки_для_разработки