Одно время приходилось пользоваться Qt под виндой. Никаких проблем с установкой не припомню. Поставил и работал.
От питона бог миловал, так что ничего не скажу.
Linux, в то же время, даёт нам и разумный набор слоёв абстракции, применимых в ситуациях, когда прямой доступ к чему либо или ручное написание некоего кода может вылиться в больший объём работы, чем тот, к которому готов программист. Много удобных инструментов можно найти в Qt и Java, есть целые стеки вспомогательных технологий, вроде Pulse Audio, Pipewire и gstreamer. Linux стремится к тому, чтобы её пользователи могли бы заниматься программированием, и не скрывает этого.
При чем тут Linux? JVM может быть установлена на любой (практически) платформе. Qt — мультиплатформенный фреймворк…
Симкарта. Не номер, к ней привязанный, а сама карта. Банк это может сразу отследить. Я не спец, но как понимаю, послав вам смс, он получает некоторое подтверждение, где содержится этот самый IMSI и они сразу увидят что он не совпадает с тем, что у них в базе (который получили в первый раз когда номер телефона привязывали). Ну а дальше уже как построена система у банка. В Альфе приходит предупреждение что все операции через мобильный и интернет банк заблокированы до тех пор, пока не придете с паспортом в офис и не подтвердите оператору что сами поменяли симку. Тогда она сбросит IMSI в базе у них и он перезапишется новым.
Но это очень приблизительно. В тонкости не вникал.
После этого, через недобросовестного сотрудника сотовой связи, перевыпускается СИМ-карта
Почти наверняка это не сработает. Не скажу за сбер, а альфе просто поменял симку как-то (старая была, большая, нсменил телефон, нужна была мелкая). Номер тот же. Но… Фиг. Банковский клиент не работает. Пишет что симка поменялась нужно идти в отделение, там с паспортом обратится к оператору и сказать что поменял симку. После этого через сутки разблокируется и можно будет пользоваться.
Долгое время (родители с работы принесли) пользовался Б3-21 (предшественник 34-й). Даже курсовой на нем считал в институте.
А позже, уже на работе, столкнулся с какой-то моделью Casio, у которой была возможность записывать и считывать программы с магнитной карты. Карточка по типу банковской с магнитной полосой и сверху была щель как у терминалов для банковских карт (когда они еще контактные были). Поставил переключатель на «запись», чиркнул картой, потом «контроль» и еще раз. Когда надо «чтение» и опять картой чирк — программа в памяти.
объект — это всё-таки абстракция, обладающая определёнными признаками (свойства и методы), и предназначенная для решения конкретной прикладной задачи
Именно так я его и рассматриваю. Вне зависимости от его реализации.
Вы же сами говорите, что:
Типы и объекты в вашем коде, при отправке вовне, будут упрощены до структур данных. Необходимо учитывать упрощение моделей в программе, что аналогично учёту потерь в реляционных моделях. И заботиться о том, что на другой стороне API, модели будут адекватно восстановлены и использованы вами или другими разработчиками без искажений.
И тут я согласен — именно так это и происходит. На нижнем уровне. Дальше на все это уже навернуто фреймворков, которые все это скрывают и для неодумляющегося разработчика делают вид, что он передает куда-то «объект». Хотя фактически идет только передача данных и ничего более.
Впрочем, на практике сейчас принято разделение: DTO отдельно, методы отдельно. И получилось почему-то просто и удобно, в отличие от.
Ничто не ново под луной… Эти подходы я использовал еще в начале 90-х годов. Причем данные могли придти как из из соседней задачи на том же компе, так и от удаленного промконтроллера по каналу RS-485.
Но если заглянуть чуть глубже, то увидите, что где-то там внизу (совсем внизу) все равно идет передача данных и создание на их основе копии объекта (термин «объект по значению»). Или «линка» на удаленный объект («ссылка на объект»).
Ну не бывает чудес. Не сможете вы напрямую обратится к объекту, который расположен в адресном пространстве другого задания. Можно организовать удаленные вызовы для получения свойств (данных) этого объекта или удаленный вызов его метода с передачей параметров и возвратом результата, но и там и там вам придется передавать и получать данные. А вот получить ссылку на этот объект и по ней вызвать метода или обратиться к данным вы не сможете. Ибо ссылка — это фактически адрес. В памяти другого задания, куда вам доступ закрыт.
За всеми этими красивыми словами все равно кроется передача данных на основе которых создается копия объекта. Иначе никак, увы. Если принимающая и передающая стороны работают хотя бы в разных заданиях (не говоря уже о разных машинах), память их друг другу недоступна и все что они могут, это обмениваться данными (причем, по значению, не по ссылке). Но не объектами.
Так что в любом случае
Типы и объекты в вашем коде, при отправке вовне, будут упрощены до структур данных.
А что уж там поверх этого наворочено второй вопрос. И насколько эффективно оно наворочено.
Типы и объекты в вашем коде, при отправке вовне, будут упрощены до структур данных. Необходимо учитывать упрощение моделей в программе, что аналогично учёту потерь в реляционных моделях. И заботиться о том, что на другой стороне API, модели будут адекватно восстановлены и использованы вами или другими разработчиками без искажений. Это дополнительная нагрузка и увеличение ответственности программиста. Вне кода, вне помощи трансляторов/компиляторов и других автоматических инструментов при создании программ, необходимо вновь и вновь заботиться о корректной передаче моделей.
Если посмотреть на вопрос с другой стороны, то пока не видно на горизонте технологий и инструментов легко передающих типы/объекты из программы на одном языке в программу на другом.
Как вы себе представляете передачу объекта из программы работающей в одном задании в программу, работающую в другом? Я уж не говорю о том, что эти программы могут работать вообще на разных машинах…
Дело не в технологиях или разных языках. Дело в том, что объект существует в памяти конкретного задания. И передать его (кстати, что вы понимаете под «передать объект» вообще?) в другое задание можно только в виде набора данных, нужных для инициализации копии этого объекта.
Тут речь не идет о переписывании ПО. Речь о изначально правильно выборе с учетом возможного масштабирования.
Тут тот случай, когда скупой платит дважды — сначала сэкономили на покупке решения подешевле, потом вкладываемся в улучшение железа и в конечном итоге приходим к тому что дальнейшее улучшение железа уже или невозможно, или безумно дорого. И начинаем понимать, что изначально держать свою команду разработчиков оказалось бы в итоге дешевле.
Да, порою оказывается так, что дешевле купить новый сервер, который переварит некоторую неэффективность, чем платить программистам за долгую и кропотливую разработку.
Новый сервер стоит $200k примерно. А их как минимум три штуки в кластере.
Вы думаете, из той же 1С начинают выковыривать SQL-операторы и заменять на что-то более шустрое? Я вас умоляю! Просто покупают новый сервер.
И Вы считаете такой подход нормальным? Сколько было стонов про ту же винду, каждая версия которой требует все более мощного железа? Это оно и есть — проблемы разработки (нет желания платить более квалифицированным разработчикам) переваливают на пользователя — пусть он покупает более мощное железо.
Ну я не зря говорил о масштабных и долгоживущих проектах. Там (как, например, у нас) «заказная разработка» — это разработка силами своей команды + (частично, опционально) силами сторонних вендоров, но постановка задачи все равно наша, приемка поставки в виде исходного кода наша (заливка в наш гит с пуллреквестом, а вот апрувы и мерджи уже наши) и тестирование наше.
Вот такой пример. Один (хотя их на самом деле можно выкатить вагон и маленькую тележку). Есть у нас документ, который называется «Нефункциональные требования к функционалу на платформе IBMi». В нем очень много чего написано. Для примера, вот такой пункт:
Использование MERGE для больших объёмов данных запрещено. На время выполнения создаются блокировки записей в количестве кратном выполненным изменениям, что при большом их объёме приводит к замедлению работы сервера.
Вот скажите — кто «из коробки» будет отказываться от MERGE для добавления/обновления пары тысяч строк в пользу более «кодоемких» решений просто потому что в конкретных условиях одного из пользователей это начинает тормозить т.к. данный процесс работает не один, а среди еще тысячи-другой процессов, какие-то из которых тоже обращаются к этому файлу?
И, повторюсь, таких требований у нас не одна страница. И все они «выстраданы». Есть целый пул «задач на оптимизацию» где переписывается исправно работающий код просто потому что он неэффективен и оказывает существенное влияние на загрузку и общую производительность системы в целом. Вот как это можно делать в случае «коробочных решений»? И кто этим должен заниматься? Коробочники? А оно им надо? Они свое уже получили с продажи коробки.
Команда коробки, как тут уже было отмечено, ориентируется на какой-то усредненный набор ими самими придуманных требований. И попытка натянуть их сову на ваш персональный глобус поначалу может быть даже успешной. Но с ростом глобуса и/или изменением его формы сова начинает трещать по швам. И чинить ее вам придется (если она в проде), скотчем и степлером. В конечном итоге скотча там будет больше чем самой совы.
Для небольших проектов это сойдет. Ну слепили мобильное приложение из кусков кода с того же стекоферфлоу, выкатили его в маркет, монетизировались на встроенной рекламе и забыли.
А для чего-то большого и долгоживущего не прокатит. Там быстро столкнетесь с тем, что тут слишком много ресурсов жрет, там слишком медленно работает, здесь вообще конфликтует с другим процессом в драке за разделяемый ресурс (кто ж из коробочников мог догадаться, что на ваш глобус кроме их совы еще будет дятел из другой коробки натягиваться...)
Мне остается только согласится :-) поскольку сам от этой темы далек.
Сам всю жизнь работал в таких областях, где или эффективно, или никак — эффективность и надежность всегда ставились на первое место. Т.е. постоянно приходилось свой уровень подтягивать до требуемого.
Вот никогда не сталкивался в веб-разработкой, но по обсуждениям складывается ощущение, что там всех интересует как бы побыстрее да попроще сделать. А что там внутри, сколько оно жрет памяти и процессора никого не волнует.
Вообще говоря, обработка ошибок тема сложная и неоднозначная.
Начать с того — а что есть ошибка? Как их классифицировать?
Некорректность входных данных — это ошибка, ради которой стоит останавливать весь процесс? Всегда? Точно? А может есть ситуации, когда некорректные данные можно просто заменить дефолтным значением, выдать предупреждение и продолжить работу?
Естественно, что есть ситуации, когда дальнейшая работа становится небезопасной и/или непредсказуемой. Или просто невозможной. В этом случае все просто — остановка.
Но вот ситуация — 30 000 000 объектов для обработки. И при обработке одного возникает ошибка. Что делаем дальше? Останавливаемся совсем, или пишем в лог что не можем обработать данный объект и пытаемся обработать остальные? Строго говоря, тут тоже ответ неоднозначный. Если все объекты независимы — скорее продолжить работу. А если нет? Тогда может дойти до отката всего что обработали ранее в начальное состояние и только потом завершение.
На мой взгляд обработка ошибки должна проводиться как можно ближе к месту ее возникновения. Если в этом месте нет возможности принять однозначное решение, ошибка должна прокидываться на уровень выше и обрабатываться там.
Далее. Есть ошибки смысловые — та же валидация данных. Они не приводят к неустойчивости процесса. А есть системные, которые грозят уронить весь процесс целиком. И обработка их должна вестись совсем иначе. В первом случае возможны обходные варианты от подстановки дефолтных значений до возврата на этап ввода данных с указанием что именно не прошло валидацию. Но процесс в целом не останавливается. Во втором же почти однозначно надо делать все чтобы остановить процесс максимально мягко с минимальным ущербом.
Поскольку язык гибридный, то для парсинга паспорта можно можно написать функцию, которая будет возвращать ассоциативный массив, а затем использовать ее в определении понятия. Даже можно сджоинить ее результат с другими понятиями.
Угу. В том случае, если это Паспорт РФ. Но вообще-то это ДУЛ — документ, удостоверяющий личность. Там может быть какой-то иностранный паспорт, военный билет и вообще что угодно. Так что для начала придется понять — соответствует ли формат строки шаблону паспорта РФ или нет :-)
Делается это на регулярках. И ими же вытаскиваются составные часть если проверка шаблона прошла успешно.
Если прошло, то парсим. Нет — значит это или не паспорт РФ, или данныее криво введены.
Причем там может быть как
ПАСПОРТ РФ: <серия> <номер> ВЫДАН <кем выдан> <дата выдачи в виде dd.mm.yyyy>
так и ПАСПОРТ РФ: <серия> <номер> ВЫДАН <дата выдачи в виде dd.mm.yyyy> <кем выдан>
Так что дату выдачи еще отдельно ищем по регулярке
[0-3][0-9][ -\\.][01][0-9][ -\\.][12][0-9]{3}
Это скорее специфика платформы, построенной на суперсерверах. В WEB проектах чаще масштабируют приложение на много дешевых серверов.
Ну… Примерно такая же специфика будет во многих задачах. Например, задачи, которые занимаются управлением и мониторингом каких-то процессов. Там тоже на первом месте эффективсность т.к. все должно обрабатываться с минимальными задержками (а есть участки кода, которые вообще очень критичны по времени выполнения т.к. ограничены жесткими таймаутами).
Так что скорее web разработка специфична в плане вольности обращения с ресурсами.
От питона бог миловал, так что ничего не скажу.
При чем тут Linux? JVM может быть установлена на любой (практически) платформе. Qt — мультиплатформенный фреймворк…
Но это очень приблизительно. В тонкости не вникал.
И при наличии мобильного клиента уведомления и коды могут приходить не смсками, а пушами.
Почти наверняка это не сработает. Не скажу за сбер, а альфе просто поменял симку как-то (старая была, большая, нсменил телефон, нужна была мелкая). Номер тот же. Но… Фиг. Банковский клиент не работает. Пишет что симка поменялась нужно идти в отделение, там с паспортом обратится к оператору и сказать что поменял симку. После этого через сутки разблокируется и можно будет пользоваться.
Так что не так все просто.
А позже, уже на работе, столкнулся с какой-то моделью Casio, у которой была возможность записывать и считывать программы с магнитной карты. Карточка по типу банковской с магнитной полосой и сверху была щель как у терминалов для банковских карт (когда они еще контактные были). Поставил переключатель на «запись», чиркнул картой, потом «контроль» и еще раз. Когда надо «чтение» и опять картой чирк — программа в памяти.
По-моему, это был Casio Pro FX-1… temofeev.ru/info/articles/samodelnye-magnitnye-karty-dlya-kalkulyatora-casio-pro-fx-1
Именно так я его и рассматриваю. Вне зависимости от его реализации.
Вы же сами говорите, что:
И тут я согласен — именно так это и происходит. На нижнем уровне. Дальше на все это уже навернуто фреймворков, которые все это скрывают и для неодумляющегося разработчика делают вид, что он передает куда-то «объект». Хотя фактически идет только передача данных и ничего более.
Ничто не ново под луной… Эти подходы я использовал еще в начале 90-х годов. Причем данные могли придти как из из соседней задачи на том же компе, так и от удаленного промконтроллера по каналу RS-485.
Но если заглянуть чуть глубже, то увидите, что где-то там внизу (совсем внизу) все равно идет передача данных и создание на их основе копии объекта (термин «объект по значению»). Или «линка» на удаленный объект («ссылка на объект»).
Ну не бывает чудес. Не сможете вы напрямую обратится к объекту, который расположен в адресном пространстве другого задания. Можно организовать удаленные вызовы для получения свойств (данных) этого объекта или удаленный вызов его метода с передачей параметров и возвратом результата, но и там и там вам придется передавать и получать данные. А вот получить ссылку на этот объект и по ней вызвать метода или обратиться к данным вы не сможете. Ибо ссылка — это фактически адрес. В памяти другого задания, куда вам доступ закрыт.
За всеми этими красивыми словами все равно кроется передача данных на основе которых создается копия объекта. Иначе никак, увы. Если принимающая и передающая стороны работают хотя бы в разных заданиях (не говоря уже о разных машинах), память их друг другу недоступна и все что они могут, это обмениваться данными (причем, по значению, не по ссылке). Но не объектами.
Так что в любом случае
А что уж там поверх этого наворочено второй вопрос. И насколько эффективно оно наворочено.
Как вы себе представляете передачу объекта из программы работающей в одном задании в программу, работающую в другом? Я уж не говорю о том, что эти программы могут работать вообще на разных машинах…
Дело не в технологиях или разных языках. Дело в том, что объект существует в памяти конкретного задания. И передать его (кстати, что вы понимаете под «передать объект» вообще?) в другое задание можно только в виде набора данных, нужных для инициализации копии этого объекта.
Тут тот случай, когда скупой платит дважды — сначала сэкономили на покупке решения подешевле, потом вкладываемся в улучшение железа и в конечном итоге приходим к тому что дальнейшее улучшение железа уже или невозможно, или безумно дорого. И начинаем понимать, что изначально держать свою команду разработчиков оказалось бы в итоге дешевле.
Новый сервер стоит $200k примерно. А их как минимум три штуки в кластере.
И Вы считаете такой подход нормальным? Сколько было стонов про ту же винду, каждая версия которой требует все более мощного железа? Это оно и есть — проблемы разработки (нет желания платить более квалифицированным разработчикам) переваливают на пользователя — пусть он покупает более мощное железо.
Вот такой пример. Один (хотя их на самом деле можно выкатить вагон и маленькую тележку). Есть у нас документ, который называется «Нефункциональные требования к функционалу на платформе IBMi». В нем очень много чего написано. Для примера, вот такой пункт:
Вот скажите — кто «из коробки» будет отказываться от MERGE для добавления/обновления пары тысяч строк в пользу более «кодоемких» решений просто потому что в конкретных условиях одного из пользователей это начинает тормозить т.к. данный процесс работает не один, а среди еще тысячи-другой процессов, какие-то из которых тоже обращаются к этому файлу?
И, повторюсь, таких требований у нас не одна страница. И все они «выстраданы». Есть целый пул «задач на оптимизацию» где переписывается исправно работающий код просто потому что он неэффективен и оказывает существенное влияние на загрузку и общую производительность системы в целом. Вот как это можно делать в случае «коробочных решений»? И кто этим должен заниматься? Коробочники? А оно им надо? Они свое уже получили с продажи коробки.
Для небольших проектов это сойдет. Ну слепили мобильное приложение из кусков кода с того же стекоферфлоу, выкатили его в маркет, монетизировались на встроенной рекламе и забыли.
А для чего-то большого и долгоживущего не прокатит. Там быстро столкнетесь с тем, что тут слишком много ресурсов жрет, там слишком медленно работает, здесь вообще конфликтует с другим процессом в драке за разделяемый ресурс (кто ж из коробочников мог догадаться, что на ваш глобус кроме их совы еще будет дятел из другой коробки натягиваться...)
Сам всю жизнь работал в таких областях, где или эффективно, или никак — эффективность и надежность всегда ставились на первое место. Т.е. постоянно приходилось свой уровень подтягивать до требуемого.
Хотя это всегда были достаточно узконишевые вещи.
Начать с того — а что есть ошибка? Как их классифицировать?
Некорректность входных данных — это ошибка, ради которой стоит останавливать весь процесс? Всегда? Точно? А может есть ситуации, когда некорректные данные можно просто заменить дефолтным значением, выдать предупреждение и продолжить работу?
Естественно, что есть ситуации, когда дальнейшая работа становится небезопасной и/или непредсказуемой. Или просто невозможной. В этом случае все просто — остановка.
Но вот ситуация — 30 000 000 объектов для обработки. И при обработке одного возникает ошибка. Что делаем дальше? Останавливаемся совсем, или пишем в лог что не можем обработать данный объект и пытаемся обработать остальные? Строго говоря, тут тоже ответ неоднозначный. Если все объекты независимы — скорее продолжить работу. А если нет? Тогда может дойти до отката всего что обработали ранее в начальное состояние и только потом завершение.
На мой взгляд обработка ошибки должна проводиться как можно ближе к месту ее возникновения. Если в этом месте нет возможности принять однозначное решение, ошибка должна прокидываться на уровень выше и обрабатываться там.
Далее. Есть ошибки смысловые — та же валидация данных. Они не приводят к неустойчивости процесса. А есть системные, которые грозят уронить весь процесс целиком. И обработка их должна вестись совсем иначе. В первом случае возможны обходные варианты от подстановки дефолтных значений до возврата на этап ввода данных с указанием что именно не прошло валидацию. Но процесс в целом не останавливается. Во втором же почти однозначно надо делать все чтобы остановить процесс максимально мягко с минимальным ущербом.
Ну как-то так…
Угу. В том случае, если это Паспорт РФ. Но вообще-то это ДУЛ — документ, удостоверяющий личность. Там может быть какой-то иностранный паспорт, военный билет и вообще что угодно. Так что для начала придется понять — соответствует ли формат строки шаблону паспорта РФ или нет :-)
Делается это на регулярках. И ими же вытаскиваются составные часть если проверка шаблона прошла успешно.
Там что-то типа такого:
ПАСПОРТ РФ: {0,}[0-9]{4} {0,}[0-9]{6} {0,}ВЫДАН.{0,}[0-3][0-9][ -\\.][01][0-9][ -\\.][12][0-9]{3}.{0,}
Если прошло, то парсим. Нет — значит это или не паспорт РФ, или данныее криво введены.
Причем там может быть как
ПАСПОРТ РФ: <серия> <номер> ВЫДАН <кем выдан> <дата выдачи в виде dd.mm.yyyy>
так и ПАСПОРТ РФ: <серия> <номер> ВЫДАН <дата выдачи в виде dd.mm.yyyy> <кем выдан>
Так что дату выдачи еще отдельно ищем по регулярке
[0-3][0-9][ -\\.][01][0-9][ -\\.][12][0-9]{3}
Ну… Примерно такая же специфика будет во многих задачах. Например, задачи, которые занимаются управлением и мониторингом каких-то процессов. Там тоже на первом месте эффективсность т.к. все должно обрабатываться с минимальными задержками (а есть участки кода, которые вообще очень критичны по времени выполнения т.к. ограничены жесткими таймаутами).
Так что скорее web разработка специфична в плане вольности обращения с ресурсами.