рубиновая среда разработки
Вы можете перехватить ведение журнала, предоставив io.Writer - log.SetOutput . Там вы можете просто проверить, является ли записываемая строка тем, что вам нужно отследить и записать трассировку стека делегированному завернутому модулю записи.
Вот пример игровой площадки: https://play.golang.org/p/2bClt2JBuFs
Обратите внимание, что получение текущей трассировки стека не является бесплатным, оно вызывает остановку и может резко замедлить ваше приложение. Если у вас есть приложение, которое создает большой объем журналов, я бы рекомендовал ограничить количество отслеживаемых данных (например, трассировать только первое совпадение или N раз в секунду / минуту)
package main
import (
"fmt"
"log"
"os"
"regexp"
"runtime/debug"
)
func main() {
log.SetOutput(NewLogInterceptor(LogInterceptionCheck{Pattern: ".*Some.*", Description: "with 'Some' substring"}))
f1()
log.Println("message that is not traced")
}
func f1() {
log.Println("Some message")
}
type LogInterceptor struct {
target *os.File
checks []LogInterceptionCheck
}
type LogInterceptionCheck struct {
regexp *regexp.Regexp
Pattern string
Description string
}
func NewLogInterceptor(checks ...LogInterceptionCheck) *LogInterceptor {
for i := 0; i < len(checks); i++ {
each := checks[i]
compiled, e := regexp.Compile(each.Pattern)
if e != nil {
log.Fatalf("cannot compile regexpt [%s]: %s", each, e)
}
checks[i].regexp = compiled
}
return &LogInterceptor{os.Stderr, checks}
}
func (interceptor *LogInterceptor) Write(p []byte) (n int, err error) {
i, err := interceptor.target.Write(p)
// use loop because it is faster and generates less garbage compared to for-range loop
for i := 0; i < len(interceptor.checks); i++ {
check := interceptor.checks[i]
if check.regexp.Match(p) {
_, e := fmt.Fprintf(interceptor.target, ">>>> Printing stacktrace [%s]\n", check.Description)
if e != nil {
log.Fatalf("cannot write: %s", e)
}
_, e = interceptor.target.Write(debug.Stack())
if e != nil {
log.Fatalf("cannot write stacktrace: %s", e)
}
break
}
}
return i, err
}
11 ответов
Я настоятельно советую не разрабатывать на Windows. Зачем? Во-первых, с каждым обновлением в Windows происходит множество проблем, и большинство создателей гемов или плагинов не используют окна, поэтому они не заботятся об окнах и не запускают на них тесты (есть несколько громких имен люди, которые упали, сказали, что окна это не их проблема, это ваша). Вы обнаружите, что проблемы * nix против Windows будут кусать вас в задницу снова и снова. Косые черты имен путей, незначительные различия в реализациях ssh, проблемы с консолью и шрифтами, rubygems, capistrano и т. Д.
Через некоторое время произойдет то, что у вас всегда будет этот голос в затылке каждый раз, когда вы должен отладить что-то, говоря: «Это проблема только в Windows?» и этот маленький голос стоит вам разряжать батарею каждый день.
Маки стоят дороже с точки зрения начальных долларов (которых, к сожалению, у меня нет), а платформы linux - это более дорогие условия, чтобы потратить день или два, пытаясь заставить работать ваше беспроводное соединение, но это авансовые затраты на единовременное использование. Тяжелая небезопасность использования Windows for Rails - это постоянные расходы. По крайней мере, до тех пор, пока сообщество не начнет отвергать вещи, которые не являются действительно кроссплатформенными.
В качестве примера рассмотрим огурец. По какой-то причине тестовая среда зависит от конкретной конфигурации консоли, недоступной в Windows. Таким образом, чтобы использовать его в Windows, вы должны изменить шрифт в консоли и изменить кодовую страницу в консоли. В противном случае буква «а» исчезнет из всех выходных данных. Зачем? Потому что он отлично работает для * nix систем и дает вам красивые цвета (я думаю, что это огромный недостаток и очень плохой выбор дизайна, даже если вы игнорируете окна).
Вы также будете чувствовать себя парнем, который пукнул в лифте каждый раз, когда вы поднимаете вопрос Windows.
Я говорю все это как кто-то, кто в настоящее время использует Windows для своей платформы разработки. Эй, что это за запах?
[позднее редактирование: Ruby также работает в Windows примерно в 3 раза медленнее. Это повлияет на вашу готовность проводить тесты постоянно и повредит вашему циклу обратной связи TDD]
Я занимался разработкой легких рельсов как для OSX, так и для Linux (Ubuntu), и я обнаружил, что различия почти незаметны (с точки зрения ruby и rails ... очевидно, что окружение рабочего стола сильно отличается между двумя ОС).
Как уже говорили другие, большинство уроков ruby / rails, гемов, плагинов и т. Д. Ориентированы на системы типа Unix, поэтому я могу предположить, что могут быть некоторые досадные икоты, пытающиеся заняться разработкой ruby / rails в Windows, если, конечно, Вы используете IronRuby. : -)
Альтернативой настройки среды Unix для разработки на Rails является небольшая проблема - запустить один из более простых в использовании дистрибутивов Linux, например Ubuntu или Fedora, под ПО для виртуализации, таким как VMWare, VirtualBox, VirtualPC и т. Д.
I agree with many of the previous posts that Rails on Windows can be an issue. Its simply the case that many people developing for Rails are on Macs or Linux and as a result Windows bugs are not found, this is particularly an issue with plugins.
One issue with Rails is IDEs. TextMate on the Mac seems to be a popular choice, yet Linux and Windows options are pretty fragmented. Normally I wouldn't worry about this, but I have found that Rails becomes much more manageable when you have IDE support. In general there are lots of files located in a reasonably complex directory structure so having an IDE which allows you to easily find files your looking for is an awesome productivity boost.
Another thing you may want to consider is what your deployment environment looks like. For example, may people deploy there Rails apps on Linux servers. In that case, you may be able to skirt around bugs by developing on OS X, but unfortunately those bugs will crop up when you go to deploy your new software. That is the last place you want to be debugging code. Of course you should be testing your code in a staging environment first, but all too often people skip this step.
Я рекомендую не использовать Windows при разработке приложения, которое впоследствии будет развернуто в системе Linux. Если вы разрабатываете приложение для практики, с Windows все в порядке.
Проблема в том, что если вы нацелены на Linux, то вам понадобится полный стек на компьютере разработчика: веб-сервер, dbms. , возможно, memcached и т. д. Хотя все это можно загрузить в Windows (я это сделал), это займет больше времени, чем на Linux-машине, будет медленнее, и вам будет сложнее найти помощь, когда что-то не так. 't work.
Кроме того, вы можете столкнуться с проблемами поддержки гемов и плагинов в Windows. Например, \ вместо / для путей к каталогам и прочих странностей. В то время как rubyists будут пытаться быть полезными, поддержка Windows иногда ограничена, так как большая часть RoR выполняется на компьютерах Mac или Linux. Например, у Capistrano были проблемы с запуском в Windows (теперь они могут быть исправлены).
В качестве альтернативы вы можете использовать Windows в качестве настольного компьютера, но использовать машину Linux в качестве сервера разработки для запуска приложения. Любой старый компьютер будет работать под Linux просто отлично. Используйте samba для удаленного доступа и редактирования файлов с вашего компьютера с Windows. Машина Linux не нуждается в отображении, вы будете использовать ее только удаленно.
Просто измените config / environment / development.rb вашего приложения, включив в него
config.action_controller.consider_all_requests_local = true
, чтобы вы могли видеть следы стека из браузера, запущенного на вашем компьютере с Windows. .
С уважением,
Ларри
Ruby on Rails works well on all platforms, but tool support varies. For instance, TextMate is a favorite editor amongst Rubyists, and it's Mac only. You'll be able to find lots of helpful tools for working with RoR in TextMate, so it might be best to do RoR development on a Mac.
I use Mac and Linux myself.
A Unix based system will offer you a path of lest resistance as all gems are available/compilable on these systems, which isn't as easy on a Windows machine. It's not impossible on Windows but you'll spend more time getting it to work rather in some cases rather than doing work.
Of those Unix systems my preferred is a Mac, it's got all the Unix power as well as all the interface niceties that can be lacking from your linux system, and of course I couldn't live without my daily dose of TextMate, so Mac it is.
Doesn't matter, If you're a purist then your dev environment should as closely match your production enviroment as possible with regard to Operating System and version of the Ruby and Rails. But really it doesn't matter much.
Некоторые гемы работают на Mac, но не некоторые разновидности Linux (например, gitjour, когда я в последний раз пробовал).
Использование Mac может быть хорошим или плохим,
Не имеет значения, с чем тебе удобнее всего. Я сделал все три.
Я полагаю, что Windows немного неудобна из-за того, что она не основана на Unix, CLI немного более неудобен.
(Но если вы используете такой инструмент, как NetBeans, вы не действительно даже CLI очень нужен)
В поисках ответа на этот вопрос из-за того, что при разработке на Ruby мне всегда приходилось лазить по окнам в поисках работы, я могу сказать, что если у вас есть возможность, используйте Linux или Mac. Я официально начал использовать Ubuntu 9.04 с сегодняшнего дня, и вот причины, по которым:
1) Не могу выполнять какие-либо действия по ssh, такие как использование Capistrano, vlad, создание драгоценных камней для rubyforge и т. Д. Вы можете делать это с помощью cygwin , но это такая головная боль, чтобы использовать cygwin и окна, работающие для всего.
2) Последней каплей была попытка запустить фоновые задачи в приложении rails только для того, чтобы понять, что окна не могут разветвлять процессы .. .. даже не стал возиться с cygwin для этого, просто перешел на Ubuntu, так что мне не нужно продолжать работать над этими проблемами.
Ubuntu 9.0.4 довольно популярный,
Я начал свою жизнь как программист в 1981 году на ранних системах Unix. Я оставался чистым человеком Unix до 1995 года. Затем произошли «разные вещи» (владение бизнесом), и Windows вошла в мою жизнь.
Итак, в 2007 году я начал изучать RoR, чистую Windows. Я развернулся на Joyent, то есть на Solaris. Я успешно разработал два больших приложения, разработанных для Windows и развернутых на Solaris / Apache / Mongrel, без серьезных инцидентов.
Единственная проблема Windows, которую я когда-либо вспоминал, это то, что мне пришлось принудительно переключать чтение и запись файловой системы в двоичный режим, чтобы исправить проблему «разработка» и «развертывание».
Я, честно говоря, не вижу проблем с разработкой в Windows и развертыванием в Unix. Но у меня был обширный опыт работы с Unix, я не уверен, что все было бы так же, если бы я не знал Unix.
Кроме того, я буду работать только над приложениями RoR, которые создаю для своего бизнеса. Мне никогда не нужно будет создавать какие-либо другие приложения RoR, я никогда не буду разрабатывать какие-либо плагины, мне никогда не придется брать на себя другой проект, никогда не будет никого INSIST Я включаю то, что доступно только в то, что плохо работает с моей средой разработки Windows и т. д.
Я бы сказал следующее:
Если вы отвечаете за разработку веб-приложения для своего работодателя, и этот работодатель работает на Windows, это НЕ ДОЛЖНО препятствовать вам рассматривать RoR как платформу. Приложение должно быть развернуто третьей стороной, если только ваш работодатель не достаточно велик, а проект достаточно важен, чтобы гарантировать использование собственных систем Unix.
Так что, если вы знаете SQUAT о Unix, вам МОЖЕТ понадобиться небольшая помощь на этом пути. Если вы используете сторонний хост Rails, посетите их форумы поддержки, убедитесь, что есть люди, желающие и способные обсудить любые проблемы с развертыванием / настройкой и обслуживанием не-Unix человека.
Я приведу вам пример на Joyent: если я хочу запустить миграцию, мне нужно пройти через их графический интерфейс базы данных, войти в базу данных, а затем «выполнить» команду. Хорошо, я получаю простое текстовое поле, в которое я ввожу ввод, предназначенный для оболочки Unix, а именно:
cd / user / myhome / sites / mysite && rake db: migrate RAILS_ENV = production
Это могло быть не так Легко понять, если бы у меня не было опыта работы с Unix.