А по мне так норм, начинать с консоли. Это сразу и тесты на минималках, при этом с возможностью проверять любые тесткейзы. И мотивирует сильнее, тк сразу видно, как система функциональностью обрастает. Например акронис труимадж если не начался (я этого не застал), то развивался через такую консольную тулзу и это очень удобно. Сам всегда начинаю именно с тулзы. Юнит тесты уже потом. А интеграционные уже можно и на ней писать.
Во времена Thinkpad t450 и даже t430, читал точно такие же статьи, где люди покупали IBM Thinkpad, потому что он хороший, а вот современные отстой. В общем то каждому свое ближе, кому то устаревший комп подешевле, а кому то новенький подороже.
К слову, использую сейчас 10 летний ноут Lenovo y5070. Купил новым. На работе был как раз что-то в районе Lenovo t450, не помню точно на sandy bridge. Хороший ноут, да.
А зря смеетесь. Именно так архивы и делаются. Например есть такое понятие как дедубликация. Когда некому хешу устанавливается в соответствие блоб. В этом случае в архиве хранятся ссылки на хеши. Вот сами прикиньте, пользователи часто льют одни и те же данные типа инсталляторов, фильмов, и прочего, и смысла хранить это во многих экземплярах нет никакого. И в Яндекс диске такое используется. Они даже не отправляют файл, если файл с таким хешом существует.
В том то и дело, что только незаконна. А легитимна вполне может быть. У работодателя немало способов давления, чтобы обеспечить соблюдение условий договора. Кроме того, это в России такой либеральный тк. А в мире не везде так. Рынок ит специалистов мировой. А значит возможны ситуации, когда это стрельнёт.
Ограничение на совмещение не на пустом месте. Это делается, я думаю, что бы обезопасить от неконтролируемого заимствования в обе стороны.
А попытки обойти это все обычно не терроризм и не мошенничество. Часто это попытка восстановить статус кво в перекошенных в сторону работодателя реальных правах. Хотя конечно, конечно, бывают нашумевшие случаи, когда человек ничего не делает на 5 работах или нанимает несколько индусов вместо себя. Последнее правда сомнительно в плане определения такой ситуации как обман. Работа ведь сделана.
Сомневаюсь, что цель мс -- борьба с буткитом. Скорее с линуксом. Я что-то не слышал, что буткиты является бичом сейчас. Хотя работаю в ав компании. Я конечно не вирусный аналитик, но всеж.
Что-то не помню такого. Мы для этого использовали virtual breaker 4 Ctrl и любая программа завершается, а tp 5.5 на виртуальном диске тут же загружается
Почитал, что пишут по этому поводу. На википедии считают что темный фотон безмассовая частица. И вообще нужен для взаимодействия частиц темной материи между собой.
Если это темные фотоны, то в чем сходство с ними обычными? В том что всегда движутся со скоростью света? Но она больше скорости убегания из галактики. А судя по всему темная материя кучкуется с обычной. В общем на мой непосвящённый взгляд эти фотоны не объясняют то из-за чего гипотеза отемной материи была выдвинута. Слишком большая угловая скорость движения заезд на окраинах галактик.
В самих алгоритмах проблем нет, если ты сам пришел сам рвешься на конкретную вакансию, то подготовиться к ней можно вполне. Но если тебя и так все устраивает, тебя уговаривают придти, а не понравиться не подешь, то странно ожидать, что кандидат будет долго готовится. Скорее он не пройдет собес.
Кроме того, такой метод все выше будет задирать планку, а в этом случае выгоду от этого получат те кто регулярно меняет работу, и hr департамент. Лояльные же сотрудники, готовые работать 5+ лет на одном месте будут проигнорированы.
По старому месту работы говорили, что человек в среднем уходит после 2х лет.
Это тот момент, когда kpi hr, приносит вред компании.
Но софт компаннии обладая большой нормой прибыли справляются с этим.
Вообще рекрутеры-люди и так уже слишком активизировались в последнее время. Чтобы общаться с чат ботом -- нужно быть очень сильно заинтересованным в трудоустройстве в конкретную компанию.
Я лично не стану общаться с ботом. А если это непонятно с первого сообщения, то перестану общаться сразу как только пойму.
Турбо паскаль 5.0. А когда я учился на спецкурсе мэи при кафедре Термеха в 93 уже borland pascal 6.0. У нас на кафедре и в школе IBM PC at 286 появились в 92 уже.
Да для школьников и студентов вполне себе.
Вот на кафедре вычислительной техники даже в 96 году были xt с mda интерфейсом. Мне такой на олимпиаде попался. Вот он не работал нормально.
обычно когда предлагают написать тестовую задачу, то хотят оценить кандидата с разных сторон: решение задачи, проектирование, стиль, понимание технологий с которыми предстоит работать, умение решать задачи эффективно, умение писать безопасный код.
какие я бы отметил проблемы:
Проектирование: основная проблема здесь, что существует один класс бог, который выполняем всё. с одной стороны этот класс не универсален, а заточен на конкретную ситуацию, с другой не решает конкретную задачу. кроме того, ответственность за работу с данными размазана между клиентом и сервером. лучшим решением было бы создать два разных класса client и server. работу с блоками данных лучше сделать на стороне клиента, чтобы не переусложнять. делать ли надстройку над сокетами -- это уже на усмотрение автора. но это упростит восприятие кода.
Протокол передачи. обычно при передаче через udp/tcp пакеты формируют в следующем виде: заголовок (4 байт), размер пакета (4 байт), crc32 (4 байт), служебные данные(например id пакета) (4 байт), данные (переменной длины). даже если часть данных передается в текстовом формате (json например) такой подход сохраняется. такой подход позволяет выявлять ошибки, получить уверенность что пакет пришел тот что надо. И это проще и для клиента и для сервера, тк протокол простой и заголовок всегда имеет стандартный размер. кроме того, так можно проверить что блок дошел полностью. здесь сходу бросается в глаза, что генерация id и заголовка переусложнена.
стилистика и мелкие ошибки проектирования: переменные называются i,j ... это очень неудобно. иногда даже опытные разработчики могут называть переменную i, но в этом случае область применения будет очень локальной типа небольшого цикла, здесь же, переменная j даже непонятно где объявлена, а тем более за что она отвечает. В c++ не принято создать объект, а потом еще раз его проинициализировать. Это приводит к тому, что объект получает возможность быть в невалидном состоянии. Лучше этого не допускать. Лишние члены класса коннекшен. sockaddr, buffer, vecline это все можно вынести в клиента и использовать один раз. Диагностика в в std::cout в классе connection и другие мелочи типа объявление переменных без инициализации. ну и то о чем уже писали. создание переменной connection в динамической памяти, вызов деструктора руками. да и WsaStratup я бы тоже в main вытащил.
решение задачи: часть проблем уже описывали: принимается только один файл и даже не идет речи о запуске двух клиентов параллельно (чему, кстати мешает приемный буфер - член класса не в последнюю очередь), работа только с текстовым файлом. Возвращаемое значение recv нужно учитывать всегда, вызов системных функций с захардкожеными путями temp.
производительность, самая главная проблема здесь -- ожидание клиентом ответа сервера. так передача будет работать очень медленно. я бы сделал клиенте упорядоченный по оффсетам файла vector, содержащий пару оффсет (текущее смещение в файле) и время. и при очередном отправлении пакета проверял не прошел ли таймаут у первого, и если прошел, то его можно перепослать. на клиенте чтобы учесть потерю пакетов забивал бы нулями незаполненную часть. конечно этот совет можно проигнорировать, но передача данных в этой задаче -- основная цель, те в продуктовом коде будут подобные задачи, и нужно сразу показать, то что решение будет эффективным. ну и конечно, нужно пользовать select/poll. это особенно важно становится если клиентов много.
безопасный код. Ошибки в большинстве случаев не проверяются. нужно либо пользовать исключениями, или в каждой строчке с io проверять результат выполнения функции. при этом exit(1) в классе решение плохое. завершать приложение класс не должен. за это должен отвечать main. про проверку количества параметров писали, можно также сказать про контроль размеров буфера. если хочется пользоваться c функциями, совместно с вектором, то желательно не использовать член класса bufsize а пользоваться buf.size(), это снизит вероятность ошибок с выходом за область массива. с этим нужно очень аккуратно работать. нужно везде на это внимание обратить.
по поводу тестов. я не думаю, что они здесь нужны. конечно некоторые их ожидают увидеть, тк видят в них серебряную пулю, поэтому не поставят галочку. но здесь код слишком простой и можно протестировать вручную. консольные утилиты сами по себе являются тестов. особенно с учетом того, что хочется сделать быстро. главное понимать как проверить какие-то краевые условия. Но, если делать оптимизацию по скорости, то на этот алгоритм можно и сделать отдельный тест. это время съэкономит. если же тестировать все подряд, то это сильно усложнит код и работу только замедлит.
Еще как вариант, для выполнения запрещенных команд, погрузки страниц в легковесном эмуляторе. Но сейчас, я думаю, это не так актуально, наверное, так как есть wsl.
Мне кажется изначально задача про атомарность была на другое. В клиент серверном приложении есть смысл атомарно складывать или умножать, но не все вместе.
Тк в случае однородных операций от перестановки слагаемых ничего не меняется, а вот если они разные, то например,
Сложить 1 и 3 а потом умножить на 5 не равно 1 умножить на 5 плюс 3
Те для атомарности операции должны быть идемпонентны
Таким образом, я думаю, что правильный ответ реализацию атомарного умножения реализовать нельзя.
А по мне так норм, начинать с консоли. Это сразу и тесты на минималках, при этом с возможностью проверять любые тесткейзы. И мотивирует сильнее, тк сразу видно, как система функциональностью обрастает. Например акронис труимадж если не начался (я этого не застал), то развивался через такую консольную тулзу и это очень удобно. Сам всегда начинаю именно с тулзы. Юнит тесты уже потом. А интеграционные уже можно и на ней писать.
Во времена Thinkpad t450 и даже t430, читал точно такие же статьи, где люди покупали IBM Thinkpad, потому что он хороший, а вот современные отстой. В общем то каждому свое ближе, кому то устаревший комп подешевле, а кому то новенький подороже.
К слову, использую сейчас 10 летний ноут Lenovo y5070. Купил новым. На работе был как раз что-то в районе Lenovo t450, не помню точно на sandy bridge. Хороший ноут, да.
А зря смеетесь. Именно так архивы и делаются. Например есть такое понятие как дедубликация. Когда некому хешу устанавливается в соответствие блоб. В этом случае в архиве хранятся ссылки на хеши. Вот сами прикиньте, пользователи часто льют одни и те же данные типа инсталляторов, фильмов, и прочего, и смысла хранить это во многих экземплярах нет никакого. И в Яндекс диске такое используется. Они даже не отправляют файл, если файл с таким хешом существует.
В том то и дело, что только незаконна. А легитимна вполне может быть. У работодателя немало способов давления, чтобы обеспечить соблюдение условий договора. Кроме того, это в России такой либеральный тк. А в мире не везде так. Рынок ит специалистов мировой. А значит возможны ситуации, когда это стрельнёт.
Ограничение на совмещение не на пустом месте. Это делается, я думаю, что бы обезопасить от неконтролируемого заимствования в обе стороны.
А попытки обойти это все обычно не терроризм и не мошенничество. Часто это попытка восстановить статус кво в перекошенных в сторону работодателя реальных правах. Хотя конечно, конечно, бывают нашумевшие случаи, когда человек ничего не делает на 5 работах или нанимает несколько индусов вместо себя. Последнее правда сомнительно в плане определения такой ситуации как обман. Работа ведь сделана.
Сомневаюсь, что цель мс -- борьба с буткитом. Скорее с линуксом. Я что-то не слышал, что буткиты является бичом сейчас. Хотя работаю в ав компании. Я конечно не вирусный аналитик, но всеж.
Вероятность повторения осмысленных фраз выше, тк они придумываются человеком, к значит и выше попасть после утечки чужого пароля.
Что-то не помню такого. Мы для этого использовали virtual breaker 4 Ctrl и любая программа завершается, а tp 5.5 на виртуальном диске тут же загружается
Мне кажется все зависит от особенностей человека. Кому-то список удобнее и практичнее, кому-то календарь.
У меня есть список и я его почти опустошил и в этом году и в прошлом, что теряет смысл я просто удаляю.
А шедулить жизнь не люблю.
А вы знакомы с pikvm? А то может свой ipkvm и не понадобится
Почитал, что пишут по этому поводу. На википедии считают что темный фотон безмассовая частица. И вообще нужен для взаимодействия частиц темной материи между собой.
https://ru.wikipedia.org/wiki/Тёмный_фотон?wprov=sfla1
Если это темные фотоны, то в чем сходство с ними обычными? В том что всегда движутся со скоростью света? Но она больше скорости убегания из галактики. А судя по всему темная материя кучкуется с обычной. В общем на мой непосвящённый взгляд эти фотоны не объясняют то из-за чего гипотеза отемной материи была выдвинута. Слишком большая угловая скорость движения заезд на окраинах галактик.
В самих алгоритмах проблем нет, если ты сам пришел сам рвешься на конкретную вакансию, то подготовиться к ней можно вполне. Но если тебя и так все устраивает, тебя уговаривают придти, а не понравиться не подешь, то странно ожидать, что кандидат будет долго готовится. Скорее он не пройдет собес.
Кроме того, такой метод все выше будет задирать планку, а в этом случае выгоду от этого получат те кто регулярно меняет работу, и hr департамент. Лояльные же сотрудники, готовые работать 5+ лет на одном месте будут проигнорированы.
По старому месту работы говорили, что человек в среднем уходит после 2х лет.
Это тот момент, когда kpi hr, приносит вред компании.
Но софт компаннии обладая большой нормой прибыли справляются с этим.
Вообще рекрутеры-люди и так уже слишком активизировались в последнее время. Чтобы общаться с чат ботом -- нужно быть очень сильно заинтересованным в трудоустройстве в конкретную компанию.
Я лично не стану общаться с ботом. А если это непонятно с первого сообщения, то перестану общаться сразу как только пойму.
Интересно. Такой подход можно и к анализу соединения 1/10gb LAN применить. Поискал сходу кажется, что NanoVNA сильно дешевле тестера diff пар LAN.
да понял уже потом, просто настальгия затмила глаза. :(
на 286
Турбо паскаль 5.0. А когда я учился на спецкурсе мэи при кафедре Термеха в 93 уже borland pascal 6.0. У нас на кафедре и в школе IBM PC at 286 появились в 92 уже.
Да для школьников и студентов вполне себе.
Вот на кафедре вычислительной техники даже в 96 году были xt с mda интерфейсом. Мне такой на олимпиаде попался. Вот он не работал нормально.
обычно когда предлагают написать тестовую задачу, то хотят оценить кандидата с разных сторон: решение задачи, проектирование, стиль, понимание технологий с которыми предстоит работать, умение решать задачи эффективно, умение писать безопасный код.
какие я бы отметил проблемы:
Проектирование: основная проблема здесь, что существует один класс бог, который выполняем всё. с одной стороны этот класс не универсален, а заточен на конкретную ситуацию, с другой не решает конкретную задачу. кроме того, ответственность за работу с данными размазана между клиентом и сервером. лучшим решением было бы создать два разных класса client и server. работу с блоками данных лучше сделать на стороне клиента, чтобы не переусложнять. делать ли надстройку над сокетами -- это уже на усмотрение автора. но это упростит восприятие кода.
Протокол передачи. обычно при передаче через udp/tcp пакеты формируют в следующем виде: заголовок (4 байт), размер пакета (4 байт), crc32 (4 байт), служебные данные(например id пакета) (4 байт), данные (переменной длины). даже если часть данных передается в текстовом формате (json например) такой подход сохраняется. такой подход позволяет выявлять ошибки, получить уверенность что пакет пришел тот что надо. И это проще и для клиента и для сервера, тк протокол простой и заголовок всегда имеет стандартный размер. кроме того, так можно проверить что блок дошел полностью. здесь сходу бросается в глаза, что генерация id и заголовка переусложнена.
стилистика и мелкие ошибки проектирования: переменные называются i,j ... это очень неудобно. иногда даже опытные разработчики могут называть переменную i, но в этом случае область применения будет очень локальной типа небольшого цикла, здесь же, переменная j даже непонятно где объявлена, а тем более за что она отвечает. В c++ не принято создать объект, а потом еще раз его проинициализировать. Это приводит к тому, что объект получает возможность быть в невалидном состоянии. Лучше этого не допускать. Лишние члены класса коннекшен. sockaddr, buffer, vecline это все можно вынести в клиента и использовать один раз. Диагностика в в std::cout в классе connection и другие мелочи типа объявление переменных без инициализации. ну и то о чем уже писали. создание переменной connection в динамической памяти, вызов деструктора руками. да и WsaStratup я бы тоже в main вытащил.
решение задачи: часть проблем уже описывали: принимается только один файл и даже не идет речи о запуске двух клиентов параллельно (чему, кстати мешает приемный буфер - член класса не в последнюю очередь), работа только с текстовым файлом. Возвращаемое значение recv нужно учитывать всегда, вызов системных функций с захардкожеными путями temp.
производительность, самая главная проблема здесь -- ожидание клиентом ответа сервера. так передача будет работать очень медленно. я бы сделал клиенте упорядоченный по оффсетам файла vector, содержащий пару оффсет (текущее смещение в файле) и время. и при очередном отправлении пакета проверял не прошел ли таймаут у первого, и если прошел, то его можно перепослать. на клиенте чтобы учесть потерю пакетов забивал бы нулями незаполненную часть. конечно этот совет можно проигнорировать, но передача данных в этой задаче -- основная цель, те в продуктовом коде будут подобные задачи, и нужно сразу показать, то что решение будет эффективным. ну и конечно, нужно пользовать select/poll. это особенно важно становится если клиентов много.
безопасный код. Ошибки в большинстве случаев не проверяются. нужно либо пользовать исключениями, или в каждой строчке с io проверять результат выполнения функции. при этом exit(1) в классе решение плохое. завершать приложение класс не должен. за это должен отвечать main. про проверку количества параметров писали, можно также сказать про контроль размеров буфера. если хочется пользоваться c функциями, совместно с вектором, то желательно не использовать член класса bufsize а пользоваться buf.size(), это снизит вероятность ошибок с выходом за область массива. с этим нужно очень аккуратно работать. нужно везде на это внимание обратить.
по поводу тестов. я не думаю, что они здесь нужны. конечно некоторые их ожидают увидеть, тк видят в них серебряную пулю, поэтому не поставят галочку. но здесь код слишком простой и можно протестировать вручную. консольные утилиты сами по себе являются тестов. особенно с учетом того, что хочется сделать быстро. главное понимать как проверить какие-то краевые условия. Но, если делать оптимизацию по скорости, то на этот алгоритм можно и сделать отдельный тест. это время съэкономит. если же тестировать все подряд, то это сильно усложнит код и работу только замедлит.
Еще как вариант, для выполнения запрещенных команд, погрузки страниц в легковесном эмуляторе. Но сейчас, я думаю, это не так актуально, наверное, так как есть wsl.
Мне кажется изначально задача про атомарность была на другое. В клиент серверном приложении есть смысл атомарно складывать или умножать, но не все вместе.
Тк в случае однородных операций от перестановки слагаемых ничего не меняется, а вот если они разные, то например,
Сложить 1 и 3 а потом умножить на 5 не равно 1 умножить на 5 плюс 3
Те для атомарности операции должны быть идемпонентны
Таким образом, я думаю, что правильный ответ реализацию атомарного умножения реализовать нельзя.