Лень и чревоугодие
Про то, как в Avito работает performance review, я очень много раз рассказывал внутри компании, а этой весной ещё и на двух конференциях — TeamLeadConf и CodeFest. Мы активно вкладываемся в доработку процесса, проводим много экспериментов и собираем кучу полезных данных, поэтому каждое новое выступление стабильно включает в себя какой-то новый контент. Цель этой статьи — не выдать вам готовое коробочное решение, а поделиться всеми практиками и инсайтами, которые мы обнаружили на своем пути.
Уже две недели Рунет шумит про Telegram и ситуацию с его бессмысленной и беспощадной блокировкой Роскомнадзором. Рикошетом задело многих, но всё это — темы для постов на Geektimes. Меня же удивило другое — я до сих пор не видел на Хабре ни одного разбора запланированной к выходу на базе Telegram сети TON — Telegram Open Network. Мне захотелось восполнить этот недостаток, ибо поизучать там есть что — даже несмотря на отсутствие официальных заявлений о нём.
Напомню — ходят слухи о том, что Telegram запустил очень масштабное закрытое ICO, уже собрав в нём невероятные суммы. Предполагается, что уже в этом году будет запущена собственная криптовалюта Gram — и у каждого пользователя Телеграма автоматически появится кошелёк, что само по себе создает немалое преимущество перед остальными криптовалютами.
К сожалению, так как официальных заявлений нет, дальше я могу отталкиваться только от документа неизвестного происхождения, о чём я сразу вас предупреждаю. Конечно, он может оказаться очень искусной подделкой, но не исключено и то, что это — реальный whitepaper будущей системы, написанный Николаем Дуровым (и слитый, вероятно, кем-то из инвесторов). Но даже если это фейк, никто нам не запретит его поизучать и обсудить, верно?
Что же говорится в этом документе? Я попробую пересказать его своими словами, близко к тексту, но по-русски и чуть более человечно (да простит меня Николай со своей склонностью уходить в формальную математику). Имейте в виду, что даже в случае его подлинности, это черновое описание системы и оно, весьма вероятно, изменится к моменту публичного запуска.
yum update и apt-get upgrade.
Еще 4 года назад использование контейнеров в production было экзотикой, но сейчас это уже норма как для маленьких компаний, так и для больших корпораций. Давайте попробуем посмотреть на всю эту историю с devops/контейнерами/микросервисами ретроспективно, взглянуть еще раз свежим взглядом на то, какие задачи мы изначально пытались решить, какие решения у нас есть сейчас и чего не хватает для полного счастья?
Я буду в большей степени рассуждать про production окружение, так как основную массу нерешенных проблем я вижу именно там.
Этот список появился как личная памятка по темам, которые я обсуждал с коллегами и друзьями и в которых хотел разобраться поглубже…
Пожалуй, непопулярное мнение (и тут немного иронии от меня).Такая позиция близка и мила моему сердцу, хотя я тоже понимаю иронию. Одна из вещей, которые я говорю потенциальным работодателям с тех пор как меня уволили за отказ оставаться программировать после работы — это то, что я не согласен на овертайм. По крайней мере, не на регулярной основе. Я могу иногда поучаствовать в авралах, когда критически важно срочно накатить конкретное изменение или исправить баг, но за исключением таких случаев я буду появляться, вкалывать — и пойду домой.
Чтобы быть способным и отличным инженером, вам не нужно писать статьи в блоге, участвовать в проектах open source, выступать с техническими лекциями или делать что-нибудь ещё.
Можете оставить свой код в офисе — и это вполне нормально.
functools (это такая свалка для всяких ненужных мне вещей :-).
— Гвидо ван Россум
Может показаться, что статья о ФП, но я не собираюсь обсуждать парадигму. Речь пойдет о переиспользовании и упрощении кода — я попытаюсь доказать, что вы пишете слишком много кода, поэтому он сложный и тяжело тестируется, но самое главное: его долго читать и менять.
В статье заимствуются примеры и/или концепции из библиотеки funcy. Во-первых, она клевая, во-вторых, вы сразу же сможете начать ее использовать. И да, нам понадобится ФП.
Да, являются.
Список объектов гражданских прав указан в ст. 128 ГК РФ:
“К объектам гражданских прав относятся вещи, включая наличные деньги и документарные ценные бумаги, иное имущество, в том числе безналичные денежные средства, бездокументарные ценные бумаги, имущественные права; результаты работ и оказание услуг; охраняемые результаты интеллектуальной деятельности и приравненные к ним средства индивидуализации (интеллектуальная собственность); нематериальные блага”
Как видно из текста закона, этот список не исключительный, и туда входят любые имущественные права, результаты работ и оказание услуг, и даже нематериальные блага (пример: "вы мне споете, а я вам станцую" — это обмен нематериальными благами)
Часто встречаемые высказывания о том, что де "нет определения криптовалюты в законодательстве РФ и поэтому операции с ними незаконны" — неграмотны.
Последние годы стала очень популярна тема микросервисов. Я не попадал на проекты с микросервисами, поэтому мне, естественно, захотелось ближе познакомиться с такой концепцией архитектуры.
Ранее у меня был домашний проект (хотя скорее даже его прототип), который было решено переписать на микросервисы. Проект представлял собой попытку сделать обучающую Java игру. То есть у игрока есть поле, на этом поле он может управлять каким-то юнитом с помощью кода. Пишет код, отправляет на сервер, там он выполняется и возвращает результат, который отображается пользователю.
Всё это было реализовано в виде прототипа — были пользователи, один урок и одна задача для него, возможность отправить код, который компилировался и исполнялся. Кое-какой фронтенд, но в статье о нём речи не будет. Технологии — Spring Boot, Spring Data, Gradle.
В статье будет реализован такой же прототип, но уже на микросервисах. Реализация будет наиболее простым путём (точнее наиболее простым, из известных мне). Реализация будет доступна любому, кто знаком со Spring.
Как JVM создает новые объекты? Что именно происходит, когда вы пишете new Object()?
На конференциях периодически рассказывают, что для аллокации объектов используются TLAB'ы (thread-local allocation buffer): области памяти, выделенные эксклюзивно каждому потоку, создание объектов в которых очень быстрое за счет отсутствия синхронизации.
Но как правильно подобрать размер TLAB'а? Что делать, если нужно выделить 10% от размера TLAB'а, а свободно только 9%? Может ли объект быть аллоцирован вне TLAB'а? Когда (если) обнуляется выделенная память?
Задавшись этими вопросами и не найдя всех ответов, я решил написать статью, чтобы исправить ситуацию.
Перед прочтением полезно вспомнить как работает какой-нибудь сборщик мусора (например, прочитав этот цикл статей).