Здравствуйте, Serginio1, Вы писали:
НС>>Вопрос не по адресу. S> Ну почему, У тебя есть опыт и знания.
Не в области 1С
S> Вот экспорты импорты как раз иногда проще писать на .Net так как есть уже готовые библиотеки и их нужно тупо использовать. Например тот же EDI.
Ну вот про это и напиши, только без закапывания в подробности.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
НС>>>Вопрос не по адресу. S>> Ну почему, У тебя есть опыт и знания.
НС>Не в области 1С
У меня у самого есть знания в этом направлении. Мне как раз нужет .Net S>> Вот экспорты импорты как раз иногда проще писать на .Net так как есть уже готовые библиотеки и их нужно тупо использовать. Например тот же EDI.
НС>Ну вот про это и напиши, только без закапывания в подробности.
Спасибо. Если вдруг что то всплывет то пиши. Буду премного благодарен.
Например очень популярна библиотека склонения имен. Что такого плана.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>> Что в твоем понимании статические файлы? 304 тоже файл при чем статический. _>>Эээ, что? S> А то, что это ответ с кодом 304. Он статичен и не изменяется S>
И где тут файл? )
S>>> Ты знаешь, что такое 1С? _>>Ты про нашу it-компанию или про что? ) S> Да и чем она занимается. Это надстройка над БД, где все изменяется с той или иной периодичностью.
Ты хочешь сказать, что в твоём случае данные (даже статические) будут в любом случае только в БД? Ну так тогда у тебя собственно и нет выбора в технологии и тебе потребуется очень мощная машина при высокой посещаемости. Только тогда непонятно какое это всё имеет отношение к обсуждаемой теме?
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
S>>>> Что в твоем понимании статические файлы? 304 тоже файл при чем статический. _>>>Эээ, что? S>> А то, что это ответ с кодом 304. Он статичен и не изменяется S>>
_>И где тут файл? )
Response
S>>>> Ты знаешь, что такое 1С? _>>>Ты про нашу it-компанию или про что? ) S>> Да и чем она занимается. Это надстройка над БД, где все изменяется с той или иной периодичностью.
_>Ты хочешь сказать, что в твоём случае данные (даже статические) будут в любом случае только в БД? Ну так тогда у тебя собственно и нет выбора в технологии и тебе потребуется очень мощная машина при высокой посещаемости. Только тогда непонятно какое это всё имеет отношение к обсуждаемой теме?
Еще раз есть куча констант, справочников которые меняются редко и есть смысл их сохранять на клиенте или только часто используемые данные.
Учитывая, что такие данные если будут занимать гигабайт то и с этим справится даже мобильный телефон
Кстати не всегда высокая посещаемость достаточно около сотни клиентов и при этом базы всего несколько десятков гигов. А с этим справляется и обычный ненавороченный и даже плюшевый сервер.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alex_public, Вы писали:
_>>>Мелкими вкраплениями я назвал собственно скриптовой код на C#, который пишет разработчик игры. А так да, управляемого кода там приличный объём, хотя бы потому, что там жирный кусок реализации .net'a висит для обеспечения работоспособности C#. ))) A>>Как будто в нативном .exe нет жирного куска статически слинкованных стандартных библиотек, разного middle-ware и прочих самописных подсистем, которые для конкретной игры не нужны, но в .exe всё равно занимают место. Например, там есть как минимум три рендера под разные графические API, два физических движка, две подсистемы анимации, две подсистемы UI, две системы частиц, подсистема динамического глобального освещения, SpeedTree... Ни одна игра всё это вместе не использует, но в движке оно лежит.
_>Дело не в этом, а в том, что собственно игровые скрипты (которые пишутся на C# или JS) занимают очень маленькую часть исполняемого кода игры.
Эта малость никого не интересует. Скрипты появляются в силу различных циклов разработки, например движка и поведения которое использует движок.
_>Я немного не об этом. Я имел в виду, что если кто-то напишет игру только на JavaScript, то может ему не надо будет тащить с собой все эти мегабайты ради поддержки работы C#? Или там нельзя так почистить движок и он по любому тащит всё, даже если оно не используется?
Любая современная система тащит с собой кучу лишнего. Проще держать готовые длл, чем пилить супер-умный линкер. И собственно в JS именно такой подход не работает. Потому приходится тащить всё, а это значит, код должен быть как можно меньшим.
Вот будет способ влёт грузить 100мб файлы, можно будет хоть десяток QT портировать.
Здравствуйте, Serginio1, Вы писали:
_>>И где тут файл? ) S>Response
Response — это какая-то переменная в твоём коде. Причём тут файл?
S> Еще раз есть куча констант, справочников которые меняются редко и есть смысл их сохранять на клиенте или только часто используемые данные. S>Учитывая, что такие данные если будут занимать гигабайт то и с этим справится даже мобильный телефон
Я что-то не понял, а что ты собственно называешь клиентом? Если бразуер, то он как раз не умеет сохранять никакие данные (не считая копеек в куках). Если же ты намекал на кэш браузера, то это временное явление и сильно зависящее от настроек пользователя (к примеру у меня оно вообще отключено — зачем попусту насиловать ssd при такой оперативке и инете как у меня). Если же ты имеешь в виду не браузер, а некое приложение, то тут уже вообще всё по другому становится.
S>Кстати не всегда высокая посещаемость достаточно около сотни клиентов и при этом базы всего несколько десятков гигов. А с этим справляется и обычный ненавороченный и даже плюшевый сервер.
Ну и кому может быть интересно это обсуждать? ) Для таких требований вообще не важно что и как делать. )))
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>И где тут файл? ) S>>Response
_>Response — это какая-то переменная в твоём коде. Причём тут файл?
Это поток на клиента.
S>> Еще раз есть куча констант, справочников которые меняются редко и есть смысл их сохранять на клиенте или только часто используемые данные. S>>Учитывая, что такие данные если будут занимать гигабайт то и с этим справится даже мобильный телефон
_>Я что-то не понял, а что ты собственно называешь клиентом? Если бразуер, то он как раз не умеет сохранять никакие данные (не считая копеек в куках). Если же ты намекал на кэш браузера, то это временное явление и сильно зависящее от настроек пользователя (к примеру у меня оно вообще отключено — зачем попусту насиловать ssd при такой оперативке и инете как у меня). Если же ты имеешь в виду не браузер, а некое приложение, то тут уже вообще всё по другому становится.
В общем то можно https://habrahabr.ru/post/112286/ http://www.noupe.com/design/html5-filesystem-api-create-files-store-locally-using-javascript-webkit.html http://stackoverflow.com/questions/16329293/save-json-string-to-client-pc-using-html5-api
Здравствуйте, alex_public, Вы писали:
_>Согласен. Если мы говорим про Qt в браузере. А вот если говорить о написание тяжёлых 3D игр для браузера, то данный компилятор становится уже очень не плохим решением. Насколько я знаю, на его базе сделали (ну точнее портировали уже написанные на C++) уже вполне законченные продукты.
Спасибо, это и без тебя было известно много лет назад. Все попытки компилирования уверенно зашли в тупик.
I>>Я в курсе. Ты пользуешься технологией конца 90х
_>Ну так а что делать, если вроде как современные технологии ничего не умеют? Ни отметить прочитанные/отвеченные мною сообщения, ни отсортировать их как надо...
Докажи, что это проблема технологий, а не конкретного разработчика.
_>>>В браузере? ) Да, не нужен, он создан не для этого. А с этим разве кто-то спорит? ) I>>Ты сам же споришь. Сам выдвинул гипотезу, сам же её и опроверг.
_>Я где-то предлагал использовать Qt в вебе? Это был всего лишь пример демонстрирующий бредовость твоих теорий о том, что причиной убогости JS фреймворков являются слабые возможности браузеров.
Именно ты и предлагаешь. JS фремворки решают совсем другие задачи, которые ты в упор не видишь.
_>>>Нуу расскажи мне как теперь правильно хранить данные. Ну и сравним эффективность при отдаче этого пользователю... ) I>>Уже.
_>Ты нигде не написал ни слова об этом. Слив? )
Цитирую себя(== учись читать):
_>Эм, а причём тут создание контента старыми методами? ) Его вообще не разработчики создают, а маркетологи с переводчиками и художниками. ))) И их методы за последние годы нисколько не изменились. )))
Наоборот. Эти маркетологи с переводчиками и художниками часто создают контент пользуясь ровно тем же инструментом-сервисом, над которым работают.
Здравствуйте, alex_public, Вы писали:
_>Дело не в этом, а в том, что собственно игровые скрипты (которые пишутся на C# или JS) занимают очень маленькую часть исполняемого кода игры.
Скажем, 5 Мб IL-кода — это много или мало? Это типичный размер кода, написанного для конкретной игры, после компиляции. Без учёта стандартных библиотек (которыми этот код пользуется) и без учёта вспомогательных внешних библиотек, типа SharpZipLib, Json-тра-та-та и прочих (которыми этот код тоже пользуется, иначе бы не потащил за собой в игру).
Глянул на Paint.NET, установленный на моём компьютере. Там все существующие .exe и .dll в сумме занимают в два раза меньше.
_>Я немного не об этом. Я имел в виду, что если кто-то напишет игру только на JavaScript, то может ему не надо будет тащить с собой все эти мегабайты ради поддержки работы C#?
JavaScript/UnityScript — такой же .Net-язык, как C#, просто чуть урезанный в возможностях и чуть менее строго типизированный — примерно как Visual Basic. Только синтаксис похож не на VB, а на Java/JavaScript/ActionScript. Он не имеет отношения к тому JavaScript, который в браузерах.
Почему этот язык официально называют JavaScript, я не знаю. На гитхабе он зовётся UnityScript. Откомпилированный код попадает в библиотеки с именами Assembly-UnityScript-xxx.dll
Соответственно, UnityScript тоже требует наличия рантайма Mono со стандартными библиотеками, плюс тянет с собой одну-две маленьких управляемых библиотечки с типами, специфичными конкретно для UnityScript и отсутствующими при разработке на C#.
_>Или там нельзя так почистить движок и он по любому тащит всё, даже если оно не используется?
Кстати, на мобилках должна работать оптимизация кода по размеру. И для нативного кода движка, и для управляемого пользовательского кода. Для последнего должен работать стрип — все типы/методы/данные, которые не используются пользовательским кодом, вырезаются. В т.ч. так же обрезаются стандартные библиотеки. Это накладывает некоторые ограничения на программистов (невозможна кодогенерация, нужна осторожность при использовании рефлекции), но уменьшает размер билдов.
Но поскольку я в мобилках нихрена не понимаю, проверить это не могу. На десктопах Unity, похоже, такой фигнёй не заморачивается, тут ±10 Мб ничего не решают.
Здравствуйте, alex_public, Вы писали:
S>> Что ты подразумеваешь под статикой? _>Под статикой я подразумеваю файлы index.html, products.html, contact.html и т.п., лежащие на сервере и отдаваемые nginx'ом.
Замеряй время отклика. В пределах этого времени уже будет широкий простор выбора технологий для динамики, как серверной, так и клиентской
_>Да, правильно, для динамических данных (зависящих от пользователя) оптимальнее всего использовать ajax. Что касается кэширования здесь, то оно вряд ли будет имеет особый смысл в большинстве случаев.
Наоборот. Такое кеширование реализовать сложнее, так что пока ходят на сервер чаще, чем хочется.
Здравствуйте, alex_public, Вы писали:
_>>>Да, правильно, для динамических данных (зависящих от пользователя) оптимальнее всего использовать ajax. Что касается кэширования здесь, то оно вряд ли будет имеет особый смысл в большинстве случаев. S>> Все зависит от данных. Почитай статьи.
_>Существенная польза от кэширования динамики может быть только в редком случае, когда она потом становится доступной всем остальным пользователям.
Прежде всего она есть уже у конкретного юзера. Дальше — больше. В зависимости от данных. Кроме того, динамикой тянется и 'статика'. Так шта...
Здравствуйте, alex_public, Вы писали:
S>> И тд. Не нужно лезть на сервер за любыми данными. Часть можно хранить на клиенте. Это не только уменьшит трафик, но и увеличит отзывчивость интерфейса и скорость выполнения.
_>Ну так это же очевидно вообще не динамика и как раз такие данные удобнее и эффективнее отдавать с сервера как статические файлы.
Если справочник обновляется раз в месяц, то собственно нет необходимости держать его статикой. Главное что бы браузер получил нужные хидеры.
Собственно сам справочник лучше держать там, где его редактируют и тд и тд. Можно хоть рендерить его по запросу и кешировать на случай большого количества запросов.
Вот для оптимизации серверных издежек, кеш можно и файлом держать и отдавать прямо из ядра(нгинкс так не умеет). Если это поможет. А если нет — см выше.
Здравствуйте, alex_public, Вы писали:
_>>>Ну так это же очевидно вообще не динамика и как раз такие данные удобнее и эффективнее отдавать с сервера как статические файлы. S>> Удобнее сообщать об изменении или возвращать 304 если изменений нет.
_>И это как раз оптимально реализуется с помощью статических файлов.
S>>Что в твоем понимании статические файлы? Данные не статичны, они изменяются, но качать с сервера нужно только измененные данные.
_>Кто изменяет данные? Если владелец сайта, то это как раз отлично ложится под модель статических файлов.
Наоборот. Справочник пусть лежит там, где это удобно владельцу СПРАВОЧНИКА, в том виде, как это удобно владельцу СПРАВОЧНИКА. А вот дальше — оптимизации.
А у тебя с ног на голову — 'я решил что справочник это файл, а раз файл то это статика'
Это да, когда-нибудь будет работать. Но его разве уже можно считать общепринятым у клиентов (в том смысле что будет работать в любом браузере)? ) Хотя я конечно не отслеживаю ситуацию в этой области, но вроде оно и родилось то только недавно.
S> Хотя каюсь. Думал о другом. В 1С http://www.develplatform.com/2013/06/blog-post_3.html S> есть возможность на вэб клиенте использовать файлы.
Да, если у тебя своё клиентское приложение, то тут уже полная свобода действия и не надо мучиться с ограничениями веб-технологий. Правда в начале надо ещё умудриться установить это своё приложение к пользователю. ))) Хотя с приходом мира смартфонов и т.п. это стало намного проще. Как следствие веб технологии даже слегка отступили (я знаю много полезных и популярных сервисов, которые доступны только в виде приложения для мобильника и недоступны в веб'е или на десктопе).
Здравствуйте, Ikemefula, Вы писали:
_>>Ну так а что делать, если вроде как современные технологии ничего не умеют? Ни отметить прочитанные/отвеченные мною сообщения, ни отсортировать их как надо... I>Докажи, что это проблема технологий, а не конкретного разработчика.
На самом деле естественно могут. На том же Хабре такое есть. Правда они сохранили и "древний" вариант (через уведомления в почту). И мне почему-то удобнее пользоваться именно им. Видимо потому что можно видеть сразу всё одном "центре", а не заходить с проверкой на все сайты, где я бываю.
В общем не стоит особо превозносить веб. Одно время были идеи, что всё перейдёт в него. Но с приходом мобильного мира пошёл откат. Потому что веб далеко не везде удобен.
_>>Я где-то предлагал использовать Qt в вебе? Это был всего лишь пример демонстрирующий бредовость твоих теорий о том, что причиной убогости JS фреймворков являются слабые возможности браузеров. I>Именно ты и предлагаешь. JS фремворки решают совсем другие задачи, которые ты в упор не видишь.
Вообще то я как раз начал с того, что хочу js фреймворк для обычного сайта, а не веб-приложения и т.п. Однако никаких предложений что-то не последовало... )))
_>>Ты нигде не написал ни слова об этом. Слив? ) I>Цитирую себя(== учись читать): I>
_>>Эм, а причём тут создание контента старыми методами? ) Его вообще не разработчики создают, а маркетологи с переводчиками и художниками. ))) И их методы за последние годы нисколько не изменились. )))
I>Наоборот. Эти маркетологи с переводчиками и художниками часто создают контент пользуясь ровно тем же инструментом-сервисом, над которым работают.
Так где они все хранят данные. Ты так и не озвучил. Файлы, базы данных, ещё что-то? Хоть один технический термин произнеси. )))
Здравствуйте, Ikemefula, Вы писали:
_>>Существенная польза от кэширования динамики может быть только в редком случае, когда она потом становится доступной всем остальным пользователям. I>Прежде всего она есть уже у конкретного юзера. Дальше — больше. В зависимости от данных.
Классический режим работы в "моём кабинете" будет в виде цикла "получить данные->поправить данные->получить данные" и т.д. Так что кэширование не будет иметь смысла даже для одного пользователя (разве что он там нервно перезагружает одну и ту же страницу).
I>Кроме того, динамикой тянется и 'статика'. Так шта...
Угу, в кривых системах типа популярных сейчас CMS и т.п. Ну как кривых... Свою задачу они отлично решают, для сотни посетителей в день. А когда появляется нагрузка пользователи просто платят больше денег за хостинг (всяческие облачные сервисы наверное просто молятся на все эти CMS). Ну или же уходят к профессионалам за сайтом на заказ.
Здравствуйте, Ikemefula, Вы писали:
_>>Ну так это же очевидно вообще не динамика и как раз такие данные удобнее и эффективнее отдавать с сервера как статические файлы. I>Если справочник обновляется раз в месяц, то собственно нет необходимости держать его статикой. Главное что бы браузер получил нужные хидеры. I>Собственно сам справочник лучше держать там, где его редактируют и тд и тд. Можно хоть рендерить его по запросу и кешировать на случай большого количества запросов.
Ну так тут вопрос в том, что называть кэшированием. ))) Собственно запуск генератора статического сайта — это же тоже в какой-то степени кэширование. Причём самое эффективное.
I>Вот для оптимизации серверных издежек, кеш можно и файлом держать и отдавать прямо из ядра(нгинкс так не умеет). Если это поможет. А если нет — см выше.
Вот как раз умеет. ))) Причём не только nginx, а по сути любое приложение на линухе — читай как работает sendfile. ) Более того, там вообще всё происходит вне процессора (см. DMA для сетевой карты и кэша жёсткого диска)! И как раз это всё не будет работать при отдаче данных из бэкен-приложение.
Здравствуйте, Ikemefula, Вы писали:
_>>Кто изменяет данные? Если владелец сайта, то это как раз отлично ложится под модель статических файлов. I>Наоборот. Справочник пусть лежит там, где это удобно владельцу СПРАВОЧНИКА, в том виде, как это удобно владельцу СПРАВОЧНИКА. А вот дальше — оптимизации. I>А у тебя с ног на голову — 'я решил что справочник это файл, а раз файл то это статика'
Вот как раз именно такую схему для сайта я и описывал (это я про начальную нашу дискуссию, а не не про 1C). Имеем удобное владельцу сайта хранение и редактирование контента (в виде папок с markdown текстом и картинками), потом даём команду build и получаем оптимизированную версию для выдачи сервером. )
S>> Хотя каюсь. Думал о другом. В 1С http://www.develplatform.com/2013/06/blog-post_3.html S>> есть возможность на вэб клиенте использовать файлы.
_>Да, если у тебя своё клиентское приложение, то тут уже полная свобода действия и не надо мучиться с ограничениями веб-технологий. Правда в начале надо ещё умудриться установить это своё приложение к пользователю. ))) Хотя с приходом мира смартфонов и т.п. это стало намного проще. Как следствие веб технологии даже слегка отступили (я знаю много полезных и популярных сервисов, которые доступны только в виде приложения для мобильника и недоступны в веб'е или на десктопе).
Вэб клиент в 1С это клиент из браузера. Хотя есть и тонкий клиент. Мне лично конечно нравится настольно мобильные приложения. Кстати я давал тебе ссылку на преобразование C#+WPF в HTML +JS. Вот тебе готовый Фреймворк. Правда с ограничениями.
Кстати в 1С тоже есть конструкторы форм которые генерятся и в HTML
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Ikemefula, Вы писали:
_>>>Кто изменяет данные? Если владелец сайта, то это как раз отлично ложится под модель статических файлов. I>>Наоборот. Справочник пусть лежит там, где это удобно владельцу СПРАВОЧНИКА, в том виде, как это удобно владельцу СПРАВОЧНИКА. А вот дальше — оптимизации. I>>А у тебя с ног на голову — 'я решил что справочник это файл, а раз файл то это статика'
_>Вот как раз именно такую схему для сайта я и описывал (это я про начальную нашу дискуссию, а не не про 1C). Имеем удобное владельцу сайта хранение и редактирование контента (в виде папок с markdown текстом и картинками), потом даём команду build и получаем оптимизированную версию для выдачи сервером. )
Ты или читать не умеешь, или врёшь. Владелец сайта != владелец СПРАВОЧНИКА. И вот владельцу СПРАВОЧНИКА твоя схема абсолютно без толку.
Это был всего лишь пример демонстрирующий бредовость твоих теорий о том, что причиной убогости JS фреймворков являются слабые возможности браузеров.
