@proGO

« Назад

Страница 310 из 1674

Далее »

Vladimir

24.11.2016
08:47:58

которые обычно не в состоянии дать данные в нужном виде просто

Kirill

24.11.2016
08:48:37

которые обычно не в состоянии дать данные в нужном виде просто

дык запрашивай нужное API сам

договаривайся

проблемы же нет

Google

Dmitri

24.11.2016
08:50:51

1. Тк стоимость разработки как раз копеечная, уйма специалистов с фронта. 2. Не всегда, на сегодняшний день эти технологии в чистом виде отходят на задний план, посмотрите на модульный css в react 3. Никто не говорит "похоронить". Я говорил про то что они не нужны большинству для решения ежедневных задач, пусть даже и из 1 кнопки(сегодня это одна кнопка, завтра SPA из овердофига страниц, так что почему бы и нет) 4. Плюсы способны покрыть большинство минусов для наиболее распространенных задач. Снова, зачем мне тратить драгоценное время на изучение qt или чего-то другого если я могу использовать то что знаю и оставить качество на достойном уровне? 5. В таких вещах - может быть, но когда кодовая база разрастается то разобраться становится тяжелее. Я за ним не следил, может с 2010 года там много всего поменялось, но в тот момент это была "та ещё лапша"

1. Во! Именно стоимость. А мне все скорость-скорость, прогресс и все такое... 2. Дело в том, что конечному браузеру, в итоге, тупо насрать на все эти модульные css-ы и прочие транспайлеры. Выглядит это так: мы пишем красивый код, который затем специальной софтинкой преобразуется в какое-то внутреннее представление, потом автоматически переводится на другую версию языка, затем уже на уровне фреймворка это все собирается в какую-то конструкцию на html+css+js в чистом виде (да-да, со всеми костылями и прочими "обратными совместимостями") и уже эта каша, переведенная по дороге на 5 диалектов 8 языков идет в браузер. Оптимально, ага. 3. Насчет "никто не говорит похоронить" - чуть выше пролистайте. Говорит. То, что они не необходимы для большинства задач, тут соглашусь. А вот для "absolute beginner", который хочет написать софтинку с 1 кнопкой касаться веб-технологий очень не рекомендуется. Жопа получится. В тот же Qt он реально быстрее "войдет". 4. Ну, я про то, что основные факторы: "доступность" специалистов, недороговизна + достаточность для большинства задач. Не в "прогрессивности" секрет. 5. Ну т.е. как раз QML и QtQuick вы, по большей части, упустили. Сильно они подросли. Замысел как раз в разделении ГУЯ и самого приложения, причем в гуе QML (практически, диалект json) + js.

Vladimir

24.11.2016
08:53:28

дык запрашивай нужное API сам

моя люьимая отмазка: «ты что. у нас же не реляционная БД, я не могу просто взять и сделать фильтр по этому параметру»

Ivan

24.11.2016
08:53:38

1. Во! Именно стоимость. А мне все скорость-скорость, прогресс и все такое... 2. Дело в том, что конечному браузеру, в итоге, тупо насрать на все эти модульные css-ы и прочие транспайлеры. Выглядит это так: мы пишем красивый код, который затем специальной софтинкой преобразуется в какое-то внутреннее представление, потом автоматически переводится на другую версию языка, затем уже на уровне фреймворка это все собирается в какую-то конструкцию на html+css+js в чистом виде (да-да, со всеми костылями и прочими "обратными совместимостями") и уже эта каша, переведенная по дороге на 5 диалектов 8 языков идет в браузер. Оптимально, ага. 3. Насчет "никто не говорит похоронить" - чуть выше пролистайте. Говорит. То, что они не необходимы для большинства задач, тут соглашусь. А вот для "absolute beginner", который хочет написать софтинку с 1 кнопкой касаться веб-технологий очень не рекомендуется. Жопа получится. В тот же Qt он реально быстрее "войдет". 4. Ну, я про то, что основные факторы: "доступность" специалистов, недороговизна + достаточность для большинства задач. Не в "прогрессивности" секрет. 5. Ну т.е. как раз QML и QtQuick вы, по большей части, упустили. Сильно они подросли. Замысел как раз в разделении ГУЯ и самого приложения, причем в гуе QML (практически, диалект json) + js.

<html><head><title> Моя кнопочкааааа</title></head><body><button onclick="MyHandler();">Кнопочко!</button></body></html> Или есть мнение, что "absolute beginner" на GTK\QT напишет лучше? )

моя люьимая отмазка: «ты что. у нас же не реляционная БД, я не могу просто взять и сделать фильтр по этому параметру»

3.14здить ногами по 2.7блу

Dmitri

24.11.2016
08:55:39

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

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

Ivan

24.11.2016
08:57:13

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

Да, только ты должен собирать этот текст из пользовательского шаблона, который он накидал в твоём wisywig'e, со всей склонной ему извращенностью, и речь изначально шла про этот гребанный визувиг

Грубо говоря ckeditor, только для email

Dmitri

24.11.2016
08:57:57

<html><head><title> Моя кнопочкааааа</title></head><body><button onclick="MyHandler();">Кнопочко!</button></body></html> Или есть мнение, что "absolute beginner" на GTK\QT напишет лучше? )

Rectangle { anchors.fill: parent Button { width: parent.width / 3 * 2 height: parent.height / 3 anchors.centerIn: parent } }

Судзумия

24.11.2016
08:58:47

На самом деле, моя больная тема в QML -- взаимодействие anchors и Layouts

Легче переписать всю разметку, чем поправить что-то в том, как они должны друг друга любить

Dmitri

24.11.2016
08:59:26

На самом деле, моя больная тема в QML -- взаимодействие anchors и Layouts

Собственно, не смешивать на одном уровне... Да, поначалу нетрививально

Ivan

24.11.2016
08:59:30

Rectangle { anchors.fill: parent Button { width: parent.width / 3 * 2 height: parent.height / 3 anchors.centerIn: parent } }

Я не понял, это сильно проще или сильно легче? =)

Dmitri

24.11.2016
08:59:54

Я не понял, это сильно проще или сильно легче? =)

Я не понял, это сильно сложнее или сильно тяжелее?

Google

Судзумия

24.11.2016
09:00:08

Я не понял, это сильно проще или сильно легче? =)

Это не использует наследие XML, и поэтому мне нравится :)

Ivan

24.11.2016
09:00:40

Я не понял, это сильно сложнее или сильно тяжелее?

Отсюда вывод для "absolute beginner" срать на чём формошлепствовать

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

А как же превью? Мы не касаемся отправки письма

Dmitri

24.11.2016
09:03:37

Да, только ты должен собирать этот текст из пользовательского шаблона, который он накидал в твоём wisywig'e, со всей склонной ему извращенностью, и речь изначально шла про этот гребанный визувиг

Собственно, из вариантов: 1. Определяешь свое "оптимальное" представление формата этого шаблона. Берешь за базу какую угодно разметку. 2. Собираешь непосредственно сообщение на стороне сервера, где шаблон и содержимое - тупо два объекта. 3. Выходом из шаблона+содержимое имеешь любой допустимый выходной формат тупо плагином/реализацией интерфейса. Промежуточное представление решает многое, смею вас заверить. Таким образом имеем фронт, который без изращений умеет один формат сообщений + бэк, который умеет из этого формата собрать нужное любым из существующих инструментов. Чо не так-то?

Это не использует наследие XML, и поэтому мне нравится :)

Ну да, оно более человекочитаемо, например. Да и в принципе удобней.

Отсюда вывод для "absolute beginner" срать на чём формошлепствовать

Собственно, да. Разница в том, что у него получится на выходе.

А как же превью? Мы не касаемся отправки письма

Превью строить на внутреннем представлении письма. Еще раз повторяю, на фронте некуй делать всем возможным извращениям с форматами отправки письма. На фронте - тупо один формат с нужным вам функционалом. Причем, в случае десктопного приложения - это, как правило, объект + интерфейс, с которым реально достаточно удобно работать. Приведение этого к html, plaintext, xhtml, чтонибудьещетам - не дело фронта.

Ivan

24.11.2016
09:10:09

Превью строить на внутреннем представлении письма. Еще раз повторяю, на фронте некуй делать всем возможным извращениям с форматами отправки письма. На фронте - тупо один формат с нужным вам функционалом. Причем, в случае десктопного приложения - это, как правило, объект + интерфейс, с которым реально достаточно удобно работать. Приведение этого к html, plaintext, xhtml, чтонибудьещетам - не дело фронта.

Ё-моё, нужно не тупо показать превью, знаешь что значит слово конструктор? wisywig? Юзер конструирует шаблон, причём сразу видит примерный результат, пинать бэк на каждый чих - ебануться можно, а ещё у юзера есть кнопочка "превью" на которую тоже нехер пинать бэк. Бэк сохраняет шаблон (в промежуточном виде на базе json), и уже при отправке этого письма делает в шаблоне автоподстановки, переводит в хтмл и пуляет на smtp

Здесь нет готовых шаблонов, точнее они есть, в примерах, есть готовые связки "блоков", но юзер может забить на всё это и использовать "базовые блоки" и сделать свой дизайн и в любом случае итоговый хтмл должен быть валидным, адаптивным и отображаться на любом дерьме мамонта правильно, а юзер должен сразу увидеть _примерный_ результат, а по нажатию кнопочки превью _точный_ результат

Судзумия

24.11.2016
09:15:15

Точный, наверное, стоит на беке формировать

Ivan

24.11.2016
09:15:21

А теперь расскажи как это сделать на QT без webview и прочего

Точный, наверное, стоит на беке формировать

Если правильно сделать - пофиг где, мы обошлись в этом плане без бэка, немного его разгрузив

Dmitri

24.11.2016
09:16:51

Ё-моё, нужно не тупо показать превью, знаешь что значит слово конструктор? wisywig? Юзер конструирует шаблон, причём сразу видит примерный результат, пинать бэк на каждый чих - ебануться можно, а ещё у юзера есть кнопочка "превью" на которую тоже нехер пинать бэк. Бэк сохраняет шаблон (в промежуточном виде на базе json), и уже при отправке этого письма делает в шаблоне автоподстановки, переводит в хтмл и пуляет на smtp

Знаю и про wisiwyg и про шаблоны, и вообще достаточно много навидался. Один только вопрос: нахрена тебе на фронте xhtml и прочее? Понимаешь ведь, что пользователь не обязательно должен видеть именно то, что отправится? Он должен видеть что-то, что выглядит ровно как отправленное сообщение, не больше и не меньше, иначе при чем тут wisiwyg. Возможно, мы с тобой по-разному понимаем задачу (я ее вообще только в твоем пересказе видел), но: 1. Зачем тебе на фронте вормировать xhtml? 2. Почему на фронте не иметь тупо 1 представление для шаблона и 1 для данных письма? Зачем извращаться, если тебе нужно показать пользователю, как оно будет выглядеть? Выбери один формат, удобный для твоей задачи.

Здесь нет готовых шаблонов, точнее они есть, в примерах, есть готовые связки "блоков", но юзер может забить на всё это и использовать "базовые блоки" и сделать свой дизайн и в любом случае итоговый хтмл должен быть валидным, адаптивным и отображаться на любом дерьме мамонта правильно, а юзер должен сразу увидеть _примерный_ результат, а по нажатию кнопочки превью _точный_ результат

И в чем конкретно здесь тебе поможет вебня?

А теперь расскажи как это сделать на QT без webview и прочего

Вот, в Qt WebView есть. Т.е. все, что можно в браузере, в Qt сделать можно. В обратную сторону оно не работает.

Ivan

24.11.2016
09:18:43

Вот, в Qt WebView есть. Т.е. все, что можно в браузере, в Qt сделать можно. В обратную сторону оно не работает.

Ок, зачём тянуть Qt с WebView, если можно сразу в браузер.

Dmitri

24.11.2016
09:20:04

Ок, зачём тянуть Qt с WebView, если можно сразу в браузер.

Ок, зачем тянуть браузер, если можно в Qt?)

Ivan

24.11.2016
09:22:32

Ок, зачем тянуть браузер, если можно в Qt?)

На девайсе кути может и не быть, а браузер 99.9% будет

Судзумия

24.11.2016
09:23:24

Ага, и девайс испекается

Пытаясь превью в браузере сделать

Google

Ivan

24.11.2016
09:25:39

Пытаясь превью в браузере сделать

Хм... девайсина с 512Метрами, ведроидом и MT6572M даже не напрягается, ЧЯДНТ?

Знаю и про wisiwyg и про шаблоны, и вообще достаточно много навидался. Один только вопрос: нахрена тебе на фронте xhtml и прочее? Понимаешь ведь, что пользователь не обязательно должен видеть именно то, что отправится? Он должен видеть что-то, что выглядит ровно как отправленное сообщение, не больше и не меньше, иначе при чем тут wisiwyg. Возможно, мы с тобой по-разному понимаем задачу (я ее вообще только в твоем пересказе видел), но: 1. Зачем тебе на фронте вормировать xhtml? 2. Почему на фронте не иметь тупо 1 представление для шаблона и 1 для данных письма? Зачем извращаться, если тебе нужно показать пользователю, как оно будет выглядеть? Выбери один формат, удобный для твоей задачи.

Грубо говоря - итоговая цель что-то на подобие вот этого: https://mosaico.io/ только понятней, удобней и с не которыми дополнительными фичами, и юзер не ограничен набором готовых блоков, а имеет в своем распоряжении "атомарные" блоки, из которых может собрать любую ересь

Судзумия

24.11.2016
09:29:44

Хм... девайсина с 512Метрами, ведроидом и MT6572M даже не напрягается, ЧЯДНТ?

А моя от современных бложиков очень даже напрягается

(при том, что она даже помощнее будет)

Ivan

24.11.2016
09:30:42

А моя от современных бложиков очень даже напрягается

Ну, на современных бложиках моя тоже напрягается, дело то ведь не в том, что делает девайсина, а как код написан

Я и на Go в несколько строк кода могу сожрать всю память и нагрузить проц =)

Dmitri

24.11.2016
09:32:53

Я и на Go в несколько строк кода могу сожрать всю память и нагрузить проц =)

Ну, так можно на любом языке.

Ivan

24.11.2016
09:33:56

Об этом и говорю

Dmitri

24.11.2016
09:40:15

Об этом и говорю

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

)))

А моя от современных бложиков очень даже напрягается

От современных бложиков у меня десктоп вполне себе напрягается(((

Судзумия

24.11.2016
09:43:28

И это грустно

Ivan

24.11.2016
09:43:59

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

mutt - forever =)

Dmitri

24.11.2016
09:45:34

С бложиками - яркая иллюстрация подхода "а давайте все перенесем на сторону браузера")

Имхо, чем "тупее" клиент, тем лучше

Ivan

24.11.2016
09:46:05

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

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

Имхо, чем "тупее" клиент, тем лучше

Увы, но, современные реалии вынуждают делать умных, толстых клиентов

Dmitri

24.11.2016
09:48:11

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

В данной конкретной ситуации, вероятно, вы правы. Задача изначально - часть, как я понимаю, веб-сервиса. Единственное, что мне показалось странным - решение таки унести логику на клиента. ИМХО, нефиг ей там делать, но, возможно я не прав, и у вас были на то веские основания. А за "вместо js была бы написана на более адекватном языке" - прям респект)

Ivan

24.11.2016
09:49:03

Хотя лично для меня лучший фронт - http://lib.ru/ но к сожалению, для бизнеса это не прокатит нынче

Dmitri

24.11.2016
09:49:05

Увы, но, современные реалии вынуждают делать умных, толстых клиентов

Вот это меня и пугает... Умный толстый клиент в браузере - мне страшно.

Google

Ivan

24.11.2016
09:50:05

В данной конкретной ситуации, вероятно, вы правы. Задача изначально - часть, как я понимаю, веб-сервиса. Единственное, что мне показалось странным - решение таки унести логику на клиента. ИМХО, нефиг ей там делать, но, возможно я не прав, и у вас были на то веские основания. А за "вместо js была бы написана на более адекватном языке" - прям респект)

А тут логика простая - либо на каждый чих юзера гонять километры json между фронтом и бэком либо вынести логику на фронт

Dmitri

24.11.2016
09:51:10

Вы же понимаете, что чем мельче задача, решаемая js в браузере, тем меньше заметны недостатки транслируемых языков (таки накладные расходы и некоторая тормознутость). На определенном пороге js может стать неприемлемым. И тут, уж извините, добро пожаловать в старый добрый натив)

Vladimir

24.11.2016
09:51:35

на каком пороге?

Ivan

24.11.2016
09:51:36

При прочих равных - гонять json черевато тем, что мы вносим задержки в UI, которые там нафиг не нужжны

Dmitri

24.11.2016
09:51:38

А тут логика простая - либо на каждый чих юзера гонять километры json между фронтом и бэком либо вынести логику на фронт

Во, кстати, по поводу json. GRPC в браузере завести можно?

Denis

24.11.2016
09:51:54

скоро заведут

Admin

ERROR: S client not available

Denis

24.11.2016
09:52:55

https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-WEB.md

Ivan

24.11.2016
09:53:38

Во, кстати, по поводу json. GRPC в браузере завести можно?

Пока только, насколько мне известно, используя ws gateway, хотя возможно инфа устарела

Мы REST юзаем

Dmitri

24.11.2016
09:53:58

на каком пороге?

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

Ivan

24.11.2016
09:55:07

Просто надо уметь выбирать стэк под задачу,

Dmitri

24.11.2016
09:56:44

Печально, что веб-стек все чаще применяется где ни попадя

Ivan

24.11.2016
09:56:49

Ну и код писать адекватно. По факту - тот же билдер делает гораздо больше полезных вещей чем любой бложик (на стороне клиента), при этом, как я выше говорил, в отличии от большинства бложиков не тормозит даже на моём ведроиде за 50$

Хотя в прод на мобилки уйдет только выбор сохраненных шаблонов, ибо нефиг

Kirill

24.11.2016
11:15:41

3.14здить ногами по 2.7блу

плюсую

Антон

24.11.2016
13:32:46

Добрый день!

Хотел бы задать несколько вопрос про управление зависимостями и пакетами, про папку vendor и все такое. Скажите, пожалуйста, как на сегодняшний день максимально правильно импортировать свои и сторонние пакеты? Использую папку vendor для хранения своих пакетов, однако при попытки запустить приложение получаю ошибку cannot find package "shared/database" in any of: C:\Go\src\shared\database (from $GOROOT) C:\golang_server\src\shared\database (from $GOPATH)

Jonh

24.11.2016
14:42:05

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

Письма должны быть plaintext

Kirill

24.11.2016
14:43:13

Письма должны быть plaintext

ага. вот желаю тебе такую же зарплату, как конверсия от этих твоих plaintext писем.

Google

Jonh

24.11.2016
14:43:39

ага. вот желаю тебе такую же зарплату, как конверсия от этих твоих plaintext писем.