О, да-да, натюрлих! Пока запросы типа "найти запись по id" или пока глубина джойнов не больше 2-х, то ORM худо бедно попрет. Но в проектах, где БД содержит 1000+ криво спроектированных таблиц да еще без FK или с такими FK, что хрен расплетешь - что на что ссылается (я говорю об унаследованных системах с сотнями миллиардов и больше записей), то медленно (а, может, и не медленно) приходит трындец. Вот всю бизнес-логику фигачить на pl/sql - этого не стоит делать точно. Лучше БД оставить хранение данных, а логику выносить в приложение.
Языки, заточенные под определенные задачи, это DSL. И да, соглашусь, что так и надо делать если, конечно нет каких-то уж очень специфических требований
Сейчас я, возможно, нахватаю люлей, ну да ладно. Скажите, вот вы рассказываете о том, какой у вас успешный бизнес. С рецептурой, расчетами, картинками. Зачем? Что за благотворительность?
Я понимаю, когда бизнес-тренеры окучивают Буратин и лупят бесстыдные деньги, рассказывая обо всем, а фактически ни о чем. Окучивают годами и успешно. Продают воздух. Но вы-то не похожи на продавца воздуха. Вам-то что за резон делиться успешным бизнес-рецептом? Если вы просто бескорыстный человек, то низкий вам поклон.
Марку Твену (хотя это сказал не он, а один немецкий врач начала 19 века) приписывают фразу: "Если лечиться по справочнику, то есть риск умереть от опечатки". Сколько пациентов умрут пока будет производиться настройка? Кто готов рискнуть и доверить себя или своих близких ИИ?
У меня был печальный 2-х летний опыт работы корпоративным архитектором. Срок, конечно, небольшой, но мне хватило.
Первое, что меня неимоверно напрягало - совещания. Два часа в день - это, считай, никаких совещаний и не было. Обычно три-четыре по часу/полтора/два. Т.е. полдня минимум. Если на совещании присутствуют представители бизнеса - то все совсем печально. При всем уважении к ним как к заказчикам, общаться с ними непросто. Они мыслят своими категориями, постоянно сбиваются на посторонние (и важные с их точки зрения) темы; разговор все время уходит в сторону. А архитектору надо все это потом осознать, сложить в голове и перевести на язык, понятный аналитикам и разработчикам.
Второе: очень редко удается собрать все заинтересованные стороны - кто-то в отпуске, кто-то на другой встрече, кто-то в командировке, кто-то занят срочной работой, кто-то с бодуна, кто-то с женой поцапался и ему не до того. Приходится встречаться и обсуждать "по кускам". Вроде с одним договорился, но после встречаешься с другими людьми и оказывается, что нет - все не так. В результате на руках ворох порой противоречивых требований, которые надо между собой увязать, нарисовать и согласовать. Апофеоз наступает когда кто-то увольняется и на его место приходит новый человек. И понеслось все сначала.
Третье - проектов никогда не бывает один; их, как правило, 4-5-6. Разной степени сложности, запущенности, срочности (впрочем, с точки зрения любого заказчика только его проект, действительно, важный и сложный, а остальные - так, баловство). Вертишься между ними как (простите) сопля по сковородке. Не мудрено что-то забыть, перепутать. Работать приходится урывками между встречами. Чтобы хоть что-то оставалось, вел записи. Исписал три больших тетради - реально не раз выручало.
Четвертое - уже в сторону корпоративных архитекторов. Я заметил, что подавляющее большинство из них не имеют адекватного практического опыта системного анализа и разработки. Представление - да, опыта - увы. Может быть, мне не повезло - спорить не стану. Более того, может корпоративным архитекторам это и не нужно? Я этого так и не понял, но когда после разработки пробуешь себя в архитектуре - это сильно удивляет.
Пятое - я заметил, что корпоративные архитекторы любят потрещать о высоких материях, инструментах проектирования, методиках. Добро бы, если бы это находило свое воплощение, но нет - отвели душу и вернулись в свое болотце.
Короче, я мучался-мучался и сбежал обратно - в разработку. Все вышеизложенное - сугубо IMHO. Если кого обидел - простите великодушно.
Итого - два места, где упоминается C#. Хотя ссылка ведет на справочник по C++. По всему тексту вижу только C++. Ругаете, что все плохо, ужасно, кошмарно и не кошерно (кое в чем - справедливо). Так предложите образец аккуратности. А то, действительно, получается "ИТ во мгле"
В порядке бреда. Оставить в интерпретаторе GIL по умолчанию. Чтобы не грохнулись мегатонны наработанного кода. Для новых проектов (и только тогда, когда это действительно кому-то будет нужно) предусмотреть в командной строке флаг, переводящий интерпретатор в режим без GIL. Повторюсь - все это в порядке бреда. Чтобы компетентно на эту тему рассуждать надо быть большим знатоком CPython.
А потом не только учиться, но и опыта набираться сложно, потому как многие погрязли в рутине. Они делают каждый день знакомое дело, потому как им нужно кормить детей. С утра на работу, вечером домой жрать и спать. Почитать, освоить, поучиться просто некогда.
Сложно, да. Это Вы еще не все проблемы перечислили: внуки, пожилые родители. А выросшие дети доставляют порой хлопот куда больше маленьких (народная мудрость: "маленькие детки - маленькие бедки; большие детки - большие бедки" и еще "маленькие детки спать не дают, а с большими сам не уснешь"). Но сдаваться нельзя. Надо осваивать и учиться хотя бы ради этих детей. Как говорил герой одного из фильмов Леонида Гайдая "Надо, Федя, надо!!!"
Ну понятно же, что так и должно быть. До кризиса было условно 10 специалистов, каждый из которых получал условно по 150 тысяч. Т.е. средняя зарплата была 150 тысяч/месяц. Но это были именно специалисты.
Потом прибежало 100 человек с корочками от курсов. Им больше 75 не дают. Простой подсчет показывает: (10 * 150 + 100 * 75) / (10 + 100) = 82 тысяч в среднем. Очень напоминает среднюю температуру по больнице. Все числа условные, но тенденцию, как мне кажется - показывают.
Не вполне так. Я не делал и физически не мог делать все расчеты за все КБ. Те, кому было положено, считали на калькуляторах и логарифмических линейках. Были очень развиты методы ручного расчета, ныне, вероятно, уже утраченные. Были пособия, справочники, номограммы, методики. И считали очень даже качественно.
Потом, с приходом компьютеров, эту задачу "переложили" на них. Я застал довольно ранние этапы этого перехода, но не задержался, а ушел в другую область
Вы задали вопрос на миллион:) К стыду своему, я практически ничего об этом не помню. Какие-то обрывки и все. Но все-таки, кое-что на память пришло. Я покопался в своих архивах и нашел таки пару книг, которые мне реально помогли. Первая книга: "Модели из кубиков", автор Маквецов, 1978, изд. "Советское радио". Вполне популярное изложение расчетов теплопередачи методом конечных разностей. Тут больше физики, чем математики, но книга очень интересная, с великолепными и веселыми иллюстрациями. Вторая: "Расчет машиностроительных конструкций на прочность и жесткость", авторы Шапошников, Тарабасов, Петров и Мяченков, 1981, изд "Машиностроение". Вот тут я и нашел то, что надо: необходимый минимум по теории, а главное - листинги программ на PL/1 для ЕС ЭВМ. В том числе и способы разбиения конструкций на элементарные фигуры и их представление в памяти. Воспользоваться 1:1 всем этим не получилось (мой опыт был еще весьма невелик), но основные идеи я понял. Методом научного тыка мне удалось сделать то, что надо (по весьма упрощенной схеме).
Повторюсь, деталей я не помню совсем. Самому жалко, что все это вылетело из головы, но примите во внимание то, что все это было больше 30 лет назад :)
Ну, как вариант да. Но напомнило анекдот:
"Объявление в борделе.
Секс - 100 баксов
Наблюдение за сексом - 200 баксов
Наблюдение за наблюдающим за сексом - 500 баксов"
О, да-да, натюрлих! Пока запросы типа "найти запись по id" или пока глубина джойнов не больше 2-х, то ORM худо бедно попрет. Но в проектах, где БД содержит 1000+ криво спроектированных таблиц да еще без FK или с такими FK, что хрен расплетешь - что на что ссылается (я говорю об унаследованных системах с сотнями миллиардов и больше записей), то медленно (а, может, и не медленно) приходит трындец. Вот всю бизнес-логику фигачить на pl/sql - этого не стоит делать точно. Лучше БД оставить хранение данных, а логику выносить в приложение.
Языки, заточенные под определенные задачи, это DSL. И да, соглашусь, что так и надо делать если, конечно нет каких-то уж очень специфических требований
Сейчас я, возможно, нахватаю люлей, ну да ладно. Скажите, вот вы рассказываете о том, какой у вас успешный бизнес. С рецептурой, расчетами, картинками. Зачем? Что за благотворительность?
Я понимаю, когда бизнес-тренеры окучивают Буратин и лупят бесстыдные деньги, рассказывая обо всем, а фактически ни о чем. Окучивают годами и успешно. Продают воздух. Но вы-то не похожи на продавца воздуха. Вам-то что за резон делиться успешным бизнес-рецептом? Если вы просто бескорыстный человек, то низкий вам поклон.
Надеюсь, что нет. Но уверенности нет
Марку Твену (хотя это сказал не он, а один немецкий врач начала 19 века) приписывают фразу: "Если лечиться по справочнику, то есть риск умереть от опечатки". Сколько пациентов умрут пока будет производиться настройка? Кто готов рискнуть и доверить себя или своих близких ИИ?
У меня был печальный 2-х летний опыт работы корпоративным архитектором. Срок, конечно, небольшой, но мне хватило.
Первое, что меня неимоверно напрягало - совещания. Два часа в день - это, считай, никаких совещаний и не было. Обычно три-четыре по часу/полтора/два. Т.е. полдня минимум. Если на совещании присутствуют представители бизнеса - то все совсем печально. При всем уважении к ним как к заказчикам, общаться с ними непросто. Они мыслят своими категориями, постоянно сбиваются на посторонние (и важные с их точки зрения) темы; разговор все время уходит в сторону. А архитектору надо все это потом осознать, сложить в голове и перевести на язык, понятный аналитикам и разработчикам.
Второе: очень редко удается собрать все заинтересованные стороны - кто-то в отпуске, кто-то на другой встрече, кто-то в командировке, кто-то занят срочной работой, кто-то с бодуна, кто-то с женой поцапался и ему не до того. Приходится встречаться и обсуждать "по кускам". Вроде с одним договорился, но после встречаешься с другими людьми и оказывается, что нет - все не так. В результате на руках ворох порой противоречивых требований, которые надо между собой увязать, нарисовать и согласовать. Апофеоз наступает когда кто-то увольняется и на его место приходит новый человек. И понеслось все сначала.
Третье - проектов никогда не бывает один; их, как правило, 4-5-6. Разной степени сложности, запущенности, срочности (впрочем, с точки зрения любого заказчика только его проект, действительно, важный и сложный, а остальные - так, баловство). Вертишься между ними как (простите) сопля по сковородке. Не мудрено что-то забыть, перепутать. Работать приходится урывками между встречами. Чтобы хоть что-то оставалось, вел записи. Исписал три больших тетради - реально не раз выручало.
Четвертое - уже в сторону корпоративных архитекторов. Я заметил, что подавляющее большинство из них не имеют адекватного практического опыта системного анализа и разработки. Представление - да, опыта - увы. Может быть, мне не повезло - спорить не стану. Более того, может корпоративным архитекторам это и не нужно? Я этого так и не понял, но когда после разработки пробуешь себя в архитектуре - это сильно удивляет.
Пятое - я заметил, что корпоративные архитекторы любят потрещать о высоких материях, инструментах проектирования, методиках. Добро бы, если бы это находило свое воплощение, но нет - отвели душу и вернулись в свое болотце.
Короче, я мучался-мучался и сбежал обратно - в разработку. Все вышеизложенное - сугубо IMHO. Если кого обидел - простите великодушно.
Вот тут https://habr.com/ru/companies/piter/articles/506872/ был обзор отличной книги в которой есть целая глава, посвященная созданию собственных стартеров. Правда, для 2-й версии бута
Итого - два места, где упоминается C#. Хотя ссылка ведет на справочник по C++. По всему тексту вижу только C++. Ругаете, что все плохо, ужасно, кошмарно и не кошерно (кое в чем - справедливо). Так предложите образец аккуратности. А то, действительно, получается "ИТ во мгле"
Почему люди не делают бэкапы?
Потому что дураки неистребимы
Да? А мужики-то не знали. Попытка перекинуть проблему на кого-то?
Вот это, пожалуй, единственный разумно выглядящий вывод.
И да, в глазах рябит от стейкхолдеров и прочей терминологической эквилибристики
Вот тут https://www.ibiblio.org/pub/academic/computer-science/history/ и тут https://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp11/ полно старой документации
Присоединяюсь: руководства от Borland были великолепны
В порядке бреда. Оставить в интерпретаторе GIL по умолчанию. Чтобы не грохнулись мегатонны наработанного кода. Для новых проектов (и только тогда, когда это действительно кому-то будет нужно) предусмотреть в командной строке флаг, переводящий интерпретатор в режим без GIL.
Повторюсь - все это в порядке бреда. Чтобы компетентно на эту тему рассуждать надо быть большим знатоком CPython.
И, кажется, не "metric", а "metrics"
Книги В.Фаронова хороши, но они были посвящены определенной реализации - Turbo Pascal. Поэтому я их и не включал в свой список
Сложно, да. Это Вы еще не все проблемы перечислили: внуки, пожилые родители. А выросшие дети доставляют порой хлопот куда больше маленьких (народная мудрость: "маленькие детки - маленькие бедки; большие детки - большие бедки" и еще "маленькие детки спать не дают, а с большими сам не уснешь").
Но сдаваться нельзя. Надо осваивать и учиться хотя бы ради этих детей. Как говорил герой одного из фильмов Леонида Гайдая "Надо, Федя, надо!!!"
Ну понятно же, что так и должно быть. До кризиса было условно 10 специалистов, каждый из которых получал условно по 150 тысяч. Т.е. средняя зарплата была 150 тысяч/месяц. Но это были именно специалисты.
Потом прибежало 100 человек с корочками от курсов. Им больше 75 не дают. Простой подсчет показывает: (10 * 150 + 100 * 75) / (10 + 100) = 82 тысяч в среднем.
Очень напоминает среднюю температуру по больнице. Все числа условные, но тенденцию, как мне кажется - показывают.
Не вполне так. Я не делал и физически не мог делать все расчеты за все КБ. Те, кому было положено, считали на калькуляторах и логарифмических линейках. Были очень развиты методы ручного расчета, ныне, вероятно, уже утраченные. Были пособия, справочники, номограммы, методики. И считали очень даже качественно.
Потом, с приходом компьютеров, эту задачу "переложили" на них. Я застал довольно ранние этапы этого перехода, но не задержался, а ушел в другую область
Вы задали вопрос на миллион:) К стыду своему, я практически ничего об этом не помню. Какие-то обрывки и все. Но все-таки, кое-что на память пришло. Я покопался в своих архивах и нашел таки пару книг, которые мне реально помогли. Первая книга: "Модели из кубиков", автор Маквецов, 1978, изд. "Советское радио". Вполне популярное изложение расчетов теплопередачи методом конечных разностей. Тут больше физики, чем математики, но книга очень интересная, с великолепными и веселыми иллюстрациями. Вторая: "Расчет машиностроительных конструкций на прочность и жесткость", авторы Шапошников, Тарабасов, Петров и Мяченков, 1981, изд "Машиностроение". Вот тут я и нашел то, что надо: необходимый минимум по теории, а главное - листинги программ на PL/1 для ЕС ЭВМ. В том числе и способы разбиения конструкций на элементарные фигуры и их представление в памяти. Воспользоваться 1:1 всем этим не получилось (мой опыт был еще весьма невелик), но основные идеи я понял. Методом научного тыка мне удалось сделать то, что надо (по весьма упрощенной схеме).
Повторюсь, деталей я не помню совсем. Самому жалко, что все это вылетело из головы, но примите во внимание то, что все это было больше 30 лет назад :)