Да, комиты должны быть маленькими, но это не значит что они должны быть однострочными, это более вероятно означает, что они должны содержать оформленный кусок чего-то одного. В оптимальном варианте — это задача/баг. Если задача слишком большая, она стопудово бьется на подзадачи.
Когда выработаете с User Story, то разбивая для правильного менеджмента их на таски, хорошим способом является разбивать их на таски не более 8-13 часов, иначе разработка данной юзерстори становится труднее для отслеживания. За 8 часов много не напрограммируешь если делать это правильно.
Когда мы говорим о хранении кода в VCS, то в центральном репозитории всегда хранятся завершенные куски, т.е. закомиченные таски. Т.е. там дибилятника в роде построчеченого комита каждого класса быть не может, иначе никогда не найдешь и не откатишь.
В случае распредленного VCS, при наличии локального репозитория — да, делаете мелкие комититы, но опять же, в стиле завершенных мыслей. Но вы же не будете предоставлять на ревью завершенную мысль, а не завершенный таск — это было бы неэффективно с точки зрения траты времени ревьюера.
Я вас понял. Перечитав немного стать, я думаю, что имеется ввиду процесс добавления файлов в Ревью, а не в проект. Т.е. вот я зафиксал багу, в этой баге я поменял файлы 1.txt и 2.txt. Вот эти файлы будут добавлены в ревью.
Ничего за возможность ревьюить или подстветить чейнджи в этом фиксе не скажу, но имхо вещь необходимая.
>>откуда в жизни берутся такие юз кейсы
Я не ТС, но давайте подумаем вместе: вы код проекта на чем пишите? Думаю, что на компьютере. Исходный код программы состоит из файликов. Имеет смысл разделять исходный код программы на компоненты и компоненты раскладывать по файлам исходных кодов. Когда соответственно создается что-то новое, то на начальном этапе количество файликов равно 0 и при разработке увеличивается. Отюсда появляются такие клевые юзкейсы, как описанный автором.
Я пытаюсь найти refurbished на ebay. Говорят они все в отличном состоянии.
Пока хожу вокруг до около, т.к. надо будет использовать какой-нибудь shipito. Плюс, стул весит много, а у нас на таможне какой-то порог в 30кг что ли. Боюсь, доставка + пошли будет большая.
Есть функция разделения экрана с автоматическим изменением размера уже открытых окон при изменении одного из них.
Подозреваю, что она выполнена в виде программки, а не сигнал с двух входов ловит (соответственно с двух выходов видеокарты), что есть не совсем хорошо, как мне кажется (хоткеи ОС могут не поддерживаться, например).
Ну а чем WSDL лучше в плане возможности фиксировать контракт?
Вот здесь я не совсем понял ваш вопрос. WSDL — это и есть контракт. Сервис ничего не отдаст, чего нет в WSDL, потому что серверная часть либо создается из WSDL файла либо WSDL создается по серверному API. Поэтому WSDL является результатом фиксированного контракта.
В REST да, все можно сделать. Только контракт описан в вики, что равно «на словах», поэтому никак не привязано к реальному API и держится на честном слове разработчиков.
Пользователь выбрал свой домашний город, или язык вебсайта или цвет бэкграунда и т.п.
Если вы будете хранить все это дело в базе на сервере, либо в сессии на сервере (для сессионных компонент), то при наплыве пользователей наступят проблемы с хранилищем на сервере (ограниченное количество соединений с базой, не резиновая память для хранения сессий в RAM и т.п.).
для мобильных приложений, все же API достаточно простое
Именно так. И особенно это работает когда клиент и сервер написаны в одной конторе :) Но в остальном он не производит серьезного впечатления, т.к. без возможности фиксировать контракт api является просто хорошим паттерном реализации сервисного уровня.
Я в данном случае говорю не о SOAPе, а о проблеме стандартизации (Кстати по поводу SOAP для java-java, net-net я не соглашусь, так как его цель именно дать возможность коммуникации между средами внезависимости от их имплементации). Сейчас все пишут REST сервисы как Б-г на душу положит. Хорошо, когда человек прочитал пару книг и имеет какой-то опыт реализации за плечами. Можно надеятся на что-то стабильное в плане API и обратную совместимость в будущем. По факту, процент таких очень мал, если мы исключим всем известные, широко используемые публичные сервисы.
Но опять же, у каждого свой путь реализации версионности сервисов, выкатываения багфиксов и т.п. В частном случае SOAP протокола, я стандартными средствами (автоматизированными даже) иду на урл сервиса, и узнаю какие версии api он поддерживает и что какой формат данных я могу оттуда ожидать. Это дает гарантию моему клиенту, что при правильном запросе он получит знакомый ему ответ.
В текущей реализации RESTа сервисов — этого сделать нельзя: я не могу парсить wiki страничку, я не могу знать стандартный урл для извлечения версий api, и контракта (не каждый сервис это предоставляет, не будет одинаковых способов это сделать). Захочется девелоперу подфиксить какой-то баг у себя в АПИ — хорошо если он об этом напишет у себя в wiki, и то я пока прочитаю, мой клиент будет лежать.
Именно это не делает REST стандартом дефакто в серьезных системах. Потому что если упадет интеграция с twitter'ом, никто ничего не потеряет.
Я бы поподробнее про это почитал где-нибудь, потому как мне казалось что E6 новая модель с соответственным железом.
Просто в домашней сети, когда есть 3g и телефон может сгонять за альманахом — то да, так быстро. 3g выключаешь при включенных a-gps, позиционировании по вышкам и т.п. — все, очень долго (при этом еще надо отъеъхать от последнего место положения, для чистоты эксперимента).
В E6, как только разблокировался экран, можно сразу жать кнопки на клавиатуре, тем самым либо номер набирая, либо в запкниге искать.
В айфоне надо сначала зайти в Phone, потом либо в Keypad для набора номера, либо в Contacts, чтобы по записной книге поискать (при этом отскролить наверх, чтобы в строку поиска перейти). Ну вы понимаете процесс…
Да, комиты должны быть маленькими, но это не значит что они должны быть однострочными, это более вероятно означает, что они должны содержать оформленный кусок чего-то одного. В оптимальном варианте — это задача/баг. Если задача слишком большая, она стопудово бьется на подзадачи.
Когда выработаете с User Story, то разбивая для правильного менеджмента их на таски, хорошим способом является разбивать их на таски не более 8-13 часов, иначе разработка данной юзерстори становится труднее для отслеживания. За 8 часов много не напрограммируешь если делать это правильно.
Когда мы говорим о хранении кода в VCS, то в центральном репозитории всегда хранятся завершенные куски, т.е. закомиченные таски. Т.е. там дибилятника в роде построчеченого комита каждого класса быть не может, иначе никогда не найдешь и не откатишь.
В случае распредленного VCS, при наличии локального репозитория — да, делаете мелкие комититы, но опять же, в стиле завершенных мыслей. Но вы же не будете предоставлять на ревью завершенную мысль, а не завершенный таск — это было бы неэффективно с точки зрения траты времени ревьюера.
Ничего за возможность ревьюить или подстветить чейнджи в этом фиксе не скажу, но имхо вещь необходимая.
Я не ТС, но давайте подумаем вместе: вы код проекта на чем пишите? Думаю, что на компьютере. Исходный код программы состоит из файликов. Имеет смысл разделять исходный код программы на компоненты и компоненты раскладывать по файлам исходных кодов. Когда соответственно создается что-то новое, то на начальном этапе количество файликов равно 0 и при разработке увеличивается. Отюсда появляются такие клевые юзкейсы, как описанный автором.
"… And one more thing!" ;(
Пока хожу вокруг до около, т.к. надо будет использовать какой-нибудь shipito. Плюс, стул весит много, а у нас на таможне какой-то порог в 30кг что ли. Боюсь, доставка + пошли будет большая.
>>Лично я отсылаю акт на подписание в oDesk за 2 недели, до того, как планирую выводить деньги.
Можете поподробнее по очередность, в этом моменте не ясно как вы отсылаете акт на подписание, если деньги еще не вывели. Спасибо.
Подозреваю, что она выполнена в виде программки, а не сигнал с двух входов ловит (соответственно с двух выходов видеокарты), что есть не совсем хорошо, как мне кажется (хоткеи ОС могут не поддерживаться, например).
Вот здесь я не совсем понял ваш вопрос. WSDL — это и есть контракт. Сервис ничего не отдаст, чего нет в WSDL, потому что серверная часть либо создается из WSDL файла либо WSDL создается по серверному API. Поэтому WSDL является результатом фиксированного контракта.
В REST да, все можно сделать. Только контракт описан в вики, что равно «на словах», поэтому никак не привязано к реальному API и держится на честном слове разработчиков.
Пользователь выбрал свой домашний город, или язык вебсайта или цвет бэкграунда и т.п.
Если вы будете хранить все это дело в базе на сервере, либо в сессии на сервере (для сессионных компонент), то при наплыве пользователей наступят проблемы с хранилищем на сервере (ограниченное количество соединений с базой, не резиновая память для хранения сессий в RAM и т.п.).
Обычно, такие данные хранят в куках.
Именно так. И особенно это работает когда клиент и сервер написаны в одной конторе :) Но в остальном он не производит серьезного впечатления, т.к. без возможности фиксировать контракт api является просто хорошим паттерном реализации сервисного уровня.
Но опять же, у каждого свой путь реализации версионности сервисов, выкатываения багфиксов и т.п. В частном случае SOAP протокола, я стандартными средствами (автоматизированными даже) иду на урл сервиса, и узнаю какие версии api он поддерживает и что какой формат данных я могу оттуда ожидать. Это дает гарантию моему клиенту, что при правильном запросе он получит знакомый ему ответ.
В текущей реализации RESTа сервисов — этого сделать нельзя: я не могу парсить wiki страничку, я не могу знать стандартный урл для извлечения версий api, и контракта (не каждый сервис это предоставляет, не будет одинаковых способов это сделать). Захочется девелоперу подфиксить какой-то баг у себя в АПИ — хорошо если он об этом напишет у себя в wiki, и то я пока прочитаю, мой клиент будет лежать.
Именно это не делает REST стандартом дефакто в серьезных системах. Потому что если упадет интеграция с twitter'ом, никто ничего не потеряет.
Просто в домашней сети, когда есть 3g и телефон может сгонять за альманахом — то да, так быстро. 3g выключаешь при включенных a-gps, позиционировании по вышкам и т.п. — все, очень долго (при этом еще надо отъеъхать от последнего место положения, для чистоты эксперимента).
В айфоне надо сначала зайти в Phone, потом либо в Keypad для набора номера, либо в Contacts, чтобы по записной книге поискать (при этом отскролить наверх, чтобы в строку поиска перейти). Ну вы понимаете процесс…