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

Подумайте какие сценарии использования вашего модуля могут быть, что поступает на вход и что должно быть на выходе. Вход и выход это не только параметры конструктора/методов и возвращаемое return значение, но и состояние БД, ФС и т. п., а для выхода ещё и исключения. Для каждого сценария подготавливаете с нуля вход (создаёте нужные объекты рантайма, файлы, схему и данные в БД), выполняете сценарий (в простейшем случае вызов одного метода) и проверяете выход.

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

Функциональность, имхо, без вопросов можно копировать. Принципы интерфейса (скажем разделение функциональности на N экранов и группировку её по экранам) тоже. Но вот внешний вид копировать нельзя, ни полностью, ни так чтобы было ясно, что ваш интерфейс (порождаемое программой аудивизуальное отображение) лишь переработанный оригинальный. Текстовые сообщения (в частности лэйблы контролов)- не уверен. По одному вроде не объекты АП, а вот их совокупность можно посчитать (суд может посчитать) подготовительными материалами для программы или вообще отдельным литературным произведением. Наверное имеет смысл записать возможные сценарии использования («На главном экране пользователь выбирает название трека из списка, запускает его проигрывание, программа проигрывает трек») и реализовывать без оглядки на интерфейс оригинала.

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

Логин у пользователя случайно не что-то вроде "';DROP TABLE "? :)

Любой мультипарадигменный язык, на котором можно показать процедурную, модульную, функциональную и ООП парадигмы. Ведь курс называется «основы программирования», а не «основы императивного и/или ООП программирования» как подразумевают многие. Личные симпатии в сторону Python. IDE не принципиальна вплоть до отсутствия. Это что касается ПКС (230115?)

Со второй сложнее, стандарта именно на экономику не нашёл (интересно только я один догадался их посмотреть, прежде чем отвечать? :) ), но если не завязываться на вендора (1С, МС), то альтернатив кроме Python тоже в голову не приходит.

Чтобы не насиловать мозг сразу несколькими новыми концепциями (вернее чтоб хоть немного уменьшить их число) возможно имеет смысл посмотреть на C# или Java — компилируемые языки со статической типизацией.

Вообще да, такой сервис, где можно было бы увидеть реальные мнения реальных пользователей, пускай и субъективные, был бы полезен, но три больших проблемы вижу:
— реальные мнения реальных пользователей: кроме озвученных «маркетологов» нужно ещё учитывать то, что отрицательные отзывы люди оставляют охотнее, плюс надо как-то учитывать массовость продукта: 100 негативных отзывов для продукта, продажи которого исчисляются миллионами — мелочь, а тысячами — проблема.
— монетизация: уже отмечено про непонятность источников доходов (хотя, контекст, по-моему, может неплохо приносить, в плане выбора поставщика), причём затраты такой сервис будет нести не столько технические, сколько административные (модераторы, юристы и т. п.)
— объединил в первом кажется :)

Сначала напишите на PHP в каком видите вы хотите работать с данными (иерархию объектов, вложенность массивов и т. п.), прикиньте как будете расширять «поля» при необходимости, чтобы не ломать весь код), и только потом думайте как это отобразить на БД. Хотя бы потому что одни и те же отношения между сущностями PHP можно реализовать в БД разными способами, например наследование (от абстрактного «коммента» наследуются «вопрос» и «ответ») отображается минимум тремя способами, а создавая их на основе базы можно просто не заметить, что имеет место какое-то удобное и понятное отношение.

Абстрагируясь от схемы БД вы можете инкапсулировать работу с ней в функции/методы типа $answers = get_answers($question_id) или $answers = Answer.getByQuestion($question) и в них привязывать любую схему БД, или вообще не схему и не БД. Поменяете схему — нужно будет поменять только эти реализации, не трогая основную логику, в ней так и будете обращаться к названию фильма как $questions[$question_id]['answers'][0]['films'][0]['name'] или $questions[$question_id].answers[0].films смотря предпочтётё вы хранить сушности в массивах или объектах.

Автор только вы, если заказчик вам не диктовал строки кода и т.п. (вот диктовал бы — вы бы оказывали техническое содействие по их вводу). Но исключительные права по умолчанию принадлежат заказчику, хотя вы вправе использовать эту программу для собственных нужд.

В коде и ресурсах не должно быть строк © yujin1st, хотя могут быть Author yujin1st, и не должно быть строк Author <Заказчик>, хотя могут быть © <Заказчик>

КПК, как я понимаю, сейчас уже не делают.

Угу :( Но звонить со смартфона вовсе не обязательно. Если требование Excel очень важно, то есть поддержка .xsl/.xslx нужна не номинальная, то нужно брать на Windows Phone (или ждать Windows 8) — субъективно MS свои файлы лучше всех читает/пишет, как ни странно :). Самое недорогое из доступного в магазинах (Питер) вроде HTC 7 Mozart — ~9к.

Если бы PHP умел бы закрывать here/newdoc не с начала строки, то выбрал бы первый вариант для себя, а так нарушается логика отступов, которую я очень люблю в том числе и при смешивании языков, без чего редкое приложение на PHP обходится. Сам использую вариант с конкатенацией.

cookies не костыль, собственно для этого они и придуманы (сессия — дальнейшее развитие идеи)

А у вас противоречие в условиях, по-моему:
Вариант с GET не подходит, ибо данные явно висят в url противоречит но через обычную ссылку их не передашь. Либо данные висят в урл, либо через обычную ссылку (без дополнительных скриптов на клиентской стороне) их не передать. Третьего не дано.

Может устроит вариант:
1. На исходной странице обычная GET ссылка на промежуточную страницу с данными в URL, нажимаем
2. Сервер принимает данные, пишет их в сессию и делает редирект на целевую страницу без данных в URL
3. Целевая страница достаёт данные из сессии и тут же сессию очищает.

Если пользователь не смотрит куда ведёт ссылка (или его браузер не показывает), то данные в URL мелькнут в адресной строке очень не надолго на современном ненагруженном компе и быстром инете.

Опять же если стоит задача скрыть от пользователя данные полностью, то это не реально, мониторить трафик умеют сейчас все популярные браузеры. Можно усложнить жизнь шифруя данные, но только усложнить. А для защиты от случайной утечке данных по сценарию типа «ломщик увидел секретный url, запомнил и дома его ввёл» моего сценария, имхо, достаточно.

Изучил бы на вашем месте Yii и Symfony 2 (плюс Silex :) ), а дальше выбирал бы под задачи, примерно так: Silex для простейших (типа форму обратной связи на статический сайт прикрутить) или очень нестандартных задач (от фреймворка по сути требуется гибкий роутинг), Yii для «ширпотреба», Symfony 2 для сложной бизнес-логики, которая вероятно будет постоянно меняться.

Всякие tor и прочие анонимайзеры чем лучше канал тем лучше его забивают :)

Не уверен, что обойдётся только if и переменными, но в голову приходит только MonoDevelop и C# из линуксового/кроссплатформенного визуального и востребованного. Qt Creator формы, конечно, рисовать умеет, но всё же не для детей имхо C++ с надстройками. Можно ещё попробовать Qt Creator вместе с PyQt/PySide но тоже не уверен, что возможно обойтись только переменными и if.
В общем посмотрите (в порядке убывания субъективных предпочтений, IDE/язык):
MonoDevelop/C#
Qt Creator/Python(PyQt)
Qt Creator/C++

Хотя, может имеет смысл и Qt Creator/Python(PyQt) на первое место поставить — динамическая типизация всё же проще по идее, и сам код не такой «грязный» — ни скобочек для структуры, ни классов вроде System.Windows.Documents.DocumentStructures.ListItemStructure в типах переменных и параметров (да простят меня знатоки .NET за некорректность примера)

Не знаю насчёт публичных докладов, но умение выбирать нужных работодателей и «заставлять» их выбирать тебя — точно нужно каждому: студенту и (почти каждому) пенсионеру, айтишнику и дворнику. Увы, нам мне таких знаний не давали, так и мыкаюсь по ненужным (постфактум) мне работодателям, не умея заинтересовать в себе нужного (предположительно).

Горбатого могила исправит, а вот тем кому жить да жить, имхо, будет очень полезно.

Увы, но судебная перспектива мне лично не ясна. Причина неясности отсутствие одного слова в этом пункте. Это слово «только». Прочитайте «ваш» вариант и мой:
7.3. Пользование Услугами связи Оператора связи может осуществляться Абонентом только в случае, если баланс Лицевого счета Абонента не является отрицательным...

Сумеете доказать суду, что это слово подразумевалось (и что предоставление услуги эквивалентно возможности её использования) — есть шанс выиграть и даже денег сверху поиметь. Не сумеете — увы…

Про открытые форматы усилил бы акценты. Не «целесообразно», а «необходимо», по крайней мере для документов с которыми работает население (прежде всего скачивание документов органов власти и госучреждений с сайтов) и бизнес (подача в документов в электронном виде), ведь документы с закрытым форматом вынуждают нас заключать лицензионные договора с иностранными фирмами, чтобы, например, ознакомиться с текстом нового закона. Или нарушать другой закон. Упомянул бы про ГОСТ на odf, который зачастую игнорируется.

И очень важный нюанс — порядок заключения лицензионных договоров. Должно быть достаточно начать использовать продукт. Существующая статья ГК(1286 п. 3) о договорах присоединения несколько не соотносится с «обычаями делового оборота», требуя чтобы договор был изложен на экземпляре или упаковке — мне сложно представить изложение договора на электричестве в сетевом кабеле или вообще радиоволнах, также сложно представить упаковку.

gtkmm