По дефолту в теме breeze тень смещена вправо-вниз. Кто нибудь знает как сделать ее по центру?

Добрый день. Посоветуйте МиниПК или неттоп из Китая x86_64 с UEFI. Нужно пассивное охлаждение, и что бы можно было без гемора поставить debian. А то сейчас куча ПК, перед которыми нужно танцевать с бубном, что бы поставить что то отличное от Android или Windows 10, а не хочется. Что бы работал Wi-fi и прочее.

Почему все книги учат, что нужно отделять гуй, usecase, бизнес сущности и т.д.

- Зачем я должен отделять sql код от бизнес сущности если, исходя из требований, никогда не будет меняться метод сохранения в бд? Почему я должен вносить не оправданную сложность?

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

Сам я так не делаю, но и объяснения «почему бы и нет» я найти не могу. Другое дело, когда мы заранее видим вектор изменений и готовим нашу архитектуру к будущим изменениям. Но если, например, у меня Android проект, и там для сохранения в базу я могу юзать только sqlite, зачем придумывать какие-то абстракции и усложнять себе жизнь? Например, я вижу только один кейс, зачем я должен придумать абстракцию в виде DAL для SQL кода. Просто что бы это все гуано лежало в одном месте ))). Но если удобно и без DAL, но зачем его писать.

У кого какие мысли по-этому поводу? Как вы делаете на работе или в своих проектах? Интересует мнение опытных разработчиков, прошедших все эти сложности. Сам я работаю еще только 6 лет. Единственное почему я придерживаюсь архитектур из книжек, это потому, что вроде как так принято что-ли. Даже Фаулер пишет о том, что не везде нужно запиливать какую-то мощную архитектуру, но тем не менее сам так делает. Странно.

Кому не лень поделитесь пожалуйста своим алгоритмом анализа предметной области. Особенно если нужно бизнес логику переплетать со сложным пользовательским интерфейсом и REST API. Короче как делать крутые архитектурные решения. Куча мастхев книг не помогают.

Вопрос тем, кто в теме. Как состыковать эти две весчицы. Сейчас у меня работает PBR + IBL. Строится это в ГБуффере и записывается в карту цвета, diffuse + specular. Как мне потом добавлять источники освещения? Тупо добавлением?

Gimp ужасно искажает Psd макеты. Несмотря на то, что все слои присутствуют, т.е. формат вроде как парсит, цвета и градиенты искажаются. Например вместо бледно-зеленого градиента я получаю тупо темно-зеленый цвет. Вместо голубого розовый, и прочие косяки. Кто-нибудь знает, как нормально юзать psd в gimp. Или может есть тулза какая для просмотра psd файлов. Буду очень благодарен за ответ.

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

Есть класс книги.
Вот варианты использования:

• Можно получить контент книги для прочтения ее.
• При редактировании контента, книга сохраняется в БД.
• Книгу можно получить только по заранее известному id (неважно откуда юзер узнает)
• Можно распечатать на принтере. Любую книгу можно печатать.

Что заранее известно:
Никогда в жизни не будет нескольких хранилищ книг, и оно никогда не изменится.
Вот код:

class Book {
    private int id;
    private String content;
    private Database database;
    private Printer printer;

    public Book(int id) {
        database = new Database("table-books");
        printer = new Printer();
        this.content = database.select(id);
    }

    public String getContent() {
        return this.content;
    }
    
    public void setContent(String content) {
        this.content = content;
        save();
    }

    public void print() {
        // предположим, что тут сложная логика из 15 строк для работы с принтером. Но больше ни один класс печататься не умеет
        printer.selectPrinterAndPrint(getContent());
    }

    public void save() {
        // предположим тут сложная логика сохранения в бд, но больше ни один класс не сохраняется
        database.updateOrInsert(id, getContent());
    }
}

Но как гласит принцип, у класса должна быть только одна причина для изменения.
Получается, что любой чувак из интернетов, кто пишет умные статьи, меня с таким кодом пошлет куда подальше.
Какого черта мне здесь создавать отдельные классы Storage и PrintingSystem ради инкапсуляции логики туда? Если никто больше юзать не собирается их. Какого класс, который юзает Book я должен еще утяжелить знаниями о Storage и PrintingSystem?
Мне кажется, что все эти принципы должны учить только одному - здравому смыслу.

Перемещено leave из talks

Посмотрите, возможно будет полезно кому нибудь. http://crossad.ru/

Кратко:

Все Ваши записи в одном аккаунте. CrossAd делает управление записями в проектах максимально простым.

CrossAd - это сервис для удобного управления Вашими записями на своих сайтах или приложениях.

Однажды использовав сервис в своем приложении, Вы в любой момент можете изменять записи.

Ежемесячная подписка на сервисе стоит почти столько же, сколько стоит проезд на работу и обратно на общественном транспорте за один день.

Перекрестная реклама

Предположим у Вас есть 20 приложений, в которых вы «зашили» информацию о других своих приложениях. Теперь Вы создаете еще одно приложение.Вам нужно испраить все 20 приложений и выкатить изменения например на Google Play. Это очень долго. В конце концов Вы просто передумаете делать рекламу в своих приложениях. Но если внедрить во все свои приложения данный сервис, то можно централизовано управлять записями. Вам нужно будет просто поставить флажок в панели управления, что бы отобразить новую запись во всех своих 20 приложениях.

Продукты

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

Страницы

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

Что угодно

С помощью нашего сервиса можно реализовать много задач. Если представить, что можно по сети передавать целые объекты в виде JSON, то можно организовать практически что угодно. Самая главная выгода - это централизованное управление контентом.

Год назад появилась новость о том, что «Мелкомягкие», открыли исходники своего продукта, ну или часть его. Что-то изменилось в лучшую сторону с тех пор? Кто нибудь в курсе?

Поставил на Арче новую плазму. Решил посмотреть. Ужаснейшие тормоза. К примеру открыл Konsole, свернул в панель задач. Нажал развернуть. Прошло 2 секунды - развернулось. И так абсолютно всё. Ставил на чистый Арч. pacman -S plasma kde-applications. Комп: Intel(R) Core(TM) i3-3210 CPU @ 3.20GHz RAM 8GB SSD 64GB NVidia GT240 (дрова nvidia, nouveau зависает вообще)

Любые другие DE на GTK2/3 работают очеть шустро - моментально.

Как поменять ширину кнопок на таск баре? Всю жизнь свою линуксовую сидел на GTK-шных DE, решил поиграться с плазмой, а тут такая беда.

Есть 4G модем, спидтест говорит, что скорость 17 мбит, на удаленные хосты скорость в пределах 15, и пинг 35. Теоретически скорость скачивания файла должна быть в районе 2мб/сек. Но качает файлы с репов арча 100 кб/с. Да и вообще с других сайтов или торрента тоже маленькая скорость. А вот FullHD фильмы онлайн тянет. Кто нибудь знает почему так может быть? P.S. модем раздает по wi-fi.

Кто нибудь в курсе какие книги в этом году выходили? По современным методикам разработки.

Ребята, подскажите. Почему нельзя просто подменить rootfs от другой версии Android, сохранив при этом ядро. Все дрова для устройств в ядре. Почему возникают какие-то проблемы?

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

public class ApiAttachment {
    public String url;
    public String small_url;
    public int type;

    public void setSmallImageToView(ImageView imageView) {
        String host = imageView.getContext().getString(R.string.host_address);
        new ImageLoaderTask(host, imageView, small_url).execute();
    }
}

Допустим есть:

class Document {
    public void dump() { ....... }
    public void print() { ....... }
}

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

Проблема такая. В принтере бумаги небыло, отправил задание на печать. Бумагу вставил, принтер ее нашел, но вот cups думает, что бумаги все еще нет. Система Arch.

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

Так:

class Book {
    private String name;
    private String text;

    public void store(Place place) {
        place.store(name, text);
    }
}

interface Place {
    void store(String name, String text);
}

class Library implements Place {
    @Override
    public void store(String name, String text) {
        // запись в БД
    }
}

// кто-то вызывает
book.store(place);

Или так:

class Book {
    private String name;
    private String text;

    public String getName() {
        return name;
    }

    public String getText() {
        return text;
    }
}

class Library {
    public void store(String name, String text) {
        // запись в БД
    }
}

// кто-то вызывает
library.store(book.getName(), book.getText());

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

И вообще, как вы подходите к проектированию системы, когда получаете ТЗ?