public void SomeFunction(int age)
{
if (age >= 0) {
// сделать что-то
} else {
System.out.println("Не верный возраст");
}
}
public void SomeFunction(int age)
{
if (age < 0){
System.out.println("Не верный возраст");
return;
}
// сделать что-то
}
Лично мне первый вариант является более приемлемым. Так как при большем количестве параметров функции возникает комбинаторный взрыв количества возможных значений и сочетаний этих параметров. И на много проще оказывается очертить множество подходящих значений, а все остальное по умолчанию считать мусором и выбрасывать ошибку (ну или как-то по другому обрабатывать эту ситуацию). По опыту так меньше ошибок вылазит в итоге.
«Создание веб-сайтов» — требует не только умения размещать милые изображения котиков на странице. Этот процесс также подразумевает вставку узлов в глобальный граф гиперссылок. Добавление одной единственной страницы ведет к потенциальному росту количества ребер графа, и это в свою очередь может оказать не очевидное на первый взгляд влияние на производительность, анализ, рейтинг в поисковой выдаче и другие характеристики.
Звучит как пафосный сценарный монолог из Крепкого орешка 4, так и вспомнилась сразу сцена где он через допотопный смартфон взламывает всю энергосистему США.
Зачем эта статья?
Проверил, все таки я был не прав. Но я не пользуюсь генераторами, так что это нормально, что я с ходу не правильно понял. Тем не менее, сообщение выше я писал в Вашу защиту.
Я вот, возможно, сейчас ошибаюсь, но, кажется, в исходном примере проход в цикле по одним и тем же данным выполняется 4 раза (в каждом из 4-х методов цепочки по разу), а в примере Gentlee — один раз. Я не исключаю, что я не правильно понял как работают асинхронные генераторы выше, но вроде все так.
Это в соц-сетях репостят одни и те же файлы, а с личными диалогами все иначе. Я вообще телеграм использую вместо дропбокса и как еще один способ забекапить личные файлы.
Мне вот EmoReco старый логотип больше приятных ощущений вызывает, а в новом эти разноцветные кольца напоминают разноцветные буквы в логотипе гугла от чего меня слегка коробит :) У Device, с определенными оговорками, старый тоже больше нравится. ИМХО.
Method and system for remote text selection using a touchscreen device
Abstract
A method for selecting the text on a remote computer or a server from a mobile device is provided. Actions of a user for selecting a text area on the mobile device are emulated on a remote server. A user initiates text selection on a mobile device using touch screen functionality, which is reflected on selected elements of a remote server. Once the mobile device user completes the selection, the emulator selects a corresponding area of the server screen. All mobile device user actions related to selection of text area are emulated on a remote server.
А что тимвьювер не нарушает данный патент? Я вот, например, с мобильного устройства выделял текст на удаленном компьютере через тимвьювер, вроде подходит. Срочно их засудите!
На данный момент, для себя нашел 1 классный зарубежный сервис, который продает качественный (игроки действительно играют в игру) трафик за приемлемую цену
Есть мнение, что контроллер — не какае-та мифическая штука, где каждый наделяет его той отвественностью какая придет ему в голову (или еще хуже каждый раз изобретая новые «шаблоны» — MVP и т. д.), а это вполне себе графический компонент, такой же как и View.
setInterval(async () => {
let file = await new Promise((resolve, reject) => {
let data = fs.readFileSync(
'...', // путь к очень жирному файлу
{encoding: 'utf8'});
});
resolve(data);
}, 0);
Работает как первый вариант, а не как второй выше, блокируя основной поток. Офигеть…
Я имелл ввиду колбек http запроса должен быть ассинхронным. Ведь если ты передаешь колбек в setTimeout он ассинхронный, если передаешь колбек в readFileSync, колбек тоже ассинхронно выполняется. Почему же когда ты передаешь колбек в http.createServer, то он выполняется синхронно, а ты вполне логично ожидаешь тут ассинхронности. Ну то есть ты ожидаешь, что весь код внутри колбека будет ассинхронно выполняться по отношению к внешнему коду.
Однако, если вы пользуетесь синхронными методами внутри обработчиков неких событий, вроде коллбэка HTTP-сервера, отвечающего за обработку запросов, то это, без вариантов, совершенно неправильно. Делать так настоятельно не рекомендуется.
И почему? Если мне в обработчике события в середние последовательности действий нужно получить какие-то данные из файла, а на следующих шагах делать что-то с этими данными, мне что колбеки городить? Бред.
Там про сравнение с шахматами и го в разделе: «The problem»
Лично мне первый вариант является более приемлемым. Так как при большем количестве параметров функции возникает комбинаторный взрыв количества возможных значений и сочетаний этих параметров. И на много проще оказывается очертить множество подходящих значений, а все остальное по умолчанию считать мусором и выбрасывать ошибку (ну или как-то по другому обрабатывать эту ситуацию). По опыту так меньше ошибок вылазит в итоге.
Звучит как пафосный сценарный монолог из Крепкого орешка 4, так и вспомнилась сразу сцена где он через допотопный смартфон взламывает всю энергосистему США.
Зачем эта статья?
А что тимвьювер не нарушает данный патент? Я вот, например, с мобильного устройства выделял текст на удаленном компьютере через тимвьювер, вроде подходит. Срочно их засудите!
Дайте ссылку, пожалуйста.
Жесть :)
Работает как первый вариант, а не как второй выше, блокируя основной поток. Офигеть…
Честно говоря думал что следующие два куска кода эквивалентны:
и вот этот:
Но оказалось нет (
И почему? Если мне в обработчике события в середние последовательности действий нужно получить какие-то данные из файла, а на следующих шагах делать что-то с этими данными, мне что колбеки городить? Бред.