FilmRestoration2019, потому что фрилансер, к которому вы придете с такой задачей, вас пафосно ограбит, сделав то, что вам на самом деле - не нужно.
Никто не будет ставить себе на телефон ваше приложение, если то же самое можно сделать на сайте.
Никто не будет ставить себе на телефон приложение неизвестно от кого.
Никто просто не узнает про ваше приложение, если вы не вбухаете кучу бабла в его раскрутку.
И уж тем более никому, включая вас, не нужно это приложение, если окажется, что и сайтом-то вашим никто не заинтересовался.
Насчет "дешевле потом" - вы это сами придумали. В реальности стоимость приложения-припарки к сайту определяется тем, насколько грамотно написан сайт. И только.
Рабочий прототип есть правда в Иксель на основе Расширенного фильтра со сложными запросами.
Вот вам и краеугольные камни вашего ТЗ. Вам нужно:
1. Перенести данные из Ёкселя в нормальную базу данных.
2. Переписать логику этой портянки на нормальный язык - PHP / Python / JS - так, чтобы сервер, получив данные формы, обработал их с использованием этой БД по вашему алгоритму.
3. Настрогать страничку с веб-формой, где нужные данные будут собираться и отправляться этому самому скрипту на сервере, отрисовывая на той же страничке результат, который он вернул.
Для MVP не требуется больше ничего. Замахиваться на кроссплатформенные приложения на этом этапе - деньги на ветер, особенно если вы собрались кормить фрилансеров, а сами в IT грамоте не разумеете. На самом деле, когда серверная часть готова, такие приложения пишутся левой пяткой.
А учитывая обстоятельства, шансы, что такие приложения вам вообще понадобятся, околонулевые.
Студент медвуза, научившийся веб-стеку, вполне способен написать такой "кроссплатформенный проект" (на самом деле - банальный сайтик) в качестве курсовой.
Разумеется, в том случае, если это действительно готовый алгоритм обработки данных, а не фантазия о том, как компьютер сделает уличную магию.
После публикации этой информации ВБ ещё раз запутал подсчет рейтинга, так что по накопленным данным его теперь считать просто бессмысленно. А ошибки в этой публикации никто исправить так и не удосужился.
Позвольте полюбопытствовать: какую задачу вы решаете в Кореле и почему именно в нем?
Просто я сам закопал такую же стюардессу 25 лет назад и был искренне уверен, что Corel VBA давно вымер.
Сергей, у меня на Либру перебрались все, в том числе те, кому в свое время куплены 2003 и 2007 M$ Office, кроме пары руководителей, которым настолько "я так привык", что у них до сих пор Семерка.
Что приятно в Либре - никаких нововведений, требующих кривых обучения кривым интерфейсам. Народ просто недельку привыкает к чуть другому расположению клавиш и менюшек - и дальше спокойно работает.
Поскольку куки может установить как фронт, так и бэк - то и вопрос, кто их устанавливает у вас, совершенно перпендикулярен какой бы то ни было безопасности.
Vitalya Ivanov, зависит от задачи. Если нужен универсальный определятор - глазами, только глазами программиста. То есть вписать в UTF-8 текст вот эти варианты - и посмотреть на них в HEX-редакторе. Получим набор шаблонов типа "если в потоке вот эти байты - то текст надо перевести из UTF-8 в CP1252, а потом из CP1251 в UTF-8, тогда будет кириллица".
Нет. Не успеешь. Ты же ни хрена не делаешь, только спрашиваешь, чего бы тебе НЕ учить и НЕ пробовать.
С таким отношением в IT вовсе соваться не стоит.
Вот, посмотри на ровесника: Что мне еще нужно изучить для бэкенд (фактически роадмап)? и подумай, как ты на его фоне будешь выходить на призовые места и - особенно - "т.п.", под которым явно скрывается "тупо подзаработать".
Сергей, я несколько лет назад окончательно отказался от Pentium4 в офисе в первую очередь потому, что они уже не позволяли натянуть память хотя бы до 4 гиг, своего предела, из-за материнок с 2 слотами, не понимающими модули DDR2 объемом 2 гига. Это насчет "всегда можно добить памяти".
Насчет "новый виндовс будет требовать" - одна из многих причин послать его в пень. Машинки, на которых у меня XP была сменена на Xubuntu 12.04, продолжали работать до 18.04 без всяких капризов, пока растущие аппетиты браузера реально не превысили возможности апгрейда памяти.
Александр Рублев, неважно, как называется и для чего предназначена. Главный принцип - вся изменяющаяся информация должна быть в базе, а не в документах. Офисные форматы - для ввода, если уж инфа в них, и вывода, кому понадобилось. Те же ЧЗ, например, у меня в одном месте загружаются из Ёкселя и привязываются к конкретным карточкам ВБ, чтобы потом видеть, что куда пошло и нет ли дублей.
Чтобы открывать офисные форматы в браузере, нужен онлайн-офис. Collabora, например. Но это, на самом деле, тупик - если повторять рабочий процесс по до-онлайновой парадигме, проект быстро начнет сопротивляться развитию и превратится просто в неудобный (из-за работы в браузере) офис.
Александр Рублев, ваши требования к "удобно" больше напоминают не CRM, а онлайн-офис, например.
Все вот это "пользователь командует создать файл, потом шляется мышкой по серверу, чтобы послать его почтой" - просто пережитки докомпьютерных времен. Менеджер должен зайти в конкретный договор с конкретным контрагентом, выбрать период, за который нужно сформировать файл, и одной кнопкой его отправить. Или, если ему только посмотреть - получить сгенерированный PDF в соседнем окошке (получив по AJAX содержимое и воткнув его в dataurl, например).
Александр Рублев, если вы по своей CRM бродите файловым менеджером, у вас не CRM, а бардак.
Отправка файлов CRM по почте должна осуществляться формой "отправить выделенные файлы по почте контрагента прикрепленными к заполненному указанными данными шаблону" на странице объекта, которому они принадлежат. Без всяких там перетаскиваний.
Загрузка ЦП приводит к тормозам, а не к вылетам.
А вот выжранная память может спровоцировать OOM Killer, молча грохающий самого прожорливого.
Если не можете добавить памяти прям сразу - можно создать файл подкачки, тогда исчерпание памяти сначала будет приводить к лютым тормозам, будет не так внезапно.
alexalexes, имхо, и в этом случае не стоит пытаться подстилать соломку.
Если на обновление техники не выделяются средства - значит, и работа на ней меняться не должна. Соответственно, не гонимся за современностью, мужественно преодолевая, а "останавливаем время" до тех пор, пока необходимость обновления не станет очевидной. Если даже вопреки этой очевидности денег на технику не будет - подпирать своей спиной чужую нежизнеспособность просто нет смысла.
P.S. ну да, я не работал на госконторы, меня бесит логика "давайте просрем стомильонов, только чтобы нам было проще с отчетностью, а нужный человечек положил половину этих растрат в карман".
Никто не будет ставить себе на телефон ваше приложение, если то же самое можно сделать на сайте.
Никто не будет ставить себе на телефон приложение неизвестно от кого.
Никто просто не узнает про ваше приложение, если вы не вбухаете кучу бабла в его раскрутку.
И уж тем более никому, включая вас, не нужно это приложение, если окажется, что и сайтом-то вашим никто не заинтересовался.
Насчет "дешевле потом" - вы это сами придумали. В реальности стоимость приложения-припарки к сайту определяется тем, насколько грамотно написан сайт. И только.