б) можно отсеять чисто физическими методами (измерение, взвешивание и проч).
Но проблема как раз любой реальной монетки заключается как раз в том, что она не абсолютно симметричная, если на ней есть выпуклый рисунок на разных сторонах. А если брать какие-нибудь старинные монеты ручной чеканки, то они даже не круглые.
Все еще хуже. Мы бросаем монетку 10 млрд раз и получаем, что количество выпавших орлов относится к количеству выпавших решек как 47 к 53. И как понять, что в этой ситуации пошло не так (выбери один или больше вариантов): а) не сработал закон больших чисел; б) монетка кривая; в) условия проведения экспериментов неодинаковы?
1) Можно в Windows выполнить FORMAT X: /p:N - пишут, каждый сектор диска X: будет обнулен, после чего перезаписан случайным числом N раз.
2) Можно загрузиться в Linux с любого Live-носителя и выполнить
dd if=/dev/random of=sdx bs= .... - можно также источником поставить /dev/zero, можно выполнить команду в скрипте N раз.
Вот во втором случае интересно, какой размер блока лучше выставлять в параметре bs? Если ставить размер небольшой, типа 512 байт, то процесс идет катастрофически медленно. А если выставить 10-20 Мб, то нет ли риска, что последний блок не будет записан? Т.е. на диске останется не прописанная dd область размером с последний блок (или меньше)?
Не очень понял, в чем ваша проблема, зачем вы это пытаетесь донести разработчикам? А). Они не выполняют обещания и срывают сроки? Б). Они выполняют обещания и не срывают сроки, но вас не устраивают их оценки? В). Вы замечали, что А и/или Б происходит по причине того, что они в рабочее время, вместо решения производственных задач, контрибьютят в опен сорс?
Если пункт В) отсутствует, то доносить надо другое.
Не стоит. Тревожному невротику даже в аналитики идти не стоит. Лучше сосредоточиться на технических скиллах, писать код, стать гуру по ряду технологий, вылечить невроз а потом думать чем заниматься дальше (по описанному плану развлечений и так хватит лет на 5-6, а то может и 10).
Ну а я видел успешное применение, где огуречными скриптами закрывалась регрессионка :) Правда, такие скрипты надо поддерживать и обновлять (а что не надо в живом ПО?), есть определенный порог вхождения. Мало кто хочет на это тратиться. Хотя автоматизация рутины лучше, чем ручной рутинный труд :)
Мне вспомнилась прошибающая до слез сцена из фильма Спилберга, где маленький робот тысячу с чем-то лет просил у пластиковой статуи: "Добрая фея, сделай меня настоящим мальчиком!"
Вы издеваетесь над бездушной машиной! Это как раз то, о чем предупреждал профессор Джозеф Вейнценбаум в 1976 году: машина сможет напечатать "я вас люблю", но никогда не поймет что такое любовь. Экзистенциальный кризис робота "Я хочу быть вам и как вам", конечно, выглядит потрясающе.
Полностью согласен с вашим рейтингом. У меня были только сомнения по поводу WPS Office, так как я вообще его не тестировал. Сам я пользуюсь Only Office по трем причинам:
а) бесплатный. вместе с Thunderbird + Яндекс 360 (там движок - какая-то его версия) = полностью заменил мне основные приложения Microsoft Office. б) ни разу не было проблем в части обмена с контрагентами (но и сложных документов не было). в) после прочтения нескольких книг по UX и дизайну не могу смотреть без боли на иконки Libre Office. Пытался себя пересилить, но пока это оказалось выше моих сил - "кто умножает познания, умножает многую скорбь" (Еккл., 1:18).
1) Опрошенные незаслуженно забыли PyTest и Cucumber. 2) TestOps - да, изменит тестирование чуть менее, чем полностью. Полагаю, это случится в ближайшие 5-6 лет. 3) Кто не успеет измениться = проиграл.
Only Office /R7 Office не рассматривали? Мне показалось что они более совместимы с MS форматом (не имел опыта эксплуатации на большом кол-ве хостов, конечно), чем Libre и выглядят привычнее...
Он хорош до тех пор, пока не начнете сталкиваться с отказами по мотивам "overqualified", эйджизмом и запросами о скидке "у вас опыт действительно большой, но к нашему проекту нерелевантный, поэтому сколько вы может уступить?".
У позиции есть зарплатная вилка, у вилки есть верхняя планка, и выше этой планки никакой горизонтальный рост компетенций прыгнуть не поможет.
Поэтому не тешьте себя иллюзиями, открывайте свой бизнес :)
Нет, в данном случае - это нормально. А вот упрощать нормы при чтении - неверная и опасная практика, которая приводит к проектированию систем - если только мы ведем их прямое нормативное проектирование - исходя из неполных и неверных моделей. Я с этим неоднократно сталкивался и тоже учился на своих ошибках.
Вы ссылаетесь на теоремы, могу предположить что базовое образование у вас - математическое. Но методы мышления, которые вырабатывает математика, к НПА нужно применять с осторожностью. Юридические определения не отвечают критериям, которые приняты у математиков, и нормы не излагаются в линейной дедуктивной последовательности, как аксиомы и определения у Евклида. Хотя формальная логика одинаковая.
Например, при внимательном прочтении ст. 15 и ст. 16 ЖК РФ, которые вас так зацепили, можно увидеть, что у этих статей вообще говоря, различные по существу цели. В ст. 15 законодатель определяет объекты жилищных прав и некоторые аспекты их жизненного цикла, а в ст. 16 - дает классификацию жилых помещений. То, что две изначально разных конструкции, пересеклись по понятиям "многоквартирный дом" и "квартира" - в данном случае скорее не порок определений, а следствие того, что квартира выступает и как частный случай объекта жилищных прав, и как частный случай жилого помещения.
А кажущаяся кольцевой ссылка между А и В выражает лишь созависимость этих понятий, т.е. квартира не может существовать иначе как в составе многоквартирного дома, и многоквартирный дом не может существовать иначе, чем как здание, состоящее из квартир и имущества, определенного корреспондирующей нормой - п. 1-3 ч. 1 ст. 36, которая также упомянута в ст 15. И вот эта корреспонденция со ст. 36 является очень существенной.
Если вы начнете выписывать структуры норм последовательно и логично, то увидите, что их понятийная схема с учетом корреспонденций значительно сложнее, чем режущая глаз созависимость А и B.
Рекомендую почитать Оробинского В.В. "Чему не учат на юрфаке" (лучше брать сразу "Чему не учат на юрфаке, расширенное и дополненное издание", там три книжки под одной обложкой), у него там были хорошие главы о стратегиях мышления, устройстве норм и их трактовании.
1) Отсутствие рефлексии относительно используемых инструментов
1,5 - 3 года - это очень малый срок, чтобы начать рефлексировать по-поводу используемых инструментов. Это всего лишь 1-3 полноценных проекта. Где можно столкнуться с REST в новой архитектуре и с SOAP немного в интеграциях какого-нибудь легаси, например. Понятно, что REST будет восприниматься как "модно, быстро, молодежно", а SOAP - нет.
2) Неумение формулировать определения
А вот это реально проблема у молодежи. Я обычно отправлял главу из "Системы Логики" Джона Стюарта Милля на почитать, когда вижу, что аналитик не умеет формулировать определения.
(Логику в среднюю школу, да и в ВУЗы по-нормальному, ясное дело, не вернут, т.к. после этого сломаются все механизмы управления государством)
3) Отсутствие мотивации к самостоятельному изучению профессии
Это последствия широко распространившегося мифа что все в IT меняется очень быстро, поэтому незачем что-то изучать глубоко. И тут есть резон, за 20 лет сменилась масса подходов.
+ очень трудно самостоятельно разобраться, что же действительно изучать. Информации так много, что выбрать ключевое крайне сложно самостоятельно.
4) Неумение смотреть на ситуацию «сверху»
Это умение появляется (либо не появляется) как раз после 3 лет практики обычно, и очень сильно зависит от этот практики, ведь на некоторых проектах можно 3 года детальные спеки на формочки писать, и ничего другого более не видеть. И это да, многолетний уже опыт. Уже не джун.
К сожалению, многие до сих пор считатают, что "аналитики - это же не джависты, три месяца поучить и будут спеки писать одна за другой". Нет. Это не так :)
5) Короткая память
К этому приводит, в том числе, постоянный поток информации, ротация проектов, задач и т.п. - пресловутые игры в "многозадачность" одновременно со "стрессоустойчивостью" и "проактивной позицией" (в результате - дефицит сна у исполнителей).
С другой стороны, зачем помнить то, что не потребуется прямо здесь и прямо сейчас?
Ну и опять же, не надо идеализировать "длинную память". Вот я помню, что примерно 20 лет назад рисовал что-то в ARIS. Но с тех пор ARIS практически вышел из употребления. Зачем мне его помнить, если заказчики хотят BPMN?
Помнить свои проекты до двух лет - это абсолютно нормально. Помнить больше - совершенно не обязательно. Какие-то воспоминания могут быть даже и вредны.
6) Не подтверждаются "ключевые навыки", заявленные в резюме
Это печально. 7)Отсутствие понимания что такое «анализ»
Дефекты нашего образования. И отсутствия самообразования.
8) Отсутствие реакции на обратную связь от собеседника
И это тоже печально.
9) Нет планирования своего профессионального развития
Ну тут несколько проблем. С одной стороны, если кандидат не отличает анализ от синтеза и требование от стейкхолдера, но о планировании развития ему говорить рано. С другой стороны, а куда аналитику развиваться? Джун, мидл, старший, ведущий и ... ведущий до пенсии? ) "Мы предлагаем вам стабильный оклад и возможности горизонтального роста компетенций в проектах связанных с автоматизацией документооборота в государственном секторе", угу, отличная перспектива развития )))
Не знаю, кто покупает Oracle в России сейчас, если со 2-го марта 2022 года Oracle прекратил все операции в России.
Но раньше ходили слухи, что Oracle активно покупают за откаты. Правда, я в закупках и продажах Oracle не участвовал, поэтому достоверными фактами, подтверждающими такие слухи, не располагаю.
Нет смысла вести дискуссию исходя их искаженных определений (а топикстартер их исказил, процитировав частично).
Читаем, как на самом деле написано в ЖК РФ:
ЖК РФ Статья 16. Виды жилых помещений
1. К жилым помещениям относятся: 1) жилой дом, часть жилого дома; 2) квартира, часть квартиры; 3) комната.
2. Жилым домом признается индивидуально-определенное здание, которое состоит из комнат, а также помещений вспомогательного использования, предназначенных для удовлетворения гражданами бытовых и иных нужд, связанных с их проживанием в таком здании.
- здесь есть комнаты, нет квартир.
3. Квартирой признается структурно обособленное помещение в многоквартирном доме, обеспечивающее возможность прямого доступа к помещениям общего пользования в таком доме и состоящее из одной или нескольких комнат, а также помещений вспомогательного использования, предназначенных для удовлетворения гражданами бытовых и иных нужд, связанных с их проживанием в таком обособленном помещении.
то есть квартира а) это структурно обособленное помещение б) имеет прямой доступ к помещениям общего пользования (т. е. если есть комната + санузел + кухня, но все это выходит в другую комнату, а не на лестничную клетку или общий коридор - это не квартиране может квартира иметь выход в другую квартиру) в) состоит не только из комнат(ы), но еще из вспомогательных помещений.
4. Комнатой признается часть жилого дома или квартиры, предназначенная для использования в качестве места непосредственного проживания граждан в жилом доме или квартире.
Таким образом, насчет пятистенка - ответ зависит от проекта, смотря какой пятистенок. Но если выход на улицу один - то речь о квартирах идти не может, только о комнатах/вспомогательных помещениях.
Кстати, квартиры в старых советских деревенских дома "на 2 семьи" не вполне удовлетворяют определению квартиры по ЖК РФ, т.к. выходы у них не в помещение общего пользования, а на улицу. Ну и нумерация часто бывает вида дом №50а и №50б, а не д. №50 кв 1 и д. №50кв 2. С другой стороны, д. №50а и д. №50б тоже сомнительно выглядит, т.к. жилой дом - это "индивидуально-определенное здание" (надо разбираться, что это значит точно).
А кортежи, списки, словари - все то, что так упрощает работу в Python и ООП (классы etc.) в нем есть?
Ну а мог бы выйти из IT, открыть свой банк и стать миллиардером.
Была бы история успеха.
Спасибо.
б) можно отсеять чисто физическими методами (измерение, взвешивание и проч).
Но проблема как раз любой реальной монетки заключается как раз в том, что она не абсолютно симметричная, если на ней есть выпуклый рисунок на разных сторонах. А если брать какие-нибудь старинные монеты ручной чеканки, то они даже не круглые.
Все еще хуже. Мы бросаем монетку 10 млрд раз и получаем, что количество выпавших орлов относится к количеству выпавших решек как 47 к 53. И как понять, что в этой ситуации пошло не так (выбери один или больше вариантов):
а) не сработал закон больших чисел;
б) монетка кривая;
в) условия проведения экспериментов неодинаковы?
Вроде бы,
1) Можно в Windows выполнить FORMAT X: /p:N - пишут, каждый сектор диска X: будет обнулен, после чего перезаписан случайным числом N раз.
2) Можно загрузиться в Linux с любого Live-носителя и выполнить
dd if=/dev/random of=sdx bs= .... - можно также источником поставить /dev/zero, можно выполнить команду в скрипте N раз.
Вот во втором случае интересно, какой размер блока лучше выставлять в параметре bs? Если ставить размер небольшой, типа 512 байт, то процесс идет катастрофически медленно. А если выставить 10-20 Мб, то нет ли риска, что последний блок не будет записан? Т.е. на диске останется не прописанная dd область размером с последний блок (или меньше)?
Не очень понял, в чем ваша проблема, зачем вы это пытаетесь донести разработчикам?
А). Они не выполняют обещания и срывают сроки?
Б). Они выполняют обещания и не срывают сроки, но вас не устраивают их оценки?
В). Вы замечали, что А и/или Б происходит по причине того, что они в рабочее время, вместо решения производственных задач, контрибьютят в опен сорс?
Если пункт В) отсутствует, то доносить надо другое.
Не стоит. Тревожному невротику даже в аналитики идти не стоит. Лучше сосредоточиться на технических скиллах, писать код, стать гуру по ряду технологий, вылечить невроз а потом думать чем заниматься дальше (по описанному плану развлечений и так хватит лет на 5-6, а то может и 10).
Ну а я видел успешное применение, где огуречными скриптами закрывалась регрессионка :) Правда, такие скрипты надо поддерживать и обновлять (а что не надо в живом ПО?), есть определенный порог вхождения. Мало кто хочет на это тратиться. Хотя автоматизация рутины лучше, чем ручной рутинный труд :)
Мне вспомнилась прошибающая до слез сцена из фильма Спилберга, где маленький робот тысячу с чем-то лет просил у пластиковой статуи: "Добрая фея, сделай меня настоящим мальчиком!"
Вы издеваетесь над бездушной машиной! Это как раз то, о чем предупреждал профессор Джозеф Вейнценбаум в 1976 году: машина сможет напечатать "я вас люблю", но никогда не поймет что такое любовь. Экзистенциальный кризис робота "Я хочу быть вам и как вам", конечно, выглядит потрясающе.
Полностью согласен с вашим рейтингом. У меня были только сомнения по поводу WPS Office, так как я вообще его не тестировал. Сам я пользуюсь Only Office по трем причинам:
а) бесплатный. вместе с Thunderbird + Яндекс 360 (там движок - какая-то его версия) = полностью заменил мне основные приложения Microsoft Office.
б) ни разу не было проблем в части обмена с контрагентами (но и сложных документов не было).
в) после прочтения нескольких книг по UX и дизайну не могу смотреть без боли на иконки Libre Office. Пытался себя пересилить, но пока это оказалось выше моих сил - "кто умножает познания, умножает многую скорбь" (Еккл., 1:18).
1) Опрошенные незаслуженно забыли PyTest и Cucumber.
2) TestOps - да, изменит тестирование чуть менее, чем полностью. Полагаю, это случится в ближайшие 5-6 лет.
3) Кто не успеет измениться = проиграл.
Only Office /R7 Office не рассматривали? Мне показалось что они более совместимы с MS форматом (не имел опыта эксплуатации на большом кол-ве хостов, конечно), чем Libre и выглядят привычнее...
Наверное, нет. Ведь если отключить телеметрию, то как таргетированную рекламу в Skype показывать? Ну и прочее все)
Поддерживаю
Он хорош до тех пор, пока не начнете сталкиваться с отказами по мотивам "overqualified", эйджизмом и запросами о скидке "у вас опыт действительно большой, но к нашему проекту нерелевантный, поэтому сколько вы может уступить?".
У позиции есть зарплатная вилка, у вилки есть верхняя планка, и выше этой планки никакой горизонтальный рост компетенций прыгнуть не поможет.
Поэтому не тешьте себя иллюзиями, открывайте свой бизнес :)
Нет, в данном случае - это нормально. А вот упрощать нормы при чтении - неверная и опасная практика, которая приводит к проектированию систем - если только мы ведем их прямое нормативное проектирование - исходя из неполных и неверных моделей. Я с этим неоднократно сталкивался и тоже учился на своих ошибках.
Вы ссылаетесь на теоремы, могу предположить что базовое образование у вас - математическое. Но методы мышления, которые вырабатывает математика, к НПА нужно применять с осторожностью. Юридические определения не отвечают критериям, которые приняты у математиков, и нормы не излагаются в линейной дедуктивной последовательности, как аксиомы и определения у Евклида. Хотя формальная логика одинаковая.
Например, при внимательном прочтении ст. 15 и ст. 16 ЖК РФ, которые вас так зацепили, можно увидеть, что у этих статей вообще говоря, различные по существу цели. В ст. 15 законодатель определяет объекты жилищных прав и некоторые аспекты их жизненного цикла, а в ст. 16 - дает классификацию жилых помещений. То, что две изначально разных конструкции, пересеклись по понятиям "многоквартирный дом" и "квартира" - в данном случае скорее не порок определений, а следствие того, что квартира выступает и как частный случай объекта жилищных прав, и как частный случай жилого помещения.
А кажущаяся кольцевой ссылка между А и В выражает лишь созависимость этих понятий, т.е. квартира не может существовать иначе как в составе многоквартирного дома, и многоквартирный дом не может существовать иначе, чем как здание, состоящее из квартир и имущества, определенного корреспондирующей нормой - п. 1-3 ч. 1 ст. 36, которая также упомянута в ст 15. И вот эта корреспонденция со ст. 36 является очень существенной.
Если вы начнете выписывать структуры норм последовательно и логично, то увидите, что их понятийная схема с учетом корреспонденций значительно сложнее, чем режущая глаз созависимость А и B.
Рекомендую почитать Оробинского В.В. "Чему не учат на юрфаке" (лучше брать сразу "Чему не учат на юрфаке, расширенное и дополненное издание", там три книжки под одной обложкой), у него там были хорошие главы о стратегиях мышления, устройстве норм и их трактовании.
1) Отсутствие рефлексии относительно используемых инструментов
1,5 - 3 года - это очень малый срок, чтобы начать рефлексировать по-поводу используемых инструментов. Это всего лишь 1-3 полноценных проекта. Где можно столкнуться с REST в новой архитектуре и с SOAP немного в интеграциях какого-нибудь легаси, например. Понятно, что REST будет восприниматься как "модно, быстро, молодежно", а SOAP - нет.
2) Неумение формулировать определения
А вот это реально проблема у молодежи. Я обычно отправлял главу из "Системы Логики" Джона Стюарта Милля на почитать, когда вижу, что аналитик не умеет формулировать определения.
(Логику в среднюю школу, да и в ВУЗы по-нормальному, ясное дело, не вернут, т.к. после этого сломаются все механизмы управления государством)
3) Отсутствие мотивации к самостоятельному изучению профессии
Это последствия широко распространившегося мифа что все в IT меняется очень быстро, поэтому незачем что-то изучать глубоко. И тут есть резон, за 20 лет сменилась масса подходов.
+ очень трудно самостоятельно разобраться, что же действительно изучать. Информации так много, что выбрать ключевое крайне сложно самостоятельно.
4) Неумение смотреть на ситуацию «сверху»
Это умение появляется (либо не появляется) как раз после 3 лет практики обычно, и очень сильно зависит от этот практики, ведь на некоторых проектах можно 3 года детальные спеки на формочки писать, и ничего другого более не видеть. И это да, многолетний уже опыт. Уже не джун.
К сожалению, многие до сих пор считатают, что "аналитики - это же не джависты, три месяца поучить и будут спеки писать одна за другой". Нет. Это не так :)
5) Короткая память
К этому приводит, в том числе, постоянный поток информации, ротация проектов, задач и т.п. - пресловутые игры в "многозадачность" одновременно со "стрессоустойчивостью" и "проактивной позицией" (в результате - дефицит сна у исполнителей).
С другой стороны, зачем помнить то, что не потребуется прямо здесь и прямо сейчас?
Ну и опять же, не надо идеализировать "длинную память". Вот я помню, что примерно 20 лет назад рисовал что-то в ARIS. Но с тех пор ARIS практически вышел из употребления. Зачем мне его помнить, если заказчики хотят BPMN?
Помнить свои проекты до двух лет - это абсолютно нормально. Помнить больше - совершенно не обязательно. Какие-то воспоминания могут быть даже и вредны.
6) Не подтверждаются "ключевые навыки", заявленные в резюме
Это печально.
7) Отсутствие понимания что такое «анализ»
Дефекты нашего образования. И отсутствия самообразования.
8) Отсутствие реакции на обратную связь от собеседника
И это тоже печально.
9) Нет планирования своего профессионального развития
Ну тут несколько проблем. С одной стороны, если кандидат не отличает анализ от синтеза и требование от стейкхолдера, но о планировании развития ему говорить рано. С другой стороны, а куда аналитику развиваться? Джун, мидл, старший, ведущий и ... ведущий до пенсии? ) "Мы предлагаем вам стабильный оклад и возможности горизонтального роста компетенций в проектах связанных с автоматизацией документооборота в государственном секторе", угу, отличная перспектива развития )))
А если такой ответ? ))))
Не знаю, кто покупает Oracle в России сейчас, если со 2-го марта 2022 года Oracle прекратил все операции в России.
Но раньше ходили слухи, что Oracle активно покупают за откаты. Правда, я в закупках и продажах Oracle не участвовал, поэтому достоверными фактами, подтверждающими такие слухи, не располагаю.
Нет смысла вести дискуссию исходя их искаженных определений (а топикстартер их исказил, процитировав частично).
Читаем, как на самом деле написано в ЖК РФ:
ЖК РФ Статья 16. Виды жилых помещений
1. К жилым помещениям относятся:
1) жилой дом, часть жилого дома;
2) квартира, часть квартиры;
3) комната.
2. Жилым домом признается индивидуально-определенное здание, которое состоит из комнат, а также помещений вспомогательного использования, предназначенных для удовлетворения гражданами бытовых и иных нужд, связанных с их проживанием в таком здании.
- здесь есть комнаты, нет квартир.
3. Квартирой признается структурно обособленное помещение в многоквартирном доме, обеспечивающее возможность прямого доступа к помещениям общего пользования в таком доме и состоящее из одной или нескольких комнат, а также помещений вспомогательного использования, предназначенных для удовлетворения гражданами бытовых и иных нужд, связанных с их проживанием в таком обособленном помещении.
то есть квартира
а) это структурно обособленное помещение
б) имеет прямой доступ к помещениям общего пользования (т. е. если есть комната + санузел + кухня, но все это выходит в другую комнату, а не на лестничную клетку или общий коридор - это не квартиране может квартира иметь выход в другую квартиру)
в) состоит не только из комнат(ы), но еще из вспомогательных помещений.
4. Комнатой признается часть жилого дома или квартиры, предназначенная для использования в качестве места непосредственного проживания граждан в жилом доме или квартире.
Таким образом, насчет пятистенка - ответ зависит от проекта, смотря какой пятистенок. Но если выход на улицу один - то речь о квартирах идти не может, только о комнатах/вспомогательных помещениях.
Кстати, квартиры в старых советских деревенских дома "на 2 семьи" не вполне удовлетворяют определению квартиры по ЖК РФ, т.к. выходы у них не в помещение общего пользования, а на улицу. Ну и нумерация часто бывает вида дом №50а и №50б, а не д. №50 кв 1 и д. №50кв 2. С другой стороны, д. №50а и д. №50б тоже сомнительно выглядит, т.к. жилой дом - это "индивидуально-определенное здание" (надо разбираться, что это значит точно).