Информация о вашей зарплате может не быть коммерческой тайной, но является конфиденциальной информацией которую банки, налоговая, и другие службы не могут передавать третьим лицам.
Когда у меня жена работала чиновником, то их ежегодно заставляли сдавать декларацию о доходах всех близких родственников - с указанием источников, счетов, недвижимости и т.п. Потом все это выкладывалось в паблик.
Т.е. там, допустим, конкатенация строк плюсом вообще не создаст проблем, потому что вы всегда видите, что складываете строки
Если код тайпчекается это ещё не значит, что в нем нет ошибок. С точки зрения математики есть вполне конкретные ожидания, какие свойства должны выполняться для плюса. Если они не выполняются, то в этом месте возникают лишние трения. А так да, программирование лояльно относится к неймингу - "хоть горшком назови, только в печку не ставь".
То есть, даже после того, как вы его пофиксили, вы не можете быть в этом уверены (что не помешает на радостях напиться). Вот это — действительно страшно, а причина сему — unmanaged-среда.
JS в этом смысле managed с ног до головы, поэтому о таких вещах ни кто здесь даже не задумывается.
Я тоже когда-то писал COM/DCOM и могу сказать, что современные инструменты реально ушли далеко вперёд, в смысле количества разложенных граблей, на которые может случайно наступить разработчик.
А если всё делать так, чтобы разные сущности всегда обозначались разными символами – может не хватить символов
В программировании есть два греха: когда одинаковые по сути вещи называют разными именами, и когда разные называют одинаково.
Если серьезно - посмотрите на хаскель. Здесь любую бинарную функцию можно записать как инфиксный оператор.
(+) 1 2 можно записать как 1 + 2
Не хватает одного символа? Просто возьмите больше: два, три, .. - сколько надо. Здесь в этом смысле полный коммунизм - каждому по потребности: name <- read <$> getLine
тут надо использовать оператор умножения (см. термины "полугруппа", "моноид")
В этом смысле любой бинарную операцию можно назвать умножением. Но на практике думаю в этом мало толку.
Если это про отношение к войнам, тогда я тоже вайнах. После армии как-то особенно.
Хотя приравнивать игры в танчики в детском саду к реальным войнам это как рисунки, где дети изображают маму с папой, приравнивать к прону (а чё они ведь тоже люди). В общем, контекст тут важен.
Мне структурные типы в TS кажутся выразительнее, чем номинальные как в Java. Плюс в нем более продвинутая алгебра типов, у которой понятно из каких разделов математической логики растут ноги. Но вполне допускаю, что это вкусовщина.
Мы не живём в России уже много лет, оставаясь при этом гражданами. В прошлом году за границей родился третий ребенок.
От РФ, жена получила статус многодетной и разовое пособие около 5 т.р.
Плюс ей открыли социальную карточку, куда теперь возвращается часть оплаты за коммуналку, которую я плачу за оставшуюся дома квартиру. Такого кэшбэка хватает на то, чтобы заплатить сотовому оператору за симки, куда приходят смс от банка, где открыт счёт, ... ну вы поняли.
Материнский капитал третьему ребенку не положен. Для выплаты пособия по уходу до 1.5 лет нужно показать или официальный заработок за два года у того кто будет сидеть в декрете, или отсутствие дохода свыше какой-то там суммы (чтобы рассчитывать на минимальное). Заработка понятно нет. Зато в банке у нее оказался небольшой вклад, проценты по которому за несколько лет сочли доходом. В общем ей ни чего не дали. Какие-то выплаты возможны для малообеспеченных, но мы не попали и под эти критерии (уф).
Оформление всех документов, включая документы на ребенка, рождённого за границей, с бегатней по разным инстанциям, заняло почти два месяца. Они были на каникулах, в гостях у бабушки, поэтому было свободное время этим заниматься.
При одинаковых условиях, семьи где работают оба супруга будут иметь значительно больший доход. Пусть и не в два раза.
От ситуации зависит. У жены практически вся зарплата госслужащией (что-то около 15т.р.) уходила на ту же работу: проездной (1.5т.р) и обеды (500*23=11.5т.р.). С учётом одежды, косметики и периодических больничных из-за сквозняков и стресса затея получалась планово убыточной. Чисто экономически ей было выгоднее ни куда не ездить, а сидеть дома.
если мать не работает, или ИП, то отец-айтишник, может взять отпуск по уходу за ребенком, тут же снова выйти на работу, и таким образом получить ~50к в месяц дополнительного дохода,
Там масса оговорок. Например, если мама не работает, то отпуск и пособия папе не дадут. Выбор появляется если мама работает официально или вы одинокий отец.
Мне кажется, что в примере есть ещё и историческое несоответствие с заявленным:
Подобное может быть верным лишь для только родившегося JS
В момент появления JavaScript, доступ к элементам был в силе "document.myForm.myInput", и это работало буквально лишь для нескольких типов (form, img и может ещё пары каких-то).
document.getElementById(), ровно как и весь DOM, это более позднее изобретение.
Код на слайде выглядит как лет на 10 позже. Т.е. JavaScript к тому времени не только родился, но уже и в школу пошёл.)
Типизация должна быть сделана на уровне рантайма, а не на уровне языка. Создатели TS рантайм не контролировали, и поэтому запилили транспиляцию.
Статическая типизация - это проверка типов на этапе компиляции. Ровно то, что реализовано в TS.
Проверка типов в рантайме это строгая типизация. Она несёт за собой дополнительные накладные расходы и тут всегда возникает tradeoff между строгостью и performance. Проверяйте входные данные, а в остальном можно жить и без этого.
если мы говорим о его использовании в микроконтроллера
У меня есть пара плат с Espurino. Это JavaScript для микроконтроллеров. Там где не важны задержки и плевать на энергоэффективность (а это львиная доля всей домашней автоматизации), писать логику на JS одно условие.
Для тех, кто у вас спрашивает оценки, а потом назначат их же вам как дедлайны - наверняка в аду приготовлен отдельный котёл.
Вообще задачи условно делятся на две категории. 1. Которые понятно как делать. 2. Которые - не понятно.
Задачи первого рода есть всегда и вы можете дать для них оценку с большой долей достоверности. Так сделайте это.
Если столкнулись с задачей второго рода, то положите в спринт спайк с задачей на исследование, и целью - родить план для дальнейших действий, которые уже сможете оценить. Установите на нее психологически и финансово комфортный лимит по времени сверху. Все у вас снова есть вполне правдоподобная оценка.
В итоге все задуманное либо будет оценено и выполнено. Либо вы от чего-то откажетесь, если сочтёте нерешаемым. Но у вас для этого уже будут все основания.
нам дали десять (двадцать, сто) камней, чтобы сложить стену, но мы не знаем, как это делать... "учи кирпичи!"
Между двадцатью и ста есть разница.
Ради интереса, попробуйте оценить: сколько времени у вас займет собрать пазл из соответствующего количества плиток? Здесь ведь даже учить ничего не надо - просто собрать. А потом реально собрать и порефлексировать над результатами.
Чтобы ещё больше приблизить игру к реальности, попробуйте предварительно смешать плитки из нескольких однотипных наборов. Просто в конце покажете несколько картинок, сложенных рядом.
Половину из них раздайте детям - с условием, чтобы они все вернули ровно через час. Оставшейся половины вам ведь точно должно хватить, чтобы не сидеть без дела всё это время?
Да, кто-то из детей потом может опоздать. Кто-то в процессе потеряетет какие-то детали, но чтобы не огорчать отца, заменит на примерно похожие. Поэтому разницы сразу вы не заметите. Но в конце результат у вас все равно должен быть как на макете.
Теперь снова прикиньте оценку. А может вам хватит простого коэффициента?)
Я называю это наркомания - стремление получить удовлетворение как можно быстрее. На это подсаживаешься, это вызывает привыкание, отсутствие быстрых результатов приводит к ломке и даже - выгоранию. В таком состоянии люди готовы буквально на всё, чтобы получить очередную дозу своего удовольствия сию секунду, даже на преступление.
Когда менеджеры требуют оценку немедленно, программисты коммитят код без тестов, чтобы закрыть задачу, а тестировщики красят в зелёный неглядя - вот это оно.
Когда у меня жена работала чиновником, то их ежегодно заставляли сдавать декларацию о доходах всех близких родственников - с указанием источников, счетов, недвижимости и т.п. Потом все это выкладывалось в паблик.
Интересно, что это была за компания (если это тоже не какой-то секрет)?
Если код тайпчекается это ещё не значит, что в нем нет ошибок. С точки зрения математики есть вполне конкретные ожидания, какие свойства должны выполняться для плюса. Если они не выполняются, то в этом месте возникают лишние трения. А так да, программирование лояльно относится к неймингу - "хоть горшком назови, только в печку не ставь".
Благодарите родителей за то, что у вас есть хобби. Многие начинают ненавидеть любимое занятие, когда оно превращается в работу.
JS в этом смысле managed с ног до головы, поэтому о таких вещах ни кто здесь даже не задумывается.
Я тоже когда-то писал COM/DCOM и могу сказать, что современные инструменты реально ушли далеко вперёд, в смысле количества разложенных граблей, на которые может случайно наступить разработчик.
Удовольствие :)
В программировании есть два греха: когда одинаковые по сути вещи называют разными именами, и когда разные называют одинаково.
Если серьезно - посмотрите на хаскель. Здесь любую бинарную функцию можно записать как инфиксный оператор.
Не хватает одного символа? Просто возьмите больше: два, три, .. - сколько надо. Здесь в этом смысле полный коммунизм - каждому по потребности: name <- read <$> getLine
В этом смысле любой бинарную операцию можно назвать умножением. Но на практике думаю в этом мало толку.
Если это про отношение к войнам, тогда я тоже вайнах. После армии как-то особенно.
Хотя приравнивать игры в танчики в детском саду к реальным войнам это как рисунки, где дети изображают маму с папой, приравнивать к прону (а чё они ведь тоже люди). В общем, контекст тут важен.
Мне структурные типы в TS кажутся выразительнее, чем номинальные как в Java. Плюс в нем более продвинутая алгебра типов, у которой понятно из каких разделов математической логики растут ноги. Но вполне допускаю, что это вкусовщина.
Это динамическая типизация. Она может быть строгой, ну или как в JS).
Мы не живём в России уже много лет, оставаясь при этом гражданами. В прошлом году за границей родился третий ребенок.
От РФ, жена получила статус многодетной и разовое пособие около 5 т.р.
Плюс ей открыли социальную карточку, куда теперь возвращается часть оплаты за коммуналку, которую я плачу за оставшуюся дома квартиру. Такого кэшбэка хватает на то, чтобы заплатить сотовому оператору за симки, куда приходят смс от банка, где открыт счёт, ... ну вы поняли.
Материнский капитал третьему ребенку не положен. Для выплаты пособия по уходу до 1.5 лет нужно показать или официальный заработок за два года у того кто будет сидеть в декрете, или отсутствие дохода свыше какой-то там суммы (чтобы рассчитывать на минимальное). Заработка понятно нет. Зато в банке у нее оказался небольшой вклад, проценты по которому за несколько лет сочли доходом. В общем ей ни чего не дали. Какие-то выплаты возможны для малообеспеченных, но мы не попали и под эти критерии (уф).
Оформление всех документов, включая документы на ребенка, рождённого за границей, с бегатней по разным инстанциям, заняло почти два месяца. Они были на каникулах, в гостях у бабушки, поэтому было свободное время этим заниматься.
От ситуации зависит. У жены практически вся зарплата госслужащией (что-то около 15т.р.) уходила на ту же работу: проездной (1.5т.р) и обеды (500*23=11.5т.р.). С учётом одежды, косметики и периодических больничных из-за сквозняков и стресса затея получалась планово убыточной. Чисто экономически ей было выгоднее ни куда не ездить, а сидеть дома.
Там масса оговорок. Например, если мама не работает, то отпуск и пособия папе не дадут. Выбор появляется если мама работает официально или вы одинокий отец.
Мне кажется, что в примере есть ещё и историческое несоответствие с заявленным:
В момент появления JavaScript, доступ к элементам был в силе "document.myForm.myInput", и это работало буквально лишь для нескольких типов (form, img и может ещё пары каких-то).
document.getElementById(), ровно как и весь DOM, это более позднее изобретение.
Код на слайде выглядит как лет на 10 позже. Т.е. JavaScript к тому времени не только родился, но уже и в школу пошёл.)
Статическая типизация - это проверка типов на этапе компиляции. Ровно то, что реализовано в TS.
Проверка типов в рантайме это строгая типизация. Она несёт за собой дополнительные накладные расходы и тут всегда возникает tradeoff между строгостью и performance. Проверяйте входные данные, а в остальном можно жить и без этого.
У меня есть пара плат с Espurino. Это JavaScript для микроконтроллеров. Там где не важны задержки и плевать на энергоэффективность (а это львиная доля всей домашней автоматизации), писать логику на JS одно условие.
С точки зрения математики, сложение и конкатенация это разные вещи. Сложение коммутативно, а конкатенация - нет.
Использование в языке одного и того же символола для обозначения разных по сути операций это однозначно фейл.
Для тех, кто у вас спрашивает оценки, а потом назначат их же вам как дедлайны - наверняка в аду приготовлен отдельный котёл.
Вообще задачи условно делятся на две категории. 1. Которые понятно как делать. 2. Которые - не понятно.
Задачи первого рода есть всегда и вы можете дать для них оценку с большой долей достоверности. Так сделайте это.
Если столкнулись с задачей второго рода, то положите в спринт спайк с задачей на исследование, и целью - родить план для дальнейших действий, которые уже сможете оценить. Установите на нее психологически и финансово комфортный лимит по времени сверху. Все у вас снова есть вполне правдоподобная оценка.
В итоге все задуманное либо будет оценено и выполнено. Либо вы от чего-то откажетесь, если сочтёте нерешаемым. Но у вас для этого уже будут все основания.
Между двадцатью и ста есть разница.
Ради интереса, попробуйте оценить: сколько времени у вас займет собрать пазл из соответствующего количества плиток? Здесь ведь даже учить ничего не надо - просто собрать. А потом реально собрать и порефлексировать над результатами.
Чтобы ещё больше приблизить игру к реальности, попробуйте предварительно смешать плитки из нескольких однотипных наборов. Просто в конце покажете несколько картинок, сложенных рядом.
Половину из них раздайте детям - с условием, чтобы они все вернули ровно через час. Оставшейся половины вам ведь точно должно хватить, чтобы не сидеть без дела всё это время?
Да, кто-то из детей потом может опоздать. Кто-то в процессе потеряетет какие-то детали, но чтобы не огорчать отца, заменит на примерно похожие. Поэтому разницы сразу вы не заметите. Но в конце результат у вас все равно должен быть как на макете.
Теперь снова прикиньте оценку. А может вам хватит простого коэффициента?)
Я называю это наркомания - стремление получить удовлетворение как можно быстрее. На это подсаживаешься, это вызывает привыкание, отсутствие быстрых результатов приводит к ломке и даже - выгоранию. В таком состоянии люди готовы буквально на всё, чтобы получить очередную дозу своего удовольствия сию секунду, даже на преступление.
Когда менеджеры требуют оценку немедленно, программисты коммитят код без тестов, чтобы закрыть задачу, а тестировщики красят в зелёный неглядя - вот это оно.