MegaMufa

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

По идее в модели должна быть логика работы с самой моделью. Коллекция ключевых слов - это формально другая модель или часть другой модели. Так что выносить однозначно стоит.

Cython разве не подходит? Он может и бинарники создавать. Есть еще вот такая штука https://github.com/JukkaL/mypy В третьем пайтоне есть аннотации legacy.python.org/dev/peps/pep-3107 они появились в результате большого желания Гвидо (если я не ошибаюсь) сделать 3й пайтон статически типизированным языком www.artima.com/weblogs/viewpost.jsp?thread=85551 www.artima.com/weblogs/viewpost.jsp?thread=86641 но сообщество было против. Да и вообще зачем нужна статическая типизация? Что бы усложнять себе жизнь? Пайтон язык со строгой динамической типизацией и этого вполне достаточно.

Как то так

<form>
    <textarea id='test' maxlength='200'></textarea><br>
    <span id='rest'></span>
</form>

$('#test').on('keydown', function(event) {
        var MAXLEN = 200;
        var str = $(this).val();
        var newLines = str.split('\n').length-1;
        var len = str.length+newLines*99;
        if (event.which == 13) {
            if (len > MAXLEN-100)
                return false;
            else 
                newLines++;
        }
        $(this).attr('maxlength', MAXLEN-newLines*99);
        return true;
    });

    $('#test').on('paste', function(event) {
        var MAXLEN = 200;
        var str = $(this).val()+event.originalEvent.clipboardData.getData('Text');
        var newLines = str.split('\n').length-1;
        var len = str.length+newLines*99;
        if (len > MAXLEN)
            return false;
        return true;
    });

    $('#test').on('keyup', function() {
        $('#rest').text($(this).val().length+'/'+$(this).attr('maxlength'));
    });

Посмею оспорить ход рассуждений lorus ( Android: Qt vs Java. Что лучше использовать? ).
Итог у нас почти один, но как в математике - когда ход рассуждений ошибочен - даже если ответ верен - то задача не решена. Возможно во много субъективно, но выскажусь, на правах личного мнения человека, который любит и писал и на Qt, и на Android с его "родным" Java тоже.
На Qt для Android не писал, потому что на момент начала последнего проекта технология была сырая.

И так: Не агитка за Qt но несколько слов в защиту Qt.

Забегая вперед скажу: топикстартеру - если есть небольшой опыт разработки под Андроид, вы не работали ранее с Qt, и вам не важна переносимость исходного кода между всем и вся - продолжайте осваивать Android SDK ( Java ) .
По крайней мере, сейчас.
Хорошее знание хотя бы одного инструмента, лучше чем посредственное знание двух. ;)
C Qt под Андроид потом разберетесь. Да и "пообкатаннее" оно будет.

1. Qt - это всё-таки C++. Разрабатывать на нём существенно сложнее, чем на Java. То есть дольше и с большим количеством ошибок.

Надо отличать "просто С++" и С++\Qt. В первую очередь, Qt - это фактически диалект языка С++. Например в объявлении Qt-класса появляются дополнительные секции signal и slots, а в процессе сборки существует фаза мета-компиляции, которая делает C++ код под вашу платформу. Не удивлюсь, если для андроида генерируется сместь Java и C++ кода которая потом скармливается Android NDK.

Во вторых, Qt - это _самодостаточный_ фреймворк. Никаких STL или "чего-что-ещё что представляют себе в комплекте с C++" типичные сторонние разработчики.
Многих проблем, которые приводят к сложности разработки "на простом C++" в "С++\Qt" просто нет "by design".

Например в Qt заложен замечательный механизм предотвращения от выхватывания "null-poiunter" - "сигнал-слоты". Это в разы упрощает и делает надежнее работу как с GUI, так и с например, объектами, работающими в разных потоках. В Qt это все сделать разы проще, чем городить аналогичные стандартные механизмы на Java. Я не говорю в итоге оно будет эффективнее - тут надо выяснять и можно поспорить - но вот то, что в Qt многие вопросы работы с потоками и межпоточным взаимодействием продуманы лучше а механизмы удобнее - на мой вгляд это факт.
(Хотя вот такого классного механизма аки runnable, в Qt нет. Но ждем 11-го стандарта С++.)

В третьих - "С++\Qt" - это хорошо продуманный фреймворк едва-ли не с лучшим дизайном классов, продуманными методлами, единым стилем решения проблем.

Как человек писавший на Qt 4.0-4.6 и сейчас закончивший первывый коммерческий проект для Android - могу выставить в сторону Java много минусов (в сравнении с Qt4/Qt5.) Просто потому, что Java - как в первую очередь коммерческая технология, был вынужден набирать нелогичности ради совместимости с предыдущими версиями - едва-ли не из первых версий Java. Посомтрите вопросы к сертификации - много вопросов, которые когда начинаешь разбирать "почему так" - уходят корнями в далекое темное прошлое развития Java. И в итоге - современная Java - это часто нелогичное, лоскутное одеяло, где в разных классах для решения одной и той-же задачи применяется если не разный подход и стиль, то как минимум разные имена методов. Ну вот зачем это?)))

Да Java детально описан, и в технически прогнозируем - но его надо зубрить, тупо зубрить все исключения и проблемы наследования логики первых версий, и зубрить где используется put(), а где add()....
... а Qt-можно _понять_ и не зубрить, понять и только изредка заглядывать в документацию. И в итоге писать на нем - легче.

К слову: дизайн классов гуглековских классов - хотя и очень-очень-оченьсвоеобразен и местами диковенен, но он, имхо, достаточно "строен" и в общей совокупности, не страдает такой уж сильной лоскутностью логики, какая имеется в стандартных классах Java. С какого-то момента ты понимаешь "как думали в гугле" и все становится несколько проще.

Ещё к слову про миф "на Java писать проще чем на C++"(если сравнивается Java под DalvikVM и C++\Qt5):
Не забывайте - DalvikVM - это вам не JavaVM.
В DalvikVM вы легко отхватите "null-pointer-exception" если вы вдруг наивно думаете, что коли у вас есть в локальной переменной ссылка на фрагмент, активити или вью - то машина не уничтожит объект "когда ей вздумается", а у вас ваша переменная не об-null-ится.

На понимание того, какие привычки десктопного написания и дизайна приложений нельзя переносить во фреймворки Android SDK и на перестройку собственного мышления - у вас уйдет несколько месяцев. А вы _начнете_ это понимать и отхватывать такие проблемы - как только начнете писать что-то бОольшее, чем набор разрозненных активити да пары фрагментов из учебных курсов.
И в итоге - первый ваш серьезный проект на Андроиде - может влететь вам в хорошие переработки.
Например, в том числе и потому что нет в Android SDK v17 жизненного цикла для класса Application. Нет механизмов для созранения состояния singleton-окружения и тд.и тп.

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

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

2. Инструментарий разработки для C++ однозначно хуже такового для Java в силу, опять-таки, особенностей языка.

Простите, но тоже малообоснованное утверждение. См пункт 1.

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

А когда вы пишете под Android на Java - вы всегда пишете кусок кода работающий в колнтексте DalvikVM и должны жить по предусмотренным данной машиной паттернам и сценариям, причем многие аспекты того "как это работает" - явно мало где прописаны. И если вдруг вы отсутпаете от стандартных шаблонов фреймворка Dalvik-машины - вы рискуете отгрести непонятные, трудно отловимые косяки, причем _вне_ вашего контроля, которые вы не можете корректно перехватить и обработать. Кто не знает - попробуйте уничтожить ViewGroup, id которого вы использовали как контейнер для размещения внутри него фрагмента. Как только вы делаете FragmentTransaction.commit() - вы ставите машине задачу, которую она будет выполнять "когда-то позже", вне вашего контроля, и не соизволит позволить вам корректно обработать исключение. Вплоть до возникновения ситуации, когда фрагмент пытается быть добавленным в Activity который уже отработал стандартные процедуры по Activity.finush(). Ладно бы оно выкинуло код ошибки куда, и тихо проигнорило - но это же Java - она выкинет исключение. А обернуть это дело в try...catch - вы не сможете - это не ваш кусок кода. Максимум что вы сможете - это "поймать перед смертью" Thread.UncaughtExceptionHandler. И все.
(если я не прав - поправляйте меня, я же тоже не инженер гугля)

3. Java - родная платформа для Android. Отсюда потенциальные проблемы с совместимостью у Qt.

Вот зачем вы занимаетесь запугиванием?
Android NDK (для разработки на С++) такой же родной как как и Android SDK (для разработки на Java).

И с совместимостью у Qt с платформой Android проблем не больше, чем у любого другого приложения, которое использует вставки C++ кода и разработано с использованием стандартного Android NDK.

--------------------------------------------
Резюмируя: автору надо просто взвесить что зачем и как он собирается использовать.
Если автору нужно одинаковое поведение на различных платформах - включая огрызочные поделия, Linux, разные Windows RT недопланшеты - то выбор ознозначен - курите Qt. Это возхитительнейший, ясный, хорошо продуманный и максимально логичный фреймворк, который не побоялись пересоздать с нуля ради устранения накопленных сложностей (вспоминайте переход с Qt3 на Qt4) Лично я приходил в восторг, когда работал с ним (2005-2009 гг)

Но - в части Андроидного приклада : подозреваю, могут быть "технические риски" с использованием каких-либо особых "мобильных кусков" типа "работа со звонками, "работа с контактами", "работа с почтой" или "поставщиками контента", и пр.
Я отошел от мира Qt когда Qt был 4.8 и я не искал там классы которые этим занимаются. Думаю что-то потомки троллей должны были создать в 5.2, но лучше проверить.
В крайнем случае - может потребоваться стыковка с джава-объектами, и тут вам потребуется изучать Android NDK, и возможно даже писать немного оберточного кода на Java.

Если же вам _нужна_ обязательная работа с описанными выше функциями, а на переносимость исполняемого кода - наплевать, или же у вас _уже_ есть опыт разработки с Android SDK - то конечно писать лучше на Java.

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

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

В любой сфере можно найти вакансии с упором на алгоритмы и логику. Даже в маленьком городе найдутся предприятия, которым надо автоматизировать что-то сложное. В свое время находил работу .Net разработчиком в маленьких городах (до 250 000 жителей) в НИИ, где занимался цифровой обработкой сигналов и на транспортном предприятии, где было море работы с граберами автомобильных номеров, RFID, шлагбаумами и Глонасс.
Если рассматривать фриланс, то на отечественных биржах с интересными сложными заказами (имею в виду только desktop, C#) очень туго, за активную 4-летнюю работу мне таких попалось от силы 5 штук. На odesk ситуация гораздо интересней, стоит начинать искать там работу.
В принципе сейчас становится все более реальным найти полноценную удаленную работу, есть примеры среди знакомых, которые приезжали в Москву на пару месяцев для прохождения испытательного срока, а после переходили на удаленку и возвращались домой.

По русскоязычным книгам я ничего не посоветую, кроме как забить на их поиск и выучить английский.
По английским: www.safaribooksonline.com/ (доступ по подписке), oreilly.com/ и еще я использую www.wowebook.com (я тут качаю книги на шару, однако везде есть ссылка на покупку книги в Амазоне для желающих)