Он там как обычный городской транспорт работает, и только по совместительству еще как туристический аттракцион. Местные им как трамваем пользуются, так что с заполняемостью там проблем особых я не заметил.
Не пойму как процитированное соотносится с вашим комментарием. Правильно ли я понял, что вы считаете, что разработчики не должны никак вникать в бизнес область в которой они работают?
Мне кажется, ваш потенциальный кандидат, довольно редкая птица, и места ее обитания вполне известны. Например многие ответы на вопросы из вашего опросника я получил в ходе участия в HighloadCup, где надо копаться во внутренностях языка чтобы понять, а что можно выжать еще. А вот эта сортировка стандартная на моем наборе данных работает оптимально, или вот тут я другую использую и она быстрее будет. Многие получают этот опыт в больших компаниях с большими нагрузками, где замена алгоритма сортировки сэкономит XXX рабочих инстансов, и такое копание в деталях — имеет бизнес-значение.
Большинство же backend разработчиков (подавляющее) в основном решают другого уровня задачи, как тут верно писали в комментариях — гонять данные туда-сюда, и скорее больше фокусируются на самом бизнесе, который может быть довольно широк, отсюда и ваш вывод про — задача сделана, идем дальше, времени мало. Больше ценятся работа в команде, софт скилы, знания бизнес процессов и т.п. Плюс добавтье сюда то, что зоопарк технологий растет очень быстро, сейчас нет просто физической возможности копаться в сорцах каждого инструмента, который разработчик использует, плюс какой смысл? Среднее время работы программиста в компаниях сейчас довольно маленькое, ну изучишь ты один инструмент от и до, как ты этот опыт перенесешь на другого работодателя? Но это не означает, что при необходимости большинство разработчиков этого не сможет сделать.
При выборе мышки в последние годы я ориентируюсь на ее симметричность, ибо левша. Все эти новомодные мышки для правшей, как бы прекрасны они не были — увы, никак не подходят.
Каждый десятый в мире левша, то есть потенциально — 10% рынка.
> insert, update, delete должны корректно проходить на изменённом слейве
это по идее легко обеспечивается на уровне кода для всех перечисленных кейсов естественным образом. Пока изменения не вступили в силу — код о них не знает.
Остается по сути только DELETE? Удалять колонку можно когда она перестает использоваться кодом. Вроде тоже не должно быть проблемы.
Остальные операции типа MOVE, это по сути INSERT -> DELETE, их все равно придется на уровне кода обеспечивать.
У вас было что-то специфическое, что запросы переставали быть обратно совместимы? Или я где-то не вижу рояля в кустах?
«или альтером слейва с последующей сменой их местами» — можно рассказать ваши мысли про этот способ? Пробовали? Почему на нем не остановились? По идее самый привлекательный способ, какие там подводные камни?
У нас сейчас есть такая же задача, смотрим неспешно именно в сторону master-slave и их сменой.
Клиент для Go уже есть russianaicup.ru/forum/index.php?topic=786.0, на local-runner уже все можно обкатывать, ждем когда начнут поддерживать на сервере, вроде как на этой неделе добавят
а если серьезно то побольше бы паузу между соревнованиями. backend, потом лифты, теперь стратегия, на все времени совсем не хватает, да и вы мне кажется не успеваете подготовиться нормально.
Другое дело что да, это надо писать самому, или искать либу. Но у Go немного другая идеология на мой взгляд, — не давать делать из коробки то, что будет работать очень неоптимально. Язык заставляет делать все более оптимально, и если вам что-то хочется навелосипедить, стоит задуматься, действительно ли вы выбираете правильное решение.
Ваш пример, так как значений очень мало, проще сделать на map (ассоциативный массив), там уже есть стандартный поиск за O(1). Если же у вас много значений, то разумнее это дело хранить в сортированном виде, и юзать binary search. В sort есть Search, который Binary search производит, также там есть SearchStrings, который делает то, что в вашем примере, но на отсоритрованном массиве. То есть когда допустим ревьювер посмотрит ваш код, увидит велосипед, у него прозвенит звонок, что где-то написано неоптимально. Если вы подключите либу, аналогично.
И если честно, я бы не сказал что это плохо, Go явно не язык общего назначения, он больше заточен под высокие нагрузки, где O(n) местами непозволительная роскошь.
Просто видимо у истоков Go стоят задачи, где за O(n) бьют линейкой по рукам, отсюда такая идеология.
Все имеет свои плюсы и минусы и когда-нибудь я думаю Go станет к этому более лояльным, особенно если вдруг generic'и появятся. Все больше и больше задач не связанных с высокими нагрузками на нем решаются, и рано или поздно это выльется во что-нибудь.
1. А можно как-нибудь получить более детальное описание, на какие запросы 400 надо отвечать?
В результатах только пишется что Code не совпадает, посмотреть тело запроса нельзя.
«Фаза обстрела # 2 (POST)», Locations — «Ответов с неверным http-кодом 3», и непонятно как это исправлять.
Уже все перебрал, и id <= 0, и добавление location уже существующего, и какие-то органичения, следующие из описания сущностей, кстати, там непонятна формулировка: «unicode-строка длиной до 50 символов.», часто сталкивался что люди по-разному такую формулировку понимают, "<" или "<=".
Плюс к этому непонятно, какие поля надо проверять на обязательность заполнения, какие нет, какие поля на что проверять (существование связанных сущностей и т.п.), а каким можно доверять.
В общем хотелось бы более четкого описания на что отвечать 400.
2. Еще по user.birth_day, в описании «Ограничено снизу 01.01.1930 и сверху 01.01.1999-ым.». В тестовом data.zip, первый же user имеет "-1720915200", это 1915 год. Что делать с таким юзером?
3. В фазе 1 остался один неверный ответ из 125 — 1. /locations/353/avg?toAge=34&fromAge=24. Тоже непонятно как исправлять с черным ящиком. Сильно сомнительно, что где-то ошибка в алгоритме, или в округлениях, которая вылазит только в одном случае.
Это все отлично, но почему требуется номер телефона при регистрации?
Мне кажется, ваш потенциальный кандидат, довольно редкая птица, и места ее обитания вполне известны. Например многие ответы на вопросы из вашего опросника я получил в ходе участия в HighloadCup, где надо копаться во внутренностях языка чтобы понять, а что можно выжать еще. А вот эта сортировка стандартная на моем наборе данных работает оптимально, или вот тут я другую использую и она быстрее будет. Многие получают этот опыт в больших компаниях с большими нагрузками, где замена алгоритма сортировки сэкономит XXX рабочих инстансов, и такое копание в деталях — имеет бизнес-значение.
Большинство же backend разработчиков (подавляющее) в основном решают другого уровня задачи, как тут верно писали в комментариях — гонять данные туда-сюда, и скорее больше фокусируются на самом бизнесе, который может быть довольно широк, отсюда и ваш вывод про — задача сделана, идем дальше, времени мало. Больше ценятся работа в команде, софт скилы, знания бизнес процессов и т.п. Плюс добавтье сюда то, что зоопарк технологий растет очень быстро, сейчас нет просто физической возможности копаться в сорцах каждого инструмента, который разработчик использует, плюс какой смысл? Среднее время работы программиста в компаниях сейчас довольно маленькое, ну изучишь ты один инструмент от и до, как ты этот опыт перенесешь на другого работодателя? Но это не означает, что при необходимости большинство разработчиков этого не сможет сделать.
Каждый десятый в мире левша, то есть потенциально — 10% рынка.
это по идее легко обеспечивается на уровне кода для всех перечисленных кейсов естественным образом. Пока изменения не вступили в силу — код о них не знает.
Остается по сути только DELETE? Удалять колонку можно когда она перестает использоваться кодом. Вроде тоже не должно быть проблемы.
Остальные операции типа MOVE, это по сути INSERT -> DELETE, их все равно придется на уровне кода обеспечивать.
У вас было что-то специфическое, что запросы переставали быть обратно совместимы? Или я где-то не вижу рояля в кустах?
«или альтером слейва с последующей сменой их местами» — можно рассказать ваши мысли про этот способ? Пробовали? Почему на нем не остановились? По идее самый привлекательный способ, какие там подводные камни?
У нас сейчас есть такая же задача, смотрим неспешно именно в сторону master-slave и их сменой.
Велик шанс что вас возьмут и дадут довольно рутиные задачи, где вообще не надо применять эти все знания… так что может оно и к лучшему?
Но такое упорство заслуживает уважения.
ps. футболка тоже не пришла :(
а если серьезно то побольше бы паузу между соревнованиями. backend, потом лифты, теперь стратегия, на все времени совсем не хватает, да и вы мне кажется не успеваете подготовиться нормально.
ps. за backend до сих пор не пришла футболка
Насчет Сименс, Бош… ну не знаю… Вы тогда получается не связанное с вебом делаете? Embedded и т.п.? Тогда конечно у вас разные области.
В Go можно тоже организовать подобное:
type SearchableList string[]
func (sl SearchableList) CanFind(search string)…
и вперед, можно его юзать.
Другое дело что да, это надо писать самому, или искать либу. Но у Go немного другая идеология на мой взгляд, — не давать делать из коробки то, что будет работать очень неоптимально. Язык заставляет делать все более оптимально, и если вам что-то хочется навелосипедить, стоит задуматься, действительно ли вы выбираете правильное решение.
Ваш пример, так как значений очень мало, проще сделать на map (ассоциативный массив), там уже есть стандартный поиск за O(1). Если же у вас много значений, то разумнее это дело хранить в сортированном виде, и юзать binary search. В sort есть Search, который Binary search производит, также там есть SearchStrings, который делает то, что в вашем примере, но на отсоритрованном массиве. То есть когда допустим ревьювер посмотрит ваш код, увидит велосипед, у него прозвенит звонок, что где-то написано неоптимально. Если вы подключите либу, аналогично.
И если честно, я бы не сказал что это плохо, Go явно не язык общего назначения, он больше заточен под высокие нагрузки, где O(n) местами непозволительная роскошь.
Просто видимо у истоков Go стоят задачи, где за O(n) бьют линейкой по рукам, отсюда такая идеология.
Все имеет свои плюсы и минусы и когда-нибудь я думаю Go станет к этому более лояльным, особенно если вдруг generic'и появятся. Все больше и больше задач не связанных с высокими нагрузками на нем решаются, и рано или поздно это выльется во что-нибудь.
В результатах только пишется что Code не совпадает, посмотреть тело запроса нельзя.
«Фаза обстрела # 2 (POST)», Locations — «Ответов с неверным http-кодом 3», и непонятно как это исправлять.
Уже все перебрал, и id <= 0, и добавление location уже существующего, и какие-то органичения, следующие из описания сущностей, кстати, там непонятна формулировка: «unicode-строка длиной до 50 символов.», часто сталкивался что люди по-разному такую формулировку понимают, "<" или "<=".
Плюс к этому непонятно, какие поля надо проверять на обязательность заполнения, какие нет, какие поля на что проверять (существование связанных сущностей и т.п.), а каким можно доверять.
В общем хотелось бы более четкого описания на что отвечать 400.
2. Еще по user.birth_day, в описании «Ограничено снизу 01.01.1930 и сверху 01.01.1999-ым.». В тестовом data.zip, первый же user имеет "-1720915200", это 1915 год. Что делать с таким юзером?
3. В фазе 1 остался один неверный ответ из 125 — 1. /locations/353/avg?toAge=34&fromAge=24. Тоже непонятно как исправлять с черным ящиком. Сильно сомнительно, что где-то ошибка в алгоритме, или в округлениях, которая вылазит только в одном случае.