Сейчас много всяких карманных игровых приставок расплодилось, по образу стимдека, на любой вкус и кошелек. Смотрю их ремонты - там то винда, то linux. И железо приближается к ноутбучному, и оно там не армовское, а вполне себе x64. Выглядит как неплохая замена ноута для путешествий: мощное железо и тонны памяти на борту уже есть, батарейки огромные, рассчитанные на игры, для работы хватит явно дольше чем на игры, добавить сюда очки и какой-нибудь более-менее удобный манипулятор или клавиатуру, приспособленную чтобы можно было работать без стола, сидя в самолете или поезде например, и комплект готов. Но повыбирать конечно придется - в таких девайсах всегда все костылями усеяно, железо кастомное, без танцев ось не поставить, а если поставить, то не факт что дрова под весь этот зоопарк найдутся, так что велика вероятность остаться на той оси, что заложил производитель изначально.
мне больше понравился kde-tiling-on-drag: сетка настраивается мышкой, окна можно быстро привязывать к сетке или держать вне сетки, получается гибкая раскладка под любые задачи
Если это тестовые сервера, то там программеры, кто на vscode, разворачивают vscode backend, и работают как у себя на машине, и с консолью обычно не сталкиваются. Если это продовые сервера, то простых программеров туда никто не пустит, и опять же с консолью они опять не сталкиваются. Так что для начинающих взаимодействие с консолью это скорее личный выбор: кто-то упорно остается в IDE, кто-то осваивает консоль, из-под палки никого никуда не загоняют.
Но личный опыт говорит о том, что IDE для начинающих все же предпочтительнее: сначала стоит сосредоточиться непосредственно на самом коде и управлением им, а уже потом можно расширять свой набор инструментов, осваивая что-то за пределами IDE. Потому что начинающие программеры, которые пытаются сразу работать с голым git, совершают слишком много ошибок, и ловят сильную демотивацию, иногда публично.
Например довольно распространенные ошибки: заливают лишнее или забывают заливать необходимое, заливают конфликты в промежуточном состоянии, разрушая код, заливают код с грубыми синтаксическими ошибками, т.е. вообще неспособный к компиляции/запуску код, случайно заливают массовые удаления тысяч файлов, а то и всего кода проекта, даже такие случаи в практике были, и неоднократно.
Все эти ошибки - детские, грубые, легко обнаружимые и легко исправляемые, но при наличии хотя бы минимального опыта, которого у начинающих просто нет.
Консоль требует больше понимания, ответственности и внимательности, чем IDE, в консоли нет AST-анализаторов, которые в IDЕ на такое сразу пнут красными метками, нет удобного и наглядного представления, и, откровенно говоря, многих консоль пугает, она сыпет непонятными ошибками на неродном языке, что приводит к панике, а если в спешке, то и к дополнительным, более грубым, ошибкам.
Конечно на стороне инфраструктуры от таких ошибок можно защититься, но это встречается на хорошо развитой инфраструктуре: перед принятием правок в git, код должен пройти валидацию автоматическими проверками на хуках, а после еще и пройти через пайплайны CI/CD, успешно пройти тесты.
Но до сих пор много где есть только голый git с ненастроенными хуками и отсутствующим ci/cd, и без каких-либо тестов. В таких окружениях программера автоматика не подстраховывает, а потому эти ошибки неизбежно вскрываются, и все внутри команды видят их, и отлично понимают, кто именно из них так начудил. И тот, кто начудил, тоже отлично понимает, что остальные отлично видят его факап, и иногда начинает накручивать себя, загоняться, со всеми вытекающими.
В итоге эти ошибки могут дорого стоить, в первую очередь воздействуя на саму команду, на ее мотивацию. После таких факапов, программер не просто обжигается, но и понимает что теряет репутацию в глазах коллег и руководства, получает негатив, демотивацию. Усиливает ее тот факт, что даже у менее опытных коллег, которые работают в IDE, таких ошибок не возникает: их подстраховывает IDE, ярко указывая на наличие проблемы, и иногда даже предлагая автоисправление.
Чтобы пройти дальше по карьере, важно уметь этот негатив в себе подавлять: нужно держать в уме, что все мы люди, все мы человеки, все мы ошибаемся, это неизбежно. Неизбежно, но это все равно неприятно, а работать с этим мало кто умеет. Многие не дают себе права на ошибку, принимают близко к сердцу, чего делать нельзя. Иногда некоторые не дают права на ошибку не только себе, но и другим - начинают охоту на ведьм, чего делать категорически нельзя: ошибиться может каждый, обвинения не принесут пользы, только усилят демотивацию. Иногда такие ошибки даже приводят к импульсивному уходу из профессии, что вообще абсурд - нельзя получить опыт, не набив шишек. Но факт есть факт: немногие способны адекватно воспринимать свои факапы и работать над собой. Особенно больно это бьет по психике и мотивации именно начинающих. Поэтому лучше уж начинать с IDE, а уже потом осваивать консоль и git, когда будет больше опыта, понимания и уверенности.
Консоль выручает там, где нет доступа к другим инструментам. Но начинающим разработчикам о таком можно даже не задумываться - такое они встретят не скоро, а может и никогда, сильно зависит от фирмы и организации производственных процессов в ней. Будет потребность - будет и опыт, переживать об этом заранее не стоит. Тем более ничего виртуозного на практике от git в таких кейсах не требуется: всякие конфликты решаются заранее, в удобном окружении, в GUI/IDE, а вручную остается только ветку переключить на нужную. В консоли процесс может облегчить tui, но, как правило, там, где нет доступа к инструментам, нет и tui - только голый git, и это в лучшем случае.
Кто плотно работает с нативным ssh, тем тоже зайдет именно голый git: ssh позволяет со временем подстроить рабочий процесс под себя, автоматизировать всю рутину, написать конфиги и сценарии, и выполнять код удаленно, в том числе через разные гейты, прокси и vpn, одной простой командой-псевдонимом. И все это великолепие очень доступно, доступнее любой IDE, буквально под кончиками пальцев, прямо в системном шелле: нажал f12 или ctrl+alt+t, набрал 2-3 буквы, tab, enter, и нужная автоматика пришла в движение, инициировав какие-то процессы на нужном тебе сервере.
Если серверов много, у каждого свои реалии, и все это завязано на тебе - самое то. Конечно можно и на стороне сервера это автоматизировать, но это значительно сложнее: таких полномочий у разработчиков обычно нет, нужно подключать бюрократию, админов, раскатывать ci/cd - в общем людей тут задействуется гораздо больше, добро на это получить значительно сложнее, и, не смотря на то, что это корректнее и эффективнее, выгоднее бизнесу, бизнес-решения штука довольно нелогичная, на практике такое доступно далеко не всегда, а родной ssh под рукой всегда, служит тебе верно, быстро и надежно, и ни от кого, кроме тебя, не зависит.
Чтобы кого-то засудить, нужно самому быть чистым перед законом. Сложно представить сценарий, чтобы преступник, неоднократно предпринимавший попытки взломать чужой сайт, подал в суд на то, что его атаковала защита и уронила его абсолютно незаконный скрипт. В таком сценарии при любых раскладах самому преступнику прилетит куда больше, чем владельцу сайта.
В старые серии баттлы играют намного больше, чем показывает статистика. По каждой из серии есть по несколько сообществ, которые пишут под них свои лаунчеры и собирают свои сервера, под свою сборку. Также сюда добавляются глобальные модификации, которые стоят особняком, как например project reality
А он на это и не рассчитан. Его ниша - cli-утилиты, мелкие сервера и микросервисы. Что-то большое на нем писать - это страшно даже представить, какая боль это будет. Но крупные проекты редко представляют из себя огромный монолит. Обычно это взаимосвязанный набор сервисов, вспомогательных инструментов, и инфраструктуры, целый зоопарк языков и множество команд разработчиков.
В теории да, удобно, можно не обрабатывать не обязательные или маловероятные ошибки, меньше кода.
На практике тут все ломает человеческий фактор. Особенно в чужом легаси коде, на котором заказчик хорошо скроил, и который писало десяток подрядчиков разного уровня - мягко говоря мешанина стилей и подходов, и тонны кода настолько низкого качества, которое и воображению не поддается. Реально: некоторые фрагменты кода даже специально написать практически невозможно, настолько они бессвязны, настолько грубые ошибки имеют, как будто их писал даже не джун, а ребенок, который только-только приступил к изучению языка.
Скрытый текст
Человеческий фактор вообще неприятная штука. На рынке достаточно много разработчиков, которые не будут делать не обязательные вещи, даже если их об этом прямо попросить. Лично сталкивался с такими: иногда нужно 2-3 замечания, прежде чем до человека дойдет, что так писать не стоит, что это вызывает гнев у коллег. И есть некоторые уникумы, которые привыкли писать в своем стиле, и чужое мнение им вообще не аргумент, но таких к счастью совсем немного. И со всеми из них приходится, так или иначе, через их код, иметь дело. Особая когорта разработчиков, т.н. летуны: кода человек приходит на проект, пишет ужасный код, а потом увольняется, а ты через несколько лет огребаешь последствия за него, и тебе приходится все это переписывать по-человечески, потому что возникла потребность внести изменения именно в этот функционал. Почему такое вообще возможно? Потому что такие проекты фактически не имеют владельца, кодом никто не владеет, нет ни правил, ни надзора, заказчик понятия не имеет как управлять кодом и что там вообще есть, ему просто нужно исправить или изменить функционал готового кода, и он даже согласен если конкретно ты все приведешь в порядок, но бюджетов на значительные изменения в коде просто нет, и ты либо 80-90% работы сверх задачи делаешь бесплатно, либо делаешь только конкретно тот объем работ, который тебе оплатили.
Поэтому на практике это иногда вызывает боль.
Также исключения - это часть неявного поведения, магии. А магия тоже иногда выстреливает и причиняет боль: ищи потом, кто и где изменил поведение кода, где эта магия спрятана, ведь явных связей в коде для магии просто нет.
Думаю именно поэтому авторы go и заложили такие строгие ограничения в свое детище: просто устали от проделок менее разумных коллег, и устали от магии.
Так что, на мой взгляд, пока подход go выглядит наиболее разумным. Тоже устал от таких коллег и от магии, поэтому всеми руками за явные контракты. Пусть даже и ценой некой многословности.
С явными контрактами всегда можно ткнуть на явную связь и пройтись по цепочке таких связей до источника проблемы. Даже без умных анализаторов IDE. Но явные связи упрощают работу и IDE: в других языках магия иногда просто не поддается автоматическому анализу, IDE не подсвечивают проблемы с ней, не видят неявные связи.
Встречал win 95 (или более древнюю, не углублялся) в относительно современных (15-17 год) китайских системах управления ЧПУ станками. Под нее еще и спецсофт с 3d кто-то писал (и наверняка поддерживает), чтобы все это работало в комплексе, бесшовно и незаметно.
С первого взгляда и не поймешь что там винда: при включении стойки сразу запускается управляющий софт, и видно только интерфейс этого софта. Но если софт крашнулся или его грохнуть, вываливаешься в винду. Так понял железо там было слабенькое, простенькое, но для задач управления ЧПУ его более чем хватает.
Выгорание несущественная проблема - моему OLED монику уже 3 года, светит часов по 10-12 в день, выгорания не заметил. На вечную работу не рассчитываю - через пару лет так или иначе наверняка будет замена на более совершенный вариант, какой-нибудь 8к или еще что-то. Так что технологии OLED уже на достаточном уровне, чтобы не беспокоится о выгорании.
А вот яркость и тепло для OLED большая проблема. Увы, греется оно как обогреватель: около 100Вт в тепло уходит, и все это в лицо идет, как будто в батарею смотришь и она тебя греет - экран ощутимо горячий, градусов 50, горячо, но еще не больно, руку держать можно. И яркость низкая: всего около 100-150 люмен при заливке всего экрана белым, получается грязно-серый цвет вместо белого, зато порядка 900-1000 люмен если яркий только небольшой участок - в играх получается красиво, звездное небо, луна и солнце, ночное освещение, прям большой контраст получается, почти как в реальности, фильмы в HDR можно спутать с видом из окна.
Но сомнительно что microled решат проблему яркости и тепла: высокая яркость так или иначе требует большого тока, а это опять много тепла. Возможно решение будет в лазерных технологиях, у них неплохая эффективность.
По тестам - результат очень сильно зависит от промта. Сильнее, чем в других модельках. Лучшие промты для qwen порождают дичайшую помесь иероглифов, в то время как самые простые промты выдают наилучший результат - видимо связано с дополнительным процессом рассуждения, сложные промты его по всей видимости искажают. Наилучший результат дал промт, в котором в начале инструкция перевести запрос пользователя на английский, а в конце просьба перевести ответ модели на русский, а также указание избегать китайского языка и символов, и уделить особое внимание корректной подаче терминов.
Так вот почему при заборе крови все время спрашивают, будет ли плохо, не нужно ли подстраховаться. Даже не подозревал что от вида крови может быть такая реакция.
Менеджер не лидер, он вообще по отношению к команде внешняя сущность. И, как уже тут сказали, команда его не примет как одного из своих, он не погружен в реалии кода. Менеджер это управленец, он владеет конкретным продуктом, ведет учет, управляет потоком задач на высоком уровне, следит за бюджетом и учитывает интересы продукта. Команда это исполнительный блок, группа специалистов разной квалификации и специализации, она разбирает поток задач и выполняет эти задачи наиболее эффективным способом, с учетом доступных ресурсов и компетенций. Слаженная команда может принадлежать нескольким проектам, а в случае разногласий иногда и фирму покидает в полном составе, такие случаи история уже знает. Тимлид тут это просто старший опытный разработчик, знакомый со спецификой кода, с бизнес-процессами, с реалиями корпоративных игр вышестоящих товарищей. Лид способен быть интерфейсом между командой и бизнесом, это наиболее грамотный, и в техническом плане, и в бизнес-плане, человек, который понимает о чем говорят вышестоящие товарищи, понимает их реальные потребности, и реальные ограничения текущего кода, понимает проблематику сверху и снизу. Лид способен перевести технические подробности на язык бизнеса, и бизнес-потребности на язык технарей. Его задача быть клеем, и внутри команды, и внутри бизнеса, оптимизировать процессы, пресекать тупняки, находить короткие пути решения тех или иных проблем, не учитывая никакие зоны ответственности, на чем спотыкаются обычные разработчики. Его задача быть крайним в команде, замыкать все внутренние вопросы и проблемы на себе, не допускать их утечки вовне, не допускать нарушения зон ответственности. Именно его будут нагружать разработчики всякими проблемами и непонятками, и он их разрешает за считанные минуты, тем самым избегая серьезных простоев на ровном месте, потому что без лида в таких случаях начинается игра в "горячую картошку", никто на себя ответственность не берет, и простейший технический вопрос утекает наверх, покидает зону ответственности технарей, и летает по всяким менеджерам и управленцам, которые не понимают что от них хотят и причем тут они вообще, и летать он там может неделями, что выглядит просто дико. Также задача лида - тактические, оперативные решения, внутри его сферы ответственности: многие вопросы или проблемы можно решить внутри команды, без привлечения внешних , и тем самым сократить время на всякую бюрократию, увеличить эффективность процессов - время ответа человека за пределами команды может достигать недели-двух, а пинг до лида обычно менее часа. И его задача быть ориентиром, вдохновлять молодых - как ни крути, но внутри команды самый большой авторитет именно у лида, новички к лиду обычно относятся особенно трепетно, в их глазах это чуть ли не человек-легенда, на его авторитет работает и огромный опыт, и роль, и тот факт что с ним считается бизнес и он постоянно пропадает на совещаниях с большими людьми, ну и личный фактор конечно же, рано или поздно лид окажет помощь каждому из команды, решит его проблему.
В целом разработка - процесс творческий, так что на конкретные сроки он не ложится, все зависит, если угодно, от музы.
Конечно всегда много шаблонной и более-менее предсказуемой рутины, но бывают и творческие задачи, или задачи на удачу, за которые никто не скажет как ее решить, и возможно ли ее решить в принципе.
Бывает на задачу выделено 40 часов бюджета, и первые 30 уходят на то, чтобы понять как к ней подступиться - в эти 30 часов могут быть перебрано несколько решений, от которых придется отказаться на той или иной стадии, кода вообще может не быть, потому что тупо крутишь идеи в голове и обсасываешь их, пока не проявится смутное чувство близости победы, "хм, а ведь если сделать вот так, то быть может все получится как надо, или хотя бы будем на шаг ближе к решению". Это как шахматная партия. И победить можно не всегда, но очень хочется.
Над одной из таких проблем пришлось несколько суток размышлять, делать предположения, опровергать их, отвергать идеи и решения, в итоге озарение пришло за полсуток до срока, который выделил на поиск решения или отказ. Смутная идея того, как раскусить проблему, пришла под струями душа, вечером, "ниоткуда" - мысль просто всплыла откуда-то из глубин. Думаю так мозг доносит результаты своей фоновой активности: частенько бывает, что решения приходят сами собой, если заранее загрузить в себя проблему, а потом просто заняться чем-то другим, через некоторое время решение просто начнет крутиться в голове, хотя сознательно им никто не занимался. Идея была смутной, и нестандартной, в эту сторону еще не думал ни я, ни мои предшественники, и чувствовалось что проработка этой идеи может либо приблизить к решению, либо щать само решение, так что с этой идеей было решено переспать, чтобы мозг дополнительно ее покрутил в фоне, как он это умеет. А на утро уже было целых два варианта на ее основе: полноценное решение, и частичное. Второе - чтобы облегчить жизнь бизнесу, на случай, если проблема все же окажется нерешаемой. Как итог все выгорело, а мне в копилку упал новый ценный инструмент для решения такого класса задач. Как оказалось, проблема эта была ежегодная, и никто даже не рассчитывал что она решаема: ежегодно, несколько лет подряд, бизнес кидался ей в команды сеньоров, которые каждый раз разводили руками, потому что после первичного анализа выяснялось, что проблема фундаментальна, и классические решения с ней не работают. Я же просто прошел на шаг дальше в анализе, разобрался какой именно фактор обламывает классическое решение. А также решил попробовать исключить этот фактор из проблемы: просто отсек его, "вынес за скобки". В результате проблема схлопнулась до тривиальной. Тут то и стало понятно, что таким же образом можно решать и другие "нерешаемые" классическим образом проблемы. Идея простая, но разработчиков никто не учит, что можно просто сделать шаг в сторону и изменить саму проблему.
Еще может быть такой кейс: лучше плохо, но сейчас, чем хорошо, но уже, быть может, никогда. В ситуациях, где важно время, решения могут быть менее аккуратными, важнее сам факт выполнения задачи, а не идеальность решения.
Если нужно выполнить код на другой машине, есть RPC.
Если нужна внешняя память или кеш, есть миллион специализированных сервисов, типа redis.
Если это попытка сэкономить ресурсы, то лучше просто обновить железо: на современном железе можно не думать о памяти и потоках. Бытовое железо позволяет крутить 32 потока, серверное - больше 256 потоков. Память измеряется десятками или тысячами гигов соответственно. И все это локально, без всяких игр с сетью, с минимальными задержками. Основная сложность на таком железе это максимально его нагрузить, что сделать совсем не просто.
А любая попытка экономить ресурсы таким сложным образом на слабом железе, это просто гарантированные лаги и задержки: физически не существует способа вовремя предсказать, когда потребуется подогреть код, который ради экономии ресурсов охладили. Накопление статистики по коду от лагов не избавляет - накопление статистики снижает процент промахов, снижает количество лагов, но лишь на фоне случая, когда лаги идут при каждом вызове функционала, на котором сэкономили, а в остальном это игра вслепую с минимальной эффективностью, человек с задачами оптимизации справляется гораздо эффективнее статистики. И любые подобные игры в оптимизацию в ситуации, когда ресурсов и так не хватает, это просто дополнительные накладные расходы: накопление статистики, логика оптимизатора и трансфер данных - это все тоже требует ресурсов.
Если действительно есть данные, которые нужно хранить постоянно, но которые достаточно быстро остывают, проще их просто вытеснять в какой-нибудь кеш по таймауту неактивности, это гораздо экономнее по ресурсам и проще по логике, промахи это не уберет, но также их снизит примерно до уровня реализации со сбором статистики. А уж для кешей готовых реализаций много: библиотечных, внешних, удаленных - каких угодно, это стандартный кирпичик современного софта.
А вообще на практике успешно работают следующие способы оптимизации:
грамотно расставленные по коду кеши: если что-то есть в кеше, это не требуется повторно вычислять. Если что-то нельзя кешировать, это можно распилить на статическую и динамическую часть, и кешировать статическую. Если динамическая часть имеет конечный и не очень большой набор вариантов - это тоже статическая часть
размен циклов на память. Например замена вычислений на выборку по смещению в предварительно посчитанной табличке или карте - этот лайфхах еще из докомпьютерной эпохи
оптимизация под железо. Горячую часть кода упрощают и уменьшают, чтобы подольше не выходить за пределы аппаратных кешей. Данные читают и размещают последовательно, чтобы работали механизмы аппаратной предзагрузки на всех уровнях и аппаратные кеши не опустошались. Заранее прогревают программные кеши запросом или вычиткой данных, до того как запустится горячая часть кода. Также на железо хорошо ложится функциональный подход, коллекции и потоки: оно однотипно, последовательно, и содержит меньше условных операторов, чем традиционный код
размен циклов на время. Например сжатие больших кешей или отправляемых данных, если они хорошо жмутся: это дает дополнительную нагрузку на cpu, но ускоряет ввод/вывод в 5-10 раз. Жмут современные cpu быстро, хватает на большинство каналов ввода/вывода. Если cpu систематически недогружен и много текстового ввода/вывода, появляется возможность использовать такой размен
Просто комбинируя эти принципы можно ускорить код на 2-3 порядка практически на ровном месте
Вот и у меня странное антибликовое покрытие. Очень непривычно после матового пластика. Поверхность глянцевая, сама панель стеклянная, ожидается сильный зеркальный эффект, но на зеркало это не похоже, отражения есть, они четкие, но очень темные, на практике их не видно, они не мешают, и уловить их можно только на черных участках, и сами блики необычные, не слепят, и красиво рассыпаются на фрагменты.
Похоже на описание "ночного режима". Есть из коробки во многих смартфонах, в win11 и KDE. По дефолту настраивается на время активности "от заката до рассвета". Как раз уводит картинки в янтарные оттенки.
Если позитрон живет в антивремени и существует в нашей вселенной, и известно что из квантовой пены могут возникать частицы и античастицы, то логично предположить что вселенная и антивселенная, время и антивремя, существуют в одном и том же пространстве, и квантовая пена как раз является проявлением этого. Далее логично предположить, что если вселенная и антивселенная находятся в одном пространстве, и существует такое явление как квантовая пена, свидетельствующее о том, что вселенная и антивселенная в каких-то местах в какие-то особые моменты могут взаимодействовать друг с другом, обмениваться материей в небольших точках, в которых нарушается равновесие, то, уже чисто по теории вероятности и закона больших чисел, где-то в пространстве просто обязаны существовать огромные регионы, где это самое равновесие нарушено, и вместо квантовой пены там должны наблюдаться квантовые штормы, с огромными объемами чужеродной материи и другими спецэффектами, такими например как источники антигравитации - если антигравитация хоть как-то может быть связана с антивселенной, то она будет именно там, в этих регионах.
Сейчас много всяких карманных игровых приставок расплодилось, по образу стимдека, на любой вкус и кошелек. Смотрю их ремонты - там то винда, то linux. И железо приближается к ноутбучному, и оно там не армовское, а вполне себе x64. Выглядит как неплохая замена ноута для путешествий: мощное железо и тонны памяти на борту уже есть, батарейки огромные, рассчитанные на игры, для работы хватит явно дольше чем на игры, добавить сюда очки и какой-нибудь более-менее удобный манипулятор или клавиатуру, приспособленную чтобы можно было работать без стола, сидя в самолете или поезде например, и комплект готов. Но повыбирать конечно придется - в таких девайсах всегда все костылями усеяно, железо кастомное, без танцев ось не поставить, а если поставить, то не факт что дрова под весь этот зоопарк найдутся, так что велика вероятность остаться на той оси, что заложил производитель изначально.
в kde можно включить тайлинг через kwin-скрипты
мне больше понравился kde-tiling-on-drag: сетка настраивается мышкой, окна можно быстро привязывать к сетке или держать вне сетки, получается гибкая раскладка под любые задачи
Если это тестовые сервера, то там программеры, кто на vscode, разворачивают vscode backend, и работают как у себя на машине, и с консолью обычно не сталкиваются. Если это продовые сервера, то простых программеров туда никто не пустит, и опять же с консолью они опять не сталкиваются. Так что для начинающих взаимодействие с консолью это скорее личный выбор: кто-то упорно остается в IDE, кто-то осваивает консоль, из-под палки никого никуда не загоняют.
Но личный опыт говорит о том, что IDE для начинающих все же предпочтительнее: сначала стоит сосредоточиться непосредственно на самом коде и управлением им, а уже потом можно расширять свой набор инструментов, осваивая что-то за пределами IDE. Потому что начинающие программеры, которые пытаются сразу работать с голым git, совершают слишком много ошибок, и ловят сильную демотивацию, иногда публично.
Например довольно распространенные ошибки: заливают лишнее или забывают заливать необходимое, заливают конфликты в промежуточном состоянии, разрушая код, заливают код с грубыми синтаксическими ошибками, т.е. вообще неспособный к компиляции/запуску код, случайно заливают массовые удаления тысяч файлов, а то и всего кода проекта, даже такие случаи в практике были, и неоднократно.
Все эти ошибки - детские, грубые, легко обнаружимые и легко исправляемые, но при наличии хотя бы минимального опыта, которого у начинающих просто нет.
Консоль требует больше понимания, ответственности и внимательности, чем IDE, в консоли нет AST-анализаторов, которые в IDЕ на такое сразу пнут красными метками, нет удобного и наглядного представления, и, откровенно говоря, многих консоль пугает, она сыпет непонятными ошибками на неродном языке, что приводит к панике, а если в спешке, то и к дополнительным, более грубым, ошибкам.
Конечно на стороне инфраструктуры от таких ошибок можно защититься, но это встречается на хорошо развитой инфраструктуре: перед принятием правок в git, код должен пройти валидацию автоматическими проверками на хуках, а после еще и пройти через пайплайны CI/CD, успешно пройти тесты.
Но до сих пор много где есть только голый git с ненастроенными хуками и отсутствующим ci/cd, и без каких-либо тестов. В таких окружениях программера автоматика не подстраховывает, а потому эти ошибки неизбежно вскрываются, и все внутри команды видят их, и отлично понимают, кто именно из них так начудил. И тот, кто начудил, тоже отлично понимает, что остальные отлично видят его факап, и иногда начинает накручивать себя, загоняться, со всеми вытекающими.
В итоге эти ошибки могут дорого стоить, в первую очередь воздействуя на саму команду, на ее мотивацию. После таких факапов, программер не просто обжигается, но и понимает что теряет репутацию в глазах коллег и руководства, получает негатив, демотивацию. Усиливает ее тот факт, что даже у менее опытных коллег, которые работают в IDE, таких ошибок не возникает: их подстраховывает IDE, ярко указывая на наличие проблемы, и иногда даже предлагая автоисправление.
Чтобы пройти дальше по карьере, важно уметь этот негатив в себе подавлять: нужно держать в уме, что все мы люди, все мы человеки, все мы ошибаемся, это неизбежно. Неизбежно, но это все равно неприятно, а работать с этим мало кто умеет. Многие не дают себе права на ошибку, принимают близко к сердцу, чего делать нельзя. Иногда некоторые не дают права на ошибку не только себе, но и другим - начинают охоту на ведьм, чего делать категорически нельзя: ошибиться может каждый, обвинения не принесут пользы, только усилят демотивацию. Иногда такие ошибки даже приводят к импульсивному уходу из профессии, что вообще абсурд - нельзя получить опыт, не набив шишек. Но факт есть факт: немногие способны адекватно воспринимать свои факапы и работать над собой. Особенно больно это бьет по психике и мотивации именно начинающих. Поэтому лучше уж начинать с IDE, а уже потом осваивать консоль и git, когда будет больше опыта, понимания и уверенности.
Консоль выручает там, где нет доступа к другим инструментам. Но начинающим разработчикам о таком можно даже не задумываться - такое они встретят не скоро, а может и никогда, сильно зависит от фирмы и организации производственных процессов в ней. Будет потребность - будет и опыт, переживать об этом заранее не стоит. Тем более ничего виртуозного на практике от git в таких кейсах не требуется: всякие конфликты решаются заранее, в удобном окружении, в GUI/IDE, а вручную остается только ветку переключить на нужную. В консоли процесс может облегчить tui, но, как правило, там, где нет доступа к инструментам, нет и tui - только голый git, и это в лучшем случае.
Кто плотно работает с нативным ssh, тем тоже зайдет именно голый git: ssh позволяет со временем подстроить рабочий процесс под себя, автоматизировать всю рутину, написать конфиги и сценарии, и выполнять код удаленно, в том числе через разные гейты, прокси и vpn, одной простой командой-псевдонимом. И все это великолепие очень доступно, доступнее любой IDE, буквально под кончиками пальцев, прямо в системном шелле: нажал f12 или ctrl+alt+t, набрал 2-3 буквы, tab, enter, и нужная автоматика пришла в движение, инициировав какие-то процессы на нужном тебе сервере.
Если серверов много, у каждого свои реалии, и все это завязано на тебе - самое то. Конечно можно и на стороне сервера это автоматизировать, но это значительно сложнее: таких полномочий у разработчиков обычно нет, нужно подключать бюрократию, админов, раскатывать ci/cd - в общем людей тут задействуется гораздо больше, добро на это получить значительно сложнее, и, не смотря на то, что это корректнее и эффективнее, выгоднее бизнесу, бизнес-решения штука довольно нелогичная, на практике такое доступно далеко не всегда, а родной ssh под рукой всегда, служит тебе верно, быстро и надежно, и ни от кого, кроме тебя, не зависит.
Чтобы кого-то засудить, нужно самому быть чистым перед законом. Сложно представить сценарий, чтобы преступник, неоднократно предпринимавший попытки взломать чужой сайт, подал в суд на то, что его атаковала защита и уронила его абсолютно незаконный скрипт. В таком сценарии при любых раскладах самому преступнику прилетит куда больше, чем владельцу сайта.
Ага, за хранение нулей срок 25 лет
В старые серии баттлы играют намного больше, чем показывает статистика. По каждой из серии есть по несколько сообществ, которые пишут под них свои лаунчеры и собирают свои сервера, под свою сборку. Также сюда добавляются глобальные модификации, которые стоят особняком, как например project reality
А он на это и не рассчитан. Его ниша - cli-утилиты, мелкие сервера и микросервисы. Что-то большое на нем писать - это страшно даже представить, какая боль это будет. Но крупные проекты редко представляют из себя огромный монолит. Обычно это взаимосвязанный набор сервисов, вспомогательных инструментов, и инфраструктуры, целый зоопарк языков и множество команд разработчиков.
В теории да, удобно, можно не обрабатывать не обязательные или маловероятные ошибки, меньше кода.
На практике тут все ломает человеческий фактор. Особенно в чужом легаси коде, на котором заказчик хорошо скроил, и который писало десяток подрядчиков разного уровня - мягко говоря мешанина стилей и подходов, и тонны кода настолько низкого качества, которое и воображению не поддается. Реально: некоторые фрагменты кода даже специально написать практически невозможно, настолько они бессвязны, настолько грубые ошибки имеют, как будто их писал даже не джун, а ребенок, который только-только приступил к изучению языка.
Скрытый текст
Человеческий фактор вообще неприятная штука. На рынке достаточно много разработчиков, которые не будут делать не обязательные вещи, даже если их об этом прямо попросить. Лично сталкивался с такими: иногда нужно 2-3 замечания, прежде чем до человека дойдет, что так писать не стоит, что это вызывает гнев у коллег. И есть некоторые уникумы, которые привыкли писать в своем стиле, и чужое мнение им вообще не аргумент, но таких к счастью совсем немного. И со всеми из них приходится, так или иначе, через их код, иметь дело. Особая когорта разработчиков, т.н. летуны: кода человек приходит на проект, пишет ужасный код, а потом увольняется, а ты через несколько лет огребаешь последствия за него, и тебе приходится все это переписывать по-человечески, потому что возникла потребность внести изменения именно в этот функционал. Почему такое вообще возможно? Потому что такие проекты фактически не имеют владельца, кодом никто не владеет, нет ни правил, ни надзора, заказчик понятия не имеет как управлять кодом и что там вообще есть, ему просто нужно исправить или изменить функционал готового кода, и он даже согласен если конкретно ты все приведешь в порядок, но бюджетов на значительные изменения в коде просто нет, и ты либо 80-90% работы сверх задачи делаешь бесплатно, либо делаешь только конкретно тот объем работ, который тебе оплатили.
Поэтому на практике это иногда вызывает боль.
Также исключения - это часть неявного поведения, магии. А магия тоже иногда выстреливает и причиняет боль: ищи потом, кто и где изменил поведение кода, где эта магия спрятана, ведь явных связей в коде для магии просто нет.
Думаю именно поэтому авторы go и заложили такие строгие ограничения в свое детище: просто устали от проделок менее разумных коллег, и устали от магии.
Так что, на мой взгляд, пока подход go выглядит наиболее разумным. Тоже устал от таких коллег и от магии, поэтому всеми руками за явные контракты. Пусть даже и ценой некой многословности.
С явными контрактами всегда можно ткнуть на явную связь и пройтись по цепочке таких связей до источника проблемы. Даже без умных анализаторов IDE. Но явные связи упрощают работу и IDE: в других языках магия иногда просто не поддается автоматическому анализу, IDE не подсвечивают проблемы с ней, не видят неявные связи.
Встречал win 95 (или более древнюю, не углублялся) в относительно современных (15-17 год) китайских системах управления ЧПУ станками. Под нее еще и спецсофт с 3d кто-то писал (и наверняка поддерживает), чтобы все это работало в комплексе, бесшовно и незаметно.
С первого взгляда и не поймешь что там винда: при включении стойки сразу запускается управляющий софт, и видно только интерфейс этого софта. Но если софт крашнулся или его грохнуть, вываливаешься в винду. Так понял железо там было слабенькое, простенькое, но для задач управления ЧПУ его более чем хватает.
Выгорание несущественная проблема - моему OLED монику уже 3 года, светит часов по 10-12 в день, выгорания не заметил. На вечную работу не рассчитываю - через пару лет так или иначе наверняка будет замена на более совершенный вариант, какой-нибудь 8к или еще что-то. Так что технологии OLED уже на достаточном уровне, чтобы не беспокоится о выгорании.
А вот яркость и тепло для OLED большая проблема. Увы, греется оно как обогреватель: около 100Вт в тепло уходит, и все это в лицо идет, как будто в батарею смотришь и она тебя греет - экран ощутимо горячий, градусов 50, горячо, но еще не больно, руку держать можно. И яркость низкая: всего около 100-150 люмен при заливке всего экрана белым, получается грязно-серый цвет вместо белого, зато порядка 900-1000 люмен если яркий только небольшой участок - в играх получается красиво, звездное небо, луна и солнце, ночное освещение, прям большой контраст получается, почти как в реальности, фильмы в HDR можно спутать с видом из окна.
Но сомнительно что microled решат проблему яркости и тепла: высокая яркость так или иначе требует большого тока, а это опять много тепла. Возможно решение будет в лазерных технологиях, у них неплохая эффективность.
По тестам - результат очень сильно зависит от промта. Сильнее, чем в других модельках. Лучшие промты для qwen порождают дичайшую помесь иероглифов, в то время как самые простые промты выдают наилучший результат - видимо связано с дополнительным процессом рассуждения, сложные промты его по всей видимости искажают. Наилучший результат дал промт, в котором в начале инструкция перевести запрос пользователя на английский, а в конце просьба перевести ответ модели на русский, а также указание избегать китайского языка и символов, и уделить особое внимание корректной подаче терминов.
Так вот почему при заборе крови все время спрашивают, будет ли плохо, не нужно ли подстраховаться. Даже не подозревал что от вида крови может быть такая реакция.
Менеджер не лидер, он вообще по отношению к команде внешняя сущность. И, как уже тут сказали, команда его не примет как одного из своих, он не погружен в реалии кода. Менеджер это управленец, он владеет конкретным продуктом, ведет учет, управляет потоком задач на высоком уровне, следит за бюджетом и учитывает интересы продукта. Команда это исполнительный блок, группа специалистов разной квалификации и специализации, она разбирает поток задач и выполняет эти задачи наиболее эффективным способом, с учетом доступных ресурсов и компетенций. Слаженная команда может принадлежать нескольким проектам, а в случае разногласий иногда и фирму покидает в полном составе, такие случаи история уже знает. Тимлид тут это просто старший опытный разработчик, знакомый со спецификой кода, с бизнес-процессами, с реалиями корпоративных игр вышестоящих товарищей. Лид способен быть интерфейсом между командой и бизнесом, это наиболее грамотный, и в техническом плане, и в бизнес-плане, человек, который понимает о чем говорят вышестоящие товарищи, понимает их реальные потребности, и реальные ограничения текущего кода, понимает проблематику сверху и снизу. Лид способен перевести технические подробности на язык бизнеса, и бизнес-потребности на язык технарей. Его задача быть клеем, и внутри команды, и внутри бизнеса, оптимизировать процессы, пресекать тупняки, находить короткие пути решения тех или иных проблем, не учитывая никакие зоны ответственности, на чем спотыкаются обычные разработчики. Его задача быть крайним в команде, замыкать все внутренние вопросы и проблемы на себе, не допускать их утечки вовне, не допускать нарушения зон ответственности. Именно его будут нагружать разработчики всякими проблемами и непонятками, и он их разрешает за считанные минуты, тем самым избегая серьезных простоев на ровном месте, потому что без лида в таких случаях начинается игра в "горячую картошку", никто на себя ответственность не берет, и простейший технический вопрос утекает наверх, покидает зону ответственности технарей, и летает по всяким менеджерам и управленцам, которые не понимают что от них хотят и причем тут они вообще, и летать он там может неделями, что выглядит просто дико. Также задача лида - тактические, оперативные решения, внутри его сферы ответственности: многие вопросы или проблемы можно решить внутри команды, без привлечения внешних , и тем самым сократить время на всякую бюрократию, увеличить эффективность процессов - время ответа человека за пределами команды может достигать недели-двух, а пинг до лида обычно менее часа. И его задача быть ориентиром, вдохновлять молодых - как ни крути, но внутри команды самый большой авторитет именно у лида, новички к лиду обычно относятся особенно трепетно, в их глазах это чуть ли не человек-легенда, на его авторитет работает и огромный опыт, и роль, и тот факт что с ним считается бизнес и он постоянно пропадает на совещаниях с большими людьми, ну и личный фактор конечно же, рано или поздно лид окажет помощь каждому из команды, решит его проблему.
Все это знакомо.
В целом разработка - процесс творческий, так что на конкретные сроки он не ложится, все зависит, если угодно, от музы.
Конечно всегда много шаблонной и более-менее предсказуемой рутины, но бывают и творческие задачи, или задачи на удачу, за которые никто не скажет как ее решить, и возможно ли ее решить в принципе.
Бывает на задачу выделено 40 часов бюджета, и первые 30 уходят на то, чтобы понять как к ней подступиться - в эти 30 часов могут быть перебрано несколько решений, от которых придется отказаться на той или иной стадии, кода вообще может не быть, потому что тупо крутишь идеи в голове и обсасываешь их, пока не проявится смутное чувство близости победы, "хм, а ведь если сделать вот так, то быть может все получится как надо, или хотя бы будем на шаг ближе к решению". Это как шахматная партия. И победить можно не всегда, но очень хочется.
Над одной из таких проблем пришлось несколько суток размышлять, делать предположения, опровергать их, отвергать идеи и решения, в итоге озарение пришло за полсуток до срока, который выделил на поиск решения или отказ. Смутная идея того, как раскусить проблему, пришла под струями душа, вечером, "ниоткуда" - мысль просто всплыла откуда-то из глубин. Думаю так мозг доносит результаты своей фоновой активности: частенько бывает, что решения приходят сами собой, если заранее загрузить в себя проблему, а потом просто заняться чем-то другим, через некоторое время решение просто начнет крутиться в голове, хотя сознательно им никто не занимался. Идея была смутной, и нестандартной, в эту сторону еще не думал ни я, ни мои предшественники, и чувствовалось что проработка этой идеи может либо приблизить к решению, либо щать само решение, так что с этой идеей было решено переспать, чтобы мозг дополнительно ее покрутил в фоне, как он это умеет. А на утро уже было целых два варианта на ее основе: полноценное решение, и частичное. Второе - чтобы облегчить жизнь бизнесу, на случай, если проблема все же окажется нерешаемой. Как итог все выгорело, а мне в копилку упал новый ценный инструмент для решения такого класса задач. Как оказалось, проблема эта была ежегодная, и никто даже не рассчитывал что она решаема: ежегодно, несколько лет подряд, бизнес кидался ей в команды сеньоров, которые каждый раз разводили руками, потому что после первичного анализа выяснялось, что проблема фундаментальна, и классические решения с ней не работают. Я же просто прошел на шаг дальше в анализе, разобрался какой именно фактор обламывает классическое решение. А также решил попробовать исключить этот фактор из проблемы: просто отсек его, "вынес за скобки". В результате проблема схлопнулась до тривиальной. Тут то и стало понятно, что таким же образом можно решать и другие "нерешаемые" классическим образом проблемы. Идея простая, но разработчиков никто не учит, что можно просто сделать шаг в сторону и изменить саму проблему.
Еще может быть такой кейс: лучше плохо, но сейчас, чем хорошо, но уже, быть может, никогда. В ситуациях, где важно время, решения могут быть менее аккуратными, важнее сам факт выполнения задачи, а не идеальность решения.
Выглядит как изобретение велосипеда.
Если нужно выполнить код на другой машине, есть RPC.
Если нужна внешняя память или кеш, есть миллион специализированных сервисов, типа redis.
Если это попытка сэкономить ресурсы, то лучше просто обновить железо: на современном железе можно не думать о памяти и потоках. Бытовое железо позволяет крутить 32 потока, серверное - больше 256 потоков. Память измеряется десятками или тысячами гигов соответственно. И все это локально, без всяких игр с сетью, с минимальными задержками. Основная сложность на таком железе это максимально его нагрузить, что сделать совсем не просто.
А любая попытка экономить ресурсы таким сложным образом на слабом железе, это просто гарантированные лаги и задержки: физически не существует способа вовремя предсказать, когда потребуется подогреть код, который ради экономии ресурсов охладили. Накопление статистики по коду от лагов не избавляет - накопление статистики снижает процент промахов, снижает количество лагов, но лишь на фоне случая, когда лаги идут при каждом вызове функционала, на котором сэкономили, а в остальном это игра вслепую с минимальной эффективностью, человек с задачами оптимизации справляется гораздо эффективнее статистики. И любые подобные игры в оптимизацию в ситуации, когда ресурсов и так не хватает, это просто дополнительные накладные расходы: накопление статистики, логика оптимизатора и трансфер данных - это все тоже требует ресурсов.
Если действительно есть данные, которые нужно хранить постоянно, но которые достаточно быстро остывают, проще их просто вытеснять в какой-нибудь кеш по таймауту неактивности, это гораздо экономнее по ресурсам и проще по логике, промахи это не уберет, но также их снизит примерно до уровня реализации со сбором статистики. А уж для кешей готовых реализаций много: библиотечных, внешних, удаленных - каких угодно, это стандартный кирпичик современного софта.
А вообще на практике успешно работают следующие способы оптимизации:
грамотно расставленные по коду кеши: если что-то есть в кеше, это не требуется повторно вычислять. Если что-то нельзя кешировать, это можно распилить на статическую и динамическую часть, и кешировать статическую. Если динамическая часть имеет конечный и не очень большой набор вариантов - это тоже статическая часть
размен циклов на память. Например замена вычислений на выборку по смещению в предварительно посчитанной табличке или карте - этот лайфхах еще из докомпьютерной эпохи
оптимизация под железо. Горячую часть кода упрощают и уменьшают, чтобы подольше не выходить за пределы аппаратных кешей. Данные читают и размещают последовательно, чтобы работали механизмы аппаратной предзагрузки на всех уровнях и аппаратные кеши не опустошались. Заранее прогревают программные кеши запросом или вычиткой данных, до того как запустится горячая часть кода. Также на железо хорошо ложится функциональный подход, коллекции и потоки: оно однотипно, последовательно, и содержит меньше условных операторов, чем традиционный код
размен циклов на время. Например сжатие больших кешей или отправляемых данных, если они хорошо жмутся: это дает дополнительную нагрузку на cpu, но ускоряет ввод/вывод в 5-10 раз. Жмут современные cpu быстро, хватает на большинство каналов ввода/вывода. Если cpu систематически недогружен и много текстового ввода/вывода, появляется возможность использовать такой размен
Просто комбинируя эти принципы можно ускорить код на 2-3 порядка практически на ровном месте
Вот и у меня странное антибликовое покрытие. Очень непривычно после матового пластика. Поверхность глянцевая, сама панель стеклянная, ожидается сильный зеркальный эффект, но на зеркало это не похоже, отражения есть, они четкие, но очень темные, на практике их не видно, они не мешают, и уловить их можно только на черных участках, и сами блики необычные, не слепят, и красиво рассыпаются на фрагменты.
Отражение солнечного луча от стеклянной панели
Похоже на описание "ночного режима". Есть из коробки во многих смартфонах, в win11 и KDE. По дефолту настраивается на время активности "от заката до рассвета". Как раз уводит картинки в янтарные оттенки.
KDE
Если позитрон живет в антивремени и существует в нашей вселенной, и известно что из квантовой пены могут возникать частицы и античастицы, то логично предположить что вселенная и антивселенная, время и антивремя, существуют в одном и том же пространстве, и квантовая пена как раз является проявлением этого. Далее логично предположить, что если вселенная и антивселенная находятся в одном пространстве, и существует такое явление как квантовая пена, свидетельствующее о том, что вселенная и антивселенная в каких-то местах в какие-то особые моменты могут взаимодействовать друг с другом, обмениваться материей в небольших точках, в которых нарушается равновесие, то, уже чисто по теории вероятности и закона больших чисел, где-то в пространстве просто обязаны существовать огромные регионы, где это самое равновесие нарушено, и вместо квантовой пены там должны наблюдаться квантовые штормы, с огромными объемами чужеродной материи и другими спецэффектами, такими например как источники антигравитации - если антигравитация хоть как-то может быть связана с антивселенной, то она будет именно там, в этих регионах.