Почему все время архитектурные решения? Вы боитесь читать код?
Может, потому что речь о вопросах собеседований? И если спрашивают о подходах к масштабированию, то отвечать в духе «ваше приложение надо рефакторить» несколько неуместно?
Ведь расфигачивание БД по разным машинкам это всегда дорого.
А что переписывать слой dao с JPA на JDBC например будет быстрее и дешевле чем репликацию настроить? А хранимые процедуры — их ведь потом ещё поддерживать придётся — пойди найди программистов которым охота этим заниматься. А юнит-тесты вы на них пишете? А как вы потом БД с хранимыми процедурами мигрировать будете?
Но впрочем я не собираюсь препятствовать любителям мужественно преодолевать самими собой созданные трудности. :)
1) про nginx — согласен!
2) ip-hash — если речь про sticky-sessions по IP то ко всем недостаткам sticky-sessions добавляется ещё и проблема захода двух юзеров в одну сессию в некоторых случаях — так ведь?
3) про редис согласен абсолютно! (правда томкат из коробки умеет именно memcache, который становится bottle-neck — надеюсь позже ситуация улучшится)
4) пожалуй добавлю-ка этот вопрос в пост — его ни разу не задали, но имхо он оч важный
5,6) про шардинг — и вообще лучше его не трогать если про него не спросят :)
7) да, я думал было добавить ещё про разделение приложений «по вертикали» на фронт-енд и бэк-енд, но похоже это надо в отдельную статью вообще
8) этот пункт мне вообще оч понравился — было бы неплохо если бы вы его может в маленькую статью хотя бы сделали — кажется, будет много пользы — а то потеряется, жалко! :)
Если вы случайно вдруг обнаружили, что tomcat стал есть 80%
Ну не будем горячиться :)
Мы не «случайно вдруг обнаружили». По крайней мере я этот вопрос понимаю скорее так что «мы написали приложение которое сначала юзали 2 тысячи клиентов в день, а через год 20 тысяч клиентов — и нагрузка возросла».
Безусловно если мы просто придя утром обнаружили что всё зависло и упало — это уже вопросы из другой области :D
Я менял работу с Senior-ской на Senior-скую. Хотя кто-то может сказать что это ближе к Lead-ским вопросам.
Особого опыта с похожими системами у меня не было, но это всё-таки «простейший» если можно так выразиться вариант «распределённости».
Есть более «хардкорные» проекты, где пишут низкоуровневый бэкенд… Там будут много спрашивать про multi-threading и garbage collector например, даже про JVM — даже если позиция middle… А про веб их вообще не интересует.
Хм. Когда меня просят на бумажке какой-то код написать я ни в коем случае не готов писать его синтаксически корректно и т.п. Да по-моему этого никто и не ждёт. :)
Скорее просто хотят оценить — понимает ли вообще человек что надо писать-то…
Да… «активно развивающийся стартап» где на коленке изобретают заново десяток уже написанных фреймворков это трэш, согласен стопроцентно :)
Как на собеседовании в Яндексе однажды насмешили:
Мы разработали за эти четыре года с нуля высоконагруженную распределенную систему для тестирования, снятия метрик, оценок… Здесь используются многие «ноу-хау» созданные сотрудниками… Хм… Короче сейчас мы ищем людей чтобы этот «велосипед» переписать
были вопросы о проектировании, а не о том, чем отличается интерфейс от абстрактного класса. Вот с ними то я и работаю до сих пор
да-да, я тоже в одной такой работал как раз до сих пор — там очень много говорили о проектировании, парадигмах, паттернах и почему-то писали гуанокод и не отличали интеграционных тестов от юнит.
Сам я на предложение реализовать двоичный поиск говорю «да-да, я тоже знаю этот подкол», после чего все могут дружно посмеяться и двигаться дальше.
мой опыт позволяет мне не заниматься написанием самописных реализаций сортировок\поисков\что
Некоторое время назад инет облетела замечательная статья — кто-то заморочился проверить сколько программистов разных уровней могут написать двоичный поиск без ошибок — там результаты удивительно неутешительные :)
Если вкратце то вот основные проблемы:
1. Зацикливание, например если middle присваивать (left + right) / 2 а потом left = middle (при переходе к старшей половине).
2. Ошибка переполнения при (left + right) / 2 если массив большой
3. Находит не первый индекс если есть дублирующие элементы.
Думаю я ещё забыл кое-что :)
Так что гордо сказать «не хочу работать с клоунами» это мало. Нужно попасть в эти 10% :D
Так вы попробуйте помимо Arduino ещё и язык Си поизучать… Нарочно! И вообще программирование — задачки небольшие порешайте и т.п. — чтобы это из головы в пальцы перетекло и не мешало вам заниматься серьёзными вещами ;-)
Это страшно поможет!
Многие разработчики firmware которых я знал как раз испытывали сложности в разработке из-за того что уровень скиллов программистских у них был… Ну как у ленивого студента — им трудно писать код такой чтоб его потом было легко поддерживать, трудно искать ошибки в этом коде… А как результат устройства работают то криво, то ненадёжно — причём с электроникой особенно стрёмно когда не знаешь, то ли баг в программе, то ли где-то контакт пропадает (или появляется) когда не нужно :D
а вот старшие как раз и дают то, что доводит общую картину до категории «печальная»
Боюсь все 32 разряда от 32-разрядного хэша мы используем нечасто. Это ж хэштаблица на 4 миллиарда элементов должна быть чтоб их заюзать :)
Плюс интересно насколько данный результат для 32-разрядного хэша зависел от входных данных. Всё-таки строки из словаря это далеко не произвольные данные, и символы в них тоже…
Какова же будет стоимость доставки, например, «лёгких грузов на существующих коптерах» — я понимаю что фантазировать на тему аппаратов будущего — да ещё при постоянно меняющейся стоимости самих денег — это сложно.
Сколько будет стоить доставка договора из двух страничек для подписания сотрудничающей компании?
Сколько доставок переживёт один набор аккумуляторов? Сколько сам коптер? Скажем, если коптер выходит из строя после 100 доставок, то это видимо будет определять и стоимость…
Правда есть ещё бурное сомнение что над Москвой разрешат летать коптерам (кроме военных и милицейских) в таком количестве.
Когда я в конторе разработкой электроники занимался, паралельные интерфейсы ЖК-дисплеев ужасно бесили при дизайне и разводке плат.
К сожалению дисплеев работающих по I2C вообще очень мало, и не всегда удавалось подыскать а тем более заказать подходящий.
Поэтому чаще ограничивались паралельным интерфейсом с 4 разрядами вместо 8 (почти все ЖК-дисплеи это умеют) — в сумме вместе с управляющими получалось штук 8-9 проводников вместо 12-13.
Код Ваш, честно говоря несколько прискорбный. Вы же умеете использовать массивы? Вот и юзайте их вместо этих длинных цепочек одинаковых вызовов и вместо этого switch-а для печати цифр…
И по поводу использования библиотек — я бы осмелился порекомендовать на данном этапе пробовать без них. Сколько помню у данного чипа достаточно простой и внятный к I2C был подход, так что методически было бы весьма полезно читать мануал по нему нежели искать по форумам нужную библиотечку :)
Впрочем повторюсь, сама тема актуальная весьма, фотографии достаточно неплохо получились — так что пост вызывает одобрительные чувства!
Я плохо знаком с реализуемым вами процессом для пользователей (точнее не знаком) поэтому не могу оценить — например, возможно ли в вашем случае уточнение с помощью названия города или нет…
И выражение «ошибки неприемлемы» я честно говоря не до конца понимаю. Есть технологический параметр — цена ошибки… Вы наверное не имеете в виду что в вашем случае он бесконечный? Или я наверное не до конца понимаю какую задачу вы решаете.
В нашем случае например речь идёт о том что либо человек публикует некорректное объявление (и теряет на его стоимости — ну впоследствии жалуется и ошибка исправляется) — либо система пропускает адрес публикация которого карается штрафом (но поскольку эти адреса на конкретных улицах, а не для всех улиц вероятность ошибки одинакова — величина тоже получается ещё меньше).
Исходя из этих соображений и решили мириться.
Правда был ещё такой критерий — сложность добавления новых топонимов в список (фактически на это требуется программист). Я думаю в вашем случае этой проблемы нет, если я верно понял…
Ну да, там реализация конечного автомата, хотя достаточно неуклюжая на мой теперешний вкус. :)
Насчёт 0.02% я не могу точно сказать насколько это «неплохо». Проблема оценки в том что для неё я использовал меньше миллиона строк — и это были строки просто взятые из того что в течение последних месяцев присылали клиенты. (т.е. не удивлюсь если какие-то очень редко встречающиеся топонимы не были проверены)
Если бы я сам настойчиво сел по списку для каждой улицы выдумывать возможные варианты опечаток — думаю раз в пять-десять больше бы эта величина была.
Но конечно после этого я бы мог «тюнинговать» словарь (хотя возможно некоторые выражения стали бы сильно неуклюжими).
Вообще пожалуй любопытно было бы потестить на каких-нибудь «более других» данных :)
Топонимов около 2000 в СПб, кажется, если вопрос об этом.
Может, потому что речь о вопросах собеседований? И если спрашивают о подходах к масштабированию, то отвечать в духе «ваше приложение надо рефакторить» несколько неуместно?
А что переписывать слой dao с JPA на JDBC например будет быстрее и дешевле чем репликацию настроить? А хранимые процедуры — их ведь потом ещё поддерживать придётся — пойди найди программистов которым охота этим заниматься. А юнит-тесты вы на них пишете? А как вы потом БД с хранимыми процедурами мигрировать будете?
Но впрочем я не собираюсь препятствовать любителям мужественно преодолевать самими собой созданные трудности. :)
Примечательно что кроме вас никто не заметил а бросились binarySort обсуждать :)
Тем не менее по ходу собеседований оказывается что это поди ж ты не middle вопросы :)
Ну мне не жалко — если хотят больше платить — так и ладно.
Поэтому хотя часть действительно не относится к java — я постеснялся вылезать за рамки своей компетенции…
1) про nginx — согласен!
2) ip-hash — если речь про sticky-sessions по IP то ко всем недостаткам sticky-sessions добавляется ещё и проблема захода двух юзеров в одну сессию в некоторых случаях — так ведь?
3) про редис согласен абсолютно! (правда томкат из коробки умеет именно memcache, который становится bottle-neck — надеюсь позже ситуация улучшится)
4) пожалуй добавлю-ка этот вопрос в пост — его ни разу не задали, но имхо он оч важный
5,6) про шардинг — и вообще лучше его не трогать если про него не спросят :)
7) да, я думал было добавить ещё про разделение приложений «по вертикали» на фронт-енд и бэк-енд, но похоже это надо в отдельную статью вообще
8) этот пункт мне вообще оч понравился — было бы неплохо если бы вы его может в маленькую статью хотя бы сделали — кажется, будет много пользы — а то потеряется, жалко! :)
Ну не будем горячиться :)
Мы не «случайно вдруг обнаружили». По крайней мере я этот вопрос понимаю скорее так что «мы написали приложение которое сначала юзали 2 тысячи клиентов в день, а через год 20 тысяч клиентов — и нагрузка возросла».
Безусловно если мы просто придя утром обнаружили что всё зависло и упало — это уже вопросы из другой области :D
Особого опыта с похожими системами у меня не было, но это всё-таки «простейший» если можно так выразиться вариант «распределённости».
Есть более «хардкорные» проекты, где пишут низкоуровневый бэкенд… Там будут много спрашивать про multi-threading и garbage collector например, даже про JVM — даже если позиция middle… А про веб их вообще не интересует.
Хм. Когда меня просят на бумажке какой-то код написать я ни в коем случае не готов писать его синтаксически корректно и т.п. Да по-моему этого никто и не ждёт. :)
Скорее просто хотят оценить — понимает ли вообще человек что надо писать-то…
Как на собеседовании в Яндексе однажды насмешили:
да-да, я тоже в одной такой работал как раз до сих пор — там очень много говорили о проектировании, парадигмах, паттернах и почему-то писали гуанокод и не отличали интеграционных тестов от юнит.
Сам я на предложение реализовать двоичный поиск говорю «да-да, я тоже знаю этот подкол», после чего все могут дружно посмеяться и двигаться дальше.
Некоторое время назад инет облетела замечательная статья — кто-то заморочился проверить сколько программистов разных уровней могут написать двоичный поиск без ошибок — там результаты удивительно неутешительные :)
Если вкратце то вот основные проблемы:
1. Зацикливание, например если middle присваивать (left + right) / 2 а потом left = middle (при переходе к старшей половине).
2. Ошибка переполнения при (left + right) / 2 если массив большой
3. Находит не первый индекс если есть дублирующие элементы.
Думаю я ещё забыл кое-что :)
Так что гордо сказать «не хочу работать с клоунами» это мало. Нужно попасть в эти 10% :D
Это страшно поможет!
Многие разработчики firmware которых я знал как раз испытывали сложности в разработке из-за того что уровень скиллов программистских у них был… Ну как у ленивого студента — им трудно писать код такой чтоб его потом было легко поддерживать, трудно искать ошибки в этом коде… А как результат устройства работают то криво, то ненадёжно — причём с электроникой особенно стрёмно когда не знаешь, то ли баг в программе, то ли где-то контакт пропадает (или появляется) когда не нужно :D
Боюсь все 32 разряда от 32-разрядного хэша мы используем нечасто. Это ж хэштаблица на 4 миллиарда элементов должна быть чтоб их заюзать :)
Плюс интересно насколько данный результат для 32-разрядного хэша зависел от входных данных. Всё-таки строки из словаря это далеко не произвольные данные, и символы в них тоже…
(с) классика
Не могу найти, задан ли уже этот вопрос:
Какова же будет стоимость доставки, например, «лёгких грузов на существующих коптерах» — я понимаю что фантазировать на тему аппаратов будущего — да ещё при постоянно меняющейся стоимости самих денег — это сложно.
Сколько будет стоить доставка договора из двух страничек для подписания сотрудничающей компании?
Сколько доставок переживёт один набор аккумуляторов? Сколько сам коптер? Скажем, если коптер выходит из строя после 100 доставок, то это видимо будет определять и стоимость…
Правда есть ещё бурное сомнение что над Москвой разрешат летать коптерам (кроме военных и милицейских) в таком количестве.
Когда я в конторе разработкой электроники занимался, паралельные интерфейсы ЖК-дисплеев ужасно бесили при дизайне и разводке плат.
К сожалению дисплеев работающих по I2C вообще очень мало, и не всегда удавалось подыскать а тем более заказать подходящий.
Поэтому чаще ограничивались паралельным интерфейсом с 4 разрядами вместо 8 (почти все ЖК-дисплеи это умеют) — в сумме вместе с управляющими получалось штук 8-9 проводников вместо 12-13.
Код Ваш, честно говоря несколько прискорбный. Вы же умеете использовать массивы? Вот и юзайте их вместо этих длинных цепочек одинаковых вызовов и вместо этого switch-а для печати цифр…
И по поводу использования библиотек — я бы осмелился порекомендовать на данном этапе пробовать без них. Сколько помню у данного чипа достаточно простой и внятный к I2C был подход, так что методически было бы весьма полезно читать мануал по нему нежели искать по форумам нужную библиотечку :)
Впрочем повторюсь, сама тема актуальная весьма, фотографии достаточно неплохо получились — так что пост вызывает одобрительные чувства!
И выражение «ошибки неприемлемы» я честно говоря не до конца понимаю. Есть технологический параметр — цена ошибки… Вы наверное не имеете в виду что в вашем случае он бесконечный? Или я наверное не до конца понимаю какую задачу вы решаете.
В нашем случае например речь идёт о том что либо человек публикует некорректное объявление (и теряет на его стоимости — ну впоследствии жалуется и ошибка исправляется) — либо система пропускает адрес публикация которого карается штрафом (но поскольку эти адреса на конкретных улицах, а не для всех улиц вероятность ошибки одинакова — величина тоже получается ещё меньше).
Исходя из этих соображений и решили мириться.
Правда был ещё такой критерий — сложность добавления новых топонимов в список (фактически на это требуется программист). Я думаю в вашем случае этой проблемы нет, если я верно понял…
Насчёт 0.02% я не могу точно сказать насколько это «неплохо». Проблема оценки в том что для неё я использовал меньше миллиона строк — и это были строки просто взятые из того что в течение последних месяцев присылали клиенты. (т.е. не удивлюсь если какие-то очень редко встречающиеся топонимы не были проверены)
Если бы я сам настойчиво сел по списку для каждой улицы выдумывать возможные варианты опечаток — думаю раз в пять-десять больше бы эта величина была.
Но конечно после этого я бы мог «тюнинговать» словарь (хотя возможно некоторые выражения стали бы сильно неуклюжими).
Вообще пожалуй любопытно было бы потестить на каких-нибудь «более других» данных :)
Топонимов около 2000 в СПб, кажется, если вопрос об этом.