Я использую для разработки десктопных приложений в связке с SQL SERVER. Логика в хранимках, на клиенте только интерфейс. Новый Firedac позволяет работать с любой БД. Скорость, простота и быстрота разработки позволяют автоматизировать такие участки в компании как ремонты приборов, мониторинг станций тестирования, тестирование электронных плат приборов и т д. Прекрасно все работает через VPN. Конечно спасает и хорошее знание SQL, разработка правильной архитектуры. Использую и git для контроля версий клиента. Контроль версий хранимок использую свой, через специальный триггер в БД, который пишет весь код в отдельную бд и таблицу. Для всех приложений доступно логирование и мониторинг. С web разработкой не связываюсь в таких сложных задачах как у меня. Слишком затратно и не нужно.
Как в любой области деятельности, для работы программистом нужно иметь определенные способности к этой деятельности и главное , это должно вам быть интересным. Склад вашего ума важен здесь. Курсы хороши для того чтобы упорядочить , структурировать и освежить уже имеющиеся знания в этой области. Если они нулевые, то они практически бесполезны ну или могут служить лишь толчком для самостоятельного изучения интересующей вас области программирования. Человек всегда учится самостоятельно, а все остальное лишь помощь в учебе.
Компьютерные устройства это одно, но есть и разработка другой электроники. Я работаю в сфере разработки интеллектуальных датчиков и процесс этот на порядок сложнее компьютерной электроники, на всех этапах, так как включает в себя допустим требования взрывозащиты, работы в широких температурных пределах, сложных испытаний, разработку методов линеаризации передаточных характристик с использованием регрессионного анализа , стендов тестирования и производства и программ для производства, сертификацию и т д и т п. В своей статье (в профиле ) я описал одну из созданных мной систем.
Я еще в конце 90-х SQL в Delphi использова на полную катушку, так что создал типа ERP . У меня были CRM, управление заказами, склад, отгрузки, интерфейс с 1С бухгалтерией ( кроме бухгалтерии тогда в 1С не было ничего), хранилище данных в SQL Server. И сейчас , после многих лет работы в сфере электроники эта связка сильно пригождается мне в работе над созданием систем тестирования электроники, создания различных приложений в компании где работаю.
Давно пишу для SQL SERVER. В основном встроенные процедуры. Запросы требуют при выполнении каждый раз создавать план запроса. Процедуры работают быстрее, потому что план запроса сохраняется и каждый раз не строится при вызове процедуры. При отладке запроса или процедуры можно вызвать предполагаемый план запроса и получить инфо об недостающих индексах. Но всякие маленькие хитрости тоже нужно знать. Как и когда использовать CTE , где лучше использовать подзапросы и где лучше join. Все приходит с опытом, "сыном ошибок трудных". Ну и от решаемых задач. Web разработка не требует хорошего знания sql. К тому же широкое использование всяких ORM и прочих костылей тоже не способствует освоению этого мощного и классного декларативного языка.
Иногда легче написать свой простой скриптовый язык для нишевой задачи, связанной с управлением оборудованием тестирования электроники, к примеру , или интеллектуального датчика. Пример такой системы и табличного языка описан в моей статье ( в моем профиле на хабр.). В общем система живет и развивается. Программирование тестов стало рутинной задачей. Обошлись без высокоуровнего языка программирования. Только LabVIEW и SQL.
Насчет begin end - сейчас end автоматически печатается после end при нажатии enter в паскале. В процедурах SQL server тоже используется begin end , но end не вставляется автоматически. В общем это не проблема. Проблема всегда в том что слишком много зависимостей в проектах делает жизнь этих проектов довольно трудной для сопровождения и порой тормозной. Быстрота и простота - вот какой должен быть девиз разработчика.
На самом деле SQL это не для новичков. По работе я имею дело с базами данных как программист, архитектор систем и dba. Это все настолько требует огромного кругозора и знаний, что новичку не подсилу. Изучить select insert и update несложно, но это лишь начальный уровень. Вся мощь SQL проявляется в сложных проектах. До этого еще надо дорасти. Ну а ORM это как костыли для разработчика. Одну из своих разработок я описал в статье (ссылка в моем профиле). Можно оценить сложность этого проекта.
Насчет китайских машин, пишут что два года до полностью ржавого авто. Насчет электроники- недавно коллега поделился новым errata на один из китайских cortex. Так вот про один интерфейс прямо написано что в случае помех возможен сбой и решения нет, как его обработать. То есть проц наглухо виснет. У STM такого треша нет. Проблем с китайской электроникой очень много, там где западные спецы не прикладывали руку. Компании отказываются даже размещать производство серийной электроники в Китае. Качество ниже плинтуса для крупных партий. Про программное обеспечение даже не говорю, масса ошибок, причем порой грубых. В этом отношении они очень напоминают российских производителей, которые все фичи не тестируют, а порой полный тест делает конечный пользователь.
На практике все немного не так с реальным датчиком давления.. Нужен технологический запас по погрешности, как по основой так и по температурной. Поэтому обычно используют пять точек давления и пять точек температур, включая крайние точки диапазона давления и рабочего диапазона температур. Метод Гаусса не дает высокой точности при обратном расчёте.. Метод Гивенса для расчета коэффициентов предпочтительнее. Данные лучше хранить в базе данных. В моей статье на хабре (в профиле) я описал свою спроектированную рабочую систему для датчиков давления, где используется LabVIEW для сбора данны и расчета коэффициентов и SQL Server для хранения данных и формирования матриц для расчёта. Ехсеll для экспериментов. Производство требует более основательного подхода. Я бы в статье с примером датчика давления упомянул физическую суть двухфакторной аппроксимации. Сенсор давления невозможно линеаризовать двумя отдельными полиномами, Основной полином по давлению должен иметь коэффициенты-полиномы по температуре. Математика математикой, но проще подходить к вопросу с точки зрения физической сущности линеаризации датчика давления. Расчет коэффициентов полинома сводится к решению СЛАУ и для пяти точек это 25 yравнений.
Слишком наивно . Это может работать на простых или типовых задачах, но на практике недостаток опыта приводит к поиску кошки в темной комнате для сложной или нетиповой задачи если не знаешь куда двигаться из-за множества вариантов или недостатка знаний.
На мой взгляд, ооп это просто абстрагированное описание моделей и их свойств некоего создаваемого вами виртуального мира, называемого программой, для компьютера. Не нужно забывать что это просто модели для отображения пикселей на экране монитора, смартфона и т п. В общем случае это паттерн имхо. Создавать программы это не к ооп, это к архитектуре и декомпозиции задачи. Далее выбор паттерна, имхо. И лучше не так как проще, а так как реальней, стабильней, быстрее и дешевле. Все зависит от задачи. И не всегда ооп нужен.
Да, верно. К примеру, LabVIEW позволяет "писать" программы как для компьютера без единой строки кода. Только диаграммы и связи. Я и мой коллега очень успешно применяем связку LabVIEW c SQL, что позволяет разрабатывать сложные приложения автоматизации производственных процессов. Одну из таких систем я описал в своей статье на Хабр.
У меня задачи и производственные и офисные. Браузер использовать в этих задачах не очень хорошо. Да и команды разработчиков нет. Поэтому старый добрый паттерн с бизнес логикой на сервере и клиентом с# или Delphi работает и быстро и разработка интерфейса не занимает много времени. Максимальный размер приложений небольшой. Использую git и для клиента и для сервера.
Недавно решал подобную задачу переноса данных из рабочей бд в тестовую на разных экземплярах сервера sql. Базы не содержат много таблиц.Ключи не удалял. Там где truncate не работал использовал просто Delete. Триггеры использую редко.их мало и поэтому просто отключаю. После переноса посмотрел уровень дефрагментации индексов у таблиц. Все было ОК. Перенесенная база отлично работает, без проблем с производительностью. Ну а использование недокументированных процедур всегда связано с риском потери данных. Лучше написать свой нормальный скрипт.
Делай всегда то, в чем у тебя интерес, что у тебя получается хорошо и где ты чувствуешь себя профи. Расти в той области где комфортно.Переход в другую область (работа с людьми ) из технической или программистской всегда будет некомфортным для технаря.
У нас это стандарт, наличие офисных приложений и принтера pdf. К тому же отчеты нужно сохранять и в excell, не только в pdf. С FR слишком много возни, так как были уже готовые шаблоны документов в Еxcell и они довольно сложные. Перерисовывать их долго было и юзеры к эти шаблонам привыкли. Через ole все просто и сравнительно быстро делается отчет по готовому шаблону. Решение универсальнее чем использовать FR. Сложность olе. кажущаяся только с первого раза.
Если все забьют на вопросы по cайтам то кормовая база всех этих gpt будет устаревать и в перспективе они будут бесполезны. Палка о двух концах. Последний раз мое обращение к DEVV было малополезным. Много неработающего кода и усложненного кода, который мне пришлось упростить, иначе не работало. Новички бы не справились.
Я использую для разработки десктопных приложений в связке с SQL SERVER. Логика в хранимках, на клиенте только интерфейс. Новый Firedac позволяет работать с любой БД. Скорость, простота и быстрота разработки позволяют автоматизировать такие участки в компании как ремонты приборов, мониторинг станций тестирования, тестирование электронных плат приборов и т д. Прекрасно все работает через VPN. Конечно спасает и хорошее знание SQL, разработка правильной архитектуры. Использую и git для контроля версий клиента. Контроль версий хранимок использую свой, через специальный триггер в БД, который пишет весь код в отдельную бд и таблицу. Для всех приложений доступно логирование и мониторинг. С web разработкой не связываюсь в таких сложных задачах как у меня. Слишком затратно и не нужно.
Как в любой области деятельности, для работы программистом нужно иметь определенные способности к этой деятельности и главное , это должно вам быть интересным. Склад вашего ума важен здесь. Курсы хороши для того чтобы упорядочить , структурировать и освежить уже имеющиеся знания в этой области. Если они нулевые, то они практически бесполезны ну или могут служить лишь толчком для самостоятельного изучения интересующей вас области программирования. Человек всегда учится самостоятельно, а все остальное лишь помощь в учебе.
Компьютерные устройства это одно, но есть и разработка другой электроники. Я работаю в сфере разработки интеллектуальных датчиков и процесс этот на порядок сложнее компьютерной электроники, на всех этапах, так как включает в себя допустим требования взрывозащиты, работы в широких температурных пределах, сложных испытаний, разработку методов линеаризации передаточных характристик с использованием регрессионного анализа , стендов тестирования и производства и программ для производства, сертификацию и т д и т п. В своей статье (в профиле ) я описал одну из созданных мной систем.
Я еще в конце 90-х SQL в Delphi использова на полную катушку, так что создал типа ERP . У меня были CRM, управление заказами, склад, отгрузки, интерфейс с 1С бухгалтерией ( кроме бухгалтерии тогда в 1С не было ничего), хранилище данных в SQL Server. И сейчас , после многих лет работы в сфере электроники эта связка сильно пригождается мне в работе над созданием систем тестирования электроники, создания различных приложений в компании где работаю.
Давно пишу для SQL SERVER. В основном встроенные процедуры. Запросы требуют при выполнении каждый раз создавать план запроса. Процедуры работают быстрее, потому что план запроса сохраняется и каждый раз не строится при вызове процедуры. При отладке запроса или процедуры можно вызвать предполагаемый план запроса и получить инфо об недостающих индексах. Но всякие маленькие хитрости тоже нужно знать. Как и когда использовать CTE , где лучше использовать подзапросы и где лучше join. Все приходит с опытом, "сыном ошибок трудных". Ну и от решаемых задач. Web разработка не требует хорошего знания sql. К тому же широкое использование всяких ORM и прочих костылей тоже не способствует освоению этого мощного и классного декларативного языка.
Иногда легче написать свой простой скриптовый язык для нишевой задачи, связанной с управлением оборудованием тестирования электроники, к примеру , или интеллектуального датчика. Пример такой системы и табличного языка описан в моей статье ( в моем профиле на хабр.). В общем система живет и развивается. Программирование тестов стало рутинной задачей. Обошлись без высокоуровнего языка программирования. Только LabVIEW и SQL.
Насчет begin end - сейчас end автоматически печатается после end при нажатии enter в паскале. В процедурах SQL server тоже используется begin end , но end не вставляется автоматически. В общем это не проблема. Проблема всегда в том что слишком много зависимостей в проектах делает жизнь этих проектов довольно трудной для сопровождения и порой тормозной. Быстрота и простота - вот какой должен быть девиз разработчика.
На самом деле SQL это не для новичков. По работе я имею дело с базами данных как программист, архитектор систем и dba. Это все настолько требует огромного кругозора и знаний, что новичку не подсилу. Изучить select insert и update несложно, но это лишь начальный уровень. Вся мощь SQL проявляется в сложных проектах. До этого еще надо дорасти. Ну а ORM это как костыли для разработчика. Одну из своих разработок я описал в статье (ссылка в моем профиле). Можно оценить сложность этого проекта.
Без человека эти модели ничего серьезного пока не могут. Как интеллектуальный поиск и подсказки может и сойдут. Не более того.
Насчет китайских машин, пишут что два года до полностью ржавого авто. Насчет электроники- недавно коллега поделился новым errata на один из китайских cortex. Так вот про один интерфейс прямо написано что в случае помех возможен сбой и решения нет, как его обработать. То есть проц наглухо виснет. У STM такого треша нет. Проблем с китайской электроникой очень много, там где западные спецы не прикладывали руку. Компании отказываются даже размещать производство серийной электроники в Китае. Качество ниже плинтуса для крупных партий. Про программное обеспечение даже не говорю, масса ошибок, причем порой грубых. В этом отношении они очень напоминают российских производителей, которые все фичи не тестируют, а порой полный тест делает конечный пользователь.
На практике все немного не так с реальным датчиком давления.. Нужен технологический запас по погрешности, как по основой так и по температурной. Поэтому обычно используют пять точек давления и пять точек температур, включая крайние точки диапазона давления и рабочего диапазона температур. Метод Гаусса не дает высокой точности при обратном расчёте.. Метод Гивенса для расчета коэффициентов предпочтительнее. Данные лучше хранить в базе данных. В моей статье на хабре (в профиле) я описал свою спроектированную рабочую систему для датчиков давления, где используется LabVIEW для сбора данны и расчета коэффициентов и SQL Server для хранения данных и формирования матриц для расчёта. Ехсеll для экспериментов. Производство требует более основательного подхода. Я бы в статье с примером датчика давления упомянул физическую суть двухфакторной аппроксимации. Сенсор давления невозможно линеаризовать двумя отдельными полиномами, Основной полином по давлению должен иметь коэффициенты-полиномы по температуре. Математика математикой, но проще подходить к вопросу с точки зрения физической сущности линеаризации датчика давления. Расчет коэффициентов полинома сводится к решению СЛАУ и для пяти точек это 25 yравнений.
Слишком наивно . Это может работать на простых или типовых задачах, но на практике недостаток опыта приводит к поиску кошки в темной комнате для сложной или нетиповой задачи если не знаешь куда двигаться из-за множества вариантов или недостатка знаний.
Если действие можно вызвать, то это просто вызов действия объекта которому оно относится. Например можно программно нажать кнопку.. Но это не объект.
На мой взгляд, ооп это просто абстрагированное описание моделей и их свойств некоего создаваемого вами виртуального мира, называемого программой, для компьютера. Не нужно забывать что это просто модели для отображения пикселей на экране монитора, смартфона и т п. В общем случае это паттерн имхо. Создавать программы это не к ооп, это к архитектуре и декомпозиции задачи. Далее выбор паттерна, имхо. И лучше не так как проще, а так как реальней, стабильней, быстрее и дешевле. Все зависит от задачи. И не всегда ооп нужен.
Да, верно. К примеру, LabVIEW позволяет "писать" программы как для компьютера без единой строки кода. Только диаграммы и связи. Я и мой коллега очень успешно применяем связку LabVIEW c SQL, что позволяет разрабатывать сложные приложения автоматизации производственных процессов. Одну из таких систем я описал в своей статье на Хабр.
У меня задачи и производственные и офисные. Браузер использовать в этих задачах не очень хорошо. Да и команды разработчиков нет. Поэтому старый добрый паттерн с бизнес логикой на сервере и клиентом с# или Delphi работает и быстро и разработка интерфейса не занимает много времени. Максимальный размер приложений небольшой. Использую git и для клиента и для сервера.
Недавно решал подобную задачу переноса данных из рабочей бд в тестовую на разных экземплярах сервера sql. Базы не содержат много таблиц.Ключи не удалял. Там где truncate не работал использовал просто Delete. Триггеры использую редко.их мало и поэтому просто отключаю. После переноса посмотрел уровень дефрагментации индексов у таблиц. Все было ОК. Перенесенная база отлично работает, без проблем с производительностью. Ну а использование недокументированных процедур всегда связано с риском потери данных. Лучше написать свой нормальный скрипт.
Делай всегда то, в чем у тебя интерес, что у тебя получается хорошо и где ты чувствуешь себя профи. Расти в той области где комфортно.Переход в другую область (работа с людьми ) из технической или программистской всегда будет некомфортным для технаря.
У нас это стандарт, наличие офисных приложений и принтера pdf. К тому же отчеты нужно сохранять и в excell, не только в pdf. С FR слишком много возни, так как были уже готовые шаблоны документов в Еxcell и они довольно сложные. Перерисовывать их долго было и юзеры к эти шаблонам привыкли. Через ole все просто и сравнительно быстро делается отчет по готовому шаблону. Решение универсальнее чем использовать FR. Сложность olе. кажущаяся только с первого раза.
Если все забьют на вопросы по cайтам то кормовая база всех этих gpt будет устаревать и в перспективе они будут бесполезны. Палка о двух концах. Последний раз мое обращение к DEVV было малополезным. Много неработающего кода и усложненного кода, который мне пришлось упростить, иначе не работало. Новички бы не справились.