У меня стажа программирования на 10 лет больше, чем у вас, и мой путь был сильно другим, с большинством советов тем не менее согласен.
Не ленитесь читать на английском, а лучше слушайте и пытайтесь говорить - пригодится. С книгами у меня сложно, чем больше опыт, тем реально хороших книг становится меньше, поэтому читать и слушать приходится чуть другие материалы. Но развиваться надо. В разных направлениях.
Не зацикливайтесь на одном языке. А лучше изучите несколько принципиально разных.
Не бойтесь легаси кода. Ваш код через два-три года тоже таким будет.
Вы оба преувеличиваете, просто в разные стороны. У меня были проекты, где я реально за неделю релизил первую задачу. И были и есть проекты, где в некоторые части нельзя въехать меньше чем за пару месяцев. То есть, ты разумеется будешь что-то писать достаточно быстро - но производительность твоя будет ниже, чем могла бы быть, потому что ты многих вещей не знаешь, а узнать их за пару дней нельзя.
На самом деле все просто - есть проекты типовые, где все как у всех (но тогда там возможно такой синьор не особо нужен), а есть нестандартные.
Я бы категорически не хотел чтобы сертификаты Минцифры использовались для работы какого-то софта, кроме тех, который без них не работает. Потому что их использование означает возможность MITM. Не вижу что тут некорректного.
Все может быть, я естественно изложил то, что я на сегодня вижу. Историю мана посмотреть интересно - но не столько даже лень, сколько непонятно, где именно. Хотя это конечно меняет картину еще раз.
Ну я бы чуть иначе к этому подходил. Доверенный центр сертификации - это в сущности лишь чей-то корневой сертификат. Например, выпущенный вашей же компанией. И их очевидно в системе много, даже не считая того, что у моей компании скажем этих УЦ штуки четыре минимум.
Сам он ничего не может (в том смысле, что он пассивный, это не код, а данные), но он используется при установлении соединения с кем-то, в том числе и с репозиториями обновлений.
Т.е. "устанавливая свои обновления под видом яблочных" - ну да, может быть и такое, но устанавливать будет кто-то типа homebrew, и при этом у него будет такой же выбор как у curl - пользоваться системным набором сертификатов доверенных УЦ, или же использовать для установки обновлений свой набор сертификатов, который у него лежит отдельно. То есть, вопрос опасности того, что мы доверяем каким-то сертификатам в частности состоит и в том, что определенный важный софт не умеет работать с хранилищами сертификатов, отличными от системного.
Ну да. Но это curl так позволяет - какой-то другой софт может пользоваться системным хранилищем, и тогда отключить все что лежит в нем, уже не получится (и на curl это повлияет в том числе). И мне такое поведение тоже не нравится.
То что такое поведение curl, ну скажем, нехорошее - я скорее согласен. Я бы предпочел иметь возможность выбрать сертификаты удостоверяющего центра сам, когда захочу. Для конкретного сайта. Очевидный вариант - сертификаты Минцифры я бы предпочел иметь отключаемыми, без вариантов.
Но цитата из ман выше показывает на мой взгляд, что отличия как раз документированы (хотя и не очень четко). Так что автору оригинала просто следовало бы ман прочитать, и найти/собрать другую реализацию, тем более что ее долго искать не придется.
Я не знаю про какую версию идет речь, но быстрый поиск мана в интернете показывает вот что:
--cacert <file>
...
(iOS and macOS only) If curl is built against Secure Transport, then this option is supported for backward compatibility with other SSL engines, but it should not be set. If the option is not set, then curl uses the certificates in the system and user Keychain to verify the peer, which is the preferred method of verifying the peer's certificate chain.
Последний абзац. На мой взгляд, тут ясно написано, что при определенных условиях cacert не должна использоваться. Ну т.е. да, определенные претензии тут могут быть - но скорее к документации, потому что непонятно/неполно описано поведение.
Ну иногда интересно сделать свое, особенно если есть принтер. Хотя я тоже не уловил причин для такой уж экономии денег, потому что пара валов (я думаю 8 мм тут достаточно) и четыре подшипника линейных самых простых обойдутся рублей эдак в 1000, не более. При таких диапазонах перемещений. И гибридные конструкции из отпечатанных деталей с усилением металлом получаются очень даже хорошие. Взять хотя бы канал USSA на ютюбе.
Я вам больше скажу - я таких примерно валидаторов видел наверное с десяток. И это практически бесполезная фигня, по той простой причине, что валидировать отдельные поля может любой дурак, и это как-то более-менее работает, в большинстве случаев. А вот когда дело доходит до кросс-валидации, когда правила для одного поля зависят от значений в других полях - начинается хаос и мрак.
И что характерно, в этом тексте тоже ни одного такого примера не приведено, и внимание на этом не акцентировалось. Сделаем скидку на то, что это первая часть, но пока - ничего нового, ничего такого, чего принципиально не было бы сделано лет 10 назад там и сям.
Ну давайте так - я говорю о существующем ИИ, в виде ChatGPT или чего-то подобного. Про перспективные варианты - не берусь предсказывать. То что вы описываете - выглядит вполне реалистично.
Не думаю, что это реально важно. В практике у нас как его только не зовут, в разговоре же обычно вполне понятно о чем речь, поэтому "постгря" или "постгри" вполне проскакивает. От этого квалификация говорящего никак не меняется.
И технически, ИИ тоже можно спросить "почему ты сделал именно так?",
Да ладно, правда что-ли? :) ну мне вот ChatGPT не говоря худого слова начал выдавать код на питоне вместо запрошенной скалы. На вопрос "а нафига так" он разумеется ничего не объяснил, а извинился, и предложил уточнить постановку. Ну то есть, это не то что не рассуждение, а даже не похоже на объяснение. Да и что оно может объяснить при своей текущей архитектуре?
Если вы перечитаете ветку с начала, то я с этого начал. Выбор стека - не вопрос, автор может его выбрать какой хочет, даже просто потому, что питон знает.
Я лишь намекаю, что некоторые утверждения автора про Excel и его использование - не совсем точные. А так вы совершенно правы, я хранил в Excel (64 битовый обязателен) порядка 500 тыс строк, это ужас-ужас. Это можно сделать, чтобы куда-то данные передать, показать, ну там не знаю, графики построить (хотя на таком объеме оно еле шевелится).
Вы не полностью правы. Строго говоря, тут не может быть полной правоты, потому что вопрос неформальный.
Мы не знаем как работает ИИ (практически, потому что параметров слишком много, и мы не знаем, как они влияют на результат - и на сегодня это не баг, а фича, потому что при этом незнании мы таки иногда получаем результат).
Мы не знаем, как работает разработчик. Но разница между ними все равно остается, и она очевидная. Разработчика мы можем спросить, почему он написал так или иначе - и он вероятно ответит. Вы отрицаете эту разницу?
Видите ли в чем дело - я и есть не только программист, но и тот самый архитектор, который ее проектирует. Только в отличие от вас, у меня зачастую вообще не бывает никакого ТЗ. И пока ИИ мне и как программисту, и как архитектору, помочь не особо может.
Я согласен, что наверное есть такие классы систем, которые как раз получится отдать на откуп ИИ. Но я вижу и другие классы, где мы к этому даже не близко. В перспективе, с обучением скажем внутри проекта - быть может. Но пока до этого нужно как минимум сделать новый класс нейросетей. И возможно не один.
А что, отключение JIT не помогает тоже? Не то чтобы я был уверен, что всегда можно отключить, но такие параметры имеются.
Еще работа в команде, в широком смысле, это тоже очень нужно - и это еще одна большая область, в которой надо развиваться.
У меня стажа программирования на 10 лет больше, чем у вас, и мой путь был сильно другим, с большинством советов тем не менее согласен.
Не ленитесь читать на английском, а лучше слушайте и пытайтесь говорить - пригодится. С книгами у меня сложно, чем больше опыт, тем реально хороших книг становится меньше, поэтому читать и слушать приходится чуть другие материалы. Но развиваться надо. В разных направлениях.
Не зацикливайтесь на одном языке. А лучше изучите несколько принципиально разных.
Не бойтесь легаси кода. Ваш код через два-три года тоже таким будет.
Вы оба преувеличиваете, просто в разные стороны. У меня были проекты, где я реально за неделю релизил первую задачу. И были и есть проекты, где в некоторые части нельзя въехать меньше чем за пару месяцев. То есть, ты разумеется будешь что-то писать достаточно быстро - но производительность твоя будет ниже, чем могла бы быть, потому что ты многих вещей не знаешь, а узнать их за пару дней нельзя.
На самом деле все просто - есть проекты типовые, где все как у всех (но тогда там возможно такой синьор не особо нужен), а есть нестандартные.
Я бы категорически не хотел чтобы сертификаты Минцифры использовались для работы какого-то софта, кроме тех, который без них не работает. Потому что их использование означает возможность MITM. Не вижу что тут некорректного.
Все может быть, я естественно изложил то, что я на сегодня вижу. Историю мана посмотреть интересно - но не столько даже лень, сколько непонятно, где именно. Хотя это конечно меняет картину еще раз.
Ну я бы чуть иначе к этому подходил. Доверенный центр сертификации - это в сущности лишь чей-то корневой сертификат. Например, выпущенный вашей же компанией. И их очевидно в системе много, даже не считая того, что у моей компании скажем этих УЦ штуки четыре минимум.
Сам он ничего не может (в том смысле, что он пассивный, это не код, а данные), но он используется при установлении соединения с кем-то, в том числе и с репозиториями обновлений.
Т.е. "устанавливая свои обновления под видом яблочных" - ну да, может быть и такое, но устанавливать будет кто-то типа homebrew, и при этом у него будет такой же выбор как у curl - пользоваться системным набором сертификатов доверенных УЦ, или же использовать для установки обновлений свой набор сертификатов, который у него лежит отдельно. То есть, вопрос опасности того, что мы доверяем каким-то сертификатам в частности состоит и в том, что определенный важный софт не умеет работать с хранилищами сертификатов, отличными от системного.
Ну да. Но это curl так позволяет - какой-то другой софт может пользоваться системным хранилищем, и тогда отключить все что лежит в нем, уже не получится (и на curl это повлияет в том числе). И мне такое поведение тоже не нравится.
То что такое поведение curl, ну скажем, нехорошее - я скорее согласен. Я бы предпочел иметь возможность выбрать сертификаты удостоверяющего центра сам, когда захочу. Для конкретного сайта. Очевидный вариант - сертификаты Минцифры я бы предпочел иметь отключаемыми, без вариантов.
Но цитата из ман выше показывает на мой взгляд, что отличия как раз документированы (хотя и не очень четко). Так что автору оригинала просто следовало бы ман прочитать, и найти/собрать другую реализацию, тем более что ее долго искать не придется.
Я не знаю про какую версию идет речь, но быстрый поиск мана в интернете показывает вот что:
Последний абзац. На мой взгляд, тут ясно написано, что при определенных условиях cacert не должна использоваться. Ну т.е. да, определенные претензии тут могут быть - но скорее к документации, потому что непонятно/неполно описано поведение.
Ну иногда интересно сделать свое, особенно если есть принтер. Хотя я тоже не уловил причин для такой уж экономии денег, потому что пара валов (я думаю 8 мм тут достаточно) и четыре подшипника линейных самых простых обойдутся рублей эдак в 1000, не более. При таких диапазонах перемещений. И гибридные конструкции из отпечатанных деталей с усилением металлом получаются очень даже хорошие. Взять хотя бы канал USSA на ютюбе.
В сегодняшних реалиях наверное уже метамордо...
Ну не вопрос, подождем. Просто это самое интересное, как по мне. Насколько вот такая валидация будет управляемой, понятной и т.п.
Я вам больше скажу - я таких примерно валидаторов видел наверное с десяток. И это практически бесполезная фигня, по той простой причине, что валидировать отдельные поля может любой дурак, и это как-то более-менее работает, в большинстве случаев. А вот когда дело доходит до кросс-валидации, когда правила для одного поля зависят от значений в других полях - начинается хаос и мрак.
И что характерно, в этом тексте тоже ни одного такого примера не приведено, и внимание на этом не акцентировалось. Сделаем скидку на то, что это первая часть, но пока - ничего нового, ничего такого, чего принципиально не было бы сделано лет 10 назад там и сям.
Ну давайте так - я говорю о существующем ИИ, в виде ChatGPT или чего-то подобного. Про перспективные варианты - не берусь предсказывать. То что вы описываете - выглядит вполне реалистично.
Не думаю, что это реально важно. В практике у нас как его только не зовут, в разговоре же обычно вполне понятно о чем речь, поэтому "постгря" или "постгри" вполне проскакивает. От этого квалификация говорящего никак не меняется.
Да ладно, правда что-ли? :) ну мне вот ChatGPT не говоря худого слова начал выдавать код на питоне вместо запрошенной скалы. На вопрос "а нафига так" он разумеется ничего не объяснил, а извинился, и предложил уточнить постановку. Ну то есть, это не то что не рассуждение, а даже не похоже на объяснение. Да и что оно может объяснить при своей текущей архитектуре?
Если вы перечитаете ветку с начала, то я с этого начал. Выбор стека - не вопрос, автор может его выбрать какой хочет, даже просто потому, что питон знает.
Я лишь намекаю, что некоторые утверждения автора про Excel и его использование - не совсем точные. А так вы совершенно правы, я хранил в Excel (64 битовый обязателен) порядка 500 тыс строк, это ужас-ужас. Это можно сделать, чтобы куда-то данные передать, показать, ну там не знаю, графики построить (хотя на таком объеме оно еле шевелится).
Вы не полностью правы. Строго говоря, тут не может быть полной правоты, потому что вопрос неформальный.
Мы не знаем как работает ИИ (практически, потому что параметров слишком много, и мы не знаем, как они влияют на результат - и на сегодня это не баг, а фича, потому что при этом незнании мы таки иногда получаем результат).
Мы не знаем, как работает разработчик. Но разница между ними все равно остается, и она очевидная. Разработчика мы можем спросить, почему он написал так или иначе - и он вероятно ответит. Вы отрицаете эту разницу?
Видите ли в чем дело - я и есть не только программист, но и тот самый архитектор, который ее проектирует. Только в отличие от вас, у меня зачастую вообще не бывает никакого ТЗ. И пока ИИ мне и как программисту, и как архитектору, помочь не особо может.
Я согласен, что наверное есть такие классы систем, которые как раз получится отдать на откуп ИИ. Но я вижу и другие классы, где мы к этому даже не близко. В перспективе, с обучением скажем внутри проекта - быть может. Но пока до этого нужно как минимум сделать новый класс нейросетей. И возможно не один.