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

[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 строк. Иначе что-то не так в датском королевстве... )))

[Slava V]

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

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

это значит "достаточно часто"

например, у Вас есть 10,000 юзеров, кто-то из ниx меняет данные, кто-то просто просматривает
все это сидит на SQL Server, в базе штук 80 таблиц, между таблицами много связей
как Вы предлагаете все это масштабировать?
можно выделить несколько read-only серверов и кормить иx с одного "главного" сервера, на который все пишется;
Вы можете смасштабировать этот "главный" сервер?

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

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

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

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

[Oleg-NY]

это значит "достаточно часто"

например, у Вас есть 10,000 юзеров, кто-то из ниx меняет данные, кто-то просто просматривает
все это сидит на SQL Server, в базе штук 80 таблиц, между таблицами много связей
как Вы предлагаете все это масштабировать?
можно выделить несколько read-only серверов и кормить иx с одного "главного" сервера, на который все пишется;
Вы можете смасштабировать этот "главный" сервер?

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

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

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

Не правда ваша. Вы стравниваете апельсины с яблоками. В процедурах вы точно так же можете нахерачить аналогичный SQL запрос на 1000 строк. Ну хорошо, пусть ваш запрос будет 500 строк потому, что вы его генерите лучше, чем EF. )) Однако вы так скорее всего не сделаете потому, что вы будете логически разделять классы данных чтобы просто уменьшить размерность и работать с ними процедурно в курсорах или в запросах к временным таблицам, но ведь тот же подход может применить и с EF.

[АццкоМото]

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

Так и представляю, как сисястая малярша заканчивает покраску и ВНЕЗАПНО - а давайте, я вам ещё и унитаз поменяю?

[Slava V]

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

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

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

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

Не правда ваша. Вы стравниваете апельсины с яблоками. В процедурах вы точно так же можете нахерачить аналогичный SQL запрос на 1000 строк. Ну хорошо, пусть ваш запрос будет 500 строк потому, что вы его генерите лучше, чем EF. )) Однако вы так скорее всего не сделаете потому, что вы будете логически разделять классы данных чтобы просто уменьшить размерность и работать с ними процедурно в курсорах или в запросах к временным таблицам, но ведь тот же подход может применить и с EF.

дело не столько в количестве строк сколько в читаемости и модифицируемости кода

Вы часто пытались ковыряться в коде, который сгенерирован EF?

[Oleg-NY]

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

Я понял что вас инетересует, но я вам уже ответил, что без знания семантики "влоб" решения нет. В порядке бреда, думаю, что в общем случае можно решить задачу распределения нагрузки на мастер-сервер путем введения избыточности, т.е. когда отдельные сервера хранят только модифицируемую информацию от которой зависят будущие изменения и обновляются параллельно в рамках одной распределенной транзакции. Сервера здесь понятие логическое и могут быть представлены теми же "read-only" с дополнительным таблицами в той же самой базе. Такой вот своеобразный кэш данных. Суть в том, что для инициации новой транзакции сервисы не будут кверить только мастер-сервер, а не в том, что туда пишем, а туда нет.
Кстати, взаимосвязанность таблиц еще не означает, что вы не можете разнести их по разным базам. Это лишь означает, что, в послденем случае, вам возможно придется поддерживать целостность данных вручную, а не за счет встроенных в сервер механизмов.

дело не столько в количестве строк сколько в читаемости и модифицируемости кода

Вы часто пытались ковыряться в коде, который сгенерирован EF?

Боже упаси! Этот код не предназначен для того чтобы в нем ковыряться. Все, в чем нужно "поковыряться" это SQL запросы, сформированные по вашим EF выражениям, но только для того, чтобы оптимизировать последние. Впрочем для этого EF предоставляет вполне легальные средства.

[stenking]

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

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

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

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

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

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

[Sierra2k]

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

pluralsight.com ?

+1

[MCP]

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

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

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

Мне кажется что хорошо когда в кампании есть И Фулл Стацк дев И более узко направленные, например 2 по UI, 2 по миддле-тиер, 1 по DB и 1 Фулл Стак,
Т.е. когда обьем новой функциональности большой то наверно имеет смысл чтобы
разные люди делали UI, миддле-тиер И бак-енд а если скажем надо сделат
небольшой сkреен И еще что-то поменьше то лучше когда 1 человек это будет все делать И не тратить время чтобы 3 человека вместо 1 входили в курс что там именно надо сделать.

[Oleg-NY]

Мне кажется что хорошо когда в кампании есть И Фулл Стацк дев И более узко направленные, например 2 по UI, 2 по миддле-тиер, 1 по DB и 1 Фулл Стак,

Но у последнего скорее всего тайтл будет не просто девелопер. Как минимум тим-лид или аркитект.

[stenking]

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

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

[Slava V]

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

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

если помните, эта часть дискуссии началась с Вашей реплики:

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

Вы все еще готовы утверждать, что Ваше решение подпадает под категорию "дублировать железо"?

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

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

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

дело не столько в количестве строк сколько в читаемости и модифицируемости кода

Вы часто пытались ковыряться в коде, который сгенерирован EF?

Боже упаси! Этот код не предназначен для того чтобы в нем ковыряться. Все, в чем нужно "поковыряться" это SQL запросы, сформированные по вашим EF выражениям, но только для того, чтобы оптимизировать последние. Впрочем для этого EF предоставляет вполне легальные средства.

не только оптимизировать (xотя и это тоже) - но и понять, где же там проблема, в том монстровом EF-запросе из 40 строк

[Slava V]

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

или просто пол помыть? за большие $$$ в час?

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

[Slava V]

Мне кажется что хорошо когда в кампании есть И Фулл Стацк дев И более узко направленные, например 2 по UI, 2 по миддле-тиер, 1 по DB и 1 Фулл Стак,

Но у последнего скорее всего тайтл будет не просто девелопер. Как минимум тим-лид или аркитект.

а на дайсе куча работ обозначена именно как "full stack developer"

вот наивные, правда? кто ж из арxитекторов к ним пойдет на такую невзрачную должность?

[stenking]

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

или просто пол помыть? за большие $$$ в час?

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

У компании с "несколько оффисов в разныx штатаx" которая ищет 5 программистов, ангуляр и т.д. нет работы для верстальщика? Который стоит как пол фул стека и раз в 5 его эффективнее?

[Slava V]

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

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

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

я ничего не упустил?