Vasyl Fomin

В течении дня могли переключить на другое задание, не связанное с программированием (скорее с тех.поддержкой ), а потом говорить почему я то не сделал.

1) Косяк в организации работ на фирме.
2) С вами не должны нянчиться, про все детали как вы работаете не должны помнить. Если у вас проблема - общайтесь с руководителем непосредственным.

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

И кто за вас будет задавать вопросы?
Выяснение задачи до конца, прежде чем начать работу - один из основных навыков программиста.

Каждое задание мне приходилось переспрашивать по 5 раз, а если вскрывался подводный камень, о котором мне не говорили, то ещё по 5 раз.

Абсолютно нормально для начинающего.
Более того - абсолютно нормально даже для сеньора, который только входит в новый для себя проект.

Да и вообще - подводные камни - это "наше все" в программировании.

Знаний для позиции Junior C# с головой

Нет. Вы не джун еще. Вы всего лишь "трейни".

но я элементарно не справлялся с задачами, которые мне давали, потому что я просто не знал что и как устроено, работает, откуда обращается и где вызывается, от чего зависит и тп.

Один из типовых навыков программиста - это все выяснять.
Постоянно, каждодневно.
Это нормально.

Получается, что каждое задание - это постоянные вопросы, непонимание, моральное давление

А вы часом не перехвалили себя в резюме?

От вас поди ожидали большей квалификации.

За всё время я лишь подтянул знания о git'е и не более.

Вас никто не будет учить, кроме вас самого.

можно ли назвать позицию "Разработчик C#/.NET", если за месяц стажировки я написал максимум 10 строчек ?

Вполне.
Дело трейни - разбираться, вникать. Тем более первый месяц.
И вообще производительность труда программиста отнюдь не в количестве строк меряется. Я с месяц назад за исправление значения 2 констант взял 6 000 рублей за свою работу.

После своего первого опыта чувствую себя ни на что неспособным в программировании. Со стажировки ушёл.

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

Большинство программистов, кстати, предпочитают не вникать.
А писать свои велосипеды.
В частности потому так очень популярен фриланс "в одного".

Не нашел ничего такого эдакого в вашем описание.
Все норм. Примерно так и должно быть

Из реальных косяков фирмы:
Другое дело, что в нормальных фирмах к стажеру прикрепляют наставника на месяц другой.

Все остальное:
Исключительно ваши косяки.


Вы напрасно слиняли.
Как показывает моя практика - 2 недели нужно только для первичного вникания.
То есть когда ты еще ничего не понимаешь по сути, но хоть что то полезное делать можешь. 2 недели только на это.

Есть 2 пути программиста:

1) Индивидуализм. Фриланс. Говносайты, говноприложения. Работа в не ИТ-шных фирмах или в мелких фирмочках где не поставлен процесс и по сути делаешь все один. Плохо тем, что не от кого получить обратную связь не с кем учиться, нет опытных коллег рядом. Всю жизнь будешь делать говносайты и говноприложения. Ну чуть чуть более цивильно. И все. Это предел.

2) Если хотите все же заниматься в жизни чем посложнее и поинтереснее и поденежнее - учиться в большой конторе с коллегами. Где поставлен процесс. Где твою работу контролируют. Да придется ковыряться в куче чужого года, в куче легаси. Это нормально. Для высококвалифицированного программиста - чужой код и взаимодействие с коллегами крайне важно. Технически серьезные проекты делаются только большими группами программистов.

Нет, если никаких примесей к слагу не добавлять то только выносить таблицу со слагами отдельно как говорите вы сделано в друпале. И пользоваться полиморфными связями https://laravel.com/docs/5.6/eloquent-relationship...

чтобы к ней не лезли на прямую.
а) в интерфейсе можно определить только метод.
б) переопределить можно только функцию.

еще плюсы можно мокать в тестах
и куча других плюсов использования гетеров и сеторов оопа.
минусы чуть медленнее.

Скорее всего у вас в таблице users должна быть колонка group_id для привязки пользователя к группе.

В этом случае правило такое:

'email' => Rule::unique('users')->where('group_id',  $request->input('group_id'))

В мидлваре.

Когда же вы, люди, научитесь уже использовать поиск или читать документацию, в самом деле... Даже на Тостере уже не раз этот вопрос поднимался: начиная с версии 5.3 в конструкторе контроллера недоступна сессия.

Мне кажется запрос получится слишком сложным.
Лучше вам в таблице книг добавить колонку куда записывать первого автора.

Первое - нужно соблюдать правила именования:
Модель - Item -> таблица - items
Модель - Category -> таблица - categories
Pivot таблица category_item - в едиственном числе в алфавитном порядке по названию полей с полями item_id, category_id.
Очень классно об этом расписал greabock

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

<?php

namespace App;

use Illuminate\Database\Eloquent\Model;

class Items extends Model
{
    protected $fillable = ['name'];

    public function categories() // название релейшена во Множественном числе, связь же ManyToMany
    {  
      return $this->belongsToMany(
           Category::class,   // Название модели 
           'items_categories',  // название твоей связующей таблицы
           'item_id',  // ключ к текущей таблице в связующей таблице
           'category_id'  // ключ к внешней таблице в связующей таблице
       );
    }
}

Потом ты можешь работать так же как с любыми другими моделями через эту связь. Например

$item = Item::find($id)
$item->categories()->create($array_of_data)

а как я знаю, сессию можно своровать

беда, расходимся (

А ещё есть вариант №3 — раскладывать все классы (в том числе и контроллеры с консольными командами) по разделам бизнес-логики, т.е. что-то типа DDD. И все варианты правильные, и все используются. И, наверное, существуют варианты №4, №5 и т.д.

На этот вопрос нет единственно верного ответа.

Ввести дополнительное поле "версия", и при записи его увеличивать. Ну а перед записью проверять, чтобы версия совпадала с редактируемой. Это называется "Оптимистическая блокировка".

Отдельная таблица для: товара, города, категории, параметр
связь один ко многим: категория - товар(в товаре id категории)
свять многие ко многим: город - товар, товар - параметр (в связующей храним значение параметра для конкретного товара)

Во имя быстродействия используем разные инструменты типа поисковых движков(sphinx, elastic, solr) или первое время обходимся кешем