Пользователь
C#. Guid.NewGuid(). Linux. Windows. Randomness or Uniqueness. RNG and PRNG. Performance. Benchmarking.
Цель нашей сегодняшней сказки — развлечься как следует. Детективная история в поисках потерянного перфоманса с красивым финалом и эффектным результатом непосредственно связана с набором слов из предыдущего абзаца.
Адрес TCP/IP поддерживает только 65000 подключений, поэтому придётся назначить этому серверу примерно 30000 IP-адресов.
Существует 65535 номеров TCP-портов, значит ли это, что к TCP-серверу может подключиться не более 65535 клиентов? Можно решить, что это накладывает строгое ограничение на количество клиентов, которые может поддерживать один компьютер/приложение.
Если есть ограничение на количество портов, которые может иметь одна машина, а сокет можно привязать только к неиспользуемому номеру порта, как с этим справляются серверы, имеющие чрезвычайно большое количество запросов (больше, чем максимальное количество портов)? Эта проблема решается распределением системы, то есть кучей серверов на множестве машин?
Март 2022.
События последних недель разделили нашу жизнь на ДО и ПОСЛЕ, а наше общество – на тех, кто ZА и ПРОТИВ. Воздержавшихся, кажется, уже не осталось. Даже тех, кто в "танке". Или в бункере.
Поэтому для некоторых это статья будет занятным чтивом из серии статей советского журнала «Вокруг света», а для других памяткой и возможно инструкцией по применению. Основой для этой публикации послужили материалы для большой статьи о разных аспектах переезда и жизни в Германии (а конкретнее во Франкфурте), идея которой пришла мне года полтора назад. Материал для неё я начал собирать несколько месяцев назад. Однако с той скоростью, с которой развиваются события сейчас и то бедственное положение, в котором оказались некоторые мои коллеги, подтолкнуло меня к мысли опубликовать материалы в том виде, в котором они у меня имелись на данный момент, с минимальными доработками.
Для жаждующих знаний и прогресса собрали материал из урока Дениса Наумова, спикера курсов Ansible и Python для инженеров. Немного разберёмся с теорией и посмотрим как написать модуль для создания пользователей в базе данных.
Материал объёмный. Рекомендуем сразу открыть итоговый код файла clickhouse.py для удобной работы со статьей.
Ранее мы рассмотрели способы расчёта нарастающего (накопительного) итога в SQL. Самый распространённый вопрос - как посчитать тоже самое, но на данных с разрывами? После написания исходной статьи мне его задавали неоднократно – так что есть смысл написать об этом отдельно.
Для кого эта статья? Конечно, для людей, работающих в сфере ИТ. Для разработчиков, тестировщиков, менеджеров разного уровня, аналитиков и т.д.. Уверен, что и для общего развития всем другим людям, так или иначе, причастным к ИТ было бы все же интересно это прочитать. Просто для расширения своего кругозора, для понимания того как создаются Информационные системы
Что меня сподвигло написать эту статью? Определенный опыт взаимодействия с разного уровня руководителями. Рассмотрим такую ситуацию. У нас есть вакансия, звучит она как Архитектор. И, вроде бы, понимание есть, что должен делать этот человек, но по факту оказывается, ждут “эникейщика”.
Что еще? Думаю, что надо договорится о подаче материала. Что, если это будет реальная история из моей практики, на мой взгляд, максимально демонстрирует работу Программного архитектора, а также некоторые выводы, которые можно сделать из нее. Постараюсь ответить здесь на следующие вопросы: Кто такой программный архитектор, какими навыками и знаниями должен обладать этот человек? Годиться?
И последнее, думаю надо представится. Меня зовут Владимир Воловиков. Работаю в ИТ сфере я уже почти 20-ть лет. В должности Системного архитектора и Программного архитектора, в общей сложности, более пяти лет. Имею четыре международных сертификата. Текущее место моей работы Системный архитектор, Банк ВТБ.
Часто возникает проблема: одна из таблиц в базе данных сильно выросла и время выполнения запросов к этой таблице увеличилось. Одним из вариантов решения подобной проблемы в PostgreSQL является партицирование. В статье затронем не только техническую реализацию, но и опишем этапы подготовки к партицированию.
Представим, что у нас есть батон хлеба. Порежем его на части. Каждый отрезанный кусочек — часть целого батона, но не сам батон. То есть мы поделили целое на части — это и есть партицирование. Батон как целое соответствует таблице, а кусочки батона как части — партициям этой таблицы.
Как и любой другой инструмент, POSIX-сигналы имеют свои правила, как их использовать грамотно, надежно и безопасно. Они испокон веков описаны в самом стандарте POSIX, в стандартах языков программирования, в manpages, однако и по сей день я нередко встречаю связанные с этим грубые ошибки даже в коде опытных разработчиков, что в коммерческих проектах, что в открытых. Поэтому давайте поговорим о важном еще раз.
Я дико люблю ковыряться в чужом коде. Это одна из моих любимых специализаций. То есть я просто беру чужой код, анализирую его, читаю. Как я читал его раньше: я переводил код в русский язык. Описывал, что происходит по флоу кода, и пытался понять, что там происходит. Эти записи я в дальнейшем использовал как для написания статей в Confluence, так и для общего понимания происходящего.
С одной стороны, решение работающее. С другой, буквально через неделю-две я уже начинал сомневаться, достаточно точно ли я «перевел» с кода на русский язык? И тогда вспомнил про UML-диаграммы. И вместо того, чтобы записывать текст, стал визуализировать его и исписал неимоверное количество тетрадей.
Но в какой-то момент подумал, что хорошо бы перевести все это в электронный вид, чтобы какой-то инкремент оставался. Не фоткать же, например, для документации, свою тетрадь с каракулями. Так я нашел инструмент PlantUML — opensource-решение, которое использует графическую библиотеку graphviz, превращающее код в наглядные схемы.
Давайте вспомним, что такое Unified Modeling Language. Чаще всего в университете UML используется для описания диаграммы классов.
Всем привет! У меня снова статья про качество. Только на этот раз речь пойдет не про код, а про подготовку к публичному выступлению.
Кадр из фильма «Индиана Джонс: В поисках утраченного ковчега» (1981)
Наблюдаемая все чаще и чаще картина в задаче анализа данных вызывает удручающее впечатление. Intel, AMD и другие производители непрерывно наращивают вычислительную мощность. Гениальные математики-программисты пишут суперэффективные библиотеки и алгоритмы. И вся эта мощь гасится и распыляется рядовыми аналитиками и разработчиками. Причем начинается это все с нулевого этапа — этап подготовки и загрузки данных для анализа. Многочисленные вопросы и диалоги показывают, что в нынешних программах обучения зияют огромные дыры. Людям просто незнакомы многие концепции и инструменты, уже давно придуманные для этих задач. Для тех, кто хочет увеличить свою продуктивность, далее тезисно будут рассмотрены ряд таких подходов и инструментов в частичной привязке к реальным задачам.
В первую очередь, материал ориентирован на аналитиков, которые манипулируют разумными объемами данных, необходимых для решения практических задач. ETL из Бигдаты в котором перекачиваются сотни Тб ежесуточно живет своей отдельной жизнью.
Является продолжением серии предыдущих публикаций.
Питон — простой, но мощный язык, который заслуженно стал одним из самых популярных. Тем не менее, иногда ему не хватает скорости статически типизированных языков с предварительной компиляцией, таких как Cи и Джава.
Если у вас есть задача выполнить трудоемкие вычисления, если нужно оптимизировать «подтормаживающее» приложение на Питоне без переписывания его на другом языке или если вы просто обожаете оптимизацию и хотите, чтобы код работал как можно быстрее, — тогда с большой вероятностью вы полюбите расширения на Си.
Расширения на Си — отличное дополнение в арсенале разработчика, будь вы фанат производительности и эффективности или любитель смешивать различные технологии и экспериментировать с чем-то новым: вы не только получаете почти «бесплатный» скачок производительности, но и расширяете функциональные возможности Питона.
В российских компаниях классический путь программиста заканчивается на должности тимлида или tech lead. Дальше — всё больше менеджера, всё меньше инженера. Хочешь расти в компании — берись за управление людьми, нравится тебе это или нет.
Но что, если есть другой путь? Опыт западных компаний показывает, что можно дать программисту остаться в разработке, а в менеджеры брать тех, у кого есть желание. И это не пойдёт компании в убыток. Наоборот — разработчик сможет вносить больший вклад в работу компании и наработать уникальную экспертизу. А ещё не выгорит от бесконечных code review. В этой статье Иван Круглов расскажет, как разработчику расти, минуя менеджмент.
У нас в компании 8 мобильных приложений и почти столько же мобильных команд. Конкретно наша работает с приложением для покупателей. Когда нас было немного, по 6-10 человек в iOS, Android и QA–командах, мы отлично справлялись с задачами. С ростом столкнулись с проблемой: чем больше у тимлида людей в подчинении, тем меньше он может уделить времени каждому, меньше времени имеет на погружение в задачи. В итоге качество управления команд начинало ухудшаться и с этим нужно было что-то делать
Решение мы нашли в распределении команд по стримам.
В этой статье расскажу как у нас организована работа для 30+ мобильных разработчиков и 14 QA: как мы планируем, делимся знаниями и что нам даёт этот подход.
Екатерина Вебер когда-то начинала в «Яндексе» и Росатоме, а сейчас работает Program manager в Google Youtube, в подразделении, занимающемся поиском абьюзивного контента. Она рассказала нам об особенностях жизни и работы в Северной Калифорнии. Почему это большая деревня, почему не стоит писать e-mail в 12 ночи, как жонглировать офферами и чем русские разработчики отличаются от других.
А еще — как найти работу в США, через какие стадии собеседований нужно пройти, на каких ресурсах искать помощь, чтобы получить хорошую зарплату. И почему работа в Google подойдет не всем.
Украинский профильный ресурс DOU.UA опубликовал статью о нелегком пути релокации специалиста в США во время пандемии, где он также отвечает на дополнительные вопросы и комментарии.
Адам Леос — Senior Software Engineer в Roku. Пару лет назад он принял решение о релокации и в итоге выбрал своей целью США. Всего за три месяца Адам с нуля собрал все необходимое для подачи на визу О1, но потом в историю вмешалась пандемия. О том, с какими трудностями он столкнулся из-за карантина, как искать работу на американском IT-рынке, как получить большое количество офферов и выторговать самую выгодную компенсацию, разработчик рассказал в интервью DOU.UA