вы про вклады до 89-го года? У вас был давний вклад… вам было 20 лет… и у вас был давний вклад… интересно…
Этак всех кинули в 89, и как вы верно заметили кинуло государство, и процент там был не рандомный. Я вам больше скажу, в 89 Россия кинула всех. По ГКО заплатили 1%. Вам выплатили менее 1%?
И речь не о том, что вас кинули, а о том, что звучит это как «петя козел» или «жизнь говно, и жать я вам не советую», без контекста это можно произнести только в шутку и только в кругу друзей.
В Ruby on Rails целыми днями меняют имена и всякие штуки.
Никто от этого не страдает, ну те кто отключил варнинги страдают, наверное…
За год после изменений предупреждается разработчик, что та или иная магия будет запрещене, используйте вот это заклинание вместо этого.
Т.о. доступна и та и другая магия в переходной версии.
Это делается просто:
WARNING: function array_map($callback, $input); will be depricated in version 5.x. Use array_collect($input, $callback) instead.
главное желание
По вашему проще доказать сначала что 2+2 = 4 и только потом начать этим пользоваться.
Открою вам тайну, круг круглый — аксиома
Квадрат — фигура с четырьмя гранями — аксиома.
Сначала сущности, потом — все остальное, так устроен весь мир.
TDD — 2003 год
BDD — 2009 год
Проффесионализм? Это нужно просто брать и делать. Мы разработчики, <тут короткое матершинное слово>. Мы должны выкуривать современные тенденции, и радоваться? не когда мы их осваиваем, а когда их встраивают в код нашей любимой IDE, или когда появляется библиотека для нашего любимого фреймворка. Мы к этому моменту должны быть готовы, должны потеть ладони и дрожать коленки в предвкушении.
сейчас 2012 год
Сейчас не некоторые люди тестируют так, а даже джуниоры должны сначала писать тесты а потом писать код.
Идеальный дзен TDD это когда тестирующий код легким движением руки превращается в программу, вот это уже от «уровня профессионализма».
Отдел тестирования?
Если модульное тестирование в автоматическом режиме длится может часами, на 16 ядрах, то сколько небоскребов должен занимать отдел тестирования?
Отдел тестирования по идде должен писать сценарии, прототипы сценариев в том или ином виде должен предоставить заказчик в человекоподобном языке
Отдел тестирования возможно должен проводить ручное тестирование, или разрабатывать сценарии для автоматического псевдоручного тестирования rubygems.org/gems/selenium-webdriver
Скачан 2 милиона 300 тысяч раз, в разные проекты, даже если предположить что только 1/3 этих проектов доживает до стадии запуска девелоперского сервера, то таких систем более 700 тысяч.
Т.о., идеологически, отдел тестирования поставляет сценарии BDD, а разработчики разрабатывают это в стиле TDD. Результаты BDD тестов можно в онлайне показывать заказчику как индикатор работоспособности системы и прогресса разработки.
Можно к каждому BDD сценарию придумывать таски с часиками и выставлять счета для оплаты. Идеальный случай — заказчик знает за какой пиксель на экране он сколько заплатил.
Система, и общий сценарий в которых работаю я:
разработка -> тестирование -> рефакторинг -> тестирование -> релиз
разработка — чтобы работало
тесторование — чтобы работало без ошибок
рефакторинг — чтобы работало быстро
тестирование после рефакторинга — чтобы работало быстро, правильно и без ошибок
И я не гений, это придумал не я, так работают сотни тысяч разработчиков.
Для меня нормально, когда вся система заработала верно и без ошибок, произвести рефакторинг элементов в которых я сделал те или иные допущения, или тех элементов которые были спроектированы не правильно изначально, годы назад.
Т.е. результат, когда код узла стал занимать вместо 1000 строк — 300, стал работать на 15% быстрее, тесторование после рефакторинга прошло сразу. Рефакторинг длился 40 минут.
Мы то знаем, что если система заработала сразу, то это означает, в системе есть ошибка. Но отладка после успешного тестирования рецессивных багов заняла еще 20 минут.
Мне не кажется, что на оптимизацию неэффективно потратить час рабочего времени. А зарание всего предусмотреть нет реальной возможности.
Паттерны вытекают не из них. ActiveRecord бал описан Фуллером еще в 2003 году, Zen только начал его использовать. Database Schema Migration тоже древний труд. Паттерны реализовываются в фреймворках, а не наоборот. Тот же REST, TDD и BDD использовались вне фреймворков в начале. Подобие MVC есть даже в 1C-бухгалтерия. Паттерны не вытикают из фреймворков. И любое изящное решение внутри фреймворка нельзя называть паттерном.
С такой интенсивностью вентиляции входить можно тольков свитере и с бородой, строгий отбор инженеров у заказчика. Чтобы мог полный рабочий день в этих морозильниках работаь.
Я не совсем понял, вы согласны или нет.
Мы спорим или об одном и том-же. Если ИП-шнику нечего делать он ничего не получит по договору. Есть противоречие или нет?
Это в современной трудовой практике принято разработку ПО рассматривать как трудовую деятельность. Если бы контора занималась разработкой ПО — согласен. Если конторе для ведения профильной деятельности нужно разработать ПО и при этом контора нанимает программиста в штат — ошибка и неэффективное расходование средств. Нужно покупать услуги по разработке ПО. Конкретная услуга, для получения конкретного продукта, с конкретной целью, конкретными сроками и расчитанным бюджетом.
Абсолютно согласен!
Я умышленно покупаю автомобиль с меньшей мощностью двигателя, чтобы платить меньше налогов.
Умышленная минимизация налогооблагаемой базы — законодательный беспредел! Надо поувольнять всех наших законотворцев.
Этак всех кинули в 89, и как вы верно заметили кинуло государство, и процент там был не рандомный. Я вам больше скажу, в 89 Россия кинула всех. По ГКО заплатили 1%. Вам выплатили менее 1%?
И речь не о том, что вас кинули, а о том, что звучит это как «петя козел» или «жизнь говно, и жать я вам не советую», без контекста это можно произнести только в шутку и только в кругу друзей.
Никто от этого не страдает, ну те кто отключил варнинги страдают, наверное…
За год после изменений предупреждается разработчик, что та или иная магия будет запрещене, используйте вот это заклинание вместо этого.
Т.о. доступна и та и другая магия в переходной версии.
WARNING: function array_map($callback, $input); will be depricated in version 5.x. Use array_collect($input, $callback) instead.
главное желание
Открою вам тайну, круг круглый — аксиома
Квадрат — фигура с четырьмя гранями — аксиома.
Сначала сущности, потом — все остальное, так устроен весь мир.
user.destroy
user.followers.remove
user.comments.last.destroy
Пожалуйста, опишите это без ооп, и чтобы всем было понятно
BDD — 2009 год
Проффесионализм? Это нужно просто брать и делать. Мы разработчики, <тут короткое матершинное слово>. Мы должны выкуривать современные тенденции, и радоваться? не когда мы их осваиваем, а когда их встраивают в код нашей любимой IDE, или когда появляется библиотека для нашего любимого фреймворка. Мы к этому моменту должны быть готовы, должны потеть ладони и дрожать коленки в предвкушении.
сейчас 2012 год
Сейчас не некоторые люди тестируют так, а даже джуниоры должны сначала писать тесты а потом писать код.
Идеальный дзен TDD это когда тестирующий код легким движением руки превращается в программу, вот это уже от «уровня профессионализма».
Отдел тестирования?
Если модульное тестирование в автоматическом режиме длится может часами, на 16 ядрах, то сколько небоскребов должен занимать отдел тестирования?
Отдел тестирования по идде должен писать сценарии, прототипы сценариев в том или ином виде должен предоставить заказчик в человекоподобном языке
Отдел тестирования возможно должен проводить ручное тестирование, или разрабатывать сценарии для автоматического псевдоручного тестирования
rubygems.org/gems/selenium-webdriver
Скачан 2 милиона 300 тысяч раз, в разные проекты, даже если предположить что только 1/3 этих проектов доживает до стадии запуска девелоперского сервера, то таких систем более 700 тысяч.
Т.о., идеологически, отдел тестирования поставляет сценарии BDD, а разработчики разрабатывают это в стиле TDD. Результаты BDD тестов можно в онлайне показывать заказчику как индикатор работоспособности системы и прогресса разработки.
Можно к каждому BDD сценарию придумывать таски с часиками и выставлять счета для оплаты. Идеальный случай — заказчик знает за какой пиксель на экране он сколько заплатил.
разработка -> тестирование -> рефакторинг -> тестирование -> релиз
разработка — чтобы работало
тесторование — чтобы работало без ошибок
рефакторинг — чтобы работало быстро
тестирование после рефакторинга — чтобы работало быстро, правильно и без ошибок
И я не гений, это придумал не я, так работают сотни тысяч разработчиков.
Для меня нормально, когда вся система заработала верно и без ошибок, произвести рефакторинг элементов в которых я сделал те или иные допущения, или тех элементов которые были спроектированы не правильно изначально, годы назад.
Т.е. результат, когда код узла стал занимать вместо 1000 строк — 300, стал работать на 15% быстрее, тесторование после рефакторинга прошло сразу. Рефакторинг длился 40 минут.
Мы то знаем, что если система заработала сразу, то это означает, в системе есть ошибка. Но отладка после успешного тестирования рецессивных багов заняла еще 20 минут.
Мне не кажется, что на оптимизацию неэффективно потратить час рабочего времени. А зарание всего предусмотреть нет реальной возможности.
Мы спорим или об одном и том-же. Если ИП-шнику нечего делать он ничего не получит по договору. Есть противоречие или нет?
Я умышленно покупаю автомобиль с меньшей мощностью двигателя, чтобы платить меньше налогов.
Умышленная минимизация налогооблагаемой базы — законодательный беспредел! Надо поувольнять всех наших законотворцев.