Обновить
0
@alpha6read⁠-⁠only

Пользователь

Отправить сообщение
Это, скорее всего, видео еще не смотрел, запуск приложений Windows в режиме тонкого клиента, выше в комментах про это писали.
Лучше предусмотреть возможность использования модуля в ООП режиме. Хотя для учебного материала это не особо нужно :)
А я про Мегафон :)
Теле2, емнип, вообще в тоннелях не работает. Насчет билайна не знаю.
В Санкт-Петербурге во всех перегонах можно разговаривать, в большинстве есть покрытие 3G.
Есть пара мест где вообще нет покрытия интернета в тоннеле, но они достаточно локальные.
Когда ее не расширить из-за ограничений чипсета или того что она распаяна на плате — ее стоимость становится величиной эфемерной и абстрактной. И да, не надо мне предлагать поменять комп — он меня устраивает :)
> А Opera Turbo?
Y.Browser использует Opera Turbo, хотя это вполне себе хромиум допиленный.
а когда можно ждать альфу для десктопа на новом движке? Хочется посмотреть на потребление памяти.
Сейчас, при моем использовании, опера жрет 600Мб, а хром 2,5 гига, разница существенная, не хотелось бы чтобы она изменилась в сторону хромовской.
20 минут грузиться в системе? В битве за LXQ я одним чаром 4 часа на черный экран любовался после пропрыга в систему. А лаг всех действий был около 10 минут. Хотя конечно это был рекорд онлайна на то время и ССР было удивлено что нода выдержала :)
Так что 20 минут прогружаться в системе — это и не лаг совсем, а так, небольшая задержка пакетов :)
Разрабы еще 2 года назад говорили что ядро не использует питон. Там проблема в том что одна солнечная система не масштабируется на несколько серверов. Это проблема архитектуры игрового движка и пока она не решена.
1. Не стоит пользоваться хостингами с древней версией перла.
2. Есть форк Mojo который работает с perl 5.8.8
Просто посмотрите за сколько шагов вы сможете развернуть приложение на сервере со стандартным набором. Что вам надо от приложения? Миграции, веб сервер, орм, шаблонизатор, удобный для верстальщиков, работа с ассетами (js/css/img), консольные утилиты, деплой на серверы, системы тестирования и прочее. В Mojo всё это из коробки и оно удобное?

Миграции в рельсах завязаны на собственный ORM. Мы, например, ORM не используем.
Вебсервер — в один Mojo встроено 3 разных типа веб серверов + Starman + Twiggy.
Шаблонизаторов кучи на любой вкус. Конкретезируйте что вы понимаете под удобством для верстальщика, пожалуйста? В том же Mojo встроенный ep вполне себе удобен для всех верстальщиков с которыми я работал. И всякие TT и иже с ним никто не отменял.
Работа с ассетами? Во фреймворке? Что Вы под этим подразумеваете? Про консольные утилиты тот же вопрос.
Деплой на сервера — Git, Capistrano и прочее прочее, причем тут язык и фреймворк?
Системы тестирования аналогично, при том что в perl и Mojo тесты идут из коробки.

Видимо тут прослеживается различие в подходах. Вам удобнее заточить процесс разработки под инструменты. Мне же удобнее взять разные инструменты и скомбинировать окружение которое будет работать с максимальной отдачей.
В сфере веб разработки эти фичи серьёзно уступают аналогам из других языков, это не вызывает спор? Дело не «писать в стиле», дело в разработке бизнес процессов, а не налаживании инфраструктуры проекта.

А можно раскрыть тему преимуществ других языков? Например, в сравнении Mojolicious/Rails/Django. На рельсах баловался — каких-то глобальных преимуществ перед Mojo/Dancer не увидел, может не туда смотрел.
а, точно CDMA же. У меня GSM, с такими проблемами не сталкивался :)
А эти данные самому узнать можно или их только сервис оператора прошить может? Если можно — то можно самому расковырять прошивку и зашить нужное. Благо прошивка на него делается совершенно элементарно.
в смысле «прошить на интернет»?
Ностальгия :)
У меня дома до сих пор лежить Palm Treo 650 — qwerty-смартфон на PalmOS. Побитый жизнью, но вполне живой :)
Нет, продакшен серверов у нас много с жутким зоопарком на них т.к. не все под нашим контролем :(
Ну тут уже скорее вопрос специфики конкретной предметной области.
Лично у меня разработческая виртуалка полностью повторяет продакшен сервер. Все инструменты разработчика работают на хост-системе. На виртуалке я только логи смотрю.
На каждом сервере крутится своя задача. Но вы действительно собираетесь собирать индивидуальную конфигурацию базовых пакетов под каждое приложение? И как вы потом будете обновлять это зоопарк?

По факту у вас есть несколько базовых ролей серверов — прокси/хранилище/сервер на котором крутятся скрипты со своим набором софта. И будет несколько нерационально разбивать запускалки еще на 10 групп из-за того что разработчики поставили себе на машины «особо_новую_версию_библиотеки» не совместимую с той что используется на серверах сейчас. И под которую написана куча софта.
А переписывать новый софт обратно уже поздно ибо дедлайн был «вчера».
Если у вас 2 мейнфрейма — то особых проблем поддерживать среду разработки и продакшен в актуальном состоянии не составит.
А вот если у вас 100+ серверов, на которых крутятся тонны разнообразного софта — то здесь уже, скорее всего, будет дешевле загнать разработчиков в виртуалки с продакшен окружением.
Разработка в продакшен окружении позволяет сэкономить много ресурсов на отлавливание глюков из серии «забыли поставить модуль»/«поставили модуль не совместимой версии»/«feature_name не работает с языком версии ниже Х» и прочее-прочее.
Сие правда не особо критично при небольшом кол-ве серверов.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность