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

А у вас накопились долги?

За 2022 год в Торонто мы потратили более 100 тысяч канадских долларов (или более 80 000 USD). Далее все суммы в статье указаны в канадских долларах (CAD), чтобы перевести их в американские - достаточно просто умножить число на 0.8. Курс этих двух валют достаточно стабилен и на протяжении многих лет меняется незначительно в ту или иную сторону.

В первой части статьи мы обсуждали разработку самого нижнего слоя СУБД Boson - CachedFileIO. Как упоминалось, статистика такого явления как Locality of Reference говорит о том, что в реальных приложениях ~95% запросов к данным локализованы в 10-15% базы данных. При этом среднее соотношение чтения/записи - 70%/30%. Это делает эффективным использование кэша (cache) работающего на основе алгоритма Least Recently Used (LRU). Реализовав его, мы получили 260%-600% прироста скорости чтения при 87%-97% cache hits.

Следующим после кэша слоем СУБД Boson является хранилище записей RecordFileIO. Это уже первый прообраз базы данных, который начинает приносить прикладную пользу. Сформулируем верхнеуровневую спецификацию требований:

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

В статье рассмотрим причины необходимости работы с токеном на клиенте веб-приложений, узнаем ,что лучше для хранения токена: localStorage, sessionStorage или cookie без флага HttpOnly (спойлер, ничего из этого), а также посмотрим на меры воздействия, которые можно использовать для снижения риска утечки токена посредством различных уязвимостей.

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

90% проблем в нашей жизни — это проблемы во взаимоотношениях с другими людьми. Конфликты на работе, сложности в близких отношениях или одиночество из-за страха, что никто не примет тебя с твоими тараканами. И самое неприятное, что для этих проблем характерна бесконечная воспроизводимость.

Какие качества отличают хорошего технического лида? Уверены, как минимум инициативность, стратегическое видение, интерес к новым практикам и инструментам, идущие рука об руку с желанием постоянно развиваться. Немалую роль в lifelong learning техлида могут сыграть правильно подобранные книги.

Немет, Луц, Лав, Танненбаум, Страуструп, Олифер, Лукас — вот лишь некоторые известные авторы, о которых мы сегодня не будем говорить. Надеемся, что раз вы стали лидером технической команды, то с фундаментальной литературой в своей области знаний знакомы не понаслышке.

Под катом рекомендуем 7 изданий о soft-skills, методологиях, управлении командами и проектами.

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

Сразу хочу отметить, что я не являюсь педагогом и у меня вообще нет никакого ни лингвистического, ни педагогического образования. Данной статьей я просто хочу поделиться своей диаграммой по изучению времен, возможно кому-то она будет полезной и поможет в понимании времен и того, как и когда использовать, то или иное время. Данная диаграмма будет поверхностной и не будет углубляться во все подробности языка (и так она получилась огромной), она не охватывает все многообразие времен и конструкций в английском. Уровень данной диаграммы А2-В1.

И сразу начну с диаграммы:

Для кого статья

Вы уже написали свои первые 1000 строк кода и сейчас хотите сделать их понятнее, потому что внесение изменений занимает столько-же времени, сколько написать заново, но советы из ООП, SOLID, clean architecture и т.д. непонятны вам.

О чем статья

Эта статья - не объяснение принципов ООП, SOLID своими словами, а попытка создать промежуточный уровень между никакой и чистой архитектурами. 100% советы будут накладываться друг на друга и перефразировать SOLID, но так даже лучше.

От кого статья

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

Отказ от ответственности

Уверен, каждый пункт из статьи может быть предметом спора, но на то это и вольный пересказ. Вся статья идет под эмблемой "Лучше применить такую архитектуру, чем не применять вообще никакой".

Формат статьи - наводящие советы / вопросы.

В новом тексте по итогам Ruby Russia 2022 Full-Stack разработчик и консультант Learning Tapestry Александр Уланов рассуждает, есть ли у Server-sent events потенциал обойти websocket-ы и long polling.

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

Каждый разработчик "кровавого" enterprise в своей работе использует СУБД (SQL/NoSQL) и меня всегда искренне интересовало как они устроены в самом сердце, на самом низком уровне. Почитав документацию и исходный код SQLite и MongoDB, про используемые в индексах и интерпретаторах запросов алгоритмы, осознал, что несмотря на широкую распространенность и некую привычность, системы управления базами данных (СУБД) - это сложные программные продукты, реализация которых не всем под силу. Отлично - как раз то, что мне надо. С мотивацией разобрались, перейдем к делу.

Итак, для начала хорошо бы сформулировать высокоуровневую спецификацию требований. Boson - это легкая, встраиваемая документоориентированная база данных на С/С++

Локомотивы: традиции Тревитика

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

«Под поверхностью машины движется программа. Без усилий, она расширяется и сжимается. Находясь в великой гармонии, электроны рассеиваются и собираются. Формы на мониторе — лишь рябь на воде. Суть остаётся скрытой внутри…» Мастер Юан-Ма, Книга программирования.

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

Участвую в стартапе, в котором разрабатывается СУБД нового типа (работает поверх некоторых kv-движков, кардинально расширяя их возможности, про это немного можно прочитать здесь). Для того, чтобы сравнить то, что понемногу получается, с тем, что имеется в индустрии, пришлось на глубоком уровне проработать первоисточники по темам Isolation и Consistency (уточню, что имеется ввиду не та Consistency, что в ACID). Обнаружил интересные нюансы, которые и излагаю в этой статье.

Тезисно:

• Термин Phantom Read является продуктом испорченного телефона
• Смысл понятий Lost Update, Write Skew и Read Skew для разделения уровней изоляций неочевиден и относителен
• Движок, который обеспечивает уровень изоляции Serializable, в распределённом мире может вести себя весьма причудливо, например, всегда возвращать пустой результат для read-only транзакций — и ему за это по стандарту "ничего не будет"
• Strong consistency в Cosmos DB — предел мечтаний? (спойлер: нет)

Ну, и ещё кое-что по мелочи. В конце рассмотрим вот такой венец творения человеческого разума:

Нестандартный полиморфизм. Паттерн Type Erasure.

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

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

Итак, что обычно мешает условному джуну подтянуться до условного мидла?

Продолжаем изучать исходный код PostgreSQL

В этот раз исследуем главный цикл сервера:

- Принятие входящих подключений;

- Проверка окружения;

- Обработка упавших воркеров.

Такая история всегда начинается одинаково. Вам показывают демку, в которой набор проблем, ранее казавшийся сложным, решается на раз — достаточно запустить некий Волшебный Инструмент. Зачастую такой инструмент рекомендуют Большие Тузы из отрасли, либо не только рекомендуют, но и сами поддерживают. У вас в организации отыскиваются коллеги, ратующие за то, чтобы немедленно взять эту технологию на вооружение. Буквально наутро этот новый инструмент приравнивается к «решению всех наших проблем».

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

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

В последние годы команда .NET усиленно рекламирует ASP.NET Core как один из самых быстрых веб-фреймворков на рынке. Источником этих утверждений всегда были бенчмарки TechEmpower Framework Benchmarks.

Скотт Хантер - директор по управлению программами .NET, утверждает, что .NET более чем в 10 раз быстрее, чем Node.js.

Скотт также утверждает, что .NET быстрее, чем Java, Go и даже C++.