О разнице работодателей.⁠⁠

я пару недель работаю, поэтому пока речи о поднятии не идет.

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

Компания не иностранная, з.п. выше рынка если проработать порядка 2ух лет.

Я видел что отдел растет, и на 4ех программистов было человек 10 аналитиков ._.

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

Деньги были и в конце концов они ведь предложили 140, значит были деньги, а до этого тупо экономили.

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

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

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

А так если и буду, то скорее на реддите, тут возможно копии будут, пока не знаю.

И нам надо перейти на другую ветку, даешь +1 коммент в другой ветке, а то тут в конец уже не дает писать

Да, но с помощью LINQ и Where ты можешь ограничить набор элементов заранее.

Я привык его использовать, просто нужно понимать где он нужен, а где нет.

Не везде нужно перечисление по всем элементам.

Как по мне самый редкий используемый цикл For )

Как перечислить часть?

Ну на ум 3 варианта:

1) var from = 0;

var to = 10;

string[] OurArray;

For (int i = from; i<= from+to; i++)

OurArray[i];

2) while (i <> from + to);

OurArray[i]

I++;

3) не использовать массив, а использовать список и делать

StringList.GetRange();

Собственно для массива - For цикл будет идеальным вариантом обычно.

Есть еще вариант через добавленный в последних версиях C# Span

string[] arrS = { "ttt", "qqq" };

Span<String> something = arrS.AsSpan(0, 1);

something.ToArray();

Span - это по сути указатель на область памяти, значения 0 и 1 ты можешь ввести вручную, и дальше работать уже с массивом который получишь путем ограничения текущего, но зачем если есть For, делающий то же самое.

Алгоритм - прямо по определению.

Есть паттерны, алгоритмы как матан методы про них мало чего помню если честно.

А вот паттерны - это для понимания построения архитектуры.

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

Один метод, одно имя, но разные реализации.

Weapon - базовый класс для Sword, bow и т.д.

Но у всех них есть своя реализация Attack.

Полиморфизм + наследование.

Вроде того.

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

У класса Bow и Sword есть метод с одинаковым именем Attack, но работает он по разному.

Суть классов в том, что ты можешь в классе Weapon тупо вызывать этот метод.

Пример:

List<Weapon> wList = new list<Weapon>();

wList.add(new Bow());

wList.add(new Sword());

wList.add(new Spear());

wList.add(new Pistol());

Foreach (var el In wList)

{

el.Attack();

}

Соответственно у тебя будет 4 разных(абсолютно) реализации класса Weapon, но они будут лежать в одном месте вызывать по сути разные методы но через один простой цикл.

Подобная магия наследования, делегирования, анимизации.

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

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

Класс для доступа к базе А.

Класс для доступа к базе Б.

Класс для связи модели с базой А.

Класс для связи модели с базой Б.

Класс модели В.

Класс модели С.

API для модели В.

API для моделей B и C.

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

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

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

Ты повышаешь уровень абстракции.

Ну и наконец в ООП языках в C# в частности есть только классы.

У тебя нет натив кода, у тебя все - объекты.

Это быстрый способ хранить тонны информации, у тебя на карте больше миллиона объектов и все они описаны в памяти, а логическое разделение позволяет тебе не запутаться где и какой объект.

ООП.

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

Класс это некая структура созданная с одной целью, как вариант - фабрика объектов.

Все что она делает - конструирует какие-то объекты в зависимости от входящих параметров. Она не умеет выводить информацию, не умеет общаться с сетью, она тупо конструирует объекты.

Классы наверное ближе к архитектурному решению для избавления от гавнокода, но штука это важная.

+ банально создание неких объединенных структур данных.

Пример:

У тебя есть воин и лучник.

У каждого есть доспех и оружие.

У каждого оружия есть параметры.

У каждого доспеха есть параметры.

Тут уже можно разбить на множество классов.

Class Weapon

{...}

Class Armor

{...}

Class Warrior

{

Weapon warWeapon;

Armor warArmor;

EnumWarType warType;

public Warrior(enumWhatToCreate createArg)

{

switch(createArg)

{

CASE warrior:

warWeapon = new Weapon("Sword");

warArmor = new Armor("Heavy");

break;

case Archer:

warWeapon = new Weapon("Bow");

warArmor = new Armor("Light")

break;

}

}

}

Суть:

В принципе воин и лучник имеют абстрактно одинаковые вещи:

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

Тебе нужна удобная структура, которая будет создавать тебе нужного воина, грубо говоря где-то на верхнем уровне юзер тупо нажмет на иконку лучника, в этот момент ты создашь класс Warrior у которого будут методы атаки и расчета сопротивления удару например, создашь его с параметрами лучника и запомнишь в одном выражении:

Var myWarrior = new Warrior(enumWhatToCreate.Archer);

Добавим функционал - воин может сменить оружие.

Мы можем в класс Warrior тупо добавить метод ChangeWeapon

и подменять воину значение Weapon а соответственно и все коэффициенты расчета атаки всего за один вызов.

Таких примеров можно придумать много, тут надо думать не сколько о коде, а сколько о логическом разбиении объектов.

_____________________________________________________________________________________________

Вот у тебя есть монитор, у него есть разъемы, они выполняют одинаковую функцию, но отличаются какими-то параметрами, относятся ли эти параметры к самому монитору?

- нет не относятся, они относятся к разъему.

Свойство "тип разъема" - это свойство разъема, а не монитора.

Монитор знает "имя разъема" и все.

Абстрактное мышление, так можно разбить все - клавиатура.

Сама по себе клавиатура не определяется кнопками, она определяется типом, механическая там или мембранная.

Но при этом есть класс кнопки, он одинаков для всех клавиатур, нужно ли знать об этой кнопке клавиатуре - скажем так, клавиатура знает что у нее есть кнопка F.

А кнопка знает как:

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

я хз они в честь открытия замутили, ну мы и зашли с тян.

Да воздушные офигенная тема )

Сейчас вообще жара пришла, ебал я в жопу это лето...

Думаю купить кондер, правда не знаю надо ли, ибо вроде как переезжать собираюсь, наверн надо.

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

Я тоже недавно всрал неплохо так денег на обувь, идешь ты в ТЦ посмотреть хеллбоя, а там новый магаз открыли, 3 пара обуви бесплатно, чувствуешь жажду потреблядства и скупаешь 3 пары )

Но теперь у меня есть божеского вида туфли(ибо другие прожили 2 года учитывая что я в них проходил все это время не снимая).

Ну и кроссовки(боже они такие мягкие, я забыл как это) =)

привыкаешь, но get запросы у них херово построены.

Как твои делишки?

Если что можешь меня найти на реддите пикабухи, DnRumata, ну если тут я отвалюсь, вот

Да я тут назвал народ кидающий прон в ленту "гавнарями" и народ обиделся.

вкусняшки это тема, а мне седня з.п. пришла )

это грубый пример, но можно отполировать.

Чистить консоль перед вводом, спрашивать у юзера (вы хотите продолжить? y/n) и при нажатии N также вызывать break;

И тут остапа понесло:

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

Решения могут быть разные, поэтому и говорят про почерк кода, каждый пишет придерживаясь удобных для себя конструкций, каждый думает по своему, один будет использовать For а другой Foreach в одной и той же ситуации )

а что ты хочешь?

что делать после срабатывания catch - выводить сообщение об ошибке например.

Goto - я объясню почему не нужно, видишь ли.

Ты еще не дошла до методов я так понимаю, у тебя есть метод Main() класса program.

Как бы я сделал:

void Main()

While(true)

{

string errorText = string.empty;

errorText = ReadValue();

if(errorText == "ошибка")

Console.WriteLine(errorText);

else

break;

}

private string ReadValue()

{

var parser = console.Readline();

var result = 0;

Try

{

result = int.Parse(readline);

}

catch(exception ex)

{

return "ошибка";

}

return result.ToString();

}

Грубо говоря если у тебя завалится Parse, то функция ReadValue поймает ошибку и за счет блока Catch вызовет тебе не "ААА ЕБ ТВОЮ МАТЬ, СУКА БЛЯТЬ УПАЛО ВСЕ НАХУЙ, ЛИВАЮ С ЭТОЙ ПАТИ", а "ошибка".

При этом ты не выйдешь из цикла(он ведь бесконечный вайлтру, ибо условие errorText == "ошибка" выполнится).

А значит цикл начнется заново(ведь на break ты не попадешь),

ты снова попадешь в ReadValue() и тебя снова попросят ввести значение.

Если же парсер пройдет успешно, то в блок Catch ты не попадешь и парсер вернет тебе число, условие не вызовется и число напечатано не будет, в итоге ты выйдешь из бесконечного цикла ввода(который бесконечный только если пользователь дятел).

Вот как-то так, поэтому GoTo не нужно.

Это ООП, методы все решают, они ссылаются друг на друга и твое IDE тебе это покажет )

Из реального применения циклов:

У тебя есть XML код ну или HTML.

Тебе нужно для всех узлов проверить их содержание:

Грубо говоря:

<html>

<head> trulala <\head>

<body> ololo <\body>

<\html>

Метод проверки контента у тебя может быть одинаковый для head и body, вместо того чтобы писать 2 вызова, ты запускаешь цикл, который берет <node> - узел.

Заглядывает в контент и вызывает твой метод проверки.

И идет так, пока не пройдет по всем нодам документа.

как-то так.

+ внутри циклов могут быть циклы.

Например:

Допустим внутри класса Element есть

List<int> insideElements;

List<element> elementList = new list<element>();

// для каждого элемента elementList

foreach(var el in elementList)

{

//для каждого элемента insideElement

  foreach(var insideEl in el.insideElements)

{

insideEl++;

}

doOutsideAction();

}

anycode...

Суть - мы заглядываем внутрь каждого элемента в списке.

У этого элемента есть свой список(с целочисленными значениями)

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

Циклы в циклах безусловно сильно повышают стоимость кода, грубо говоря тебе нужно сложить общее количество объектов типа Element с общим количество объектов внутри insideElements для каждого элемента.

Грубо говоря у тебя 100 объектов element.

Внутри каждого по 500 записей в InsideElements;

В итоге у тебя будет 100*500 итераций цикла.

Итерация - один полный проход цикла.

Есть еще:

var i = 0;

do

{

something();

}

While(условие цикла( пример: i != 0 )

- anycode...

Разница в том - когда у тебя проверяется условие.

Когда идет твой код, то при входе в цикл, он сразу проверяет условие(для while, for)

Для do while он сначала исполнит код в do, потом проверит, должен ли завершится цикл?

Тобишь у тебя i с самого начала 0.

Но алгоритм будет такой:

- присвоили переменной i значение 0;

- вызвали Something();

- ушли в anycode;

Для обычного While у тебя не было бы второго пункта(something), а здесь он сначала выполнит тело, а потом проверит условие.

В общем разница лишь в том - когда проверяется условие.

GoTo адское зло, которое не используют или используют, когда уже прям совсем критикал.

При норм архитектуре приложения метки не нужны.

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

Как используются циклы?

Есть 3 конструкции по циклам:

1) For

For (int i = 0; i != 2; I++)

{

тело цикла(пример dosomething();)

}

Конструкция внутри: (счетчик цикла, условие цикла(по сути это тот же if но когда условие вернет false цикл закончится), выражение увеличения счетчика)

В чем суть - для счетчика I, который мы создаем когда код доходит до этого цикла.

- пока I не будет равно 2ум.

- прибавляем к I единицу, как только тело цикла проходит полностью(тобишь у тебя прошел вызов doSomething(); 

- к I прибавилась единица(оператор ++)

- и тело началось заново.

Суть циклов в постоянном выполнении некого кода, своего тела, пока удовлетворяется некое условие.

Применяются повсеместно и также распространены как и if.

2) While

var i = -1;

While (I <= 2)

{

dosomething();

I++;

}

While(по сути любое выражение выдающее в конце bool(то же самое условие))

Важно понять, что цикл может быть и бесконечным, а внутрь тела ты можешь написать любое выражение которое в конце возвращает boolean тип(да/нет, true/false).

И цикл будет продолжаться пока условие определяющее его возвращает TRUE.

3) Foreach

List<int> myList = new List<int>();

foreach(var listElement in myList)

{

doSomething();

}

Это скорее исключение - суть, цикл проходит по всем элементам твоего IEnumerable и заканчивается как только доходит до конца.

Если у тебя в myList было 3 элемента(например 3,5,8) то при первом проходе по циклу в переменной listElement будет 3 => вызовется dosomething() => тело цикла завершится.

Второй проход цикла listElement =5 => вызовется doSomething() => тело цикла завершится.

Бесконечные/конечные циклы:

While(true) - ты можешь написать так, это конструкция подразумевает бесконечное условие, но есть 2 стоп элемента для циклов:

Break - выходит из цикла, мгновенно.

Continue - пропускает тело цикла с места вызова, начиная следующую его итерацию.

Пример для Break:

Этот код:

var i = -1;

While(true)

{

if(i >2)

break;

i++;

}

anyCode...

По сути равен примеру с While что я привел выше.

Каждую итерацию у тебя выполняется if пока он меньше 2ух, код будет доходить до i++;

Как только i у тебя станет >2 - вызовется break, который завершит выполнение цикла и перекинет тебя на код следующий за циклом(anyCode).

Пример для Continue:

например у тебя есть список чисел (2,3,4,5,6) - тебе нужно выбрать только нечетные и сделать это обязательно циклом.

List<int> myList = new list<int>();

List<int> resultList = new list<int>();

foreach(var element in myList)

{

if(element % 2 == 0)

continue;

resultList.add(element);

}

anycode...

Объясняю:

твой цикл идет по каждому элементу.

Он проверяет четное ли число?

Если число четное - то он пропускает весь код, который будет после Continue, он пропускает все и берет следующий элемент.

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

Пример не очень хороший, ибо злоупотреблять этими элементами не рекомендуется, но иногда их применяют.

на реальном примере:

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

Вместо того чтобы в конструкторе передавать 1,0 или подобную хрень, я передавал значение Enum, потому что тогда ты открываешь класс страницы, видишь конструктор таблицы и понимаешь как в нем будет идти селекция, сразу наглядно, удобно.

Для того и юзаются, больше - да нет особой нужды.

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

А так в основном - читабельность вместо MagicString, MagicNumber и прочего не очень классного подхода.

Массивы штука архаичная и редкая.

Списки они же листы - штука повсеместная и юзается повсюду и в огромных объемах, знать нужно обязательно)

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

Но иногда ни к чему кроме массивы ты не приведешь.

Перечисления - редко юзаются, в основном нужны для каких-то статических вещей и замены MagicNumbers.

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

У тебя есть:

public enum MyEnum

{

none = -1,

Mobile = 0,

Desktop = 1

}

Class Browser

public MyEnum BrowserType;

public void Filter(MyEnum type)

{

  return browsers.Where(el => el.BrowserType == type);

}

Ты могла бы передавать вместо Enum тупо 0,1,2.

Но Enum это способ это запомнить вместе с нормальным названием, банально повышает читабельность кода, я использовал их только в таком контексте.

Листы штука очень мощная, один из основных элементов Generic, вообще интерфейс IEnumerable очень мощная вещь, понимаешь это когда пишешь их на С++ вручную )

С событиями там целый класс пришлось бы описывать с конструктором и т.д. )

В целом события вообще жопная штука для понимания )

Как только начнется WinForms я раскрою некоторые функции отладчика, а пока страдай )

Хотя мб ты уже сама нарыла )

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

Грубо говоря:

выбери ка мне шарики, синего цвета.

if(Something.Figure == "Bowl" && Something.Color == Сolor.Blue)

{

selectIt();

{

У нас есть что-то, мы не знаем что это, это может быть красный квадрат, но по задаче нам нужно выбрать это, только если это синий шар.

Мы проверяем - что это ШАР И СИНИЙ

Поменяем условия задачи:

Выбери ка мне все шарики и все фигуры синего цвета.

Теперь условие будет такое же, но тебе придется использовать ИЛИ вместо И

Мы проверяем - что это ШАР ИЛИ СИНЯЯ ФИГУРА(соответственно мы получим шарики все цветов и все фигуры синего цвета).

Отрицание:

Поменяем задачу - выбери мне все фигуры, кроме шариков

if(Someting.Figure != "Bowl")

Мы проверяем - что это НЕ ШАР

ОФФТОП:

Конечно мы могли бы перечислить все фигуры через ИЛИ.

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

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

|| - логическое ИЛИ

&& - логическое И

! - логическое отрицание.

логическая переменная 1 и 0

Посмотри таблички OR.

Суть:

ИЛИ:

1 или 0 = 1

1 или 1 = 1

0 или 1 = 1

0 или 0 = 0

И:

1 и 0 = 0

1 и 1 = 1

0 и 0 = 0

0 и 1 = 0

отрицание:

Не 1  = 0

Не 0 = 1

Соответственно:

не 1 или 0 = 0

Принцип работы проверки:

If(a%2>0)

Алгоритм:

- мы берем число а и делим его на 2(% по сути операция деления, которая покажет тебе только остаток при делении(тобишь дробную часть числа)).

- мы смотрим получили мы остаток при делении.

- если число четное, то оно всегда делится на 2 без остатка, значит когда остаток будет >0 - число нечетное.

Чтобы понять как и что работает - не бойся добавлять код для отладки.

var d = a%2;

console.WriteLine("Результат деления: "+d);

var d2 = a%2>0;

console.WriteLine("Результат условия: " + d2.ToString());

Есть конечно более прогрессивные способы, но отладка - это 90% времени программиста.

Про Try Catch забудь на время, освой условия, циклы, классы, наследование, интерфейсы, это основной скелет.

Особенно нужно понимать классы, ибо ООП - это классы, методы и т.д.

Принцип работы проверки - любое условие которое ты выводишь должно в конце выдать да/нет(именно поэтому программинг сильно завязан на логику).

If(условие выдающее тип Boolean в итоге, это может быть вызов функции, сложное условие, что-то комплексное, но в конце всегда будет boolean).

Если условие верно(True) выполняется первый блок кода

Иначе(else) - второй блок кода, соответственно условие будет в итоге выдавать False.

Поразбирай тяжелую дичь вроде

var a = 1;

var b = -2;

if((!(a==b) & (b-a)>0) || (a-b) <0)

Принцип работы Try Catch - когда код внутри try Catch компилится, асм помечает нечто некими командами(да да да, я плохо знаю асм) XD

Суть в том, что он прикрепляет к твоему методу точки и ссылки на Catch код, когда твой код при исполнении падает и выдает Exception(об этом тебе скажет Windows, это уже уровень ОС и микрокодов ЦП, просто попробуй поделить на 0, только неявно)

Аля Var a = 2;

var b = 0;

var c = a/b; - получишь Exception.

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

Все это он пакует в класс Exception(или один из его дочерних классов).

Например NullReferenceException.

Поэтому возможно писать структуры

Catch(NullReferenceException ex) - в этом случае блок Catch будет ловить исключительно NullReferenceException(попробуй, я не уверен).

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

Собственно Catch ловит этот Exception и выполняет тот код который тебе нужен.

Когда ты ставишь блок Try Catch ты всегда знаешь что вот в этом месте возможна непредвиденная ошибка, которую ты не можешь предугадать заранее, ты можешь открыть Connection с кривой строкой или сервер может выдать таймаут, в этом случае ты получишь Exception.

При вызове ХП у тебя может упасть код ХП на сервере, твой код о нем ничего не знает, ты просто делаешь запрос через API, в итоге твой запрос падает, потому что ХП возвращает Exception.

Точнее SQLException.

Проверка числа на четность - есть %

var a = 3;

var b = 4;

a%2 = 1;

b%2 = 0;

% вычисляет остаток от деления.

if else разумеется.

Потому что под Try Catch структуру у тебя при компиляции создается сложная безопасная структура с переходами, которая будет работать раз в 10 медленней чем If else.

Про функциональную нотацию просто покажу:

if ( a==b)

{

do1();

}

else

{

do2();

}

Можно записать как: a==b ? do1() : do2();

Это называется функциональная запись, выглядит не так читабельно, но в лямбдах пригодится, просто знай что такая есть, но пока советую писать If else =)

Try Catch - почти повсеместно стоит на подключения и работе с базой, потому что когда падает исполнение хранимки на сервере, тебе сыпет Exception и его надо обыгрывать.

Иногда так тупо проще реализовать логику, или красивее.

Поэтому штука норм, нужная.

WinForms - не создавай консольный проект, создай приложение WindowsForms.

Все эти кнопочки ты выставляешь в конструкторе, у формы свой класс )

Ну в WPF понадобится еще знание XML и умение верстки, но это не так уж прям сложно )

Сон для слабаков, я никогда не высыпаюсь (

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

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

И все это работало примерно вызовом одной строки:

ReportModule.CreateReport(IReport reportClass, params args)

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

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

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

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

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

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

Все остальное модуль делал и запускал сам, по факту он мог запустить любую часть кода, в отдельном потоке и выдать результат.

Некий менеджер потоков, только круче )

когда дойдешь до работы с WinForms скажи, я подкину тебе очень хороший фреймворк, в формате "лицензия", только тсссс )

По сути тот же набор контролов, но умнее.

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

Лучше создать 3 контрола под выбор ФИО, чем запихать все в один бокс.

Потому что как потом разбивать ФИО - черт поймет.

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

Если юзер вводит телефон, мы задаем формат полю Format в свойствах TextBox контрола.

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

Для таких случаев использую

Try Catch Finally конструкции

//Если в этом блоке произойдет ошибка или падение, код перейдет в исполнение блока Catch, передав туда возникшее "исключение".

Try

{

Throw notImplementedException();

}

//Ты можешь обработать, залогировать или сделать что-то при возникновении исключения, в дальнейшем код либо продолжает исполняться дальше, после Catch блока.

Catch(exception EX)

{

Console.Printf(ex.StackTrace);

MessageBox.Show("Произошла ошибка");

}

//Блок Finally исполняется и при падении и при успешном прохождении Try блока.

Finally

{

MessageBox.Show("Повторить?", че-то там баттоны);

}

Собственно TryParse можно написать самому:

bool TryParseint(string parseString, out int Result)

{

try

{

Result=int.Parse(parseString);

return True;

}

Catch(exception ex)

{

Return false;

}

}

1) Есть 2 типа переменных:

  - ссылочные типы(например string - ссылочный тип, их отличает то что они могут хранить значение Null и при передаче между функциями они передают указатель на память, а не клонируют значение).

- всякого рода структуры, целочисленные значения и т.д.

Конвертеры стараются не использовать, ибо Convert.ToInt32 можно заменить на.

(int) variable.

для ссылочных типов доступно безопасное приведение:

AnyClass AS int - выходной тип будет Nullable<Int> он же int?

2) Парсинг строк всегда затратен.

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

Конверт более жесткая и простая операция.

Она не завязана на локализацию, не завязана на формат числа и т.д.

В целом что удобно то и используй, но TryParse в случае с переводом из строки куда проще пишется )

+ C# язык не тупой, и когда ты вертишь типами, он сам может понять что

int a = 1;

float b = 1.1;

var res = (a+b);

res is Float - это строка будет True пока ты не поменяешь второй тип на int.

тобишь сумма = Float.

Это одно из правил конвертации, при конвертации двух разных типов, выбирается тип с большим объемом.

Грубо говоря у тебя может быть:

float a = 1;

double b = 1;

var res = A+b;

res is Double == true;

Результат вполне можно впихнуть в int, однако максимальный тип у тебя Double, Double выше чем Float, возьмет Double.

Если ты хочешь пойти на понижение размеров типа - Тобишь на том же примере, ты сделала 1 + 1 получила Double, но хочешь сделать из него Int.

Тебе нужно явно указывать конвертацию - (int) res;

Движение по повышению автоматически называется неявное преобразование.

По понижению - явное преобразование типа.

Parse работает в основном исключительно со строками.

Convert может конвертнуть тебе DateTime, Parse так не сможет.

Однако для строк, поскольку очень часто пользователи вводят "один один ;3435" - я советую использовать именно TryParse, чтобы от такого гавна не было падений )

По своему опыту - Convert устаревшая хрень, которая практически не используется, повсюду только Parse.

Может мне просто нравится как тыкает клавиатура )

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

+ у Parse есть TryParse реализация, которая безопасна.

Структуру - ну смотри, начни с MVP и MVC, да они избыточны для калькулятора, но нужно врубиться в структуру, архитектуру.

У тебя есть уровень интерфейса пользователя - View

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

Есть контроллер/презентер - это прослойка, грубо говоря ты знаешь что должен как-то преобразовать данные введенные пользователем, он связывает одно с другим.

Схема базовая и стара как мир, но понятна и удобна.

Углубляясь глубже в архитектуру - есть хорошая книга Сергей Тепляков "Паттерны Проектирования" - как только разберешься с тем что такое делегирование, что такое динамическая типизация, dynamic, анонимные методы, лямбда выражения и т.д. - можно почитать.

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

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

Почему - идиотом был.

В этом прелесть Backend, тебе почти не нужно знание js, jquery и тучи фреймворков, C# Core практически не отличается от простого C#, ну да EF работает слегка по другому, но это все такие же сущности.

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

Собственно запросы принимают контроллеры, которые взаимодействуют с бизнес логикой и моделями(сущностями и т.п.).

Я ничего не знал о вебе месяц назад, ну типо слышал что-то но очень тухло, сейчас я пишу для него )

Перестроится очень легко.

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

ПО - ну основная мощь, Java, C++, C# - это Backend, PHP - веб.

Есть узкие направления для питона, это в основном ИИ и машин лернинг.

Сейчас практически все высокие языки ООП, тот же JS уже ООП, при полной динамической типизации.

Без практики не поймешь как все это работает, никогда, по крайней мере я не могу, а как иначе?

Чтобы понять как строить архитектуру нужно построить дермище и в нем запутаться, чтобы понять что комменты действительно писать лучше обязательно, нужно столкнуться с приложением в более чем 1000 файлов не говоря уже о методах, там понимаешь что мягко говоря нужно описывать что ты делаешь, потому что запомнить такие объемы нереально.

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

Если с движками работать, я писал диплом транслятор, знаешь всякую чушь на которой показывают программинг в школах, посмотри "интерпретатор исполнителя Робот" - вот я то же самое делал в 3D на BP скриптах в UE4, подход ужасный и писать логику транслятора/интерпретатора на таком формате не стоит, но опыт интересный.

Это ближе к сис. программированию, но очень интересно, когда понимаешь насколько тот же C# умная вещь, синтаксический анализ - чепуха.

А как насчет лексического и семантического анализа - вот это жопа.

твой код разбивается на токены, токены разбиваются на команды и исполняются простейшим уровнем.

А так нууу работать с БД скучновато многим, но у БД мощная логика.

Сделай древо скиллов, кажется что легко, но ты сломаешь мозги, когда поймешь количество сущностей )

У тебя есть лвл, скилл, какое-то описание того что делает скилл, у каждого описания - реализация(-1 к хп противника).

Лвл связан с опытом, опыт дается за что-то, в итоге получается большое поле для идей и творчества.

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

Стиль кода сформируется со временем, свой почерк, свои ошибки, слабые и сильные места.

А творить в программинге - ну хз, многие не видят разницы между гавнокодом и хорошим кодом, но чувство победы, когда ты запихнул какую-то цепочку в 2 строки, которые понятны и читабельны - незаменимо =)

А творить - если работаешь над своим проектом, творить можно много )

ООП - инкапсуляция, полиморфизм, наследование.

Определения эти действительно нужно хорошо понимать, зачем - поймешь позже )

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

Главное пройти HR, в крупные фирмы без опыта почти анриал смотреть, поэтому в основном рассчитывай на мелкие.

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

Собственно из направлений:

- Клиент АСУ(SQL(в абсолютно разных его проявлениях) + java/C#/Python(для BigData)/Ruby

- Вэб фронт: JS, HTML, JQuery, JSON, React, Angular, PHP(в меньшей степени) - там жопа, прям вот жопа, брать фуллстак(Front + Backend) вэб не советую, помрешь под нагрузкой, а платят мало.

- Вэб Backend: почти то же что и АСУ.  SQL/Oracle, C#, PHP, Java, Python, Ruby неплохо требуют знание архитектур и паттернов.

- Высоконагруженные клиент приложения: Rust/Go(оба в меньшей степени), C++(наше все и думаю останется еще надолго), остальное от предметной области.

Ну и строго специализированные разработки, вроде научных на функциональных жопных языках, связанных с поиском(знание Elastic Search), геймдев(DX, OpenGl, шейдерные языки(F#), C++, знание игровых библиотек движка(unity, ue4 и т.д.))

Последнее встречается реже и требует навыков матана обычно.

Как-то так по языкам, ну и нужно понимать хотя бы примерно как строится архитектура приложений, архитектура вэб приложений сильно отличается от клиентских.

Ибо вэб связан неразрывно с браузером или с разного рода API и что-то вроде протоколов(нужно обязательно знать в чем суть HTTP) почитать про RESTfull API, если в легаси - SOAP.

Понимать что есть модификация уровней MVC паттерна:

- Front(включая различного рода фабрики объектов или сборщики для React)

- Controller(может быть много или мало, могут быть нагрузочные и нет).

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

И дополнения вроде DAL и левых фреймворков, таких как React для фронта, EF для работы с базами и т.д. и т.п.

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

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

Я продул порядка 6 или 8ми собеседок, прежде чем меня взяли, дали тестовое задание на дом, я написал его за день и написал не идеально, но надежно, с комментами и т.д. и т.п. В общем оно было работоспособно сделано по MVP и на интерфейсах.

Англ - да, я вот тоже думаю когда бы засесть, но хз, времени нет.

Вчера 2 нервных срыва за день, к успеху иду мать его, нервы не выживают.

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

Ну и + когда я ходил по собеседкам я не закрывался, когда я понимал что я много завалил, я начинал спамить вопросами - "а что нужно, что почитать, что выучить?".

Ну и вообще когда перед тобой активное тело на собеседовании это приятно выглядит, тебе задают вопрос как работают делегаты, ты вместо тупого "не знаю" и молчания, отвечаешь "не знаю, а как?" и тебе разъясняют.

Мне мой бывший когда-то, сейчас текущий нач. целую схему на листке рисовал, уже не помню о чем я спрашивал, но он ответил на свой же вопрос, объясняя мне )

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

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

У нас на работе был бог SQL, Godlike уровень, я никогда не встречал столь профессионального SQLщика, то над чем я мог промучатся день, он делал за 10 минут, из таких надо тянуть инфу, мол что читать, а как это работает(как не удивительно, но мало кто использует насчетные поля в индексациях и знает о рекомендациях блокировок таблиц).

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

Shift Alt )

не Alt Shift

первым просто на шифт нажимай и все, проблема решится, ибо Alt врубает что-то вроде хоткей режима.

воу воу, успех )

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

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

53 минуты, ну привет хлоя, что все же решила пересесть на пикабушку? )

@tripguard, @irina855, Я поддержу ваши догадки и скажу что это связано с поиском, но это не Яндекс и не Mail )

знаю, поэтому на компах компании над своими проектами я не работаю, да и потом крупных наработок с монетизацией у меня нет )

А так, начинал я с 30 )

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

Я не сильно прихотлив к з.п. я начинал с малого, очень малого по меркам IT рынка, но тогда и просили немного, а когда я стал в роли ведущего имея должность младшего программиста и таща на себе стажера и "мидла", который был едва ли не хуже стажера, это очень муторно. Никто не повышал время на мои задачи, грубо говоря я работал за 2-3ех человек одновременно и прекрасно разбирался в блоках задач, в которых не разбирался больше никто. Меня не просто так пытались отговорить от ухода 5 человек, я был для них важен, но получал меньше тех, чьи задачи выполнял и должен был в свободное время работать, чтобы доказать, что достоин повышения, этоо мягко говоря ну такое.