Хм, интересно, зачем это им. Ну тогда любопытным читателям комментариев на будущее:
Таблицы налогового департамента кантона Цюрих. https://www.steueramt.zh.ch/internet/finanzdirektion/ksta/en/spezialsteuern/quellensteuer/arbeitnehmende_arbeitgebende/tarife.html (увы, только на немецком).
Плюс 6.225% на соц. страховку (AHV/IV/EO и от безработицы. Выплачивается пополам с работодателем, так что ещё столько же скрытой нагрузки на ФОТ, но брутто-зарплата указывается только с учётом вашей половины).
Плюс отчисления в индивидуальный накопительный пенсионный фонд (BVG, 2. Säule). Тут с конкретными цифрами сложно, потому что варьируется в зависимости от возраста и зависит от договора с работодателем. Минимум вроде 7%.
Итого у одинокого бездетного программиста без вероисповедания до 34 лет обязательных отчислений с зарплаты 10000 франков/месяц будет примерно 24%.
Больше 120K/год уже надо заполнять налоговую декларацию и налог начинает зависеть не только от кантона, но и муниципалитета (Gemeinde). Но в целом налоговая нагрузка в Швейцарии заметно ниже, чем у европейских соседей.
Вы зарплату в Швейцарии пересчитали в доллары по курсу евро. CHF/USD = 1.05, а не 1.23.
С 110K франков/год подоходный налог будет гораздо меньше 25%. Вот вам калькулятор наиболее актуального для иностранцев (ВНЖ типа L и B) tax at source: https://en.comparis.ch/steuern/quellensteuerrechner/default
Я тоже пережил период воинствующего технократизма и пренебрежения к гуманитарному знанию. Если попытаться свести личный опыт в одно предложение, главное — это уход от восприятия других людей исключительно как досадной помехи (учёбе, проекту, идеальному общественному строю) или полезного инструмента. Объективации, одним словом. Когда понимаешь, что людей нельзя ни поменять как хочется, ни игнорировать, сколько-нибудь серьёзная дискуссия по гуманитарным вопросам становится невозможной без знания философии и истории, потому что все лежащие на поверхности мысли передуманы, пережёваны, а порой и испробованы сотни лет назад. Даже оставая строго в рамках профессии, понимаешь, что peopleware — это не хрень, которую придумали менеджеры, чтобы казаться полезными. Что даже без формальной управленческой позиции уметь договариваться и вести за собой — это единственный способ создать что-то стоящее.
Эти перемены сложно заметить и в себе, и в людях, с которыми постоянно общаешься, потому что процесс занимает годы. Но сравнивая себя и свой круг общения сегодня и 8-10 лет назад, корреляция с возрастом очевидна. В моём случае особенно повлияли семья (развивается эмпатия) и работа в большой компании с людьми много умнее себя (закручивает эго в правильную сторону).
P.S. Это скорее не к конкретному комментарию, а ко всем вашим постам по веткам. Местами кажется, что в зеркало смотрюсь.
Либо пробежаться по коду как минимум с парой коллег, предварительно загрузив их чтением манов Ragel (а у них свои задачи, между прочим). Либо не выпендриваться и написать на примитивных строковых операциях, благо протокол не столь сложный. Да, дольше писать, больше кода, медленнее работает. Но инструмент нельзя рассматривать в отрыве от контекста, и этот контекст помимо собственно задачи включает команду, компанию и т.д.
Потому что на работе, где это можно узнавать, это уже все узнали и используют, а ваш поезд ушёл.
В реальности между НИИ Г*на и Торфа и DeepMind непрерывный многомерный спектр.
Я же не спорю, что учиться полезно. Пока есть возможность и в кайф кодить всё свободное время — на здоровье. Но в 30+ лет и/или с семьёй невозможно соревноваться со вчерашними студентам в скорости изучения фреймворков. Надо брать чем-то другим.
Думаю, у нас с вами нет принципиальных расхождений, только в количественных оценках. Тезисно (ибо краду у своих 8 часов):
Владеть широким набором абстракций и уметь издалека распознавать их применимость очень важно. Изучение ЯП принципиально разных парадигм — отличный способ пополнить свой набор инструментов. Но не единственный.
3 хаскель-месяца vs 9*N плюсо-месяцев возможно только в идеальной команде Белоснежка и Семь Гномов хаскелист и семь плюсовиков. Иначе добавляется независимый от языка организационный оверхед, который нивелирует разницу. Это не значит, что от языка ничего не зависит, просто он редко является bottleneck. Правильным языком и хорошей организацией можно добиться больше, чем просто хорошей организацией, но никакой язык или фреймворк не спасёт от последствий плохой организации.
intrinsic complexity во многом обусловлена столкновением абстракций с несовершенным миром. Умение это предвидеть, обойти, и смягчить последствия — переносимо между стеками и не требует bleeding edge технологий для прокачки. У нас в должностных обязанностях инженеров выше определённого уровня прописано «уменьшать хаос вокруг себя». Вот это оно, лучше не скажу.
Парсеры. Обожаю парсеры. Моя любимая лакмусовая бумажка технической компетентности, потому что зачастую люди не могут распознать КС-грамматику и лепят регулярки, задолго до того как встаёт вопрос о комбинаторных парсерах. Тем не менее, мне до сих пор слегка стыдно за то что в одной конторе я оставил после себя парсер протокола на Ragel — быстрый и декларативный, не чета предыдущему убожеству на регулярках — тем самым добавив им головняка при поддержке.
(Не вам лично) «Зачем вы занимаетесь нелюбимым делом [на которое не тянет после 17:00]» можно развернуть в обратную сторону: «Зачем вы работаете там, где с 9 до 17 нельзя узнать ничего нового и полезного».
«Условный C++17» зачастую слабо влияет на эффективность решения задач. Конечно, нельзя уйти в анабиоз на 10 лет и остаться востребованным специалистом. Но саморазвитие не ограничивается новыми версиями языков и фреймворков. С опытом работы приходит понимание, что «можно» далеко не всегда означает «нужно». Человек, который умеет писать простой надёжный код для больших систем на условном «Си с классами», без труда найдёт себе применение. Есть много компаний и интересных задач, где важно знание C++17. Есть не меньше компаний и задач, в которых главное — управление сложностью, чтобы сотни человеко-лет работы не сложились под собственным весом. Как бывший плюсо-задрот и большой любитель Х-ля, я скрепя сердце вынужден признать, что роль языков и фреймворков в этом много меньше, чем мне казалось ранее.
Прочитал, порадовался, что люди независимо сделали свой маленький Borg, респект им. Манифесты, назначение ресурсов на задачи, раздельное управление классом изоляции и приоритетом размещения (appclass и priority соответственно в терминологии Borg), FQDN-like имена. Даже из lessons learned два пункта присутствуют: глубокая иерархия задач и IP на контейнер. Только Service Discovery нет, что отдельно проговаривается. Но у простых пользователей cluster management вопросы к проприетарному решению могут быть только из праздного любопытства, а архитекторы… не знаю, может на HighLoad своё любопытство удовлетворили? :-)
В гугловском стеке надо очень постараться, чтобы сохранить данные без репликации. Безвозвратная потеря данных в любом объёме — это ЧП для SRE. Если бы каждый выбывший диск уносил с собой пользовательские данные, этими продуктами никто бы не пользовался.
По приведённым ссылкам в одном случае снимки из кармана, в другом — протухшие URL. Насчёт двух других не знаю, но если у вас есть свежие примеры такого поведения и вы готовы поделиться ссылкой на битое, напишите пожалуйста в личку — я подниму внутренний баг.
Это не катастрофа, это реальность в любом большом (сотни человеко-лет) проекте. Конечно, критерии вхождения в проект можно задать разные: какой-то полезный код обычно можно начать писать очень быстро. Но для выхода на сравнимую со старожилами продуктивность нужны месяцы. По собственному опыту, чтобы перестать упираться в необходимость глубокого поиска на каждом шаге, мне в YouTube как раз около полугода понадобилось. Google — это экстремальный пример, потому что очень большой и очень проприетарный, но всё же едва ли единственный в своём роде. Посмотрите на это с такой стороны: в проекте может быть больше внутренних API, чем, скажем, в стандартной библиотека Python и вашем любимом веб-фреймворке вместе взятых. Сколько, по-вашему, нужно времени, чтобы начать эффективно писать на условном Django? Да, опыт рулит, решения повторяются, основы те же. Но все равно очень много информации надо через себя пропустить, чтобы полноценно работать.
Детальная 3D-карта собирается машинами Street View с лидарами (http://static.googleusercontent.com/media/research.google.com/ru//pubs/archive/36899.pdf), этих данных много больше, чем вручную созданных моделей. Найдите в Maps город с более-менее свежим покрытием Street View и перейдите в 3D-режим, хорошо видно каждое дерево.
Понятно, что у облачного файлового хранилища отношение watch qps / corpus size гораздо меньше, чем у специализированного видео-хостинга, но неужели CPU настолько дешевле хранилища, что вы даже уже перекодированные куски видео удаляете?
Ряд сервисов (например, YouTube, социальные сети и прочие) конвертирует пользовательское видео в пригодные для воспроизведения форматы сразу после загрузки. Только после окончания конвертации ролик становится доступным для просмотра, но оригинал при этом удаляется.
Выделенное неверно. Оригинал доступен для скачивания через google.com/takeout
Тред на crypto.se со множеством ссылок на криптографические методы: crypto.stackexchange.com/questions/606/time-capsule-cryptography
В частности, Ривест, Шамир и Вагнер в 1996 предложили (Time-lock puzzles and timed-release Crypto) схему, в которой время расшифровки >> времени шифрования и вычислительные затраты довольно точно регулируются.
Пробежался по текстам. Во втором правильно отмечено, что весь сыр-бор вокруг вопроса, считать ли человека абсолютной ценностью. Хочется уточнить: «текущий эволюционный миг, называемый человеком», но это уже отдаёт эмоциональной предвзятостью.
Писали мы конечно с tornado.gen и это отличная обёртка, но абстракция все равно течёт. Ладно, можно один раз проковырять исходники tornado и понять, как здесь реализовали кооперативную многозадачность на этот раз. Но больше всего напрягает, что синхронный и асинхронный код в Питоне — разные миры. Да, иногда можно забить на блокирующие операции сторонних библиотек. Можно вынести их в отдельный поток/процесс и общаться через очередь. Только после всего этого невольно возникает вопрос: а за тот ли молоток я вообще взялся?
Прошли похожую эволюцию от чистого Pyramid к Pyramid + Tornado + TornadIO2 + Redis как общая шина. Потом отказались от socket.io в пользу sockjs и sockjs-tornado. Не могу указать конкретно, в чём корень проблем socket.io, но со стабильностью соединения и задержками стало гораздо лучше. К тому же sockjs не настолько node-центричен, протокол проще и прозрачнее.
Ещё я в процессе понял, как ненавижу программирование на коллбэках (асинхронный сервер у нас содержит приличный объём логики), но переписывать этот кусок на Erlang пока не велит bus factor, хотя прототип был сваян и опробован.
Вот оно что… Я то всю жизнь TP под линуксом пользовался, где средняя кнопка работает два в одном без каких-либо лишних телодвижений. Сидел недоумевал всю ветку.
Хм, интересно, зачем это им. Ну тогда любопытным читателям комментариев на будущее:
Таблицы налогового департамента кантона Цюрих.
https://www.steueramt.zh.ch/internet/finanzdirektion/ksta/en/spezialsteuern/quellensteuer/arbeitnehmende_arbeitgebende/tarife.html (увы, только на немецком).
Плюс 6.225% на соц. страховку (AHV/IV/EO и от безработицы. Выплачивается пополам с работодателем, так что ещё столько же скрытой нагрузки на ФОТ, но брутто-зарплата указывается только с учётом вашей половины).
Плюс отчисления в индивидуальный накопительный пенсионный фонд (BVG, 2. Säule). Тут с конкретными цифрами сложно, потому что варьируется в зависимости от возраста и зависит от договора с работодателем. Минимум вроде 7%.
Итого у одинокого бездетного программиста без вероисповедания до 34 лет обязательных отчислений с зарплаты 10000 франков/месяц будет примерно 24%.
Больше 120K/год уже надо заполнять налоговую декларацию и налог начинает зависеть не только от кантона, но и муниципалитета (Gemeinde). Но в целом налоговая нагрузка в Швейцарии заметно ниже, чем у европейских соседей.
Вы зарплату в Швейцарии пересчитали в доллары по курсу евро. CHF/USD = 1.05, а не 1.23.
С 110K франков/год подоходный налог будет гораздо меньше 25%. Вот вам калькулятор наиболее актуального для иностранцев (ВНЖ типа L и B) tax at source: https://en.comparis.ch/steuern/quellensteuerrechner/default
Я тоже пережил период воинствующего технократизма и пренебрежения к гуманитарному знанию. Если попытаться свести личный опыт в одно предложение, главное — это уход от восприятия других людей исключительно как досадной помехи (учёбе, проекту, идеальному общественному строю) или полезного инструмента. Объективации, одним словом. Когда понимаешь, что людей нельзя ни поменять как хочется, ни игнорировать, сколько-нибудь серьёзная дискуссия по гуманитарным вопросам становится невозможной без знания философии и истории, потому что все лежащие на поверхности мысли передуманы, пережёваны, а порой и испробованы сотни лет назад. Даже оставая строго в рамках профессии, понимаешь, что peopleware — это не хрень, которую придумали менеджеры, чтобы казаться полезными. Что даже без формальной управленческой позиции уметь договариваться и вести за собой — это единственный способ создать что-то стоящее.
Эти перемены сложно заметить и в себе, и в людях, с которыми постоянно общаешься, потому что процесс занимает годы. Но сравнивая себя и свой круг общения сегодня и 8-10 лет назад, корреляция с возрастом очевидна. В моём случае особенно повлияли семья (развивается эмпатия) и работа в большой компании с людьми много умнее себя (закручивает эго в правильную сторону).
P.S. Это скорее не к конкретному комментарию, а ко всем вашим постам по веткам. Местами кажется, что в зеркало смотрюсь.
Либо пробежаться по коду как минимум с парой коллег, предварительно загрузив их чтением манов Ragel (а у них свои задачи, между прочим). Либо не выпендриваться и написать на примитивных строковых операциях, благо протокол не столь сложный. Да, дольше писать, больше кода, медленнее работает. Но инструмент нельзя рассматривать в отрыве от контекста, и этот контекст помимо собственно задачи включает команду, компанию и т.д.
В реальности между НИИ Г*на и Торфа и DeepMind непрерывный многомерный спектр.
Я же не спорю, что учиться полезно. Пока есть возможность и в кайф кодить всё свободное время — на здоровье. Но в 30+ лет и/или с семьёй невозможно соревноваться со вчерашними студентам в скорости изучения фреймворков. Надо брать чем-то другим.
Думаю, у нас с вами нет принципиальных расхождений, только в количественных оценках. Тезисно (ибо краду у своих 8 часов):
Белоснежка и Семь Гномовхаскелист и семь плюсовиков. Иначе добавляется независимый от языка организационный оверхед, который нивелирует разницу. Это не значит, что от языка ничего не зависит, просто он редко является bottleneck. Правильным языком и хорошей организацией можно добиться больше, чем просто хорошей организацией, но никакой язык или фреймворк не спасёт от последствий плохой организации.«Условный C++17» зачастую слабо влияет на эффективность решения задач. Конечно, нельзя уйти в анабиоз на 10 лет и остаться востребованным специалистом. Но саморазвитие не ограничивается новыми версиями языков и фреймворков. С опытом работы приходит понимание, что «можно» далеко не всегда означает «нужно». Человек, который умеет писать простой надёжный код для больших систем на условном «Си с классами», без труда найдёт себе применение. Есть много компаний и интересных задач, где важно знание C++17. Есть не меньше компаний и задач, в которых главное — управление сложностью, чтобы сотни человеко-лет работы не сложились под собственным весом. Как бывший плюсо-задрот и большой любитель Х-ля, я скрепя сердце вынужден признать, что роль языков и фреймворков в этом много меньше, чем мне казалось ранее.
Прочитал, порадовался, что люди независимо сделали свой маленький Borg, респект им. Манифесты, назначение ресурсов на задачи, раздельное управление классом изоляции и приоритетом размещения (appclass и priority соответственно в терминологии Borg), FQDN-like имена. Даже из lessons learned два пункта присутствуют: глубокая иерархия задач и IP на контейнер. Только Service Discovery нет, что отдельно проговаривается. Но у простых пользователей cluster management вопросы к проприетарному решению могут быть только из праздного любопытства, а архитекторы… не знаю, может на HighLoad своё любопытство удовлетворили? :-)
По приведённым ссылкам в одном случае снимки из кармана, в другом — протухшие URL. Насчёт двух других не знаю, но если у вас есть свежие примеры такого поведения и вы готовы поделиться ссылкой на битое, напишите пожалуйста в личку — я подниму внутренний баг.
Это не катастрофа, это реальность в любом большом (сотни человеко-лет) проекте. Конечно, критерии вхождения в проект можно задать разные: какой-то полезный код обычно можно начать писать очень быстро. Но для выхода на сравнимую со старожилами продуктивность нужны месяцы. По собственному опыту, чтобы перестать упираться в необходимость глубокого поиска на каждом шаге, мне в YouTube как раз около полугода понадобилось. Google — это экстремальный пример, потому что очень большой и очень проприетарный, но всё же едва ли единственный в своём роде. Посмотрите на это с такой стороны: в проекте может быть больше внутренних API, чем, скажем, в стандартной библиотека Python и вашем любимом веб-фреймворке вместе взятых. Сколько, по-вашему, нужно времени, чтобы начать эффективно писать на условном Django? Да, опыт рулит, решения повторяются, основы те же. Но все равно очень много информации надо через себя пропустить, чтобы полноценно работать.
Выделенное неверно. Оригинал доступен для скачивания через google.com/takeout
В частности, Ривест, Шамир и Вагнер в 1996 предложили (Time-lock puzzles and timed-release Crypto) схему, в которой время расшифровки >> времени шифрования и вычислительные затраты довольно точно регулируются.
Ещё я в процессе понял, как ненавижу программирование на коллбэках (асинхронный сервер у нас содержит приличный объём логики), но переписывать этот кусок на Erlang пока не велит bus factor, хотя прототип был сваян и опробован.