Н
Говорю же - экспертная ветка
как правило фуллстек это человек умеющий всего понемногу, и хорошо если имеющий экспертные знания хотя бы в одной из областей
Size: a a a
2019 November 16
PD
Фулстек это топовый эксперт, сто это управленческая ветка
С чего топовый-то? Обычно это миддлы.
2019 November 17
E
Фулстек это топовый эксперт, сто это управленческая ветка
> фулстек это топовый эксперт
чет захрюкал, вы видели этих фулстеков-то?
чет захрюкал, вы видели этих фулстеков-то?
GM
> фулстек это топовый эксперт
чет захрюкал, вы видели этих фулстеков-то?
чет захрюкал, вы видели этих фулстеков-то?
пару раз видел, работают за 10-15 киллоевро нет в месяц в фанг или где-то рядом, в дикой природе встретить фактически невозможно
GM
пару раз видел, работают за 10-15 киллоевро нет в месяц в фанг или где-то рядом, в дикой природе встретить фактически невозможно
ребята попроще работают в условном букинге за 6-8 нет евро, хотя тут уже с нюансами почему они до топ 4 не дотянули, в рф таких людей практически невозможно нанять просто потому что для них самих нет смысла тут оставаться, а предлагаемые зп с запасом зп CIO-CTO перекрывают при том что делать надо будет задачи "по-душе"
E
в россии фулстек - это пхпшник, который умеет jquery
SI
в россии фулстек - это пхпшник, который умеет jquery
Достаточное количество fullstack js специалистов, которые пишут на nodejs и vue/react/angular
E
принципиально ничем не отличается, кроме знания на язык меньше
S
ребята попроще работают в условном букинге за 6-8 нет евро, хотя тут уже с нюансами почему они до топ 4 не дотянули, в рф таких людей практически невозможно нанять просто потому что для них самих нет смысла тут оставаться, а предлагаемые зп с запасом зп CIO-CTO перекрывают при том что делать надо будет задачи "по-душе"
Теперь понятно, почему у них открытый сайт съедает батарею ноута за полчаса.
D
Андрей Лесных
Всем привет.
Внесу свои 5 копеек.
Каждый должен изобрести свой процессный движок ;) после чего начать использовать промышленное решение. Например Камунду. И да, процесс должен быть описан прежде чем... Ну вы в курсе ;)
Внесу свои 5 копеек.
Каждый должен изобрести свой процессный движок ;) после чего начать использовать промышленное решение. Например Камунду. И да, процесс должен быть описан прежде чем... Ну вы в курсе ;)
Вы не так уж и не правы:) вот ребята у которых движок процессов одна из основных функций, делятся почему в итоге свой написали: https://m.habr.com/ru/company/directum/blog/468803/
D
Аргументация за свой велосипед выглядит разумной и обоснованной.
АЛ
Denis
Аргументация за свой велосипед выглядит разумной и обоснованной.
Ктоб сомневался ;) у каждого обоснования свой путь.
D
Андрей Лесных
Ктоб сомневался ;) у каждого обоснования свой путь.
Ну у них судя по всему с т.з. бизнеса это кратно окупилось
DS
Андрей Лесных
Ктоб сомневался ;) у каждого обоснования свой путь.
А есть статьи про обоснование использования процессного движка на проекте в принципе? Ну почему раньше обходились, а теперь ни как не получится, так как накопился ряд нерешаемых обычной разработкой проблем.
АЛ
А есть статьи про обоснование использования процессного движка на проекте в принципе? Ну почему раньше обходились, а теперь ни как не получится, так как накопился ряд нерешаемых обычной разработкой проблем.
Вот, например, парни рассказывают зачем они это счастье используют:
https://m.habr.com/ru/company/tinkoff/blog/455860/
Как правило, там где есть необходимость часто реагировать на изменения бизнес процессов (банки, телеком, etc) собственно и появляются движки. Если не хватает существующих возможностей - пишем свое или развиваем существующее. Выбор зависит от:
1) кто (программист, аналитик, etc.) будет писать процессы?
2) как часто будет меняться процесс?
3) в какой нотации?
4) нужен ли редактор?
5) как происходит деплой новых процессов?
6) какой нужен персистанс?
7) нужна ли поддержка взаимодействия с очередями?
8) взаимодействие с гуем пользователя?
9) вопросы безопасности?
10) логгирование?
11) мониторинг?
12) обработка ошибок?
...
Тут думаю каждый для себя вопросов накидает еще пару десятков из которых можно будет сделать осознанный выбор - пишем сами (основные недостатки: долго, дорого, функционально не развито, надо сопровождать и поддерживать и т.п. в зависимости от условий) или берем существующее (недостатки зависят от выбранного движка и опять же условий).
Т.е. однозначно сказать что лучше - можно проведя анализ решения применительно к задаче - что выиграем, где проиграем, как поведет себя в будущем, сколько будет стоить и приняв для себя эти риски.
https://m.habr.com/ru/company/tinkoff/blog/455860/
Как правило, там где есть необходимость часто реагировать на изменения бизнес процессов (банки, телеком, etc) собственно и появляются движки. Если не хватает существующих возможностей - пишем свое или развиваем существующее. Выбор зависит от:
1) кто (программист, аналитик, etc.) будет писать процессы?
2) как часто будет меняться процесс?
3) в какой нотации?
4) нужен ли редактор?
5) как происходит деплой новых процессов?
6) какой нужен персистанс?
7) нужна ли поддержка взаимодействия с очередями?
8) взаимодействие с гуем пользователя?
9) вопросы безопасности?
10) логгирование?
11) мониторинг?
12) обработка ошибок?
...
Тут думаю каждый для себя вопросов накидает еще пару десятков из которых можно будет сделать осознанный выбор - пишем сами (основные недостатки: долго, дорого, функционально не развито, надо сопровождать и поддерживать и т.п. в зависимости от условий) или берем существующее (недостатки зависят от выбранного движка и опять же условий).
Т.е. однозначно сказать что лучше - можно проведя анализ решения применительно к задаче - что выиграем, где проиграем, как поведет себя в будущем, сколько будет стоить и приняв для себя эти риски.
АЛ
Denis
Ну у них судя по всему с т.з. бизнеса это кратно окупилось
А почему бы и нет? Правильно все взвесили и молодцы ;)
DS
Андрей Лесных
Вот, например, парни рассказывают зачем они это счастье используют:
https://m.habr.com/ru/company/tinkoff/blog/455860/
Как правило, там где есть необходимость часто реагировать на изменения бизнес процессов (банки, телеком, etc) собственно и появляются движки. Если не хватает существующих возможностей - пишем свое или развиваем существующее. Выбор зависит от:
1) кто (программист, аналитик, etc.) будет писать процессы?
2) как часто будет меняться процесс?
3) в какой нотации?
4) нужен ли редактор?
5) как происходит деплой новых процессов?
6) какой нужен персистанс?
7) нужна ли поддержка взаимодействия с очередями?
8) взаимодействие с гуем пользователя?
9) вопросы безопасности?
10) логгирование?
11) мониторинг?
12) обработка ошибок?
...
Тут думаю каждый для себя вопросов накидает еще пару десятков из которых можно будет сделать осознанный выбор - пишем сами (основные недостатки: долго, дорого, функционально не развито, надо сопровождать и поддерживать и т.п. в зависимости от условий) или берем существующее (недостатки зависят от выбранного движка и опять же условий).
Т.е. однозначно сказать что лучше - можно проведя анализ решения применительно к задаче - что выиграем, где проиграем, как поведет себя в будущем, сколько будет стоить и приняв для себя эти риски.
https://m.habr.com/ru/company/tinkoff/blog/455860/
Как правило, там где есть необходимость часто реагировать на изменения бизнес процессов (банки, телеком, etc) собственно и появляются движки. Если не хватает существующих возможностей - пишем свое или развиваем существующее. Выбор зависит от:
1) кто (программист, аналитик, etc.) будет писать процессы?
2) как часто будет меняться процесс?
3) в какой нотации?
4) нужен ли редактор?
5) как происходит деплой новых процессов?
6) какой нужен персистанс?
7) нужна ли поддержка взаимодействия с очередями?
8) взаимодействие с гуем пользователя?
9) вопросы безопасности?
10) логгирование?
11) мониторинг?
12) обработка ошибок?
...
Тут думаю каждый для себя вопросов накидает еще пару десятков из которых можно будет сделать осознанный выбор - пишем сами (основные недостатки: долго, дорого, функционально не развито, надо сопровождать и поддерживать и т.п. в зависимости от условий) или берем существующее (недостатки зависят от выбранного движка и опять же условий).
Т.е. однозначно сказать что лучше - можно проведя анализ решения применительно к задаче - что выиграем, где проиграем, как поведет себя в будущем, сколько будет стоить и приняв для себя эти риски.
Очень похоже на правду!
2019 November 19
АС
А ведь тут могут быть все пункты сразу. Даже с одним и тем же человеком.
К
А ведь тут могут быть все пункты сразу. Даже с одним и тем же человеком.
+
К
или какой то другой вариант