В сложных ERP-системах многие сущности имеют иерархическую природу, когда однородные объекты выстраиваются в дерево отношений «предок — потомок» — это и организационная структура предприятия (все эти филиалы, отделы и рабочие группы), и каталог товаров, и участки работ, и география точек продаж,…



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

Существует много способов хранения такого дерева в СУБД, но мы сегодня остановимся только на одном варианте:

CREATE TABLE hier(
  id
    integer
      PRIMARY KEY
, pid
    integer
      REFERENCES hier
, data
    json
);

CREATE INDEX ON hier(pid); -- не забываем, что FK не подразумевает автосоздание индекса, в отличие от PK

И пока вы всматриваетесь в глубину иерархии, она терпеливо ждет, насколько же [не]эффективными окажутся ваши «наивные» способы работы с такой структурой.


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

Несколько лет назад, для закрытия одного их предметов мне довелось перевести данный букварь. Де-факто этот вариант стал официальным переводом. Но развитию этого перевода мешает, тот факт, что он был написан в Google Drive и закрыт на редактирования. Сегодня я уделил время на переформатирования всего этого текста в MD формат с помощью редактора Хабра, с радостью публикую здесь и вскоре отдам текущим контрибьюторам.

Словарь

Node — нода — узел с каким либо ресурсом
Content — контент — данныe
Traffic — трафик — запрос/ответ, данные которые передаются от сервера клиенту и наоборот
Hardware — железо — аппаратная часть
Instance — инстанс — созданный объект какой либо сущности. Например инстанс сервера API
Headers — хедеры — заголовки (как правило TCP пакета, но может быть и HTTP запроса)

---

Предисловие

Однажды в далекой-далекой галактике… потребовалось нам реализовать аутентификацию пользователей с помощью учетной записи ЕСИА на ГосУслугах. Т.к. обитаем мы в галактике .Net, первым делом был изучен весь гугол на предмет готового космолета дабы не костылить все самим, но поиски ни к чему путному не привели. Поэтому решено было изучить тему и реализовать-таки космолет своими силами.

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

В мире C++ я решал подобные штуки очень просто с использованием define и опций компилятора. Но в .Net define не имеют значений кроме true/false, т.е. они либо определены либо нет. Насколько я понимаю, их цель это простейшая условная компиляция.

Кому интересно решение добро пожаловать под кат.

Появление async/await в C# привело к пересмотру того, как писать простой и корректный параллельный код. Зачастую, используя асинхронное программирование, программисты не только не решают проблемы, которые были с потоками, но и привносят новые. Дедлоки и рейсы никуда не пропадают — их просто становится труднее диагностировать.



Дмитрий Иванов — Software Analysis TeamLead в Huawei, в прошлом техлид JetBrains Rider и разработчик ядра ReSharper: структур данных, кэшей, многопоточности, регулярный спикер конференции DotNext.

Под катом — видеозапись и текстовая расшифровка доклада Дмитрия с конференции DotNext 2019 Piter.

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

Платформы непрерывной разработки и интеграции, или CI/CD, сейчас используются повсеместно в тех отраслях, где решающую роль играет итеративность и отлаженность технических процессов. В этой статье речь пойдёт о CI/CD для реализации наших Unity-проектов для мобильной геймдев-разработки: с какими проблемами мы столкнулись, как их удалось решить, каких улучшений мы добились и как прописан наш пайплайн сборок билдов.

Сразу договоримся, что в качестве сервера CI мы используем TeamCity от JetBrains, в качестве хранилища Git-репозиториев ― GitHub, для хранения артефактов сборки ― Nexus.

От переводчика: Это перевод статьи авторства Джоэля Спольски (Joel Spolsky). Через 2 года эта статья уже сможет получить автомобильные права в США, а еще через два — и не только там. Да, ей 14 лет (а точнее 14 лет и 11 дней), но актуальности она не потеряла ни грамма. Я регулярно вижу, как программисты (да и я сам, временами) порываются наступить на эти грабли. Тот факт, что я не нашел ее перевода на Хабре, вполне может свидетельствовать о том, что я плохо искал. Об ошибках перевода прошу сообщать в ЛС

UPD: Оказывается перевод статей Джоэля, в т. ч и этой, есть еще в бумажном издании «Джоэл о программировании»

Наконец выходит первая публичная бета-версия Netscape 6.0. Версии 5.0 не существует. Предыдущий мажорный релиз — версия 4.0 — был выпущен почти три года назад. Три года — это невероятно большой срок в мире интернета. Все это время в Netscape сидели и беспомощно наблюдали за тем, как уменьшается их доля рынка.

Это немного подло с моей стороны критиковать их за столь долгое ожидание между релизами. Они ведь не специально это сделали, правда?

Сейчас я расскажу, как выглядит процесс разработки на Unity в маленькой gamedev компании и как мы его улучшаем и автоматизируем. Всё-таки 2020 год на дворе, хватит уже мышкой водить…

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

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

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

У меня есть довольно большой опыт — в течение последних семи лет я работал только в этом жанре (Cogmind, Cogmind 7DRL, POLYBOT-7, REXPaint, X@COM), и в течение последних пяти эта работа была моей основной. К тому же, все эти годы я помогал превращению r/RoguelikeDev в крупнейшее сетевое сообщество разработчиков roguelike.

Введение

Решая довольно элементарную задачу и не осилив спартанских условий разработки под ESP8266 решил вернуться в уютный мир .Net в котором есть и автодополнение и отладка.

Итак, имеем на руках:

• Компьютер с Windows 10 Pro Build 1803 (однако почти всё написанное ниже можно выполнить и на *nix с минимальными изменениями)
• Orange Pi Zero с установленным Raspbian Server
• Желание писать код на C# и отлаживать на устройстве просто нажав F5

В прошлой статье я описал технологии и подходы, которые мы используем при разработке нового мобильного fast paced шутера. Т.к. это была обзорная и даже поверхностная статья — сегодня я копну глубже и подробно расскажу, почему мы решили написать собственный ECS-фреймворк и не стали использовать существующие. Будут примеры кода и небольшой бонус в конце.

В Unity3D с выходом версии 2018 появилась возможность использовать нативную (для Unity) ECS систему, сдобренную многопоточностью в виде Job System. Материалов в интернете не особо много (пара проектов от самих Unity Technologies да пара обучающих видео на ютубе). Я попробовал осознать масштаб и удобность ECS, сделав небольшой проект не из кубов и кнопок. До этого у меня не было опыта проектирования ECS, так что два дня ушло на изучение материалов и перестроение мышления с ООП, день ушел на восхищение подходом, и еще один-два дня — на разработку проекта, борьбу с Unity, выдергивание волос и курение семплов. В статье содержится немного теории и небольшой пример проекта.

На конференции connect(), мы объявили, что .NET Core будет выпущен полностью как программное обеспечение с открытым исходным кодом. В этой статье мы сделаем обзор .NET Core, расскажем, как мы собираемся его выпускать, как он соотносится с .NET Framework и что это все означает для кросс-платформенной разработки и разработки с открытым кодом.

Поднять свой socks прокси очень просто — справится даже далекий от Linux и серверного администрирования человек. Достаточно иметь VDS/выделенный сервер за границей.


Пошаговая инструкция для запуска своего sockd прокси на Centos7

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

После перехода нашего продукта на Angular 2+ мы столкнулись с тем, что Ангуляр предоставляет свой механизм для описания анимации. Поскольку Ангуляр полностью владеет транзакциями DOM, то он может упростить описание анимации и мы решили попробовать отказаться от анимации на CSS. Да и в целом было интересно посмотреть, что из этого получится. За почти год разработки проекта мы так и не перешли обратно на CSS-анимацию, и я могу сказать, что можно вполне успешно жить с анимацией Ангуляра. В этой статье я расскажу, как использовать анимацию в проектах на Angular 2+ и о возможностях, которые до сих пор почему-то не описаны в официальном гайде.

Если вы не изучали JavaScript с самого начала, то осваивать его современную версию сложно. Экосистема быстро растёт и меняется, так что трудно разобраться с проблемами, для решения которых придуманы разные инструменты. Я начал программировать в 1998-м, но начал понимать JavaScript только в 2014-м. Помню, как просматривал Browserify и смотрел на его слоган:

Browserify позволяет делать require («модули») в браузере, объединяя все ваши зависимости

Я не понял ни слова из предложения и стал разбираться, как это может помочь мне как разработчику.

Цель статьи — рассказать о контексте, в котором инструменты в JavaScript развивались вплоть до 2017-го. Начнём с самого начала и будем делать сайт, как это делали бы динозавры — безо всяких инструментов, на чистом HTML и JavaScript. Постепенно станем вводить разные инструменты, поочерёдно рассматривая решаемые ими проблемы. Благодаря историческому контексту вы сможете адаптироваться к постоянно меняющемуся ландшафту JavaScript и понять его.

Как правильно построить архитектуру приложения, с учетом специфики REST? Было ли с вами такое, что словом «REST» называют любое HTTP API без разбору — и как донести истинное значение этого термина? Как показать, что преимущества REST проявляются в больших долгосрочных проектах, но для небольшой утилиты лучше взять что-то попроще? Эти и другие животрепещущие вопросы освещает Дилан Битти (Dylan Beattie) в докладе «Real world REST and Hands-On Hypermedia».

Дилан — системный архитектор и разрабточик, за жизнь успевший поучаствовать во множестве проектов, от небольших вебсайтов до огромных распределенных систем; от легаси с двадцатилетней историей до самых новейших разработок. Сейчас он работает архитектором в Spotlight и занимается решением сложных задач в современных распределенных системах. Создание правильных, красивых и эффективных HTTP API является частью его работы, и он действительно знает в них толк.

Вы сможете встретиться с Диланом вживую на конференции DotNext Moscow 2017, куда он приедет с новым докладом «Life, liberty and the pursuit of APIness: the secret to happy code». Напоминаем, что вы можете купить билеты по вкусной цене вплоть до 31 октября включительно.

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



Комментарии к статье приветствуются и действительно важны — мы постараемся задать ваши лучшие вопросы напрямую Дилану на DotNext Moscow 2017.

Введение

В этой статье я хочу рассказать об использовании некоторых конструкций, применяющихся для осуществления неблокирующей синхронизации. Речь пойдёт о ключевом слове volatile, функциях VolatileRead, VolatileWrite и MemoryBarrier. Мы рассмотрим, какие проблемы вынуждают нас воспользоваться этими языковыми конструкциями и варианты их решения. При обсуждении барьеров памяти вкратце рассмотрим модель памяти .NET.