Идея интересная, надеюсь что-то полезное выйдет. Пользуюсь gmail, несколько замечаний.
Цепочки мне лично нравятся и полезны. Это аналог обсуждения на форуме по какой-то теме. Если отказаться от них, то чем заменить?
Поддерживаю идеологию «входящий ящик — пуст» в жизни. Но есть ряд цепочек, которые «вечно» висят перед глазами.
После длительных экспериментов выбрал кнопки с надписями вместо иконок. Просто надоело запоминать иконки.
Чтобы архивировать письмо, один раз кликаю на письме (оно открывается) и второй раз кликаю на кнопку архивации. Но идея архивировать за один клик — хорошая.
Не совсем понятно, почему креативности противопоставляется лицемерие.
Кроме того, вообще неясно, откуда автор решил, что мало креативности. Может ему повнимательней вокруг посмотреть и увидеть множество замечательных изобретений, которые, собственно, и явились плодом креативности.
И еще одно замечание. Креативность предполагает исследование. Исследование предполагает эксперимент. Однако жизнь не может состоять из одного сплошного эксперимента. Точнее, нужно отделять среду для экспериментов и среду для жизни. Потому что совершенно не обязательно ваш эксперимент понравится вашим соседям и вы станете обычным эгоистом.
Вообще, люди, которым «мешают» жить, чего-то не понимают про себя или про жизнь. Любая борьба есть ошибка.
> Программисты производят мысли. Они субъективны == идеальны.
Программисты не производят мысли, они думают. Но не только они, все люди (как правило). Меня не интересует объективность мышления, а сам факт, что вы назвали мысли нематериальными (точнее вы сами не знаете так это или нет, поскольку в одном предложении противоречите себе). Мысли являются материальными.
> Поверьте, даже когда вы выбираете длину переменной цикла, это будет проектирование.
Конечно. И когда столяр выбирает какой шуруп ему нужен, он тоже занимается проектированием. И когда водопроводчик подбирает шланг под резьбу. Просто решения на таком уровне не называют проектированием, слишком мелко.
> Если бы мы понимали каким местом мы думаем (ведь, есть еще выражение "*опой чувствую") и как мы это делаем, то тридцатикратное повышение производительности программистов было бы воспроизводимо
Вы смешиваете интуицию и рациональное мышление. Но оба процесса без мозга неосуществимы.
Насчет 30-кратного повышения производительности вспоминается анекдот, что «если бы мне к заднице пилу приделали, то я бы еще и дерево спилил». Но он неприличный для данного ресурса.
> В программировании основной метод — «метод проб и ошибок».
В любой области. В абсолютно любой области этот метод единственно возможный. Поскольку полнотой информации никто не обладает. Просто программирование — молодая наука и мало пути пройдено.
> Так и вижу хирурга или сапера, которые решают свои задачи методом проб и ошибок.
Хм… Автор, вы шутите или серьезно? Вы действительно думаете, что хирурги никогда не ошибаются и все знают наперед? Или саперы? Вы полагаете, что в медицине на любую болезнь есть ясный и понятный способ лечения? Блин, вам надо скорее в доктора, столько народу спасете…
Простите, но у вас в голове какой-то идеализированный мир. И вы преувеличиваете значение ошибки. Ошибки неизбежны в любой области деятельности. Вот недавно самолет упал, пилоты допустили ошибку (возможно). Хотя их учат и тренируют как никого другого. В вашем мире такого бы не случилось, а в реальном — произошло.
> А вы объективно с хронометром понаблюдайте на мало-мало серьезном проекте разработки (от 100KSLOC) сколько времени уходит на уточнение задачи, обсуждение подходов к ее решению, дискуссии типа: найден баг или фича, статус митинги и проч.
Что в этом плохого? Если беспокоит потраченное время — есть способы формализации и передачи знаний, которые позволяют это ускорить.
> В большинстве промышленных разработок имеют вовсе не алгоритмическую сложность, а экспоненциальную сложность масштаба, которую со времен Брукса никто так и не победил.
Автор, вы себе опять противоречите, не замечаете? Вы решите — либо промышленные разработки есть (и значит проблемы решаются как-то), либо их нет (что не так).
> Если вам надо создать ИС, которая содержит тысячи сущностей и десятки тысяч экранных форм то какие достижения CS вам помогут?
Автор, вы не понимаете из чего сложность растет. Кол-во не представляет собой сложность. Сложность — это разнообразие поведения.
А достижения самые обычные: базы данных, XML, языки программирования, тесты и прочее.
Автор, не пишите о том, чего не знаете или не понимаете.
> То, что производят программисты, нематериально – это brainware, результат коллективного мыслительного процесса проектной команды, материализованный на одном из языков программирования.
Автор много курил и так и не смог понять — материален ли труд программиста или нет?
> Программирование – это проектирование и только проектирование
То есть когда я цикл пишу, то занимаюсь проектированием? Пойду за прибавкой, «мужики-то и не знают».
> Никто не знает, каким местом человек думает и, как он этим местом это делает
Кхм. Обычно — головой. Там, этот — мозг. У автора другое место думает?
> Разработка ПО, ИМХО, по ошибке отнесена к инженерии. Инженерия – это там, где применяются достижения науки, техники, используются законы естественных наук для решения конкретных проблем и достижения поставленных целей. В разработке ПО еще не открыты свои законы Ньютона
Товарищ. Вы с какой луны свалились? В программировании, как минимум, используется математика, но не только она. Алгоритмы рассказать когда были придуманы?
> Даже выдающиеся программисты не возьмут на себя смелость утверждать об архитектуре новой программной системы то, что она будет успешной. Хотя в программировании уже накоплен определенный опыт провалов, который может позволить искушенному программисту увидеть в архитектуре новой системы антипаттерны — источники серьезных будущих проблем. Но не более того
А зачем больше-то??? Исследование чего-либо нового — это всегда крайне затратный труд, успех которого никто не гарантирует. Если я спроектировал архитектуру, в которой я могу опереться на существующие, хорошо зарекомендовавшие себя решения, то она будет мною построена, скорее всего, без серьезных сюрпризов.
В других областях знаний человека, между прочим, все происходит также. Например, строительство.
> Существующее состояние Software Engineering напоминает большую поваренную книгу с многочисленными описаниями рецептов однажды успешно приготовленных блюд из ингредиентов, которых никогда в будущем не будет.
Ну так молодая наука. Вы почитайте историю математики, найдете столько скелетов в шкафу.
> А поскольку это ремесло, то человек, научившийся писать программы на C ++, будет также далек от профессионала, как ученик третьего класса средней школы, научившийся писать по-русски, от А. С. Пушкина или Ф. М. Достоевского.
Автор вообще не понимает о чем пишет, поскольку смешал разные понятия. Попробую растолковать.
Хорошее знание языка не предполагает, что его обладатель станет Пушкиным. Хорошее знание языка = знание грамоты, то есть законов, по котором строятся предложения и вот это все. Более того, есть масса писателей, которые пишут грамматически неверно (авторский язык). Они являются профессиональными писателями. Но могут не сдать ЕГЭ по русскому.
В слове «ремесло» нет ничего плохого, скорее верно обратное. Если что-то стало ремеслом, значит уже накоплен позитивный опыт (на базе тонны негативного) и есть проверенные, работающие решения, которых достаточно, чтобы работать (создавать продукты).
> Свобода – необходимое условие работы программиста.
Автор предлагает их из тюрьмы выпускать на время создания кода?
> В силу отсутствия открытых законов большинство решений программистских задач находится методом проб и ошибок.
Конечно, конечно. Каждая разработка начинается с написания своего компилятора, создания IDE, написание своей базы данных и своих сетевых сокетов.
> У программистов должно быть право на ошибку. Это нормальный атрибут творческого поиска. На ошибках учатся. Умный не тот, кто не делает ошибок, а тот, кто их не повторяет.
Привет, капитан Очевидность! Как жизнь? А можно у людей остальных профессий тоже будет право на ошибку? СПАСИБО, друг! (* плачет от счастья *)
> Для программных продуктов еще не придумали адекватные инструменты визуализации
А как же многостраничные распечатки машинных кодов????? Автор, ну очнись уже. Столько напридумали разных схем и прочего.
> Необходимость постоянных коммуникаций участников разработки. Из опыта. В среднем у каждого участника проекта разработки ПО на всякие разговоры уходит 50% рабочего времени
Кажется, понял автора. Труд программиста — это такой особый труд, где приходится много разговаривать. Возьмем, например экипаж самолета или бригаду хирургов — они-то всю жизнь молчат! Только при выходе на пенсию парой слов обменяются… Или, скажем, работают лифтеры — молчат себе и молчат. Только когда раскаленное олово на голову капнет — тогда разговаривают. А эти программисты — они, блин, болтуны чертовы.
> Для коллективного программистского творчества скорее уместна аналогия с созданием художественного кинофильма или театрального спектакля.
Капустник? Клоунада?
Автор, время идет, жизнь меняется. Когда-то действительно студентам давали на лето задание — написать систему распознавания образов. Но сейчас слегка наработан опыт в самых разных областях программирования и более-менее прояснена сложность тех или иных задач. Также более-менее ясно сколько ресурсов будет уходить на менеджмент, коммуникации и прочее, связанное непосредственно с человеческим ресурсом. С современной точки зрения ваша статья — это несусветная чушь.
Графика понравилась. Персонажи «без изюминки». Надоели боевые собаки в качестве верных помощников, хочу боевого хомяка. Отсутствует стиль: не фэнтэзи, не фикшн и пр. Нужно к чему-то привязаться, ИМХО, чтобы зацепить аудиторию. И еще нужны «бдыыщ» и все разлетелось. А то скучно.
1) отказоустойчивость: на уровне приложения закладывается возможность вести изменения сразу в двух БД: основной и резервной и переходить на резервную при отказе основной;
2) скорость: БД размером до 1 Gb (например), очень интенсивно используется — загружаем целиком в базу-в-памяти (используя Online Backup API), включаем репликацию в базе-в-памяти и время от времени сбрасываем изменения в базу на диске. Сброс изменений на диске делается в отдельном потоке, то есть база-в-памяти при такой репликации почти не занята в процессе.
Цепочки мне лично нравятся и полезны. Это аналог обсуждения на форуме по какой-то теме. Если отказаться от них, то чем заменить?
Поддерживаю идеологию «входящий ящик — пуст» в жизни. Но есть ряд цепочек, которые «вечно» висят перед глазами.
После длительных экспериментов выбрал кнопки с надписями вместо иконок. Просто надоело запоминать иконки.
Чтобы архивировать письмо, один раз кликаю на письме (оно открывается) и второй раз кликаю на кнопку архивации. Но идея архивировать за один клик — хорошая.
Кроме того, вообще неясно, откуда автор решил, что мало креативности. Может ему повнимательней вокруг посмотреть и увидеть множество замечательных изобретений, которые, собственно, и явились плодом креативности.
И еще одно замечание. Креативность предполагает исследование. Исследование предполагает эксперимент. Однако жизнь не может состоять из одного сплошного эксперимента. Точнее, нужно отделять среду для экспериментов и среду для жизни. Потому что совершенно не обязательно ваш эксперимент понравится вашим соседям и вы станете обычным эгоистом.
Вообще, люди, которым «мешают» жить, чего-то не понимают про себя или про жизнь. Любая борьба есть ошибка.
Программисты не производят мысли, они думают. Но не только они, все люди (как правило). Меня не интересует объективность мышления, а сам факт, что вы назвали мысли нематериальными (точнее вы сами не знаете так это или нет, поскольку в одном предложении противоречите себе). Мысли являются материальными.
> Поверьте, даже когда вы выбираете длину переменной цикла, это будет проектирование.
Конечно. И когда столяр выбирает какой шуруп ему нужен, он тоже занимается проектированием. И когда водопроводчик подбирает шланг под резьбу. Просто решения на таком уровне не называют проектированием, слишком мелко.
> Если бы мы понимали каким местом мы думаем (ведь, есть еще выражение "*опой чувствую") и как мы это делаем, то тридцатикратное повышение производительности программистов было бы воспроизводимо
Вы смешиваете интуицию и рациональное мышление. Но оба процесса без мозга неосуществимы.
Насчет 30-кратного повышения производительности вспоминается анекдот, что «если бы мне к заднице пилу приделали, то я бы еще и дерево спилил». Но он неприличный для данного ресурса.
> В программировании основной метод — «метод проб и ошибок».
В любой области. В абсолютно любой области этот метод единственно возможный. Поскольку полнотой информации никто не обладает. Просто программирование — молодая наука и мало пути пройдено.
> Так и вижу хирурга или сапера, которые решают свои задачи методом проб и ошибок.
Хм… Автор, вы шутите или серьезно? Вы действительно думаете, что хирурги никогда не ошибаются и все знают наперед? Или саперы? Вы полагаете, что в медицине на любую болезнь есть ясный и понятный способ лечения? Блин, вам надо скорее в доктора, столько народу спасете…
Простите, но у вас в голове какой-то идеализированный мир. И вы преувеличиваете значение ошибки. Ошибки неизбежны в любой области деятельности. Вот недавно самолет упал, пилоты допустили ошибку (возможно). Хотя их учат и тренируют как никого другого. В вашем мире такого бы не случилось, а в реальном — произошло.
> А вы объективно с хронометром понаблюдайте на мало-мало серьезном проекте разработки (от 100KSLOC) сколько времени уходит на уточнение задачи, обсуждение подходов к ее решению, дискуссии типа: найден баг или фича, статус митинги и проч.
Что в этом плохого? Если беспокоит потраченное время — есть способы формализации и передачи знаний, которые позволяют это ускорить.
> В большинстве промышленных разработок имеют вовсе не алгоритмическую сложность, а экспоненциальную сложность масштаба, которую со времен Брукса никто так и не победил.
Автор, вы себе опять противоречите, не замечаете? Вы решите — либо промышленные разработки есть (и значит проблемы решаются как-то), либо их нет (что не так).
> Если вам надо создать ИС, которая содержит тысячи сущностей и десятки тысяч экранных форм то какие достижения CS вам помогут?
Автор, вы не понимаете из чего сложность растет. Кол-во не представляет собой сложность. Сложность — это разнообразие поведения.
А достижения самые обычные: базы данных, XML, языки программирования, тесты и прочее.
Автор, не пишите о том, чего не знаете или не понимаете.
Автор много курил и так и не смог понять — материален ли труд программиста или нет?
> Программирование – это проектирование и только проектирование
То есть когда я цикл пишу, то занимаюсь проектированием? Пойду за прибавкой, «мужики-то и не знают».
> Никто не знает, каким местом человек думает и, как он этим местом это делает
Кхм. Обычно — головой. Там, этот — мозг. У автора другое место думает?
> Разработка ПО, ИМХО, по ошибке отнесена к инженерии. Инженерия – это там, где применяются достижения науки, техники, используются законы естественных наук для решения конкретных проблем и достижения поставленных целей. В разработке ПО еще не открыты свои законы Ньютона
Товарищ. Вы с какой луны свалились? В программировании, как минимум, используется математика, но не только она. Алгоритмы рассказать когда были придуманы?
> Даже выдающиеся программисты не возьмут на себя смелость утверждать об архитектуре новой программной системы то, что она будет успешной. Хотя в программировании уже накоплен определенный опыт провалов, который может позволить искушенному программисту увидеть в архитектуре новой системы антипаттерны — источники серьезных будущих проблем. Но не более того
А зачем больше-то??? Исследование чего-либо нового — это всегда крайне затратный труд, успех которого никто не гарантирует. Если я спроектировал архитектуру, в которой я могу опереться на существующие, хорошо зарекомендовавшие себя решения, то она будет мною построена, скорее всего, без серьезных сюрпризов.
В других областях знаний человека, между прочим, все происходит также. Например, строительство.
> Существующее состояние Software Engineering напоминает большую поваренную книгу с многочисленными описаниями рецептов однажды успешно приготовленных блюд из ингредиентов, которых никогда в будущем не будет.
Ну так молодая наука. Вы почитайте историю математики, найдете столько скелетов в шкафу.
> А поскольку это ремесло, то человек, научившийся писать программы на C ++, будет также далек от профессионала, как ученик третьего класса средней школы, научившийся писать по-русски, от А. С. Пушкина или Ф. М. Достоевского.
Автор вообще не понимает о чем пишет, поскольку смешал разные понятия. Попробую растолковать.
Хорошее знание языка не предполагает, что его обладатель станет Пушкиным. Хорошее знание языка = знание грамоты, то есть законов, по котором строятся предложения и вот это все. Более того, есть масса писателей, которые пишут грамматически неверно (авторский язык). Они являются профессиональными писателями. Но могут не сдать ЕГЭ по русскому.
В слове «ремесло» нет ничего плохого, скорее верно обратное. Если что-то стало ремеслом, значит уже накоплен позитивный опыт (на базе тонны негативного) и есть проверенные, работающие решения, которых достаточно, чтобы работать (создавать продукты).
> Свобода – необходимое условие работы программиста.
Автор предлагает их из тюрьмы выпускать на время создания кода?
> В силу отсутствия открытых законов большинство решений программистских задач находится методом проб и ошибок.
Конечно, конечно. Каждая разработка начинается с написания своего компилятора, создания IDE, написание своей базы данных и своих сетевых сокетов.
> У программистов должно быть право на ошибку. Это нормальный атрибут творческого поиска. На ошибках учатся. Умный не тот, кто не делает ошибок, а тот, кто их не повторяет.
Привет, капитан Очевидность! Как жизнь? А можно у людей остальных профессий тоже будет право на ошибку? СПАСИБО, друг! (* плачет от счастья *)
> Для программных продуктов еще не придумали адекватные инструменты визуализации
А как же многостраничные распечатки машинных кодов????? Автор, ну очнись уже. Столько напридумали разных схем и прочего.
> Необходимость постоянных коммуникаций участников разработки. Из опыта. В среднем у каждого участника проекта разработки ПО на всякие разговоры уходит 50% рабочего времени
Кажется, понял автора. Труд программиста — это такой особый труд, где приходится много разговаривать. Возьмем, например экипаж самолета или бригаду хирургов — они-то всю жизнь молчат! Только при выходе на пенсию парой слов обменяются… Или, скажем, работают лифтеры — молчат себе и молчат. Только когда раскаленное олово на голову капнет — тогда разговаривают. А эти программисты — они, блин, болтуны чертовы.
> Для коллективного программистского творчества скорее уместна аналогия с созданием художественного кинофильма или театрального спектакля.
Капустник? Клоунада?
Автор, время идет, жизнь меняется. Когда-то действительно студентам давали на лето задание — написать систему распознавания образов. Но сейчас слегка наработан опыт в самых разных областях программирования и более-менее прояснена сложность тех или иных задач. Также более-менее ясно сколько ресурсов будет уходить на менеджмент, коммуникации и прочее, связанное непосредственно с человеческим ресурсом. С современной точки зрения ваша статья — это несусветная чушь.
«К сожалению, всю подлинную, былую красоту Марса мы никогда уже не увидим.»
Давайте представим, что Луна могла бы быть сделана из золота. И жалеть, что не увидим ее золотистый блеск.
Это не «моделирование», это фантизирование.
2) скорость: БД размером до 1 Gb (например), очень интенсивно используется — загружаем целиком в базу-в-памяти (используя Online Backup API), включаем репликацию в базе-в-памяти и время от времени сбрасываем изменения в базу на диске. Сброс изменений на диске делается в отдельном потоке, то есть база-в-памяти при такой репликации почти не занята в процессе.
Наверное, можно и еще придумать сценарии.
Следующий шаг — она становится Open Source.Но и Windows RT тоже для конечного пользователя. Или сравнение некорректно?