Комментарии 210
создавать веб-приложения в классической Delphi-манере, посредством визуальных компонентов, причём, что является немаловажным, в большинстве случаев она полностью скрывает от разработчика всю клиентскую (браузерную) «кухню»
Когда я был молодой, лет этак 15 назад, в дистрибутиве Delphi уже был такой набор компонент. Назывался IntraWeb, поддерживался каким-то сторонним разработчиком. Он сейчас есть, или ушёл?
В Delphi 10.2 присутствует.
Дополню ответ выше. С Delphi поставляются различные редакции IntraWeb, обладающие разными возможностями:
- С Professional — Personal-редакция, в которой наиболее неприятное ограничение — 5 одновременных сессий.
- С Enterprise и выше — Standard с не такими критичными запретами.
Унигуй по составу компонент намного шире IntraWeb'а. Плюс в нём из коробки есть стендэлон сервер. Так же тремя дефайнами один и тот же код можно выполнить в виде standalone exe, isapi, или windows service. Опять же — в унигуе есть полноценный пак компонент для работы на мобильных устройствах, чего насколько я знаю нет в IntraWeb.
Стендэлон сервер, насколько я помню, и в IntraWeb есть, точнее, юзался тот, что в Indy. Но, помнится, стабильность IntraWeb меня огорчала. Как с этим в Унигуе дела обстоят? Спрашиваю больше из любопытства, т.к. последний проект на Delphi «ушёл» в прошлом году, но чем чёрт не шутит, вдруг что-то новое появится.
Как по мне создавать сайты на delphi дикость. Если хочется "компонентности", что-то похожее на перетащил в форму кнопку или текстбокс, то чем плох asp net? И не является ли delphi немножко устаревшим яп, а уж тем более для создания вебсайтов? Javascript фреймворки или php с этим прекрасно справляются и вроде возни поменьше да и специалистов много. Вот сможете ли вы найти программистов веб сайтов на delphi, да чтобы еще могли читать и разобрать чужой код? Мне кажется писать на delphi сайты является не очень разумным решением. Я конечно не критикую delphi и не имею ничего против, но как по мне он как бы уже устарел
Почему бы и нет, но если только "потому, что могу" (троллейбус.жпг) или сайт-визитку для персонального пользования.
А для реальных задач это катастрофа. Если уж на хорошо стандартизированных и более-менее популярных языках и фреймворках не пишут из оглядки на сложность поддержки и поиска специалистов в дальнейшем, то уж о Делфи и говорить нечего
Не читал, но осуждаю, как обычно. В реальных задачах очень удобно, на самом деле. Довольно сложное гуёвое приложение где-то около 50ти форм было за месяц целиком перенесено мною в веб и отлично там работает. Компоненты вылизанные, работать удобно. Поддержка автора компонент отличная. В комплекте все плюшки — собственно сама среда, отлаживать удобно + эврикалог для решения удалённых проблем. Работает вся делфёвая инфраструктура. В реальной жизни это очень удобно.
Просто «специалисты» мельчают, потому и сложно. Чем современнее язык/фреймворк, тем меньше извилин нужно на его использование, что обеспечивается уменьшением гибкости и увеличением прожорливости решения. Потому и получается, что Delphi — это уже сложно. Смешно.
Потому и получается, что Delphi — это уже сложно. Смешно.
Есть такое понятие, как «продуктивность». Измеряется не в строках кода программиста, а во времени, которое он потратит на решение задачи. Когда-то давно можно было без всяких оговорок утверждать, что если вам нужно десктопное приложение, тем более работающее с СУБД или интегрированное с чем-либо, то максимальную продуктивность вам даст как раз Delphi. Сейчас этого нет. Где-то в середине 2000-х я стал замечать, что конкурентные преимущества Delphi появились и на других платформах. А потом ещё хуже пошло. Какие-то типовые вещи в корпоративной разработке вроде «интеграции с Active Directory», «пул коннектов к БД», «клиент REST-сервиса», «пул асинхронных задач», которые в Delphi сделать, конечно же, можно, но для этого надо было или что-то написать, или что-то найти/установить/настроить/отдебажить, оказались, к примеру, в дотнете доступными «из коробки». И вышло так, что продуктивность разработки перешла к другим продуктам. Причем никаких объективных причин для этого как бы и нет, всего лишь нежелание у вендора развивать продукт. Всяко проще купить очередную свистоперделку у сторонней конторы, и добавить её в дистрибутив, нежели развивать стандартную библиотеку.
Верно, для всякой задачи сейчас можно подобрать свой оптимальный инструмент. В идеале, конечно, продуктивность важный параметр. Но ведь идеала не бывает. Если уже привязан к Delphi, то логично будет, пускай, даже тратить время на освоение чего то нового, но не плодить лишнего. В конечном итоге продуктивность определяется не только инструментом, но и специалистом его использующим. Поэтому однозначно заявлять, что Delphi устарел, уж точно нельзя.
«Устарел» тут просто неправильный термин. Скорее, «потерял актуальность». На нём можно тянуть легаси-проекты, которые ещё, может быть, проживут не одно десятилетие. Но начинать что-то новое лично я бы не стал. Хотя бы из тех соображений, что непонятно, где я буду брать других специалистов на развитие/поддержку проекта.
Да, это уже ближе к реальности. В силу своей немодности новых адептов просто нет, все предпочитают хвататься за что-нибудь новенькое. Это болезнь отрасли, которую создают малограмотные HR пишущие в требованиях вакансий что-то вроде «опыт работы с языком X от 3 лет», когда этот самый язык только вышел. Спрашивается, зачем он им? А потому что модное новьё… печально.
Что-то упустил, что новенького появилось за последние 3 года?
Это был пример. Точка отсчета относительна. В свое время, когда только появился C# именно такие требования и встречались в вакансиях. Работодатель еще даже не знал зачем ему это, но просил. Вплоть до абсурда с физически не существующими сроками опыта. Таким образом и задавался тренд, в который вливались большинство новичков.
В свое время, когда только появился C# именно такие требования и встречались в вакансиях. Работодатель еще даже не знал зачем ему это, но просил.
А че, приятно же считать себя умнее других.
Работодатели идиоты, да?
Мало ли чего написано в тех вакансиях?
1) Это всего лишь мечты работодателей.
2) Далеко не всегда вакансии проходят вычитку у технических специалистов.
3) Понимать «три года опыта C#» тогда, когда ему самому было только 3 года следует так — «Три года опыта разработки (конкретный язык мало важен). Точка. Знание языка С#»
Не надо домыслов и вымыслов. Как говорится, что написано пером, то не вырубишь топором. А написано было именно про опыт разработки на конкретном языке. И суть этого была в том, что работодатель (во всяком случае тот, кто ответственен за найм) все-таки идиот, т.к. пишет абсурдные требования и хочет технологию, пользу которой еще даже не в состоянии оценить (т.е она ему может и нафиг то не нужна). Как следствие неокрепшие умы видят именно эти вакансии, где кругом сплошное новьё, на которое они и ориентируются в итоге. Соответственно появиться поддержке существующим технологиям и языкам уже существенно сложнее.
И суть этого была в том, что работодатель (во всяком случае тот, кто ответственен за найм) все-таки идиот, т.к. пишет абсурдные требования и хочет технологию, пользу которой еще даже не в состоянии оценить (т.е она ему может и нафиг то не нужна)
Еще раз:
1) Вам приятно считать других людей идиотами. Это кое что о вас говорит.
2) Не нужно ассоциировать отдельных исполнителей большой конторы со всей конторой. Пример объявления — банальный «испорченный телефон».
В смысле зачем? Microsoft же толкал новую революционную технологию. Спольски как то написал У Microsoft поехала крыша
Хотя бы из тех соображений, что непонятно, где я буду брать других специалистов на развитие/поддержку проекта.
Да там же где и обычно.
Разработчики, глубоко разбирающиеся в технологии Х — огромная редкость и стоят дорого.
Потому все согласные на новичков, да на переучившихся.
В конце концов ничего такого сверхуникального в Дельфи нет. Это не Хаскель — любой программист с опытом освоит быстро.
Да в том-то и дело, что не так всё радужно. Любой программист освоит быстро, но далеко не любой захочет на это тратить своё время. Программисты с опытом ведь не хватаются за любую работу подряд, а тоже выбирают, в каком направлении им развиваться, и что изучать. Исходя и из своих дальнейших перспектив на рынке труда, и просто из интересности/новизны платформы. Delphi им в этом плане сейчас мало что может предложить.
Любой программист освоит быстро, но далеко не любой захочет на это тратить своё время
Ну вот не надо сказок рассказывать. Что, мол, подавляющее большинство программеров занимаются только тем, что им интересно, а ходит на работу вовсе не за деньгами.
Да, лучшие могут выбирать где и над чем работать. Но основная серая масса — работает там, где им платят. Особенно при нынешнем переизбытке на рынке «войти-в-айтишников».
Ничего такого сложного и доступного только сверхъчеловекам в Pascal нет. То же JavaScript и обилие модных фреймворков под него — и то более сумбурно и сложнее для изучения.
А если исходить из-того, что использовать следует только самые распространенные технологии, то тогда мы бы сейчас все ПО разрабатывали только с помощью PHP.
Ну так что дозволено Юпитеру, то не дозволено быку. Если вы предложите кому-то из подавляющего большинства программеров изучить новую перспективную платформу (с работой на этой платформе в придачу), то конечно же, он вряд ли откажется. Но эта схема совершенно не прокатывает с Delphi. Вакансий немного, спрос потихоньку сокращается, рынок софта большей частью — поддержка систем, обычно написанных под внутренние нужны предприятий (очень редко что-то для внешнего энтерпрайза), зарплаты ничем выдающимся не блещут, следующая работа будет скорее всего на другой платформе.
Разве не так? И какой смысл тогда выкидывать несколько лет жизни на приобретение опыта, который более нигде не пригодится? Только потому, что поленился поискать другую работу?
Абсолютно ничего. Но зато есть тонны рутинной библиотечной жвачки с четвертьвековым легаси. Знаете, это куда сильнее отпугивает, нежели сложности.
Разве не так? И какой смысл тогда выкидывать несколько лет жизни на приобретение опыта, который более нигде не пригодится? Только потому, что поленился поискать другую работу?
Ничего такого сложного и доступного только сверхъчеловекам в Pascal нет.
Абсолютно ничего. Но зато есть тонны рутинной библиотечной жвачки с четвертьвековым легаси. Знаете, это куда сильнее отпугивает, нежели сложности.
И какой смысл тогда выкидывать несколько лет жизни на приобретение опыта, который более нигде не пригодится? Только потому, что поленился поискать другую работу?
В мире веба закладываться на какую-то технологию сложнее в сто крат. Пока успел более-менее изучить один фреймворк/технологию — вышло 5 новых. И ты уже легаси-программист.
Я же профессионально пишу на делфи уже 16-й год. Весьма успешно. Вот — уже и до веба добрался :) В пределах одного языка/среды.
Абсолютно ничего. Но зато есть тонны рутинной библиотечной жвачки с четвертьвековым легаси. Знаете, это куда сильнее отпугивает, нежели сложности.Как обычно: не читал, но осуждаю. Вы себе несколько плохо представляете состояние библиотек Delphi.
В мире веба закладываться на какую-то технологию сложнее в сто крат
Вы ошибаетесь. В мире веба есть стабильные платформы, которые уже давно заняли свою нишу и развиваются экстенсивно. Вам совсем не обязательно разгребать авгиевы конюшни npm, чтобы быть актуальным веб-разработчиком. Вы можете работать с ASP.NET MVC, можете быть Angular/React-разработчиком, и оставаться в тренде без крутых поворотов каждый год.
Как обычно: не читал, но осуждаю. Вы себе несколько плохо представляете состояние библиотек Delphi.
Я пришел в мир Delphi в 1997-м году. Писал на нём все, что можно
— от кастомных DB-aware компонент до расширений PHP. Писал эксперты, высоконагруженную систему клиент-банк и т.д. Последний проект закончил поддерживать в 2015-м. Возможно, там за эти три года всё радикально поменялось, и я отстал от жизни. Но мне почему-то кажется, что нет. И моё мнение про Delphi всё-таки вполне адекватное :)
И вот это стоит почитать (огонь и движение):
russian.joelonsoftware.com/Articles/FireAndMotion.html
статья старая, но со временем стала еще более актуальна в разных сферах.
russian.joelonsoftware.com/Articles/FireAndMotion.html
статья старая, но со временем стала еще более актуальна в разных сферах.
Delphi на месте не стоит. Многое добавляется от версии к версии. Работа с REST точно появилась, остальным не интересовался.
Ох уж эти осторожные комментарии про то, что Делфи устарел! На Хабре так, да, одно неосторожное слово и тебя заминусуют (в карму причем) ярые сторонники… Но давайте быть честными — он безбожно устарел. Бескомпромиссно. Без оговорок. Когда-то был неплохой, а сейчас плохой. Для каждый задачи есть набор наиболее подходящих инструментов, и во всех потенциальных сферах применения у Делфи есть море более привлекательных аналогов, особенно для создания сайтов. Дайте уже старичку уйти…
Байка в тему. Когда я в 2010 году устроился на первую работу, то попал в отдел к замечательному и одаренному человеку, который к тому же отличный рассказчик. Очень запомнился одна его история — "Никогда в жизни не сидел на форумах. Только раз очень сильно понадобилось что-то спросить про ASM, форум был закрытый, пришлось зарегистрироваться, все сделал, зашёл, и тут хоп — вижу раздел про Делфи. Захожу туда, читаю пару тем, отвечаю в одну 'а что, на Делфи ещё пишут?' и тут же пожизненный бан. Все, больше форумами никогда не пользовался". Уважаемые господа, не будьте людьми с того форума! :)
Его не за Делфи забанили, а за оффтопик и разжигание флейма. Не будьте как тот одаренный человек, учитесь пользоваться форумами и другими тематическими сообществами.
Нормально всё с Delphi. Развитие идёт, не взирая на то, что его все 20 лет хоронят :) Активно лезет в веб. Пользоваться Унигуем на реальных приложениях очень удобно.
Интересно, за что минусят. Delphi реально активно развивается и догоняет время. Много всего там прикрутили. Даже компилить проекты можно не только под x86, а под MacOS/iOS с андроидом. Да, не все гладко, но это болячки роста. Главное, что он есть.
Слишком медленно догоняет, по сравнению с развитием, например, тех же С++/С#. А уж компилятор под мобильные платформы — я вообще не понимаю, как его использовать…
Основан на LLVM (прощай, скорость компиляции!), мало совместим с другими платформами (ARC- менеджер памяти, отсуствие тех же short strings)…
Основан на LLVM (прощай, скорость компиляции!), мало совместим с другими платформами (ARC- менеджер памяти, отсуствие тех же short strings)…
С интересом послушаю чем же именно он устарел и чем же он стал так уж плох…
Если вкратце:
И отдельно для ElectroGuard, про «развитие идет» — какую фичу и когда последний раз добавили в сам язык? Для сравнения в С# вкусности приходят каждые полгода\год, и даже слегка консервативная Java обновляется всего в пару раз реже.
А вообще все уже расписали до нас.
* Я знаю о чем Вы подумали — у С++ тоже нет. Но планируется! И С++ в широком кругу задач незаменим.
** В свое время проводил технические собеседования — очень грустный опыт. Даже у PHP-шников CS-бэкграунд лучше. Это не наезд на PHP — просто у него такой же низкий порог входа для создания какого-то сайта, какой и у Делфи для создания какого-то оконного приложения.
*** Насколько распространен SuperPascal не знаю, если расскажете — буду травить байки про это ввысокосветских беседах с коллегами.
- Нет менеджера пакетов* (если быть точным, то нет пакетов как таковых)
- Нет коллекций типа хэш-таблицы или деревьев в стандартной библиотеке (9 из 10 людей на вакансию Delphi разработчика** не слышали ни про какие коллекции, кроме массива и списка)
- Нет поддержки многопоточности в стандартной библиотеке (если хочется, то развлекаемся с WinAPI), а тем более в самом языке*** (Go, Erlang как пример)
- Громоздкий синтаксис (грузные begin end, странный и неудобный if then else, обязательная декларация переменных в начале функции и др.)
- Нет поддержки вендоров (всякие SonarQube, CheckMarx, PVS Studio и прочие вещи из этого ряда никогда не появятся для Делфи)
- Нет нормальных IDE (собственно, выбора нет, есть только RAD Studio, и она объективно устарела, имеет интерфейс из 90-ых, постоянно валится)
- В конце концов в языке нет никакой киллер фичи, в которой бы он превосходил какой-то другой язык и был бы из-за этого ценнен. Свойства и события с апгрейдом переехали в C#. По скорости его превосходит С++. И так далее, по свойству X его превосходит язык Y.
И отдельно для ElectroGuard, про «развитие идет» — какую фичу и когда последний раз добавили в сам язык? Для сравнения в С# вкусности приходят каждые полгода\год, и даже слегка консервативная Java обновляется всего в пару раз реже.
А вообще все уже расписали до нас.
* Я знаю о чем Вы подумали — у С++ тоже нет. Но планируется! И С++ в широком кругу задач незаменим.
** В свое время проводил технические собеседования — очень грустный опыт. Даже у PHP-шников CS-бэкграунд лучше. Это не наезд на PHP — просто у него такой же низкий порог входа для создания какого-то сайта, какой и у Делфи для создания какого-то оконного приложения.
*** Насколько распространен SuperPascal не знаю, если расскажете — буду травить байки про это в
Нет менеджера пакетов* (если быть точным, то нет пакетов как таковых)Уточните, о каких пакетах речь?
Нет коллекций типа хэш-таблицы или деревьев в стандартной библиотекеTDictionary<TKey, TValue>
Нет поддержки многопоточности в стандартной библиотекеTParallel
Громоздкий синтаксисСинтаксис сильно повышает читаемость (уменьшая заодно число ошибок). Удобно и ничего лишнего.
PVS StudioКоторое появилось не от хорошей жизни. Процентов 70-80 ошибок, которые находит эта студия, просто невозможны в Delphi/Pas в принципе. В основном за счет более 'жесткого' синтаксиса.
Для остальных 20-30 процентов есть свои вполне удобные инструменты (FixInsight, например. Наша разработка, к слову).
Так же можно Paganz'у вспомнить:
www.softpedia.com/get/Programming/Other-Programming-Files/Pascal-Analyzer.shtml
Нет нормальных IDE (собственно, выбора нет, есть только RAD Studio, и она объективно устарела, имеет интерфейс из 90-ых, постоянно валится)1. Студия давно уже не в интерфейсе 90х.
2. Я работаю часто и много (XE6). Да, бывает падает. Раз в месяц, иногда реже. Врятли это подходит под определение 'часто'.
3. Есть активно развивающийся плагин для IDEA: plugins.jetbrains.com/plugin/7340-i-pascal ну и, собственно, бесплатный Лазарус.
Свойства и события с апгрейдом переехали в C#. По скорости его превосходит С++Но в шарп не перехала нативность, к сожалению. Также он использует GC. Который далеко не всегда удобен. Плюсы минимально по скорости быстрее, однако возможностей выстрелить себе в ногу на порядок больше.
какую фичу и когда последний раз добавили в сам язык?А каких фич в самом языке не хватает?
Для сравнения в С# вкусности приходят каждые полгода\годКакие вкусности пришли в Шарп за последнее время?
НЛО прилетело и опубликовало эту надпись здесь
Некоторые вещи имеют сомнительную ценность и слишком частное применение.
Многое же из перечисленного уже есть в Delphi, подтянули Шарп, молодцы, что сказать :)
Многое же из перечисленного уже есть в Delphi, подтянули Шарп, молодцы, что сказать :)
Delphi как-то больше в последнее время над платформами работает:
community.embarcadero.com/article/16563-rad-studio-roadmap-september-2017
community.embarcadero.com/article/16563-rad-studio-roadmap-september-2017
К слову, пробежало. Ссылки фич по версиям:
stackoverflow.com/questions/8460037/list-of-delphi-language-features-and-version-in-which-they-were-introduced-depre/8460108#8460108
Много всего. Смотрите.
stackoverflow.com/questions/8460037/list-of-delphi-language-features-and-version-in-which-they-were-introduced-depre/8460108#8460108
Много всего. Смотрите.
Честно, разочарован. Ожидал чего то большего и значимого.
В общем, детский сад какой-то. Ждал чего то более серьезного. Странные вам попадались делфисты, если сравниваете с PHP-шниками. Не надо судить о языке программирования, если плохо его знаете и встречали только «специалистов» по формошлепству. Delphi продолжает развиваться. Почитайте про линейку XE — там вкусняшки и догоняшки вполне есть. Похоже вы просто знаете и понимаете слишком мало о Delphi, чтобы его адекватно оценивать. Уровень программиста от средств разработки не зависит, он на чем угодно будет делать конфетку. Зато большинству «кодеров» ничего не поможет — насмотрелся.
На сколько помню, в том же C# в свое время очень удивился, когда вдруг в таком современном языке не оказалось средств доступа к SFTP/FTPS и прочему из коробки.
Та же Java — один большой костыль. Чего только стоила до относительно недавнего момента работа с временем, а ведь многие проекты так и будут сидеть на семерке.
- Менеджер пакетов — Уже есть, в последних версиях. Хотя как то жилось и без него.
- Коллекции — Спокойно можно жить и без них. Пишу ныне на Java и особого экстаза при использовании HashMap не испытываю, скорее наоборот.
- Многопоточность — Есть, класс TThread.
- Громоздкий синтаксис — Вы серьезно? Умрете, если напишете begin/end вместо {}? Беда...
- Обязательная декларация переменных в начале функции — Это наоборот огроменный плюс, который учит порядку и правильному мышлению, вместо того чтобы гадить созданием переменных посреди кода. Не будем опускаться до всяких PHP, VBS и прочих диалектов программирования «для бедных».
- Про поддержку вендоров с их примочками ничего не скажу, но тоже не видел ни одного страдающего делфиста.
- IDE не так уж и плоха, и да, та же IDEA мне нравится больше. Но писать качественный софт это никак не мешало.
- Сейчас нет ни единого языка с какими то киллер фичами, любая стоящая вещь превращается в некую парадигму и разлетается по всему миру разработки. Со скоростью тоже не все так однозначно. Забавно, что сравниваете с более древним и далеко не идеальным C++.
В общем, детский сад какой-то. Ждал чего то более серьезного. Странные вам попадались делфисты, если сравниваете с PHP-шниками. Не надо судить о языке программирования, если плохо его знаете и встречали только «специалистов» по формошлепству. Delphi продолжает развиваться. Почитайте про линейку XE — там вкусняшки и догоняшки вполне есть. Похоже вы просто знаете и понимаете слишком мало о Delphi, чтобы его адекватно оценивать. Уровень программиста от средств разработки не зависит, он на чем угодно будет делать конфетку. Зато большинству «кодеров» ничего не поможет — насмотрелся.
На сколько помню, в том же C# в свое время очень удивился, когда вдруг в таком современном языке не оказалось средств доступа к SFTP/FTPS и прочему из коробки.
Та же Java — один большой костыль. Чего только стоила до относительно недавнего момента работа с временем, а ведь многие проекты так и будут сидеть на семерке.
Замечено, общая беда хейтеров. Они остались примерно на уровне 7-го Делфи, которому, уже как бы 15 лет. Новых сред и всей инфраструктуры то и не видели. Обычно это странное какое-то зрелище. Time machine какой-то.
И даже древнюю семерку рано списывать в утиль, зависит от того кто «за рулем». Некоторые вот, как оказалось, от begin/end могут перетрудиться, да без всяких примочек становятся беспомощными :)
Основная проблема Delphi — её цена. Что толку от её фич, если она стоит 2.5 килобакса за редакцию Professional, и при этом от версии к версии дорожает. Когда она вышла на рынок, она стоила $50, а в институты поступала бесплатно. С такой ценовой политикой у неё просто нет шанса получить приток новых пользователей.
Основная проблема Delphi — её цена. Что толку от её фич, если она стоит 2.5 килобакса за редакцию Professional, и при этом от версии к версии дорожает. Когда она вышла на рынок, она стоила $50, а в институты поступала бесплатно.
Вы с какой планеты будете? Марс что ли? Профешнал всегда стоил около тысячи +-. И раньше он меньше не стоил. И сейчас он больше не стоит. Ну и вузы имеют огромный дисконт, как и имели.
А что такое для бизнеса ну пусть даже тысяча за инструмент? Да ничто. Один раз купили и забыли. Мы на разработку в прошлом году потратили порядка 30 тысяч зелени. И мы то так, мелкая контора.
Опять же, не нравится прайс — есть Лазарус. Бесплатный совсем.
На той планете, где он стоил около тысячи, я был лет 10 назад. На нынешней планете, куда я сейчас приземлился, он стоит вот столько:
www.embarcadero.com/ru/app-development-tools-store/rad-studio
Первая версия, повторюсь, стоила $50, точнее, $49. Delphi 3, которая уже имела три редакции, если память меня не подводит, стоила вполне понятные $219 за версию Client-Server (из неё потом Architect вырос). В начале 2000-х за Проф уже просили $799, а тысячные цены появились где-то в середине нулевых. Он постоянно растёт в цене. Очевидно, Эмбаркадеро махнула рукой на расширение рынка, и просто пытается по-максимуму выдоить постоянно сужающийся круг богатых корпоративных клиентов. Пока они ещё есть.
Вы очень заблуждаетесь. Вы оцениваете инструмент с позиции «сколько он денег позволит заработать», а бизнес оценивает инструмент с позиции «какой из предлагаемых на рынке вариантов предпочтительнее». Видя несколько аналогичных по функционалу инструментов, бизнес не купит тот, который дороже, и при этом имеет меньший круг специалистов.
Кстати, про этих самых специалистов. Это вторая сторона медали. Чтобы бизнес рассматривал какой-то инструмент, у него должны быть в штате специалисты, которые с ним работали. А откуда берутся такие специалисты? Правильно, или с предыдущих проектов, или из институтов, или от самостоятельного изучения. Так вот, специалисты Delphi с предыдущих проектов — это уже преимущественно дяди «за 40», которых всё меньше и меньше, они уходят кто на пенсию, кто в менеджмент, а кто просто на другие платформы. А новые при такой ценовой политике вендора не появляются.
www.embarcadero.com/ru/app-development-tools-store/rad-studio
И раньше он меньше не стоил
Первая версия, повторюсь, стоила $50, точнее, $49. Delphi 3, которая уже имела три редакции, если память меня не подводит, стоила вполне понятные $219 за версию Client-Server (из неё потом Architect вырос). В начале 2000-х за Проф уже просили $799, а тысячные цены появились где-то в середине нулевых. Он постоянно растёт в цене. Очевидно, Эмбаркадеро махнула рукой на расширение рынка, и просто пытается по-максимуму выдоить постоянно сужающийся круг богатых корпоративных клиентов. Пока они ещё есть.
А что такое для бизнеса ну пусть даже тысяча за инструмент? Да ничто.
Вы очень заблуждаетесь. Вы оцениваете инструмент с позиции «сколько он денег позволит заработать», а бизнес оценивает инструмент с позиции «какой из предлагаемых на рынке вариантов предпочтительнее». Видя несколько аналогичных по функционалу инструментов, бизнес не купит тот, который дороже, и при этом имеет меньший круг специалистов.
Кстати, про этих самых специалистов. Это вторая сторона медали. Чтобы бизнес рассматривал какой-то инструмент, у него должны быть в штате специалисты, которые с ним работали. А откуда берутся такие специалисты? Правильно, или с предыдущих проектов, или из институтов, или от самостоятельного изучения. Так вот, специалисты Delphi с предыдущих проектов — это уже преимущественно дяди «за 40», которых всё меньше и меньше, они уходят кто на пенсию, кто в менеджмент, а кто просто на другие платформы. А новые при такой ценовой политике вендора не появляются.
allsoft.ru/software/vendors/embarcadero/delphi-10-2-tokio
87 999 рублей. Примерно 1300 зеленых. Да, незначительно подорожал. Был, когда мы покупали 1200 что ли. Зато мобильный пак включили, раньше был платный.
87 999 рублей. Примерно 1300 зеленых. Да, незначительно подорожал. Был, когда мы покупали 1200 что ли. Зато мобильный пак включили, раньше был платный.
Кстати, про этих самых специалистов.С учетом того, что порог вхождения минимальный, обычно (по своему опыту) люди за несколько месяцев вполне обучаются. Если, конечно, вообще к программированию пригодны.
87 999 рублей. Примерно 1300 зеленых
Я вам ссылку на RAD Studio привёл, это немного другой продукт :)
По поводу «немного подорожал», вот цены XE2, например: www.interface.ru/home.asp?artId=27079
За шесть лет в полтора раза подорожал.
С учетом того, что порог вхождения минимальный, обычно (по своему опыту) люди за несколько месяцев вполне обучаются
Поймите же, «несколько месяцев вполне обучаются» надо читать как «ваша задача будет решена на несколько месяцев позже, и с бОльшим количеством проблем, чем если бы вы взяли ту технологию, которая более распространена и известна».
Поэтому нет, новых клиентов с такой политикой Delphi приобрести не сможет, по крайней мере, таких, у которых есть хоть капля здравого смысла.
Я вам ссылку на RAD Studio привёл, это немного другой продукт :)Всё верно. Но я же говорил про Delphi :) Указанного продукта вполне достаточно для разработки.
Поймите же, «несколько месяцев вполне обучаются» надо читать как «ваша задача будет решена на несколько месяцев позже, и с бОльшим количеством проблем, чем если бы вы взяли ту технологию, которая более распространена и известна».1. Любого человека нужно вводить в курс дела. Я не верю в то, что кто-то придёт и сразу сядет делать хоть сколько сложный проект. Врятли это будет быстрее месяца-двух. Заодно и в Делфае разберется, нет там сложностей, всё просто как пробка, в чем и прелесть среди остального.
2. Всё таки, люди, как правило, берутся на годы. Если где-то человека берут на несколько месяцев — то что-то в такой конторе не так. Либо текучка, либо смысла человека брать вообще не было — проще было на аутсорс отдать (что мы, к слову, достаточно активно практикуем в том числе)
Поэтому нет, новых клиентов с такой политикой Delphi приобрести не сможет, по крайней мере, таких, у которых есть хоть капля здравого смысла.Конечно, хочется что бы инструменты были дешевле, спорить глупо. Но они стоят разумных денег. И инструменты — далеко не единственные расходы при изготовлении ПО. И уж точно это не самые большие расходы. Ну может процентов 10 от общегодовых +-. И то расходы один раз лет на 5 (по опыту нашей компании, 16 лет). Мы до сих пор на XE6 сидим, и нам его достаточно. При том, что разработки ведутся очень активно. Опять же — есть возможность покупать обновления, не обязательно покупать каждый раз среду занова. Акции проводятся почти ежегодно. Мы по акциям два раза из трёх и обновляли. Недавно была акция, по которой можно было обновится с любой версии до последней по цене обновления (обычная практика у них — с трёх последних).
1. Любого человека нужно вводить в курс дела. Я не верю в то, что кто-то придёт и сразу сядет делать хоть сколько сложный проект.
Процесс ввода в дело человека, который имеет опыт работы с платформой, выглядит так:
1. Дать почитать техническое задание.
2. Назначить таски.
Я не шучу, именно так и есть. Т.е. человек приступает непосредственно к работе через пару дней.
А два-три месяца на изучение новой платформы — это очень дорого. Причем дорого не только в плане «несколько тысяч баксов зарплаты программисту на этапе обучения», и даже не столько. Эти два-три месяца обучения — это значит, продукт будет выпущен на два-три месяца позже. А это уже стоит намного дороже.
При этом, как я уже говорил, человека ещё и заинтересовать надо, чтобы он изучал малопопулярную платформу.
Заодно и в Делфае разберется, нет там сложностей, всё просто как пробка, в чем и прелесть среди остального.
Вы знаете, я тут с вами вообще никак не соглашусь. Delphi проста, если нужно заниматься кнопкокидательством на уровне джуниора. Для профессиональной разработки там надо знать очень и очень много. Когда-то я писал на Delphi и собственный набор DB-aware компонент, и эксперты для IDE, и много чего другого, поэтому знал её внутри очень хорошо. Нифига она не простая.
Случаи, конечно, всякие бывают. Мы у себя новичков за текущие проблемы не сажаем никогда. Наработки на будущее. Да и новичку, обычно, проще что-то новое полностью сделать, чем разбираться в имеющемся коде.
При этом, как я уже говорил, человека ещё и заинтересовать надо, чтобы он изучал малопопулярную платформу.Перейти с Delphi на тот же шарп — опять же — месяц — максимум. Как и наоборот, впрочем. Продукты весьма близкие, особенно с учетом того, что один человек их дизайнил изначально. Так что — можно договориться.
Нифига она не простая.Ну разве что если компоненты свои делать, тогда соглашусь. Но мы компоненты все покупаем. Пишется только то, что купить невозможно. Купить обычно получается существенно дешевле по деньгам. А по времени — то нечего и говорить. DB Aware у нас купленный как раз (UniDAC, DxGrid).
Перейти с Delphi на тот же шарп — опять же — месяц — максимум.
Да не так всё просто, на самом деле-то. Дело ведь не в языке и даже не стандартной библиотеке. Язык — это вообще несколько дней (на уровне пользования, а не свободного владения, конечно). Намного больше отличий в подходах. В Delphi, например, вы кастомный столбец к любому гриду добавляете, подвесив обработчики на события перерисовки. В дотнете вы должны унаследоваться от базового класса и переопределить поведение. Иначе устроен слой работы с данными. И таких нюансов, работающих по-разному, миллион.
Особая песня — фреймворки. Вам для работы надо же не голый шарп знать, а где его применять. Будьте добры, учите ASP.NET MVC, например. Так что месяц — это только для уровня «совсем джуниор».
DB Aware у нас купленный как раз
В моём случае на рынке не было DB Aware компонент, позволявших работать с DB2 AS/400 :)
Перейти с Delphi на тот же шарп — опять же — месяц — максимум.
Остаётся нераскрытым вопрос зачем нужен промежуточный этап, если можно сразу заняться более популярным на рынке труда шарпом. Прямо сейчас на hh.ru около 1 000 вакансий с упоминанием C# и чуть более сотни — с упоминанием Delphi. Вывод очевиден.
К тому же за месяц будет освоен только базовый синтаксис и крохотное подмножество стандартной библиотеки. Впереди месяцы набивания шишек, усвоения best practices и изучения стандартной библиотеки.
Переучить человека на другую платформу, тем более, если он её впервые видит — затратное дело. Delphi отличный инструмент для разработки софта и быстро там можно только формошлепству научиться. Большинство на этом и останавливается, совершенно не понимая что это лишь плюшка к самому языку, а не его суть. Язык мощный, позволяет написать что угодно. Соответственно, для глубокого изучения понадобятся годы. Потому брать человека с целью научить можно лишь в нескольких случаях. Либо это дешевый новичок с перспективой роста, либо просто классный разработчик, который окупит затраты на освоение инструмента своими скиллами. В остальных случаях, согласно здравому смыслу, возьмут того, от кого будет отдача сразу и кого проще заменить на рынке. Сам уже не могу рьяно защищать Delphi, хоть и проработал на ней много лет. Давно посматривал вокруг и, при первой возможности, как только очень удачно сошлись звезды, перешел на Java. Хоть и не совсем новичок, но быстро освоиться все равно не возможно. И дело не в синтаксисе, а в подходах к решению элементарных задач.
Важно понимать: изготовление ПО — это далеко не бесплатный процесс и недешевый. И цена собственно Delphi — это реально капля в море по сравнению с другими расходами. Если кто-то собирается производить ПО по-взрослому, а не на коленке на кухне — стоит быть готовым к расходам, даже если делать это будете не на Делфае. Делфай у нас тоже не единственный, хоть и главный, инструмент.
Не совсем все так, но, да, ценовая политика играет важную роль в популярности среды. Когда есть удобные и дружелюбные community версии для VS/IDEA очень сложно чем то заманить неофитов в мир Delphi/Pascal.
Если бы цена играла бы важную роль, то все бы перешли на open source решения.
Думаю, хватает людей, которые хотели бы иметь в своем личном распоряжении лицензию, но в итоге пользуются соответствующими версиями VS/IDEA. В итоге фан-база поддержки сообщества фактически отсутствует.
В мире около трёх миллионов зарегистрированных копий Delphi, ворованных, думаю, еще больше. Коммьюнити, конечно, не такое большое, как у той же Жавы, но уж точно не маленькое. Да и Лазарус добавляет фанов прилично, особенно в последнее время, когда он более-менее дорос до того состояния, когда на нём можно сделать что-то приличное. Бесплатный Стартер, опять же, можно вспомнить.
Можете посмотреть некоторые ресурсы:
freepascal.ru/forum
www.sql.ru/forum/delphi
www.cyberforum.ru/delphi
fire-monkey.ru
Народа, на самом деле, немало. Даже в рунете. В бурже то больше.
Можете посмотреть некоторые ресурсы:
freepascal.ru/forum
www.sql.ru/forum/delphi
www.cyberforum.ru/delphi
fire-monkey.ru
Народа, на самом деле, немало. Даже в рунете. В бурже то больше.
Не хочу обижать автора, но вы сами просто не сильно разобрались в языке. Я не знаю как дела сейчас, на Delphi что-то серьезное писал более 10 лет назад, когда это был еще Borland. Но могу сказать что Вы не правы, из личного опыта:
Типа пакетов там была реализация, помню закладки новых компонентов добавляли тремя кликами мышки, указываешь где лежат файлы bpl и вуаля.
Многопоточность тоже была чуть не с первой версии, хоть уже столько лет не писал, но помню что это делалось через thread, и помню страдания с синхронизацией через различные семофоры, пусть криво но он еще тогда 15 лет назад было.
Синтаксис не спорю. Но уже не помню названия, но еще в те годы появлялись плагины для IDE, и они сами практически за вас писали все эти конструкции, многие популярные сейчас редакторы думаю это взяли оттуда.
Насчет IDE это вы тоже зря. Покажите мне IDE 10 летней давности где так быстро готовился интерфейс приложения.
Киллер фичи, ну это уже дань моде. Когда пишешь более менее серьезное ПО, то стараешься использовать то что проверенно временем, что будет работать, а новая фича у которой потом вылезут баги и потом придется переделывать ПО и раскидывать по сотням серверов по всему миру, извините, когда пару раз наступаешь на такие грабли то ценишь стабильность.
Да и хорошим вещам фичи не нужны :) вон ложку придумали несколько тысяч лет назад, и все еще такая же.
П.С. Почитал переписку, что-то заностальгировал, погуглил и чуть глаз не выпал. Уже вышла 25 версия, я на 7 писал, и там просто ппц… компилится и под винду, и линух, и мак, и андройды с айфонами. Смотрю и уже прикручивают интернет-вещи, а это уже как-раз пик. И кучи различных интеграций, и киллерфич там тоже вагон и маленькая тележка. В общем вы батенька зря, этот язык как наш ВПК, да был забыт и отстал, но сейчас рвется вперед. Надо качнуть триалку и попробовать что-то себе на андройд запилить.
Типа пакетов там была реализация, помню закладки новых компонентов добавляли тремя кликами мышки, указываешь где лежат файлы bpl и вуаля.
Многопоточность тоже была чуть не с первой версии, хоть уже столько лет не писал, но помню что это делалось через thread, и помню страдания с синхронизацией через различные семофоры, пусть криво но он еще тогда 15 лет назад было.
Синтаксис не спорю. Но уже не помню названия, но еще в те годы появлялись плагины для IDE, и они сами практически за вас писали все эти конструкции, многие популярные сейчас редакторы думаю это взяли оттуда.
Насчет IDE это вы тоже зря. Покажите мне IDE 10 летней давности где так быстро готовился интерфейс приложения.
Киллер фичи, ну это уже дань моде. Когда пишешь более менее серьезное ПО, то стараешься использовать то что проверенно временем, что будет работать, а новая фича у которой потом вылезут баги и потом придется переделывать ПО и раскидывать по сотням серверов по всему миру, извините, когда пару раз наступаешь на такие грабли то ценишь стабильность.
Да и хорошим вещам фичи не нужны :) вон ложку придумали несколько тысяч лет назад, и все еще такая же.
П.С. Почитал переписку, что-то заностальгировал, погуглил и чуть глаз не выпал. Уже вышла 25 версия, я на 7 писал, и там просто ппц… компилится и под винду, и линух, и мак, и андройды с айфонами. Смотрю и уже прикручивают интернет-вещи, а это уже как-раз пик. И кучи различных интеграций, и киллерфич там тоже вагон и маленькая тележка. В общем вы батенька зря, этот язык как наш ВПК, да был забыт и отстал, но сейчас рвется вперед. Надо качнуть триалку и попробовать что-то себе на андройд запилить.
Подкину еще ссылку, возможно будет интересно.
Наши же ребята запилил новый фреймворк под мобинльники, FGX Native:
fire-monkey.ru/forum/177-fgx
Это кросс-плафторменный фрейворк поддерживающий нативные контролы на разных платформах. Пока что в разработке. Обещают в этом году выпустить.
Пока хейтеры занимаются хейтерством, люди зарабатывают деньги.
Наши же ребята запилил новый фреймворк под мобинльники, FGX Native:
fire-monkey.ru/forum/177-fgx
Это кросс-плафторменный фрейворк поддерживающий нативные контролы на разных платформах. Пока что в разработке. Обещают в этом году выпустить.
Пока хейтеры занимаются хейтерством, люди зарабатывают деньги.
Комментарий 2018 года, но он уже тогда не актуален. Я честно.
Менеджер пакетов:
- Есть встроенный менеджер пакетов и зависимостей, называется GetIt
- Пакеты в Делфи были ещё в те времена, когда другие только файлами с кодом перекидывались. Расширение пакетов - DPK. Полноценные паки с кодом.
- Помимо встроенного официального (и более строгого) GetIt, есть несколько сторонних менеджеров пакетов. Бери на свой вкус (например Boss).
Коллекции:
- Загляните в модуль стандартной библиотеки, который появился еще в 15-16 году, System.Generics.Collections (TDictionary<>, TList<>, TObjectList<>, TThreadList<>, TQueue<>, TStack<> и т.д.)
- Да тот же массив имеет дженерик TArray<>
Многопоточность:
- Загляните в модуль стандартной библиотеки System.Threading (TTask, TParallel, TThreadPool, TFuture, их I-представление и т.д.)
TTask.Run(
procedure
begin
//my async code
end);
Громоздкий синтаксис:
- Инлайн переменные, анонимные функции, дженерики, выведение типов
begin
var i := 12;
var i: Single := 0.2;
var f := function(Result := Random(10));
var n := f();
var Dict := TDictionary<string, integer>.Create;
Dict.Add('key', 123);
...
end;Дженерик методы сами могут определять тип и не нужно его указывать при их вызове.
Всё выше приведенное - кроссплатформенное.
"Нет поддержки вендоров":
- В Делфи имеются встроенные анализаторы
- Существование подобных сторонних инструментов результат того, что в других языках намного легче ошибиться, так что не надо перекладывать с больной головы на здоровую
Выбор среды:
- VSCode имеет плагин для работы с Делфи, только вы понимаете, что среда разработки RAD Studio предлагает инструменты, которые просто не возможно нормально повторить в независимых средах. Вы лишь выбираете редактор кода, а не среду. Много ли у C# выбора в средах? Вот решили вы создать на C# WinForms или WPF приложение. Где вы будете его делать? Правильно, только в VS.
- Вы давно видели среду разработки RAD Studio? Она ни чем не уступает VS. При всём при том, что VS и слизывал все наработки у RAD Studio (тогда ещё Borland Delphi).
- Среда разработки у меня запущена месяцами. И что-то совсем не валится. Что я делаю не так?
А теперь по внесённым в сам язык фичам:
1. Как уже упоминал - инлайн объявление, анонимные функции
2. Инлайн функции и процедуры
3. for var i := 0 to 10 do
4. for var Item in List do
5. Компиляция под Linux, MacOS, Android, iOS, поддержка M1
6. Бинарные числа x := %1001001
7. Разделение тысячных AMillion = 1_000_000
8. Инструкции AVX-512
9. Классовые конструкторы/деструкторы
10. Конструкторы/деструкторы записей
И так далее. Их много, очень много. Всё искать и сравнивать я просто устану.
Обновления выходят каждые четверть года.
Если Вы так хорошо знаете экосистему, то может и о минусах замолвите словечко? А то непонятно, почему технология не завоевала мир при таком обилии сильных сторон.
Минусы само-собой имеются. Но, в основном эти минусы касаются политики компании, а не самого языка.
Стоимость среды
Community версия среды появилась сравнительно недавно. И об этом мало кто знает. И эта версия совершенно не подходит для коммерческой разработки, хоть и не запрещает её.Мало потокобезопасных штатных инструментов
Конечно есть TThreadList, TThreadDictionary, но сильно не хватает потокобезопсаной кроссплатформенной системы сообщений .Проблемы с RTL
Существуют, как и в RTL любого языка баги или не 100% покрытие. Это решаемо со стороны разработчика, но хотелось бы, чтоб быстрее решалось на уровне среды. У языка и среды есть публичная Jira, где можно опубликовать проблему и её решат. Но приоритет её решения не подвластен разработчику.
Например, есть проблема с огромными текстурами в DirectX. DirectX не сразу скидывает из памяти не используемые текстуры, а Делфи не может на это повлиять (в данный момент). Конечно, это особенность DirectX, но из-за этого, я не могу выпустить в прод проект с 3D панорамами. Плюс ко всему, эта проблема имеется на Андроид, а там не DirectX подключается, а OpenGL ES, что странно. Но поведение одинаково.Нет веб-сокетов из коробки. Есть несколько сторонних решений, хороших и рабочих, но хорошо бы добавить это уже из коробки. На самом деле, не хватает обычных сокетов с SSL из коробки. Есть просто сокет, но для него нужна реализация SSL. Повторюсь, это лишь нет из коробки.
Конструкции языка
Есть анонимные функции, но не хватает краткой записи - лямбд.
Анонимные функции захватывают данные из внешних переменных только в момент их исполнения.
Т.е, если мы напишем вот такой код
for var i := 1 to 10 do
TTask.Run(
procedure
begin
Writeln(i);
end)То мы увидим в выводе примерно такой ответ (1, 1, 1, 3, 3, 3, 3, ...)
Потому что Таск может выполниться кода угодно и захват переменной будет в момент начала выполнения Таски. Это, конечно, понятно, но ты ждешь, что захватится значение i, а не переменная. Решается очень просто и даже лучше выглядит, но новичкам не очевидно.
Обучающий материал
В связи с тем, что язык потерял свою былую популярность, материала на русском языке сложнее найти. Видео, книги, вебинары имеются, но в основном на английском. Вебинары проходят и на русском (речь об официальных вебинарах), но намного реже.
А в целом, фатальных недостатков нет. Иначе, я бы и не использовал Делфи. А вот преимуществ и возможностей очень много. В особенности у кроссплатформенного фреймворка FMX:
- уникальная система стилизации
- шейдеры
- анимация
- поддержка skia
- 3D из коробки
- LiveBindings
- подход к управлению элементами и их содержимым
Об этом можно целую статью написать и не одну.
А вот преимуществ и возможностей очень много. В особенности у кроссплатформенного фреймворка FMX
Интересно было бы устроить опрос, сколько процентов дельфистов используют FMX.
А то субьективно у меня тоскливое ощущение, что все эти роскошества нафиг никому не нужны.
Новички всё равно на 100% уверены, что Дельфи устарел - хоть с FMX, хоть без. Старые дельфисты поддерживают уже написанный под VCL код и не хотят вдохновляться новыми, будем уж откровенны, свистоперделками типа "уникальной системы стилей", ради которых весь этот VCL-код нужно переписывать.
Ошибка Embarcadero в том, что они сделали ставку на новичков. Если бы выкинули свистоперделки и обеспечили максимальную совместимость с VCL, тогда от FMX было бы больше пользы.
А так получается, что даже пресловутую кроссплатформенность удобнее прикрутить через Freepascal.
Я им многие люди, из тг групп, в которых я состою пишут новые проекты на FMX. Многие используют FMX именно для создания мобильных приложений. Я же, использую FMX и там и там. Уже более года не создаю VCL-приложения. С того момента, на моём счету несколько проектов.
Например, просмотр 3D панорам, созданных нашей программой (вот она на VCL, писалась ещё до FMX)
Приложение для Android. Собрать можно и на iOS, но оно предназначено для больших планшетов, для компании LeroyMerlin.
Остальные проекты в основном являются частью основной программы. Т.е. я создаю динамическую библиотеку, подключаю к программе и встраиваю в неё новый интерфейс со всеми возможностями отрисовки интерфейса на GPU.
Из чата люди делают разные мониторинговые системы на Андроид, клиенты и прочие приложения для работников своей компании. Кто-то делает софт freeware. Есть несколько проектов игр. Например, Rise of Legions.
Но, конечно, большинство создают или поддерживают VCL приложения.
Ну и небольшую статистику я могу привести. У нас есть общий чат и чат конкретно по FMX. В общем чате 700+ человек, в чате по FMX 350+. Как правило, в FMX чате есть все, кто есть в основном чате, но не 100% по разным причинам.
По чатам аж половина - ну ОК, возможно я просто не в курсе, планшеты с Андроидом как-то прошли мимо.
Сейчас больше Линукс интересен, но для Линукса с GUI нужно ещё стороннее дополнение, и качество кодогенерации под вопросом. Все компиляторы кроме виндовых работают через LLVM, который в теории может хорошо оптимизировать, но я слышал, что в Дельфи LLVM работает с перманентным -O0, то есть без оптимизации. Хотя может быть эти слухи уже устарели.
Если покупать среду RAD Studio для корпоративной разработки, то возможность создавать графические приложения под Linux идут из коробки. Т.е. FMXLinux идёт в комплекте.
По LLVM, насколько мне известно делали оптимизации. Насколько масштабные, я точно не знаю. Можно порыться в анонсах выхода новых версий. Там часто пишут "LLVM optimization", но насколько масштабные, я, к сожалению, не в курсе.
Вон у Oxygene LLVM правильно прикручен:
https://talk.remobjects.com/t/some-interesting-performance-comparision-island-vs-delphi/24596
Хотя тест скорее неудачный - практического смысла в вычислении на этапе компиляции нет, но он показывает, что оптимизация в LLVM работает.
А по Дельфи/Линукс свежей информации нет, придётся видимо самому тестировать.
Нашёл тесты скорости Линуксового кода - действительно в 2 раза медленнее, правда это 2017 год:
https://helloacm.com/integer-performance-comparisons-of-delphi-win32-win64-and-linux64-for-singlemultithreading-counting-prime-number/
Ко всему этому можно добавить интеграцию питона в язык, а соответственно получение доступа ко всем его библиотекам. При чем интеграция имеется в обе стороны. Так же, можно в питоне использовать Делфи, как графический фреймворк, или как среду для исполнения тяжелого кода.
А asp.net заработает на каком-нибудь промышленном компе? Ну скажем на такой плате? А на такой?
Увы, все, что надежное — устарелое. А для производства — нужны именно надежные компы. Они все равно будут работать 15-20 лет, так что устарелость не важна. Ну будет в конце службы устарелость на 30 лет, а не на 20 — какая разница?
А вот производительность — важна. У меня самописный web-сервер на Delphi работал на 133 мегагерц плате (примерно второй пень). И свои задачи — он выполнял.
Увы, все, что надежное — устарелое. А для производства — нужны именно надежные компы. Они все равно будут работать 15-20 лет, так что устарелость не важна. Ну будет в конце службы устарелость на 30 лет, а не на 20 — какая разница?
А вот производительность — важна. У меня самописный web-сервер на Delphi работал на 133 мегагерц плате (примерно второй пень). И свои задачи — он выполнял.
А почему нет? .net core как бы на линуксах работает, в плане производительности проиграет слабо, разве что памяти желательно не очень мало.
А вот кидаться в крайности зачем? На второй железке вы прям тоже так запустите нормально сайт на делфях? Да и учитывая цены приведённых железок, заводить на них веб интерфейс, это некий бред. Надо всё же по назначению железо использовать, а никак не троллейбус из хлеба.
А вот кидаться в крайности зачем? На второй железке вы прям тоже так запустите нормально сайт на делфях? Да и учитывая цены приведённых железок, заводить на них веб интерфейс, это некий бред. Надо всё же по назначению железо использовать, а никак не троллейбус из хлеба.
Конечно запущу, раз на более слабой запустил. И не надо считать производственные задачи бредом. Да и цены на них небольшие, думаю, что всего 1-2 тысячи баксов, не более. То есть разработка связи сайта с железкой — намного дороже.
Вы просто не понимаете специфики производства. Ну как пример…
Береговой узел радиосвязи МЧС (ловит те самые сигналы SOS). Радиостанции у нас где? Правильно в вагончиках, поближе к антеннам. Вагончики без отопления, ибо радиостанции греются. Кондиционеры есть, но в жару не очень помогают. То есть бытовой комп в вагончике накроется через месяц-два.
С другой стороны, управление радиостанцией — по RS232. Плюс надо кое-какие аналоговые датчики на неё навесить. Так что далеко кабели от радиостанции не протянешь. Ну и ставится промышленные компы прямо в вагончик — по одному на радиостанцию. На компах — web-интерфейс на LAMP. И оператор получает возможность конторолировать радиостанции, не выходя из теплого помещения.
Цена удовольствия — процентов 5 от цены радиостанций без антенн. И намного меньше — если брать цену антенн, земельного участка и так далее. Зато — больше шансов, что ваш SOS услышат. А не пропустят из-за сбоя радиостанции.
И таких примеров, когда компы надо ставить там, где человеку некомфортно — вагоны.
А цена… Цену компа надо сравнивать с ценой той аварии, которую он предотвращает. Если на стане цена минутного сбоя — 40 тысяч долларов, то и сетевая карта Ethernеt-II (целых 2 мегабита по толстому коаксиалу) за 1000 долларов кажется весьма недорогой. Это 2001 год, бытовые сетевухи были по 10 баксов на 100 мегабит.
P.S. Чтобы было понятней -эта плата работала как горячий резерв с шансами предотвратить 1 аварию раз в 5 лет. Но все равно — это выгодно.
P.P.S. Там за месяц даже в бытовках выпадает из воздуха миллиметр металлической окалины. Так что бытовые платы — сдохнут быстро.
Вы просто не понимаете специфики производства. Ну как пример…
Береговой узел радиосвязи МЧС (ловит те самые сигналы SOS). Радиостанции у нас где? Правильно в вагончиках, поближе к антеннам. Вагончики без отопления, ибо радиостанции греются. Кондиционеры есть, но в жару не очень помогают. То есть бытовой комп в вагончике накроется через месяц-два.
С другой стороны, управление радиостанцией — по RS232. Плюс надо кое-какие аналоговые датчики на неё навесить. Так что далеко кабели от радиостанции не протянешь. Ну и ставится промышленные компы прямо в вагончик — по одному на радиостанцию. На компах — web-интерфейс на LAMP. И оператор получает возможность конторолировать радиостанции, не выходя из теплого помещения.
Цена удовольствия — процентов 5 от цены радиостанций без антенн. И намного меньше — если брать цену антенн, земельного участка и так далее. Зато — больше шансов, что ваш SOS услышат. А не пропустят из-за сбоя радиостанции.
И таких примеров, когда компы надо ставить там, где человеку некомфортно — вагоны.
А цена… Цену компа надо сравнивать с ценой той аварии, которую он предотвращает. Если на стане цена минутного сбоя — 40 тысяч долларов, то и сетевая карта Ethernеt-II (целых 2 мегабита по толстому коаксиалу) за 1000 долларов кажется весьма недорогой. Это 2001 год, бытовые сетевухи были по 10 баксов на 100 мегабит.
P.S. Чтобы было понятней -эта плата работала как горячий резерв с шансами предотвратить 1 аварию раз в 5 лет. Но все равно — это выгодно.
P.P.S. Там за месяц даже в бытовках выпадает из воздуха миллиметр металлической окалины. Так что бытовые платы — сдохнут быстро.
Конкретно для подобных ситуаций лучше уж делать UI в виде SPA, и никак не Server-Side. Со стороны backend — REST API. Это позволит сделать легко клиент не только в браузере, это позволит удобно работать с множеством эндпоинтов посредством одного приложения и т.д. А вот клепать серверный UI на делфях, это в данном случае выстрел себе в ногу.
Ну давайте спорить о вкусе устриц с теми, кто их ел.
Конкретно для подобных ситуаций лучше уж делать UI в виде SPA, и никак не Server-Side. Со стороны backend — REST API. Это позволит сделать легко клиент не только в браузере, это позволит удобно работать с множеством эндпоинтов посредством одного приложения и т.д. А вот клепать серверный UI на делфях, это в данном случае выстрел себе в ногу.
Ну вот только не SPA. Тогда уж классический Web 1.0.
Для производства такие вещи делаются раз и на десятки лет.
И никто там не обновляет браузеры и пр.
«Перезагрузить страницу в случае ошибки», что естественно для обычного веб-мира — неприемлимо для производства.
Вы предлагаете «модно, стильно, молодежно».
А требования то в производстве — ну просто совсем другие:
www.rootfront.com/article/178831/2011-04-12/processory-kosmicheskih-apparatov
На земном производстве, конечно, допустимо и пошустрее железо. Но в целом — промышленность предпочитает более простые, более «дубовые» основы для ИТ. Ибо производительности уже много лет как хватает.
А вот простой станка, обходящийся в десятки тысяч долларов в день — это уже серьезно.
Более дубовые, зато необслуживаемые решения. А не более стильные модные молодежные.
Ну и плюс это все мелкосерийное. А сделать плату под более современное (но ненужное под задачу) железо — просто дороже и больше подводных камней на помехи и пр. И чем тоньше дорожки, больше слоев и выше частоты — тем больше этих камней.
Так я и предлагаю облегчить используя REST API, именно железка, с высокими требованиями к надёжности оперирует только данными не зная про UI, максимум, так она отдаст статику (код приложения). А вот использовать UI как я понял уже можно и на обычном железе.
Моё предложение и строится на этих допущениях.
Моё предложение и строится на этих допущениях.
UI, разумеется, статика. Вы просто не понимаете, что delphi — это в первую очередь веб-сервер, а не вебсайт. Это очень быстрый и гибкий CGI, а не server based.
Ну как пример, что я делал. Приходит от клиента запрос на JPEG. Что может сделать обычный веб-сервер — или считать уже готовый JPEG с диска (куда приложение периодически его подкладывает) или отдать закэшированный в памяти. Максимум управления — время кэширования.
Что было сделано на дельфи. При приходе запроса на JPEG делается анализ — насколько изменились данные. Если сильно изменились — на лету генерится новый JPEG и отдается, если не сильно — смотрится загрузка проца — есть у нас резервы на генерацию или нет. Если почти совсем не поменялось — отдаем из кэша.
Ещё пример — увеличение FPS. Клиент нажимает на кнопочку, команда уходит на устройство, потом ответ устройства передается клиенту. Без дельфи — время реакции порядка 300мс… С дельфи — легко можно добиться 50 мс. А оператору для комфорта — надо чтобы было как на пульте железки, то есть меньше 100мс.
А вы сколько сделаете на 100Мгц сервере на 5-10 клиентов? Покажите ваши сайтики, померяем время реакции вашего REST API,
P.S. Да, под дельфи я понимаю и C++ Builder, ибо возможности у него те же.
Ну как пример, что я делал. Приходит от клиента запрос на JPEG. Что может сделать обычный веб-сервер — или считать уже готовый JPEG с диска (куда приложение периодически его подкладывает) или отдать закэшированный в памяти. Максимум управления — время кэширования.
Что было сделано на дельфи. При приходе запроса на JPEG делается анализ — насколько изменились данные. Если сильно изменились — на лету генерится новый JPEG и отдается, если не сильно — смотрится загрузка проца — есть у нас резервы на генерацию или нет. Если почти совсем не поменялось — отдаем из кэша.
Ещё пример — увеличение FPS. Клиент нажимает на кнопочку, команда уходит на устройство, потом ответ устройства передается клиенту. Без дельфи — время реакции порядка 300мс… С дельфи — легко можно добиться 50 мс. А оператору для комфорта — надо чтобы было как на пульте железки, то есть меньше 100мс.
А вы сколько сделаете на 100Мгц сервере на 5-10 клиентов? Покажите ваши сайтики, померяем время реакции вашего REST API,
P.S. Да, под дельфи я понимаю и C++ Builder, ибо возможности у него те же.
Мы для управления радиостанцией почти SPA сделали, только страница логина на PHP. А в остальном — все именно так. И сейчас для околоземной орбиты берем 100Мгц MIPS. Медленно — зато радиационно-стойко.
А на заводах — бывает похлеще космоса. Радиации нет, зато есть дыра в крыше, откуда льет дождь в 50 сантиметрах от контроллера. :-) И та же металлическая окаллина, миллиметр которой выпадает за месяц прямо из воздуха на все поверхности. Так что только безвентиляторные решения, иначе коротнет.
А на заводах — бывает похлеще космоса. Радиации нет, зато есть дыра в крыше, откуда льет дождь в 50 сантиметрах от контроллера. :-) И та же металлическая окаллина, миллиметр которой выпадает за месяц прямо из воздуха на все поверхности. Так что только безвентиляторные решения, иначе коротнет.
Пожалуйста, передайте вашему штатному телепату,/ что он ошибся чуть более, чем полностью. И вообще гоните этого шарлатана в шею.
Для начального понимания, рекомендую заглянуть в веб-админку собственного роутера и подумать, почему сделано так, а не иначе.
SPA — хорошая штука, но плохо совместима с ACS. Если мы встраиваем ACS в SPA, то есть шансы, что хакер проанализирует клиентское приложение/, изменит пару переменных и получит доступ. Поэтому проще (см. далее про REST) страницу входа сделать отдельно, на PHP. Ну и сам собой, что клиентский ACS — это профанация, ACS всегда должен быть серверным.
REST -хорошая штука, но избыточная для этой задачи. Поиграйтесь с админкой собственного роутера — какое состояние клиента сохраняется?Никакое. Только уровень доступа (про него уже решили, что его должен контролировать сервер) Наоборот, изменение состояния железки должно передаваться всем клиентам. Поэтому некий недоREST.
Ну тогда подумайте, почему контакт и фейсбук используют собственную архитектуру, а не обходятся стандартными средствами. А потом поймите, что 100 Мгц мелкая машинка на 5-10 клиентах — это как раз «highliad» в том смысле, что 100%C PU и 80% ОЗУ.
Для начального понимания, рекомендую заглянуть в веб-админку собственного роутера и подумать, почему сделано так, а не иначе.
SPA — хорошая штука, но плохо совместима с ACS. Если мы встраиваем ACS в SPA, то есть шансы, что хакер проанализирует клиентское приложение/, изменит пару переменных и получит доступ. Поэтому проще (см. далее про REST) страницу входа сделать отдельно, на PHP. Ну и сам собой, что клиентский ACS — это профанация, ACS всегда должен быть серверным.
REST -хорошая штука, но избыточная для этой задачи. Поиграйтесь с админкой собственного роутера — какое состояние клиента сохраняется?
А вот клепать серверный UI на делфях, это в данном случае выстрел себе в ногу.Наш штатный телепат мне подсказывает, что ни одного веб-сервера вы в жизни не написали. Только веб-сайты. Он прав?
Ну тогда подумайте, почему контакт и фейсбук используют собственную архитектуру, а не обходятся стандартными средствами. А потом поймите, что 100 Мгц мелкая машинка на 5-10 клиентах — это как раз «highliad» в том смысле, что 100%C PU и 80% ОЗУ.
Я так понимаю, с матчастью у вас не очень и с телепатией того хуже. Отвечу к одному посту. Да и что-то порёли у вас сравнения то, на чём сидите с пальцем.
CGI и Server-Based, ну как бы сказать, CGI выполняется на стороне клиента и в случае, если используется старый CGI, а не Fast CGI, то это будет очень тормозно, и тут не спасёт ничего, тут даже PHP с модулем для Apache будет быстрее. Ибо при использовании CGI на каждый запрос создаётся новый процесс, что совсем не быстро.
При чём тут вообще как отдаётся JPEG? Если хотите скорость, отдаёте голые данные для графика, подготовленные, ну сотню точек, берёте D3 и строите на стороне клиента. Для 100MHz железки это будет очень сильным облегчением.
REST API требует меньше ресурсов, т.к. нет оверхеда в виде генерации хтмл и очень сильно экономит трафик, ибо гоняет голые данные. Да HTML составит хакеру проблемы, он потратит целых пару минут своей жизни, чтобы написать регулярку, великая проблема. А авторизация вешается отлично и на REST API.
SPA приложение очень хорошо кэшируются браузерами и не надо каждый раз загружать весь код.
REST API поддерживать на слабых железках куда проще, уж доводилось и не нужно тут бычить, если сами не пробовали, не знаете и т.д. REST API никак не избыточен, избыточен классический UI, повторюсь, ибо придётся работать не только с данными, но еще и с оформлением.
Что такое веб-сервер и веб-сайт в вашем понимании? Мне вот именно приходилось заниматься разработкой сервера приложений своё мультиплексирование делать не стал ибо есть готовые решение, использовал boost::asio, при этом использовалась активно и атомарность. Приходилось делать модуль для nginx (выдача баннеров для баннерной системы), который спокойно обрабатывал сотни тысяч запросов в секунду на гружая проц на пару процентов от силы.
Highload оценивается не нагрузкой на проц и ОЗУ, а кол-вом одновременных подключений и скоростью ответа.
Если бы потратили то время, что потратили обкладывая меня, REST API и пытаясь показать свою крутость и удовлетворить своё ЧСВ, на чтение матчасти, провели бы время с большей пользой.
CGI и Server-Based, ну как бы сказать, CGI выполняется на стороне клиента и в случае, если используется старый CGI, а не Fast CGI, то это будет очень тормозно, и тут не спасёт ничего, тут даже PHP с модулем для Apache будет быстрее. Ибо при использовании CGI на каждый запрос создаётся новый процесс, что совсем не быстро.
При чём тут вообще как отдаётся JPEG? Если хотите скорость, отдаёте голые данные для графика, подготовленные, ну сотню точек, берёте D3 и строите на стороне клиента. Для 100MHz железки это будет очень сильным облегчением.
REST API требует меньше ресурсов, т.к. нет оверхеда в виде генерации хтмл и очень сильно экономит трафик, ибо гоняет голые данные. Да HTML составит хакеру проблемы, он потратит целых пару минут своей жизни, чтобы написать регулярку, великая проблема. А авторизация вешается отлично и на REST API.
SPA приложение очень хорошо кэшируются браузерами и не надо каждый раз загружать весь код.
REST API поддерживать на слабых железках куда проще, уж доводилось и не нужно тут бычить, если сами не пробовали, не знаете и т.д. REST API никак не избыточен, избыточен классический UI, повторюсь, ибо придётся работать не только с данными, но еще и с оформлением.
Что такое веб-сервер и веб-сайт в вашем понимании? Мне вот именно приходилось заниматься разработкой сервера приложений своё мультиплексирование делать не стал ибо есть готовые решение, использовал boost::asio, при этом использовалась активно и атомарность. Приходилось делать модуль для nginx (выдача баннеров для баннерной системы), который спокойно обрабатывал сотни тысяч запросов в секунду на гружая проц на пару процентов от силы.
Highload оценивается не нагрузкой на проц и ОЗУ, а кол-вом одновременных подключений и скоростью ответа.
Если бы потратили то время, что потратили обкладывая меня, REST API и пытаясь показать свою крутость и удовлетворить своё ЧСВ, на чтение матчасти, провели бы время с большей пользой.
CGI выполняется на стороне клиентаваш уровень знаний понятен. :-))
нет оверхеда в виде генерации хтмл и очень сильно экономит трафикТо есть десяток килобайт вас уже научили экономить? Это отрадно.
При чём тут вообще как отдаётся JPEG? Если хотите скорость, отдаёте голые данные для графика,Вероятно, это будет следующим этапом вашего обучения — научиться экономить сотни килобайт. Там до 604 800 точек, так что передача JPEG намного компактней.
Упс, опечатался, суть не в этом, да, на сервере.
На а дальше тролля кормить я не буду. Если же не так, мне вас жаль, о карьерном росте вам придётся забыть. Хотя если только среди равных.
На а дальше тролля кормить я не буду. Если же не так, мне вас жаль, о карьерном росте вам придётся забыть. Хотя если только среди равных.
Лихо вы комментарий изменили. :-)
Это отраслевой стандарт — передавать отклонения решений GPS/ГЛОНАСС в виде мишени за час/сутки/неделю. И самый компактный способ передачи — это как раз JPEG. Он — не сжимается архиваторами, то есть является локальным минимумом передаваемых данных. И по времени — отрисовать точки на картинке будет быстрее, чем сортировать их по координатам и исключать дубликаты.
Что касается карьеры — то она лежит совсем в другой области, чем рисование сайтиков. Потому за 35 лет работы и сайтиков было всего два, оба — специфические. И на обоих HTML/CSS/JS — делали фрилансеры. Правда мне потом пришлось их баги в JS править.
Мне другое интересно. Вы писали модуль и не поняли, какие преимущества дает самописный модуль? Или вы принципиально против fullsctack, когда один человек пишет всю систему?
Кайф от дельфи (C++ Builder) как раз в том, что весь backend пишется в рамках одного приложения на одном языке (delphi или С++). И только frontend отдается фрилансеру.
Это отраслевой стандарт — передавать отклонения решений GPS/ГЛОНАСС в виде мишени за час/сутки/неделю. И самый компактный способ передачи — это как раз JPEG. Он — не сжимается архиваторами, то есть является локальным минимумом передаваемых данных. И по времени — отрисовать точки на картинке будет быстрее, чем сортировать их по координатам и исключать дубликаты.
Что касается карьеры — то она лежит совсем в другой области, чем рисование сайтиков. Потому за 35 лет работы и сайтиков было всего два, оба — специфические. И на обоих HTML/CSS/JS — делали фрилансеры. Правда мне потом пришлось их баги в JS править.
Приходилось делать модуль для nginx
Мне другое интересно. Вы писали модуль и не поняли, какие преимущества дает самописный модуль? Или вы принципиально против fullsctack, когда один человек пишет всю систему?
Кайф от дельфи (C++ Builder) как раз в том, что весь backend пишется в рамках одного приложения на одном языке (delphi или С++). И только frontend отдается фрилансеру.
А если пользователь захочет увеличить масштаб и рассмотреть часть графика поподробнее?
В случае генерации картинки на сервере придется ее перестраивать заново с другими параметрами. А если передать сырые данные на клиент, то там можно будет перестраивать ее как угодно без лишних запросов.
А если пользователь захочет увеличить масштаб и рассмотреть часть графика поподробнее?На это есть ТЗ, подписанное заказчиком. Там и написано, что заказчик хочет, а что нет.
Мне, от подобного устройства хотелось бы совсем другого. Например, исключить из расчета спутники, попадающие в определенные сектора (исключение многолучевости) и пересчитать массив измерений за неделю.
А у заказчика — совсем иная задача. Когда судно в очередной раз сталкивается с опорами моста, а капитан все сваливает на «GPS лажает», ему надо разобраться — действительно ли были проблемы с GPS или капитан просто врет. Ну и вторая задача — если на самом деле «GPS врет» предупредить об этом суда на Неве, Онеге, Беломоре и Волго-Балте.
Собственно в этом и отличие интернетский сайтов от приборов с web-интерфейсом. У приборов — есть заказчик с заранее известными потребностями.
P.S. Самое забавное, что скриншоты с веб-интерфейса — важнее самого веб-интерфейса. Правильно заверенный скриншот — это аргумент в суде по УК 263 и иным статьям. А веб-интерфейс — всего лишь сырье для заверенных скриншотов.
P.P.S Для иного ТЗ — задача бы решалась иначе. На ином оборудовании, иными средствами. И возможно, что при ином ТЗ вы были бы правы.
Нотариально заверенный скриншот — это что-то из области интернет-мемов.
По-хорошему, разбор полетов начинается с поднятия логов на устройстве, интерфейс тут совершенно не при чем.
А зачем нотариально? Комиссия из трех человек выносит решение, что сбоев не было. Печати, подписи, скриншоты показаний прибора. В итоге это называется «заключение специалиста» (УПК 80 часть 3).
Про логи GPS — поржал. Вы хоть раз судовой приемонидикатор видели? Нету у него логов. Кстати, из соображений надежности нету — любая флэшка через пару лет сдыхает.
И вообще, судно — не самолет, черными ящиками обычно не оборудовано. Хотя один раз и черный ящик писали — но там специфическая задач была — найти, где и кому капитаны топливо сливали.
Про логи GPS — поржал. Вы хоть раз судовой приемонидикатор видели? Нету у него логов. Кстати, из соображений надежности нету — любая флэшка через пару лет сдыхает.
И вообще, судно — не самолет, черными ящиками обычно не оборудовано. Хотя один раз и черный ящик писали — но там специфическая задач была — найти, где и кому капитаны топливо сливали.
А у меня созрел встречный вопрос. А если заказчик подключит Windows 95 c IE 3, что будет с генерацией картинки на клиенте? Сумеете её под IE 3 сделать?
И это как раз более реальный сценарий. Комп сломался, заказчику на замену со склада выдали «мощный» ноут с Windows 95 борту — такое бывает.
Кстати, штатным браузером у заказчика был, если не путаю, IE 6 или IE 7. Дело лет 8-10 назад было.
И это как раз более реальный сценарий. Комп сломался, заказчику на замену со склада выдали «мощный» ноут с Windows 95 борту — такое бывает.
Кстати, штатным браузером у заказчика был, если не путаю, IE 6 или IE 7. Дело лет 8-10 назад было.
Интерфейс uniGUI тоже развалится на браузере IE6. На их сайте в поддерживаемых браузерах стоит IE9+.
Ну так не про uniGUI речь, а про веб-серверы на Delphi.
Если у вас там винтажная атмосфера, и пользователи заходят с устройств, у которых процессор слабее современной кофеварки, то, наверное, нужно делать как вы говорите.
А еще важно понимать, что такие требования очень редкие. Поэтому, преподносить их как норму, и советовать всем делать точно так же, не стоит.
Ну что значит редки? Обычные производственные требования. Как только вы уходите от бытовухи — так сразу встают вопросы надежности. Самолеты, корабли, космос, локомотивы, производство, военка — везде нужны надежные железки. А надежные — это срок службы 20 лет.
Так что железка 20летней давности, разработанная на технологиях 30летней давности — это норма.
Закройте глаза на бытовуху. И сразу увидите, что вокруг — вагоны такой техники. В доме, где вы живете лифт какого года разработки? А какой у него процессор?
P.S. А в кофеварке скорее всего что-то 4хбитное стоит (как в калькуляторах). Максимум — 8битное. Если знаете точно — дайте ссылочку.
Так что железка 20летней давности, разработанная на технологиях 30летней давности — это норма.
Закройте глаза на бытовуху. И сразу увидите, что вокруг — вагоны такой техники. В доме, где вы живете лифт какого года разработки? А какой у него процессор?
P.S. А в кофеварке скорее всего что-то 4хбитное стоит (как в калькуляторах). Максимум — 8битное. Если знаете точно — дайте ссылочку.
Просто все привыкли думать уровнем котиков в соцсетях.
В SpaceX используется Angular/ASP.NET — http://www.spacex.com/careers/position/215151 — вполне современный стек.
Использование только старых технологий не является обязательным условием для запуска ракет в космос
Угу. Для построения графика работы уборщиц — можно и современный стек. И для пресс-релизов, и для CRM…
На стартовом столе — очень сомневаюсь, чтобы хоть какие-то веб-технологии были. А на самой ракете… Вы попытайтесь, найдите хоть один радиационно-стойкий процессор, которые смог поддержать ваши веб-технологии. Ссылочку на российские я дал, можете поискать американские.
Одно исключение — камеры, стоящие на ракете. Вот они могут быть и почти бытовыми, ибо сдохнут — не жалко.
Ну как вам сказать. Если мы гарантируем срок службы 20 лет с вероятностью 99%, то все используемые микросхемы должны реально (хоть одной партией) отработать эти 20 лет. Иначе может быть, что через 10 лет диффузия её разъест, и 20% микросхем откажет. Всякое искусственное старение — помогает, но не сильно (см. ссылку выше — Intelу не помогло). Вот и получается, что заведомо надежное железо — это сильно устаревшее железо.
Запустить-то и на I7 можно. Но сколько дней оно пролетает живым? Пару суток или часы? Для видеокамер — не страшно. А для блока управления спутника со сроком службы в 20 лет?
На стартовом столе — очень сомневаюсь, чтобы хоть какие-то веб-технологии были. А на самой ракете… Вы попытайтесь, найдите хоть один радиационно-стойкий процессор, которые смог поддержать ваши веб-технологии. Ссылочку на российские я дал, можете поискать американские.
Одно исключение — камеры, стоящие на ракете. Вот они могут быть и почти бытовыми, ибо сдохнут — не жалко.
Использование только старых технологий не является обязательным условием для запуска ракет в космос
Ну как вам сказать. Если мы гарантируем срок службы 20 лет с вероятностью 99%, то все используемые микросхемы должны реально (хоть одной партией) отработать эти 20 лет. Иначе может быть, что через 10 лет диффузия её разъест, и 20% микросхем откажет. Всякое искусственное старение — помогает, но не сильно (см. ссылку выше — Intelу не помогло). Вот и получается, что заведомо надежное железо — это сильно устаревшее железо.
Запустить-то и на I7 можно. Но сколько дней оно пролетает живым? Пару суток или часы? Для видеокамер — не страшно. А для блока управления спутника со сроком службы в 20 лет?
Полагаю, в случае со спутниками/ракетами всякого рода REST-сервисы и похожие протоколы как раз и используются, вместо генерации jpeg-ов на серверной стороне, о чем вы говорили в начале переписки. Здесь тот самый случай, когда и на сервере ресурсы на вес золота, и канал связи узкий, зато клиент может позволить себе что угодно. Подход, предлагаемый REST, в такой среде весьма эффективен.
REST — работает по запросу. То есть для получения телеметрии не только Земля должна услышать спутник, но и спутник должен надежно слышать Землю. Такое снижение надежности никому не нужно.
REST не имеет кадрового и строчного разделения. Мы не можем заменить непринятую строку или кадр строкой или кадром из предыдущего суперкадра. Это огромное снижение надежности.
REST — не имеет ни продольных, ни поперечных контрольных сумм. То есть работает лишь поверх надежного транспортного протокола. Это опять не про космос.
REST — байтовый текстовый протокол. А в космической телеметрии экономится каждый бит.
Чем фантазировать — лучше почитайте, как передаются телеметрия.
Ещё лучше — почитайте ИКД ГЛОНАС или ИКД GPS, но они сложные. В качестве упрощенной версии — RTCM 2.2, он же ГОСТ Р 53612-2009. В связи с повышением скорости с 50 бод (спутник) до 100/200 бод (КСС) из протокола были выброшены кадры (заменены сообщениями), но все остальное осталось.
То есть это чуть упрощенный протокол GPS c 6-битовыми байтами, 30-битовыми строками, поперечными и продольными контрольными сумма и экономией каждого бита. Протокол битовый, то есть прием начинается с любого бита. Более того, есть защита от смены полярности, то есть замена всех 0 на 1 и наоборот не мешает приему.
P.,S. Вы же вроде в курсе, что я по работе GPS/ГЛОНАСС занимаюсь.
REST не имеет кадрового и строчного разделения. Мы не можем заменить непринятую строку или кадр строкой или кадром из предыдущего суперкадра. Это огромное снижение надежности.
REST — не имеет ни продольных, ни поперечных контрольных сумм. То есть работает лишь поверх надежного транспортного протокола. Это опять не про космос.
REST — байтовый текстовый протокол. А в космической телеметрии экономится каждый бит.
Чем фантазировать — лучше почитайте, как передаются телеметрия.
Ещё лучше — почитайте ИКД ГЛОНАС или ИКД GPS, но они сложные. В качестве упрощенной версии — RTCM 2.2, он же ГОСТ Р 53612-2009. В связи с повышением скорости с 50 бод (спутник) до 100/200 бод (КСС) из протокола были выброшены кадры (заменены сообщениями), но все остальное осталось.
То есть это чуть упрощенный протокол GPS c 6-битовыми байтами, 30-битовыми строками, поперечными и продольными контрольными сумма и экономией каждого бита. Протокол битовый, то есть прием начинается с любого бита. Более того, есть защита от смены полярности, то есть замена всех 0 на 1 и наоборот не мешает приему.
P.,S. Вы же вроде в курсе, что я по работе GPS/ГЛОНАСС занимаюсь.
Куда-то совсем в странную сторону завернула дискуссия...
Изначально в статье говорилось "а давайте напишем интернет-магазин на Delphi", на что комментаторы справедливо заметили, что для этой задачи есть технологии получше.
Потом пришли вы, и ответили, что на этих технологиях в космос не улететь. Справедливо, никто с этим и не спорит. Но это не значит, нужно писать интернет-магазин на технологиях для встраиваемой электроники. Выйдет прекрасный сайт с потрясающей надежностью передачи данных, но пользователи этого не заметят, потому что уже давно уйдут к другому продавцу, который запилил сайт намного быстрее на более подходящем стеке.
В общем, спорить можно бесконечно, только смысла в этом нет, потому что задачи обсуждаются совсем разные.
Вы частично правы. Действительно, сайт для сотен тысяч пользователей, каждый из которых не важен, есть смысл пилить на чем-то «стильном, модном, молодежном».
А с другой стороны — сайт на 3 пользователя, каждый из которых крайне важен и должен иметь возможность пользоваться этим сайтом 20 лет.
И это может быть тот же интернет-магазин, просто взгляд со стороны гендира или главбуха.
А с другой стороны — сайт на 3 пользователя, каждый из которых крайне важен и должен иметь возможность пользоваться этим сайтом 20 лет.
И это может быть тот же интернет-магазин, просто взгляд со стороны гендира или главбуха.
Я вам более того скажу — и бэкэнд гендира/главбуха тоже должен быть красивый, иметь адаптивный дизайн и всякие фантики/рюшечки. Использование «дубовых технологий» оправдано в редких случаях, таких, как ваши спутники. Или в других промышленных применениях, там, где преимущественно пофигу на дизайн, оператор будет работать с тем, что ему дали, лишь бы вертелось без сбоев.
Я вам более того скажу — и бэкэнд гендира/главбуха тоже должен быть красивый, иметь адаптивный дизайн и всякие фантики/рюшечки.Для бухгалтера то всё это и будет. Как я уже говорил — именно для веб-приложений Унигуй подходит идеально.
Даже там где пофигу на дизайн, все равно нужно хотя бы немного об этом думать, чтобы не получилось так
я бы сказал, что древние технологии намного красивей современной штамповки. Чем менее серийное производство — тем больше внимания красоте и удобству.
При современном производстве делать красиво — это удорожать выпуск в десятки раз. При ручном изготовлении — удорожание идет на проценты.
Web 1.0 — сам по себе адаптивен. Нужно лишь избавиться от табличной верстки. Более того, web 1.0 адаптивен настолько, что его можно смотреть даже на текстовых браузерах.
Когда я не могу настроить веб-интерфейс железки из-под современного хрома — это очень печально. 10 лет назад кто-то ошибся и использовал чуть более новые технологии, чем нужно. А эти технологии — отмерли.
Вы вот уверены, что ваши сайты выдержат 10-20 лет без исправлений? А это те же роутеры, IoT… — ну в общем куча всякой бытовой долгоживущей техники.
А красота… На мой взгляд ya.ru или google.com — это красивей «современных» адаптивных дизайнов.
Оператору нужно удобство. А удобство и красота — это очень близкие понятия. Вот этому дизайну — лет 30, если не 50. Это передняя панель радиостанции, мы её просто скопировали в веб. Это почти SPA (кроме логина), кнопки «Настройки» и «аварии» вызывают другие страницы. Но без новомодных короткоживущих фреймворков. Это очень удобно для оператора — все навыки работы с реальной радиостанцией сохраняются.
Кстати, спустя 5 лет, уже с трудом отличаю, где картинки с web-aplication, а где с windows gui. Уж больно они похожи.
Ну вот, например, буквица из красной строки
При современном производстве делать красиво — это удорожать выпуск в десятки раз. При ручном изготовлении — удорожание идет на проценты.
Web 1.0 — сам по себе адаптивен. Нужно лишь избавиться от табличной верстки. Более того, web 1.0 адаптивен настолько, что его можно смотреть даже на текстовых браузерах.
Когда я не могу настроить веб-интерфейс железки из-под современного хрома — это очень печально. 10 лет назад кто-то ошибся и использовал чуть более новые технологии, чем нужно. А эти технологии — отмерли.
Вы вот уверены, что ваши сайты выдержат 10-20 лет без исправлений? А это те же роутеры, IoT… — ну в общем куча всякой бытовой долгоживущей техники.
А красота… На мой взгляд ya.ru или google.com — это красивей «современных» адаптивных дизайнов.
Оператору нужно удобство. А удобство и красота — это очень близкие понятия. Вот этому дизайну — лет 30, если не 50. Это передняя панель радиостанции, мы её просто скопировали в веб. Это почти SPA (кроме логина), кнопки «Настройки» и «аварии» вызывают другие страницы. Но без новомодных короткоживущих фреймворков. Это очень удобно для оператора — все навыки работы с реальной радиостанцией сохраняются.
Это из багрепорта, не смотрите на цифры
Кстати, спустя 5 лет, уже с трудом отличаю, где картинки с web-aplication, а где с windows gui. Уж больно они похожи.
Вы вот уверены, что ваши сайты выдержат 10-20 лет без исправлений?
Уверен. Вы же сейчас можете в современном браузере открыть сайт, разработанный в 1990-х, и он будет выглядеть примерно так же. Также я уверен, что у меня скорее всего не будет ни одного сайта, которые проживут даже 10 лет. Через десять лет будет другая мода, другие потребности у пользователей, и клиенты наверняка захотят как минимум новый дизайн.
Значит вам везет, а мне нет. я постоянно вижу веб-интерфейсы железок, с которыми надо работать только из IE или только из FireFox. И чем они современней — тем больше привязаны не только к браузеру, но и к конкретным версиям браузеров.
Но вы правы " будет выглядеть примерно так же". Только параметры не поменять.
А если нет — то понимайте, что клиенты не меняют то, что работает. Меняют — владельцы сайтиков в погоне за модой. И лишь тогда, когда каждый отвалившийся из-за смены дизайна клиент абсолютно не значим для бизнеса.
Но вы правы " будет выглядеть примерно так же". Только параметры не поменять.
клиенты наверняка захотят как минимум новый дизайн.Вы лично меняли роутер из-за дизайна веб-интерфейса? Если да — с какого на какой сменили?
А если нет — то понимайте, что клиенты не меняют то, что работает. Меняют — владельцы сайтиков в погоне за модой. И лишь тогда, когда каждый отвалившийся из-за смены дизайна клиент абсолютно не значим для бизнеса.
Значит вам везет, а мне нет. я постоянно вижу веб-интерфейсы железок, с которыми надо работать только из IE или только из FireFox.
Просто это тот самый случай, когда работу выполняет человек, который должен был делать что-то другое. Во все времена веб-разработки была возможность использовать стандарты w3c, и была возможность использовать уникальные фичи своего любимого браузера. Кто выбрал второй вариант, тот и наказал своих пользователей.
Вы лично меняли роутер из-за дизайна веб-интерфейса? Если да — с какого на какой сменили?
Продавая роутер, вы не продаете веб-интерфейс. Вы продаете роутер. А продавая сайт, продавая бизнес-приложение, продавая интернет-магазин и т.д., вы продаете именно веб-интерфейс. В этом и разница.
А если нет — то понимайте, что клиенты не меняют то, что работает.
Вы очень сильно заблуждаетесь. Практически все клиенты постоянно меняют то, что нормально работает, просто ради покупки нового, более современного или просто модного. И роутеры тут не исключение. Вы разве дома не меняли роутер просто потому, что вам понадобился вайфай не 22 мб/с, а 480 мб/с?
Да на этом вся современная экономика построена :)
Заказчики веб-сайтов — такие же клиенты, они и сами хотят себе что-то модное, и понимают, что их покупатели тоже будут более лояльны, если у них сайт станет выглядеть современнее. И опять же таки, технологии. Десять лет назад практически никто не делал покупки с телефона. Сейчас — больше половины клиентов интернет-магазинов. Поэтому современные сайты должны иметь адаптивный дизайн, который одинаково функционален и на экранах компьютеров, и на планшетах, и на смартфонах.
Кто выбрал второй вариант, тот и наказал своих пользователей.
То есть с точностью до наоборот. FireFox следует W3C, поэтому в нем работает. Chrome сделал чуть по-своему, поэтому в нем не пашет. Если интересно, могу скинуть вам дампы страничек Lantronix XPort, сами полюбуетесь.
Так что все наоборот — тупое следование W3C вызывает проблемы.
Продавая роутер, вы не продаете веб-интерфейс. Вы продаете роутер. А продавая сайт, продавая бизнес-приложение, продавая интернет-магазин и т.д., вы продаете именно веб-интерфейс.Мягко говоря, вы не правы. Когда я использую веб-интерфейс роутера — мне нужно настроить роутер. Когда я использую веб-интерфейс магазина — мне нужно купить товар. И главное для меня — цена и качество товара. А веб-интерфейс либо мешает то сделать (и тогда проще оформлять заказ звонком) либо помогает.
Если я не смогу настроить роутер из-за кривости веб-интерефйса (или наличия там современного фреймоворка, не идущего на свежепоставленной WinXP) — я сменю роутер. Аналогично с магазином — не сумею оформить заказ — уйду к конкурентам.
Но менять роутер или инет-магазин из-за слишком старого веб-интерефейса я точно не буду. То есть чем старее — тем больше шансов, что я куплю именно там.
Хороший пример — сайт мосигры. В исходники гляньте и подивитесь. :-) Но Milfgard прав — действительно на этом сайте зависаешь минут на 20, если не больше. Хотя никаких «современных технологий» там нет.
Вы разве дома не меняли роутер просто потому, что вам понадобился вайфай не 22 мб/с, а 480 мб/с?Скорее наоборот, закрыть 802.11a/c/n и оставить только 802.11b. Ибо хочется иметь прием по всей квартире, без мертвых зон.
Заказчики веб-сайтов — такие же клиенты,Заказчики — это заказчики, клиенты — это клиенты, сервера — это сервера. Выигрывать в споре, давая терминам произвольное значение — некорректно.
Поэтому современные сайты должны иметь адаптивный дизайн,Для этого достаточно не верстать таблицами.
Я тут несколько лет жил на андроиде 1.5. Все эти «современные» сайты — там просто не открывались. Между прочим, для любителей QWERTY-клавиатур на мобильниках, современных вариантов нет.
Когда я использую веб-интерфейс магазина — мне нужно купить товар. И главное для меня — цена и качество товара.
Я же с вами не спорю по поводу спутников. Вот и вы со мной не спорьте по поводу веб-сайтов ;) Интернет-магазины не конкурируют ценой и качеством товаров. От слова «почти совсем». Потому что товары у всех одни и те же, цена тоже на одинаковые товары одинаковая или близкая у большинства магазинов. Они конкурируют рекламными бюджетами, скоростью обработки заказа, поставкой, и та-дам, как раз интерфейсом. Если покупателю не нравится веб-интерфейс, он просто купит такой точно товар, за примерно ту же сумму, но на другом сайте. Следующем по списку в выдаче гугла.
Скорее наоборот, закрыть 802.11a/c/n и оставить только 802.11b
Я тут несколько лет жил на андроиде 1.5. Все эти «современные» сайты — там просто не открывались.
Значит, вы очень нетипичный пользователь, и этот мир устроен не так, как вы любите, только и всего.
Заказчики — это заказчики, клиенты — это клиенты, сервера — это сервера. Выигрывать в споре, давая терминам произвольное значение — некорректно.
Вот вы сейчас как раз манипулируете. Беретё два неверных утверждения, добавляете верное, и добавляете силу своим словам. На самом деле сервера — это сервера, а заказчики/клиенты/продавцы — это одни и те же лица, зависит лишь от контекста. Я вот клиент или продавец? Если я покупаю в Мосигре игру, то я клиент. Если я им продаю сайт, то Моисгра — клиент, а я продавец. И поэтому мои предпочтения от моей роли никак не зависят. Если мне нравится, например, material design, он мне будет нравиться и как посетителю сайта, и как заказчику сайта.
Для этого достаточно не верстать таблицами.
К сожалению, весьма и весьма недостаточно. И наоборот, таблицы сами по себе бывают вполне уместны в адаптивном дизайне.
Я же с вами не спорю по поводу спутников.Да ну? А это что было?
Интернет-магазины не конкурируют ценой и качеством товаровДа ну? Между 8700 и 11420 для меня — существенная разница.
он просто купит такой точно товар, за примерно ту же сумму, но на другом сайте.Да ну? И у кого же? В этом и предыдущем примере город — Питер.
Чтобы не обвиняли в надуманности — это вот ровно то, что я покупаю через инет-магазины. Планшет — уже куплен, велик — будет покупаться через неделю.
Следующем по списку в выдаче гугла.А… Ну если смотреть по выдаче гугла, то действительно все одинаково. А если искать по яндекс-маркету (или иному агрегатору с хорошими возможностями поиска), то можно найти товар на 20-20 процентов дешевле или с характеристиками на 20-30 процентов лучше. Увы, гугл не умеет отвечать на вопрос «какой максимум характеристик можно взять за такую-то цену».
Значит, вы очень нетипичный пользователь,Линуксоиды с их текстовыми браузерами ещё более нетипичны. :-)
а заказчики/клиенты/продавцы — это одни и те же лица, зависит лишь от контекста.Нет. Заказчик — тот, кто платит за создание сайта, клиенты — пользуются сайтом. Это одно и то же, лишь когда в интранете сайт делается под нужды гендиректора.
Да ну? А это что было?
А где вы там увидели спор в одном-то посте, со словом «полагаю»?
Да ну? Между 8700 и 11420 для меня — существенная разница.
Там в ряд куча магазинов с ценой порядка 8600 плюс-минус сто. Разве этого недостаточно?
Линуксоиды с их текстовыми браузерами ещё более нетипичны.
Да, им тоже нелегко ;)
Нет. Заказчик — тот, кто платит за создание сайта, клиенты — пользуются сайтом
Не понимаю смысл вашей классификации относительно предмета спора.
Вы написали «А если нет — то понимайте, что клиенты не меняют то, что работает. ».
Я написал «Заказчики веб-сайтов — такие же клиенты, они и сами хотят себе что-то модное». С чем здесь вообще можно не согласиться? Заказчик сайта — это клиент. Какую бы вы классификацию не надумали, независимо от этого, как только он пришел ко мне за сайтом, он мой клиент. Такой же клиент, как его клиенты, которые у него покупают новый холодильник или телевизор, хотя старые ещё работают.
Там в ряд куча магазинов с ценой порядка 8600 плюс-минус сто. Разве этого недостаточно?С доставкой в Питер из Москвы? Так это те же 11 тысяч в итоге и будет. Велосипед же, не батарейка — вес и габариты приличные. :-)
акую бы вы классификацию не надумали, независимо от этого, как только он пришел ко мне за сайтом, он мой клиент.Ваш клиент и клиент сайта — огромная разница. Клиент сайта — тот, кто использует сайт. А клиенты сайтостроительной фирмы называются заказчиками.
Ваш клиент и клиент сайта — огромная разница.
Вообще не вижу, в чём разница. Расскажите, что ли. Мой клиент — это такой же человек, который что-то покупает, продаёт в интернете. Его вкусы/пожелания в сайтостроении находятся в том же диапазоне, что и других людей, которые приходят к нему на сайт.
Ну если разницы между продавцом и покупателем не видеть — то да, все одинаково. Продавец и покупатель, истец и ответчик, убийца и убитый, пожарный и пожарник, мальчик и девочка — какая в %опу разница?
Пример от той же мосигры. У них важная характеристика — время, которое человек проводит на сайте. Чем больше — тем лучше. Это позиция продавца.
А у покупателя желания иные — как можно быстрее купить нужное. А не торчать на сайте, изучая ненужное, но интересное.
Мне, как клиенту — вообще лучше без сайта. На яндекс-маркете выбрал, там же оплатил, там же выбрал пункт самовывоза. И никаких сайтиков с их долгим и муторным изучением доставки и способов оплаты. И, надеюсь, что скоро эта сказка обратится в жизнь.
Пример от той же мосигры. У них важная характеристика — время, которое человек проводит на сайте. Чем больше — тем лучше. Это позиция продавца.
А у покупателя желания иные — как можно быстрее купить нужное. А не торчать на сайте, изучая ненужное, но интересное.
Мне, как клиенту — вообще лучше без сайта. На яндекс-маркете выбрал, там же оплатил, там же выбрал пункт самовывоза. И никаких сайтиков с их долгим и муторным изучением доставки и способов оплаты. И, надеюсь, что скоро эта сказка обратится в жизнь.
В Штатах уже. Хинт: Amazon.
Ну если разницы между продавцом и покупателем не видеть — то да, все одинаково
Мне всегда казалось, что разница зависит от контекста (вы же и сами заметили, по крайней мере, со стороны анатомии). Если мы бы говорили о мерчендайзинге товаров, то разница есть. Если бы мы говорили об использовании людей в пищу, о статистике заболеваемости гриппом, о следовании моде в одежде или в сайтостроении, то разница между продавцами и покупателями здесь отсутствует.
Мне, как клиенту — вообще лучше без сайта.
Совсем без сайта никак. Вы же хотите и характеристики посмотреть, и картинки, и отзывы почитать, верно? И чтобы это всё было удобно и наглядно, с фильтрами, со сравнениями. И чтобы на смартфоне работало. Поэтому нет, не без сайта. Но можно взять сайт-агрегатор :)
Если бы мы говорили об использовании людей в пищу...., то разница между продавцами и покупателями здесь отсутствует.Вот теперь мне стало очень страшно. Людоеды вовсе не равны съеденной ими школьнице, Уж не о говорю о серийных убийцах.
Совсем без сайта никак.Сбербанк-онлайн, например. Сайт, только десктопный, с мобильника не зайти. Яндекс-транспорт не имеет даже десктопного сайта. Uber — сайт есть, но такси с него не заказать. Пригород — опять сайта нет.
А вы лично что-то покупаете с мобильного через сайты? У меня сейчас андроид 7 с экраном в 5 дюймов. Ни разу не потребовалось покупать с мобильного сайта. Через приложения — да, покупаю, а с сайта — мне глаза жальче.
Мобильные сайты интернет-магазинов — это тренд для Африки и ЮВА, где мобильников больше, чем компов, а денег на разработку приложений нет.
Вот теперь мне стало очень страшно
Не бойтесь, скорее всего, вас не съедят.
А вы лично что-то покупаете с мобильного через сайты?
Да, регулярно. Как и подавляющая часть владельцев смартфонов. Я же не живу в обнимку с компьютером. Я могу сидеть и на диване, и быть на улице, и в машине. И там у меня как раз есть смартфон. Про то, что половина покупателей приходят через смартфоны, вы же читали выше, помните? Это факт, который существует независимо от ваших личных предпочтений и от предпочтений Сбербанка. С ним нужно мириться, если хотите их не потерять.
Мобильные сайты интернет-магазинов — это тренд для Африки и ЮВА, где мобильников больше, чем компов, а денег на разработку приложений нет.
Вы меня троллите, или вы серьезно написали этот треш? Вам не очевидно, что ни один нормальный пользователь не будет загаживать смартфон приложениями интернет-магазинов? Можно поставить софт, который имеет какую-то полезную бизнес-логику, например, приложения клиент-банк (причём одно-два, а не для всех банков, которыми вы пользуетесь), или тот же Uber. Но приложения для магазинов, это абсурд.
половина покупателей приходят через смартфоны,Не путайте визит на сайт с покупкой, а смартфоны с планшетами. И вообще, вместо голословных утверждений, дайте ссылочку на статистику какого-нибудь инет-магазина.
нормальный пользователь не будет загаживать смартфон приложениями интернет-магазинов?Вы давно в PlayMarket смотрели?
Буквоед — 50 тысяч установок (покупка книг через инет)
2 берега — 100 тысяч установок (заказ пиццы, локальный для Питера)
пригород — 100 тысяч установок (билеты на электричку)
Додопицца — 1 миллион установок
OZON — 5 миллионов установок (опять книги)
Яндекс.киноафиша — 10 миллионов установок (это покупка билетов в кино)
Яндекс.Такси — 10 миллионов установок
Uber — 100 миллионов установок
ebay — 100 миллионов установок
aliexpress — 100 миллионов установок
Вам мало?
P.S. Чуть не дописал.
Можно поставить софт, который имеет какую-то полезную бизнес-логику
Так она у всех магазинов есть. Как минимум два общих места:
- Просмотр заказов без инета и вообще кэширование при отсутствии инета (и ускорение при наличии)
- Привязка карты к приложению, а не к агрегатору платежей.
Этого достаточно. Ну и UI получше. И проблем со вводом меньше.
Не путайте визит на сайт с покупкой, а смартфоны с планшетами.
Не путаю. Половина посетителей = половина покупателей. И планшеты тут не причем, они, между прочим, уже активно выходят из моды.
Вам мало?
Ничтожно мало. Я вам бы и без заглядывания рассказал, что у Убера, Алиэкспресса или Ебея есть миллионы пользователей. Для вас не будет секретом, что 99.9% интернет-магазинов не имеют приложений в маркете, и никогда их не будут иметь, зато имеют адаптивный дизайн, позволяющий удобно делать покупки через смарты?
вместо голословных утверждений, дайте ссылочку на статистику какого-нибудь инет-магазина.
Не дам. Честно, беседа с вами не настолько для меня важна, чтобы ещё и тратить время, чтобы выискивать цифры, доказывать вам что-то. Я сказал про статистику, которая мною не придумана, ну а верить мне или нет, ваше дело.
Просмотр заказов без инета и вообще кэширование
Я даже не могу придумать, зачем мне это нужно как покупателю (если номер заказа узнать, чтобы позвонить, он и так у меня есть — в смс, вайбере, почте, т.к. все магазины какие-то уведомления присылают). Вот серьёзно, зачем? Чтобы периодически в оффлайне посматривать на фото заказанной видеокарты или мультиварки и довольно урчать, пока она не приехала?
А карту тем более лучше доверить агрегатору, чем приложению магазину «Рога и копыта», который не проходит никакого аудита, и в любой момент может исчезнуть, неизвестно куда дев свою клиентскую базу.
А с точки зрения магазина, тратить ресурсы на разработку бесполезной приблуды, тем более.
Половина посетителей = половина покупателей.Голословно. Пруфов, я так понимаю, вы дать не можете. Опровержение столь же голословно — я иногда прикидываю с мобильника, что есть и по какой цене. Через гуглопоиск. Но никогда с с мобильного сайта не покупаю. И таких, как я, достаточно.
зато имеют адаптивный дизайн, позволяющий удобно делать покупки через смарты?Знаете, у вас и возможность убить есть. Вот только вы не убиваете. Так и тут — возможность купить с мобильника — не означает покупок. И 99.9% мелких магазинчиков не делают погоды.
Отсутствия приложения — это, скорее, критерий что перед вами мелкая шарашкина контора, в которой возврата и гарантийного ремонта просто нет. Ну или станет критерием через пару лет.
Я даже не могу придумать, зачем мне это нужно как покупателюА это разница между заказчиком и клиентом. Мне, как клиенту, удобней в точке самовывоза показать экран приложения, чем рыться в куче СМС. Тем более, что СМС не у всех есть, а email — требует инета. А в точках самовывоза частенько бывает так, что сотовая сеть шалит.
А карту тем более лучше доверить агрегатору,Через браузер? У меня десяток хромов одновременно подо мной зайдено. Так что безопасность — НОЛЬ. Только через приложение.
чем приложению магазину «Рога и копыта»А у «рогов и копыт» как раз нет денег на приложение. На сайтик — есть, а на приложение нет. Один из критериев для отличения однодневок.
Вот вам типичная однодневка — furby-toy.com На современный сайт деньги есть, на приложение нет. Дней 5 поживет, потом на новый адрес переедет. Присылает чистую липу наложенным платежом.
P.P.S. «25709 выполненных заказов» — это поисковый признак. Это число уже 2 месяца не меняется. А вот сайтик — меняет URL как перчатки.
Голословно. Пруфов, я так понимаю, вы дать не можете.
А надо? Мы с вами не в суде. Как я уже говорил, вы неправы, но это исключительно ваша проблема.
И 99.9% мелких магазинчиков не делают погоды.
Как раз они и делают :) Или вы будете спорить с тем, что люди чаще покупают где доступнее и дешевле? Если бы на крупных площадках было лучше, этих тысяч магазинчиков просто бы не существовало.
мелкая шарашкина контора, в которой возврата и гарантийного ремонта просто нет.
Не обижайте мелкие конторы. Во-первых, даже в самом захудалом магазинчике обычно есть и гарантия и возврат. А во-вторых, то, что контора мелкая, это не означает что-то плохое. Это означает, что пока вы протираете штаны, работая «на карман» чужому дядьке, кто-то набрался смелости и открыл собственный бизнес. Пусть даже и «купи-продай».
Мне, как клиенту, удобней в точке самовывоза показать экран приложения, чем рыться в куче СМС.
Не понимаю я ваш подход к эргономике, ей-богу. Мне вот, как клиенту всегда было проще называть в точке самовывоза мою фамилию. Или чтобы курьер домой привозил. Но доставать смартфон и искать там мой заказ в каком-то приложении… нет, спасибо.
У меня десяток хромов одновременно подо мной зайдено.
Повторюсь, вас таких в интернете десятка два, или чуть больше :) Ваши проблемы уникальны и практически никто с ними не сталкивается. А ради вас одного (и двоих, и даже тысячи таких как вы) Интернет не поменяется.
Пруфы — надо. Тем более, что ваш опыт касается другой страны. То есть я не удивлюсь, что пользовательский опыт на/в/по Украине примерно такой же как у её соседки по ВВП — Нигерии.
Все остальное — это тоже огромная разница между странами. Та же «Новая почта» с доставкой за день, которой в РФ нет.
Так что бездоказательно в отношении РФ.
P.S. Сразу видно иностранца
Любой россиянин знает, что даже в крупных магазинах может не быть ни возврата(так называемая технически сложная продукция практически не возвращается), ни гарантийного ремонта. То есть формально гарантийный ремонт есть — но в Москву надо привезти аппарат самому.
Все остальное — это тоже огромная разница между странами. Та же «Новая почта» с доставкой за день, которой в РФ нет.
Так что бездоказательно в отношении РФ.
Ваши проблемы уникальны и практически никто с ними не сталкивается.Да, нас в РФ всего 145 миллионов. Так что рынок действительно маловат.
P.S. Сразу видно иностранца
даже в самом захудалом магазинчике обычно есть и гарантия и возврат.
Любой россиянин знает, что даже в крупных магазинах может не быть ни возврата(так называемая технически сложная продукция практически не возвращается), ни гарантийного ремонта. То есть формально гарантийный ремонт есть — но в Москву надо привезти аппарат самому.
Все остальное — это тоже огромная разница между странами.
Вы знаете, покупатели в интернет-магазинах в странах с похожим менталитетом (да и вообще в странах с высоким проникновением интернетов и образования, к коим нам с вами повезло относиться) имеют абсолютно схожие модели поведения. У вас в России нет никаких племенных обычаев покупки, которые бы существенно отличали вас будь-то от поляков, будь-то от украинцев, будь-то от французов.
Да, нас в РФ всего 145 миллионов. Так что рынок действительно маловат.
Не обобщайте, пожалуйста. Ваши особенности — это не особенности российского покупателя, а особенности вашего довольно редкого психотипа ;)
Любой россиянин знает, что даже в крупных магазинах может не быть ни возврата(так называемая технически сложная продукция практически не возвращается), ни гарантийного ремонта.
Хм. Что вы там про Нигерию писали? ;)
На самом деле Нигерия тут не причем, можно всё вернуть и отремонтировать по гарантии. Просто вы не знаете законов своей страны.
www.consultant.ru/document/cons_doc_LAW_305/76ae101b731ecc22467fd9f1f14cb9e2b8799026
И есть лайфхак (который с трудом даётся многим людям): если магазин отказывается выполнять нормы законодательства, на него сначала надо писать заявление с требованием их выполнения, а в случае отказа — подавать в суд. И представьте себе, вы его выиграете, и вам компенсируют и стоимость покупки, и все ваши затраты, и моральный ущерб. Всё это прекрасно работает и в России. Вы же поймите, Украина находится не на другом конце земного шара. Я часто бываю в России, у меня есть и родственники, и клиенты тут. Поэтому я вполне осведомлен о ваших местных реалиях.
да и вообще в странах с высоким проникновением интернетовВыше вы писали про низкое проникновение десктопов на Украине.
Да и зарплаты на/в/по Украине — раза в 4 ниже российских. Соответственно иной выбор смартфонов. Просчитывали, что работать в Питере на российскую фирму, снимая жилье — выгодней работы на западную фирму по Украине.
Ещё одна особенность — по Украине нет внутреннего роуминга и дешевые внутриоператорские звонки. Это означает широкое распространение специальных трехсимочных смартфонов, которые являются экзотикой в РФ.
Социально — тоже огромное отличие. Украина до сих пор социальное государство. Например, украинские студенты из сел Луганщины — подкрамливают родителей своей стипендией. Российской стипендии — хватает поесть неделю, и то впритык.
Так что не вижу общего, кроме менталитета.
Законы надо уметь читать. По вашей ссылочке прочтите про технически сложный товар и существенный недостаток товара. Да, я вполне верю, что по Украине таких требований в законе нет.
Что касается судов, то в РФ это
Выше вы писали про низкое проникновение десктопов на Украине.
Т.е. исходя из вашей логики, у вас в стране низкое проникновение гужевого транспорта и телеграфных линий? Вы и правда крайне нестандартно мыслите.
Только превышение количества мобильных покупателей над пользователями десктопов — это общемировой тренд. В России то же самое.
Да и зарплаты на/в/по Украине — раза в 4 ниже российских.
Чуть больше, чем в два раза, если быть точным. Средняя официальная зарплата в Украине сейчас порядка 8400 грн, это $323, в РФ порядка 41500, это где-то $670. Ну и не надо забывать про паритет покупательной способности, в Украине стоимость проживания значительно ниже. Поэтому такого явления, чтобы у вас все покупатли айфоны, а тут кнопочные Нокии, нет. Рынок примерно одинаков.
Это означает широкое распространение специальных трехсимочных смартфонов, которые являются экзотикой в РФ.
А в Америке негров линчуют, а по Москве медведи с балалайками ходят. Я не знаю, что такое трехсимочные смартфоны, и даже попробовал поискать их в интернет-магазине. Не нашел.
Законы надо уметь читать. По вашей ссылочке прочтите про технически сложный товар и существенный недостаток товара
В Украине закон очень похожий, и собственно, никак потребителя не ограничивает. В любом случае, продавец обязан недостаток устранить за свой счет. Разница в том, что при существенном недостатке товар можно сразу вернуть, а при несущественном сначала должны попробовать отремонтировать. С доставкой в сервисный центр за счет продавца, между прочим.
Что касается судов, то в РФ это опупея эпопея минимум на полгода.
Ну тогда да, можно сидеть и терпеть, это быстро.
Только превышение количества мобильных покупателей над пользователями десктопов — это общемировой тренд. В России то же самое.
Голословно вы можете утверждать, что угодно. Но первая же найденная статистика говорит об обратном.
В России с десктопов заходят раза в 3 больше, чем с мобильных.
И пока вы не научитесь приводить пруфов, дискуссия — это лишь бесполезна трата моего времени.
дискуссия — это лишь бесполезна трата моего времени.
Вам нужно понимать, что ваше время для меня не стоит ни копейки ;)
Конечно. Ровно поэтому вы приводите как факт личное мнение, которое в рамках РФ является или полностью неверным или очень спорным.
Вот вам статистика продаж через приложение по сравнению с сайтом. И цифирка конверсии через приложение — 84.53%.
И ещё раз повторю достоинство приложения для РФ: независимо от того, я в метро, лечу на самолете или на «Сапсане», есть у меня интернет или нету — хорошее приложение мне покажет закешированные данные. И само обновит их — в фоне. И этого преимущества — достаточно.
Ну в общем я вас поймал на трех недостоверных высказываниях, превозносимых, как абсолютная истина. Так что остальные ваши высказывания — дальше буду считать спорными. Может быть для мира и для Украины — вы и правы. А для РФ — нет.
Вот вам статистика продаж через приложение по сравнению с сайтом. И цифирка конверсии через приложение — 84.53%.
Картинка - через приложение продаж почти 8 раз больше
И ещё раз повторю достоинство приложения для РФ: независимо от того, я в метро, лечу на самолете или на «Сапсане», есть у меня интернет или нету — хорошее приложение мне покажет закешированные данные. И само обновит их — в фоне. И этого преимущества — достаточно.
Ну в общем я вас поймал на трех недостоверных высказываниях, превозносимых, как абсолютная истина. Так что остальные ваши высказывания — дальше буду считать спорными. Может быть для мира и для Украины — вы и правы. А для РФ — нет.
Вот вам статистика продаж через приложение по сравнению с сайтом. И цифирка конверсии через приложение — 84.53%.
Да, а вы почитали статью? Там написано, что
а) Конверсию считали как 100% * количество заказов / количество установок. Оно после первого заказа самоуничтожается, что ли?
б) Через приложение заказ на 10% дешевле. Просто удивительно, почему оно вдруг популярнее сайта оказалось. Наверное, из-за удобства.
Ну в общем я вас поймал на трех недостоверных высказываниях, превозносимых, как абсолютная истина.
Вы знаете, вы и сами своё время ни в грош не цените, если вы его тратите на то, чтобы меня «подлавливать», искать статьи с подтверждениями/опровержениями и так далее, и всё ради обычного общения на форуме.
Просто удивительно, почему оно вдруг популярнее сайта оказалось.А! Так вы не в курсе, что в РФ за рекламу платят? Получил скидочную карту — пошла реклама на номер мобильника, к которому её прикрепил. Поставил приложение — пошла реклама в пуш-уведомлениях. А взамен — скидки.
Для РФ норма, что в приложении чуть дешевле. Я даже поставил ненужное мне приложение потому, что за его установку давали 3000 бонусов и сережки ребенку вышли в два раза дешевле.
Удивляет обратное, что по Украине — не так.
Это вот цена ваших утверждений, что менталитет одинаков. Увы и ах, он совсем разный.
Это вот цена ваших утверждений, что менталитет одинаков
А не вы ли утверждали, что через мобильное приложение якобы «удобнее»? А на поверку оказалось, что суть в том, что дают скидки за принудительный показ рекламы, и вы готовы ради этого терпеть, что ваш телефон загаживают рекламными уведомлениями.
Поверьте, в Украине тоже найдется масса пользователей, которые не поленятся скачать приложение ради того, чтобы купить товар со скидкой. Но называть это «заботой о покупателе со стороны магазина» или «удобством» я бы не стал.
Мобильное приложение действительно удобнее. Если по Украине они есть — попробуйте, поставьте. А реклама от них — удобнее и для меня (клиента) и для магазина, ибо точнее таргетирована. То есть в четверти случаев рекламные скидки — по делу и влияют на мой выбор, где и когда покупать.
Ещё раз. Основное удобство- это кэширование. РФ — отсталая страна. В отличие от Украины у нас в тоннелях метро мобильной связи нет. И высокоскоростных поездах с ней плохо, и в самолетах.
Ещё раз. Основное удобство- это кэширование. РФ — отсталая страна. В отличие от Украины у нас в тоннелях метро мобильной связи нет. И высокоскоростных поездах с ней плохо, и в самолетах.
… но при этом у вас есть странное нездоровое желание делать покупки в метро, в поездах и в самолётах, не зная ни актуальных цен, ни актуального ассортимента, находясь при этом в оффлайне без возможности отправить заказ, а и ещё и рекламу смотреть :)
Увы, ad hominem.
Про case покупки билета на электричку в метро я уже говорил. Про вызов такси из поезда или самолета — тоже понятно. Аналогично — заказ пиццы. Ещё один case — прямо в магазине, отчаявшись, что продавец найдет нужный товар по описанию — ткнуть ему под нос мобильник с приложением, с фоткой и данными товара. Увы, я не по Украине, в РФ многие ТЦ — железные ангары и мобильная связь там есть только в отдельных местах.
И онлайна раз в 5 минут мне для всего этого хватает. А вот «современные» сайтики, даже открытые заранее, очень любят перезагружаться, увидев малейшую щелочку (GPRS) в инет. Так что даже открытие заранее не помогает. Кстати, скорее всего из-за рекламы и перезагружаются. Или наличие товара раз в 5 минут проверяют.
А у вас актуальные цены на электрички раз в неделю меняются? Или чаще?
P.S. Россия — не Украина, у нас другие реалии.
Про case покупки билета на электричку в метро я уже говорил. Про вызов такси из поезда или самолета — тоже понятно. Аналогично — заказ пиццы. Ещё один case — прямо в магазине, отчаявшись, что продавец найдет нужный товар по описанию — ткнуть ему под нос мобильник с приложением, с фоткой и данными товара. Увы, я не по Украине, в РФ многие ТЦ — железные ангары и мобильная связь там есть только в отдельных местах.
И онлайна раз в 5 минут мне для всего этого хватает. А вот «современные» сайтики, даже открытые заранее, очень любят перезагружаться, увидев малейшую щелочку (GPRS) в инет. Так что даже открытие заранее не помогает. Кстати, скорее всего из-за рекламы и перезагружаются. Или наличие товара раз в 5 минут проверяют.
А у вас актуальные цены на электрички раз в неделю меняются? Или чаще?
P.S. Россия — не Украина, у нас другие реалии.
Вдогонку. Понимаете, одно дело — это ввести данные карты в приложение, где они хранятся на смартфоне и передают в момент покупки. Другое — запомнить их в инете, чтобы они были доступны на 10 синхронизированных под мой логин хромах. Первое — я готов, вторым — не рискну.
И этого (плюс доп.фишки приложений, которые не удобны на сайтах) — хватает, чтобы я ставил приложения, несмотря на отсутствие SD-карты на мобильнике.
ну так что с пруфами на покупки с мобильников через сайты? Они будут?
И этого (плюс доп.фишки приложений, которые не удобны на сайтах) — хватает, чтобы я ставил приложения, несмотря на отсутствие SD-карты на мобильнике.
ну так что с пруфами на покупки с мобильников через сайты? Они будут?
Понимаете, одно дело — это ввести данные карты в приложение, где они хранятся на смартфоне и передают в момент покупки.
Я вам более того скажу, лучше всего третье дело — не вводить их никуда. Вы не развалитесь от того, что будете вбивать эти 23 цифры пару раз в месяц, когда что-то собираетесь купить (это секунд десять занимает, между прочим). Зато избавите себя от вероятного длительного геморроя, когда в очередной раз при утечке «нескольких миллионов карт» вашу карту заблокируют и вам надо будет ехать в банк оформлять новую.
на 10 синхронизированных под мой логин хромах
Кстати, маленький лайфхак — научитесь использовать свой смартфон по назначению, и вам не нужен будет зоопарк браузеров на всех компьютерах, где вы только бываете. У вас их будет всего три — дома, на работе, в смартфоне.
Минимум — 40 раз в месяц. Скорее 50-60 раз. За одну командировку (ночь туда, день там, ночь обратно) — 8 поездок на такси. Каждую неделю -4-6 поездок на электричке. Остальное — по мелочи: пицца, книжки…
А, ещё раза 3-4 в неделю ispp.spbmetropoliten.ru — это пополнение траспортных карт детям и знакомым.
А, ещё раза 3-4 в неделю ispp.spbmetropoliten.ru — это пополнение траспортных карт детям и знакомым.
Ну так у вас же Uber стоит, верно? Это отдельный случай. А всё остальное — как обычно.
Uber, Яндекс-такси, GetTaxi, Таксовичков. Но погоду делают не они (командировки не каждую неделю), а «Пригород» и пополнения транспортных карт. Там кривейший интегратор, в нем не зарегистрироваться. Он вообще создан для платежей с мобильников, а с карт — так, побочка.
И это единственный сайтик, с которого я 1 (целый ОДИН) раз в жизни попытался заплатить с мобильного. Полчаса на платеж — извините, больше не хочется.
Ну в общем мобильные сайтики — идут лесом. Можете сами сравнить по удобству ну скажем yandex.ru/pogoda c приложением. Или metro.yandex.ru с приложением. Или rasp.yandex.ru с приложением.
Приложения удобны, а сайтиками с мобильного пользоваться — замучаешься.
И это единственный сайтик, с которого я 1 (целый ОДИН) раз в жизни попытался заплатить с мобильного. Полчаса на платеж — извините, больше не хочется.
Ну в общем мобильные сайтики — идут лесом. Можете сами сравнить по удобству ну скажем yandex.ru/pogoda c приложением. Или metro.yandex.ru с приложением. Или rasp.yandex.ru с приложением.
Приложения удобны, а сайтиками с мобильного пользоваться — замучаешься.
Uber, Яндекс-такси, GetTaxi, Таксовичков. Но погоду делают не они (командировки не каждую неделю), а «Пригород» и пополнения транспортных карт.
У меня только Uber. Покрывает 100% потребности в такси. Правда, я сейчас живу в Украине, и я не знаю, например, что такое «место, где плохо ловит сотовая связь» (кроме некоторых районов Донецка/Горловки), или «полчаса на платеж с мобильного».
У Uber есть в приложении скриншоты чеков? Они для отчета по командировке нужны. Обратная сторона белой бухгалтерии.
Про полчаса на платеж с мобильного — на старости узнаете. Ну не дружат мои лапы с тачпадами. Даже на платежных терминалах кнопки с пятого раза нажимаются. Пальцы — большие и луженые, а кнопки — мелкие и нежные. Лет через 20-30- — будет ещё веселее, ибо начнется тремор. Потому и qwerty-клавиатурники люблю. Просто андроид 1.5 уже достал. Хотя и бывший флагман.
Боюсь, что вы просто плохо Украину знаете. Как там с сотовой связью по трассе от Одессы до Болграда?
Если не в курсе — для сайтиков edge не катит, нужно минимум 3G. На edge только приложения нормально работают.
P.S. Плохо ловит сотовая связь — это GPSR, EDGE, 3G. Хорошо ловит — это HSPA, HSPA+ и 4G, Хотя мы, наверное зажрались доступным почти всюду HSPA.
Про полчаса на платеж с мобильного — на старости узнаете. Ну не дружат мои лапы с тачпадами. Даже на платежных терминалах кнопки с пятого раза нажимаются. Пальцы — большие и луженые, а кнопки — мелкие и нежные. Лет через 20-30- — будет ещё веселее, ибо начнется тремор. Потому и qwerty-клавиатурники люблю. Просто андроид 1.5 уже достал. Хотя и бывший флагман.
я не знаю, например, что такое «место, где плохо ловит сотовая связь»А что, у вас больших торговых центров нет? А высокоскростные поезда у вас ходить уже перестали? У них стекла металлические, да и скорость — 200 км/ч, то есть больше 160, на которые рассчитана сотовая связь. А массовых демонстраций/гуляний тоже не бывает? Ну чтобы 50 тысяч нарожу на одной площади? А метро в Киеве уже закрылось?
Боюсь, что вы просто плохо Украину знаете. Как там с сотовой связью по трассе от Одессы до Болграда?
Если не в курсе — для сайтиков edge не катит, нужно минимум 3G. На edge только приложения нормально работают.
P.S. Плохо ловит сотовая связь — это GPSR, EDGE, 3G. Хорошо ловит — это HSPA, HSPA+ и 4G, Хотя мы, наверное зажрались доступным почти всюду HSPA.
У Uber есть в приложении скриншоты чеков? Они для отчета по командировке нужны.
Не знаю, не смотрел. Все мои платежи есть на сайте в интернет-банкинге моего банка (и в приложении тоже).
Про полчаса на платеж с мобильного — на старости узнаете.
Я не про терминалы. Я не понимаю, почему с мобильного платеж выполняется полчаса. Ну минута, ну полторы. Сколько нужно времени на то, чтобы ввести данные карты и нажать «оплатить»? Причем в том случае, если оплата не производится через Apple Pay или там Приват 24, где достаточно просто код камерой щёлкнуть или телефон приложить к терминалу.
А что, у вас больших торговых центров нет?
Есть.
А высокоскростные поезда у вас ходить уже перестали?
Не перестали
А массовых демонстраций/гуляний тоже не бывает?
Бывает
А метро в Киеве уже закрылось?
Нет
Вот только связь есть и в поездах, и в торговых центрах и в метро в Киеве. В скоростных поездах есть бесплатный вайфай. Работает так себе, но по крайней мере, не хуже 3G. Нет связи в метро в Днепропетровске, и бывают проблемы в толпе при массовых гуляниях. Поверьте, и то, и другое — не вызывает необходимости иметь приложение для просмотра в оффлайне каталога товаров какого-то магазина :)
Все мои платежи есть на сайте в интернет-банкинге моего банка (и в приложении тоже).Будьте любезны, скриншот предъявите. Что-то я сомневаюсь, что в платежке будет точка посадки и точка высадки. А они нужны для включения чека в отчет по командировке. А в том, что банк делает товарные чеки — я очень сильно сомневаюсь.
Я не понимаю, почему с мобильного платеж выполняется полчаса. Ну минута, ну полторы.Постараете — узнаете. :-) Подсказка: у взрослых пальцы сильно больше, а кожа на них грубее.
Мил человек, или поезда действительно высокоскростные — или мобильная связь. По стандарту она работает до 160 км/ч, реально на 155 км/ч уже огромные проблемы. Да и стеклышки там не оконные, а прилично металозированные. Так что сигнал пропускают слабо.А высокоскростные поезда у вас ходить уже перестали?
Не перестали
Вот только связь есть и в поездах, и в торговых центрах и в метро в Киеве.Пруф приведите, про наличие излучающих кабелей всех операторов в туннелях. А то вы большой мастер утверждать то, что в итоге оказывается ложным. Думаю, что приема 3G/4G от всех операторов на перегонах между станциями и в Киеве нет.
Поверьте, и то, и другое — не вызывает необходимости иметь приложение для просмотра в оффлайне каталога товаров какого-то магазина :)Простите, дома, на работе и в гостинице есть комп. А вот билет на электричку — я покупаю в метро, когда уже понятно, успеваю я на высокоскоростную "Ласточку" или еду обычной электричкой. И в "Сапсане" и самолетах мне заняться нечем — можно и книжку заказать. Или пиццу к гостинице.
Будьте любезны, скриншот предъявите. Что-то я сомневаюсь, что в платежке будет точка посадки и точка высадки.
Там нет точки посадки и высадки. Это сугубо информационный документ о платеже. А что, ваша бухгалтерия считает первичкой картинки из каких-то программ?
Мил человек, или поезда действительно высокоскростные — или мобильная связь.
Я же сказал, в поездах бесплатный вайфай :)
Пруф приведите, про наличие излучающих кабелей всех операторов в туннелях
Понимаете, в Украине есть аж три мобильных оператора (на самом деле больше, но остальные не считаются). Два из них в киевском метро работают. Этого достаточно.
А вот билет на электричку — я покупаю в метро
Объясните мне, каким образом вы сможете его купить через ваше приложение со всеми его кешированиями, если там не будет интернета?
Постараете — узнаете. :-) Подсказка: у взрослых пальцы сильно больше, а кожа на них грубее.
Я не настолько моложе вас, чтобы вы мне что-то новое открыли. Мне 38. Полагаю, мои пальцы через двадцать лет в два раза не вырастут, чтобы не попадать на кнопки экранной клавиатуры. И емкостные датчики от их кожи работать не перестанут.
А что, ваша бухгалтерия считает первичкой картинки из каких-то программ?
Угу, вот такого чека достаточно, хотя точки посадки и высадки тут нет
Я же сказал, в поездах бесплатный вайфай :)В РФ 3D secure требует СМС. Так что Wifi не хватает для покупок.
Два из них в киевском метро работают.То есть пруфа нет. Извините, но я больше верю Киевским СМИ:
в подземке словить мобильный интернет практически нереально. Даже связь 2G работает не на всех станциях, не говоря уже о 3G или 4G. Это декабрь 2017 года. В Питере — 3G/HDSPA/4G- от 4х операторов на всех станциях, но в перегонах — увы, только WiFi и Мегафон.
Объясните мне, каким образом вы сможете его купить через ваше приложение со всеми его кешированиями, если там не будет интернета?Приложению хватает 3G на станциях, а вот сайтам — нет. Обмен у приложения — маленький, и заточен на дурные условия связи.
И емкостные датчики от их кожи работать не перестанут.На гитаре поиграйте — узнаете. :-)
Приложению хватает 3G на станциях, а вот сайтам — нет. Обмен у приложения — маленький, и заточен на дурные условия связи.
Какая разница между современным сайтом и приложением в плане трафика при осуществлении покупок? Вы вроде бы выше сделали вид, что в курсе про REST. Или вы до сих пор живете в мире Web 1.0?
В РФ 3D secure требует СМС. Так что Wifi не хватает для покупок.
Т.е. вы в России не можете делать покупки в поездах? Или вы делаете покупки, но доверяете реквизиты своей действующей банковской карты третьей стороне? Хм. Тогда к чему эта демагогия?
Какая разница между современным сайтом и приложением в плане трафика?В худшем случае -порядка тысячи раз. То есть сайтик постоянно желает обновить жирную рекламу (rich media! анимация! видео!), а пока не обновит — контент не дает.
Вы вроде бы выше сделали вид, что в курсе про REST.Так к REST ещё и желание нужно. И прямые руки. То есть надо все остальное (и прежде всего — рекламные банеры) грузить статически, с кэшированием в браузере. И не переобновлять страницу, если REST получил сбой связи.
Т.е. вы в России не можете делать покупки в поездах?Могу. 20 секунд 3G раз в 3 минуты хватает для приложений. А вот для сайтиков — маловато.
Так к REST ещё и желание нужно. И прямые руки.
Вы себе не представляете, сколько есть способов сделать хреновое, неповоротливое мобильное приложение с кучей рекламы при отсутствии прямых рук и желания.
И в отличии от сайта, ЭТО будет у вас на смартфоне, и к тому же будет лазить по вашим данным (вы же, небось, соглашаетесь с запрашиваемыми разрешениями у заинтересовавших вас приложений, как и подавляющее большинство пользователей).
Могу. 20 секунд 3G раз в 3 минуты хватает для приложений.
Ну так и СМСка для 3D secure без проблем проскочит ;)
Вы себе не представляете, сколько есть способов сделать хреновое,Представляю. Но, увы и ах, приложения работают нормально. REST они подгружают, когда есть связь, reload попусту не делают, статику — кэшируют до упора, а рекламу — грузят в последнюю, а не в первую очередь.
А вот хорошо работающих сайтиков — нет и быть не может. Для понимания — пара caseов.
Печатаете пост, он не отправляется из-за отсутствия связи, закрываете сайтик. Связь появилось — открываете страницу заново. Пост загрузится или нет? В приложении — загрузится, пробовал.
Печатаете пост, он не отправляется из-за отсутствия связи, переходите на другую страницу. Связь появилось — пост загрузится или нет? В приложении — загрузится, пробовал.
Можете проверить мобильную версию контакта vs официальное приложение.
Ну так и СМСка для 3D secure без проблем проскочит ;)Зато сайтик не загрузится.
Забыл ещё один недостаток Uber. Чемоданы, Чебоксары, Чебуреки… В Чебоксарах есть Uber?
Собственно для вас у меня есть хорошая задачка. Возьмите собственный домашний роутер, взгляните на его веб-панель и переделайте на «современный стек технологи».
Удастся — честь вам и хвала, особенно если после этого роутер можно будет использовать по назначению. Не удастся — ну хоть поймете, почему технологии, пригодные для сайтиков, не годятся в АСУТП, IoT и кучи других областей.
Удастся — честь вам и хвала, особенно если после этого роутер можно будет использовать по назначению. Не удастся — ну хоть поймете, почему технологии, пригодные для сайтиков, не годятся в АСУТП, IoT и кучи других областей.
Подсказка
Стюардесса в салоне нового лайнера объявляет о то, что находится в самолете:
— На первой палубе — багаж, на второй — бар, на третьей — поле для гольфа, на четвертой бассейн.
И добавляет:
— А теперь, господа, пристегнитесь. Сейчас со всей этой х%йней мы попробуем взлететь.
— На первой палубе — багаж, на второй — бар, на третьей — поле для гольфа, на четвертой бассейн.
И добавляет:
— А теперь, господа, пристегнитесь. Сейчас со всей этой х%йней мы попробуем взлететь.
НЛО прилетело и опубликовало эту надпись здесь
Будьте добры, дайте список роутеров, чья веб-морда сделана на «Современных фреймворках»,
Если точнее — список роутеров, которые я не смогу настроить со свежепоставленной windows XP (IE 6) или windpows 7 (IE 8).
Если ещё точнее — список роутеров. которые категорически не стоит покупать.
Если точнее — список роутеров, которые я не смогу настроить со свежепоставленной windows XP (IE 6) или windpows 7 (IE 8).
Если ещё точнее — список роутеров. которые категорически не стоит покупать.
НЛО прилетело и опубликовало эту надпись здесь
В быту — сначала настраиваем роутер, потом ставим с инета Chrome и обновления (или винду поновее).
Ваши «современные интерфейсы» на свежепоставленной Windows 7 (IE 8) пойдут? Да ровно так же обломаются, как и на IE 6.
Поэтому ещё раз прошу список моделей, которые категорически не стоит покупать.
Что касается XP — удобнейшая штука нетбук (тот же ASUS EEE PC). Легкий, компактный, работает часов 10 на батарейках. Вот только на win10 их в принципе нет.
А промышленный коммутатор — согласен. Сначала подключились к инету через нормальный роутер, обновили софт, потом настраиваем ненормального монстра, требующего новый софт. В промышленности ещё и не то бывает.
Ваши «современные интерфейсы» на свежепоставленной Windows 7 (IE 8) пойдут? Да ровно так же обломаются, как и на IE 6.
Поэтому ещё раз прошу список моделей, которые категорически не стоит покупать.
Что касается XP — удобнейшая штука нетбук (тот же ASUS EEE PC). Легкий, компактный, работает часов 10 на батарейках. Вот только на win10 их в принципе нет.
А промышленный коммутатор — согласен. Сначала подключились к инету через нормальный роутер, обновили софт, потом настраиваем ненормального монстра, требующего новый софт. В промышленности ещё и не то бывает.
Вы будете долго ржать, но я нашел даташит на процессор для кофеварки. Так вот, 4х битный он. Аж 8 мегагерц.
CGI выполняется на стороне клиентаОго :)))
Так может вам больше какой-нибудь LabVIEW подойдет?
А то неприятно будет, если кто-то не получит мой сигнал SOS, из-за undefined is not a function
А то неприятно будет, если кто-то не получит мой сигнал SOS, из-за undefined is not a function
К сожалению, вам не удастся заменить JavaScript на G. :-)
Чуть подробней поясню, чем так хорош Delphi. Обычная схема: приложение на С++ общается с объектом и подсовывает файлики AJAX, apache отдает статику, PHP проверяет пароли. В пике всем не хватает ни процессора, ни памяти. А пик на такой крохе — это от четырех клиентов.
Используем Delphi (точнее С++ Builder). Ценой очень небольших усилий выкидывается и апач и PHP, а их роли берет на себя основное приложение. И с разу с ресурсами становится сильно легче.
На следующем шаге мы не пишем на диск файлики для AJAX, а просто ловим запрос на их чтение и генерим ответ на лету. Соответственно веб-интерфейс становится живее, лучше отражает команды операторы. Сами команды (нажатия на кнопки сайта) тоже отрабатывают не чрез файлы-флаги и их поиск через inotify, а напрямую.
Ориентировочно — нагрузочная способность возрастает раза в 4.
Используем Delphi (точнее С++ Builder). Ценой очень небольших усилий выкидывается и апач и PHP, а их роли берет на себя основное приложение. И с разу с ресурсами становится сильно легче.
На следующем шаге мы не пишем на диск файлики для AJAX, а просто ловим запрос на их чтение и генерим ответ на лету. Соответственно веб-интерфейс становится живее, лучше отражает команды операторы. Сами команды (нажатия на кнопки сайта) тоже отрабатывают не чрез файлы-флаги и их поиск через inotify, а напрямую.
Ориентировочно — нагрузочная способность возрастает раза в 4.
А то неприятно будет, если кто-то не получит мой сигнал SOS, из-за undefined is not a functionА от Windows 95 c IE 4.0 никто не застрахован. Привыкайте к специфике. Тут софт обновляется только сертифицированной организацией во время ремонта оборудования. Сломается комп — может и софт поновей будет. Не сломает — так и будет то, что при рождении поставили. Так что брендовые компы 1996ого года с Win95 на борту иногда встречаются.
Почему нет? Я ковырял NASы с ресурсами как у второй платы, где софт производитель писал на python.
Та в конкретной ситуации его ркскритивать не составит труда. Плюсы от подхода:
1) Легко создать. Все больше ничего.
Минусы:
1) Быстродействие.
2) Практичность, захотелось использовать библиотеки, нет все пиши сам.
3) Поддержка. Я сомневаюсь, что найдутся те 1,5 разработчика сайтов на Delpfi, т.к они заняты написанием сайтов на ассемблере.
4) Размер страницы.
1) Легко создать. Все больше ничего.
Минусы:
1) Быстродействие.
2) Практичность, захотелось использовать библиотеки, нет все пиши сам.
3) Поддержка. Я сомневаюсь, что найдутся те 1,5 разработчика сайтов на Delpfi, т.к они заняты написанием сайтов на ассемблере.
4) Размер страницы.
1) Легко создать. Все больше ничего.
Когда то так же говорили и про ассемблер. Программисты на машинных кодах.
Минусы:
1) Быстродействие.
Это на компилируемой-то Дельфи, в отличие от более принятых под это дело PHP, JS (NodeJS) и Python и Ruby?
Да не смешите.
Вы утверждаете обратное? Я же пишу что сайты на Delphi это в рубрику ненормальное программирование. Не хочу набирать больше минусов. . Вероятно кто то знает больше плюсов. Но почему то поставил минус и готово.
Прошу прошения за комментарии вышел. Совершил ошибку. Старое не значит устаревшее, а значит проверенное и опытное. Предвзятое мнение, мне нет прошения. С таким же успехом мог написать такое про PHP.
Есть множество legacy-проектов на Delphi, которым, таким образом, можно легко и дешево добавить веб-интерфейс. Поэтому, думаю, ниша обеспечена.
Очень удобно делать веб-интрефейсы на delphi. На самом деле даже не сайты, а именно веб-морды для софта, веб приложения. В Унигуе множество готовых копмпонент, приложение делается быстро и просто.
Развитие идёт весьма бурно. Вот — новые библиотеки появляются. Следующим сообщением кину несколько шотов.
И не является ли delphi немножко устаревшим яп, а уж тем более для создания вебсайтов?
Развитие идёт весьма бурно. Вот — новые библиотеки появляются. Следующим сообщением кину несколько шотов.
Если к проекту надо прикрутить веб, то зачем плодить сущности в виде дополнительных технологий? На Delphi можно реализовать что угодно. Речь, разумеется, не о формошлепстве, которое почему то плотно ассоциируется с Delphi, хотя оно сейчас есть абсолютно везде, где только возможно, просто потому что так удобно. Устарел ли Delphi? Ни капельки, проблема в головах, которые активно захламляют технологиями-однодневками и прочими сиюминутными модой и тенденциями. Да и просто достаточно спросить «чем же он устарел?»…
Был Delphi, но через несколько лет Остапа понесло и пришлось отказаться как от среды разработки. Но спасибо что есть Free Pascal/Lazarus тем и живём.
Потом появился Delphi fo PHP но Остапа опять понесло Славу богу что большие проекты не успели запалить пришлось уйти на Oracle XE + APEX.
А в общем радует что у людей есть понимание того что бизнес приложения это бизнес приложения, к ним совсем другие требования по интерфейсам и поддержке.
Потом появился Delphi fo PHP но Остапа опять понесло Славу богу что большие проекты не успели запалить пришлось уйти на Oracle XE + APEX.
А в общем радует что у людей есть понимание того что бизнес приложения это бизнес приложения, к ним совсем другие требования по интерфейсам и поддержке.
Хех… Я лет 5 назад ещё не таким извращением занимался. Писал движок сайта на Lazarus/FreePascal (чисто в экспериментальных целях, не подумайте плохого :) ). Если кому интересно, статья и куски кода здесь: https://petrochenko.ru/lazarus/lazarus-cms.html
Уточните — что в итоге получается от компиляции проекта? И как оно потом подключается к сайту.
Так же интересует вопрос — Можно стандартно приладить туда обычные компоненты? (на одной из конференций была такая фитча :) — «киоск» — веб приложение + считыватель СКУД + принтер)
Когда то давно на Delphi 6-7 тестил OLE — т.е. Компилировался ocx файл и его можно было воткнуть на страницу, более или менее работал, правда весил немерено для HTTP (возможно что-то напутал — очень уж давно было).
Так же интересует вопрос — Можно стандартно приладить туда обычные компоненты? (на одной из конференций была такая фитча :) — «киоск» — веб приложение + считыватель СКУД + принтер)
Когда то давно на Delphi 6-7 тестил OLE — т.е. Компилировался ocx файл и его можно было воткнуть на страницу, более или менее работал, правда весил немерено для HTTP (возможно что-то напутал — очень уж давно было).
Уточните — что в итоге получается от компиляции проекта? И как оно потом подключается к сайту.Зависит от выбранного в мастере типа проекта:
- Автономный (standalone) сервер и Windows-служба компилируются в исполняемый файл (exe), как такового подключения не требуют, т. к. сами себе и веб-сервер, и сайт — всё в одном флаконе.
- ISAPI-модуль представляет собой DLL, которую необходимо добавить в сторонний веб-сервер. Сайт-агрегатор, упомянутый в статье, развёрнут именно в таком виде (на IIS).
Можно стандартно приладить туда обычные компоненты?Если под «туда» имелась в виду форма, а под определение «обычные» подпадают визуальные VCL-компоненты, то нельзя, однако большинство невизуальных (например для работы с базами данных) — конечно можно.
В самом Унигуе есть больше 100 готовых визуальных компонент, которые покрывают большую часть имеющихся задач. Перенести интерфейс VCL приложения в веб можно простой копипстой теста формы (dfm) в форму Унигуя.
Уточните — что в итоге получается от компиляции проекта? И как оно потом подключается к сайту.
Оно не подключается к сайту, оно и есть сайт. То есть фронт + бэк в одном флаконе.
Как человек писавший веб интерфейс на C++ по средствам Wt, такой вопрос, а как обстоит дело с состоянием(state), если делать приложение с web интерфейсом. Например редактор документа или обозреватель файловой системы сервера.
Наличие такого состояния порождает ряд вопросов:
- пользовательские сессии;
- многопотчность при standalone server.
а как обстоит дело с состоянием(state), если делать приложение с web интерфейсомЕсли правильно понял вопрос, то дело с состоянием вполне обстоит — при каждом обращении к веб-приложению (речь идёт о SPA) создаётся своя сессия в новом потоке, которая может хранить любые нужные ей данные (то самое состояние); если представить, что пользователь открыл, скажем, 3 вкладки такого сайта, то на сервере появится та же троица сессий.
многопотчность при standalone serverДанный тип сервера ничем не отличается в этом плане от прочих — на каждую сессию будет автоматически создан свой поток.
Многопоточность, многосессионность и многоюзерность реализована из коробки. Всё работает само, формы создаются и разрушаются когда нужно. Все данные доступны по-сессионно. Главное за синхронизацией доступа к данным из разных потоков смотреть, само собой.
Все-таки у лени должны быть границы. Не вижу сложностей использовать упомянутую связку HTML-CSS-JavaScript, которая позволяет реализовать что угодно, не пытаясь подстраиваться под ограниченность очередного набора компонентов.
Мой комментарий ниже поясняет, почему был выбран именно такой небесспорный способ.
Несколько шотов (убрал под спойлер, так так большие довольно:
Заголовок спойлера
Для внутрикорпоративных ресурсов унигуи просто великолепен. ExjJS позволяет просто не заморачиваться клиентской частью вообще, одновременной идет разработка как веб части которая будет выполняться на клиенте в браузере и серверной части. Не могу подобрать слова к описанию скорости разработки, думаю подходит чудовищно, чудовищно великолепна :)
Сравнивали с yii и самописным фреймворком на форме с гридом и попапом для редактирования данных. Unigui просто уничтожил противника. Причем во второй команде сидели программеры которые собаку сожрали на yii и php с js.
При этом стабильность тоже отличная, тестировали во время одного мероприятия как модуль на IIS, ресурсов жрет немного, и нормальная работа около 300 клиентов и до 800 конкурентных в пике нагрузки.
Сравнивали с yii и самописным фреймворком на форме с гридом и попапом для редактирования данных. Unigui просто уничтожил противника. Причем во второй команде сидели программеры которые собаку сожрали на yii и php с js.
При этом стабильность тоже отличная, тестировали во время одного мероприятия как модуль на IIS, ресурсов жрет немного, и нормальная работа около 300 клиентов и до 800 конкурентных в пике нагрузки.
Видео еще немного ('десктоп' на Унигуе):
Официальное видео с вебинара (прошлогоднего):
Официальное видео с вебинара (прошлогоднего):
Ext JS это фреймворк для создания сложных приложений, на уровне толстых клиентов, но работающих в браузере. Делать на его базе веб-сайты весьма неэффективно. Вы берёте инструмент, для ваших целей не подходящий в принципе, и пытаетесь его изнасиловать. Зачем?
Дело в том, что в статье не отражена некоторая подоплёка: изначально никакой ручной вёрстки не планировалось, однако после того, как было сделано чуть больше половины работы (включая интерфейс и серверный код, ответственный за доступ к данным), из-за одной проблемы с uniGUI, которую так и не удалось решить, пришлось применить описанный в статье подход, сохранив, что крайне важно и приятно, весь серверный код. Поэтому написанное — это положительная иллюстрация того, что библиотека позволяет при острой необходимости проделать такую радикальную замену.
Также в качестве небольшой ремарки — упомянутый проект агрегатора на самом деле состоит из двух сайтов: публичного из статьи и служебного, служащего для управления содержимым первого, который уже написан исключительно на компонентах uniGUI, по первому сценарию.
Также в качестве небольшой ремарки — упомянутый проект агрегатора на самом деле состоит из двух сайтов: публичного из статьи и служебного, служащего для управления содержимым первого, который уже написан исключительно на компонентах uniGUI, по первому сценарию.
Поэтому написанное — это положительная иллюстрация того, что библиотека позволяет при острой необходимости проделать такую радикальную замену.
Не наезда ради, а конструктивной критики для: скорее это говорит о неверном изначальном выборе инструментария и архитектуры. В английском есть такая поговорка: если у тебя в руках молоток, то всё вокруг начинает казаться гвоздями; вы начали разработку проекта, используя привычные инструменты и не задумались о том, насколько они подходят для задачи.
Конкретно в данном случае ошибка в неразделении серверной и клиентской стороны. На чём сделан сервер, браузеру совершенно всё равно: HTTP и в Африке HTTP. А вот с клиентской стороны у вас по факту два приложения, и для одного из них Ext JS подходит примерно так же, как карьерный самосвал для гонок в картинге. Отсюда и вся боль и страдания.
Если этот проект всё ещё в разработке, рекомендую заменить Ext JS на что-нибудь попроще для публичного веб-сайта, жизнь станет гораздо проще и солнечнее. Это я вам как разработчик Ext JS говорю. :)
P.S. Пардон, ткнул не туда — ответ был на предыдущий комментарий.
Была такая либа с похожим функционалам и бесплатная raudus
Подобные компоненты TMS начал активно развивать, к слову:
TMS WEB Core
www.tmssoftware.com/site/tmswebcoreintro.asp
TMS WEB Core
www.tmssoftware.com/site/tmswebcoreintro.asp
Возможно кому-то будет телеграмм канал интересен:
t.me/Delphi_Lazarus
Unigui там тоже используют, стучите, кому интересно.
t.me/Delphi_Lazarus
Unigui там тоже используют, стучите, кому интересно.
Delphi в этом случай напоминает Remote Application Platform — была (и есть) такая штука в Eclipse экосистеме, которая позволяла запускать rich client приложения, написанные на java, в браузере, для того чтобы не писать новый код. Конечно десктопные приложения в вебе выглядели ужасно и 100% совестимости кода не было. Но ортодоксальным пользователем, которые привыкли к десктопу было нормально.
Основные причины писать такое в вебе были миллионы строк легаси кода, новый проект конечно начинать не стоило бы. Тоже самое и с Delphi, хотя интересно что жив еще курилка и барахтается.
P.S. эх было в 00ых интересно с Delphi, когда надо было сваять что-то быстро :)
Основные причины писать такое в вебе были миллионы строк легаси кода, новый проект конечно начинать не стоило бы. Тоже самое и с Delphi, хотя интересно что жив еще курилка и барахтается.
P.S. эх было в 00ых интересно с Delphi, когда надо было сваять что-то быстро :)
Оставлю еще несколько ссылок, возможно кому-то будет интересно.
Некоторые возможности Enterpise версии (UML проектирование):
www.youtube.com/watch?v=n7Jm5loU_QY
Еще один крупный форум в рунете, в том числе по Делфаю:
forum.ru-board.com/forum.cgi?action=filter&forum=33&filterby=topictitle&word=delphi
Некоторые возможности Enterpise версии (UML проектирование):
www.youtube.com/watch?v=n7Jm5loU_QY
Еще один крупный форум в рунете, в том числе по Делфаю:
forum.ru-board.com/forum.cgi?action=filter&forum=33&filterby=topictitle&word=delphi
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создание сайта на Delphi, или Как использовать uniGUI по-минимуму