• Ультрабюджетный ноутбук Chuwi LapBook 14.1: Все во имя экономии
    +1
    Скажу совершенно крамольную вещь: в работе с текстами и браузером я не чувствовал особой разницы со своим MacBook Pro предпоследнего поколения. С учетом разницы в цене – очень неслабый результат.

    Сильное заявление. По каким параметрам сравниваете? При сравнении этих машин в браузерах и текстовых редакторах можно найти десятки критичных параметров, по которым между ними будет пропасть. Сравнивать продукты из разных ценовых категорий (цена отличается в 10 раз не просто так) и делать такие субъективные заявления, как минимум не профессионально, извините. Ладно, те кто понимает о чём речь, улыбнуться и пройдут мимо такого обзора. Но ведь кто-то прочитает хвалебный отзыв о чудесной китайской поделке за 14000, которая не уступает макбуку за более чем 100000 и купит это. И что он получит? В статье пишите, что ноутбук внезапно умер, а дальше хвалите.
  • Journalist – ведём текстовые онлайн трансляции через Telegram
    0
    В этом месте согласен. Недосмотрел. 5 имел ввиду — блок информации. Они же выводятся при её повторном запросе с клавиатуры. Первое и последнее тут касается непосредственно старта трансляции. Их можно объединить, согласен.
  • Journalist – ведём текстовые онлайн трансляции через Telegram
    0
    Там 5 сообщений. Ссылки объединены в одно. А сообщение с командой и кодом для вставки сделаны отдельными, чтобы, как вы правильно заметили, их было удобно копировать и вставлять. На счёт ссылки на /join надо подумать, что удобнее. Т.к. сейчас нет возможности лишний раз случайно по ней кликнуть, а тот, кому её пришлют, легко отправит её боту и присоединится к трансляции.
  • Journalist – ведём текстовые онлайн трансляции через Telegram
    0
    Хороший вопрос. Чтобы не натыкаться на лимиты — всё общение с ботом проходит через специальную прослойку, ограничивающую количество запросов к api в секунду до разрешенных параметров. Для приложения это выглядит прозрачно, при превышении лимита результат вернётся из метода чуть позже (как только очередь выполнится). Учитывая специфику бота, а именно то, что количество сообщений в чат минимально, в сам лимит упереться в данном случае довольно сложно. Эта проблема более остро стоит для ботов с большей интерактивностью, например игр. Но если всё-таки ситуация случится, то пользователь получит ответ на 1-2 секунды позже. При большом количестве пользователей обход лимитов возможен только увеличением их со стороны Telegram.
  • Journalist – ведём текстовые онлайн трансляции через Telegram
    0
    Спасибо за развёрнутый ответ. Отвечаю по порядку.

    На счёт Markdown Вы правы — в Telegram и Journalist формат немного различается. Но как раз в Journalist используется его стандартная реализация. Если провести тот же самый опыт на GitHub, Ghost или на Хабре, поведение будет идентично используемому в Journalist. Т.к. сервис позиционируется для использования сотрудниками СМИ и блогерами, я считаю более правильным использовать реализацию поддерживаемую во многих инструментах публикации текста, т.к. к ней уже все привыкли.

    На счёт парсинга MessageEntity я думал, но пока не пришел к однозначному выводу о том, нужно ли это делать и смешивать их с поддержкой Markdown, это может создать дополнительную путаницу, т.к. может получиться ситуация, когда будет разметка в разметке. И это всё очень сильно усложнит, если появится (я думаю рано или поздно это произойдёт, в зависимости от требований пользователей) иной способ доступа к редактированию/написанию постов, например web-интерфейс. Тогда смешанная разметка может принести ещё больше бед, чем пользы.

    На счёт кнопки опубликовать. Как показала практика, без неё очень сложно. Посты чаще всего состоят из нескольких сообщений. Могут содержать разные типы данных и кнопка опубликовать является логическим завершением целостного поста. Плюс, это ещё один рубеж для предотвращения ошибок. Хоть возможность редактирования и существует, но очень не приятно, если случайное сообщение прилетит нескольким тысячам пользователей. В данном случае я убеждён, что без явной команды на публикацию серьёзные посты с действительно большой аудиторией формировать будет на много сложнее и опаснее.

    Горячие посты и удаление — это то, что мне пока не нравится. С удалением лучше и быстрее способ, чем ответ на сообщение командой я не вижу, пока боты не научатся это событие ловить. А вот с типом поста — об этом можно подумать. Сейчас они с удалением образуют единый UX, не нужно вспоминать, как делать одно, а как другое. Замена обозначения горячего поста на некий набор символов может упростить задачу в некотором плане, но иногда может затруднить вхождение в процесс. Хотя идея с тегами — не плохая. Об этом можно подумать. Но тут стоит помнить также про возможную реализацию иных клиентов в будущем.

    Рад, что в целом сервис нравится. На будущее есть ещё много планов по улучшению функционала.
  • Почему объём памяти у MacBook Pro ограничен 16GB
    +2
    У меня V300 на 240Гб стоял в сервере с БД год 24х7, куда очень много писалось и удалялось большое количество статистических данных. Потом перестало хватать места, его заменил на Hyperx Savage 480Гб, а этот V300 стоит в другом сервере, где места много не требуется. При этом за то же время умерло два новых WD Blue на 1Тб, которые использовались для бекапов данных, они тоже были включены 24х7, но на них лишь раз в сутки скидывался дамп и ничего не читалось. Оба просто перестали определяться и тормозили компьютер при подключении.
  • Почему объём памяти у MacBook Pro ограничен 16GB
    +3
    У кого-то хоть один SSD умер от износа ресурса дома при обычной работе? Это такой стереотип, как не устали только эту мантру повторять. Да, это было актуально, когда SSD только появились, были маленьких объемов и очень дорогими. Но на сегодня это уже много лет не актуально.
  • Почему объём памяти у MacBook Pro ограничен 16GB
    0
    А у меня совершенно обратный опыт. Был Mac Mini 2012 с 16Гб и SSD. Вообще никаких проблем не знал, потребление было где-то 12-14Гб, ни в чём себе не отказывал, вкладок полно, IDE тяжелые и все такое. Но мне удобнее за ноутбуком, поэтому перешел на Air с 8Гб, в принципе хватало и хватает, но под завязку, т.е. жить можно, но надо помнить, что еще немного и начнется своп. Потом захотелось хорошего экрана, т.к. на Air он печальный, перешел на Retina, так он и греется сильнее и батарею меньше держит и визуально медленнее и память жрет сильнее, чем Air. Да машина хорошая, экран вне конкуренции, но не получается комфортно работать, когда уже было быстрее до этого. Поэтому, как бы глаза не были против — вернулся на Air. Я бы выбрал Air с 16Гб, да нет такого.
  • Почему объём памяти у MacBook Pro ограничен 16GB
    +2
    Почему-то часто в таких комментариях из крайности в крайность. Как будто люди либо сёрфят ВК и им достаточно 4Гб или вообще планшета и потом сразу рендеринг 3D. Причём большая часть работы как раз лежит между этими крайностями. Я уже лет 8 использую ноутбуки для работы и мне это нравится. У меня есть возможность собрать себе любой настольный ПК, который захочу, но мне это не удобно. И нет, я не бегаю по встречам и не провожу 50% времени в самолёте, как видят обычно пользователей ноутбуков. Я большую часть времени нахожусь за своим рабочим местом дома, просто мне так удобно и в целом производительности ноутбука хватает для решения моих задач. На данный момент я пользуюсь Macbook Air 13" в максимальной комплектации. И меня напрягает тот факт, что у Air нет опции с 16Гб памяти хотя бы, потому что в 8Гб хоть и хватает с натягом, но приходится думать, где-то экономить память. И на данный момент память — единственное, во что я реально упираюсь в этом компьютере. Есть Retina версии, там можно поставить 16Гб. Я полтора года проработал на Pro Retina с 8Гб, но оказалось, что хороший экран требует слишком много жертв, там те же 8Гб забиваются, как 4 на Air, на абсолютно тех же задачах. И 8-10Гб свопа у меня было обычным делом. В итоге я вернулся на Air. И выходит, если я сейчас в теории захочу поменять компьютер, так, чтобы мне хватало памяти у меня вариантов не много. Либо брать iMac 5K стационарный, куда можно поставить до 32Гб, либо 2015 Macbook 15" с 16Гб и дискретным видео, которое может обслужить Retina-экран без лагов, либо новая 13", которая без суперудобного MagSafe порта и почему-то позиционируется, как «базовая» и имеет всего 2 порта, хотя единственная с полноценной клавиатурой. Это конечно субъективно, но вот мне touchbar новый никак не нужен.
  • Почему объём памяти у MacBook Pro ограничен 16GB
    +1
    А вот тут внезапно — Air работает быстрее Pro. Если говорим о 13" версии. У Pro чуть быстрее процессор и видео, но за счёт того, что на экране в 3 раза больше пикселей, которые нужно обслуживать — он заметно медленне, если сравнивать его в лоб с Air. Так же он сильнее греется, пожирает больше памяти на тех же задачах и быстрее сажает аккумулятор. У Pro единственное преимущество перед Air — потрясающий экран. Так что те, кто говорят, что Air — это печатная машинка, обычно и в руках его не держали никогда. Либо держали только древний или версию с 4Гб ОЗУ.
  • Почему объём памяти у MacBook Pro ограничен 16GB
    0
    SO-DIMM DDR3 на 16GB.
    Похоже устарела информация.
  • Поддержка https совсем без настроек
    +1
    Интересная реализация. А что на счёт производительности? Интересно было бы увидеть замеры: с этим прокси против стандартной реализации ssl в nginx, на различном количестве соединений (в большом диапазоне), с различным размером тела запроса (от маленького до большого), как при этом ведёт себя сервис, сколько потребляет памяти. Так же было бы здорово, если бы сразу был представлен результат проверки такого сайта популярным ssl-чекером. Поскольку это приложение претендует на точку входа — оно может стать неожиданной причиной падения сервиса, поэтому такие подробности были бы очень кстати.
  • Apple Special Event, октябрь 2016 [архив текстовой трансляции]
    +13
    Все самые плохие прогнозы сбылись.
    1. Отсутствие MagSafe — одной из самых крутых фишек макбуков, сколько раз она спасала от падения. И даже не упомянули, просто похоронили.
    2. Отсутствие обычных USB. Thunderbolt 3 и всё такое это конечно круто. Но флешки, внешние диски и другое оборудование всё ещё среди нас. Пока рано хоронить USB-A разъем, особенно в Pro линейке.
    3. 6 поколение процессоров, когда конкуренты начинают выпускать на 7.
    4. Отсутствие опции 32Гб ОЗУ. 2016-2017? Pro? Серьёзно? 8Гб на ретине крайне мало, 16 рабочий минимум для серёзных задач, 32 — было бы для комфорта сейчас и несколько лет вперёд, всё таки не дешевая машина.

    Можно долго перечислять ещё. Нововведения можно назвать «прикольными». Не плохо, но не киллерфича, которыми хотят их представить. Печаль.
  • Microsoft Windows 10 Event [архив текстовой трансляции]
    +15


    Не могу разглядеть, какая модель Surface Book у журналистов?
  • Первый слух: OLED-дисплей и Touch ID в новом Macbook Pro
    +1
    На счёт тактильных ощущений, возможно там будет их taptic engine, что конечно не отменяет убогости подхода, особенно, когда клавиши используются в работе постоянно.
  • Пишем микросервис на KoaJS 2 в стиле ES2017. Часть II: Минималистичный REST
    0
    На всякий случай, moment.js хоть и очень удобный, но очень медленный (на некоторых операциях). У меня был случай, что до 90% времени генерации страницы тратилось на обработку дат в moment.js. Его стоит использовать очень осторожно.
  • Mini-Desktop своими руками. 3.0
    0
    MBP Retina очень сильно разогревается. При просмотре FullHD на ютубе может в легкую до 95 раскочегариться, при этом вентиляторы начинают ощутимо работать как раз где-то в районе 90 градусов. Корпус нагревается при этом значительно.
  • GitLab выпустила версию 8.8
    +1
    В этом образе интеграция с Docker Registry ещё не допилена. Но работа ведётся в этом направлении.
  • Мой опыт настройки окружения для Web-разработки
    +3
    У нас в 2016 это уже моветон.
  • Как я новостной агрегатор делал
    0
    В планах есть, но пока не понятно по времени. За это время несколько раз менялась архитектура, расширялось, оптимизировалось, переписывалось очень много. С момента написания этой статьи до текущего момента изменилось практически всё в том или ином роде. Во время разработки, как обычно, вскрывается очень много крайних ситуаций, которые сильно затрудняют дальнейшую работу и которые очень сложно предвидеть на начальном этапе. Я не раз читал отзывы, в стиле «такое можно за 12 часов написать». Только вот не видел потом за 12 часов написаных аналогов =) Сейчас в основном занимаюсь стабилизацией текущей версии, чтобы можно было продолжать разработку и поддержку без боли, т.к. планируется введение нового функционала. Недавно перевёл всю систему на Docker. Стало на много проще управлять группами серверов. Нужно было делать так изначально — сэкономило бы много времени и нервов. Потихоньку начинает вставать вопрос о грамотной оркестрации. Сейчас в день добавляется около 70000 новых статей, будет больше, после проведения оптимизации.
  • Как я новостной агрегатор делал
    0
    Да, имеется ввиду, что новостные источники этого региона добавлены в обход.
  • Ubuntu. Русификация консоли в 2016 году
    +1
    Ставил Ubuntu Server 16.04 Beta 2. После первой загрузки была такая же проблема. Но после apt-get update && apt-get upgrade и ребута — консоль сама поправилась.
  • Рабочая станция Dell Precision 15 7000 Series (7510): Компромиссов больше нет
    +1
    Вот всегда удивляла такая сборка и материалы в "премиум" моделях. Такое ощущение, что материалы вообще никакую проверку не проходят, а достаются тикетом в отдел закупок с формулировкой: "купите пластмассы". Зазоры у кнопок тачпада и клавиатуры тоже огромные, гарантированно соберут мусор. Пластиковый тачпад — это вообще нечто, или это стекло так натёрлось? А ещё фанаты любят это прикрывать отговорками: это же ноутбуки для бизнеса, типа грубое промышленное решение, как будто они не должны при этом иметь современный экстерьер.
  • Персистентная оперативная память
    0
    На видео состояние сохраняется и восстанавливается как раз через CRIU. Они используют runc checkpoint, который в свою очередь работает через CRIU.
  • Персистентная оперативная память
    0
    Вот крутое демо, сервер Quake в контейнере переносят между датацентрами с сохранением состояния и сетевого подключения. https://www.youtube.com/watch?v=MHJmNZSRve0&feature=youtu.be&t=1328
  • Поняв Docker
    0
    Встречный вопрос. Если мы отталкиваемся от того, что окружение разработки похоже на окружение боевое (у нас так), то каким образом доставлять в это окружение код во время разработки? Если для боевого окружения собрать новый образ с кодом и либами с нуля и выкатить его — не проблема, то для окружения разработки это очень долго. Если представить, что закоммитили php файл и ждём, пока CI клонирует проект, установит все зависимости, соберёт образ и запустит его — так можно состариться во время разработки.
  • Поняв Docker
    +1
    Ну так деплой через git у нас не отменяет преимущества докера. Вот пример яркий: в выходные игра попала в фичеринг и онлайн вырос на 30-40%, мощностей стало не хватать. Мы купили новый сервер, поставили ОС, а дальше docker-machine, docker-compose и готово — сервер обрабатывает запросы. 25 минут на всё, из них 20 на покупку сервера и установку ОС. Без докера бы тут было дел на много дольше. Можно конечно всякие там ansible, но мне докер тут удобнее.
  • Поняв Docker
    +2
    В случае если я пушу один php файл в git, он просто зальётся во все нужные контейнеры и сервер продолжит работу без даунтайма. Если же пушить контейнер с кодом, придётся как минимум перезапустить php-fpm что приведёт к потере некоторых запросов, если по простому, а если по тяжёлому — приведёт к необходимости настройки умных балансировщиков, которые для нас сейчас избыточны. Пуш в продакшн ветку могут сделать несколько разработчиков, для этого либо каждому из них придётся в запускать сборку контейнера с кодом, либо поднимать CI-сервер, который будет это делать для каждого пуша. Я просто не вижу смысла делать ещё одну прослойку между git и сервером, только для того, чтобы соответствовать чьим-то убеждениям, причём без видимого профита от неё и с видимым замедлением и усложнением процесса. Я никого делать так не призываю, мы просто нашли для себя удобное решение и я им поделился.
  • Поняв Docker
    +1
    Если git pull на сервере привёл к тому, что файлы обновились, после него выполнится npm install для node.js и composer update для php.
  • Поняв Docker
    +2
    Код, конфиги и данные у нас вынесены в volume. Сами контейнеры содержат только окружение. Например, если мы хотим обновить php или node.js, мы собираем образ с его новой версией и деплоим через docker-compose. Он пересоберёт образ и стартует его, подцепив volume с кодом и конфигами (которые при необходимости уже подготовлены для работы с новой версией окружения). Это удобно — мы везде быстро получаем одинаковое окружение. Но если слепо идти дальше и, например, мы немного подправили баланс в игре и для этого нужно собрать контейнер и пушнуть его на все сервера и перезапустить — это уже не удобно. Вместо этого мы просто пушим нужные коммиты в продакшн ветку и она вытягивается на все сервера через git. Это на много быстрее и не смешивает всё в кучу — наше приложение и его окружение. Если бы речь шла о каком-то бинарном приложении, которое бы нужно было предварительно скомпилировать и оно имело жесткие релизные интервалы, вариант с контейнером мог бы подойти, но в нашем случае, это будет только мешать.
  • Поняв Docker
    0
    Беспорядок в npm конечно существует, но все крупные библиотеки уже давно обновляются очень культурно. Ну и они сами по себе не обновятся при сборке образа. Если конечно не указывать в зависимостях что-то типа версия 2 и больше. Мы всегда указываем все версии зависимостей чётко, это гарантирует, что каждый раз будет установлена одна и та же библиотека. Когда нужно обновится — поднимаем версию руками, обновляем, тестируем и уже после этого она попадает в сборку. Обычная практика, это касается любого пакетного менеджера, не только npm.
  • Поняв Docker
    +1
    Использование динамических ip и не использование своих конфигураций — это проблема не Docker, а человека его настраивающего. ip вообще нет необходимости использовать, т.к. всё работает через локальный DNS для контейнеров на одной машине и через DNS внешнего сервиса типа Consul, при работе на нескольких машинах. А конфиги, у нас например, подгружаются из git и чтобы их поменять, нужно только запушить новый конфиг в нужную ветку и перезагрузить контейнер. В образ конфиги мы не зашиваем, чтобы каждый раз не пересобирать.
  • Поняв Docker
    +2
    Особо сложного ничего не делали. Есть набор машин, они создаются через docker-machine create, а всё окружение докера (папка .docker) хранится в гите. Само окружение управления так же запускается внутри контейнера, чтобы всем было проще его у себя запустить и работать с машинами. Проект разбит на микросервисы: 1 контейнер — 1 процесс. node.js, php, mysql, nginx. Код в контейнеры подгружается из git с заданным интервалом из продакшн ветки. Как только всё готово, мы мерджим текущую ветку в продакшн ветку и она вытягивается на сервера. node.js контейнеры при этом дополнительно пинаются, чтобы изменения подхватились. Поднят свой registry, в него собираем свои образы, заточенные под удобство конкретного проекта. Из глюков ничего особо серьёзного не было. Пару раз было что докер-демон переставал отвечать на какие-либо команды и даже его рестарт не помогал, приходилось перезагружать весь сервер. Зато, развернуть новый сервер при увеличении нагрузки можно за 15 минут из них 10 уйдёт на оплату сервера и установку ОС.
  • Поняв Docker
    +3
    С данными пока не всё так красиво, как со stateless контейнерами, но шаги в этом направлении делаются. Если с не большими и не сильно требовательными к скорости чтения/записи данными, можно обойтись сетевыми решениями вроде своей NFS или готовых облачных решений, то с базами данных сложнее. Тут либо локальное хранение на том же сервере, либо дорогие высокопроизводительные решения СХД. Недавно появилась возможность именовать и создавать volume отдельно от контейнеров, это немного улучшило управляемость. До этого для данных создавался отдельный контейнер с volume, которые подключались к другим контейнерам (которые этими данными управляют) через volumes_from. Что тоже вполне нормально работало. Перенос больших данных пока не очень удобен, есть ручные действия, хотя есть сторонние решения, типа flocker, которые эту задачу пробуют решить. Но сам пока не пробовал его в бою. На небольших тестовых данных всё хорошо, но не понятно, будет ли всё так же хорошо при копировании 500Гб БД. В любом случае, проблема больших данных лежит немного за рамками Docker, т.к. такие объёмы пока упираются в проблемы, которые Docker решать не предназначен. Бекапить работающую БД путём копирования файлов всё равно не получится. Нужен либо дамп, либо репликация, а вот это уже делается средствами Docker без проблем.
  • Поняв Docker
    +11
    Полгода используем Docker в production. Более 20 серверов, более 300 тысяч уникальных посетителей в сутки. Около 30 различных контейнеров. Экономит время и нервы колоссально, но нужно хорошо разобраться, чтобы начать получать профит. Технологии ешё есть куда расти: бывают небольшие сбои, кое-где некоторые вещи кажутся не логичными, но дело движется. В любом случае, Docker это лучшее, что случалось с управлением серверами за последние годы (по моему мнению). Сейчас у нас вся конфигурация и код в хранится в git, деплой через git (push в prodcution ветку). Уже давно нет никаких конфигов nginx написанных (или подправленных) кем-то в редакторе прямо на сервере. Даже при полном крахе, вся система может быть развернута за минуты на голых серверах. Пока используем машины вне кластера, переключаясь через docker-machine env внутри специального контейнера для управления. Очень хочется перейти на swarm, но пока есть факторы, которые останавливают.
  • Новые кнопки «твитнуть» или прощай счётчик
    0
    За исключением того, что иногда значение излишне кешировалось, счётчик вполне отражал то, для чего создавался.
  • Новые кнопки «твитнуть» или прощай счётчик
    0
    Кастомные кнопки на сайтах соответственно тоже поломались.
  • Новые кнопки «твитнуть» или прощай счётчик
    +1
    Спасибо, приятно слышать. Потихоньку работаю над его улучшением. Появились приложения для Android и Windows Phone. Когда iOS приложение пройдёт аппрув, об их разработке отдельно напишу.
  • Повышаем отказоустойчивость системы на nodejs
    +2
    Все ситуации разные. Подход один: когда видим, что память расходуется не так, как должна, делаем дамп heap и разбираем его в профайлере (Google Chrome). Когда нормальный расход процесса, например, 100Мб, а фактический — гигабайт, не сложно будет увидеть, что за объекты наполняют heap. Ну а далее — думаем, почему GC их не собрал. Причины появления в программе разные, но причина не сбора обычно одна — где-то осталась ссылка на объект, возможно и не явная. Мог где-то быть запущен setInterval или установлен EventListener, в область видимости которого попадает объект. Может быть взаимная ссылка между объектами — очень коварный баг. Ещё могут заполняться буферы, если куда-то пишут быстрее, чем читают. Вообще ситуаций полно, каждую раскручивать нужно исходя из того, что именно утекло.
  • Повышаем отказоустойчивость системы на nodejs
    +2
    По поводу утечек памяти и перезагрузок. В конечном счёте обычно выясняется, что виноват код, либо ваш, либо npm. У нас игра на nodejs, очень интенсивная, сетевое взаимодействие через websocket с клиентами. Были «детские» проблемы, которые тоже время от времени забивали память и приходилось перезагружать инстанс, но под пристальным анализом они все были выявлены и исправлены, и да, все они были в коде приложения, хотя далеко не все были так очевидны, т.е. на первый взгляд казалось, что всё в коде хорошо. Но анализ дампов heap и примерных ситуаций, в которых они возникали, помог их выявить. Сейчас инстансы работают спокойно столько, сколько нужно. Неделю недавно работали, т.к. долго не апдейтили код.
    У меня ещё есть сайт написанный на node.js, там тоже всё отлажено, писал давно его и долго мучился сначала, но после того, как все проблемы устранил — работает без перезагрузок вообще, поскольку код там не обновляется, аптайм там месяцами измеряется. Ну и все относительно популярные модули npm довольно серьёзно относятся к проблемам утечек памяти, в целом с ними там ситуация хорошая, их либо нет, либо их быстро исправляют.