Здравствуйте, Abalak, Вы писали:
A>Для некоторых и .NET c VBA неподъемные до такой степени, что за 4 месяца ни одной строчки кода вменяемой написать не могут. Для таких и 90% демпинг — мало. А к другим очередь выстраивается из работодателей. Такова жизнь.
Я начинающий .net разработчик, но есть что показать( веду свой проект ), 3 года опыта php-программистом, однако очередь не выстраивается, более того — всего два собеседования за месяц. Что я делаю не так?
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Думаю, коллегам будет небезынтересно прочитать вот этот отзыв.
Именно на него я сразу и наткнулся, когда задумался о то что меня развели.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>а ты готов выполнить 10 теcтовых заданий?
А с чего их 10 будет? Обычно задание одно, на какую-то конкретную область.
Здравствуйте, Diaver, Вы писали:
D>Здравствуйте, Abalak, Вы писали:
A>>Для некоторых и .NET c VBA неподъемные до такой степени, что за 4 месяца ни одной строчки кода вменяемой написать не могут. Для таких и 90% демпинг — мало. А к другим очередь выстраивается из работодателей. Такова жизнь.
D>Я начинающий C# разработчик, но есть что показать, 3 года опыта php-программистом. Очереди нет и близко, всего два собеседования за месяц.
Этот пост предназначался Паше и только ему А свою работу ты найдешь, не переживай.
Здравствуйте, hokkaido, Вы писали:
H>Заранее прошу прощения за ламмерский вопрос (в БД практически ниче не понимаю), а нужно ли в данном случае (без дополнительной инфы) "нормализовывать" базу?
Не нужно. Откуда будут браться данные в "словаре" для операторов? Значит должен быть некий функционал по их добавлению/регистрации (GUI, backend). А где это в ТЗ?
Здравствуйте, Handie, Вы писали:
H>Дизайн с одной табличкой несколько наивен. H>1) Хранить исходные данные и вычисляемые поля в одной таблице — не очень хорошо. С одной стороны идет поток инсертов, с другой — поток апдейтов. Требования например по индексам разные.
Как бы нет данных о нагрузке.
H>2) Не делалось попыток факторизовать поля. Напимер хранить сотню миллионов строк "beeline" "megafon" неразумно. Надо сделать табличку operators и в базу писать код, типа 1-beeline, 2-megafon.
Комментировал выше. Не известно что делать в случае, если оператора нет в БД. А зачем себе выдумывать головную боль?
H>3) Хранить пароль в открытом виде — несколько наивно, есть риск утраты базы.
Это должно оговариваться. Например, что делать если клиент пароль не получил, а денег сняли? Генерировать новый?
H>4) Мелкие оптимизации — если телефоны структурированы, то лучше хранить их в другом формате, вплоть до INTEGER
См. пункт 1.
H>5) Названия полей непонятны человеку который первый раз глянет в базу
Единственное, с чем согласен.
H>6) Нет индексов для поиска — например по номеру телефона поиск будет немерянным
Где информация о поиске, и по каким полям он нужен клиенту? У нас точно ожидаются сотни [нефти] тысяч записей?
Здравствуйте, techgl, Вы писали:
T>Здравствуйте, hokkaido, Вы писали:
H>>Заранее прошу прощения за ламмерский вопрос (в БД практически ниче не понимаю), а нужно ли в данном случае (без дополнительной инфы) "нормализовывать" базу? T>Не нужно. Откуда будут браться данные в "словаре" для операторов? Значит должен быть некий функционал по их добавлению/регистрации (GUI, backend). А где это в ТЗ?
База по умолчанию должна быть нормализована. Точка. Если есть явные предпосылки для деномализации, то можно начинать думать.
Здравствуйте, techgl, Вы писали:
T>Здравствуйте, Handie, Вы писали:
H>>Дизайн с одной табличкой несколько наивен. H>>1) Хранить исходные данные и вычисляемые поля в одной таблице — не очень хорошо. С одной стороны идет поток инсертов, с другой — поток апдейтов. Требования например по индексам разные. T>Как бы нет данных о нагрузке.
Update должен был быть только в случае повторного запроса от существующего номера телефона.
H>>4) Мелкие оптимизации — если телефоны структурированы, то лучше хранить их в другом формате, вплоть до INTEGER T>См. пункт 1.
Телефон мог прийти в виде "+7 (546) 456 25 25", или например 13-ти значный номер
H>>5) Названия полей непонятны человеку который первый раз глянет в базу T>Единственное, с чем согласен.
Первоначально сделал полные названия, но потом переименовал для точного соответствия принимаемым параметрам, я решил что как раз головняка будет меньше не надо разбираться что значит каждый из параметров в запросе и сопоставлять с БД.
Спасибо за поддержку, а то на меня все накинулись как на школьника.
Здравствуйте, Diaver, Вы писали:
D>Кстати у них по ходу принято давать тестовые задания на неделю работы по первого собеседования Вот только зачем?
Практика показывает: если компании реально нужен сотрудник, то на собеседовании даются вменяемые тестовые задания и собеседование проводит вменяемый сотрудник. Если сотрудники не нужны (или поиск сотрудника ведется в фоновом режиме: найдется — хорошо, не найдется — тоже неплохо), то тестовые задания разрастаются до монстрообразных.
Здравствуйте, Abalak, Вы писали:
A>База по умолчанию должна быть нормализована.
А она нормализована. Просто не до того уровня, который тебе хотелось бы. Как минимум 2 уровня там есть.
Вопрос ты, кстати, проигнорировал. Как заполнять таблицу с операторами? Что делать если запрос содержит оператора, которого нет в БД? A>Точка. Если есть явные предпосылки для деномализации, то можно начинать думать.
Откуда у тебя уверенность, что предпосылок нет? Повторюсь, где данные о нагрузке? Там реально ожидаются сотни тысяч а может миллионы записей? Ты представь, какой это должен быть сервис, чтобы у него было столько пользователей.
Напридумывали тут на ходу какие-то требования, о которых в исходом задании вообще ни слова.
Здравствуйте, techgl, Вы писали:
T>Здравствуйте, Abalak, Вы писали:
A>>База по умолчанию должна быть нормализована. T>А она нормализована. Просто не до того уровня, который тебе хотелось бы. Как минимум 2 уровня там есть.
Нужна 3-я.
T>Вопрос ты, кстати, проигнорировал. Как заполнять таблицу с операторами? Что делать если запрос содержит оператора, которого нет в БД?
В данном случае заполняем скриптом при создании бвзы. Справочник оператора не та вещь, для которой нужна админка. Если оператора нет, то исключкние — т.к. с этим ты не сможешь продолжить при любой структуре бвзы.
A>>Точка. Если есть явные предпосылки для деномализации, то можно начинать думать. T>Откуда у тебя уверенность, что предпосылок нет? Повторюсь, где данные о нагрузке? Там реально ожидаются сотни тысяч а может миллионы записей? Ты представь, какой это должен быть сервис, чтобы у него было столько пользователей.
Нужна масштабируемость. Если даже сервисом пользуются три калеки (или вообще никто в случае тестового задания), это не значит, что завтра не будет сотен тысяч пользователей? Все переписывать? Кстати денормализация как раз и нужна для убыстрения запросов, там где другое не помогает. И это крайний случай.
T>Напридумывали тут на ходу какие-то требования, о которых в исходом задании вообще ни слова.
— А шо? Ведь все работает... Ну-ну.
Вот так и получается говнокод, который приходится переписывать при необходимости малейших изменений. Это элементарный анализ ситуации. Сюрприз! Тупого быдлокодинга по ТЗ в программировании недостаточно. Хороший разработчик спросит или заложится, плохой — закодит как бог на душу положит.
Здравствуйте, Diaver, Вы писали:
D>Спасибо за поддержку, а то на меня все накинулись как на школьника.
Да никто на тебя не набрасывался. Ты спросил, что ты сделал не так, тебе ответили. По поводу конторы, я их бы послал подальше, но ты согласился на задание, тем самым приняв правила игры и не справмлся. Ничего страшного, всякое бывает.
T>>А она нормализована. Просто не до того уровня, который тебе хотелось бы. Как минимум 2 уровня там есть. A>Нужна 3-я.
То есть нормализация все же есть? Смысл высказывания "БД должна быть нормализована"?
A>В данном случае заполняем скриптом при создании бвзы. Справочник оператора не та вещь, для которой нужна админка. Если оператора нет, то исключкние — т.к. с этим ты не сможешь продолжить при любой структуре бвзы.
Это нарушение условия из исходного задания. Там сказано что все запросы должны сохраняться в БД. Решение автора работает, а твое генерирует "исключение".
A>Нужна масштабируемость. Если даже сервисом пользуются три калеки (или вообще никто в случае тестового задания), это не значит, что завтра не будет сотен тысяч пользователей?
Внезапно "сотни тысяч". Знаешь, чтобы придумать идею, которая позволит иметь такое количество оплат, надо очень постараться. Так что пока оставим это на уровне
фантазии.
A>Все переписывать?
Зависит от логики работы с этой справочной таблицей. Но в любом случае не все нужно будет переписывать. Это похоже на истерику новичка-гения, пришедшего на проект — "Ужасный код, кто так программирует, все переписать !!!!одиодиодин".
A>Кстати денормализация как раз и нужна для убыстрения запросов, там где другое не помогает. И это крайний случай.
Угу, мужики не в курсе.
A>- А шо? Ведь все работает... Ну-ну.
Именно. Решение автора работает. А это минимальное необходимое условие приемки.
Твое решение не работает.
A>Вот так и получается говнокод, который приходится переписывать при необходимости малейших изменений.
Смотри выше, про гениев.
Чтобы определится что им конкретно не понравилось написал предельно вежливое письмо:
Здравствуйте.
Среди большого круга моих коллег разгорелся нешуточный спор по поводу вашего ТЗ и о возможной причине недовольства вашего руководителя структурой БД в частности, поэтому мы все вам будем благодарны, если вы сообщите что именно в структуре БД не понравилось вашему руководителю.
H>>>Дизайн с одной табличкой несколько наивен. H>>>1) Хранить исходные данные и вычисляемые поля в одной таблице — не очень хорошо. С одной стороны идет поток инсертов, с другой — поток апдейтов. Требования например по индексам разные. T>>Как бы нет данных о нагрузке. D>Update должен был быть только в случае повторного запроса от существующего номера телефона.
Если id неизвестен, то как Вы себе представляете апдейт от существующего телефона? Table Full Scan? На таблице под OLTP нагрузкой?
H>>>4) Мелкие оптимизации — если телефоны структурированы, то лучше хранить их в другом формате, вплоть до INTEGER T>>См. пункт 1. D>Телефон мог прийти в виде "+7 (546) 456 25 25", или например 13-ти значный номер
Про регулярные выражения слышали? В курсе что в базе гораздо лучше хранить распарсенную информацию представленную в стандартизованном формате?
D>Первоначально сделал полные названия, но потом переименовал для точного соответствия принимаемым параметрам, я решил что как раз головняка будет меньше не надо разбираться что значит каждый из параметров в запросе и сопоставлять с БД.
Параметры названы коротко потому что это HTTP — минимизация трафика и усложение задачи перехватившим траффик. Для базы эти аргументы несуществвенны.
D>Спасибо за поддержку, а то на меня все накинулись как на школьника.
Нашли еще одного дремучего невежду и прониклись к нему симпатией. Я бы вашего "приятеля" на работу не взял, впрочем Вас наверное тоже.
Здравствуйте, Diaver, Вы писали:
D>2Handie D>даже комментировать не буду D>Наверно быть самым умным это очень круто, расскажите нам еще что-нибудь!
Умный человек задумается, Ваши представление о себе как о профессионале не совпали с представлениями интервьюера. Есть смысл прокачать знания, а Вы вместо этого затаили обиду на всех и вся.
Я больше всего благодарен не тем интервьюерам, которые брали меня на работу, а тем, кто возвращал меня на землю и тыкал меня носом в мои пробелы. Они сбивали мою спесь и заставляли меня двигаться вперед
Вот только зачем?
