Подрабатывал грузчиком, официантом, продавцом в магазине бытовой техники. В 19 лет с другом открыл компанию по установке кондиционеров.
То есть, не имея опыта установки кондиционеров, вдруг бах и открыть компанию по их установке (возможно у друга опыт был?), а через год хоп и контракты по всему городу. Как блин так?
ох, мы на 4м курсе такое считали, автомат стабилизации, входные данные - отклонение и его первая производная, коэффициенты по критерию Рауса-Гурвица, там вот это все. Еще запаздывание там как-то вводится, забыл уже
Моей 5, и я поставил на телефон codingskills, игру с элементами кодинга - последовательности, простые циклы и пользовательские функции - полет нормальный, все поняла, и даже интересно. Там сложность очень плавно нарастает. Вот сейчас scratch junior надо попробовать.
Но она у меня в принципе смышленая, читает/пишет, считать с переходом через 10 сама научилась, в позиционной записи разбирается
Я в юности и молодости занимался, имел красивое тело. Девушки на это не вешались. Вешались чуть позже, когда я стал заниматься "пикапом классическим" (не реклама, не всем подойдет, особо не рекомендую, очень эмоционально затратно). Зато приобрел проблемы с шеей и плечами. Сейчас уже все равно все результаты погребены где-то под большим животом. А для уверенности в себе намного больше рекомендую бокс.
ну так я и сравнивал по coremark/mhz, все-таки относительный показатель не настолько чувствителен к разнице техпроцессов. M1 привел чисто как пример для референтных цифр. Далее сравниваются дополнительно 2 отечественных решения и одно забугорное на похожих техпроцессах. Специально приводил в пример отечественные risc-v решения, чтобы обратить внимание на то, что они уже уделывают эльбрус по относительной производительности.
Ну как сказать бред.. У эльбруса 8с/16 где-то 3.1 coremark/mhz. У apple m1, для сравнения - где-то 9.8. Было бы еще сравнимо, если бы частота у эльбруса была в 3 раза выше, но нет - она раза в 2 ниже!
3.1 coremark/mhz - это примерно как синтакоровский scr5 (risc-v), энергоэффективный микроконтроллер. Уже scr7 предлагает 4 coremark/mhz, на подходе scr9.
Возьмем cloudbear bi-671, тоже risc-v - 5.7 coremark/mhz, это уже в принципе приближается к тому же core i7 - 2600, у которого 6.7 .
Короче, эльбрус и правда плох, и по относительным показателям, и по абсолютным.
Запустить первого и второго фолыча мне хватало и моего 486dx4 . И первый яндекс под столом у Сегаловича работал. Вот только нормальный сервак сейчас на этом не построить, даже горизонтальное масштабирование уровня "бог" не спасет
Для хрюшек в резюме пишут ачивменты типа задача х, сделал y, получил z в k % . Всегда можно написать типа была задача по внесению новой функциональности, я(!) сделал ресеч(! и именно такими словами) и отрефакторил код, сократив delivery time (!) на 30-50% . И все, и хрюше не докопаться (ты ж не дуер, ты ачивер), и менеджеру нанимающему будет чем задницу прикрыть. А то, что ты в реале прикручивал костыль к инвалидной коляске, никого не волнует.
ведь навык ковыряния в куче кала не оценивают на собеседованиях.
Бро, на собеседованиях оценивают навык прохождения собеседований, нужно это уяснить раз и навсегда и не ждать от работы того, чего она не может дать. А это значит, что навык прохождения собеседований нужно качать Отдельно: решать литкод, решать всякие систем дизайн примеры, разбирать их, читать и запоминать архитектуру фреймворков/бд/облаков/етк, зубрить всякие неочевидности языка, на котором пишешь, теорию, да мало ли.
И да, не бывает чистого кода, проработавшего в продакшене хотя бы условно пару лет. Любой, даже наичистейший код с идеальнейшей архитектурой, поработав в проде, становится кучей кала, даже в той же IT Digital Kal, причем там кал будет еще похлеще, чем в финтехе.
И кстати, если бы я нанимал, то я бы предпочел кандидата именно с опытом разгребания авгиевых конюшен, при условии знания оным основ алгоритмов.
да, это так. Все через координатор гоняет. Я очень сильно протупил, перепутал внезапно с apache phoenix-ом.
Почитал ваш коннектор, я немного не до конца понял, как у вас планируются партиции ( это надо видимо с дебагером погонять), а в каждом PartitionReader-е/DataWriter-е у вас внутри RmiSlave поднимается http-server c gpfdist-протоколом, и одновременно создается в gp внешка с location-ами этих серверов, и в нее пишется/из нее читается. В принципе, это все и без коннектора можно сделать, будет проще. Я свой последний коннектор написал в 2020м, и в принципе, кмк, его стоит писать только тогда, когда есть возможность обеспечить data locality.
И почему-то меня не покидает ощущение, что можно сделать еще проще (возможно, ложное).
Я может чего не понимаю, но в jdbc-коннекторе есть возможность параллельного чтения данных с разбиением на партиции по одной колонке, с параллельной записью тоже проблем нет, тем более gp должен поддерживать copy, можно ж просто сделать dataframe.foreachPartition и в ней через copy залить. Едтнственное, где я вижу необходимость в своем коннекторе - если spark-ноды и gp-ноды нахожятся на одних машинах, и надо по возможности read local обеспечить. В любом случае, исходники на гитхаб было бы плюсом, а так в статье одна вода "какие мы молодцы бла бла бла и как мы круто сделали бла бла бла"
Там в самом начале дается PV-диаграмма при атмосферном давлении и при 100 барах. При наддуве цилиндра PV-диаграмма вытягивается по вертикали и перепад давления вместо 0.02-0.1 становится 2-10. А надуть цилиндр можно насосом, работающим от поршня, который будет вдувать в холодную часть цилиндра в фазе всасывания. Главная проблема там - уплотнения поршня и штока.
Теперь к паровой технике. Мне кажется, без холодильника-конденсатора обойтись будеь сложно, так как без регенерации пара на одном котле далеко не уедешь, мот - не паровоз. А регенератор должен большую площадь теплообменника иметь, +насос, который воду будет обратно в котел вкачтвать, да еще и с давлением больше, чем в котле. Это увнличивает габариты, и надо будет аккуратно компоновать. По-моему нв ютубе был видос про автомобили Добля, как он там все делал.
С техническими собеседованиями вообще всегда было непросто - последние 10 лет все кинулись решать задачи, до этого (~ 2010 - 2012) все были укушены паттернами программирования, чуть раньше и одновременно с этим досконально зубрили стандарт языка, чтобы отвечать на бесконечные вопросы "что выдаст вот этот говнокод".
Но вообще алгосы нужны, но в них нужна мера. По моему опыту, нужно обязательно проверять 4 вещи: знает ли человек про динамический массив и куда в него можно вставлять, а куда нельзя, знает ли про двусвязный список и куда в него можно вставлять, а куда нельзя, знает ли пользу сортировки и бинарного поиска и знает ли, что такое хэш-мапа. RB-мапа - как бонус. Потому что 80% неоптимального кода - когда юзают динамический массив вместо мапы. 20% - на все остальное, преимущественно списки (это моя личная статистика за ~12 лет, когда я так или иначе ревьюил чужой код в разных компаниях).
Тестовое задание - вообще тема. Если честно, я бы никогда не взял человека, который откажется сделать тестовое. Единственный минус тестового - нет уверенности в том, что человек его сделал лично, даже после беседы (да, я обожаю делать тестовые, никогда не отказывался и всегда они были интересными).
Просто на поговорить - мне кажется, такие собеседования контрпродуктивны, так как проверяют навыки коммуникации, а не собственно разработки, я такие интервью не люблю ни проводить, ни проходить.
Для тех, кто хочет привнести в Java немного функциональности, существует Scala.
тогда учиться никто не будет. А психологическое давление от системы - это какое? Требование учиться что ли? Ну так это жизнь требует, а не система
Меня всегда в людях поражало вот это:
То есть, не имея опыта установки кондиционеров, вдруг бах и открыть компанию по их установке (возможно у друга опыт был?), а через год хоп и контракты по всему городу. Как блин так?
Если что, З - это зависть
ох, мы на 4м курсе такое считали, автомат стабилизации, входные данные - отклонение и его первая производная, коэффициенты по критерию Рауса-Гурвица, там вот это все. Еще запаздывание там как-то вводится, забыл уже
Моей 5, и я поставил на телефон codingskills, игру с элементами кодинга - последовательности, простые циклы и пользовательские функции - полет нормальный, все поняла, и даже интересно. Там сложность очень плавно нарастает. Вот сейчас scratch junior надо попробовать.
Но она у меня в принципе смышленая, читает/пишет, считать с переходом через 10 сама научилась, в позиционной записи разбирается
Я в юности и молодости занимался, имел красивое тело. Девушки на это не вешались. Вешались чуть позже, когда я стал заниматься "пикапом классическим" (не реклама, не всем подойдет, особо не рекомендую, очень эмоционально затратно). Зато приобрел проблемы с шеей и плечами. Сейчас уже все равно все результаты погребены где-то под большим животом. А для уверенности в себе намного больше рекомендую бокс.
Куда его втыкать-то??
P.S.: А, не, ноут 2009го года еще с читалкой
ну так я и сравнивал по coremark/mhz, все-таки относительный показатель не настолько чувствителен к разнице техпроцессов. M1 привел чисто как пример для референтных цифр. Далее сравниваются дополнительно 2 отечественных решения и одно забугорное на похожих техпроцессах. Специально приводил в пример отечественные risc-v решения, чтобы обратить внимание на то, что они уже уделывают эльбрус по относительной производительности.
Ну как сказать бред.. У эльбруса 8с/16 где-то 3.1 coremark/mhz. У apple m1, для сравнения - где-то 9.8. Было бы еще сравнимо, если бы частота у эльбруса была в 3 раза выше, но нет - она раза в 2 ниже!
3.1 coremark/mhz - это примерно как синтакоровский scr5 (risc-v), энергоэффективный микроконтроллер. Уже scr7 предлагает 4 coremark/mhz, на подходе scr9.
Возьмем cloudbear bi-671, тоже risc-v - 5.7 coremark/mhz, это уже в принципе приближается к тому же core i7 - 2600, у которого 6.7 .
Короче, эльбрус и правда плох, и по относительным показателям, и по абсолютным.
Запустить первого и второго фолыча мне хватало и моего 486dx4 . И первый яндекс под столом у Сегаловича работал. Вот только нормальный сервак сейчас на этом не построить, даже горизонтальное масштабирование уровня "бог" не спасет
Есть книжка Харрис и Харрис, там это все тоже очень хорошо и доступно излагается. Очень рекомендую!
Да.
Для хрюшек в резюме пишут ачивменты типа задача х, сделал y, получил z в k % . Всегда можно написать типа была задача по внесению новой функциональности, я(!) сделал ресеч(! и именно такими словами) и отрефакторил код, сократив delivery time (!) на 30-50% . И все, и хрюше не докопаться (ты ж не дуер, ты ачивер), и менеджеру нанимающему будет чем задницу прикрыть. А то, что ты в реале прикручивал костыль к инвалидной коляске, никого не волнует.
Бро, на собеседованиях оценивают навык прохождения собеседований, нужно это уяснить раз и навсегда и не ждать от работы того, чего она не может дать. А это значит, что навык прохождения собеседований нужно качать Отдельно: решать литкод, решать всякие систем дизайн примеры, разбирать их, читать и запоминать архитектуру фреймворков/бд/облаков/етк, зубрить всякие неочевидности языка, на котором пишешь, теорию, да мало ли.
И да, не бывает чистого кода, проработавшего в продакшене хотя бы условно пару лет. Любой, даже наичистейший код с идеальнейшей архитектурой, поработав в проде, становится кучей кала, даже в той же IT Digital Kal, причем там кал будет еще похлеще, чем в финтехе.
И кстати, если бы я нанимал, то я бы предпочел кандидата именно с опытом разгребания авгиевых конюшен, при условии знания оным основ алгоритмов.
Первая задача действительно простая, решается через std::unordered_map<int, std::set<int>>, O(N*logK)
Вторая неожиданно сложная, хоть и easy. На ум приходит суффиксный массив + sliding window за O(NlogN), но это чет не easy
Третья на префиксную сумму, можно обойти если общая сумма gas больше, стартовая точка - где префиксные суммы последний раз пересекаются
я подозреваю, что люди постоянно приносят/забирают документы и списки постоянно меняются
да, это так. Все через координатор гоняет. Я очень сильно протупил, перепутал внезапно с apache phoenix-ом.
Почитал ваш коннектор, я немного не до конца понял, как у вас планируются партиции ( это надо видимо с дебагером погонять), а в каждом PartitionReader-е/DataWriter-е у вас внутри RmiSlave поднимается http-server c gpfdist-протоколом, и одновременно создается в gp внешка с location-ами этих серверов, и в нее пишется/из нее читается. В принципе, это все и без коннектора можно сделать, будет проще. Я свой последний коннектор написал в 2020м, и в принципе, кмк, его стоит писать только тогда, когда есть возможность обеспечить data locality.
И почему-то меня не покидает ощущение, что можно сделать еще проще (возможно, ложное).
Я может чего не понимаю, но в jdbc-коннекторе есть возможность параллельного чтения данных с разбиением на партиции по одной колонке, с параллельной записью тоже проблем нет, тем более gp должен поддерживать copy, можно ж просто сделать dataframe.foreachPartition и в ней через copy залить. Едтнственное, где я вижу необходимость в своем коннекторе - если spark-ноды и gp-ноды нахожятся на одних машинах, и надо по возможности read local обеспечить. В любом случае, исходники на гитхаб было бы плюсом, а так в статье одна вода "какие мы молодцы бла бла бла и как мы круто сделали бла бла бла"
Про стирлинг вы не правы. Вот очень хороший видос от siemens, в котором по полочкам разложено, как сделать мощный стирлинг:
https://youtu.be/XWAoaU1q-Yw?si=UKnbxnxYuLIh019W
Там в самом начале дается PV-диаграмма при атмосферном давлении и при 100 барах. При наддуве цилиндра PV-диаграмма вытягивается по вертикали и перепад давления вместо 0.02-0.1 становится 2-10. А надуть цилиндр можно насосом, работающим от поршня, который будет вдувать в холодную часть цилиндра в фазе всасывания. Главная проблема там - уплотнения поршня и штока.
Теперь к паровой технике. Мне кажется, без холодильника-конденсатора обойтись будеь сложно, так как без регенерации пара на одном котле далеко не уедешь, мот - не паровоз. А регенератор должен большую площадь теплообменника иметь, +насос, который воду будет обратно в котел вкачтвать, да еще и с давлением больше, чем в котле. Это увнличивает габариты, и надо будет аккуратно компоновать. По-моему нв ютубе был видос про автомобили Добля, как он там все делал.
С техническими собеседованиями вообще всегда было непросто - последние 10 лет все кинулись решать задачи, до этого (~ 2010 - 2012) все были укушены паттернами программирования, чуть раньше и одновременно с этим досконально зубрили стандарт языка, чтобы отвечать на бесконечные вопросы "что выдаст вот этот говнокод".
Но вообще алгосы нужны, но в них нужна мера. По моему опыту, нужно обязательно проверять 4 вещи: знает ли человек про динамический массив и куда в него можно вставлять, а куда нельзя, знает ли про двусвязный список и куда в него можно вставлять, а куда нельзя, знает ли пользу сортировки и бинарного поиска и знает ли, что такое хэш-мапа. RB-мапа - как бонус. Потому что 80% неоптимального кода - когда юзают динамический массив вместо мапы. 20% - на все остальное, преимущественно списки (это моя личная статистика за ~12 лет, когда я так или иначе ревьюил чужой код в разных компаниях).
Тестовое задание - вообще тема. Если честно, я бы никогда не взял человека, который откажется сделать тестовое. Единственный минус тестового - нет уверенности в том, что человек его сделал лично, даже после беседы (да, я обожаю делать тестовые, никогда не отказывался и всегда они были интересными).
Просто на поговорить - мне кажется, такие собеседования контрпродуктивны, так как проверяют навыки коммуникации, а не собственно разработки, я такие интервью не люблю ни проводить, ни проходить.