Владимир Чернышев

Если абстрагироваться от таких «мелочей» как производительность, масштабируемость и надёжность, то Д(окументно)О(ориентированные)СУБД и О(объектно)О(ориентированные)СУБД во многих случаях позволяют разработчику отражать сущности предметной области на сущности БД без введения дополнительных сущностей :), которые приходится вводить в Р(еляционных)СУБД. Например, сколько копий переломано в спорах о том, как хранить в РСУБД объекты различных классов, унаследованных от одного базового класса (в одной таблице с кучей пустых полей, в таблицах для каждого отдельного класса, в общей таблице общие поля, ...), а тут просто храним в одной «таблице» и не думаем о таких мелочах. Отношения 1:1 и 1: М, когда сущности во второй половине отношения принадлежат одной и только одной сущности первой и не имеют смысла без неё также отображаются без дополнительных таблиц и полей для связи (вместо comments.post_id и comments.content просто храним в поле posts.comments список/массив комментов, не заботясь о целостности связей, синхронизации и т. п.). Другими словами, ДОСУБД часто облегчают жизнь разработчику, хотя иногда её усложняют (когда связи двунаправленные прежде всего, особенно M: М — для установления связи между двумя уже существующими сущностями надо производить две операции — добавление к первой ссылку на вторую, а ко второй на первую -, а не одну — добавление в таблицу связи — как в РСУБД )

Мне для общего развития хватило главы про текст и шрифты в книге Д. Кирсанова «Веб-дизайн»

На уровне абстракций предметной области ТЗ на сайт (веб-сервис) ничем, имхо, не отличается от ТЗ на любое приложение клиент-сервер. Сессии это уже механизм реализации этих абстракций, причём в разных языках/фреймворках/… они могут быть совсем по разному реализованы или даже спрятаны от разработчика, которые оперирует пользователями, правами доступа и т. п.

Думаю, самое простое в вашей ситуации, это найти фрилансера, который за пару часов (максимум) и некоторое количество рублей реализует нужный вам функционал. Причём это элементарно делается и в том же MS Access как отдельное приложение — сотрудницы будут кликать по иконке на рабочем столе, вводить свои данные в форму/таблицу, а больше ничего от акцесса и видеть не будут.

>2) Разработку можно полностью вести на языке Java, при этом время вхождения в технологию очень мало, что позволит начать разработку практически через несколько часов после прочтения документации. Все интуитивно понятно.

Под вот этим что имеется в виду? Можно начинать разработку не изучая особо Java? Если так, то интересно :)

В Drupal неплохие возможности коллективного блоггинга «из коробки»

Можно. Назначить расширению jpg обработчиком php например (тогда в jpg надо хранить текст скрипта :) ).

Или, как выше сказано, rewrite/redirect: из запроса GET /upload/articles/58fa0825907dc76e67e8cb1150a7ac36.jpg?w=100&h=100&strict делать запрос GET /superscript.php?path=/upload/articles/58fa0825907dc76e67e8cb1150a7ac36.jpg&w=100&h=100&strict

Хотя, если стоит задача масштабирования, я бы пошёл другим путём:
— при запросе nginx проверяет есть ли файл /upload/articles/58fa0825907dc76e67e8cb1150a7ac36_100х100_strict.jpg
— если нет, то вызывает php для генерации
— отдаёт файл (он уже есть обязательно, если не было фатальных ошибок)

Плюсы: php вызывается только один раз, при первом обращении
Минусы: требуется больше места на диске; при изменении оригинального файла нужно удалять сгенерированные

i и b использую для дизайнерских решений, когда использование только CSS нецелесообразно (например, навигация, подписи к картинкам и т. п. — зачем выделять в span, которому присваивать bold, если можно выделить в b?), а strong и em в основном контенте страниц для выделения части фразы/абзаца/…

Для меня главный недостаток — при копировании человекопонятного URL'а из адресной строки в буфер получаем не человекопонятный (закодированный) URL, причём гораздо большей длины (один символ кириллицы -> 6 символов URL'а), поэтому предпочитаю использовать транслит (система Б ГОСТ 7.79-2000, он же ISO 9-95)

Нужно понимать, что можно (грубо, есть нюансы) разделить языки на языки серверного веб-программирования (тот же php, ещё популярны python, ruby, java, c#, вообще любой язык «общего назначения» в принципе, хоть ассемблер) и клиентского (самый популярный, практически монополист — Javascript). Если вам нужно взаимодействие между посетителями сайта (включая посещение одним пользователем через разные компы/браузеры), то нужно, прежде всего, изучать серверные языки и, как правило, БД. Клиентский Javascript — когда будет реализована серверная логика (приложение будет делать то, что нужно) и начнёте думать об пользовательском интерфейсе (чтобы оно это делало удобно и/или красиво). Если же хотите, грубо говоря, делать локальные приложения, запускаемые из браузера, то про серверные языки можно не думать.

Период обучения кого имеется в виду? Программы или лектора? :)

Если программы, то, скорее всего, ещё нет «промышленных» разработок, на уровне, скажем, FineReader, тем более для русского языка (не потому что сложный, а потому что потенциальные доходы малы).

>тоесть цены выбирает верные, но ид номера никак не соответствует ценнику, должно быть так

Собственно по другому и не должно быть — группируете по стране, выбираете максимальную цену и выводите «рандомный» номер, нигде не указывая, что он должен соответствовать этой цене. Так или иначе нужно сначала получить максимальное значение, а потом номер для него.

По моему опыту, при тонкой настройке библиотек, реализующих ORM (прежде всего настройка lazy load чуть ли не для кждого запроса) оверхид при выполнении от них небольшой (по сравнению с собственно выполнением запроса) и полностью компенсируется упрощением разработки и поддержки, если не требуется использовать «экзотику» типа хранимых процедур или триггеров.

Если при проверке сотрудники сделают заявление «Ноутбук мой и софт я украл сам, а компании сказал что купил», то не несёт, но рассчитывать на такую лояльность, по-моему, сложно, в лучшем случае надо будет это доказать — если не получится то ещё и ответственность за наршение правил учёта и т. п. добавится.

— Если используется версия, например, 1.0 с лицензией Л1, то нет, если с Л2, например 2.0 — то да. То есть лицензия программы B должна быть совместимой с фактически используемой, если лицензия Л2 вам не понравилась, то просто не апгрейдитесь до версии 2.0, а, например, делаете свой форк версии 1.0

— Юридически, имхо, не распространяется. По-хорошему, указываю что «this product is… port of ...» или «this product based on ...» (даже если язык не изменился, но код переписан чуть более чем полностью и от оригинала осталось, например, лишь API), но лицензия совсем не обязательно совместимая с оригиналом.

Антарктида — никаких налогов, никаких конкурентов, а главное — непаханный рынок :)

Прежде всего, имхо, стоит изучать английский на уровне беспроблемного общения с потенциальными иностранными заказчиками по e-mail/IM, чтобы на равных конкурировать с индусами :)

А насчёт книг не понятно — книги по непосредственно заданиям (технические, грубо говоря) или по работе во фрилансе (экономические и психологические)?

Согласятся какое-то время участвовать и даже весьма активно, я думаю, многие начинающие, хотя бы (если проект не сулит отдачи или, как минимум, достойной оплаты) для наработки портфолио и приобретения опыта (если выбранная платформа востребована или перспективна). Но вот насколько продуктивно будет их участие — имхо, только от организаторских способностей зависит. Искать таких можно практически на всех сайтах, где есть раздел «ИТ-вакансии».