G
Забежал, не разобрался, начал писать... похоже на "ребята где в ваших линуксах диск C ?"
кажется, здесь: ln -s /dev/null 'диск С'
Size: a a a
2020 June 10
S
C/C++ до сих пор себя прекрасно чувствуют и ничто новое полностью не заменило, хотя много нового вполне нашло себе место совместно с C/C++
RT
C/C++ до сих пор себя прекрасно чувствуют и ничто новое полностью не заменило, хотя много нового вполне нашло себе место совместно с C/C++
Я маску только нашел, но по косвенным данным складывается впечатление что часть задач стэка C/C++ постепенно переносится на Rust. Rust по сути и есть новая версия C++, примерно для того же сегмента пользователей.
S
переносится, но и С/C++ остается. Слишком велик объем кода
S
так же как и что-то переносится на Go
S
в том числе с Java
S
но и Java остается
S
и даже MS с их NET Core где-то рядышком живет
S
глобальных убиений технологий было не так много
S
ведь даже Delphi каким-то чудом живет
AP
коллеги, а покидайте пожалуйста ссылок на какие-нибудь внятные обзоры рынка по поводу BI-инструментов
PD
На самом деле, любая концепция "everything as a something" это ошибка, связанная с тем, что её адепт считает всех сотрудников компании такими же, как он.
Почему документирование кодом без обычных документов плохая идея? Потому что код нафиг не упёрлось читать всем, кроме программистов.
Почему архитектурный репозиторий для всего плохая идея? Потому что всей остальной компании, кроме архитекторов, нафиг не упёрлось что-то пытаться понять в этих моделях.
Нарушается самый главный постулат - информация должна быть в формате, понятном читателю, а не писателю.
Почему документирование кодом без обычных документов плохая идея? Потому что код нафиг не упёрлось читать всем, кроме программистов.
Почему архитектурный репозиторий для всего плохая идея? Потому что всей остальной компании, кроме архитекторов, нафиг не упёрлось что-то пытаться понять в этих моделях.
Нарушается самый главный постулат - информация должна быть в формате, понятном читателю, а не писателю.
Ну, docs as code предполагает как раз много разных представлений для разных клиентов.
Для меня ... as code - это про версионирование и про возможность автоматической обработки.
Для меня ... as code - это про версионирование и про возможность автоматической обработки.
PD
kafka KSQL надеюсь скоро заменит большинство старых подходов
А что хорошего в Kafka SQL?
PD
коллеги, а покидайте пожалуйста ссылок на какие-нибудь внятные обзоры рынка по поводу BI-инструментов
Тебя интересует обзор рынка или инструментов?
RT
На самом деле, любая концепция "everything as a something" это ошибка, связанная с тем, что её адепт считает всех сотрудников компании такими же, как он.
Почему документирование кодом без обычных документов плохая идея? Потому что код нафиг не упёрлось читать всем, кроме программистов.
Почему архитектурный репозиторий для всего плохая идея? Потому что всей остальной компании, кроме архитекторов, нафиг не упёрлось что-то пытаться понять в этих моделях.
Нарушается самый главный постулат - информация должна быть в формате, понятном читателю, а не писателю.
Почему документирование кодом без обычных документов плохая идея? Потому что код нафиг не упёрлось читать всем, кроме программистов.
Почему архитектурный репозиторий для всего плохая идея? Потому что всей остальной компании, кроме архитекторов, нафиг не упёрлось что-то пытаться понять в этих моделях.
Нарушается самый главный постулат - информация должна быть в формате, понятном читателю, а не писателю.
Добавлю еще такое наблюдение:
описание “в коде” констатирует как это реализовано, но не отвечает на вопрос “что должно быть реализовано и почему”. Плюс, не описывает межсервисные процессы.
Документация, в моем представлении, в первую очередь описывает:
- задачу в терминах домена прикладной области (problem domain)
- особенности прикладного домена (напр. регуляторные требования)
- требования заказчиков фнукцинальные и нефункциональные
“Документация кода” лишь помогает новичкам быстрее сориентирвоаться в проекте, упрощает передачу проекта в эксплуатацию или на сопрвождение другой команде.
Эти два класса документов практически никогда не смешиваются.
описание “в коде” констатирует как это реализовано, но не отвечает на вопрос “что должно быть реализовано и почему”. Плюс, не описывает межсервисные процессы.
Документация, в моем представлении, в первую очередь описывает:
- задачу в терминах домена прикладной области (problem domain)
- особенности прикладного домена (напр. регуляторные требования)
- требования заказчиков фнукцинальные и нефункциональные
“Документация кода” лишь помогает новичкам быстрее сориентирвоаться в проекте, упрощает передачу проекта в эксплуатацию или на сопрвождение другой команде.
Эти два класса документов практически никогда не смешиваются.
F
Но второе основано через код на первом. Иначе как объяснить зачем все это в коде?
RT
Итого, требования пишут всегда люди, а генерацию схем текущего состояния реализации можно возложить и на машину
F
И как сказать зачем вообще этот код нужен, его импакт.
AP
Добавлю еще такое наблюдение:
описание “в коде” констатирует как это реализовано, но не отвечает на вопрос “что должно быть реализовано и почему”. Плюс, не описывает межсервисные процессы.
Документация, в моем представлении, в первую очередь описывает:
- задачу в терминах домена прикладной области (problem domain)
- особенности прикладного домена (напр. регуляторные требования)
- требования заказчиков фнукцинальные и нефункциональные
“Документация кода” лишь помогает новичкам быстрее сориентирвоаться в проекте, упрощает передачу проекта в эксплуатацию или на сопрвождение другой команде.
Эти два класса документов практически никогда не смешиваются.
описание “в коде” констатирует как это реализовано, но не отвечает на вопрос “что должно быть реализовано и почему”. Плюс, не описывает межсервисные процессы.
Документация, в моем представлении, в первую очередь описывает:
- задачу в терминах домена прикладной области (problem domain)
- особенности прикладного домена (напр. регуляторные требования)
- требования заказчиков фнукцинальные и нефункциональные
“Документация кода” лишь помогает новичкам быстрее сориентирвоаться в проекте, упрощает передачу проекта в эксплуатацию или на сопрвождение другой команде.
Эти два класса документов практически никогда не смешиваются.
Так оно и "как" не констатирует тоже.
Кто задаёт вопрос "как"? Тестировщик, аналитик, админ, солюшен-архитектор, изредка релиз или проджект.
Кто из этих людей будет (не может, а именно будет) читать код? Да никто вообще не будет, конечно же
Кто задаёт вопрос "как"? Тестировщик, аналитик, админ, солюшен-архитектор, изредка релиз или проджект.
Кто из этих людей будет (не может, а именно будет) читать код? Да никто вообще не будет, конечно же