я не интересуюсь ни "правильным питанием" ни "правильным режимом дня", но полагаю на эти темы много исследований. И скорее всего много противоречивых.
Это означает, что это глубокая тема и в обществе нет конкретного консенсуса - не перебегай на красный. Поэтому я уточнил в вашем комментарии что не стоит обобщать. Мне кажется в таких случаях нужно просто сходить к диетологу или какому еще врачу, который рассмотрит ваш частный случай и подберет наилучшее питание (а лучше к нескольким).
Но у меня появились сомнения, т.к. как автор и сказал - новый коммит теряет связь со старым. Но гит ведь все же узнает как-то перенесен ли уже коммит в команде `git checkout -v master feature`. Возможно сравнением исходников просто.
Посыл статьи, как мне показалось, в том что общение это важный фактор успешного развития проекта. А этот человек не способствует общению.
Конечно, всегда можно сказать что у него тысячи дней опыта за спиной и лучше послушать его и смириться. А на следующий день сделать так снова и снова и снова. В итоге остаться напряжение, человек не растет - не учится на своей ошибке, человек не становится самостоятельной единицей.
Одной из важных неявных задач любого специалиста является обмен опытом с людьми вокруг.
Но все ставят необходимые плагины. Функции которые вы назвали это базовые кирпичики, которые есть везде.
Да и вообще IntelliSense в целом заметно упрощает жизнь и ускоряет работу.
Честно говоря, Intellisense в VS мне чаще мешает. Часто ошибается и медленно реагирует на изменение кода. Выдает 1к ошибок, при этом сборка проходит без проблем. Не знаю, может тут проблема в том что проект большой.
А что он предлагает полезного, что не даёт lsp?
Кстати насчёт поиска по файлам, функциям, классам - VS и близко не приближается по скорости и удобству поиска к многим плагинами вима или к helix. По каким-то причинам там fuzzy поиск просто медленнее (resharper вроде быстрее, но тоже не настолько)
UPD: в догонку, а в VS есть jumplist? Такая вещь чтобы например после go to definition вернуться обратно одним хоткеем. Самое близкое что я нашел это bookmarks, но их надо сначала поставить. В helix это есть и это очень удобно при изучении кода. В виме тоже плагины есть наверняка
На пути от джуна к мидлу мне было бы полезно знать, что вопросы — это на самом деле ответы. Да-да :)
Мне это напомнило множество ситуаций когда внезапно в голове возникает вопрос, и руки уже тянутся написать сообщение коллеге. Но вот минута, две, пять и, разбираясь в нем самостоятельно, приходишь к ответу. В такой момент появляется и радость познания и одновременно какая-то легкая грусть что не придется спрашивать .-.
«Если бы к вам пришли и сказали, что нужны дашборды, что бы вы спросили?» Джун спросил бы, какие нужны дашборды и где мы будем их хостить. А вот сеньор спросил бы, кто будет на эти дашборды смотреть и как часто
Может я еще не дорос, но мой первый ответ это "А для чего вам нужны эти дашборды?".
Это, как вы подметили выше, попытка не решать задачу, а попытка решать проблему. Довольно часто, пообщавшись с другими людьми, можно понять что к проблеме стоит подходить с другой стороны.
Это кстати хороший совет впринципе для всех - когда вы обращаетесь за помощью - будь то в сообщество или к коллегам - обязательно опишите не только вопрос касательно задачи, но и проблему которую вы решаете с ее помощью. Так более опытные ребята смогут, быть может, предложить решение в разы проще и лучше.
Спасибо за хорошую статью - не часто увидишь такое вкрадчивое и обдуманное чтиво на эту тему. Думаю со временем моего роста я смогу с нее еще что-нибудь почерпнуть.
Посыл который я уяснил, пусть и избит уже, но не теряет актуальности - стоит быть любопытным, открытым к новому, подходить критически к проблемам и задачам. И, главное, не забывать что все мы люди.
P.S. очень незаурядно вы прорекламировали свой тг. После прочтения вернулся к нему, чтобы узнать побольше, а оказалось своего канала нет в профиле .-. . Выходит и не реклама.
P.P.S. Даже жаль стало что отклонил недавно предложение пообщаться с hr из вашей компании в пользу другой :c ...
как будто проблема вообще в существовании функции.
Зачем вам проверять что ее нужно экранировать? Чтобы потом снова пройтись и сделать это самое экранирование?
Выходит два прохода вместо одного и это изменение вроде не такое масштабное для архитектуры.
Кстати, хотелось бы спросить т.к. не знаю.
Вы сказали что бранч мешает компилятору сделать векторизацию. А потом ручками написали simd. Что значит *векторизация* тогда? Может имеется ввиду то как процессор выполняет инструкции, а не как компилятор их генерит. Надо глянуть асм.
Кстати, интересно как атрибут [[likely]] повлиял бы на производительность. Если ли вообще смысл его применять. Я слышал что он просто игнорируется на многих архитектурах
да так) аппетит перебивает .-.
я не интересуюсь ни "правильным питанием" ни "правильным режимом дня", но полагаю на эти темы много исследований. И скорее всего много противоречивых.
Это означает, что это глубокая тема и в обществе нет конкретного консенсуса - не перебегай на красный. Поэтому я уточнил в вашем комментарии что не стоит обобщать. Мне кажется в таких случаях нужно просто сходить к диетологу или какому еще врачу, который рассмотрит ваш частный случай и подберет наилучшее питание (а лучше к нескольким).
ничего не могу сказать про "не есть сладкое".
Но замечу логическую ошибку - вы обобщаете единичный случай из личного опыта до общего факта: проблема не в сахаре.
Даже если допустить что дело не в самом сахаре, то нельзя забывать про последствия его потребления.
Грубо говоря - люди перебегающие на красный свет чаще попадают в ДТП. Очевидно, человеку не красный свет нанес вред, а машина.
лучше до - будьте последовательны, б***!
совет вообще на всю жизнь)
первое что пришло в голову - миллион частиц и обновление из позиции со временем.
а у этого есть какое-либо применение?
по-моему гит сам это резолвит.
Но у меня появились сомнения, т.к. как автор и сказал - новый коммит теряет связь со старым. Но гит ведь все же узнает как-то перенесен ли уже коммит в команде `git checkout -v master feature`. Возможно сравнением исходников просто.
это open source,
давайте контрибьютить, если хотим модули
это перевод..
эх, а я думал это саркастический ответ на недавнюю статью про раст, которая начинается со слов
1997
ага, меня тоже смутило.
За три недели написать проект на go, который пересобирается 2 минуты...
Тут и на C++ нужно задуматься в такой ситуации
это не гениально, это эгоистично и высокомерно.
Посыл статьи, как мне показалось, в том что общение это важный фактор успешного развития проекта. А этот человек не способствует общению.
Конечно, всегда можно сказать что у него тысячи дней опыта за спиной и лучше послушать его и смириться. А на следующий день сделать так снова и снова и снова. В итоге остаться напряжение, человек не растет - не учится на своей ошибке, человек не становится самостоятельной единицей.
Одной из важных неявных задач любого специалиста является обмен опытом с людьми вокруг.
в вим этих вещей никогда и не будет.
Но все ставят необходимые плагины. Функции которые вы назвали это базовые кирпичики, которые есть везде.
Честно говоря, Intellisense в VS мне чаще мешает. Часто ошибается и медленно реагирует на изменение кода. Выдает 1к ошибок, при этом сборка проходит без проблем. Не знаю, может тут проблема в том что проект большой.
А что он предлагает полезного, что не даёт lsp?
Кстати насчёт поиска по файлам, функциям, классам - VS и близко не приближается по скорости и удобству поиска к многим плагинами вима или к helix. По каким-то причинам там fuzzy поиск просто медленнее (resharper вроде быстрее, но тоже не настолько)
UPD: в догонку, а в VS есть jumplist? Такая вещь чтобы например после go to definition вернуться обратно одним хоткеем. Самое близкое что я нашел это bookmarks, но их надо сначала поставить. В helix это есть и это очень удобно при изучении кода. В виме тоже плагины есть наверняка
по вашему опыту, чего не хватает виму и друзьям?
Просто мне по работе пришлось перейти на VS и я не ощущаю каких либо удобства - скорее наоборот.
Интересная статья - спасибо.
Мне это напомнило множество ситуаций когда внезапно в голове возникает вопрос, и руки уже тянутся написать сообщение коллеге. Но вот минута, две, пять и, разбираясь в нем самостоятельно, приходишь к ответу. В такой момент появляется и радость познания и одновременно какая-то легкая грусть что не придется спрашивать .-.
Может я еще не дорос, но мой первый ответ это "А для чего вам нужны эти дашборды?".
Это, как вы подметили выше, попытка не решать задачу, а попытка решать проблему. Довольно часто, пообщавшись с другими людьми, можно понять что к проблеме стоит подходить с другой стороны.
Это кстати хороший совет впринципе для всех - когда вы обращаетесь за помощью - будь то в сообщество или к коллегам - обязательно опишите не только вопрос касательно задачи, но и проблему которую вы решаете с ее помощью. Так более опытные ребята смогут, быть может, предложить решение в разы проще и лучше.
Спасибо за хорошую статью - не часто увидишь такое вкрадчивое и обдуманное чтиво на эту тему. Думаю со временем моего роста я смогу с нее еще что-нибудь почерпнуть.
Посыл который я уяснил, пусть и избит уже, но не теряет актуальности - стоит быть любопытным, открытым к новому, подходить критически к проблемам и задачам. И, главное, не забывать что все мы люди.
P.S. очень незаурядно вы прорекламировали свой тг. После прочтения вернулся к нему, чтобы узнать побольше, а оказалось своего канала нет в профиле .-. . Выходит и не реклама.
P.P.S. Даже жаль стало что отклонил недавно предложение пообщаться с hr из вашей компании в пользу другой :c ...
похоже код запускается только на машине автора..
`man` - вот что изменит вашу жизнь)
Для начала попробуйте `man man`
кроме "прекрасного" powershell из комментариев выше, есть например nushell.
Очень неплох, хотя до fish по дружелюбности не дотягивает
как будто проблема вообще в существовании функции.
Зачем вам проверять что ее нужно экранировать? Чтобы потом снова пройтись и сделать это самое экранирование?
Выходит два прохода вместо одного и это изменение вроде не такое масштабное для архитектуры.
Кстати, хотелось бы спросить т.к. не знаю.
Вы сказали что бранч мешает компилятору сделать векторизацию. А потом ручками написали simd. Что значит *векторизация* тогда? Может имеется ввиду то как процессор выполняет инструкции, а не как компилятор их генерит. Надо глянуть асм.
Кстати, интересно как атрибут
[[likely]]повлиял бы на производительность. Если ли вообще смысл его применять. Я слышал что он просто игнорируется на многих архитектурахто что полезная нагрузка объекта находится в куче, не означает что за освобождением памяти нужно руками следить.
вектор, строка... и тд
приведите пример когда нельзя