Программирование *

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

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

Хоть Rust не является чистым функциональным языком программирования, однако он имеет множество инструментов, позволяющих применять функциональные принципы.

Rust поддерживает рекурсию, хотя и без оптимизации хвостовых вызовов, что является отступлением от некоторых традиционных функциональных языков, таких как Haskell. Тем не менее, язык предоставляет мощные абстракции и паттерны, такие как владение и заимствование.

Rust также поощряет иммутабельность данных по умолчанию, что является в целом базой ФП. Переменные в Rust иммутабельны по умолчанию, и язык требует явного указания mut, если хочется изменить значение.

Кроме того, Rust имеет поддержку функций высшего порядка и замыканий.

На просторах интернета есть несколько статей об алгоритме получения хеш-функции Стрибог (ГОСТ 34.11-2012), в том числе и на Хабре. Однако везде в качестве примера приводится реализация на языках программирования C, C#, Python и других. То есть идет последовательное выполнение операций алгоритма. В данной статье я хочу затронуть аппаратную реализацию на языке System Verilog, уделить внимание распараллеливанию вычислений и описанию интерфейсов модулей. Для начала кратко рассмотрим теорию.

Этому миру требуется новая теория, теория, которая могла бы описать все теории на планете. Теория которая могла бы одинаково легко описывать философию, математику, физику и психологию. Сделать все виды наук вычислимыми.

Именно над этим мы и работаем. Эта теория, если у нас всё получится, станет единой метатеорией всего.

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

Как и всё что мы делали до этого, теория связей публикуется и передаётся в общественное достояние и принадлежит человечеству. То есть именно тебе. У этого труда множество авторов, однако сам этот труд намного важнее конкретного авторства. И мы надеемся уже сегодня это сможет быть полезно каждому.

Мы приглашаем тебя стать частью этого увлекательного приключения.

Привет, Хабр! Привет, меня зовут Иван Шурыгин, я работаю fullstack-разработчиком, в свободное время занимаюсь исследованием опенсорс-проектов, люблю покопаться в репозиториях. Таким образом в свое время наткнулся на Node. У меня есть аккаунт на вАЙТИ — если возникнут вопросы по статье, пишите в личку. С радостью отвечу.

Еще в студенчестве, слушая подкасты, я узнал про среду выполнения Bun.js. Тогда она была в бета-стадии и только теоретически подавала надежды на то, чтобы составить конкуренцию Node.js и Deno. Тогда я подумал, что это крутая штука, которая однажды может «выстрелить».

Прошло время, я сменил несколько стеков: успел поразрабатывать на .net, позже стал Java-разработчиком. При этом моя любовь к Node не угасала. А в сентябре 2023 года я понял, что оказался прав в своей вере в Bun.js: она вышла в релиз.

Сегодня я расскажу об этой новой среде выполнения, опишу процесс эволюции рантаймов JavaScript и продемонстрирую производительность Bun в сравнении с Node.js.

Привет, Хабр! Мы — Рома, Настя и Карина — бэкенд-разработчики Тинькофф, пишем код на Scala и горим желанием его популяризировать. Мы собираем и агрегируем новости из разных источников, включая Scala Times, блог Petr Zapletal и канал Scala Nishtyaki, добавляем новости и собственные комментарии. Свою мотивацию мы черпаем из желания развиваться и делиться полученными знаниями. Приветствуем любую обратную связь! (づ ◕‿◕ )づ

Электронная подпись, шифрование данных с помощью RSA, AES. Реализация на Kotlin, Micronaut, bouncycastle.

В самом начале своей карьеры я имел честь в одно лицо разрабатывать проект, предназначенный для массового пользователя. Надо сказать, что почти все основополагающие принципы того, как провалить проект, были соблюдены, однако, он до сих пор жив. Проект был предназначен для принудительного использования определенной категорией работников бюджетной сферы. Технического задания, аналитики, дизайн-документов, макетов в Фигме, лавандового смузи, и прочих этих ваших модных слов, без которых N лет назад строили БАМ и Траннсиб не было от слова совсем. Зато, были процессы “в бумаге”, которые требовалось оцифровать. Поэтому то, что можно было принять за ТЗ, выглядело как “Эти (работники) заполняют вот это (бумаги) потом несут тем (проверяющим) а дальше все это хранится, сделай чтобы они с компьютера могли загрузить и отправить, у нас тут целый этаж бумагами занят, пожар начнется - всему хана”. Используя весь свой багаж знаний и опыта в построении высоконагруженных систем (на этом месте я отошел от написания статьи сначала проржаться а потом поплакать), я приступил к реализации.

За время моей недолгой работы инженером-программистом (2,5 года) мне всегда невероятно везло с людьми, которые меня окружали. Я сталкивался с гениальными инженерами, которые, проявляя терпение и оказывая поддержку, делали все возможное, чтобы помочь мне учиться, совершенствоваться и самому становиться лучшим инженером.

В первый день работы в моей первой компании я не понимал, что такое POST-запрос. В начале прошлого года я не знал, что такое GraphQL. До вчерашнего дня я никогда не использовал defer в GoLang.

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

Фараон, вышедший в далеком 1999 году был одной из первых игр, которые предлагали поэтапное строительство зданий. Да которые еще и требовали наличие разных ресурсов. Навскидку могу припомнить серию Settlers, Majesty и может еще парочку. После Цезарь III, исхоженного вдоль и поперек, где основным ресурсом при постройке зданий были монеты, это было действительно удивительно и ново. Особым удовольствием было наблюдать, как город живет своей жизнью в процессе постройки монументов, помню просто построил минимальную необходимую инфраструктуру для монумента и просто наблюдал как архитекторы жаловались на недостаток материалов, рабы бегали то на фермы, то на строительную площадку, торговцы периодически продавали кирпичи. Ну и остальной город, конечно, жил своей жизнью, можно даже забыть на какое время про отдельные части города, игра все равно не остановится, и тут понимаешь почему игра до сих пор остается одним из лучших градостроев: отличительная особенность серии — «баланс», баланс отточенный в мелочах. Восстанавливая эту часть игры, я не перестаю удивляться как это все было реализовано на тех аппаратных средствах, замечу, очень и очень небольших, 64Мб оперативки было далеко не у всех. Одним из нововведений монументов было то, что они были составными зданиями, отдельные части могли быть заменены на другие, что в общем давало возможность из одного набора текстур создавать разные по виду здания. Это сейчас кажется, что такой подход есть в любой игре, но в 99 такой механикой могли похвастаться немногие. Сначала я пытался восстановить оригинальный алгоритм отрисовки, но быстро понял, что столько if не осиливаю не только я, но и компилятор, пришлось велосипедить.

Всем привет. На своем последнем месте работы я выполнял обязанности Java разработчика в одной из команд сервиса, чье приложение установлено в смартфоне большинства жителей РФ. Использовался стандартный стек технологий: Java, Spring(web, jdbc, core), PostgreSQL, Kafka. Обычное синхронное API по работе с данными, без всякой реактивщины, с нагрузкой более миллиона пользователей в день. Я столкнулся с тем что сервисы по работе с БД были обильно «усыпаны» Spring аннотациями @Transactional. Даже одиночные запросы на чтение данных использовали аннотацию с параметром readOnly=true. Я пытался писать комментарии к мердж‑реквестам с вопросом: «зачем вы это делаете?». Но получал ответы из разряда: «для перфоманса», «у нас так принято, чтобы случайно не упустить случай когда транзакция будет действительна нужна», «раньше у нас была какая‑то проблема с коннектами (какая именно никто так и не вспомнил сколько я не пытал), мы везде добавили аннотации и все заработало». Если интересно чем в итоге закончилась эта дискуссия, то подробности далее.

На сайте hackerrank.com есть отличная задача. По заданному массиву short[] A; найти максимальное количество его подмассивов, xor элементов которых будет одинаковым. Сам этот xor тоже нужно найти.

Максимальная длина массива равна 10⁵, так что квадратичный алгоритм не укладывается в лимит по времени исполнения. Я в своё время с этой задачей не справился и сдался, решив подсмотреть авторское решение. И в этот момент я понял почему не справился — автор предлагал решать задачу через дискретное преобразование Фурье.

Наша команда Mobile Doc&Loc «Лаборатории Касперского» занимается подготовкой документации и локализации B2C-продуктов компании для мобильных устройств. Основная сложность (и одновременно фишка) нашей работы заключается в том, что необходимо регулярно подготавливать переводы на 34 языка в крайне сжатые сроки.

Меня зовут Юлиана Соломатина, я — Doc&Loc-инженер, и в этой статье я расскажу про инструменты-автоматизации, которые помогают нам справляться с наплывом задач и укладываться в дедлайны, не жертвуя при этом качеством. Кстати, многие из этих инструментов мы разработали сами.

В данной статье будет показана нестандартная реализация компонентов Vue + Bitrix, которую вряд ли кто то видел и использовал.

Без NPM, без сборщиков и без костылей. Все "нативными" средствами

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

1. Как используется встраивание (embedding) в Go?

В Go директива //go:embed используется для встраивания файлов и папок в бинарный файл Go на этапе компиляции. Эта функция улучшает безопасность, производительность и простоту кода за счёт возможности прямого импорта файлов без использования функций операционной системы.

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

Rust имеет два основных типа макросов: декларативные и процедурные. Каждый из этих типов служит различным целям и предоставляет различные возможности манипуляции с кодом.

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

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

В этой статье мы как раз и рассмотрим то, как их пишут на Rust.

Начнем с декларативных!

Стейт-машины: The Good, The Bad and The Ugly 

Привет! Меня зовут Дарья Андреева, я тимлид в команде бэкенда Биллинга Яндекс 360. Яндекс 360 объединяет такие сервисы, как Диск, Телемост, Почта и другие, в единую экосистему, а мы собираем их в цельный продукт и реализуем функции оплаты и подписочные модели. 

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

Чем дольше работаю, тем больше вижу разнообразных практик по работе с секретами. Некоторые рабочие, другие — нет, а от части просто берёт оторопь. В статье я разберу варианты и расскажу о плюсах и минусах разных подходов.

Поговорим мы о секретах в общем, но с практической точки зрения сфокусируемся именно на работе с секретами на машинах разработчиков: как их туда безопасно доставить и употребить.

Этот текст — продолжение серии CI/CD в каждый дом, в прошлый раз мы обсуждали, как организовать сборочный цех базовых docker-образов.

TL;DR: На dev-тачках должны светиться только персональные/локальные секреты. Короткоживущие секреты лучше вечных. Храним безопасно. Передаём шифрованно. Употребляем сессионно.

Годот, немного костылей и прямые руки (по желанию).

Самый подробный гайд о создании системы инвентаря, без воды, по факту и с кодом!

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

Предисловие

Начнем с того,что я не специалист по Java и у меня нет коммерческого опыта на этом языке. Я просто обычный кодер, который по вечерам пилит проекты на Java, а основной мой стек состоит из PHP и смеси Python + Go. В данной статье хочу с вами поделиться опытом с использованием виртуальных потоках (Virtual Threads) в обработке файлов.