Nick Murzin

Изучение CSS Разметки - ru.learnlayout.com

Тут нужно ответить на вопросы: сколько страничек будет на сайте? Будут ли эти страницы добавляться и как часто/много? Сайт будешь вести ты или не знакомый с html и css человек?

Если страниц не много, контент почти не обновляется, а сайтом занимаешься лично ты, то конечно проще статичные странички.

Если страниц много, контент динамический и добавляется каждый день через удобную админку, тот тут без вариантов нужна CMS.

Если я проведу с вами онлайн собеседование, то вы явно его завалите.
Об этом говорит

JQuery, js(немного),

Если бы было JS, Jquery ( немного ), то возможно бы и прошли.

sass - там и учить то нечего. Вот если на отлично знаешь CSS 2/3

НА самом деле, вам надо сверстать с нуля простой макет (скажем блога), и тогда люди уже скажут что и как. Просто глядя на код.

По теме: я сам впервые устроился в сферу веб, где то около 16 лет. Правда это был 2000-2001г =)
Тогда и без трудовой и вообще бумаг работал. На тот момент получал 250$ (да! тогда были доллары в ходу).
Спустя два года, я уже поднаторел в верстке/дизайне/php программировании. Перешел в ужасную русскую компанию (желто-красную), где получал уже 30000р. (это как сейчас 60т.р.). Ну а далее по накатанной. Издательский дом, различные IT конторы и в итоге свои проекты, стартапы. Теперь я нанимаю а не меня =)

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

знание самого php на уровне джуниора (первые четыре главы мануала тобиш вы должны знать хорошо). Базовое понимание ООП (расчитывать на то что вы все будете понимать не приходится). Далее - читаем phptherightway и документацию по целевому фреймворку и best practice по ним (что пока возможно только для Symfony2)

Начните с базового и постепенно переходите на изучение сложных вещей: кейсы, аналитика, анализ оптимизированных сайтов.

• Прочитайте Яндекс.Помощь для Вебмастеров: Информация на сайте, в PDF-формате
• Google.Помощь для Вебмастеров для начинающих: Руководство по SEO, есть версия в PDF - хоть старенькое, но информация актуальна
• Изучите исследования SEO от ТопЭксперт
• Зарегистрируйтесь на профильном форуме SearchEngines.ru
• Читайте публикации на SEONews.ru
• Найдите и подпишитесь на рассылки известных SEO-блогеров. Например, ADNE.iNFO, Devaka.ru, Maul.net, Александр Люстик, Алексей Терехов - кто-то занялся другим направлением, кто-то перестал вести блог, но если попользоваться поиском и посмотреть архив публикаций, есть море чего полезного.
• Подписаться в Twitter на активных SEO-блогеров: список-1, список-2, английские ленты
• Изучайте информационные бюллетени и исследования Яндекса
• Подписаться на пресс-релизы Яндекса
• Прочитать всю информацию по поисковым технологиям Яндекса
• Читать публикации клуба Яндекс.Поиск
• Можно подписаться на аккаунты Яндекса в Twitter
• Прочитать справку Яндекс.Метрики и Google.Analytics - это поможет при дальнейшей работе с сайтами, во время отчетности и другого анализа
• Изучить сайты крупных SEO-компаний, это поможет сформировать схемы работы продвижения: по трафику, по позициям и пр. И сформируется представление по рынку услуг SEO. Рейтинги компаний есть на SEONews.ru.
• Посмотреть 200-факторов от Google
• Есть ещё пункт по ПО, но это отдельно, наращивается какая-то база своих программ. Сперва поработайте руками, для понимания механики.
• Тоже, как Nidora, рекомендую прочитать книгу Ашманова - оптимизация и продвижение сайтов в поисковых системах. И ссылка на полезные книги.
• И всегда быть в курсе актуальных новостей SEO

По терминологии сами всё поймете, когда начнете изучать.
Материала Вам хватит на пару месяцев. enjoy!

Лыжи или сноуборд?

В том смысле, что это вечный спор, т.к. в первую очередь - дело вкуса. До 2012 г. я покупал только GF. Но потом, увлёкшись BTC и майнингом других криптовалют, решил купить Radeon. И дело даже не в том, что он якобы был лучше, а просто потому, что хотелось попробовать топовую карту на майнинге и CUDA. Для последнего уже была GF, поэтому решил взять Radeon. Всё устроило. Даже решил вспомнить юность и сыграл - тоже порадовало. Но вот если говорить о вложенных деньгах и получаемом результате, то, честно, столь уж ощутимой разницы я не увидел. Возможно, для геймеров и гиков-экстремалов, она видна и осязаема, для меня как программиста-самоучки - нет.

Поэтому мой выбор пал бы сейчас на Радеон - всё же любые деньги сэкономленные, это деньги заработанные.

Оукей. давайте возьмем ваш пример с fl.ru + чаты.

mongodb - хипстерская база данных. Для проекта типа fl.ru я бы пожалуй не использовал оную (не потому что монга отстой а потому что я лично не вижу в использовании оной смысла в контексте проекта типа fl.ru. Нам не нужен шардинг, реплекация реализуется нормально на любой нормальной RDBS, документоориентированность не нужна, хотя при грамотном подходе можно было бы реализовать неплохие агрегированные коллекции и оптипизировать селекты... Для себя не нашел у монги ни одного плюса перед RDBS типа PostgreSQL). В любом случае если вы не оставляете выбор - тут у нас будут храниться все данные. Придется потратить время на то что бы избавиться от желания что-то заджойнить и реализовать map/reduc-ы для обновления связанных коллекций. Но зато это будет так по хипстерски!

То есть если у вас есть куча однотипных запросов с кучей джойнов данные для которых обновляются редко а выборки происходят часто, то тогда можно вооружиться монгой а делать коллекции как агрегации этих выборок. Если вы вставляете референсы и пытаетесь эмитировать джойны в монге то значит вы сделали не правильный выбор основного хранилища данных). Правда денормализовать данные можно и с RDBS....

sphinx - поисковой индекс. То есть если мы должны реализовать вменяемый поиск (например по описанию вакансии) - то стоит его заюзать. Сфинкс не самый дружелюбный зато один из самых быстрых поисковых индексов. Хорошо интегрируется с MySQL и подобными и если сравнивать с ElasticSearch из коробки чуть лучше дружит с русским языком. Но опять же у эластики свои плюшки. Некоторые оной заменяют монгу так как по большинству фич в плане хранилища данных они совпадают.

redis - мы там вроде чатик делали. Помимо того что redis это хорошее key-value in-memory хранилище, которое к тому же может обеспечить нам надежность хранения данных (мэпится на файловую систему еще), оно так же поддерживает pub/sub. То есть чисто теоритически мы можем не добавлять в стэк штуки типа ZeroMQ и прочие *MQ для реализации авторизации и связи приложения чатика и основного приложения (вдруг у нас чатик будет написан на go/node.js/erlang).

memcache - вот тут стоит подумать нужен ли он если у нас есть редиска. Раньше для жирного кеша выбор был очевиден - memcached, так как reddis в те времена не поддерживал кластеризацию. Сейчас же по возможностям редиска далеко впереди. Так что даже то что memcached чуточку быстрее (но жрет больше памяти и не поддерживает авторизацию к примеру из коробки) не должно стать поводом для использования оного. Но я если честно redis в кластерах не использовал и ничего говорить не могу, а memcached испытан годами.

Потому что сидят крутые дизайнеры и фронтэндеры на топовых мак про и плевать им, что у простых смертных не 32гига оперативы и не топовый i7.

Зато красиво.

У меня на проекте 80гб фотографий в доске объявлений. Делаю по категориям:

pics/users/cat/subcat/{{ID}}/1.png
pics/users/cat/subcat/{{ID}}/2.png
...

echo $_GET['producer_id'];
это вам нужно?

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

Книга, курсы и пара приложений мало.
Просто поставь себя на место руководителя. Каждая компания набирает человека для решения определенного круга задач. Угадать заранее с этим набором задач ты не можешь, поэтому лучшим решением будет охватить как можно больше умений и навыков.
Все просто - начни писать приложения, которые ты не знаешь как писать. Допустим нужна какая-то физика движений объектов и ты не знаешь как это реализовывать. Бери и учись. Так когда тебя спросят об этом, ты сможешь ответить какой подход ты выбрал для реализации задачи. Параллельно читай дополнительные книги. Это не обязательно книги по IOS. Многим работодателям нужны люди не только разбирающиеся в языке, но и умеющие программировать. То есть знающие паттерны, теории алгоритмов и прочее прочее. Если ты не знаешь как создать двусвязный список на указателях, о каких приложениях под IOS может идти речь? (Это я к примеру)
Далее уже можно пробовать фриланс. Поначалу нужно будет делать либо дешево либо бесплатно, пока карма не поднимется. Далее уже можно будет брать деньги за работу. Как только ты начнешь зарабатывать на фрилансе хоть что-то, у тебя появится опыт и ты уже сможешь что-то предоставить техническому специалисту на интервью. Ну и последнее, но немаловажное - собирай портфолио. Какие приложения/игры ты создавал. Это даст почву для разговора на интервью. По большому счету работодателя не интересует как и где ты учился, ему нужно знать что ты действительно умеешь и стоишь, чтобы понять потянешь ли ты тот груз задач и ответственности, что на тебя хотят взвалить.

Все это под большим ИМХО, ибо я прошел почти такой же путь

[Специалист] JavaScript. Уровень 3в. Серверное программирование на Node.js
Год выпуска: 2014
Производитель: Специалист
Сайт производителя: www.specialist.ru
Автор: Специалист/Борисов
Продолжительность: 14.01.45
Тип раздаваемого материала: Видеоурок
Язык: Русский
Описание: Интерактивный видео курс по Серверному программированию Node.js от лучшего в России учебного Центра «Специалист» при МГТУ им. Баумана.
rutracker.org/forum/viewtopic.php?t=4829384

Шаблонизатор шаблонизатору рознь. Но в целом следует выделить общие задачи. которые должны решать за вас шаблонизаторы. С blade не работал и не вижу смысла есть есть twig.

Безопасность. Это пожалуй можно поднять на верх. Типичная картина в шаблонах на php - <?= $someUserInput; ?>. Частенько это можно встретить в выводе инпутов, при формировании ошибок поиска (мол "по запросу $userInput ничего не найдено. То есть вставляем в инпут подключение наших js скриптиков, если это форма поиска - делимся с "другом" и забираем его сессию. Ну или еще какие забавные штуки можно делать. А ведь все очень просто решается. Ставим какую-то функцию, которая по умолчанию будет фильтровать XSS инъекции при выводе, и не будет этого делать только если мы попросим. Если писать просто на php - появляются отвратные функции, которые можно просто забыть вызвать. А с шаблонизаторами мы пишем красивые {{ someUserInput }} и можем спать спокойно.

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

Ограничивают полет фантазии разработчика. Далеко не новость что разработчики ленивые засранцы. Особенно молодые. Если им в шаблоне внезапно понадобились какие-то данные из БД, или данные связанные с запросом, большинство не будет париться и зафигачит нужный код прямо в темплейте. Так же некоторые грешат тем что часть бизнес логики размазывают по шаблонам. Так же встречал проекты отданные на суппорт, где чуваки в шаблонах разбирали через xpath ответы от сторонней апишки (которая использовалась вместо базы данных. То есть это дело было размазано по всему проекту). Рефакторинг в случае изменения апишки будет болью.

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

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

Так как за все эти приятные вещи мы по сути ничего не платим (шаблонизатор должен компилировать все это в нативный php так что оверхэда просто не будет), почему бы не пользоваться?

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

function template() {
		if (!is_null($this->template) && is_file("template/{$this->template}.tpl.php")) {
			extract($this->data, EXTR_SKIP);
			ob_start();
			require "template/{$this->template}.tpl.php";
			$content = ob_get_clean();
			return $content;
		} else {
			throw new Exception('Не указан шаблон: '.$this->template);
		}
	}

По-моему, наиболее простой и удобный вариант.