Ненормальное программирование *

«Возьми вишневый мамин плащ и кружку молока» – вспомнился мне фрагмент моего любимого стиха из книги Григория Остера «Вредные советы». И я понял, что у меня для вас тоже есть пара советов. Конечно, мои советы  не такие «сочные», но все же использовать их стоит с умом и большой осмотрительностью.

Мы рассмотрим три приема работы с XWiki, которые скорее всего выбиваются из хорошей практики, но могут быть полезны в ваших экспериментах. В любом случае, если вы пересели с иглы Confluence на его open source аналог (со слов разработчиков). То вам, точно не помешает знать о возможностях доработки его напильником.

Начнем мы с получения доступа к командной оболочке прямо из XWiki, а закончим обхождением ограничений CORS с помощью скрипта на Python.

Как говорится: «Милости прошу под кат»

Пару месяцев назад в очередной раз занесло меня в Акихабару, и конечно же я не мог не заглянуть в свой любимый Akizuki Denshi.

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

Делать нечего, придётся пилить — и давайте попробуем сделать это, совершенно не занимая процессор!

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

История о провале госконтракта.

Всем привет! Меня зовут Сергей. И в данной статье задену тему очередной эмуляции Nes/Dendy/Famicon. Зачем? Зачем плодить очередной эмулятор того, что уже сделано достаточно хорошо. Можете считать это моей прихотью, а так же пробой своих сил (хотя на самом деле для пробы своих сил лучше, наверно, что-то попроще эмулировать).

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

В C++ уже больше 10 лет существует constexpr, который позволяет программисту ушло возложить часть вычислений на компилятор. В свое время это взорвало мне мозг, ведь компилятор может посчитать какие-то достаточно сложные вещи еще до запуска программы!

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

На этом моменте и зародился мой челлендж:

"Без рук" или "даже не думай запускать exe-файл"

База данных — это сердце многих приложений, от полнофункциональных корпоративных сайтов до сравнительно простых инструментов, например, для ведения списков покупок и финансовых трекеров. Популярны реляционные базы данных на основе SQL, но в Linux можно собрать более простую и прозрачную альтернативную базу данных.

На эти грабли я чуть не наступил (но не наступил!) в рабочем коде, когда захотел прикрутить концепты. Просто задумался о последствиях, проверил на дистиллированном коде, - и да, оно стреляет. Поэтому предлагаю вам в качестве упражнения по ненормальному C++.

Итак. Пусть у нас есть полиморфная (шаблонная, перегруженная, - неважно) функция f(x).
И мы написали концепт, который говорит, что тип может быть аргументом этой функции.
Назовём его fable, то есть, "f-абельный", или, по-русски, "сказка". (Эта сказка будет страшной).

На C++20 это выглядит очень просто и элегантно. (Без requires в виде шаблонной метафункции это тоже делается, но заметно громоздче).

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

Фундаментальной (по моему мнению) проблемой множества языков программирования является неявное использование ссылок (ссылочных переменных).

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

Еще одной проблемой (или следствие предыдущей) является многопоточное и/или асинхронное выполнение программы, когда к одной и той же области данных может быть получен доступ из разных потоков приложения, что в купе с неявным доступом по ссылкам еще больше усугубляет ситуацию.

А как бы хотелось отдать эти проблемы на откуп компилятору! Чтобы компьютер сам автоматически проверял корректность доступа по ссылкам, в том числе и из разных потоков и чтобы все это делалось во время компиляции приложения без накладных расходов в рантайме!

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

На Хабре выходило много статей про эзотерические языки программирования: про самые неординарные, про 5 наиболее странных, примеры кода на 39 эзотерических языках. Как раз когда я готовил этот текст, появился панорамный обзор по теме. Меня это не остановило, потому что хотелось зайти с другой стороны — какие культовые фильмы, группы, песни, книги и авторы вдохновляли создателей ЭЯП. Об этом и хочу рассказать в статье.

Совершать невозможное и раздавать пинки здравому смыслу — в этом и состоит жизнь членов Гуррен-Дана! (C) Камина

Эта статья вступает в техническую полемику со статьей 2015 года за авторством Atakua, подходы из которой я и атакую. Atakua исследует 7 видов интерпретаторов байткода, но делает это без уважения - быстрейшей оказывается двоичная трансляция, которая, по сути, уже не интерпретатор байткода, а форма Ahead-Of-Time компилятора. Эта двоичная трансляция транслирует байткод в машинный код, представляющий собой цепочку вызовов скомпилированных сервисных процедур. Тех самых, что в интерпретаторе байткода отвечают за выполнение каждого опкода.

Но Atakua не выжал из интерпретаторов байткода всю скорость которая возможна. Так что эта статья - туториал: как написать интерпретатор байткода, который может обгонять JIT/AOT-компиляцию по скорости. Интересно? Читайте дальше!

Бенчмарк прилагается. Будет немного хардкора и ни одной сгенерированной нейросетью картинки!

В 2014 году в движке Unity набралось столько критических изменений и новинок, что «пятерка» фактически была другим движком. И хотя многие за одинаковым фасадом не особо этого и заметили, но изменения коснулись всех компонентов движка, начиная от файловой системы и заканчивая рендером. Питерский офис EA имел свою ветку основного репозитария, отставая от мастера максимум на месяц. Я уже писал про различные реализации и типы строк в игровых движках, но в Unity была своя реализация, имевшая как положительные так и отрицательные стороны, которая использовалась практически во всех подсистемах. К ней привыкли, знали слабые стороны и плохие «use cases» и хорошие «best practices». Поэтому когда эту систему стали выпиливать из движка много чего поломалось, и если у обычных пользователей был сразу переход на новую версию и наблюдались только отголоски шторма, то допущенные до «тела» наловили много прикольных багов.

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

Но в IT всегда были люди, которым мало «обычного» хардкорного кода, и они начали изобретать собственные, иногда совершенно безумные и оригинальные эзотерические языки программирования. О них мы сегодня и поговорим.

void в плюсах довольно забавная штука. Мы можем привести к void почти любой тип, завести указатель с типомvoid*, который может адресовать что угодно. Еще можем сделать функцию с возвращаемым типом void , которая ничего не возвращает. Объявление функции типа void f(void) будет просто функцией без аргументов. Но вот иметь объекты типа void или написать что-то вроде void& не можем. Это немного странно, но не настолько, чтобы вызывать у вас бессонные ночи, пока вы не начинаете ловить странные баги, когда void вообще не void.

Проблема возникла где не ждали, а именно на проекте немного обновили бенчмарк фреймворк, казалось что такого может случиться на выполнении тестов?

"Ничего хорошего не случится" - сказал техлид и в пятницу вечером залил, в обход этих самых тестов, новый фреймворк. А сам укатил на какую-то конференцию.

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

То, что будет происходить ниже – сущий ад. Я буду писать простейшие программы на языке Whitespace (Но не такие простые, как в прошлой статье). Этот язык настолько ненужный, что оригинальный сайт с интерпретатором для этого языка уже давно мертв, все ссылки на оригинальные гайды, соответственно – тоже.

Наверное, в этой форме надо написать выжимку для привлечения внимания? Нуу, мы с головой запрыгнем в язык, состоящий из пробелов, черт побери, что вам еще нужно? А потом этим пробельным кодом отформатируем отрывок из книги «Война и Мир», и он будет прекрасно компилироваться.

Я сделал небольшой клиент для Wolfram Language, который умеет вызывать OpenAI API и другие API, которые на него похожи. Сам активно пользуюсь им и хочу рассказать о том, как легко создать ассистента на основе OpenAI API и добавить в него свои собственные плагины.

Зачем я это делаю?

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

Во-вторых, у Wolfram Language есть фантастически крутой блокнотный пользовательский интерфейс. Речь конечно же про Mathematica и про наш родной отечественный WLJS Notebook. Формат интерактивного блокнота как нельзя лучше подходит для работы с чат-ботами, LLM и нейросетями.

В-третьих, в пакете AILink есть киллер-фича WL из коробки, которая доступна всем пользователям Wolfram Language - это Cloud Evaluate. С его помощью вам не потребуется VPN для обхода блокировки по региону со стороны OpenAI. То есть AILink в Wolfram Language работает в РФ без использования прокси!

В-четвертых, я как фанат Wolfram Language просто в очередной раз хочу про него рассказать.

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

Сегодня столкнулся с очередным нетипичным вариантом использования - "перекладыванием" значений из JSON-строк в столбцы.

Давайте сделаем это попроще.

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

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

Ошибки программистов C++ — это отдельный вид искусства, вроде бы простой язык, но стоит отвлечься на чашечку кофе, как компилятор начинает вываливать простыню ворнингов пополам с ошибками, и иногда это больше похоже на древнеегипетские письмена, чем на нормальный выхлоп. Вы наверное и сами не раз сталкивались с разыменованием nullptr или перепутали (= и ==) по недосмотру. Часто причиной ошибкой является лень или невнимательность, или усталость - не зря появились суеверия "не комитить в пятницу вечером", "не кодить в состоянии изменного сознания" или "избегать кода под кофейным угаром", ну это когда три-четыре кружечки кофе навернул и пошел нести добрый код направо и налево.

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

C++ не прощает ошибок, но именно в этом его "шарм". В большинстве приведенных примеров сохранен стиль и названия параметров, только немного подчищены коментарии, дабы не палить контору.