Я постоянно читаю комментарии к коммитам. Представьте, вы работаете над унаследованным проектом, который писался кучей людей несколько лет. Открываете новый файл, там неочевидная конструкция, и вы не можете понять, зачем она.
Если коммиты пишутся хорошо, то можно понять в чем дело по одному только взгляду на git blame. К сожалению, чаще всего это не так, так как многие пишут в commit message что попало, типа: "Fixed a bug" или "Refactoring" или "Today's work" или тому подобный бред, который вообще не помогает понять историю изменений.
Для меня особенной разницы нет. Rebase и merge чаще предпочитаю делать в командной строке, так как есть иллюзия большего контроля над процессом (видишь больше служебной информации).
Но в общем, да: поддержка Git в IDEA очень хороша, поэтому все чаще предпочитаю делать все из PyCharm, даже rebase.
Даже не знаю, что сказать. Я не очень пристально слежу за разработкой языка, но честно говоря, я всегда любил питон за некоторую строгость и лаконичность. Мне кажется, что данное расширение не идет на пользу языку, так как позволит писать трудно понимаемые конструкции с большим потенциалом для возникновения ошибок.
При этом странно: многострочные lambda функции не допускаем, а подобное безобразие не только пропихиваем в язык, но еще и недовольны, что не всем это нравится.
Я доверяю Яндекс не меньше, чем кому-либо еще. Да и продукты у них, в общем хорошие. С диском обидная для меня ситуация, но мало у кого есть силы, чтобы поддерживать клиентов для всех платформ. У Google Drive клиента для Linux вообще никогда не было.
Так что пользуюсь клиентом Яндекс.Диска для Android, а на ноуте web-интерфейсом.
У всех разный опыт, конечно. Рядом со мной всегда происходят такие истории:
1) Можно реализовать это самостоятельно, у нас простой вырожденный случай, мы получим свое быстрое решение
2) Через месяц: «Ой, а вот надо бы этот и это случай поддержать»
3) Еще через месяц: «Оказывается, существующее ПО рассчитывает на то и это, придется наш велосипед расширить для совместимости с существующими клиентами»
4) Еще через месяц: «На production страшный баг, срочно требуется до 6 утра найти и накатить патч, иначе бизнес потеряет кучу денег»
И т.д. Свое решение всегда будет расти. Его надо будет расширять, портировать на новые платформы, тестировать, поддерживать. И в большинстве случаев на это потребуется намного больше денег, чем купить более дорогой или еще один сервер.
То есть теоретически я красоту и крутость понимаю. Но на практике, скорее всего, выгоду из этого может извлечь только Google, Яндекс и Cloudflare. Остальные, если сунутся, увязнут по шею.
Да и у всех разные задачи, конечно. В моей практике есть гораздо более доступные цели для оптимизации. Если я в текущем проекте начну оптимизировать раздачу статики, то даже самый дотошный пользователь не заметит никаких изменений. Зато есть десяток мест, где я могу не только произвести вполне заметное измеримое улучшение, но и при этом получить еще более поддерживаемый читаемый код.
Но это, конечно, мой случай. Допускаю, что есть места, где другая ситуация, и единственным узким местом может стать копирование данных из ядра в процесс и обратно. Просто уверен, что таких проектов, единицы проектов в мире.
А в Узбекистане наоборот — правительство приняло указ о поддержке и развитии криптовалют. Теперь, надо думать, Узбекистан станет одним из мировых лидеров в экономике, потеснив Китай. Шах и мат, китайцы!
Эх… В жизни все направлено на оптимизацию прибыли, а оптимизация быстродействия часто противоположна оптимизации прибыли.
Как качественно перевести книгу издательству, если качественный перевод требует большего времени и больших затрат на переводчиков (кого попало не возьмешь, а грамотный опытный переводчик будет стоить дороже)? Пока будет готовиться качественный перевод, скажем, книги по Rust, другие издательства напечатают книги по Rust плохого качества, и убьют рынок для качественной книги — затраты на качественный перевод никогда не отобьются.
Как сделать качественный быстродействующий сайт, если ресурсы надо тратить на захват рынка, исправление неотложных багов, добавление свистелок, которые нравятся тем пользователям, от которых зависит прибыль?
К сожалению, как-то приходится с этим жить.
Если любая компания вместо того, чтобы сосредоточиться на своем продукте, будет писать собственные реализации TCP и HTTP, прогресс совсем замрет.
А http не так уж и сложно/заумно реализовывать, если надо.
С этих слов начиналось очень много epic fail'ов. Практически все не так уж сложно реализовать. До тех пор пока не надо укладываться в дедлайны, пока не нужно думать о поддержке всего этого в течении многих лет (особенно будет «приятно», если автор подобного велосипеда на атомном реакторе уйдет в другое место, а поддерживать его придется менее продвинутым коллегам), исправлении уязвимостей безопасности, и так далее и так далее.
Я стал страшно далек от таких низкоуровневых деталей, но разве nginx не использует для раздачи статики sendfile? Тогда тоже не должно быть накладных расходов на копирование в userspace и обратно.
А так может получиться, что когда реализуешь полноценные TCP и HTTP, поддержку прочих плюшек типа HTTPS, rate-limiting, error pages, и т.д. и т.п., окажется, что все выигрыши где-то потерялись, а стоимость поддержки такого решения чрезвычайно высока.
Ну, со вторым экраном и клавиатурой не поездишь. Поэтому все равно лучше привыкнуть к одному. Я сейчас в офисе работаю, но у меня командировки порой на месяцы. В командировку с собой тоже не возьмешь второй монитор.
У каждого свои требования к комфорту, конечно. Но я не жалею, что привык. Мобильность повысилась, если есть пересадка в аэропорту длительностью в 8 часов и более, можно не тупить в телефоне, а сделать что-нибудь полезное. Да я даже во время перелетов теперь работать могу (спать в самолете мне не удается, а так хоть что-то полезное делаю).
Некоторые незначительные преимущества есть, просто они в данной статье вообще не рассмотрены. Но я использую virtualenv + fish + virtualfish, и пока для себя не вижу резона переходить на pipenv. Надо возможно поиграться с ним на каком-нибудь проекте, может быть, тогда почувствую преимущества.
Цитаты, например, Сократа и Лао-Цзы описывают проблему, но не описывают решение. Хорошо сосредоточиться на настоящем, и не нервничать о прошлом или будущем. Но как?..
И даже если в один конкретный момент времени можно суметь сосредоточиться на хороших мыслях, хороших поступках, но чтобы достичь полного безусловного освобождения в любой момент времени, необходим путь.
Есть еще применение телефона в качестве навигатора, например. Тут мне кажется, e-ink экран весьма кстати был бы. Но попробовать так и не удалось, к сожалению.
Мне нужна. Я очень хотел купить YotaPhone 3, но так и не дождался. Купил Huawei P20 Pro, хотя это совсем другой аппарат. Зато радует отличными снимками и видео.
Я давно перешел на ноутбук. После гигантского 24" монитора (или больше, не помню уже) было немного сложно адаптироваться, но я жил в нескольких странах, переезжая в каждой стране из города в город. Эта практика быстро учит обходиться только самым необходимым.
Одним из толков был рассказ знакомого, который был лично знаком с одним хорошим программистом, работы которого я знал по его GitHub. И мне мой знакомый рассказал, что тот вообще работает на нетбуке (это было более 10 лет назад). Нетбук дешевый, легкий, компактный, с ним хоть в лес можно идти и на пеньке работать.
Тогда меня очень впечатлило, что профессионал, известный в определенной области, делает свои разработки на слабом маленьком нетубуке, с крошечной клавиатурой и экраном.
Для себя же я выбрал компромиссный вариант. Ноутбук Lenovo T440s: большая автономность (сменные батареи), небольшой вес, размеры на грани допустимого — 13 или 14 дюймов — помещается в почти любой рюкзак. На 1" больше и уже будет намного тяжелее и не в каждом рюкзаке/сумке можно будет носить.
Вы так говорите, словно есть какой-то гарантированный путь к успеху или избежать неудач. Никакая аналитика не может гарантировать успех со 100% вероятностью.
Да и так ли важно концентрироваться на успехе или неудаче? Самое важное — то, что происходит в процессе.
Буддисты такие же люди, как и все остальные. К тому же, как многие практикующие быстро замечают, групповая медитация очень сильно отличается по ощущениям от индивидуальной.
Вот пример из книги «Посыпание Будды пеплом»:
Поэтому мы живем вместе и действуем вместе. Совместные действия означают обрезание моих условий, обрезание моей ситуации. Тогда мы становимся пустым умом. Мы возвращаемся к белой бумаге. Тогда появляется наше истинное мнение, наше истинное условие, наша истинная ситуация. Когда мы кланяемся вместе, поем вместе и едим вместе, наши умы становятся одним умом. Это как море. Когда поднимается ветер, там много волн. Когда ветер стихает, волны становятся меньше. Когда ветер прекращается, вода становится зеркалом, в котором все отражается — горы, деревья, облака. С нашим умом точно так же. Когда у нас много желаний и много мнений, там много больших волн. Но после того, как мы какое-то время сидим в Дзэн и совместно действуем, наши мнения и желания исчезают. Волны становятся меньше и меньше. Затем наш ум становится как чистое зеркало, и все, что мы видим, слышим, обоняем, чувствуем на вкус, ощущаем или думаем — есть истина. Тогда очень легко понимать умы других людей. Их умы отражены в моем уме. Поэтому пение очень важно. Сначала вы не понимаете, но если вы поете регулярно, то вы поймете. А пение — очень хорошее ощущение! То же самое с поклонами 108 раз. Сначала людям это не нравится. Зачем нам кланяться? Мы кланяемся не Будде, мы кланяемся себе. Малое «Я» кланяется большому «Я», затем малое «Я» исчезает и становится большим «Я». Это истинные поклоны. Поэтому приходите практиковать с нами. Вы быстро поймете».
Непонятно, почему вопрос ко мне. Я такие ситуации просто не создаю.
Я постоянно читаю комментарии к коммитам. Представьте, вы работаете над унаследованным проектом, который писался кучей людей несколько лет. Открываете новый файл, там неочевидная конструкция, и вы не можете понять, зачем она.
Если коммиты пишутся хорошо, то можно понять в чем дело по одному только взгляду на git blame. К сожалению, чаще всего это не так, так как многие пишут в commit message что попало, типа: "Fixed a bug" или "Refactoring" или "Today's work" или тому подобный бред, который вообще не помогает понять историю изменений.
Для меня особенной разницы нет. Rebase и merge чаще предпочитаю делать в командной строке, так как есть иллюзия большего контроля над процессом (видишь больше служебной информации).
Но в общем, да: поддержка Git в IDEA очень хороша, поэтому все чаще предпочитаю делать все из PyCharm, даже rebase.
Даже не знаю, что сказать. Я не очень пристально слежу за разработкой языка, но честно говоря, я всегда любил питон за некоторую строгость и лаконичность. Мне кажется, что данное расширение не идет на пользу языку, так как позволит писать трудно понимаемые конструкции с большим потенциалом для возникновения ошибок.
При этом странно: многострочные lambda функции не допускаем, а подобное безобразие не только пропихиваем в язык, но еще и недовольны, что не всем это нравится.
Я доверяю Яндекс не меньше, чем кому-либо еще. Да и продукты у них, в общем хорошие. С диском обидная для меня ситуация, но мало у кого есть силы, чтобы поддерживать клиентов для всех платформ. У Google Drive клиента для Linux вообще никогда не было.
Так что пользуюсь клиентом Яндекс.Диска для Android, а на ноуте web-интерфейсом.
У всех разный опыт, конечно. Рядом со мной всегда происходят такие истории:
1) Можно реализовать это самостоятельно, у нас простой вырожденный случай, мы получим свое быстрое решение
2) Через месяц: «Ой, а вот надо бы этот и это случай поддержать»
3) Еще через месяц: «Оказывается, существующее ПО рассчитывает на то и это, придется наш велосипед расширить для совместимости с существующими клиентами»
4) Еще через месяц: «На production страшный баг, срочно требуется до 6 утра найти и накатить патч, иначе бизнес потеряет кучу денег»
И т.д. Свое решение всегда будет расти. Его надо будет расширять, портировать на новые платформы, тестировать, поддерживать. И в большинстве случаев на это потребуется намного больше денег, чем купить более дорогой или еще один сервер.
То есть теоретически я красоту и крутость понимаю. Но на практике, скорее всего, выгоду из этого может извлечь только Google, Яндекс и Cloudflare. Остальные, если сунутся, увязнут по шею.
Да и у всех разные задачи, конечно. В моей практике есть гораздо более доступные цели для оптимизации. Если я в текущем проекте начну оптимизировать раздачу статики, то даже самый дотошный пользователь не заметит никаких изменений. Зато есть десяток мест, где я могу не только произвести вполне заметное измеримое улучшение, но и при этом получить еще более поддерживаемый читаемый код.
Но это, конечно, мой случай. Допускаю, что есть места, где другая ситуация, и единственным узким местом может стать копирование данных из ядра в процесс и обратно. Просто уверен, что таких проектов, единицы проектов в мире.
А в Узбекистане наоборот — правительство приняло указ о поддержке и развитии криптовалют. Теперь, надо думать, Узбекистан станет одним из мировых лидеров в экономике, потеснив Китай. Шах и мат, китайцы!
Уже около 8 лет мы видим все более пустые статьи, как блокчейн и криптовалюты изменят экономику. Потому что изменят.
Тем не менее, платежным средством криптовалюты так и не стали. Раз за столько времени не стали, то уже и не станут.
Когда-то был еще HTTP сервер в ядре...
Эх… В жизни все направлено на оптимизацию прибыли, а оптимизация быстродействия часто противоположна оптимизации прибыли.
Как качественно перевести книгу издательству, если качественный перевод требует большего времени и больших затрат на переводчиков (кого попало не возьмешь, а грамотный опытный переводчик будет стоить дороже)? Пока будет готовиться качественный перевод, скажем, книги по Rust, другие издательства напечатают книги по Rust плохого качества, и убьют рынок для качественной книги — затраты на качественный перевод никогда не отобьются.
Как сделать качественный быстродействующий сайт, если ресурсы надо тратить на захват рынка, исправление неотложных багов, добавление свистелок, которые нравятся тем пользователям, от которых зависит прибыль?
К сожалению, как-то приходится с этим жить.
Если любая компания вместо того, чтобы сосредоточиться на своем продукте, будет писать собственные реализации TCP и HTTP, прогресс совсем замрет.
С этих слов начиналось очень много epic fail'ов. Практически все не так уж сложно реализовать. До тех пор пока не надо укладываться в дедлайны, пока не нужно думать о поддержке всего этого в течении многих лет (особенно будет «приятно», если автор подобного велосипеда на атомном реакторе уйдет в другое место, а поддерживать его придется менее продвинутым коллегам), исправлении уязвимостей безопасности, и так далее и так далее.
Я стал страшно далек от таких низкоуровневых деталей, но разве nginx не использует для раздачи статики sendfile? Тогда тоже не должно быть накладных расходов на копирование в userspace и обратно.
А так может получиться, что когда реализуешь полноценные TCP и HTTP, поддержку прочих плюшек типа HTTPS, rate-limiting, error pages, и т.д. и т.п., окажется, что все выигрыши где-то потерялись, а стоимость поддержки такого решения чрезвычайно высока.
Что за экран такой?
Ну, со вторым экраном и клавиатурой не поездишь. Поэтому все равно лучше привыкнуть к одному. Я сейчас в офисе работаю, но у меня командировки порой на месяцы. В командировку с собой тоже не возьмешь второй монитор.
У каждого свои требования к комфорту, конечно. Но я не жалею, что привык. Мобильность повысилась, если есть пересадка в аэропорту длительностью в 8 часов и более, можно не тупить в телефоне, а сделать что-нибудь полезное. Да я даже во время перелетов теперь работать могу (спать в самолете мне не удается, а так хоть что-то полезное делаю).
Некоторые незначительные преимущества есть, просто они в данной статье вообще не рассмотрены. Но я использую virtualenv + fish + virtualfish, и пока для себя не вижу резона переходить на pipenv. Надо возможно поиграться с ним на каком-нибудь проекте, может быть, тогда почувствую преимущества.
Потому что он открыл путь к счастью.
Цитаты, например, Сократа и Лао-Цзы описывают проблему, но не описывают решение. Хорошо сосредоточиться на настоящем, и не нервничать о прошлом или будущем. Но как?..
И даже если в один конкретный момент времени можно суметь сосредоточиться на хороших мыслях, хороших поступках, но чтобы достичь полного безусловного освобождения в любой момент времени, необходим путь.
Есть еще применение телефона в качестве навигатора, например. Тут мне кажется, e-ink экран весьма кстати был бы. Но попробовать так и не удалось, к сожалению.
Мне нужна. Я очень хотел купить YotaPhone 3, но так и не дождался. Купил Huawei P20 Pro, хотя это совсем другой аппарат. Зато радует отличными снимками и видео.
Я давно перешел на ноутбук. После гигантского 24" монитора (или больше, не помню уже) было немного сложно адаптироваться, но я жил в нескольких странах, переезжая в каждой стране из города в город. Эта практика быстро учит обходиться только самым необходимым.
Одним из толков был рассказ знакомого, который был лично знаком с одним хорошим программистом, работы которого я знал по его GitHub. И мне мой знакомый рассказал, что тот вообще работает на нетбуке (это было более 10 лет назад). Нетбук дешевый, легкий, компактный, с ним хоть в лес можно идти и на пеньке работать.
Тогда меня очень впечатлило, что профессионал, известный в определенной области, делает свои разработки на слабом маленьком нетубуке, с крошечной клавиатурой и экраном.
Для себя же я выбрал компромиссный вариант. Ноутбук Lenovo T440s: большая автономность (сменные батареи), небольшой вес, размеры на грани допустимого — 13 или 14 дюймов — помещается в почти любой рюкзак. На 1" больше и уже будет намного тяжелее и не в каждом рюкзаке/сумке можно будет носить.
Вы так говорите, словно есть какой-то гарантированный путь к успеху или избежать неудач. Никакая аналитика не может гарантировать успех со 100% вероятностью.
Да и так ли важно концентрироваться на успехе или неудаче? Самое важное — то, что происходит в процессе.
Буддисты такие же люди, как и все остальные. К тому же, как многие практикующие быстро замечают, групповая медитация очень сильно отличается по ощущениям от индивидуальной.
Вот пример из книги «Посыпание Будды пеплом»: