Тем не менее минимум 11 человек посчитали, что работа проднелана не зря. И если вам статья не была полезна, это не означает, что она не была полезна для кого-либо еще.
Я описал то, что делал для себя, что б другим было проще проделать то же самое, если понадобится. Лично, я перед тем, как начать все это делать, искал в инете подобную статью. Ни у нас ни в буржунете ничего подобного не было. Поэтому я и написал статью, что б и мне и другим в следующий раз было проще проделать тоже самое.
Никто вас не заставляет использовать фиш, zsh тоже замечательная оболочка. Но лично мне больше нравится когда оболочка угадывает, что ты ее хотел попросить сделать.
Я долго осваивался, но когда понимаешь логику — все что надо ищется по комплитам и вроде не надо конфиги редактировать. Вводишь set fish — и ищешь в комплитах нужный параметр. Я из всего только цвета менял и приветствие убирал. ( set fish_greeting )
Интерактивностью поиска относительно истории и комплишинов. Рассказать достаточно сложно, нужно показывать. Поиск по истории и некоторым комплишинам происходит во время ввода команды. Чем-то похоже на строку для ввода поискового запроса в гугле, когда сразу выполняется и поиск. Возможно, баш тоже можно для такого настроить.
Интересные мысли, но создается впечатление, что автор не знаком с работами классиков Agile, такими, как Кент Бек, Мартин Фаулер, Хенрик Книберг. Не говоря уже о каких-либо более сложных работах в этой области. Успешно применяю, то что можно обощить, как Agile уже около 10-ти лет.
1. Нет критериев эффективности конечного результата.
Как так? Гуглите по запросу «метрики Agile» и найдите, то что наиболее подходит для вас!
2. Непредсказуемость.
Как раз Agile направлен на то, что б получить результат. Но результатом в данном случае является то, что надо бизнесу, причем с точки зрения бизнеса. Мы принимаем за аксиому, что бизнес постоянно изменяется и это требует внесения изменений в ПО. Пример простой, есть компания которая продает скажем ноутбуки, и тут бизнес принимает решение, что нужно продавать еще и планшеты, потому что это перспективный рынок. До того, как появились планшеты бизнес ни на каком проектировании не мог предположить, что нужно такие требования к разработке выдвигать. Понятно, что нужно будет значительную часть системы переписать, но иначе бизнес упустит перспективную возможность, и об этом на этапе проектировании ничего не было известно. При этом, используя метрики и проектирование, можно в течении нескольких дней сказать сколько это времени займет и сколько будет стоить. Что очень хорошо для бизнеса. В Agile бизнес-решения принимает бизнес, а технические решения принимают — программисты. Ответственность в Agile должна приниматься всей командой, включая бизнес, иначе аджайла не будет. Так что аджайл в этом смысле с одной стороны предсказуем — из 20 спринтов последнего проекта, не правильно оценили время мы всего в двух и то из-за полного отсутствия информации.
Тема интересная. У вас какие-то наработки есть? Занимаюсь уже несколько лет разработкой технологии чем-то перекликающейся с вашими «тегами» и «версионностью», у меня правда все ориентировано на облака и энтерпрайз и это скорее специальный вариант базы данных (в смысле NoSQL) поверх которых навернуты некоторые приложения для энтерпайза. Сильно подробностями делиться не могу. Ваша статья заставила меня задуматься о технолгии, как о файловой системе.
Спасибо! Отличная статья! Взял на заметку проблему.
Скорее всего все происходит потому, что Voldemort пердполагает немного другое использование, судя по архитектуре LinkedIn. Они используют для больших объемов сформированные на хадупе ридонли стораджи. У себя я собираюсь в беркли хранить только промежуточную информацию (за 5-10-60 мин), а потом объединять ее на хадупе с остальной информацией и совершать следующую итерацию пересчета.
Еще у Бека есть книга «Test Driven Development» — которая круче! Там Бек через тестирование разрабатывает фреймворк для тестирования и пишет, что это похоже на нейрохирургическую операцию на собственном мозге.
Выходите на следующий уровень Behavior Driven Development. Почему думал, что он Behavior Driven Design. Википедия утверджает, что все-таки Development.
С тем что если регистрация не нужна — ее не должно быть, я согласен. Даже выше в коментариях уже соглашался с ораторами на эту тему.
Телефон, емейл и прочее не нужно для аутентификации человека. Они могут присутсвовать как опциональные и пользователь, если хочет иметь востановления пароля по емейлу или телефону введет их. Принуждать его к вводу емейла или телефона не стоит.
Про ИНН и Номер паспорта — это полный бред. Пользователь совершенно не обязан знать их наизусть. Да его можно попросить ввести их на сайте для активации какой-либо услуги. Но использование подобного идентификатора в качестве идентификатора, только показывает насколько нас провайдер услуги не уважает как своих пользователей.
Я долго осваивался, но когда понимаешь логику — все что надо ищется по комплитам и вроде не надо конфиги редактировать. Вводишь set fish — и ищешь в комплитах нужный параметр. Я из всего только цвета менял и приветствие убирал. ( set fish_greeting )
1. Нет критериев эффективности конечного результата.
Как так? Гуглите по запросу «метрики Agile» и найдите, то что наиболее подходит для вас!
2. Непредсказуемость.
Как раз Agile направлен на то, что б получить результат. Но результатом в данном случае является то, что надо бизнесу, причем с точки зрения бизнеса. Мы принимаем за аксиому, что бизнес постоянно изменяется и это требует внесения изменений в ПО. Пример простой, есть компания которая продает скажем ноутбуки, и тут бизнес принимает решение, что нужно продавать еще и планшеты, потому что это перспективный рынок. До того, как появились планшеты бизнес ни на каком проектировании не мог предположить, что нужно такие требования к разработке выдвигать. Понятно, что нужно будет значительную часть системы переписать, но иначе бизнес упустит перспективную возможность, и об этом на этапе проектировании ничего не было известно. При этом, используя метрики и проектирование, можно в течении нескольких дней сказать сколько это времени займет и сколько будет стоить. Что очень хорошо для бизнеса. В Agile бизнес-решения принимает бизнес, а технические решения принимают — программисты. Ответственность в Agile должна приниматься всей командой, включая бизнес, иначе аджайла не будет. Так что аджайл в этом смысле с одной стороны предсказуем — из 20 спринтов последнего проекта, не правильно оценили время мы всего в двух и то из-за полного отсутствия информации.
Дольше и дороже.
Тут я просто ссылку на статью дам, которая все объясняет http://blog.scrumtrek.ru/2011/03/agile-waterfall.html
Скорее всего все происходит потому, что Voldemort пердполагает немного другое использование, судя по архитектуре LinkedIn. Они используют для больших объемов сформированные на хадупе ридонли стораджи. У себя я собираюсь в беркли хранить только промежуточную информацию (за 5-10-60 мин), а потом объединять ее на хадупе с остальной информацией и совершать следующую итерацию пересчета.
Телефон, емейл и прочее не нужно для аутентификации человека. Они могут присутсвовать как опциональные и пользователь, если хочет иметь востановления пароля по емейлу или телефону введет их. Принуждать его к вводу емейла или телефона не стоит.
Про ИНН и Номер паспорта — это полный бред. Пользователь совершенно не обязан знать их наизусть. Да его можно попросить ввести их на сайте для активации какой-либо услуги. Но использование подобного идентификатора в качестве идентификатора, только показывает насколько нас провайдер услуги не уважает как своих пользователей.