О! Давайте еще ссетевиков/админов нафиг пошлем — тоже на какой другой ресурс!
И менеджеров/HR-ов на другой ресурс.
Дизайнеров/графиков/писателей документации — тоже нафиг. И тестеров — они вообще с разработкой рядом не стояли…
А если серьезно, то решение, со всем уважением к редакции, выглядит серьезной ошибкой в позиционировании ресурса — большАя часть активной аудитории (как читателей так и писателей) теряется, и Хабр становиться все более скучным…
Вынос рекламных обзоров гаджетов и политики на GT (который многие вообще не открывают) еще был обоснован, но убрать туда разработку железа — это не правильно.
Я лично на GT заглядывал несколько раз, но так и не прижился… и многие GT игнорируют.
Замечательный сервис! Классно, что много локаций, из которых можно пинговать сервера. Бесплатный план очень либеральный и действительно позволяет опробовать сервис.
Пользуемся NewRelic но он не очень подходит для мониторинга большого числа серверов (дорого на каждый сервер ставить deep-dive монитор), а бесплатный монитор серверов не ловит многие проблемные ситуации.
первая система из уравнений вполне решается, если с помошью первых двух уравнений выразить сложение скоростей, и заменить им сложение скоростей в третьем уравнениии. путь сокращается и остается только искомое время.
да, лучше не скажешь.
Эти разные диаграммы — просто вынос мозга.
На каждую новую диаграмму приходится тратить кучу времени, чтобы понять, как ее расшифровать…
В смысле, опрос-то хороший, и информация полезная, но экперименты с диаграммами отбивают желание его читать примерно после трети статьи.
Попробуйте en.wikipedia.org/wiki/Magician_%28novel%29 если еще не попадалось — это несколько циклов романов по два-три тома в одном и том-же фантазийном мире. Сравнивать с Толкиеном не будем, это самостоятельное великолепное произведение. Я его на английском читал, но оно 100% переводилось.
В связи с тем, что вы наверняка хорошо знакомы с конкурентами :-) у меня вопрос — какой аналогичный сервис вы могли-бы порекомендовать на мировом рынке, с невысокой стоимостью входа (недорого для 3-5 сотрудников) — поддержка пользователей в разных странах (ответы на вопросы), ведение базы знаний и желательно еще системы помощи для онлайнового продукта. Можете что-нибудь порекомендовать?
В статье по ссылке сам автор статьи пишет — "… Я не уверен, что я найду им применение в Свифте..."
I agree that curried functions are pretty odd at first. They definitely are an acquired taste! I’m not sure if I will find them useful in Swift, time will tell.
То есть вы предлагаете применить для решения проблемы инструмент, который люди обычно находят странным и редко используют :-)
Получается, чтобы избавиться от массы кода по обработке ошибок, код нужно структурировать в виде как можно более длинной последовательности вызовов функций с одним параметром, а всякие неудобные дополнительные параметры прятать каррированием — насколько легко такой код будет читать?
Очень упрощенный пример… Как оно в реальной жизни будет работать, когда функции не будут такие замечательные — обязательно с одним параметром? Я подозреваю, что этих проверок switch + Success + Failure будет как проверок «if( res != NULL )» в С, или не будет вообще (оставят без проверок) — уж больно многословные и код загромождают.
Как по мне, лучше exceptions для обработки ошибок пока ничего не придумали.
Выглядит слишком сложно и непрактично, по-моему.
А оригинальная подробная классификация — вообще мрак. Классификация должна быть достаточно простая и логичная, чтобы не надо было сверяться со специальным документом на каждый новый открытый баг.
Только категории Дизайнерские и Документации понятны простому смертному, а все остальные категории нуждаются в расшифровке.
В результате может получиться, что только один человек в конторе будет знать, что какая категория означает, а все остальные привыкнут тупо ставить Комбинированную.
Немного более подробно:
Категория Логические перекрывается частично Технической и частично Дизайном — сама по себе она невнятная.
Категория Локализованные — название очень неинтуитивное, хотя идея и понятна.
Категория Соотношения — тоже очень мутная.
При создании категоризации нужно плясать от того, для чего (принятия каких решений или какого анализа) категоризация нужна, и кто будет отвечать за назначение категорий. В данном случае это явно не QA, так как предложенные категории слишком технические. А зачем они нужны программерам — не совсем понятно.
Мы не отказались. Мы его для продакшн серверов используем — он для южной америки наиболее подходит, с нашей точки зрения. А вот резервные копии мы постарались разместить в ЦОДе, наиболее удаленном от других ЦОД-ов, которые мы используем. И по возможности подальше от цунами и землятрясений.
мы как-то выбирали ЦОД для резервного копирования, и один из вариантов был в Далласе, где стоят часть продакшн серверов. С одной стороны, было прикольно увидеть практически моментальное копирование файлов между двумя разными облачными провайдерами. С другой, сразу сказали — «нафиг, нафиг», и выбрали другой штат.
И менеджеров/HR-ов на другой ресурс.
Дизайнеров/графиков/писателей документации — тоже нафиг. И тестеров — они вообще с разработкой рядом не стояли…
А если серьезно, то решение, со всем уважением к редакции, выглядит серьезной ошибкой в позиционировании ресурса — большАя часть активной аудитории (как читателей так и писателей) теряется, и Хабр становиться все более скучным…
Вынос рекламных обзоров гаджетов и политики на GT (который многие вообще не открывают) еще был обоснован, но убрать туда разработку железа — это не правильно.
Я лично на GT заглядывал несколько раз, но так и не прижился… и многие GT игнорируют.
Пользуемся NewRelic но он не очень подходит для мониторинга большого числа серверов (дорого на каждый сервер ставить deep-dive монитор), а бесплатный монитор серверов не ловит многие проблемные ситуации.
Эти разные диаграммы — просто вынос мозга.
На каждую новую диаграмму приходится тратить кучу времени, чтобы понять, как ее расшифровать…
В смысле, опрос-то хороший, и информация полезная, но экперименты с диаграммами отбивают желание его читать примерно после трети статьи.
В тех-поддержку пробовали писать, но безрезультатно…
Или еще en.wikipedia.org/wiki/The_Sharing_Knife — великолепный автор и отлично прописанный мир и герои.
У конкурентов языки стоят $50 за агента в месяц — самое дешевое, что пока нашел
насчет «маленького рассказа» — это сильно!!!
То есть вы предлагаете применить для решения проблемы инструмент, который люди обычно находят странным и редко используют :-)
Получается, чтобы избавиться от массы кода по обработке ошибок, код нужно структурировать в виде как можно более длинной последовательности вызовов функций с одним параметром, а всякие неудобные дополнительные параметры прятать каррированием — насколько легко такой код будет читать?
Я не ради холивара — я понять пытаюсь…
Как по мне, лучше exceptions для обработки ошибок пока ничего не придумали.
А оригинальная подробная классификация — вообще мрак. Классификация должна быть достаточно простая и логичная, чтобы не надо было сверяться со специальным документом на каждый новый открытый баг.
Только категории Дизайнерские и Документации понятны простому смертному, а все остальные категории нуждаются в расшифровке.
В результате может получиться, что только один человек в конторе будет знать, что какая категория означает, а все остальные привыкнут тупо ставить Комбинированную.
Немного более подробно:
Категория Логические перекрывается частично Технической и частично Дизайном — сама по себе она невнятная.
Категория Локализованные — название очень неинтуитивное, хотя идея и понятна.
Категория Соотношения — тоже очень мутная.
При создании категоризации нужно плясать от того, для чего (принятия каких решений или какого анализа) категоризация нужна, и кто будет отвечать за назначение категорий. В данном случае это явно не QA, так как предложенные категории слишком технические. А зачем они нужны программерам — не совсем понятно.
Если XP удачная, Vista неудачная, 7 удачная, 8 неудачная, то 9 должна была быть удачной, а 10 снова неудачной! Они отказались от своей удачи!!!