По-моему Сеньор -- это человек, который может брать и реализовывать большие куски проекта или целые проекты при этом не задавая мелких вопросов на каждый чих. Если человеку можно дать работу и быть уверенным что всё будет сделано и результат будет вменяемый, то он сеньор.
Конечно проекты и задачи бывают разного размера и сложности и ожидания насчёт "всё вменяемо" в разных организациях разные. Что именно называется сеньором в разных организациях -- это их личное дело. Единственно правильного ответа тут нет.
Да, я тоже удивился. На самом деле, конечно, всё наоборот, TSMC будет производить чипы для Intel. Это позволит им не ждать свою фаундри и сходу конкурировать с AMD на TSMC-шном процессе. Ну и потом можно продолжать комбинировать свою фаундри и TSMC, благо с чиплетами (простите, тайлами) для этого есть богатые возможности.
В таком плане есть риск что TSMC будет сильно лучше своей фаундри, и производство будет потихоньку перетекать к ним, но Интелу сейчас выбирать не приходится.
Статья отличная, но вот тут по-моему не совсем всё точно:
> Если планы реализуются, то Intel сохранит действие закона Мура и догонит AMD/TSMC.
Догонять AMD Интелу не надо. AMD не производит микросхемы сама, а заказывает их у TSMC. Интел тоже так может делать и на самом деле уже и делает.
А вот догнать TSMC к 2029-му году будет весьма непросто. TSMC сейчас заканчивает работу над 3нм — пока оно не в массовом производстве, но фабрики строятся и заказы получены. Работа над 2нм уже тоже началась. Тем временем, Интел остаёт от роадмапа на картинке: 10нм вот только-только кажется доделали, с 7нм пока проблемы. На стороне Интел тот факт что их 7нм примерно эквивалентен 5нм от TSMC и Samsung, но всё равно они остают на несколько лет и, что более важно, движутся вперёд медленнее. Я всячески болею за Интел и надеюсь у них получится в будущем опять серьёзно пободаться с TSMC и Samsung, но для этого понадобятся экстраординарные меры.
20 лет опыта программирования и я вполне нормально отношусь к программированию на собеседованиях — это весело и молодёжно. Не все сеньоры ненавидят собеседования с кодингом.
Задачу домой — тоже ок, но это немного другой вид спорта и он тестирует другой набор навыков. Что клёво в лайв-кодинге — это то что можно вместе подумать над задачей и сразу посмотреть как кандидат мыслит и как он общается. А это тоже важные навыки для программистов.
Ваш пример про учительницу не совсем аналогичный, так как кодинг-задачи на интервью гораздо проще чем боевое программирование. А попросить учительницу объяснить умножение столбиком, чтобы посмотреть как она объясняет — это по-моему ок.
Ещё одно важное замечание про кодинг-интервью: люди, которые участвовали в соревнованиях по программированию, умеют лайв-кодинг гораздо лучше обычных программистов и стоит делать на это поправку. Ну и понятно что не кодингом единым ограничивается работа программиста, особенно если он сеньор, так что не стоит всё время собеседования на это тратить.
Регулирование бизнеса государством в интересах жителей страны — вполне обычное дело, и это происходит везде. Налоги, антимонопольное законодательство, законы об интеллектуальной собственности (да и о не интеллектуальной тоже) и ограничение на передачу контроля над важными для страны компаниями — это общепринятая практика. Совсем свободный рынок плохо работает, так что (почти) всем лучше если есть компетентное и не коррумпированное правительство, которе его регулирует. Насколько британское правительство компетентно и не коррумпировано я судить не берусь, но то что передача Арма Нвидии не в интересах Великобритании — в это я легко верю, так что тут мне кажется они всё правильно делают.
Вообще фаундри конечно дофига, но если речь идёт о производстве чипов для Apple, то кроме Samsung есть разве что Intel (я смотрю на вот этот список фабов). А насчёт «тут же займёт»: TSMC это >50% рынка фаундри и они на пару лет впереди по технологиям даже по сравнению с Samsung и Intel — быстро занять их место по-моему сейчас не может никто.
Сама — это значит заказывает производство TSMC (которые кстати тоже не слишком далеко от монополии на рынке фаундри). Вот с ними можно и договориться, как недавно американцы «договорились» чтобы они не делали чипы для Huawei.
Да, я конечно не ожидал что от этого моего комментария до победы компьютера над профессиональным 9-м даном пройдёт всего год. Я тогда не знал что DeepMind этим уже занимается и думал что ещё лет 5-10 понадобится. Но с другой стороны матч против Ли Седола в 2016-м ещё был на куче железа (48 TPU на нескольких серверах) и до сверхчеловеческого уровня на домашнем ПК потребовалось ещё несколько лет.
Отлично, но ваш калькулятор полагается на то, что число случаев в среднем удваивается за 5 дней. Это верно только если никаких мер не принимать, то есть в данный момент в большинстве стран калькулятор неприменим.
Я имел ввиду, что если мы знаем IFR и знаем сколько смертей в день сейчас происходит, то можно прикинуть сколько заражалось в день две недели назад (или сколько там в среднем получится), а от этого, зная скорость умножения инфекции в эти последние две недели (можно прикинуть по динамике официальных случаев и смертности) можно прикинуть сколько новых заражённых сегодня. Во всех этих числах есть неточности конечно, но порядок хотя бы можно оценить.
О, кстати, есть вот ещё какая штука: если мы знаем IFR в какой-то стране, то зная количество смертей можно попробовать оценить общее количество случаев. Понятно что если это делать наивно, то мы получим сколько было случаев две недели назад, но это можно откорректировать. Общее число случаев и его динамика — это весьма полезные метрики, которые позволяют оценить личный уровень риска, понять насколько работают существующие меры и нужно ли добавить или убавить мер.
Вы наверняка это и так знаете, но в посте не написали, а это по-моему важный момент.
IFR тоже не один у всех, он зависит от возрастной структуры населения, состояния и загрузки медицинской системы, и ещё бог знает от чего. По оценкам, которые я видел, получается что-т типа 0.5% если хватает аппаратов ИВЛ и прочей интенсивной терапии на все тяжёлые случаи и 2.5% если не хватает. В Италии чуть больше, так как там более старое население. В любом случае это выглядит гораздо хуже чем грипп, тут я с вами согласен.
> Но посыл поста вообще был не в оценках и прогнозах.
> вот только оценка недокументированных случаев (86%) не применима к более поздним данным, когда начали выявлять много новых случаев.
Ну ок, не применима. То есть мы не знаем как посчитать IFR от CFR = 4%. Но это же не значит что можно эту цифру выкинуть и делать вид что CFR всё ещё 18%.
> На графике новых случаев в Китае хорошо виден резкий скачок — это как раз начали тестировать не только по ПЦР
Он не очень большой, там всего где-то 10к случаев добавилось по сравнению с обычной скоростью роста в тот момент. То есть это точно не близко к 85% и после скачка всё равно скорее всего много непосчитанных случаев. Согласен что мы не знаем точно сколько, но это можно оценить и всё равно сегодняшние цифры мне кажутся более информативными.
Совершенно верно. Автор построил отличную мат модель, но забыл что надо ещё проверить применима ли она к реальной жизни. Модель, которая предполагает удвоение случаев каждые 5 дней к Китаю сегодня неприменима.
Согласен. Я говорил про миксины, от которых класс просто наследуется. А прикручивание стороннего миксина на ходу из другого модуля по-моему не очень сильно отличается от манки-питчинга — мне не сильно легче от того что пять сторонних методов, которые неизвестно откуда оказались в моём классе, оказывается все пришли из одного класса.
С другой стороны, в некоторых языках вброс методов, или конструкции, на него похожие, выглядит довольно естественно. Например реализация трэйтов для чужих структур данных в Расте имеет что-то общее с вставкой методов в чужой класс. Но разработчики Раста защитились от хаоса: во-первых там нельзя реализовывать чужие трэйты для чужих типов (можно только реализовывать свой трэйт для чужого типа или чужой трэйт для своего типа), так как это редко нужно и приводит к проблемам, а во-вторых строгий компилятор со строгой системой типов сильно сужает возможности прострелить себе ногу. Ну и конечно Раст вообще не особо ООП язык и трэйты больше похожи на тайп-классы из Хаскеля.
contextmanager пробовал, забыл про него. Для меня это еще 1 минус языка — чтобы не добавлять многострочные лямбды, добавили сомнительную конструкцию языка и к ней костыль. Во мне негодует Оккам. Возвращать значения из with все равно нельзя вроде, поэтому мне этот способ не подошел в реальной ситуации.
Контекст менеджеры не являются заменой многострочных лямбд. Понятно что с помощью многострочных лямбд можно сделать что-то похожее, и это даже в некотором смысле элегантно, но контекст менеджеры — это менее универсальное и более простое решение только одной конкретное проблемы, а не всего что можно делать лямбдами. Ну и ещё Питонисты слишком подозрительно относятся к функциональному программированию, чтобы вместо контекст менеджеров использовать многострочные лямбды. Это конечно жаль что они не любят функпрог больше, но Питон был бы совсем другим, если бы он пошёл навстречу функциональным техникам и скорее всего потерялась бы часть простоты и читаемости, а это для Питона важнее.
Кстати, если негодует Оккам, надо пописать на Лиспе и обычно отпускает (не всегда правда отпускает, но это тоже ок :).
Для того чтобы посмотреть код модуля/метода, список методов объекта и, какие из какого модуля добавлены, не нужно никаких IDE — есть библиотека pry, написанная на руби. Похожего для других языков я не встречал.
В большинстве ООП языков добавление методов в чужие классы считается хаком и не поощряется (а иногда и вообще невозможно). Потому что инкапсуляция от этого ломается. Если в Руби это обычная практика, то это довольно сильное отличие от ООП мэйнстрима.
Не очень понял какой будет ответ на мой вопрос из предыдущего комментария, посчитаю что вам не кажется что вменяемые программисты на Руби, которые хорошо знают язык лучше относятся к магии чем их Питон-эквиваленты. Это хорошо, проапдейчусь в сторону меньшей разницы в одобрении магии между сообществами.
Касательно Python, по-моему, большое колличество особенных методов вида __len__ — это более магически. Даже их вид настораживает. При этом их необходимо использовать, чтобы пользоваться основными конструкциями языка.
Методы типа __len__ — почти все магия (кроме разве что __init__). Лучше их не трогать если нет на то серьёзных причин. Конкретно __len__ нужен если реализуешь что-то типа коллекции и не можешь понаследоваться от чего-то, у чего уже есть __len__. Мне кажется что специальный вид магических методов оправдан — сразу всем видно что это не простые методы.
Мне особенно не нравится with с __enter__ и __exit__.
Ваш пример с пулингом соединений — в общем-то нормальный юзкейс для __enter__/__exit__, но реализация в вашем примере слегка против шерсти Питона. Пожалуй самый удобный способ это сделать пожалуй через декоратор contextlib.contextmanager (в этом случае мы сами магии не делаем а используем заготовки из стандартной библиотеки):
import contextlib
class Pool:
@contextlib.contextmanager
def get_connection(self, timeout):
connection = self._check_out(timeout)
try:
yield connection
finally:
self._check_in(connection)
with pool.get_connection(42) as connection:
connection.get('some')
Пример с временным переключением уровня логирования мне кажется более спорным. Аналогичное решение с контекст-менеджерами на Питоне было бы, на мой вкус, слишком магично для обычного приложения и слишком не threadsafe для библиотеки. Как сделать лучше сходу не знаю, так как я не очень понимаю мотивацию этого примера.
Были бы многострочные лямбды, было бы лучше, наврное
По-моему Сеньор -- это человек, который может брать и реализовывать большие куски проекта или целые проекты при этом не задавая мелких вопросов на каждый чих. Если человеку можно дать работу и быть уверенным что всё будет сделано и результат будет вменяемый, то он сеньор.
Конечно проекты и задачи бывают разного размера и сложности и ожидания насчёт "всё вменяемо" в разных организациях разные. Что именно называется сеньором в разных организациях -- это их личное дело. Единственно правильного ответа тут нет.
Да, я тоже удивился. На самом деле, конечно, всё наоборот, TSMC будет производить чипы для Intel. Это позволит им не ждать свою фаундри и сходу конкурировать с AMD на TSMC-шном процессе. Ну и потом можно продолжать комбинировать свою фаундри и TSMC, благо с чиплетами (простите, тайлами) для этого есть богатые возможности.
В таком плане есть риск что TSMC будет сильно лучше своей фаундри, и производство будет потихоньку перетекать к ним, но Интелу сейчас выбирать не приходится.
> Если планы реализуются, то Intel сохранит действие закона Мура и догонит AMD/TSMC.
Догонять AMD Интелу не надо. AMD не производит микросхемы сама, а заказывает их у TSMC. Интел тоже так может делать и на самом деле уже и делает.
А вот догнать TSMC к 2029-му году будет весьма непросто. TSMC сейчас заканчивает работу над 3нм — пока оно не в массовом производстве, но фабрики строятся и заказы получены. Работа над 2нм уже тоже началась. Тем временем, Интел остаёт от роадмапа на картинке: 10нм вот только-только кажется доделали, с 7нм пока проблемы. На стороне Интел тот факт что их 7нм примерно эквивалентен 5нм от TSMC и Samsung, но всё равно они остают на несколько лет и, что более важно, движутся вперёд медленнее. Я всячески болею за Интел и надеюсь у них получится в будущем опять серьёзно пободаться с TSMC и Samsung, но для этого понадобятся экстраординарные меры.
Задачу домой — тоже ок, но это немного другой вид спорта и он тестирует другой набор навыков. Что клёво в лайв-кодинге — это то что можно вместе подумать над задачей и сразу посмотреть как кандидат мыслит и как он общается. А это тоже важные навыки для программистов.
Ваш пример про учительницу не совсем аналогичный, так как кодинг-задачи на интервью гораздо проще чем боевое программирование. А попросить учительницу объяснить умножение столбиком, чтобы посмотреть как она объясняет — это по-моему ок.
Ещё одно важное замечание про кодинг-интервью: люди, которые участвовали в соревнованиях по программированию, умеют лайв-кодинг гораздо лучше обычных программистов и стоит делать на это поправку. Ну и понятно что не кодингом единым ограничивается работа программиста, особенно если он сеньор, так что не стоит всё время собеседования на это тратить.
Сама — это значит заказывает производство TSMC (которые кстати тоже не слишком далеко от монополии на рынке фаундри). Вот с ними можно и договориться, как недавно американцы «договорились» чтобы они не делали чипы для Huawei.
Я имел ввиду, что если мы знаем IFR и знаем сколько смертей в день сейчас происходит, то можно прикинуть сколько заражалось в день две недели назад (или сколько там в среднем получится), а от этого, зная скорость умножения инфекции в эти последние две недели (можно прикинуть по динамике официальных случаев и смертности) можно прикинуть сколько новых заражённых сегодня. Во всех этих числах есть неточности конечно, но порядок хотя бы можно оценить.
Вы наверняка это и так знаете, но в посте не написали, а это по-моему важный момент.
> Но посыл поста вообще был не в оценках и прогнозах.
Ну ок, а в чём он тогда был?
Ну ок, не применима. То есть мы не знаем как посчитать IFR от CFR = 4%. Но это же не значит что можно эту цифру выкинуть и делать вид что CFR всё ещё 18%.
> На графике новых случаев в Китае хорошо виден резкий скачок — это как раз начали тестировать не только по ПЦР
Он не очень большой, там всего где-то 10к случаев добавилось по сравнению с обычной скоростью роста в тот момент. То есть это точно не близко к 85% и после скачка всё равно скорее всего много непосчитанных случаев. Согласен что мы не знаем точно сколько, но это можно оценить и всё равно сегодняшние цифры мне кажутся более информативными.
Совершенно верно. Автор построил отличную мат модель, но забыл что надо ещё проверить применима ли она к реальной жизни. Модель, которая предполагает удвоение случаев каждые 5 дней к Китаю сегодня неприменима.
С другой стороны, в некоторых языках вброс методов, или конструкции, на него похожие, выглядит довольно естественно. Например реализация трэйтов для чужих структур данных в Расте имеет что-то общее с вставкой методов в чужой класс. Но разработчики Раста защитились от хаоса: во-первых там нельзя реализовывать чужие трэйты для чужих типов (можно только реализовывать свой трэйт для чужого типа или чужой трэйт для своего типа), так как это редко нужно и приводит к проблемам, а во-вторых строгий компилятор со строгой системой типов сильно сужает возможности прострелить себе ногу. Ну и конечно Раст вообще не особо ООП язык и трэйты больше похожи на тайп-классы из Хаскеля.
Контекст менеджеры не являются заменой многострочных лямбд. Понятно что с помощью многострочных лямбд можно сделать что-то похожее, и это даже в некотором смысле элегантно, но контекст менеджеры — это менее универсальное и более простое решение только одной конкретное проблемы, а не всего что можно делать лямбдами. Ну и ещё Питонисты слишком подозрительно относятся к функциональному программированию, чтобы вместо контекст менеджеров использовать многострочные лямбды. Это конечно жаль что они не любят функпрог больше, но Питон был бы совсем другим, если бы он пошёл навстречу функциональным техникам и скорее всего потерялась бы часть простоты и читаемости, а это для Питона важнее.
Кстати, если негодует Оккам, надо пописать на Лиспе и обычно отпускает (не всегда правда отпускает, но это тоже ок :).
В большинстве ООП языков добавление методов в чужие классы считается хаком и не поощряется (а иногда и вообще невозможно). Потому что инкапсуляция от этого ломается. Если в Руби это обычная практика, то это довольно сильное отличие от ООП мэйнстрима.
Методы типа __len__ — почти все магия (кроме разве что __init__). Лучше их не трогать если нет на то серьёзных причин. Конкретно __len__ нужен если реализуешь что-то типа коллекции и не можешь понаследоваться от чего-то, у чего уже есть __len__. Мне кажется что специальный вид магических методов оправдан — сразу всем видно что это не простые методы.
Ваш пример с пулингом соединений — в общем-то нормальный юзкейс для __enter__/__exit__, но реализация в вашем примере слегка против шерсти Питона. Пожалуй самый удобный способ это сделать пожалуй через декоратор contextlib.contextmanager (в этом случае мы сами магии не делаем а используем заготовки из стандартной библиотеки):
Пример с временным переключением уровня логирования мне кажется более спорным. Аналогичное решение с контекст-менеджерами на Питоне было бы, на мой вкус, слишком магично для обычного приложения и слишком не threadsafe для библиотеки. Как сделать лучше сходу не знаю, так как я не очень понимаю мотивацию этого примера.
Да, этого не хватает, было бы здорово.