VitaliyBoris:до фронта не допускал бы
ну так это для бэка
для фронта совсем другой уровень js нужен
VitaliyBoris:до фронта не допускал бы
ну так это для бэка
для фронта совсем другой уровень js нужен
офлайн
VitaliyBoris
Senior Member
|
|
1445 |
18 лет на сайте Город:
|
dmitry_cx:VitaliyBoris:до фронта не допускал бы
ну так это для бэка
для фронта совсем другой уровень js нужен
Можете пояснить, что имеется ввиду? Не совсем понятно какого рода скриптик на JS для бэка нужно написать?
P.S. в nodejs "скриптик" писать не пустил бы еще пуще
офлайн
SpiritMoon
Senior Member
|
|
1267 |
11 лет на сайте Город:
|
VitaliyBoris:dmitry_cx:VitaliyBoris:SpiritMoon:вакансии по Java или C# без знания JS днем с огнем сейчас не сыщешь
Да ладно...
ну примерно так и есть. Никто не говорит про экспертное знание js, но понимать что можно сделать, какой скриптик написать - это мастхэв
я б таких
какой скриптик написать
до фронта не допускал бы
Добавлено спустя 1 минута 43 секундыP.S. чисто по бэкэнду постоянно валятся предложения в linkedin. Где вы не можете днем да еще и с огнем найти их?
Я не намекаю, что на крепкое или хорошее знание, меня правильно поправили выше, всегда приписка "желательно", на сколько глубоко вы туда полезите, это уже по ситуации.
VitaliyBoris:Можете пояснить, что имеется ввиду? Не совсем понятно какого рода скриптик на JS для бэка нужно написать?
Например при выборе даты в календаре, валится фронт или идет отправка не валидной dto, надо залесть и подправить, минимуально подкрутить ui на материале или jquery ui.
Node это другой мир, хоть и тот же JS.
офлайн
VitaliyBoris
Senior Member
|
|
1445 |
18 лет на сайте Город:
|
SpiritMoon:Например при выборе даты в календаре, валится фронт или идет отправка не валидной dto, надо залесть и подправить, минимуально подкрутить ui на материале или jquery ui.
На основе приведенного примера можно вести разговор в двух направлениях:
Korben_Dallas:alex-145:Если в программном обеспечении заложена ПРОСТОТА в использовании пользователем, то такой продукт идет на расхват. Не мало важно эта простота самим разработчикам.
Подобная логика может иметь место только с "розничными" программными продуктами, продающимися широким необразованным массам с полок магазинов. Т.е продуктах, которые пользователь схватит, уволочет в свою берлогу и там будет разбираться с ними наедине с самим собою или аналогичными пользователями, без какой-либо прямой поддержки от разработчика.
Но как только речь заходит о серьезных программных продуктах, работающих, скажем, в научных и технологических областях, такие вопросы роли практически не играют. В большинстве таких продуктов клиента интересует именно и только характеристики результата: качественные (напр. точность) и количественные (напр. скорость получения). А "выжимать" эти характеристики из программного продукта будет не сам пользователь, а все тот же самый разработчик, предоставляющий пользователю постоянную поддержку. И тема "простоты" возникает только в той мере, в которой она полезна и выгодна именно разработчику, а не пользователю. А это совсем другой подход.
Лукавство чистой воды Простота нужна везде. И в разработке и в использовании.
Не надо путать понятие простоты с малофункциональностью.
Вид программного обеспечения не играет роли.
Человек так устроен, что чем проще продукт, тем ему удобнее и приятнее им пользоваться. Пусть даже если это ПО для очень сложных производительных и многофункциональных систем.
Запутывать никого не надо - вот и весь принцип разработки ПО.
офлайн
SpiritMoon
Senior Member
|
|
1267 |
11 лет на сайте Город:
|
VitaliyBoris:SpiritMoon:Например при выборе даты в календаре, валится фронт или идет отправка не валидной dto, надо залесть и подправить, минимуально подкрутить ui на материале или jquery ui.
На основе приведенного примера можно вести разговор в двух направлениях:
- Крутые спецы
наговноразработали классый фронт а баги за них править должны уметь бэкэнд разработчики, самим им видимо влом такими мелочами заниматься- Любой адекватный разработчик с такой мелочевкой как минимально подправить dto и т.п. справится без особых проблем даже не имея приписки в своем CV о минимальных познаниях в области JS.
Вы можете рассуждать как хотите. Ваше право, вакансии висят и спрос есть на все и всех.
офлайн
VitaliyBoris
Senior Member
|
|
1445 |
18 лет на сайте Город:
|
SpiritMoon:VitaliyBoris:SpiritMoon:Например при выборе даты в календаре, валится фронт или идет отправка не валидной dto, надо залесть и подправить, минимуально подкрутить ui на материале или jquery ui.
На основе приведенного примера можно вести разговор в двух направлениях:
- Крутые спецы
наговноразработали классый фронт а баги за них править должны уметь бэкэнд разработчики, самим им видимо влом такими мелочами заниматься- Любой адекватный разработчик с такой мелочевкой как минимально подправить dto и т.п. справится без особых проблем даже не имея приписки в своем CV о минимальных познаниях в области JS.
Вы можете рассуждать как хотите. Ваше право, вакансии висят и спрос есть на все и всех.
SpiritMoon:вакансии по Java или C# без знания JS днем с огнем сейчас не сыщешь
Вот оно как теперь уже
офлайн
Неизвестный кот
Senior Member
|
|
12519 |
21 год на сайте Город:
|
alex-145:Лукавство чистой воды Простота нужна везде. И в разработке и в использовании.Не надо путать понятие простоты с малофункциональностью.Вид программного обеспечения не играет роли.Человек так устроен, что чем проще продукт, тем ему удобнее и приятнее им пользоваться. Пусть даже если это ПО для очень сложных производительных и многофункциональных систем.Запутывать никого не надо - вот и весь принцип разработки ПО.
Да нет тут никакого лукавства. Если технологическое оборудование само по себе сложное, и для его управления нужно иметь возможность изменять сотни не связанных между собой параметров, столько же будет и действий (менюшек, страниц веб-интерфейса и т.д.) в управляющем ПО. Даже если эти интерфейсы будет ясными, понятными и интуитивными - простым его никак назвать нельзя.
офлайн
SpiritMoon
Senior Member
|
|
1267 |
11 лет на сайте Город:
|
VitaliyBoris:SpiritMoon:VitaliyBoris:SpiritMoon:Например при выборе даты в календаре, валится фронт или идет отправка не валидной dto, надо залесть и подправить, минимуально подкрутить ui на материале или jquery ui.
На основе приведенного примера можно вести разговор в двух направлениях:
- Крутые спецы
наговноразработали классый фронт а баги за них править должны уметь бэкэнд разработчики, самим им видимо влом такими мелочами заниматься- Любой адекватный разработчик с такой мелочевкой как минимально подправить dto и т.п. справится без особых проблем даже не имея приписки в своем CV о минимальных познаниях в области JS.
Вы можете рассуждать как хотите. Ваше право, вакансии висят и спрос есть на все и всех.
SpiritMoon:вакансии по Java или C# без знания JS днем с огнем сейчас не сыщешь
Вот оно как теперь уже
Ок, если вы собрались меня третировать, то делаем так.
На момент написания этого поста, всем известный сайт по поиску работы выдает по поиску 632 вакансии «JavaScript» , 393 вакансии «Java», 222 вакансии «C#» 78 вакансий «Java Android»
154 вакансии «Java JavaScript» - добротно, это при том, что Java самостоятельный то язык. А еще разделите андройд от интерпрайза.
Никто не писал что их нету, их мало, я рассматриваю чисто веб и общую массу.
VitaliyBoris:Вот оно как теперь уже
офлайн
VitaliyBoris
Senior Member
|
|
1445 |
18 лет на сайте Город:
|
Так я и не спорю что вакансий по JS больше. Я лишь усомнился в достоверности категоричного высказывания про днём с огнём. А тут уже оказывается что никто и не писал, или писал но имел ввиду другое
gooblin:alex-145:Лукавство чистой воды Простота нужна везде. И в разработке и в использовании.Не надо путать понятие простоты с малофункциональностью.Вид программного обеспечения не играет роли.Человек так устроен, что чем проще продукт, тем ему удобнее и приятнее им пользоваться. Пусть даже если это ПО для очень сложных производительных и многофункциональных систем.Запутывать никого не надо - вот и весь принцип разработки ПО.
Да нет тут никакого лукавства. Если технологическое оборудование само по себе сложное, и для его управления нужно иметь возможность изменять сотни не связанных между собой параметров, столько же будет и действий (менюшек, страниц веб-интерфейса и т.д.) в управляющем ПО. Даже если эти интерфейсы будет ясными, понятными и интуитивными - простым его никак назвать нельзя.
Вы не поняли о чем было написано. Простота использования не означает простоту самой системы.
Недавно столкнулся с MS Access - я не удивлен почему оно загнулось фактически. Более не понятного и не логичного интерфейса я в подобных продуктах не встречал. Почти за любым чихом приходилось гуглить. То же самое применимо к любым комплексам. Вся его работа должна поддаваться логике простого пользователя, чтобы он мог, примерно, понимать, чтобы ему нужно делать не залезая в мануал или интернет каждую минуту. В противном же случаи такие системы - не жизнеспособны и умирают достаточно быстро.
Yosic:gooblin:alex-145:Лукавство чистой воды Простота нужна везде. И в разработке и в использовании.Не надо путать понятие простоты с малофункциональностью.Вид программного обеспечения не играет роли.Человек так устроен, что чем проще продукт, тем ему удобнее и приятнее им пользоваться. Пусть даже если это ПО для очень сложных производительных и многофункциональных систем.Запутывать никого не надо - вот и весь принцип разработки ПО.
Да нет тут никакого лукавства. Если технологическое оборудование само по себе сложное, и для его управления нужно иметь возможность изменять сотни не связанных между собой параметров, столько же будет и действий (менюшек, страниц веб-интерфейса и т.д.) в управляющем ПО. Даже если эти интерфейсы будет ясными, понятными и интуитивными - простым его никак назвать нельзя.
Вы не поняли о чем было написано. Простота использования не означает простоту самой системы.
Недавно столкнулся с MS Access - я не удивлен почему оно загнулось фактически. Более не понятного и не логичного интерфейса я в подобных продуктах не встречал. Почти за любым чихом приходилось гуглить. То же самое применимо к любым комплексам. Вся его работа должна поддаваться логике простого пользователя, чтобы он мог, примерно, понимать, чтобы ему нужно делать не залезая в мануал или интернет каждую минуту. В противном же случаи такие системы - не жизнеспособны и умирают достаточно быстро.
Совершенно верно. И так во всех сферах деятельности человека, во всех профессиях.
И если вернуться к начальной теме этой беседы о выборе языка: из простых в использовании я бы перечислил такие как java, php, python, js.
Есть системы, языки, программы где как ни крутись заходишь в тупик, т.к. спроецировано не верно изначально. И тут не до работы, а до изматывания себя на пустом месте Простота везде и во всем
dmitry_cx:alex-145:такие как java, php, python, js.
C# ?
там нет простоты. одно мученье и запутывание разработчика как и во всех изделиях MS. Все лукавство их продуктов - там вечно что то изначально не доведено до логического конца, до ума, пусть даже чуть чуть. И вечно обновы, заплатки, а воз и ныне там... и все более и более запутывать людей и усложнять и обростать систему ненужным и лишним. Простоты нет совершенно. Путь в никуда. На изматывание сил и средств. Но как говорится на вкус и цвет...
есть языки и программы в которых логически все обустроено изначально в полноте. Добавление большего функционала это равновесие не нарушает.
Из ОС этим может похвастаться только OS X. Но там сложности с привязкой к оборудованию дорогостоящему.
Это из моих наблюдений и опыта. Может кто то из колег не согласен или есть иное мнение?
офлайн
Korben_Dallas
Senior Member
|
|
2843 |
12 лет на сайте Город:
|
alex-145:Лукавство чистой воды Простота нужна везде. И в разработке и в использовании.
Никакого лукавства. Я сужу по себе (EDA, ака CАПР СБИС). Я знаю, что наши клиенты, покупающие наши продукты, практически никогда не будут использовать эти продукты сами. Наши продукты на клиентских мощностях и на клиентских входных данных будем настраивать у них на клиентской локации мы же. "На локации" может означать прямой визит, удаленный доступ, secure room у нас, но суть в одном - нашими продуктами будем в первую очередь пользоваться именно мы. Клиента интересует только результат и его качество. Клиент будет только нажимать кнопку "запустить", когда мы все уже настроили. Клиент сам может пытаться что-то делать (в зависимости от степени своей продвинутости), но как правило это не более чем элементарная подмена входных файлов в рамках одного flow, уже настроенного нами. Чуть меняется flow - снова на сцене появляемся мы.
Поэтому в моем случае клиентское понятие "простоты" никого не интересует. В моем случае важнее девелоперская "простота" - средства, позволяющие мне найти решение клиентских проблем на месте, в отрыве от родного девелоперского офиса, родного продавленного кресла и родной засыпанной крошками клавиатуры. И какими бы сложными эти средства ни были, найти решение проблемы "на месте" - это настоящая "простота", по сравнению с необходимостью делать несколько отдельных сессий. Более того, клиент тоже хочет именно этой "простоты" - чем быстрее у меня "все заработает", тем лучше ему.
alex-145:Не надо путать понятие простоты с малофункциональностью.
Вот именно. Не существует никакой абсолютной простоты. "Простота" решения всегда должна оцениваться в контексте "простоты" задачи. Простые решения для сложных задач существуют только в сказках, в пенсионерских байках "у костра" и в трепотне мотивационных спикеров (что всё одно и то же).
alex-145:одно мученье и запутывание разработчика как и во всех изделиях MS. Все лукавство их продуктов - там вечно что то изначально не доведено до логического конца, до ума, пусть даже чуть чуть.[...]Из ОС этим может похвастаться только OS X.
И вот тут то мы натыкаемся на противоречащую вышеупомянутому принципу белиберду. Тот непререкаемый и ни для кого не достижимый авторитет и уважение, который Майкрософт имеет в профессиональном и мире, основывается именно на сложности задач, которые они решают. Во-первых, это их невероятный успех в решении задачи обратной совместимости. (В возможность такой совместимости изначально не верил никто). Во-вторых, это широта применения той же Windows (во многом обусловленная "во-первых". Весть мир построен на Windows. В дополнение к обычным офисным рабочим станциям, все железо, вся аппаратура сидит на Windows. Все производственные линии на заводах, все станки, вся медицинская аппаратура, все аэропорты, от рентгена до заправщика до посадочного рукава, все магазины, все финансы и т.д. и т.п. - все сидит исключительно на Windows. А это зоопарк - о-го-го и задача титанического уровня сложности.
А вы сравниваете это с "простотой" глорифицированной подставки для кофе с встроенной Internet-enabled фоторамкой и браузером. Ну и еще, говорят, музыку играть может... (Здесь всем известная картинка: трехколесный-велосипед-Mac-vs.-супербайк-Windows.jpg).
Korben_Dallas, в вышеизложенном тексте одно лукавство со всем к вам уважением. Уводите разговор в иную плоскость многословием и запутыванием. Нет простоты у вас. Еще раз прошу извинить если не корректен
Korben_Dallas:Никакого лукавства. Я сужу по себе (EDA, ака CАПР СБИС). Я знаю, что наши клиенты, покупающие наши продукты, практически никогда не будут использовать эти продукты сами. Наши продукты на клиентских мощностях и на клиентских входных данных будем настраивать у них на клиентской локации мы же. "На локации" может означать прямой визит, удаленный доступ, secure room у нас, но суть в одном - нашими продуктами будем в первую очередь пользоваться именно мы. Клиента интересует только результат и его качество. Клиент будет только нажимать кнопку "запустить", когда мы все уже настроили. Клиент сам может пытаться что-то делать (в зависимости от степени своей продвинутости), но как правило это не более чем элементарная подмена входных файлов в рамках одного flow, уже настроенного нами. Чуть меняется flow - снова на сцене появляемся мы.
Поэтому в моем случае клиентское понятие "простоты" никого не интересует. В моем случае важнее девелоперская "простота" - средства, позволяющие мне найти решение клиентских проблем на месте, в отрыве от родного девелоперского офиса, родного продавленного кресла и родной засыпанной крошками клавиатуры. И какими бы сложными эти средства ни были, найти решение проблемы "на месте" - это настоящая "простота", по сравнению с необходимостью делать несколько отдельных сессий. Более того, клиент тоже хочет именно этой "простоты" - чем быстрее у меня "все заработает", тем лучше ему.
Вы продаете не продукт, а сервис - это совершенно другая сфера. Я тоже, когда прихожу, например, в банк не сильно интересуюсь их внутренними системами - мне важен результат. Я не являюсь пользователем их системы - я пользователь их сервиса. Вы говорите именно об этом. А речь шла про программные продукты и комплексы с точки зрения тех, кто будет ими пользоваться.
Korben_Dallas:в пенсионерских байках
Не уважительное отношение к старшему поколению - скорее признак не зрелости, чем повод это выпячивать.
Korben_Dallas:Тот непререкаемый и ни для кого не достижимый авторитет и уважение, который Майкрософт имеет в профессиональном и мире
Вы в каком-то другом мире живете. Ничего подобного Микрософт не имеет. По крайней мере в моем круге разработчиков. Микрософт отличается не полнотой документации и не логичностью решений - это да. Это их фирменный знак, так сказать
Korben_Dallas:Здесь всем известная картинка: трехколесный-велосипед-Mac-vs.-супербайк-Windows.jpg
Наверное по-этому они очень озадачились поддержкой linux нативно?
Korben_Dallas:о-го-го и задача титанического уровня сложности.
Ну уже стало и так понятно, что вы с придыханием смотрите на Микрософт. Может быть больше конкретики? Вся их обратная совместимость основана на том, что API меняется оооочень медленно. И даже при этом не мало функций работают "чуть по разному" от версии к версии.
Я выскажу свое мнение. Лично для меня ваши аргументы не убедительны и выглядят притянутыми за уши. Вы можете не соглашаться со мной, это ваше право, как и я с вами.
Микрософт отличается не полнотой документации и не логичностью решений - это да. Это их фирменный знак, так сказать
Я все никак не могу свой логин в скайпе live:xxxxx переименовать в удобоваримый вид.... что говорить о чем то большем
офлайн
VitaliyBoris
Senior Member
|
|
1445 |
18 лет на сайте Город:
|
Интересно, любители хаять, вас кто-то заставляет использовать то что не нравится? Каждый инструмент хорош при правильном использовании и в нужном месте. А хороший разработчик это тот кто умеет адекватно подойти к решению задачи и правильно выбрать инструмент. А то эти ваши "ЯП1 говно, вот ЯП2 самый лучший" звучат мягко говоря непрофессионально.
VitaliyBoris:Интересно, любители хаять, вас кто-то заставляет использовать то что не нравится? Каждый инструмент хорош при правильном использовании и в нужном месте. А хороший разработчик это тот кто умеет адекватно подойти к решению задачи и правильно выбрать инструмент. А то эти ваши "ЯП1 говно, вот ЯП2 самый лучший" звучат мягко говоря непрофессионально.
Лично я ничего и никого не хаял. Учавстовал в открытой дисскуссии на заданную тему
Мы общаемся, обсуждаем.
Хаять - это поливать грязью и что то кому то навязывать.
Личное мнение никто не запрещает высказывать. Для этого эта тема и создана. Или я не прав?