Востребованность специалиста T-SQL в Германии.
ТОЛЬКО специалистами - включая написание кода
Вы ничего не путаете? ИТ-лер конечно понятие растяжимое. Отчеты делает ИТ-лер. Код пишет ИТ-лер. Компы ремонтирует ИТ-лер. А вот любую логику функционирования продукта пишут профильные специалисты. Ибо только врач в медицинской проге может заложить логику, что должно происходить после измерения давления. Только экономист может сказать, как расчитывается аннуитет при определенном проценте кредита. Но эти люди не могут писать код. Физически не умеют. Поэтому экономист пишет раскладку, как конкретные цифры должны просчитываться, программист превращает это описание в код и обеспечивает сохранность этих данных например в базе данных, а отчетописатель вытаскивает эти цифры и формирует отчет.
Нет, я ничего не путаю. Потому как не являясь по образованию программистом, все это делаю лично наряду с другими не-программистами в качестве одной из многих задач. Отчеты делаем мы сами полностью. Кодируем их генерацию сами. Любую ЦОС - сами (например, распознавание сложного профиля сигнала на фоне сильных шумов). Даже системы контроля производственных процессов - используя специфические программные продукты для обработки и визуализации данных, в которых имеются развитые скриптовые языки для создания полноценного интерфейса с юзером. Я уже писал, что у нас наукоемкое производство, порядка 15% сотрудников из постоянного штата с учеными степенями (физики, химики). И таких производств я знаю достаточно много. Для экономических показателей есть какие-то очень продвинутые приблуды к екселю, которые начальство пользует самостоятельно (начальство тоже с учеными степенями - один даже в области информатики, вроде), это считается несложной рутинной задачей пользователя, а не программера, хотя, возможно, некоторым SQL-запросы пишут айтишники, но эти запросы довольно примитивные и не требуют сильно высокой квалификации. Отчеты в первую очередь нужны не экономистам или держателям акций, а для "мозгового штурма" на совещаниях, где совместно пытаются найти решение довольно сложных проблем, часто - недостаточно или вообще не изученных в фундаментальной науке.
Потому как не являясь по образованию программистом, все это делаю лично наряду с другими не-программистами в качестве одной из многих задач.
Я не знаю уровень сложности ваших задач, но если вы не программист, вы не сможете ничего нормально запрограммировать. Научная степень здесь роли не играет. Задача программиста как раз в том, что бы написать приложение. Если специалисты лепят поделки из экселя на коленке - тут программисты не нужны.
Для экономических показателей есть какие-то очень продвинутые приблуды к екселю
Репортинг-программы - это совсем другой уровень. Если нужно просто просчитать цифры, то Excel пойдет. Но к клиентам ходят все таки с настоящими отчетами, такими отчетами, которые продают. Сделанные например в Qlik Sense. Вот именно там может найтесь место для ТСа
Отчеты в первую очередь нужны не экономистам или держателям акций, а для "мозгового штурма" на совещаниях,
Это не так. Это там у вас нужны просто цифры. А многие фирмы делают отчет для клиетов и там внешний вид и юзабельность - это обязательное условие и деньги.
Даже системы контроля производственных процессов - используя специфические программные продукты для обработки и визуализации данных, в которых имеются развитые скриптовые языки для создания полноценного интерфейса с юзером.
Смотрите. Постановка задачи.
Есть банк и работники этого банка расчитывают процентные ставки по кредитам. Расчеты сложные, внутренние, специфичные для банка. Делаются в экселе. Сам набор экселевских макросов и листов настолько сложет и запутан, что небольшое изменение часто влечет обвал всего расчета. У многих работников разные варианты этого экселевского приложения. И на каждом рабочем месте нужен этот экселевский файл, что бы начать считать.
В этом случае и пишется приложение. Лепим сервер с бизнес-логикой. Лепим веб-клиентов, что бы любой работник получил доступ с любого рабочего места . Лепим базу данных с штаммдатами клиентов, что бы каждый раз не забивать. Лепим таблицы(или логи), где мы сохраняем, кто , когда и кому считал. А посколько для входа надо анмельдоваться, мы действительно
видим КТО. Вот это и делают программисты и не могут делать экономисты.
И теперь отчеты. Никто не забивает циферки в таблички. Репортинг-тул выдает из нашей базы сколько было сделано кредитных приложений за месяц.
если вы не программист, вы не сможете ничего нормально запрограммировать
Дальше, честно говоря, нам беседовать не о чем. :) Меня всегда забавляла такая программистская непокобелимая уверенность. Переубеждать мне лень, да и дел хватает. Нет, мне не нужно посчитать просто цифры. Мне нужно сгенерить сложные графики со статистикой - всякие там боксплоты, гистограммы, хемометрика и прочее, запердолить это в красивом виде в отчет или презентацию (они тоже генерятся полностью автоматически - например, запускается в командной строке batch с одним параметром, на выходе - отчет, где-то делаю "кнопку"). И я именно генерю - пишу код, иногда заколбашиваю интерфейс. Причем наши вполне профессиональные программеры-кодеры (они клепают интерфейсы для управления производством - склад, подготовка материалов, первичный ввод информации) оценили, что им в си-шарпе для аналогичной сложности задачи понадобилось бы на порядок больше часов работы при скорее всего менее приемлемом результате - даже при использовании всевозможных "полуфабрикатов".
Да, это, видимо, особенность наукоемкого производства. Экстраполировать на любую фирму я не буду. В ооочень многих областях профессиональные программеры абсолютно незаменимы. Но тенденция заменять программеров не-программерами при наличии достаточно квалифицированных кадров для "внутренних" задач с учетом возможностей современных средств анализа и визуализации данных существует.
ЗЫ. Считать цифры в екселе, конечно, можно. Но неудобно. Есть гораздо более продвинутые проги, в кооторых можно на скриптовых языках запрограммить весьма сложные вещи. И это будет работать вполне стабильно и надежно. А главное - многие в коллективе смогут продолжить развитие тулзы и оптимизировать под свои задачи (ну, например, добавить прорисовку производной функции, применить любые виды сглаживания сигнала и data exploration).
ЗЗЫ. Мы продаем продукцию, а не отчеты.
Мы не банк. Мы наукоемкое производство. Коих в Германии много.
В банковских задачах я не копенгаген. Охотно верю. что там все по-другому.
У нас отличный от банковского подход и организация труда.
Про необходимость айти для организации доступа к данным я упоминал. Это серьезные вещи, которыми должны заниматься профессионалы. Вот они и занимаются. Но не созданием генераторов отчетов.
ЗЫ Ексель - зло.
НП.
Из почты, чтобы было на что ориентироваться:
NET expertise needed 5 years .NET
Experience of working with large web based applications
Technologies:
.NET Core
Building Restful Microservices - planning (domain analysis) and scaling
SignalR
MS SQL (Optimisation, migrations)
Azure (App services, function apps)
Kubernetes
Elastic Search
Redis
planning and design of CI/CD
Cosmo DB
ServiceStack
Service Bus / Kafka
Работа в Дублине.
Следующая в списке
Essential .NET C# skills needed:-
Strong C# experience
Expertise of creating and working with WebAPI’s.
You will have worked with modern development practices.
You want to be build great software, properly.
Documentation is important to you.
Be passionate about technology and want to learn more and more !
If technology is your hobby this is the environment for you.
Able to solve problematic architecture problems
Hungry to learn
Motivated by what you create / how it can grow and evolve
Public WebAPi’s – useful
High Traffic Web Applications – useful
Their .NET technical environment
.NET C#
Azure
No MVC , Single Page Application
NSerivceBus
Microsoft SQL
MongoDB
Redis
Cosmos DB
Restful API
Entity Framework
React
я лично не программист по образованию, но регулярно обходил "профессиональных программистов" на профильных олимпиадах...
а также работал в ИТ-компании где людей с ИТ-образованием было макс 10%, а остальные были физиками, астрономами и химиками. (про германию не говорю)
Программист это не образование - это образ мышления. Особенно если это касается архитектуры сложных систем, а не попытки "отполировать" ненужную штуку которая может быть и выглядит круто с точки зрения конкретного гика, но ни приносит денег, ни которую просто сопровождать
я лично не программист по образованию, но регулярно обходил "профессиональных программистов" на профильных олимпиадах...
Я не имел в виду мыслительные способности. Я имел в виду другое. Программа - это не набор красивого кода. Это система. Система, которая обрабатывает и сохраняет информацию. Я умею собирать и сохранять. И я умею организовывать обработку. В том смысле, что я вижу слабые места самопальных систем, я вижу, где нужно ограничить доступ пользователей, а где ввести логирование, что бы "консервы не тырили". Сюда же относится и гарантированое автоматическое удаление информации при необходимости и централизованое управление и много еще чего. Это мое ремесло.
Иногда это все не надо. Мой пример с банком не случаен. Просто посчитать можно и на калькуляторе. И если этого достаточно, то никто никаких лишних телодвижений не делает. Но на крупных фирмах самое важное это информация. Информация о клиентах, информация о товарах. И именно там существуют распределенные системы обработки информации, гарантирующие в первую очередь сохраненность информации и во вторую прозрачность доступа - видно кто, что и когда испортил.
Я пишу в контексте вопроса ТСа. Айтишники нужны именно для обслуживания таких систем. Не всегда для написания, не всегда нужны именно программисты. Нужны люди, которвые понимают в системах хранения информации чуть больше бухгалтера, но не претендуют на самостоятельное создание подобных систем.
Не нужно из контекста все выдергивать и ко всему придираться. В фразе "Может в вашем случае имеет смысл какой-нибудь в Access + VBA подтянуть" моего 1-го поста есть такие слова, как "может", "какой-нибудь" и они не случайно там написаны.
Ну а касательно "Сложность Аксеес вс .Нет/Джава - примерно одинаковая" - на мой взгляд, это как @уй с пальцем сравнивать, и @уй в данном случае не Аксеес.
это как @уй с пальцем сравнивать
-----
Ну а почему бы и не сравнить? Тем более, что есть вполне сопоставимые характеристики...
Берем параметер - время от начала изучения до написания пром.кода - и сравниваем.
В моем случае:
- Аксесс - около 2-3-х недель
- Джава - 6-7 суток
Но! Знания по Аксесс мне больше НИГДЕ не пригодились, а из Джавы кое-что все же помогало...
Термин "пром.код" объяснять надо? Нечто, возможно чудовищно ублюдочное, но выполняющее
работу определенную тех.заданием...
это как @уй с пальцем сравнивать
-----
Ну а почему бы и не сравнить? Тем более, что есть вполне сопоставимые характеристики...
-----
Теперь мое сравнение. На .NET/C# + frameworks пишутся enterprise системы, на Access небольшие настольные системы.
Система на Access - это спроектированная БД в нем, написанные SQL запросы к БД и формы с обработчиками на VBA. Исходя из бэкграунда GeorgF-а спроектировать БД + SQL под нее написать - не проблема, освоить VBA + формы клепать - несложно. Говорить о многослойной архитектуре приложения на Access, наверное, неактуально вообще, знания ООП - нужны постольку-поскольку.
Просто выучить ЯП C# - этого мало, .NET-framework сам по себе очень жирный(вкл. Linq, TPL, и т.д.), но этого тоже мало, чтобы устроиться на работу. Нужны доп-е framework-и, в зависимости от направления, например: ASP.NET MVC - вэб, WebApi - вебсервисы, EF - базы данных, WPF - десктоп, xamarin - мобайл, и пр. Помимо всего этого нужно знать ООП, принципы написания чистого кода, область в которой ты программируешь(вэб например), уметь писать юнит-тесты и пр.
На .NET/C# + frameworks пишутся enterprise системы, на Access небольшие настольные системы.
------
Пишутся разные системы.
Но .Нет - пишется как малые, так и большие. На Аксесс - большие не делаются или делаются, но мучительно.
Сравнение по сложности - некорректно.
При равной величине квалификации на .Нет МОЖНО писать так же как на Аксессе.
Вот наоборот - не получится - между системами почти 10 лет быстрого развития технологий... 3 поколения...
Говорить о многослойной архитектуре приложения на Access, наверное, неактуально вообще, знания ООП - нужны постольку-поскольку.
------
Вот и разъясни ньюансы имплементации ООП-парадигмы в Аксессе/ВБА/ВБ6 по сравнению с более-менее стандартной.
И ты не прав в оценке архитектуры - можно сделать и многослойку, можно сделать и многозвенку... правда - много сложнее...
Я бы даже сказал - мучительно сложнее - чтобы реализовать на Аксессе ТО ЖЕ САМОЕ, что и на .Нет в плане архитектуры
придется изучать БОЛЬШЕ информации.