Вы когда-нибудь жгли свои руки какой-то новой и незрелой технологией?

Question

Я часто слышу, как люди говорят, что вы не должны спешить с внедрением новых технологий, пока они не станут стабильными, испытанными и испытанными. Есть даже шутка о том, что требуется 3 версии, чтобы понять это правильно. Это может быть голос реального опыта, но, по крайней мере, иногда такая поза является результатом самодовольства, сопротивления изменениям и усилий, необходимых для освоения новых навыков.

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

Вот стратегия, которой я стараюсь следовать при любой возможности:

• Будьте агрессивны в освоении новых технологий
• Используйте ранние бета-версии для экспериментов, прототипы и RC для разработки
• Обращайтесь к любым последним изменениям в продукте, когда выйдет официальный релиз технологии, которую вы ранее приняли,
• Не полагайтесь на какой-нибудь непонятный проект с открытым исходным кодом с активностью 0
• Обязательно изучите, но возьмите с собой крупицу официального продукта.

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

Больше, чем приглашение к дискуссии на тему досрочного усыновления, поскольку такой вопрос, безусловно, является спорным и субъективным, я хотел бы услышать реальный опыт, когда внедрение ранней новой технологии оказалось серьезной ошибкой и ужасной ценой. должен был быть оплачен.

Answer 1

QBASIC никогда не взлетал. Я тоже потратил годы на изучение этого.

Хорошо, если честно, это был мой первый язык и хороший способ выучить. И позже он был заменен Visual Basic, а затем VB.NET. Так что это не было пустой тратой моего времени. ;)

Большую часть времени, даже если язык не «вылетает» точно, это все же хороший опыт обучения, который можно применить к чему-то другому.

Answer 2

К сожалению, это сокращает оба пути. Когда мы впервые начали разработку большого веб-приложения для Windows, .NET вышла в бета-версии - с выходом окончательного выпуска .NET 1.0.

Однако, потому что это было ново, и мы не знали, что произойдет, насколько оно будет популярным, и будет ли MS отброшено через шесть месяцев. Таким образом, мы остановились на проверенном VB6.

Мы все еще должны поддерживать это наследие VB6, и какое-то время оно было ограничительным. Хотя он нигде не указан, мы становимся параноиками, что поддержка среды выполнения VB будет прекращена в данной версии Windows.

Тем не менее, переход на .NET-маршрут мог иметь свою собственную боль: 1.0, 1.1 и 2.0 появлялись довольно быстро друг за другом, каждый с (некоторыми) несовместимостями с предыдущей версией. Таким образом, необходимость переноса платформы .NET несла бы другой риск. Меньше или больше? Не могу ответить, что не испытав этого: -)

В конце концов, вы можете быть прокляты, если вы делаете, и прокляты, если вы этого не сделаете. Если кто-то может прочитать внутренности, чтобы определить, преуспеет ли данная технология в какой-то момент времени, у них не должно быть работы в Программном обеспечении, и он, вероятно, вместо этого должен заняться управлением хедж-фондами, заработать кучу денег и рано уйти на пенсию: -)

Answer 3

AzMan (Microsoft Authorization Manager)

Мы начали использовать это в общедоступном веб-сайте / веб-приложении, соблазненном мечтами о едином входе в систему и заявлениями о возможности «использовать свою существующую инфраструктуру» или о чем-то, что сейчас говорится в маркетинге. Встроенное решение для ASP.NET, которым могут управлять системные администраторы без необходимости разработки каких-либо инструментов или написания какого-либо кода. Это было беспроигрышно, верно?

В результате нашего решения мы узнали несколько вещей, ни одну из которых мы не хотели изучать:

• Сам Active Directory не очень хороший выбор для механизма аутентификации, обслуживающего общедоступный веб-сайт. Не то чтобы он не способен - он вполне способен, но это все равно что нанимать доктора философии, чтобы написать приложение «Hello World». Он переоценен, он на намного больше, чем вы могли когда-либо нуждаться в таком контексте, с намного сложнее работать, чем с простой старой таблицей SQL, и требует много больше обслуживания.

• AzMan работает медленно. Очень, очень медленно. Поставщик ролей должен поддерживать кэш , который должен указывать вам, о какой производительности мы говорим. Я никогда не понимал, почему это так медленно, но я думаю, что это как-то связано с гнездом шершня COM и сетевых протоколов, от которых оно зависит.

• Кэш (см. Выше) может быть очень опасным, когда вы почти не контролируете его. Когда мы добавляли новых пользователей вручную (т.е. через административное приложение, а не сам сайт), у этих пользователей появлялся экран «не авторизован» до тех пор, пока не истек срок действия кэша, и они не вышли из системы. Иногда это может случиться даже с пользователями, которые самостоятельно зарегистрировались в Интернете; мы так и не узнали почему.

• Инструменты были ужасны. кратко посмотрите на консоль AzMan , если вы мне не верите, или прочитайте часть документации , если вам действительно нужна головная боль. Почему все должно быть так сложно?

• Это было странно. Часто провайдер просто переставал работать, выплевывая загадочные COM-ошибки (каждый раз по-разному!), И нам приходилось перезагружать IIS или даже весь веб-сервер, чтобы заставить его снова сотрудничать. У нас также было настроено доверие к домену - поскольку очевидно, что мы не хотели, чтобы 50 000 учетных записей публичных пользователей в нашем внутреннем корпоративном домене - единственная проблема состояла в том, что администраторам приходилось входить в учетные записи администратора на дополнительном домене для управления ролей, потому что консоль может работать таинственным образом, если вы попытаетесь использовать ее с основного (даже в качестве администратора предприятия с правами администратора домена на дополнительном домене).

• Поддержка практически отсутствовала. Если вы используете базовый поставщик ролей SQL Server (чего мы не делаем, но только в качестве примера), существует 10 миллионов учебных пособий, и вы можете обратиться в Google за любым сообщением об ошибке или задать любой вопрос на любом форуме. Всякий раз, когда что-то не получалось с AzMan или мы хотели сделать что-то новое, мы постоянно пытались найти хорошую информацию.

• Интеграция кода была неудобной. Вы должны были пройти через кучу беспорядочных COM-слоев, и интерфейс был отстой. Если я правильно помню, просто не было возможности выполнить простую проверку авторизации - вам пришлось загрузить весь реестр приложений / ролей. Это было очень давно, поэтому моя память может быть туманной в этом аспекте.

В конце концов, мы не могли больше терпеть и решили собрать всю систему для домашней, основанной на паре таблиц SQL Server, что, вероятно, и следовало сделать с самого начала. Миграция была болезненной (см. Два пункта выше), но мы сделали это и никогда не оглядывались назад.

Answer 4

Mozilla XULRunner.

Это был Adobe AIR, до того, как появился AIR. Мы написали нашу систему управления персоналом, используя ее. В то время, когда XULrunner был почти готов к выпуску в качестве основного движка для FireFox, мы ожидали, что все, что нам нужно сделать, - это убедиться, что у наших пользователей установлен FireFox.

2 года в проекте, и прямо перед развертыванием вышел новый XULrunner, который полностью сломал весь наш код, а развертывание Firefox нигде не было видно. В итоге мы развернули более старую версию с помощью специального установщика для настольных компьютеров и с тех пор использовали его без обновлений безопасности или производительности, поскольку нам пришлось бы переписывать слишком много кода для совместимости. Несмотря на это, это был очень успешный проект с нашими клиентами.

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

Answer 5

Java

Я очень хотел начать работать над ним в 1996 году и использовал его для нескольких проектов. Но для веб-разработки я всегда предпочитал Perl, а в наши дни PHP. Разработка графического интерфейса В основном я использовал .NET. Для немногих программ командной строки, которые не могут быть обработаны скриптами, я предпочитаю использовать Perl, Python или даже для этого PHP.

Лишь немногие написанные мною Java-программы использовались в течение длительного времени, в то время как некоторые из моих до-Java-приложений все еще использовались.

Я думаю, что главная причина этого заключается в том, что на разработку Java всегда уходило больше времени, чем на другом языке программирования: поэтому полученные приложения содержали меньше функций и их было легче заменить.

Поскольку скорость разработки обычно является проблемой для моих клиентов, Java обычно оказывается вторым выбором.

Answer 6

Ад да

В настоящее время я чувствую боль от раннего принятия Fortran 2003: -)

Mark

Answer 7

за недостаток присутствия на рынке:

• Google's Go
  • Плохой набор инструментов, отсутствует интеграция с популярными компиляторами и C.
• Python3000
  • Отсутствие обязательных функций: итераторы, очищенные внутренние компоненты и более аккуратные интерфейсы хороши для нас, хардкорных пользователей, но большинству нужна производительность, а это не было достигнуто.
• C ++ 0x
• C99
  • Прошло 12 лет, и ни один из основных компиляторов не реализовал это полностью. Популярные проекты и нишевые архитектуры остаются на C89 безопасными.

За плохое качество:

• Windows Vista
  • - сказал Нуфф.
• неволей
• C ++

Для отстающих вверх по течению:

• PyGTK в Windows
• MSVC C поддержка

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

Answer 8

64-битные API-интерфейсы Carbon в Mac OS X: я не переживал об этом лично, но у меня есть друг, работающий в крупной софтверной компании, которая потратила год на преобразование почти всего своего кода в 64-битные API-интерфейсы Carbon только чтобы узнать на WWDC, что эти API больше не будут доступны.

Answer 9

Кто-нибудь заметил здесь тенденцию? Большинство технологий здесь были созданы и отменены или изменены Microsoft ...

Microsoft также сожгла изменения, внесенные в структуру сущностей.

Answer 10

Я невероятно близок к пламени каждый день, будучи ранним последователем MonoTouch. Я никогда не знаю, что будет дальше с этой структурой. Но, к счастью, команда Novell работает с огнетушителями около 24/7:)