Юрий Ярош

Можно написать браузерное расширение (extension).
Простое window.open(url, '_blank'); не сработает.

Также есть СSS3 свойство target-new, правда ничего не могу сказать по поводу совместимости.

По умолчанию это всё считается всплывающими окнами, и нужно явно разрешить возможность их открытия.

Скопировать конфиг Murmur.ini и поставить в копии другой порт, поменять скрипт в init.d что бы запускалось два демона с разными конфигами.

Вообще зависит от каждого конкретного проекта, обычно выработка требований должна происходить при формировании и определении его задач самими исполнителями совместно с заказчиком, это рекурсивный процесс повторяется 4-5 раз (минимум 2-3 по ГОСТу для автоматизированных систем). Но в этом плане на фриланс слишком надеятся не приходится, так как контроль качества тут отсутствует в принципе, и заказчики особо не парятся по этому поводу... а фрилансеры/студии впаривают что могут/умеют, учитывая что универсальных инструментов не бывает выглядит это довольно печально.

Главными критериями при подборе человека для написания любых ТЗ является наличие опыта

1. Проектирования SOA
2. Внедрения непрерывной интеграции и приёмочного тестирования
3. Знание основных подходов и технологий на 3-4 языках программирования
4. Организации долгосрочной поддержки продуктов (5+ лет)
5. Формирования требований к проектной документации
6. Формирования требований к профилированию, нагрузочному тестированию, вертикальному и горизонтальному масштабированию

Если нужны PUSH нотификации, то это уже не MVC, а СQRS-ES ... и php / python / ruby для такого подходят довольно плохо так как довольно плохо утилизируют аппартные мощности серверов, и у них нет родной многопоточности/ассинхронности без костылей - были случаи когда люди слазили с ruby на golang и java, получали 10ти кратные приросты производительности и соответствующее уменьшения количества серверов.

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

Пишите в скайп void.nugget,
обсудим детали - помогу чем смогу.

Вопрос очень плохо сформулирован, не ясно какую задачу нужно реализовать подобным образом.
Берём и читаем как настраивается rewrite в nginx'е и Apache.

"Шта? Как (блеять) сборка проекта относится к тестированию ?"

Ну лет так 8 назад можно было так сказать про Maven, что он крут и т.п. ...
Сейчас же ситуация очень сильно изменилась - Maven и Ant это просто бесполезные динозавры.
Используйте Gradle, и будет вам счастье.

А Selenium используется в основном для приёмочных тестов со стороны фронтенда и написания ботов.
У него есть абстрагированное HTTP Api которое можно привязать к любой платформе и языку.

Так что, к примеру, если у вас есть Angular приложение и вы хотите его тестировать - писать приёмочные тесты на Watij или Geb очень глупо, для этого есть Protractor и webdriver.io - это обёртки к WebDriver.js и http api selenium'a.

Если у вас там есть хотя бы намёк на TDD/BDD, то человек отвествнный за фронтенд должен сам под себя писать тесты на JS'е под selenium, и не дёргать лишний раз тестировщиков. Хотя и выделять тестировщиков как отдельный класс персонала в таком случае бесполезно - слишком большие накладные расходы на коммуникацию...

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

Знаком почти со всеми популярными MVC-фреймворками которые сейчас есть на рынке, и даже с Catalyst'ом :)
Нет универсальных решений - у всех есть свои недостатки.

Ввиду движений в сторону реактивностей от себя могу выделить Play2 / Xitrum и Grails.
Но у них тоже хватает проблем с производительностью, хоть они и на много (очень-очень много) быстрее тех же рельсов или джанги, или всяких симфоний / Yii2 и экспрессов с Sails.js'ами.

Вот что писал раньше по поводу того же питона.

Сейчас требования на рынке возросли в 3-4 раза по сравнению с тем что было 2-3 года назад. PUSH-нотификации по вэбсокетам (или comet'у) и в мобильные приложения требуют асинхронности и в случае с PHP / Python / Ruby реализовуются довольно костыльно - прикручивают очереди Celery / Beanstalkd / Gearmand / RabbitMQ. В итоге умирает вертикальное масштабирование решения в рамках одного сервера из-за накладных расходов на коммуникацию. Микросервисную архитектуру стоит внедрять в рамках нескольких машин, и профилировать накладные расходы на коммуникацию.

Также существует очень много проблем с PHP / Python / Ruby / Node.js c долгосрочной поддержкой - слишком часто отваливается обратная совместимость у существующих библиотек и зависимостей. Часто меняется API самой платформы.

Из фреймворков сейчас веселее всего с Play2 / Xitrum / Grails.
У них есть свои недостатки, но они будут шустрее всего остального в десятки,а в случае с рельсами - в сотни, раз.

С Node.js куча проблем.

Опять же там много заморочек с архитектурой - нужно внедрять SOA и CQRS-ES для реактивностей, и это уже не банальное MVC к которому все так привыкли. Подобный подход просто требует TDD/BDD и приёмочных тестов для фронтенда.

В общем там браузерная шаблонизация - нужно смотреть в сторону Angular / Ember / Meteor / React + rx.js
Cейчас вопрос с SEO и браузерной шаблонизаций обычно решается либо дублированием шаблонов на сервере и в браузере, но основе Jade к примеру, либо гоняют рендер в браузере или node.js, как это делается с React'ом или prerender.io.

Ну вот к примеру learni.st написан на Angular'е и отлично индексируется гуглем.

Сейчас наиболее перспективным является GWT-way, когда серверные шаблоны прозрачно транслируются в браузерные, и все изменения модели передаются посредством push нотификаций и по вэбсокетам или comet'у (socket.io / sock.js). Но для этого нужно ещё реализовать нормальную поддержку Virtual DOM суррогата, так как это сделано в React'e. В нём кстати самый толковый рендер DOM'a, из-за этого рождаются вундервафли типа ngReact.

В общем вопрос фронтенда за последние 3 года очень сильно усложнился с появлением различных MVC-подобных браузерных подходов, и jQuery уже "прошлый век". Сейчас всё упирается в реактивности с асинхроном и многопоточностями, а с ними в PHP / Ruby куча проблем. В Python этих проблем меньше, но и костыли там тоже встречаются, а в node.js вообще их нет... но производительность обоих решений оставляет желать лучшего.

Пробуйте golang, или Typesafe Stack / Grails.
На фронтенде веселее всего с React rx.js и socket.io / sock.js, но для коммуникации можно и что-то своё написать.

Ну как-бэ всё слишком просто.
Тынц, тынц, тынц.

Мало информации, а ванговать здесь никто не будет.

Если нужна асинхронность и push-нотификации в РНР - проще уж прикрутить ворекров для очередей типа Gearmand / Beanstalk.

Видел 100500 примеров как не надо писать RESTful сервисы.
Главное понимать задачи DataMapper'ов в рамках RESTful сервисов и AAA.
"Одна табличка - один CRUD контроллер с логикой" - путь в никуда.

Из бэкендов сейчас стоит двигать в сторону Typesafe Stack или Groovy Grails, и забыть про этот тупой РНР ширпотреп.

Play2 - прост как дверь, и достаточно быстрый, не без overhead'ов, но и выбирать сейчас особо не с чего :(
Если Scala не является препятствием можно двигать к Xitrum'у, но у него нет энтерпрайсной поддержки.
На Grails оч удобно реализовывать RAD приложения, правда производительность не очень. Но сравнивать можно только с jRuby или jyton'ом.

Python / PHP / Ruby / Node.js не подходят для реактивных приложений, и долгосрочная поддержка просто сущий ад. В общем рано или поздно приходится пилить Push нотификации и асинхронности и там обычно прикручивают Celery / Gearmand / Benstalk / RabidMQ etc естественно работает это не ахти ввиду накладных расходов на коммуникацию.

p.s. А, да, точно и зачем русским РНР программистам говорить о важности TDD/BDD ?...

Пишу на питоне ещё с 15 лет (2.4+)... ненавижу его runtime и архитектуру. Язык хороший - реализация никакущая. Ну да его синтаксис достаточно упрощён, но и за синтаксический сахар приходится платить сложностями отладки и поддержки.

Сейчас же почти все известные мне конторы не используют питон в продакшенах с более-менее высокой нагрузкой. Яндекс тому пример. Чаще питон используется для решения прикладных задач администрирования, так как это делается, к примеру, в SaltStack. Все дружно слезают с питона, РНР и рельсов на Golang, Java/Scala, и иногда даже Groovy - производительность выше в десятки раз, и managed runtime на много стабильнее. Правда в случае с JVM очень сильно раздувается куча в виду избыточности объектной модели (оператву жрёт как дурное, а я байтики считать привык). Сейчас это должно лечится с помощью Project Graal и Truffle, правда пока до этого дошёл только jRuby, который тоже в пару десятков раз быстрее Ruby. По идее и Groovy тоже должен переползти как-то ... Вот про jyton ничего не знаю.

Много моих знакомых слезло на Golang с Ruby и Питона.
Стоит попробовать - он достаточно простой и идиоматичный, вот рефлексию стоит обходить стороной - она очень медленная, впрочем как и везде. Работу может и не найдёте сразу, но после реализации пары простых проектов будет проще предлагать в качестве целевой платформы.

Фрилансить с питоном начать можно, но очень желательно опробовать ещё хотя бы пару окружений и фреймворков типа Groovy Grails, или Typesafe Stack. Сейчас требования рынка возросли в пару раз за последние два года - нужны ассинхронности/многопоточности, push-нотификации в мобильные приложения и по вэбсокетам/комету. И это всё с богатыми js-фронтендами на всяких там Angular'ах и React'ах. Естественно можно крутить костыли типа Celery / Gearmand / Beanstalk / RabidMQ, но накладные расходы на коммуникацию слишком большие :( Компилируемые языки со своими Managed Runtime'ами позволяют строить монолитные приложения в которых подобные решения избыточны в рамках одной и той же машины, а если это куча нод в кластере то нужно мерить/думать.

Django сейчас сложно поддерживать так как он достаточно сильно развился за последние 3 года, и я очень сомневаюсь что сохранится совместимость новых версий со старыми.

А вот с pyramid (pylons) и SQLAlchemy можно строить достаточно хорошие приложения. У них есть enterprise поддержка и соответствующие гарантии.

Типовые задачи на питоне:
- написать какой-то мелкий скрипт с Gui на PyQT / Pyside для какой-то аналитики и отрисовки графиков, иногда попадаются задачки с gstreamer'ом
- написать какое-то простое RESTful CRUD приложение, в стиле "одна табличка БД - один контролеер", это конечно же тонна копипасты и мне больше нравятся DataMapper'ы по типу TastyPie. Иногда люди хотят чистого Tornado или Flask'a, так как им не нравится overhead в джанге и pylons.
- написать скрипты для деплоя чего-то, обычно люди не знают про SaltStack.

В плане архитектуры питонистам чужды различные SOA с CQRS-ES'ом, потому что сам компилятор не располагает. Хотя её достаточно просто поддерживать.

Проблема всех проектов на Node.js / Python / Ruby это отсутствие долгосрочной поддержки библиотек и фреймворков - часто ломается обратная совместимость, и нужно постоянно следить за состоянием всех зависимостей. Опять же нужен TDD/BDD для того что это всё хорошо контролировать. Тестируешь руками - себя не уважаешь.

Ну и вроде всё ...
p.s. я опубликую на хабре статью сегодня-завтра "Freelance - you're doing it wrong" там поделюсь опытом работы и основными организационными проблемами в рамках удалённой работы и фриланса, покажу разницу между ними.

Отзывчивость - изменение размеров под конкретное расширение, это горизонтальные ритмы в % и вертикальные в em'ах rem'ах, или любых других относительных шрифтовых размерностях.

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

Есть display: table, display: table-cell, display: table-column, display: table-row их можно использовать для того что бы сделать из div'ов (или ещё чего-нить) табличку.

Количество колонок которое целесообразно отображать зависит от текущей ориентации дисплея.
Обычно для портретной ориентации это 2-3 колонки, а для альбомной 4-5.

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

Адаптивность реализовывается посредством media queries.

Желательно использовать препроцессоры с миксинами для упрощения генерации под весь набор расширений.