Когда хочешь быстро научиться чему угодно.
20.05.2018, 11:34
По песку.
"Научиться делать сайты", ммм?
Звучит как "научиться делать скульптуры". В какой технике, из какого материала, какого размера, итд? Ни один скульптор не умеет всего...
Звучит как "научиться делать скульптуры". В какой технике, из какого материала, какого размера, итд? Ни один скульптор не умеет всего...
Да нынче HTML CSS и javascript не только в плане сайтов нужны. Уже давным давно гуй можно пилить как раз с помощью этого. Так же базы данных вполне себе используют в десктопных приложениях, а на пыхе можно писать скриптики для повседневных задач(правда это уже извращение).
Не о том речь.
Продолжая метафору, научить человека делать какие-то скульптуры (фигурки) я могу часов за 8, например, легко.
Вот только это будет конкретная техника, размер и материал.
А не "скульптуры вообще".
Продолжая метафору, научить человека делать какие-то скульптуры (фигурки) я могу часов за 8, например, легко.
Вот только это будет конкретная техника, размер и материал.
А не "скульптуры вообще".
Это не техника, не размер и не материал.
Даже не близко. Всё вышеперечисленное - это вершина айсберга фронт-энда, а в бэке такой же айсберг со своими заморочками.
Пыхпач и мускуль - бекенд? Да ладно?
PHP - нет, MySQL - вполне, как внутренняя БД для низконагруженного микросервиса. Но под "таким же айсбергом" я подразумевал: язык программирования + бизнес-фреймворки + веб-фреймворки + фреймворки для тестирования + тулы для сборки приложения и управления зависимостями + тулы контроля версий + спец. библиотеки и фреймворки по специфике проекта + упаковщики, контейнеры, сервера + методологии разработки (в любом проекте вы столкнётесь минимум с тремя методологиями) + баг-трекеры + логгеры + БД разных типов + криптография и безопасность.
Выучить всё это на достаточном уровне можно за 9-12 месяцев, но не раз придётся бороться с отчаянием, когда натыкаешься на очередную проблему и приходится учить новый инструмент для её решения, хотя у тебя параллельно идёт изучение ещё 2-х технологий.
Выучить всё это на достаточном уровне можно за 9-12 месяцев, но не раз придётся бороться с отчаянием, когда натыкаешься на очередную проблему и приходится учить новый инструмент для её решения, хотя у тебя параллельно идёт изучение ещё 2-х технологий.
Ах да, ещё забыл: знание паттернов проектирования и умение эффективно использовать язык и писать хороший код, каждый из этих пунктов = минимум одна книга ~350-400 страниц.
Разные БД в одном проекте может и встречаются редко, но ты же не будешь работать всё время над одним проектом. Мидл от джуна в текущих реалиях отличается только опытом и качеством работы, стек технологий у них почти одинаковый, только сениоры явно идут впереди по необходимому количеству знаний.
>>Мидл от джуна в текущих реалиях отличается только опытом и качеством работы
Щас, вот прям только лвлом и отличаются. На приеме на джуна никто с меня не спрашивал ни orm, ни АОП, ни патернов, ни даже работу с системами контроля версии. Про всякие технологии, аля SignalR или WCF у новичков если и спрашивают, то только для галочки.
>>Разные БД в одном проекте может и встречаются редко, но ты же не будешь работать всё время над одним проектом.
При переходе с одного проекта на другой, используемая база тоже не обязательно меняется. А учитывая что я сижу на .net, у меня по сути mssql по умолчанию.
Щас, вот прям только лвлом и отличаются. На приеме на джуна никто с меня не спрашивал ни orm, ни АОП, ни патернов, ни даже работу с системами контроля версии. Про всякие технологии, аля SignalR или WCF у новичков если и спрашивают, то только для галочки.
>>Разные БД в одном проекте может и встречаются редко, но ты же не будешь работать всё время над одним проектом.
При переходе с одного проекта на другой, используемая база тоже не обязательно меняется. А учитывая что я сижу на .net, у меня по сути mssql по умолчанию.
Блъ, хотел возмутиться про отношение mysql и php к фронту, но я упоролся после дачи и словил крит. промах.
._.
._.
Тебе? Не знаю, но люди иногда используют + наследие минувших дней. MySQL ты можешь даже напрямую не использовать, но понимать суть взаимодействия с такой БД нужно. Про ебанутые формулировки вакансий, где ты должен знать всё-всё-всё я просто промолчу.
5 минут и шаблонный говно-сайт готов. Этого достаточно только для каких-то сайтов для лабораторной по предмету 3-го курса не ИТ и не дизайнерских специальностей.
началось... До появления всяких пабликов в соцсетях и каналов на телеграме, мелкие группы аля "туристичний гурт села ховрашівка" только на cms свои внутрении сайты и делали. Да и сейчас, чтобы обзавестись тем же интернет магазином, обращаются на площадки, а не заказывают с нуля. Для мелких проектов CMS самое оно, вот только знать технологию построения с нуля все равно придется, иначе только готовое из коробки и развернешь.
Во времена вайберов, телеграмов и фейсбуков иметь говносайт-визитку вообще смысла нет. Все что ты перечислил можно на визитку вынести. А детальную информацию отправлять тем же способом, каким собирался отправлять адрес на страницу сайта.
Отнюдь: сайт-визитка "маст хев" для некоторых массовых мероприятий (концерт начинающей группы в местном пабе сюда не относится), с полным расписанием, телефонами связи, правилами, картами проездов и на разных языках. Пихать такое в соц. сети - моветон.
Не знаю, что там у вас за локальные моветоны, но почти все местные музыкальные группы имеют паблик группу и там пишут про все свои мероприятия. Никакие карты проездов никто на такие события не выкладывает, а правила - это как себя вести на концерте? Называется притянул за уши к желаемому.
Обновлять через гит? На проде? Плохая идея.
Лучше так: веб-сервер считает рутом директорию, которая на самом деле симлинк, который смотрит на директорию 1, в которой лежит билд 1. Сделав билд 2 (билдят не на проде, есессно), его выливают rsync-ом в директорию 2 на прод, а потом переключают симлинк на нее. Таким образом мгновенно переключаются на новые релизы. В случае если в релизе баг, симлинк переключают обратно на директорию 1. Но от похеренной в билде 2 бд этот способ не спасает, конечно.
Лучше так: веб-сервер считает рутом директорию, которая на самом деле симлинк, который смотрит на директорию 1, в которой лежит билд 1. Сделав билд 2 (билдят не на проде, есессно), его выливают rsync-ом в директорию 2 на прод, а потом переключают симлинк на нее. Таким образом мгновенно переключаются на новые релизы. В случае если в релизе баг, симлинк переключают обратно на директорию 1. Но от похеренной в билде 2 бд этот способ не спасает, конечно.
Артефакты наше всё. Они не изменны. Запускаем докер контейнер с образом необходимым, если не ок, быстро возвращаем предыдущий.
Про бд, надо тестировать на стейдже изменения, и если на стейдже всё ок, то и на проде должно быть ок. А так же надо чтобы стейджовая БД была как продовая, как минимум по структуре.
Про бд, надо тестировать на стейдже изменения, и если на стейдже всё ок, то и на проде должно быть ок. А так же надо чтобы стейджовая БД была как продовая, как минимум по структуре.
DigitalOcean ну или другие VPS решит как минимум 5 проблем. Ставишь и настраиваешь свою лампу.
Что в твоем понимании научился?
Если конечная цель была, делать сайты визитки, то 2-3 недели много)
Если конечная цель была, делать сайты визитки, то 2-3 недели много)
Чтобы написать коммент, необходимо залогиниться
