100% успехом это будет, когда будет показана экономическая эффективность. А без нее — для чего вся эта многоразовость?
Ну, в смысле, оно конечно летает, да. Оно получилось недорогое (хотя это еще вопрос открытый, стоимость выведение килограмма при первой успешной посадке была запредельно высока). Назвать это неудачей было бы сильным преувеличением, но и заявленные цели пока далеко не достигнуты.
Премодерация — это для лентяев типа меня, которым комментировать хочется, а статьи писать лениво или некогда.
>>куда вы собрались выкинуть (отделить) IT составляющую, с всеми ее BPMN, SOA и пр.?
>ИТ- в отдельный слой. Везде присутствует декомпозиция и абстрагирование одного слоя от другого,
Ну так ктож против декомпозиции? Вопрос только в одном — чтобы декомпозировать, особенно IT от остального, нужно формализовать на каком-то языке интерфейсы между уровнями. Мой опыт мне говорит, что скажем BPMN для этого годится плохо, и свои цели, как их декларируют, не достигает по ряду причин. Так что ждем на этот вопрос ответа дальше.
Знаете, я вот минусануть не могу, но честно говоря — плюсовать тут тоже не за что. Понятно что вы старались, но скажем прямо — читать сложно, и понять, что вы хотели донести, еще сложнее.
Ну так, просто для примера: совершенно не ясно осталось, куда вы собрались выкинуть (отделить) IT составляющую, с всеми ее BPMN, SOA и пр.? Сами по себе большинство перечисленных аббревиатур, методик и пр. гроша ломаного не стоят. Я совершенно не хочу сказать, что без BPMN никуда, наоборот — у подобных нотаций есть масса врожденных недостатков, от которых практически невозможно полностью избавиться.
Никуда без приложений — поэтому в идеале методика должна давать на выходе приложение. Никуда не уйти и без существующих приложений — поэтому нужно интегрироваться с уже написанным их зоопарком. Это реальная рутина, которая вполне способна погубить любой проект.
>А зачем в данных разнообразие типов?
Попробуйте написать проект, где вам нужны даты/timestamp, которых в json нет. Скорее всего ваше мнение изменится довольно быстро.
Целые тут ни при чем совершенно — речь про то, что те типы, которых в языке нет, очень сложно однозначно восстановить при разборе, потому что я JSON нет и метаданных для типа, в том числе. Т.е. без схемы вы не можете понять, это вам пришло число, или дата в виде количества миллисекунд от начала эпохи, пришла строка или опять же дата в формате ISO 8601.
Формализацию требований заказчика делают люди, и им свойственно ошибаться.
>А для внесения изменений есть свой формальный процесс.
Вот я лично для себя именно так и понял посыл данного текста — не нужно путать настоящие и формализованные цели. Если вы видите, что записанные на бумаге формальные требования противоречат в чем-то цели (которая обычно может сама быть записана в паре абзацев) — то самое время остановить реализацию этой формальной чепухи и запустить процесс внесения изменений.
Вот что никогда не следует делать — так это молча отступать от требований, просто потому что они видятся вам неполными.
Ну, согласитесь, что это лишь один фактор из многих. Причем непонятно какой по важности — зависит от жизненного цикла вашего проекта. И чрезвычайно сложно оцениваемый.
Ну вот вам реальный пример — был у меня проект, лет пять назад. UI — где-то на уровне вашего по сложности. Огромные формы, сложные зависимости, нетривиальные компоненты. В качестве одного из инструментов предлагался Flex. Аргументы против были именно в этом духе — технология мол не будет поддерживаться. Пять лет прошло. Тот проект давно в могиле — в том числе потому, что на выбранной другой технологии его просто не получилось сделать. Flex никуда не делся. А сколько javascript фреймворков за эти пять лет померли и были забыты?
>Я увидел что реакт — в продакшене на куче крутых сайтов. FB
Вы не представляете, как это местами смешно выглядит. Не, правда.
Я не про ваш выбор вовсе — я про аргументы типа, что «это в продакшн у FB». Я с трудом могу вспомнить более глючное, плохо продуманное, менее предсказуемое приложение, чем FB. И да, я не про компоненты вовсе, а просто о том, что FB в качестве примера для других — это мягко говоря не довод.
Кроме всего прочего, у вас действительно достаточно сложный UI, какого у FB не встретишь. И другие технологии в основе.
А вам с какой целью нужна эта классификация? Что вас в моих формулировках смущает?
Я вполне явные примеры приводил — вот если вы пишете интернет банк, как вы собрались делать его чисто серверным? Без логики и кода на клиенте, без ЭЦП на клиенте, без доступа к файлам клиента?
Когда в качестве примера того, к чему нужно стремиться, приводится почта, мне становится смешно. Это текст 2001 года? Так прошло уже лет 15, а покажите мне сегодня, хотя бы две нормальные реализации веб почты, где есть нормальное вменяемое шифрование end-to-end?
>Ну и последнее, веб-приложения должны быть менее уязвимы для вирусов. Если на терминале не запускается ничего, кроме браузера, меньше шансов получить вирус
Да-да. Слыхали. Опять же, сегодня в 2016 году это выглядит смешно. На сегодня браузер является как раз одной из основных дыр в системе безопасности любой ОС. Потому что практика показала, что чисто серверные приложения, без логики на клиенте, без javascript, java или flash, почти никому не нужны. А когда все это появляется — браузер становится плохо защищенным.
А может это вы читали невнимательно? У меня как раз создается (субъективное, разумеется, но вполне устойчивое впечатление), что он сплошь и рядом делает ненужные обобщения. А пытаясь критиковать альтернативные решения, допускает явные ляпы. Вот, обратите внимание:
>С приложением на сервере вы можете делать доработки почти так же, как в программе, которую вы пишете для себя. Вы >выпускаете версии как последовательность поэтапных изменений вместо внезапного большого взрыва. Обычно компания, >производящая десктопное ПО, может выпустить одну или две версии за год. Для Viaweb мы часто делали три-пять версий в день.
Что, простите? При чем тут сервер vs desktop? Во-первых, на сегодня это давно устарело, потому что многие вполне настольные приложения легко обновляются с любой частотой. А во-вторых, возможность выпуска версий часто и понемногу — вовсе не особенность серверных приложений. Это особенность бизнеса компании. Опять же — если вы гугль или yahoo, и выпускаете десять версий своего поисковика или карт в день — это никого не волнует, в первую очередь потому, что вы никому ничего не обязаны. Вы как раз и пишете «как для себя». Только это не ваше достижение ни разу, и хвастаться тут нечем.
Ничего крамольного про апплеты? Да он написал так, как будто серверные и клиент-серверные приложения взаимозаменяемы, и мы можем выбрать что захотим. Что совсем не так. Это и есть еще одно ненужное и неправильное обобщение.
История с практической стороны показала, что даже сейчас, в 2016, те вещи, которые я перечислил, вызывают большие проблемы при разработке в стандартной web-парадигме. А тогда реальных альтернатив не было вообще (если не считать flash).
>Грэм продвигает Server-based computing в противопоставление standalone приложениям
И при этом несет чушь о технологиях, которые знает плохо. Это его не извиняет ни разу. «Проще дойти до логического конца и запускать программы на сервере» — проще по сравнению с чем? Понимаете, если вы скажем гугль, и пишете поисковик — то вам и javascript-то не особо нужен. У вас серверное приложение by design.
А если вы банк, и вам скажем нужна на клиенте ЭЦП, то у вас и сегодня, 20 лет спустя, будет очень немного реальных альтернатив тем же апплетам.
Апплеты никогда не были легковесными сами по себе. Единственное, чем они отличаются от обычного приложения — это запуск в браузерной песочнице. С ограничениями в правах. И с загрузкой jar как правило с сервера — т.е. технология доставки клиенту обновлений кода такая же, как для клиентских javascript приложений.
Да, именно server-based или клиент-серверных (причем это не одно и тоже), а не серверных — и это тоже две большие разницы. Они работают только на клиенте. И совершенно не обязаны с сервером общаться.
standalone? Почему бы и нет? Не предназначены — но могут в таком виде вполне использоваться.
Вспомните, что речь примерно про 1995, и скажите себе честно — а что, где-то еще была нормальная интерактивная 2D графика? canvas не было, WebGL и SVG насколько я помню — тоже. И File API еще не появился. И web socket не было тоже. И webworker тоже не было — javascript программы только недавно стали многопоточными.
Поэтому апплеты были (да и сейчас еще в значительной степени остаются) единственным средством разработки во многих случаях: когда нужна графика, когда нужен доступ к файлам клиента, когда нужен доступ к clipboard, когда нужно например шифрование — потому что шифрование на javascript это нонсенс, особенно 20 лет назад. Почему клиент-банки во множестве на апплетах? Потому что шифрование и электронная подпись.
А теперь перечитайте фразу Грэма про апплеты, и вдумайтесь, чем он хвастает? Тем что клиент-серверных приложений у них не было, а были только серверные. Вот вы серьезно думаете, что это достижение? По-моему, это просто глупость.
>Java-апплеты рассматривались как технология, которую все будут использовать для разработки серверных приложений.
Апплеты всегда были, и рассматривались как технология разработки клиентских приложений. И только их. И кстати, в оригинале server-based, и это не тоже самое.
В том, что вы не можете писать нормальные функции. В том, что нет нормальной обработки ошибок. В том, что нет нормальных структур данных.
И это все совсем не к синтаксису претензии. Хотя он тоже тот еще… недавно у нас в проекте забыли кавычку где-то на 20 строке. Упало на строке 89, перед этим выполнив предыдущие 88. Шикарный синтаксис, который не защищает от пропуска закрывающей кавычки, не правда ли?
Чисто практический опыт показывает, что переписывание (там где это можно) с bash на нормальный язык, сокращает объем примерно в три раза, сохраняя или увеличивая читаемость кода. Да хоть на python или perl. Я пробовал на groovy. На что угодно — только не bash и это семейство (ksh в общем туда же, плюс-минус).
Прекрасно понимаю, что избавиться от всего добра, которое на нем написано, вряд ли возможно, тем не менее совершенно непонятно, ради чего его защищать? По сегодняшним меркам он архаичный весь, от и до.
Минуя печать? А что, по вашему книги в электронном виде пишутся быстрее? По-моему они уже все лет 20 как пишутся в текстовом процессоре. Безо всяких исключений. И время очевидно уходит именно на написание, а уж точно не на печать. Я думаю на нормальную книгу нужно хотя бы полгода.
Безалаберность? Да просто нормальные авторы понимают, что такого рода книги никому не нужны (я не говорю обо всех их видах). Их устаревание до момента выхода в свет всем очевидно. Реально живут только книги по продукту, которые пишутся и развиваются в виде wiki сразу, и обновляются постоянно. А печатную форму приобретают просто путем применения другого форматирования.
Узкопрофильные книги имеют свойство устаревать мгновенно. Обычно еще до выхода в свет. А типичный случай — когда в момент выхода книга описывает версию продукта, которой года три. По тем продуктам, на которых я лично сегодня работаю, одна книга вышла в 2010, а второе ее издание начато в 2015 — и не написано. Так вы какими книгами предлагаете пользоваться — не напечатанными (т.е. в сущности, все равно интернетом), или устаревшими лет на 5?
>И это работает! А 95% людей, услышав слово webservice, полезли бы в JEE.
Ну как бы вам сказать… вот то что вы так пишете, возникло вовсе не само по себе — а в результате обобщения опыта JavaEE. И более того, насколько я помню, JAX WS это часть именно JavaEE как спецификации. То что оно вообще (я тут про все фреймворки, а не только про JAX WS само собой) стало доступно отдельно — это именно результат развития спецификации и множества ее альтернативных реализаций. Причем развития многолетнего.
>к вам придет добрый дядя DBA и скажет, что все данные будут вот в этой одной БД, а БД будет в Житомире.
Если бы. Вы сначала напишете все в виде join из четырех таблиц, а потом придет тот же самый дядя, и скажет вам, что это будет четыре разные базы (хоста). За две недели до релиза. И это реальный случай, между прочим.
Ну, в смысле, оно конечно летает, да. Оно получилось недорогое (хотя это еще вопрос открытый, стоимость выведение килограмма при первой успешной посадке была запредельно высока). Назвать это неудачей было бы сильным преувеличением, но и заявленные цели пока далеко не достигнуты.
Впрочем, на фото кажется как раз бак. Так что в целом да, я как раз склонен думать, что это копоть.
>>куда вы собрались выкинуть (отделить) IT составляющую, с всеми ее BPMN, SOA и пр.?
>ИТ- в отдельный слой. Везде присутствует декомпозиция и абстрагирование одного слоя от другого,
Ну так ктож против декомпозиции? Вопрос только в одном — чтобы декомпозировать, особенно IT от остального, нужно формализовать на каком-то языке интерфейсы между уровнями. Мой опыт мне говорит, что скажем BPMN для этого годится плохо, и свои цели, как их декларируют, не достигает по ряду причин. Так что ждем на этот вопрос ответа дальше.
Ну так, просто для примера: совершенно не ясно осталось, куда вы собрались выкинуть (отделить) IT составляющую, с всеми ее BPMN, SOA и пр.? Сами по себе большинство перечисленных аббревиатур, методик и пр. гроша ломаного не стоят. Я совершенно не хочу сказать, что без BPMN никуда, наоборот — у подобных нотаций есть масса врожденных недостатков, от которых практически невозможно полностью избавиться.
Никуда без приложений — поэтому в идеале методика должна давать на выходе приложение. Никуда не уйти и без существующих приложений — поэтому нужно интегрироваться с уже написанным их зоопарком. Это реальная рутина, которая вполне способна погубить любой проект.
Попробуйте написать проект, где вам нужны даты/timestamp, которых в json нет. Скорее всего ваше мнение изменится довольно быстро.
Целые тут ни при чем совершенно — речь про то, что те типы, которых в языке нет, очень сложно однозначно восстановить при разборе, потому что я JSON нет и метаданных для типа, в том числе. Т.е. без схемы вы не можете понять, это вам пришло число, или дата в виде количества миллисекунд от начала эпохи, пришла строка или опять же дата в формате ISO 8601.
>А для внесения изменений есть свой формальный процесс.
Вот я лично для себя именно так и понял посыл данного текста — не нужно путать настоящие и формализованные цели. Если вы видите, что записанные на бумаге формальные требования противоречат в чем-то цели (которая обычно может сама быть записана в паре абзацев) — то самое время остановить реализацию этой формальной чепухи и запустить процесс внесения изменений.
Вот что никогда не следует делать — так это молча отступать от требований, просто потому что они видятся вам неполными.
Ну вот вам реальный пример — был у меня проект, лет пять назад. UI — где-то на уровне вашего по сложности. Огромные формы, сложные зависимости, нетривиальные компоненты. В качестве одного из инструментов предлагался Flex. Аргументы против были именно в этом духе — технология мол не будет поддерживаться. Пять лет прошло. Тот проект давно в могиле — в том числе потому, что на выбранной другой технологии его просто не получилось сделать. Flex никуда не делся. А сколько javascript фреймворков за эти пять лет померли и были забыты?
Вы не представляете, как это местами смешно выглядит. Не, правда.
Я не про ваш выбор вовсе — я про аргументы типа, что «это в продакшн у FB». Я с трудом могу вспомнить более глючное, плохо продуманное, менее предсказуемое приложение, чем FB. И да, я не про компоненты вовсе, а просто о том, что FB в качестве примера для других — это мягко говоря не довод.
Кроме всего прочего, у вас действительно достаточно сложный UI, какого у FB не встретишь. И другие технологии в основе.
Я вполне явные примеры приводил — вот если вы пишете интернет банк, как вы собрались делать его чисто серверным? Без логики и кода на клиенте, без ЭЦП на клиенте, без доступа к файлам клиента?
Когда в качестве примера того, к чему нужно стремиться, приводится почта, мне становится смешно. Это текст 2001 года? Так прошло уже лет 15, а покажите мне сегодня, хотя бы две нормальные реализации веб почты, где есть нормальное вменяемое шифрование end-to-end?
>Ну и последнее, веб-приложения должны быть менее уязвимы для вирусов. Если на терминале не запускается ничего, кроме браузера, меньше шансов получить вирус
Да-да. Слыхали. Опять же, сегодня в 2016 году это выглядит смешно. На сегодня браузер является как раз одной из основных дыр в системе безопасности любой ОС. Потому что практика показала, что чисто серверные приложения, без логики на клиенте, без javascript, java или flash, почти никому не нужны. А когда все это появляется — браузер становится плохо защищенным.
>С приложением на сервере вы можете делать доработки почти так же, как в программе, которую вы пишете для себя. Вы >выпускаете версии как последовательность поэтапных изменений вместо внезапного большого взрыва. Обычно компания, >производящая десктопное ПО, может выпустить одну или две версии за год. Для Viaweb мы часто делали три-пять версий в день.
Что, простите? При чем тут сервер vs desktop? Во-первых, на сегодня это давно устарело, потому что многие вполне настольные приложения легко обновляются с любой частотой. А во-вторых, возможность выпуска версий часто и понемногу — вовсе не особенность серверных приложений. Это особенность бизнеса компании. Опять же — если вы гугль или yahoo, и выпускаете десять версий своего поисковика или карт в день — это никого не волнует, в первую очередь потому, что вы никому ничего не обязаны. Вы как раз и пишете «как для себя». Только это не ваше достижение ни разу, и хвастаться тут нечем.
Ничего крамольного про апплеты? Да он написал так, как будто серверные и клиент-серверные приложения взаимозаменяемы, и мы можем выбрать что захотим. Что совсем не так. Это и есть еще одно ненужное и неправильное обобщение.
>Грэм продвигает Server-based computing в противопоставление standalone приложениям
И при этом несет чушь о технологиях, которые знает плохо. Это его не извиняет ни разу. «Проще дойти до логического конца и запускать программы на сервере» — проще по сравнению с чем? Понимаете, если вы скажем гугль, и пишете поисковик — то вам и javascript-то не особо нужен. У вас серверное приложение by design.
А если вы банк, и вам скажем нужна на клиенте ЭЦП, то у вас и сегодня, 20 лет спустя, будет очень немного реальных альтернатив тем же апплетам.
Да, именно server-based или клиент-серверных (причем это не одно и тоже), а не серверных — и это тоже две большие разницы. Они работают только на клиенте. И совершенно не обязаны с сервером общаться.
standalone? Почему бы и нет? Не предназначены — но могут в таком виде вполне использоваться.
Вспомните, что речь примерно про 1995, и скажите себе честно — а что, где-то еще была нормальная интерактивная 2D графика? canvas не было, WebGL и SVG насколько я помню — тоже. И File API еще не появился. И web socket не было тоже. И webworker тоже не было — javascript программы только недавно стали многопоточными.
Поэтому апплеты были (да и сейчас еще в значительной степени остаются) единственным средством разработки во многих случаях: когда нужна графика, когда нужен доступ к файлам клиента, когда нужен доступ к clipboard, когда нужно например шифрование — потому что шифрование на javascript это нонсенс, особенно 20 лет назад. Почему клиент-банки во множестве на апплетах? Потому что шифрование и электронная подпись.
А теперь перечитайте фразу Грэма про апплеты, и вдумайтесь, чем он хвастает? Тем что клиент-серверных приложений у них не было, а были только серверные. Вот вы серьезно думаете, что это достижение? По-моему, это просто глупость.
Апплеты всегда были, и рассматривались как технология разработки клиентских приложений. И только их. И кстати, в оригинале server-based, и это не тоже самое.
И это все совсем не к синтаксису претензии. Хотя он тоже тот еще… недавно у нас в проекте забыли кавычку где-то на 20 строке. Упало на строке 89, перед этим выполнив предыдущие 88. Шикарный синтаксис, который не защищает от пропуска закрывающей кавычки, не правда ли?
Чисто практический опыт показывает, что переписывание (там где это можно) с bash на нормальный язык, сокращает объем примерно в три раза, сохраняя или увеличивая читаемость кода. Да хоть на python или perl. Я пробовал на groovy. На что угодно — только не bash и это семейство (ksh в общем туда же, плюс-минус).
Прекрасно понимаю, что избавиться от всего добра, которое на нем написано, вряд ли возможно, тем не менее совершенно непонятно, ради чего его защищать? По сегодняшним меркам он архаичный весь, от и до.
Безалаберность? Да просто нормальные авторы понимают, что такого рода книги никому не нужны (я не говорю обо всех их видах). Их устаревание до момента выхода в свет всем очевидно. Реально живут только книги по продукту, которые пишутся и развиваются в виде wiki сразу, и обновляются постоянно. А печатную форму приобретают просто путем применения другого форматирования.
Ну как бы вам сказать… вот то что вы так пишете, возникло вовсе не само по себе — а в результате обобщения опыта JavaEE. И более того, насколько я помню, JAX WS это часть именно JavaEE как спецификации. То что оно вообще (я тут про все фреймворки, а не только про JAX WS само собой) стало доступно отдельно — это именно результат развития спецификации и множества ее альтернативных реализаций. Причем развития многолетнего.
Если бы. Вы сначала напишете все в виде join из четырех таблиц, а потом придет тот же самый дядя, и скажет вам, что это будет четыре разные базы (хоста). За две недели до релиза. И это реальный случай, между прочим.