Sergey Romanov

Самый последний который я знаю это iTunes Connect.

https://itunesconnect.apple.com/WebObjects/iTunesC...

P.S. Только фрэймворки не советуйте, пожалуйста .)

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

Для примера, так решили эту задачу Microsoft. В приложениях которые пришутся на яваскрипте используются котовые методы для создания классов, и для их вызова.

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

Но найтивно на голом яваскрите писать красивый ООП код НЕВОЗМОЖНО.

По мне так "Онлайн консультант" ни чего не говорит. Какой там будет функционал? Какие будут нагрузки?

В любом случае, в идеале я бы использовал ElasticSearch как базу данных. Очень часто для ее использования даже не надо писать сервис. Можно на прямую использовать REST API движка. Для защиты можно использовать плагины для доступа с ключем или по авторизации.

Или в крайнем случае можно просто сделать небольшой врапер что не сложно и не займет много времени и ресурсов.

А уже интерфейс бакенда или фронтена можно писать на ява скрипте с использованием ангуляр.

В данной конфигурации есть одно преимущество. На выходе вы получаете современное доностраничное приложение которое легко конвертировать в мобильное приложение или просто настольное приложение.

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

Тот кто работает над содержимым или так скажем тестом, это копирайтер.

Тот кто работает над внешним видом страници это дизайнер.

Тот кто работает над струтурой или разметкой, положением элементов управления, если страница требует взаимодействия это фронтенд девелопер.

Во первых на воод даты нужно поставить селектор даты. Это реально поможет пользоватеям вводить дату без ошибок.

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

Если нужно проверить то тебе нужно проверить строку а не дату. Можно проверить регуляркой. 30 февраля это валидная дата. Так как это 1е или 2е марта в реале. Например как ты получишь какой день последний в феврале? Ты введшь 0 марта. Это будет последний день ферраля не важно 28 или 29 дней в месяце.

Так что технология проверки дат, лежит в основном в технологии ввода даты.

1. DNS. Что бы не заморачиваться с DNS сервисом и зонами у себя на сервере, воспользуйтесь бесптаной DNS службой cloudflare. Там вы можете легко создать DNS записи, привязать к вашему IP и получить простые NS-ки для настройки у провайдера.

2. Теперь нужно просто создать виртуальных хостинг и прописать ServerName. Это все. Все должно работать.

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

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

Часто бывает так что атрибуты так же влияют на конечную цену. Например, белый цвет может стоить на $5 дороже. Так что хранить атрибуты надо соответственно. Хотя с тем стилем что я сейчас делаю, я бы их просто сохранил как упакованый json в отдельном поле attributes.

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

Angularjs + Ionic.

Можно создать основные библиотеки на Ангуляре, и их использовать уже как в веб, прикладные программы а так же мобильные устройсва. Ionic многоплатформенный фреймворк для мобильный приложений на Ангуляр.

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

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

Я пользуюсь Мак ОС. Это система тоже униксовая. Мне она нравится из за того что на нее софта уже достаточно. Можно все делать. И в тоже время все найтивно встает. К стати ноуд и подобные были одной из причиной прикупить Мак.

Можно конечно беспланые как Убунту, но я реально считаю, что система должна приносить удовольствие во время работы. Ббольшая часть жизни проходит взирая на эту систему. Ну а мак реально не плохая система.

Я сам был в шоке. Навигация по папкам в маке дерьмо. Как можно не запоминать ширину окна! Это же элементарное удобство! Но его нет. И нет двойного клика для выравнивания по самому большому имени.

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

И таких мелких неудобств просто куча.

Продолжаю работать на маке только потому что жалко потраченых денег. Столько отдал, ну надо что это хоть немного отработало.

При разговоре только голосом до 9 мегобайт в час. Лично измерял. Если включать видео, то там зависит от качества связи. Чем лучше интернет тем качественнй картика, тем больше трафика.

В режиме ожидания скайп почти ни чего не расходует.

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

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

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

Основное правило такое. Если в условиях WHERE используются колонки таблици которая была JOIN то лучше разбить на вложеные запросы.

В твоем случае делать 2 запроса смысла нет. Можно одним.

Я полагаю вы делаете что то вроде CCK.

Есть 2 подхода как хранить такие архитектуры.

Вертикальный

Это то о чем вы написали. Вы хнарите поля как строки в таблице полей. Для этого вам нужно 2 таблици. Одна это тип. Другая это поля. Где в таблице поля будет ссылка на тип. Таким образом вы всегда можете выбрать список полей этого типа как для построения формы, так и для отображения данных.

Нужна будет еще одна таблица для хранения статей и данных полей этой статьи. Это как бы связь между типом и статей на его основе. И уже в таблице хранения данных полей, можно использовать разные колонки для разных типов.

Хотя я использовал один тип и это достаточно быстро работает до 100 000 записей в разделе. Но если больше то надо конечно свои типы определять.

Естественно каждое поле это РНР класс или на чем вы там пришите. И просто у него есть свойство типа данных. На основе этого свойства и знаешь что дергать.

Горизонтальный

Это когда вы создаете таблицу под каждый тип и добавляете поля в эту таблицу как колонки. Тут можно обойтись одной таблицей.

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

Есть еще свои подводные камни. Я делал CCK для CMS использую вертикальный подход. И пока что не пожалел.