Вы неправы с проведённой оценкой. Она вмеру объективна, но полностью бесполезна.
Если Вас полностью устраивает нетбук за 12 тыр (или ещё чего такого), то не факт, что Вы найдёте похожий на него мак. Эппл делает весьма узкую линейку техники, причём скорее топового сегмента. И в своём классе маки весьма неплохи. По некоторым качествам даже уникальны. Например, чтобы не быть голословным, только на маках Вы сможете получить одновременно хорошо упакованный юникс и Фотошоп (и некоторый другой проприетарный софт). Широко известны общественности непревзойдённые тачпады макбуков. Но опять же повторюсь, что линейка их техники довольно узка, на мой взгляд она стала менее интересна, чем при Джобсе, и найти полноценный аналог для любого другого устройства на рынке вряд ли выйдет.
Впрочем, это верно и в обратную сторону: найти полноценный аналог какому-нибудь макбуку про, например, с Touch Bar-ом будет столь же нелегко, как и глупо. Найденный аналог будет отнюдь не дешевле, проиграет сравнение по каким-нибдуь второстепенным признакам, и сольётся полностью при сравнении интеграции ОС с железом (где у Эппла традиционно всё хорошо).
Так что не сравнивайте несравнимое и тогда Ваши действия не будут подвергаться остракизму. (:
Вот-вот. Мне как раз и кажется, что у большей части комментаторов нет перед глазами или в памяти примеров хорошего менеджемента. Отсюда и попытки нафантазировать, что мне бы, мол, как программисту, наверняка было бы легче взаимодействовать с менеджером, который умеет программировать. А вот встретив хорошего менеждера, человек невольно задаётся вопросом, почему же он так хорош и чем именно это определяется. И оказывается внезапно, что отнюдь не знаниями в программировании.
Что-то у меня чешутся руки написать, что если менеджер должен уметь программировать, то наверное и программист должен уметь менеджерить. Как-то набрать и организовать команду, придумать продукт, продать его заказчику, согласовать план работ, получить оплату, свести бюджеты, следить за рисками, замотивировать всех вокруг. Для симметрии вроде как просится…
(Тут должны быть смайлики, а то без них в интернете шутки уже давно не понимают)
Мне кажется, вы — плохой менеджер, который ставит блокирующие таски, а впоследствии ищет виноватого
Не вижу из чего Вы делаете такие далеко идущие и столь категоричные выводы, да ещё и в форме персонального обвинения. Как бы намекаю, что наезд был мимо тазика. И Вы явно путаете карьеру и карьеризм.
Дальше уже не лично Вам, так что «вы» будет уже обезличенным, и по правилам русского языка будет писаться с маленькой буквы. Поясню свою мысль, так как вижу, что нашёлся кто-то, кто коммент staticY выше плюсанул.
В специальности ИТ так же хорошо, как и в других сферах бизнеса, замечательно работает правило «спасение утопающих — дело рук самих утопающих». Если менеджер на вашем проекте — чудак на букву «м», то не стесняйтесь работать за него. Если за счёт этого вытянете проект, то в компании это должны оценить. Это шанс стать более полезным для компании, то есть для карьерного роста. Это хорошее основание поднять должность и/или зарплату. А если не оценят, то поменяете работу и с имеющимся опытом будете претендовать опять же на более высокую должность и зарплату.
А если менеджер адекватный, но просто не успевает или что-то упускает по каким-либо другим причинам (см. в статье развесистый список того, что делает хороший менеджер), то тоже будет только польза по тем же самым причинам. Это шанс для вашего карьерного роста. И я не зню ни одной причины не помогать менеджеру, если такая возможность представилась.
Выводы не бог весть какой глубины, но почему-то молодёжь к ним приходит очень долго, считая, что лишь углубленное изучение фреймворков (читай: технической части) открывает пути карьеры. А работодатель платит деньги не за знание фреймворков, а за решение конкретных задач бизнеса. И не каких-то там «тасков», а скорее проектов, если оставаться в ИТшной терминологии. Фреймворки же могут пригодиться решать поставленные задачи быстрее или лучше, а могут и не пригодиться…
Замечательно написано о том, что действительно делает из человека в менеджерской должности настоящим менеджером. Браво. Снимаю шляпку перед теми трудностями, которые пришлось пройти, чтобы всё это осознать.
Хотелось бы дополнить парой комментариев для подчинённых: если видите, что руководитель не успевает сделать что-то из вышеперечисленного, не стесняйтесь сделать это за него. Не надо сидеть ровно и тем более ныть, что меня, мол, недостаточно замотивировали, или ТЗ не совсем понятное, или ещё чего-там-ещё-кто-не-организовал. Это надо вам самим. Менеджерская работа по-хорошему дожна быть сделана, и не обязательно самим менеджером. Она вернётся сторицей в виде хорошо выполненного проекта или слаженностью команды. А систематическая помощь менеджеру со стороны подчинённого рано или поздно возвращается ростом зарплаты и/или карьерным ростом. Потому что сотрудник, который самоорганизуется в работе, куда как ценнее для работодателя, чем тот, с которым надо няньчиться.
Странно. Для меня менеджер — это человек, который организует работу. Зачем тут нужно два иностранных языка? Вот уметь говорить с подчинёнными на понятном им языек — это да, это важно. Но это скорее всего будет не один-два и не факт, что иностранных…
PS Что-то похоже Вам хороших менеджеров пока не попадалось.
В девятой считаем количество комбинаций совпадающих сумм первой пары и второй пары.
Вот так оно выглядит «в лоб» и «оптимизированно»:
Код
create table abacus as
(select level as n from dual connect by level < 10);
select count(1)
from abacus a, abacus b, abacus c, abacus d
where a.n+b.n = c.n+d.n;
>>> 489
select sum(x*x)
from (select count(*) x
from abacus t1
, abacus t2
group by t1.n + t2.n);
>>> 489
Вроде сходится.
Для восьмой задачи достаточно посчитать таблицу с промежуточными результатами сумм и произведений, а потом по ней уже посчитать сколько раз встречается одинаковое там и там:
Осторожно, решение восьмой задачи
create table abacus_pairs as (
select t1.n + t2.n s
, t1.n * t2.n m
from abacus t1
, abacus t2;
select count(*)
from abacus_pairs a
, abacus_pairs b
where a.s = b.m;
Выше я слегка наврал, всего 1000 записей была в таблице abacus для восьмой задачи.
О, наконец-то появилось что-то интересное в комментариях.
Да, в восьмой задаче в таблице было 10000 записей. Подсчёт «в лоб» слишком долгий. А предварительный расчёт сумм и произведений пар (или WITH, или временной таблицей) даёт приемлемый результат. Догадаться до такой оптимизации не так уж сложно, но нужно догадаться, что оптимизация вообще нужна. Скажем, для студентов это совсем нетривиально. Опять же блиц и стресс.
Но в девятой задаче это уже не проходит и там уже нужна хорошая алгоритмическая оптимизация. Вот предложенный Вами метод действительно работает! У нас было 5000 записей в таблице. Вот наше решение:
Осторожно, решение задачи!
select sum(x*x)
from (select count(*) x
from vpoupkine.abacus t1
, vpoupkine.abacus t2
group by t1.n + t2.n)
Надо было из бэкапа восстанавливаться, это работает и надёжно. И бэкап в такой ситуации точно не помешает.
Мне по-прежнему все эти жалобы на эппл кажутся какими-то придирками, извините, ничего личного. Как-то так:
Google search: миграция данных windows проблема
About 6,320,000 results (0.79 seconds)
Google search: миграция данных mac проблема
About 172,000 results (0.53 seconds)
И это с учётом, что капризные маководы под переносом ожидают на новом маке все программы с настройками, пароли и прочие плюшки, а не только свои файлы данных. А что там переносят виндоводы, которые будут минимум будут ставить и настраивать весь софт, я вообще не понимаю. Всегда на отдельный том свои файлики собирал…
Забэкапить пользовательские данные через VSS тоже не является проблемой
Теоретически да, а на практике почему-то нет. У меня есть домашний мак и рабочая винда с настроенными штатными бэкапами. И с маком всегда всё хорошо, а у винды постоянно что-то случается. И не надо думать, что я как-то криворук к винде, я заинтересованное лицо в том, чтобы все мои бэкапы работали как часы, чего и добивался. В результате преходится винду время от времени чуть ли не вручную бэкапить, чтобы точно копия была. Бекап-сервер — мелкая каропка с дисками на платформе ARM с линуксом внутри.
Собственно ценность моих коментариев в том и только в том, что будучи знаком и с маком и с виндой не понаслышке, я утверждаю, что ТМ — классная вещь, в винде такого сильно не хватает.
И, да, ТМ — действительно скорее для пользовательских данных. Но если с операционкой вдруг что-то случится, то её не составляет труда поставить заново и восстановить все пользовательские данные и все программы из бэкапа ТМ. То есть после восстановления прдолжите работу с того же места, на котором был сделан бэкап. И макОС сам не ломается, это же юникс.
Я вот не понимаю, за что огульно мак обвиняют? В потрохах это очень неплохо укомплектованный прямо из коробки юникс. Открываешь консоль и почти всё необходимое имеется под руками. Все работающие процессы можно смотреть штатными способами. Работает man. Поведение, описанное в статье, присутствует в документации. Чего тут неявного-то? Лично из Эппла должны были позвонить и предупредить? Где в статье про неявное поведение? Неожиданное для ТС — да.
Так что повторю ещё раз: <sarcasm> вы на венду посмотрите, что там творится, это вообще тихий ужас. Положение спасает только тотальная техническая безграмотность пользователей. </sarcasm>
И, на всякий случай для совсем непонятливых: я не скрытые действия софта, я Time Machine защищаю, так как считаю, что это одна из лучших реализаций бытового резервного копирования.
Судя по повествованию и комментам, эти люди кажись венды не видели. А то молились бы на TM. Всё познаётся в сравнении.
Я вот считаю, что TM — одно из неоспоримых преимуществ мака, когда за пару кликов можно настроить резервное копирование для дома, для семьи. Без заморочек, технически красиво реализованное и просто работающее. А вот попытки делать дома бэкапы венды — это всегда приключение, то не завелось, то не сработало, то завелось и отработало, только файлы не достать.
Ну нет, не годится. Даже мне, человеку довольно далёкому от оптимизации, ясно, что время работы будет зависеть много от чего, включая заполненность кэшей базы и особенности физического распределения данных по дискам (читай: от погоды на луне). То есть объективно сравнить два решения будет совершенно невозможно. Обычно оптимизацию хоть как-то меряют по количеству логических чтений. Это раз. А во-вторых, с точки зрения олимпиады, это уже не задача на SQL получается, а оптимизация работы некоей IT-системы.
Плюс, вопросы оптимизации они такие, мягко говоря не совсем простые по критериям. Обычно оптимизация ведётся до приемлемого уровня, планка которого для каждого конкретного случая выставляется в определённую конкретную величину, которую можно померять.
Потому что любое улучшение производительности не даётся просто так. После исправления первых глупостей, где банально неправильно похватывается план исполнения, дальше приходится за любое улучшение скорости платить, и платить немало. Это статистика для оптимизатора, дополнительные индексы, промежуточное хранение или денормализация данных, изменение алгоритмов обработки и т.п. И чем дальше, тем больше приходится изголяться. Вплоть до признания, что такое-то значение за такое-то время из базы получить невозможно, давайте выбирать что-то другое, что можно получить, то есть изменение постановки задачи. Поэтому остановиться надо сразу, как только приемлемый уровень производительности достигнут.
Вобщем тема оптимизации несомненно интересна и очень востребована, но олимпиада была по SQL. Как в SQL дать задачу на производительность мы придумали, см. задачи 8 и 9 финала. А аналитические хранилищи оптимизировать, это наверное не на олимпиаде, а на производстве с 09 до 18.
Парсер — это в калькуляторе? Специально так подбирали условие, чтобы от парсера там был один подзапрос с регулярным выражением. Не думаю, что это было проблемой хоть для кого-то, кто взялся за решение задачи.
А вот как Вы себе представляете задачу по ускорению аналитического запроса? Я без всяких шуток интересуюсь. Просто для меня миграция данных — это как взял лопату и «бери больше, кидай дальше», никаких сложностей сплошная рутина. Что тут оценивать-то?
Специфика есть, но она не особо существенная. Например, используются словарные объекты оракловой базы для получения информации типа DBA_TABLES, DBA_TAB_COLUMNS, DBA_DEPENDENCIES. В PostgreSQL должны быть свои аналогичные словарные таблицы. Оптимизация в оракловой базе явно отличается от других. И так далее. Но на другую базу переносимо. Другой вопрос в том, нужно ли это переносить на другую базу.
Анонсировать не могу. Сегодня мне уже на пальцах показали, что с таким только в корпоративных блогах можно, чуть учётку не заблокировали. Но Вы сами почитайте про олимпиаду. В этом году кто-то другой SQL готовит, но я вижу, что даже мою текстовку с правилами не поменяли, только даты другие.
Если Вас полностью устраивает нетбук за 12 тыр (или ещё чего такого), то не факт, что Вы найдёте похожий на него мак. Эппл делает весьма узкую линейку техники, причём скорее топового сегмента. И в своём классе маки весьма неплохи. По некоторым качествам даже уникальны. Например, чтобы не быть голословным, только на маках Вы сможете получить одновременно хорошо упакованный юникс и Фотошоп (и некоторый другой проприетарный софт). Широко известны общественности непревзойдённые тачпады макбуков. Но опять же повторюсь, что линейка их техники довольно узка, на мой взгляд она стала менее интересна, чем при Джобсе, и найти полноценный аналог для любого другого устройства на рынке вряд ли выйдет.
Впрочем, это верно и в обратную сторону: найти полноценный аналог какому-нибудь макбуку про, например, с Touch Bar-ом будет столь же нелегко, как и глупо. Найденный аналог будет отнюдь не дешевле, проиграет сравнение по каким-нибдуь второстепенным признакам, и сольётся полностью при сравнении интеграции ОС с железом (где у Эппла традиционно всё хорошо).
Так что не сравнивайте несравнимое и тогда Ваши действия не будут подвергаться остракизму. (:
(Тут должны быть смайлики, а то без них в интернете шутки уже давно не понимают)
Значит мой совет был не для Вас, и его можно было просто проигнорировать.
Искренне рад, что Вы нашли полностью устраивающий Вас путь своего развития. Держите нас в курсе (:
Не вижу из чего Вы делаете такие далеко идущие и столь категоричные выводы, да ещё и в форме персонального обвинения. Как бы намекаю, что наезд был мимо тазика. И Вы явно путаете карьеру и карьеризм.
Дальше уже не лично Вам, так что «вы» будет уже обезличенным, и по правилам русского языка будет писаться с маленькой буквы. Поясню свою мысль, так как вижу, что нашёлся кто-то, кто коммент staticY выше плюсанул.
В специальности ИТ так же хорошо, как и в других сферах бизнеса, замечательно работает правило «спасение утопающих — дело рук самих утопающих». Если менеджер на вашем проекте — чудак на букву «м», то не стесняйтесь работать за него. Если за счёт этого вытянете проект, то в компании это должны оценить. Это шанс стать более полезным для компании, то есть для карьерного роста. Это хорошее основание поднять должность и/или зарплату. А если не оценят, то поменяете работу и с имеющимся опытом будете претендовать опять же на более высокую должность и зарплату.
А если менеджер адекватный, но просто не успевает или что-то упускает по каким-либо другим причинам (см. в статье развесистый список того, что делает хороший менеджер), то тоже будет только польза по тем же самым причинам. Это шанс для вашего карьерного роста. И я не зню ни одной причины не помогать менеджеру, если такая возможность представилась.
Выводы не бог весть какой глубины, но почему-то молодёжь к ним приходит очень долго, считая, что лишь углубленное изучение фреймворков (читай: технической части) открывает пути карьеры. А работодатель платит деньги не за знание фреймворков, а за решение конкретных задач бизнеса. И не каких-то там «тасков», а скорее проектов, если оставаться в ИТшной терминологии. Фреймворки же могут пригодиться решать поставленные задачи быстрее или лучше, а могут и не пригодиться…
Хотелось бы дополнить парой комментариев для подчинённых: если видите, что руководитель не успевает сделать что-то из вышеперечисленного, не стесняйтесь сделать это за него. Не надо сидеть ровно и тем более ныть, что меня, мол, недостаточно замотивировали, или ТЗ не совсем понятное, или ещё чего-там-ещё-кто-не-организовал. Это надо вам самим. Менеджерская работа по-хорошему дожна быть сделана, и не обязательно самим менеджером. Она вернётся сторицей в виде хорошо выполненного проекта или слаженностью команды. А систематическая помощь менеджеру со стороны подчинённого рано или поздно возвращается ростом зарплаты и/или карьерным ростом. Потому что сотрудник, который самоорганизуется в работе, куда как ценнее для работодателя, чем тот, с которым надо няньчиться.
PS Что-то похоже Вам хороших менеджеров пока не попадалось.
Вот так оно выглядит «в лоб» и «оптимизированно»:
Вроде сходится.
Для восьмой задачи достаточно посчитать таблицу с промежуточными результатами сумм и произведений, а потом по ней уже посчитать сколько раз встречается одинаковое там и там:
Выше я слегка наврал, всего 1000 записей была в таблице abacus для восьмой задачи.
Да, в восьмой задаче в таблице было 10000 записей. Подсчёт «в лоб» слишком долгий. А предварительный расчёт сумм и произведений пар (или WITH, или временной таблицей) даёт приемлемый результат. Догадаться до такой оптимизации не так уж сложно, но нужно догадаться, что оптимизация вообще нужна. Скажем, для студентов это совсем нетривиально. Опять же блиц и стресс.
Но в девятой задаче это уже не проходит и там уже нужна хорошая алгоритмическая оптимизация. Вот предложенный Вами метод действительно работает! У нас было 5000 записей в таблице. Вот наше решение:
Мне по-прежнему все эти жалобы на эппл кажутся какими-то придирками, извините, ничего личного. Как-то так:
Google search: миграция данных windows проблема
About 6,320,000 results (0.79 seconds)
Google search: миграция данных mac проблема
About 172,000 results (0.53 seconds)
И это с учётом, что капризные маководы под переносом ожидают на новом маке все программы с настройками, пароли и прочие плюшки, а не только свои файлы данных. А что там переносят виндоводы, которые будут минимум будут ставить и настраивать весь софт, я вообще не понимаю. Всегда на отдельный том свои файлики собирал…
Теоретически да, а на практике почему-то нет. У меня есть домашний мак и рабочая винда с настроенными штатными бэкапами. И с маком всегда всё хорошо, а у винды постоянно что-то случается. И не надо думать, что я как-то криворук к винде, я заинтересованное лицо в том, чтобы все мои бэкапы работали как часы, чего и добивался. В результате преходится винду время от времени чуть ли не вручную бэкапить, чтобы точно копия была. Бекап-сервер — мелкая каропка с дисками на платформе ARM с линуксом внутри.
Собственно ценность моих коментариев в том и только в том, что будучи знаком и с маком и с виндой не понаслышке, я утверждаю, что ТМ — классная вещь, в винде такого сильно не хватает.
И, да, ТМ — действительно скорее для пользовательских данных. Но если с операционкой вдруг что-то случится, то её не составляет труда поставить заново и восстановить все пользовательские данные и все программы из бэкапа ТМ. То есть после восстановления прдолжите работу с того же места, на котором был сделан бэкап. И макОС сам не ломается, это же юникс.
Я вот не понимаю, за что огульно мак обвиняют? В потрохах это очень неплохо укомплектованный прямо из коробки юникс. Открываешь консоль и почти всё необходимое имеется под руками. Все работающие процессы можно смотреть штатными способами. Работает man. Поведение, описанное в статье, присутствует в документации. Чего тут неявного-то? Лично из Эппла должны были позвонить и предупредить? Где в статье про неявное поведение? Неожиданное для ТС — да.
Так что повторю ещё раз: <sarcasm> вы на венду посмотрите, что там творится, это вообще тихий ужас. Положение спасает только тотальная техническая безграмотность пользователей. </sarcasm>
И, на всякий случай для совсем непонятливых: я не скрытые действия софта, я Time Machine защищаю, так как считаю, что это одна из лучших реализаций бытового резервного копирования.
Я вот считаю, что TM — одно из неоспоримых преимуществ мака, когда за пару кликов можно настроить резервное копирование для дома, для семьи. Без заморочек, технически красиво реализованное и просто работающее. А вот попытки делать дома бэкапы венды — это всегда приключение, то не завелось, то не сработало, то завелось и отработало, только файлы не достать.
Плюс, вопросы оптимизации они такие, мягко говоря не совсем простые по критериям. Обычно оптимизация ведётся до приемлемого уровня, планка которого для каждого конкретного случая выставляется в определённую конкретную величину, которую можно померять.
Потому что любое улучшение производительности не даётся просто так. После исправления первых глупостей, где банально неправильно похватывается план исполнения, дальше приходится за любое улучшение скорости платить, и платить немало. Это статистика для оптимизатора, дополнительные индексы, промежуточное хранение или денормализация данных, изменение алгоритмов обработки и т.п. И чем дальше, тем больше приходится изголяться. Вплоть до признания, что такое-то значение за такое-то время из базы получить невозможно, давайте выбирать что-то другое, что можно получить, то есть изменение постановки задачи. Поэтому остановиться надо сразу, как только приемлемый уровень производительности достигнут.
Вобщем тема оптимизации несомненно интересна и очень востребована, но олимпиада была по SQL. Как в SQL дать задачу на производительность мы придумали, см. задачи 8 и 9 финала. А аналитические хранилищи оптимизировать, это наверное не на олимпиаде, а на производстве с 09 до 18.
А вот как Вы себе представляете задачу по ускорению аналитического запроса? Я без всяких шуток интересуюсь. Просто для меня миграция данных — это как взял лопату и «бери больше, кидай дальше», никаких сложностей сплошная рутина. Что тут оценивать-то?