?

Log in

No account? Create an account

Всё будет хорошо. Живу и радуюсь

июн. 12, 2017

11:19 pm - Выложил фотографии 2017 года

Выложил на Яндекс.фотки и Flickr фотографии за январь-май 2017.

DSC00023

Полистать новое можно, начиная с ссылок:
https://fotki.yandex.ru/next/users/sekrasoft/album/525075/view/1517779 и правее
https://www.flickr.com/photos/sekrasoft/35095929182/in/datetaken/ и правее

май. 6, 2017

04:25 pm - Королевская корона

Интересно.

Если https://www.youtube.com/watch?v=0IUwtMcSboM открыть разлогиненному пользователю в браузере с английским языком интерфейса, название и описание будут английскими.
Если https://www.youtube.com/watch?v=0IUwtMcSboM открыть разлогиненному пользователю в браузере с русским языком интерфейса, название и описание будут переведены.
Если https://www.youtube.com/watch?v=0IUwtMcSboM открыть залогиненному пользователю в браузере с русским языком интерфейса, название и описание останутся английскими.
Если https://www.youtube.com/watch?v=0IUwtMcSboM открыть залогиненному пользователю в браузере с русским языком интерфейса во вкладке в режиме инкогнито, название и описание будут переведены.

Если https://youtu.be/0IUwtMcSboM?list=UU8JE00xTMBOqKs7o0grFTfQ залогиненному пользователю в браузере с русским языком интерфейса, название и описание останутся английскими.
Если после этого развернуть видео на весь экран, название останется английским.
Если выйти из полноэкранного режима, название останется английским.
Если войти обратно, название останется английским.
Если после этого кликнуть на кнопку плейлиста слева, кликнуть по этому видео (его название останется английским), заголовок станет русским! Если выйти из полноэкранного режима, название будет английским.
Если войти обратно, название снова станет русским!



Вариации видео: Chrome/RU/logged in vs Chrome/RU/private vs Firefox/RU vs Firefox/EN.



Вариации плейлиста: Chrome/RU/logged in vs Chrome/RU/private.


Интересно.

май. 1, 2017

01:31 am - Кажется, проводил 2016й

Загрузил на Flickr и Яндекс.фотки пачку фотографий с 2016 года.

DSC09459.jpg

По ссылкам ниже можно листать вправо.
https://www.flickr.com/photos/sekrasoft/33521987734/in/datetaken/
https://fotki.yandex.ru/next/users/sekrasoft/album/525075/view/1504780

апр. 23, 2017

12:28 am - Искажённое восприятие директорий

Ох уж эти программы, которые умнее меня...

Почему, мать вашу, в программах, работающих с медиафайлами, так любят придумывать свои структуры "папок"? Открываешь такое творение, а там всю иерархию просрали.

Файл с жёсткого диска? С флешки? Лежал где-то в тематической коллекции? Да кто его знает! Отображается только какая-нибудь очередная "коллекция" или "файлы за месяц" или ещё что-нибудь, до чего додумались в пьяном угаре авторы программы.

Ядрёна мышь, я хочу видеть СТРУКТУРУ. Я хочу видеть КАТАЛОГИ. Каталоги, понимаете? Каталоги хочу видеть. Папки хочу видеть. Директории хочу видеть. Может быть, дерево каталогов как в Проводнике.

Файл уже на жёстком диске? Мне можно выткнуть флешку? Да фиг его знает, давайте попробуем выткнуть, может что-то будет видно. Вроде не исчез файл. И по двойному клику открывается. Значит с флешки удаляем. Э-э-э, так это был кэш? Это превьюшка из кэша открывалась, а настоящий файл я с флешки удалил, получается? Ну чёрт возьми, почему вы заменили удобную иерархическую структуру на самописное говно?

А Андроид что? Отправил меня в прошлый век.
Кто-нибудь помнит, когда были файловые системы без иерархии каталогов? Живые свидетели есть? А в 2017м ещё кто-то этим пользуется? Что? Нет?
Нет. В 2017 Андроидный просмотрщик картинок показывает мне одноуровневую иерархию папок! Одноуровневую, Карл! То есть если я сохранил сотню интернет-страниц с картинками (html+папка) в отсортированном виде, разбив всё на папки по темам и храню 100 папок с фотографиями в 5 папках по каждой теме, то просмотрщик плюнет на иерархию, расплющит её и покажет мне 200 папок с превьюшками, среди которых я должен возить пальцем по экрану и листать, листать, листать. И это, если кликнуть на "фотографии с устройства". Иначе - 400 дат, за которые были созданы накопившиеся файлы. И опять листать, листать, ли... Да что за ерунда, папки мне покажите!

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

Кому вообще это удобно?
Программистам? Нет, ведь иерархия папок естественна, и для неё наверняка есть 100500 готовых решений для разных языков/фреймворков/...
Пользователям? Ну разве что совсем тупым, у которых нет ни флешек, ни внешних дисков, есть только один компьютер с одним жёстким диском и пара знакомых знатоков компьютера, которые перенесут потом всю накопившуюся срань на новый компьютер.
Если у пользователя мало файлов, то он и в папках их найдёт. Если их много, потребуется каталогизация, и автоматика здесь разве что по датам разложит корректно. Если же речь идёт о музыке, то там в тегах частенько такая чушь, что все редкие песни, скачанные чёрт знает откуда, автоматика определит чёрт знает куда. И ищи их потом... Стоит упомянуть лишь, что дефис и тире в названии исполнителя породят его "злобного брата-близнеца", а "A feat. B" не будет отнесено ни к A, ни к B, причём "B feat. A"... ну сами знаете.

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

апр. 8, 2017

04:39 pm - Порция аудиосчастья. Крутые песни 90х-00х.

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

МакSим - Знаешь ли ты
Вирус - Ты меня не ищи
Акула - Такая любовь
Катя Чехова - Я тебя люблю 2020
t.A.T.u. - Полчаса
Инфинити - Я не боюсь
t.A.T.u. - Не верь, не бойся, не проси
Катя Чехова & Vortex Involute - В Твоих Глазах
МакSим - Ветром стать
Инфинити - Где ты
Света - Не говори
Reflex - Я тебя всегда буду ждать

дек. 18, 2016

08:25 pm - Компьютерная грамотность

Тонкий интерфейс


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


Реклама Apple Macintosh Portable, 1989

Ещё ссылки на 2 копии, а то видео, вставленное в оригинальный пост, удалили:


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

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

Эволюция от выживания к жизни


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

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

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

Что нового появилось в старых версиях компьютера (будем рассматривать программно-аппаратный комплекс)? Возможность хранить файлы! Командная строка как у хакеров вместо ввода с перфокарт! Цветной монитор! Доступ в Интернет! Проигрывание аудио без тормозов! Проигрывание видео без тормозов! Игры!

На качественном уровне просто целая революция произошла. Ещё вчера фича просто не могла выжить, а сегодня вдруг появилась.

Что нового появилось в новых версиях компьютера? Более быстрый доступ к файлам. Более быстрый доступ в Интернет. Хранение файлов в Интернете. Проигрывание аудио из Интернета. Проигрывание видео из Интернета. Более быстрый доступ в Интернет. Поддержка более нового стандарта беспроводной связи, проводной связи, шины данных.

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

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

Мануалы не нужны


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

Уже сейчас гугление ответов на stackoverflow популярнее инструкций к библиотекам. Почему? Потому, что исключается лишняя абстракция.

Изучение библиотек не нужно


Как это работает?
  1. Имеется пространство задач (то, что должна уметь библиотека)
  2. Программист A находит базис X в пространстве задач и реализует его (создаёт модель задачи, проектирует программные интерфейсы
  3. Программист A описывает базис X словами (создаёт документацию по каждому классу/методу Xi
  4. У другого программиста B появляется задача Y = &Sigma ai Xi, причём ai неизвестны.
  5. Программист B подмечает, что библиотека X ему поможет (видно, что задачу как-то можно решить с помощью библиотеки X, т.к. она делает что-то подобное)
  6. Программист B изучает все Xi и находит координаты Y в базисе X (изучает документацию, понимает философию библиотеки и пишет программу)


Слабые места в этом алгоритме –
  1. Необходимость изучения посторонней библиотеки при имеющихся знаниях синтаксиса языка, принципов работы того, на чём построена библиотека.
  2. Неспособность понять философии библиотеки и эффективно её использовать. Любой человек ограничен умом. Программист A с большой вероятностью может сделать неоптимальную библиотеку с неэффективным интерфейсом, программист B с большой вероятностью может не осознать всех принципов и взаимосвязей.


Мой любимый пример: для получения элемента списка нужно линейное время, для получения всех элементов списка нужно линейное время. Но если не нарушать абстракцию и пользоваться for ... get(i), выйдет квадратичное время. В этом заключается слабость реальных абстракций. Пока ты не понял, что внутри, у тебя могут возникнуть проблемы с их использованием. Но если тебе пришлось заглянуть внутрь, то это какая-то неполноценная абстракция.

Переформулировка задачи не нужна


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

Часто программист, когда сталкивается с чем-то новым, вообще не знает, что ему нужно. Он идёт как бы напролом и неправильно группирует свои действия. Как программист, он разделяет свою задачу Y на Y1 и Y2, т.е. находит некоторый свой базис исходя из имеющегося опыта (который не работает в случае в новой библиотекой X) и спрашивает на форуме. Ему задачу раскладывают по басису X и отвечают:
Y1 = a X1 + b X2 + c X3
Y2 = -a X1 - b X2 + d X3
Оказывается, что проблема решается стандартными средствами, и решить её как целое легче, чем неправильно разложить на подзадачи и решать уже их. Меньше разложений по базису и смен координат.

К сожалению, сообщество стимулирует бездумное поведение и имитацию бурной деятельности. Приходит человек на форум, спрашивает, как сделать Y. Ему говорят, что это элементарно, и надо просто погуглить. Или что вопрос слишком общий, нужен поконкретнее. Он гуглит, ничего не находит, разделяет задачу на подзадачи, спрашивает про подзадачи, ему отвечают по каждой в подробностях, потом интересуются, зачем это. Человек говорит "для Y" и ему тут же сообщают "Да так бы и сказал, это (c+d) X3!" В дальнейшем человек приспосабливается и задаёт совершенно бесполезные конкретные "умные" вопросы.

И вопрос "я хочу реализовать Y" превращается в "я хочу понять X". Заметим, что задача из описания заказчика уже перетекла в какое-то её понимание руководителем отдела разработчиков, сформулирована в письменном виде, как-то понята и смоделирована конкретным программистом, который уже готов исказить этот поток информации ещё несколько раз, выразив своё понимание на языке программирования, который он знает как свой родной язык, либо перевести свои идеи с языка программирования в метаязык библиотеки.

Аналогично с примером с форумами, здесь архитектор может сделать неудачную модель задачи заказчика (наклонить базис куда попало) а программист – неправильно выразить её в терминах ЯП (создать ещё одну систему координат под другим углом). В итоге решение задачи будет гораздо более сложным, чем если бы заказчик сам написал программу.

Это ненужное искажение информации, ненужные затраты по изучению чёрт знает чего.
Гораздо удобнее, когда знаток библиотеки X сам разложит твою задачу по её базису. Он сделает это по определению оптимальнее тебя, т.к. он уже осознал X, а также не будет совершать лишних действий по изучению X, т.к. он уже осознал X. Это банальная окупаемость. Если мне нужно один раз доехать к другу в гости, я вызываю такси за 500 рублей. Если мне нужно ездить к нему раз в день в течение двух лет, я покупаю велосипед за 10000 рублей.

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

Языки программирования не нужны


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

Заказчику нужно автоматизировать некоторую задачу. Ему не нужно, чтобы кто-то изучал библиотеку X и ЯП Z (это дорого и не всегда окупается), ему нужно автоматизировать свою задачу. Лишние прослойки вроде программиста, языков программирования, компьютеров и даже программ не нужны. Если бы заказчик мог купить решение задачи, он бы его уже купил и радовался, а не звал бы кого-то.

Проще метаинтерфейс – проще интерфейс


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

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

Тут ещё нужно вспомнить стремление человека к усложнению. Если людям дать волю, они придумают этикет, сарказм и годовые отчёты, чтобы заменить свободное общение на неповоротливую громоздкую машину намёков, домыслов и спецтерминов. Как минимум, разделение на "ты" и "вы" (имеющее более двух градаций в некоторых языках!) – только оверхед, который не обеспечивает никакой конкретики, вызывает обиды и засоряет память носителя языка.

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

Модульность для ограниченных или философия компиляции


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

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

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

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

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

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

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

Люди не смогли сразу выполнить свои задачи, поэтому разделили их реализацию:
  1. Пользователь формально описывает задачу
  2. Разработчик создаёт программу
  3. Пользователь общается с программой
  4. Программа выдаёт результат

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

В идеале можно вообще выкинуть все или некоторые этапы, ну или хотя бы пытаться их оптимизировать.

Планы на будущее


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

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

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

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

ноя. 20, 2016

04:24 pm - Когда примирение измерений?

Достал Воздушный белый и удивился. Масса шоклоадки - не 100г, не даже 90г а 85г. На первой стороне написано "74ккал", а сверху приписка "~14г" и "в 1/6 плитки".

ШТО? Откуда вы берёте эти цифры? Почему бы 100г не сделать? Кто вообще съедает 1/6, игнорируя остальные 5/6? Почему в 1/6, а не в 1/29? В будущем предлагаю взять конкатенацию SHA1 от слова "вечность", SHA1 от SHA1 от слова "вечность" и т.д., используя это как последовательность пятибитных чисел со значениями 1/3, 1/4, 1/5 ... 1/34 для более креативного представления энергетической ценности.

Кстати, такая ерунда с единицами измерения у нас везде. То калории вместо джоулей, то дюймы вместо сантиметров. Позорище какое, хоть святых выноси. Скорей бы уже ввели какую-нибудь единую интернациональную систему мер и весов, хотя бы французскую.

Маркетологу на заметку. Войны телевизоров в сантиметров более захватывающие. Вот у меня экран 60см, а у тебя вообще может все 120, а не какие-то жалкие 48 дюймов. И гораздо эффектнее, когда ты как производитель представил телевизор 121, когда у конкурентов только 120. Стараться при этом тебе надо на 1.54 сантиметра меньше, а сенсация та же!

ноя. 12, 2016

08:44 pm - О сайтах для показывания картинок

По-моему, Яндекс.фотки интереснее, чем Флицкр.

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

Остаётся вопрос только про EXIF: что у Яндекса, что на Флицкре хотелось бы видеть метаданные где-то рядом с картинкой. Скажем, справа, где у Яндекса располагаются менее полезные комментарии вроде "это шедевр" или "горизонт завален". У Флицкра метаданные показываются внизу, надо страницу для этого обязательно листать. Я пробовал открывать страничку на мониторе побольше и даже уменьшать масштаб, но злобный CSS говорит "нит, хочеш методанные - листай". А главное - Яндекс умеет искать, у Яндекса найдётся всё. С Яндексом я могу дать ссылку на фотографии пользователя X, которые он снял на фотоаппарат Y: fotki.yandex.ru/search.xml?text=Y&search_author=X. Яндекс - молодец.

На Флицкре можно искать автора, либо камеру, если флицкролюди добавили к ней описание (Olympus SP820UZ и Sony Alpha 3500ILCE там нет), а пересечение? Ну вот захочу я порекомендовать человеку фотоаппарат и показать результаты на примерах:
Шмель на цветке

И да, новости.



Дорогие мои, подписывайтесь да следите за жежешечкой.

ноя. 4, 2016

03:51 pm - Достойные оптимизации, недостойные тенденции

Достойные оптимизации


Вот за что я люблю фотоаппараты – так это за молниеносность в отображении фотографий. Крутишь колёсико – и на экране всё быстро-быстро меняется. Увеличиваешь – и оно увеличивается (например, Canon Powershot SX110IS мигом увеличивает девятимегапиксельные фотографии), подключаешь монитор через HDMI, если есть разъём, – и фотоаппарат выдаёт наверно кадров десять в секунду (например, Sony Alpha 6000 выдавал ещё больше, если б у человека были силы крутить колёсико быстрее). Смотришь на карту, а там только какие-то килобайтные файлики с метаданными лежат, и то для видео. И, выходит, эта штука за секунду спокойно справляется с десятью 1-9-мегабайтными зафурьированными монстрами, лежащими в разных файлах, выдаёт для каждого небольшое 300килопиксельное-двухмегапиксельное изображение на экран фотоаппарата или по HDMI на внешнее устройство.

Компьютерам должно быть стыдно. За 5-10 тысяч раньше можно было купить фотоаппарат с молниеносным отображением фотографий на экранчике. Работало ещё где-то десять лет назад. Сейчас можно купить за 15-50 тысяя фотоаппарат с молниеносным отображением фотографий на внешнем мониторе.
Где мне найти за те же деньги компьютер, который выдаст такие же результаты? А чтобы 300-500 граммов? А чтоб системный блок с клавиатурой помещались в карман? (см. рис. 1)

Canon Powershot SX110IS; Sony Alpha 6000-ILCE
Рисунок 1. Недорогие портативные машинки для быстрых фиксации и демонстрации изображений.

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

Недостойные тенденции


Сейчас вообще уже почти никто не думает о производительности. Совершенно нормально забабахать сайт, который вываливает вам здоровенные фотографии в просмотрщик, реализованный на каком-нибудь JS-плагине к jQuery с динамическим изменением CSS. Какие-нибудь $.fadeIn, $.fadeOut для анимации перехода заставляют браузер каждые несколько миллисекунд переоценивать применённые стили и рендерить кусок страницы заново. И всё это отображается на полупрозрачном фоне в блоке поверх страницы, где что-то само по себе крутится, мигает, подгружает и рендерит ещё несколько узлов DOM с обновлениями.

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

Берегите компактные аппараты


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

Ещё пару лет назад можно было купить отличнейший аппарат Canon Powershot SX150IS (или 140, или 160) за 4-7 тысяч. Удобный зум примерно 25-300 экв.мм, надёжность, аккумуляторы AA, стабилизатор и достойные фотографии, масса 300 граммов. Такого фотоаппарата хватает для большинства ситуаций, а если не хватает, есть CHDK.

А ведь сейчас разные клоуны понапокупали дорогущие херкальные аппараты и носятся с ними. Носить килограмм на шее? Кто-то всю жизнь об этом мечтает. Разумеется, никто не предупреждал о том, что
  1. цена растёт далеко не линейно в зависимости от площади матрицы,
  2. для получения результатов пропорционально затратам придётся поднапрячься где-то от корня до квадрата из затрат,
  3. 20Мп отличаются от 4Мп тем, что камеру придётся держать в 2 раза жёстче,
  4. весь процесс изменится серьёзным образом, начиная от того, что народ будет пялиться и в опасных районах уже не пройти, заканчивая размером сумки, громким шумом затвора и т.д.

Зачем, люди, зачем? Вы потом просматриваете это на заляпанном телефоне в шакальном качестве в мерзких социальных сетях. И? И всё.

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

Какая нелепость. Простой советский Иван телефончиком за 6 тысяч сделал картинку лучше, чем хипстер Эдуард фотоаппаратом за 100 тысяч. Затем Иван убрал свою "камеру" в карман и пошёл домой по ночным переулкам, пока Эдуард потирал уставшую шею и ждал такси, избегая тёмных улиц.

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

Производители одичали и решили подняться на любви пользователя к качеству. Теперь у нас почти не будет компактов за 5-10 тысяч, нам предлагают более громоздкие ультразумы за 15-30 тысяч или более тяжёлые беззеркалки за 20-100 тысяч. Есть ещё камеры с матрицей 1", которые стоят даже дороже камер с APS-C. Ну или можно сосать лапу со смартфоном за 10-30 тысяч, расставшись со стабилизацией, хватом, зумом и хоть какими-то ручными настройками. Но ведь как минимум приоритет выдержки нужен абсолютно всем, чтобы фотографировать свою кошку!
Итого, на замену компактам не вышло ничего аналогичного по фотографическим, физическим и финансовым характеристикам (см. рис. 1: небольшую беззеркалочку в каждый карман упрячешь). Всё плохо.

Аналогичное произошло с ультрабуками. Раньше можно было вместо зеркалки 15-дюймового рабочего ноутбука за 30-60 тысяч купить компакт нетбук за 7-15 тысяч. А сейчас вместо компактов нетбуков на прилавках только небольшие беззеркалки ультрабуки за 30-50 тысяч. А злые языки тоже говорили, что ультрабуки заменят смартфоны и планшеты. Отлично, просто отлично, ещё бы к ним полноценную клавиатуру, которую можно отвязать от зарядного устройства да ОС на выбор.

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

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

окт. 31, 2016

01:07 am - Бесконечная лента и реальный мир

2016 год. Закон Мура мы уже обогнали, а мышление ещё совсем детское, наивное и непорочное. Если 640кб достаточны для всех, то почему бы не сделать бесконечную прокрутку, когда у тебя гигабайты памяти?

Непомерно популярный сайт ВК как бы намекает "не трать на меня время, не читай мои ленты, 100 постов тебе хватит, а потом я повешу твой планшет".



Ещё в 2012 году, когда бесконечные ленты только начинали долбиться железными кулаками в наш увядший более не экспоненциальный дом, нормальные люди озаботились проблемами производительности: https://dannysu.com/2012/07/07/infinite-scroll-memory-optimization/

Короче, суть такова. Бесконечности достичь нельзя. Любая конечная память в любом случае заполнится. DOM-элемент с контентом к тому же ещё имеет метаданные и занимает гораздо больше, чем его JSON-представление, а также браузер должен перерисовывать его и вычислять высоту. Если делаешь бесконечную ленту, убедись, что в DOM находится постоянное ограниченное количество элементов, а в памяти - постоянное ограниченное количество подгруженных данных.

То есть

Navigate: (Previous 10 Entries | Next 10 Entries)