Востребованность специалиста T-SQL в Германии.
Добрый день!
Почти год назад переехал в Германию, Дрезден, по линии ПП.
Мне 51 год, и немецкий язык к сожалению, дается очень тяжело, вернее совсем не дается, особенно в разговорной части. Английский не знаю.
В России работал в банковском ИТ, разрабатывал функционал на T-SQL для банковской системы Диасофт.
Система эта в Германии отсутствует, и львиная часть моего опыта и знаний никому здесь не нужны.
И остался чистый T-SQL :)
Порылся на площадках вакансий, делал запросы по частоте упоминания , и пришел к выводу, что надо еще в довесок знать какой либо ЯП.
Если я начну его изучать, то буду уже 52-х летним юниором, что как то не очень хорошо выглядит для работодателя.
В итоге хочется работу, где нужен именно T-SQL.
Вопрос, где я могу быть востребован? Как найти работу? И реально ли это, или переучиваться?
чтобы хоть как то начать работать на стабильной работе со стабильным финансированием и без немецкого языка тебе нужно владеть следующим списочком :
Java/Groovy/REST/Spring/Feign/JUnit/... и желательно очень специализированная разработка типа атлассиан
HTML/CSS/Bootstrap/JS/Node.js/MVVM Framework (Vue/React)
АПЕКС/PL/SQL
Python
Cи шарп
и если хотите я могу продолжить.
Только обладая таким списочком вас будут брать даже с нулевым немецким уровня Б2
Чем то из этого списка? или всеми позициями желательно?
Я покопался в вакансиях, составил тоже спискк по частоте упоминаний, получился похожий
JAVA JavaScript , HTML, CSS, PHP , C#, .NET, PYTHON и т.д.
Я если все же язык подтяну, то как мой первый вопрос , про работу с чистым SQL?
Так понимаю, что искать надо крупные компании, где есть узкая специализация разработчиков?
Немецкий я, естественно учу, сейчас перерыв между курсами, но я пол дня трачу на самостоятельное обучение.
И собеседование конечно на немецком буду проходить.
Видимо, моя запись про тяжело дающийся язык увела в сторону.
Вопрос так звучит - достаточно ли мне для нахождения работы знаний T-SQL, или надо еще добавить какой либо язык програмирования?
Есть ли у кого свой опыт, опыт знакомых, которые работают , используя только опыт работы с базой знаний.
Я начал изучать JAVA, но переживаю, не зря ли трачу время, может стоит состедоточится на SQL.
неправда. Я работал на фирме - конкурент САП. архитектура близка к 1с 7.5.
Так вот там вся логика на хранимках Firebird. На клиенте только код вызова хранимок.
Только там мало платят, очень большая движуха (новые работники не продерживаются и 9 месяцев) и в основном берут школьников со знаниями Паскаля или Hartz IV Empfänger ов.
Вот с ними и будете конкурировать.
но в целом с вами согласен. У нас был выкинут результат разработки длительностью почти в год и ушел человек, который это затеял. Из-за того, что начал изобретать велосипед с хранимками на PL SQL по формированию древовидный структуры. Ес-но там были баги и их никто не смог фиксить. Пытались заменить неработающий и unmaintainable интерфейс с хранимкой на собственный, но переход тоже порвалился.
В итоге все выдуманное им ПО было замененено стандартным от производителя на Ява и вызов из шарпа проходил через мост.
Ну значит просто не сталкивался. Что говорит о распостраненности и шансах туда попасть. А проблема не в школьниках. Это как плюс, потому что говорит о низком пороге вхождения.
неправда....но в целом с вами согласен.
Насколько востребованы чисто Database Developer?
-----
По моему опыту, а это НЕ Германия, чистого Датабасе Девелопера не ищут уже лет 15-ть...
Последняя "смешная" позииция была на тюнинг оракловских баз с пакаджами, но с "небольшими" довесками - там еще требовалось писать миддле на паре-тройке языков, делать формочки - вин-, них-, веб-, быть вебовским фронтэндщиком, дизайнером и специалистом по графике... ну и руководировать небольшим, до пары тысяч кодеров, коллективчиком...
Как то так...
Чем то из этого списка?
-----
По крайней мере - одну полную линейку - от фронта до бэка...
Лучше - если будет не одна линейка и понимание где, что и чем можно заменить.
Для понимания того, где ты находишься с голым Т-СКЛ - посмотри в сторону Ентити Фрамеvорк и/или Гибернате...
Попробуйте просто посмотреть вакансии на том же stepstone.de или monster.de
Их не так мноо, но они есть, вопрос только в том насколько вы к ним подходите.
Сейчас стараются уйти от сложных БД, но не всем это подходит и не все фирмы хотят что-то менять (да им и не надо по-хорошему). Смотрите в сторону банков, страховок, медицины. Там если какое-то приложение работает со сложной базой, то и следующие 10 лет будет. Они регулярно нанимают "советников", которые советуют переходить от такого к "логика в коде, в базе только данные", а потом посчитают затраты и продолжают тянуть свою систему.
На самом есть вакансии Datenbankentwickler (Database developer), напр. вот или вот - по сути только T(PL)-SQL без языков программирования, но нужен нем-й и анг-й.
Cначала учите немецкий по максимуму, потом в Arbeitsamte пробуете пробить какие-нибудь курсы по программированию(Java или C++ или XXX), чтобы спектр того, на что вы сможете теоретически претендовать шире был. Почему "теоретически" потому что без анг-го в IT на сегодняшний день - это беда, и в Германии, наверное, можно только рассчитывать на какие-нибудь маленькие фирмы до 20 чел. Может в вашем случае имеет смысл какой-нибудь в Access + VBA подтянуть, чтобы вот на подобное мочь претендовать - это, конечно, не фонтан, но у вас слишком скудный IT-профиль.
Спасибо!
Смотрел курсы ,например Java, попались длительностью 4 дня и стоимостью под 2000. я естественно и сам по учебникам и прочему учусь, надеялся, что курс дополнительно даст немецкую терминологию и как то структурирует.
Но что то сомневаюсь в пользе 4х дневных курсов. Но может я плохо искал нормальные курсы. тем более может в Дрездене с ними плохо просто.
Также покопался по вакансиям, и нашел что с TSQL частенько просят С# и .NET.
Думаю, сюда может еще направить усилия......
Курсы нужно пытаться получить в Arbeitsamt-е (или Job-center), вообщем, нужно вам с ними проконсультироваться.
Естественно T-SQL будет идти в связке с .NET - Microsoft тех. стек. Но c C# как и c Java - мало знать язык программирования, важны frameworks и опыт работы с ними. Как правило в таких объявлениях речь идет о .NET Developer, и T-SQL - это не самое главное, что требуется.
Мне, кажется, что при большом опыте с T-SQL можно относительно легко пересесть на PL(-pg)-SQL для Oracle или PostgreSQL, и, в моем пред-м посте я упор делал на это, а язык программирования как довесок(что-то вроде, а я еще немного это знаю, но готов углубиться).
Смотрел курсы ,например Java, попались длительностью 4 дня и стоимостью под 2000.
Я сдавал на Sun(догда еще sun) Ява сертификат и подготовка длилась полгода. Книга для подготовки в три пальца толщиной. Книга "Остров Ява" - в четыре пальца. Какие то смИшные курсы. Не смешная только цена.
Но что то сомневаюсь в пользе 4х дневных курсов.
-----
Как-то давно, когда Плюсы еще только-только появлялись, Я проверял сколько времени займет полный курс по языку Си.
Получилось - лекция на 40 минут. Т.е. за 40 минут можно рассказать в полном объеме что и как в Пуре Си.
Вот только гениев способных это усвоить за те же 40 минут не наблюдается... надо, минимум, месяца трi...
Да, Access & VBA - не то, о чем мечтает прогер. Но мы ведь не знаем насколько обучаем GeorgF в 50-м возрасте, мы знаем лишь то, что он знает только T-SQL, что для 50-го IT-ка очень мало. Либо он в IT начал очень поздно(за 40+) работать, вероятность чего оч. маленькая, так как в странах бывшего союза в таком возрасте в IT на джунов практически не берут. Либо, наш герой очень давно, кроме как с T-SQL ни с чем(имею ввиду технологии) дело не имел, а значит ничего технологического не изучал, +анг-го нет. С таким, предполагаемым, бэкграундом в enterprise - это .NET & Java - лучше, наверное, не лезть - много там всего, чтобы код(+тесты) писать за который не будет стыдно. На Access & VBA писать какую-нибудь офисную мелочь(там и поговнокодить можно) + хранимки для MS SQL Servera. Пока как-то так по входным данным...
с 2003 года я в банковской сфере, на АБС Диасофт. новый функционал и отчеты писались почти все как процедуры на сервере MSSQL.
до этого был как админ в банке, что то писал на Foxpro (эх, когда это было).
переехав в Германию, я потерялся как специалист в системе Диасофт (в Москве востребованно) и остался с голым TSQL.
сейчас поставил на ноут сервер MSSQL (ностальгия :) ) , Eclipse , обложился учебниками
и на Java пишу програмку для карточек с фразами немецкого языка.
это в перерывах изучения Deutsch.
потом хочу попробовать в Android studio что то поделать (тут Java как раз в тему будет)
затем поочередно
ORM Entity Framework / Hibernate
JavaScript (Typescript )
C#
.NET
PYTHON
пока так решил. и параллельно искать все же работу, на то что есть.
маловероятно, но вдруг окажется что то, хоть временно.
Лечь на диван и пособие(если не выгонят дворником) наверное всегда успею
+1То, что вы написали, это все же больше, чем голый T-SQL. Учите нем-й и ищите работу с тем, что есть: T-SQL, MS-SQL Server, администрирование и FoxPro(я бы указал в резюме). На что(Dev, Administration, System Engineer) получится найти туда и идите. В резюме пишите все, что умеете, знаете linux/unix - пишите, умете bat-ники писать - пишите.
Сходите в Job Center для консультации, может они вам какие-нибудь курсы полугодовые по программированию дадут.
Сходите в Job Center для консультации, может они вам какие-нибудь курсы полугодовые по программированию дадут.
Я бы даже больше сказал. Есть курсы, которые АА оплачивает, но почему то не предлагает. Кроме того есть курсы, оплачиваемые из других источников, например от Евросоюза. Ищите активно курсы сами. Интересуйтесь, кто может эти курсы оплатить(организаторы курсов знают это лучше) и пробивайте оплату.
На Access & VBA писать какую-нибудь офисную мелочь
-----
Ее, мелочь, давно пишут на .Нет и цепляют ко всем офисам.
хранимки для MS SQL Servera.
-----
Аналогично - на .Нет пишут нужную логику обработки и цепляют к серверу. Повторюсь - не к приложению, а именно к серверу, как расширение.
Чистый Т-СКЛ пользуется всего в двух ипостатсях - ДДЛ и контроль за целостностью данных. На СКЛ-сервере, в принципе, ничего другого и быть не должно. По крайней мере все известные мне проекты, где в Т-СКЛ решались другие задачи, уже померли... Да и ДДЛ в чистом виде уже начинает отмирать - из коде фирст разруливают структуру базы...
не знаем насколько обучаем GeorgF в 50-м возрасте
------
Роли не играет.
Он либо - обучаем - и тогда без разницы чему учить, либо - не обучем - и тогда освоение Аксесс + ВБА будет под вопросом...
Лично Я очень не люблю Аксесс. Причина - элементарная - чтобы в нем что-то сделать надо точно ЗНАТЬ не что надо делать, а как именно это надо делать в этой версии Аксесса. При этом очень большое количество возможностей просто не документировано или документировано настолько отвратно, что надоедает искать где оно описано... Правда это со времен Аксесс 2/95, поменялось ли что сейчас - не знаю...
пока так решил
-----
Ну тут либо
Java + Hibernate + ?
либо
.NET + Entity Framework + LINQ + CORE + шаблоны
и поверь - в обоих случаях это будет не быстро...
HTML + JavaScript + JQuery + AJAX + JSON + Node.js(?) + ...
- это надо, но в чистом виде - редко - обычно есть обертки в виде компонентов...
Да, для информации - JavaScript - бывает как клиентский, так и серверный...
PYTHON
- обхожусь без.
Лет 15 назад разок помогал с Питоном - не нашел ничего, что не мог бы удовлетворительно сделать другими уже имеющимися инструментами и с тех пор к нему не возвращался. Не думаю, что мне потребуется.
Typescript
- не смотрел.
Из упущеного - веб-сервисы, СОАП, РЕСТ & (тут почти до бесконечности) - нужно уметь управляемо перекидывать данные между системами.
Еще, из того что на слуху, Azure & AI...
В общем - на пару пятилеток...
В резюме пишите все, что умеете
-----
Для начала стоило бы выписать все в столбик, потом пометить уровень владения, уровень интереса к использованию, время, необходимое до доведения до рабочего состояния и думать что из этого и как включать в резюме.
А так - да, надо вспоминать и включать ВСЕ.
2ТС: Чтобы не проваливаться в самооценке - сходи на МСДН-форумы и ознакомься с вопросами, которые здают, и с ОТВЕТАМИ, которые предлагают тамошние спецы...
На Access & VBA писать какую-нибудь офисную мелочь
-----
Ее, мелочь, давно пишут на .Нет и цепляют ко всем офисам.
----
В основном да, но Access еще используется, я привел ссылку на job-angebot в своем первом посте.
хранимки для MS SQL Servera.
-----
Аналогично - на .Нет пишут нужную логику обработки и цепляют к серверу. Повторюсь - не к приложению, а именно к серверу, как расширение.
Чистый Т-СКЛ пользуется всего в двух ипостатсях - ДДЛ и контроль за целостностью данных. На СКЛ-сервере, в принципе, ничего другого и быть не должно. По крайней мере все известные мне проекты, где в Т-СКЛ решались другие задачи, уже померли... Да и ДДЛ в чистом виде уже начинает отмирать - из коде фирст разруливают структуру базы...
----
Когда нужна максимальная производительность на ms-sql server-е пишутся хранимые процедуры и вью на T-SQL.
не знаем насколько обучаем GeorgF в 50-м возрасте
------
Роли не играет.
Он либо - обучаем - и тогда без разницы чему учить, либо - не обучем - и тогда освоение Аксесс + ВБА будет под вопросом...
-----
Играет. Есть сложный материал, а есть несложный. Человек может освоить не без труда несложный, а сложный может не потянуть.
достаточно ли мне для нахождения работы знаний T-SQL
шансы конечно всегда есть, но по идее довольно минимальные.
Нужен довольно большой проект, чтобы был смысл держать только специалиста по базам.
Хотя был как то проект с одной фабрикой, так у них был целый отдел который только базами занимался.
Зато ПП относительно неплохо - можно несколько курсов из арбайтсамта выбить. Думаю для Вас корочки будут совсем не лишними.
Но для начала - это язык, без разговорного совсем никуда.
чтобы был смысл держать только специалиста по базам.
Есть и ещё один вариант - отчёты. Существует отдел менеджеров, им или клиентам нужны различные отчёты за различные периоды. Есть прога, через которую в базу забивается или импортируется инфа. И нужны люди, которые на репортинговой проге готовят sql запросы и оформляют в красивые отчёты. Минимальные требования это SQL и немецкий
Нет, это инженеры/физики/химики/биологи, хорошо разбирающиеся в сути производственных процессов - т.е., технологи со специальными знаниями в данной области. По крайней мере, я видел на нескольких предприятиях подобную ситуацию (включая то, на котором работаю). АйТи практически не занимается обработкой данных, только их накоплением, хранением и доступом.
Ну физика за отчёты садить не рационально. У нас это просто обученный персонал, который не имеет особых знаний в программировании, но может работать с программой, генерирующей отчёты. Они получают задания типа "нам нужна выборка за последние 2 месяца по трем отделам по следующим параметрам..." . Ну в общем есть такая экономическая ниша, я только не знаю, насколько это распространено.
АйТи практически не занимается обработкой данных, только их накоплением, хранением и доступом.
срочно меняй все учебники по информатике и википедию!
Речь шла об АйТи-отделе предприятия, а не об отрасли в целом. Думал, это и ежу понятно, ан нет...
Обработку и анализ производственных данных (включая формирование запросов к БД, ЦОС, визуализацию) у нас (т.е., на наукоемком производстве - у соседей все примерно так же) проводят ТОЛЬКО специалисты из R&D, а не айтишники, роль которых в данном аспекте сводится к установке ПО, которое затребует специалист, ну, очень изредка - еще и консультация по SQL.
Обработку и анализ производственных данных
Все правильно. Управленцы требуют новый столбец в квартальном отчете "количество просиженных штанов на квадратный метр". Программисты закладывают логику в прогу и дополняют бaзу данных. А потом те, кто делает отчеты, смотрят, где они эти данные могут взять и хреначат красивую синию полосу через весь отчет - количество штанов. Их задача - с помощью SQL(или другой источник данных) вытащить данные и изменить отчет. А отчеты могут быть теxнически сложные. А вот понимать, что конкретно эти цифры обозначают, необязательно.
Программисты закладывают логику в прогу
Повторяю: у нас никто программистов до серьезной логики не допускает. Айти занимается организацией первичного ввода данных на рабочих местах и функционированием СУБД, причем, структуру БД определяют тоже только специалисты-производственники. ВЕСЬ АНАЛИЗ осуществляется ТОЛЬКО специалистами - включая написание кода И для обработки данных ("логика"), И для генерации отчетов (визуализация данных, вывод в заданном формате). Айтишники не имеют отношения к генерации сколь-нибудь серьезных отчетов вообще. Максимум - что-то типа месячного графика количества трудоспособных сменных рабочих для начальника участка.
Поэтому я и скептичен по поводу востребованности чистого SQL-специалиста - да, возможно, "непрофессиональный программист" сделает менее эффективно (возможно! но не обязательно!), но и эта эффективность будет достаточна для решения всего спектра задач. И отдельную ставку для очень хорошо знающего SQL
не станут организовывать.
Access еще используется
-----
Дельфи - тоже.
Причем - вакансии заявляются довольно регулярно.
Будешь рекомендовать изучать Турбо Паскаль?
Когда нужна максимальная производительность на мс-сял сервер-е пишутся хранимые процедуры и вью на Т-СЯЛ.
-----
Ну и кто же утверждает что оно будет быстрее?
Я вот могу утверждать, что при выборе из 100 спецов каждого профиля, в 80% случаев написанное расширение будет работать быстрее.
Просто за счет того, что квалификация пишущих расширения к серверу по определению несколько выше.
Есть сложный материал, а есть несложный.
-----
Сложность Аксеес вс .Нет/Джава - примерно одинаковая. Второе даже чуть проще из-за доступности информации.
Ну физика за отчёты садить не рационально.
-----
Ну Я, вообще-то, физик по одной из специальностей.
У производственников "рациональность" несколько специфическая - рассматривается с точки зрения функционирования предприятия.
Т.е. можно инженера нанять на копание канавы - медленно, плохонько, дорого, но будет делаться и будет сделано - это рационально.
ТОЛЬКО специалистами - включая написание кода
Вы ничего не путаете? ИТ-лер конечно понятие растяжимое. Отчеты делает ИТ-лер. Код пишет ИТ-лер. Компы ремонтирует ИТ-лер. А вот любую логику функционирования продукта пишут профильные специалисты. Ибо только врач в медицинской проге может заложить логику, что должно происходить после измерения давления. Только экономист может сказать, как расчитывается аннуитет при определенном проценте кредита. Но эти люди не могут писать код. Физически не умеют. Поэтому экономист пишет раскладку, как конкретные цифры должны просчитываться, программист превращает это описание в код и обеспечивает сохранность этих данных например в базе данных, а отчетописатель вытаскивает эти цифры и формирует отчет.
Нет, я ничего не путаю. Потому как не являясь по образованию программистом, все это делаю лично наряду с другими не-программистами в качестве одной из многих задач. Отчеты делаем мы сами полностью. Кодируем их генерацию сами. Любую ЦОС - сами (например, распознавание сложного профиля сигнала на фоне сильных шумов). Даже системы контроля производственных процессов - используя специфические программные продукты для обработки и визуализации данных, в которых имеются развитые скриптовые языки для создания полноценного интерфейса с юзером. Я уже писал, что у нас наукоемкое производство, порядка 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 по сравнению с более-менее стандартной.
И ты не прав в оценке архитектуры - можно сделать и многослойку, можно сделать и многозвенку... правда - много сложнее...
Я бы даже сказал - мучительно сложнее - чтобы реализовать на Аксессе ТО ЖЕ САМОЕ, что и на .Нет в плане архитектуры
придется изучать БОЛЬШЕ информации.
Говорить о многослойной архитектуре приложения на Access, наверное, неактуально вообще, знания ООП - нужны постольку-поскольку.
Лично для меня странно видеть разговор от архитектуре и при этом завязываться на какую-то БД или язык программирования :)
спасибо, смеялись всем банком .
вам напомнить, сколько вы допустили в слове Java ошибок ?
---
1. А что, собственно, смешного, пояснишь?
2. Стиль сообщения, похож на стиль задрота, которому нужно самоутверждаться, пытаясь кого-то унизить.
Лично для меня странно видеть разговор от архитектуре и при этом завязываться на какую-то БД или язык программирования
---
Там в контексте сравнения с .NET было.
Ну, и, есть такое понятие архитектура приложений, которые пишутся на каких-нибудь конкретных языках программирования.
Там в контексте сравнения с .NET было.
.Net - это тоже конкретика.
Ну, и, есть такое понятие архитектура приложений, которые пишутся на каких-нибудь конкретных языках программирования.
Нет такого понятия. Архитектура и ООП оперируют абстракциями. Язык программирования, фреймворки и прочие инструменты - это уже конкретика.
Т.е., "архитектура приложений" имеет место быть? Что и т.д.
Чукча писатель? :)
Термин "архитектура приложений" безусловно есть. А вот фраза:
архитектура приложений, которые пишутся на каких-нибудь конкретных языках программирования
- полная ересь, т.к. архитектура приложений ни коем образом не может завязываться на какие-либо языки программирования.
А вот фраза
Фраза логичная. Ибо все приложения пишутся на конкретных языках. И у приложений есть архитектура. Во фразе нет указания на зависимости архитектуры от выбора языка.
Чукча писатель? :)
Чукча - тот, кто фантазирует за оппонента.
Во фразе нет указания на зависимости архитектуры от выбора языка.
Говорить о многослойной архитектуре приложения на Access, наверное, неактуально вообще
Я говорил лишь о том, что архитектура приложения никак не должна быть связана с используемой технологией (не зависимо от того ДБ, фреймворк или язык программирования).
Ну а как еще, кроме доведения вопроса до абсурда, можно показать несостоятельность мировоззрения?
То, что написано от мелкомягких - реклама того, что мелкомягие смогли осознать и имплементировать.
До написания того, на что ты привел ссыылку, они допускали великое множество различных ошибок и
эти ошибки представляли как нечто шедевральное... так что читать что-то от мелкомягких надо с
применением коэффициента доверия... и, кажется, не выше 0.3...
В данном конкретном случае - описана не архитектура, а имплементация некоторой архитектуры
выполненная мелкомягкими. как и по каким критериям нарабатывалась сама архитектура - увы, но
осталось за кадром...
Именно об этом, если Я правильно понял, тебе пытается сказать 
Программист
