Повсеместное программирование: достаточно ручки и бумаги
Новые идеи могут прийти на ум программисту в любое время — например, на прогулке или в очереди. Для обмена идеями отлично подходят рабочие планерки. Какой-то комментарий сам по себе может быть странным или предсказуемым, но в нем попадется несколько фраз, которые привлекут мое внимание. Они смешаются с какими-то незаконченными мыслями и впечатлениями вчерашнего дня.
Так рождаются новые идеи
Оставшаяся на настольном компьютере среда разработки никогда не кажется такой далекой и такой тяжелой на подъем, как в те моменты, когда у тебя в голове задыхается и чахнет новая идея, которой нужен «глоток воздуха», чтобы заявить миру о своем существовании.
Если мы спешим, то можем хотя бы законсервировать идею — набросать ее на бумаге, пока ее помним, а потом вернуться к ней, когда будет время. Но иногда этот момент бывает упущен, искра гаснет, а вернуть ее не удается. Требуется снова искать пищу для ума. Правда, сегодня уже есть Twitter. Этот сервис не назовешь отличным инструментом для записи идей программиста, но Twitter отлично подходит для записи тех кратких мыслей и остроумных замечаний, которые в другой среде остаются неуслышанными и неоцененными.
Я думаю, что Twitter не менее удобен для записи коротких программ и кратких программинг-сессий, длящихся от тридцати секунд до нескольких минут. Подобную роль Twitter может играть и в социальных взаимодействиях: отслеживание программ, которые находятся в процессе разработки, обмен предложениями, опровержение, расширение, интеграция идей.
Под «повсеместным программированием» (Ubiquitous programming) я понимаю возможность программировать где угодно и когда угодно, даже в такие короткие свободные минутки. Термин указывает на связь такого подхода с более масштабным явлением «повсеместных вычислений». Конечно, термин «повсеместное программирование» впервые употребил не я, но мне нечасто приходится встречать людей, которые буквально понимают это выражение (а не как «программирование для систем, обеспечивающих повсеместные вычисления»).
В последнее время я не раз задумывался о повсеместном программировании, так как меня одолевали новые идеи. Некоторые из них я изложил в статье «Abadoning Commitment in HCI» и в дискуссии с группой программистов, занимающихся технологией дополнения пользовательского ввода.
Как бы то ни было, после приобретения смартфона я не раз задумывался, как можно использовать его для программирования. Идей почти не было, пока один приятель не объяснил мне интерпретацию интерпретации замечательной статьи Брета Виктора «Доступное программирование», в которой Виктор критикует излюбленный способ записи моего друга. Не подумайте, что он стал жаловаться: «Ой-ой, не трогайте мою нотацию!», он просто натолкнул меня на интересные мысли. Я стал размышлять: какой способ записи идеально подошел бы для повсеместного программирования?
Ручка, бумага и камера
Уже сама идея писать код на сенсорном экране смартфона мне неприятна. Даже когда я ввожу через тачскрин информацию на естественном языке, я чувствую себя скованным — визуально, физически, духовно, эмоционально. Ладони у меня большие, они закрывают экран, правильно поставить курсор удается не с первого раза. Еще часть экрана закрывает виртуальная клавиатура. Если бы мне пришлось впихнуть на такой экранчик окно IDE — предложения, аннотации, ссылки и т.д., — то совершенно не было бы места не то что для кода и комментариев, а даже для моих собственных мыслей. Планшет и ноутбук неудобны по другим причинам. Они довольно тяжелые, их нужно слишком долго готовить к работе, и, конечно, они не находятся рядом в тот самый момент, когда тебя озарила идея. У меня нет карманов, в которые влезал бы планшет, а если бы и были, не представляю, как можно удобно усесться с такими карманищами.
Но когда я подумал об очках, они показались мне интересным вариантом
В очках для дополненной реальности есть встроенная камера, которая «видит» то же, что и я. Если я смотрю на код, то могу тут же загрузить этот код в программу. То же самое можно сделать и при помощи камеры смартфона: сфотографировать сделанные наброски. Тогда первое грубое редактирование можно выполнять уже не на экране. Достаточно иметь с собой небольшую стопку простой бумаги и ручку, эти вещи легко носить в кармане или кошельке. А более запасливый человек может носить с собой даже общую тетрадь или блокнот в переплете.
Ручка, бумага и камера становятся основными устройствами ввода. «Носитель» программы — бумага — может быть и большим, и маленьким, смотря как его сложить. Тонкая ручка — гораздо более удобное устройство ввода, чем палец. Кстати, возможно, кому-то будет удобнее работать карандашом.
Если выполнять редактирование на бумаге, то экран смартфона остается свободен для более сложных аспектов разработки: аннотаций, предложений, запросов на разъяснение, предупреждений, ошибок, выстраивания взаимосвязей с другими программами. При работе с очками подобные элементы могут отображаться в наложенном слое или на периферии.
Модульность, связывание, совместное использование
В таком случае мы не сможем напрямую подключать подпрограммы, которые пишутся на других «холстах». Допустим, мы записали их на других листах блокнота, которые не хотим вырывать. Соответственно, межпрограммные взаимосвязи также выстраиваются в виртуальном пространстве. Автор нарисует нужную связь на бумаге — например, начертив прямоугольник или добавив немного контекста (скажем, заголовок или другая надпись, может быть, дата, номер версии и имя автора). Имея такое представление в качестве подсказки, а также менее явные подсказки (это может быть история просмотренных автором программ), мы сможем отобразить на телефоне или в очках существенное количество вариантов.
Выбирая варианты, выстраивая взаимосвязи, мы превращаем программу в нечто большее, чем просто наброски на бумаге. Получается более значимая, точная, логичная, правильная, интегрированная сущность. Разработка и редактирование превращаются в смешанную картину, состоящую из виртуальных операций и реальных дополнений (а иногда и сокращений — допустим, нам потребовалось стереть или зачеркнуть элемент). Фактически программа — это виртуальный объект, поддерживаемый в среде программирования. Программу желательно располагать в облаке (общедоступном или закрытом) и синхронизировать с локальным хранилищем данных (на случай неожиданного вылета в оффлайн). Программа останется таким объектом, если не будет повреждена и до тех пор, пока она будет доступна для понимания. Виртуальные программы индексируются по многим показателям: автор, дата, местоположение, содержание, комментарии, взаимосвязи, история и прочая визуальная информация, находящаяся «на кончиках пальцев».
Если у вас есть доступ «только для чтения» к моему облаку, я могу дать вам блокнот, и вы сможете читать программы. Не только рассматривать мою полуразборчивую писанину, но и улавливать связи, читать разъяснения. Моя библиотека станет для вас досягаема. Повсеместное программирование предполагает совместное использование именно таким чудесным осязаемым образом, напоминающим обмен книгами. Разумеется, вы сможете воспользоваться и методом «электронной книги», просматривая облако непосредственно с экрана. Но это, пожалуй, будет намного менее удобно.
Схемы и заметки в произвольной форме
Современное программирование — это в первую очередь написание текста, так как именно текст набирается на клавиатуре. Для ввода в произвольном формате можно использовать мышь, но мне это показалось довольно неудобным. А вот работая с ручкой и бумагой, мы можем рисовать какие угодно графики, схемы, стрелки, функциональные кривые, наброски (символы, карты, взаимодействия), специальные математические символы и т.д.
Это особая свобода, которая и привлекает меня возможностью делать наброски параллельно с обдумыванием идей. Я охотно покупаю общие тетради, наборы ручек, с которыми хожу и в парк, и в ресторан. Мне уже зачастую нелегко вернуться к написанию программ обычным негибким текстом.
Мне нравится делать наброски, заметки на полях. Я объединяю идеи. Я не в восторге от структурных редакторов, а вот совершенно «неструктурированное» редактируемое пространство, в котором можно представить хорошо структурированный объект виртуальной программы (при помощи объяснений и ограничивающих условий), очень меня привлекает.
Не только текст
Обычно мои наброски из рабочих тетрадей превращаются в путаные обрывки информации, к которым я никогда не возвращаюсь (они мне просто не нужны после того, как я полностью усвою записанные в них концепции). Но если бы все эти эскизы, наброски, схемы и прочая информация индексировалась, становилась доступной для поиска, изучения, воспроизводилась на носителе, который не горит, то это значительно обогатило бы текстовую информацию (не обязательно связанную с программированием). Часто на рабочих собраниях люди фотографируют схемы, сделанные на маркерных досках. Почему всю эту информацию никто еще не сохраняет и не индексирует? Есть ли в наличии подходящий для этого инструмент? Дарю идею для революционного приложения, которое озолотит своего создателя, — развивайте!
REPL, виджеты, живой кодинг
Независимо от того, работаем ли мы с умными очками или камерой, наши программы, написанные на бумаги, будут отличаться высокой интерактивностью. В частности, это касается вычисления выражений. Как записать серию выражений и сразу же узнать их значения? Запросто, если программа создается ручкой на бумаге.
Интересная возможность связана с развитием концепции REPL-среды полнофункциональных виджетов. Выражение должно результировать не в обычную величину, а в осязаемое значение, или оголенный объект, или в подобную сущность, которую можно представить в виде виджета, наблюдать ее и манипулировать ею. В частности, такие виджеты могли бы управляться голосом или жестами.
Виджеты, разработанные таким образом, могут управлять состоянием в реальных системах и оказаться удобной основой для повсеместных человеко-компьютерных взаимодействий (HCI). Открываем блокнот на нужной странице. Настраиваем несколько необходимых виртуальных ползунков и флажков. Берем чистый лист бумаги и записываем на нем несколько программ или ссылок на них. Загоняем это в нашу среду разработки — всё, виджет готов.
Понятие «живого кодинга» противоречит повсеместному программированию, но я считаю, что две эти методики могут хорошо взаимодействовать на стыке программирования и человеко-компьютерных взаимодействий: при разработке таких виджетов и REPL-сред.
Как максимально эффективно использовать цвет?
Программируя ручкой на бумаге, мы теряем подсветку синтаксиса. Разработчики, которые не желают от нее отказываться, могут воспользоваться разноцветными ручками или цветными карандашами. Но при повсеместном программировании, как и в повсеместных вычислениях, я не склонен использовать семантический цвет как минимум по шести причинам:
- если у цветов разная семантика, то перед наброском идеи требуется тратить драгоценное время на сортировку карандашей;
- при использовании нескольких цветов потребуется носить с собой гораздо больше карандашей или ручек, такое количество может не уместиться в кармане;
- чем проще контрастность, тем лучше ее будут обрабатывать алгоритмы машинного зрения;
- с цветами неудобно работать при изменяющемся освещении (особенно при необычном, например, неоновом свете);
- в повсеместном программировании/HCI могут прижиться невидимые ссылки (инфракрасные, ультрафиолетовые, использующие дифракцию на кристаллах), но обычно таким ссылкам не хватает гибкости при представлении цветовой информации;
- чем проще контрастность, тем более повсеместным получается программирование
Тем не менее цветовые возможности могут найти применение в чуть более сложном подручном программировании или компиляции.
Что дальше
Думаю, повсеместное программирование при помощи ручки и бумаги — многообещающая и интересная возможность, которую можно реализовать уже сегодня. При такой работе предпочтительно было бы использовать умные очки (особенно при работе стоя или в движении), но смартфоны более распространены, доступны и лучше подойдут для начала. Существующие сегодня алгоритмы машинного зрения в принципе достаточно совершенны для достижения этой цели. Нужное для работы облако также несложно реализовать (предпочтительно на базе свободного ПО).
Здесь я не затронул еще одного аспекта, необходимого для реализации этой модели, — речь об интеграции такого гибкого синтаксиса с моделью программирования. При этом можно обойтись и без протокола RDP (хотя я бы только приветствовал это). Несколько лет назад я много размышлял о синтаксисе и пришел к выводу, что его стоило бы упростить по максимуму, ради сохранения статического восприятия кода.
Интересно, может ли какой-либо подход, связанный с пользовательским синтаксисом, помочь развить специализированный визуальный и схематический синтаксис. Объединив такой подход с применением виртуального объекта программы, мы сможем значительно отложить выстраивание синтаксиса. Достаточно начать писать, а синтаксис разъяснить уже потом (ведь синтаксис — это просто еще один вид связей внутри программы!).
Браузер на страже API-запросов: строим безопасное общение фронтенда с бэкендом
Тут ошибка. mc.yandex.ru это только один из доменов метрики. Для пользоватей из других регионов метрика перестанет работать. Самое неприятное здесь это то что нельзя применить плейсхолдеры как у Гугл аналитики, потому что метрика не использует поддомены. Перечислять все 20+ доменов метрики в заголовках это дичь. К тому же они могут измениться.
Поэтому придётся полностью отказаться от CSP либо от метрики.
Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Безусловно, вы правы. Для регионов надо указывать альтернативные домены (которые есть в документации яндекса), в статье я привёл ознакомительный пример конфига. Не думаю, что стоит совсем отказываться от CSP или метрики. Тут всё зависит от направленности самого приложения и тем, на сколько часто будут возникать блокировки csp. Если такие визиты единичны, то ими можно пренебречь.
Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
Вам надо что-то с ручками делать…
Всего голосов 1: ↑1 и ↓0 +1
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Что вы имеете в виду?
Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Лучше вы поясните, что вы имели в виду под ручками в вашем тексте (переводе?)… поищите, если вы читали его, конечно))
REST API ручками
Пусть ручка получения POST
В ручке POST
Всего голосов 2: ↑2 и ↓0 +2
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
дак у буржуев эт endpoint же…
Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
С буржуями всё понятно, и с точками входа, и с обработчиками и другими адекватными словами-переводами и не очень. Но вот ручка… даже по смыслу бред, ручка двери только на ум приходит. Откуда этот «сленг»?)
Всего голосов 1: ↑1 и ↓0 +1
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
В паре проектов, в которых я участвовал сленговое «ручка» тоже вполне себе использовалось. Цепочка аналогий такая: у нас есть метод, что-то обрабатывающий, он же handler -> hand -> ручка 🙂
Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Ручка — это endpoint API-интерфейса. Например GET /user — endpoint получения информации о пользователе. В русском языке закрепился немного сленговый термин «ручка»)
Всего голосов 6: ↑3 и ↓3 0
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
В русском языке закрепился немного сленговый термин «ручка»
Первый раз про него слышу.
Всего голосов 5: ↑5 и ↓0 +5
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Я полагаю имелось ввиду = handle
Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
handle как «ручка» тоже нечасто переводится. Обычно это «дескриптор».
Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
НЛО прилетело и опубликовало эту надпись здесь
Показать предыдущий комментарий
Принял ваше замечание, спасибо) исправил. Надеюсь, так понятнее)
Комментарий пока не оценивали 0
Ответить Добавить в закладки Ещё
Хранение refresh_token в любых куках плохая идея. А тут ещё он превратился из токена в обычную сесионую куку, которой и нужна защита от CSRF. Ну и дальнейшая идея использовать в качестве CSRF токена протухший acess-token ещё хуже.
Всего голосов 1: ↑1 и ↓0 +1
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
В статье я как раз говорил, что хранить надо только в httpOnly. Это не совсем сессионная кука, это кука, нужна только для обновления токена доступа. Если злоумышленник не будет иметь прежний токен доступа (который не достать csrf атакой), то воспользоваться рефреш токеном он не сможет.
Всего голосов 2: ↑1 и ↓1 0
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Признак httpOnly говорит только о том, что эта кука недоступна из javaScript и для всех запросов она работает как обычная кука. CSRF как раз и основан на автоматической отправке кук, и для него глубоко паралельно она htpOnly или нет. Поэтому ваш refresh-token для CSRF ПОЛНОСТЬЮ аналогичен обычной куке.
В обычной ситуации считается, что access-token может быть перехвачен, но из-за его короткого действия похититель ним воспользоваться не может (не успеет). А вот своровать refresh-token сложно (в идеале вообще невозможно). А у вас вы refresh-token положили вору на блюдечке (он отдается автоматически при запросе), да ещё и разрешили воспользоваться протухшим acces-token — это просто праздник для хакера.
ЗЫ: При разработке системы безопасности есть основное правило: ЕСЛИ ВЫ НЕ ЭКСПЕРТ ПО БЕЗОПАСНОСТИ СЛЕДУЙТЕ ИНСТРУКЦИИ И НЕ ПРИДУМЫВАЙТЕ СВОЮ СИСТЕМУ, ТАК КАК В ВАШЕЙ СИСТЕМЕ С ВЕРОЯТНОСТЬЮ 100% ЕСТЬ ДЫРА. 🙂
Всего голосов 3: ↑2 и ↓1 +1
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Каким образом в этой схеме злоумышленник с помощью одного лишь csrf-атаки прочитает токен, хранящийся в httpOnly cookie? Он может послать запрос через браузер с этой куки в заголовке, не отрицаю. Но что он этим добьётся? Как вы верно заметили, такую куку он с помощью js прочитать не сможет. А одного рефреш токена не достаточно для того, чтобы выполнить какое-либо действие или получить пользовательские данные.
ЗЫ: Нужно больше капса)
Всего голосов 3: ↑1 и ↓2 -1
Ответить Добавить в закладки Ещё
Показать предыдущий комментарий
Мне кажется если вы критикуете в чем то оппонента, то может стоит предложить верный алгоритм, хотя бы в одной фразе?
Что такое ручки в прграммировании?
Угу. Если handle, то это «дескриптор», или «числовой идентификатор»
А если просто ручки, то ими стучат по клаве.
Кирилл ИнжуватовУченик (134) 8 лет назад
Там имелось ввиду, что они выдерживают нагрузку 100 и 1000rps
Кирилл ИнжуватовУченик (134) 8 лет назад
Там имелось ввиду, что они выдерживают нагрузку 100 и 1000rps
Ирина В Просветленный (49017) Кино не смотрела конечно, но rps это «обороты в секунду», в программировании таких объектов нет. Но если Вы приведете фрагмент текста, и название продукта, то попробую понять. Возможно, что речь о гироскопах, в навигационных чипах, для мобильников?
Кирилл ИнжуватовУченик (134) 8 лет назад
Браузер использовал Cocaine потому что он позволял делать ручки которые выдерживают нагрузку 100 rps и 10000rps.
То чем мы занимаемся в серверной стороне яндекс браузера это ручки начиная с аджеста api turbo.
Что такое «ручки» на сленге программистов?
Ну в том числе у нас есть такие ручки, в том числе продуктовые ручки, когда нужно чтобы в определенный момент в браузере что-то замигало. Ну вот это не сильно нагруженные ручки. Очень нагруженные ручки мы стали писать на плюсах.
Отслеживать
задан 20 июн 2015 в 21:38
113 1 1 золотой знак 1 1 серебряный знак 5 5 бронзовых знаков
Это что-то яндексоспецифическое, видимо. Ни разу не слышал слово «ручки» в таком контексте.
20 июн 2015 в 21:39
предположу: «инструменты», в контексте цитаты, логично вытекает, «собственные наработки программного обеспечения». СЕО контекст — обработка некоторого объёма информации путём визуального просмотра, это объясняется спецификой некоторых тематик
20 июн 2015 в 22:00
4 ответа 4
Сортировка: Сброс на вариант по умолчанию
Это термин специфичный для Яндекса, пошел от «ручек управления» — т.е. что-то, за что можно подергать, чтобы произошло какое-то действие. Часто используется в словосочетании «дернуть ручку».
К handle никакого отношения не имеет. К UML возможно тоже, т.к. он в документации не используется.
Отслеживать
ответ дан 21 июн 2015 в 11:04
31k 13 13 золотых знаков 96 96 серебряных знаков 157 157 бронзовых знаков
Кажется, это должно быть принятым ответом.
13 окт 2021 в 14:43
Ручки — это, например, URL’ы в API какого-нибудь сервиса.
Вот, например, API Яндекс.Диска.
Я могу сказать: «Чтобы загрузить файл на сервис, мне надо дёрнуть ручку https://cloud-api.yandex.net/v1/disk/resources/upload и получить URL для закачки».
Отслеживать
19.1k 6 6 золотых знаков 30 30 серебряных знаков 44 44 бронзовых знака
ответ дан 20 июн 2015 в 22:05
421 2 2 серебряных знака 5 5 бронзовых знаков
слово «ручка» в данной документации не упоминается
30 дек 2020 в 4:58
Подозреваю, это может быть как-то связано с внешним видом реализуемых компонентом интерфейсов в UML, которые выглядят как рукоятки в механике/гидравлике:
Соответственно, «дернуть ручку» — воспользоваться интерфейсом.
Отслеживать
ответ дан 21 июн 2015 в 10:43
34.5k 15 15 золотых знаков 65 65 серебряных знаков 94 94 бронзовых знака
Ручка — это просто метод публичного интерфейса приложения, будь то веб-приложение или еще какое-то. Пошло от английского handle, насколько понимаю, используется со времен handle = fopen(path, mode); . Очевидно, в тексте речь идет про какие-то ресурсы публичного API, которые вследствие высокой нагрузки переписали на плюсах для увеличения быстродействия.
Отслеживать
ответ дан 20 июн 2015 в 22:32
36.1k 2 2 золотых знака 56 56 серебряных знаков 83 83 бронзовых знака
видать орусифицирование английского handle
21 июн 2015 в 2:31
@des1roer «Пошло от английского handle»
21 июн 2015 в 7:22
-
Важное на Мете
Похожие
Подписаться на ленту
Лента вопроса
Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.
Дизайн сайта / логотип © 2024 Stack Exchange Inc; пользовательские материалы лицензированы в соответствии с CC BY-SA . rev 2024.1.3.2953
Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.