Size: a a a

DocOps-сообщество

2019 July 23

SR

Stas Rychkov in DocOps-сообщество
Привет. Не про док и не про опс, но близко в плане способов описания чего-то и связи этого с реальным миром.

https://medium.com/codeiq/object-oriented-programming-the-trillion-dollar-disaster-️-92a4b666c7c7

Что скажете? 🙂
источник

BG

Bogdan (SirEdvin) Gladyshev in DocOps-сообщество
There’s no objective and open evidence that OOP is better than plain procedural programming.

Ох лол
источник

BG

Bogdan (SirEdvin) Gladyshev in DocOps-сообщество
Мне кажется, кто-то давно не пробовал хорошей процедурщины без всякого solid.
источник

M

Max in DocOps-сообщество
Bogdan (SirEdvin) Gladyshev
Мне кажется, кто-то давно не пробовал хорошей процедурщины без всякого solid.
Хмм... А вы прочитали статью?
источник

PD

Phil Delgyado in DocOps-сообщество
Я прочитал, тем более что она не слишком свежая. Там не про ООП, конечно, а про энтерпрайз и 'наиболее популярными становятся наименее удачные решения'. Если энтерпрайз начнет все делать в ФП, то будет ещё хуже (
источник

PD

Phil Delgyado in DocOps-сообщество
Ну или так же хуже )
источник
2019 July 24

BG

Bogdan (SirEdvin) Gladyshev in DocOps-сообщество
Max
Хмм... А вы прочитали статью?
Я еще раз ее пересмотрел по диагонали, а там все те же. Аппеляция к авторитетам, пассажи в стиле "У вас неправильное ООП, а вот тут правильное. И вообще если бы вы взяли ФП!" и так далее. (Очень классно смотрится аппеляция к Линусу, благодаря которому код ядра до сих пор не полностью покрыт тестами)

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

M

Max in DocOps-сообщество
Phil Delgyado
Я прочитал, тем более что она не слишком свежая. Там не про ООП, конечно, а про энтерпрайз и 'наиболее популярными становятся наименее удачные решения'. Если энтерпрайз начнет все делать в ФП, то будет ещё хуже (
Я же не говорю, что в статье "все правильно". Просто первая нападка была очень "мимо кассы".

Но некоторое количество здравых идей я там увидел. Все reactive, observables и binding, без которых сейчас не обходится фронтэнд - это messages, так или иначе.
источник
2019 July 25

IA

Ivan Abashkin in DocOps-сообщество
Ребят, всем привет!
Мы у себя только обдумываем переход на другой подход создания документации.

Подскажите, в чем плюсы-минусы rST по сравнению с Asciidoc? Что лучше начать использовать, если опыта с документацией как код ещё не было?
источник

L

Lana in DocOps-сообщество
Ivan Abashkin
Ребят, всем привет!
Мы у себя только обдумываем переход на другой подход создания документации.

Подскажите, в чем плюсы-минусы rST по сравнению с Asciidoc? Что лучше начать использовать, если опыта с документацией как код ещё не было?
Зависит от списка ваших требований, какие вам нужны элементы в документации
источник

L

Lana in DocOps-сообщество
Что-то в одном языке лучше, что-то в другом, какие таргеты хотите
источник

НН

Нац Нац in DocOps-сообщество
Ivan Abashkin
Ребят, всем привет!
Мы у себя только обдумываем переход на другой подход создания документации.

Подскажите, в чем плюсы-минусы rST по сравнению с Asciidoc? Что лучше начать использовать, если опыта с документацией как код ещё не было?
Если нет опыта, стартаните с markdown. Как упретесь в ограничения - пробуйте тот, в котором есть то, чего нет в md. Аскидок и РСТ со старту могут быть оверкиллами
источник

FM

Fox Mulder in DocOps-сообщество
Нац Нац
Если нет опыта, стартаните с markdown. Как упретесь в ограничения - пробуйте тот, в котором есть то, чего нет в md. Аскидок и РСТ со старту могут быть оверкиллами
Особенно если все эти технологии оплачиваются за 50-60к )
источник

A

Antonio in DocOps-сообщество
Мы вот как раз упёрлись серьезно в ограничения маркдауна. Буду топить за переход на аскидоктор
источник

НН

Нац Нац in DocOps-сообщество
сорта и виды легких языков разметки это как писать для разных аудиторий, каждому нужно своё
источник

ИУ

Илья Улеско in DocOps-сообщество
Нац Нац
Если нет опыта, стартаните с markdown. Как упретесь в ограничения - пробуйте тот, в котором есть то, чего нет в md. Аскидок и РСТ со старту могут быть оверкиллами
А что делать бизнесу в тот момент, когда техпис упрется в ограничения? Что делать потом с готовыми наработками в md?
Или тут расчет на то, что техпис достаточно быстро наткнется на ограничения и не успеет сделать много? )
источник

VS

Vadim Smelyanskiy in DocOps-сообщество
pandoc!
источник

СФ

Семён Факторович in DocOps-сообщество
Ты хотел сказать, pandoc и неопределенное количество доработок напильником:)
источник

НН

Нац Нац in DocOps-сообщество
Или конвертить, как упомянули выше (благо все тулзы опенсорс и делается это с полпинка, качественно и давно) или во время изучения. Благо это не разница а-ля JavaScript vs Go, например, это два вечера тыканий в VSCode
источник

СФ

Семён Факторович in DocOps-сообщество
(как автоматических, так и ручных)
источник