Представлен (https://www.djangoproject.com/weblog/2017/dec/02/django-20-r...) релиз web-фреймворка Django 2.0 (https://docs.djangoproject.com/en/2.0/releases/2.0/), написанного на языке Python и предназначенного для разработки веб-приложений. Присвоение выпуску номера 2.0 связано к переходом к новой схеме (https://docs.djangoproject.com/en/2.0/internals/release-proc...) нумерации версий, соответствующей принципу семантического версионирования. Важными изменениями, также способствовавшими присвоению знакового номера, стали прекращение поддержки Python 2.7 (для работы Django 2.0 теперь необходимо наличие Python 3.4, 3.5 или 3.6), серия нарушающих совместимость изменений (https://docs.djangoproject.com/en/2.0/releases/2.0/#backward...) и удаление большой порции возможностей (https://docs.djangoproject.com/en/2.0/releases/2.0/#removed-...), ранее объявленных устаревшими.В рамках новой схемы присвоения версий каждый третий значительный выпуск будет отнесён к выпускам с длительным временем поддержки (LTS). После каждого LTS выпуска первая цифра версии будет увеличиваться. Например, 2.0, 2.1, 2.2 (LTS), 3.0, 3.1, 3.2 (LTS). Ветка Django 2.0 отнесена к категории выпусков с обычным сроком поддержки и будет получать (https://www.djangoproject.com/download/#supported-versions) обновления до августа 2018 года. LTS-ветка Django 1.8 до апреля 2018 года, а LTS-ветка 1.11 до апреля 2020 года.
Поддержка ветки 1.10 прекращена.
Ключевые улучшения (https://docs.djangoproject.com/en/2.0/releases/2.0/):- Поддержка упрощённого синтаксиса (https://docs.djangoproject.com/en/2.0/topics/http/urls/) маршрутизации URL, позволяющего привязывать обработчики путей без применения регулярных выражений. Например, вместо "url(r'^articles/(?P‹year›[0-9]{4})/$', views.year_archive)" теперь можно указать "path('articles/‹int:year›/', views.year_archive)". Для сохранения обратной совместимости поддержка старых методов на основе регулярных выражений сохранена в полной мере;
- Новый интерфейс администратора (contrib.admin (https://docs.djangoproject.com/en/2.0/ref/contrib/admin/)), построенный с использованием методов адаптивной вёрстки и работающий как на настольных, так и на мобильных устройствах;
- Выражение Window (https://docs.djangoproject.com/en/2.0/ref/models/expressions...) для построения запросов с применением выражения "OVER" (запрос формируется как "expression OVER window"). Например:
window = {
'partition': [F('studio'), F('genre')],
'order_by': ExtractYear('released').asc(),
}
Movie.objects.annotate(
best=Window(
expression=Max('rating'), **window,
),
worst=Window(
expression=Min('rating'), **window,
),
)
URL: https://www.djangoproject.com/weblog/2017/dec/02/django-20-r.../
Новость: http://www.opennet.me/opennews/art.shtml?num=47667
Вот я собираюсь делать веб-сайты, хочу научиться. Что еще за приложения? они мне нужны? Сколько пользуюсь инетом, хожу по сайтам, никаких приложений не видел. Что это?P.S. А так очень рад! Питон лучший.
Представьте себе, что браузеров не бывает, и для того, чтобы зайти на сайт, вам нужно было бы ставить приложение этого сайта. Вот вы ткнули в ярлычок "ОпенНет", и выпало вам окошко приложения, отображающего новости, комментарии, форумы и прочее. А еще оно умеет ваши комментарии отправлять и прочее.
Так вот, все то же самое, только браузер позволяет отдельные программы не ставить. И оказывается, что значительную часть тех ярлыков, которые ведут к установленным у вас приложениям, тоже можно заменить ссылкой - и никому от этого хуже не будет.
Представил... ну а в чем смысл тогда этих приложений? Это как мобильные приложения facebook и т.п.?
Нет, это как решение задач, которые в прошлом веке решали отдельные приложения, но без отдельного приложения.
Сколько заполнятелей формочек было написано на Дельфи - одному Аполлону известно. Практически всем им - самое место на сайте.
Сколько плееров было? Сейчас Вконтакте музыку слушают чаще, чем в Винампе.
Сколько раз мы слышали проклятия о тексте, который писался три часа - и не был сохранен? В Гугль.Документах так не бывает.
И так далее...
Тем не менее, отдельные приложения делают все, кому не лени. Т.к. браузер никогда не сравнится с ними по скорости, функциональности и энергоэффективности.
А пример скайпа не показателен, там царит маразм.
Учитывая, что те отдельные приложения все чаще являются просто интерфейсом, дергающим ровно тот же самый API сайта, что и онлайн-версия... в общем, вы лепите горбатого. 95% приложений ни скорость, ни прочая энергоэффективность не критичны в принципе.Если вам не угодно соглашаться со мной - посмотрите на вакансии на биржах. Разработчики на Дельфи больше не нужны никому, а разрабочики на Крестах востребованы отнюдь не для разработки standalone-приложений. Работа с сетью, хайлоад, вот это все.
Собственно сейчас разработка идет с обоих сторон на встречу. Мы видим что Swift, Jvaa и JavaScript в принципе идут на встречу. Сайты, приложения имеют одну парадигму и вполне повторяют представление - это скорее всего XML с частными реализациями кнопок: JavaFX с JXML формочками, .NET со своим WPF или HTML со своим приходом сейчас слоев и прочей требухи вроде CSS. Все идут к одной и тоже идее просто это разные пути грустно что все они по своему имеют ограничения. И вместо обьединения усилий все гнут свои недостатки как достоинства
> Питон лучшийНу так. Неплохой. Про него могу сказать абсолютно уверенно, что он определенно лучше BASIC. Лично я на питоне произвожу перегонку с одних форматов на другие -- для одноразовых скриптов определенно хороший язык. А хейтеры питона, которые будут сейчас вопить про чрезвычайно низкую скорость работы -- окститесь! Это как жаловаться на тормоза баша. То же и про пробелы вместо скобок -- язык создан специально для написания одноразовых скриптов в 20 строк, незачем для такого тащить сюда свои сишные привычки. Баш вон тоже не си-подобен.
В 4-ой версии планируют сделать быстрей.
Это не значит, что его назначение изменится, и большинство фанатиков перестанут быть извращенцами.
> Это не значит, что его назначение изменится, и большинство фанатиков перестанут быть
> извращенцами.Ну хватит уже трололо ну у языка в дизайне сказано что язык для прототипирования (прототипы делать для экспериментального завода самое то). Сделали прототип на Django поиграли поняли что нагрузки много и пеерписали узкие места на нужный вам системный язык или расширили то что там у вас просело ...
>в дизайне сказано что язык для прототипированияТы всё как обычно перепутал - это вот у тебя в истории болезни написано!
Ни на вике, ни в питон доках такого нет :-)
>>>> Релиз web-фреймворка Django 2.0
>он определенно лучше BASIC
>хейтеры питона, которые будут сейчас вопить про чрезвычайно низкую скорость работы
>язык создан специально для написания одноразовых скриптов в 20 строктак тонко не прокатит
Нет, не тонко. Абсолютно всё, как оно есть. Просто некоторые еще не готовы к правде, но подгорать начинает. А это уже неплохо...
Расматривай веб-приложения как отдельный сетевой сервис, работающий на отдельном tcp-порту и отображающий этот самый динамический сайт.
Веб-сайты можно делать, написав вручную HTML. А приложение - это программа. Программисты разрабатывают приложения. Веб или не веб - значения не имеет.
> Веб-сайты можно делать, написав вручную HTML. А приложение - это программа. Программисты
> разрабатывают приложения. Веб или не веб - значения не имеет.Веб или не веб - разница есть:
1. веб приложения у пользователя фактически нет;
2. веб приложение работает только когда есть интернет;
3. веб приложение может меняться разработчиком незаметно от пользователя. Аудит безопасности бессмыслен;
4. веб приложение всегда будет работать медленнее, и потреблять больше ресурсов;
5. веб приложения далеко не всегда можно создать настолько же функциональными, как и обычные приложения.
И для кого-то эта разница имеет значение.
1. А игрушка, купленная вами в Стиме, вам принадлежит? Точно принадлежит? Даже если Стим против?
2. Данные устарели. Современное веб-приложение вполне может работать на компьютере пользователя, используя интернет только для синхронизации.
3. А что ОПАСНОГО может быть в веб-приложении? Напоминаю, любая запущенная вами программа имеет доступ к тем же файлам и системным вызовам, что и запустивший ее пользователь. Запущенное в браузере - не имеет прав практически ни на что.
4. Совершенно не факт. Веб-приложение позволяет вынести "тяжелую" часть с вашего компьютера, и у клиента будет работать исключительно интерфейс. Скорость самого пользователя обычно куда ниже.
5. И vice versa. То, что для обычного приложения требует rocket science - например, совместная работа - для веб естественно и делается любым студентом по готовым библиотекам. Так что сравнивается теплое с мягким.Разница, конечно, есть. Но ее бессмысленно рассматривать "в лоб". Веб - это немного другой подход к решению задач. Если пытаться все делать по старым рельсам - может получиться хуже, чем было. Если понимать возможности и смотреть на задачи с другой стороны - то после их решения вы будете смотреть на отдельные приложения как на прошлый век. Которым они, собственно, уже и являются. Просто инерция велика.
> 3. А что ОПАСНОГО может быть в веб-приложении? Напоминаю, любая запущенная вами программа имеет доступ к тем же файлам и системным вызовам, что и запустивший ее пользователь. Запущенное в браузере - не имеет прав практически ни на что.Смысл в том, что для обычного приложения аудит безопасности МОЖНО произвести, после чего всегда быть уверенным, что оно ничего лишнего не делает. Веб-приложения же, как правило, подгружают свой код по сети и на лету его интерпретируют, что даёт широченный простор для творчества всякого рода вредителям. Собственно, поэтому веб-приложение и запихивают в контейнер, чтобы не дай бог оно не смогло что-либо сделать.
Но как бы это сказать... Это как вместо того, чтобы купить что-нибудь простое, типа миксера, ты приобретаешь девайс, который может в любой момент взорваться, но он в свинцовом контейнере, так что если рванёт -- не страшно. И за контейнерами вроде бы и следят, чтобы любой взрыв выдерживали. Однако у меня, как у потребителя, остаётся небольшой вопрос: на кой ляд мне тащить в дом бомбу?
Что-то я не припомню случаев массового аудита приложений. Если не считать плясок над трупом TrueCrypt-а.
И уж ничего сравнимого с шифровальщиками, способными подложить свинью целому офису, в браузерах пока не водится.
> И уж ничего сравнимого с шифровальщиками, способными подложить
> свинью целому офису, в браузерах пока не водится.разумеется, ничего сравнимого.
Теперь, в новой модной парадигме "все в облачке, то ись ,на ветер", шифровальщики способны положить не офис, а крупную компанию целиком.Изучайте, любознательные: http://www.opennet.me/opennews/art.shtml?num=45580
только за последний год подобных историй было несколько - и в минимум двух случаях, часть беззаботно доверенных вебу данных кто-то таки не поленился зашифровать, жаль что хозяева данных не знают, каким ключом ;-)
> шифровальщики способны положить не офис, а крупную компанию целиком.И для этого достаточно, чтобы офисная планктонина открыла вложение из письма?
> зашифровать, жаль что хозяева данных не знают, каким ключом ;-)
А от собственных бэкапов, к которым сервер никак доступа не имеет, они тоже ключи потеряли?
В отличие от хрен-его-знает-по-какой-логике-хранящихся данных локальной программы, базы данных совсем не трудно бэкапить, реплицировать, раскидывать по серверам и пр.
> Что-то я не припомню случаев массового аудита приложенийНикто про массовый аудит ничего не писал. Вы всё надумали. Но касательно аудита, в моей компании он проводится.
Расскажите, как вы аудировали MS Office, например.
> Никто про массовый аудит ничего не писал. Вы всё надумали. Но касательно
> аудита, в моей компании он проводится.Компания как называется?
> Что-то я не припомню случаев массового аудита приложений.Я тебя, зелёный брат, конечно уважаю, но ответы из разряда "да плевать на все ваши аргументы" сами кушайте.
А мне пожалуйста два ответа на исходные тезисы.
Первый: чем тебе достаточное количество глаз мейнтейнеров не "массовый аудит"? Децентрализованный механизм, социальный и саморегулирующийся, с приемлемым качеством на выходе.
Второй: зачем мне тащить себе в дом бомбу?
Тут, видимо, пропущен нулевой пункт: мы говорим о Линукс-инфраструктуре, где хоть какая-то проверка приложений есть.
Просто вне этой инфраструктуры взрослые люди продолжают тащить в рот такую каку, что с вебом ее даже странно сравнивать.Далее, я же не призываю вас безоглядно бросаться на все веб-сервисы подряд, не разбираясь в мотивах их предлагающих.
Но если вам внутри вашей собственной офисной сетки нужно работать с какими-то данными, да еще и совместно - тут просто со всей очевидностью приходится признать, что классические приложения морально устарели, и строить работу на веб-технологиях и проще, и перспективнее.
Тем более, что из офисной сетки оно при желании без каких-то критичных усилий выносится во всемирную.
> 4. Совершенно не факт. Веб-приложение позволяет вынести "тяжелую" часть с вашего компьютера,
> и у клиента будет работать исключительно интерфейс. Скорость самого пользователя обычно
> куда ниже.И наоборот. Веб-приложение позволяет вынести "тяжёлую" часть с сервера, и переложить нагрузку на клиента. Чем всякие разные личности весьма активно пользуются. :)
То, что бензопилой можно отпилить голову - совершенно не проблема самой технологии, согласитесь.
То, что на питоне можно написать всё - совершенно не проблема самой технологии, согласитесь. © ПитоноФанатик
А если сарказм в сторону, с потребительской точки зрения конечный продукт наиболее важен. И плохие практики, поощряемые технологией, можно сказать, являются их составной частью.
Технология веб-приложений поощряет майнеры не больше, чем обычные приложения - уже привычную малварь.
> То, что бензопилой можно отпилить голову - совершенно не проблема самой технологии, согласитесь.Зачем же тогда производство всё более тяготеет к высокоуровневым языкам, которые выстрелить себе в ногу не позволяют? Ну, сам спросил, сам и отвечу: потому что постоянно простреленные ноги -- это как раз-таки проблема.
Применительно к веб-приложениям: у нас весь офис пересел на телеграм даже не из-за недостаточной функциональности нового интерфейса скайпа, а скорее из-за некоторой его тормознутости и жадности до ресурсов. Вот он, самый что ни на есть успех веб-приложений.
PS: и я очень сомневаюсь, что бензопилой можно отпилить голову. В ужастиках-то всё просто, но туша не из папье-маше сделана. Заглохнет бенза как пить дать.
> Вот он, самый что ни на есть успех веб-приложений.На скайпе свет клином не сошелся. Скайп - это, в первую очередь, сервис, отягощенный множеством недостатков. С него не спрыгивали только из-за недоразвитости конкурентов. Убогий клиент, сделанный с явным пренебрежением к нуждам пользователей - просто последняя капля.
Ровно та же история, помнится, была у Аськи под Линукс, когда ее умудрились слепить на Адобе Эйр. Грабли стандартной комплектации, можно сказать.
Примерно то же самое относится и к прочим аналогичным Электронам. Это все то же, еще с прошлого века, стремление создать богатую платформу, под которую легко и приятно пишется. В результате и платформа жрет ресурсы, как не в себя, создавая богатые абстракции, и написанное легко ни черта не оптимизировано. Точь-в-точь Джава с дотНетом в начале пути...Это не веб-приложения, это монстры нашего века. Веб-приложения - это те же Телеграм с Вайбером, которым безразлично, где работать - в своем клиенте, в браузере или общаться с другим сервером через API.
> Это не веб-приложения, это монстры нашего века. Веб-приложения - это те же
> Телеграм с ВайберомУчитывая, что телеграм написан на плюсах с использованием Qt, мы определённо называем веб-приложением разные вещи. Я вот говорил о js-приложениях, работающих в браузере.
> которым безразлично, где работать - в своем клиенте, в браузере или
> общаться с другим сервером через API."Приложение может работать в своём клиенте" -- это очевидно некий оборот речи для улучшения взаимопонимания? Клиент -- это и есть приложение, которое человек запускает на своём компьютере.
Далее. Судя по всему клиент (бинарное приложение, собранное под конкретную систему) и приложение в браузере (веб-приложение) каким-то невиданным чудом противопоставляются "общению с другим сервером через API". Это наверное вишенка, чтобы взаимопонимание торжественно достигло своего апогея?Я ничерта не понял! Давайте уточним терминологию, после этого всё встанет на свои места. Итак, веб-приложение -- это...
> Учитывая, что телеграм написан на плюсах с использованием Qt_Клиент_ Телеграма написан на плюсах.
Телеграм - это веб-сервис, к которому может обратиться как плюсовый клиент, так и браузер или вообще другой веб-сервер.
Вы же не будете говорить, что у вас почта написана на плюсах только потому, что используете Thunderbird.
А цепляться за standalone-клиенты, которые сами по себе делают только то, что скажет им сервис, и говорить о каких-то проблемах с работой с тем же самым сервисом через браузер несколько странно, согласитесь.
> Давайте уточним терминологию, после этого всё встанет на свои места. Итак, веб-приложение -- это...
Давайте дружно посмотрим на заголовок новости. Django - фреймворк для веб-приложений, например. С чего обсуждающие так дружно вспоминают Скайп - для меня загадка.
> Телеграм - это веб-сервис, к которому может обратиться как плюсовый клиент, так и браузер или вообще другой веб-сервер.Телеграм - это комплект программ. У него есть сервер, у него есть клиенты. И всё это различные программы, различные приложения.
> Вы же не будете говорить, что у вас почта написана на плюсах только потому, что используете Thunderbird.
Я использую Thunderbird, следовательно мой почтовик написан на плюсах. Выражение "почта написана на..." я не перевариваю, так вообще никто и никогда не говорит.
> А цепляться за standalone-клиенты, которые сами по себе делают только то, что скажет им сервис, и говорить о каких-то проблемах с работой с тем же самым сервисом через браузер несколько странно, согласитесь.
Не понимаю, переведите на русский, пожалуйста.
>> Давайте уточним терминологию, после этого всё встанет на свои места. Итак, веб-приложение -- это...
> Давайте дружно посмотрим на заголовок новости. Django - фреймворк для веб-приложений, например. С чего обсуждающие так дружно вспоминают Скайп - для меня загадка.А скайп вспоминают потому, полагаю, что большинство людей всё-таки понимают под веб-приложением именно что js, работающий в браузере, и общающийся с неким сервисом по сети. Например фейсбуки, вконтакты, скайпы, ну и прочая мутотень -- всё это веб-приложения.
Django -- это фреймворк для веб-приложений, да. Но не всякий комплект клиент-серверных программ является веб-приложением. Вот ssh клиент и сервер есть -- но это не веб-приложение ведь. Xorg -- то же самое. Веб-приложение -- это именно что клиентская часть, написанная на js и работающая в браузере.
UPD: вот, почитайте
https://ru.wikipedia.org/wiki/%D0%92%D0%...
> UPD: вот, почитайтеА вы сами, простите, читали то, на что ссылаетесь?
Там, например, говорится: "Веб-приложение состоит из клиентской и серверной частей"...Главное отличие веб-приложения от классического - именно в архитектуре "клиент-сервер", причем в роли сервера выступает веб-сервер.
Классический Firefox может использовать сервера Мозиллы только для вспомогательных функций и спокойно будет работать без них.
Телеграм, как веб-приложение, без своего веб-сервера превращается в тыкву. Хотя написан он на плюсах и все такое.
>> UPD: вот, почитайте
> А вы сами, простите, читали то, на что ссылаетесь?Давай лучше на ты. Уже достаточно общаемся.
> Там, например, говорится: "Веб-приложение состоит из клиентской и серверной частей"...
Википедия формируется людьми не всегда грамотными. Ты и сам знаешь, что серверная часть не обязательна для веб-приложения (твоё сообщение #40, п.2).
> Главное отличие веб-приложения от классического - именно в архитектуре "клиент-сервер", причем в роли сервера выступает веб-сервер.
Ну правильно. Обычно с одной стороны веб-сервер, с другой -- веб-браузер. Но поскольку серверная часть не обязательна, остаётся только браузер. Веб-приложение -- это приложение, работающее в браузере.
> Классический Firefox может использовать сервера Мозиллы только для вспомогательных функций и спокойно будет работать без них.
> Телеграм, как веб-приложение, без своего веб-сервера превращается в тыкву. Хотя написан он на плюсах и все такое.Я не понимаю, что это так принципиально меняет. Теоретически кто-либо может проанализировать API, которым пользуется клиент Telegram, и написать свою серверную реализацию этого API. Просто никому это не упёрлось. У Telegram есть своё веб-приложение, свой веб-клиент. Но сервер и остальные клиенты -- это уже не веб-приложения. Иначе, если по-твоему, то любой демон, реализующий REST API -- это уже веб-приложение. Но это же не так.
PS: Послушай, Я не имею целью тебя обидеть. Мы уточняем терминологию в силу объективной необходимости: потому что мы друг друга не понимаем из-за разлчных трактовок одних и тех же понятий.
PPS: Всё-таки я бы предложил тебе принять моё определение за основное, поскольку именно у тебя возникают проблемы вида "не понимаю, почему все вдруг стали вспоминать Скайп". Даже если я вдруг неправ (в чём лично я сомневаюсь), если ты примешь моё определение, то будешь априори говорить с людьми на одном языке всегда. Выгодно же.
> Википедия формируется людьми не всегда грамотнымиЗнаю, сам некоторую часть "наформировал" ;)
> серверная часть не обязательна для веб-приложения (твоё сообщение #40, п.2).
И вдобавок оно может вообще не высовываться в веб. Например, если это html-страничка с запрограммированным в ней калькулятором, и только. Однако о таких "как бы приложениях" никто, как мне кажется, особо и не спорит. Пройтись по списку страшилок, на который я отвечал по пунктам - они окажутся просто неприложимы к подобным "браузерным приложениям" - вернее было бы называть их так.
> Но поскольку серверная часть не обязательна, остаётся только браузер
"А вот если бы у рыбы был мех, в нем водились бы блохи..." Выколупываем частности и делаем на их базе обобщения?
> Теоретически кто-либо может проанализировать API, которым пользуется клиент Telegram, и написать свою серверную реализацию этого API. Просто никому это не упёрлось.
Нет. "Просто" это будет написанием Телеграма заново, с нуля.
> любой демон, реализующий REST API -- это уже веб-приложение. Но это же не так.
Отчего же? Это готовая серверная часть веб-приложения. Какой бы к ней ни предполагался клиент, сделать веб-клиента для такого сервиса легко и вполне естественно.
> то будешь априори говорить с людьми на одном языке всегда. Выгодно же.
Не вижу никакой выгоды в том, чтобы говорить на одном языке с людьми, говорящими ерунду или ложь. А это в IT, увы, довольно частое явление. Вам бы хотелось говорить на одном языке, например, с маркетологами Битрикса?
>> Но поскольку серверная часть не обязательна, остаётся только браузер
> "А вот если бы у рыбы был мех, в нем водились бы блохи..." Выколупываем частности и делаем на их базе обобщения?Ну почему же? Мне кажется это логичным. В принципе, ввиду неясности термина, можно договориться в некоторых случаях считать сервер частью веб-приложения. Но покуда мы их не определим, я буду по-прежнему считать, что веб-приложение -- это исключительно клиентская часть, если тут нет возражений.
>> Теоретически кто-либо может проанализировать API, которым пользуется клиент Telegram, и написать свою серверную реализацию этого API. Просто никому это не упёрлось.
> Нет. "Просто" это будет написанием Телеграма заново, с нуля.Ну и что? Остальные клиенты от этого станут несовместимы с этим "заново написанным" телеграмом? Нет, не станут. Потому что это отдельные программы.
Не всякая программа, работающая с сервером через API, реализованный поверх HTTP -- это веб-приложение.>> любой демон, реализующий REST API -- это уже веб-приложение. Но это же не так.
> Отчего же? Это готовая серверная часть веб-приложения. Какой бы к ней ни
> предполагался клиент, сделать веб-клиента для такого сервиса легко и вполне естественно.Вот допустим у меня есть лисповый веб-сервер hunchentoot, и я написал в нём обработчик, чтобы при дёргании curl-ом https://<server-name>/start-vpn, он поднимал бы скрытый сервис vpn. Никто ж не будет утверждать, что я написал веб-приложение? А почему? Потому что я не написал веб-интерфейс к этому делу, каким бы естественным это ни казалось.
>> то будешь априори говорить с людьми на одном языке всегда. Выгодно же.
> Не вижу никакой выгоды в том, чтобы говорить на одном языке с
> людьми, говорящими ерунду или ложь. А это в IT, увы, довольно
> частое явление. Вам бы хотелось говорить на одном языке, например, с
> маркетологами Битрикса?Проблема в том, что менеджеры проектов и маркетологи часто говорят на одном языке. А вот менеджеру проекта объяснить суть бывает полезно. Вообще полезно быть максимально коммуникабельным. Но это, конечно, на твоё усмотрение.
По части же того, что они говорят ерунду и ложь, что уж там... Люди никогда ничего не понимают. Мы вечно ошибаемся.
> я буду по-прежнему считать, что веб-приложение -- это исключительно клиентская часть, если тут нет возражений.Вижу возражение в вашем же тексте. Вы эту часть сами же называете веб-интерфейсом. Хотя правильнее называть ее веб-клиентом.
> Ну и что? Остальные клиенты от этого станут несовместимы с этим "заново написанным" телеграмом? Нет, не станут. Потому что это отдельные программы.
Ага, если к отдельной программе launcher.exe написать заново Skyrim.exe и все, что он реализует - то эта отдельная программа останется с ним полностью совместима.
> Никто ж не будет утверждать, что я написал веб-приложение? А почему? Потому что я не написал веб-интерфейс к этому делу, каким бы естественным это ни казалось.
Веб-клиент вы не написали. А веб-интерфейс вы как раз курлом и дергаете. А можете дергать из браузера или специализированной программы. Потому что веб-сервер, как вы сами сказали, уже написан - в соответствии со стандартами, позволяющими без проблем писать клиентскую часть.
Это и есть суть веб-приложений - отделение фронтэнда, вынос бэкенда на веб-сервер и построенный на веб-технологиях интерфейс между фронтом и бэком.
Собственно, классические приложения тоже бывают без интерфейса пользователя. Запустил программу - действие выполнилось. Не вижу разницы.
Короче, давай тогда так:
Я буду иметь в виду, что существуют люди, считающие, что любой демон, принимающий запросы по HTTP, является веб-приложением...
А ты можешь взять на заметку, что есть люди, которые считают веб-приложением только javascript, выполняющийся в браузере пользователя.Если принять вышенаписанное, то наши позиции становятся более-менее понятны нам обоим, и между ними вроде бы нет особого противоречия.
> любой демон, принимающий запросы по HTTP, является веб-приложениемНе обязательно является.
Он может быть использован в качестве бэкенда для веб-приложения - это вроде как очевидно.> есть люди, которые считают веб-приложением только javascript
И делают это в комментариях к новости про джангу, в тексте которой написано про создание на ней веб-приложений. Ну, ладно, бывает...
JS-майнеры Monero и других криптовалют, пригодных для майнинга на CPU - вишенка на торте в наши дни. Но, кажется мне, это только начало. :)
> А игрушка, купленная вами в Стиме, вам принадлежитигрушка, купленная в ларьке "стопицот игр на одном dvd" точно так же тебе не принадлежит. И что?
> Данные устарели. Современное веб-приложение вполне может работать на компьютере пользователя,
> используя интернет только для синхронизации.но не хочет
> А что ОПАСНОГО может быть в веб-приложении?
то что их ляпают для того, для чего раньше хватало браузера. А вот число запускаемых мной локальных программ - ограничено, и каждая новая вызывает вопросы, нужны ли мы нам.
> Совершенно не факт. Веб-приложение позволяет вынести "тяжелую" часть с вашего компьютера, и у
> клиента будет работать исключительно интерфейсрасскажи это пользователям гугледокса. Где тяжелая часть как раз у пользователя, а докумены достаются гуглю.
> Скорость самого пользователя обычно куда ниже.
скорости не вычитаются, они складываются. Сначала тупит пользователь - а потом пользователь еще и ждет, пока поворочается чудо-веб-приложение, особенно удобно, когда rtt нифига не 50ms.
Частенько это выглядит как "добро пожаловать во времена word for windows 2.0", когда проще и быстрее было импортировать текст, чем пытаться набирать его в этой тормозилке.> То, что для обычного приложения требует rocket science - например, совместная работа
так и остается ей в вебе, если только студент не умеет пользоваться готовой библиотекой.
Причем, если пользовался студент - в вебе все получается гораздо хуже из-за того же rtt.> Веб - это немного другой подход к решению задач.
в основном суть этого подхода - чтобы не только твой софт тебе не принадлежал, но и твои данные тоже достались дяде.
> в основном суть этого подхода - чтобы не только твой софт тебе не принадлежал, но и твои данные тоже достались дяде.Ну, расскажи, какому дяде принадлежат написанные мной сервисы и особенно данные, которые в них обрабатываются.
А то заказчики-то и не в курсе, что, сидя на собственном сайте, они подвергаются столь страшной опасности!Да, есть модель продаж, при которой тебе дают попользоваться готовеньким, предоставляя всю инфраструктуру в комплекте с вендор-локом. Но она, внезапно, не единственная.
> Ну, расскажи, какому дяде принадлежат написанные мной сервисы и особенно данные, которые
> в них обрабатываются.А причем здесь твои сервисы?
Вы, наверное, просто не в курсе. Здесь форум.
Здесь надо читать тред с начала, потому что без этого последний ответ может быть не вполне понятен.
> 1. А игрушка, купленная вами в Стиме, вам принадлежит? Точно принадлежит? Даже если Стим против?Первый пункт про принадлежность ничего не говорит. Если Вы это надумали, то и всё остальное тоже.
Так и я не о принадлежности, а о возможности пользоваться без разрешения "дяди".
Внезапно, веб-приложение может быть под открытой лицензией и запускаться на вашем собственном сервере.Я вообще не о том. Я о том, что нет никакой принципиальной разницы между веб-программированием и любым другим. Нельзя научиться "делать веб-приложения", не умея программировать.
> Я вообще не о том. Я о том, что нет никакой принципиальной
> разницы между веб-программированием и любым другим. Нельзя научиться "делать веб-приложения",
> не умея программировать.а. Так это тоже неверно - опыт миллиона "разработчиков на дельфи".
Кстати, в веб оно тоже умело ;-)
Дельфи - только подтверждение. Есть программисты, а есть формошлепы. Формошлепить тоже можно и для веба, и не для веба. :-)
современные сайты (те, которые так не любят местные телепузики) уже давно не набор хтмл-страниц и какого-нибудь незамысловатого кода, это полноценные приложения. То, что вы не видели никаких приложений на сайтах - это лишь потому что вы пользователь, а не разработчик.
> современные сайты (те, которые так не любят местные телепузики) уже давно не набор хтмл-страниц и какого-нибудь незамысловатого кода, это неполноценные приложения. То, что вы не видели никаких приложений на сайтах - это лишь потому что вы пользователь, а не разработчик.починил.
Бэкэнд уже не приложение?
Сейчас сайт это своеобразный html-терминал, а приложения работают на сервере.
> Например, вместо "url(r'^articles/(?P‹year›[0-9]{4})/$', views.year_archive)" теперь можно указать "path('articles/‹int:year›/', views.year_archive)".О исправили фьюче-баг что цифр в году может быть больше чем 4. :D
Цифры важны. Замечательный релиз!
Бессмертные оценят.
> Бессмертные оценят.Если только за следующие 8000 лет не потеряю голову, обязательно посещу могилу разработчиков.
Прекрасный веб-фреймворк!
> Прекрасный веб-фреймворк!особенно, если выбирать между django, django и django...
А так, Rails, Hanami или Phoenix будут и по-лучше, по-гибче, по-быстрее, по-надёжнее и по-удобнее в написании кода.
Ну, почему же " между django, django и django", есть ведь и другие. Например, Flask. Я его опробовал недавно и могу сказать что он меня определенно впечатлил.
Сегодня Flask, а завтра питон продашь....Сказано пользоваться джангой - должны пользоваться джангой.... Непонятно, зачем питон использовать в вебе вообще. Стар он для этого.
> Сказано пользоваться джангой - должны пользоваться джангой.... Непонятно, зачем питон
> использовать в вебе вообще. Стар он для этого.Скорее не стар, а это не его назначение. Стихия питона - локальные скрипты.
> Скорее не стар, а это не его назначение. Стихия питона - локальные
> скрипты.Даже для локальных скриптов он стар. Корявости работы со строками (сравните с Ruby). Нет возможности формальной валидации кода, как в Go. Несовместимые версии (до сих пор основные линуксы типа Centos живут с 2.7 по-умолчанию). Собственно, чем он лучше баша, кроме того, что его, частенько, надо ставить?
> Корявости работы со строками (сравните с Ruby).В каком месте в Python 3 она корявая?
>> В каком месте в Python 3 она корявая?ну хотя бы в том, что до сих пор по-умолчанию в линуксах 2.7
Дык тогда и ребе 1.9! :)
А с учётом того что ребе проги работают только на машине девелопера ... и если вам повёзет то он грамотно засунул это в докер ... то лучше уж пестон :\
> Скорее не стар, а это не его назначение. Стихия питона - локальные скрипты.Которые отваливаются при каждом апгрейде системы. И правда стихия.
>> Скорее не стар, а это не его назначение. Стихия питона - локальные скрипты.
> Которые отваливаются при каждом апгрейде системы. И правда стихия.2.6 -> 2.7? А, ну да, вопросов нет.
Отваливаются без обновления самого Python? Так вы не язык ругайте, а писателей либ без обратной совместимости.
ничего, что у большинства других скриптовых языков проблем с обратной совместимость нет или почти нет?
Lua, Ruby, PHP, Perl - проблемы есть. Про JS не знаю, не писал на нём.
Какие проблемы у Lua, Ruby, PHP, Perl?
foreach - не забудем, не простим!
Возьми проект на PHP 4 и запусти его без рефакторинга на PHP 5. Удачи.
Или с пятого на седьмой - при должном качестве кода портировать будет не особо сложно, но это всё равно требуется.Или Lua 5.1 - > 5.2 -> 5.3. Будь всё совместимым, в Gentoo не было бы до сих пор 5.1.
С перлом проще, но был у меня на Генте софт, который между 5.20 -> 5.22 -> 5.24 проходилось патчить.
Софт на Ruby 1.9 тоже не работал на 2.x без таких же правок, как и во всех случаях выше.
> С перлом проще, но был у меня на Генте софт, который между 5.20 -> 5.22 -> 5.24 проходилось патчить.очень смешно, давайте примеры кода: 5.024 просто обязан быть обратно совместим с любым кодом вплоть до 5.000 (за исключением экспериментальных фич, в итоге не принятых)
ЕМНИП то всё-таки были изменения некоторых очень редко используемых, но не экспериментальных синтаксических конструкций. Причем сначала объявлялось deprected и лишь спустя много версий и лет наконец удалялось/изменялось.
> Какие проблемы у Lua, Ruby, PHP, Perl?Из этого списка серьезных проблем с обратной совместимостью нет только у Perl. На нем действительно большая часть кода работает с 5.8(это 2002-й год и всё еще иногда встречающийся RHEL/Centos 5) до последних версий. Lua в основном используется как встроенный язык и как следствие проблемы совместимости его в большинстве случаев не касаются. А вот с Ruby и PHP ситуация ничем не лучше, а может даже хуже питона.
Еще с обратной совместимостью хорошо у так нелюбимого всеми javascript. Конечно если мы говорим про сам язык, а не про экосистему ноды.
>> А вот с Ruby и PHP ситуация ничем не лучше, а может даже хуже питона.У Ruby было только одно большое изменение - 1.8 -> 1.9. Примерно 10 лет назад. Когда сделали полный переход на UNICODE, а заодно поправили кучу других мелочей (именно мелочей). В остальном изменения только в сторону расширения или устранения неоднозначностей, которые и так обходили стилем программирования.
А что тогда? PHP? Perl? JS? Вы серьёзно? Ruby может быть, но имеет свои проблемы, и разумная альтернатива всё равно нужна.Java? Для не слишком сложных проектов это перебор. Да и для сложных зачастую не лучший выбор.
Компилируемые языки (в т.ч. JVM) в вебе - удовольствие малопопулярное (кроме, пожалуй, Java), хоть и интересное, но инфраструктура там послабее, чем у некопилируемых.
> А что тогда? PHP? Perl? JS? Вы серьёзно? Ruby может быть, но
> имеет свои проблемы, и разумная альтернатива всё равно нужна.Под веб? Ruby, Go, Js
+ Crystal, если нужна статическая типизация
+ Elixir, если нужна скорость, но хочется писать в стиле Ruby
> JsСпасибо, но я не г-ноед. JS буду применять только там где без него нельзя, а там, где можно без него - выберу что-то другое.
> + Crystal, если нужна статическая типизация
> + Elixir, если нужна скорость, но хочется писать в стиле RubyПокажите мне сколько компаний на просторах СНГ имеют специалистов по этим языкам. Почему не сразу Groovy + Grails? Почему не Clojure + ClojureScript? Почему не Nim или Ceylon? Их-то точно никто не умеет, кроме пары-тройки компаний-единорогов на страну! Конечно, для души, а не за деньги, можно писать на чем угодно, и не только вышеперечисленном.
> Ruby
Раз Ruby, тогда и Python. У него, в отличие от Ruby, есть не только один major framework (Django), а и весьма популярные Pyramid и Flask. Как ни странно, лично мне за три года периодического кодописания на Питоне приходилочь работать с джангой меньше, чем с пирамидой или фласком.
Кстати, если в Руби есть другие популярные веб-фреймворки кроме рельс, то развенчайте моё заблуждение, буду только рад тому, что язык поддерживает жизнеспособность не завязываясь на единственный инструмент.
> Go
Да, хорошо, но ему ещё предстоит обрести популярность как язык, который "хорош для веба" (на котором удобно писать бэкэнд). Сейчас инфраструктура (либы, инструменты и особенно фреймворки) для веба пока слабенькая если сравнивать с Python или Ruby, но это вопрос времени. Всё очень активно пилится прямо сейчас.
> Кстати, если в Руби есть другие популярные веб-фреймворки кроме рельс, то развенчайте моё заблуждение, буду только рад тому, что язык поддерживает жизнеспособность не завязываясь на единственный инструмент.Sinatra, Hanami, middleman...
Спасибо что напомнили о Синатре (про другие не слышал). Я надеялся что всё не так плохо и что я просто заблуждаюсь. :)
Ruby на поприще Rails силён и мощен, но вне Rails практически мёртв, что вызывает нежелание изучать его вообще. Кроме того, не один знакомый рубист возился-возился с mri, но в итоге перешёл на JRuby, потому что, внимание, MRI тормозит. Ну а ещё потому что JRuby это энтепрайзненько. В итоге благодаря JRuby один из них начал учиться в интеграцию кода на Руби и Джаве, и через полтора года свалил в Джаву насовсем.
>Непонятно, зачем питон использовать в вебе вообще. Стар он для этого.Очень тонкая шутка про современный веб.
Особенно с учётом того, что JS младше всего на 4 года.
> Особенно с учётом того, что JS младше всего на 4 года.Это не так. Идеология питона - в 70-х. JS сделан на базе языков, актуальных в 90-е.
> Ну, почему же " между django, django и django", есть ведь и
> другие. Например, Flask. Я его опробовал недавно и могу сказать что
> он меня определенно впечатлил.Слушайте ну не позорьтесь ... Flask это микрофреймворк... Не сравнивайте грабли с трактором.
И если уж речь о Flask то во всем грамотном мире принято считать потоковые переменные злом,
а во Flask это опять таки достоинство ... Ну что за ерундень опять ...
Я думал что Flask это небольшой, но не микрофреймворк. Микро - это Bottle. Или это уже нано?
В чем-то одном его много кто превосходит. Но джанго -- это прекрасный набор "всё в одном", аналогов которому нет.
Я б не стал так категорично.
http://web2py.com
Самый толерантный фреймворк https://code.djangoproject.com/ticket/22667
> Самый толерантный фреймворк https://code.djangoproject.com/ticket/22667Наоборот нетолерантный. Дискриминируют рабовладельческий строй.
Не понимаю чего все так топят и хвалят эту django. По мне дак тот же flask и pyramid в разы лучше фреймворки.
> Не понимаю чего все так топят и хвалят эту django. По мне
> дак тот же flask и pyramid в разы лучше фреймворки.Да, в них есть определенная прелесть. Но джанга сейчас, это без малого Ынтерпрайз. А Ынтерпрайз это не обязательно самое крутое, но обязательно самое массовое и вылизанное.
> Да, в них есть определенная прелесть. Но джанга сейчас, это без малого
> Ынтерпрайз. А Ынтерпрайз это не обязательно самое крутое, но обязательно самое
> массовое и вылизанное.Где ж вы живёте с таким ынтырбпрайзом.... Все питоновские фреймворки в целом менее популярны, чем JS Express, Ruby on Rails или PHP Lavarel/Yii.....
Годность не всегда соотносится с популярностью. Миллионы мух, которые не могут ошибаться, всегда нам про это напоминают.
Дальше следует отметить про наш индивидуальный путь питоностроения, независимо от того, используют ли его ещё за пределами РФ
> PHP YiiБгг. За пределами ex-USSR об нем не знает примерно никто.
А если уж говорить о PHP - то прежде всего стоит упомянуть Symfony.
А Express вообще не стоит ставить в этот ряд, это весьма низкоуровневая штуковина, сравнивать можно с HTTP Core-фреймворками типа Slim или Sinatra.Впрочем, для node полновесных application frameworks-то до недавнего времени и вообще не было. Недавно вот только NestJS появился.
flask и django просто разные, с немного разным применением. Вообще оба хорошие.
И пирамида. Сложная, но оправдано из-за хреновой тучи предоставляемой ею возможностей. Применять её там, где Django или Flask хватает с головой - бессмысленно, но для проектов со сложной бизнес-логикой и без Java - самое то. Впрочем и увы, тенденции указывают на то, что около-Zope-тусовка стареет без внимания новых участников, покрывается мхом, отсыхает, отваливается и окаменевает. Пирамида из этого всего пока самая живая и служит столпом, который держит всё.
> Не понимаю чего все так топят и хвалят эту django. По мне
> дак тот же flask и pyramid в разы лучше фреймворки.Да никто его не хвалит. В том то и дело приходит начальник и говорит так у нас нет процесса потому как я понтовщик на Mitsubisy не понимаю в процессах а еще у нас тех лид мудик-анимешник программисты студенты геймодро#@ы и нужно заказчикам сайтик по быстрому ... И тут выбегает маленький Ален и говорит а вот вам Django и все конечно рады так как за них уже решили как и куда файлы создавать и главное готовый ORM ... А задро-там вроде гиков которые курят там всякие Piramid, Flaks, Bootle не дай бог еще какие-нить FCGI+Alchemy или чего еще долезут до Twisted, Tornado или aiohttp так вообще сразу в даль будут посаны ибо дорого долго и как-то непонятно чего со всей этой лапшой потом делать ... ВОт и все популярность... Я бы назвал на безбабье и рак лебедь ...
Прекрасный пример того, что спагетти можно писать на любом языке. Даже на русском.
> ну хотя бы в том, что до сих пор по-умолчанию в линуксах 2.7и? Это типа минус? :В Еще одна жертва маркетинговой нумерации.
> Корявости работы со строками (сравните с Ruby).
конкретные примеры корявости в студию
> Нет возможности формальной валидации кода, как в Go.
а в руби есть? о_О
> Несовместимые версии (до сих пор основные линуксы типа Centos живут с 2.7 по-умолчанию).
такое есть у любого ЯП. Я вот столкнулся с попыткой перевода проекта на руби 1.8 на 1.9 удовльствие еще то. Так что не надо тут заливать про совместимость
> Собственно, чем он лучше баша
тем, что python
> кроме того, что его, частенько, надо ставить?
в том же centos он уже идет в минимальной поставке в отличие от ruby/golang