tugo

Микротик, Керио. Юбикьюти. Второе самое няшное. Но многие его не любят за это. Да и попроще он чем тот же миротик.

RewriteEngine On
RewriteCond %{REQUEST_URI} ! \.html$
RewriteCond %{REQUEST_URI} ! /$
RewriteRule ^(.*)$ $1.html

В htaccess. Обращение на /about будет открывать /about.html, к примеру

Не надо лицемерить.
Здесь единственный выбор это винда, никаких полноценных маткадов и офисов в линуксах нет.
>АПД: Было решено использовать две системы : Win 8.1 и linux Вторую хочу взять за основу.
Ага, и большинство времени проводить в неосновной системе.

Вы путаете IDE и компилятор, разберитесь что есть что.

Дальше есть 2 варианта с чего начать, сложно сказать какой "лучше":

1. Сразу поставить IDE (под Windows я бы выбрал Visual Studio, под линуксом я бы выбрал Qt, в обоих случаях речь идет о консольных приложениях, в Qt проект создавать через Non Qt Project -> Plain C Project / Plain C++ Project) и изучать сам язык. Когда-то позже дорасти (или не дорасти) до п. 2.

2. Начать с понимания того как это все компилируется: поставить линукс на виртуальную машину (если вы под виндой), писать код в любом блокноте (gedit, vim, под виндой notepad++), разобраться с консолью, gcc / g++, include, makefile. Потом перейти к п. 1.
Консоль (в т.ч. PowerShell) конечно и в винде есть, можно и без линукса обойтись, но по-моему там это было бы проще, натуральнее.

Если это ваш первый язык и нет никакого опыта в программировании, то пожалуй я бы выбрал первый вариант. Да и язык бы выбрал более высокоуровневый (Python, C#, Java, ...) или хотя бы С вместо С++, но на этот счет тоже есть много точек зрения, это холиварный вопрос

Забавные эти вопросы. Стоит ли изучать $programming_language1, чем лучше $programming_languageA $programming_languageB, etc. Просто забавны. Не то чтобы они не нужны - каждому делу свой инструмент. Сложно забивать гвозди отвёрткой, а вилкой вырезать по дереву (хотя и можно).

Так вот, внесу свою лепту - конечно стоит! И даже не стоит, а требуется. Пайтон уверенно просачивается в жизнь и часто требуется специалист C++ со знанием (знакомством) пайтона. Немного расширяет кругозор - всё же динамическое программирование с небольшой функциональщиной.

Но не стоит думать, что есть инструмент на все случаи жизни. Пайтон идеален там, где есть идея и больше ничего, хорош он и для прототипирования, очень не плох в научной среде. Но противопоказан для дальнейшего масштабирования, плох он и в стресс-тестированиях, в общем продакшн из него так себе, примерно как и у C++. Впрочем, он близок к средней по больнице.

Я проходил этот путь. Было время, когда достаточно хорошо я знал только Си++ (даже не Си). И в этом были свои проблемы. Теперь я полиглот. Из плюсов - очень быстро учиться что-то новое. Буквально сразу цепляю различия и могу скопипастить целый проект - этот навык сложно переоценить. Уже сотни раз писали, что пайтон хорош для прототипирования - повторюсь: вбиваешь в терминал python и печатаешь. В лаборатории сразу появляются формулы, графики, отчёты. У стартапа сразу появляется UI, логика, прототип. Но... Есть огромные минусы: в какой-то момент без хорошей документации очень тяжело идти дальше - виной очень крутая динамическая типизация. try: catch'и: и тут и там - снова она, ибо никогда не знаешь что тебе подадут в аргументах. Теперь священные воины пробелы vs табы (аля K&R vs BSD) могут обрушить весь проект вместе со сроками.

Ну и да. pyqt ужасен. Лучше использовать что-нибудь другое (хотя ничего другого особо и нет). Гейзенбаги (те, которые то появляются, то исчезают) - тысячи их. И та самая интерактивность сводиться на нет, дай только проекту разраститься до 100 строк - а это очень быстро произойдёт, никакой pythonic-way не поможет. Так померло много проектов, не успев начаться.

Наконец, если хотим кросс-платформы, с горечью вспоминаются ночи (!) проведённые за попытками скомпилировать какую-то полузаброшенную boost-подобную либу-зависимость какого-то гика на гите, который единственный подумал скинуть пару примеров использования всеми забытого протокола.

Зато все слухи про низкую производительность python'а - чушь и клевета. Эта @#$% очень быстра, по крайне менее, если писать подобающе, а не проходиться по словарям в миллионы элементов в сотый раз (если такие словари, пора уже БД подключать, наверное).

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

Кроме того можно попробовать начать с модификации примеров рабочего кода. Берите код из туториалов по интересным вам темам ( по тому же сетевому программированию огромное количество примеров как клиентов так и серверов ).

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

Посмею оспорить ход рассуждений 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.

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

Если проблема только с кириллицей и русскими путями, то проще всего будет создать symlink на Александр

mklink /D c:\users\alex c:\users\Александр