Павел Тетюев

Кончено, можно учить сначала C++, потом Qt5 потом qml, но мне кажется что в одной книге это было бы удобнее.

Размером такая книга будет с войну и мир, так что не думаю, что она когда-нибудь появится.

Потому план такой:

• Берем любую книгу по С++, того же Шилдта например
  
• Берем любую книгу по Qt не ниже 4, того же Шлее например
  
• Берем примеры программ из стандартной поставки и смотрим их
  

Получится правильная общая картина, которая легко дополняется документацией и статьями. Вот еще хороший обзорный мануал: qmlbook.github.io

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

CSS
.first-block:hover .second-block{
display: block;
}

Аля пример.

А зачем вам ещё варианты? :nth-child и :nth-last-child прекрасно справятся с задачей.
Думаю, что ещё с помощью flexbox можно замутить, но :nth-child покроссбраузернее будет, мягко говоря.
Действительно, можно (пример в разделе A Quickie Example).

Если эта штука будет абсолютно статичной - то делайте картинкой и не парьтесь.
Если хочется чтобы эффекты можно было присобачить - делайте свг.
tympanus.net/Development/TextInputEffects/index2.html - чекните Nao и Shoko, там при фокусе/блюре как раз идет анимация волнистой линии. Правда там линии изначально прямые, а кривая часть спрятана в оверфлоу и видна только во время анимации. У вас по виду так же красиво не получится сделать.

Не уверен, что подходит для новичков, но как вариант — получение данных, которые могут быть разбиты на несколько страниц. Например, API Яндекс.Расписаний отдаёт не более 100 элементов за раз. На случай, если элементов больше, есть специальная секция pagination и там булевое поле has_next. То есть код должен выглядеть как-то так.

$page = 1;
do {
    $data = jsondecode(file_get_contents("https://api.rasp.yandex.net/...&page=$page"));
    // bla-bla-bla
    $page++;
} while ($data['pagination']['has_next'])

То есть, do while нужен там, где не обойтись одним действием для проверки условия.

Как говорит мануал, $_POST заполняется только для HTTP Content-Type application/x-www-form-urlencoded или multipart/form-data.

Значит, разбирать вам этот запрос вручную надо. Кратко говоря:

parse_str(file_get_contents('php://input'), $rgInputData);
//var_dump($rgInputData);

www.google.com/intl/ru_ru/contact
Но вообще им насрать к сожалению. В gmail баг с не выключающейся пересылкой почты исправляли ~3 года.

PS Отдел веб-разработки google - это звучит. Так и представляю себе комнату такую, там сидит человек 15 - отдел веб разработки :)

Лень двигатель прогресса. Хороший пример - принцип 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 хоть на малых хоть на больших проектах. Вот вообще никакого.

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

Вкратце, полноценный клиентский разработчик должен знать:
– html5/css3 + bootstrap
– один-два препроцессора (less/stylus)
– чистый js и пару-тройку клиентских библиотек или фреймворков (knockout/backbone/angular/react)
– немного node.js, чтобы уметь пользоваться пакетным менеджером (npm) и билд-менеджером (gulp/grunt)

Этот список покрывает большинство клиентских задач в средней студии или стартапе.

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

Другой вопрос – что со всем этим делать.

Я обычно предлагаю попытаться начать свой маленький проект. Какой-нибудь простенький личный сайт, игру на js (тот же flappy bird или 1048 – много ума здесь не нужно). Посложнее – свою тему или библиотечку. Это будет хорошим практическим опытом, который не стыдно описать в резюме.

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

Если говорить о личном опыте, то я неплохо подтянул js с помощью codewars – задачки начинаются от самых простых (преобразование строк, перебор массива), до очевидно тяжелых (собственные интерпретаторы и преобразование данных изображения).

А вот попытка спихнуть на верстальщика UI/UX – это уже экономия со стороны отдельных контор, которые по какой-то причине не хотят нанимать отдельного дизайнера/проектировщика в штат или по контракту. Тут, к сожалению, придется мириться и смотреть статьи по теме – тот же GoodUI.