* Не привлекая внимания санитаров

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

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

Что ж, вызов был брошен. И я поставил себе задачу (вы же тоже сами ставите себе задачи?) — нарисовать красивый красный квадратик размером 3 × 3 см. Тому, что у меня в итоге получилось, и посвящён мой необычный рассказ. 

Привет, меня зовут Аня, и я Android-разработчица в KTS. В этой статье разберем, какие обновления для обеспечения безопасности пользователей были представлены в докладе Safeguarding user security on Android на Google I/O, и как они отразятся на разработке.

Немного вводных по 2023 году:

– к публикации не допущено более 2 миллионов приложений, нарушающих правила;

– забанено примерно 330 тысяч плохих аккаунтов;

– каждый день сканировалось около 200 миллиардов приложений в поисках вредоносного ПО;

–  более 10 миллионов долларов выплачено в качестве награды за обнаружение ошибок в безопасности.

И это еще не все. Благодаря Google Play Protect обнаружено более 500 тысяч вредоносных приложений и вынесено более 3 миллионов предупреждений.

Google Play Protect может предложить просканировать приложения во время установки, если они не были проверены до этого. Это помогает Google намного быстрее отслеживать угрозы безопасности. 

Когда-то давным-давно (почти десять лет назад) мне пришлось писать довольно много статей для разных компаний, которые впервые выходили на Хабр. Среди них были совсем небольшие стартапы, IT-компании побольше, международные корпорации, и все они хотели одного: написать статью, которую все прочитают, запомнят и к которой читатели непременно вернутся. Практически утопия. Идея найти формулу идеальной статьи сродни попыткам отыскать философский камень: вроде все компоненты есть, рецептура есть, но всегда чего-то не хватает. И кажется, что на Хабре волшебную формулу ищут многие. Кто-то пишет статью с самым высоким рейтингом, кого-то добавляют в закладки сотни пользователей, кто-то — мастер вызывать аудиторию на обсуждение и собирает буквально бесконечные ветки комментариев. А если автор опытный, то он периодически миксует суперспособности своих публикаций.

В самом начале июля мы выкатили статистику публикаций для всех авторов Хабра: теперь каждый может не только оценивать рейтинг и просмотры, но и видеть, как именно его статью читают, в какой момент уходят и сколько пользователей решают покинуть страницу почти сразу. Это классная опорная статистика, которая позволяет понять, что нравится аудитории и исходя из этого скорректировать подачу контента. Июль закончился, статистика поднакопилась, мы решили попробовать собрать компоненты успешной статьи и разобраться, как же написать «ту самую» звёздную статью. А заодно посмотреть, что и как писали лучшие авторы месяца.

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

Я немного опоздал, соревнования проводились в январе. И на Java. Меня не особо интересует Java, зато давно интересует оптимизация кода на Go.

Этот челлендж был очень прост: обработать текстовый файл названий метеорологических станций и температур, и для каждой станции вывести минимальное, среднее и максимальное значение. Чтобы упростить задачу, было ещё несколько ограничений, однако я проигнорировал те, что относятся только к Java.

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

Однако с этим я согласиться никак не могу. Программирование по содержанию ничуть не сложней многих других отраслей знаний, а в чем-то даже и легче, особенно когда касается прикладных задач. Наткнулся на заметку человека, который высказал весьма небанальную мысль: при обучении программированию "с нуля" этот "ноль" для всех сильно разный. И у меня есть стойкое убеждение, что сложность освоения четко зависит от значения этого нуля. А вот почему он разный и что на него влияет- мне и хотелось бы поразмышлять.

▍ Но как?

Баги, баги, баги... Как же их много... Немудрено и фобию заиметь. И ведь никогда не знаешь, чем обернётся очередная ошибка в коде. Страх перед неизвестным, желание держать всё под контролем — закономерные спутники магического мышления. Но подождите, какие ещё магические ритуалы в 21 веке? Тем более у программистов...

Последние инновации в сфере ИИ, наиболее примечательными из которых стали проекты наподобие GPT-4, очевидно, могут иметь далеко идущие последствия для общества: от утопического избавления от монотонного труда до антиутопического ущерба для работы художников в капиталистическом обществе, а также до экзистенциальных угроз самому человечеству.

Лично я получил формальное образование дата-саентиста, даже выиграв в высококонкурентном конкурсе по машинному обучению в одном из лучших университетов Австралии и написав магистерскую, для которой создал в MATLAB с нуля собственные библиотеки. Я не гений в этой сфере, но, очевидно, лучше большинства конкурентов, то есть практиков вроде меня; я не могу, сидя в пещере, создавать собственные библиотеки на C, но умею читать учебники, реализовывать готовые решения на языках высокого уровня и использовать библиотеки, написанные элитными организациями.

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

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

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

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

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

Начну очень издалека. Видите мой ник? Его опосредованный источник — давно забытый одноимённый криминальный фильм двадцатилетней давности; когда мне нужно было придумать позывной для регистрации в местной локалке, забавное сочетание букв само выпрыгнуло из извилин на клавиатуру. И с тех пор кочует вслед за мной, не считаясь с моими желаниями, в том числе — и в одном из созданных ещё на заре gmail почтовых ящиков, используемых для всяких регистраций, подписок, и прочего спама.

Несколько лет назад на этот почтовый ящик стали приходить письма от рекрутеров, зовущих Станислава поработать iOS-разработчиком. Здесь было две проблемы: я никогда не писал для iOS, и я не Станислав.

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

Так благодаря одному тексту появилась идея — собрать самые необычные публикации, связанные с темой персональных данных, и объявить конкурс интересных «историй, достойных экранизации». Мы предлагаем продолжить в комментариях — рассказывать о из ряда вон выходящем опыте, а мы вместе с ***, ***, и *** выберем лучшие и наградим победителей призами — *** (если честно — это будет хабрамерч). 

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

Вспомним наш любимый мультфильм «Падал прошлогодний снег» с его шикарными крылатыми фразами. Одна из них: «Уж послала, так послала». Вот и система так же — вместо отправки запроса посылает его куда-то далеко. А запросу обидно.

В технической документации часто встречаются фразы с использованием страдательного залога. Параметры там «задаются», файлы «сохраняются», а программа «запускается». Ох, опасная эта форма для строгих и однозначных описаний! Почему же страдательный залог заставляет читателей страдать? Будем разбираться...

«Лучший способ в чём-то разобраться до конца — это попробовать научить этому компьютер». Дональд Кнут (как минимум викицитатник говорит, что он так сказал).

Год назад я осознал, что моё развитие как инженера застопорилось. Не то, чтобы я перестал изучать что-то новое, скорее, страдал от отсутствия системности. Не было понятно, что изучать дальше, что уже получилось изучить и что из изученного я смог для себя извлечь. Поэтому я решил как-то осмыслить процесс самообучения и за год привёл его к системе, которая мне довольно сильно помогает.

Для тех, кто, как и я, испытывал похожие проблемы, я решил поделиться своим методом.

По счастливой случайности я оказался резидентом Евросоюза, а значит, на меня также распространяется GDPR. Он позволяет мне запросить копию информации, которая хранится обо мне у всяких разных компаний. Я решил сделать это у Apple, и был неприятно удивлен.

Apple старается собирать как можно меньше данных.