Естественно. Даже так если система живёт годами но по отдельности её компоненты делаются с нуля, завершаются и про них забывают и они слабо связаны. В вашем случае тесты будут крайне полезны.
У меня приблизительно похожий опыт. Вместо того, что бы тратить время на написание тестов лучше больше уделить внимание качеству кода. В моём деле некоторые ошибки отловленные вручную перед продакшеном не очень страшно, а крупные проблемы точно не попадут в продакшен (а очень мелкие не страшно, и быстро фиксятся). У нас нету модулей или библиотек которые нужно рефакторить при этом оставив нужное поведение, часто в месте с рефакторингом меняется и сами требования (мы что то переделываем когда приходят новые требования). Опять писать заново тесты это тратить время.
Но вот когда я работал над веб приложениями для интранета, с некой бизнес-логикой там уже тестами покрывались множество вещей. Там почти не возникало вопроса: «а зачем они?».
Мне кажется не всем нужны тесты. Понимание когда нужны тесты придёт само, если ты конечно не совсем «дундук». :)
ЗЫ всё это не отменяет тестирование путём прокликивания, и прочей верификации во время самой разработки.
Спасибо вам!
Это первая статья с трезвым взглядом на данную проблематику. А то в последнее время встречаю только фанатов SCRUM или чего то ещё конкретного.
Если форма отправляется через AJAX то перехватить ошибку от СУБД/ORM и вывести её пользователю вполне можно (не теряя контекст). Но на самом деле всё это я привёл только как пример. Вы к примеру сделали вывод, который противоречит данной статье и привели вполне себе веские технические доводы.
MVC слишком абстрактный «патерн», мне кажется он больше путает.
Всё же не аналог. AMQP гарантирует доставку сообщений. Он оперирует понятием «сообщение», а не «запрос» что явно лучше в данной ситуации. D-bus это по сути RPC.
На самом деле концепция «Тощего контроллера, толстой модели» характерна только для бизнес приложений. Большинство же сайтов (СМИ, развлекаловка, да даже форумы) по своей природе просто не нуждаются в переносе логики в модель. У них почти нету «модели» и контролеры не раздуты. 90% запросов это чтение и оно должно работать быстро, если модель увесистая то сразу возникают проблемы с производительностью доступа к БД. В современном вебе (публичном, а не корпоротивном) надо делать что то простое но ОЧЕНЬ быстро, по этому чем меньше абстракций тем лучше. На самом деле MVC это слишком поверхностный взгляд на то, что происходит. Мне кажется куда важнее описывать конкретные абстракции(элементы системы), к примеру: СУБД<->ORM<->Controller->Template. И тут уже проще понять куда и что. К примеру часть валидации можно положить констрейнами в СУБД (Postgres к примеру позволяет просто кучу всего валедировать), часть проверок можно установить в объектах ORM, а что то уже запихнуть в контроллер и даже в template можно через javascript/html5 проводить часть валидации. На этом примере мы видим, что у некоторых задачь нету чёткого места, каждая задача проходит декомпозицию и раскидывается по элементам системы.
Что у вас за видео драйвер? И система big-endian или little-endian? www.opengl.org/sdk/docs/man/xhtml/glReadPixels.xml — что то я таких странностей в спецификации не нахожу.
Используйте GL_UNSIGNED_BYTE и будет вам счастье.
glReadPixels(0,0, SCREEN_WIDTH, SCREEN_HEIGHT, GL_RGB, GL_UNSIGNED_BYTE, output);
А зачем для скриншота RGBA? Можно просто RGB и тогда не будет проблем с сохранением альфа канала. На самом деле веселуха если изображение 8 битное и есть несколько зон в палитре. :)
В Dojo деревья немного запутаны НО лучше чем в ExtJS. Жалко что ваш пример использует старую парадигму без AMD (да и в целом в Dojo 1.8 много вскусняшек).
Потому что эти идиоты решили не использовать Gallium и теперь сидят в ****.
Они там что то начали на LLVM ваять но это ещё ОЧЕНЬ далеко от продакшана. Тогда как вариант на Gallium можно было бы уже использовать.
Я бы всё же посоветовал им для нового чипа уже писать на gallium тогда бы проблем было бы меньше (в том числе и с поддержкой аппаратного видео).
Тогда вам придётся динамически его линковать так как он под LGPL.
Если я не смогу собрать новую Opera сам то нафиг тогда она нужна?
ЗЫ кроме того вам придётся опубликовывать ваш вариант движка который вы подключаете к «интерфейсу». Хром к примеру только периодически синхронизирует свою версию вебкита с общей.
Когда научитесь распознавать образы на изображениях? И сделать поиск по объектам в картинках?
Хотя вижу, что вакансия ещё не закрыта по computer vison.
Интерфейс у Я.Картинок ещё ничего но вот ищет он какойто бред… у меня как минимум есть личные счёты из-за anime-pictures.net/?lang=ru самый крупный из российских ресурсов по этой тематике и 0 представления в яндексе в отличии от гугла. :(
Но вот когда я работал над веб приложениями для интранета, с некой бизнес-логикой там уже тестами покрывались множество вещей. Там почти не возникало вопроса: «а зачем они?».
Мне кажется не всем нужны тесты. Понимание когда нужны тесты придёт само, если ты конечно не совсем «дундук». :)
ЗЫ всё это не отменяет тестирование путём прокликивания, и прочей верификации во время самой разработки.
Это первая статья с трезвым взглядом на данную проблематику. А то в последнее время встречаю только фанатов SCRUM или чего то ещё конкретного.
MVC слишком абстрактный «патерн», мне кажется он больше путает.
www.opengl.org/sdk/docs/man/xhtml/glReadPixels.xml — что то я таких странностей в спецификации не нахожу.
Используйте GL_UNSIGNED_BYTE и будет вам счастье.
glReadPixels(0,0, SCREEN_WIDTH, SCREEN_HEIGHT, GL_RGB, GL_UNSIGNED_BYTE, output);
Они там что то начали на LLVM ваять но это ещё ОЧЕНЬ далеко от продакшана. Тогда как вариант на Gallium можно было бы уже использовать.
Я бы всё же посоветовал им для нового чипа уже писать на gallium тогда бы проблем было бы меньше (в том числе и с поддержкой аппаратного видео).
Если я не смогу собрать новую Opera сам то нафиг тогда она нужна?
ЗЫ кроме того вам придётся опубликовывать ваш вариант движка который вы подключаете к «интерфейсу». Хром к примеру только периодически синхронизирует свою версию вебкита с общей.
К примеру картинка которая якобы на моём сайте: fentazy2.narod.ru/20933.jpg (хотя она явно не на моём)
А ссылка рядом с картинкой ведёт на anime-pictures.net/pictures/view_post/69795?lang=ru (где сооовсем другая картинка)
Что это за бред? Могу скриншот прислать если не верите.
UPD он нашёл preview размером до 150ч150 где то с низу страницы при этом проигнорировал большое preview собственно как и основной размер. Бред.
Хотя вижу, что вакансия ещё не закрыта по computer vison.
Интерфейс у Я.Картинок ещё ничего но вот ищет он какойто бред… у меня как минимум есть личные счёты из-за anime-pictures.net/?lang=ru самый крупный из российских ресурсов по этой тематике и 0 представления в яндексе в отличии от гугла. :(