Ну это не совсем правда, а точнее не вся, т.е. это упрощение.
Эти слова все желательные, но не необходимые.
И потом, знаете, я вот знаю итальянский ровно на этом уровне, т.е. мой словарный запас где-то слов 100 (очень примерная субъективная оценка). Но разница между запасом активным и пассивным все равно имеет место и тут, т.е. я не вспомню скажем названия всех цветов сам - но пойму, когда мне скажут verde, что это зеленый, без проблем. С числами та же фигня. Могу ли я общаться? Так общаюсь же... как-то.
Как там Фигаро выражался в незабываемом спектакле - чтобы общаться с англичанами достаточно знать только "god dammit". И там же был прекрасно проиллюстрирован уровень этого общения :)
Поэтому кардинальность поля (или полей) таблицы можно измерять отношением количества уникальных записей в поле (полях) к общему количеству записей в таблице.
На практике это означает фуллскан, а значит в реальных условиях больших таблиц эти идеи могут оказаться неприменимы. Если бы это движок СУБД скажем умел бы вычислять в процессе сбора статистик... замедляя саму процедуру сбора :)
А где вы тут увидели стандартные средства? Автор измеряет три своих реализации. Первое очевидное предположение - что все измерения неверные. Второе почти столь же очевидное предположение - что две других реализации написаны не оптимально.
return sorted(set(divs)) # set() нужен, потому что по непонятной мне причине на степенях двойки появляется лишняя единица
Третье очевидное предположение - а откуда мы вообще знаем, что реализации дают верные результаты?
Тогда название хорошо бы немного уточнить. Керберос не сводится к AD и Windows. И получается что в нем самом (в виде FreeIPA скажем) такой уязвимости нет.
ER диаграммы еще разумеется используются при проектировании хранилищ. Но я совсем не уверен, что они не появились еще до UML.
И хотел бы заметить, что даже в проекте, где они у нас активно применялись, и из них генерился код, это не помогло прошлепать баг, когда одна из связей оказалась 1:1, а должна была быть 1:M. Т.е. все эту связь видели, но никто не заметил, что она не той кардинальности, пока в каком-то одном из последних отчетов не всплыло, что у объекта залога оказывается может быть больше одного владельца.
Ну то есть, весь код работы с БД был построен в расчете, что владелец один, и все приложение работало с этим кодом, и все формы и отчеты, кроме одного, были построены исходя из этого.
Поэтому на вопрос, улучшает ли описание в виде UML понимание проекта, ответ неоднозначный. Вроде и улучшает, а вот подиж ты...
Я вот про это. Не так уж редко бывает сложно сказать, какая именно документация официальная, и уж тем более, если две ее страницы дополняют (а то и противоречат друг другу) - то источника правды может вовсе и нет. Ну так, чисто для примера: насколько русская документация по постгресу от postgres pro является официальной? И если да, то она официальна для сборок postgres pro, или для ванильного postgresql тоже?
Почему не следует? Я такого не говорил. Я лишь оцениваю то что вижу, то что тут написано, и описываю как это выглядит с точки зрения нанимателя. Какие есть недостатки, реальные или нет - тут сказать сложно, а уж дальше дело автора решать, что с ними можно сделать. И вообще, стоит ли брать вот конкретно такого человека - очень сильно зависит от проекта. Человек, который делал проект в одно лицо, у него кстати есть и свои плюсы.
работать за 50% (и при этом выполнять 70% работы сеньора
Ну вот честно, никогда не видел такого. Обычно те кто готов работать за 50%, это те кто кое-как могут выполнять работу джуна. Те кто могут реально быть синьорами, все же как правило делали такую работу, и понимают, сколько они стоят. Они могут ошибаться в оценке себя, но мне очень сложно представить, чтобы синьор менял работу без прибавки в зарплате. Разумеется, с поправкой на разные жизненные обстоятельства типа эмиграции...
Ну мне кажется, проставить хинт - это для случая, когда вы точно знаете, что они малы. В моем проекте скажем вы обычно знаете в лучшем случае то, что они сравнительно маленькие, но не можете просто оценить, стоит ли их бродкастить.
как будет колебаться размер датафрейма от запуска к запуску
Согласен. Я бы это рассматривал как предмет для мониторинга. Т.е. завести такую метрику, и смотреть графики, ну или обучать модель. Рано или поздно многие к этому приходят.
Человек без опыта работы в коллективе, с непонятным набором знаний. Он скорее всего что-то умеет, но скорее всего - не то, что нужно для разработки в условном энтерпрайзе. Никакого систематического образования вероятно не получил.
Для меня вот нет ничего удивительного, что он не может найти работу. Хотя для автора это разумеется плохо.
Причем я бы еще сказал, что не только перестраивает, но и в данном конкретном случае выбирает, делать ли broadcast - в зависимости от размеров. Т.е. про конкретный пример прямо напрашивается вопрос, а пробовал ли автор AQE, и на какой версии спарка он сидит.
Баскетбол, настольный теннис, авиамоделирование... при этом в целом я совершенно согласен. Особенно если учесть, что учат они в 2024 году например jquery. Что на мой взгляд уже несколько лет как нонсенс.
Даже в блокноте текст отображается с использованием какого-то системного шрифта
Разного у того кто набирает и того кто читает. Именно поэтому я считаю что в формате блокнота шрифта нет. И заголовков там строго говоря нет. А вот абзацы есть.
кто-то назначает заголовку тег Н2 в маркдауне, он верстает текст.
Я просто подхожу к этому так: есть верстка, задающая отображение текста. И есть верстка скажем так, семантическая. И то и другое называют версткой, хотя смысл у них сильно разный. Не исключаю, что строгой границы между ними нет, и где-то они пересекаются.
Так вот, оформление текста с привязкой к странице, ее размеру, с выбором шрифта и т.п., как вы это ни называйте, я считаю вредным делать до того, как вы отредактировали сам текст. Именно потому, что это все равно может уехать. Это мой практический подход, основанный на множестве отредактированных текстов. Я его не навязываю, да и не все его смогут внедрить, особенно если ты не контролируешь весь процесс.
Без шрифта? А вы представляете, есть такой формат plain text :) ну или скажем markdown. Я не к тому, что надо так делать, я к тому, что преждевременная верстка до появления окончательного варианта самого текста - это пустая трата времени. Она потом с большой вероятностью съедет, а переделывать зачастую сложнее, чем сверстать с нуля.
P.S. Причем вы же ниже про это же пишете. О причудах редактора и плаче верстальщиков.
А учитывая, что мне приходится редактировать чужие тексты, лучше бы им не быть сверстанными Таймсом на всю ширину. Но это — повторюсь — субъективное.
Ну почему прямо субъективное? Я вот думаю (а я отредактировал сотни и тысячи страниц текстов, хоть я и не профессиональный редактор), если текст еще будет кем-то редактироваться, лучше ему вообще не быть сверстанным. Потому что верстать его раньше чем он готов - только зря время тратить. То есть, в нем могут быть абзацы, заголовки, т.е. структура, но не должно быть шрифтов или там выравнивания. Это все потом.
m - постоянная, то, что мы вытащим с Земли наверх в баке, независимо от того, водород это, кислород, или ксенон
Не совсем так. 1 кило водорода и 1 кило керосина - это конечно одно и тоже, но масса бака с жидким водородом и масса бака с керосином - это две большие разницы. Содержимое бака по массе одинаковое, по объему уже нет, и масса самого бака может сильно отличаться.
Ну то есть, водород выгоднее энергетически, но менее выгоден с точки зрения хранения, потому что а) объем, даже в жидком виде б) текучесть в) взрывоопасность.
И таки да, удельный импульс - это не расход топлива конечно же, это расход топлива на единицу тяги.
Ну это не совсем правда, а точнее не вся, т.е. это упрощение.
Эти слова все желательные, но не необходимые.
И потом, знаете, я вот знаю итальянский ровно на этом уровне, т.е. мой словарный запас где-то слов 100 (очень примерная субъективная оценка). Но разница между запасом активным и пассивным все равно имеет место и тут, т.е. я не вспомню скажем названия всех цветов сам - но пойму, когда мне скажут verde, что это зеленый, без проблем. С числами та же фигня. Могу ли я общаться? Так общаюсь же... как-то.
Как там Фигаро выражался в незабываемом спектакле - чтобы общаться с англичанами достаточно знать только "god dammit". И там же был прекрасно проиллюстрирован уровень этого общения :)
На практике это означает фуллскан, а значит в реальных условиях больших таблиц эти идеи могут оказаться неприменимы. Если бы это движок СУБД скажем умел бы вычислять в процессе сбора статистик... замедляя саму процедуру сбора :)
А где вы тут увидели стандартные средства? Автор измеряет три своих реализации. Первое очевидное предположение - что все измерения неверные. Второе почти столь же очевидное предположение - что две других реализации написаны не оптимально.
Третье очевидное предположение - а откуда мы вообще знаем, что реализации дают верные результаты?
Тогда название хорошо бы немного уточнить. Керберос не сводится к AD и Windows. И получается что в нем самом (в виде FreeIPA скажем) такой уязвимости нет.
Впрочем, там написано "Разработка под Windows"...
Я правильно понял, что эта уязвимость - Windows only, так как фактически для эксплуатации используется DCOM?
ER диаграммы еще разумеется используются при проектировании хранилищ. Но я совсем не уверен, что они не появились еще до UML.
И хотел бы заметить, что даже в проекте, где они у нас активно применялись, и из них генерился код, это не помогло прошлепать баг, когда одна из связей оказалась 1:1, а должна была быть 1:M. Т.е. все эту связь видели, но никто не заметил, что она не той кардинальности, пока в каком-то одном из последних отчетов не всплыло, что у объекта залога оказывается может быть больше одного владельца.
Ну то есть, весь код работы с БД был построен в расчете, что владелец один, и все приложение работало с этим кодом, и все формы и отчеты, кроме одного, были построены исходя из этого.
Поэтому на вопрос, улучшает ли описание в виде UML понимание проекта, ответ неоднозначный. Вроде и улучшает, а вот подиж ты...
Я вот про это. Не так уж редко бывает сложно сказать, какая именно документация официальная, и уж тем более, если две ее страницы дополняют (а то и противоречат друг другу) - то источника правды может вовсе и нет. Ну так, чисто для примера: насколько русская документация по постгресу от postgres pro является официальной? И если да, то она официальна для сборок postgres pro, или для ванильного postgresql тоже?
Кстати, далеко не факт, что у вас двоих третья ссылка в поиске - одна и та же страница.
А что практически нужно предъявить в качестве подтверждения английского B2?
Баллистические ракеты все статически неустойчивы. Пожалуй не 50, а все 70 уже.
Есть классический способ - обойти HR фильтры. Т.е. чтобы вас взяли "по знакомству". Но как получить эти самые знакомства - вот тут я вам не подскажу.
Почему не следует? Я такого не говорил. Я лишь оцениваю то что вижу, то что тут написано, и описываю как это выглядит с точки зрения нанимателя. Какие есть недостатки, реальные или нет - тут сказать сложно, а уж дальше дело автора решать, что с ними можно сделать. И вообще, стоит ли брать вот конкретно такого человека - очень сильно зависит от проекта. Человек, который делал проект в одно лицо, у него кстати есть и свои плюсы.
Ну вот честно, никогда не видел такого. Обычно те кто готов работать за 50%, это те кто кое-как могут выполнять работу джуна. Те кто могут реально быть синьорами, все же как правило делали такую работу, и понимают, сколько они стоят. Они могут ошибаться в оценке себя, но мне очень сложно представить, чтобы синьор менял работу без прибавки в зарплате. Разумеется, с поправкой на разные жизненные обстоятельства типа эмиграции...
Ну мне кажется, проставить хинт - это для случая, когда вы точно знаете, что они малы. В моем проекте скажем вы обычно знаете в лучшем случае то, что они сравнительно маленькие, но не можете просто оценить, стоит ли их бродкастить.
Согласен. Я бы это рассматривал как предмет для мониторинга. Т.е. завести такую метрику, и смотреть графики, ну или обучать модель. Рано или поздно многие к этому приходят.
Человек без опыта работы в коллективе, с непонятным набором знаний. Он скорее всего что-то умеет, но скорее всего - не то, что нужно для разработки в условном энтерпрайзе. Никакого систематического образования вероятно не получил.
Для меня вот нет ничего удивительного, что он не может найти работу. Хотя для автора это разумеется плохо.
Причем я бы еще сказал, что не только перестраивает, но и в данном конкретном случае выбирает, делать ли broadcast - в зависимости от размеров. Т.е. про конкретный пример прямо напрашивается вопрос, а пробовал ли автор AQE, и на какой версии спарка он сидит.
Баскетбол, настольный теннис, авиамоделирование... при этом в целом я совершенно согласен. Особенно если учесть, что учат они в 2024 году например jquery. Что на мой взгляд уже несколько лет как нонсенс.
Разного у того кто набирает и того кто читает. Именно поэтому я считаю что в формате блокнота шрифта нет. И заголовков там строго говоря нет. А вот абзацы есть.
Я просто подхожу к этому так: есть верстка, задающая отображение текста. И есть верстка скажем так, семантическая. И то и другое называют версткой, хотя смысл у них сильно разный. Не исключаю, что строгой границы между ними нет, и где-то они пересекаются.
Так вот, оформление текста с привязкой к странице, ее размеру, с выбором шрифта и т.п., как вы это ни называйте, я считаю вредным делать до того, как вы отредактировали сам текст. Именно потому, что это все равно может уехать. Это мой практический подход, основанный на множестве отредактированных текстов. Я его не навязываю, да и не все его смогут внедрить, особенно если ты не контролируешь весь процесс.
Без шрифта? А вы представляете, есть такой формат plain text :) ну или скажем markdown. Я не к тому, что надо так делать, я к тому, что преждевременная верстка до появления окончательного варианта самого текста - это пустая трата времени. Она потом с большой вероятностью съедет, а переделывать зачастую сложнее, чем сверстать с нуля.
P.S. Причем вы же ниже про это же пишете. О причудах редактора и плаче верстальщиков.
Ну почему прямо субъективное? Я вот думаю (а я отредактировал сотни и тысячи страниц текстов, хоть я и не профессиональный редактор), если текст еще будет кем-то редактироваться, лучше ему вообще не быть сверстанным. Потому что верстать его раньше чем он готов - только зря время тратить. То есть, в нем могут быть абзацы, заголовки, т.е. структура, но не должно быть шрифтов или там выравнивания. Это все потом.
Не совсем так. 1 кило водорода и 1 кило керосина - это конечно одно и тоже, но масса бака с жидким водородом и масса бака с керосином - это две большие разницы. Содержимое бака по массе одинаковое, по объему уже нет, и масса самого бака может сильно отличаться.
Ну то есть, водород выгоднее энергетически, но менее выгоден с точки зрения хранения, потому что а) объем, даже в жидком виде б) текучесть в) взрывоопасность.
И таки да, удельный импульс - это не расход топлива конечно же, это расход топлива на единицу тяги.