Давным-давно, во времена студенчества в колледже я немного занимался разработкой компьютерных видеоигр. Это была эпоха 8-битных PC, когда игровое оборудование по современным стандартам было почти невозможно медленным.

Поэтому вас не должно удивлять, что программисты игр придумывали всевозможные безумные трюки, чтобы их игры работали с приемлемой скоростью. Безумные, безумные трюки.

Это история об одном из таких трюков.

Я постараюсь припомнить все важные подробности, однако в чём-то могу ошибиться. Если так случится, простите меня, это было очень давно.

Исходные данные

Мой друг, одарённый программист, почти закончил свою новую игру. Каким-то образом ему удалось почти без изменений уместить в компьютер эпохи 1980-х довольно впечатляющую графически на то время игру, популярную на аркадных автоматах.

Единственная проблема заключалась в том, что его версия игры оказалась неиграбельной. Она работала слишком медленно, а дёрганые движения мешали вовлечённости игрока, ведь игра была сайд-скроллером.

Мой друг, работавший над игрой параллельно с учёбой в колледже, начал уже ощущать себя немного вымотанным. Опасаясь, что мог упустить какую-нибудь простую оптимизацию, он попросил посмотреть код меня.

Я посмотрел. Но там нельзя было найти никакой простой оптимизации.

Пять лет назад я сидел в чужой квартире, в чужом городе, без работы и с последними копейками на счету. За два месяца до этого я ушел из большой корпорации. Мне казалось, я был слишком хорош для того, что в ней делал. Хотел заниматься чем-нибудь полезным, возвышенным и меняющим-мир-к-лучшему — а не увядать и жиреть в корпоративной столовке. 

На прощание мне говорили, что я полный идиот, потому что нигде не найду таких же денег в своей профессии, что даже в лучших местах мне будут платить в три раза меньше, а драть в пять раз больше. Я подумал — пускай, я слишком молод, чтобы расслабляться, до тридцатника не помешает хлебнуть профилактического говнеца.

Но пары месяцев с голой задницей оказалось достаточно, чтобы сломаться. 

Если вы узнали стиль заголовка и вам больше не нужны никакие подробности — вот ссылка на репозиторий.

Если вы недоумеваете что это такое и почему я отнимаю место в ленте у хороших авторов — тогда немного контекста будет под катом.

Алоха! Меня зовут Даша, я тестирую мобильные приложения. Скоро Хэллоуин, а FunCorp традиционно обновляет к некоторым праздникам иконку и сплеш. Сейчас именно такой случай, потому что большинство наших пользователей находятся в США. Задача показалась тривиальной, я быстро составила базовый чек-лист на 8 пунктов, но в процессе нашла ещё несколько кейсов, и он вырос до 13-ти (прилагается).

Здесь нет rocket science, я лишь расскажу, на что стоит обращать внимание в таких тасках, чтобы не пропустить лишних багов в прод — и на Android, и на iOS.

В схеме любой базы данных, наверняка, будет множество текстовых полей. Я, для целей этой статьи, разделил текстовые поля на три категории:

1. Маленькие тексты. Имена и фамилии людей, заголовки страниц, имена пользователей, адреса электронной почты и прочее подобное. Обычно на размер таких полей накладываются определённые ограничения, довольно сильные. Возможно, это даже не поля типа text, а поля типа varchar(n).
2. Большие тексты. Это, например, содержимое публикаций в блогах, тексты статей, HTML-код. Такие данные представляют собой большие фрагменты текста неограниченной длины, хранящиеся в базе данных.
3. Тексты среднего размера. Это — описания, комментарии, отзывы о товарах, данные о трассировке стека и так далее. В сущности это — любые текстовые поля, размер которых находится между размерами «маленьких» и «больших» текстов. Обычно размер таких полей не ограничен, но их содержимое, по естественным причинам, меньше, чем содержимое полей категории «большие тексты».

В этом материале я хочу рассказать о неожиданном влиянии текстов среднего размера на производительность запросов в PostgreSQL. В частности, мы поговорим о TOAST (The Oversized-Attribute Storage Technique, Техника хранения больших атрибутов) 

Привет! Меня зовут Ксения Якиль. Я пишу core-сервисы на C и Go в бэкенд-отделе Badoo и Bumble. Наш бэкенд — это высоконагруженная распределённая система, обслуживающая пользователей по всему миру. Она оперирует большими массивами данных и делает всю ту магию, благодаря которой люди находят друг друга. 

В этой статье я не буду концентрироваться на специфике наших сервисов, а расскажу, как мы реализовали автоматизированные интеграционные тесты в распределённой системе, поделюсь общими принципами и нюансами создания фреймворка для них. В тексте будут встречаться отсылки к реализации на Go, так как мы использовали именно этот язык, но понять основную мысль это не помешает.

Есть у меня хороший друг. И есть у него одно очень замечательное свойство - он владелец русского стриптиз клуба на walking street ( кто не в теме это такая улица разврата и порока в Паттайе ) :-). 

Если взять все собеседования, которые когда либо проходили у людей, и расставить их в порядке от лучшего к худшему — то на самой последней строчке окажется мое. Это было давно. Я уже умел разрабатывать, но совершенно не разбирался в собесах — и, слепой от желания получить оффер, пропустил все тревожные звоночки.

На первом же созвоне прошло сложное техническое интервью — что нормально — но только в самом конце его объявили «первым этапом, скринингом». Второй этап вел эйчар, третий — настоящие посланники ада. Два человека наперебой заваливали техническими вопросами про дотнет, не давали ни подумать, ни ответить и переходили к следующему.

Я справился странно. Именно странно. На несколько вопросов, которые дотнетчик не может не знать я ответил неправильно, на несколько таких, которые знает далеко не каждый, я ответил хорошо. Вот так бывает, я не сказал, что такое финалайзер, потому что начинал учиться с плюсов, и запомнил его как деструктор. Зато рассказал про поколения в сборщике мусора.

Они похоже оценивали просто количество ответов, иначе как тогда они могли апрувнуть человека, который не знает про финалайзер — это необходимое знание даже для стажера в .net.

Я был ослеплен «успехом» и согласился на финальный этап — лайвкодинг. И вот там мне и пришлось переосмыслить значение слова «жопа».

На осенней презентации AMD представила новое поколение видеокарт семейства Radeon RX 6000 серии, построенных на архитектуре RDNA 2. Та же архитектура используется и в консолях следующего поколения Xbox Series X и S и PlayStation 5.

На презентации сотрудники компании сравнили производительность Radeon RX 6800 XT с недавно представленным конкурирующим решением NVIDIA, GeForce RTX 3080. Исходя из этого сравнения, производительность видеокарт AMD оказывается той же или даже немного лучше по показателю частоты кадров при меньшем энергопотреблении.

Подробнее обо всех основных преимуществах новой архитектуры — читайте ниже.

Joomla — третья по популярности (после Wordpress и Shopify) система управления контентом, написанная на языке PHP и использующая в качестве хранилища данных реляционные базы данных.

Как и многие другие CMS, Joomla полностью бесплатна для использования и имеет открытый код. Система шаблонов легко позволяет менять внешний вид сайта, а огромный каталог расширений, позволяет так же легко дополнять функциональность сайта нужными модулями.

Не счесть холиваров о том, стоит ли быть фуллстек-разработчиком. И в них часто вылезает ещё один спорный вопрос: а что это понятие означает-то? «Фронтбэкендер»? «Многорукий Шива, мастер всего от инфраструктуры до тестирования»? «Человек, освоивший столько технологий, что воспарил над ними в мир общих концепций»?

Я захотел разобраться, как это понятие появилось и что люди в него вкладывали изначально. Было ли какое-то «каноническое» определение? Пока разбирался, увидел прямо-таки эволюцию представлений о нём и решил изложить её для Хабра.

Когда понятие возникло? Как можно увидеть по графику Google Trends, в широкий обиход оно вошло с 2014-го. А на Хабре первое упоминание произошло в 2013-м. Это был перевод англоязычного блог-поста, где упоминается, что Facebook «нанимает только Full Stack». То есть в Фейсбуке это уже тогда было устоявшимся понятием? Я стал гуглить дальше и в техническом блоге Facebook нашёл пост 2010 года «The Full Stack, Part I» с тысячей лайков. А он, в свою очередь, ссылается на пост разработчика Рэнди Шмидта 2008 года. И, судя по прочей найденной мной информации, вот у Шмидта и было первое использование понятия, из которого выросло всё остальное. Теперь, когда мы дошли до начала начал, давайте пойдём по этим же постам в обратном направлении (по хронологии) и посмотрим, что в них говорилось.

На конференции North Bay Python в 2018 году я делал доклад об именах пользователей. Информация из доклада по большей части была собрана мною за 12 лет поддержки django-registration. Этот опыт дал мне гораздо больше знаний, чем я планировал получить, о том, насколько сложными могут быть «простые» вещи.

В начале доклада я, правда, упомянул, что это не будет очередное разоблачение из серии «заблуждения по поводу Х, в которые верят программисты». Таких разоблачений можно найти сколько угодно. Однако мне подобные статьи не нравятся. В них перечисляются разные вещи, якобы являющиеся ложными, однако очень редко объясняется – почему это так, и что нужно делать вместо этого. Подозреваю, что люди просто прочтут такие статьи, поздравят себя с этим достижением, и потом пойдут находить новые интересные способы делать ошибки, не упомянутые в этих статьях. Всё потому, что они на самом деле не поняли проблем, порождающих этих ошибки.

Последние 6 лет я работаю экспертом по информационной безопасности в Одноклассниках и отвечаю за безопасность приложений.

Мой доклад сегодня — о механизмах межпроцессного взаимодействия в Android и уязвимостях, связанных с их неверным использованием.

Но сначала пара слов о том, как появился этот доклад.

Наверное, вы уже заметили, что на каждом Heisenbug есть как минимум один доклад про безопасность, например про XSS или поиск уязвимостей в веб-приложениях. Тема мобильной безопасности осталась не охвачена, хотя мы живем в 2020 году, и аудитория мобильных приложений уже давно превысила аудиторию веба. Мне хотелось выбрать тему из мира мобильной безопасности — достаточно конкретную, чтобы выдержать формат технического доклада, но при этом достаточно распространенную.

Кто и как пережил весну 2020-го, обсуждать можно бесконечно. Меня, например, карантин застал почти сразу после переезда в другой город, и на несколько месяцев запер в однушке с котом. Думаю, мы оба многое переосмыслили.

Аtención: Мнение, описанное в статье, — субъективно, это личный взгляд на вещи. У каждого человека разные способности к изучению языков, как и к любой другой деятельности.

До переезда в Испанию у меня был скудный опыт в изучении иностранных языков. Относительного успеха я добилась только в изучении английского делового языка в университете. И даже его благополучно забыла в течение пары лет за ненадобностью. В 29 лет судьба закинула меня в Испанию, где я начала изучить совершенно новый для меня язык.

Все, что я читала в интернете на форумах живущих в Испании за полгода до переезда:

• Испанский очень легкий язык.
• За три месяца можно научиться бегло говорить, даже не обучаясь языку специально.
• Испанцы с удовольствием тебе будут помогать, когда увидят, что ты стараешься выучить их язык.
• Простая грамматика и тому подобное.

Как оказалось, многие утверждения вовсе не соответствуют реальному положению вещей. Подробнее обо всем этом — под катом.

Некоторые производители гаджетов пытаются уйти от концепта сенсорного смартфона без физической клавиатуры, которые очень похожи друг на друга. До недавнего времени наиболее известным производителем устройств с физической клавиатурой была компания RIM, производитель смартфонов линейки Blackberry.

Есть и другие компании, менее известные. Одна из них — F(x)tec. Сейчас она представила устройство F(x)tec Pro1, которое, в целом, сложно назвать телефоном. Скорее, это один из последних представителей форм-фактора UMPC. Хотя, возможно, этот телефон станет популярным и на него обратят внимание другие производители. Пока же оценим, что там внутри и снаружи.

Tarantool — это персистентная NoSQL СУБД в памяти с хранимыми процедурами на Lua. В него встроен SQLite и дисковый движок (Vinyl). Также для Tarantool написано очень много расширений, поэтому многие считают его «сервером приложений». Здесь есть индексы разных типов, а в одном спейсе кроме первичного индекса может быть множество вторичных. Также в Tarantool есть один transaction thread, который выполняет все транзакции в памяти, есть сетевой thread и WAL thread.

Как же устроена работа с памятью в этой СУБД?

Давненько хотел сравнить аппараты на разной технологии.

Вкратце: в ассортименте Epson какое-то время назад появились первые лазерные проекторы для дома. Инсталляционные аппараты в каталоге уже не первый год, а вот первый компактный лазерный проектор Epson EF-100B/W появился только в 2019-м году, о чем я рассказывал в блоге ранее. Однако выяснилось, что планов отказываться от производства ламповых моделей у Epson нет. И вот тут мне стало интересно: раз появилась лазерная модель, то, вероятно, дни ламповых проекторов сочтены, так?

А вот и нет! Инженеры Epson считают иначе.

Поэтому я решил провести собственное сравнение проекторов на разных технологиях и разобраться, правы ли инженеры или это я самый умный и проницательный.

Для этого взял два аппарата: лазерный Epson EF-100W (бывает и в черном цвете) и ламповый Epson EH-TW5400.

Лазерный EF-100W (слева) и «ламповый» EH-TW5400 (справа)

В сравнении буду смотреть в первую очередь не на параметры конкретных моделей, а постараюсь экстраполировать характеристики и возможности с учетом их форм-фактора, типа источника света и возможных сценариев использования, в целом. Иначе говоря…

Лазер против лампы. Поехали.

Автор: Барт Хендрикс, понедельник, 26 октября 2020 г.

Пролог

Под перечислимым типом обычно понимают тип данных, который может принимать ограниченное и, как правило, небольшое число значений. Его выделяет то, что эти значения часто хардкодятся программистами в исходный код. И, как следствие, пользователи и операторы приложения не могут менять множество значений перечислимого типа. Их меняют только разработчики, зачастую с соответствующими исправлениями в коде и бизнес-логике приложения. Примерами перечислимых типов могут быть: времена года, месяцы, направление типа въезда/выезд или in/out, какие-нибудь типы или категории чего-нибудь, и так далее. В PostgreSQL подобную функциональность могут и реализуют различными способами. Этому посвящена статья.