К сожалению, доступ к тому коду уже утрачен, а разбираться заново сейчас не готов. Мои ссылки на документацию, увы, тоже протухли (excel & sorting, Understanding the Excel Object Model). Но суть там была относительно простой — создаём правильный COM-объект и изучаем в MSDN дерево объектов. Дальше — творим свою бизнес-логику (подсматривая иногда в код сгенерированных на VBA макросов).
Рекомендую начать откуда-то отсюда:
Excel object model overview — здесь можно подсмотреть дерево объектов, оно должно совпадать с доступным из COM.
Тема на social — тут есть следы моих ссылок, м.б. что-то полезное найдётся в окрестностях, но я быстро не нашёл.
Если мне не изменяет память, в студии была tool’а (где-то в External Tools при более-менее полной установке), которая показывала список зарегистрированных в системе COM-объектов (а может она есть в самой винде, а не в студии). Там нужно поискать Excel и/или vsto.
Немного скепсиса в тему: работать на террасе в солнечную погоду не очень комфортно из-за бликующего монитора, шума и позы типа «скрючился в модном кресле-качалке».
Имхо, не стоило переводить слово embedding. Его обычно просто транслитерируют, иногда векторами слов называют. При чтении отрывка постоянно приходится декодировать смысл методом обратного перевода, что очень мешает читать.
P.S. Я за грамотный и чистый русский язык, но в данном случае речь об отсутствии устоявшегося перевода.
Даже 255!/(255-85)! — это слишком много. При этом не понятно, зачем им брать эквивалентные наборы (те же токены, но в другой последовательности выбранные) — они же дают тот же эффект. Т.е. по-хорошему, нужно ещё на 85! разделить и получить C(n,k), но и это, конечно, очень много.
Однако, оказалось, что мы покрыли тестами то, что съедало много времени тестировщика, но при этом практически никогда не менялось разработчиками и слабо влияло на процессы бизнеса.
И где тут ошибка?
Тестировщиков освободили от рутины — профит (больше времени на полезные задачи, выше мотивация). Регрессионные тесты они как раз про то, чтобы не сломать случайно в будущем что-то давно и хорошо работающее и не терять деньги от простоя — профит для бизнеса.
Да, соглашусь, поторопился.
vtable один на объект (для каждого интерфейса), корректно инициализированный наследниками, и множественное/виртуальное наследование тут ничего не сломает при хождении по иерархии.
Под «экспертизой по ML» я имел ввиду наличие опытного сотрудника, представляющего себе, что такое машинное обучение, и способного ставить задачи/проверять результат.
Нет экспертизы по ML + желание взять специалистов подешевле (без опыта) = большие проблемы в будущем (с архитектурой, кодом, производительностью). Стажёрами нужно много заниматься, понимая при этом что и зачем они делают. /Зануда mode off/
Может быть, 2Мб для чтения двух подряд байт — поиск первого значения прогрузит адреса в TLB, сбросить их нельзя (из user space), зато можно взять второй мегабайт и замеряться на нём (новые адреса, не в TLB). Потом вернуться к первому мегабайту, и так по кругу.
pyahocorasick — и не нужно изобретать велосипед.
Кстати, в статье описано простое префиксное дерево, которое построит движок регулярных выражений, если добавить в него все альтернативы через ИЛИ. А Ахо-Корасик работает несколько сложнее: у него есть переходы между ветками, благодаря чему не нужно перезапускать поиск на каждом символе (или делать возвраты в переборе).
Не в защиту префиксов (сам их не люблю), но справедливости ради.
В современных средах после точки можно вводить любой кусок имени идентификатора, сопоставление ищется по подстроке (VisualAssist, например, такое умеет).
P.S. пардон, ниже уже об этом написали.
К сожалению, доступ к тому коду уже утрачен, а разбираться заново сейчас не готов. Мои ссылки на документацию, увы, тоже протухли (excel & sorting, Understanding the Excel Object Model). Но суть там была относительно простой — создаём правильный COM-объект и изучаем в MSDN дерево объектов. Дальше — творим свою бизнес-логику (подсматривая иногда в код сгенерированных на VBA макросов).
Рекомендую начать откуда-то отсюда:
Excel object model overview — здесь можно подсмотреть дерево объектов, оно должно совпадать с доступным из COM.
Про VSTO на wiki.
Как ms всех пересаживает на js. Видимо, тут причина закопанной документации по interop’у на плюсах.
Тема на social — тут есть следы моих ссылок, м.б. что-то полезное найдётся в окрестностях, но я быстро не нашёл.
Если мне не изменяет память, в студии была tool’а (где-то в External Tools при более-менее полной установке), которая показывала список зарегистрированных в системе COM-объектов (а может она есть в самой винде, а не в студии). Там нужно поискать Excel и/или vsto.
P.S. Я за грамотный и чистый русский язык, но в данном случае речь об отсутствии устоявшегося перевода.
Вообще, статья оставляет ощущение какой-то незаконченности. Яснее не стало.
И где тут ошибка?
Тестировщиков освободили от рутины — профит (больше времени на полезные задачи, выше мотивация). Регрессионные тесты они как раз про то, чтобы не сломать случайно в будущем что-то давно и хорошо работающее и не терять деньги от простоя — профит для бизнеса.
vtable один на объект (для каждого интерфейса), корректно инициализированный наследниками, и множественное/виртуальное наследование тут ничего не сломает при хождении по иерархии.
Кстати, в статье описано простое префиксное дерево, которое построит движок регулярных выражений, если добавить в него все альтернативы через ИЛИ. А Ахо-Корасик работает несколько сложнее: у него есть переходы между ветками, благодаря чему не нужно перезапускать поиск на каждом символе (или делать возвраты в переборе).
В современных средах после точки можно вводить любой кусок имени идентификатора, сопоставление ищется по подстроке (VisualAssist, например, такое умеет).
P.S. пардон, ниже уже об этом написали.