100% remote - Full stack - Web.API 2, C#, SQL, EF, Angular - есть 5 вакансий

[Slava V]

у нас фулл стаки как раз перенимают новые феньки друг у друга - он и не узнает про SASS/LESS пока на него не наткнется в нашем проекте - попросит объяснить как оно работает и станет пользоваться
не бином Ньютона.

Вы не слышите что я говорю. У вас есть Х часов. Мы можете потратить их на 3 разных предмета или совершенствовать 1. 3 узких специалиста ( хирург, анастезиолог и медсестра) при хорошо выстроенном процессе эффективнее 3-х специалистов широкого профиля ( 3 семейных доктора )

имxо, это передергивание

выучиться на xирурга занимает несколько больше времени, чем научиться пользоваться SASS/LESS

У вас есть Х часов. Мы можете потратить их на 3 разных предмета

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

[Slava V]

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

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

в смысле - если я должен поддерживать 3 разные базы, то под интерфейс с Business Layer мне надо написать 3 data layers - каждый со своим кодом (включая api и sprocs)
я что-то упустил?

[stenking]

выучиться на xирурга занимает несколько больше времени, чем научиться пользоваться SASS/LESS

Когда вы поработаете с теми кто только пишет HTML/SASS 10 лет то тогда вы и почувствуете разницу

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

П.С. А вообще, один ремонт дома своими силами сразу мозги про фул стаков на место ставит

[Slava V]

выучиться на xирурга занимает несколько больше времени, чем научиться пользоваться SASS/LESS

Когда когда вы поработаете с теми кто только пишет HTML/SASS 10 лет то тогда вы и почувствуете разницу

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

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

А вообще, один ремонт дома своими силами сразу мозги про фул стаков на место ставит

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

[stenking]

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

Поломанный процесс. Нет запланированных задач задолго вперёд, еффективной системы тикетов и т.д.

Т.е. хирург ждёт пока медсестра давление поменяет а анастезиолог забыл что утром пациент.

[FreemanUSA]

Конечно CSS устарело из за этого CSS3 КРУЧЕ со всякими анимашками и выбором елементов типа last-child before after Просто SASS написали на тот момент и всё Game Over, а если знаеш как аплаить кросбраузер платформ дерективы и получать елемент без присвоения id или class CSS3 то юзеры библиотек которые ограничены этой библиотекой уже отпадают. Для JS in HTML5 вообше идеально всё, даже юзерский атрибют придумали data-* и верти елемент как хочешь

[Slava V]

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

Поломанный процесс. Нет запланированных задач задолго вперёд, еффективной системы тикетов и т.д.

Т.е. хирург ждёт пока медсестра давление поменяет а анастезиолог забыл что утром пациент.

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

[FreemanUSA]

Как заказчик я предпочёл такое http://www.adidas.com/us и то наверно SASS и Angular девелуперы не доработали менюшку и прочие еффекты нету смус еффект, режет глаз.

[Oleg-NY]

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

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

в смысле - если я должен поддерживать 3 разные базы, то под интерфейс с Business Layer мне надо написать 3 data layers - каждый со своим кодом (включая api и sprocs)
я что-то упустил?

Можно и так, конечно, но почему это франкенштейн-то? Однако можно и по-другому. Сама по себе база (как схема) у вас одна и та же (если только вы не на nosql хотите еще замахнуться). Разные engines? Но абстракцию оных вам предоставляет сам мелкософт. Зачем тогда вам, например, тот же EF. Это не единственное решение впрочем.

[Slava V]

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

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

в смысле - если я должен поддерживать 3 разные базы, то под интерфейс с Business Layer мне надо написать 3 data layers - каждый со своим кодом (включая api и sprocs)
я что-то упустил?

Можно и так, конечно, но почему это франкенштейн-то? Однако можно и по-другому. Сама по себе база (как схема) у вас одна и та же (если только вы не на nosql хотите еще замахнуться). Разные engines? Но абстракцию оных вам предоставляет сам мелкософт. Зачем тогда вам, например, тот же EF. Это не единственное решение впрочем.

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

[Oleg-NY]

в EF некоторые вещи получаются слишком монструозными

Ведомо. ))) Однако EF не единственный в своем роде. Кроме того, можно вообще не использовать ORM. Теоретически можно рассматривать стандартный SQL как требующийся вам abstraction layer. Медленно? Неэффективно? Да, но дублировать железо нынче куда дешевле, чем ваять, а потом поддерживать.

- куда проще убрать все это в спрок

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

[FreemanUSA]

Вот пример, чисто сейчас получил в JPA есть метод merge(). Фрэймеворк пытаюсь проверить сушествования юзера в дб по эмайл в регестрациионной форме, если есть то пропуск к заветному и после апдате юзерских данных в дб с помощю merge(), тупо вносит новую запись и если юзер пытаеться воити на страницу скачки продукта Java возрашает ошибку так как два юзера с тем же самым эмайлом. Баг при использование merge() нужно опять получить юзера из базы получить его айди апплаить его к обьекту который передаёш merge() Вот откуда мне как новичку знать такие тонкости ФРЭЙВОРК мне проше сиквел синтекс написать и всё, а это подключи библтотеку которая упрощает жизнь?

[Slava V]

в EF некоторые вещи получаются слишком монструозными

Ведомо. ))) Однако EF не единственный в своем роде. Кроме того, можно вообще не использовать ORM. Теоретически можно рассматривать стандартный SQL как требующийся вам abstraction layer. Медленно? Неэффективно? Да, но дублировать железо нынче куда дешевле, чем ваять, а потом поддерживать.

дублировать железо? попробуйте сдублировать sql server (в который активно пишутся данные)

- куда проще убрать все это в спрок

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

ничуть. это просто соображения эффективности (сопровождение кода в течение 10 лет может стоить НАМНОГО больше чем его первоначальное написание - кто-то когда-то будет вынужден ковыряться в Вашем EF-запросе на 40 строк, из которого генерится SQL-запрос на 1000 строк

[Slava V]

Вот откуда мне как новичку знать такие тонкости ФРЭЙВОРК

pluralsight.com ?

[Oleg-NY]

дублировать железо? попробуйте сдублировать sql server (в который активно пишутся данные)

Это что за критерий такой "активно"? У вас что поток запросов на модификацию данных на порядок превышает чтение и при этом требование доступности новых данных типа "мгновенное"?
Ну тогда увы. Мне представлялось, что в e-commerce это не так. Но даже если и так, то запись записи рознь. Думаю сами понимаете...

ничуть. это просто соображения эффективности (сопровождение кода в течение 10 лет может стоить НАМНОГО больше чем его первоначальное написание - кто-то когда-то будет вынужден ковыряться в Вашем EF-запросе на 40 строк, из которого генерится SQL-запрос на 1000 строк

Надеюсь это была гипербола про 40 строк. Иначе что-то не так в датском королевстве... )))