В 1961 году М. И. Радовский опубликовал архивные документы Академии наук СССР, относящиеся к прошению Корсакова. В 1980-х годах публикации Радовского привлекли внимание профессора кафедры кибернетики Национального исследовательского ядерного университета «МИФИ» Геллия Николаевича Поварова, которому мы в большей степени обязаны осознанием значимости и повторным открытием изобретений Корсакова[3]. Оценка трудов Корсакова впервые была изложена Поваровом в 1982 году на семинаре по искусственному интеллекту, проходившем под руководством Е. А. Александрова в Центральном Доме культуры медицинских работников (г. Москва).
Иначе говоря, он сделал что-то интересное, но про это почти никто не знал и никто не учитывал в своих работах => он не сильно повлиял на развитие кибернетики и информатики.
Вообще-то я спрашивал про сравнение скорости. Вы несколько раз упомянули, что Jira «тормозит», а basecamp — «не тормозит». И я поинтересовался, для каких операций Jira будет работать медленно, а basecamp, соответственно — быстро.
Вам не кажется, что введение отношения порядка для объектов разных множеств, — это несколько странная операция? Я «несколько раз упомянул», что не считаю эти продукты эквивалентными по каким-либо значимым характеристикам.
Нет, серьезно, что вы хотите измерять? Возьмем простую аналогию, которую я уже приводил выше: «сравним» операции в notepad и ms word. Какие операции мы можем сравнить?
Видимо, придется немного подумать и выписать все операции, которые можно произвести в ворде и все из блокнота, найти пересечение.
Видимо, придется договориться об уровне абстракции так, чтобы пересечение было не пустое (потому как технически «открыть файл в ворде» и «открыть файл в блокноте» — разные операции, и общего у них — только вызов win api функции для открытия файла).
Окей, мы найдем пересечение. Например, в сет попадут операции «открыть файл, закрыть файл, напечатать символ, скопировать символ, вставить символ + модификаторы „большой файл, блок текста“ и т.п.
Возьмем таймер и сделаем замеры каждой операции в ворде и блокноте, запишем результаты. Можно предположить, что блокнот быстрее открывается, быстрее работает с маленькими файлами, но ворд быстрее работает с большими объемами данных.
Что нам дадут абсолютные показатели? Я лично совершенно не понимаю, какую реально полезную информацию отсюда можно получить. Уж не говоря о том, что наши кейсы будут сильно оторваны от реального мира.
Я ещё, как будто в первый раз, скажу, что не считаю возможным сравнение jira и basecamp (hint: по любым значимым показателям).
Если вы считаете, что это возможно, и вам реально так это интересно — сходите и сравните как-нибудь. ;) Успехов, ага.
Ага, вроде понятно. У basecam более простой интерфейс и он не тормозит.
Неверно. Перечитайте, пожалуйста.
Ну про интерфейс понятно, про тормоза — можно поподробнее? В каких условиях сравнивалось?
Что сравнивалось? Я выше 3 раза так и эдак написал, что эти продукты не стоит сравнивать, а теперь вы меня спрашиваете, как я их сравнивал? Думаю, на этом я закончу дискуссию. :)
Я не очень активный пользователь Jira, так что воспринимайте мои слова соответственно. :)
Как я уже говорил, jira обладает более широким функционалом, чем basecamp.
Jira — это навороченная система, которая соединяет в себе баг-трекер, ПМ; у неё есть куча конфигураций и т.п. Обладая некоторой фантазией и умением программировать, её можно превратить во что угодно. И ещё оно может сильно тормозить, если не уметь настраивать эту махину.
Basecamp — это очень простой инструмент для управления проектами, там нет ничего лишнего (в нынешней версии разработчики убрали часть функционала, который, по их мнению, слишком усложнял систему). Basecamp не подходит для больших организаций, огромных, сложноструктурированных проектов и команд. Нет багтрекера. Что есть? Todo-list, calendar, discussions, шаблоны проектов, простое распределение доступов, простейшие текстовые документы, возможность загружать и комментировать файлы + удобнейший интерфейс ко всему этому набору + rest. Он не тормозит и всегда работает без обработки напильником.
Basecamp и Jira — инструменты из разных весовых категорий, они рассчитаны на разные задачи, с ними работают разные команды (и люди).
sed, awk & vim — все они используются для редактирования текста, но задачи разные, поэтому никакой конкуренции на «общем рынке» между ними не может существовать.
Jira — все-таки система с более широким функционалом. Не думаю, что basecamp & jira можно сравнивать.
P.S. Количество вопросов на stackoverflow не корректно использовать в качестве метрики популярности. Я лично вообще не понимаю, что можно спрашивать по поводу простейшей (с т.з. пользователя) системы — basecamp, а вот по поводу jira у меня всегда много вопросов. :))
37signals и его платные аналоги даже не стал пробовать.
В чем причина? Может быть, вам и не стоит пробовать, откуда мы знаем?:)
Пользуюсь бейскампом около 2-х лет для любых проектов, даже для личного органайзера. Удивительно удобный и не перегруженный функционал — работали с командой разработчиков и заказчиками (которые браузером еле пользуются), организовывал походы, обсуждали с друзьями проекты, плотно работали с программистами над задачами, — никаких сложностей с использованием и обучением не было. Проекты до сих пор в системе, можно работать с материалами.
Киллер-фича для меня — плагин для Harvest, который позволяет трекать время бейскаповых задач в системе Harvest. Для почасовой работы — незаменимая вещь, на мой взгляд.
В дополнение могу сказать, что бейскамп нужно уметь готовить: при попытке сделать из него форум (без строгих правил к организации топиков) или базу знаний, бейскапм трескается по швам и тормозит всю работу.
Из серьезных минусов можно ещё отметить верстку основной страницы — рабочее поле шириной 960px не тянется на больших экранах. Разработчики, как я понял, эту ситуацию пока исправлять не планируют. Тут нам помогает stylish и подобные плагины. :)
Речь идет о TDD на уровне продукта. До того как все обсудили и поняли задачу, сформулировав свои знания в виде приемочных тестов, примеров поведения и просто примеров использования, браться за разработку бессмысленно.
Сказка просто. Тут недавно был похожий топик, там сказочный программист рассказывал, что программы, вообще-то, надо писать без ошибок. Вот так.
Но в других сферах жизни так не делают. За качество отвечает тот, кто производит товар или услугу, то есть исполнитель. В нашем случае это и есть сам разработчик.
В любой технологически сложной отрасли есть понятие «контроль качества». Это значит, что помимо отделов по производству, существует отдел по проверке качества продукции, в том числе соответствия продукции нормативам предприятия.
Сразу хочу заметить, что проводить прямую аналогию между процессом проектирования и реализации автоматизированных систем и производством материальных товаров — не очень корректно.
Кстати говоря, у вас в статье нет определения «качества», которое по-вашему должны обеспечивать разработчики вместо тестировщиков. Что вы понимаете под качеством? Что вы понимаете под дефектом? Вы уверны, что разработчики могут успешно тестировать документацию, например? Есть немало исследований, подтверждающих факт о том, что контроль должен производится внешней системой (могу попозже написать несколько ссылок на такие, если интересно).
Сидел на виндах долгие годы, но последние пару лет разрабатывать на ней стало совершенно невыносимо (в основном из-за моих меняющихся потребностей, конечно). И так я её готовил, и эдак, и под конец прикрутил хорошую консоль, редакторы кода и прочее… но около года назад снес к чертям и перешел на линукс. Идеологии в этом решении было мало (винду использую для игр и фотошопа сейчас). Просто в линуксе в сотню раз удобнее работать, если хоть что-то знаешь про компьютеры, конечно.
Так что ваше «Она же менее удобнее чем винда и это факт и от него никуда не деться!», на мой взгляд, пропитано идеологической ненавистью к консоли. ;)
P.S. Для работы с файловой системой хватает zsh, для редактирования файлов проектов (быстрое открытие и переход между большим количеством файлов) — vim + CommandT + ctags. В редких случаях открываю mc. Удобно, быстро. Возможны теги и pushd алиасами.
А вы читайте между «букв». :)
Могу посоветовать посмотреть в сторону smalltalk и более ранних наработок, а так же в сторону ANSI Common Lisp.
За аббревиатурой ООП скрыто слишком много смыслов, которыми её нагрузили в 90-ых и 2000-ых годах. Развитие объектно-ориентированного подхода не закончилось симулой и не останавливается на стандарте Java или какого-то другого языка. Понимание того, как удобнее работать с объектами, развивается, — появляются новые языки и концепции (взять тот же Go). На мой взгляд, общение с объектами с помощью событий или сообщений больше походит на реальный мир, чем вызовы методов, — это мое мнение. Может быть, через 10 лет какой-нибудь исследователь попытается описать современную ему конъюнктуру, и дополнит SOLID (или логично интегрирует) событийной концепцией. ;)
Ну да, упростили. Было: вызовы нескольких методов, стало несколько событий + менеджер событий на группу объектов.
Мне нравятся события, это ближе к православному ООП, но, на мой взгляд, вопросы борьбы со сложностью события решают не так уж и хорошо, как это постулируется в статье.
Иначе говоря, он сделал что-то интересное, но про это почти никто не знал и никто не учитывал в своих работах => он не сильно повлиял на развитие кибернетики и информатики.
Читаемее же :)
… про скрам, аджайл, *DD и т.п. «инновации», отвергая фундаментальные знания. В этом я с вами соглашусь полностью! :)
Вам не кажется, что введение отношения порядка для объектов разных множеств, — это несколько странная операция? Я «несколько раз упомянул», что не считаю эти продукты эквивалентными по каким-либо значимым характеристикам.
Нет, серьезно, что вы хотите измерять? Возьмем простую аналогию, которую я уже приводил выше: «сравним» операции в notepad и ms word. Какие операции мы можем сравнить?
Видимо, придется немного подумать и выписать все операции, которые можно произвести в ворде и все из блокнота, найти пересечение.
Видимо, придется договориться об уровне абстракции так, чтобы пересечение было не пустое (потому как технически «открыть файл в ворде» и «открыть файл в блокноте» — разные операции, и общего у них — только вызов win api функции для открытия файла).
Окей, мы найдем пересечение. Например, в сет попадут операции «открыть файл, закрыть файл, напечатать символ, скопировать символ, вставить символ + модификаторы „большой файл, блок текста“ и т.п.
Возьмем таймер и сделаем замеры каждой операции в ворде и блокноте, запишем результаты. Можно предположить, что блокнот быстрее открывается, быстрее работает с маленькими файлами, но ворд быстрее работает с большими объемами данных.
Что нам дадут абсолютные показатели? Я лично совершенно не понимаю, какую реально полезную информацию отсюда можно получить. Уж не говоря о том, что наши кейсы будут сильно оторваны от реального мира.
Я ещё, как будто в первый раз, скажу, что не считаю возможным сравнение jira и basecamp (hint: по любым значимым показателям).
Если вы считаете, что это возможно, и вам реально так это интересно — сходите и сравните как-нибудь. ;) Успехов, ага.
Неверно. Перечитайте, пожалуйста.
Что сравнивалось? Я выше 3 раза так и эдак написал, что эти продукты не стоит сравнивать, а теперь вы меня спрашиваете, как я их сравнивал? Думаю, на этом я закончу дискуссию. :)
Как я уже говорил, jira обладает более широким функционалом, чем basecamp.
Jira — это навороченная система, которая соединяет в себе баг-трекер, ПМ; у неё есть куча конфигураций и т.п. Обладая некоторой фантазией и умением программировать, её можно превратить во что угодно. И ещё оно может сильно тормозить, если не уметь настраивать эту махину.
Basecamp — это очень простой инструмент для управления проектами, там нет ничего лишнего (в нынешней версии разработчики убрали часть функционала, который, по их мнению, слишком усложнял систему). Basecamp не подходит для больших организаций, огромных, сложноструктурированных проектов и команд. Нет багтрекера. Что есть? Todo-list, calendar, discussions, шаблоны проектов, простое распределение доступов, простейшие текстовые документы, возможность загружать и комментировать файлы + удобнейший интерфейс ко всему этому набору + rest. Он не тормозит и всегда работает без обработки напильником.
Basecamp и Jira — инструменты из разных весовых категорий, они рассчитаны на разные задачи, с ними работают разные команды (и люди).
sed, awk & vim — все они используются для редактирования текста, но задачи разные, поэтому никакой конкуренции на «общем рынке» между ними не может существовать.
Jira и basecamp решают разные задачи, немного пересекаясь. С таким же успехом можно сравнивать notepad и ms word.
P.S. Количество вопросов на stackoverflow не корректно использовать в качестве метрики популярности. Я лично вообще не понимаю, что можно спрашивать по поводу простейшей (с т.з. пользователя) системы — basecamp, а вот по поводу jira у меня всегда много вопросов. :))
В чем причина? Может быть, вам и не стоит пробовать, откуда мы знаем?:)
Пользуюсь бейскампом около 2-х лет для любых проектов, даже для личного органайзера. Удивительно удобный и не перегруженный функционал — работали с командой разработчиков и заказчиками (которые браузером еле пользуются), организовывал походы, обсуждали с друзьями проекты, плотно работали с программистами над задачами, — никаких сложностей с использованием и обучением не было. Проекты до сих пор в системе, можно работать с материалами.
Киллер-фича для меня — плагин для Harvest, который позволяет трекать время бейскаповых задач в системе Harvest. Для почасовой работы — незаменимая вещь, на мой взгляд.
В дополнение могу сказать, что бейскамп нужно уметь готовить: при попытке сделать из него форум (без строгих правил к организации топиков) или базу знаний, бейскапм трескается по швам и тормозит всю работу.
Из серьезных минусов можно ещё отметить верстку основной страницы — рабочее поле шириной 960px не тянется на больших экранах. Разработчики, как я понял, эту ситуацию пока исправлять не планируют. Тут нам помогает stylish и подобные плагины. :)
Сказка просто. Тут недавно был похожий топик, там сказочный программист рассказывал, что программы, вообще-то, надо писать без ошибок. Вот так.
В любой технологически сложной отрасли есть понятие «контроль качества». Это значит, что помимо отделов по производству, существует отдел по проверке качества продукции, в том числе соответствия продукции нормативам предприятия.
Сразу хочу заметить, что проводить прямую аналогию между процессом проектирования и реализации автоматизированных систем и производством материальных товаров — не очень корректно.
Кстати говоря, у вас в статье нет определения «качества», которое по-вашему должны обеспечивать разработчики вместо тестировщиков. Что вы понимаете под качеством? Что вы понимаете под дефектом? Вы уверны, что разработчики могут успешно тестировать документацию, например? Есть немало исследований, подтверждающих факт о том, что контроль должен производится внешней системой (могу попозже написать несколько ссылок на такие, если интересно).
Так что ваше «Она же менее удобнее чем винда и это факт и от него никуда не деться!», на мой взгляд, пропитано идеологической ненавистью к консоли. ;)
P.S. Для работы с файловой системой хватает zsh, для редактирования файлов проектов (быстрое открытие и переход между большим количеством файлов) — vim + CommandT + ctags. В редких случаях открываю mc. Удобно, быстро. Возможны теги и pushd алиасами.
Могу посоветовать посмотреть в сторону smalltalk и более ранних наработок, а так же в сторону ANSI Common Lisp.
За аббревиатурой ООП скрыто слишком много смыслов, которыми её нагрузили в 90-ых и 2000-ых годах. Развитие объектно-ориентированного подхода не закончилось симулой и не останавливается на стандарте Java или какого-то другого языка. Понимание того, как удобнее работать с объектами, развивается, — появляются новые языки и концепции (взять тот же Go). На мой взгляд, общение с объектами с помощью событий или сообщений больше походит на реальный мир, чем вызовы методов, — это мое мнение. Может быть, через 10 лет какой-нибудь исследователь попытается описать современную ему конъюнктуру, и дополнит SOLID (или логично интегрирует) событийной концепцией. ;)
Мне нравятся события, это ближе к православному ООП, но, на мой взгляд, вопросы борьбы со сложностью события решают не так уж и хорошо, как это постулируется в статье.