Всё уже придумали, проблема в скорости шины, это сразу становится горлышком. Видеокарта это такая тварь, которая требует не только много питания, но и много шины. Я бы сказал что видеокарты в потребительских ПК - основной потребитель ширины PCI Express, по сравнению с которым всё остальное (SSD, USB/TB) это слёзы.
Это вопрос выбора "базы данных" для хранения таких поясняющих комментариев. Гит - это распределённая система, и всё что у вас в истории можно в две команды перелить с какого-нибудь Bitbucker Server на Gitlab или какой-нибудь Gitea. А мигрировать содержимое Jira уже сложнее.
Если бы не 2022-й, я бы тоже не считал это проблемой, но 2022-й случился.
Надо, вроде, чтобы весь код работал правильно и согласованно, а не каждый коммит по отдельности?
А это уж как вы организовали у себя в проекте/команде. Я прошу разработчиков делать атомарные коммиты, которые переводят репозиторий из одного работающего состояния в другое работающее (включая компилируемость кода и проходящие юнит-тесты). Да, это не всегда удаётся, поэтому у нас договорённость - если в коммите что-то сломано и починится в следующем, желательно об этом написать.
Сейчас многие проекты выбрали для себя единицей изменений именно МР, а коммиты остаются целиком инструментом для автора кода - коммить когда вздумается, всё равно мы будем смотреть только весь МР сразу. Это может работать, но становится неподъёмным, когда количество ревью через одного человека резко возрастает (например, команда за полгода увеличилась в 2-3 раза). Тогда начинаешь задумываться о том, что коммиты неплохо бы использовать по их изначальному назначению: как атомарную единицу изменений в проекте.
Как разбивка на коммиты помогает понять, что происходит в коде, стесняюсь спросить?
Ну если коммит-мессадж такой: "fixed a bug", то никак не помогает. А если коммит-мессадж такой, то в код можно и не смотреть в теории. По крайней мере смотреть в код придётся только ревьюеру, а если кто-то позже придёт почитать - коммит-мессадж будет даже полезнее кода.
В общем целом я бы сказал что лучше небольшой самостоятельный МР из одного коммита, чем большой МР из десятка коммитов.
Это безусловно так и есть. Не знаю ни одного разработчика и ревьюера, который просил бы побольше изменений закинуть в один МР вместо нескольких. Но МР для того и придумали, что это такая единица изменений/работы над проектом, которую можно целиком применить, а потом целиком откатить, если припекло. И такая единица далеко не всегда будет совпадать с единицей "загрузки изменений в голову читателя" (коммитом), т.к. первая обычно значительно больше.
Понятное дело что в любом приличном проекте есть feature flags и подобные штуки, чтобы не показывать юзерам недопиленные фичи, но всё же это касается в основном нового кода. Недорефакторенный старый код в прод не выкатишь, а значит недоделанный МР не смёржишь (разумеется сегодня бизнес хочет релизиться если каждый день, то в любом момент когда потребуется, поэтому мастер/релизная-ветка должна быть всегда в рабочем состоянии).
Так что "маленькие" МР — это здорово, но встречается довольно редко. Обычно когда мне приходит МР с одним коммитом - это человек просто не умеет пользоваться коммитами и напихал кучу изменений в один коммит, а мне теперь как-то за 20 минут нужно успеть понять, что в нём происходит (иначе я ничего не успею). Так что текст коммита — это скорее механизм работы с головой читателя кода, и кмк его полезно использовать.
Ну и что хорошего в том, что вы не смотрите на текст коммита? Почему не сделать из этого инструмент и не начать им пользоваться?
Нет, я понимаю к чему вы про забор: в прод пойдёт код, а не текст коммита. Но можно сидеть 20 минут пытаться понять чего именно добивался человек этими изменениями, а можно прочитать текст коммита и понятно станет за 3 минуты.
Кроме того, правильное пользование коммитами позволяет автору кода загружать изменения в голову ревьюера правильными порциями. В моём случае это вообще самое важное: чтобы не зависать на каждом МР на час (коих за день может быть с десяток-другой), я прошу перед отправкой на ревью сделать нормальные коммиты, чтобы можно было смотреть ревью по ним, а не сразу всё.
Большинcтво компонентов софта не живет больше 1-2 лет, за исключением энтерпрайза и некоторых других исключений, не надо думать и закладывать туда все возможное и делать максимально универсально.
Тут что-то на фронтэндерском, не получается прочитать.
Как вы на HH определяете, как развивается карьера отдельных людей? Вот у меня из пяти знакомых:
трое ушли с десктопного C++ на бэкенд и Go;
ещё один перешёл с Electron на бэкенд (тоже Go);
ещё один хотел бы перейти с Electron на бэкенд (пока этого не сделал, но сделает как только пройдёт собесы в интересующие его компании). Правда этот парень бывший плюсовик, на Electron его занесло скорее вынужденно.
Причём и не скажешь, что они ушли из какой-то одной компании (где было всё сильно плохо) или пришли в какую-то одну компанию (где было всё сильно хорошо), компании разные. Справедливости ради, есть и такой знакомый, который остался на десктопном C++, но уехал из РФ в стартап с довольно щедрыми зарплатами, поэтому всем доволен и так.
Зайдите на стримы к разных популярным ребятам, и посмотрите на качество их картинки. А потом посмотрите на их сетап. Ну например: Sony A7 IV и Sony A7С (да, аж две камеры сразу, чтобы красиво было!).
Пока Microsoft, Apple и прочие гиганты бились за звание главной платформы для запуска клиентского кода, Google тихонечко закатила всем в огород троянского коня в виде Хрома. И получилась такая вот интересная ситуация, что теперь "операционной системой" (а точнее, средой для работы клиентского приложения) является браузер, а не натив. И эта среда победила. Почему - уже написали предыдущие комментаторы.
JS и сейчас относительно конченный язык, а году в 2013-м это был ад и Израиль. И ничего, все пошли колоться об этот кактус. Чтобы писать под победившую среду запуска клиентского кода. Побежали все переписывать старые проекты - MS переписала Офис, Гугл же написал свой офис сразу в вебе.
Уже все и забыли, что "Веб" - это про организацию информации прежде всего, а не про HTML/CSS/JS.
Теперь разработчиков под нативный десктоп и нет толком. Точнее, они есть, но им за их знания заплатят намного больше, например, на бэкенде. А над клиентским десктопом можно издеваться, память-то там клиентская, она "бесплатная" для компании, в отличие от памяти на серверах.
Зато навалом разрабов под браузер, стоят они приемлемо, вот и вся история.
Вот на мобилках ресурсов поменьше, и там веба почти нет - каждый второй проект делает себе приложение и переманивает туда всякого, кто зашёл на сайт с мобилы.
А, самое главное: на десктопах толком не прижились магазины приложений. На мобилках юзеров к этому приучили с горшка, и проблема деливери/автоапдейта была решена на корню. А десктоп уже слишком стар как концепция, чтобы его юзеров можно было заставить что-то делать иначе. Microsoft Store почти никому не нужен, Snap Store тоже, разве что на Маке удалось более-менее посадить на их магаз.
А задача - открывать на просмотр такие архивы, ибо распаковывать их целиком просто для "посмотреть" - это практически нереально. Вернее, когда у вас ext4 на NVMe-диске - может и реально, но не когда NTFS на магнитном.
Вполне себе хранятся миллионы файлов и на ноуте с NTFS
Хранятся-то они замечательно, вы попробуйте удалить их потом. Задача на полдня примерно. Если бы всё так было хорошо с NTFS, зачем бы тогда MS придумала использовать ReFS в своей фиче Dev Drive.
Если я распакую каждый архив из 105-гигайбайтовой утечки исходников Twitch-а, у меня ФС загнётся от количества файлов. Зачем, если можно архиватором вытаскивать нужные подпапки?
“Вот понаберут глупых новичков, а мне потом за ними РАЗГРЕБАТЬ!”. Что это за инженер с 10-летним опытом, вынужденный исправлять ошибки за сокомандником? Почему крутые специалисты просто не откажут неадекватным кандидатам, не пустив их в свой продукт?
Так, стоп. Разве это не гейткипинг? Т.е. вся остальная статья не имеет смысла? Почему спрашиваю: потому что для меня это основной (если не единственный) аргумент заливать про Таненбаума, CS и всё прочее. Хочется в какой-то момент перестать подтирать за человеком, а он пока даже не понимает, а почему, собственно, за ним подтёрли.
Самый эффективный инструмент для трудоустройства и зарплатного роста в IT
Чтобы контент приносил результат, его надо выпускать регулярно. Только так вы добьетесь нужного количества касаний с нужной аудиторией. Это значит, что делать одну висишку раз в полгода — это не контент-маркетинг.
Как-то всё это грустно. Про «регулярно», про «касания». Когда автор прибегает к помощи редакторов/писателей/прочих специалистов по выражению мыслей и идей в достойном виде — тогда и результат достойный. А вот когда делается наоборот, потому что нужны «касания» — такое себе.
Впрочем, о чём это я, я же просто не с той стороны рта нахожусь. Люди работу работают, а мы потом будем выискивать сокровища в информационной свалке.
А вот за эту статью спасибо! Вот её как раз писали именно те люди, которые «кто ручками каждый день в ней [теме] ковыряется».
Как скоро они выгорят от не своей работы?
Неужели хороших авторов настолько мало и они настолько недоступны, что не вариант идти по пути их выращивания и менторства?
что тестирование не гарантирует правильность программы и вообще не является инструментом разработки
По большей части с вами согласен. В том числе поэтому считаю статическую типизацию (например) куда более важным инструментом, чем тесты. Те же модульные тесты нужны прежде всего чтобы: а) дать самодокументацию в виде каких-то кейсов, чтобы на ревью или при рефакторинге читающий не спрашивал "а вот это будет работать?", "а вот такой кейс предусмотрели?". Все ответы уже заготовлены в виде тестов, а если что-то пропущено - то лучше в виде очередного теста и добавить. Это по сути одна из самых лучших форм документации - никогда не устаревает, в отличие от просто рукописного текста. б) "заткнуть" какие-то краевые ситуации, которые не может покрыть статическая типизация. Обычно если в языке с типизацией не очень, тестов приходится писать намного больше. И с другой стороны, если типизация очень сильная, то язык программирования превращается в язык доказательства теорем, и в таком языке модульные тесты и не нужны, потому что если программа компилируется - скорее всего она корректна.
Я скорее говорил о том, что никто не будет выводить в прод написанный за полчаса алгоритм или структуру данных без должного тестирования, а тестирование отдельных алгоритмов это в 99% случаев именно unit-тестирование.
Всё уже придумали, проблема в скорости шины, это сразу становится горлышком. Видеокарта это такая тварь, которая требует не только много питания, но и много шины. Я бы сказал что видеокарты в потребительских ПК - основной потребитель ширины PCI Express, по сравнению с которым всё остальное (SSD, USB/TB) это слёзы.
Это вопрос выбора "базы данных" для хранения таких поясняющих комментариев. Гит - это распределённая система, и всё что у вас в истории можно в две команды перелить с какого-нибудь Bitbucker Server на Gitlab или какой-нибудь Gitea. А мигрировать содержимое Jira уже сложнее.
Если бы не 2022-й, я бы тоже не считал это проблемой, но 2022-й случился.
А это уж как вы организовали у себя в проекте/команде. Я прошу разработчиков делать атомарные коммиты, которые переводят репозиторий из одного работающего состояния в другое работающее (включая компилируемость кода и проходящие юнит-тесты). Да, это не всегда удаётся, поэтому у нас договорённость - если в коммите что-то сломано и починится в следующем, желательно об этом написать.
Сейчас многие проекты выбрали для себя единицей изменений именно МР, а коммиты остаются целиком инструментом для автора кода - коммить когда вздумается, всё равно мы будем смотреть только весь МР сразу. Это может работать, но становится неподъёмным, когда количество ревью через одного человека резко возрастает (например, команда за полгода увеличилась в 2-3 раза). Тогда начинаешь задумываться о том, что коммиты неплохо бы использовать по их изначальному назначению: как атомарную единицу изменений в проекте.
Ну если коммит-мессадж такой: "fixed a bug", то никак не помогает. А если коммит-мессадж такой, то в код можно и не смотреть в теории. По крайней мере смотреть в код придётся только ревьюеру, а если кто-то позже придёт почитать - коммит-мессадж будет даже полезнее кода.
Это безусловно так и есть. Не знаю ни одного разработчика и ревьюера, который просил бы побольше изменений закинуть в один МР вместо нескольких.
Но МР для того и придумали, что это такая единица изменений/работы над проектом, которую можно целиком применить, а потом целиком откатить, если припекло. И такая единица далеко не всегда будет совпадать с единицей "загрузки изменений в голову читателя" (коммитом), т.к. первая обычно значительно больше.
Понятное дело что в любом приличном проекте есть feature flags и подобные штуки, чтобы не показывать юзерам недопиленные фичи, но всё же это касается в основном нового кода. Недорефакторенный старый код в прод не выкатишь, а значит недоделанный МР не смёржишь (разумеется сегодня бизнес хочет релизиться если каждый день, то в любом момент когда потребуется, поэтому мастер/релизная-ветка должна быть всегда в рабочем состоянии).
Так что "маленькие" МР — это здорово, но встречается довольно редко. Обычно когда мне приходит МР с одним коммитом - это человек просто не умеет пользоваться коммитами и напихал кучу изменений в один коммит, а мне теперь как-то за 20 минут нужно успеть понять, что в нём происходит (иначе я ничего не успею). Так что текст коммита — это скорее механизм работы с головой читателя кода, и кмк его полезно использовать.
Ну и что хорошего в том, что вы не смотрите на текст коммита? Почему не сделать из этого инструмент и не начать им пользоваться?
Нет, я понимаю к чему вы про забор: в прод пойдёт код, а не текст коммита. Но можно сидеть 20 минут пытаться понять чего именно добивался человек этими изменениями, а можно прочитать текст коммита и понятно станет за 3 минуты.
Кроме того, правильное пользование коммитами позволяет автору кода загружать изменения в голову ревьюера правильными порциями. В моём случае это вообще самое важное: чтобы не зависать на каждом МР на час (коих за день может быть с десяток-другой), я прошу перед отправкой на ревью сделать нормальные коммиты, чтобы можно было смотреть ревью по ним, а не сразу всё.
Тут что-то на фронтэндерском, не получается прочитать.
Как вы на HH определяете, как развивается карьера отдельных людей?
Вот у меня из пяти знакомых:
трое ушли с десктопного C++ на бэкенд и Go;
ещё один перешёл с Electron на бэкенд (тоже Go);
ещё один хотел бы перейти с Electron на бэкенд (пока этого не сделал, но сделает как только пройдёт собесы в интересующие его компании). Правда этот парень бывший плюсовик, на Electron его занесло скорее вынужденно.
Причём и не скажешь, что они ушли из какой-то одной компании (где было всё сильно плохо) или пришли в какую-то одну компанию (где было всё сильно хорошо), компании разные.
Справедливости ради, есть и такой знакомый, который остался на десктопном C++, но уехал из РФ в стартап с довольно щедрыми зарплатами, поэтому всем доволен и так.
Зайдите на стримы к разных популярным ребятам, и посмотрите на качество их картинки. А потом посмотрите на их сетап. Ну например: Sony A7 IV и Sony A7С (да, аж две камеры сразу, чтобы красиво было!).
Давайте начистоту.
Пока Microsoft, Apple и прочие гиганты бились за звание главной платформы для запуска клиентского кода, Google тихонечко закатила всем в огород троянского коня в виде Хрома. И получилась такая вот интересная ситуация, что теперь "операционной системой" (а точнее, средой для работы клиентского приложения) является браузер, а не натив. И эта среда победила. Почему - уже написали предыдущие комментаторы.
JS и сейчас относительно конченный язык, а году в 2013-м это был ад и Израиль. И ничего, все пошли колоться об этот кактус. Чтобы писать под победившую среду запуска клиентского кода. Побежали все переписывать старые проекты - MS переписала Офис, Гугл же написал свой офис сразу в вебе.
Уже все и забыли, что "Веб" - это про организацию информации прежде всего, а не про HTML/CSS/JS.
Теперь разработчиков под нативный десктоп и нет толком. Точнее, они есть, но им за их знания заплатят намного больше, например, на бэкенде. А над клиентским десктопом можно издеваться, память-то там клиентская, она "бесплатная" для компании, в отличие от памяти на серверах.
Зато навалом разрабов под браузер, стоят они приемлемо, вот и вся история.
Вот на мобилках ресурсов поменьше, и там веба почти нет - каждый второй проект делает себе приложение и переманивает туда всякого, кто зашёл на сайт с мобилы.
А, самое главное: на десктопах толком не прижились магазины приложений. На мобилках юзеров к этому приучили с горшка, и проблема деливери/автоапдейта была решена на корню. А десктоп уже слишком стар как концепция, чтобы его юзеров можно было заставить что-то делать иначе. Microsoft Store почти никому не нужен, Snap Store тоже, разве что на Маке удалось более-менее посадить на их магаз.
Думаю самый лучший вариант - приложение Tino. Если удалят и его, то в этот момент Apple как бы сама себя удалит из своего магазина.
Это чеболизация по-российски.
А задача - открывать на просмотр такие архивы, ибо распаковывать их целиком просто для "посмотреть" - это практически нереально. Вернее, когда у вас ext4 на NVMe-диске - может и реально, но не когда NTFS на магнитном.
Ну там не один архив на 105, а несколько (самый большой на ~16 Гб), но дело-то в другом - что не мне выбирать, как упаковывать, ибо торрент не мой.
А хороший софт потому и хорош, что он хорошо справляется не только с "лёгкими" и популярными кейсами, но в том числе и с не совсем адекватными.
Хранятся-то они замечательно, вы попробуйте удалить их потом. Задача на полдня примерно.
Если бы всё так было хорошо с NTFS, зачем бы тогда MS придумала использовать ReFS в своей фиче Dev Drive.
Если я распакую каждый архив из 105-гигайбайтовой утечки исходников Twitch-а, у меня ФС загнётся от количества файлов. Зачем, если можно архиватором вытаскивать нужные подпапки?
Так, стоп. Разве это не гейткипинг? Т.е. вся остальная статья не имеет смысла? Почему спрашиваю: потому что для меня это основной (если не единственный) аргумент заливать про Таненбаума, CS и всё прочее. Хочется в какой-то момент перестать подтирать за человеком, а он пока даже не понимает, а почему, собственно, за ним подтёрли.
Всё понятно. Рад знакомству (нет).
Как-то всё это грустно. Про «регулярно», про «касания». Когда автор прибегает к помощи редакторов/писателей/прочих специалистов по выражению мыслей и идей в достойном виде — тогда и результат достойный. А вот когда делается наоборот, потому что нужны «касания» — такое себе.
Впрочем, о чём это я, я же просто не с той стороны рта нахожусь. Люди работу работают, а мы потом будем выискивать сокровища в информационной свалке.
А вот за эту статью спасибо! Вот её как раз писали именно те люди, которые «кто ручками каждый день в ней [теме] ковыряется».
Неужели хороших авторов настолько мало и они настолько недоступны, что не вариант идти по пути их выращивания и менторства?
Как раз два года опыта с момента релиза классики!
Что вы имеете в виду? В одном случае это бинраный оператор, в другом - унарный.
По большей части с вами согласен. В том числе поэтому считаю статическую типизацию (например) куда более важным инструментом, чем тесты. Те же модульные тесты нужны прежде всего чтобы:
а) дать самодокументацию в виде каких-то кейсов, чтобы на ревью или при рефакторинге читающий не спрашивал "а вот это будет работать?", "а вот такой кейс предусмотрели?". Все ответы уже заготовлены в виде тестов, а если что-то пропущено - то лучше в виде очередного теста и добавить. Это по сути одна из самых лучших форм документации - никогда не устаревает, в отличие от просто рукописного текста.
б) "заткнуть" какие-то краевые ситуации, которые не может покрыть статическая типизация. Обычно если в языке с типизацией не очень, тестов приходится писать намного больше. И с другой стороны, если типизация очень сильная, то язык программирования превращается в язык доказательства теорем, и в таком языке модульные тесты и не нужны, потому что если программа компилируется - скорее всего она корректна.
Я скорее говорил о том, что никто не будет выводить в прод написанный за полчаса алгоритм или структуру данных без должного тестирования, а тестирование отдельных алгоритмов это в 99% случаев именно unit-тестирование.