Веб-технологии

Последние записи

2023.01.06 • Иван Шихалев

Кстати, о птичках

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

Но недавно я обнаружил еще более странный момент, заглянув в Я.Вебмастер — см. собственно скриншот. Т.е. люди ищут уже не просто поведение птиц на кормушке, а конкретный текст конкретного автора. Такое ощущение, что попал в какую-то учебную программу в качестве рекомендованного материала. Или что это вообще?

shikhalev.orgпоискптицысайты

ТехнологииWebДыбрО себе

2022.12.07 • Иван Шихалев

Дыбр сайтостроительный

Оптимизация страниц

В процессе работы с hugin.shikhalev.org обнаружилась интересная особенность Jekyll, о которой желательно знать, чтобы не было мучительно больно…

«Страницы», то есть «pages», не являющиеся постами (и не входящие в никакие другие коллекции) обрабатываются крайне медленно. Переделка страниц в коллекции ускорила сборку сайта (локально) примерно в 10 раз — с около двухсот секунд до менее двадцати. Сначала я даже попытался переделать их в посты, но пост должен содержать дату в имени, и нет никакой возможности задать ему URL, соответствующий просто структуре каталогов, без даты в каком-либо виде. Точнее, каждому посту в отдельности-то можно, вручную во front matter, но это уже издевательство над самим собой и полный трэш в случае каких-то переделок и рефакторинга. Создание же отдельных коллекций такой проблемы не несет, единственное, что понадобилось прописать ручные адреса для файлов index.md, чтобы ссылки на них шли как ссылки на каталоги, а не на index.html

Что делать с комментариями?

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

Думаю в ближайшее время подключить giscus, каковой уже испытан на hugin.shikhalev.org, а затем как-то решить вопрос с автоматическим сохранением комментариев внутрь репозитория. Впрочем, буду рассматривать и другие варианты, может быть, за последнее время появилось что-то более интересное и подходящее.

upd: Прикрутил giscus, но вопрос закрытым не считаю.

Jekyllshikhalev.orgкомментарииоптимизациясайты

ТехнологииСофтWeb

2022.11.04 • Иван Шихалев

Conky и OpenWeather

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

У меня почему-то не получилось получить данные текущей погоды с OpenWeatherMap.org, только прогноз на пять дней с интервалом 3 часа. Надо, конечно, поразбираться с их API получше — еще один повод не считать работу законченной…

Как бы то ни было, пятидневный прогноз вполне себе отображается. Как его использовать:

Мне потребовалось доустановить некоторые пакеты для Lua:
- lua-cjson для парсинга ответа от сервера.
- luaposix для всякой вспомогательной работы с файлами и каталогами.
- luasocket для собственно загрузки по HTTP.
В вашей системе это все может быть уже установлено, а может и не быть, нужно проверить и доустановить.

ConkyLuaOpenWeatherмониторингпогода

ТехнологииWebПрограммированиеО себе

2021.07.09 • Иван Шихалев

Отчет о рефакторинге

Скриншот с [официального сайта Jekyll](https://jekyllrb.com/) — Скриншот с официального сайта Jekyll

Итак, я таки отрефакторил и обновил данный сайт. Почему нельзя было сразу делать правильно? Ну, в основном потому, что я впервые имел дело с Jekyll, изрядно подзабыл (а что-то и не знал) базовые приемы верстки… И так далее, и тому подобное.

Вторая (в моем случае) причина — это то, что, как это часто бывает, представление о желаемом результате уточнялось и формировалось в процессе достижения результата просто работающего. Соответственно, решение «исторически сложилось», если вы понимаете, о чем я. Любой проект ставит разработчика перед выбором: или бесконечное (и потому бесплодное) делание «как надо», или движение к идеалу через неидеальные, зато рабочие, варианты, которые, впрочем, без регулярного рефакторинга быстро становятся неулучшаемым и иногда не совсем рабочим болотом.

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

CSSFont AwesomeGitHubGoogle FontsGoogle MapsHTMLJavaScriptJekyllLiquidPNGSASSSCSSSVGaspect-ratiodisplayflexgridkramdownmarkdownshikhalev.orgstickyблогивеб-шрифтыверсткаграблииконкимедиа-селекторыпробелырефакторингсайтыстатическая генерацияшрифты

О себеТехнологииWeb

2021.06.03 • Иван Шихалев

Планирую рефакторинг

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

Самое время попросить фидбек: ежели кто видит недочеты, неудобства, баги какие-то… или имеет конструктивные предложения — welcome комментировать, здесь или в соцсетях.

Я в принципе в курсе о проблемах на мобильных, но детали не помешают.

Еще могут быть косяки на старых браузерах… Вот только новая версия скорее всего с ними будет еще менее совместима — думаю на grid’ах сверстать. Кто-то сейчас пользуется старыми браузерами? И если пользуется, то обращает ли внимание на верстку вообще?

Нужно ли что-то менять в рубрикации? Адреса контента от нее не зависят, так что могу себе позволить…

Визуальный дизайн тоже можно попинать, желательно с конкретикой.

shikhalev.orgверсткасайты

ТехнологииПрограммированиеRubyПубликации«Системный администратор»Web

2020.01.11 • Иван Шихалев

Rack — основа веб-фреймворков в Ruby

Оригинал этой статьи опубликован в журнале «Системный администратор» №5 (150) за май 2015. Прошу обратить внимание на год — какие-то моменты могут расходиться с современными версиями языка и библиотек…

Библиотека Rack — простой объектный интерфейс для написания веб-приложений.

Слово «rack» в английском языке имеет множество значений, включая такие, как «пытка» и «разрушение»… Однако, надо полагать, название рассматриваемой библиотеки произошло от другой группы смыслов: «стойка», «штатив», «каркас» и т.д. Rack обеспечивает простой и в то же время удобный интерфейс, обеспечивающий взаимодействие между веб-сервером и приложением, позволяя программисту сосредоточиться исключительно на логике последнего.

Этот интерфейс достаточно низкоуровневый и не ограничивает разработчика каким-либо заранее заданным способом организации приложения и высокоуровневыми абстракциями. Соответственно, он и не предоставляет таких абстракций — это уже дело фреймворков, которые работают поверх него: Rails, Sinatra и других.

Rack

ТехнологииПрограммированиеWeb

2013.08.16 • Иван Шихалев

Сохраняем выделение

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

var saved = null;

function storeSelection(e) {
  var main = document.getElementById('main');
  var current = e.target;
  var compare = main.compareDocumentPosition(current);
  if (compare != 0 && (compare & 16) == 0) {
    var range = window.getSelection().getRangeAt(0);
    saved = {
      startContainer : range.startContainer,
      startOffset : range.startOffset,
      endContainer : range.endContainer,
      endOffset : range.endOffset
    };
  }
}

function restoreSelection(e) {
  var main = document.getElementById('main');
  var current = e.target;
  var compare = main.compareDocumentPosition(current);
  if (saved && compare != 0 && (compare & 16) == 0) {
    var range = document.createRange();
    range.setStart(saved.startContainer, saved.startOffset);
    range.setEnd(saved.endContainer, saved.endOffset);
    var selection = window.getSelection();
    selection.removeAllRanges();
    selection.addRange(range);
  }
}

window.addEventListener('load', function(e) {
  var body = document.body;
  body.addEventListener('mousedown', storeSelection, false);
  body.addEventListener('mouseup', restoreSelection, false);
}, false);

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

В принципе, механизм очевиден, пояснения по методу compareDocumentPosition() можно найти в документации Mozilla, или на JavaScript.ru.

В процессе довелось столкнуться с интересным моментом — при абсолютном позиционировании элементов на странице могут быть области ничем не покрытые, в т.ч. и элементом body. Соответственно, обработчик события на них не срабатывает, и выделение сбрасывается. Чтобы этого не происходило, я использовал CSS:

body {
  position : absolute;
  top : 0px;
  bottom : 0px;
  left : 0px;
  right : 0px;
  padding : 0px;
  margin : 0px;
}

Демо-пример целиком можно взять по адресу: https://gist.github.com/shikhalev/6246433.

CSSHTMLJavaScript

ТехнологииWebЖизньОбщество

2011.07.29 • Иван Шихалев

Распределенная блогосфера

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

Сервера новой системы должны стать по сути трекерами, а хранение информации следует возложить на пользователей. Зря что ли придуманы всяческие ухищрения в современных браузерах? Причем хранить пользователь должен не только свои посты, но и посты тех, кого он желает видеть в своей френдленте. Это вполне оправданная нагрузка, которая позволит всякому более менее читаемому блогописателю быть постоянно доступным, даже без кэширования со стороны сервера-трекера (хотя и данное кэширование отнюдь не помешает). Причем, помимо того, что сервер обслуживает некоторое множество блогов, каждый блог должен иметь возможность подключаться к произвольному множеству серверов. И пусть сервера конкурируют друг с другом в удобстве веб-интерфейса и всяческих дополнительных плюшках (например, сроки кэширования, скорость канала). Идентифицировать же пользователя следует по публичному ключу, коим он и будет подписывать свои записи.

Вообще говоря, для работы такой системы достаточно и одного веб-интерфейса (при условии, что все блоггеры пользуются современными браузерами), но, естественно, никто не мешает (а открытость протокола и способствует) создавать браузерные плагины, десктопные и мобильные приложения, клиенты командной строки…

блогосфераразмышлизмы