Николай

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

На собеседовании я обычно прошу выбрать из послужного списка какой-нибудь один проект (на усмотрение самого кандидата - наиболее крутой: в котором было найдено какое-нибудь особенно интересное решение, или использованы какие-нибудь крутые технологии, или решена какая-нибудь нетривиальная задача... короче, которым он сам гордится) и рассказать о нем подробнее, но, опять же, не в смысле, какие именитые были заказчики или как необъятен был бюджет, а в смысле, что он любимый в нем конкретно сделал, чему научился и чего добился. Обычно уже сам выбор достаточно показателен. (Если чел собеседуется, например, на синьера JEE, а в качестве темы выберет написанный в старших классах школы сайт на PHP, на котором была особенно удачная фотография кошки - это уже повод задуматься.)

А дальше, по мере рассказа, начинаю задавать уточняющие вопросики (на вшивость): ага... тесты писали... а какое было покрытие? А как определяли? А в каком порядке выполнятся тесты из одного класса?.. Так, так... JBoss... а какая версия использовалась? Дескрипторы или аннотации? А что нового появилось в следующих версиях? А сервлеты вручную писали? ...ага, SOAP. А из каких трех частей состоит WSDL? А моки в SOAPUI делали? Ну, и далее - вглубь или вширь, по мере объема знаний кандидата.

У такого подхода есть две стороны. Первая: если человеку есть чем гордиться, он начинает с горящими глазами грузить меня техническими подробностями, снимается ситуация стресса. Из режима "теста" мы плавно переходим в режим беседы на профессиональные темы. Если же начинает мямлить что-то про невероятную важность проекта и свою ключевую роль в нем, но на вопросы не может ответить, т.к. "этим он лично не занимался", а "эти решения принимали другие", то с ним очень быстро все становится понятно и беседу на этом можно заканчивать.

И вторая: из резюме зачастую сложно даже предположить уровень "погружения" в отдельные технологии. В беседе удается точно выяснить предположительные сильные стороны кандидата и тогда уже задавать конкретные вопросы, позволяя ему раскрыть глубину познаний.

Еще по поводу отдельных технологий, о которых заходит речь, прошу кандидата оценить свои познания в ней по пятибальной шкале "1 - первый раз слышу, 5 - эксперт". Для экспертов у меня заготовлены конкретные вопросы из жизни, как правило, примеры кода, иллюстрирующие какую-нибудь нетривиальную хреновину, которые я тут же достаю из папочки и предлагаю совместно разобрать. Эксперт в Яве - хорошо! Давай побеседуем о медели памяти, сборщиках мусора или кеше процессора. Эксперт в SQL - замечательно! Давай попробуем оптимизировать запрос. Эксперт в сетях - чудесно! Давай разберемся, почему падает вот этот долбаный сокет. Опять же, цель этого подхода - отнюдь не завалить самоуверенного кандидата, а именно понять, как человек мыслит, как ищет решения проблем, достаточно ли у него для этого знаний и опыта. Не беда, если кандидат погорячился с самооценкой... тут важно не знание ответа, а именно подход к решению проблемы (т.к. от синьера именно таки ожидается решение проблемы, а не констатация ее сложности).

Ваш вопрос можно приводить в качестве наглядного пособия на тему "Как именно вылазит боком кривая архитектура системы" :) Основная проблема в том, что интеграция компонент через storage есть зло, рано или поздно (чаще - рано) заставляющее разработчика выполнять стойку на ушах. Так что, если есть такая возможность, постарайтесь устранить зло в корне, т.е. найти способ узнавать об изменениях, ну, или хотя бы о самом факте, до того, а не после. Тогда не придется ничего опрашивать в цикле, а только реагировать на изменения. А это уже - половина проблемы!

Если возможности нет, а делать все равно надо, сначала смитритесь с тем, что Вы никогда на PHP не добьетесь ровненько 86400 вызовов в сутки каждую секунду, если только не поставите ядро реального времени / не напишете соответствующий код на С и т.д. и т.п. Особенно, если storage крутится на том же процессоре в той же ОС, и количесво данных в нем будет со временем увеличиваться. Но это почти наверняка и не нужно, а нужно проанализировать задачу и понять, что на самом деле критично и какие отклонения от идеала возможны без ущерба для функциональности.

"Примерно 0.03с" само по себе еще не о чем не говорит. Это всегда или в случае, если изменений нет, или если они небольшого объема? А если 90% данных обновились? Это - раз. Два: если изменения обнаружены, сколько может занять их обработка (в худшем случае)?.. И, наконец, три: если уже наступила "следующая секунда", а мы все еще не закончили обработку прошлых изменений, возникает целый ряд вопросов. Имеет ли в этом случае вообще смысл проверять новые изменения (сможем ли мы их осмысленно обработать, если найдем)? Если да, понадобится как минимум 2 потока. Если нет, насколько критично пропустить эту секунду? А сколько еще можно пропустить без ущерба для функционала? Предположим, это не критично, и мы уже пропустили секунду (или несколько), что нам важнее: чтоб следующая проверка выполнилась как можно ближе к границе "следующей секунды", или как можно быстрее? И т.д. и т.п.

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

Вам нужно для начала точнее определиться с собственными целями... Если цель пока просто поиграться с железом, чтоб понять, нравится или нет, то самое правильное будет спокойно продолжить получать фундаментальное образование по программированию и делать какие-нибудь DIY проекты. Если же уже понятно, что это "дело всей жизни", то придется еще много чего учить, чего на телематике наверняка не будет (по крайней мере, в нужном объеме) и без чего в низкоуровневом программировании и, особенно, робототехнике делать просто нечего. Это прежде всего физика, электротехника, схемотехника, общие принципы конструирования и разработки систем, плюс, разумеется, технологии производства (тупо уметь паять), измерений (тупо уметь пользоваться осцилографом или LA), стандартизация и т.д. и т.п. вплоть до того же всеми горячо любимого сопромата. Из программирования и математики помимо чисто фундаментальных знаний (типа алгоритмов и структур данных, которые можно учить на любом языке) тоже понадобится много конкретного, например, DSP, криптография, ассемблер, устройство компиляторов, протоколы... английский (как минимум "технический") тут даже смешно упоминать. Одним словом, будьте готовы к тому, что в таком случае Вам фактически понадобятся ДВА образования.

С чего начинать, в каком порядке и как их получать (еще куда-то поступать или учить недостающее самостоятельно) - особой роли не играет. В результате придете к тому же самому. Но хотя бы одно "официальное" образование обязательно нужно... не потому, что там чему-то конкретному научат, а потому, что там дадут возможность научиться учиться.

А вот про "всю жизнь писать код" реально улыбнуло... Как только почувствуете, что устали писать код, паять, измерять, конструировать и, главное, изучать новое - так сразу же и уходите из профессии, ибо дальше в ней делать просто нечего! :)

Если человек, не знакомый с арифметикой захочет понять, что означает "два плюс три равно пять", ему недостаточно объяснить, что такое "два", или что такое "плюс"! Так же и тут. Для понимания, что такое localhost, сначала нужно понять, что такое хост вообще, что такое сеть, что такое имя хоста, что такое сервер, как это все связано с адресами и номерами портов, а те - с, собственно, одним конкретным компом (который, в зависимости от контекста, могут называть и "хостом", и "сервером", и "localhost"). Так что, на всякий случай:

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

Когда к хосту обращаются по имени, это имя сначала разрешается в адрес хоста, по которому, собственно, и происходит обращение. В сети этим обычно занимается DNS (который, кстати говоря, тоже является сервером... но это уже другая история, которая сейчас не так важна для понимания сути), но если DNS нет, соответствие имен-адресов можно прописать в файле hosts на самом хосте. Если некое имя хоста и там не прописано, обратиться к нему по имени не удастся... хотя прямое обращение по адресу будет работать.

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

На одном компе (=хосте, сервере) может одновременно выполняться несколько разных программ-серверов. Для того, чтоб обратиться к конкретной из них (адрес-то у всех один и тот же!), в протоколе TCP/IP используются разные номера портов.

Если на компе запущен, например, HTTP сервер (= Webserver, например, Nginx или Apache), он "слушает" порт 80, а если не запущен, порт 80 никто не слушает, и если обратиться к такому хосту (= серверу, компу) по его адресу в порт 80, никакого ответа не придет... хотя сам хост и будет доступен.

Для разных общеизвестных типов программ-серверов (в этом случае также говорят о "сервисах" или же "протоколах", что в данном контексте практически одно и то же) принято использовать общеизвестные номера портов, а для наиболее распространенных (как тот же HTTP) можно даже не указывать номер порта при обращении, как мы обычно и делаем в строке броузера, т.к. клиент автоматически использует номер порта по умолчанию, в данном случае 80. Но, в принципе, любой сервис можно (переконфигурировав) использовать на любом порту... если, конечно, в этом есть смысл. Единственно, что нельзя - одновременно использовать разные серверы на одном порту.

И, наконец, было бы совсем глупо, если бы для обращения к какому-то серверу на одном хосте в сети обязательно был бы нужен еще и другой комп, с которого обращаться. Вот и придумали возможность обратиться к программе-серверу с того же хоста, на котором она выполняется, т.е. локально, а чтоб не гадать, по какому адресу или имени это делать, ввели понятие localhost.

localhost - "общеизвестное" имя компа для самого себя и ему соответствует IP адрес 127.0.0.1. Это - общепринятая договоренность, которую просто нужно знать. Если говорят "установить сервер на localhost", это означает "установить на тот самый комп, с которого и обращаться к этому серверу".

Да, иногда проходят базовые курсы. Раньше точно проходили.
Например, базовый Javascript:
https://htmlacademy.ru/blog/225-online-intensive-j...
Или, вот, базовый PHP:
https://htmlacademy.ru/blog/263-online-intensive-php
А вот, базовый HTML и CSS:
https://htmlacademy.ru/blog/193-online-intensive-h...

Про БД не парьтесь вообще. Есть она у вас или нет - гуглу знать не дозволено никаким образом, да и не нужно оно ему то по сути))
То, что вы слышали - имелось ввиду использовать cms скорее всего. Ну на худой конец можно и тупо в БД те же html-ки хранить, по крайней мере управлять ими будет удобней с помощью sql-запросов, чем просто кучей файлов (даже не представляю как!)) наверно программы специальные для этого придумали ибо если нет - от одной мысли в дрожь бросает).
Раскрутить - ... эээ вобщем да и ни чуть не сложнее других сайтов, но тут больше вопрос в том, сможете ли именно вы его раскрутить (не имея в этом ни малейшего опыта и знаний).
И еще, не хочется вас обижать, возможно (и скорее всего) вы вложили много труда в этот сайт, но дизайнер из вас, как из меня народный целитель)) Подумайте, над тем, чтобы взять шаблон готовый. И если последуете этому совету - постарайтесь как можно меньше изменять его на свой лад (проверено на собственном опыте неоднократно т.к. дизайнер я точно такой же как и вы:)).