Нормально отправлять пользователю тот код что ожидает увидеть тот или иной браузер. Можно делать универсальные решения (включая вёрстку) и радоваться, но скорость загрузки и отзывчивость системы стоят того что бы немного поработать. Другой вопрос в простоте. Если сделать это не аккуратно то будет сложно-разбираемый баг.
OnYourLips: одно дело bluetooth точка-точка делать, другое дело "наличие рядом радиоволн", которые могут быть любыми. Кто знает что там у автора вопроса в голове, может ему важно прослушивать разговоры дальнобойщиков в округе.
Получил сообщение 20 ноября: "К сожалению, вынуждены приостановить обработку заявок на доступ к API, так как получили большое количество заявок. Сейчас мы выбираем наилучший способ, как удовлетворить все разнообразие требований пользователей. Как только мы подготовим решение, мы опубликуем информацию на сайте и продублируем вам в письме в ответ на вашу заявку."
В общем как-то вяло они "открытое" API раздают... скорее интересуются у рынка что им нужно. Если кто-то его реально получил - дайте знать:)
Странно тут ожидать полноценного генератора случайных вариантов. Оно тут вовсе не нужно. По части распределения нагрузки (а ведь обычно для неё делается такой финт с самым быстрым ответом) лучше сделать так:
Отправлять задачи на сервера по кругу, считать время ответа, если какой-то сервер выбивается по времени ответа - убирать его из списка или ставить в самый конец относительно текущей позиции... или пропускать его при следующем запросе или ещё что-то...
Надо вспомнить что сейчас многое на Golang или переписывается (теми же фейсбуками, вконтактами) или пишется новое уже на нём. Ещё лет пять и Golang будет таким же мейнстримом как PHP.
Самый дельный ответ. Не знаете какой язык выбрать - значит не знаете ни один из этих языков достаточно хорошо. Значит надо узнать хотя бы один. Если не будет хватать - узнать второй и так далее... Не возможно прыгать из Node.JS в Golang и обратно попутно делая часть работы на Scala без должного понимания всех трёх языков программирования.
Лично я рассматриваю кеширование как часть алгоритмов. Просто алгоритм знает что есть кеш в оперативке, кеш на диске, если программист знает о наличии таких механизмов, но в алгоритм их не положил - значит он странный программист и любит костыли добавлять поверх. Универсального кеширования почти не бывает. По крайней мере интересного:)
Владимир Грабко: в Golang каждый пакет можно рассматривать как изолированный, выполняющий свою собственную функцию. В этом контексте в общем-то не требуется делать прослойки. Разве что универсальные.
Лучше делать нужные проекты, чем просто так задачки решать. Отличный способ:
1. решить освоить какую-то технологию в контексте применения на Golang.
2. найти похожую задачу на fl.ru или любом другом фрилансерском сайте.
3. предложить сделать задачу на Golang за теже деньги честно сказав что именно из необходимого ещё не делалось ни разу, описав преимущества этого языка программирования в сравнении с тем же PHP ,например.
Где-то между вторым и третьим пунктом составить список решений для задачи:
- что почитать
- кто решал уже такое
- алгоритмы, пакеты, репозитарии
В общем, подготовиться. Протестировать идею на вопрос "сможет или не сможет сделать".
Елизавета Борисова: тут есть два варианта джуниора. Джуниор-разработчик (Джуниор-программист) и Golang-джуниор... Второй может быть очень крутым разработчиком, просто опыта в Golang, предположим ноль или чуть больше.
Согласен с Sayber ☠, у вас сильно низкий бюджет, скорее говорит о том что вы не знаете сложности и как будете это реализовывать. Но если это не так - покажите примеры своих сложных работ и я с удовольствием буду с вами сотрудничать.
Важно то поможет ли этот текст другим или нет. Желательно с чем-то улучшающим жизнь, например в программных продуктах. Плохие программисты всё равно будут делать те проекты за которые им платят, так пусть хотя бы делают их чуть-чуть лучше, удобнее, приятнее, производительнее и так далее...