beduin01

JWT и не надо изобретать велосипедов. (под все фреймворки имеются пакеты)
Получаете токен и используете его. В токене могут быть права, экперинс и т.д.

У PHP был и остается предельно низкий порог входа. Для того, чтобы установить (тем более, настроить и кастомизировать) сайт на какой-либо CMS на Django надо хоть что-то знать. Понимать Python хотя бы на уровне туториала, уметь работать в командой строке, понимать, что там за буковки выводятся, когда пишешь mkvirtualenv или pip install.

С PHP ничего вообще знать не надо. К сожалению, эта монета имеет и обратную сторону — с любым кодом на PHP после Python работать просто невозможно. Глаза слезятся и вытекают.

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

Я бы картинку нарисовал, но там очень уж нецензурный вид получается ;-)

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

Уже сейчас чтобы тебя считали верстальщиком/программистом/фронтэндером/бэкэндером - надо знать в 2 раза больше технологий, чем 2 года назад. Этакий Закон Мура наоборот. Да вы сами просто посмотрите эти списки "компетенций"!

Читаешь список требований к "Web-программистам" и видишь, что месяц за месяцем, год за годом HR-ы и те, кто там им задачи ставит, вписывают в требования все больше умных словечек, которые они сами услышали и не понимают, зачем оно им нужно и нужно ли? Все ближе и ближе ситуация подходит к "Если бы водителей принимали на работу как програм.... В 2010 году это была "шутка юмора". Сейчас это уже почти реальность.

Пример хотите?

Одна государственная организация выставила список требований к "веб-программисту". При зарплате в 35000 рублей он должен уметь чуть ли не МКС программировать и чуть ли не кластера из сотен серверов настраивать. А на деле основной задачей человека будет - таскать проекторы из аудитории в аудиторию, чистить мышки студентам, переставлять winxp и изредка, раз в полгода - добавлять статью на сайт гос.организации. Откуда информация? Связался с человеком, которому 45, который в этой организации работает уже 18 лет. Ему стаж капает, а деньги он зарабатывает совсем в другом месте.

Что уж говорить об организациях коммерческих? Особенно тех, для которых веб-программист - и чтец, и жнец, и на дуде игрец?

Но это все лирика и крик души. Извините.

И да, к 35-40-45 годам по мнению "молодых и амбициозных IT-специалистов" ты должен обладать строго определенным списком компетенций как в профессии, так и по жизни (к примеру, я столнулся с отказом в приеме на позицию программиста потому что у меня нет... автомобиля. Зачем программисту автомобиль? Ну там сложная и длинная логическая цепочка, сводящася к "раз у тебя нет автомобиля - ты лох, а лохи нам не нужны").
Мне кажется, проблема в том числе и в том, что подавляющее большинство этих самых "молодых и амбициозных" специалистов совершенно не думают о своем будущем. Нет, я не про то будущее, которое "куда я пойду, когда закончу вот этот крутой проект". Я о реальности. В их понимании 35 лет - это недостижимо далёкое будущее, а до 50 они не доживут (а если и доживут - то в мечтах тимлидами в гугле).

Соответственно "молодые и амбициозные специалисты" с презрением смотрят на людей, которые отдали 15 лет разработке определенной платформы, платформы, которую сейчас тщится заменить какой-то пул новых технологий. По их мнению - все что старше 5 лет - ненужное устаревшее говно мамонта. А те, кто не знают появившуюся полгода назад технологию - отставшие от жизни ламеры.
Also, Эффект Даннинга—Крюгера тут работает в полную силу.

Резюмирую: трудно, если у тебя нет в резюме стапятисот сделанных проектов. И чем дальше - тем сложнее и труднее будет. Но тебе может повезти - если ты компетентный специалист в узкой области (даже если она 'legacy'). Или ты можешь найти синекуру - гос.организацию, в которой ты присоединишься к когорте таких же скинутых с паровоза прогресса "молодыми и амбициозными". Не переживай, через 20 лет скинут их. А ты останешься.

Вот только кушать хочется сейчас. Хотя бы просто хлебушка.

У меня вышло около 400 строк. Сюда вошел сам перцептрон и его "обучатель", который подсовывал ему изображение и бил/хвалил в зависимости от результата. Плюс отдельно было написо приложение на C# с UI, которое уже использовало сгенерированые веса для идентификации. Там нет ничего сложного, если знаешь матчасть.

PS. Но я щас смотрю на код и не понимаю, почему я написал некоторые участки именно так=)

• 1А. Одноимённые улицы можно склеить в один сегмент.
  
• 1Б. Тут я не совмес понял как вы хотите отсеять. Но по уму это должно быть как от точки n-1 до n можно проехать за 30 секунд, а по треку всего 1с, значит точку выкинуть. Следовательно нужен роутинг, а не склейка дорог.
  
• 2. Тип дорог отражает важность, к скорости отношение постольку-поскольку. Но можно получить все дороги в пределах населённого пункта.
  

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

Отлично с этим делом.

Да, прямо туда ST_POINT.
Но вообще странный запрос. Обычно строят буфер в 100, 200 и т.д. метров, и смотрят какая дорога в него попавшая ближе.
А можно и без буфера если нужно только название:

SELECT osm_id, highway, name, tags, ST_DISTANCE(way, point) AS Distance
  FROM public.planet_osm_line
	INNER JOIN (SELECT ST_TRANSFORM( ST_SetSRID(ST_POINT(48.323, 54.263), 4326), 900913) AS point ) AS p
		ON ST_DWithin(point, way, 200)
  WHERE highway IS NOT NULL AND name IS NOT NULL  
  ORDER BY Distance
  LIMIT 1;

не все утилиты могут обновлять в рамках какого-либо региона.

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

Node.js не подгружает никакие файлы *.vue (получите syntax error при попытке подключить .vue файл), этим занимается либо webpack c плагином vue-loader, либо browserify с плагином vueify, которые в свою очередь являются инструментами сборки клиентского кода в пакет (bundle) - отдельный файл в котором собран код со всеми зависимостями.
Этим инструментам для работы нужен Node.js, но то что у них получается на выходе, с node.js уже никак не связано - в этом коде не будет никаких require/export. Просто скопируйте эти файлы из директории build, подключите на страницу тегом script, link и хостите чем угодно, nginx, IIS. Разумеется речь идет только о клиентской части приложения.
Vue.js на ноду завязана только в одном месте - Server-Side Rendering, но это относится уже к серверной части приложения.