Знают, куда надавить! Мой 4XL меня полностью устраивает по абсолютно всем параметрам (и будет ещё устраивать года 2-3), но вот 7 лет гарантированных новых версий андроид это весомый аргумент
Видимо в скором будущем для авторизации пользователя наушники будут использовать что-то типа эхолокации - проверять картину отражённого сигнала на разных частотах.
Заработок - это дать корпоративу творить любую дичь
Какое-то однобокое восприятие проблемы.
Бизнес должен приносить прибыль, а заработок - это ещё и наличие работы для целой команды.
Я не говорю, что за деньги можно разрешить всё что угодно, а про то, что в текущей системе монетизации проекта не стоит воспринимать команду ресурса как людей, который продались корпоративным блогам ради долларов долларов долларов
У вас случайно нет инсайдов из индустрии на тему можно ли ждать кооперации производителей принтеров и сканеров и наконец- то придти к какому-то нормальному безглючному стандарту?
Вот есть функция. У неё есть аргументы. Есть код, который вызывает это функцию и передаёт какие-то переменные.
Вопрос - а что по факту передаётся в функцию?
Ответ - по факту это всегда некий адрес в памяти. Массив, int, объект, и т.д. - это всё просто некий адрес в памяти, а дальше уже компилятор разруливает как вызвать метод объекта по этому адресу памяти или как трактовать это как элемент массива.
На заре программирования думали-думали и решили сделать два способа передачи параметров (забавный факт - в компуктерах PDP-11 было аж 42 способа адресовать аргумент) :
1) По ссылке - когда функция получает ровно тот же адрес переменной, который был когда вызвали функцию. В данном случае компилятор просто копирует адрес переменной.
2) По значению - когда функция получает совершенной другой адрес переменной при вызове. В данном случае компилятор выполняет полное копирование переменной.
После это стали думать ещё. А вдруг аргумент функции не изменяется, а мы передаём его по значению. Если это огромный массив - то мы зря делаем полную копию массива.
Пришла гениальная идея - а давайте не будем делать полную копию, вместо этого передадим по факту по ссылке, дождёмся пока код решит что-то записать в эту переменную, и только тогда сделаем полную копию (ну и подвиснем ещё на некоторое время). В итоге компилятор вставляет дополнительный код чтобы разруливать такие сценарии.
Итого: передача аргумента (в более широком смысле - адресация переменных) и стратегия cope-on-write разные вещи, но существуют в одном контексте. Поэтому их часто употребляют как взаимозаменямо. Но их гораздо больше!
ОДИНАКОВЫЕ!!!! Не разные!!! Буква в букву! Если в базе у вас в таблице user есть поле userName, то в энтити user у вас должно быть userName, и в userDto у вас должно быть поле userName.
Поддерживаю, нет ничего сложного в накате миграции для изменения схемы. В крайнем случае, если нет механизма автонаката, можно руками быстро на проде выполнить - по моему опыту даже если у юзеров какие-то реквесты упадут, то ничего страшного, просто выполнят ещё раз.
2. 20 строк в методе, 200 строк в классе
Я бы ещё убрал тупое правило каждый класс в отдельном файле.
Автор правильно пишет про преждевременную оптимизацию и маленькие классы. Если у меня простенький контроллер на 1 экшен, DTO из двух полей и простой CRUD то всё это лучше положить в одном файле User, чем городить UserController, UserDto, etc.
В идеале так вообще один класс, который имплементит все нужные интерфейсы и содержит всю реализацию в себе.
Когда логика усложнится, можно и тесты добавить, и подумать над разделением.
Падает генерация электричества. Симуляция нужна для эмоций, т.е. стимуляции активности мозга.
Знают, куда надавить! Мой 4XL меня полностью устраивает по абсолютно всем параметрам (и будет ещё устраивать года 2-3), но вот 7 лет гарантированных новых версий андроид это весомый аргумент
Смотря что имелось ввиду под "полноценным аналогом". Может количество контента, а может и просто дизайн / скорость работы / удобство использования
Писали бы сразу "в 30-50", чего утаивать правду-то
Недавно доказали, что чётность символа "бесконечность" равна чётности "числа i"
Видимо в скором будущем для авторизации пользователя наушники будут использовать что-то типа эхолокации - проверять картину отражённого сигнала на разных частотах.
Какое-то однобокое восприятие проблемы.
Бизнес должен приносить прибыль, а заработок - это ещё и наличие работы для целой команды.
Я не говорю, что за деньги можно разрешить всё что угодно, а про то, что в текущей системе монетизации проекта не стоит воспринимать команду ресурса как людей, который продались корпоративным блогам ради долларов долларов долларов
Я спрашивал в поддержке, ответили так нельзя.
Опишите этот долгий процесс?
У вас случайно нет инсайдов из индустрии на тему можно ли ждать кооперации производителей принтеров и сканеров и наконец- то придти к какому-то нормальному безглючному стандарту?
Было бы интересно узнать сколько подписок в среднем требуется и какая их стоимость?
Какова себестоимость печати с доставкой при удачном тираже?
кстати у команды vk нет интереса в сторону llvm?
@gumeniukcom
Вряд ли CEO криптокомпании такой
дурачоклегкомысленный, чтобы заплатить $2.9m за NFT, рассчитывая на перепродажу.Мне кажется основной профит NFT в отмыве денег, а не в поиске таких же
лоховкриптоинвесторовв люстру чижевского!
За играми не слежу, i7 для минималки это уже норм?
Может у меня получится прояснить разницу.
Вот есть функция. У неё есть аргументы. Есть код, который вызывает это функцию и передаёт какие-то переменные.
Вопрос - а что по факту передаётся в функцию?
Ответ - по факту это всегда некий адрес в памяти. Массив, int, объект, и т.д. - это всё просто некий адрес в памяти, а дальше уже компилятор разруливает как вызвать метод объекта по этому адресу памяти или как трактовать это как элемент массива.
На заре программирования думали-думали и решили сделать два способа передачи параметров (забавный факт - в компуктерах PDP-11 было аж 42 способа адресовать аргумент) :
1) По ссылке - когда функция получает ровно тот же адрес переменной, который был когда вызвали функцию. В данном случае компилятор просто копирует адрес переменной.
2) По значению - когда функция получает совершенной другой адрес переменной при вызове. В данном случае компилятор выполняет полное копирование переменной.
После это стали думать ещё. А вдруг аргумент функции не изменяется, а мы передаём его по значению. Если это огромный массив - то мы зря делаем полную копию массива.
Пришла гениальная идея - а давайте не будем делать полную копию, вместо этого передадим по факту по ссылке, дождёмся пока код решит что-то записать в эту переменную, и только тогда сделаем полную копию (ну и подвиснем ещё на некоторое время). В итоге компилятор вставляет дополнительный код чтобы разруливать такие сценарии.
Итого: передача аргумента (в более широком смысле - адресация переменных) и стратегия cope-on-write разные вещи, но существуют в одном контексте. Поэтому их часто употребляют как взаимозаменямо. Но их гораздо больше!
Поддерживаю, нет ничего сложного в накате миграции для изменения схемы. В крайнем случае, если нет механизма автонаката, можно руками быстро на проде выполнить - по моему опыту даже если у юзеров какие-то реквесты упадут, то ничего страшного, просто выполнят ещё раз.
Я бы ещё убрал тупое правило каждый класс в отдельном файле.
Автор правильно пишет про преждевременную оптимизацию и маленькие классы. Если у меня простенький контроллер на 1 экшен, DTO из двух полей и простой CRUD то всё это лучше положить в одном файле User, чем городить UserController, UserDto, etc.
В идеале так вообще один класс, который имплементит все нужные интерфейсы и содержит всю реализацию в себе.
Когда логика усложнится, можно и тесты добавить, и подумать над разделением.
Зачем это на десктопе? Чтобы запустить fdisk с дискетки?
Возникает вопрос - зачем современному десктопному CPU режим совместимости не то, чтобы с x86, а даже с реальным режимом x86?
ФГДС отдельно требуется, а стоматолог - нет?