Pull to refresh
67
0
Николай Петроченко @nik_vr

User

Send message
Такая картина бывает, если включены блокировщики рекламы типа AdGuard.
API тоже иногда меняется :) Хотя legacy-кода там могло бы быть и поменьше. Насчёт прожорливости учту — чаще всего WordPress для клиентов приходится переносить на виртуальный сервер, с лимитом времени на скрипты бывают проблемы.
Немного смущает, что этот плагин уже полтора года не обновлялся. В какой-то момент он может начать некорректно отрабатывать на новых версиях WordPress. Но в целом относительные пути — это отличная вещь.
И не только в визуальный. Я plaintext-редактор использую — штатный загрузчик изображений и туда вставляет полные пути. Вот прямо сейчас проверил на свежем WordPress 4.1 — ничего не поменялось. В принципе, можно каждый раз ручками править, но оно кому-то надо? Не так уж часто с домена на домен приходится переносить.
Ссылки, которые хранит сам WordPress у меня за 6 лет ни разу не было проблем (в плане замены). Не один десяток сайтов так перенёс. Возможно, могут быть проблемы с плагинами, которые хранят ссылки как-то нестандартно.
Что касается сериализованных данных, то не вижу особых проблем — если всё делать аккуратно, ссылки в «наборах» прекрасно заменяются.
Но за ссылку на утилиту — спасибо, интересная штука, надо будет попробовать.
Буквально с месяц назад переносил сайт на WordPress 4.0 с локалхоста на сервер — ссылки на изображения в постах прямые были.
При переносе с localhost'а на реальный сервер нельзя забывать про адрес сайта. Смена домена с одновременным переносом по вашей инструкции сделает сайт абсолютно неработоспособным. По-этому в инструкцию стоит добавить ещё один шаг (актуальный при смене домена, в т.ч. — при переносе с локального сервера на боевой). Для примера будем считать, что сайд переносится с домена mysite.local на домен mysite.ru.

В сохранённом дампе базы данных WordPress ищем все вхождения mysite.local и заменяем на mysite.ru. Можно это сделать в любом нормальном текстовом редакторе (например, Notepad++). После замены аккуратно сохраняем БД, не забывая о кодировке (в случае с более или менее современными версиями WordPress нужна кодировка UTF-8 без BOM).
Фанатская локализация игр на профессиональном уровне — возможно ли это?

На этот вопрос много-много лет назад ответили ребята из СПК, сделавшие пиратскую гениальную локализацию WarCraft 2.
Извилистый путь: снимаешь вирусный ролик, выкладываешь на Youtube, он попадает на ТВ… Profit!
Если говорить о клавиатурах с переменной раскладкой, то стоит упомянуть ещё лебедевский «Оптимус». Идея, в целом, интересная — по дисплею в каждой кнопке.
Уже не помню, как там в Delphi, а в Lazarus со вводом даты проблем вообще нет — есть отличный компонент TZVDateTimePicker, который при ручном вводе всё лишнее фильтрует (ну и выбрать из календаря позволяет, да). Разделитель при этом используется системный. Дальше — дело техники: в базу пишем значение даты, преобразованное в UnixTime, а при выводе — преобразуем обратно (при таком раскладе о разделителе можно сильно не беспокоиться).
Всё зависит, опять-таки, от данных. Вернёмся к исходной теме поста. Скажем зачем забивать пользователю голову такой ненужной информацией, как тип десятичного разделителя? С точки зрения пользователя важно ввести данные (быстро и правильно). Если мы заставим его думать над тем, запятую ему вводить, или точку — он будет отвлекаться от основной работы.
Другое дело, когда данные вводятся в достаточно свободной форме — тогда имеет смысл сообщать об ошибке (по возможности — не модально).
Excel — это вообще отдельная тема, в силу своей универсальности он позволяет очень многое, перекладывая ответственность на пользователя. Там и не может быть никакой фильтрации (хотя из-за этого тоже свои заморочки).

Но мы же говорим о разработке собственного ПО, а здесь именно на нас, как на разработчиков, ложится ответственность за удобство работы. Разумеется, всегда нужно исходить из конкретной задачи. В конце концов, это программа должна быть инструментом (удобным!) в руках пользователя, а не пользователь — инструментом (сам-себе-валидатором) в руках программы.

Даже если взять АРМ, которым пользуются в небольшой конторе, допустим, 8 человек. Допустим, сейчас это 8 опытных сотрудников, которые хорошо знают, что и куда вводить в формах — их можно строго не ограничивать. А если завтра на их место придут новые сотрудники, плохо знакомые с устоявшимися принципами ввода данных? Вот чтобы они дров не наломали, нужно внимательно следить за вводом, ограничивая возможность ввода некорректных данных.
Преобразование в число — это само собой. Но тут тоже есть подводный камень. (всё дальнейшее рассуждение относится прежде всего к desktop-приложениям, в частности к написанным в Delphi-подобных IDE) Если, допустим, мы не фильтруем ввод, а валидацию проводим при отправке формы, то высока вероятность при попытке преобразования получить системное исключение. Понятно, что его не проблема отловить и обработать. Но при этом нам придётся вывести пользователю сообщение об ошибке. А это, в свою очередь, выбивает пользователя из «потока», отвлекая его от основной задачи — ввода данных.

PS. На эту тему (информирование пользователя об ошибках ввода) очень хорошо написано у Купера в «About Face» — рекомендую к прочтению всем, кто проектирует интерфейсы.
По поводу копипаста ответил чуть выше.

Что касается опасности, то тут как минимум два нюанса. Во-первых, чем «свободнее» ввод, тем строже должна быть валидация. Это само по себе не проблема. Во-вторых, при копировании вероятность ошибки оператора в ряде ситуаций повышается (в сравнении с ручным вводом). К примеру, оператор копирует в поле ввода число 11127634,44 — если оператор случайно не выделит первую или последнюю цифры при копировании, то шанс, что он заметит ошибку ниже, чем если бы он вбивал числа вручную, глядя из окна в окно.

PS. Повторюсь, всё зависит от конкретного случая, где-то копипаст необходим, но не везде.
Имхо, многое зависит от конкретного случая. Например, есть АРМ, где оператор вводит финансовые значения в диапазоне примерно от 10 до 2000. Значения вводятся «с листа», т.е. всегда с бумажного носителя. Нужен там копипаст? Нет.
В других случаях, да, без копипаста не обойтись, но, как я уже сказал, тогда нужна строгая валидация и зачистка.
Я в таких полях (не текстовых) обычно блокирую вставку из буфера. Но в принципе, можно отлавливать вставку из буфера и чистить приходящее значение. Как бы в любом случае при отправке поля в SQL-запрос надо следить за содержимым, а вставленное из буфера содержимое потенциально, имхо, более опасно, чем ввёдённое с клавиатуры (поскольку может содержать чёрте что).
Такой вариант тоже возможен. Единственный нюанс — если введённые данные дальше попадают в SQL-запрос, то при отправке формы запятую придётся либо заменить, либо экранировать.
Кстати, в случае с ноутбуком быстрый ввод десятичного разделителя представляет собой ещё большую проблему — встречал модели, у которых клавиша "?/.," была сдвинута.
Ну и нумпады есть далеко не у всех моделей, да.
Я с ходу не смог вспомнить ни одного приложения, где бы мне приходилось вручную вводить разделители разрядов. Но в целом, согласен — такой случай мой алгоритм не обработает. Можно попытаться его адаптировать, но, как минимум, нужно проверять системные настройки (разделители) и уже от них плясать.

Information

Rating
5,440-th
Location
Слободской, Кировская обл., Россия
Date of birth
Registered
Activity