Банально, но крайне практично и эффективно:
видим сайт с хорошим или приятным нашему глазу дизайном:
а\ жмём ПКМ > Исходный код
б\ жмём F12
изучаем. Учимся
Рекомендую!
p.s. Если что-то в коде не понимаем или просто находим интересные моменты кода - повторяем это самостоятельно в своём HTML\CSS, как урок.
Поскольку, различные правила постоянно обновляются и модифицируются, актуальная версия всех правил и рекомендаций по защите веб-сервера доступна по этой ссылке.
Забудьте о двух версиях письма. Делайте одну. Резиновыми таблицами. Приложение gmail медиазапросы не понимает. Ссылку на мой фреймворк уже дали выше. Там есть шаблона письма, который можно повертеть для понимания. Sergey Goryachev все верно говорит.
Никак. Gmail (мобильный клиент) не поддерживает медиа-запросы.
Верстка резиновыми таблицами, где можно.
PS: Верстальщик писем, опыт 5 лет.
PPS: Имеется ввиду самое кроссплатформенное решение.
Первый этап — подумать, надо ли это вам вообще. К хорошему дизайну на кривой козе не подъедешь.
Прежде всего: Майк Монтейро «Дизайн — это работа». Даже если не будете потом заниматься дизайном — книга все равно полезная.
Во многом избавляет от романтического подхода вроде «дизайнер — это художник».
Второй этап — учиться: смотреть и делать свое.
Только, во имя всех скандинавских богов, смотреть не на Behance и Dribble. Там красиво, конечно, стиль, все дела, но в конечном итоге 95% работ там просто картинки.
А веб–дизайн — в первую очередь сценарий. Дизайнер определяет то, как пользователь будет пользоваться сайтом: в его власти сделать интерфейс простым и ясным или запутать до невозможности.
Посмотрите работы бюро Горбунова, особенно процесс создания.
Соответственно свои работы тоже нужно рассматривать с точки зрения полезного действия, а не внешней красоты. Эстетика — это третий этап.
Учиться значит читать, в первую очередь. Чтобы делать правильно — нужна система.
Читать лучше от общего к частному, начать стоит с этого:
Дональд Норман «Дизайн привычных вещей»
Виктор Папанек «Дизайн для реального мира»
Параллельно:
Генрих Альтшуллер «Найти идею»
37Signals «Getting Real»
Веб — это интерфейс, значит:
Джеф Раскин
«Новые направления в проектировании компьютерных систем», «Об интерфейсе»
Брюс Тогнаццини «Главные принципы интерактивного дизайна»
Якоб Нильсен «Веб-дизайн. Книга Якоба Нильсена»
Веб — это шрифт и текст, стало быть:
Ян Чихольд «Новая типографика»
Эмиль Рудер «Типографика»
Нора Галь «Слово живое и мертвое»
Саша Карепина «Искусство делового письма»
Веб — структура и верстка:
Тим Харровер «Настольная книга газетного дизайнера»
Мюллер-Брокман «Модульные сетки в графическом дизайне»
Оставлю за кадром книги по самоуправлению и переговорам, это уже другая фаза.
Про английский язык и умение верстать уже сказали, повторяться не буду.
Я прошел этот путь дважды, и 15 лет назад нечаянно получил экономическое образование, поэтому посчитаю, что имею право советовать.
Вы для себя можете ответить на вопрос, что такое "серьезная компания"? В письменном виде опишите критерии. Потом прочтите Rework. Потом, когда освоитесь на фрилансе, обнаружьте, сколько там серьезных компаний. Кроме шуток.
На каком этапе вы будете считать себя серьезной компанией? Когда вы будете не работать, а руководить? Обломлю: руководство - более жесткий и тяжелый труд, нежели чем делать что-то низкоуровневое самому.
А вообще, выше написали верно - рулят идеи и процессы. У вас есть достаточно ценная идея, которую можно превратить в процесс, которая позволит вам уверенно конкурировать? А подсчитать в цифрах свои возможности можете? И отдельно изучите риски. Прям погуглите "риски в бизнесе".
У меня у самого так не получалось (приходилось постоянно доделывать за наёмными рабочими). Но в компании, где я работал, было примерно так. Берётся крупный проект, первое самое ответственное время его ведёт такой человека, как вы. Не кодит. Но постоянно всех разрабов собирает и подробно обсуждает, что, как и когда будет сделано. Начиная с определённого момента он постепенно снижает своё присутствие, перекладывая полномочия на самого ответственного и опытного разраба (вплоть до общения с заказчиком), а сам переключается на другой проект.
Возможно, вашу проблему сможет решить размер проектов. Т.е., не 20 небольших, а 3 огромных. Тогда вам не надо будет особо вообще вникать, начиная с определённого этапа.
Я знаю немало художников, которые отвратительные дизайнеры.
А также отличных дизайнеров, которые не умеют рисовать в традиционном понимании — пейзажи, людей и тд.
Веб дизайн это все же в первую очередь создание удобного интерфейса, а только потом рисование. Посмотрите на флэт-дизайн - где там нужны навыки художественных училищ? :)
А если размеров куча? Что, десятки файлов разные держать? Исходите из ситуации, если стилей очень много и размеров мало, то ваш вариант подходит, а когда стилей мало, но размеров много то проще все в 1 файле держать!
При многопоточном программировании имеется несколько потоков, которые выполняют разные "программы", взаимодействующие друг с другом. Например, поток пользовательского интерфейса, поток вычислений, поток обработки ввода/вывода. Многопоточное программирование позволяет упростить (при адекватном подходе) архитектуру программы, но требует отдельных навыков при проектировании и отладке.
Параллельное программирование применяется для численных расчетов, или, например, в компьютерной графике. В этом случае "программа" одна, данные разные. Использование конвейеризации и большого количества вычислительных ядер позволяет получить значительный прирост в скорости вычислений.
Прокси позволяет отлавливать какие-либо действия с объектом и перенаправлять их на другой объект, либо направлять в назначенный обработчик. По-моему, довольно полезная вещь - сэкономит множество строк кода в некоторых ситуациях. К примеру, вместо того, чтобы в разных местах прописывать что-то после изменения свойства объекта, можно назначить 1 обработчик, который сам будет все делать.
Ну а Reflect - это просто набор полезных методов для работы с объектами, половина которых - просто переписанные сущеествующие.
Сейчас главный разработчик на огромном портале.
Пришел туда так как пригласил однокурсник ( сейчас он тимлид ). Знал php на уровне недобыдлокодера. js - чуток Jquery. Html/css более-менее.
Предыдущие разрабы свалили на более "вкусные вакансии" - у одного теперь своя студия а второй теперь заместитель директора одного крупного автомобильного портала.
У нас двоих в итоге "модифицированная" этими злыми гениями UmiCMS устаревшей век назад версии. Задачь с дедлайном вчера на несколько листов a4. И огонь в глазах. Сначала это был ад. Костыли на костылях, контроль версий или бэкапы? нет не слышали! Хакерские атаки и 3 шелла. Постоянные попытки поднять внезапно упавший ночью сервак и сотни тысяч других радостных у ужасных ситуаций.
Сейчас нас уже 5.
Читая хабр, выполняя работу и постоянно развиваясь я вырос в неплохого backend разработчика. Научился классным штукам вроде git с push autodeploy, laravel, nodejs, composer, npm, bower, gulp, scss, haml. Подучил jQuery и создал для проекта 3 плагина, Angularjs, Backbone, Html5 bootstrap.
Однокурсник вырос в тимлида и подучил UX и продвинулся как менеджер, создал проект который увеличил прибыль компании.
После того как к нам пришли 2 дизайнера и один frontend ninja все стало просто замечательно.
Итог - нужно найти компанию где согласятся взять джуна. Сейчас очень многие компании выращивают своих специалистов. Даже если нет наставника - не стоит отчаиваться. Опыт придет с работой. Главное упорно работать и применять мозг для сокращения объема работы, изучать технологии. Создавать для забавы мини-проекты.
Единственный минус - первое время зп будет критически малой. Но это можно компенсировать фрилансом.
