Ну, Запад много хорошего перенял у СССР, когда была конкуренция двух систем. Сейчас конкуренции больше нет и социальные условия якобы (как говорят старожилы) становятся хуже. Ну я в 80-е жил в СССР, а не на Западе, сравнивать не могу. Но многие вещи, которые нам обещали при социализме, с удивлением обнаруживаю в Германии.
Из данного обобщения есть исключения. Но очевидно, что если мыслительные процессы у мужчин и женщин происходят по-разному (а это - медицинский факт, тут, например, интересная инфографика), то и подход к управлению проектами у разных полов - разный. Аргументация, в целом хорошо работающая для мужчин, может плохо подходить для женщин. Как и наоборот. Женщины видят больше деталей, умеют их лучше интерпретировать, оценивать. Мужчины считают это чудом и называют интуицией. Мужской мозг умеет отфильтровывать детали, оставляя только сами объекты, их контуры. Сэкономленные ресурсы мужской мозг может себе позволить потратить, например, на выхолащивание объектов в абстрактные модели. Мне лично понимание этого факта в своё время сильно упростило жизнь.
Да, привет. Безусловно, я же без претензий. Воспользовался случаем напомнить про эту «древнюю» метрику ;)
По моему опыту 80 процентов тормозов любого компьютера, от ноутбука до сервера, связано с дисковой подсистемой, как самой медленной. SSD эту проблему частично решают.
В общем — «прикопали» этот лайфхак (и можно ещё гвоздиком вверх в правом углу приколотить :))
Загрузку процессора и памяти посмотрели. Молодцы! А почему про глубину очереди чтения записи (queue depth) СХД или сервера ничего не написали? Забыли?
Метрика выражается целым числом и для оптимально загруженной системы рассчитывается по формуле:
Data Queue = 2 + <количество шпинделей жёстких дисков RAID-массива>.
Т.е. если глубина равна 10 или больше, а у вас, например, всего 4 диска (шпинделя) — есть повод задуматься об оптимизации, а если больше 50 — у вас проблема.
Достать показатель проще всего через оснастку монитора производительности (Performance Monitor — Физические носители — актуальная длина очереди). Через Task Manager такое не видно.
Извините, уважаемый Shmidtk, отличная идея!
Но получилось, что замах на рубль, а удар на копейку.
Очень надеюсь, что вы всё-таки доработаете свою таблицу и исправите хотя бы фактические ошибки. Как план для быстрого отчёта по проделанной работе для начальства табличка может и годится, но вот делать на её основе адекватные выводы опасно. Это будет кошмар, если другие пользователи начнут делать свои выводы на её основе.
У Qlik (не Qlick, поправьте пожалуйста) есть несколько продуктов. Уточните плз, какой вам показывали (но очевидно, что это Sense).
С удивлением обнаруживал, что вы отняли функциональность, которая в продуктах есть, а вы её заминусовали (например, tooltips, crossjoin и группировка у Power BI, параметры запросов у Qlik). Это не полный перечень.
C учётом того, что описания некоторых «фич» я перечитывал несколько раз, но не уверен, что понял их все. Спрашивал у коллег, думал, только я не догоняю, но нет, всем отделом решали этот ребус. Попробуйте уточнить определения и, уверен, ценность статьи от этого только выиграет.
Вообще, похоже на сравнительный анализ куриц и крокодилов только на том основании, что и те и другие несут яйца. Но это, конечно, моё субъективное мнение.
Думаю понятие «статистической значимости» здесь применимо на 99,99%. Меня учили, что при анализе «человеков» ((С) Футурама) объём выборки в 1000 — минимально достаточен. При уменьшении этого числа точность деградирует значительно сильнее, чем повышается при его (даже значительном) увеличении.
Другими словами: 1000 — нормуль, 10000 — хорошо, 1 млн. — ещё лучше, 500 — скорее всего полня фигня.
Слава богу не отменили, всё, вроде регулярно обновляется. По крайней мере ничего не читал про то, что чему-то из списка пришёл конец.
И если у Вас есть релевантные ссылки по данной тематике кидайте сюда. Думаю многим будет интересно.
По приведённым цифрам, честно, говоря, так и не понял, какая именно задача решалась, но это особо и не важно. Понятно, что по сравнению с несколькими часами или даже днями 140 секунд — это мгновенно :)
Мне вот интереснее вопрос о неоднозначности поиска словоформы. Первая попавшаяся обычно очень кривая. Этот анализ проводился?
Безусловно никакого дополнительного смыслового анализа не проводилось. Это задача более сложных систем ИИ. А вот морфологический анализ — это без проблем, все данные корпуса были сохранены и доступны для анализа. И скорость обработки, при этом, практически никах не пострадала т.к. все данные уже in-memory.
Классный кейс, снимаю шляпу.
Вот только проблема использованного корпуса в том, что он неотсортирован. И без предварительной подготовки файла базы использовать его с ВПР не получиться.
То, что у меня в результате получилось и место кушает умеренно и вполне себе продакшн имхо.
Кстати "мгновенно" в вашем случае — это сколько? Меньше одной секунды? На каком железе?
В Power BI два встроенных языка, как описано в статье: M и DAX.
R c Python — это дополнительные "расширения", причём последнее пока в стадии беты. Про ошибки Python-визуализаций и способы их обхода я писал в другой своей статье: https://habr.com/post/421659/
Безусловно специализированными инструментами работать удобнее. Но в них, как правило, нет ни требуемого уровня интерактивности, ни возможности создать нужный UX, как в BI-интрументах. Эта статья как раз про это.
А с учётом интеграции Python c PBI этот вопрос для многих разработчиков может быть вообще снят с повестки дня.
Сейчас уже и не вспомню точно причину. То ли из-за потенциальных проблем с совместимостью, то ли из-за более широких возможностей визуализации.
Но скорее всего причина была в наличии в Excel движка PowerPivot и потенциальной возможности публикации на ферме SharePoint. Т.е. вполне себе прдакшн-решение.
Ну да, в Direct Query скорость визуализации определяется фактически скоростью обработки неагрегированных запросов к базе. Не «летает», конечно (и не должно), но работать вполне комфортно.
Логистику трудоустройства кандидата именно в вашей фирме я, разумеется, не принимал во внимание. Но то, что она (логистика) может меняться в соответствии с внутренним регламентом компании (кроме требования оформления ТК и собственно трудового договора) — это точно.
Просто я предложил ещё одну опцию. И, судя по другим комментам, я не одинок.
Бывает, что человек берёт на основной работе отпуск на пару дней-неделю.
Правда на позиции серьёзных специалистов я лично такого не припомню, но на позиции от джуниоров до мидлов бывало.
Как тогда без траты времени понять, что соискатель нам подходит, и соискателю подходят условия, компания и должность?
Vasek18, эта процедура давно отработана, прописана в ТК, и называется «испытательный срок».
И не надо со стороны работодателя ждать двух-трёх месяцев, чтобы сказать соискателю: «Извините, Вы нам не подходите». Три дня и — adieu.
То же справедливо и для кандидата.
Как вам такой подход?
Ну, Запад много хорошего перенял у СССР, когда была конкуренция двух систем. Сейчас конкуренции больше нет и социальные условия якобы (как говорят старожилы) становятся хуже. Ну я в 80-е жил в СССР, а не на Западе, сравнивать не могу. Но многие вещи, которые нам обещали при социализме, с удивлением обнаруживаю в Германии.
Из данного обобщения есть исключения. Но очевидно, что если мыслительные процессы у мужчин и женщин происходят по-разному (а это - медицинский факт, тут, например, интересная инфографика), то и подход к управлению проектами у разных полов - разный. Аргументация, в целом хорошо работающая для мужчин, может плохо подходить для женщин. Как и наоборот.
Женщины видят больше деталей, умеют их лучше интерпретировать, оценивать. Мужчины считают это чудом и называют интуицией.
Мужской мозг умеет отфильтровывать детали, оставляя только сами объекты, их контуры. Сэкономленные ресурсы мужской мозг может себе позволить потратить, например, на выхолащивание объектов в абстрактные модели.
Мне лично понимание этого факта в своё время сильно упростило жизнь.
По моему опыту 80 процентов тормозов любого компьютера, от ноутбука до сервера, связано с дисковой подсистемой, как самой медленной. SSD эту проблему частично решают.
В общем — «прикопали» этот лайфхак (и можно ещё гвоздиком вверх в правом углу приколотить :))
Метрика выражается целым числом и для оптимально загруженной системы рассчитывается по формуле:
Data Queue = 2 + <количество шпинделей жёстких дисков RAID-массива>.
Т.е. если глубина равна 10 или больше, а у вас, например, всего 4 диска (шпинделя) — есть повод задуматься об оптимизации, а если больше 50 — у вас проблема.
Достать показатель проще всего через оснастку монитора производительности (Performance Monitor — Физические носители — актуальная длина очереди). Через Task Manager такое не видно.
Но получилось, что замах на рубль, а удар на копейку.
Очень надеюсь, что вы всё-таки доработаете свою таблицу и исправите хотя бы фактические ошибки. Как план для быстрого отчёта по проделанной работе для начальства табличка может и годится, но вот делать на её основе адекватные выводы опасно. Это будет кошмар, если другие пользователи начнут делать свои выводы на её основе.
У Qlik (не Qlick, поправьте пожалуйста) есть несколько продуктов. Уточните плз, какой вам показывали (но очевидно, что это Sense).
С удивлением обнаруживал, что вы отняли функциональность, которая в продуктах есть, а вы её заминусовали (например, tooltips, crossjoin и группировка у Power BI, параметры запросов у Qlik). Это не полный перечень.
C учётом того, что описания некоторых «фич» я перечитывал несколько раз, но не уверен, что понял их все. Спрашивал у коллег, думал, только я не догоняю, но нет, всем отделом решали этот ребус. Попробуйте уточнить определения и, уверен, ценность статьи от этого только выиграет.
Вообще, похоже на сравнительный анализ куриц и крокодилов только на том основании, что и те и другие несут яйца. Но это, конечно, моё субъективное мнение.
Другими словами: 1000 — нормуль, 10000 — хорошо, 1 млн. — ещё лучше, 500 — скорее всего полня фигня.
И если у Вас есть релевантные ссылки по данной тематике кидайте сюда. Думаю многим будет интересно.
Безусловно никакого дополнительного смыслового анализа не проводилось. Это задача более сложных систем ИИ. А вот морфологический анализ — это без проблем, все данные корпуса были сохранены и доступны для анализа. И скорость обработки, при этом, практически никах не пострадала т.к. все данные уже in-memory.
Можете убедиться на предложенном PBIX.
Классный кейс, снимаю шляпу.
Вот только проблема использованного корпуса в том, что он неотсортирован. И без предварительной подготовки файла базы использовать его с ВПР не получиться.
То, что у меня в результате получилось и место кушает умеренно и вполне себе продакшн имхо.
Кстати "мгновенно" в вашем случае — это сколько? Меньше одной секунды? На каком железе?
В Power BI два встроенных языка, как описано в статье: M и DAX.
R c Python — это дополнительные "расширения", причём последнее пока в стадии беты. Про ошибки Python-визуализаций и способы их обхода я писал в другой своей статье:
https://habr.com/post/421659/
А с учётом интеграции Python c PBI этот вопрос для многих разработчиков может быть вообще снят с повестки дня.
Но скорее всего причина была в наличии в Excel движка PowerPivot и потенциальной возможности публикации на ферме SharePoint. Т.е. вполне себе прдакшн-решение.
Правильно я понимаю, что это был режим Direct Query?
Решалась задача нормализации словаря. Т. е. все формы слов как раз не интересовали. Это, как Вы верно поняли, была более простая задача.
Просто я предложил ещё одну опцию. И, судя по другим комментам, я не одинок.
Правда на позиции серьёзных специалистов я лично такого не припомню, но на позиции от джуниоров до мидлов бывало.
Vasek18, эта процедура давно отработана, прописана в ТК, и называется «испытательный срок».
И не надо со стороны работодателя ждать двух-трёх месяцев, чтобы сказать соискателю: «Извините, Вы нам не подходите». Три дня и — adieu.
То же справедливо и для кандидата.
Как вам такой подход?
Раньше были и на 8", но они тут по форм-фактору, скорее всего, не подойдут.