А у меня обратное мнение. Пользуемся Bamboo в связке с Jira-Confluence-Bitbucket. Если честно после Jenkins, просто раем показался. :) TeamCity не пробовал пощупать по настоящему, поэтому не могу сказать за его удобство.
Что сделать в Bamboo проще:
— разделение стадий сборки и деплоя
— удобный и понятный интерфейс (субъективно)
— контроль версионности
— git-workflow из коробки
Минус я вижу только один — действительно маленькое сообщество и небольшое количество плагинов. Хотя на самом деле написать свой плагин дело пары тройки дней. Мы, например, написали плагин деплоя сборки на сервера Amazon AWS через OpsWorks. Работает вполне прилично.
Может все таки поделитесь кодом как Вы измеряли скорость и что показали замеры в числах? Пока выглядит очень голословно.
И по сути заметки: первый же результат в гугле выдал ответ на stackoverflow, с которым я полностью солидарен. В 99% случаев String.valueOf подойдет на ура.
Спасибо, как раз таких разборов и не хватает в различных гайдах и туториалах, особенно для людей не-художников.
Ну и присоединяюсь ко всем комментаторам, ностальгия по старым игрушкам пробила нехилая :)
Да, я понимаю, что это разработчики nginx. Но ведь согласитесь, что с точки зрения архитектуры, эти задачи находятся на логическом (бизнес) уровне приложения. Мне как то странно думать, что веб сервер, в задачи которого входит отдача статического контента и проксирование, будет вместо приложения рулить роутингом или авторизацией…
Единственное что приходит на ум в качестве примера использования таких модулей, это legacy код, который не можешь физически поправить, но при этом позарез нужен именно nginx. Но такие случаи достаточно редки в общей массе применений, поэтому поддержать это на уровне ядра… Ну не знаю, тот же Lua в модуле и никому не мешает. У кого есть надобность, тот и поставил и использует вполне осознанно.
Вроде везде черным по белому пишут, что на nginx не надо программировать. Не сталкивался с ситуацией, когда можно было бы реализовать какую либо фичу только программированием в конфигах… Поправьте, если это не так.
Огромное спасибо, введение очень наглядное и понятное, буквально «на пальцах», но не пропущены технические детали (я хоть и не спец в этой области, но просветление настало). Да и Ваша реализация описана не хуже.
Побольше бы таких статей!
Ну я все таки верю, что человек, который пишет про Agile книги и продает их, не с потолка берет эти сведения, у него наверняка есть аргументы, почему так.
Тем не менее, Вы правы, что это просто взгляд, а не истина, которой следует идти. Повторюсь, своя голова у всех должна быть :)
Подходов вагон и маленькая тележка, конечно нужно с умом подходить. Если статистика для большинства, это не значит, что подход подойдет именно Вам.
Не согласен по поводу правил. Правила, или если хотите «рецепты» или «подходы», очень нужны и важны. Это обмен опытом, не представляю как можно без него представить ИТ индустрию.
Здесь может быть в другом проблема и размер тут не при чем — затраты на поддержку автоматизированного тестирования не входит в бюджет (или признаны слишком большими для такого проекта). Возможна также некомпетентность отдельных руководителей.
Давайте разберем Ваши задачи по полочкам:
1) Анимационные эффекты — только ручное, трудоемкость невысокая (на уровне «открыл, посмотрел, зафиксировал»).
2) Удобство использования, по идее, должно быть заложено на этапе проектирования интерфейса и затраты тестирования должны быть отнесены на этот этап.
3) и 4) Отображение картинок, видео и «поехавшая верстка» см. п. 1)
В итоге весь класс задач, можно охарактеризовать, как Вы верно подметили, «визуальной составляющей», т.е. той, что требует людских глаз для оценки. В вашем проекте 50% времени тестировщики выполняют такую работу? Это вполне возможно для определенных категорий проектов (игры, анимационные приложения), но все таки в общей доле проектов это не большинство. А цифры в пирамиде приведены именно статистически, т.е. для большинства.
Что касается проектов с моим участием, то они частенько сложнее двух кнопок и формы. Мы стараемся двигаться в направлении автоматизации по похожей схеме и это дает ощутимый эффект.
Абсолютно согласен с автором. Из опыта могу сказать, что подход с юнит-тестами + автоматизированным тестированием + немного ручного тестирования дает очень большой качественный эффект. Если это еще стоит и на рельсах CI, то эффект можно смело умножать на два.
Я считаю, роль тестировщика должна быть одной из ключевых в команде, поскольку только он может сказать «продукт готов, можно выпускать».
Вопрос не холивара ради: зачем к именам методов добавлять префикс «fn»? Не первый раз просто с подобным сталкиваюсь, к чему эти лишние символы и чем не угодил «getSlotInfo» и «getSlotList»?
И еще вопрос, не пробовали с Electron запускать? Под капотом вроде тот же набор (node.js + io.js).
Что сделать в Bamboo проще:
— разделение стадий сборки и деплоя
— удобный и понятный интерфейс (субъективно)
— контроль версионности
— git-workflow из коробки
Минус я вижу только один — действительно маленькое сообщество и небольшое количество плагинов. Хотя на самом деле написать свой плагин дело пары тройки дней. Мы, например, написали плагин деплоя сборки на сервера Amazon AWS через OpsWorks. Работает вполне прилично.
И по сути заметки: первый же результат в гугле выдал ответ на stackoverflow, с которым я полностью солидарен. В 99% случаев String.valueOf подойдет на ура.
Ну и присоединяюсь ко всем комментаторам, ностальгия по старым игрушкам пробила нехилая :)
Единственное что приходит на ум в качестве примера использования таких модулей, это legacy код, который не можешь физически поправить, но при этом позарез нужен именно nginx. Но такие случаи достаточно редки в общей массе применений, поэтому поддержать это на уровне ядра… Ну не знаю, тот же Lua в модуле и никому не мешает. У кого есть надобность, тот и поставил и использует вполне осознанно.
Вроде везде черным по белому пишут, что на nginx не надо программировать. Не сталкивался с ситуацией, когда можно было бы реализовать какую либо фичу только программированием в конфигах… Поправьте, если это не так.
Побольше бы таких статей!
Тем не менее, Вы правы, что это просто взгляд, а не истина, которой следует идти. Повторюсь, своя голова у всех должна быть :)
Кстати оригинал статьи не открывается.
Не согласен по поводу правил. Правила, или если хотите «рецепты» или «подходы», очень нужны и важны. Это обмен опытом, не представляю как можно без него представить ИТ индустрию.
Давайте разберем Ваши задачи по полочкам:
1) Анимационные эффекты — только ручное, трудоемкость невысокая (на уровне «открыл, посмотрел, зафиксировал»).
2) Удобство использования, по идее, должно быть заложено на этапе проектирования интерфейса и затраты тестирования должны быть отнесены на этот этап.
3) и 4) Отображение картинок, видео и «поехавшая верстка» см. п. 1)
В итоге весь класс задач, можно охарактеризовать, как Вы верно подметили, «визуальной составляющей», т.е. той, что требует людских глаз для оценки. В вашем проекте 50% времени тестировщики выполняют такую работу? Это вполне возможно для определенных категорий проектов (игры, анимационные приложения), но все таки в общей доле проектов это не большинство. А цифры в пирамиде приведены именно статистически, т.е. для большинства.
Что касается проектов с моим участием, то они частенько сложнее двух кнопок и формы. Мы стараемся двигаться в направлении автоматизации по похожей схеме и это дает ощутимый эффект.
UPD: даже 10%, на уровне приемочного тестирования это тоже можно выявить, в т.ч. руками.
Я считаю, роль тестировщика должна быть одной из ключевых в команде, поскольку только он может сказать «продукт готов, можно выпускать».
Было бы полезно мне кажется иметь виджет, без лишних зависимостей… Может кто подскажет такой, с опытом реального использования?
Возможно поможет ссылка на документацию по работе с нативными модулями для старта.
И еще вопрос, не пробовали с Electron запускать? Под капотом вроде тот же набор (node.js + io.js).