У меня похожая ситуация сложилась, коллега любит поболтать, только наушники спасают. И не важно сколько девушек в офисе, достаточно хотя-бы одной болтушки и одной которая согласна слушать.
Потому-что «test-driven development» подразумевает что тесты первичны, и код вторичен. Как-бы тесты определяют какой должен быть код.
Возможно если вы пишите код с целью научится писать тесты — то это верно, они первичны, если пишите код с целью развлечься и попробовать новые технологии — тогда это можно назвать «fun-driven development». На недавней конференции red dot кто-то упоминул что у них бывает «conference-driven development» (код пишут чтобы показать на конференции и не выглядеть бездельником), разработчики языка ruby говорили об chrismas-driven development :)
Я считаю что обычно первичны бизнес требования, т.е. делать что-то, быть решением для какой-то проблемы и в том числе, быть легко поддерживаемым, это одно из бизнес требований.
Я считаю что код должен быть написан с целью делать то, что он должен делать, решать проблему. В голове должно быть осознание проблемы, как код должен работать и как потом этот компонент будет использоваться. А потом уже написать тесты которые будет помогать поддерживать код в рабочем состоянии, делать последующий рефакторинг более безболезненым и другим разработчикам проще вникнуть в код.
Я не считаю что тесты вредят проекту, ни в коем случае, но концентрироваться только на тестах и ставить их выше первоначальной задачи может привести к затратам времени. Еще есть мнение что scrum и tdd (или bdd) делают разработку более гибкой, это не всегда так. Вывает что н ужно иногда писать код чтобы посмотреть будет ли это работать и хорошо выглядеть, тогда написание тестов будет тратой времени, и в этом случае включается еще один менеджер или технический руководитель который следит чтобы весь код был покрыт тестами, и пытается доказать что passing тесты и соблюдение scrum важнее.
Посмотрел ваши ссылки и пришел к выводу что разница между теорией и практикой на практике больше чем в теории :)
Думаю вы имеете ввиду «Разделение ответственности», я не открыл принцип для себя, я понял как правильней для меня разделять эти ответственности.
Тогда у вас получается код который написан с целью озеленения тестов, спроектирован чтобы его было легко тестировать. Я считаю что код должен решать бизнес задачи, тесты проверять код и помогать разработчиками быть увереными в их коде (экономить время и нервы на тестирование).
Какое-то время назад я думал что это самое правильное сначала писать тесты и потом писать код который будет работать как задумывалось. И переодически пробовал заставлять себя так делать. Но потом посмотрел это видео www.confreaks.com/videos/3315-railsconf-keynote-writing-software и обдумал этот момент еще раз.
Так-же сталкивался с тестами которые тестируют слишком много, например stub каждый метод внутри тестрируемого компонента, это приводит к тому, что когда код подвергся рефакторингу все эти тесты ломаются потому-что та функция сейчас работает по другому и понять что-то же нужно поправить и зачем вобще эти тесты — сложно. Поэтому я обычно отключаю их и прошу автора тестов решить проблему или выкинуть эти тесты.
Я пришел к подходу делить код на части, это как предприниматель малого бизнеса, по началу делает все сам, и когда задач становится слишком много — поручить их другим людям. Так-же в коде, если один кусок становится слишком большим или начинает решать более чем одну задачу — значит нужно его распилить на части в следующий этап рефакторинга. Тогда код получается легче читаемый и логичный, с проектирован с целью выполнения задачи и быть легко обслуживаемым (maintenance www.youtube.com/watch?v=c-kav7Tf834)
Так-же и тесты писать, тестировать как каждый элемент решает поставленную им задачу, и как все это работает вместе (integration test)
В blackberry10 есть такая возможность, хотя там приложения проходят более строгую проверку и я этой функцией почти не пользуюсь. Не требуется.
Еще он умеет из коробки устанавливать и запускать приложения для андройда, только нужно скачать файл.
p.s. Вобще заголовок вводивт заблуждение «Яндекс.Кит: новая прошивка для смартфонов», более правдоподобно: «Яндекс.Кит: андройд со вкусом яндекса» или «Яндекс.Кит: телефоны с предустановленным якдексом».
Для себя я предпочитаю использовать оригинальный продукт, особенно если его нельзя заменить. Например андройд развивается и будет развиваться, и чем ближе прошивка к первоначальному продукту тем проще с обновлениями и совместимостью. Например samsung, htc и другие компании делают новые телефоны каждые пару месяцев а обновления делать для старых не хотят, потому-что продавать обновления сложно, им выгоднее телефоны продавать. Самому это делать сложно, потому-что исходный код драйверов закрыт.
Мне кажется более честный подход когда новые операционные системы на телефонах делаются с dual-boot.
Ваш Яндекс.Переезд умеет перенести данные из я.фона в обычный телефон? Или только в одну сторону?
«Наша клавиатура самая быстрая по скорости набора среди аналогов.» — очень интересно как вы это измеряли?
«устройства с Яндекс.Китом работают дольше аналогов» — можете рассказать о подробностях и привести цифры. Думаю это актуально для всех андройд телефонов
Отлично дружит. Постоянно использую маленький хаб-зарядник для телефона. Потому-что usb порта только 2 у меня, и если вставить модем то он оба порта закрывает.
Проблем с хабом никаких нет, определяется и начинает работать мгновенно
Готовый html будет выглядеть так:
А что если в шаблонизаторе класс динамически высчитывается? например:
nodejs.org/api/http.html#http_agent_maxsockets
Возможно если вы пишите код с целью научится писать тесты — то это верно, они первичны, если пишите код с целью развлечься и попробовать новые технологии — тогда это можно назвать «fun-driven development». На недавней конференции red dot кто-то упоминул что у них бывает «conference-driven development» (код пишут чтобы показать на конференции и не выглядеть бездельником), разработчики языка ruby говорили об chrismas-driven development :)
Я считаю что обычно первичны бизнес требования, т.е. делать что-то, быть решением для какой-то проблемы и в том числе, быть легко поддерживаемым, это одно из бизнес требований.
Я считаю что код должен быть написан с целью делать то, что он должен делать, решать проблему. В голове должно быть осознание проблемы, как код должен работать и как потом этот компонент будет использоваться. А потом уже написать тесты которые будет помогать поддерживать код в рабочем состоянии, делать последующий рефакторинг более безболезненым и другим разработчикам проще вникнуть в код.
Я не считаю что тесты вредят проекту, ни в коем случае, но концентрироваться только на тестах и ставить их выше первоначальной задачи может привести к затратам времени. Еще есть мнение что scrum и tdd (или bdd) делают разработку более гибкой, это не всегда так. Вывает что н ужно иногда писать код чтобы посмотреть будет ли это работать и хорошо выглядеть, тогда написание тестов будет тратой времени, и в этом случае включается еще один менеджер или технический руководитель который следит чтобы весь код был покрыт тестами, и пытается доказать что passing тесты и соблюдение scrum важнее.
Думаю вы имеете ввиду «Разделение ответственности», я не открыл принцип для себя, я понял как правильней для меня разделять эти ответственности.
Какое-то время назад я думал что это самое правильное сначала писать тесты и потом писать код который будет работать как задумывалось. И переодически пробовал заставлять себя так делать. Но потом посмотрел это видео www.confreaks.com/videos/3315-railsconf-keynote-writing-software и обдумал этот момент еще раз.
Так-же сталкивался с тестами которые тестируют слишком много, например stub каждый метод внутри тестрируемого компонента, это приводит к тому, что когда код подвергся рефакторингу все эти тесты ломаются потому-что та функция сейчас работает по другому и понять что-то же нужно поправить и зачем вобще эти тесты — сложно. Поэтому я обычно отключаю их и прошу автора тестов решить проблему или выкинуть эти тесты.
Я пришел к подходу делить код на части, это как предприниматель малого бизнеса, по началу делает все сам, и когда задач становится слишком много — поручить их другим людям. Так-же в коде, если один кусок становится слишком большим или начинает решать более чем одну задачу — значит нужно его распилить на части в следующий этап рефакторинга. Тогда код получается легче читаемый и логичный, с проектирован с целью выполнения задачи и быть легко обслуживаемым (maintenance www.youtube.com/watch?v=c-kav7Tf834)
Так-же и тесты писать, тестировать как каждый элемент решает поставленную им задачу, и как все это работает вместе (integration test)
Еще интересное видео об абстракциях www.confreaks.com/videos/3852-rdrc2014-magenta-is-a-lie-and-other-tales-of-abstraction
Еще он умеет из коробки устанавливать и запускать приложения для андройда, только нужно скачать файл.
p.s. Вобще заголовок вводивт заблуждение «Яндекс.Кит: новая прошивка для смартфонов», более правдоподобно: «Яндекс.Кит: андройд со вкусом яндекса» или «Яндекс.Кит: телефоны с предустановленным якдексом».
Для себя я предпочитаю использовать оригинальный продукт, особенно если его нельзя заменить. Например андройд развивается и будет развиваться, и чем ближе прошивка к первоначальному продукту тем проще с обновлениями и совместимостью. Например samsung, htc и другие компании делают новые телефоны каждые пару месяцев а обновления делать для старых не хотят, потому-что продавать обновления сложно, им выгоднее телефоны продавать. Самому это делать сложно, потому-что исходный код драйверов закрыт.
Мне кажется более честный подход когда новые операционные системы на телефонах делаются с dual-boot.
Ваш Яндекс.Переезд умеет перенести данные из я.фона в обычный телефон? Или только в одну сторону?
«Наша клавиатура самая быстрая по скорости набора среди аналогов.» — очень интересно как вы это измеряли?
«устройства с Яндекс.Китом работают дольше аналогов» — можете рассказать о подробностях и привести цифры. Думаю это актуально для всех андройд телефонов
habrastorage.org/files/4a4/7fe/a40/4a47fea404714a2e9c1138627c725e23.png
Очень нравится фича с $varname в названии элемента
Проблем с хабом никаких нет, определяется и начинает работать мгновенно