Андрей

Первым делом нужно отделить собственно код на PHP (обработка данных, форм например, формирование данных для построения страницы), от кода построения страницы. Последнее лучше доверить шаблонизатору. Я пользуюсь Smarty, но вариантов масса, тут на вкус и цвет все фломастеры разные. А мешать код PHP с кодом HTML, и, упаси Боже, с кодом JS - Это Богохульство я считаю... :D

Хотя PHP это позволяет, но это равносильно выстрелу себе в ногу...

В целом я люблю PHP, особенно после Clipper 5.2 и Borland Pascal. Назад я уже точно не вернусь.

Однако, тенденции современности таковы, что логика все больше мигрирует в сторону клиентского кода. Это то, чем занимаются всевозможные Angular.JS, Ember.JS, Backbone.JS, React.JS и прочие jQuery, и же с ними...

Что еще более замечательно, это то, что JS стал активно мигрировать в сторону бэкенда (Node.JS, Io.JS и т.п.)

Так вот, по моему личному опыту последних лет, а это очень много AJAX+jQuery, бэкенд все больше превращается в эдакий прокси модели до БД и сервис аутентификации/авторзации... И в этом плане, каким бы прекрасным ни был PHP7, но работы для него все меньше (потому что совершенно до фонаря, скрипты на каком ЯП отдают JSON)... По крайней мере в том ключе, в каком он изначально задумывался и существовал до начала бурной эпохи AJAX.

Поэтому моё мнение такое, раз уж начал проект на PHP - надо прочитать начало моего поста, облегчить себе жизнь, завершить и сдать проект, а потом переключиться на фронтенд, и с ходу бросить все силы на освоение сначала JavaScript, а потом сразу Ember.JS, в крайнем случае Angular.JS, ибо именно там сейчас полным ходом развивается будущее. Разумеется какой может быть фронтенд разработчик без серьезных скиллов в HTML5/CSS3... Поэтому и это тоже надо обязательно изучать.

Делать это надо хотя бы потому, что освоить Ember.JS равносильно получению второго высшего образования, и вакансий по этой тематике все больше, а минимальный доход пряморукого разработчика на таких вакансиях от 60 тысяч у.е. в год. Разумеется необходимо владеть английским, как без этого...

Безусловно, и на бэкенде еще полно работы, и есть такая, которую на фронтенд нет смысла тащить, тем не менее, бэкенд уже не тот что был 10 лет назад, и уже не будет прежним.

P.S.: все вышесказанное - это сугубо плод моего воображения и личного опыта (20 лет в разработке), думать придется, в любом случае, собственной головой и нести ответственность за принятые решения, и разбираться с последствиями оных.

Десктопные приложения я писал очень давно, еще под DOS на Clipper 5.2, а до того вообще на Borland Pascal 6/7. Как только в коде появлялся мало-мальски долгоиграющий расчет, интерфейс зависал и интерактив сводился к нулю.

Как мне кажется сегодня очень замечательно можно асинхронно и многопоточно разделять интерфейс от всяких долгоиграющих процедур, дабы пользователь не думал, что компьютер подвис.

Текстовый файл 2 мб это не так много. Я бы спарсил текстовый файл в отдельную временную таблицу (даже можно in-memory), а потом от нее делал OUTER JOIN на основную, и в тех строках, которые есть в файле, но нет в основной таблице получил бы NULL, по которому и отбирал бы то, что надо дозалить в основную таблицу.

Это более-мене адекватный и производительный способ на мой взгляд.

Разумеется должны быть индексы на соответствующие поля в обеих таблицах, и вот тут, все зависит от нескольких моментов. Во первых, если строки всегда идентичные, но длиннее 32 байт, то есть смысл добавить дополнительные поля в таблицы, загонять туда MD5 хеши строк и индексировать по хешам.

Если же в строках что-то плавает, например регистр символов, то перед вычислением хэша строки надо приводить к единому виду. Причем в таблицах помимо хэшей хранить можно и оригинальные строки, тут вопрос только о вариантах сравнения.

Если пользователей будет десяток-другой, то можно хоть как извращаться, хоть в массив писать.

Если же тысячи будет их, то не думаю что ОС понравятся такие извраты...

Нет, нет и еще раз нет!

Для обслуживания прав доступа пользователей давно придуманы библиотеки авторизации, в частности они принимают решение, будет ли скрипт вообще иметь право доступа к базе в каждом конкретном случае.

Так и только так.

Сегодня актуален JavaScript

Каким либо образом запоминать что элемент был ранее показан, для бэкенда это делается в сессии, для фронтенда либо в куке либо в локальном хранилище. с куками осторожнее, там есть лимиты, ставить кучу лишних кук не вариант.

Через таймер обычно зацикливают анимацию в канвасе типа setInterval

Можно загуглить JavaScript Best Practices и почитать/посмотреть/послушать что на этот счет говорят...

Например вот www.youtube.com/results?search_query=javascript+be...

На голом ЯП писать долго, муторно и непродуктивно. Приходится из проекта в проект постоянно одни и те же типовые вещи делать снова и снова. Умные люди уже много лет эти типовые вещи грамотно упаковывают в фреймворки. Основная идея хорошего фреймворка - максимум времени бизнес-логике, минимум времени заморочкам с реализацией.

По части JS фреймворков я сторонник Ember.JS, порог вхождения конечно заоблачный, но оно того стоит.

Нынче на голом JS, как, в прочем, и на любом другом голом ЯП мало кто кодит, ибо долго, муторно и непродуктивно. Нынче фреймворки правят бал в разработке чего угодно на чем угодно.

По части JS рекомендую обратить внимание на Ember.JS

Очень высокий порог вхождения, но лучше пока ничего не придумали, ИМХО.

Я начал плотно изучать программирование лет в 14, в 16 написал первую коммерческую программу и что-то на этом заработал. Мастерство приходит примерно после 10 тысяч часов адресной практики, количество дней и лет можно посчитать, многое будет зависеть от интенсивности занятий. Я бывало кодил по 12-16 часов в сутки практически без перерывов, так меня пёрло и штырило...

Однако путь одиночки очень нестабилен и витиеват. Я бы рекомендовал устроиться стажером в крепкий коллектив профессионалов, там, при условии упорного труда можно за несколько лет вырасти в крепкого специалиста в интересующей области, заодно удастся очень мягко нейтрализовать грабли, коих тысячи их.

Обратите внимание на Ember.JS, порог вхождения высокий, но оно того стоит.

По Эмебру на русском актуальной инфы практически нет, далеко не все владеют инглишем в должной степени. Туториалы корявые у них, и да, очень активная разработка, много стремительных изменений.

Тем не менее для себя я выбрал именно Эмбер и потихоньку вгрызаюсь. Уж больно близка мне его философия. Да и в целом времена такие, что без вариантов...

И да, порог вхождения достаточно высок, необходимо впитать массу контекстов. Однако я убежден, оно того стоит.

ЗЫ: Ангуляр мне не прижился - слишком много анархии.
ЗЫ2: В 2016 я таки выбрал React.JS...

Когда один и тот же ребенок занимается с разных девайсов — его можно идентифицировать по ПИНу. Не вопрос. Форма организации пина обсуждаема.

Но когда на одном и том же девайсе разные дети занимаются… Вот тут собака порылась.

Подчеркну, каждое решение ребенка логируется в привязке к заданию, с тем, чтобы выявить, какие задачи у него вызывают затруднения, т.к. на эти задачи нужно сделать усиленный упор. Если ребенок за девайсом один, вопросов нет. Но если их в семье или классе более одного, то возникает проблема. Дети могут портить или улучшать друг другу статистику, чего происходить не должно.

И еще тут в голову пришла проблема с коллективным решением задач. Как это пресекать я пока вообще не понимаю.

Часто СТО в стартапе оказывается крайним. Знаю не по наслышке.

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

Средний программист — натура творческая и норовистая. Чуть недоглядел — его унесло в неведомые дали.

2 человека будет недостаточно, нужен третий — тестер. Кто-то должен непредвзято тестировать. Сам программист, часто, не способен качественно оттестировать то, что наваял, испытывая к творению, чуть ли не родительскую, слабость. По крайней мере мне за моими бойцами приходилось очень тщательно код выверять, неоднократно заворачивая на допилинг.

На моем опыте с первого раза никогда ничего не взлетает. Слишком много субъектива в понимании сути дела. Я уже умолчу о каком-то парадоксальном сопротивлении, с которым часто приходится сталкиваться, когда ставишь задачу.

Вам нужен человек, профи, которому еще интересно всем этим заморачиваться, и которого разработчики не смогут водить вокруг пальца.

Я бы тоже делал онлайн приложение, сегодня для этого существуют все необходимые возможности.