Я давно пользуюсь кодогенерацией. Ещё во времена Yii фреймворка мне нравилось, что одним кликом мышки можно было сгенерировать CRUD с бэкендом, таблицами и формами. Backbone.js сразу из коробки обеспечивал REST API запросы и другие фичи. Между тем временем и нынешним днём — целый пласт инструментов для автоматизации, бутстрапинга и шаблонизации разработки. Приходилось и хрюкать, и глотать. То, что всё это, мягко говоря, так себе — уже отдельная история. Местами стало даже хуже. Хуже, чем когда вы неделю возились с конфигом Webpack.

В этой статье мы рассмотрим вайбкодинг. В чистом виде так сказать.

Основной объём трафика в вебе возникает из-за ботов. По большей части, эти боты используются для обнаружения нового контента. Это читалки RSS-фидов, поисковые движки, выполняющие краулинг вашего контента, а сегодня и боты ИИ, собирающие контент, чтобы скармливать его LLM. Но есть и зловредные боты. Их создают спамеры, скрейперы контента и хакеры. На моём прежнем месте работы бот обнаружил уязвимость Wordpress и встроил в наш сервер зловредный скрипт, а затем превратил машину в ботнет, используемый для DDOS. Один из моих первых веб-сайтов был полностью выдавлен из поиска Google из-за ботов, генерирующих спам. Мне нужно было найти способ защиты от этих ботов, поэтому я начал пользоваться zip-бомбами.

После каждой новой статьи с заголовком «ООП — это обман» хочется напомнить: ООП — это не набор шаблонов из книжек, а инженерный подход. Если проект страдает от наследования и DI, возможно, проблема не в ООП. А в том, как вы его применяете.

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

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

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

Вы делаете то, что действительно ВАЖНО, или занимаетесь тем, на что хватает силы...

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

Я сразу начну с главной проблемы. Она заключается в том, что мы не видим проблем с отдыхом! 

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

Но из-за того, что зачастую мы отдыхаем некорректно, мозг не успевает перезагрузиться. Особенно это касается предпринимателей, когда поток стресса не заканчивается, одна задача наслаивается на другую. Организм просто не успевает переработать негативные последствия. Так незаметно начинается истощение. И к сожалению, со временем оно может привести к желанию ВСЕ БРОСИТЬ...

Но есть Хорошая новость. Уже сейчас Вы можете изменить эту ситуацию, если проведёте сheck-up своего досуга на следующие 13 ошибок, чтобы проверить, действительно ли привычный отдых восстанавливает Вас.

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

В мире разработки программного обеспечения существует множество "священных коров" — принципов и практик, которые принимаются как данность и редко подвергаются критическому анализу. Особенно показательна ситуация с принципами SOLID на русскоязычных ресурсах: достаточно открыть Хабр, чтобы найти 100500 статей о SOLID, и в каждой из них принципы интерпретируются по-разному.

Само существование такого количества "объяснительных" статей говорит о фундаментальной проблеме: если принципы требуют толкования, значит их названия не являются самодостаточными и интуитивно понятными. А если каждый разработчик понимает принципы по-своему, возникает вопрос — зачем вообще нужны принципы, которые не дают однозначного руководства к действию? Принципы SOLID, предложенные Робертом Мартином, давно стали одной из таких "священных коров". Однако пришло время честно признать: то, как мы используем SOLID сегодня, часто противоречит изначальным идеям и в целом иногда может приносить больше вреда, чем пользы. Зависит от контекста.

SRP не SRP

Самый яркий пример искажения первоначального замысла — это интерпретация принципа единственной ответственности (SRP).

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

Всегда хотел написать о чем-нибудь легком и воздушном, как пишет например @antoshkkaпро userver или о том, как легко и непринужденно обернуть какую-нибудь хрень алгоритм в десяток шаблонов, полить это все std::optional и попивая кофе ждать, когда компилятор соизволит это всё пережевать. Но судьба (а не тимлид, нет, как вы могли такое подумать) постоянно подкидывает задачки, где суровые объятия отладчика не отпускают мечтательную душу программера до поздней ночи, да вечная борьба с компилятором рушит все попытки обернуть результат хрени алгоритма в другой десяток шаблонов. На этот раз судьба ясным июньским утром подкинула забавную задачу - время полной сборки бандла подбиралось к двум часам, да собирать бандлы нынче удовольствие не из быстрых, но посмотрев статистику стало понятно, что ~55% процентов времени тратится на сборку ресурсов: текстур, моделей, локализацию, и тд. Там есть что чинить, но это царство билд-инженеров. Еще 30% или сорок минут тратится на тесты, теперь все что мы насобирали и переконвертили надо проверить, загрузить, пострелять, побегать, монстров поубивать, BT-шки погонять, с этим пусть QA разбираются. А вот оставшиеся 15% или около 15 минут мы занимались настоящей работой, собирали сердце проекта - бинарь. Да норм, у нас всегда так, даже на пустом проекте UE - сказали наши мобильщики и ушли пить кофе на терассу . Но мы же не мобильщики, мы серьезные AAA ребята, у нас свой движок и кастомный пайплайн на билдферме. И потом 15 минут это очень много, даже если у тебя 27к файлов в проекте, айда смотреть куда время потратили.

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

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

В этом посте я хочу рассмотреть вопрос, ответ на который, надеюсь, поможет вам понять, почему многие вещи в мире устроены так, как они устроены. Почему многие законы такие нелогичные? Почему идущие в кинотеатрах фильмы такие незамысловатые, а шедевры всегда проваливаются в прокате? Почему до сих пор так распространено мошенничество "с безопасным счётом", если о нём трындят на каждом шагу? Почему в США так важно кого на выборах поддержит Тейлор Свифт? Почему существует общество плоской Земли? Почему полиция работает так, как она работает? Причём я не буду прямо рассматривать ни один из этих вопросов, а рассмотрю только метавопрос, метаответ на который безмолвно отвечает на них все.

Привет, Хабр!

Идея статьи появилась, когда я начал повсюду замечать якобы подтверждения мифа, что «программирование — это просто»‬‬.

В новостях «восьмилетняя девочка, которая второй раз в жизни занимается программированием, наклепала чат-бота за 45 минут»‬ (ага, да!).

Курсы предлагают мне за 10 месяцев с нуля стать миддл+ (ага, да!).

Но я-то знаю, как оно на самом деле. Мы, программисты, обычно решаем проблемы и двигаемся дальше, но я решил запротоколировать всё как есть, и в течение пары месяцев скрупулёзно записывал всю ту хрень, что происходила со мной и моими коллегами, чтобы показать программирование без прикрас. Поехали!

Привет, меня зовут Даниль Гатиатуллин, я инженер юнита Performance в Авито. В этой статье я рассказываю, что такое Baseline Profiles, как он ускоряет запуск программы и каким приложениям он принесет больше пользы. В качестве примера возьму наш эксперимент, который ускорил время запуска приложения на 15%. Также расскажу, как мы автоматизировали добавление профилей в каждый релиз.

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

Что такое «точки следования»?

Точки следования (sequence points)– такие точки в процессе выполнения программы, в которых все побочные эффекты уже выполненного кода закончили свое действие, а побочные эффекты кода, подлежащего исполнению, еще не начали действовать. (§1.9/7)

Побочные эффекты? А что такое «побочные эффекты»?

Побочный эффект (side effect) (согласно Стандарту) – результат доступа к volatile объекту, изменения объекта, вызова функции из библиотеки I/O или же вызова функции, включающей в себя какие-то из этих действий. Побочный эффект является изменением состояния среды выполнения.

Как известно, с недавних пор сервера qt.io запрещают загрузку любых архивов с российских IP. Если первое время проверка шла только на получение метаинформации, теперь любая загрузка файла обрывается сервером.

Обычные советы, как это обойти, включают:

• Используй платный безлимитный VPN;
• Используй дистрибутив Linux и его бинарные сборки;
• Собирай сам из исходинков.

Все это рабочие советы, но не очень дружелюбны к начинающим разработчикам, которые только hello world начинают собирать. Я расскажу, как можно быстро настроить окружение используя зеркала Yandex и github.

В кульминационный момент Второй мировой войны ЦРУ выпустило потрясающую книгу Simple Sabotage. В ней изложены различные способы, которыми диверсанты могут снижать продуктивность компании. Некоторые из этих советов не стареют, например, раздел «Общие помехи организациям и производству»:

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

2. Делайте «доклады». Говорите как можно чаще и пространнее. Иллюстрируйте свои «идеи» долгими историями из жизни и ссылайтесь на личный опыт. С готовностью делайте «патриотические» комментарии.

3. По возможности отправляйте все вопросы в комитеты для «более глубокого изучения и рассмотрения». Стремитесь делать комитеты как можно больше, не менее чем из пяти членов.

4. Как можно чаще поднимайте вопросы о несущественных проблемах.

5. Спорьте о чётких формулировках в общении, протоколах, резолюциях.

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

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

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

Меня всегда поражало, насколько хорошо эти советы прошли проверку временем.

Если вы хотите сделать хорошую архитектуру, то используйте эту схему и строго соблюдайте правила, без каких-либо исключений.

Прим. Wunder Fund: В статье описаны базовые подходы к работе с корутинами в 20м стандарте С++, на паре практических примеров разобраны шаблоны классов для промисов и фьючеров. По нашему скромному мнению, можно было бы реализовать и поизящнее. Приходите к нам работать, если имеете сильные мнения о корутинах хе-хе.

Возникает такое ощущение, что тема реализации корутин в C++20 окутана серьёзной неопределённостью. Полагаю, это так из-за того, что в проекте технической спецификации C++20 сказано, что работа над механизмами корутин всё ещё ведётся, в результате в данный момент нельзя ожидать полной поддержки этих механизмов компиляторами и стандартной библиотекой.Множество проблем, вероятно, возникает из-за отсутствия официальной документации по работе с корутинами. Нам дали синтаксическую поддержку корутин в C++ (co_yield и co_return), но не всё то, что я счёл бы признаками их полной библиотечной поддержки. В стандартной библиотеке имеются хуки и базовый функционал поддержки корутин, но нам приходится самостоятельно встраивать всё это в наши собственные классы. Я ожидаю, что полная поддержка корутин-генераторов появится в C++23.

Если вы — Python- или C#-разработчик и ожидаете увидеть в C++ простую механику работы с корутинами, то вас ждёт разочарование, так как фреймворк общего назначения C++20 недоработан. Учитывая это, можно отметить, что в интернете имеется множество публикаций, в состав кода, обсуждаемого в которых, входит шаблонный класс, поддерживающий корутины-генераторы. В этом материале вы найдёте шаблон корутины, применимый на практике, а также примеры кода. Всё это предваряется общими сведениями о корутинах.