Комментарии

Спасибо за детальное и ясное объяснение этого полезного механизма.

❤

00:00 Вступление
03:52 ГК «Галс-Девелопмент»: как Tangl value ускорил цифровизацию компании и помог в автоматизации расчета объемов работ
10:56 «Ак Барс Дом»: как с помощью Tangl стало возможным получать более 85% объемов работ из ТИМ-моделей, оптимизируя проектирование
19:44 УралДомСтрой: повышение точности и эффективности расчетов с использованием Tangl value
26:45 ТДСК: успешный пилотный проект по внедрению Tangl value для автоматизации процессов проектирования
32:13 Первая в России государственная экспертиза, выполненная только по цифровой информационной модели (ЦИМ) благодаря Tangl control
37:20 АйДи Инжиниринг: выбор Tangl как основной платформы для работы с BIM-данными
41:30 Брусника: обеспечивает независимость от зарубежных вендоров интегрируя Tangl SDK
48:48 Дорожная карта развития Tangl value на 2025 год
57:32 Дорожная карта развития Tangl control на 2025 год
01:04:18 Дорожная карта развития Tangl space на 2025 год
01:07:48 Дорожная карта развития Tangl system на 2025 год
01:11:33 Интеграции с системами управления проектами
01:13:29 Улучшение пользовательских сценариев работ
01:14:30 Что такое Tangl SDK простыми словами и планы развития на 2025 год
01:29:18 Ответы на вопросы
01:35:38 Новогодний конкурс

А можно показать UML диаграмму что мы собственно говоря делаем, а лучше полноценное ТЗ с описанием задачи?

И про Компас забыли

В контексте bim, билдинг — это строительство в широком смысле, а не только здание

20:05 — как то ловко Вы от БИМа перескочили на машиностроение))) Тем временем, тот же Компас используется на многих предприятиях, в чем по-вашему они разрабатывают свои изделия?

вкатунов с быдлокодинга на пхп тяжело на нормальные языки перетащить не просто так чтобы они выучили синтаксис и функции стандартной библиотеки а имели глубокие знания не только о го но и о общем программировании которое не применимо к пхп например потоки, tcp/udp и сисколлы — тестовые на го я бы делал не на написание каких-то рудиментарных рест апи а на что-то более интересное типа задач на конкурентность

Зашел на видео увидев превью — «как я перешел с PHP на golang», я думаю, что ответ на этот вопрос такой — «Отлично перешел!». Так же можно было назвать видео «как я перешел с PHP на любой другой язык?» — «Замечательно перешел!!»

научите меня бесплатно, очень хочется писать приложения работающие годами)

Отличный видос! Будут ли еще задачи с собеседований? Вы отличный наставник.

Здравствуйте! А где обычно берут регистрационный номер для военкомата?

Спасибо большое! Но что за функции «Справочники.БК_ИсточникиДанных.НайтиПоИмени(ИмяИсточника)» И РегистрыСведений.БК_ПараметрыИспользования.Данные(Источник)?

@sergframer Сергей Рафаэльевич! ещё раз большое спасибо за очередной урок. но есть несколько вопросиков:
1) на 15:07 функция НайтиПоИмени из модуля менеджера справочника ИсточникиДанных более-менее понятна (аналогично функции АлгоритмПодключения из того же модуля — правильно?
2) на 16:02 при определении ПараметрыИсточника, когда процедура ПодключитьИсточникДанных обращается к РегСв ПараметрыИспользования — насколько я понимаю, этот регистр Вы более детально распишите на следующем занятии?
3) на 17:21 Вы наверно имели ввиду модуль менеджера справочника Объекты?

Морячёк плавает
— Ответ gpt: Парадигмы vs Принципы vs Паттерны программирования

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

## Парадигмы программирования

Парадигма программирования — это общий подход или стиль программирования, который определяет, как разработчики организуют и структурируют код. Основные парадигмы включают:
1. Императивное программирование: Описание шагов, которые необходимо выполнить для достижения результата (например, C, Java).
2. Декларативное программирование: Описание того, что нужно сделать, без указания, как это сделать (например, SQL, HTML).
3. Объектно-ориентированное программирование (ООП): Организация кода в виде объектов, которые содержат данные и методы (например, Java, C++).
4. Функциональное программирование: Использование функций как основных строительных блоков, акцент на неизменяемость данных (например, Haskell, Scala).
5. Логическое программирование: Основывается на логических выражениях и правилах (например, Prolog).

## Принципы программирования

Принципы программирования — это общие рекомендации и лучшие практики, которые помогают разработчикам создавать качественный и поддерживаемый код. Некоторые из них включают:
1. DRY (Don't Repeat Yourself): Избегайте дублирования кода.
2. KISS (Keep It Simple, Stupid): Стремитесь к простоте в дизайне и реализации.
3. YAGNI (You Aren't Gonna Need It): Не добавляйте функциональность, которая не нужна в данный момент.
4. SOLID: Набор принципов для проектирования объектов в ООП (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion).

## Паттерны программирования

Паттерны программирования — это проверенные решения распространенных проблем, которые возникают в процессе разработки. Они могут быть как высокоуровневыми (архитектурные паттерны), так и низкоуровневыми (проектные паттерны). Примеры:
1. Singleton: Гарантирует, что класс имеет только один экземпляр и предоставляет глобальную точку доступа к нему.
2. Factory Method: Определяет интерфейс для создания объектов, но позволяет подклассам изменять тип создаваемого объекта.
3. Observer: Определяет зависимость «один ко многим» между объектами, так что при изменении состояния одного объекта все зависимые объекты уведомляются и обновляются автоматически.
4. MVC (Model-View-Controller): Архитектурный паттерн, разделяющий приложение на три взаимосвязанные компоненты.

## Заключение
— Парадигмы определяют общий подход к программированию.
— Принципы — это рекомендации для написания качественного кода.
— Паттерны — это готовые решения для распространенных проблем.

Каждая из этих концепций важна для создания эффективного и поддерживаемого программного обеспечения.

Сделайте пожалуйста ролик по работе с API Wildberries и OZON.

Спасибо что продолжаете выкладывать видео на Ютуб.

Еще забыл Идиомы.

Скорее всего есть разные ниши, где-то концентрированный ООП, где-то ФП стиль, а не то, чтобы полноценные какие-то взаимозаменяемые парадигмы. Ибо вот взять REST API, который постоянно принимает и отдаёт какие-то json структуры, что означает их какую-то сериализацию и репрезентацию внутрь приложения. А следовательно уже ФП пролетает мимо со своим стремлением к отсутствию структур. Он не может полностью это реализовать. Ибо это именно что структуро-ориентированность, всё приурочено к данным доменной области, которая состоит из структур и их связей, что по сути основа БД, вокруг которых всё и строится в итоге. То есть смысл какого-то долгоживущего приложения в его персистентном хранилище, которое полностью структурировано и можно сказать именно это объективное обстоятельство порождает ООП естественным образом. И ещё попробуй из него выпрыгнуть. Поэтому мне кажется, что сама эта расхожая постановка вопроса про самостоятельные парадигмы — неверная. Она ставит на одну полку категориально разные вещи. ФП это скорее просто нишевый стиль, как процедурный какой-нибудь, или аспектный. Он не может заменить ООП, он просто акцентировано выносит поведение на видное место, но работать всё равно придётся со структурами данных. Минимизация переменных для человеко-читабельности не значит минимизацию для машино-читабельности. Сама сигнатура любой функции предопределяет что-то принять и что-то вернуть, её запуск уже порождает ссылки на куче, сборщик мусора и что-нибудь такое. А то, что этого не видно для человека это не значит, что этого нету. Череда функций вызываемых друг другом просто скрывает мимолётное создание переменных от читателя. И чем строже типы, тем больше там скрытого контроля над структурами их входов и выходов. В общем, мне кажется это интересной стилистической особенностью, но фундаментально ООП — единственная парадигма. Просто она для своего существования требует некоторой эволюционной развитости экосистемы, поэтому появилась не сразу, в прадедовские времена языка СИ её не было, но тем не менее решение повседневных проблем языка типа СИ с неизбежностью приводит к ООП. Мне кажется, что это потому, что человеческий язык в фундаменте имеет субъект-объектное, а не функциональное устройство. Мы в ООП отражаем какой-то фундамент мышления. И поэтому нет альтернативы этой парадигме. Но это просто моё мнение из интернета, никто не обязан с ним соглашаться

Хорошая структурная подача. Спасибо!