German Jet

Если вы Битрикс 1с специалист и не знаете 1с, то термин "внедрение 1с" будет слишким широким для вас. 1с поделена на несколько ниш. Специалисты 1с как правило охватывают пару-тройку из этотого. речь идет о конфигурациях 1с. Кто то умеет торговлю внедрять, (УТ11. УТ10.3), кто то ERP2, кто то Зарплату (ЗУП), кто то всего понемножку. чтобы внедрить 1с недостаточно просто скачать инсталляшку и установить. Там надо еще помогать клиенту настраивать учет. множество настроек. Когда надо внедрить 1с, то клиент обращается к 1с франчайзи компаниям и обрисовывет свою задачу. Под его нужды продежкт менеджер или кто-нибудь еще выбирает конфигурацию 1с и назначает нужных специалистов под нее. Ну и оговариваются моменты синхронизации 1с с имеющимися сервисами или системами клиента. а всё знают только очень опытные специалисты, которые поработали в разных местах в том числе и в разных франчайзях. Они исходя из своих знаний могут вам порекомендовать что то. но внедрять лучше если будет узкоспециализированный специалист каждый вид конфигурации 1с. Таких и отправляют. Под бухгалтерию один, под зарплату другой, под производство третий.

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

Технологий слишком много, и у разных компаний может быть совсем разный стек. Кто пишет сайты - обязательно фреймворки, а где-то их не будет. Где-то будут требовать знание Vertica или Clickhouse, а много где вообще ни разу не услышите этих слов. Кто-то захочет еще и знание Go, а где-то очень желателен будет React и пофиг что это не backend.
Но есть и общие моменты, очевидно знание git, PSR, composer, xdebug, для мидла должны быть не "навыки ООП", а отличное знание и понимание (в том числе SOLID, GRASP), оценка сложности алгоритмов, sql с пониманием работы индексов (разумеется нормализация, транзакционность, уровни изолированности, ACID), знание того же самого PHP (начиная с того, где и когда применяем Exception заканчивая SPL, Reflection, даже если никогда к ним не обращались, нужно знать, что они есть, когда возникнет необходимость), способы защиты от уязвимостей, сложности параллелизма (та же самя "гонка"), типы данных и что они из себя представляют (начиная с банального почему деньги не храним в float и т.п.). К примеру, вы можете не использовать ORM, но должны знать какие они бывают и доказать почему собственно вы их не использовали в конкретной задаче. Тоже самое trait, clojure и т.д. И много еще чего. Вплоть до провакационых вопросов "есть ли в php перегрузка?".
Это часть базисных вещей, на которые накладывается специфика работы со своими технологиями.

Postgresql вам редактировать и не препятствует. Раз вы смогли сделать create table - значит база не в read only режиме. Напишите соответствующий update и выполните.

А вот вашему GUI клиенту скорей всего не нравится отсутствие primary key.

Атрибуты это PHP . У вас должна быть версия 8.0 или выше.

Если я правильно понял вопрос (а это непросто), то потому что язык SQL - нечувствителен к регистру, т.е. следующие запросы эквивалентны:

select * from Groups;
select * from groups;
select * from GROUPS;
SELECT * FROM groups;
SeLeCt * FrOm GrOuPs;

Если вы берете название таблицы/колонки (или иного объекта БД) в кавычки, он становится (по крайней мере, согласно SQL стандарту) case-sensitive, т.е. "group"/"Groups"/"gRoUps" - будут разными идентификаторами (например, все три такие таблицы могут существовать в БД одновременно).
Если кавычек нет, идентификаторы по стандарту сравниваются после приведения к upper-case. В Postgres это немного не так: там идентификаторы без кавычек приводятся к lower-case.

Т.е. другими словами, запрос create table Groups ... создаст в Postgres таблицу с именем groups. Запрос select * from GrOupS; будет также искать таблицу с именем groups.
При использовании кавычек запрос create table "Groups" ... создаст таблицу с именем Groups. Запрос select * from "GrOupS"; будет также искать таблицу с именем GrOupS.


Обычно это не вызывает проблем, пока вы не начинаете использовать закавыченные и незакавыченные идентификаторы одновременно. Например, что скорее всего имеет место в вашем случае, таблица создается запросом

create table Groups ...
-- реальное имя таблицы - groups

Когда же вы делаете запрос select * from "Groups", обращение идет к несуществующей таблице Groups.

В общем, разберитесь, какое название у таблицы в БД (в psql команда \dt, или смотрите свойства таблицы в своей среде). Если оно не lower-case, используйте кавычки с точным названием (например, select * from "GROUPS"), в противном случае лучше обходиться вообще без кавычек.

Могу ответить с точки зрения фрилансера:

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

Вот несколько советов, которые помогут улучшить «возвращаемость» фрилансеров:

• Чаще всего фрилансер готов делать работу сразу (особенно когда работает с вами первый раз), он показывает рвение и очень быстро всё делает. С вашей стороны ожидается, что вы можете оплатить работу мгновенно после того, как всё сделано и проверено как фрилансером так и вами. Если вы скажете фрилансеру, что вам нужно некоторое время, чтобы дойти до банкомата и пополнить счёт, потому что прямо сейчас не можете заплатить, это очень сильно испортит впечатление, и с большой вероятностью человек не покажет виду, спокойно без психов подождёт, когда вы ему заплатите, но в следующий раз работать с вами больше не будет. Фрилансер готов работать сразу, значит и вы должны быть готовы платить сразу.
  
• Если у вас низкая техническая подготовка, и фрилансеру приходится кроме самого кода очень много общаться с вами на тему, что именно нужно делать, желание работать дальше тоже пропадает. Чем меньше требуется обсуждений и созвонов в мессенджере, тем больше веротность, что фрилансер и дальше будет с вами работать. Фрилансеры обычно не считают переписку частью оплачиваемой работы и, соответственно, чем больше времени будет занимать переписка, тем меньше будет желание продолжать работу. Фрилансер обычно хочет сразу делать работу и не отвлекаться на всякую бесплатную болтологию.
  
• Если фрилансеру нужно заниматься в дополнение администрированием вашего сервера, а это заранее не обговаривалось, это тоже может испортить впечатление. Часто заказчики пишут, что им нужно поправить менюшку на сайте, а это в итоге превращается в правку менюшки, а потом залитие кода на сайт, настройка и перезапуск сервера и ещё какие-то подобные работы, которых в задании не было вообще. И, скорее всего, вы считаете само собой разумеющимся, что фрилансер должен уметь это делать, и думаете, что это нормальная практика, если он в дополнение к кодингу будет делать ещё и это. Дополнительно, если эти моменты ещё и не оплачиваются, шансы, что люди захотят с вами работать и дальше, снижаются ещё сильнее.
  
• Некоторые заказчики любят показывать свой авторитет. Запомните, что для фрилансера вы не начальник, а равноправный партнёр, и он ждёт от вас соответствующего уровня общения. Если вы строите из себя начальника, люди будут придумывать любые отмазки, но повторно работать не станут.
  

Вот это основные факторы, которые влияют на то, что вам ответит фрилансер, если вам понадобится помощь в следующий раз, и вы решите, что можно обратиться к тому, с кем раньше работали.

Считаю, что "проектом" можно обозвать много чего. Отсюда и следует их объем и сложность, а следовательно и возможность ими управлять.
Если проекты не сложные, по развитию уже действующих, то 7 сложно, но посильно.
Если 7 полноценных сложных проектов, то скорее всего будет очень сложно и вплоть до провала всех.

В данный момент у меня 3 сложных проекта, 4 средней сложности и много мелких задач и я чувствую, что не справляюсь в некоторых из них. А есть ещё крупные задачи, за которые я пока "не успеваю" взяться. Я участвую со стороны заказчика.

Ох, тут уже на предлагали... Что ж, я не путешествую, но вопрос "куда можно запихнуть мини ПК" меня какое то время мучил, и я пришёл к выводу, что из мини ПК может получится неплохая ретро-консоль. И естественно она должна быть портативной. И раз вам так хочется сменить ноут на миник, то поделюсь к каким выводам я пришёл.
1. Покупать что то излишне миниатюризированное формата raspberry Pi не стоит. Это вариант для умного дома и управления прочими прибамбасами, а не для работы или тем более игр. Естественно туда же идут и все варианты, напоминающие флэшку. При попытке работать будете плеваться от тормозов.
2. Излишне тесный корпус приводит к нагреву и требует излишнего охлаждения. А это шум, доп потребление, механические детали и повышение стоимости . В тесных корпусах возможно только CPU с очень низким теплопакетом, а значит смотри пункт первый, тормоза неизбежны.
3. Только не Андроид (и arm)! Не знаю кому как, а мне софта на адройде мало И практически отсутствует open source варианты. Так что и всякие планшеты и тв-боксы и подобный хлам - в лес. К тому же можно ещё испытать и прекрасный геморрой при попытке с планшета вывести изображение на монитор. Не все планшеты такое поддерживают.
4. И не intel NUC или тем более его китайские собратья. В качестве самого NUC сомневаться не приходится. Однако, тем не менее, это проприетарная платформа и от ноутбука отличается только отсутствием монитора... Ничего толком не известно сколько будет стоить апгрейд и будет ли он вообще возможен. А спрашивается зачем тогда оно ? По этой же причине и не мак-мини и прочие надкусанности. Сюда же ещё и дефицит софта в сравнении с x86 как и у андройда.
Итого: приходим к выводу, что это будет самосбор:
Вариант 1: Корпус формата mini ITX - не слишком маленьких, что бы туда влезало типовое железо и небыло проблем с охладом и не слишком большой потому что портативность. Объём 2-5 литров. Плюсы:
- можно собрать x86 на десктопном процессоре, с приличным объёмом оперативки и даже встроенным SSD приличного объёма (хотя уж с этим то сейчас проблем нет и полно внешних корпусов для SSD, но встроенный вы не будете искать среди кучи хлама после очередного переезда.
- всё ещё поддается апгрейду, но занимает места примерно столько же сколько и ноут. Допускает относительно хорошее охлаждение Широкий выбор самих корпусов, как у именитых брендов так и китайцев. Полностью сменная начинка, которая никуда не исчезнет с рынка. И даже сменный процессор и память. И в тоже время - внешний БП как и в ноуте (правда без батареи, но как говорится, кто мешает и её воткнуть...), может оказаться полезной вещью в дороге, если нужно запитать ещё какие то низковольтные устройства от 12 вольт
- Возможность втыкивать достаточно мощный процессор. Я присматривался к райзену с интегрированным GPU. На таком не только работать, но и во что то не сильно требовательное можно поиграть.
- Можно настроить dual boot - windows + linux для тех кому нужно. Полноценная сеть (уже не во всех ноутбуках она есть. А во всяких малиноподобных вариантах - как правило, сеть медленная)
- Широкий набор внешних портов. Любой ноут здесь проигрывает. (другой вопрос нужно ли это для вашей работы)
- Прочный металлический корпус (полно как стальных, так и алюминивых вариантов. Есть и пластиковые, но я бы брал металл как из-за прочности так и из-за охлаждения)
Минусы:
- Цена Как говорится, из разряда "отложу как я это до лучших времён" С такими ценами, как сегодня, вообще не выгодно менять железо.
- Надо собирать самому (ну для меня это не минус, а для вас - не знаю)
- Размер и вес скорее всего будет немного больше того же Intel NUC но, считаю, что это не существенно.
- мощность системы не должно превышать 150-200 ватт иначе будет перегреваться да и БП на такую мощность найти сложновато. Вполне можно уложиться если брать CPU с TDP 45-65 Ватт

Вариант 2 Мощный самосбор в корпусе miniITX объёмом до 12 литров. Плюсы:
- Всё тоже самое что и варианте 1 но немного дешевле т к корпус больше
- Уже есть возможность запихнуть какой-никакой дискретный GPU Но тут надо заранее выбирать и велика вероятность того, что этот элемент потом обновлять будет тяжело, т к трёх-слотовый монстр длиной 30+ сантиметров туда не встанет, а среднебюджетных вариантов как то не видно на горизонте Только слабенькие GPU делают в усеченных размерах и их ещё найти нужно.
- можно поставить очень хорошее охлаждение при желании. Но тоже нужно об этом думать на этапе выбора
корпуса
- Уже относительно стандартные внутренние БП на 300-500 ватт
Минусы:
- Вес. Если для вас не критично вес в несколько килограмм (сейчас только видяхи по килограмму весят =)
- Размер 12 литров - это как два с половиной пятилитровых бутыля. Для сравнения, обычно корпуса ноутбуков не превышают 2-х литров. Очевидно, при авиаперелетах это скорее всего в багаж отправится...

С малых лет увлекался компьютерами. В школьные годы ходил на курсы «Сергис».После 9 класса отучился в колледже Бонча. После колледжа поступил в университет (закончить не смог из за семейных обстоятельств, в ближайшее время собираюсь перепоступать).

Никому не интересно. Тут нет ИТ опыта.

С компьютерами как эникей-сисадмин начал работать в судах

У многих понятие эникей-сисадмин это тот, кто меняет мышку и переустанавливает софт. То есть продвинутый юзер.

У моменту увольнения из был Консультантом(и ИО начальника отдела информатизации и статистики)
Управлял отделом (пусть и маленьким)

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

Занимался всем (ремонт компьютеров, мелкий ремонт мфу, обновление и настройка по на пк и серверах)

Ну вот. Что это за ремонт?
Я понимаю, когда под "чинил мфу" ты бы написал "менял печку, перепаивал конденсаторы на платах". А так, среднестатистический эникейщик под ремонтом принтеров и МФУ обычно вытаскивает забитую бумагу и сдает картриджи на перезарядку.

Я попал на время становления ИАЦ по этому на нас испытывали многое по
И у нас было больше свободы и доступа в отличии от других судов
Я многому научился за годы работы там

Какая полезная и понятная информация.

Позже я устроился на завод «младшим сисадмином»
Позже стал начальником отдела
И в итоге являюсь Инженером ТЗИ

Какая полезная и понятная информация.

За время своей работы я поднимал доменные, файловые сервера

Создавал свой домен с нуля, или что такое "доменный сервер"?
Что такое файловый сервер - просот расшарил папку на диске (сейчас может даже блондинка сделать), или ставил Novell Netware?

Обновлял и правил 1с на серверах

Что сюда входит? Обновлял темплейты отчетов? Писал код? Или просто по инструкции обновлял? Во многих компаниях обновление делает либо сам бухгалтер, либо отдельно выделенный человек. ЧТо делал ты - неясно.

Тянул сеть и худо-бедно настраиваю микротики
Поднял сеть видеонаблюдения на трассире
Разобрался и привёл в порядок систему турникетов и шлагбаумов perco
Позже прошёл обучение в perco (хотя по факту я уже все знал к тому моменту из того чему они учили)

Ну хоть что-то конкретное. Но опять таки, микротики можно настраивать по-разному. Система турникетов и шлагбаумов - сам проектировал или просто оптимизировал уже имеющееся? (Скорее всего там очень простые настройки)

Работал с поставщиками и менеджерами

Так все это делают в конторах где нужно покупать какую-то технику.

И по факту организовал пусть не идеальную, но стабильную работу на отдельно взятом заводе
Я если чего-то не знаю то гуглю/ищу знакомых/техподдержку которые могут ответить на мои вопросы
Да у меня есть пробелы в знаниях
Я этого не скрываю
Я слаб в теоретической части и я это понимаю
По факту со многими вопросами приходилось разбираться на ходу

В первую очередь ярко выражен недостаток в виде неумения сформулировать свои мысли и выдать конкретику. А это один из самых главных требований к любому айтишнику.

Я пытался откликнуться на вакансии младших системных администраторов, эникеев в крупных и средних компаниях, но мне приходит отказ или просто игнор

Так а требования совпадают с резюме?

Соответственно прошу помочь статьями/объяснением как правильно создать резюме и как подать себя

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

Вот после прочтения, я понятия не имею, сможешь ли ты поднять домен с нуля. Сможешь ли ты вайфай настроить с бесшовным соединением в частном доме чтобы добивало на 100-200м и не пускало соседних кидди-хакеров в локалку. Сможешь ли корпоративную почту хотя бы настроить или какой-то мониторинг организовать. Умеешь ли в скриптинг хоть на чем-либо.

Нет информации никакой.

Буквально неделю назад закрыл в отделе вакансию, искал человека в том числе без опыта (не по Вашему профилю, правда), смотрел в пераую очередь на сопроводительное письмо и описание технологий, с которыми человек сталкивался. Если это был отклик, а не предложение от агентства, смотрел особенно внимательно.
Ищите, и найдете.

Как правильно заметили, не бойтесь отправлять резюме на вакансии, где есть часть технолоигй, которые Вы еще не освоили. Обычно указывается весь стек задействованных технологий в надежде "а вдруг повезет". Бывает, что большинство сотрудников в отделе достаточно универсальны и нового человека можно кинуть на любую из используемых технологий, закрыв остальные уже имеющимися сотрудниками. На начальных вакансиях могут искать человека под обучение, т.е. технология в описании означает скорее что с этим придется работать, а не как требование идеально ее знать на момент найма.

И рассылайте, рассылайте, рассылайте резюме. На HH, linked.in, и других площадках. При прошлом поиске работы у меня было отправлено более 150 резюме и только с десяток дошли до собеседования, кстати. И, замечу. я уже много лет в разработке. Но бывает что везет и даже первое резюме оборачивается оффером.

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

Удачи в поиске!