German Jet

Список вакансий со знанием SQL - ежедневно у меня агрегатором с HH приходит - по Москве более 700.
И это могут быть позиции от менеджеров по продажам до архитекторов сложного софта.
И уровень знаний требуется разный.

На своем примере скажу так.
У меня был примерно аналогичный опыт, и работала я аналитиком данных в банке.
Потом сократили.
Ходила на собеседования на инженера техподдержки, разраба БД, бизнес аналитика, тестировщика.
Для разраба уровень слабоват.
На аналитика и в техподдержку не пошла в те места именно.
Тестером работаю больше года.
Здесь уровень необходимых знаний по SQL зависит от проекта и разработок.

Еще бы хорошо знать и уметь, как разворачивать и переносить БД, читать ошибки, отслеживать и оптимизировать время выполнения запросов и т.д. и т.п.

Можно.
Для построения плана обучения используйте следующие ресурсы:
- Возьмите планы обучений платных курсов. Изучайте разделы самостоятельно.
- Послушайте на YouTube примеры собеседований. По вопросам сформируйте себе план обучения.
- Обратитесь к ментору на одной из платформ менторов - для построения плана обучения.

Шифрование настраивается в самом постгресе:
https://postgrespro.ru/docs/postgresql/15/runtime-...

UPD: похожий вопрос на форуме MS с похожей проблемой.
https://community.powerbi.com/t5/Service/PostgreSQ...
Пишут что должен быть включен SSL и при этом сертификат должен быть заверен доверенным центром сертификации, а не самоподписанный.

cobain backup 11

В документации же русским по белому написано:

PostgreSQL 15 содержит много новых возможностей и улучшений, в том числе:

• Поддержка SQL-команды MERGE.
  
• Выборочная публикация содержимого таблицы в рамках логической репликации с возможностью указывать списки столбцов и фильтры строк.
  
• Больше возможностей для использования сжатия и поддержка сжатия Zstandard (zstd). В том числе реализована возможность сжатия на стороне сервера при создании копии с помощью pg_basebackup.
  
• Поддержка структурированного вывода журнала сервера в формате JSON.
  
• Улучшения производительности, в частности, оптимизация операций сортировки в памяти и на диске.
  

https://postgrespro.ru/docs/postgresql/15/release-...

PostgreSQL 14 содержит много новых возможностей и улучшений, в том числе:

• Хранимые процедуры теперь могут возвращать данные через параметры OUT.
  
• Реализованы описанные в стандарте SQL параметры SEARCH и CYCLE для общих табличных выражений.
  
• Операцию обращения по индексу теперь можно применять не только к массивам, но и к любому типу данных, для которого она имеет смысл. В этом выпуске такие операторы добавлены для типов jsonb и hstore.
  
• Диапазонные типы были дополнены мультидиапазонными, позволяющими представлять несплошные диапазоны данных.
  
• Проведена большая работа по улучшению производительности параллельных запросов, обработки многопоточной нагрузки, секционированных таблиц, логической репликации и процедуры очистки.
  
• Изменения в индексах-B-деревьях теперь обрабатываются более эффективным методом, уменьшающим замусоривание индексов.
  
• Процедура VACUUM автоматически становится агрессивнее и пропускает несущественные операции очистки в случае приближения базы данных к моменту зацикливания идентификаторов транзакций.
  
• Расширенную статистику теперь можно собирать по выражениям, что позволяет получить лучшие планы для сложных запросов.
  
• Библиотека libpq теперь поддерживает конвейерную передачу нескольких запросов, что позволяет ускорить получение результатов через сетевые соединения, которым свойственны большие задержки.
  

https://postgrespro.ru/docs/postgresql/14/release-14

Если объект возвращает DTO как представление самого себя

Как? DTO это объект, который просто описывает некую модель данных и не имею поведения (Wikipedia). Ладно, с этим всё равно, едем дальше

нельзя менять свойства объекта из вне, это могут делать только методы объекта

Ну это уже смотря на логику... К примеру, наведу пример из .Net, возьмите стандартный класс от Microsoft по типу Console (Класс для работы с консолью). Там же есть свойства, по типу BackgroundColor, Height, Width и т.д. Изменение размеров окна является нарушением инкапсуляции?

То представление инкапсуляции, что вы имеете, оно опирается только на наличие модификаторов доступа public и private. Является ли инкапсуляцией наличие модификаторов доступа? Нет, потому что не было бы описано 100500 книг и статей по поводу двух модификаторов доступа. Инкапсуляция - это, в первую очередь, целостность объекта, т.е., что объект может взаимодействовать сам с собой через внутренние методы (По типу того, как вы описали).

Но неужели объект не может меняться снаружи, или он не может меняться через публичные свойства? Если бы это было запрещено, то в конвенциях к ООП писалось бы такое ещё и жирным шрифтом, что: "НЕЛЬЗЯ ДЕЛАТЬ СВОЙСТВА ПУБЛИЧНЫМИ".

Для примера, есть такой языка как C++ (Думаю, что вы слышали). Там, в отличии от более продвинутых языков программирования, нет большей части упрощающего функционала (Синтаксического сахара, называйте как хотите). Весь объект строится из полей и методов (С различными комбинациями модификаторов доступа). Есть ли там инкапсуляция? Да. Запрещены ли там публичные поля? Нет.

машина машина должен решать задачи по перевозке водителя,

А если вам скажут настроить взаимодействие двух машин? Да, тут свойства использоваться вряд ли будут, но будет ли нарушение инкапсуляции то, что другая машина будет влиять на первую? Нет. Как они будут это делать? Определённо через методы. Зачем тогда есть публичные свойства и поля?

Класс который содержит поля - является структурой данных (без поведения). класс который содержит и структуры данных (т.е. свойства) и поведение является объектом.

Любой класс является классом. Конкретная реализация описания класс является объектом. Структура данных (Вообще модель данных) является самым простым типом класса. Если у класса есть методы для описания поведения, то он всё равно остаётся объектом некого класса. Как выше написал уже Владимир Коротенко :

dto являются легчайшими объектами взаимодействия с бд, они просто по своей сути не могут содержать в себе логики

мы хотим при оплате добавить еще какое-нибудь поведение, поверх стандартного

Наследование, ещё один принцип ООП. Если полностью закрытый класс даже для наследования (sealed) значит тут уже как не крутись, у вас ничего не получится, как бы вы не ХОТЕЛИ УСОВЕРШЕНСТВОВАТЬ функционал. Значит так задумано вышестоящим разработчиком/ами

но как без знания объекта это сделать

Для этого есть документации. Задумайтесь, на сколько часто вы закрываете свои классы от наследования, когда пишете код?

Не будем же мы после каждого требования бизнеса изменять старый код.

Будете. Будете делать всё что вам скажут, абсолютно.

Давайте представим объект и DTO которым пользуется объект. Если объект возаращает DTO как представление самого себя, например методом showStruct(): DTO будет ли это являться нарушением инкапсуляции?

Я понял ваш вопрос. Смотрите. Философия ООП базируется на том что все действия с объектом должны быть санционированы языком или средой выполнения. Например в Java есть техника рефлексии которая позволяет много чего делать например менять приватные поля. Это часто используется в Mock/Mockito и я часто про это говорю. Мокито - фактически взламывает инкапсуляцию. Но это всех устраивает потому-что "тестить нуна!".
В Java также есть технология сериализации-десериализации которая обеспечивает сохранения состояния объектов на диск или передачу их в сеть для дальнейшей работы (например пользовательская сессия прыгает между нодами кластера). И это действие (сериализация) полностью санкционировано средой и языком. Всех это устраивает. Хотя с моей точки зрения - этож капец взлом. Но зато в Java вы никогда не сделаете down-casting объекта одного типа к типу другого если иерархия этого не позволяет. Этого делать нельзя ... ну потому что это точняк нарушение ООП. И нельзя найти никакой санкции на такое странное действие. Вот в языке С++ например вы можете жонглируя указателями взглянуть в любую память своего процесса или потока и прочитать любой байт или word/dword. Что можно сделать в PHP из подобного? Я не знаю. Но новерное что в PHP много механик которые не позволяют делать хакинг когда. Вот. Поэтому ООП и считается философией программирования а вовсе не тюрьмой. Вобщем код надо писать по правилам языка и среды а не "хачить". И лучшие практики ООП они как раз стоят именно на этой идее. Кроме того - не существует единого ООП - а есть просто разные его реализации в разных языках. Короче вы не найдете самого-самого-ООП-шного языка.

А вообще если это опнсорц - ну сделайте себе форк и меняйте что хотите в исходниках.

И Еще пример. если объект не будет возвращать никаких данных о себе, то тогда как придерживаться принципа OpenClosed?

Про что вообще OpenClosed? Это - расширенная трактовка ООП в части SOLID (вторая буква О).
Означает что если вы хотите внести изменение в класс - то вы его наследуете. Например
class BMWX5 extends BMW { .. }
Мы ничего не нарушили. Мы не меняли свойств BMW. Мы создали новый класс BMWX5 где есть изменные методы. Оригинальный BMW мы не трогали. Все - в правовом поле.

Начнем с первого вопроса:
Я бы вообще не смотрел вакансии где написано "ручной тестировщик", а искал вакансии где написано "тестировщик" и необходимы навыки автоматизации, или обозначено "тестировщик-автоматизатор". Т.е. понимаете, что если фирма в голове у себя считает что тестировщики делятся на ручных и неручных то вам с такой фирмой не по пути. Вы там в лучшем случае наберете нужное количество лет профессионального опыта, чтобы свалить оттуда без сожаления при первой возможности.

И нe смотрите на конкурренцию, смотрите на свои интересы. Нужно заходить с сильной позиции. Люблю тестировать, дотошный, целеустремленный, упорный, люблю технологии, быстро учусь, и т.п по списку. Если им такой не нужен то они себя лишают хорошего сотрудника или сотрудника на вырост. Так им и надо. Следующий.

Второй вопрос:
Может так случиться что применения всему спектру навыков на проекте не найдется. Так что сильно заморачиваться изучением чего-то сильно отстоящего от мейнстрима вероятно не стоит. Но ознакомиться на уровне чтобы понимать о чем и зачем это - стоит. И чем шире спектр осведомленности, тем лучше. Меня например спрашивали на собеседовании, знаю ли я JMeter, сказал знаком, знаю зачем он, пользоваться не приходилось, если надо научусь. И мне много-много чем не приходилось пользоваться о чем я знаю. И это нормально. Сегодня человеку умственного труда важно научиться учиться. И быстро адаптировать свои навыки под новые требования. Гибкость бьет всё. Гибкий кадр это джокер-карта в руках проект-менеджера.

Третий вопрос:
Куда стоит развиваться это девопс, там огромный простор. И тестировщику-автоматизатору это близко. На начальных стадиях удобно самому управлять инфраструктурой для тестирования, а дальше можно и облачные технологии изучать для скалирования.

Что касается перехода в менеджеры, у меня был момент когда мне предложили перекинуться в разработчики либо пойти в тест-менеджеры. Но я понимал что из крепкого тестировщика-автоматизатора превращаться в нуба разработчика не комильфо. А тест-менеджер, это куча отчетности, а тестировать будут другие. А мне нравится тестировать. Поэтому не пошел ни туда ни туда. А остался дальше тестировщиком-автоматизатором. И оказалось что это дерево растет пока растешь ты.
--
Надеюсь попал своими ответами в ваши вопросы хотя бы на 7/10 :)
Спрашивайте еще, пишите в личку если что, я на хабре есть, а может еще в моих старых комментариях чего-то найдете полезного.

так ты ж мидл мы у тебя должны спрашивать

Для начала определитесь - стагнация или потеря интереса к профессии
Даже в рамках одной конторы можно интересно и с пользой для дела получать знания
Вот навскидку:
Поиграйтесь с VLAN, разделение сети на сегменты, поднятием MESH
Поставьте и настройте Zabbix, натравите на мониторинг сети
Подберите на свой вкус программу инвентаризации и учета (например, GLPI)
Найдите удалённую подработку
Самое главное - это чтобы было интересно

Откуда миф о нехватке кадров?

От не очень умного коллективного бессознательного, непомерных запросов работодателей и рекламы кусов.

Начнём с последних - реклама курсов. Создаются курсы по IT с целью заработать деньги, а их реклама говорит, что ну НЕ ХВАТАЕТ айтишников, ну нет и всё! А зарплаты - сотка с порога.
Хотя почему их не хватает, кто это сказал, где статистика, графики, отчёты? Этих отчетов НИКТО и НИКОГДА не видел.
Касательно упомянутого автором веба: я начинал свой карьерный путь в начала 2003 года. Тогда уже были форумы по программированию, люди обсуждали, как заставить javascript работать в IE и NetscapeNavigator. Это было 20 лет назад почти. Как думаешь, за 20 лет сколько людей вкатилось в сферу программирования? Десятки тысяч стали полноценными специалистами.

Теперь относительно работодателей. У айтишников с незапамятных времен был такой фетиш - "да ты не знаешь бибилотеку Н? - Ну ты и лох" - образно говоря. Чем больше знал айтишник - тем он был круче, чем другие. Это был своего рода выпендрёж одних айтишников перед другими.
Но это было давно, опять же, лет 20 назад. За последние 20 лет индустрия рванула вперед настолько, что каждая технология, каждый ЯП оброс массой технологий-сателлитов. Для работы фронта нужно знание JS и каких-то там библиотек. Для работы с PHP требуют в вакансиях знания как минимум ТРЁХ фреймворков, не говоря о сопутствующих библиотеках, знания ОС unix/linux, DevOps, СУБД/высокие нагрузки, кэши-редисы, умение это все грамотно применять и т.д. Работодатели видят, что айтишник - это такой весьма покладистый тип личности, которого хлебом не корми, а дай что-нибудь поучить в свободное от работы время (ну а зачем зашуганному ботанику свободное время, пусть сидит дома фреймворки изучает). Вот работодатели и начали задирать планку и жаловаться, что "специалистов не хватает".
Да, сумасшедших гениев, кто знает целые вереницы технологий, намного меньше, чем обычных ребят, которые исполняют свою зону ответственности. А поскольку работодатели хотят сэкономить, то ищут этого фантомного чудо-программиста, который должен, по их мнению, работать за три отдела. Не находят и жалуются, что "специалистов не хватает".

Теперь последнее. На подобный вопрос, как ты видишь, все отвечают примерно так - "есть нехватка квалифицированных кадров". При этом НИКТО не даст ответ, чем квалифицированный кадр отличается от неквалифицированного (и, опять же - КТО сказал, что есть нехватка?).

Вклад в этот миф о нехватке спецов вносят сами разработчики. Сидел такой Петя, кодил 5 лет уткнувшись в монитор, потом его руководитель увольняется и, о чудо, Петя становится НАЧАЛЬНИКОМ отдела аж из пяти программистов. И вместо того, что бы делать свою работу хорошо, у Пети формируется синдром вахтера и Петя начинает задавать весьма заковыристые задачки на собеседовании, заставлять кандидата писать в режиме реального времени код, дает ему тестовое задание на 2 недели. А когда кандидаты сливаются, начальник-Петя, решает, он самый умный, а "спецов не хватает". Хотя проблема не в спецах, а в идиоте-Пете, который самоутверждается через свою должность главного формошлепа.

И что самое главное. Кому в РФ нужны айтишники? Бизнесу. В первую очередь.
Бизнесы развиваются в ногу со временем.
Взять в пример бизнесы 2010 года - что они делали? Свои веб-сайты, пилили какие-то свои наколенчатые решения.
Что делают бизнесы 2022 года? Идут на ВБ и Авито, покупают готовые продукты.
Время расставляет всё по местам, происходит оптимизация.
Что бы твою продукцию покупали больше не надо держать ИТ-штат для поддержки сайта, для этого есть ВБ.
А с учетом последних событий бизнесы будут неминуемо сокращать расходы.

Айтишники были в последние годы слишком дорогим удовольствием для бизнесов, айтишные аппетиты реально стали чем-то запредельно наглым, когда видишь, что Маша 25 лет с 2 годами опыта хочет 250 000 рублей.
Бизнесы в нынешних условиях неминуемо будут сокращать траты и условные Маши, которые вчера хотели 250 000 за JavaScript скоро будут работать за 50, тк таких Машек с каждым годом всё больше и больше.

Сфера айти перестала бурно расти и развиваться, но она никуда не денется. Появились нюансы. Повсеместная пропаганда престижности и якобы больших зарплат привела к тому что много человек бросились скорее входить в айти. Из-за этого устроиться новичку не так просто как это было лет 10 назад. Тем не менее, тот кто осознанно идет учиться на программиста и получает серьезное образование в этой сфере устраивается нормально. В этом случае можно надеяться на достойную зарплату и человеческие условия труда. Выгоднее выбирать направление связанное с точными науками, где от программиста требуют помимо кодинга знания, например, некоторых разделов математики (как пример, цифровая обработка сигнала, графика). Таким образом, будешь тем самым инженером-программистом.

Насчет сильного ИИ можешь не беспокоиться. Если он и будет сделан, то на компьютерах с совсем другой архитектурой и физикой.