Александр

1. Если Ваш сайт, то не надо так делать. Сделайте нормальный API, который будет отдавать json.
2. Если это не Ваш сайт, то как вариант поискать API того сайта.
3. Если это не Ваш сайт и API нет, то лучше сделать отдельно свой сервер с API(сервер будет парсить сайт и отдавать в JSON приложению). Почему так? Парсинг на клиенте(особенно мобильном) будет кушать много ресурсов(причем заметно), это снижает заряд батареи, тормозит и много других неприятностей.

Структуры данных - обязательно. Вы же с данными работать будете, как можно не знать структуры.

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

Лень двигатель прогресса. Хороший пример - принцип DRY - Don't repeat yourself. Я весьма подозреваю что вы стараетесь соблюдать этот принцип когда делаете макеты или чем вы там занимаетесь. Так же я весьма уверен что вы хотя бы пытались чуть автоматизировать рутину своей повседневной работы. Так же у вас могли быть ситуации когда вы переиспользовали какие-то элементы. Мало ли.

Так вот... CSS это тупая таблица стилей. Селектор и стили, ничего сверх умного тут придумать нельзя. Лет 5-10 назад было довольно модно держать один мегажирный CSS файл на 10К+ строк и радоваться жизни внося все больше изменений и т.д. Соответственно даже если вы соблюдаете всякие правила модульной верстки и все такое, у вас возникает несколько проблем:

• организация стилей, то есть держать все в одном файле не удобно особенно когда проект длится годами
• Дублирование стилей и селекторов. По мере развития проекта появляются какие-то снипиты которые можно реюзать. Так же у вас может появиться масса однообразных селекторов отличающихся лишь немного. При модульных подходах вложенности редко имеет место быть но все же имеет. Но не будем забывать что большинство фигачит селекторы просто так. В итоге если мы переместили блок или переименовали класс какого-то блока нужно отредактировать еще массу селекторов.
• Привязка размеров и параметров к другим стилям, например у вас в стилях задана ширина блока, от нее зависят другие параметры, отступы для других блоков и т.д. Да, в css3 появился calc для этого но это было относительно недавно и только с недавних пор можно почти без опаски использовать эту штуку.
• Таблицы стилей, как и HTML ориентированы на удобный разбор этого добра машиной, но не человеком. Человек же существо ленивое и как-то вот лень лишний раз скобку поставить или точку с запятой. Просто лень.

Есть так же хорошее правило, или идея если хотите.... Если код можно сгенерить - его лучше сгенерить. То есть для решения всех выше перечисленных проблем придумали препроцессоры. Они как бы были и раньше всех этих scss/less/stylus но как-то не решали всех проблем и т.д. Что в итоге было предложено (перечисляю в том же порядке что и в списке выше).

• У CSS есть такая штука как @ import. Но не очень круто импортировать сотню стилей в продакшене. Стоит сделать так что бы все стили были склеены при сборке проекта. Эта идея в итоге развилась и если разработчик использует это дело правильно, можно зайти в любой файл со стилями и увидеть список всего от чего зависят эти стили. Какие стили подключаются и т.д. Причем один файл с зависимостями может быть подключен в нескольких файлах а препроцессор сам разберется как и куда все вставлять сгенерив максимально оптимизированный по структуре файл. А разработчик получил четкую структуру файлов и возможность быстро найти где что и от чего зависит.
• С селекторами проблему предложили решить наиболее логичным вариантом. Если у нас есть вложенные селекторы, то имеет смысл определять их внутри блока этого селектора. Это существенно упрощает поддержку стилей. Так же для управления снипитами и прочим добавили миксины - эдакие параметризованные или нет функции которые выплевывают шматок CSS. До появления штук вроде autoprefixer это был единственный способ писать поддерживаемые стили, использовать плюшки CSS3 и вообще новые плюшки и не сойти с ума от префиксов. Префиксы это только пример, там могут быть самые разные штуки позволяющие грамотно производить реюз стилей
• Проблему зависимостей значений стилей друг от друга решили... собственно самым очевидным способом - переменные. Это удобно, легко поддерживать и в умелых руках это мощный инструмент. Нужно поменять базовые цвета - не нужно лазить по 100500 блоков и править значения руками, можно поправить переменные и все будет хорошо.
• Насколько я помню SCSS/LESS не стремились решить эту проблему. Какие-то решения образовывались сами собой с течением времени. В плане минимализма и выразительности пожалуй сейчас самая крутая штука это stylus.

Что в итоге произошло. В один прекрасный момент какие-то там рубисты придумали SCSS (они вообще не любят все что не в стиле ruby в плане минимализма и выразительности). Затем чуваки подумали и сказали, SCSS это круто но почему-то они используют синтаксис знакомый именно Ruby разработчикам а не обычные для CSS конструкции. В итоге реализовали LESS, причем его уже реализовали на javascript, что с наличием node.js позволило это все добро еще на одной платформе собирать. А так как под эту платформу и так плодили препроцессоры оно удачно вписалось.

Далее уже шли какие-то модификации дальнейшие, вроде того же Stylus, где синтаксис упростили просто до нельзя.

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

Забудь про фриланс, сколько бы про него не говорили, это биржа ДЕШЕВОЙ рабочей силы со всеми вытекающими последствиями в виде кидалова, низкой зп, скучной работы, туда идут люди с серьезными проблемами вроде невозможности перебраться в город, социопатии, инвалидности, "утонченная личность", фриланс это почти всегда вынужденная мера. Вообще фриланс и стабильный заработок несовместимые понятия, просто потому что фриланс подразумевает постоянный поиск мелкой работы, никакой заказчик не будет давать большой серьезный проект фрилансеру никогда, потому что это большая ответственность, посмотрите соседние вопросы, пацики с рейтами 150баксов в час работают 10 часов в месяц, а остальное время ищут заказы, причем это люди с опытом и портфолио + отличный английский. Начинать карьеру с фриланса это 100% гарантия того что, все что можно сделать неправильно (техническая сторона), будет сделано неправильно, потому что работает, дедлайн вчера, а подсказать или сделать код ревью некому, никакие книжки тут не помогут, выбора не будет, ты либо читаешь либо работаешь. Так что не советую ввязываться в эту тему. Лучше начать работы в офисе под строгим надзором. Ну и конечно html+css+js это мало, нужно знать еще около программисткие штуки вроде систем контроля версий, багтрекеры, несколько ide/ текстовых редакторов, если это веб почти гарантированно надо иметь представления о http/https, ООП, возможно sql. Не то чтобы для 20к месяц все это нужно отлично знать, но как минимум иметь представление, чтобы не отвлекаться. Вот по фронтэнду. Для большой гарантии устройства на работу, как уже сказали выше, лучше сделать себе сайт, а еще лучше сделать небольшое портфолио и выложить на гитхаб, это сейчас очень модно. На изучения всего вышеперечисленного уйдет 1-2 месяца если сидеть по 8-4 часа в день примерно, свой сайт где-то неделю на разработку визитки и еще неделя на вылизывание, но оно того стоит, а в процессе поиска работы можно и на гитхаб по чуть-чуть кидать, хотя вряд ли получится много. Удачи.

Чтобы установить python 3-ей версии по умолчанию в ubuntu есть 2 способа:

1. добавляете вот такую строчку alias python=python3 в ваш ~/.bashrc или ~/.bash_aliases файл и обновляете сам файл source ~/.bashrc (этот вариант будет работать только для той учетной записи, под которой вы добавляете алиас ).

2. выполнить sudo ln -sf python3 /usr/bin/python. эта команда обновит ссылку на питон в вашем /usr/bin каталоге (этот вариант будет работать для всех учетных записей).

Естественно, оба варианта будут работать только если питон 3 уже установлен на машину :)

Насчет sublime text 3 @brutal_lobster привел правильный конфиг. Единственное, что этот конфиг сработает, если в /usr/bin/ имеется файл python3.3. Если его там нет, путь нужно будет указать абсолютный. Например такой: "cmd": ["/usr/bin/python3", "-u", "$file"],