Страницы

Поиск по вопросам

пятница, 7 июня 2019 г.

Дробные пиксели

Я всегда считал, что значения в px могут быть только целыми числами. Но недавно, отлавливая ошибку в Internet Explorer 10 обнаружил в панели разработчика следующее:

Дробные значения в пикселях везде.
При этом в GWT метод getClientWidth/Height() возвращает только целые значения. Как сделать совместимость с IE10? У меня во многих местах нужно один абсолютно позиционированный элемент отображать ровно над другим, а в IE10 он "дергается" (смещение менее, чем на 1 px).
И еще такой вопрос: а остальные величины (offset, padding, margin, coordinates) могут быть дробными в px?


Ответ

Дробное значение быть может, но это, скорее "неумность" разработчиков, или же "неумность" браузера при высчитывании ширины/высоты определенного DOM-элемента, установленного в дробное значение в процентах, например:

Браузер в таком случае производит простейшие математические действия для преобразования процентного соотношения в пиксельное без последующего преобразования результата в целое число(из дробного). А вообще, дробное значения пикселя - это, конечно же, абсурд. Нельзя "закрасить" половину пикселя или же его треть. Должно быть понятно, что 123.86px == 124px

Обсуждение примера частного наследования из книги

Вомозжно, если кто-то из Вас читал книгу Прата "C++ Primer Plus", и отвечал на вопросы в конце главы, сталкивался со следующим примером: For each of the following sets of classes, indicate whether public or private derivation is more appropriate for Column B: A B class Bear class PolarBear class Kitchen class Home class Person class Programmer class Person class HorseAndJockey class Person, class Automobile class Driver Ответы, на этот квиз, из книги, таковые: class Bear, class PolarBear public class Kitchen class Home private class Person class Programmer public class Person class HorseAndJockey private class Person, class Automobile class Driver public for Person, private for Driver Я в принципе то согласен, но вот есть парочка вопросов. Поскольку частное наследование делает все публичные методы (интерфейс) базового класса закрытой областью в классе наследнике (т.е. можно юзать внутри класса, но нельзя вызывать снаружи), возникает парочка вопросов. К примеру, в классах Kitchen и Home, так уж ли подходит здесь частное наследование? Не спорю, отношения между этими двумя классами больше попадает под парадигму отношений has-a, нежели is-a, но все-таки. Что, если я создам, к примеру, экземпляр класса Home и захочу запустить тостер, который находится на кухне? Или посудомоечную машину? Писать для этого новые методы в Home, которые просто будут реализовывать интерфейс кухни (вызывать ее методы)? Как-то не очень удобно. Или, скажем, HorseAndJockey. Все-таки, Жокей, он как ни крути, а должен иметь в своем интерфейсе методы Личности, так или нет? Ну и с последним примером так же. Что, для водителя нельзя вызывать методы Person напрямую? И почему Автомобилем я не могу управлять напрямую вызывая методы Automobile из Driver? Ну как-то так.


Ответ

У вас возникли правильные вопросы - в этом части C++ Primer, к сожалению, пропускает два фундаментальных момента, которые очень важны с практической точки зрения:
Favor composition over inheritance. Приватное наследование в C++ стоит использовать только для выражения отношения is-implemented-in-terms-of (Effective C++, Issue 42), что на практике встречается достаточно редко.
Насчет примеров - если вы правильно ответили на вопросы [1], [3] и про class Driver : public Person в вопросе [5], то можете считать, что с упражнением вы справились.
Остальные случаи действительно попадают под отношение has-a и их стоит моделировать с помощью композиции - так, кухня является частью дома, водитель может быть частью абстракции "автомобиль" (или наоборот, смотря как подходить к данной ситуации) HorseAndJockey vs Person - это не самый лучший пример, поскольку автором вводится некоторая сущность Jockey, которая может никак не соответствовать классу Person

Приложения баз данных. Паттерны проектирования.

Здравствуйте! Есть небольшая база данных, допустим, библиотеки. Какие паттерны проектирования стоило бы использовать? Какие правила стоит учитывать при проектировании базы данных и самого приложения? Стоит ли использовать паттерн MVP и какая выгода будет от этого? Заранее спасибо.


Ответ

Как сказали в уточнениях, паттерн MVP действительно не имеет отношение к БД. Он скорее имеет отношение к интерфейсной части (client-side). Я бы сказал, что самое главное правило, которого стоит придерживаться при разработке приложений, которые обращаются к БД, это трехслойная архитектура: UI - Business Logic - DB. В самом тупом случае, слой DB у вас может представлять собой набор хелперов для работы с БД. В частности, отмечу некоторые важные моменты: все прямые обращения к БД должны быть только в слое DB, никаких прямых вызовов к БД, разбросанных по всему коду все обращения к слою DB должны исходить только из слоя BL, в UI не должно быть прямых вызовов кода из слоя DB В остальном, реально не имеет значения (особенно в небольшом проекте), как у вас будет организовано получение и сохранение данных: тупые датасеты, ORM или что-то еще. Существует несколько распространенных паттернов для работы с данными, однако их применение также не очень критично (и уж точно не стоит применять их ради самого факта применения, о чем говорили выше). Главное — обособить код для работы с базой, это уже избавит вас от множества проблем. Ниже список некоторых паттернов для работы с БД: http://design-pattern.ru/patterns/repository.html http://ru.wikipedia.org/wiki/Data_Access_Object http://design-pattern.ru/patterns/table-data-gateway.html http://design-pattern.ru/patterns/row-data-gateway.html http://design-pattern.ru/patterns/active-record.html -- тут я готов спорить, предпочитаю иметь тупые объекты (DTO, только данные) плюс классы, которые отвечают за загрузку/сохранение http://design-pattern.ru/patterns/data-mapper.html

Перемещаемая форма со скрытыми границами

Возможно ли сделать так, чтобы форму можно было перемещать мышкой за ее главное окно, даже если у нее скрыты границы? p.s. + еще ко всему этому чтобы она Resizable была так же.


Ответ

Конечно такое возможно. Один из вариантов - послать окну сообщение WM_NCLBUTTONDOWN на нажатие мыши, которое сигнализирует о нажатии левой клавиши мыши вне клиентской части окна, то есть на скрытых границах. Однако, перед этим действием необходимо снять "захват" курсора окном, иначе сообщение будет просто проигнорировано.
private const int WM_NCLBUTTONDOWN = 0xA1; private const int HTCAPTION = 0x2;
protected override void OnMouseDown(MouseEventArgs e) { Cursor = Cursors.Hold; Capture = false; Message msg = Message.Create(Handle, WM_NCLBUTTONDOWN, (IntPtr)HTCAPTION, IntPtr.Zero); DefWndProc(ref msg); Cursor = Cursors.Default; }

С ресайзингом придётся повозится дольше, тем более если его делать на этой же самой форме. Как вариант - сначала сделать ресайз только за правый нижний угол. Придётся переопределить оконную процедуру Form.WndProc и самому обработать сообщение WM_NCHITTEST. Кстати, первую проблему можно тоже решить в этом месте. Более подробно смотрите здесь

Как описать граф, где важны только рёбра?

Планирую проект, где будет множество данных о связях между очередными двумя узлами, и эти связи и их многочисленные свойства — главная информация, с которой вся работа. Можно сказать, что есть граф, у которого узлы лишь идентифицируются как-то, чтобы не перепутать, а область интереса это рёбра. Как бы вы стали описывать и хранить такие данные? Варианты, которые пока приходят на ум: реляционная БД, таблица нод, таблица связей: node1id, node2id, json_properties какая-то специфическая, может, не реляционная бд, заточенная под описание графов? Задачи: хранить, добавлять новые связи, определять, связаны ли две ноды через цепочку связей?


Ответ

Если я правильно понял задачу, то, как вариант - neo4j, статья на хабре

SEO при редизайне

Что нужно учитывать при редизайне сайта, чтобы не потерять индексацию поисковиками?


Ответ

SEO Website Redesign Checklist: Don’t Mess Up Your Site Traffic 6 Website Redesign SEO Secrets Your Developer May Not Know 3 SEO Traps to Avoid During Your Redesign

Программирование в IDE на широкоформатном мониторе?

Хочу заказать широкоформатный монитор диагональю дюймов в 29, с каждым днем маленькое окошко текстового редактора в IDE раздражает меня все больше и больше. У кого нибудь был подобный опыт? Какие подводные камни? Как следует правильно выбирать монитор, чтобы на него можно было по долгу смотреть?


Ответ

У меня 2 монитора по 22". Очень удобно, пространства хоть отбавляй. В Visual Studio я раздвигаю окно на 2 монитора, делаю сплит рабочих областей. Немного не удобно в том плане, что иногда приходится переводить взгляд с одной области на другую, но это совсем пустяк по сравнению с реальным комфортом. Насчет большого монитора на 29" я не советовал бы, потому что разрешение экрана также останется 1920х1080 (если он конечно не особенный хD), а впервую очередь для меня важно количество точек, а не "здоровый" монитор. Плюс к этому можно наладить дебаг мультимониторных приложений (если такая необходимость имеется). К тому же по цене 2 монитора по 22" будут сравнимы, а если уже монитор имеется, то выгода очевидна. Знаю только, что 29" нужны дизайнерам, которые постоянно вглядываются в мелочи. Плюс я купил новый монитор с IPS, старый с TN-Film -- разницы практически никакой. Все может быть сугубо индивидуально, но я поступил так и ничуть не жалею.