Миниатюрная фича: убрать результат из поиска по коду

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

Например, в VS Code можно убрать результат из поиска. Можно сделать простой запрос, зная, что в него попадёт немного больше, чем нужно, что в результатах будет несколько false positives — и убрать их в один клик.

Первоначальная задача наверняка стояла как «выводим результаты поиска», и в такой формулировке совсем не очевидно, что такая кнопка а) нужна и б) будет полезна.

NPR Accuracy Checklist (3x5in)

Обожаю красиво оформленные чеклисты и испытываю нежность к NPR в целом.

THE NPR ACCURACY CHECKLIST 13 THINGS THAT MUST BE DOUBLE- OR TRIPLE-CHECKED

  • AGES (Get the date of birth & do the math.)
  • DAYS, DATES (Are you sure it happened then?)
  • GRAMMAR & SPELLING (Listeners & readers notice mistakes & forget your great story.)
  • HISTORICAL “FACTS” (Don’t trust your memory.)
  • LOCATIONS (Get them right & pronounce them correctly.)
  • NAMES OF BUSINESSES, GROUPS & SCHOOLS (For the 100th time, it’s Dartmouth College!)
  • NUMBERS (Check your math. Don’t say “millions” if it’s “billions.” Learn about percent vs. percentage point.)
  • PERSONAL NAMES (Get the correct spelling & pronunciation.)
  • PRONUNCIATIONS (Not only names, but places & terms too. The dictionary and our online guide are your friends!)
  • QUOTES (Make sure they’re accurate & correctly attributed.)
  • SUPERLATIVES (Claims to be the first, best, worst, etc., are often wrong; never trust them.)
  • TITLES (CEO, president, professor, etc.)
  • WEB ADDRESSES & PHONE NUMBERS (Never report them without testing them.)

Также в 2018 Марк Меммот объявил, что количество ошибок на NPR зашкаливает, надо CQ'чить всё перед тем, как отдать редактору. CQ — cadit quaestio — означает, что журналист проверил все факты.

Браузер должен отражать ценности пользователя

Каждый браузер посылает заголовок User-Agent, в котором пытается рассказать, что это за браузер (там, конечно, полный кошмар, об этом был перевод на Фронтире). Это интересное словосочетание: агент пользователя. То есть, тот, кто действует от лица и в интересах пользователя.

Но кажется, что где-то веб свернул не туда, и, в результате понятной динамики, сейчас браузер это в первую очередь агент корпораций, которые создают браузеры: Гугл, Эппл, Мозилла, Майкрософт, Яндекс, Самсунг, и так далее.

Кроме корпораций, это ещё и агент больших сайтов, таких как Медиум или Ютуб, которые могут потратить большое количество ресурсов на разработку своей платформы с одной целью — вовлечённость (это страшное слово engagement). Как правило, это вовлечённость затем монетизируется опосредованно, через рекламу.

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

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

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

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

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

На фоне этого инди-сайт совершенно теряется, и становится меньше причин поддерживать свой независимый сайт («я получу больше лайков в Твиттере!»). Часть авторов нашла интересный компромисс: они публикуют оригинал у себя, и загружают на Медиум копию вместе с ссылкой на оригинал. Таким образом они получают и распространение Медиума, и сохраняют контроль над текстом.

Что может хотя бы чуть-чуть противостоять таким системным эффектам, как фидбек луп распространения Медиума? Агент пользователя. 11 декабря я написал твит с идеей расширения, которое автомагически переходило бы по ссылке на самостоятельно размещенную версию статьи с Медиума. Это пример того, как браузер вместе с расширениями могут точнее отражать мои намерения, могут помочь проявить мою agency, то есть, способность действовать самостоятельно.

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

Но я сейчас использую Firefox — что тоже кажется важным в свете смерти движка внутри Edge. Потому что разнообразие браузеров — тоже одна из моих ценностей.

Точно таким же агентом пользователя выступает браузер, когда предлагает такие фичи, как «режим чтения», увеличивание текста, игнорирование запрета автозаполнения паролей. Любая возможность, которая даёт пользователю больше контроля над происходящим, неизбежно забирая часть контроля у авторов сайтов, увеличивает agency пользователя — и потому хороша.

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

Сейчас маятник контроля сайт/пользователь сильно на стороне сайта, и сам по себе он не качнётся в обратную сторону. Существуют Greasemonkey и Stylish, расширения, которые позволяют вмешиваться в происходящее на странице, но их аудитория во многом ограничена теми, кто уже владеет JS и CSS; существуют адблокеры разной степени честности. Нужно больше, нужно больше новых идей и расширений, меняющих опыт просмотра сети, и ещё больше расширений, которые изменят опыт авторства в сети. Нужно, чтобы идеи и расширения были настолько хорошими, чтобы у них получилось преодолеть барьер «а что такое расширения» (браузеры могут здесь, несомненно, помочь пиаром — но вряд ли будут это делать).

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

Если у вас есть такие идеи, можете поделиться в Твиттере (я осознаю иронию): @marinintim, или по почте: [email protected].

Пустое пространство в жизни

Скорее всего, вы слышали от дизайнеров о важности пустого пространства. Умелое использование такого пространства концентрирует наше внимание на том, что есть на странице, и позволяет элементам «дышать».

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

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

Нужно бежать изо всех сил, чтобы остаться на том же месте.

Из этого вырисовывается образ «идеального программиста»: её расписание забито под завязку, и те минуты, что она не тратит на рабочий проект, она изучает что-то, ну, в крайнем случае, пробует новый инструмент.

Информационное давление усугубляет эффект. Стоит открыть твиттер, как сразу сыпется огромное количество новостей, которые следует прочитать и учесть. Рассылки «Лучшие репозитории на Гитхабе за неделю», «Главные статьи по фронтенду за месяц».

Я не говорю, что всё это не нужно или не важно. Я говорю, что важно и другое.

Поездка в метро без подкаста в наушниках, просто разглядывая двери. Вечер без митапов, утро без статей, и дни без экспериментов с CSS. Обед без телефона в руке с открытым лонгридом или твиттером.

Пространство, которое целенаправленно не занято чем-то.

Поначалу это покажется странным. Неэффективным. Скучным. Может быть, даже расточительным. В конце концов, в сутках всего восемьдесят шесть тысяч четыреста секунд — и потратить шестьсот из них вникуда?

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

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

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

Например, что пустое пространство в дизайне и в жизни решают схожие задачи.

На странице, где каждый свободный сантиметр экрана занят чем-то, сложно сориентироваться. Сложно найти важное. Дизайнеры знают уже давно, что важность передаётся не только гигантским размером шрифта, но и отступами, пространством вокруг. Здесь — ровно то же самое.

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

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

1

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

Открытое предложение

Кратко: Мне можно писать на почту [email protected] — особенно если мы не знакомы лично. Предложение действительно до тех пор, пока здесь не написано обратное. Рад пообщаться про разработку, фронтенд, обучение, подкасты.


Привет, меня зовут Тим. В 2018 году я работаю в компании EPAM, где занимаюсь фронтендом и немножко обучением. Также я делаю (очень медленно) подкасты про веб и тех, кто его делают. До этого я читал курс про Джаваскрипт; и я веду смешной на мой взгляд твиттер.

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

Не надо думать «а можно ли написать письмо незнакомому человеку» — этот пост и есть приглашение и разрешение. Я с удовольствием пообщаюсь про Джаваскрипт и Раст, Software Engineering и архитектурные штуки; посмотрю/попробую ваш стартап; отвечу на вопросы про подкасты.

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

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

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

Также, если вы будете в Петербурге (или вообще там живёте), то меня можно выцепить на кофе — точно так же, через почту. (С обычными оговорками о сложности расписаний)

Я поддерживаю в актуальном состоянии страницу /now, где пишу о том, что мне интересно сейчас, и о чем мне будет особенно интересно поговорить.

Спасибо за внимание, и до встречи в инбоксе.

Руководство по программистским спорам

Наверняка у вас есть друзья-программисты, которые ведут ожесточенные споры про языки программирования. Что же делать, если вам хочется поучаствовать, но вы не разбираетесь?

Прочитать это руководство, конечно же! Чтобы начать, нужно запомнить несколько простых правил.

Правило №1: язык — говно

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

— Джава хороший язык. — Да говно твоя джава!

Дальше возможно два исхода: либо собеседник нехотя признает вашу правоту, либо начнёт защиту. В первом варианте мы уже победили, и можно заняться более продуктивными вещами, например, настроить заново внешний вид редактора.

Во втором случае возможны несколько опций, которые будут рассмотрены в дальнейших правилах.

Первое правило задаёт темп дискуссии и позволяет создать видимость профессионализма. 1

Правило №2: бейте в слабые места

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

— Чё это джава говно?
закатив глаза Статическая. Типизация. Кошмар, как так можно вообще в (подставить год)?

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

  • Джаваскрипт: интерпретируемый язык с динамической типизацией, прототипной моделью наследования, сборщиком мусора. ПРИДУМАН ЗА ДЕСЯТЬ ДНЕЙ!
  • Джава: компилируемый язык со статической типизацией, классовой моделью наследования, сборщиком мусора. ОЧЕНЬ МНОГОСЛОВНО, БЕЗ IDE НЕ РАЗОБРАТЬСЯ.
  • Раст: компилируемый язык со статической типизацией, с автоматическим управлением памяти без сборщика мусора.
  • Кложура: компилируемый и интерпретируемый язык с динамической типизацией, сборщиком мусора.
  • Хаскель: компилируемый язык со статической типизацией, сборщиком мусора. НУЖНО ПОНЯТЬ МОНАДЫ, ЧТОБЫ ВЫВЕСТИ HELLO WORLD.
  • Эликсир: компилируемый и интерпретируемый язык со статической типизацией, сборщиком мусора
  • Си: компилируемый язык со статической типизацией, ручным управлением памятью.
  • Сиплюсплюс: компилируемый язык со статической типизацией, ручным управлением памятью и иногда автоматическим управлением памятью.
  • Руби: интерпретируемый язык с динамической типизацией, классовым наследованием, сборщиком мусора.
  • Не перечисленные выше: ДА ОН ЖЕ НИКОМУ НЕ НУЖЕН.

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

— И что хорошего в джаве? — На рынке полно разработчиков, легко найти работу. — Тебе что ли десять тысяч кодеров нужно? Лучше уж найти двоих-троих, зато самых клёвых. Да и какую работу ты джавистом найдёшь? То-то же.

Правило №2 поможет вам продержаться на ринге дискуссии до тех пор, пока собеседнику не надоест — тогда-то и надо объявлять победу.

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

Правило №3: объявите, что объективности не существует

Конечно, вчера вы говорили одно, а сегодня другое — но это не потому, что вы не правы, а потому что это два разных спора! Контекст всегда очень важен (но упоминать его до этого не стоит — от вас могут потребовать подробностей). Секрет в том, что без контекста действительно нельзя однозначно сказать, нужна ли динамическая типизация, или сборщик мусора.

Ещё всё зависит от проекта, но больше всего — от команды. (На наши правила это не влияет, но звучит хорошо)

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


Ну вот и всё, вы восхитительны и готовы участвовать на равных в спорах про языки программирования!

1

Обсценная лексика работает для этого ещё лучше, но не везде.