German Jet

В любом случае js лучше выучить. Как минимум, чтобы понимать, почему что-то работает нет так как запланировано (часто в силу особенностей js).

PS Если в jquery можно обойтись их api с минимумом чистого js, то во многих фреймворках придётся часто использовать ванильный js.

Самое простое - взять Flask и SQLAlchemy. Прикрутить ОРМ джанги к готовой базе труднее, чем в SQL. Да и сам фласк не навязывает свои решения, он модульный. Нужна админка - ставь отдельно. Аутентификация тоже отдельно. ОРМ отдельно, и т.д.

А инфы мало, потому что сам фреймворк маленький. В документации фласка всё есть. Для всяких расширений доже документации обычно хорошие. Мне обычно хватает инфы из доков.

Будут (возможно) пробемы с юникодом. Например, для имён моделей в 2.7 надо перегружать __unicode__, а в 3-м - __str__. Ну и не стоит ещё забывать, что http будёт слать всё в однобайтовой кодировке, что в 3-м питоне обозначается как тип bytes, а не str. Поэтому, иногда придётся делать decode.

Например, во фласке в 3-й ветке, тестовый клиент сохраняет данные в response-объекте в виде bytes, а JSON умеет только со строками работать (которые в 3-й теперь только юникод). Надо декодировать. Хотя в самом фреймворке (не в тестовом клиенте) не надо так делать, он сам декодит как надо.

Ну и почитай основные отличия веток: print теперь функция, методы словаря iteritems, iterkeys, itervalues упразднены, так как итераторы теперь используются по-умолчанию (остались только items, keys, values). Некоторые либы (в том числе urllib) поменяли структуру, так что некоторые модули надо будет импортить по-другому. Ну и так далее.

Ну... Первое, что приходит в голову, это сохранение данных для входа в переменных.

def logged_in():
    # в сессии будет храниться информация о том, что пользователь вошёл
    return session.get('logged')

# от этого класса должны наследоваться все классы админки - кроме индекса
class MyView(BaseView):
    def is_accessible(self):
        return logged_in()

    def _handle_view(self, name, **kwargs):
        if not logged_in():
            # делать редирект в некоторых случаях не стоит
            return self.render('admin/login.html')

class AdminIndex(AdminIndexView):
    @expose('/', methods=['GET', 'POST'])
    def index(self):
        if request.method == 'POST':
            frm = request.form.get
            login = frm('login')
            password = frm('pass')            

            # проверяете введённые данные...
            if ...
                session.update({обновляете сессию})
                session.modified = True
                return self.render('admin/index.html')
            else:
                return self.render('admin/login.html',
                                   error=u'Ошиблись паролем?..')
        # уже вошёл, но перешёл на /admin/
        if logged_in():
            return self.render('admin/index.html')
        return self.render('admin/login.html')

    # остальные методы класса

А с чем возникли сложности?

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

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

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

Я бы пытался настаивать на постепенном развязывании системы и рефакторинге с последующим переводом на Symfony2

Откуда уверенность, что поддерживать Франкенштейна будет проще, чем просто сложное приложение? И что значит "поддерживать"? Вам не хватает гибкости для дальнейшего расширения? Тогда однозначно затык не в языке или базе, а в структуре.

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

Не хотите даже структуру базы и работу с сессиями менять? Тогда все просто:
1. Разработчиков Джанго меньше, чем разработчиков пхп (подставьте ваш фреймворк)
2. Разработчиков перепиленного под пхп джанго еще меньше, чем просто разработчиков джанго.

Я бы может сказал, что в Rails есть некоторые возможности поизвращаться, что б поддерживать кастомные названия таблиц, структуры и т.д., но как-то не логично: использовать фреймворк (культуру, опыт и бестпрактис сообщества), что бы пойти против культуры, бестпрактис и опыта сообщества.

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

Сначала загружайте jQuery, потом jquery.tools. То есть вот примерно так:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
<script src="/media/jquery.tools.min.js"></script>

Но как правило никакого смысла загружать jQuery нет, он уже есть в jquery.tools, однако можно скачать и без него, поэтому попробуйте и так, и так.

Но использовать такую старую версию jQuery и jquery.tools нельзя ни в коем случае, если это новый проект. Используйте новые инструменты. Это можно только если вы поддерживаете старый сайт, и с новыми версиями оно не заводится.

Во-первых, надо знать основы программирования. Что такое цикл, переменная и т.д.
Во-вторых, надо знать HTML & CSS на среднем или высоком уровне.
В-третьих, надо развернуть локальный сервер для мучений и испытаний!
В-четвертых, надо приобрести/скачать хорошую IDE. Лучшая - PHPStorm (ИМХО).
В-пятых, надо подготовить Базу Данных. Я советую MySQL. Есть книги которые предполагают умение работы с Базами Данных, а есть те, которые Вас этому постепенно обучают. Если предполагает знание SQL, то сначала купите книжку с кратким курсом SQL.
В-шестых, приобретите книгу. Я настоятельно советую всю серию Head First от издательства O'Reilly - Изучаем PHP и MySQL. Там внятно объяснят все! Без замудрения! Просто и понятно от А до Я. Книга как уже понятно расчитана что Вы не знаете MySQL, SQL. Самое главное отличие от ВСЕХ книг по PHP - она написана интересно. Вы сможете написать первый код после 2 страниц. Все объясняется на ПРИМЕРАХ, тобишь на приближенных к реальности Проектах. Все рассказывается на картинках, якобы беседах между функциями PHP. Кучу упражнений!
Вы сможете закрепить свои знания и поймете что Вы об этом не УЗНАЕТЕ, а будете ЗНАТЬ! Я видел много книг, но эту книгу считаю лучшей.
В-шестых, Вам нужно любить Программирование! Любить кодить! Любить то, что Вы делаете. Полюбить PHP.
-------------------------------------------------------------------------------------
Лучшая книга по PHP - www.headfirstlabs.com/books/hfphp
Книга по SQL если вы не выберите книгу выше - www.headfirstlabs.com/books/hfsql
Книга по HTML и CSS - msiter.ru/knigi/dzhon-dakett-html-i-css-razrabotka...
Еще книга по HTML и CSS - www.headfirstlabs.com/books/hfhtml
Сервер для пыток (там-же можно работать с Базами Данных) - open-server.ru
Лучшая IDE (скачать) (ИМХО) - rutracker.org/forum/viewtopic.php?t=4830573
Лучшая IDE (купить) (ИМХО) - www.jetbrains.com/phpstorm

как по мне, тут главное страсть к программированию.
Придумайте себе проект который вы хотели бы сделать, и делайте на досуге.
Или найдите клиента под свой проект, дабы интересное с деньгами совместить.

В начале я занимался дизайном сайтов, рисовал макеты и т.д.
Потом перешел на сис. админа. (это отдельная тема развития от win до linux)

а начинал с Perl, особо ещё даже не подозревая что такое Linux.
Просто сам освоил и писал сайты, каталоги, гостевые книги, чаты.

Потом услышал про php, в принципе почти одинаковые языки были.
Перешел на php, начал писать применять.
Сайты делать.

Потом попросили сделать в клинике - мед. систему. начал делать,
заодно изучил весь JS, MYSQL, CSS3, ну html понятно - оно простое.

Писал своё, писал систему, ещё кто то попросил сайт доделать.
Так и идет.

Вот недавно добрался до Фреймворков, понимая то что на чистом языке писать больше и не особо безопасно стало.

Главное чтобы была страсть. А резюме вы себе сделать успеете.
А насчет сторон познания, сейчас столько всего выходит нового, что нифига не успеваешь следить, даже супер про. пока они пишут на одном - уже 10 новых вышло продуктов.
Можно даже не морочить голову. Главное результат!

Дорога открывается под ногами идущего.

Так же как и через броузер. Отправляем запрос от phonegap приложения серверу, получаем JSON ответ, отображаем данные на клиенте.

UPD
простенький пример
samcroft.co.uk/2012/posting-data-from-a-phonegap-a...

Я даже текст вопроса не менял lmgtfy.com/?q=%D0%9A%D0%B0%D0%BA+%D0%B2+phonegap+%...

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

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

Но в какой то момент, я решил попробовать программировать. Я начал изучать PHP. Ну с ним естественно MySQL, HTML, CSS, JS.

О как я был слеп. Войдя в мир программированя, я понял, почему будучи художником, и еще стал учится музыке. Мне не хватало. Я чувствовал голод. Но погрузившить в программирование, я "нашел мир своей душе" (только Бог может дать истинный мир). Я насытился. Я получил все что надо.

Я всегда думал что я гуманитарий и точные науки, я не потяну. Даже в институт из за этого не пошел. Но оказалось, что я просто был обманут тем фактом что в 10 лет был отдан в Художественную школу что и сформировало следующие 22 года моей жизни.

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

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

Короче

Коротко ответ на вопрос. Может и у вас скрытый талант и любовь к этому. Может попробовав вы уже не сможете от этого отказаться. А может и нет.

Ни знаю стоит ли изучать програмирование дизайрену, но уверен что попробовать уж точно стоит.

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

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

Что касается литературы - читайте всё, литературу для разработчиков, аналитиков, архитекторов, руководителей. Так поймёте, что хотят от инженера по тестированию. Литературу для инженеров по тестированию тоже читайте, так научитесь говорить на одном языке с коллегами.

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

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

Оукей. давайте возьмем ваш пример с fl.ru + чаты.

mongodb - хипстерская база данных. Для проекта типа fl.ru я бы пожалуй не использовал оную (не потому что монга отстой а потому что я лично не вижу в использовании оной смысла в контексте проекта типа fl.ru. Нам не нужен шардинг, реплекация реализуется нормально на любой нормальной RDBS, документоориентированность не нужна, хотя при грамотном подходе можно было бы реализовать неплохие агрегированные коллекции и оптипизировать селекты... Для себя не нашел у монги ни одного плюса перед RDBS типа PostgreSQL). В любом случае если вы не оставляете выбор - тут у нас будут храниться все данные. Придется потратить время на то что бы избавиться от желания что-то заджойнить и реализовать map/reduc-ы для обновления связанных коллекций. Но зато это будет так по хипстерски!

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

sphinx - поисковой индекс. То есть если мы должны реализовать вменяемый поиск (например по описанию вакансии) - то стоит его заюзать. Сфинкс не самый дружелюбный зато один из самых быстрых поисковых индексов. Хорошо интегрируется с MySQL и подобными и если сравнивать с ElasticSearch из коробки чуть лучше дружит с русским языком. Но опять же у эластики свои плюшки. Некоторые оной заменяют монгу так как по большинству фич в плане хранилища данных они совпадают.

redis - мы там вроде чатик делали. Помимо того что redis это хорошее key-value in-memory хранилище, которое к тому же может обеспечить нам надежность хранения данных (мэпится на файловую систему еще), оно так же поддерживает pub/sub. То есть чисто теоритически мы можем не добавлять в стэк штуки типа ZeroMQ и прочие *MQ для реализации авторизации и связи приложения чатика и основного приложения (вдруг у нас чатик будет написан на go/node.js/erlang).

memcache - вот тут стоит подумать нужен ли он если у нас есть редиска. Раньше для жирного кеша выбор был очевиден - memcached, так как reddis в те времена не поддерживал кластеризацию. Сейчас же по возможностям редиска далеко впереди. Так что даже то что memcached чуточку быстрее (но жрет больше памяти и не поддерживает авторизацию к примеру из коробки) не должно стать поводом для использования оного. Но я если честно redis в кластерах не использовал и ничего говорить не могу, а memcached испытан годами.

Лучшие инструменты это текстовый редактор + мозг.
Дримвивер не поможет вам понять основы и вникнуть в смысл построения сайтов, а лишь научить тыкать кнопки.
Лучше старайтесь больше изучать по книгам и мануалам в сети таких много.
Редакторов уйма. Мне лично по душе Sublime Text.

Вариантов-то немного. Либо пишете на том, на чем знаете, либо пользуетесь возможностью и пишете, параллельно изучая что-то новое. Знаете JS — так и делайте на nodejs.

Это можно сделать:
1) на каждом компе в организации прописать адрес в /etc/hosts. Это плохой путь.
2) внутри организации, поднять DNS сервер, если его еще нет. По DHCP (если используется DHCP) выдавать адрес вашего DNS сервера. На этом DNS сервере добавить. Это нормальный путь.