German Jet

Прежде всего, не всегда нужен фронт с js-фреймворком. Часто вполне достаточно обычных страничек. Но если действительно нужен развитый фронт, то бэк перестаёт использоваться для рендеринга шаблонов и выступает как REST- или GraphQL-сервис. Из Django для этого даже специализированное и очень удобное решение выросло - Django REST Framework.

Как-то так примерно:

urls.py

urlpatterns = [
    path('check-username/', check_username, name='check_username'),
]

views.py

@require_GET
def check_username(request):
    if 'name' not in request.GET:
        return HttpResponseBadRequest()

    return JsonResponse({'exists': User.objects.filter(username__iexact=request.GET['name']).exists()})

registration.js

$('#id_name').change(function() {
    $.getJSON('/check-username/', {'name': $(this).val()}, function(user) {
        if(user.exists)
            alert('Пользователь с таким именем уже зарегистрирован');
    });
});

1) На сколько удобны Homstead + Vagrant, которые они рекомендуют использовать? Посмотрел информацию по его установке, использовании. Разве это удобнее всем привычного openServer?

Насколько удобен конкретно именно этот стек, и насколько он удобен будет лично для Вас - сказать затрудняюсь, но в общей сложности, использование "родной" среды при разработке приложения - практика весьма правильная. Думаю что в данный момент, большинство моих эпитетов на тему "почему оно так и зачем" Вам будут не очень интересны, но, есть простой пример из реальной жизни: в *nix, чаще всего, файловые системы чувствительны к регистру имён файлов, в Windows [NTFS] (и OpenServer в частности) - такой чувствительности нет, что влечёт за собой потенциальные ошибки в самый неподходящий момент (когда Вы будете выгружать сайт на хостинг) и исправить их "по быстрому" удаётся не всегда, по этому, я бы рекомендовал использовать "родной" Linux при разработке. Какой стек взять - сакрального значения не имеет, мы используем: Docker (Hyper-V), VirtualBox + настроенную самостоятельно вирт. машину и различные другие варианты (среди которых, OpenServer проскакивает крайне редко).

2) Прямо из коробки Laravel поддерживает Vuejs, но посмотрев их курсы на Laracasts и ещё пару примеров компонентов для него, мне показалось, что он не совсем подходит для того, чтобы делать на нём те же слайдеры, системы частиц и подобные вещи.

VueJS - это JS фреймворк, волей судьбы "встроенный" в Laravel. Как мы знаем, JS относится к области вёрстки, что в целом с фреймворком серверным связано крайне слабо. Какие элементы в вёрстке использовать лично Вам - дело - лично Ваше. Из собственного опыта могу сказать, что мы в своей работе не гнушаемся ни VueJS, ни jQuery, ни различными готовыми слайдерами и вообщем всем, что может быть уместно в рамках конкретных требований конкретного проекта. По сему - я думаю Вам не стоит забивать себе этим голову. Насколько и чем хорош VueJS - можно узнать из массы уроков по оному.

Вообще не понравилось, что в HTML-разметке вставляются ивент-слушатели, как в стандартном JS прям (@click, onclick). Мне это напомнило встраивание CSS прямо в тэги. Мне нравится в jQuery то, что все ивенты вешаются прямиком в скрипте, не заглядывая в HTML-разметку.

На вкус и цвет все фломастеры разные. Какой подход "лучше" - покажет только время. В данный момент, мы используем оба из них и особо не паримся по этому поводу.

Я просмотрел вакансии на разных сайтах, чтобы понимать, какой стэк технологий нужен работодателям, и в требованиях я вообще не нашёл, что им нужен jQuery, только Vuejs. Отсюда и вопрос, то есть мне нужно переписать свои слайдеры, системы частиц под Vuejs? Часто встречал сообщения о том, что переплетать эти две технологии плохая затея. Либо то, либо то. Посмотрел предложенные готовые слайдеры, вообще не впечатляют.

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

3) Хорошим ли является планом, чтобы сделать воображаемый интернет-магазин для обучения и освоения Laravel? Или как лучше изучать эту технологию от легкого к сложному? Всегда была проблема с тем, чтобы структурировано изучать ту или иную область разработки. Чтобы не тупо копировать, а понимать, как всё устроено и как работает.

Что бы понимать что-то структурно - нужно понимать истоки. В области веб-разработки таковыми "истоками" могут являться например, протокол HTTP, фундаментом которого будет протокол TCP/IP, в основе которого лежат другие технологи... чем лучше Вы будете понимать как всё работает изначально, и в результате чего появилась, например, такая парадигма как MVC, как работает composer так далее, далее, далее... когда Вы будете всё это понимать - в голове будет складываться целостная картина происходящего, а не обрывки каких-то знаний. Разработка интернет-магазина в этом процессе, глобально, погоды не сделает, но какой-то опыт безусловно даст, главное, перед тем как будете разрабатывать собственный магазин - найдите какой-то уже готовый и постарайтесь в точности повторить его функционал, начиная от восстановления пароля заканчивая тем, как в корзине пересчитывается цена при изменении количества товара.

Скачай карты тут
разверни у себя Geoserver
Все карты твои, обращайся к ним на здоровье.

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

О. обожаю этот вопрос!

Открою секрет - IT само по себе бесполезно. Как, например и логистика/грузоперевозки. Или охрана.
IT должно облегчать другие сферы жизни. Программист должен писать что то, облегчающее другие сферы жизни.
Обязательно надо в чём то разбираться:

• бизнес/магазин - разбирайся с логикой заказов/покупок/возвратов
  
• банк - логика движения, денег, валют, транзакций, проверок, откатов
  
• движок игры - разбирайся с физикой. магнитизм, механика, свет/тень - все эти жизненные законы надо оцифровывать.
  
• игра на готовом движке - тогда закапывайся в детали, какого размера ступеньки должны быть что бы соответствовать шагу игрока с учетом его скорости передвижения. здесь требования не таки сложные, но вот игра без таких деталей будет казаться г**ном
  
• драйвера - разбирайся в железе, какую нагрузку держат - температура как повышается, сколько микроват где бегает.
  
• МАШИННОЕ ОБУЧЕНИЕ???????? Это вообще жесть как надо миллион тематических свойств изучить чтобы заложить обучение. И эксперты области редко понимают чё тебе надо
  
• data engeneer - вообще не область. Но даже тут надо понимать какие данные надо хранить/обрабатывать и с какой вероятностью нужны будут правки.
  
• роботы - опять же физика движений во всех проявлениях
  
• ИИ - психология, лингвистика.
  
• парсинг текстов - опять же, лингвистика, еще и разных языков, грамматика, синтаксис. а может и стилистику языков надо учитывать
  
• ...и т.д.
  

И так со всем.
Да, программисту будут ставить задачи, может даже детальные. Но всё равно он последняя инстанция - до него что то могли не продумать - программист ошибку увидит сразу и должен отреагировать. Предотвратить что то или увидеть возможности для прикладного...

И более того, есть мнение, что просто кодеры не нужны скоро будут. Нужны будут именно специалисты в определенных профессиях, которые могут перевести в программы свои идеи. Как раньше ученые статусные люди должны были уметь писать. Потом знать иностранные языки, потом владеть компьютерами/быстрым набором. Сейчас уметь запрограммировать.

Использую vscode+webpack+pug+scss+бэм. Из физических инструментов, основной моник: lg ultrawide 29um69g, рядом прикручен моник от ноутбука повешенный вертикально, подключенный через универсальный скаллер.

0) Запускаю Spotify :-)

1) Произвожу установку всех необходимых модулей для сборки. В моем случае у меня набор конфигураций для webpack (отдельные файлы для pug, scss, static и.т.д., выбираю что нужно).

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

3) Запускаю VS Code, открываю нужную папку.

4) Пишу размету на Pug. Пишу с БЭМ, если встречаю повторяющийся блок, то открываю файл _mixins.pug, в который пишу миксины для повторяющихся блоков, например товаров, пунктов меню, каких-то блоков и.т.д. Pug умеет делать циклы, это ускоряет сильно.

5) Когда HTML готов, начинаю делать каркас. Если дизайн сделан по сетке, определяю контейнеры, колонки, строки в свои классы (не пишу в html тучи классов аля col-md-6, а пишу в SCSS инклуды в нужные мне блоки, типа @include make-col(2) и.т.д.).

6) Экспортирую картинки из Avocode. Очень делается просто, указываю папку и просто кликаю экспорт и ввожу название файла и расширения. Преимущественно для иконок использую svg, если нет svg, то ищу эту иконку в интернете (дизайнеры редко рисуют иконки сами, но зато любят вставлять их не в векторе). Если иконка простая, могу сам ее в inkscape обвести, ну и если нет, то экспортирую png в 2х размере (благо авокод это позволяет, если конечно дизайнер не вставил в исходном маленьком размере). Когда есть контакт с дизайнером, трясу его, ибо растр это плохо для иконок.

7) Пишу стили блоков из страницы. На этом этапе можно на втором монике параллельно смотреть футураму или
Арчера :-) Но чаще на широком монике слева браузер, справа VS Code, а на втором монике Avocode (может меняться местами с браузером). Мысленно нарезаю страницу на блоки. Для каждого блока (БЭМ) создаю отдельный scss файл (кто-то даже для элемента создает, но мне лень), из него сразу выписываю все селекторы. Иногда могу сначала выписать все селекторы со страницы (но так лучше не делать, т.к. во время работы может потребоваться изменить что-то в разметке), но чаще для одного блока выполняю этот пункт и за ним сразу выполняю пункт 8, потом для нового блока опять 7 и 8 и.т.д.

8) Пишу css код вместе с Avocode, у него беру нужные мне параметры (а он уже подставил в них переменные), и вставляю в мой код. И параллельно сверяю со скрином макета используя вот это расширение https://chrome.google.com/webstore/detail/perfectp...

9) Пишу адаптив. Я не могу привыкнуть к методологии mobile-first, поэтому пишу всегда сначала полную версию сайта. Я понимаю, что это чревато всякими проблемами и это типа не модно, но мне норм.

10) Медиа-запросы пишу прямо в блоках, для каждого блока/элемента/модификатора может быть отдельный медиа-запрос. Но для начала определяю breakpoint'ы для разных экранов (чтобы их не было сотни разных), если использую Bootstrap, то беру его breakpoint'ы.

11) Добавляю анимашки. Даже если заказчик не просил отдельно (и если не указал отдельно, что нельзя), он все равно будет доволен, а с animate.css+onscreen.js это вообще работа 10 минут. Сложные анимации обговариваю отдельно, чтобы не сделать ненужную работу.

11) Все снова сверяю, пишу скрипты где надо. Для слайдеров в 99% случаев подходит slick (с доработками конечно, но там хорошее API), для других случаев могу написать свой.

12) Сдаю заказчику и жду ответа сидя на тостере/пикабу.

Это чисто мой опыт, опыт фрилансера, не знаю, как делают другие и не могу на 100% утверждать что это 100% правильный способ. Я так и не смог заставить свой конфиг webpack правильно вставлять спрайты svg.
Надеюсь чем-то поможет мой ответ.

Самое простое решение это в конструктор окна с табами добавить аргумент индекса необходимого таба и присваивать свойству SelectedIndex контрола TabControl индекс выбранной вкладки

Если честно, не вижу проблемы использовать кириллицу в качестве классов в C#. Это работает, хоть и выглядит не очень (ну и красота - субъективное понятие).

Если же порекомендовать один их вариантов - я бы выбрал бы третий вариант. Почему - по моему опыту, в 1C пускают сложно и все телодвижения там - весьма затратные (оплата специалиста, если его нет в штате, время реагирования на таск в целом, отладка взаимодействия - у вас может быть рассинхрон по времени и проблемы совместного запуска интеграционных тестов и т.д.).

Третий вариант хорош тем, что вы можете сделать как ручной маппер, так и маппинг по структурированному документу (json, xml и т.п.). Мне не кажется, что он будет особенно сложным, даже при вложенности моделей.
Такой вариант позволит куда оперативнее реагировать на возможные нюансы, и, что тоже не мало важно, правила Transform-части можно сделать и в виде странички, где их можно проставлять обычному сотруднику, без привлечения программиста.

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

p.s.
Опять же, вариант с настройкой на вашей стороне может позволить вам использовать библиотеки вида Automapper, к примеру - но, там, скорее всего, только через кодогенерацию.

В Enterprise проектах (в основном в банковском ПО) бизнес логику часто пишут на PL/SQL в СУБД Oracle. По этому рекомендую Вам книгу по программированию на PL/SQL "Oracle PL/SQL. Для профессионалов. 6-е изд.".
По данной книге вы можете выполнять поиск по тексту и находить ответы на многие вопросы по Oracle PL/SQL.

Верный путь будет прочитать книгу и практиковаться на каком то домашнем проекте.
Например. вы можете поднять локальную БД Oracle XE, как раз недавно вышла его свежая версия, о чем говориться в статье habr. В локальной БД Oracle создать свою первую схему с таблицами, наполнить их данными, повыполнять различные выборки смотря по примерам из книги, создать хранимые процедуры и функции, создать пакет, поиграться с триггерами, попробовать
использовать представления и материлизованные представления, понять что такое коллекции итд.

Также при изучении рекомендую воспользоваться несколькими IDE для разработки на Oracle PL/SQL, например PL/SQL Developer, TOAD, DataGrip, хотя последнее не часто используется, по крайней мере в моей практике работы в разных банках и в аутсорсе.

Фейерштейн С., Прибыл Б.
Ф36 Oracle PL/SQL. Для профессионалов. 6-е изд. — СПб.: Питер, 2015. — 1024 с.: ил. —
(Серия «Бестселлеры O’Reilly»).

Данная книга является подробнейшим руководством по языку PL/SQL, представляющему
собой процедурное языковое расширение для SQL. В ней детально рассмотрены основы PL/
SQL, структура программы, основные принципы работы с программными данными, а также ме-
тодика применения операторов и инструкций для доступа к реляционным базам данных. Боль-
шое внимание уделяется вопросам безопасности, влиянию объектных технологий на PL/SQL
и интеграции PL/SQL с XML и Java.
За последние десятилетия, в течение которых переиздается данная книга, она стала незаменимым
руководством по PL/SQL для сотен тысяч программистов, как начинающих, так и профессиона-
лов. Шестое издание книги полностью обновлено под версию Oracle12c.

Итак. Stepic не для начинающих.
Для совсем начинающих, на торрентах курс ITVDN. Изумительный курс. С ним лучше параллельно читать Шилдта «Java 8. Руководство для начинающих», а уже потом можно stepic.
Очень понравился курс Петра Арсеньева, также торрент.
Есть ещё классный курс, но он для продвинутых OTUS, на торрентах их два.
JavaRush не рекомендую, но для детей самое то, и он уже не бесплатный.
В любом случае нужно прорешать задачник Златопольского "Сборник задач по программированию", руку набить и прочитать книгу по алгоритмам Седжвика, и книгу «Чистый код». Курсы же должны быть платные, чтобы проверяли задания, в этом их суть.

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

Приведу пример, как это могло бы выглядеть в виде shell-сценария (можете просто копировать и выполнять команды в командной строке шаг за шагом и смотреть что происходит):

#!/bin/sh

# Создание временной директории
cd "$(mktemp --directory)";

# Клонирование репозитория во временную директорию
git clone https://github.com/symfony/demo .;

# Извлечение ветки для релиза
git checkout master;

# Установка зависимостей фронтенда
npm install

# Сборка фронтенда
node_modules/.bin/encore production

# Загрузка кода из временной директории на сервер при помощи rsync

# Остальные действия производятся уже на сервере

Добрый вечер.
Можно попробовать сделать в правилах urlManager так

'car' => 'base/index' // укажите своё действие вместо index

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

Я бы выделил несколько "кластеров" в городе:
1. Северо-запад - Беговая/Ст.Деревня/Пионерская/Черная речка
2. Восток - Пл.Ленина/Новочеркасская/Ладоджская
3. Юг - Техноложка/Фрунзенская/Моск.Ворота/Электросила + небольшая часть Московская > Пулковское ш.
4. Васильевский остров - тут и "линии", и Приморская
5. Центр и Петроградка.

По поводу жилья - если переезжаете из другого города, главной ошибкой будет покупка недвижимости сразу. Я не знаю, может для вас сумма в 5-7 млн. не кажется чем-то выдающимся, но по-моему тратить её нужно с умом.
Я видел желание жить на Петроградке, и, конечно, я вряд ли переубежу кого-то живущего уже там, это определенная секта, которая с пеной у рта будет доказывать, что это лучшее место на Земле. Но есть определенные проблемы:
1. Отсутствие крупных магазинов, т.е. продукты будете покупать либо в магазинах пешей доступно с крайне скромным выбором, либо ездить в другие районы.
2. Отсутствие зелени: ваши лучшие друзья будут дворы-колодцы, асфальт и пыль. Для кого-то это романтика, но она быстро пройдет, как и надоест гулять исключительно в парке на Крестовском.
3. Транспортный коллапс: во-первых со всех сторон вы ограничены мостами, случись что и ваш район в блокаде. Футбольный матч, приезд какого-то чиновника, еще что-то способно перекрыть вам все пути побега. Ну да, и в момент навигации нужно внимательно следить за временем, чтобы случайно не опоздать на мосты и тогда придется объехать пол-города, чтобы попасть домой.
4. Как и в любом другом центральном районе будьте готовы к тому, что машину, скорее всего будет сложно припарковать, а в ближайшие пару лет еще и платная парковка к вам может придти, в садик/школу попасть будет сложно, т.к. желающих много, а новых объектов уже не открывают, здесь есть новостройки, но это не гарантирует отсутствие проблем с коммуникациями, т.к. во-первых, коммуникации до дома старые, во-вторых, качество нынешнего строительства вызывает много вопросов.
В принципе, всё это так же легко перекладывается на Васильевский остров, ситуация схожая.

Если рассматривать центр, то наиболее благоприятным местом будет Коломна - тихо, спокойно, это еще не считается "элиточкой", что сказывается на ценнике, есть определенные проблемы с общественным транспортом (нет метро), но на авто он относительно свободен и он не транзитный, что в лучшую сторону сказывается на воздухе.
"Золотой треугольник" - дорого и не комфортно, очень много людей, круглосуточные пробки, и хостелы/мини-отели в каждой второй парадной.
Вполне неплох участок за Фонтанкой, в районе Загородного. За исключением зелени и отсутствием крупных магазинов особо сильных проблем не назову.
Район Чернышевской неплох, но "элитен" и цены в нем сильно завышены, очень сильная социальная пропасть, в одной парадной могут быть клоповники-коммуналки с алкашами и "аппартамента" какого-нибудь господина на Rolls-Royce. В силу этого, регулярные конфликты обеспечены. Ну и метро Чернышевская в часы пик - сущий ад.
Лиговский и Пески - неоднозначно, слишком много "питерского" духа в виде коммуналок и алкашей.
Московский район - идеален :) Много зелени, недвижимость в разумных пределах, пробки бывают, но много путей объезда. Инфраструктура вся в порядке.
Естественно, это исключительно моё мнение и кто-то с ним может не согласится.
На мой взгляд идеальное жилье получается когда:
1. Дом не большой
2. Жильцы относятся примерно к одному социальному классу
3. Рядом есть вся необходимая инфраструктура
4. Въезды/выезды и района не ограничены 3-4 путями, из которых часть мосты и ж/д переезды
5. Есть зелень