Официальный релиз был 1-ого декабря. Многие ждали этой книги.
Кому интересно, можно скачать с народа книгу и примеры
суббота, 20 декабря 2008 г.
четверг, 18 декабря 2008 г.
пятница, 5 декабря 2008 г.
Поход за молоком, который заставил задуматься
Был обычный вечер пятницы, я возвращался домой с работы, и как обычно бывает - зашел в ближайший супермаркет "Велика кишеня" купить молока. Расплачиваюсь кредиткой (процент не снимается), девушка-кассир говорит: “Введите пинкод”. В голову закрадывается мысль: “Странно, вроде в этом магазине этого делать никогда не нужно было…”. Но, вечер, устал, да и ничего такого страшного вроде сделать не нужно. Фискальный принтер живенько распечатал чек, и кассир мне дал на подпись. Смотрю на сумму – выходит почти 90 гривен(!) – не плохо за 3 пакета молока, да? Говорю: “Это не мой чек – я не буду это подписывать” (когда у тебя квадратные глаза – то крайне сложно прочитать свое имя). Кассир: “Это, наверное, предыдущие покупатели забыли”. И дает мне мой чек на 14 грн. Этот я подписываю, но в голову начинает закрадываться странная мысль, что где-то я уже видел предыдущую сумму. Думаю: “Неужто с меня, только что сняли лишние 90 гривен?”. Решил перепроверить - дождался сообщения от услуги “Mobile Banking”, и таки да – меня оповестили, что с моей карточки последовательно сняли сначала 90, а затем 14 гривен. Поднял кипишь, взял тот не подписанный чек, и прочитав там свое имя стал требовать аудиенции главного кассира. Кассу. ясное дело, закрыли - пришел главный кассир, и стал разбираться, в чем дело. Посмотрели предыдущие чеки – нету чека с такой суммой, раскрутили принтер, стали смотреть контрольную ленту. Стали куда-то звонить. Говорить идентификатор кассира, я вставил 5 копеек, чтобы попробовали по номеру чека поискать – все без результатов, нет такого чека и все. Смотрю на чек еще раз, и до меня доходит, что сумма (двузначное число гривен и копейки) – это мой пинкод. Главный кассир меняется в лице и начинает отчитывать девушку за кассой, что та пропустила важнейшее собрание, на котором рассказывали о новой версии используемого Кышеней программного обеспечения. Передо мной извиняются и принуждают кассира возместить всю сумму из собственного кармана…
Вывод №1 (вторичный) Я понял, откуда такие очереди по вечерам и почему катастрофически не хватает людей за кассой. Ведь никто не захочет за свою малейшую оплошность (или глюк в программе) платить из собственного кармана. У такого крупного магазина просто должен быть резерв на подобные непредвиденные обстоятельства. Конечно, за ошибки наказывать надо, но прям вот так на глазах у всего магазина и на сумму сопоставимую с доходом за день… Жестко, одним словом.
Вывод №2 (вторичный). Теперь очень многие знают мой пинкод. Можно поменять, но не думаю, что кругом одна мафия:)
Вывод №3 (основной). Все же программисты в какой то мере счастливчики. Что случиться с программистом в случае ошибки?
а) Поругают. Не приятно, но пережить можно
б) Его будут мучить угрызения совести. Более неприятно, чем первое.
в) Урежут премию. Вот это уже гораздо хуже, чем выговор.
г) Уволят… Жуткий сценарий. Но если пользователь в результате ошибки понес потери к примеру на 100К $. То программиста не заставят продать квартиру или сесть в тюрьму. А вот, к примеру, начальника цеха на каком-нибудь заводе могут, так как он лицо материально ответственное.
Для меня так и остается загадкой какого фига при первом проводе карточкой программа потребовала ввести сумму, а при втором молча прохавала и пробила чек. И почему первый чек нигде не залогился.
Но после того, как в очередной раз на собственной шкуре убедился, что ошибка – зло (исправление глюков в овертаймах бъет по здоровью, но не по кошельку, а в 23 года о здоровье особо не думаешь, достаточно отоспаться потом:) ) почувствовал, что к коду нужно относиться более бережно, так как для нас это просто код (пусть и такой родной и написанный с таким трудом), а кому-то “маленькие ошибочки” могут нанести огромный вред.
Вывод №1 (вторичный) Я понял, откуда такие очереди по вечерам и почему катастрофически не хватает людей за кассой. Ведь никто не захочет за свою малейшую оплошность (или глюк в программе) платить из собственного кармана. У такого крупного магазина просто должен быть резерв на подобные непредвиденные обстоятельства. Конечно, за ошибки наказывать надо, но прям вот так на глазах у всего магазина и на сумму сопоставимую с доходом за день… Жестко, одним словом.
Вывод №2 (вторичный). Теперь очень многие знают мой пинкод. Можно поменять, но не думаю, что кругом одна мафия:)
Вывод №3 (основной). Все же программисты в какой то мере счастливчики. Что случиться с программистом в случае ошибки?
а) Поругают. Не приятно, но пережить можно
б) Его будут мучить угрызения совести. Более неприятно, чем первое.
в) Урежут премию. Вот это уже гораздо хуже, чем выговор.
г) Уволят… Жуткий сценарий. Но если пользователь в результате ошибки понес потери к примеру на 100К $. То программиста не заставят продать квартиру или сесть в тюрьму. А вот, к примеру, начальника цеха на каком-нибудь заводе могут, так как он лицо материально ответственное.
Для меня так и остается загадкой какого фига при первом проводе карточкой программа потребовала ввести сумму, а при втором молча прохавала и пробила чек. И почему первый чек нигде не залогился.
Но после того, как в очередной раз на собственной шкуре убедился, что ошибка – зло (исправление глюков в овертаймах бъет по здоровью, но не по кошельку, а в 23 года о здоровье особо не думаешь, достаточно отоспаться потом:) ) почувствовал, что к коду нужно относиться более бережно, так как для нас это просто код (пусть и такой родной и написанный с таким трудом), а кому-то “маленькие ошибочки” могут нанести огромный вред.
четверг, 6 ноября 2008 г.
Популярность Delphi растет
Вышел новый рейтинг популярности языков программирования от TIOBE Programming Community.
За последний месяц Delphi поднялся на 3 позиции, и теперь занимает 8 место, при этом дыша в спину C#. Интересно на сколько объективен этот рейтинг, и скажется ли этот рост на Украине хоть в какой-либо степени?
А в лидерах как и раньше Java, C и С++...
За последний месяц Delphi поднялся на 3 позиции, и теперь занимает 8 место, при этом дыша в спину C#. Интересно на сколько объективен этот рейтинг, и скажется ли этот рост на Украине хоть в какой-либо степени?
А в лидерах как и раньше Java, C и С++...
среда, 5 ноября 2008 г.
www.sql-ex.ru
Из конференции разработчиков Firebird узнал об интересном ресурсе, позоляющем повысить (может, кому повезло, и просто проверить) навыки владения SQL. Для решения предоставляется ряд задач, с градацией по сложности от 1 - 4 баллов (1 и 2 легкие даже для меня :), а до троек я пока не дошел:( ).
Посетитель вводит запрос, который исполняется Microsoft SQL Server 2005. Собственно результат проверяется, в случае правильного ответа засчитывается. Хотя два абсолютно разных запроса могут вернуть один и тот же результат (для текущего состояния) базы, засчитается только правильный (заполненность видимой пользователю тестовой базы и базы невидимой разная). На более продвинутых этапах еше и производительность проверяется и если запрос не достаточно оптимизирован - звыняйтэ.
Есть ряд жалоб, что предлагаемые базы плохо спроектированы. Думаю, сделано специально, в целях наглядности. Кроме того, в реальной жизни ведь тоже не все так гладко, так как этакие недочеты в этапе проектирования, могут всплыть на стадии разработки (ну к примеру, заказчик посмотрит предворительную версию программы, и его требования поменяются и т.д., или не все учли при проектировании...)
По результатам тестирования возможно получить сертификаты, если есть такое желание.
Так что будемс дерзать.
Посетитель вводит запрос, который исполняется Microsoft SQL Server 2005. Собственно результат проверяется, в случае правильного ответа засчитывается. Хотя два абсолютно разных запроса могут вернуть один и тот же результат (для текущего состояния) базы, засчитается только правильный (заполненность видимой пользователю тестовой базы и базы невидимой разная). На более продвинутых этапах еше и производительность проверяется и если запрос не достаточно оптимизирован - звыняйтэ.
Есть ряд жалоб, что предлагаемые базы плохо спроектированы. Думаю, сделано специально, в целях наглядности. Кроме того, в реальной жизни ведь тоже не все так гладко, так как этакие недочеты в этапе проектирования, могут всплыть на стадии разработки (ну к примеру, заказчик посмотрит предворительную версию программы, и его требования поменяются и т.д., или не все учли при проектировании...)
По результатам тестирования возможно получить сертификаты, если есть такое желание.
Так что будемс дерзать.
пятница, 17 октября 2008 г.
Assembla стала попсой :(
Assembla.com - великолепный сервис для управления проектами. Пожалуй лучшее, что я пока видел. Обидно только то, что популярность к этому ресурсу пришла гораздо быстрее, чем сам ресурс дорос до этого с технической точки зрения. Как результат, первым делом было сокращено место на сервере под проект с 500 до 200 мб, теперь вот чуть ли не каждый день на сервере ведутся работы, и по полдня нельзя на сайт зайти.
Из жизненных наблюдений. Когда на рынок выходит новый продукт, он зачастую великолепного качества (взять к примеру сгущенку:) ). Через некоторое время, появляется куча дешевых подделок, и самое обидное, что и сам производитель перестает уделять должное внимание качеству.
Однако конкуренция в IT существенно превышает конкуренцию во многих других сферах, так что думаю, что за качеством все равно следить по большому счету нужно, хотя реалии таковы, что зачастую потребителю побыстренькому кидается сырая версия, чтобы опередить конкурентов. А дальше как повезет:)
Вспомнил фильм "Пираты Силиконовой Долины". Там в конце фильма Джобс говорит Гейтсу:
- Бил наш Макинтош лучше Вашего Виндоуз
- Ты так и не понял, Стив? Это уже не имеет ни какого значения...
P.S. ЗЫ сейчас проверю ассемблу, авось уже починили, и я наконец смогу прочитать тикет:)
Из жизненных наблюдений. Когда на рынок выходит новый продукт, он зачастую великолепного качества (взять к примеру сгущенку:) ). Через некоторое время, появляется куча дешевых подделок, и самое обидное, что и сам производитель перестает уделять должное внимание качеству.
Однако конкуренция в IT существенно превышает конкуренцию во многих других сферах, так что думаю, что за качеством все равно следить по большому счету нужно, хотя реалии таковы, что зачастую потребителю побыстренькому кидается сырая версия, чтобы опередить конкурентов. А дальше как повезет:)
Вспомнил фильм "Пираты Силиконовой Долины". Там в конце фильма Джобс говорит Гейтсу:
- Бил наш Макинтош лучше Вашего Виндоуз
- Ты так и не понял, Стив? Это уже не имеет ни какого значения...
P.S. ЗЫ сейчас проверю ассемблу, авось уже починили, и я наконец смогу прочитать тикет:)
четверг, 2 октября 2008 г.
Public – protected – private
Мой друг Паша на днях изложил свои мысли по поводу возможности разделения функций привычных всем модификаторов доступа еще и "модификаторами наследования"... Собственно размышления носят сугубо теоретический характер и я точно не могу судить, на сколько подобная возможность была бы востребована на практике, но сама идея кажется интересной. Собственно вот оригинал статьи:
Public – protected – private.
В последнее время стал замечать, что что-то не так в этой троице. Вроде как все просто – public это модификатор доступа, указывающий, что к элементу можно получить доступ извне, private – только другим членам этого же класса, а protected – этого же класса и производных от него. Но ведь это не так!
То есть вроде и так, но не так. Ведь если вспоминать про производные классы, то можно сказать что помеченный словом public – это наследуемый член, private – не наследуемый, а protected – снова же наследуемый.
То есть получается, что эти три модификатора – это не только модификаторы “доступа”, а еще и модификаторы “наследования” одновременно. Где
Разумно было бы разделить понятия модификаторов доступа и модификаторов наследования, оставив для доступа public и private, и выделив для наследования, например, inherited и non-inherited. Тогда получим еще и четвертую комбинацию – public + non-inherited.
Многие могут сказать, что такая комбинация не нужна, но как известно применение может быть найдено всему чему угодно :) Например, вспомогательный открытый метод, который не пригодиться в производных классах. Кроме того явное использование модификаторов наследования позволит не раздувать производные классы, что в какой-то мере реабилитирует “повторное использование кода” при наследовании.
Конечно, можно предположить, что возникнут проблемы с вызовами виртуальных функций, которые есть в базовом классе, но нет в производном. Почему бы не вызывать как виртуальные только те методы, которые класс реализует от наследуемого интерфейса, так сказать подписывает контракт на реализацию. Такой метод будет гарантировать, что все нужные методы (т.е. те которые указаны в интерфейсе) всегда будут и в производных классах.
Public – protected – private.
В последнее время стал замечать, что что-то не так в этой троице. Вроде как все просто – public это модификатор доступа, указывающий, что к элементу можно получить доступ извне, private – только другим членам этого же класса, а protected – этого же класса и производных от него. Но ведь это не так!
То есть вроде и так, но не так. Ведь если вспоминать про производные классы, то можно сказать что помеченный словом public – это наследуемый член, private – не наследуемый, а protected – снова же наследуемый.
То есть получается, что эти три модификатора – это не только модификаторы “доступа”, а еще и модификаторы “наследования” одновременно. Где
| Доступ | Наследование | |
| Public | Public | Inherited |
| Private | Private | Non-inherited |
| Protected | Private | Inherited |
Разумно было бы разделить понятия модификаторов доступа и модификаторов наследования, оставив для доступа public и private, и выделив для наследования, например, inherited и non-inherited. Тогда получим еще и четвертую комбинацию – public + non-inherited.
Многие могут сказать, что такая комбинация не нужна, но как известно применение может быть найдено всему чему угодно :) Например, вспомогательный открытый метод, который не пригодиться в производных классах. Кроме того явное использование модификаторов наследования позволит не раздувать производные классы, что в какой-то мере реабилитирует “повторное использование кода” при наследовании.
Конечно, можно предположить, что возникнут проблемы с вызовами виртуальных функций, которые есть в базовом классе, но нет в производном. Почему бы не вызывать как виртуальные только те методы, которые класс реализует от наследуемого интерфейса, так сказать подписывает контракт на реализацию. Такой метод будет гарантировать, что все нужные методы (т.е. те которые указаны в интерфейсе) всегда будут и в производных классах.
среда, 24 сентября 2008 г.
Google Phone
Не знаю, толи это я такой дремучий, толи мир движется слишком быстро... Возможно, что я просто не очень внимательно слежу за новинками IT индустрии, но если признаться честно – то выход мобильного телефона от Гугля меня просто шокировал. Если перед выходом Ghrome я еще что-то знал, то эта новость меня довольно сильно удивила.
Собственно в желании компании расширять свою клиентскую базу, ничего странного нету, тем более что политика гугла направлена на расширение. Но все эти IPhone, IPod’ы, теперь еще и Google Phone’ы мне почему то напоминают ситуацию начала-середины 90-х, когда родители покупали игрушку, а на коробке было указано, что производитель – это машино-тракторный завод…
Насколько мне известно, то первое серийное (массовое?) производство сего девайса будет базироваться на о.Тайвань и цена будет составлять 180$. До нас дойдет примерно через год. Если цена не будет превышать 300-400 баксов, то возможно я буду в числе покупателей :), так как моя черно-белая Моторола, с тупейшим и неудобнейшим интерфейсом пользователя, мягко говоря достала.
Думаю, свою долю на рынке GPhone займет, а если интеграция с такими сервисами как Google Maps, You Tube и собственно с поисковиком будет на уровне, то телефончик станет просто хитом.
пятница, 12 сентября 2008 г.
среда, 3 сентября 2008 г.
Программист, он как самбист - делает все на автомате:)
О том, когда кто-то просит составить, к примеру, список продуктов, а ты с нуля начинаешь...
Вот заметил за собой еще маленький бзик: когда набираю какой-то текст, или путь в браузере машинально нажимаю Ctrl + Space.
Интересно, какие еще приколы люди за собой замечают?
Вот заметил за собой еще маленький бзик: когда набираю какой-то текст, или путь в браузере машинально нажимаю Ctrl + Space.
Интересно, какие еще приколы люди за собой замечают?
OFF: Обстановка все же влияет на результат
В моем спортзале сделали ремонт. После того как покрасили стены, возникло ощущение пространства, а благодаря вытяжке - есть чем дышать! Я на радостях присел 150, до личного рекорда (170) пока еще далеко, но это гораздо лучше, чем когда умираешь от 120.
пятница, 29 августа 2008 г.
Delphi 2009
На сайте кодегиров висит флешка с весьма громким заявлением: "The next generation of speed, connectivity and productivity is here". Что ж буду ждать когда выйдет скачать на халяву.
Со времен легендарной семерки делфа конечно продвинулась неймоверно: как улучшения в IDE так и в языке Delphi (да теперь он официально именно так называется, а не Object Pascal как любят с умным видом твердить университетские профессора:) ).
Если в семерке даже такие казалось бы банальные вещи как статические поля и методы класса были не возможны...
Пока из новых фич о которых я читал в Тибурон добавили:
- полноценную поддержку Unicode. Круто конечно, теперь автора многих Shareware будут просто пищать от удовольствия:)
- TObject обзавелся тремя новыми методами: ToString, GetHashCode и Equals
- Exit с параметром. Инересно почему нигде кроме как в PHP не додумались сделать с параметрами Break и Continue?
- класс TStringBuilder. Интересно неужто теперь объекты типа string нельзя изменять будет:)
- Шаблоны. С-шники теперь не смогут в холиворах этот пункт как аргумент приводить:)
- Анонимные методы.
- Поддержка лямбда-исчисления. Смутно помню что оно такое, почему то вспомнил о Lisp.
- Улучшены компоненты доступа к данным. Embarcadero одним словом.
Что удивило, что в Delphi2009 нету поддержки .NET. Ну и не надо - для этого есть C#:) Думаю, что кому либо кроме Мягкософта угнаться за выходом очередного фрейморка крайне тяжело...
В общем нас ждет светлое будущие. Жаль только, что новость об очередной фишке, как то TStringBuilder наводит странные мысли: "Где то я это уже видел?!". Перенимать лучшее, что есть у конкурентов это конечно здорово, но какой-то неприятный горький осадок почему то остается...
P.S. Вчера дочитал Рихтера "CLR via C#". Думаю, что в ближайшее время нужно побольше внимание посвещать непосредственно кодированию. А дальше посоветовали для общего развития ознакомиться с:
1. LINQ: язык интегрированных запросов в C# 2008 для профессионалов Джозеф C. Раттц-мл.
WPF.
2. Windows Presentation Foundation в .NET 3.5 с примерами на C# 2008 для профессионалов Мэтью Мак-Дональд
3. И не плохо было бы и по делфе прочитать что-небудь уровня Рихтера:)
Со времен легендарной семерки делфа конечно продвинулась неймоверно: как улучшения в IDE так и в языке Delphi (да теперь он официально именно так называется, а не Object Pascal как любят с умным видом твердить университетские профессора:) ).
Если в семерке даже такие казалось бы банальные вещи как статические поля и методы класса были не возможны...
Пока из новых фич о которых я читал в Тибурон добавили:
- полноценную поддержку Unicode. Круто конечно, теперь автора многих Shareware будут просто пищать от удовольствия:)
- TObject обзавелся тремя новыми методами: ToString, GetHashCode и Equals
- Exit с параметром. Инересно почему нигде кроме как в PHP не додумались сделать с параметрами Break и Continue?
- класс TStringBuilder. Интересно неужто теперь объекты типа string нельзя изменять будет:)
- Шаблоны. С-шники теперь не смогут в холиворах этот пункт как аргумент приводить:)
- Анонимные методы.
- Поддержка лямбда-исчисления. Смутно помню что оно такое, почему то вспомнил о Lisp.
- Улучшены компоненты доступа к данным. Embarcadero одним словом.
Что удивило, что в Delphi2009 нету поддержки .NET. Ну и не надо - для этого есть C#:) Думаю, что кому либо кроме Мягкософта угнаться за выходом очередного фрейморка крайне тяжело...
В общем нас ждет светлое будущие. Жаль только, что новость об очередной фишке, как то TStringBuilder наводит странные мысли: "Где то я это уже видел?!". Перенимать лучшее, что есть у конкурентов это конечно здорово, но какой-то неприятный горький осадок почему то остается...
P.S. Вчера дочитал Рихтера "CLR via C#". Думаю, что в ближайшее время нужно побольше внимание посвещать непосредственно кодированию. А дальше посоветовали для общего развития ознакомиться с:
1. LINQ: язык интегрированных запросов в C# 2008 для профессионалов Джозеф C. Раттц-мл.
WPF.
2. Windows Presentation Foundation в .NET 3.5 с примерами на C# 2008 для профессионалов Мэтью Мак-Дональд
3. И не плохо было бы и по делфе прочитать что-небудь уровня Рихтера:)
четверг, 21 августа 2008 г.
Надоело чесать правой рукой левое ухо...
Чего-то в моем блоге последнее время больше жалоб на жизнь, чем технической информации:( А куда еще душу изливать?:)
На работе после перетасовки отделов, я получился единственным штатным программистом на отдел (!). Оно бы еще ничего, если бы человек работающий на удалёнке имел возможность работать на нас по человеческим часам. А так чтобы что-то спросить/предложить/обсудить приходиться писать письмо (к примеру с утра), которое он часов в 12 ночи прочитает и ответит. Так как естественно с первого раза к соглашению мы не приходим, то такая вот переписка может растянуться на несколько дней, хотя при живом общении вопрос решился бы ну минут за 30 максимум. Как по мне, то такой стиль общения приемлем для общения с клиентом (учитвая географическую удаленность или еще какие-то факторы, хотя в некоторых аутсорсах ради такой цели дежурных на ночь назначают) , возможно с удаленным разработчиком работающим где-небудь в Дели, но не с таким же человеком из Киева. Вот и выходит такая своеабразная пробуксовка на месте...
На работе после перетасовки отделов, я получился единственным штатным программистом на отдел (!). Оно бы еще ничего, если бы человек работающий на удалёнке имел возможность работать на нас по человеческим часам. А так чтобы что-то спросить/предложить/обсудить приходиться писать письмо (к примеру с утра), которое он часов в 12 ночи прочитает и ответит. Так как естественно с первого раза к соглашению мы не приходим, то такая вот переписка может растянуться на несколько дней, хотя при живом общении вопрос решился бы ну минут за 30 максимум. Как по мне, то такой стиль общения приемлем для общения с клиентом (учитвая географическую удаленность или еще какие-то факторы, хотя в некоторых аутсорсах ради такой цели дежурных на ночь назначают) , возможно с удаленным разработчиком работающим где-небудь в Дели, но не с таким же человеком из Киева. Вот и выходит такая своеабразная пробуксовка на месте...
четверг, 10 июля 2008 г.
Наверное пора в отпуск...
Странные сны последнее время снятся... Позавчера о перспективах развития отдела кастомизации. Вчера немного закемарил перед телевизором, и мне приснилась реалезация какого-то класса, который после пробуждения я не смог воспроизвести. А ночью снилось, как я убеждал всех остальных на работе перейти на .NET, и нами в качестве инструмента было выбранно Delphi for .NET. И когда мне уже будут пальмы с морским песочком сниться...
SharpDevelop – альтернатива Visual Studio!!!
Наткнулся вчера на весьма достойный проект. http://wiki.sharpdevelop.net/. Первые впечатления сугубо положительные. Порадовало, что в заинсталенном виде занимает всего 30 Мб. Тянем меня, почему-то, последнее время к минимализму и всяческим OpenSource. Логотип SharpDevelop – шестеренка, почему то напомнил времена, проведенные под KDE (на подсознательном уровне вызвало ностальгию и задало общее восприятие на позитив).
Естественно главное окно без бутылки, не отличишь от студийного. Ничего лишнего.
Не нашел визуальный контсруктор форм. Не сказал бы, что сей факт меня сильно порадовал, но и не то, чтобы растроил:) Мы привыкшие в runtime компоненты создавать, тем более, я так подозреваю, что при желании можно подгрузить ресурсы с формой.
Почитал документацию, узнал что он должен быть(прям как суслик)
Есть возможность создавать приложения WPF для третьего фрейморка.
О таких приятных мелочах как подсведка синтаксиса, поиск и автозавершение кода я молчу, так как не одно средство, предендующие на почетное звание IDE, без этого просто не обойдется.
Порадовало, что сразу же встроенные такие вещи как модульное тестирование, CodeAnalysis и возможность работать с Subversion непосредственно из среды.
Разработка под мобильные устройства типа КПК, смартфоны и т.д., как я понял не предусмотренна (а может я просто плохо искал...), не увидел ServerExlorer'a и некоторых еще возможностей студии, которые я и не использую. Затем обнаружил, что ServerExlorer есть, только он называется DatabaseExlorer и находится немного не там, где я ожидал его увидеть.
Растроило весьма скудненькое меню рефакторинга
но думаю, что это обязательно исправится в следующих релизах.
Сразу же в меню Tools включен дизасемблер, и зачем то возможность перегонять исходный текст в блокнот:)
Затем решили с Пашей немного поиздеваться, и переименовали папку AddIns, на удивление ничего страшного не произошло, затем я переименовал папку AddIns\AddIns и при запуске обнаружилось, что оболочка функционирует, только кнопка Debug стала неактивной. Затем я все же полностью удалил AddIns и наконецто смог получить долгожданный exception, который заслуживает особого внимания
Еще его можно выбросить из меню Help\About. Кстати сам help - это MSDN, какое отношение этот инструмент имеет к Microsoft (кроме того, что предназначен для работы с одним из основных направлений деятельности мелгомягких:), я выяснять не стал).
Немного покалупавшись, нашел файлы локализации, и возникло желание чем то помочь... к примеру заняться локализацией для державної мови України, так как на великий и могучий, я так думаю, и без меня есть кому переводить.
Реализована поддержка плагинов, и их создание обещает быть более простым чем для студии с её COM (Паша на это очень надееться и я тоже). Покрайней мере, доступность исходников порождает перспективы для полета фантазии.
Вот впринципе и все, на большее пока времени не хватает:(
Естественно главное окно без бутылки, не отличишь от студийного. Ничего лишнего.
Не нашел визуальный контсруктор форм. Не сказал бы, что сей факт меня сильно порадовал, но и не то, чтобы растроил:) Мы привыкшие в runtime компоненты создавать, тем более, я так подозреваю, что при желании можно подгрузить ресурсы с формой.
Почитал документацию, узнал что он должен быть(прям как суслик)
Есть возможность создавать приложения WPF для третьего фрейморка.
О таких приятных мелочах как подсведка синтаксиса, поиск и автозавершение кода я молчу, так как не одно средство, предендующие на почетное звание IDE, без этого просто не обойдется.
Порадовало, что сразу же встроенные такие вещи как модульное тестирование, CodeAnalysis и возможность работать с Subversion непосредственно из среды.
Разработка под мобильные устройства типа КПК, смартфоны и т.д., как я понял не предусмотренна (а может я просто плохо искал...), не увидел ServerExlorer'a и некоторых еще возможностей студии, которые я и не использую. Затем обнаружил, что ServerExlorer есть, только он называется DatabaseExlorer и находится немного не там, где я ожидал его увидеть.
Растроило весьма скудненькое меню рефакторинга
но думаю, что это обязательно исправится в следующих релизах.
Сразу же в меню Tools включен дизасемблер, и зачем то возможность перегонять исходный текст в блокнот:)
Затем решили с Пашей немного поиздеваться, и переименовали папку AddIns, на удивление ничего страшного не произошло, затем я переименовал папку AddIns\AddIns и при запуске обнаружилось, что оболочка функционирует, только кнопка Debug стала неактивной. Затем я все же полностью удалил AddIns и наконецто смог получить долгожданный exception, который заслуживает особого внимания
Еще его можно выбросить из меню Help\About. Кстати сам help - это MSDN, какое отношение этот инструмент имеет к Microsoft (кроме того, что предназначен для работы с одним из основных направлений деятельности мелгомягких:), я выяснять не стал).
Немного покалупавшись, нашел файлы локализации, и возникло желание чем то помочь... к примеру заняться локализацией для державної мови України, так как на великий и могучий, я так думаю, и без меня есть кому переводить.
Реализована поддержка плагинов, и их создание обещает быть более простым чем для студии с её COM (Паша на это очень надееться и я тоже). Покрайней мере, доступность исходников порождает перспективы для полета фантазии.
Вот впринципе и все, на большее пока времени не хватает:(
четверг, 3 июля 2008 г.
И кто сказал, что мое поколение мало читает?
Начал читать Роббинс Дж. "Отладка приложений для Microsoft.NET и Microsoft Windows". Заинтриговало. Возникает вопрос: "почему я читал так мало специализированных книг раньше"? Turbo Pascal 7.0 и Delphi от Фролова не считается:) огромный толмут "Руководство системного администратора Unix" тоже... так как линуксоид из меня, увы не вышел (может ещё не поздно?). Практически все свое свободное время трачу на чтение и попытки воплотить прочитаное в жизнь.
Попытаюсь вспомнить все, что я прочитал за последние полгода (Оскар Уайлд и др. не считаю).
1. Учебник по созданию Shareware-программ. Жарков. Все хочу попробывать, но все имеющиеся поделки, как то стыдно выкладывать (а смысл от продукта которым сам не гордишся?)
2. Троэлсен Э. C# и платформа .NET. Попса мягко говоря... книга из серии "C++ за 24 часа"
3. Addison.Wesley.C.Sharp.Programming.Language. Поинтереснее Троэлсена. Хотя все равно упора на практику как по мне маловато.
4. Firebird руководство разработчика баз данных. Хеллен Борри. вместе с содержимым сайте ibase.ru Реально зачет. Жаль только, что многие из вопросов описанных для меня пока трудноваты.
5. Понимание SQL. Мартин Грабер (Martin Gruber). Стандарт SQL без привязки к конкретному серверу. Очень хорошие примеры.
6. Быстрая разработка программ: принципы, примеры, практика , Роберт C. Мартин. Нужно не забыть Диме отдать книжку:)
7. Практически весь сборник статей DRKB 3.0. вот из-за такого вот сборника (Delphi world) я в свое время делфийстом стал:) описание и решение многих реальных проблем, реальными живыми людьми.
8. Кнута увы уже 2 года не могу заставить себя читать всерьез... хватает на неделю, две и все:(
Инересно, а что значит много читать?
Попытаюсь вспомнить все, что я прочитал за последние полгода (Оскар Уайлд и др. не считаю).
1. Учебник по созданию Shareware-программ. Жарков. Все хочу попробывать, но все имеющиеся поделки, как то стыдно выкладывать (а смысл от продукта которым сам не гордишся?)
2. Троэлсен Э. C# и платформа .NET. Попса мягко говоря... книга из серии "C++ за 24 часа"
3. Addison.Wesley.C.Sharp.Programming.Language. Поинтереснее Троэлсена. Хотя все равно упора на практику как по мне маловато.
4. Firebird руководство разработчика баз данных. Хеллен Борри. вместе с содержимым сайте ibase.ru Реально зачет. Жаль только, что многие из вопросов описанных для меня пока трудноваты.
5. Понимание SQL. Мартин Грабер (Martin Gruber). Стандарт SQL без привязки к конкретному серверу. Очень хорошие примеры.
6. Быстрая разработка программ: принципы, примеры, практика , Роберт C. Мартин. Нужно не забыть Диме отдать книжку:)
7. Практически весь сборник статей DRKB 3.0. вот из-за такого вот сборника (Delphi world) я в свое время делфийстом стал:) описание и решение многих реальных проблем, реальными живыми людьми.
8. Кнута увы уже 2 года не могу заставить себя читать всерьез... хватает на неделю, две и все:(
Инересно, а что значит много читать?
пятница, 27 июня 2008 г.
О наболевшем
Стоит передомной задача... Если следовать утверждению, что клиент не всегда прав, то этот клиент уж сильно не прав. Но он готов платить денег столько, что руководство хватается за него руками и ногами. И что мне делать, если для удовлетворения требований нужно идти в разрез с одним из основных принципов системы? нет ну я могу попробовать систему обмануть, другой вопрос во что оно потом выльется через определенное время... если в клиентской базе полный срач, и названия типа "Аспирин", "Асперин", "Асприн" плодятся в невероятном количестве? уже порядком поднадоело отвечать на письма: "у Вас уже есть этот медикамент в базе, у вас название медикамента с ошибкой написано" брррр...
вторник, 24 июня 2008 г.
Шаблоны проектирования. Часть 2.
Abstract Factory and Factory Method.
Если честно, то я, наверное, до конца так и не понял, в чем различие между этими шаблонами. Оба предназначены для создания групп объектов, которые имеют общее поведение (было бы странно если бы они имели разное реализуя общий интерфейс). Хотя естественно, что если мы наследуем просто от класса с абстрактными методами, то в классе потомке можно добавить новые уникальные методы, чего не сделаешь с классами, которые наследуются от TInterfacedObject.
Реализация Abstract Factory (в наглую сдерта с вики + небольшие правки)
Реализация FactoryMethod
Builder.
Позволяет сконструировать сложный объект на основе “кирпичиков” – более простых объектов. Выходит, что мы можем иметь два объекта одного типа, но с разным содержимым.
Реализация
Пример использования
Если честно, то я, наверное, до конца так и не понял, в чем различие между этими шаблонами. Оба предназначены для создания групп объектов, которые имеют общее поведение (было бы странно если бы они имели разное реализуя общий интерфейс). Хотя естественно, что если мы наследуем просто от класса с абстрактными методами, то в классе потомке можно добавить новые уникальные методы, чего не сделаешь с классами, которые наследуются от TInterfacedObject.
Реализация Abstract Factory (в наглую сдерта с вики + небольшие правки)
unit AbstractFactory;
interface
type
// AbstractProduct
TCar = class
public
function Info: string; virtual; abstract;
end;
// ConcreteProductA
TFord = class(TCar)
public
procedure Test;
function Info: string; override;
end;
// ConcreteProductB
TToyota = class(TCar)
public
function Info: string; override;
end;
// AbstractFactory
TCarFactory = class
public
function CreateCar: TCar; virtual; abstract;
end;
// ConcreteFactoryA
TFordFactory = Class(TCarFactory)
public
function CreateCar: TCar; override;
end;
// ConcreteFactoryB
TToyotaFactory = Class(TCarFactory)
public
function CreateCar: TCar; override;
end;
implementation
{ TFord }
function TFord.Info: string;
begin
Result:='Ford';
end;
procedure TFord.Test;
begin
Writeln('TFord.Test');
end;
{ TToyota }
function TToyota.Info: string;
begin
Result:='Toyota';
end;
{ TFordFactory }
function TFordFactory.CreateCar: TCar;
begin
Result := TFord.Create;
end;
{ TToyotaFactory }
function TToyotaFactory.CreateCar: TCar;
begin
Result := TToyota.Create;
end;
end.
Реализация FactoryMethod
unit FactoryMethod;
interface
type
// "Product"
IProduct = interface
procedure GetName;
end;
// "ConcreteProductA"
TConcreteProductA = class(TInterfacedObject, IProduct)
procedure GetName;
end;
// "ConcreteProductB"
TConcreteProductB = class(TInterfacedObject, IProduct)
procedure GetName;
end;
// "Creator"
ICreator = interface
function FactoryMethod: IProduct;
end;
// "ConcreteCreatorA"
TConcreteCreatorA = class(TInterfacedObject, ICreator)
function FactoryMethod: IProduct;
end;
// "ConcreteCreatorB"
TConcreteCreatorB = class(TInterfacedObject, ICreator)
function FactoryMethod: IProduct;
end;
implementation
{ TConcreteCreatorA }
function TConcreteCreatorA.FactoryMethod: IProduct;
begin
Result := TConcreteProductA.Create;
end;
{ TConcreteCreatorB }
function TConcreteCreatorB.FactoryMethod: IProduct;
begin
Result := TConcreteProductB.Create;
end;
{ TConcreteProductA }
procedure TConcreteProductA.GetName;
begin
Writeln('TConcreteProductA.GetName;');
end;
{ TConcreteProductB }
procedure TConcreteProductB.GetName;
begin
Writeln('TConcreteProductB.GetName;');
end;
end.
Builder.
Позволяет сконструировать сложный объект на основе “кирпичиков” – более простых объектов. Выходит, что мы можем иметь два объекта одного типа, но с разным содержимым.
Реализация
unit Builder;
interface
uses
SysUtils, Classes;
type
// Product
TProduct = class
private
FParts: TStringList;
public
procedure Add(Part: string);
procedure Show;
constructor Create;
destructor Destroy;
end;
// Builder
IBuilder = interface['{52A37564-3B0B-4A5A-ADF0-1DD7AB3A6789}']
procedure BuildPartA;
procedure BuildPartB;
function GetResult: TProduct;
end;
// ConcreteBuilder1
TConcreteBuilder1 = class(TInterfacedObject, IBuilder)
private
FProduct: TProduct;
public
procedure BuildPartA;
procedure BuildPartB;
function GetResult: TProduct;
constructor Create;
destructor Destroy;
end;
// ConcreteBuilder2
TConcreteBuilder2 = class(TInterfacedObject, IBuilder)
private
FProduct: TProduct;
public
procedure BuildPartA;
procedure BuildPartB;
function GetResult: TProduct;
constructor Create;
destructor Destroy;
end;
TDirector = class
public
procedure Construct(Builder: IBuilder);
end;
implementation
{ Product }
procedure TProduct.Add(Part: string);
begin
FParts.Add(Part);
end;
constructor TProduct.Create;
begin
FParts := TStringList.Create;
end;
destructor TProduct.Destroy;
begin
FreeAndNil(FParts);
end;
procedure TProduct.Show;
var
I: Integer;
begin
Writeln('Product Parts -------');
for I := 0 to FParts.Count - 1 do
Writeln(FParts[I]);
end;
{ TConcreteBuilder1 }
procedure TConcreteBuilder1.BuildPartA;
begin
FProduct.Add('PatrA');
FProduct.Add('PatrB');
FProduct.Add('PatrC');
end;
procedure TConcreteBuilder1.BuildPartB;
begin
FProduct.Add('PatrD');
end;
constructor TConcreteBuilder1.Create;
begin
FProduct := TProduct.Create;
end;
destructor TConcreteBuilder1.Destroy;
begin
FreeAndNil(FProduct);
end;
function TConcreteBuilder1.GetResult: TProduct;
begin
Result := FProduct;
end;
{ TConcreteBuilder2 }
procedure TConcreteBuilder2.BuildPartA;
begin
FProduct.Add('PatrX');
end;
procedure TConcreteBuilder2.BuildPartB;
begin
FProduct.Add('PatrY');
end;
constructor TConcreteBuilder2.Create;
begin
FProduct := TProduct.Create;
end;
destructor TConcreteBuilder2.Destroy;
begin
FreeAndNil(FProduct);
end;
function TConcreteBuilder2.GetResult: TProduct;
begin
Result := FProduct;
end;
{ TDirector }
procedure TDirector.Construct(Builder: IBuilder);
begin
Builder.BuildPartA();
Builder.BuildPartB();
end;
end.
Пример использования
var //Builder Director: TDirector; B1, B2: IBuilder; P1, P2: TProduct; begin Director := TDirector.Create; B1 := TConcreteBuilder1.Create; Director.Construct(B1); P1 := B1.GetResult; P1.Show; B2 := TConcreteBuilder2.Create; Director.Construct(B2); P2 := B2.GetResult; P2.Show; end;
четверг, 19 июня 2008 г.
Шаблоны проектирования. Глава 1.
Здесь буду высказывать свое мнение и реализацию относительно некоторых паттернов проектирования.
Итак, поехали.
Шаблоны проектирования (паттерн, pattern) — это эффективные способы решения характерных задач проектирования, в частности проектирования компьютерных программ. Паттерн не является законченным образцом проекта, который может быть прямо преобразован в код, скорее это описание или образец для того, как решить задачу, таким образом, чтобы это можно было использовать в различных ситуациях.
http://ru.wikipedia.org/wiki/Шаблоны_проектирования
В принципе вопросов по поводу определения не возникает. Интересно, что подразумевают люди, когда в резюме пишут "Владею шаблонами проектирования"? Имхо как по мне сей факт мало о чем говорит. Ведь можно наизусть зазубрить все 73 шаблона (я столько насчитал) и абсолютно не применять их на практике, либо применять там, где это не нужно (так называемая “избыточная сложность”). А можно и без знания того или иного шаблона своим умом дойти до эффективного решения. Ну да ладно это вопрос таланта, опыта и .т.д. Другой вопрос, что человек, который знаком с сабжем при решении реальной задачи, возможно, вспомнит о том или ином шаблоне и попросту не будет изобретать велосипед (но тут таки опять таки больше вопрос в том уместно ли сей шаблон применять). Так что фразу "Владею шаблонами проектирования" я бы перефразировал в “Знаком с шаблонами проектирования и знаю, в какой ситуации, какой применять”.
Лирическое отступление закончил. Начну пожалуй обзор.
Delegation pattern/Шаблон делегирования
Довольно полезный шаблон позволяющий решить проблему множественного наследования. Суть в том, чтобы передать реализацию того или иного метода связанному объекту.
Реализация 1.
В принципе в данном примере все прозрачно, с помощью методов TClassDel.ToClassA и TClassDel.ToClassB меняем ссылку на базовый класс, в котором и содержится необходимая реализация.
Реализация 2
Также есть класс отвечающий за реализацию. С помощью procedure IImplInterface.P1 = MyP1; можно переопределить метод TImplClass тоесть в моем понимании некий аналог виртуальных методов.
Functional design/Шаблон функционального дизайна
Функциональный дизайн гарантирует, что каждый модуль компьютерной программы имеет только одну обязанность и исполняет её с минимумом побочных эффектов на другие части программы.
Вроде бы это и так понятно. Как говорится нужно отделять “Мух от котлет”. У Мартина в “Быстрая разработка программ: принципы, примеры, практика” на эту тему много чего написано.
Immutable
Идея в использовании неизменяемых объектов. Вполне может быть в некоторых ситуациях полезна. Хотя я не вижу сложности в том, чтобы создать такой объект. Представляю себе это примерно так:
Итак, поехали.
Шаблоны проектирования (паттерн, pattern) — это эффективные способы решения характерных задач проектирования, в частности проектирования компьютерных программ. Паттерн не является законченным образцом проекта, который может быть прямо преобразован в код, скорее это описание или образец для того, как решить задачу, таким образом, чтобы это можно было использовать в различных ситуациях.
http://ru.wikipedia.org/wiki/Шаблоны_проектирования
В принципе вопросов по поводу определения не возникает. Интересно, что подразумевают люди, когда в резюме пишут "Владею шаблонами проектирования"? Имхо как по мне сей факт мало о чем говорит. Ведь можно наизусть зазубрить все 73 шаблона (я столько насчитал) и абсолютно не применять их на практике, либо применять там, где это не нужно (так называемая “избыточная сложность”). А можно и без знания того или иного шаблона своим умом дойти до эффективного решения. Ну да ладно это вопрос таланта, опыта и .т.д. Другой вопрос, что человек, который знаком с сабжем при решении реальной задачи, возможно, вспомнит о том или ином шаблоне и попросту не будет изобретать велосипед (но тут таки опять таки больше вопрос в том уместно ли сей шаблон применять). Так что фразу "Владею шаблонами проектирования" я бы перефразировал в “Знаком с шаблонами проектирования и знаю, в какой ситуации, какой применять”.
Лирическое отступление закончил. Начну пожалуй обзор.
Delegation pattern/Шаблон делегирования
Довольно полезный шаблон позволяющий решить проблему множественного наследования. Суть в том, чтобы передать реализацию того или иного метода связанному объекту.
Реализация 1.
unit DelegationPattern;
interface
uses SysUtils;
type
IDelegateInterface = interface ['{37573FCA-5D5B-4340-9D64-5CB61F672BB6}']
procedure Method1;
procedure Method2;
end;
TClassA = class(TInterfacedObject, IDelegateInterface)
public
procedure Method1;
procedure Method2;
end;
TClassB = class(TInterfacedObject, IDelegateInterface)
public
procedure Method1;
procedure Method2;
end;
TClassDel = class(TInterfacedObject, IDelegateInterface)
private
FInterface: IDelegateInterface;
public
procedure Method1;
procedure Method2;
procedure ToClassA;
procedure ToClassB;
end;
implementation
{ TClassA }
procedure TClassA.Method1;
begin
Writeln('TClassA.Method1');
end;
procedure TClassA.Method2;
begin
Writeln('TClassA.Method2');
end;
{ TClassB }
procedure TClassB.Method1;
begin
Writeln('TClassB.Method1');
end;
procedure TClassB.Method2;
begin
Writeln('TClassB.Method1');
end;
{ TClassDel }
procedure TClassDel.Method1;
begin
FInterface.Method1;
end;
procedure TClassDel.Method2;
begin
FInterface.Method2;
end;
procedure TClassDel.ToClassA;
begin
FInterface := TClassA.Create;
end;
procedure TClassDel.ToClassB;
begin
FInterface := TClassB.Create;
end;
end.
В принципе в данном примере все прозрачно, с помощью методов TClassDel.ToClassA и TClassDel.ToClassB меняем ссылку на базовый класс, в котором и содержится необходимая реализация.
Реализация 2
type
IImplInterface = interface['{96387A25-C8F4-4275-A553-802F9955CF62}']
procedure P1;
procedure P2;
end;
TImplClass = class
procedure P1;
procedure P2;
end;
TMyImplClass = class(TInterfacedObject, IImplInterface)
FMyImplClass : TImplClass;
property MyImplClass: TImplClass read FMyImplClass implements IImplInterface;
procedure IImplInterface.P1 = MyP1;
procedure MyP1;
procedure MyProc;
end;
implementation
{ TImplClass }
procedure TImplClass.P1;
begin
Writeln('TMyImplClass.P1');
end;
procedure TImplClass.P2;
begin
Writeln('TMyImplClass.P2');
end;
{ TMyImplClass }
procedure TMyImplClass.MyP1;
begin
Writeln('TMyClass.MyP1');
end;
procedure TMyImplClass.MyProc;
begin
Writeln('TMyClass.MyProc');
end;
Также есть класс отвечающий за реализацию. С помощью procedure IImplInterface.P1 = MyP1; можно переопределить метод TImplClass тоесть в моем понимании некий аналог виртуальных методов.
Functional design/Шаблон функционального дизайна
Функциональный дизайн гарантирует, что каждый модуль компьютерной программы имеет только одну обязанность и исполняет её с минимумом побочных эффектов на другие части программы.
Вроде бы это и так понятно. Как говорится нужно отделять “Мух от котлет”. У Мартина в “Быстрая разработка программ: принципы, примеры, практика” на эту тему много чего написано.
Immutable
Идея в использовании неизменяемых объектов. Вполне может быть в некоторых ситуациях полезна. Хотя я не вижу сложности в том, чтобы создать такой объект. Представляю себе это примерно так:
type
TImmutable = class
private
FData: string;
public
procedure Write;
constructor Create(Data: string);
protected
property Data: string read FData;
end;
implementation
{ TImmutable }
procedure TImmutable.Write;
begin
Writeln(FData);
end;
constructor TImmutable.Create(Data: string);
begin
FData := Data;
end;
вторник, 17 июня 2008 г.
DUnit
Проводить автоматизированное тестирование собственного программного кода хорошо. Первое case средство, которое бросилось в глаза – утилита DUnit (если верить тому, что написано в About ее идея принадлежит самому Кенту Беку (Kent Beck) [падает ниц и бьет челом]). Тулза изначально на sourceforge обитает, и с некоторых пор включена в комплект поставки с Делфи (надо будет ещё нечто подобное для студии посмотреть). Итак, попробую описать основные принципы работы с DUnit.
Для начала создадим новый проект с помощью Test Project Wizard (File -> Other -> Unit Test -> Test Project). Теперь, когда у нас есть готовый проект для тестирования, нам осталось добавить тестируемые модули (File -> Other -> Unit Test -> Unit Case). В результате работы кодогенератора мы получим шаблон теста для модуля, который нужно подключить к проекту (если пользоваться не делфовской DUnit, а той, которая на sourceforge лежит, то для преобразования кода можно использовать утилитку XPGen из Conrlib).
Запустив тестовый проект на исполнение, увидим дерево тестируемых методов. Для того, чтобы начать тестирование нажмем зелененькую кнопку.
Как видно из рисунка, один из моих методов провалился (деление на ноль однако).
Хотя переменная I1 и не определена. Это конечно не ошибка и для обнаружения подобных недоразумений есть подсказки компилятора, чтение и исправление которых в дальнейшем сильно облегчает жизнь.
Для начала создадим новый проект с помощью Test Project Wizard (File -> Other -> Unit Test -> Test Project). Теперь, когда у нас есть готовый проект для тестирования, нам осталось добавить тестируемые модули (File -> Other -> Unit Test -> Unit Case). В результате работы кодогенератора мы получим шаблон теста для модуля, который нужно подключить к проекту (если пользоваться не делфовской DUnit, а той, которая на sourceforge лежит, то для преобразования кода можно использовать утилитку XPGen из Conrlib).
Запустив тестовый проект на исполнение, увидим дерево тестируемых методов. Для того, чтобы начать тестирование нажмем зелененькую кнопку.
Как видно из рисунка, один из моих методов провалился (деление на ноль однако).
procedure TForm3.btnTest1Click(Sender: TObject); var D1, D2: Double; begin D1 := 0; D2 := 1/D1; ShowMessage(FloatToStr(D2)); end;А вот второй метод прошел на ура.
procedure TForm3.btnTest2Click(Sender: TObject); var I1: Integer; begin ShowMessage(IntToStr(I1)); end;
Хотя переменная I1 и не определена. Это конечно не ошибка и для обнаружения подобных недоразумений есть подсказки компилятора, чтение и исправление которых в дальнейшем сильно облегчает жизнь.
пятница, 13 июня 2008 г.
Firebird Hymn
Fire, Fire, Fire!!, Fire!
It was old very complex unresolved task
Low budget, too weak chips, and complete time lack
People said with no doubt - it’s impossible to do
But I knew with the fire inside I can do
Power of bytes, embed in my heart
Ready to fight, be enough smart
You need – Firebird!
Build it in right way, break the limits, you can hit them down
Do it simpler, but faster, and faster! We have some fun!
Use Fire triggers, stored procedures, save the time
Burn business rules, use all nice tools
Yeah, yearh, Fire! Fire! Burning inside!
Download it for free
Can I code it again please
Yeah deploy was so fast
It was - Firebird
Firebird, Firebird, Firebird, yeah
Download it for free
Nice to code – try please!
Firebird, Firebird
Firebird, Firebird
Yeah, it’s alright, we’re doin’ right
Yeah, it’s alright, we’re doin’ fine, fine, fine
Firebird,
Firebird, Firebird
Firebird, baby, baby
Firebird, you’ve been Firebird!
It was old very complex unresolved task
Low budget, too weak chips, and complete time lack
People said with no doubt - it’s impossible to do
But I knew with the fire inside I can do
Power of bytes, embed in my heart
Ready to fight, be enough smart
You need – Firebird!
Build it in right way, break the limits, you can hit them down
Do it simpler, but faster, and faster! We have some fun!
Use Fire triggers, stored procedures, save the time
Burn business rules, use all nice tools
Yeah, yearh, Fire! Fire! Burning inside!
Download it for free
Can I code it again please
Yeah deploy was so fast
It was - Firebird
Firebird, Firebird, Firebird, yeah
Download it for free
Nice to code – try please!
Firebird, Firebird
Firebird, Firebird
Yeah, it’s alright, we’re doin’ right
Yeah, it’s alright, we’re doin’ fine, fine, fine
Firebird,
Firebird, Firebird
Firebird, baby, baby
Firebird, you’ve been Firebird!
среда, 4 июня 2008 г.
О самосовершенствовании
Последнее время мучают мысли: "Почему учась в институте, так немногому научился...". Думаю причин не так уж и много:
1. Отсутствие серьезного стимула. Чтобы сдать сессию (главный двигатель студента), в далеко не самом престижном ВУЗе страны навыки программирования особо не нужны, так как, много предметов абсолютно не связанных с будущей специальностью, а уровень требований, к знанию предметов профильных, чрезвычайно низок.
2. Отсутствие наблюдения за "зубрами". Большинство адекватных студентов приблизительно равны и ты просто не видишь людей, производительность которых в 10, 100, 1000 раз выше, чем у тебя (программистский синхрофазатрон), поэтому складывается впечатление, что все ок.
3. Привычка конторить... Я думаю каждый хоть раз сдавал абсолютно левую лабу:)
4. Отсутствие "старших товарищей", которые могут в нужном направлении подтолкнуть.
5. Полное отсутствие контроля за качеством кода (на второй моей работе за это взялись серьезно). Я, конечно понимаю, что нужно самому проводить так называемый рефакторинг, но я в те времена даже слова такого не знал:)
6. Уйма свободного времени. Расслабляет, однако.
7. Возможно, нужно было идти работать не на 5-ом курсе, а на годик раньше.
8. Смутное представление о размерах сообщества программистов. В OpenSource почему то даже не пробывал лезть, а необходимость править, а порой даже компилить чужие исходники под линух наводила страх. Были попытки навоять что-либо интересное с одногрупниками, но все они сошли на нет.
Ну вот... думал напишу пару пунктов и успокоюсь, как оказалось самокритиковать себя могу весьма долго.
И так, что мы имеем на сегодняшний день? Работа программистом уже 1,5 года, наконец, пришло понимание (а возможно иллюзия понимания), в какую примерно сторону нужно двигаться, огромное желание развиваться и не тратить время на бесполезные занятия, видны кое-какие примеры для подражания, пусть часть из них и виртуальны. Осознание того, что реальная работа может быть не всегда интересной и порой даже рутинной, но само программирование весьма занятно. Любовь "хорошо покушать", что требует профессионально роста, так как за красивые глазки никто нормально платить не будет.
Так что "вперед и только вперед, не шагу назад".
1. Отсутствие серьезного стимула. Чтобы сдать сессию (главный двигатель студента), в далеко не самом престижном ВУЗе страны навыки программирования особо не нужны, так как, много предметов абсолютно не связанных с будущей специальностью, а уровень требований, к знанию предметов профильных, чрезвычайно низок.
2. Отсутствие наблюдения за "зубрами". Большинство адекватных студентов приблизительно равны и ты просто не видишь людей, производительность которых в 10, 100, 1000 раз выше, чем у тебя (программистский синхрофазатрон), поэтому складывается впечатление, что все ок.
3. Привычка конторить... Я думаю каждый хоть раз сдавал абсолютно левую лабу:)
4. Отсутствие "старших товарищей", которые могут в нужном направлении подтолкнуть.
5. Полное отсутствие контроля за качеством кода (на второй моей работе за это взялись серьезно). Я, конечно понимаю, что нужно самому проводить так называемый рефакторинг, но я в те времена даже слова такого не знал:)
6. Уйма свободного времени. Расслабляет, однако.
7. Возможно, нужно было идти работать не на 5-ом курсе, а на годик раньше.
8. Смутное представление о размерах сообщества программистов. В OpenSource почему то даже не пробывал лезть, а необходимость править, а порой даже компилить чужие исходники под линух наводила страх. Были попытки навоять что-либо интересное с одногрупниками, но все они сошли на нет.
Ну вот... думал напишу пару пунктов и успокоюсь, как оказалось самокритиковать себя могу весьма долго.
И так, что мы имеем на сегодняшний день? Работа программистом уже 1,5 года, наконец, пришло понимание (а возможно иллюзия понимания), в какую примерно сторону нужно двигаться, огромное желание развиваться и не тратить время на бесполезные занятия, видны кое-какие примеры для подражания, пусть часть из них и виртуальны. Осознание того, что реальная работа может быть не всегда интересной и порой даже рутинной, но само программирование весьма занятно. Любовь "хорошо покушать", что требует профессионально роста, так как за красивые глазки никто нормально платить не будет.
Так что "вперед и только вперед, не шагу назад".
среда, 28 мая 2008 г.
Настройки цветовой схемы Visual Studio
Не могу долго работать при стандартных настройках студии, белый цвет по глазам сильно бьет. По этому перенастраиваю путем замены файла настроек.
Для установки файла настроек:
1. Нажмите меню Tools
2. Выберите Import and Export Settings
3. Выберите 'Import Selected Environment Settings' и нажмите Next
4. Сделайте резервную копию текущих настроек
5. Выберите файл настроек и нажмите Next
6. Подтвердите перезапись настроек только для шрифта и цветов, нажмите Finish
7. Enjoy
Вот отсюда можно скачать различные темы.
Для установки файла настроек:
1. Нажмите меню Tools
2. Выберите Import and Export Settings
3. Выберите 'Import Selected Environment Settings' и нажмите Next
4. Сделайте резервную копию текущих настроек
5. Выберите файл настроек и нажмите Next
6. Подтвердите перезапись настроек только для шрифта и цветов, нажмите Finish
7. Enjoy
Вот отсюда можно скачать различные темы.
вторник, 27 мая 2008 г.
Начало
Вот и я присоединился к модной нынче тенденции ведения блогов. На вопрос: зачем? Отвечаю: “Хочу так”. Буду записывать сюда некоторые мысли, ведь интересно, к примеру, через год почитать себя самого и попытаться оценить прогресс за год.