:-) Не соглашусь, т.к. "кому интересно идти в IT не за деньгами, а по внутреннему призванию/желанию" (естественно если есть способность к этому виду труда) - в ближайшей перспективе быстро "обойдут" тех "кто пришел в IT за деньгами".
:-) Железо - на ваш выбор (как вариант энергоэффективного и производительного Intel N100) + + Xpenology. И обойдется это (в зависимости от желаемого "набора" железа) от 20 до 30 тыс. без дисков.
:-) Логика простая... Требования к разработчику - "сделай в программном продукте вот этот функционал и побыстрее". Разработчик же заинтересован в постоянной "разработке программного продукта" - именно этим он "зарабатывает". По этой причине (кроме отдельных перфекционистов "по природе") софт "исходящий" от разработчков сырой, не оптимизирован и полон багов. "Бац-бац и готово!" Требования к тестировщику - "клиент не должен сообщать об ошибках в программном продукте и его функциях".
:-) Вот тесты на реальных приложениях и показывают "что заявлено" и "как по факту".... А выбор (неважно чего) - это всегда "компромис"... Быстро, качественно, недорого - выбирайте любые два пункта.
Если ты превосходно разбираешься в соей узкой области и не хочешь/можешь даже в общем приближении понимать "как все под капотом работает" - это не ужасно, но недостаток. И получаем ответы от всех "узких специалистов" - "С моей стороны пули вылетели, проблемы на вашей стороне..."
К слову "другие люди" и среди нового поколения есть... :-) Не много, но есть. Любознательность, альтруизм и реальное трудолюбие (получение удовольствия от результатов своего труда) еще не изжиты современным обществом и государством...
По сути написано верно, но... Касаемо фразы "ЭТОГО НЕТ В МОЕЙ ДОЛЖНОСТНОЙ ИНСТРУКЦИИ!". Если на все ваши другие аргументы 1,2,3 (они перечислены в статье) вы получаете ответы в стиле "Я начальник - ты дурак. Клиент за это платит." - значит пора уходить. Правда в ситуации если вы реально специалист, а не просто "думаете что вы специалист"...
:-) Ну да. "Школьники пишут программы" сейчас, вот только "когда все идет не так" - зовут "других людей". Так что реальным IT специалистам работы хватает.... :-)
DB2 - "жестко" связывает с одним вендором, и инфраструктурой. А компании разработчику софта "хочется" широкого рынка сбыта под требования разных клиентов. Вот по этой причине - Oracle (до определенного этапа), а сейчас еще и PG. Ситуация с тестами простая. Есть клиенты нашего прикладного ПО (или потенциальные клиенты). Есть поставщики/вендоры оборудования (или комплекса услуг типа IBM/Oracle). Все вендоры заинтересованы в "больших и надежных" клиентах. Клиентам всегда нужно производительность-надежность-масштабируемость-безопасность и по "минимальной цене поддержки/эксплуатации". На это еще "сверху ложатся" скажем так "интересы конкретных людей в компаниях у клиентов". :-) Вот и получается ситуация когда клиент "говорит" вендору - "Хотите чтоб наша компания стала вашим клиентом? Ну продемонстрируйте на прикладных тестах что вы можете. Синтетика и теория - это одно, а реальные показатели - может быть другое." Периодически и сама наша компания "ища рынки сбыта" самостоятельно пробует работу нашего прикладного софта под разными платформами, вендорами, OS (предваряя запросы наших клиентов). С разными вычислительными мощностями в различных конфигурациях и т.п. Иногда приходится "проверять громкие заявления вендоров о прорыве в технологиях" и т.п. Все вроде бы просто. "Есть требования бизнеса клиента"(это enterprise) - "Есть прикладное решение"(или несколько) - "Есть ресурсы/решения конкретного вендора"(или разных). До приобретения комплекса бизнес клиента хочет - "А покажите на деле что можете! А что будет если "уронить"? А время восстановления и % потерь? А если у нас завтра бизнес вдвое вырастет? А где логи всех действий в системе (изменений в прикладной базе)? А соответствие PCI/DSS? А интеграция с .....?" Вот на такие вопросы дают ответы тесты (конкретные цели ставит заказчик конечно же)... :-) Зачастую познавательно слушать "перепалку" спецов вендора по платформе/OS с их же спецами по работе Oracle DB (на платформе/OS) кто из них "накосячил" с конфигурацией системы/комплекса.
:-) Ну российские спецы IBM по DB2 сразу сказали что пробовать и не будут... Тупо исходники в европейское отделение отправили. А уж кто там занимался - не интересовался. IBM тогда (на фоне спада интереса к DB2) активно продвигал софт типа "автоматической адаптации написанного на PL/SQL под DB2", со словами "наш софт портирует 90% исходников - вам руками останется поправить 10%".... А вот насчет тестов - вы не очень правы. Я там конечно с "прикладной стороны смотрел", но вендорам всем "вводные давали одинаковые". Не думаю что в Монпелье спецы по системам совсем слабые (что по z что по p-System) и те и другие тюнили системы после начала тестов не слабо. Но... Они же и объясняли сами "почему такой результат". Сам я в Монпелье с ними и общался за пару командировок недели по 3 каждую. На результаты прикладной производительности нашего софта они "смотрели с уважением" когда я им объяснял что делает система, т.к. их же системы работали с другим (но аналогичным) прикладным софтом по всему миру и знали сколько ресурсов "жрет" подобный софт при примерно такой же прикладной производительности.
:-) А что у нас с Oracle под zOS? Концепция уже сменилась? Или м.б. Oracle не та компания которой нужны крупные корпоративные клиенты и у них недостаток ресурсов для портирования новых версий? DB2 - это возможно и хорошо (учитывая что Oracle использовал ее концепции), но... Когда то давно (в начале 2000-х) к нам обратились IBM спецы и заявили что "на раз-два" портируют на неё терминал-сервер приложение написанное под Oracle, и получили наши исходники на PL/SQL. Где то через пол года получили от них информацию - "ну не шмогла я...". Сама z-System (правда работал я со старой z10 и под AIX где Oracle тогда был) штука крутая, но... Была задача как справятся (на реальных тестах прикладного приложения 24/7 и под большой нагрузкой) разные виртуальные системы, в частности SPARC, z и p IBM (все при базе Oracle) с масштабированием количества выделенных для OS(Solaris, AIX)/DB vCPU - уж очень это интересовало наших клиентов. Результаты были "интересные" - только p-System под AIX без "заморозки" всех процессов БД в OS на несколько (2-5) секунд это смогла...
СБП говорите... СМС говорите... Ну-Ну... Пока никто не смог мне достаточно аргументированно объяснить, какое отношение ваш двухсторонний договор с одним юридическим лицом (банком) имеет отношение к вашему же двухстороннему договору с другим юридическим лицом (сотовым оператором). Причем по договору с сотовым оператором вы только "арендуете" номер/идентификатор телефона и оператор в любой момент (с определенными нюансами договора) может договор отозвать/расторгнуть. И мало этого, вы добровольно (поскольку в договоре с сотовым оператором нет никаких гарантий или штрафных санкций за отсутствие связи) свою возможность распоряжаться своими же деньгами (по банковскому договору) ограничиваете условиями договора с сотовым оператором (совершенно другим юридическим лицом).... Вот как то так... :-) P.S. А уж если у вас несколько договоров с одним банком (что является нормальной практикой), то чтобы перевод вам по СБП "попадал" на необходимый вам "в текущем моменте" конкретный ваш банковский счет, вам скажем так нужно "попрыгать" (если до этого момента он "попадал" на другой ваш счет). Про "приключения" со сменой сотового номера (особенно "связанного" с госуслугами) - отдельная история. :-)
:-) История учит, если государство говорит "Колхоз дело добровольное!", значит скоро начнут "раскулачивать" и "ссылать за Урал"....
:-) Не соглашусь, т.к. "кому интересно идти в IT не за деньгами, а по внутреннему призванию/желанию" (естественно если есть способность к этому виду труда) - в ближайшей перспективе быстро "обойдут" тех "кто пришел в IT за деньгами".
:-) В IT я 30+ лет. С автором статьи во многом согласен...
:-) Железо - на ваш выбор (как вариант энергоэффективного и производительного Intel N100) + + Xpenology. И обойдется это (в зависимости от желаемого "набора" железа) от 20 до 30 тыс. без дисков.
:-) Логика простая...
Требования к разработчику - "сделай в программном продукте вот этот функционал и побыстрее". Разработчик же заинтересован в постоянной "разработке программного продукта" - именно этим он "зарабатывает". По этой причине (кроме отдельных перфекционистов "по природе") софт "исходящий" от разработчков сырой, не оптимизирован и полон багов. "Бац-бац и готово!"
Требования к тестировщику - "клиент не должен сообщать об ошибках в программном продукте и его функциях".
:-) Ну как бы - https://github.com/cybernoid/archivemount "стирает проблему" -Fd ...
:-) Вот тесты на реальных приложениях и показывают "что заявлено" и "как по факту".... А выбор (неважно чего) - это всегда "компромис"...
Быстро, качественно, недорого - выбирайте любые два пункта.
Если ты превосходно разбираешься в соей узкой области и не хочешь/можешь даже в общем приближении понимать "как все под капотом работает" - это не ужасно, но недостаток. И получаем ответы от всех "узких специалистов" - "С моей стороны пули вылетели, проблемы на вашей стороне..."
К слову "другие люди" и среди нового поколения есть... :-) Не много, но есть. Любознательность, альтруизм и реальное трудолюбие (получение удовольствия от результатов своего труда) еще не изжиты современным обществом и государством...
По сути написано верно, но...
Касаемо фразы "ЭТОГО НЕТ В МОЕЙ ДОЛЖНОСТНОЙ ИНСТРУКЦИИ!". Если на все ваши другие аргументы 1,2,3 (они перечислены в статье) вы получаете ответы в стиле "Я начальник - ты дурак. Клиент за это платит." - значит пора уходить. Правда в ситуации если вы реально специалист, а не просто "думаете что вы специалист"...
:-) Ну да. "Школьники пишут программы" сейчас, вот только "когда все идет не так" - зовут "других людей". Так что реальным IT специалистам работы хватает.... :-)
DB2 - "жестко" связывает с одним вендором, и инфраструктурой. А компании разработчику софта "хочется" широкого рынка сбыта под требования разных клиентов. Вот по этой причине - Oracle (до определенного этапа), а сейчас еще и PG.
Ситуация с тестами простая. Есть клиенты нашего прикладного ПО (или потенциальные клиенты). Есть поставщики/вендоры оборудования (или комплекса услуг типа IBM/Oracle). Все вендоры заинтересованы в "больших и надежных" клиентах. Клиентам всегда нужно производительность-надежность-масштабируемость-безопасность и по "минимальной цене поддержки/эксплуатации". На это еще "сверху ложатся" скажем так "интересы конкретных людей в компаниях у клиентов". :-)
Вот и получается ситуация когда клиент "говорит" вендору - "Хотите чтоб наша компания стала вашим клиентом? Ну продемонстрируйте на прикладных тестах что вы можете. Синтетика и теория - это одно, а реальные показатели - может быть другое."
Периодически и сама наша компания "ища рынки сбыта" самостоятельно пробует работу нашего прикладного софта под разными платформами, вендорами, OS (предваряя запросы наших клиентов). С разными вычислительными мощностями в различных конфигурациях и т.п.
Иногда приходится "проверять громкие заявления вендоров о прорыве в технологиях" и т.п.
Все вроде бы просто. "Есть требования бизнеса клиента"(это enterprise) - "Есть прикладное решение"(или несколько) - "Есть ресурсы/решения конкретного вендора"(или разных).
До приобретения комплекса бизнес клиента хочет - "А покажите на деле что можете! А что будет если "уронить"? А время восстановления и % потерь? А если у нас завтра бизнес вдвое вырастет? А где логи всех действий в системе (изменений в прикладной базе)? А соответствие PCI/DSS? А интеграция с .....?" Вот на такие вопросы дают ответы тесты (конкретные цели ставит заказчик конечно же)... :-)
Зачастую познавательно слушать "перепалку" спецов вендора по платформе/OS с их же спецами по работе Oracle DB (на платформе/OS) кто из них "накосячил" с конфигурацией системы/комплекса.
Интересно что несколько клиентов у нас на p-System еще "сидят", но поддержку 12 Oracle в этом году мы "заканчиваем"....
:-) Ну российские спецы IBM по DB2 сразу сказали что пробовать и не будут... Тупо исходники в европейское отделение отправили. А уж кто там занимался - не интересовался. IBM тогда (на фоне спада интереса к DB2) активно продвигал софт типа "автоматической адаптации написанного на PL/SQL под DB2", со словами "наш софт портирует 90% исходников - вам руками останется поправить 10%"....
А вот насчет тестов - вы не очень правы. Я там конечно с "прикладной стороны смотрел", но вендорам всем "вводные давали одинаковые". Не думаю что в Монпелье спецы по системам совсем слабые (что по z что по p-System) и те и другие тюнили системы после начала тестов не слабо. Но... Они же и объясняли сами "почему такой результат". Сам я в Монпелье с ними и общался за пару командировок недели по 3 каждую. На результаты прикладной производительности нашего софта они "смотрели с уважением" когда я им объяснял что делает система, т.к. их же системы работали с другим (но аналогичным) прикладным софтом по всему миру и знали сколько ресурсов "жрет" подобный софт при примерно такой же прикладной производительности.
:-) А что у нас с Oracle под zOS? Концепция уже сменилась? Или м.б. Oracle не та компания которой нужны крупные корпоративные клиенты и у них недостаток ресурсов для портирования новых версий?
DB2 - это возможно и хорошо (учитывая что Oracle использовал ее концепции), но... Когда то давно (в начале 2000-х) к нам обратились IBM спецы и заявили что "на раз-два" портируют на неё терминал-сервер приложение написанное под Oracle, и получили наши исходники на PL/SQL. Где то через пол года получили от них информацию - "ну не шмогла я...".
Сама z-System (правда работал я со старой z10 и под AIX где Oracle тогда был) штука крутая, но...
Была задача как справятся (на реальных тестах прикладного приложения 24/7 и под большой нагрузкой) разные виртуальные системы, в частности SPARC, z и p IBM (все при базе Oracle) с масштабированием количества выделенных для OS(Solaris, AIX)/DB vCPU - уж очень это интересовало наших клиентов. Результаты были "интересные" - только p-System под AIX без "заморозки" всех процессов БД в OS на несколько (2-5) секунд это смогла...
Ну так я в курсе вообще то.... :-)
В любом случае с таким "подходом" или безопасности нет, или индексов... А финансовое приложение без этих двух компонентов БД - неполноценно....
А смысл в проверке тогда? :-)
Осталось понять как индексировать зашифрованные данные... И каким образом хранится индекс по ним.... :-)
СБП говорите... СМС говорите... Ну-Ну...
Пока никто не смог мне достаточно аргументированно объяснить, какое отношение ваш двухсторонний договор с одним юридическим лицом (банком) имеет отношение к вашему же двухстороннему договору с другим юридическим лицом (сотовым оператором).
Причем по договору с сотовым оператором вы только "арендуете" номер/идентификатор телефона и оператор в любой момент (с определенными нюансами договора) может договор отозвать/расторгнуть.
И мало этого, вы добровольно (поскольку в договоре с сотовым оператором нет никаких гарантий или штрафных санкций за отсутствие связи) свою возможность распоряжаться своими же деньгами (по банковскому договору) ограничиваете условиями договора с сотовым оператором (совершенно другим юридическим лицом)....
Вот как то так... :-)
P.S. А уж если у вас несколько договоров с одним банком (что является нормальной практикой), то чтобы перевод вам по СБП "попадал" на необходимый вам "в текущем моменте" конкретный ваш банковский счет, вам скажем так нужно "попрыгать" (если до этого момента он "попадал" на другой ваш счет). Про "приключения" со сменой сотового номера (особенно "связанного" с госуслугами) - отдельная история. :-)