Турбопаскаль это и IDE и компилятор. При этом и то, и другое отличалось немного от Borland Pascal, который был дороже, и выходил за стандарты языка Pascal. Другое дело, что как и с C++, компилятор далеко не лучший. А убили его появление Delphi с его Object Pascal и отказ Borland от дальнейшей поддержки турбика, что эволюционно не верное решение.
PS: а еще Turbo Pascal был лучшим, для программирования... на ассемблере под х86 )))
"Мы начинали с дорогих красок, думали, это будет стоит чуть дороже, зато классно, но молочные заводы отказались" - дело в замене краски. Не исключаю, что оборудование для начала нужно промывать.
Странный разговор... Ок. Берем калькулятор. Простой оборудования 10% это: снижение производства на 10%, из-за чего происходит снижение расходов на сырье на 10%. В общей сложности, расходы будут 245 миллионов (другие расходы не снижаются) на производство + 10 миллионов долги + 7 миллионов (меньше, снижение налога на прибыль, но не фатально) налоги. Итого: 262 миллиона расходов при 270 миллионах выручки. Снижение чистой прибыли - с 17 до 8 миллионов (не 10%, а больше чем в 2 раза!), снижение рентабельности продаж с 5.7 до 2.96 процента. Да, если у рынка не будет запроса на эту продукцию, нет смысла городить вторую линию. Но даже при наличии такого запроса - нельзя создавать простой. Маржа слишком маленькая, можно выехать только на объеме.
Не понял Вашей математики. Простой оборудования в 10% говорит о недополученной в итоге выручке в 10%. Что в месяц составляет 30 миллионов. При цене печатного станка в 87.5. Время окупаемости станка в этом случае - 3 месяца, что смехотворно для любого бизнеса. Потому, видимо, и поставили. И нет, 50% простоя не образуется, при наличии заказов под этот станок.
Что-то мне подсказывает, что простой оборудования при перенастройке "дёшево"-"дорого" может стоить столько, что в итоге получится "дорого" и "очень дорого". Те, кто работал с ризографами, поймут. Там нельзя сделать больше/меньше краски, матрицы менять надо. А матрица сама по себе вещь не дешёвая.
Решается покупкой bluetooth микро клавиатуры. Братья-китайцы уже позаботились о таких людях.
Видео-контент ограничивается исключительно рилсами и тиктоками? Я, к примеру, регулярно в видеоконференциях с телефона учувствую. Кино смотрю. Обучающие курсы.
Дольше чем у обычного смартфона, но не долгое. По мимо экрана есть еще аппаратная часть, которая не хило кушает батарею. В целом, не думаю что он будет жить сильно дольше обычного смартфона с 6000 махами в штатном для телефона режиме использования.
Для чтения текстов экран маловат. Проще электронную книжку купить. Вместе со смартфоном все равно дешевле получится.
Тут вопрос не в том, что данный телефон плохой или еще что-то. Мне просто не понятно ценообразование и целевая аудитория с такой ценой.
Категорически не понял, какие преимущества у этого телефона за 40 тысяч рублей перед китайцем типа Redmi 13C за 8 тысяч рублей. Физическая клавиатура в ущерб размеру и цветности экрана? Ну такое себе.
"Есть много интерпретируемых языков - ... , но самый быстрый из них Java."
Автора ни в одном месте не смущает, что Java никогда не был интерпретируемым языком? Как в 1995, когда он только появился, так и сейчас java-код транслируется в байт-код.
Никогда не понимал желание аналитика залезть в области, где ему делать нечего. Ваша обязанность - описать пользовательские сценарии, и результаты выполнения этих сценариев. Для этого вообще не нужны ни Swagger в частности, ни OpenAPI в целом. Поскольку тот же Swagger никак не может описать изменения в БД после выполнения сценария. А оно как бы надо. Ну и 2 ОЧЕНЬ больших косяка (это как пример, на самом деле их даже не десяток) у вас лично, при попытке влезть в чужую предметную область:
Ограничение на catId стоит только not null. Подскажите, он у вас действительно может быть отрицательным? Зачем? Это была неудачная попытка влезть в область системного архитектора.
Поля с датами у вас date_created и date_updated. Жестко прописаны. Например в Laravel эти поля по умолчанию называются created_at и updated_at. Таким образом вы создаете абсолютно ненужную работу программисту, залезая в его область.
Ну и как добрый совет, почитайте уже наконец про BDD (Behavior-driven development). Вот это уже сильно ближе к работе аналитика, нежели перенос описашек из Сваггера в Конфлюенс.
Хм… Конфиденциальны ли, к примеру, персональные данные вы тоже определяете для себя сами? А сведения, составляяющие адвокатскую или врачебную тайну?
Единственное, что вы можете сами определить — набор сведений, составляющих коммерческую тайну, если это не противоречит законодательству (объявить коммерческой, как многие это любят делать, тайной зарплату сотрудника нельзя, например). Не путайте эти понятия.
А еще адекватный взрослый человек должен прекрасно понимать, что никому "там" он не нужен без профильного образования, опыта работы, рекомендаций, портфолио (не обязательно все пункты сразу). Ну и ещё момент: очень сложно вот так вот взять и кардинально поменять свою жизнь, когда в ней столько якорей. Это я если что про ребенка, который уже с репетитором занимается. Так что согласен с вами, статья с большой долей вероятности ничего общего с действительностью не имеет.
Жил был программист. Программист как программист, уровня миддл или даже выше. Но была с ним одно беда — не любил он хранимую рутину. Не, триггер на получение ключа из сиквенса он еще написать мог, но все что больше — считал плохим тоном. Ибо логика должна была быть на миддл-слое. И получил он как-то раз задачу, обновить данные в неком дереве, которое представляло из себя сеть Петри. Только обновить данные нужно было хитро, в зависимости от результата агрегации данных нижестоящих узлов. Ну и решил он задачку как обычно. А потом остался он без премии, и чуть не остался без работы. Поскольку мозг нужно включать, и понимать, что иногда накладные расходы на многократную передачу данных на сторону, агрегацию их там и последующее их обновление могут быть такими, что будут по сути Dos-атакой. База лежала 4 часа.
Вот и вся сказка.
ПС: а еще он забыл отключить индексы, за что ему поставили отдельный памятник.
Они не денормализованы, они разрежены. Это 2 разных термина, и означают они немного разные вещи. Хотя внешне это похоже. Что же касается "не умели SQL", то тут проблема в том, что языка структурных запросов просто недостаточно для работы с OLAP-кубами. Формально, нормально транслировать их научилась только одна СУБД (Oracle). Для всех остальных это ад, и OLAP для них этот как правило отдельное ПО, которое базу использует только как хранилище. И да, в качестве хранилища можно использовать noSQL решения, но реализация MOLAP (на многомерных структурах) по сути является костылем, и в разы сложнее реализации ROLAP (на реляционных структурах).
Нет. Описанием OLAP-куба является "проекция отношений фактов". Что само по себе термин из реляционной алгебры. Ну и хронологически, OLAP-кубы существовали до появления современных noSQL решений.
Поверьте, в накладные расходы уровня сети/памяти вы в приведенном кейсе упретесь в разы быстрее, нежели в производительность БД. Собственно, у Oracle есть нативные витрины данных для OLAP из коробки, и с ними никогда не было никаких проблем.
Ни в коем случае. Есть нативные средства. К примеру, для Oracle — это гетерогенные службы (heterogeneous services). Только вот если мы говорим о способе общения как у сервисов (а один сервис ничего не знает о состоянии другого, и общение идет через апи) то это скорее transparent gateways или rpc (один инстанс базы вполне в состоянии дернуть хранимую другого инстанса и ничего не знать при этом о структурах данных второго, что как раз ближе всего к сервисной архитектуре).
А применять правила НЕ хай-лоад разработки для всей разработки корректно? И, на секундочку, в описанном мной кейсе уровень хай-лоада приблизительно равен нулю.
Турбопаскаль это и IDE и компилятор. При этом и то, и другое отличалось немного от Borland Pascal, который был дороже, и выходил за стандарты языка Pascal. Другое дело, что как и с C++, компилятор далеко не лучший. А убили его появление Delphi с его Object Pascal и отказ Borland от дальнейшей поддержки турбика, что эволюционно не верное решение.
PS: а еще Turbo Pascal был лучшим, для программирования... на ассемблере под х86 )))
"Мы начинали с дорогих красок, думали, это будет стоит чуть дороже, зато классно, но молочные заводы отказались" - дело в замене краски. Не исключаю, что оборудование для начала нужно промывать.
Странный разговор... Ок. Берем калькулятор. Простой оборудования 10% это: снижение производства на 10%, из-за чего происходит снижение расходов на сырье на 10%. В общей сложности, расходы будут 245 миллионов (другие расходы не снижаются) на производство + 10 миллионов долги + 7 миллионов (меньше, снижение налога на прибыль, но не фатально) налоги. Итого: 262 миллиона расходов при 270 миллионах выручки. Снижение чистой прибыли - с 17 до 8 миллионов (не 10%, а больше чем в 2 раза!), снижение рентабельности продаж с 5.7 до 2.96 процента. Да, если у рынка не будет запроса на эту продукцию, нет смысла городить вторую линию. Но даже при наличии такого запроса - нельзя создавать простой. Маржа слишком маленькая, можно выехать только на объеме.
Не понял Вашей математики. Простой оборудования в 10% говорит о недополученной в итоге выручке в 10%. Что в месяц составляет 30 миллионов. При цене печатного станка в 87.5. Время окупаемости станка в этом случае - 3 месяца, что смехотворно для любого бизнеса. Потому, видимо, и поставили. И нет, 50% простоя не образуется, при наличии заказов под этот станок.
Что-то мне подсказывает, что простой оборудования при перенастройке "дёшево"-"дорого" может стоить столько, что в итоге получится "дорого" и "очень дорого". Те, кто работал с ризографами, поймут. Там нельзя сделать больше/меньше краски, матрицы менять надо. А матрица сама по себе вещь не дешёвая.
Не за 40 тысяч.
Решается покупкой bluetooth микро клавиатуры. Братья-китайцы уже позаботились о таких людях.
Видео-контент ограничивается исключительно рилсами и тиктоками? Я, к примеру, регулярно в видеоконференциях с телефона учувствую. Кино смотрю. Обучающие курсы.
Дольше чем у обычного смартфона, но не долгое. По мимо экрана есть еще аппаратная часть, которая не хило кушает батарею. В целом, не думаю что он будет жить сильно дольше обычного смартфона с 6000 махами в штатном для телефона режиме использования.
Для чтения текстов экран маловат. Проще электронную книжку купить. Вместе со смартфоном все равно дешевле получится.
Тут вопрос не в том, что данный телефон плохой или еще что-то. Мне просто не понятно ценообразование и целевая аудитория с такой ценой.
Категорически не понял, какие преимущества у этого телефона за 40 тысяч рублей перед китайцем типа Redmi 13C за 8 тысяч рублей. Физическая клавиатура в ущерб размеру и цветности экрана? Ну такое себе.
"Есть много интерпретируемых языков - ... , но самый быстрый из них Java."
Автора ни в одном месте не смущает, что Java никогда не был интерпретируемым языком? Как в 1995, когда он только появился, так и сейчас java-код транслируется в байт-код.
Никогда не понимал желание аналитика залезть в области, где ему делать нечего. Ваша обязанность - описать пользовательские сценарии, и результаты выполнения этих сценариев. Для этого вообще не нужны ни Swagger в частности, ни OpenAPI в целом. Поскольку тот же Swagger никак не может описать изменения в БД после выполнения сценария. А оно как бы надо. Ну и 2 ОЧЕНЬ больших косяка (это как пример, на самом деле их даже не десяток) у вас лично, при попытке влезть в чужую предметную область:
Ограничение на catId стоит только not null. Подскажите, он у вас действительно может быть отрицательным? Зачем? Это была неудачная попытка влезть в область системного архитектора.
Поля с датами у вас date_created и date_updated. Жестко прописаны. Например в Laravel эти поля по умолчанию называются created_at и updated_at. Таким образом вы создаете абсолютно ненужную работу программисту, залезая в его область.
Ну и как добрый совет, почитайте уже наконец про BDD (Behavior-driven development). Вот это уже сильно ближе к работе аналитика, нежели перенос описашек из Сваггера в Конфлюенс.
Единственное, что вы можете сами определить — набор сведений, составляющих коммерческую тайну, если это не противоречит законодательству (объявить коммерческой, как многие это любят делать, тайной зарплату сотрудника нельзя, например). Не путайте эти понятия.
А еще адекватный взрослый человек должен прекрасно понимать, что никому "там" он не нужен без профильного образования, опыта работы, рекомендаций, портфолио (не обязательно все пункты сразу). Ну и ещё момент: очень сложно вот так вот взять и кардинально поменять свою жизнь, когда в ней столько якорей. Это я если что про ребенка, который уже с репетитором занимается. Так что согласен с вами, статья с большой долей вероятности ничего общего с действительностью не имеет.
Давайте расскажу сказку на ночь.
Жил был программист. Программист как программист, уровня миддл или даже выше. Но была с ним одно беда — не любил он хранимую рутину. Не, триггер на получение ключа из сиквенса он еще написать мог, но все что больше — считал плохим тоном. Ибо логика должна была быть на миддл-слое. И получил он как-то раз задачу, обновить данные в неком дереве, которое представляло из себя сеть Петри. Только обновить данные нужно было хитро, в зависимости от результата агрегации данных нижестоящих узлов. Ну и решил он задачку как обычно. А потом остался он без премии, и чуть не остался без работы. Поскольку мозг нужно включать, и понимать, что иногда накладные расходы на многократную передачу данных на сторону, агрегацию их там и последующее их обновление могут быть такими, что будут по сути Dos-атакой. База лежала 4 часа.
Вот и вся сказка.
ПС: а еще он забыл отключить индексы, за что ему поставили отдельный памятник.
Они не денормализованы, они разрежены. Это 2 разных термина, и означают они немного разные вещи. Хотя внешне это похоже. Что же касается "не умели SQL", то тут проблема в том, что языка структурных запросов просто недостаточно для работы с OLAP-кубами. Формально, нормально транслировать их научилась только одна СУБД (Oracle). Для всех остальных это ад, и OLAP для них этот как правило отдельное ПО, которое базу использует только как хранилище. И да, в качестве хранилища можно использовать noSQL решения, но реализация MOLAP (на многомерных структурах) по сути является костылем, и в разы сложнее реализации ROLAP (на реляционных структурах).
Нет. Описанием OLAP-куба является "проекция отношений фактов". Что само по себе термин из реляционной алгебры. Ну и хронологически, OLAP-кубы существовали до появления современных noSQL решений.
OLAP-кубы на noSQL решениях это сильно. Звучит как заявка на победу. Прямо вижу как вы пытаетесь реализовать снежинку на Mongo...
Поверьте, в накладные расходы уровня сети/памяти вы в приведенном кейсе упретесь в разы быстрее, нежели в производительность БД. Собственно, у Oracle есть нативные витрины данных для OLAP из коробки, и с ними никогда не было никаких проблем.
Ни в коем случае. Есть нативные средства. К примеру, для Oracle — это гетерогенные службы (heterogeneous services). Только вот если мы говорим о способе общения как у сервисов (а один сервис ничего не знает о состоянии другого, и общение идет через апи) то это скорее transparent gateways или rpc (один инстанс базы вполне в состоянии дернуть хранимую другого инстанса и ничего не знать при этом о структурах данных второго, что как раз ближе всего к сервисной архитектуре).
Нет ровным счетом никаких проблем с распилом базы на куски аналогично распилу монолита на сервисы. Тут единственная проблема — лицензии.
А применять правила НЕ хай-лоад разработки для всей разработки корректно? И, на секундочку, в описанном мной кейсе уровень хай-лоада приблизительно равен нулю.