Автор статьи, видимо, забыл (не знал?), что деление на множестве вещественных чисел не ассоциативно :) Уважаемый автор, посмотрите какой-нибудь курс алгебры. Все-таки, систематическое математическое образование - не такая уж плохая вещь
До того, как Эндрю Уайлс доказал великую теорему Ферма, веками существовало скопище т.н. "ферматистов". Похоже, пришел черед "риманистов" в честь Б.Римана.
Автор, без обид, но к таким задачам надо приходить сугубо подготовленным. Скажите, вы читали ну хотя бы книгу Джона Дербишира "Простая одержимость"? Чтобы хотя бы ощутить сложность того, чем вы пытаетесь заниматься.
О, да-да, натюрлих! Пока запросы типа "найти запись по id" или пока глубина джойнов не больше 2-х, то ORM худо бедно попрет. Но в проектах, где БД содержит 1000+ криво спроектированных таблиц да еще без FK или с такими FK, что хрен расплетешь - что на что ссылается (я говорю об унаследованных системах с сотнями миллиардов и больше записей), то медленно (а, может, и не медленно) приходит трындец. Вот всю бизнес-логику фигачить на pl/sql - этого не стоит делать точно. Лучше БД оставить хранение данных, а логику выносить в приложение.
Языки, заточенные под определенные задачи, это DSL. И да, соглашусь, что так и надо делать если, конечно нет каких-то уж очень специфических требований
Сейчас я, возможно, нахватаю люлей, ну да ладно. Скажите, вот вы рассказываете о том, какой у вас успешный бизнес. С рецептурой, расчетами, картинками. Зачем? Что за благотворительность?
Я понимаю, когда бизнес-тренеры окучивают Буратин и лупят бесстыдные деньги, рассказывая обо всем, а фактически ни о чем. Окучивают годами и успешно. Продают воздух. Но вы-то не похожи на продавца воздуха. Вам-то что за резон делиться успешным бизнес-рецептом? Если вы просто бескорыстный человек, то низкий вам поклон.
Марку Твену (хотя это сказал не он, а один немецкий врач начала 19 века) приписывают фразу: "Если лечиться по справочнику, то есть риск умереть от опечатки". Сколько пациентов умрут пока будет производиться настройка? Кто готов рискнуть и доверить себя или своих близких ИИ?
У меня был печальный 2-х летний опыт работы корпоративным архитектором. Срок, конечно, небольшой, но мне хватило.
Первое, что меня неимоверно напрягало - совещания. Два часа в день - это, считай, никаких совещаний и не было. Обычно три-четыре по часу/полтора/два. Т.е. полдня минимум. Если на совещании присутствуют представители бизнеса - то все совсем печально. При всем уважении к ним как к заказчикам, общаться с ними непросто. Они мыслят своими категориями, постоянно сбиваются на посторонние (и важные с их точки зрения) темы; разговор все время уходит в сторону. А архитектору надо все это потом осознать, сложить в голове и перевести на язык, понятный аналитикам и разработчикам.
Второе: очень редко удается собрать все заинтересованные стороны - кто-то в отпуске, кто-то на другой встрече, кто-то в командировке, кто-то занят срочной работой, кто-то с бодуна, кто-то с женой поцапался и ему не до того. Приходится встречаться и обсуждать "по кускам". Вроде с одним договорился, но после встречаешься с другими людьми и оказывается, что нет - все не так. В результате на руках ворох порой противоречивых требований, которые надо между собой увязать, нарисовать и согласовать. Апофеоз наступает когда кто-то увольняется и на его место приходит новый человек. И понеслось все сначала.
Третье - проектов никогда не бывает один; их, как правило, 4-5-6. Разной степени сложности, запущенности, срочности (впрочем, с точки зрения любого заказчика только его проект, действительно, важный и сложный, а остальные - так, баловство). Вертишься между ними как (простите) сопля по сковородке. Не мудрено что-то забыть, перепутать. Работать приходится урывками между встречами. Чтобы хоть что-то оставалось, вел записи. Исписал три больших тетради - реально не раз выручало.
Четвертое - уже в сторону корпоративных архитекторов. Я заметил, что подавляющее большинство из них не имеют адекватного практического опыта системного анализа и разработки. Представление - да, опыта - увы. Может быть, мне не повезло - спорить не стану. Более того, может корпоративным архитекторам это и не нужно? Я этого так и не понял, но когда после разработки пробуешь себя в архитектуре - это сильно удивляет.
Пятое - я заметил, что корпоративные архитекторы любят потрещать о высоких материях, инструментах проектирования, методиках. Добро бы, если бы это находило свое воплощение, но нет - отвели душу и вернулись в свое болотце.
Короче, я мучался-мучался и сбежал обратно - в разработку. Все вышеизложенное - сугубо IMHO. Если кого обидел - простите великодушно.
Итого - два места, где упоминается C#. Хотя ссылка ведет на справочник по C++. По всему тексту вижу только C++. Ругаете, что все плохо, ужасно, кошмарно и не кошерно (кое в чем - справедливо). Так предложите образец аккуратности. А то, действительно, получается "ИТ во мгле"
В порядке бреда. Оставить в интерпретаторе GIL по умолчанию. Чтобы не грохнулись мегатонны наработанного кода. Для новых проектов (и только тогда, когда это действительно кому-то будет нужно) предусмотреть в командной строке флаг, переводящий интерпретатор в режим без GIL. Повторюсь - все это в порядке бреда. Чтобы компетентно на эту тему рассуждать надо быть большим знатоком CPython.
А потом не только учиться, но и опыта набираться сложно, потому как многие погрязли в рутине. Они делают каждый день знакомое дело, потому как им нужно кормить детей. С утра на работу, вечером домой жрать и спать. Почитать, освоить, поучиться просто некогда.
Сложно, да. Это Вы еще не все проблемы перечислили: внуки, пожилые родители. А выросшие дети доставляют порой хлопот куда больше маленьких (народная мудрость: "маленькие детки - маленькие бедки; большие детки - большие бедки" и еще "маленькие детки спать не дают, а с большими сам не уснешь"). Но сдаваться нельзя. Надо осваивать и учиться хотя бы ради этих детей. Как говорил герой одного из фильмов Леонида Гайдая "Надо, Федя, надо!!!"
Ох, и не говорите. Кажется, новый Билли Миллиган уже тут
Автор статьи, видимо, забыл (не знал?), что деление на множестве вещественных чисел не ассоциативно :)
Уважаемый автор, посмотрите какой-нибудь курс алгебры. Все-таки, систематическое математическое образование - не такая уж плохая вещь
До того, как Эндрю Уайлс доказал великую теорему Ферма, веками существовало скопище т.н. "ферматистов". Похоже, пришел черед "риманистов" в честь Б.Римана.
Автор, без обид, но к таким задачам надо приходить сугубо подготовленным. Скажите, вы читали ну хотя бы книгу Джона Дербишира "Простая одержимость"? Чтобы хотя бы ощутить сложность того, чем вы пытаетесь заниматься.
Впрочем, скорее всего, действительно: весна...
Ну, как вариант да. Но напомнило анекдот:
"Объявление в борделе.
Секс - 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. Поэтому я их и не включал в свой список
Сложно, да. Это Вы еще не все проблемы перечислили: внуки, пожилые родители. А выросшие дети доставляют порой хлопот куда больше маленьких (народная мудрость: "маленькие детки - маленькие бедки; большие детки - большие бедки" и еще "маленькие детки спать не дают, а с большими сам не уснешь").
Но сдаваться нельзя. Надо осваивать и учиться хотя бы ради этих детей. Как говорил герой одного из фильмов Леонида Гайдая "Надо, Федя, надо!!!"