Михаил

Так у того же Spotify API есть. https://developer.spotify.com/documentation/web-api/

Странный дизайн и странный верстальщик. У того же Bootstrap максимальная ширина контейнера для XXL размера - 1320 пикселей. То есть на типичном сегодня FullHD (1920х1080) он занимает центральную часть экрана, оставляя поля слева-справа. Аналогично здесь, на тостере - содержимое ограничено шириной 1440 пикселей.

Тут в общем-то главный вопрос: а как договаривались с верстальщиком? Была ли в требованиях к нему адаптивная верстка? Обсуждался ли этот вопрос вообще? Потому что если ему дали макет и сказали: "вот, делай как на макете" - верстальщик и сделал исходя из того что заказчик знает чего хочет.

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

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

Ну а если все-таки очень хочется - то см. ответы которые написали выше.

Зависит от требований к апгрейду.

Проц - можно было бы поменять на Core i7 2700 (Sandy Bridge) или Core i7 3770 (Ivy Bridge), если материнка поддерживает Ivy Bridge (теоретически должна, практически - смотреть надо). Но это все равно достаточно старые процессоры, которые сейчас можно найти только с рук.

Память - можно добавить до 8-16 Гб. Но опять же - это DDR3. По современным меркам - деньги на выброс, потом все равно покупать DDR4 или DDR5.

Как уже сказали добавить SSD - даст свой вклад в рост производительности. Но тут нужно смотреть на возможности материнки - есть ли там SATA (M2 скорее всего нет), какой версии. Возможно придется ставить SSD в PCIe, а это, вероятнее всего, не позволит сделать его загрузочным.

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

То есть, если стоит вопрос бюджетного апгрейда - можно докупить DDR3 память, SSD, и поискать i7 процессор - продлить жизнь этому железу получится. Для программирования, положим, вполне годная машинка выйдет. Для игр - увы. Впрочем, с играми там и сейчас все чуть менее чем никак.

Либо собирать новый комп с нуля (оставить старый HDD как вариант). В этом случае я бы предложил смотреть в сторону Ryzen 5000 с мощной встройкой (чтобы не брать дискретную видеокарту, ибо невменяемо дорого).

DayOfWeek.values()[index]

Когда вы пишете

LEFT JOIN Accessories on 
  Orders.AccessorieCode1 = Accessories.AccessorieCode 
  and Orders.AccessorieCode2 = Accessories.AccessorieCode 
  and Orders.AccessorieCode3 = Accessories.AccessorieCode

Вы требуете от СУБД "найди в таблице Accessories записи у которых AsseccorieCode совпадает с Orders.AccessorieCode1 и Orders.AccessorieCode2 и Orders.AccessorieCode3, а если не найдешь - то впиши NULL-ы". Вы действительно хотели сказать что поля Orders.AccessorieCode{1,2,3} должны иметь одно и тоже значение, равное Accessories.AccessorieCode? Я так подозреваю, что в БД нет строк, удовлетворяющих этому условию, вот вы и получаете пустые строки.

Как решить: подумать еще раз что вы хотите иметь в выборке. Я так подозреваю, там должно быть OR. Accessories.AccessorieCode = Orders.AccessorieCode1 или Orders.AccessorieCode2 или Orders.AccessorieCode3

С Services аналогично.

gazes12, если ничего не путаю, в CSS нельзя задавать правила для селектора в зависимости от состояния дочерних элементов. Похоже вы хотите что-то вроде псевдокласса :has, но он пока не поддерживается браузерами.

Зависит от того какая в обработчиках исключений выполняется логика. Если там просто логирование исключений, никак не связанное с логикой консьюмера - то вполне оправданно эту логику отделить. Но можно и не отделять. Тут все зависит от желания переиспользовать консьюмер и декоратор. Также оправданно отделять подобные независимые вещи для облегчения юнит-тестирования.

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

curl_init("https://$ip")
или даже
curl_init("https://$host")

Spring Boot решает вашу проблему чуть более чем полностью.
Открываете Spring initializr, отмечаете нужные фичи, получаете заготовку готового приложения, которое можно запустить локально или даже развернуть на сервере, если понадобится.

И собственно в этом шаблоне дописываете любые нужные вам фичи.

Эспортируете данные в SQL (см. mysqldump, pg_dump). На целевой системе - загружаете полученный SQL.

А где эта переменная объявлена? Я в коде вижу упоминание об $users_email в одном единственном месте. Как компьютер должен понимать какое значение переменной он должен использовать?

https://stackoverflow.com/questions/3898130/check-...

Если нужно без jQuery, на чистом JS, то аналогично:

1. Зацепиться на событие window.onScroll
   
2. Проверять значения свойств window.scrollY, window.innerHeight, document.body.clientHeight
   

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

Вашу задачу можно решить, например, вот так:

import java.util.Arrays;

public class Main {

    public static void main(String[] args) {
        Arrays.stream(args).map(Main::reverse).forEach(System.out::println);
    }

    private static String reverse(String s) {
        final StringBuilder result = new StringBuilder();
        for (char c : s.toCharArray()) {
            result.insert(0, c);
        }

        return result.toString();
    }
}

Тут интерфейс используется неявно (в функции map), туда подставлена другая функция - reverse. Если хочется - можно обернуть её в интерфейс.

Гарантировать ACID возможно только с ограничениями. В данном случае, то о чем вы говорите, называется "жертвой устойчивости к распаду на секции (то есть сбоя в системе коммуникации между узлами)". См. теорема CAP