Как мне не хватает нынче мертвого rentacoder.com. 8-15% от суммы, никаких дополнительных платежей, никаких премиум аккаунтов и разноцветных/прикрепленных bid-ов. Исполнители соревнуются только своим рейтингом и профилем.
А о (полу)мертвых — или хорошо, или ничего. К сожалению, постгрес в этом плане относится к "типичному опнсорсу" — всё работает отлично, пока ты не пытаешься собрать кластер. Вот пара приколов из нашего опыта (мастер, один слейв, синхронная репликация):
репликация синхронная, но чтение со слейва не всегда возвращает данные, которые только что были записаны на мастер
хост со слейвом упал, мастер при попытке вставки строки возвращает ошибку, но строку вставляет и транзакцию коммитит.
Хотя может мы его готовим неправильно — настройка и администрирование кластера постгреса — это отдельная песня.
Ну как с самого начала — сначала установить соединение, потом скачать хтмл, потом опять устанавливать соединения… При высоком пинге это сильно увеличивает latency. Особенно при использовании TLS. Читал где-то, что разрабатывается стандарт для упрощенного (в плане кол-ва round-trip-ов) TLS, но когда мы его увидим...
А вообще — когда вы сделаете HTTP/2 prefetch? Это будет мощный довод переходить на новый протокол для технологически продвинутых веб-мастеров.
Т.е. для каналов с приличным % потери пакетов TCP считает, что пакеты теряются из-за шейпера и урезает окно. Но надо же смотреть в светлое будущее, а не в темное прошлое :-)
С торрентами немного другая история — там много соединений с разными сидами позволяет справляться с ситуацией, когда канал получателя шире канала отправителя.
Странная статья со странными выводами. HTTP/2 не нужна дополнительная функциональность и конфиденциальность — в плане функционала в HTTP/1.1 всё отлично. Новая версия протокола потребовалась прежде всего для решения проблем с производительностью, со скоростью загрузки сайтов.
Нападки автора на TLS совершенно непонятны — он отлично решает задачу авторизации и конфиденциальности. И в HTTP/2 TLS быстрее — потому, что HTTP/1.1 устанавливает 6-8 TLS-соединений с сервером, а HTTP/2 — одно. Перерасход ресурсов на шифрование — сомнительно, в современных процессорах есть аппаратная поддержка AES.
То же самое про кукисы. Полный контроль над ними у пользователя есть уже сейчас, а оверхед на передачу больших кукисов снижает HPACK. "идентификатор сессии" при желании можно засунуть в те же кукисы вместо реальных данных — веб-сайты заинтересованы в том, чтобы они быстрее открывались и не раздувают кукисы без нужды.
Про быстрые реализации — ткните автора лицом в nginx.
Про улучшения и нежелательность SSL. HTTP/2 был сделан полностью совместимым по функционалу не просто так — это позволяет всем существующим приложениям, говорящим на HTTP/1.1, получить преимущества нового протокола вообще без изменения кода — просто поставив перед ними тот же nginx, который будет заниматься перекодировкой 2 — > 1.1 и обратно.
В целом, HTTP/2 рассчитан на использование в интернете для эффективной закачки контента веб-сайта в браузер. Что означает, что HTTP/1.1 никогда не умрет — как протокол для простых низконагруженных серверов, как протокол для REST. Выбор будет всегда.
Сложные задачи требуют много времени для решения, а зачем мучать и кандидата, и интервьювера, если все нужные выводы можно сделать на основе простой задачи, которую решат за 5 минут?
Ну серьезно, практика показывает, что кандидат, который а) написал на бумажке сортировку пузырьком и б) внятно рассказал, чем хорошо и плохо делать очереди на основе таблицы в оракле, будет неплохо и архитектуру проектировать, и сложные задачи решать.
Не ново всё, не ново. Есть упомянутый в статье i-bem.js утилитами, есть старый, но эффективный google closure library. Есть поддержка рендера на сервере в реакте.
Вы недооцениваете количество людей, которые эту задачу не решат. В моей практике собеседований сложные вопросы просто не нужны — достаточно послушать, что кандидат расскажет про свой проект и поспрашивать основы + простейшие задачки типа "найти максимальную глубину двоичного дерева".
Да, расскажите подробнее, если есть желание. Почему не дали выводить деньги? Вы им поздно показали договор? Не предупредили о намерении выводить деньги? Не смогли толком объяснить, куда вы их денете после вывода?
Так в любой стране же так? Если потом окажется, что вы деньги отмывали, банк штрафанут вне зависимости от того, знал он об этом или нет. Я перед заключением нетипичного договора хожу в банк и выясняю, как мне его провести. Помогает от неприятных неожиданностей.
Может правда свой сайт запилить на аналогичных условиях? Имеет ли это смысл?
Как мне не хватает нынче мертвого rentacoder.com. 8-15% от суммы, никаких дополнительных платежей, никаких премиум аккаунтов и разноцветных/прикрепленных bid-ов. Исполнители соревнуются только своим рейтингом и профилем.
А о (полу)мертвых — или хорошо, или ничего. К сожалению, постгрес в этом плане относится к "типичному опнсорсу" — всё работает отлично, пока ты не пытаешься собрать кластер. Вот пара приколов из нашего опыта (мастер, один слейв, синхронная репликация):
Хотя может мы его готовим неправильно — настройка и администрирование кластера постгреса — это отдельная песня.
Спасибо за информацию)
Наверное, браузеры в будущем будут открывать несколько соединений HTTP/2 параллельно по указанным вами причинам.
Ну как с самого начала — сначала установить соединение, потом скачать хтмл, потом опять устанавливать соединения… При высоком пинге это сильно увеличивает latency. Особенно при использовании TLS. Читал где-то, что разрабатывается стандарт для упрощенного (в плане кол-ва round-trip-ов) TLS, но когда мы его увидим...
А вообще — когда вы сделаете HTTP/2 prefetch? Это будет мощный довод переходить на новый протокол для технологически продвинутых веб-мастеров.
Т.е. для каналов с приличным % потери пакетов TCP считает, что пакеты теряются из-за шейпера и урезает окно. Но надо же смотреть в светлое будущее, а не в темное прошлое :-)
С торрентами немного другая история — там много соединений с разными сидами позволяет справляться с ситуацией, когда канал получателя шире канала отправителя.
Про скорость многопоточной закачки — я нашел вот это. Можете рассказать, почему два соединения будут быстрее, на уровне TCP/IP?
Странная статья со странными выводами. HTTP/2 не нужна дополнительная функциональность и конфиденциальность — в плане функционала в HTTP/1.1 всё отлично. Новая версия протокола потребовалась прежде всего для решения проблем с производительностью, со скоростью загрузки сайтов.
Нападки автора на TLS совершенно непонятны — он отлично решает задачу авторизации и конфиденциальности. И в HTTP/2 TLS быстрее — потому, что HTTP/1.1 устанавливает 6-8 TLS-соединений с сервером, а HTTP/2 — одно. Перерасход ресурсов на шифрование — сомнительно, в современных процессорах есть аппаратная поддержка AES.
То же самое про кукисы. Полный контроль над ними у пользователя есть уже сейчас, а оверхед на передачу больших кукисов снижает HPACK. "идентификатор сессии" при желании можно засунуть в те же кукисы вместо реальных данных — веб-сайты заинтересованы в том, чтобы они быстрее открывались и не раздувают кукисы без нужды.
Про быстрые реализации — ткните автора лицом в nginx.
Про улучшения и нежелательность SSL. HTTP/2 был сделан полностью совместимым по функционалу не просто так — это позволяет всем существующим приложениям, говорящим на HTTP/1.1, получить преимущества нового протокола вообще без изменения кода — просто поставив перед ними тот же nginx, который будет заниматься перекодировкой 2 — > 1.1 и обратно.
В целом, HTTP/2 рассчитан на использование в интернете для эффективной закачки контента веб-сайта в браузер. Что означает, что HTTP/1.1 никогда не умрет — как протокол для простых низконагруженных серверов, как протокол для REST. Выбор будет всегда.
Да, так лучше.
Где-то ошибка — должно быть 21 Fizz, а регулярка выводит просто 21.
sed (GNU sed) 4.2.2
сеньорному — да. От джава программиста ожидается правильный ответ, а от С++ — объяснение, что такое UB ^_^
Сложные задачи требуют много времени для решения, а зачем мучать и кандидата, и интервьювера, если все нужные выводы можно сделать на основе простой задачи, которую решат за 5 минут?
Ну серьезно, практика показывает, что кандидат, который а) написал на бумажке сортировку пузырьком и б) внятно рассказал, чем хорошо и плохо делать очереди на основе таблицы в оракле, будет неплохо и архитектуру проектировать, и сложные задачи решать.
Не ново всё, не ново. Есть упомянутый в статье i-bem.js утилитами, есть старый, но эффективный google closure library. Есть поддержка рендера на сервере в реакте.
Вы недооцениваете количество людей, которые эту задачу не решат. В моей практике собеседований сложные вопросы просто не нужны — достаточно послушать, что кандидат расскажет про свой проект и поспрашивать основы + простейшие задачки типа "найти максимальную глубину двоичного дерева".
О, совсем забыл — в скале нет имплиситных конвертаций булеана в инт. Не С++ все же.
Какие такие пустые строки? Мой вариант пустрых строк не выводит…
Но про неявную конверсию bool -> int — хорошая идея.
Вот вам вариант вообще без if-ов.
https://cleantalk.org/blacklists?record=8.8.8.8
Как такое может быть?
Да, расскажите подробнее, если есть желание. Почему не дали выводить деньги? Вы им поздно показали договор? Не предупредили о намерении выводить деньги? Не смогли толком объяснить, куда вы их денете после вывода?
Так в любой стране же так? Если потом окажется, что вы деньги отмывали, банк штрафанут вне зависимости от того, знал он об этом или нет. Я перед заключением нетипичного договора хожу в банк и выясняю, как мне его провести. Помогает от неприятных неожиданностей.