Многие начинающие программисты страдают тем, что желание у них есть, а вот возможности воплотить не хватает. И начинает молодой специалист бегать по библиотекам, читать разные книги умные и советоваться с другими,- более умудренными опытом.
Но проходит время и начинаешь понимать, что знание уже не радует, умение не увлекает, а свет в конце тунеля превратился в серо-голубую лампочку будней.
понедельник, 2 ноября 2009 г.
понедельник, 19 октября 2009 г.
Миф о скорости работы
Скорость работы и как с ней бороться
Многие из нас помнят смысл тех слов, что часто слышим от наших начальников, клиентов и сотрудников: "Постарайтесь сделать побыстрее". А, именно: "Мы ожидали уже увидеть результат, но пока его нет, в чем проблема?"
Когда это слышишь, то чувствуешь себя, как будто подвёл человека. Но на самом деле это не так. Они сами часто меняют спецификации. Определяют сроки, которые трудно назвать реальными. За одно им только становишься благодарным: за то, что после общения с ними ищешь способа поднять скорость работы и усовершенствоваться.
Многие из нас помнят смысл тех слов, что часто слышим от наших начальников, клиентов и сотрудников: "Постарайтесь сделать побыстрее". А, именно: "Мы ожидали уже увидеть результат, но пока его нет, в чем проблема?"
Когда это слышишь, то чувствуешь себя, как будто подвёл человека. Но на самом деле это не так. Они сами часто меняют спецификации. Определяют сроки, которые трудно назвать реальными. За одно им только становишься благодарным: за то, что после общения с ними ищешь способа поднять скорость работы и усовершенствоваться.
суббота, 17 октября 2009 г.
Творчество против Продуктивности
Сколько раз мы сталкивались с тем, что хочется сотворить приложение по своему. Но наши заказчики указывают сроки. Причем - очень сжатые. И начинаешь задумываться, а что действительно тебе нужно от программирования.
Если творчество - то денег таким образом заработать трудно. Прямая дорога - в шароваршики. Если же есть желание зарабатывать на заказах - то продуктивность очень важна. Просто критически необходима.
И это приводит к двум противоположным стилям программирования - вдумчивому анализу и программированию "по шаблону". Создаваемые программы получаются стандартизированными и выпускаются очень быстро. Но на исследование новых механизмов, алгоритмов и моделей не остается времени.
Если творчество - то денег таким образом заработать трудно. Прямая дорога - в шароваршики. Если же есть желание зарабатывать на заказах - то продуктивность очень важна. Просто критически необходима.
И это приводит к двум противоположным стилям программирования - вдумчивому анализу и программированию "по шаблону". Создаваемые программы получаются стандартизированными и выпускаются очень быстро. Но на исследование новых механизмов, алгоритмов и моделей не остается времени.
понедельник, 12 октября 2009 г.
Дилемма: XP или Архитектура
Как оказалось новые технологии сильно конфликтуют друг с другом. Так ХР (Экстремальное программирование) требует постепенного улучшения и совершенствования моделей, подтвержденных тестами. Академические же методики требуют изначального формального рассмотрения системы в целом. Если избежать паралича анализа - то можно определить систему подробно и увидеть все подводные камни.
Эти методики как разный взгляд на путешествие. ХР - это драйв на яхте к тем местам, которые хочешь увидеть. Архитектурный подход - скрупулезное планирование пути по карте и выставление вех. После этого работа - чисто на автоматизме, с применением генераторов кода и дешевых "кодеров".
Эти методики как разный взгляд на путешествие. ХР - это драйв на яхте к тем местам, которые хочешь увидеть. Архитектурный подход - скрупулезное планирование пути по карте и выставление вех. После этого работа - чисто на автоматизме, с применением генераторов кода и дешевых "кодеров".
понедельник, 5 октября 2009 г.
Ценность мастеров или Почем волшебная палочка
После упорного поиска оптимального метода программирования я пришел к следующим выводам:
- Чем меньше кодирования, тем пишешь быстрее
- Чем больше библиотек компонентов, кода - то кодировать приходиться меньше
четверг, 1 октября 2009 г.
Сравнение RAD в Delphi и Visual Studio
Мы все рады заметить, что знаменитая версия Delphi 7 теперь продается за $75. Если учесть его возможности, и что на нем можно создавать вполне реальные и профессиональные приложения - то можно сказать, что Embarcadero подарило нам эту среду бесплатно.
Для сравнения - RAD Studio for Delphi 2009 стоит $895, а Visual Studio $1000-$2000. Что не всегда по карману даже профессиональному программисту, а уж о начинающих и говорить нечего. Сообщество программистов Open Delphi пытается выкупить права на 7ю версию и сделать ее открытой и общедоступной. Сейчас они собрали $29 750. Будем ждать, когда этот переломный момент произойдет.
Конечно, есть и Eclipse - но Java не всегда понятна "простому смертному". Завязка на свою собственную объектную модель и архитектура виртуально машины, отличной от того, что мы видим и знаем в Windows - мешает быстрому изучению языка.
Итак, сравним RAD (Rapid Application Development) в Delphi 7 и Visual Studio. Delphi 2008 и выше сейчас используют среду Visual Studio, поэтому можно сравнивать лишь "старую" и "новую" версии пакета Delphi.
Так, как в Delphi 2009 можно создать классическую разделенную среду программирования, то можно сказать, что она - надмножество среды программирования Delphi 7. Но, тут есть один нюанс - множество компонент, написанных для самой популярной версии 7 не работают нормально под 2009 без переработки. Удобство среды Delphi 2009 - заимствованная из Visual Studio автовыравнивание компонентов и полная MDA поддержка. QA (Quality Assurance) - тоже прекрасная штука для нахождения ошибок и качества кода.
Но, во первых современная среда, на основе Visual Studio грузится целых 2 минуты, а занимает больше 400 Мб памяти.
Отличие возникает в том, когда начинаешь строить RAD системы с использованием компонент доступа к БД. Так в Delphi мы можем построить приложение работы с БД - дело 10 минут. В Visual Studio - это уже на так удобно. Поскольку, C# позволяет каждый компонент использовать источник данных, то нет необходимости в сторонних компонентах. Но при этом модель - таблица, адаптер, база не всегда удобна.
Обе фирмы стремились облегчить разработку веб- и B2B- приложений, что создали визуальные компоненты для эффективной работы с ними. Они преуспели в этом, но Microsoft, как всегда впереди - для своих ASP.NET серверов нет ничего удобнее в разработке, чем Visual Studio. Тут не попишешь.
Остается отметить, что Borland, хоть и пытался выйти на арену сред разработки для профессионалов, все же не удалось этого сделать. Их ниша - средние и продвинутые разработчики и небольшие команды и фирмы по разработке ПО. Исходя из этого - Borland продукты в RAD - удобнее всего делать маленькие приложения и компоненты для своих нужд и нужд фирмы. Microsoft среду - разрабатывать большие корпоративные приложения.
Удобство обоих сред на высоком уровне. У Delphi есть одно преимущество - быстрый выбор свойства по Tab. В Microsoft не посчитали нужным это делать. И у Delphi огромное преимущество - большой выбор бесплатных компонент. Поэтому значительно легче построить приложение в TRM (True RAD Manner). Достаточно скачать нужные компоненты и поставить их - и в вашем распоряжении уже готовый фреймворк. Visual Studio - более серьезная и денежная среда. Ее компоненты тяжеловеснее и дороже. Но и приложения можно строить на порядок более сложнее.
Сделаю вывод - Delphi RAD для прототипов и средних проектов, дешево и сердито. Конечно, среда, бывает, глючит, но не это самое важное. Важно - легкость разработки и доступность бесплатных компонент. Visual Studio - ни разу не выдавала ошибок, но компоненты дороже. Бесплатных почти нет, что делает ее не так привлекательной для начинающих и продвинутых программистов.
Благодарю вас за проведенное со мной время.
В следующей статье я расскажу, как я искал путь ускорения разработки и что нашел на этом пути.
Для сравнения - RAD Studio for Delphi 2009 стоит $895, а Visual Studio $1000-$2000. Что не всегда по карману даже профессиональному программисту, а уж о начинающих и говорить нечего. Сообщество программистов Open Delphi пытается выкупить права на 7ю версию и сделать ее открытой и общедоступной. Сейчас они собрали $29 750. Будем ждать, когда этот переломный момент произойдет.
Конечно, есть и Eclipse - но Java не всегда понятна "простому смертному". Завязка на свою собственную объектную модель и архитектура виртуально машины, отличной от того, что мы видим и знаем в Windows - мешает быстрому изучению языка.
Итак, сравним RAD (Rapid Application Development) в Delphi 7 и Visual Studio. Delphi 2008 и выше сейчас используют среду Visual Studio, поэтому можно сравнивать лишь "старую" и "новую" версии пакета Delphi.
Так, как в Delphi 2009 можно создать классическую разделенную среду программирования, то можно сказать, что она - надмножество среды программирования Delphi 7. Но, тут есть один нюанс - множество компонент, написанных для самой популярной версии 7 не работают нормально под 2009 без переработки. Удобство среды Delphi 2009 - заимствованная из Visual Studio автовыравнивание компонентов и полная MDA поддержка. QA (Quality Assurance) - тоже прекрасная штука для нахождения ошибок и качества кода.
Но, во первых современная среда, на основе Visual Studio грузится целых 2 минуты, а занимает больше 400 Мб памяти.
Отличие возникает в том, когда начинаешь строить RAD системы с использованием компонент доступа к БД. Так в Delphi мы можем построить приложение работы с БД - дело 10 минут. В Visual Studio - это уже на так удобно. Поскольку, C# позволяет каждый компонент использовать источник данных, то нет необходимости в сторонних компонентах. Но при этом модель - таблица, адаптер, база не всегда удобна.
Обе фирмы стремились облегчить разработку веб- и B2B- приложений, что создали визуальные компоненты для эффективной работы с ними. Они преуспели в этом, но Microsoft, как всегда впереди - для своих ASP.NET серверов нет ничего удобнее в разработке, чем Visual Studio. Тут не попишешь.
Остается отметить, что Borland, хоть и пытался выйти на арену сред разработки для профессионалов, все же не удалось этого сделать. Их ниша - средние и продвинутые разработчики и небольшие команды и фирмы по разработке ПО. Исходя из этого - Borland продукты в RAD - удобнее всего делать маленькие приложения и компоненты для своих нужд и нужд фирмы. Microsoft среду - разрабатывать большие корпоративные приложения.
Удобство обоих сред на высоком уровне. У Delphi есть одно преимущество - быстрый выбор свойства по Tab. В Microsoft не посчитали нужным это делать. И у Delphi огромное преимущество - большой выбор бесплатных компонент. Поэтому значительно легче построить приложение в TRM (True RAD Manner). Достаточно скачать нужные компоненты и поставить их - и в вашем распоряжении уже готовый фреймворк. Visual Studio - более серьезная и денежная среда. Ее компоненты тяжеловеснее и дороже. Но и приложения можно строить на порядок более сложнее.
Сделаю вывод - Delphi RAD для прототипов и средних проектов, дешево и сердито. Конечно, среда, бывает, глючит, но не это самое важное. Важно - легкость разработки и доступность бесплатных компонент. Visual Studio - ни разу не выдавала ошибок, но компоненты дороже. Бесплатных почти нет, что делает ее не так привлекательной для начинающих и продвинутых программистов.
Благодарю вас за проведенное со мной время.
В следующей статье я расскажу, как я искал путь ускорения разработки и что нашел на этом пути.
четверг, 24 сентября 2009 г.
MDA vs XP
Доброго времени суток.
Продолжу разговор о современных технологиях программирования, ускоряющих разработку и облегчающих нам - программистам, жизнь. Эти технологии прямо противоположны по методике разработке.
Так MDA (Model Driven Architecture) - изначально предполагает, что вы, как архитектор, создадите уже готовую часть (или всю) системы в виде моделей и спецификаций, а остальное на себя возьмет уже среда моделирования. Программистам останется лишь добавить специфической функциональности, что на современный момент не является необходимым - большое количество библиотек классов и фреймворков решают все.
С другой стороны - XP (Extremal Programing), подразумевает упор на кодинге. Сама архитектура вторична, и хотя они ее называют "метафора", это понятие весьма расплывчато. И дизайн системы постоянно улучшается - рефакторится.
Что больше всего интересно, так это то, что оба лагеря обещают быструю и удобную разработку, удовлетворение клиента и своевременную реакцию на изменения.
Я попробовал оба подхода и могу сказать следующее: MDA - вещь хорошая, но есть один нюанс - вы должны быть профессиональным архитектором и знать UML/OCL как свои пять пальцев. Иначе вы запросто заблудитесь в этих спецификациях и функциях системы. Как правило они очень мощные и слишком универсальные. Поэтому надо знать, что творишь и двигаться строго по методологии RUP/UML.
Экстремальное программирование - более легко в освоении, и близко к духу настоящего программирования. Ориентировано на кодирование, тесты и рефакторинг. И все бы хорошо, но оно отличается тем, что без общего плана, лишь с "метафорой" и текущим списком задач далеко не уедешь. Часто происходит то, что говорят: "не зная куда идешь, ты придешь не туда". Из-за этого необходимо поддерживать тесную связь с заказчиком. Даже влить его в команду, как они и советуют. Но наши заказчики - занятые люди и сложно уговорить их работать с нами на равных.
Да и психологически XP сложен в применении. Когда начинаются проблемы с кодом быстро возвращаются старые привычки - вместо маленьких шагов тестирования начинаешь вообще отказываться от него. В уме прокладываешь дорожки в обход и начинаешь глобальные изменения. И все - это больше нельзя назвать экстремальным программированием. А в случае, если заблудишься - то только VCS системы спасут и доставят на ближайший чек-поинт. И хорошо, если пользуетесь ими часто. У меня как то месяц работы накрылся из-за чрезмерно возросшей сложности.
Могу лишь сказать, что я изучал UML с 1996 года и старался стать архитектором ПО. Продукты выходили достойные, но происходило это очень медленно - от 3х до 9и месяцев уходило на рождение системы. Хорошо клиенты попадались понимающие. После чего я встретил экстремальное программирование, и дух творчества и азарт, который начал стихать заново загорелся. Сейчас я делаю небольшие программы за неделю, но оставляю возможность их улучшения. Самое трудное - перейти на автономное тестирование. Рефакторингом мы занимаемся по любому достаточно часто. А вот тестирование, причем, встроенное в процесс разработки - увы не так удобно, как кажется.
Благодарю вас за ваше время.
В следующей статье обсудим разработку RAD, основываясь на средах Delphi, Visual Studio.
Буду рад встретиться с вами
Продолжу разговор о современных технологиях программирования, ускоряющих разработку и облегчающих нам - программистам, жизнь. Эти технологии прямо противоположны по методике разработке.
Так MDA (Model Driven Architecture) - изначально предполагает, что вы, как архитектор, создадите уже готовую часть (или всю) системы в виде моделей и спецификаций, а остальное на себя возьмет уже среда моделирования. Программистам останется лишь добавить специфической функциональности, что на современный момент не является необходимым - большое количество библиотек классов и фреймворков решают все.
С другой стороны - XP (Extremal Programing), подразумевает упор на кодинге. Сама архитектура вторична, и хотя они ее называют "метафора", это понятие весьма расплывчато. И дизайн системы постоянно улучшается - рефакторится.
Что больше всего интересно, так это то, что оба лагеря обещают быструю и удобную разработку, удовлетворение клиента и своевременную реакцию на изменения.
Я попробовал оба подхода и могу сказать следующее: MDA - вещь хорошая, но есть один нюанс - вы должны быть профессиональным архитектором и знать UML/OCL как свои пять пальцев. Иначе вы запросто заблудитесь в этих спецификациях и функциях системы. Как правило они очень мощные и слишком универсальные. Поэтому надо знать, что творишь и двигаться строго по методологии RUP/UML.
Экстремальное программирование - более легко в освоении, и близко к духу настоящего программирования. Ориентировано на кодирование, тесты и рефакторинг. И все бы хорошо, но оно отличается тем, что без общего плана, лишь с "метафорой" и текущим списком задач далеко не уедешь. Часто происходит то, что говорят: "не зная куда идешь, ты придешь не туда". Из-за этого необходимо поддерживать тесную связь с заказчиком. Даже влить его в команду, как они и советуют. Но наши заказчики - занятые люди и сложно уговорить их работать с нами на равных.
Да и психологически XP сложен в применении. Когда начинаются проблемы с кодом быстро возвращаются старые привычки - вместо маленьких шагов тестирования начинаешь вообще отказываться от него. В уме прокладываешь дорожки в обход и начинаешь глобальные изменения. И все - это больше нельзя назвать экстремальным программированием. А в случае, если заблудишься - то только VCS системы спасут и доставят на ближайший чек-поинт. И хорошо, если пользуетесь ими часто. У меня как то месяц работы накрылся из-за чрезмерно возросшей сложности.
Могу лишь сказать, что я изучал UML с 1996 года и старался стать архитектором ПО. Продукты выходили достойные, но происходило это очень медленно - от 3х до 9и месяцев уходило на рождение системы. Хорошо клиенты попадались понимающие. После чего я встретил экстремальное программирование, и дух творчества и азарт, который начал стихать заново загорелся. Сейчас я делаю небольшие программы за неделю, но оставляю возможность их улучшения. Самое трудное - перейти на автономное тестирование. Рефакторингом мы занимаемся по любому достаточно часто. А вот тестирование, причем, встроенное в процесс разработки - увы не так удобно, как кажется.
Благодарю вас за ваше время.
В следующей статье обсудим разработку RAD, основываясь на средах Delphi, Visual Studio.
Буду рад встретиться с вами
четверг, 17 сентября 2009 г.
Быстрая разработка, как она есть. Или мифы вокруг RAD, MDA и UML.
Быстрая разработка - мечта всех программистов во всем мире. Сколько было придумано различных технологий, сколько копий было сломано в "крестовых войнах" на тему, кто лучше, кто быстрее и удобнее. Но все решило время. Сейчас мы видим, что остались лишь два направления: профессиональное - деньги, бизнес программирования; и свободное - с открытым исходником, клич протеста и величие единого духа программистов.
Когда в 1998 появилась на свет Delphi весь мир кричал: "RAD, RAD - вот панацея от всех бед". Но, как часто и происходит, новые возможности открыли новые проблемы. Да, то что раньше можно было сделать за неделю, сейчас писалось за день, но возникли новые проблемы. Сложность систем возросла экспоненциально. И проблема показала себя с другой стороны. Теперь один человек не мог понять всей системы, которую сам и разрабатывал. И в результате сопровождение у улучшение превращалось в сплошной кошмар.
Но, программисты не сдавались, и вскоре появилась единая система моделирования UML. И хотя она была не сильно удобна в использовании, но зато унифицировала множество имеющихся тогда форматов моделирования: Buch, OMT, и других. После этого группа Unified Solutions выпустила Rational Rose. Эта среда первая могла создавать код по диаграмме и наоборот, преобразовывать код в диаграмму. И забрезжил свет в конце туннеля. Но не тут то было. Оказалось, что генератор не сильно оптимальный и что обучать новому стилю мышления значительно дольше. Эти ребята хотели сократить процесс обучения и даже создали Rational Unified Process (RUP), но дальше IBM он не пошел. Поскольку был тяжеловесен в использовании и обучении.
MDA - Model Driven Architecture
Как только вышла первая среда с разработкой на основе моделей, гиганты начали соревноваться друг с другом в том, кто быстрее и "круче" создаст механизм проектирования с автогенерацией. Borland выпустила JBuilder, попыталась внедрить ModelMaker в Delphi, но все же остановилась на Together Designer (хотя он и не сильно удобен и написан на яве). Microsoft - та вообще встроила в профессиональную среду механизм разработки по модели. Visual Studio 2003-2008 представляют собой пример планомерного развития этой модели.
Многие мелкие разработчики включились в дело. Так возник HiAsm - среда визуального проектирования, где без единой строчки кода можно создать приложение. Но проблема в том, что они все отошли от классического понятия программирования: реализация алгоритма механизмами вычислительной техники. Я, конечно, понимаю, что кодирование уже отходит на задний план. Появились множество средст автогенерации кода - так называемые "визарды" и "эксперты". Появилось множество фреймворков, как общих - вида Net, VCL, MFC; так и частных - SAP, iFIX и других.
Но сообщество программистов восстало против такого обращения с собой и отказалось принимать технологии, убивающие саму сущность программирования - творчество, ради скорострельной наживы. То, что потом служба поддержки, да и сами программисты будут мучаться с улучшением костного и жестко прошитого кода и архитектурной модели - бизнесменов не волновало. Главное было - снять быстрее деньги.
В результате на горизонте появилось новое движение. Возврат к истокам. Отказ от громоздких фреймворков. Кодирование - как основа всего процесса. Это вышел на сцену XP - eXtremal Programing.
Extremal Programing (XP)
И все бы хорошо - новое детище обеспечивало быструю обратную связь, уменьшало возможности ошибок (благодаря сквозному тестированию - TDD), улучшало архитектуру и постоянно поддерживало ее минимально-сложной и актуальной (Refactoring). Но нашлось и здесь несколько сложных моментов. Пара программистов - это хорошо, но некоторые работают одни, а другим убедить менеджера передать работу одного двоим - стало камнем преткновения. И экстремальное программирование потихоньку сместилось в нишу свободных групп, которые управляются также - свободно и возлагают на каждого ту ответственность, которую они сами хотят взять на себя.
Благодарю Вас за то, что вы со мной.
В следующей статье я поведу разговор о сравнении технологий MDA и XP. Два мощнейших направления разработки - два противоположных взгляда на программирование, жизнь и работу.
И кто же из них победит?
Буду ждать вас через неделю.
С уважением, Владимир.
Когда в 1998 появилась на свет Delphi весь мир кричал: "RAD, RAD - вот панацея от всех бед". Но, как часто и происходит, новые возможности открыли новые проблемы. Да, то что раньше можно было сделать за неделю, сейчас писалось за день, но возникли новые проблемы. Сложность систем возросла экспоненциально. И проблема показала себя с другой стороны. Теперь один человек не мог понять всей системы, которую сам и разрабатывал. И в результате сопровождение у улучшение превращалось в сплошной кошмар.
Но, программисты не сдавались, и вскоре появилась единая система моделирования UML. И хотя она была не сильно удобна в использовании, но зато унифицировала множество имеющихся тогда форматов моделирования: Buch, OMT, и других. После этого группа Unified Solutions выпустила Rational Rose. Эта среда первая могла создавать код по диаграмме и наоборот, преобразовывать код в диаграмму. И забрезжил свет в конце туннеля. Но не тут то было. Оказалось, что генератор не сильно оптимальный и что обучать новому стилю мышления значительно дольше. Эти ребята хотели сократить процесс обучения и даже создали Rational Unified Process (RUP), но дальше IBM он не пошел. Поскольку был тяжеловесен в использовании и обучении.
MDA - Model Driven Architecture
Как только вышла первая среда с разработкой на основе моделей, гиганты начали соревноваться друг с другом в том, кто быстрее и "круче" создаст механизм проектирования с автогенерацией. Borland выпустила JBuilder, попыталась внедрить ModelMaker в Delphi, но все же остановилась на Together Designer (хотя он и не сильно удобен и написан на яве). Microsoft - та вообще встроила в профессиональную среду механизм разработки по модели. Visual Studio 2003-2008 представляют собой пример планомерного развития этой модели.
Многие мелкие разработчики включились в дело. Так возник HiAsm - среда визуального проектирования, где без единой строчки кода можно создать приложение. Но проблема в том, что они все отошли от классического понятия программирования: реализация алгоритма механизмами вычислительной техники. Я, конечно, понимаю, что кодирование уже отходит на задний план. Появились множество средст автогенерации кода - так называемые "визарды" и "эксперты". Появилось множество фреймворков, как общих - вида Net, VCL, MFC; так и частных - SAP, iFIX и других.
Но сообщество программистов восстало против такого обращения с собой и отказалось принимать технологии, убивающие саму сущность программирования - творчество, ради скорострельной наживы. То, что потом служба поддержки, да и сами программисты будут мучаться с улучшением костного и жестко прошитого кода и архитектурной модели - бизнесменов не волновало. Главное было - снять быстрее деньги.
В результате на горизонте появилось новое движение. Возврат к истокам. Отказ от громоздких фреймворков. Кодирование - как основа всего процесса. Это вышел на сцену XP - eXtremal Programing.
Extremal Programing (XP)
И все бы хорошо - новое детище обеспечивало быструю обратную связь, уменьшало возможности ошибок (благодаря сквозному тестированию - TDD), улучшало архитектуру и постоянно поддерживало ее минимально-сложной и актуальной (Refactoring). Но нашлось и здесь несколько сложных моментов. Пара программистов - это хорошо, но некоторые работают одни, а другим убедить менеджера передать работу одного двоим - стало камнем преткновения. И экстремальное программирование потихоньку сместилось в нишу свободных групп, которые управляются также - свободно и возлагают на каждого ту ответственность, которую они сами хотят взять на себя.
Благодарю Вас за то, что вы со мной.
В следующей статье я поведу разговор о сравнении технологий MDA и XP. Два мощнейших направления разработки - два противоположных взгляда на программирование, жизнь и работу.
И кто же из них победит?
Буду ждать вас через неделю.
С уважением, Владимир.
пятница, 11 сентября 2009 г.
Благодарность тем, кто создал этот великий мир - компьютер и языки программирования
Мы, программисты, благодарны тем, кто нам помог ощутить красоту этого незабываемого мира, имя которому программирование. Это и общение с устройством, готовым выполнить любую твою команду, и тренировка мышления. И власть, и интересные задачи - это все программирование.
Этот бесценный опыт, что получаешь, начав общаться с компьютером - это знание того, что любую проблему можно решить. И у тебя есть помощник, который всегда к твоим услугам. До этого величие мысли и мощь виртуальных миров были доступны лишь выдающимся математикам. Но, с помощью наших старших братьев, теперь каждый малец может наслаждаться пребыванием в виртуальном мире.
Да, мы каста, мы избранные... Поскольку мы избрали этот путь. И хоть сейчас понятие "программист" сильно расплылось: от прикладников, работа которых напоминает скорее работу каменщика, до глубоких системщиков, которые до сих пор стремятся оптимизировать скорость и объем драйверов любой ценой.
Но все же, несмотря на нашу "разношерстную" компанию мы все благодарны этим людям:
Алан Тьюринг - выдающийся математик, что предложил идею автомата, который будет обрабатывать некоторые данные в полностью независимом от человека режиме. Это был прорыв. Компьютеры, которые мы сейчас видим - это точное воплощение машины Тьюринга. Объем памяти можно считать условно бесконечным, а инструкции записаны в памяти, которую также можно выполнять.
Джон Фон Нейман - величайший математик и первый программист. Придумал идею по расширению машины Тьюринга. Теперь по его определению компьютер должен иметь единую область памяти для кода и данных. Это благодаря ему мы можем создавать полиморфные программы и операционная система может использовать DLL файлы. Мы весьма признательны.
Никлаус Вирт - отец современного стиля обучения программирования, создатель языков Паскаль, Модула, Ада, Оберон и других. Первый, кто решил сделать такой язык, чтобы на нем можно было и обучаться, и благодаря его строгости и стройности - совершенствоваться. И профессионалы, и новички помнят свои первые опыты. Благодаря заслуге фирмы Borland, а именно - Филиппу Кану мы можем теперь наслаждаться быстрым компилятором и красотой языка Паскаль и современнейшими технологиями: RAD, OOP/OOA/OOD, Event Driven Development, Test Driven Development и других. Но отец основатель - он. И мы помним его и очень благодарны.
Стив Джобс - отец персональных компьютеров. До него были лишь монстры IBM и похожих фирм. Он вложил душу в детище, потомки и образы которого теперь у каждого у нас на рабочем столе, дома и даже в карманах. Его эпл до сих пор является мощной и интересной платформой. Но не всем доступной, возможно это и хорошо.
Билл Гейтс - основатель корпорации Microsoft. Создатель и вдохновитель проекта Windows и Visual Studio. Мы знаем, что он многое сделал для того, чтобы доставить комьютеры к каждому из нас. Да не просто пустые ПК, как было раньше, а удобные и приятные в обращение средства для работы и развлечения. Его страсть к Basic-у привела к созданию целого сонма бейсик клонов: и в офисе, и в скриптах, и отдельной средой - это его любимый проект. Мы знаем, что бейсик очень удобен. Я сам программировал на Quick Basic, пока не появился Borland Pascal. После чего бейсик был удостоен звания - язык для прототипов и быстрых набросков. Очень уж легко и быстро на нем пишется ПО. За вклад в развитие мирового программерского сообщества выражаем ему особенную благодарность. Живи и твори, Билли.
И, хотя, он отошел от управления фирмой, но все же его участие чувствуется в духе компании и помощи в образовании по всему миру. Его фонд - сильный метод воздействия на безграмотность.
Благодарю Вас за то, что прочли мою очередную статью. В следующем выпуске мы поговорим с Вами о настоящем "Быстром" программировании.
Буду рад видеть вас на моем блоге
Этот бесценный опыт, что получаешь, начав общаться с компьютером - это знание того, что любую проблему можно решить. И у тебя есть помощник, который всегда к твоим услугам. До этого величие мысли и мощь виртуальных миров были доступны лишь выдающимся математикам. Но, с помощью наших старших братьев, теперь каждый малец может наслаждаться пребыванием в виртуальном мире.
Да, мы каста, мы избранные... Поскольку мы избрали этот путь. И хоть сейчас понятие "программист" сильно расплылось: от прикладников, работа которых напоминает скорее работу каменщика, до глубоких системщиков, которые до сих пор стремятся оптимизировать скорость и объем драйверов любой ценой.
Но все же, несмотря на нашу "разношерстную" компанию мы все благодарны этим людям:
Алан Тьюринг - выдающийся математик, что предложил идею автомата, который будет обрабатывать некоторые данные в полностью независимом от человека режиме. Это был прорыв. Компьютеры, которые мы сейчас видим - это точное воплощение машины Тьюринга. Объем памяти можно считать условно бесконечным, а инструкции записаны в памяти, которую также можно выполнять.
Джон Фон Нейман - величайший математик и первый программист. Придумал идею по расширению машины Тьюринга. Теперь по его определению компьютер должен иметь единую область памяти для кода и данных. Это благодаря ему мы можем создавать полиморфные программы и операционная система может использовать DLL файлы. Мы весьма признательны.
Стив Джобс - отец персональных компьютеров. До него были лишь монстры IBM и похожих фирм. Он вложил душу в детище, потомки и образы которого теперь у каждого у нас на рабочем столе, дома и даже в карманах. Его эпл до сих пор является мощной и интересной платформой. Но не всем доступной, возможно это и хорошо.
Билл Гейтс - основатель корпорации Microsoft. Создатель и вдохновитель проекта Windows и Visual Studio. Мы знаем, что он многое сделал для того, чтобы доставить комьютеры к каждому из нас. Да не просто пустые ПК, как было раньше, а удобные и приятные в обращение средства для работы и развлечения. Его страсть к Basic-у привела к созданию целого сонма бейсик клонов: и в офисе, и в скриптах, и отдельной средой - это его любимый проект. Мы знаем, что бейсик очень удобен. Я сам программировал на Quick Basic, пока не появился Borland Pascal. После чего бейсик был удостоен звания - язык для прототипов и быстрых набросков. Очень уж легко и быстро на нем пишется ПО. За вклад в развитие мирового программерского сообщества выражаем ему особенную благодарность. Живи и твори, Билли.И, хотя, он отошел от управления фирмой, но все же его участие чувствуется в духе компании и помощи в образовании по всему миру. Его фонд - сильный метод воздействия на безграмотность.
Благодарю Вас за то, что прочли мою очередную статью. В следующем выпуске мы поговорим с Вами о настоящем "Быстром" программировании.
Буду рад видеть вас на моем блоге
Подписаться на:
Сообщения (Atom)
