Нужно писать документацию ( а некоторые языки поддерживаются хуже других и писать приходится больше ) и попрыгать с бубном немного, чтобы все заработало — по-моему кой-какая плата присутствует.
Вероятно в том, что без особого напряга получается приличная документация, с аналогом тегов, поиском и в html-формате. Которая, кроме всего прочего, лежит рядом с кодом и обновляется автоматом.
Вам этого мало? :)
хм. оффтоп конечно, но что из приличной литературы по архитектуре ПО на русском посоветуете?
Уж больно похоже на то, что в теме вы очень плотно, глупо не воспользоваться ситуацией и не спросить :)
И еще один вопрос, если позволите — инверсия контроля и создание объекта-можордома, который строит и возвращает нам любые иные объекты (не совсем абстрактная фабрика, но что-то типа) — плохая идея? Что-то меня в ней смущает, а без нее никак не пойму правильного применения Bread::Board.
ммм… идеально, но не получится. В программировании нет ничего простого, а разрезание на кучу маленьких частей не упрощает итоговое приложение, сложность просто «размазывается» + накладные расходы на взаимодействие (в сложностном смысле, не трогаем производительность).
Кроме того не будем забывать, что приложения пишутся не сферическими программистами в ваккуме для самовыражения, а, в основном, по требованию бизнеса.
А для бизнеса: быстрее и надежнее лучше, чем дешевле.
с точки зрения бизнеса лучше гарантировано терять 5 штук баксов на еще один сервер, потому что медленно, чем неожиданно 50 штук, из-за того что внедренная фича все сломала или 500 штук, потому что требование не может быть реализованно архитектурно вообще.
С другой стороны, если подумать — Method::Signatures все же overkill. ИМХО пакет = класс, так к чему плодить сущности и упихивать все внутря, раздувая кавычечки?
Хороший обзор, но!
черт побери, за вот это sub make_noise {
my $self = shift;
say $self->{name}, " says: ruff-ruff!";
}
в приличном обществе можно схлопотать по шапке.
даже маленький тестовый пример не повод плевать на MVC.
Забавляют реакции из серии «лишний код», «зависимости» и тэдэ.
Когда вы начинаете писать реально сложное приложение, которое должно быть расширяемым, управляемым и предсказуемым в процессе «жизненного цикла», то в итоге приходишь к сеттерам\геттерам, контролю и валидации данных объекта, исключеним, ролям, аспектам, инверсии зависимостей и всему остальному «монструозному».
Задумайтесь на минуточку — «монструозная» Java — чуть ли не стандар de facto для большого бизнеса.
Ширее надо смотреть на вещи, и не заниматься субоптимизацией прототипов.
ну, к тому что я наглый врун и форменный невежда я еще и жуткий скряга, так что денег не будет, можете закачать свой комментарий обратно. :)
Не пользуйтесь. Нет, не так — конкретно Вам я запрещаю пользоваться этим инструментом. Кашрут надо блюсти.
«несколько тысячь языков программирования.» — ну да. Есть еще русский. Хотите об этом поговорить?
Ура! да, Вы правильно меня поняли, речь идет о js(only). Ну или покажите мне финт ушами с нативным C/C++/Objective-C, который исполнит мой FF.
но, тестировать GET часть RESTful интерфейса можно, но согласитесь, что не для этого инструмент предназначен, а как раз наоборот. Иначе зачем тело поста?
Если я — наглый врун (хвалите меня, хвалите!), то вы последний буквоед, лечащий по фотографии.
request body означает по факту «часть после ?» так как сделать запрос можно только GET, у которого body нет (в части реализации оного браузером).
Если религия не позволяет — ну не используйте вы это поле, представьте, что пишите RESTful и пишите свой путь до данных только в верхней части.
Дальше, jsonp вааще тогда противопоказан RESTful-евангелистам, бо добавляет богомерзкий ?callback=[whatever] в незапятнанный всякой дрянью URI. Так что или флеш, или фреймы — ваше все, или CORS (может быть).
Как это называется — астронавты? Ага?
Но название статьи не соответсвует содержанию. Назовите тогда «Тестировани веб сервисов».
Не могу, так мы смутим остальных, которые будут интересоваться, как же этим можно протестировать комментарии в их любимой жежешечке или вконтактик.
И, потом, инструмент позволяет проверить работоспособность GET-части RESTFul-сервиса, это Вы отрицать не будете?
А инкриминировать мне создание сервиса, который не REST? Ведь я никакого сервиса не делал :)
Так что я перед законом чист.
то что у меня тут написано — это строка поиска, разбитая на две части.
И тестировать этим, что тут написано, можно что угодно, что может отдать jsonp ответ. Совершенно без разницы, как будет выглядеть запрос.
Ну и так далее.
Аааа… а вот скажите мне, как Вам представляется возможным отдать из браузера постом на любой сервис данные и получить что-то вменяемое и отображаемое в ответ?
Вот после этого будем обсуждать Ваши «так далее», а то получается «не читал, но осуждаю».
Вам этого мало? :)
Уж больно похоже на то, что в теме вы очень плотно, глупо не воспользоваться ситуацией и не спросить :)
И еще один вопрос, если позволите — инверсия контроля и создание объекта-можордома, который строит и возвращает нам любые иные объекты (не совсем абстрактная фабрика, но что-то типа) — плохая идея? Что-то меня в ней смущает, а без нее никак не пойму правильного применения Bread::Board.
PS. трехтомник Кнута для меня невкуряем.
Кроме того не будем забывать, что приложения пишутся не сферическими программистами в ваккуме для самовыражения, а, в основном, по требованию бизнеса.
А для бизнеса: быстрее и надежнее лучше, чем дешевле.
с точки зрения бизнеса лучше гарантировано терять 5 штук баксов на еще один сервер, потому что медленно, чем неожиданно 50 штук, из-за того что внедренная фича все сломала или 500 штук, потому что требование не может быть реализованно архитектурно вообще.
use MooseX::FollowPBP;
?
За MooseX::StrictConstructor спасибо, ага.
черт побери, за вот это
sub make_noise {my $self = shift;
say $self->{name}, " says: ruff-ruff!";
}
в приличном обществе можно схлопотать по шапке.
даже маленький тестовый пример не повод плевать на MVC.
Когда вы начинаете писать реально сложное приложение, которое должно быть расширяемым, управляемым и предсказуемым в процессе «жизненного цикла», то в итоге приходишь к сеттерам\геттерам, контролю и валидации данных объекта, исключеним, ролям, аспектам, инверсии зависимостей и всему остальному «монструозному».
Задумайтесь на минуточку — «монструозная» Java — чуть ли не стандар de facto для большого бизнеса.
Ширее надо смотреть на вещи, и не заниматься субоптимизацией прототипов.
для github нужно только git push.
ну и да, тикеты и реквесты с форками рулять.
я стену штукатурю.
может еще расскажите, что и флеш плезен? :) и гиф анимированный?
сроду эти технологии не использовались в мирных целях…
Adblock Plus
ставится на Firefox, Chrome и последний Safari.
ну, может и еще куда, но я только это и юзаю
Или как бронебойная артилерия — прокся с privoxy, но с ней любви много, пока все настроишь. Я раньше юзал, но надоело.
see no evil
Не пользуйтесь. Нет, не так — конкретно Вам я запрещаю пользоваться этим инструментом. Кашрут надо блюсти.
«несколько тысячь языков программирования.» — ну да. Есть еще русский. Хотите об этом поговорить?
Ура! да, Вы правильно меня поняли, речь идет о js(only). Ну или покажите мне финт ушами с нативным C/C++/Objective-C, который исполнит мой FF.
Если я — наглый врун (хвалите меня, хвалите!), то вы последний буквоед, лечащий по фотографии.
request body означает по факту «часть после ?» так как сделать запрос можно только GET, у которого body нет (в части реализации оного браузером).
Если религия не позволяет — ну не используйте вы это поле, представьте, что пишите RESTful и пишите свой путь до данных только в верхней части.
Дальше, jsonp вааще тогда противопоказан RESTful-евангелистам, бо добавляет богомерзкий ?callback=[whatever] в незапятнанный всякой дрянью URI. Так что или флеш, или фреймы — ваше все, или CORS (может быть).
Как это называется — астронавты? Ага?
Не могу, так мы смутим остальных, которые будут интересоваться, как же этим можно протестировать комментарии в их любимой жежешечке или вконтактик.
И, потом, инструмент позволяет проверить работоспособность GET-части RESTFul-сервиса, это Вы отрицать не будете?
А инкриминировать мне создание сервиса, который не REST? Ведь я никакого сервиса не делал :)
Так что я перед законом чист.
И тестировать этим, что тут написано, можно что угодно, что может отдать jsonp ответ. Совершенно без разницы, как будет выглядеть запрос.
Ну и так далее.
Аааа… а вот скажите мне, как Вам представляется возможным отдать из браузера постом на любой сервис данные и получить что-то вменяемое и отображаемое в ответ?
Вот после этого будем обсуждать Ваши «так далее», а то получается «не читал, но осуждаю».
Право слово, Ваша категоричность впереди :)
мопедAPI emspost.ru.Понятия не имею, почему у них так.