Статьи

Понимание скрытых мотивов и сил вокруг стандартов программных технологий

Введение в стандарты программного обеспечения

Каковы технологические стандарты? Какие стандарты? По сути, технологический стандарт представляет собой общее соглашение об интерфейсе прикладного программирования и / или протоколе связи в вертикальном секторе. Стандарты могут быть большими или маленькими. Они оказывают глубокое влияние на сознание общества людей, экономический рынок и, конечно, корпоративную деятельность.

Британский институт стандартов упоминает три аспекта стандартов, а именно:
разнотравно

  1. Стандарты усиливают защиту потребителей и доверие
  2. Стандарты обеспечивают основу для взаимодействия
  3. Они облегчают торговлю

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

1
2
3
class Java_Community_Process
 
alias JCP type of Java_Community_Process

Это определяет сущность под названием Java_Community_Process с псевдонимом. Помните, что это не язык программирования Java, а придуманный для примера. Конечно, мой придуманный псевдо-язык Java обходится без точек с запятой, потому что я живу во втором десятилетии двадцатого века, а не в середине 1990-х годов. Я также склоняю голову перед концепцией делегатов; композиция по наследованию, а также идея управления версиями классов, типов и функций, которую я отметил в других академических языках программирования исследований. Давайте вернемся на правильный путь.

JCP является органом стандартизации, который поддерживает, записывает и выполняет более 500 запросов спецификаций Java (JSR). Давайте просто выберем один из них:

1
2
3
4
5
6
7
abstract class JSR delegate from JCP
 
alias JSR type name Specification  // the popular vernacular term "standard"
 
abstract class JPA version 1.0 delegate from JSR
 
abstract class JPA version 2.0 delegate from JSR

Это определяет стандарт API Java Persistence с двумя разными версиями.

1
2
3
4
5
implementation class Hibernate version 5.0 extends JPA version 2.0
 
implementation class EclipseLink extends JPA version 2.0
 
implementation class TopLink extends JPA version 1.0

Это определяет две стандартные реализации JPA 2.0 и признает существование реализации, которая соответствует более старой версии JPA.

Обычно, когда вы пишете конкретный класс, вам сначала нужно определить суперклассы. Странная практика — писать классы реализации перед предком, если у вас есть предварительные знания о полных суперклассах. Когда у вас будет много суперклассов реализации, и у них будут общие функции, соавторы и ответственность, тогда у вас может появиться время для рефакторинга, чтобы упростить повторное использование.
Точно так же, прежде чем какие-либо библиотеки могут быть стандартизированы, они должны уже существовать. Многие клиенты и потребители уже используют библиотеку последовательно, надежно и продуктивно. По этой причине экспертной группе гораздо легче создать успешную спецификацию JPA впервые, чем страдать от Entity EJB.

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

J2EE промахи и размышления

Когда Java EE началась в 1999 году, как J2EE, комитет, экспертная группа, сделал технические и коммерческие стратегические ошибки в их общей спецификации.

Во-первых, это был ад XML для всех видов конфигурации. Первым версиям EJB требовалась смелая конфигурация XML, чтобы определить, например, Session Bean без состояния. Они также указали как минимум два Java-интерфейса, которые должен был реализовать класс. Это была длинная история, но аннотации в стиле Java 5 в конце концов спасли день.

Во-вторых, группа экспертов разработала катастрофическую концепцию EJB Entity Beans для сохранения в базе данных. Экспертная группа основывала свои спецификации на более старых стандартах проектирования, таких как CORBA.

В-третьих, группа экспертов и комитет не спешили следить за тем, чтобы разработчики переходили к простоте использования, быстрому и итеративному проектированию. Серверы приложений были дорогими, и было мало примеров с открытым исходным кодом полной технологии J2EE, доступной для студентов и новых учеников. К тому времени, когда движение AJAX и Ruby-on-Rails началось в 2005 году, игра почти вышла из строя. К счастью, Sun Microsystems внесла некоторые изменения в импорт.

Наконец, технология в значительной степени опиралась на поиск зависимостей. Комитет не мог видеть влияние Инверсии Контроля на будущее после тысячелетия в сравнении с Инъекцией Зависимости. Поэтому другие люди и, в частности, один человек увидели разрыв на рынке. Некоторые говорят, что остальное уже история.

Креативность

Вокруг стандарта креативность связана с жизнеспособностью. Если стандарт представляется слишком ограничительным, то история показала, что инновации будут происходить снаружи и снаружи группы. Иногда творчество будет следовать общему направлению API и / или протокола. Иногда некоторые поставщики просто платят за услугу стандарту, потому что, несмотря на то, что он существует, стандарт слишком слаб или просто не поддерживает совершенно новую концепцию.

Поэтому стандарты не могут быть использованы для ограничения творчества. Тем не менее, они могут помочь обеспечить совместимость.

Меч с двумя лезвиями

Креативность также является мечом с двойным лезвием, она может быть разумным местом для добавления API-интерфейсов конкретных поставщиков в стандарт. Например

В Java EE есть несколько спорных вопросов со стандартом. Я назову лишь несколько тем для обсуждения:

Безопасность — текущая безопасность Java EE не является достаточной для многих корпоративных нужд, поэтому ваш пробег на самом деле меняется. Существует несколько решений, таких как Spring Security, Apache Shiro и API для конкретных поставщиков. Стоит также отметить, что не существует такого понятия, как единый вход в стандарт API для Java EE.

Embedded Container — нет стандартного API для запуска для создания так называемого безконтейнерного приложения. Некоторые люди называют эту концепцию uber-jar или uber-war, а некоторые называют этот модульный сервер приложений и приложений. Все люди согласны с тем, что встроенный сервер внутри концепции приложения превращает обычное развертывание файла WAR в сервер приложений с ног на голову. Стоит также отметить, что инструменты для этой концепции от основных IDE находятся в зачаточном состоянии.

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

Развертывание, Администрирование и Облако — нет единого мнения о том, как развертывать в среде облачных сервисов. Это реальность даже в 2016 году, потому что облачные технологии находятся в быстром темпе и в постоянном движении.

предпринимательство

Давайте вернемся к началу сети. Возможно, каждый, кто работает в области цифровой разработки, дизайна и архитектуры, услышал об одном сэре Тиме Бернерс-Ли . Именно этот британский джентльмен создал первую реализацию Всемирной паутины и разработал вариант XML-документа под названием «Язык гипертекстовой разметки», а также протокол передачи гипертекста, известный как HTTP . Бернерс-Ли создал эту WWW, работая в крупном европейском научном концерне под названием CERN . (Как иронично, что я чертовски пишу этот текст в пятницу, 1 июля 2016 года ?! Примечание для BREXIT .) Мы можем утверждать, что наблюдатели утверждают, что его бывшие работодатели, CERN, заплатили за творчество и видение Тима, а также WWW.

Исходя из экспоненциального роста WWW в терминах глобальной торговли, торговли и сообщества, количество финансовой валюты достаточно для ЦЕРН, чтобы финансировать научные исследования в течение 2000 лет.

Исходя из стоимости сметных WWW, 2 триллиона фунтов стерлингов ( Quora ) и общих годовых затрат на эксплуатацию LHC 1 миллиард долларов США ( Forbes ).

Или ЦЕРН, имел бы часть этих денег, если бы лишил права интеллектуальной собственности (ПИС). Согласно Википедии определение IP относится к созданию прав, которые предоставляются для защиты от коммерческой конкуренции на интеллектуальные произведения, которые включают товарные знаки, авторские права, патенты, права на промышленные образцы и секреты.

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

Еще в то время, когда Стив Джобс носил галстук-бабочку и неожиданно получил лоботомию от корпорации Apple в Купертино, малоизвестный компьютерный специалист создал новое концептуальное приложение, уникальное для первых выпусков компьютеров Macintosh.

Билл Аткинсон — легендарный программист и дизайнер. Он работал в Apple с 1978 по 1990 год. Он несет полную ответственность за Quick Draw, базовую библиотеку UI для Macintosh, которая ознаменовала собой изменение ландшафта в области графических пользовательских интерфейсов. Он также создал первый пример библиотеки под названием MacPaint. Билл Аткинсон также создал HyperCard , которая была предшественником стекируемой всемирной паутины. На самом деле Бернерс-Ли использовал HyperCard в качестве источника вдохновения. Принципиальной особенностью HyperCard была возможность перемещаться с карты на карту одним щелчком мыши по текстовому элементу.

Дело в том, что HyperCard, хотя и предшествовал WWW и тому, что мы знаем, был коммерческим приложением, потому что потребители платили свои с трудом заработанные деньги за привилегию его использования. В 1987 году не было никакого freemium или почти никакой «облегченной версии» коммерческих продуктов. Никто даже не слышал об этом маркетинговом меме, потому что в этом не было необходимости. Мы жили в мире, те из нас, кто помнит и кто был жив на данный момент, не могли понять смысл этой бизнес-модели. Мы полагались на кассету, дискеты и там, если у вас был доступ к подключенной сети, она называлась Ethernet, вероятно, она называлась Token Ring.

Что Бернерс-Ли сделал со своим ребенком, WWW? Поскольку он работал в CERN и верил в научную модель общего доступа к информации, а также потому, что он хочет помочь своим конечным пользователям (UX), уважаемому и очень трудолюбивому ученому, он открыл своего ребенка. Не бесплатно, но передал ПИС WWW в то время существующему органу по технологическим стандартам. Сэр Тим, во-первых, предоставил Целевой группе по Интернету (30-летний орган) HTTP-документ для связи. Во-вторых, в 1994 году он помог основать Консорциум всемирной паутины (W3C), чтобы официально поручить стандарту HTML и другим частям, связанным с Интернетом. W3C является признанным органом по стандартизации.

Так что да! Без этого предоставления ПИС организациям, стандартным органам наш взгляд на мир выглядел бы бы по-другому по сравнению с цифровым миром, в котором мы живем сегодня.

С органом по стандартизации, поэтому IP предоставляется, разрешается и сохраняется.

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

Возьмите историю JavaScript, который является языком программирования, который был создан и прототипирован за несколько ночей одним исключительно ярким, противоречивым и политически некорректным Бренданом Айчем в его бывшем работодателе, Netscape Communications . Полная история JavaScript и его удивительное невероятное влияние должны быть оставлены еще на один день вне этой статьи, потому что я хочу привлечь ваше драгоценное внимание к битве, с которой Netscape Communication столкнулась с корпорацией Microsoft, а также к тому, что Брендан Айх сыграл огромную роль. в творчестве сделать JavaScript стандартом.

Все в возрасте старше 30 лет, вероятно, помнят свои первые впечатления от веб-браузера Netscape, законного предка Mozilla Firefox. Браузер Netscape был продуктом некоего Марка Андреессена в 1995 году, и он также использовал пробел на рынке и возможности, два основных компонента в бизнесе. Публичный доступ к Интернету внезапно стал чем-то особенным для классов белого вина, болтовни и сплетен, а также не было коммерческого веб-браузера, кроме очень академичного и выглядящего пешеходом веб-браузера NCSA .

В тот момент, когда Netscape Communications неожиданно запустился, не задумываясь о каламбурах, Microsoft, за которой охотился гигант на миллиард долларов. Была длительная корпоративная битва, в которой участвовали регуляторы, американский аналог антиконкурентной монопольной практики. Это тоже еще одна проблема, и дело в том, что Andreessen и, вероятно, Eich искали лучшую надежную защиту для защиты своего привлекательного продукта, Netscape, а также своего детского JavaScript-кода LiveE. Они боялись, что Microsoft подорвет свой приятный маленький динамический язык сценариев, поэтому они вместе с Sun Microsystems представили его международному частному финансируемому органу по стандартизации под названием ECMA International . Следовательно, сегодня у нас есть ECMAScript и стандарты вокруг JavaScript языка программирования.

Уничтожение конкурса

Microsoft использовала противоречивую бизнес-стратегию в первой части своей истории под названием Embrace, Extend, а затем Extinguish . Это была стратегия, на которую опирался Билл Гейтс, и которую Стив Балмер придерживался с 1975 по 2008 год. Она была очень актуальна для технологий, изобретенных более мелкими конкурентами, включая Java, JavaScript, Apple Windows и тело стандартов. Ключевой идеей было создание определенных расширений Microsoft для ключевой технологии и / или стандарта, а затем зависеть от доли рынка капитального ремонта, чтобы захватить и доминировать над маленьким игроком. В конце концов, убивая их полностью.

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

Наконец, давайте перейдем к теме инноваций.

новаторство

Инновация — это потерянная душа слова. Что на самом деле означает инновации? Чем он отличается от творчества?

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

В программном обеспечении мы не обязательно смотрим на инновации, лучшее, что мы видели в CAR Hoare , QuickSort , алгоритме или выраженном в виде CAP, и это алгоритмы. К сожалению, вы не можете просто продавать алгоритмы с шифрованием RSA и криптографические физические карты, такие как Oystercard, являющаяся исключением из этого правила.

Тем не менее, мы можем внедрять инновации в программных продуктах, библиотеках и инфраструктурах. Дело в том, что инновации лучше всего работают вне стандартного органа и опережают любые попытки стандартизировать решение. Тем не менее, программные инновации должны стоять на плечах гигантов. У нас есть идея НЕИЗБЫТОГО ЗДЕСЬ (NIH) или НЕ ПОВТОРЯТЬ СЕБЯ (СУХОЙ), которая наполняет всю отрасль как ужасная катастрофа. Если вы пишете свой собственный сервис транзакций с нуля или пытаетесь переписать операционную систему, то вам нужно быть исключительно талантливым и трудолюбивым. Линус Торвальдс кланяется. Инновации происходят через потребность, разочарование и усилия.

Когда у нас есть по крайней мере две аналогичные реализации инновации Java EE, тогда, возможно, и только тогда, мы должны подумать об организации JSR для нее, в противном случае мы будем делать те же ошибки, что и J2EE 1.0. Проблема с инновациями заключается в том, что они всегда находятся в состоянии изменения, откуда вы знаете, что вы вводили инновации в определенном пространстве? Когда ваше решение достаточно стабильно? Комфортно ли вам делиться своими правами с конкурентами? Как это повлияет на ваших клиентов, клиентов и вашу основную бизнес-модель? Если вы занимаетесь бизнесом, вам нужно знать ответы на все эти вопросы. Вероятно, очень понятно, почему так мало предприятий вовлечено в какой-либо процесс стандартизации из-за общего времени, усилий и энергии, чтобы внести свой вклад. Если бы вы работали над задачами стандартизации, вы бы наверняка спросили о наиболее вероятной окупаемости инвестиций. Такое противоречие между инновациями, прибылью и убытками и тем, чтобы быть хорошим гражданином в органе по стандартизации, никогда не будет легко решить.

Вывод

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

Теперь должно быть ясно, что вы не можете использовать орган по стандартизации или группу экспертов для инноваций. Поэтому не ожидайте увидеть инновации в экспертной группе по Java EE (или в любом другом органе по стандартизации: ECMA, W3C, IETF) в ближайшее время, потому что настоящие изобретатели, создатели и цифровые органы на самом деле не думают о теле стандартов, когда лампочка в их головах вдруг излучается блестящий свет. Они слишком заняты гонками впереди, чтобы первыми вывести этот инновационный продукт из рук в руки потребителей. Только когда они закончат, они оглянутся назад по своей траектории и историческому пути и поймут, что, возможно, им следовало бы стандартизировать части своей интеллектуальной собственности.

Java EE 8 Кризис и стандарты

Процесс сообщества Java — это стандартное тело для технологии Java, а не для инноваций. С точки зрения пуриста, некоторые могут сказать, что JCP просто предвзят, потому что Oracle поддерживает это в финансовом, политическом и социальном плане; и потому что Oracle является текущим управляющим всей платформы Java. На мой взгляд, JCP может придерживаться своего, потому что он установил процессы и подзаконные акты отдельно от Oracle. Также сторонние компании, такие как IBM, Red Hat, Azul и другие, внесли свой вклад в определение запросов спецификации Java. Таким образом, Oracle несет ответственность перед сообществом через JCP, а также за счет использования продуктов, услуг этих связанных предприятий. Разработчики обладают собственной силой, хотите верьте, хотите нет, если вы хотите кричать неодобрение о прогрессе Java EE 8, тогда вам следует взглянуть на Java EE Guardians и затем принять решение подписать петицию .