Comments 115
Вопрос, вкратце, Вы уверены, что проблема на стороне программистов?
Проблема на стороне всех, кто подвержен хайпу.
То, что на новой работе понабоиться использовать все те технологии, о которых вас спрашивали — вовсе не факт.
Выясняют ваш интерес к профессии разработчика.
Мне к примеру интересны устоявшиеся на «рынке» технологии или то что можно назвать зрелой технологией
ИТ — чрезвычайно быстро развивающаяся отрасль.
И интересовать новыми технологиями — это норма для разработчика, который хочет поддерживать себя в форме. Иначе как вы узнаете, что ваша технология не зрелая, а уже устаревшая?
Показать, что вы читаете о новых технологиях — не единственный способ проявить себя на собеседовании при приёме на работу.
Если вы предпочитаете «проверенные решения», то я ожидаю от вас, что вы сможете обсудить плюсы-минусы любимого фреймворка. И минусы в том числе и возможные пути их решения.
Без хотя бы поверхностного знания «а что там происходит в мире» вы даже не узнаете, что это столь досаждающая вам особенность является минусом и как-то там решается в других фреймворках.
Просто для расширения кругозора нужно это знать.
Не обязательно применять немедленно.
а юзать новомодный фреймворк ради одной фичи это бред.
Никто и не говорит, что нужно юзать. Я это сразу и написал:
То, что на новой работе понадобится использовать все те технологии, о которых вас спрашивали — вовсе не факт.
а) кодер работает не менее 5 часов. Оставшиеся 3 часа он смотрит в окно, пьёт чай, читает любимый форум.
б) кодер работает от 2 до 4 часов и оставшееся время, в том числе смотрит новые фреймворки. Так сверху, рекламки читает на хабре.
в) кодер работает мало, он сразу в гугл и ищет любой фреймворк или библиотеку, которая хотя бы частично решает его задачу. Ему пофиг на рекламу и перспективы, всё равно года через два он сменит работу по тысяче причин.
Ожидать от А тяги к хайпу, наивно. Он перепишет лучше. Очень опасен Б, он ради премии на пятиминутке обязательно ляпнет, что есть новое и модное и он готов, за доплату внедрить. Ему доплата, всем (цензура). Как правило В не опасны совсем, так как где есть В — там проекты больше 3-х лет не живут.
Но всё меркнет перед начальником, который говорит: «Я знаю, что через браузер можно получить доступ к внутренним ресурсам компьютера, пример, хром ос. Давайте!». И что надо сказать, чтобы угомонит тягу начальника к хайпу?
ИТ — чрезвычайно быстро развивающаяся отрасль.
Честно, очень спорное утверждение. Я всё таки придерживаюсь комментария ниже, так как большая часть людей перестали читать книги совсем, то «внезапно» многие люди осилившие литературу 90-х годов могут предложить нечто новое, которое хорошо забытое старое.
ага, обычно опыт должен быть не менее 5-ти лет… )
Забыли добавить, работодатели часто требуют опыт не менее 5-ти лет даже по фреймворкам, которым ещё нет 5-ти лет.
Куда отнести того, кто работает много, но половину времени — в гугле в поисках библиотек, решающих задачу?
Или того, кто первым схватит любую подходящую библиотеку — но если ее возможностей не хватит либо в ней найдется баги — сам же и перепишет ее лучше?
Куда отнести того, кто работает много, но половину времени — в гугле в поисках библиотек, решающих задачу?
Б.
Или того, кто первым схватит любую подходящую библиотеку — но если ее возможностей не хватит либо в ней найдется баги — сам же и перепишет ее лучше?
А. Только он не схватит любые библиотеку, а проведёт анализ чужого кода и использует чужие наработки для своего кода. Или восхитившись неизвестными мастерами будет юзать их код. Ну правда если речь не о совсем известном, типа БД.
Только это уточнение никак к теме комментария не относится. Надо внести правки в программу на java. Внезапно, кто-то заявляет, что java отстой, а go это тренд! Программа переписывается на go. При этом программисты go изначально не знали, вот учатся на вашем проекте. Для программистов, по моему мнению, это нонсенс. Для работодателей — сплошь и рядом.
То есть я первый спросил, как бороться с начальниками? Кодер человек маленький, чего нам бодаться?
Такое ощущение, что вы не просто не изучаете, что происходит вокруг, а еще и гордитесь этим.
Забыли добавить, работодатели часто требуют опыт не менее 5-ти лет даже по фреймворкам, которым ещё нет 5-ти лет.
В большинстве вакансий вижу требования к опыту 1-3 года
Такое ощущение, что вы не просто не изучаете, что происходит вокруг, а еще и гордитесь этим.
Себя я отношу к категории В, то есть я за любой скопированный код, который хоть частично решит мою задачу.
Может сойдёт за оправдание, что пока программирование не мой заработок.
Это вокруг в интернетах все трудоголики грамотные.
ага, обычно опыт должен быть не менее 5-ти лет… )
Какая шумиха вам больше пришлась по душе?
Веб 2.0, Bootstrap и, конечно же, JQuery.
И вот, очередной перевод. Берём первый попавшийся отрывок.
Оригинал:
watch carefully what happens after people are back from conference. People get inspired. And that’s a two-edged sword. Starting to use newest hottest lib/framework/architecture paradigm without enough research might be a highway to hell.
Перевод из статьи:
воодушевление после посещения конференции, что на самом деле палка о двух концах: использование новейших, последних библиотек/интерфейсов/технологий без опыта обращения с ними может быть дорогой в ад
Как на самом деле переводится отрывок:
посмотрите внимательно, что происходит, после того, как люди возвращаются с конференции. Люди воодушевлены. А это обоюдоострый меч. Использование новейших, наиболее привлекательных библиотек/фреймворков/архитектур без предварительного изучения может быть дорогой в ад
Хочется задать автору вопрос — зачем вы порете отсебятину, вместо того, чтобы заниматься переводом?
Перевод топикстартера — лучше.
Вас не смущает, что в оригинале нет слова интерфейс? Что в оригинале нет слова технология?
В частности вам нужно посмотреть в сторону понятия переводческой эквивалентности.
Вы написали комментарий в ответ на мой вопрос, не смущает ли кого-нибудь, что в оригинале нету слова интерфейс и слова технология. Там, где у пеерводчика интерфейс в оригинале — фреймворк. Там где у переводчика технология — в оригинале — архитектура.
Мне вот очень любопытно, как слово интерфейс может быть на втором уровне эквивалентности слову framework, а слово фреймворк — на пятом уровне эквивалентности слову framework.
При этом одному читателю может понравиться один вариант, кому-то — другой. Начинаются споры и обвинения в «неправильности», хотя на деле всё это очень субъективно. Примерно такое наблюдается в каком-нибудь комьюнити фансаба азиатской анимации.
Что касается конкретно этих двух слов — в профиле автора есть замечательная кнопочка, по которой можно отправить личное сообщение. Если бы вы хотели, чтобы слова были исправлены, вы бы написали ему. Но вам, видимо, хотелось попесочить косточки постоянно переводящему статьи пользователю, поэтому вы начали писать комментарий со слов: «И вот, очередной перевод. Берём первый попавшийся отрывок…»
Перевод — то не уравнение с одним решением. Его можно выполнить по-разному. Какой-то будет точнее следовать оригиналу и выглядеть как подстрочник
Быть ближе к оригиналу и выглядеть, как подстрочник — разные вещи. Но вы только что сказали, что у нас с авторорм разные уровни эквивалентности. Интуитивно подозреваю, что пятый уровень хуже, чем второй. И решение автора перевода — по вашему мнению лучше.
Вы не могли бы добавить побольше конкретики? В других коментариях есть замечаение про фразеологизм. Оно понятное и ценное. У вас есть замечания такого характера?
Что касается конкретно этих двух слов — в профиле автора есть замечательная кнопочка, по которой можно отправить личное сообщение. Если бы вы хотели, чтобы слова были исправлены, вы бы написали ему. Но вам, видимо, хотелось попесочить косточки постоянно переводящему статьи пользователю
Переводы пользователя пестрят грубыми ошибками. Какие-то исправляются, какие-то нет. Я думаю, если писать по поводу ошибок перевода непостредственно в коментарии — переводы станут лучше. И вы знаете — действительно помогает. Раньше у переводчика были переводы, меняющие смысл фразы на противоположный — теперь такого не встречаю.
Я правильно понимаю, что вы только что попросили не обсуждать в коментариях к переводу качество перевода?
Если замечания по переводу ценные, то перевод улучшится независимо от того, куда эти замечания отсылать.
И, конечно, вы заблуждаетесь. Обсуждать — это писать комментарий — смотрите вот тут у автора косяк. Или смотрите — вот тут автор перевёл особенно хорошо. Всё точно так же, как в технических статьях.
Я правильно понимаю, что вы считаете, что не нужно обсуждать качество перевода в коментариях к переводу?
Правильно :) Мне, по-большому счету, все равно, кто расставил эти буквы в слова в таком порядке, меня, по-большому счету, интересует прежде всего информация, которая передается при помощи этих слов. Это https://habrahabr.ru/, а не http://yapishu.net/
Я правильно понимаю, что вы считаете, что не нужно обсуждать качество перевода в коментариях к переводу?
Ну обсудили уже.
С вами большинство не согласны.
Предложенные вами идиомы — более корявы, чем у автора перевода.
P.S. Если не знать откуда там джаз и девушки — то вообще мистика
У топикстартера перевод лучше, чем у вас
Ну да, ну да. Например в оригинале обоюдоострый меч, а у него палка о двух концах. Или в оригинале фреймворк/архитектура, а у него интерфейс/технология. В оригинале — предварительное изучение или исследование, у него — опыт обращения.
Уверен это сильно улучшило перевод.
Переводить слово в слово — не всегда хорошая идея
Наверное, можно заменить фразеологизмы, которые отсутствуют в языке, на который мы переводим, на те, которые там есть. Но у переводчика тут просто переписывание текста так, как ему больше нравится, иногда с правками, искажающими смысл.
Когда переводишь — надо переводить. И, если автор написал — посмотрите внимательно, что происходит когда — то надо переводить то, что написал автор, а не то, что тебе хотелось бы видеть на этом месте.
Например в оригинале обоюдоострый меч, а у него палка о двух концах.
Идиомы в разных языках — они разные.
Французы бы сказали скорее про «две стороны одном медали», к примеру.
«Обоюдоостный меч» — практически не употребляется в русском языке и совершенно непонятно, приходится вдумываться.
В то же время «палка о двух концах» — понятно сразу.
Вы, наверное, хотите сказать, что в русском языке нет идиомы обоюдоострый меч? И что русские две стороны одной медали не говорят?
Обоюдоостный меч — это малоупотребимая калька с английского.
Тем не менее фразеологизм в русском языке есть и, пусть редко, но используется. Но допустим, вариант с палкой о двух концах лучше. Вы действительно считаете, что присутствие хорошо перенесённого в культурный контекст фразеологизма компенсирует остальные дефекты перевода?
Оригинал:
watch carefully what happens after people are back from conference. People get inspired. And that’s a two-edged sword. Starting to use newest hottest lib/framework/architecture paradigm without enough research might be a highway to hell.
Перевод из статьи:
воодушевление после посещения конференции, что на самом деле палка о двух концах: использование новейших, последних библиотек/интерфейсов/технологий без опыта обращения с ними может быть дорогой в ад
Ваш перевод:
посмотрите внимательно, что происходит, после того, как люди возвращаются с конференции. Люди воодушевлены. А это обоюдоострый меч. Использование новейших, наиболее привлекательных библиотек/фреймворков/архитектур без предварительного изучения может быть дорогой в ад
Ваш пример режет русскоязычный слух.
Мой русскоязычный слух — не режет. Но допустим у вас слух лучше.
Повторю вопрос, который уже задавал. Вас не смущает, что в оригинале нет слова интерфейс? Что в оригинале нет слова технология? Не смущает вас, что в оригинале предлагают примотреться к людям, которые вернулись с конференции, а в переводе этого нет вообще?
И потому, что мысль от этого не изменится, слово фреймворк надо заменить на слово интерфейс?
Мне не нравятся ничем не мотивированные правки авторского текста. Но я бы не стал делать отдельный коментарий, если бы автор ограничивался ими.
В публикациях данного автора систематически встречаются грубые ошибки в переводе. Грубые. Если при первом взгляде на перевод нашлась немотивированная замена одного слова на другое — наверняка если посмотреть внимательнее — найдётся что-то совсем плохое.
И действительно.
Оригинал:
people who know different paradigms, understand theory of programming (e.g. algorithms, concurrency)
Перевод:
Люди, которые знакомы с различными парадигмами, понимают теорию программирования (например, алгоритмы, взаимосовместимость)
Это явный пример перевода промптом. Мало того, что автор выкладывает перевод, сделанный кем-то другим, так он ещё и не проверяет его перед публикацией.
Но, как я вижу, кроме меня, такое мелочи никого не интересуют.
А кроме того, промт не заменил бы одну идиому на другую — это как раз осмысленная человеческая работа.
Я допускаю, что у автора встречаются реальные ошибки — но ваш исходный комментарий выглядит как мальчик, кричащий «Волки!» при их отсутствии, так что вы сами поставили себя в ситуацию, когда, кроме вас, это уже никого не интересует.
Это не «явный пример перевода промтом», потому что как раз промт никогда не перевёл бы concurrency как «взаимосовместимость».
Действительно. Промпт перевёл concurrency как паралеллизм. Чувствуется, что вы лучше меня с ним знакомы.
Мне нужно было сказать, не пример перевода промптом, а пример случая, когда переводчик понятия не имеет о чём текст, который он переводит.
Вот тут мой коментарий заминусовали.
А переводчик тем временем поправил перевод. Раньше он переводил concurrency как взаимосовместимость.
Теперь он поправил перевод и concurrency переведено как параллельные вычисления. Кто-то еще верит, что переводчик понимает что написано в тексте, который он переводит?
P. S.
Да, примерно так concurrency перевёл Промпт :).
Мой русскоязычный слух — не режет.
Судя по количеству допускаемых вами грамматических ошибок, ваш слух это действительно не должно резать.
А вы делаете различие между грамматическими ошибками и опечатками?
Если же у вас совсем-совсем нет времени на проверку, то что вы здесь делаете, комментируя?
Опечатка это разновидность ошибки, которая получается, когда думаешь, что жмёшь на одну клавишу, а на самом деле жмёшь на другую. Их количество зависит не от уровня владения языком, а от уровня владения клавиатурой. Таким образом тот факт, что человек делает опечатки — не свидетельствует о пренебрежении к языку.
Исправлять опечатки мешает одна особенность человеческого мозга. Люди, которые много читают, зачастую определяют слово не по совокупности букв, а по первой букве, последней букве и контексту. Для того, чтобы найти опечатку — надо намеренно бороться с этой особенностью, что далеко не так легко, как кажется на первый взгляд. О незнании правил тут речи не идёт. Если попросить человека, который сделал опечатку произнести слово по буквам — он сделает это правильно. О неуважении к языку тот факт, что человек не исправляет опечатки, не свидетельствует по той же причине.
«кто с мечом к нам придет, тот от меча и погибнет».
Но она про другое.
Обоюдостным меч — это, скорее, следствие таких вот переводчиков как вы, которые считают, что языки отличаются только звучанием и нужно переводить дословно.
А язык — это часть культуры, часть мышления.
Простой лобовой первод — всегда некорректен. Даже простое приветствие «хау ду ю ду» нельзя переводить в лоб.
Я согласен, что языки сближаются. Кальки идиом переходят из языка в язык…
Но когда вы начинаете бежать впереди паровоза — ваш перевод может быть трудно понять человеку, которые не знает английский.
Обоюдостным меч — это, скорее, следствие таких вот переводчиков как вы, которые считают, что языки отличаются только звучанием и нужно переводить дословно.
Фразеологизм обоюдоострый меч пришёл в русский язык не из английского языка, а, в лучшем случае, из Библии.
Я согласен, что языки сближаются. Кальки идиом переходят из языка в язык…
Давно уже пришёл. Настолько давно, что успел немного устареть.
Но когда вы начинаете бежать впереди паровоза — ваш перевод может быть трудно понять человеку, которые не знает английский.
Мда
И, если уж на то пошло, то не фреймворк, а каркас.
Разработка постепенно превращается в ад, но у начальства все хорошо
Возможны вы имеете ввиду обговоренности и общее понимание того что и как и зачем и почему без излишней формализации процесса… Тогда согласен…
В данном случае речь идет не о формальный процессах, которых может и вовсе не быть — а о процессах AS IS, как есть.
Отслеживаются ли где-нибудь выявленные баги? В какой форме они доносятся до исполнителей — email, какой-нибудь im-клиент, телефон — или программист узнает о баге в тот момент когда в нему врывается орущий начальник? :)
Как взаимодействуют те, кто разрабатывают взаимодействующие сервисы? Договариваются сами, или есть ответственный за протокол взаимодействия?
Как выделяется время на инфраструктурную часть? "Пока логи не сделаем — за сервис не беремся" — или по остаточному принципу, "ты главное баги закрой — а логи будешь чинить если время в конце спринта останется?"
Отслеживаются ли где-нибудь выявленные баги? В какой форме они доносятся до исполнителей — email, какой-нибудь im-клиент, телефон — или программист узнает о баге в тот момент когда в нему врывается орущий начальник? :)
Я это для меня норма. тут мы на одной волне.
Я имел ввиду перерегуляцию которая мне встречалась (не СНГ).
Например наш процесс выглядит так, что перед тем как добавить 3 столбца в ДБ ты должен обговорить это с Тем-то и с тем-то…
Процесс заказа виртуальных машин, рамки фреймворков, рамки, языков програмирования…
Процесс получения прав на сервисы и АПИ, процесс аргументации за новую идею…
Мой опыт подсказывает, что сделать разработку можно сделать менее адовой за счёт изменения процесса. Порефлексировать, откуда берётся ад и соответствующим образом поменять разработку. Можно формальным изменением процесса, можно другими способами.
Вы встречались с подобным? Команда выбирает новейшие, самые «горячие» технологии для использования в проекте. Кто-то из них читает пост в блоге, тренд в Твиттере или только что пришел с конференции, на которой говорили великие вещи. И вот уже команда использует эту блестящую технологию (или новую парадигму программной архитектуры), но вместо обещанной большой скорости работы и высокого качества продукта, они получают неприятности.
Я чаще с обратным сталкивался.
Новая технология уже в мейнстрим входит, а люди все еще считают, что мол «это очередная игрушка, которых каждый год выпускается вагон и маленькая тележка — мы будем сидеть на проверенных технологиях 1990-х годов (даже не очень-то и утрирую)»
Вы что — одним проектом по 10 лет занимаетесь?
Вряд ли даже хотя бы 3 года.
А начать очередной новый проект на новой технологии — достаточно безвредно.
А что в итоге? Новая мега-супер-пупер штука как и все предыдущие до нее обладают одними и теми же проблемами:
а) Ее тесты не покрывают добрую половину сценариев использования.
б) Имеет ограниченный набор инструментов для расширения собственных же инструментов.
в) Функционально чаще всего ограничена минимальным набором функций, которые смогли сделать к релизу версии №5 (хотя на самом деле, публичный релиз первый).
г) Добавление новых функций идет по двум сценариям: 1 — я бог, а вы ничто, я сказал этого здесь не будет. 2 — под давлением общественности набрасывается уйма новых функций, без опять же должного тестирования, и теперь тесты покрывают только 25% всех кейсов.
д) Не получив должного инвестирования, библиотека накрывается медным тазом и саппортится либо вялым комьюнити, либо платными консультантами.
Вас никто не заставляет использовать небольшие полухобби-проекты в качестве базы для своих разработок.
Полно хорошо финансируемых новых разработок.
Скажем над Kubernetes трудятся разработчики из десятков крупных фирм (на зарплату, замечу).
И к ним присоединяется Кристиан Гислер, а также разработчики OpenOffice / Libre Office. Все они тянут свои продукты по многу лет.
И что более печально, таких случаев с мёртвыми технологиями гораздо больше, чем случаев ненужного использования молодых инструментов, но говорят почему-то только про второй случай.
в некоторых банках ещё остаётся COBOL. Они также не поддерживаются, в них не добавляются новые функции, а тестов нет вообще. Зато не «модная хипстерская игрушка». Разве это нормально?
Кобол используется только в крупнейших банках, которые начали автоматизироваться еще полвека назад, когда это было страшно дорого и недоступно для большинства.
Так что уж что-что, а компетентных специалистов такие банки могут себе позволить.
И уж кто-кто, а банки умеет считать деньги.
Если какие-то используется Кобол, то они так оценили стоимость работ и стоимость своих рисков перехода на новую систему.
До сих пор масса сайтов работают под PHP 3.0
Главная причина, по которой мы уходим от ручного труда к автоматике — автоматика работает и зарплату не просит.
То есть — если PHP 3.0 где-то работает и владельцев этой системы всё устраивает, то кто мы с вами такие, чтобы указывать владельцам той системы что им следует перейти на PHP 7.1?
Ни я не вы вовсе не собираемся оплачивать им этот переход.
Они самостоятельно решают как им распорядиться деньгами — сделать апгрейд до PHP 7.1, закупить новую мебель в бухгалтерию или поехать в Ниццу.
Поэтому даже если мы с вами видим недостатки использования PHP 3.0 в современном мире — мы никак не можем влиять на это. Ну ровно до тех пор, пока кого либо из нас (вас или меня) привлекут к доработкам этой системы и мы предложим за 100500 денег допилить с PHP 3.0, а за 100500/2 перейти на 7.1 и допилить уже с PHP 7.1.
В мире JavaScript каждый день появляются новые фреймворки: Node.js (ключевые слова: событийно-ориентированное программирование)
Э… с каких это пор Node.js является фреймворком? И причем тут событийно-ориентированное программирование?
As an asynchronous event driven JavaScript runtime, Node is designed to build scalable network applications.Взято с Node.Js/About
основываясь на ошибочных мнениях из социальных сетей и на всем том, что является скорее модным, чем хорошо изученным, без серьезной оценки возможного влияния на их проекты
Я чет в псевдосоцсетях не нашел нормального контента по программированию. :)
Но да, программисты нынче стали модниками. :)
TDD мертв из-за DHH
Хм, возможно позиция DHH повлияла на Ruby. Но да, у толкового разработчика должна быть своя позиция, а не быть флюгером. :)
П.С.
Сам борюсь с хайпом на счет «Фреймворки — наше все» в PHP. :)
Разумеется вам не обязательно использовать все подряд, использовать это так и там, как определяют авторы в своих решениях. Но знание подобного рода инструменов очень полезно для собственной базы знаний. Это один из факторов, от которого зависит ваш профессионализм, качество предоставляемых вами решений. Если вы читали статью Роберта Мартина «Screaming Architecture» (https://8thlight.com/blog/uncle-bob/2011/09/30/Screaming-Architecture.html) то понимаете, что програмное решение не должно зависеть от таких вещей как фреймворки, библиотеки, базы данных, веб серверы, и т.п.
Но эти знания не будут лишними, когда настанет время раскрыть детали вашей програмной архитектуры. И тогда вовремя представленное предложение позволит сэкономить вашей команде огромное количество времени, в попытках решить задачу стандартным набором инструментов.
Берешь новую технологи, документации нифига нету, тратишь время, руки по локоть в коде…
Через некоторое время, понимаешь, что это «новая технология» нифига не новая, а самая что ни есть «старая», которую обругали поколение назад.
Пару раз мне было интересно, откуда ноги растут у «новой технологии», и складывается такое впечатление, что люди писавшие «новую технологию» не читали книжек хотя бы 10 летней давности.
Самое забавное, когда доходит до сравнения финансовых показателей похожих проектов по «старой кривой технлогии» и «самой новой правильной технологии». Вот тут и выясняются, что разницы то нету, а зачастую «новая технология» первые год… два может быть дороже :) Но это же фигня? через два года будет «Самая Новая Технология».
Критерий — деньги. Пока иного мерила не придумали
По совокупности скромные/убогие/устаревшие стандарты и решения заложенные в 90х могут дать фору Новым Мегафичам и Правильным Архитектурным Подходам.
Иногда складывается такое впечатление, что кто-то наконец прочитал книжку 90х… попробовать сваять, оно заработало и с криком «Ура! Заработало! Я мегакрут!!!» выкладывает в сеть.
Например: микросервисы. Основная декларируемая проблема, что они должны решить «сейчас делают большие толстые сервисы и это плохо и сложно».
Насколько я помню, в момент перехода от RPC к сервисной архитектуре основным декларируемым достоинством было: мы можем наделать кучу маленьких специфических сервисов, а клиент сам будет решать что ему надо. Середина 90х годов и начало 200х.
Чем декларация середины 90х отличается от декларации середины 201х? на мой вгляд ничем.
Основная проблема это либо техника, которая «не тянет».
Либо, что встречается на мой взгляд чаще, дурь религиозная…
Это решение от мс, поэтому фигня.
Достаточно посмотреть на vml/svg, модные датабиндинги в современных js фреймворках и реализации этого же в IE, да тот же dojo с его кастомными атрибутами в свое время поносился как «неправоверный» и нарушающий html, а нынче angular, Bootstrap, knockout и иже с ними работают именно так.
А так… Стек возможностей нынче до боли похож на начало 2000-х.
Датабиндинги в IE принципиально отличаются от современных. Они ведь не к js-объектам привязываются — а к COM.
емнип, там был биндинг к элементам страницы. Причем практически любым.
С доступом из Js.
Серьезно принципиально отличаются по сути решаемой задчи?
С одной стороны — да, любой элемент страницы. А с другой-то что? А с другой вот это: https://msdn.microsoft.com/en-us/library/ms531386(v=vs.85).aspx
csv-файл, база данных, xml-файл… Ничего такого, чем можно было бы достаточно просто управлять через js.
Современные же решения берут данные из js-объектов
Предоставленные нам сервером.
Рассуждения бессмысленны. Поскольку скатятся к формату «если бы».
Технология была еще в затертом 2001, была не востребована по разным причинам.
Сейчас переизобрели велосипед и года 4-8 его развивали.
Угу, а в объекты мы кладем их из файл/база/файл.
Предоставленные нам сервером.
Ради того, чтобы перегнать данные из файла или базы в HTML — датабиндингом никто не заморачивается. Для этих целей есть неплохо работающие серверные шаблонизаторы.
Смысл клиентского датабиндинга — в том, что данные "в объекты" попадают от пользователя, минуя сервер.
В рамках тех времен предполагалось не плодить зоопарк, а работать прозрачно в одной архитектуре. Когда клиентский ввод обрабатывается в одном месте, а не в 2-3 дублях (и на клиенте, и на сервере.
Опять же повторюсь. Рассуждения бессмысленны. Поскольку для корректных параллелей потребуется слишком много допущений о последующем развитии технологии.
Если брать аналогию, то электромобили и двс. Начало прошлого века и началого этого.
Электромобили были раньше и долгое время держали рекорды.
Потом пришел двс который делает то же самое, но немного иначе.
Сейчас на примере Теслы и прочих наблюдаем возврат к электромобилям.
Вообще-то, это вы высказали утверждение — вам его и доказывать. Нельзя что-то доказать сказав "Рассуждения бессмысленны"
А отказ от них или аргументы против были скорее религиозного характера или просто не тянула техника (например те же чистые js приложения, и, да, я в курсе о влиянии js-движков)
Перечитайте внимательно.
И vml, и биндинги, и dojo Toolkit
Доказательства тут это примеры рабочих систем.
Или отсылки на спецификации.
Первое я вам не приведу.
Второе дал пусть и в единственном числе.
Dojo Toolkit и дискуссии по нему времен 2008/2009 поищите как-то сами. В качестве подсказки могу задать направление — кастомные атрибуты в html, которые он использовал, вызывали возражения.
А вы ожидаете от меня каких-то доказательств вашему личному внутреннему несогласию с чем-то неизвестным мне, поскольку вашей позиции я вообще не знаю.
Вам не кажется смешным для меня вести дискуссию в таком ключе? :-D
Причем тут религия — если всеми этими технологиями неудобно пользоваться?
Какими из?
Вам неудобно было с vml?
Или с dojo?
Насколько я помню единственное и существенное неудобно было у пользователей линукса, которых на начало 2000-х было чуть меньше чем ничего.
Поскольку многие технологии были завязанными на win-платформу
Я говорю про то, про что знаю — про биндинги. То, что было сделано в IE, могло иметь применение в приложениях для интранета — но в вебе это попросту негде применить.
Это было в 2000-2001
Там спроса не было на тяжёлые RIA в вебе.
Соответственно и технологии решали актуальные задачи на тот момент.
Если бы мелкомягкие не факапили, а развивали их, то…
Во рту росли бы грибы.
Как это отменяет тот факт, что современные решения это реализация старых, но в новом окружении реалий?
Это отменяет вот это:
Либо, что встречается на мой взгляд чаще, дурь религиозная…
Это решение от мс, поэтому фигня.
Те технологии забыты потому что мелгомягкие факапили, а не потому что мелгомягкие.
Ослика подзабросили.
А потом забили камнями окружающие.
И доблестно боролись с трудностями повторно.
Причины там были именно что религиозные.
Возражения о проприетарности и лицензиях появились лет эдак на пять позже.
P.S. И, да, религиозная дурь встречается и сейчас, и не только в отношении мелкомягких.
Просто они были одним из первых и ярких примеров
P.P.S. Как-то дикусс у нас скатился совсем не в техническую сторону, которой вы возражали изначально.
Поэтому предлагаю закрыть его.
Например я решал определнные проблемы с деплойментом аппликаций и в начале 14-го наткнулся на Докер — который по определнию, если тупо смотреть на графики развития графиков был ХАЙПОМ (а многие до сих пор за хайп считаают)
Но поскольку у меня был уже 10 летний опыт програмирования, заботы о продуктивных серверах и решении организационных вопросов, я стал его испосльзовать и понемногу даже евангилизировать у себя на фирме (где был сраавнительно недавно)
И именно -этим граффиком мне давлаи отпор не вдумываясь… Мол хайп и ерунда…
Вот пол года назад стали ко мне приходить, что-бы показал как-та, было-то… Как его варить его, у тебя мол это же работаает в комманде…
Я смог доверить своему опыту и разобраться нужно это мне или нет не ждать 2-3 года пока кто-то решит что эот уже не хайп…
Мой вывод: Да про хайпы надо знать, особенно если ты юниор… Но когда ты сеньор и поковырял много чего, испытал много проблем, то доверяй своему опыту и остовайся открытым к диалогу…
Ищи диалог с опытными людьми особенно с теми кто другово мнения, если конечно человек умеет открыто общаться… Оставайся в диалоге…
Архитектуры и тулы не вечны и еще не постояннее требования к системам.
Не ради поддержания руссиано, а чтобы знать, откуда черпать все эти «термины», чтобы оставаться в полном понимании картины и быть на гребне сленга?
А, скажем, у немцев и французов — огромное количество англицизмов, да еще прямо без какой-либо трансляции с учетом грамматики языка пишутся буква-в-букву.
Правда, китайцам тут повезло больше. Они при всем желании не могут заимствовать.
Но есть и альтернативная модель поведения и на латинице: финны очень рачительно относятся к новым терминам в своем языке. Общемировых сходных во большинстве языков слов типа «фотография» в финнском языке крайне мало. Предпочитают сами придумывать.
французов
эти какраз переводят все научные термины, есть вроде контора такая за это ответственая… — ля гранд натьен — таки ;))
А немцы не паряться так по этому поводу… — и я тоже если честно… глаза режет на русском читать «гибкие методы» и прочее…
Зачем? Никто не заставляет в Пушкина вставлять английские слова… Но в проффессиональной деятельности, совершенно глобально востребонанной и развивающейся области, где английский стандарт, зачем придумывать сложности?
ИМХО.
SVN
Как на счёт CVS? :)
ну как пример: третья версии С++ — это С++98, вполне зрелая технология. Третья версия Си — это С89, тоже хорошая технология. Третья версия паскаля — это Delphi.
А с Git все проще. Какая цена перехода? Какая цена переобучения? Какая цена ошибок, возникших от недостаточного владения Git?
— Армяне лучше, чем грузин!
— Чем лучше?
— Чем грузин!
Пока вы не расскажете руководству реальную киллер-фичу git — цена перехода будет выше потенциальных преимуществ.
P.S. Мы сидим на git, :-)
2) «Зачем создавать ветки, если можно коммитить все в master?»
3) «Зачем настраивать деплой через Git, если есть FTP?»
Hype Driven Development