kashey
0
PS: Проблемы с общими моками, подключенными через третий файл — нет. У каждой инстанс сам за себя, так как rewiremock сам себя из кеша вырезает. Общий только кеш nodejs.
kashey
0
Жил в России — все фигели от моего русского. Переехал зарубеж — теперь все фигеют от моего английского.

Насчет параллельных тестов — сразу честно — не тестировал, но должно работать. Потому что:
1. База моков — общая (надо будет сделать простой интерфейс по клонированию и ресету моков перед началом теста).
2. По enable/disable из кеша вырезаются все мокнутые файлы и все файлы что как либо от них зависят.
Итого можно быть увереным, что после enable получите ровно то, что и нужно, а после disable — все вернется на круги своя.

Единственная проблема — ресет.
Возможно вот такой код сработает:
//mocks.js
 rewireMock('file1'); // do nothing, just indicate mock, to wipe it from a cache
 rewireMock('file2');


//test.js
 rewireMock('file1').with(something); // override mock.
kashey
+2
Но на самом деле — скучно. Я то уж боялся, что там будут страшные вопросы про хитрые моменты PHP, классы, архитектуру, greedy алгоритмы и жадные регулярки.
А то я уже лет 7 не являюсь php разработчиком, и _НЕ_ должен пройти этот тест.
(ну один пунктик одного вопроса я зафейлил)
По факту вопросы были стартового для хакерранка уровня. Школа/Первый курс. Базовые алгоритмы (которые в принципе ЦА как раз может уже немного и забыть, кстати)

Имхо тест должен быть такой, чтобы мог показать уровень кандидата, и отсеять как можно больше не ЦА.
Тут же — половина задач не может быть автоматически обработано, и требует ревью живым человеком. Сложно.

Я бы добавил бы пару примеров посложнее, и пару примеров которые можно решить сильно по разному. Например поиск подстроки в строке с ограничением по времени/большими строками.
И/или задачу реализовать наследование обьектов под некую задачу. Хоть под многоугольники. Опять же первый курс, но можно подойти творчески.

Идеал — когда основная часть народу не может решить половину задач, что позволяет отсеять самый сок. И даже с таким отбором 90% прошедших на самом деле люди не подходящие. К сожалению.
kashey
0
Все верно —
От каждого по способностям, каждому по потребностям.

Если нет способностей, но есть потребности — rewiremock и аналоги помогут.
kashey
0
У вас не совсем корректный пример. Точнее вы не правильно используете proxyquire.
Ваш пример работает на основе паразитного сайд эффекта работы библиотеки, а точнее на основе странного поведения, когда после работы proxyquire в кеше модульной системы остается мокнутая версия process.
Буквально в следущем тесте, когда вы уже будете ожидать «нормальное» поведение — вам прилетит сюрприз.
Не делайте так. Очень много людей ночами не спали, все думали почему по одиночке их тесты работают, а все вместе — падают.
Правильный код:
const app = proxyquire.noPreserveCache().load('./app', { process: { uptime } }); // app с мокнутым process
const app = require('./app'); // "настоящий" app, как и должно быть

PS: В любом случае «нужный» app надо забирать из метода load, а не require. Даже если noPreserveCache вам не нужен.

В то же время такой код нормален для rewiremock
rewiremock('process').with({uptime});

rewiremock.enable();
const app = require('./app'); // app с мокнутым process
rewiremock.disable(); // вычистит все затронутые модули

const app = require('./app'); // "настоящий" app, как и должно быть
kashey
0
И jest `мокает` так же как sinon. Это не перехват внутренней зависимости модуля, а внешней.
Представим что вас есть код на реакте
 const someComponent = ()....

 const mapStateToProps = (state) => ({
   awesomeData: coolSelectorFromReduxStore
 });

 const ConnectedComponent = connect(connect(
  mapStateToProps
)(someComponent);

И вы тестируете именно ConnectedComponent. Ну бывает.
Стандартные средства заставят вас собрать правильный store, обернуть все в Provider и все будет плохо. Там нечего мокать «напрямую». Все спрятано в файле и в тесты не светит.

Rewiremock и компания же могут «по живому» перегрузить connect или coolSelectorFromReduxStore внутри файла, а не снаружи, и итоговый тест будет прост как три копейки.
kashey
0
Я подразумевал живых людей из дельта окрестности. Библиотек то – на любой вкус.
kashey
0
За прошедшие два года я успел: допилить геокодер, переписать регионы на es6, обзавестись третим сыном и переехать в Австралию.
Чего не успел — добиться стабильной сборки геометрии одной командой с консоли.
А osme некоторое время назад пришлось скрыть из-за некоторых моментов, которые не очень дружат с опенсорсом.
В данный момент переписываю. В моих интересах выложить его куда либо, чтобы получить помощь других разработчиков и снять это ярмо(tech debt) с шеи.
kashey
+2
Вместо
<button aria-hidden="true" style="display: none;">Don't Click Me</button> 

Надо писать просто
<button hidden>Don't Click Me</button>

В том числе для любых скрытых через css элементов никаких aria-hidden писать не надо, так как элементы которые не присутствуют в render-tree так же не присутствуют в accessibility-tree.
Вообще по «разделению» role=«presentation» и aria-hidden были долгие споры в интернете, так как оба этих подхода в итоге делают одно и тоже.
Да и вообще 80% «правил» применений ARIA имеет под собой более философскую проблему, чем техническую.
kashey
+1
16 метров же?
А обычный 32-ти битный Z код описывает квадрат по стороной 300 метров если его применять «world-wide». Достаточно для фильтрации большинства данных.
kashey
0
А можно бенчмарк для 32-битных ключей. В принципе 16 бит на координату — достаточно, особенно если использовать Z именно как индекс.
kashey
0
Кстати — Hierarchical Triangular Mesh индексируется такой же кривой как Z. При наличие правила обхода треугольников получается код полностью удовлетворяющий принципам spatial filling.
Шрырительный пример http://kashey.ru/maps/fractal/fractal.html, где Z и G — обычные 2Д разбиения, а T и L — «треугольные» (T на основе треугольника ньютона, 4 ноды за раз, L — две ноды)
kashey
+1
О! Месье знает толк колбасных обрезках. Жму вашу руку, коллега.
kashey
+2
1. В принципе да, на стороне БД это уложиться в B-дерево. Получается достаточно честно. Смотрите на это без БД.
2. Кстати – Z-code, который иногда еще называют «bit interleaving», в принципе KD. Каждый бит режет пространство своей плоскостью.
3. Только вот поиск в окрестности такой четырех-мерной точки будет немного затруднен :)

В общем случае Z(и компания) просто позволяет в начале как-то уложить в некий интервал данные, а потом в нем искать.
При это самый «быстрый» поиск по кодам, когда вам нужна конкретная «ячейка» виртуального quadtree, лучше всего (технически) работает через маску. Вы говорите с чего код должен начинаться – фиксируете первые шаги погружения в дерево, а после некого момента «отпускаете» код, позволяя ему свободно менятся.
Если весь код 4 бита, те 2 уровня, то фиксация 0b1000 с маской 0b0111 матчится на все элементы в левом(или правом) поддереве, те между 0b1000 и 0b1111.
В принципе — это — возможность использовать эти «числа» как NestedSet — одна из основых фичей этих кривых. За прошедшие годы для разных spatial filling придумали очень много наркомании. Текстуры в памяти видеокарты по ним разложены. Gray Code, на котором 99% электроники работает — тоже spatial filling.

К своему сожалению — я далеко не самый лучший рассказчик, но быть может одна старая статейка немного поможет понять, что же я имел в виду.
kashey
+2
Очень хорошо, но есть пара проблем:
1. Z-code это, фактически linear quad-tree. Не R. И совсем не B. Все, что вы обьявили бонусами в начале статьи — не работает. Никакой балансировки нет. И дерева никакого нет. Это что-то среднее между фракталом и кривой – spatial filling curve, И их много бывает разных. Смысл один — понижают размерность.
2. Попробуйте Hilbert. Считать его сложнее, но более «близкие» значения в нем расположены «ближе»
3. «Секрет» работы Z-value-ii хорошо описан в интернетах как BIGMIN/LITMAX (https://en.wikipedia.org/wiki/Z-order_curve#Use_with_one-dimensional_data_structures_for_range_searching)

В общем крайне рекомендую активно дружить с этой математикой. Она реально хорошо работает, но надо понимать ограничения.
И не забывать — Z это точка. В то время как R-tree продолжает жрать кактус.

PS: Еще в интернетах можно найти множество более быстрых функций построения Z-кодов
PPS: Некоторые модификации R-tree сами по Z строятся
PPPS: Вэлкам ту зе клаб!
kashey
0
s/еще не задача/еще та задача.
Особенно если требуется экономить пользовательский трафик.
Esosedi/regions тут в плюсе — 3 языка, 8 уровней детализации(4*тип границ), супер компактный размер исходных данных, различные спец возможности, возможность использовать локально.
kashey
+1
Большинство примеров тут так или иначе построены вокруг административного деления, которое получить — еще не задача.
В итоге не могу не прорекламировать свой «источник» этих данных, который в принципе и раскрашивать их умеет, при должной сноровке – esosedi/regions – просто, бесплатно, компактно. Пост на хабре.
kashey
0
На более не равномерных данных, например на обзорных масштабах, когда виден и город (густо) и область(пусто), или когда количество обьявлений упрется в лимит — эффект будет более заметен.
kashey
0
При горизонтальном драге перестроения быть не должно. На гифке есть «хорошая» догрузка при драге направо, и «плохая» при драге обратно. В том числе кластеризация не «устойчивая».
Когда я похожую проблему решал много лет назад для схожего по тематике сайта gdeetotdom – мне первое решение завернули сразу именно из-за «раздражающих анимашек» неустойчивой кластеризации.
kashey
+1
Вот в том и дело — что дополнительную сложность не вводит, новые пины у вас появляются рядом со старыми, да и кластеризация при таких условиях может полностью менять картинку при малейших изменений данных.
Вот смотрели вы на краешек Москвы, и все данные были там. Потому что их много.
А потом подвинули на пиксель — и картинка полностью изменилась. Потому что данные обычно запрашивают с никим лимитом, и раньше этот лимит «тратился» на центр города.
У меня (к счастью? к сожалению?) нет возможности проверить как работает андроид приложение, но в вебе сейчас все с этим плохо, и всегда так и было – информация приходит не равномерно.
Сейчас есть два «хороших» решения проблемы — или загрузка данных дискретными «тайлами». В том числе там нет понятия «запрос, который еще не успел выполнится» — тайл в любом случае может оставаться актуальным, и пускай продолжает загружаться. Либо ограничения лимита через серверную кластеризацию, по тем же Z-кодам.
PS: Z-code, он же Morton code, может быть заменен Geocode или hilbert code. В общем 1D spatial index.

Опять же — если хранить данные в Z кодах, а запрашивать в тайлах — запрос превращается в поиск в 1D интервале и начинает работать чуть чуть быстрее.
У меня нет ссылки на «не матан», а на понятное обьяснение задачи, но есть видео.

Ну и конечно же все эти мозги без особых проблем спрячутся за фасадом функции getClusters, а сам пример с RxJS очень понравился.
kashey
0
Потому что это карты, и совершенно нормальные две ситуации — человек сдвинул карту не очень сильно(и большая часть старых данных валидна), и человек сдвинул карту обратно (и надо бы использовать те данные что есть).
Это приводит к тому, что при сдвиге карты надо загрузить только дельту по сдвигу, дополнив, а не заменив, данные.
В общем в JS API этот момент немного самим API покрыт, под андроидом судя по всему — нет.

Так уж получилось — но Яндекс.Недвижка ну совсем не умеет работать с данными карты. А принцип там очень простой — при сдвиге карты данные (в уже видимой области) НЕ должны меняться.
kashey
0
человек передвинул карту, то предыдущий запрос теряет актуальность и мы должны запросить новые точки.

Конечно же это не так :)
kashey
+16
Как я скучал по таким статьям!
kashey
0
В https://github.com/yandex/ymb никакого бабеля нету, как и возможности использовать es2015 модули.
А сам сборщик не плохой, особенно в плане минимизации передачи данных.
kashey
–1
Да знаю что видели. Говорят просто о чем-то другом, о возвышенном, думали когда мысли свои на бумагу переносили.
Что «старый» importScripts невозможно использовать, что новый import/require почему-то думает что все исходники лежат в разных файлах и доступны надежно и с нулевым латенси.
В ES6 Modules есть только один плюс — возможность статического анализа. Все остальное как-то не о том.
А все эти webpack, browserify, requirejs, systemjs — это не от жизни хорошей. У нас вот тоже «своя» модульная система есть — ymb/yms.
kashey
0
Одно только плохо — никакого нормального способа это делать в «родном» синтаксисе js почему-то не придумали.
Такая необходимая фича, и ни намека про нее в стандарте :(
Как будто не видели придумыватели стандартов решения на AMD и аналогах. Не знали что сервер по другую сторону WiFi, браузеры не резиновые, трава не зеленая.
kashey
0
Если смотреть на техническую реализацию — ООП породил классы. Классы породили таблицу виртуальных методов. Которая дала возможность работать с классами-наследниками как с классами-родителями.
Что для большинства строго-типизированных языков — основа функционирования различных контейнеров и половины программных интерфейсов.
В том числе потому что эти «программные интерфейсы» на вход получают не реализации неких интерфейсов, а именно наследников базовых классов.
Этот момент сильно зависит от конкретного ЯП, зашит в стиль использования конкретного ЯП. Это норма, фактически словом ООП различные ЯП, архитектуры, школы и подходы и «продают» разные понятия. Насколько я понял — lair в начале этого топика примерно об этом и говорил.
kashey
–2
ООП очень странный предмет:
— для некоторых языков (тот же PHP, JS) это просто некий архитектурный синтаксический сахар. Возможность.
— для некоторых языков (С++?) это техническая возможность «обойти» статическую типизацию. Привет приведению типов!
У первой группы нет проблемы вызвать любой метод любого обьекта, у второй группы нет выбора. В итоге получается что бывает разный ООП, для разных целей и растет он из разных причин.
Судя по всему Ален Кей не называл ООП ни первое ни второй. Софистика…
kashey
+4
Интервью взято в феврале, но руки дошли до публикации только сейчас.

А потом его постригли…
kashey
0
Так и есть. А потом еще и удаляется, вызывая фризы GC. Ну и слабо оптимизируются, так как мало раз выполняются.
В этом плане обычные замыкания от «стрелочных» никак не отличаются. Но боятся этого надо когда такое создание/уничтожение имеет массовый характер.
И можно было бы сделать (и имело бы смысл) код как в примере №2 — он был бы самым быстрым и про однократной работе коде, и, особенно, при многократной.
kashey
0
В свое время задушили Жабу и поставили на сервер БД отдельный Raid и BBU к нему.
Эффект был просто феерический. Режим WriteBack реально творит чудеса.
kashey
0
Вы конечно молодцы, и выпустили удобный продукт… Но давайте класс Earth отправим на глубокий рефактор.
Есть список макрорегионов (https://ru.wikipedia.org/wiki/Макрорегионы_мира_(ООН)), на основе которого и надо именовать методы.
Регионов дефакто немного больше, они немного по другому разбиты. И Micro — это микронезия, не надо ее обижать.
PS: Связь стран и макрорегионов можно взять из экспорта http://data.esosedi.org/
kashey
0
Есть же "модуль регионов" от Яндекс.Карт, или их аналог от меня лично.
Пример раскраски — http://twirl.github.io/ymaps-stat-visualizer/cities.html
kashey
+4
Смайлик, или IE7?
PS: Счастливый человек!
kashey
0
Это как бы понятно. Можно еще учитывать что данные можно готовить чуть раньше и в другом треде, так чтобы к моменту сравнения именно сравнение быстрее сработало, даже если один раз.
Но жалуюсь я на то, что именно реализаций и не заметно – гуглинг типа «BHV point in polygon» ничего не дает. Мухи и котлеты — отдельно.
В Q/B/BSP деревья для данной задачи я не верю. И в BHV тоже не верю — тут капсули нужны, а не волумы.
kashey
0
Все в этих математиках хорошо, но 99.99% реализаций (которые я видел) не содержат оптимизации через деревья. В том числе из-за того что время подготовки данных сильно больше времени работы самого алгоритма по наивному варианту.
kashey
0
Это не сарказм. Я сам уже успел два подхода к станку сделать, и готовлю третий.
kashey
+1
Еще чатики в МирТесен были, «приветики» в esosedi и другие геопривязанные твитеры с meanwhile на хвосте.
Такое количество не самых удачных решений явно показывает что дело нужное. Просто никак приготовить не получается.
kashey
+2
ObjectManager, RemoteObjectManager, LoadingObjectManager и просто Clusterer.
https://tech.yandex.ru/maps/doc/jsapi/2.1/dg/concepts/many-objects-docpage/