С крайностями понятно, потому что они очевидные. Когда линейная рутина и просто устанавливаем нужное состояние, то резать ее на куски излишне. А когда из алгоритма легко можно выделить библиотечный примитив, то не выделять его, это сбивать фокус у читателя.
Но давайте поговорим о чем-то среднем. Сегодня разбирал класс, у него в основе несколько списков (to_update, to_create) и пара хэш таблиц, в которые по ключам расставляются данные. Сам класс пытается сравнить две последовательности: то, что пользователь пытался заказать и то, что поставщик в итоге в посылку положил. Если чего-то нет, то отметить, если что-то разделили на товары из разных партий, разделить это и в заказе. И т.п., логики много, есть позиции с дочерними позициями, есть виртуальные позиции.
Так этот класс аккуратно порезан на функции, функции какими-то флагами обмениваются между собой, но все обращаются к общим переменным, постоянно туда что-то добавляя. Оформлено тщательно и хорошо, а читать тяжело, 600 строк туго переплетенного месива на python: хоровод с циклами, списками и словарями. Было бы дерево в основе, было бы куда его растить.
И вот имхо, даже если бы этот код написали плохо, но в том же стиле, сильно хуже он читаться не стал бы. А если бы двое разработчиков сели и потратили день-два, чтобы перетасовать методы класса, не переписывая начисто, он не стал бы понятнее.
Сначала нужно постараться с организацией данных, потом с общей концепцией. И только потом аргументы за "резать" или "не резать" начинают что-то значить.
Лес разный. В ленточном сосновом бору некоторых регионов Сибири, например, деревья стоят относительно плотно и тянутся вверх, а почва это непрочный суглинок. Когда ветер сильный, то одно из деревьев рано или поздно не выдерживает нагрузки, получается пробел и нагрузка на другое дерево возрастает, оно тоже падает.
В итоге, можно найти участок, где полосой повален ценный пиловочный материал, приезжай и бери. А контроль за лесом жесткий, его воруют и в черную, и в белую, поэтому споров о том, что кому когда можно, немало. А еще там сухо и даже упавший сухостой еще местами пригоден на распиловку, а уж точно на дрова.
В болотистых таежных местах Томской области, например, такого нет. Другие почвы и сыро. Если что-то упало, то значит оно сгнило еще стоя, а если и нет, то сгниет в считанные недели.
Насколько я понял, это такой enterprise интерфейс для self-hosted моделей. Акцент на контроле: кто куда заходил, с чем ему можно там работать и что он при этом у модели спрашивал. Потому, что даже внутри одной компании есть вещи, с которыми работают люди и которые не нужно знать работникам. Даже бизнес-подписка от openai, где обещают не использовать ввод пользователей для обучения моделей, все равно не подходит корпорациям, потому что секреты публикуются в чужом контуре.
Судя по описанию, умеет оно примерно то же, что и projects в gpt: диалоги с доступом к контексту в файлах и кастомным prompt. На картинках все больше о ролях, аудите и о том, что развивайте как хотите, мол это платформа, а не готовый ИИ ассистент.
Такое мнение можно найти про все, что требует усилий. Так уж устроен человек. И вместе с тем, есть люди увлеченные, готовые чем-то заниматься уже только потому, что это интригует. Позвольте под вашим комментарием разместить манифест о том, что учиться очень хорошо и полезно, это развивает мозг и формирует личность.
Возможно ли сконфигурировать прикладное решение, не прочитав ни одной книги и заработать на этом? Да, конечно. С ростом опыта еще и время эффективно потратив.
Так то эти задачки придумали для собеседований, чтобы как-то формализовать отбор, чтобы рекрутеры могли высокомерно рассуждать о квалификации кандидата, не утруждаясь значению слов. И вот конкретно в Яндекс задачи третьей секции выбирают откровенно глупые, наверное потому, что сложные не каждый интервьюер сможет. И эти интервьюеры еще наплевательски относятся к собеседованию: опоздал, ну да и ладно, зато неспеша начнем, как раз поболтать захотелось и есть идея про задачу (неправильная). Кроме молодых ребят, которые на первых двух этапах, те волнуются и серьезны, причем у них и задачи интереснее бывают, чем на "алгоритмической" секции.
Так вот, задачи глупые, а собеседования пафосный бардак. Но алгоритмы это круто и алгоритмы это не пара трюков из однострочных задачек. Можно не учить и не знать, но не нужно таких специалистов смешивать в одном ряду, они из разных сфер. Кто-то уже все сделал, что можно использовать готовое? Так оно не само готовым сделалось.
К слову, для сотрудников того же Яндекс одно время читал лекции Максим Бабенко.
С GPT есть другая серьезная проблема в нашей работе, о ней пока мало говорят. Это коллеги, которые раньше ничего не делали и потому не мешали.
Например, входящий запрос от руководителя: "Я ввел описание твоей задачи в gpt и мне кажется, что она написала что-то дельное, но я не читал. Прочитай, напиши мне аргументированный ответ и объясни свою позицию, обязательно понятную мне, чтобы я мог цепляться к словам не утруждаясь".
Или соседняя команда, которые сгенерировали JSON и опубликовали его в качестве контракта не читая. И передали его тебе на ревью, чтобы ты сделал эту работу целиком. Отчитаться, что на их стороне все готово, они не забыли, теперь ждут одного только тебя.
У гоферов проблема с `go run`, там компилятор такой быстрый, что можно запускать из исходников. В rust есть `cargo run`, хотя оно и медленнее. Например, это автоматическое тестирование: собрали в нужной конфигурации, запустили и так много раз. Можно еще представить что-то сервисное, когда код генерируется из шаблонов под задачу и сразу же выполняется.
Спасибо за ссылку, интересно было почитать, как люди живут. Там в POSIX пытались сделать так, чтобы дочерный процесс получал закрытые дескрипторы после fork. И не сошлись во мнении, что будет с сокетами.
>> The deny_write_access() mechanism is causing really pointless issues such as [1]. If a thread in a thread-group opens a file writable, then writes some stuff, then closing the file descriptor and then calling execve() they can fail the execve() with ETXTBUSY because another thread in the thread-group could have concurrently called fork(). Multi-threaded libraries such as go suffer from this.
То есть мешал не столько запрет на запись в выполняемый файл, сколько запрет запускать не закрытый после записи файл. Насколько я понял, проблема была с fork'нутыми процессами, которые успевали форкнуться до того, как файл был закрыт. И страдали из-за этого, в первую очередь, go разработчики с их goрутинами, которые форкаются сами по себе.
Раз статья для того, чтобы вставить свою фамилию в первом абзаце, то писать ее нужно все же самому. Ведь есть же интересные истории про проекты, где не выполнялось то или иное, или все сразу. Редактор молодец, а вот материала ей большой директор выделил мало.
Мне тоже это кажется наглостью. Требования жесткие, а бюджет скромный. И даже если никто не предложит это "вау" из коробки, то можно забесплатно собрать обзор по использованным подходам. Одна только сопроводительная документация позволит упростить разработку собственного решения.
Бывает и веселее, одна компания рассылала приглашения на свой хакатон. И в приглашении конкретное ТЗ, по которому им нужен прототип, приходите мол с уже готовым, показывайте. Призовой фонд 150тыс (нашими, бесполезными). И я тогда подумал, что за такие деньги тоже хочу прототип нового продукта, а еще с возможностью нанять разработчиков.
На форуме wasm.ru он писал развернутые сообщения о своей жизни в США после переезда. Работал в McAfee и делали они анализ зловредов в сети на лету. Рассказывал про анализ pdf (там есть js внутри), доказывал что у него там всякие крутые ребята вокруг и что он не выделяется.
А меня удивляет, что если человек не против работать в условном озоне, то его собеседуют по принципу брать/не_брать. При этом компания отчаянно нуждается в людях, задачи разноплановые, у команд разные стили и требования.
Как по мне, обязательно нужно проверить на адекватность и умение связно мыслить, дисциплину и умение работать. А техническое интервью нужно для оценки и проф. ориентирования, но не как барьер.
Завалил задачку на кодинг в граничных случаях, но правильно рассуждал про нее и архитектуру? Ну покрутись вот в этой команде на мидловской роли во время испытательного срока, джунов поменторишь и сам подучишься. Будет 0.75 от ожидаемой зп, через три месяца пересмотр. Или вот в этой команде, они там документацию никак не успевают наладить, а у тебя по всем тех. навыкам провал, кроме аналитических. Вектор развития обсудим через два месяца.
В rpg часто есть кнопка для случайной генерации характеристик персонажа. И вот игрок не выбрал первый или второй набор, с которым тоже интересно играть, но в определенном стиле. Тогда его выбор будет через десятки нажатий на эту кнопку: сила 20, даже больше чем хотелось, но ой что-то интеллект маловат, а там разговоры же, понажимаю еще. Сила 18, это что-то мало, бывало и больше. И так до изнеможения, пока глаз не замылится.
Спасибо за статью.
Расскажите, пожалуйста, как вы управляете общим кодом между сервисами? Что у вас получается выделить отдельно, а что приходится копировать?
Это ElectricTrains. time-usage показывает, что на него приходится половина времени. Не зависит от статуса поезда, мод на каждый тик обновляет статус топлива для всех поездов и делает это прямолинейно:
function OnTick()
if anzLoc > 0 and anzControl > 0 then
for i,loc in pairs(global.LocList) do
if loc and loc.entity and loc.entity.valid then
if not (loc.provider and loc.provider.valid) then
CreateProvider(loc)
else
needPower = loc.entity.burner.currently_burning.fuel_value - loc.entity.burner.remaining_burning_fuel
restPower = loc.provider.energy - needPower
if restPower > 0 then
loc.entity.burner.remaining_burning_fuel = loc.entity.burner.currently_burning.fuel_value
loc.provider.energy = loc.provider.energy - needPower
else
loc.entity.burner.remaining_burning_fuel = loc.entity.burner.remaining_burning_fuel + loc.provider.energy
loc.provider.energy = 0
end
end
else
RemoveLoc(i)
end
end
end
end
Есть ups оптимизированная версия от другого автора, Advanced electric train. Она не обновлялась, но там много изменений и он делает так:
function onTick()
for i, train in pairs(global.TrainList) do
if train and train.entity and train.entity.valid then
train.entity.burner.currently_burning = global.Fuel
train.entity.burner.remaining_burning_fuel = global.Fuel.fuel_value
else
table.remove(global.TrainList, i)
end
end
end
Если остановить поезда, то играбельность повышается от остановки производства. Нет мода, чтобы включить все поезда разом и я включил чуть больше ста, ups просел на 6, так что в оценке, кто второй по потреблению ups, не уверен. Time-usage для ElectricTrains не вырос, поднялось все остальное, а поиск путей для поездов все еще около нуля.
Могу еще заметить, что 1000 поездов для такой базы, это слишком много: без неоптимизированного мода они бы и не тормозили, но их все же тяжело менять или обновлять. С LTN хватило бы и 50, заправка топливом в депо.
У вас также слишком длинные транспортеры, причем без особой нужды. И длинные надземные трубы — жидкость в каждой секции расчитывается отдельно, поэтому AdvancedFluidHandling замечательный мод. Ну и перекрестки, пропускающие по одному поезду за раз (идей с дизайном путей можно набраться на factorioprints).
Вы пробовали «Advanced Fluid Handling»? Он добавляет много всяких хитрых труб, что позволяет уменьшить их количество в 3-4 раза. Если нужен хаб на четыре стороны, то вместо пяти ставится одна. Расчет жидкостей может отнимать и четверть от всего времени.
Из bob's мне понравился мод про inserters, держу только его из пакета и это позволяет использовать меньше транспортеров.
Ну и все в духе минимализма: LTN позволяет использовать десяток поездов вместо 100, Krastorio добавляет производительные smelters, которые отлично сбалансированы и ничего не ломают. Это отдельный фан, когда модуль базы должен содержать только необходимый минимум деталей.
С копипастом легко расширяться, но появляется много лишнего. По сети доступны гигафабрики в самом разном стиле, многие отчаянно тормозят и при этом явно избыточны, но трейновые все же самые производительные.
Было бы интересно посмотреть на проблему с сигналами поездов, потому что это неожиданно, такую базу можно отправить разработчикам, они специально просят для профилировки. Вижу комментарий ниже, у вас точно с остановкой поездов не останавливается производство? В общем, если хотите, давайте вместе посмотрим.
Вы пробовали Logistic Train Network? Это мод про автоматическое расписание для поездов по запросу и с ним поездов становится на порядок меньше. Загружаторы и warehouse тоже сильно снижают количество деталей. Еще, для меня было сюрпризом, что и в ванильной версии можно делать одинаковые имена остановок, добавляя в расписание только одну из них, а пустые выключая по условию, но с LTN все равно элегантнее выходит.
Самые часто упоминаемые моды, но имхо, у bob's серьезные проблемы с балансом. Зато мне очень понравилось Krastorio + Space-exploration. Их реже упоминают, так что рекомендую всем, кто про них еще не слышал.
Если у них senior, это тот, кого принято называть middle, то все сходится. Человек, который понимает, что происходит. Не зря же упомянут какой-то staff и еще три дополнительных уровня.
С крайностями понятно, потому что они очевидные. Когда линейная рутина и просто устанавливаем нужное состояние, то резать ее на куски излишне. А когда из алгоритма легко можно выделить библиотечный примитив, то не выделять его, это сбивать фокус у читателя.
Но давайте поговорим о чем-то среднем. Сегодня разбирал класс, у него в основе несколько списков (to_update, to_create) и пара хэш таблиц, в которые по ключам расставляются данные.
Сам класс пытается сравнить две последовательности: то, что пользователь пытался заказать и то, что поставщик в итоге в посылку положил. Если чего-то нет, то отметить, если что-то разделили на товары из разных партий, разделить это и в заказе. И т.п., логики много, есть позиции с дочерними позициями, есть виртуальные позиции.
Так этот класс аккуратно порезан на функции, функции какими-то флагами обмениваются между собой, но все обращаются к общим переменным, постоянно туда что-то добавляя. Оформлено тщательно и хорошо, а читать тяжело, 600 строк туго переплетенного месива на python: хоровод с циклами, списками и словарями. Было бы дерево в основе, было бы куда его растить.
И вот имхо, даже если бы этот код написали плохо, но в том же стиле, сильно хуже он читаться не стал бы. А если бы двое разработчиков сели и потратили день-два, чтобы перетасовать методы класса, не переписывая начисто, он не стал бы понятнее.
Сначала нужно постараться с организацией данных, потом с общей концепцией. И только потом аргументы за "резать" или "не резать" начинают что-то значить.
Лес разный. В ленточном сосновом бору некоторых регионов Сибири, например, деревья стоят относительно плотно и тянутся вверх, а почва это непрочный суглинок. Когда ветер сильный, то одно из деревьев рано или поздно не выдерживает нагрузки, получается пробел и нагрузка на другое дерево возрастает, оно тоже падает.
В итоге, можно найти участок, где полосой повален ценный пиловочный материал, приезжай и бери. А контроль за лесом жесткий, его воруют и в черную, и в белую, поэтому споров о том, что кому когда можно, немало.
А еще там сухо и даже упавший сухостой еще местами пригоден на распиловку, а уж точно на дрова.
В болотистых таежных местах Томской области, например, такого нет. Другие почвы и сыро. Если что-то упало, то значит оно сгнило еще стоя, а если и нет, то сгниет в считанные недели.
Насколько я понял, это такой enterprise интерфейс для self-hosted моделей. Акцент на контроле: кто куда заходил, с чем ему можно там работать и что он при этом у модели спрашивал. Потому, что даже внутри одной компании есть вещи, с которыми работают люди и которые не нужно знать работникам. Даже бизнес-подписка от openai, где обещают не использовать ввод пользователей для обучения моделей, все равно не подходит корпорациям, потому что секреты публикуются в чужом контуре.
Судя по описанию, умеет оно примерно то же, что и projects в gpt: диалоги с доступом к контексту в файлах и кастомным prompt. На картинках все больше о ролях, аудите и о том, что развивайте как хотите, мол это платформа, а не готовый ИИ ассистент.
Такое мнение можно найти про все, что требует усилий. Так уж устроен человек.
И вместе с тем, есть люди увлеченные, готовые чем-то заниматься уже только потому, что это интригует.
Позвольте под вашим комментарием разместить манифест о том, что учиться очень хорошо и полезно, это развивает мозг и формирует личность.
Возможно ли сконфигурировать прикладное решение, не прочитав ни одной книги и заработать на этом? Да, конечно. С ростом опыта еще и время эффективно потратив.
Так то эти задачки придумали для собеседований, чтобы как-то формализовать отбор, чтобы рекрутеры могли высокомерно рассуждать о квалификации кандидата, не утруждаясь значению слов. И вот конкретно в Яндекс задачи третьей секции выбирают откровенно глупые, наверное потому, что сложные не каждый интервьюер сможет. И эти интервьюеры еще наплевательски относятся к собеседованию: опоздал, ну да и ладно, зато неспеша начнем, как раз поболтать захотелось и есть идея про задачу (неправильная). Кроме молодых ребят, которые на первых двух этапах, те волнуются и серьезны, причем у них и задачи интереснее бывают, чем на "алгоритмической" секции.
Так вот, задачи глупые, а собеседования пафосный бардак.
Но алгоритмы это круто и алгоритмы это не пара трюков из однострочных задачек. Можно не учить и не знать, но не нужно таких специалистов смешивать в одном ряду, они из разных сфер. Кто-то уже все сделал, что можно использовать готовое? Так оно не само готовым сделалось.
К слову, для сотрудников того же Яндекс одно время читал лекции Максим Бабенко.
С GPT есть другая серьезная проблема в нашей работе, о ней пока мало говорят. Это коллеги, которые раньше ничего не делали и потому не мешали.
Например, входящий запрос от руководителя: "Я ввел описание твоей задачи в gpt и мне кажется, что она написала что-то дельное, но я не читал. Прочитай, напиши мне аргументированный ответ и объясни свою позицию, обязательно понятную мне, чтобы я мог цепляться к словам не утруждаясь".
Или соседняя команда, которые сгенерировали JSON и опубликовали его в качестве контракта не читая. И передали его тебе на ревью, чтобы ты сделал эту работу целиком. Отчитаться, что на их стороне все готово, они не забыли, теперь ждут одного только тебя.
У гоферов проблема с `go run`, там компилятор такой быстрый, что можно запускать из исходников. В rust есть `cargo run`, хотя оно и медленнее.
Например, это автоматическое тестирование: собрали в нужной конфигурации, запустили и так много раз. Можно еще представить что-то сервисное, когда код генерируется из шаблонов под задачу и сразу же выполняется.
Спасибо за ссылку, интересно было почитать, как люди живут. Там в POSIX пытались сделать так, чтобы дочерный процесс получал закрытые дескрипторы после fork. И не сошлись во мнении, что будет с сокетами.
>> The deny_write_access() mechanism is causing really pointless issues such as [1]. If a thread in a thread-group opens a file writable, then writes some stuff, then closing the file descriptor and then calling execve() they can fail the execve() with ETXTBUSY because another thread in the thread-group could have concurrently called fork(). Multi-threaded libraries such as go suffer from this.
То есть мешал не столько запрет на запись в выполняемый файл, сколько запрет запускать не закрытый после записи файл. Насколько я понял, проблема была с fork'нутыми процессами, которые успевали форкнуться до того, как файл был закрыт. И страдали из-за этого, в первую очередь, go разработчики с их goрутинами, которые форкаются сами по себе.
https://github.com/golang/go/issues/22315
Выручает плагин "I don't care about cookies". А на смартфоне хромовские плагины можно ставить в браузер kiwi, в том числе и фильтры рекламы.
Но за что оно так с пользователями, я тоже не понимаю.
Раз статья для того, чтобы вставить свою фамилию в первом абзаце, то писать ее нужно все же самому. Ведь есть же интересные истории про проекты, где не выполнялось то или иное, или все сразу.
Редактор молодец, а вот материала ей большой директор выделил мало.
Мне тоже это кажется наглостью. Требования жесткие, а бюджет скромный.
И даже если никто не предложит это "вау" из коробки, то можно забесплатно собрать обзор по использованным подходам. Одна только сопроводительная документация позволит упростить разработку собственного решения.
Бывает и веселее, одна компания рассылала приглашения на свой хакатон. И в приглашении конкретное ТЗ, по которому им нужен прототип, приходите мол с уже готовым, показывайте. Призовой фонд 150тыс (нашими, бесполезными). И я тогда подумал, что за такие деньги тоже хочу прототип нового продукта, а еще с возможностью нанять разработчиков.
На форуме wasm.ru он писал развернутые сообщения о своей жизни в США после переезда. Работал в McAfee и делали они анализ зловредов в сети на лету. Рассказывал про анализ pdf (там есть js внутри), доказывал что у него там всякие крутые ребята вокруг и что он не выделяется.
Вот тут подняли архив, можно почитать его сообщения:
https://wasm.in/search/40827668/
https://wasm.in/search/40827736/ (с фильтром по нетехническому разделу)
https://wasm.in/members/kaspersky.305/
А меня удивляет, что если человек не против работать в условном озоне, то его собеседуют по принципу брать/не_брать. При этом компания отчаянно нуждается в людях, задачи разноплановые, у команд разные стили и требования.
Как по мне, обязательно нужно проверить на адекватность и умение связно мыслить, дисциплину и умение работать. А техническое интервью нужно для оценки и проф. ориентирования, но не как барьер.
Завалил задачку на кодинг в граничных случаях, но правильно рассуждал про нее и архитектуру? Ну покрутись вот в этой команде на мидловской роли во время испытательного срока, джунов поменторишь и сам подучишься. Будет 0.75 от ожидаемой зп, через три месяца пересмотр. Или вот в этой команде, они там документацию никак не успевают наладить, а у тебя по всем тех. навыкам провал, кроме аналитических. Вектор развития обсудим через два месяца.
В rpg часто есть кнопка для случайной генерации характеристик персонажа. И вот игрок не выбрал первый или второй набор, с которым тоже интересно играть, но в определенном стиле. Тогда его выбор будет через десятки нажатий на эту кнопку: сила 20, даже больше чем хотелось, но ой что-то интеллект маловат, а там разговоры же, понажимаю еще. Сила 18, это что-то мало, бывало и больше. И так до изнеможения, пока глаз не замылится.
Как по мне, полезно уже тем, что фронты могут какие-то вещи делать сами. Особенно в проектах, где SPA с кучей логики, а на бэке просто REST.
Меньше суеты, меньше звеньев, быстрее и дешевле разработка. Бывает, что один час в забытом бэком проекте, это два дня ожидания и день правок.
Расскажите, пожалуйста, как вы управляете общим кодом между сервисами? Что у вас получается выделить отдельно, а что приходится копировать?
Есть ups оптимизированная версия от другого автора, Advanced electric train. Она не обновлялась, но там много изменений и он делает так:
Если остановить поезда, то играбельность повышается от остановки производства. Нет мода, чтобы включить все поезда разом и я включил чуть больше ста, ups просел на 6, так что в оценке, кто второй по потреблению ups, не уверен. Time-usage для ElectricTrains не вырос, поднялось все остальное, а поиск путей для поездов все еще около нуля.
Могу еще заметить, что 1000 поездов для такой базы, это слишком много: без неоптимизированного мода они бы и не тормозили, но их все же тяжело менять или обновлять. С LTN хватило бы и 50, заправка топливом в депо.
У вас также слишком длинные транспортеры, причем без особой нужды. И длинные надземные трубы — жидкость в каждой секции расчитывается отдельно, поэтому AdvancedFluidHandling замечательный мод. Ну и перекрестки, пропускающие по одному поезду за раз (идей с дизайном путей можно набраться на factorioprints).
Из bob's мне понравился мод про inserters, держу только его из пакета и это позволяет использовать меньше транспортеров.
Ну и все в духе минимализма: LTN позволяет использовать десяток поездов вместо 100, Krastorio добавляет производительные smelters, которые отлично сбалансированы и ничего не ломают. Это отдельный фан, когда модуль базы должен содержать только необходимый минимум деталей.
С копипастом легко расширяться, но появляется много лишнего. По сети доступны гигафабрики в самом разном стиле, многие отчаянно тормозят и при этом явно избыточны, но трейновые все же самые производительные.
Было бы интересно посмотреть на проблему с сигналами поездов, потому что это неожиданно, такую базу можно отправить разработчикам, они специально просят для профилировки. Вижу комментарий ниже, у вас точно с остановкой поездов не останавливается производство? В общем, если хотите, давайте вместе посмотрим.