?

Log in

No account? Create an account
nearly programming themes
 
[Most Recent Entries] [Calendar View] [Friends]

Below are the 7 most recent journal entries recorded in teamat's LiveJournal:

Saturday, February 24th, 2007
9:35 pm
Куда развиваться?
В современном мире знание нескольких языков сложно переоценить. Это вытекает хотя бы из того, что среди прочих требований к кандидатам на подавляющее большинство должностей (в основном и IT-индустрии) присутствует знание английского языка. Это, как известно, стандарт де-факто международного общения. Специалист со знанием английского языка ценится на много выше, нежели не владеющий им человек. Можно долго размусоливать все прелести свободного владения иностранными языками, но думаю ни кто не будет спорить с приведенными выше утверждениями.
Между прочим точно такая же ситуация и в мире программирования. Сейчас редко можно встретить высокооплачиваемого профессионального программиста со знанием какого-то одного языка программирования. Как минимум следует знать основной и вспомогательный языки. Кстати, даже не очень глубокое знание вспомогательного языка, может существенно повысить эффективность применения основного. В программировании как и в естественном общении есть язык которым должен владеть специалист, это С (и его производные). Что касается программирования для WEB, то таким языком можно назвать PHP. Он используется в подавляющем большинстве интернет приложений, и пока не думает сдавать позиции.
Данные утверждения звучат как призыв: - «Учите C или PHP (если вы web-программист) как основной язык». Но соображающий читатель поймет некоторую его шаткость. Действительно, если посмотреть на то как быстро меняются стандарты и требования в последние годы, можно увидеть, что такая же ситуация через 5-10 лет совсем не факт. Может быть, вскоре уже никому не нужен будет PHP. И что тогда делать профессиональному PHP программисту? Переучиваться? Но так сразу на другую технологию не перейдешь. Нужно какое-то время на практику. Программист работающий с каким-то языком 3 года на много более продуктивен, чем начинающих, пусть даже и знания самого языка у них одинаковые. Так что переезд на другую технологию стоит не дешево.
В свете всего этого выбирая основной язык следует 7 раз подумать, а не хвататься сразу просто за злободневные вопросы. Сейчас может быть модно и актуально одно, а завтра уже совсем другое и нужно смотреть в будущее. Приведу простой пример. Для тех кто следит за индустрией не секрет, что развитие процессоров по пути увеличения частоты уперлось в тепловой барьер. Выделение тепла даже при малом увеличении частоты уже превосходит всякие разумные пределы, которые требуют мощной системы охлаждения и уже не просто киллеров, а подходов основанных на жидком азоте. Это во-первых дорого, во-вторых неудобно. Так что разработчики процессоров перешли на новый принцип, многоядерность. И это направление теперь будет активно развиваться. Что это значит? Что на серьезные приложения в будущем понадобятся специалисты в области разработки под многопроцессорные (многоядерные) системы. То есть можно уже сейчас увидеть то, что будет актуально в перспективе и сделать правильный выбор, что является самым важным этапом в начале профессионального пути каждого человека.
Wednesday, February 14th, 2007
1:08 am
Отладка. Несколько советов.
Контр-адмирал ВМС США и один из авторов языка COBOL, покойная Грейс Хоппер, утверждала, что слово “bug” появилось в программировании во время первого крупного цифрового компьютера – Mark I. Разбираясь с причинами неисправности компьютера, программисты нашли в нем крупного мотылька, замкнувшего какую-то цепь, и с тех пор вину за все компьютерные проблемы стали сваливать на насекомых. Вне программирования же это слово уходит корнями как минимум во времена Томаса Эдисона.
Вообще говоря, ошибки их поиск, устранение и предупреждение важная часть процесса разработки программ, которой при подготовке специалистов обычно уделяют незаслуженно мало внимания. Действительно, я не могу припомнить, что бы в каком либо из изучаемых мною учебных планов какого либо имеющего отношение к программированию факультета, какого либо вуза отдельным пунктом был бы вынесен цикл лекций о проблемах отладки, возможно и бывает пара докладов, но на этом все и ограничивается. Максимум что обычно сообщается по этому поводу – отлаживайтесь брэйк пойнтами. Однако это серьезное упущение в полноте читаемых курсов, в некоторый проектах отладка занимает 50% общего времени разработки. Таким образом, студент, а в последствии специалист зачастую вынужден изобретать концепции отладки заново. Ужасная трата времени и сил.
Здесь я постараюсь дать несколько дельных советов по отладке и предупреждению ошибок, надеюсь они помогут вам при случае.
Лучший способ создания качественной программы заключается в тщательной выработке требований, грамотном проектировании и кодировании. Отладка на самом деле средство крайнего случая. Вообще, о чем говорит наличие дефекта? Исходя из того, что оно нежелательно, это говорит о том, что вы не полностью понимаете программу. Все же, программа должна делать то что нужно. Если вы не до конца понимаете указания которые даете компилятору, вскоре всего вскоре начнете программировать методом проб и ошибок. В таком случае дефекты неизбежны. Вам не нужно учиться исправлять ошибки, нужно знать как их избегать. Однако люди несовершенны и даже прекрасные программисты допускают ошибки. Вы можете попробовать изучить собственные ошибки, подумать как их можно было предотвратить, содержит ли код другие такие ошибки. Следует изучить программу, над которой работаете, изучить качество своего кода, убедиться, что он удобочитаем, для другого человека, как его можно улучшить. Учитывая что на отладку уходит солидная часть времени разработки программы, время потраченное на осмысление того, удачно ли выбрана вами стратегия отладки и изменение процесса отладки может сослужить вам большую службу. Тоже самое можно сказать о самом способе исправления ошибок. Подумайте, вносите ли вы простые исправления используя частные случаи, которые устраняют в основном симптомы, но не причину, или вы совершаете системные исправления, точно определяя и устраняя причины проблем?
В своем бессмертном творении Данте отвел нижний круг ада самому Сатане. Но с тех пор кое что изменилось, сейчас Сатана делит нижний круг с программистами, не умеющими эффективно отлаживать программы. Он мучает их, заставляя отлаживать код используя популярные, но не эффективные принципы:
Например для нахождения дефектов можно разбросать по программе команды печати и изучить выходные данные. Если так выявить ошибку не удается, можно попробовать изменить тот или иной участок кода, авось что получится. Если вы точно не знаете что делает программа, программирование становится более увлекательным. Советую запастись колой и чипсами, потому что за монитором вам придется провести всю ночь.
Сатана в бесконечной своей щедрости выделили часть ада программистам, отлаживающимся опираясь на суеверия. В каждой группе есть программист, бесконечно сражающийся с демоническими компьютерами, таинственными дефектами компилятора, скрытыми дефектами языка, которые проявляются только в полнолуние, заколдованными текстовыми редакторами, которые неправильно сохраняют код… Это и есть «суеверное программирование».
Следует запомнить одну вещь. Если написанная вами программа не работает, ошибка лежит на вашей совести, а компьютер с компилятором ни в чем не виноваты.
К счастью существуют более эффективные способы отладки, чем гадание. Отладка программы основанная на размышлении о проблеме на много эффективнее чем танцы с бубном вокруг системного блока. Лучшие программисты не гадают, как исправить дефект, они используют интеллектуальный подход и научные методы.
Можно еще долго вести разговоры об отладке, это на много более глубокий вопрос чем может показаться с первого взгляда. Если кому-то интересно более подробное изучение проблемы, могу посоветовать эти книги:
- Mayers, Glenford J. “The Art of Saftware Testing”. NY: John Wiley & Sons, 1979.
Это классика жанра, одна из глав которой посвящена отладке
- Agans, David J. “Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems.” Amacom, 2003.
В этой книге рассматриваются общие принципы отладки, независящие ни от языка, ни от среды.
Monday, February 12th, 2007
6:46 pm
История из Microsoft
Многие ругают корпорацию Microsoft за разведенный ею монополизм (что в принципе вполне справедливо), кто-то за то, что с навязываемыми ею программными продуктами невозможно нормально работать, мол, падучие, тормозные, и вообще один сплошной глюк. Кто-то просто, потому что это модно и думает, что за поношение софтверного гиганта старшие, более солидные, товарищи будут его уважать. Последний случай граничит с идиотизмом, потому как мало кто из людей чье сознание способно охватить всю индустрию в целом и оценить вклад Microsoft в ее развитие, будет разделять убеждения о «корпорации зла». Ну а на других равняться собственно и не стоит.
Я завел разговор о компании Билла Гейтса потому, что недавно вспомнил одну историю о разрабатывавшем некую программу отделении Microsoft, прекрасно иллюстрирующее настроения и отношение к клиенту в этой корпорации. Заказчику нужна была, к истории не имеет отношения что делающая, программа в которой разработчики использовали маленький контрол «сетка», представляющий собой таблицу, с пятнадцатью простыми методами. На каком-то этапе разработчикам понадобилась возможность менять цвета отдельных ячеек сетки, но данный контрол не поддерживал такого метода. Под рукой оказалась «электронная таблица» (которую можно лицезреть в excel-е), конечно предоставляющая необходимую функциональность. Электронная таблица это огромный, жирный, с полутора сотнями методом контрол. Но от этого компонента требовалась лишь одна функция отсутствовавшая в сетке, так что одному из программистов команды было поручено создать дочерний компонент от Электронной таблицы, поддерживающий все методы которые есть в сетке и еще один, смену цвета ячеек, а все остальные методы от Электронной таблицы должны были быть закрыты. В итоге все было сделано, и в конечный вариант программы был включен 16 методовый, огромный компонент который раздул и утяжелил продукт в разы.
Вообще, создается впечатление, что в Microsoft примерно так ко всему и относятся, вот у нас универсальная (пусть большая и тяжелая) библиотека для решения любой задачи, и можно ее всегда использовать. По хорошему, для программы, о которой говорилось выше следовало бы написать контрол с 16-ю необходимыми методами, а не включать в нее сотню ненужных, которые хоть и не видны но здорово нагружают приложение.

Возвращаясь к вопросу о правильных именах переменных, относительно которого у нас с ivirus-ом возникла небольшая дискуссия в коментах. Приведу немного более широкий пример, но он все же правильно отображает мысль, которую я вложил в тот пост (примеры будут приводиться на языке Pascal):

Как думаете, что в следующем цикле означает число 12?:

Непонятный код
for i := 1 to 12 do
	profit[i] := revenue[i] – expense[i]; 


Исходя из содержимого кода, можно предположить, что выполняется цикл по двенадцати месяцам года. Но вы уверены?
Можно развеять сомнения с помощью хорошо названной именованной константы:

Более понятный код
for i := 1 to NUM_MONTH_IN_YEAR do
	profit[i] := revenue[i] – expense[i]; 


Это уже лучше, но для большей понятности кода (например если тело цикла достаточно большое) индекс тоже следует назвать более информативно:

Еще более понятный код
for month := 1 to NUM_MONTH_IN_YEAR do
	profit[month] := revenue[month] – expense[month]; 


Этот пример весьма неплох, но можно сделать еще один шаг вперед, применив перечислимый тип данных:

Очень понятный код
for month := january to december do
	profit[month] := revenue[month] – expense[month]; 


В последнем примере не может возникнуть никаких сомнений относительно назначения цикла.
Это я и имел в виду.
Saturday, February 10th, 2007
8:37 pm
О трудолюбии.
У вас не бывало так? Вы думаете над темой статьи, или того же поста (нормальных размеров и посвященного какой-то теме) в блог, над курсовой, чем угодно, что требует более менее творческого подхода. Вам в голову приходит не дарственная тема для рассмотрения, у вас есть какие-то идеи по этому поводу, и сначала у вас в голове уже есть план изложения, которое грозит выйти вполне приличным. Вы приступаете к работе, излагаете свои мысли, но где-то к концу статьи понимаете, что получилась, мягко говоря, слабо похожая на то что вы представляли в начале ахинея, а ведь никаких отступлений от первоначального плана вы собственно и не делали. Бывало? Вот и у меня недавно возникло такое ощущение. И что с ним делать? И переделывать все с самого начала уже нет ни времени, ни желания. Ну да ладно, это так, лирическое отступление.
Столкнулся я недавно с одним не мною написанным js сценарием, который мне нужно было оптимизировать, слишком уж он тормозил на слабеньких машинах. Скрипт выполнял сортировку списка присутствующих в чате по одному из нескольких параметров. Так вот, когда присутствующие в чате переваливали за, скажем, 100, у некоторых участников на минуту, а то и больше, вешала браузер, естественно иногда не обходилось без сообщения, что сценарий отжерает слишком много ресурсов, и его бы лучше остановить. Конечно, js интерпретируемый язык, и на его швыткость не особо нужно надеяться, а вопрос того, что лучше, сортировать данные на стороне клиента или сервера, это тема, требующая отдельного рассмотрения. Углубившись в код, стало ясно, что для сортировки используется стандартный метод массивов – sort. Ну, ей богу, товарищи программисты, неужели нельзя сделать нормальную сортировку, а не эту на уровне 8 класса? Все самые лучшие алгоритмы когда либо придуманные человечеством доступны в сети, их никто не прячет. Не ленитесь и не стесняйтесь использовать чью либо наработку, если конечно дело не доходит до плагиата. Конечно, для разных ситуаций лучше подходят разные алгоритмы. Тогда можно выбирать, какой метод применять при разных размерах сортируемых наборов. Это отнимет у вас пол часа жизни и расширит код на пару тройку килобайт, но, зато повысит удобство пользователей. Да и ишней головной боли как для вас так и для заказчика поможет избежать.
Thursday, February 8th, 2007
9:13 pm
Простейшие правила хорошего кода. Размышления на тему
Думаю ни кто не будет спорить, что в идеале каждый человек должен в жизни заниматься тем, что у него лучше всего получается. Например, мне с моим отсутствием художественного вкуса не стоит лезть в создание дизайнов, или семплов, но я думаю, что в своем направлении я хоть немного, да преуспел. Так же талантливый плотник редко бывает еще и хорошим фармацевтом. Всем следует заниматься тем, что у них лучше получается и не лезть не с свою среду, иначе кроме посредственности из этого ничего не выйдет.
Я недавно зашел на сайт какой-то браузерной online игры и из бесконечного своего любопытства заглянул в исходные тесты страницы. Там было подключено несколько js модулей обеспечивающих всю интерактивность в игре. Хорошо, в принципе все работало как, видимо, и было описано в ТЗ (техническом задании) проекта. Но посмотрев на сам код, мне показалось, что программную часть реализовал человек, если и не достаточно далекий от серьезного программирования, то по крайней мере совсем не знакомый с теорией и не способный сам додуматься до простейших ее аксиом. Всем понятно, что код должен быть удобочитаемым и понятным, это одно из первых требований которое предъявляется в серьезных проектах. И желательно, что бы у программиста такой подход велся в спинной мозг, а для этого нужно всегда, даже в маленьких программках, придерживаться данного правила. Прежде всего, нужно приучить себя правильно называть переменные и функции, и выделять все логические части. Например, если функция ищет на странице элемент по какому-то признаку, и создает новый, в том случае если искомый элемент обнаружен, то лучше разделить ее на две, функцию поиска, и функцию создания нового узла, которая будет вызываться из первой по тому же условию. Ведь просто, и достаточно придерживаться этого незамысловатого правила, что бы повысить сопровождаемость программы. На счет правильных имен. Пример с упоминаемого выше игрового сайта. Там есть была функция «go», описанная так:

function go(a){
	return document.all[a];
}


Тоесть, она возвращает а-тый элемент из списка всех элементов на странице. Такое название функции еще свидетельствует о том, что написавший ее слабо знаком с языком на котором программировал. У объекта location есть метод «go» (выполняющий совсем другую задачу) и не сложно понять, что наличие описанной выше функции, где ни будь в коде, может вызвать затруднение у изучающего текст. Это было бы не важно, если бы один человек все время вел проект, сам занимался его модификацией и так далее. Но в больших программах может возникнуть ситуация, когда ведущий разработчик меняется, и ему придется потратить много времени, что бы вникнуть во все что написал предшественник, если тот не соблюдал простых правил поддержки читабельности кода. Исходя из контекста, лучше было бы назвать функцию как ни будь вроде «getDocumentElementByIndex» Это название говорит само за себя. Так же в циклах по каким-то наборам лучше не использовать абстрактные индексы типа i или j, а назвать эти переменные в соответствии с тем, что они обозначают, например номер элемента, или сотрудника.
Придерживайтесь простых правил поддержания своего кода в приличном виде и если когда ни будь надумаете профессионально заняться программированием, или уже занимаетесь, то этот нехитрый совет поможет вам и вашим коллегам сэкономить много времени и сил.
Wednesday, February 7th, 2007
11:02 pm
Web-тесты для программиста. Размышления на тему.
Программирование, да и вообще ИТ, можно изучать по разному. Существуют специализированные факультеты в ВУЗ’ах, школы, и прочие учебные заведения. Можно засесть за учебники и вникать в принципы самостоятельно, или, как начинал (по крайней мере с web-программированием) я, взять конкретную, сущуствующую, проблему и решать ее, попутно естественным путем постигая область задачи. В учебных заведениях существует контроль качества образования (в миру – контрольные и экзамены), а как быть с проверкой своих знаний доморощенным специалистам? Конечно, на самом деле никакая проверка знаний не нужна, если человек сам взялся изучать некоторую область (и вполне удачно практикует в ней), но с другой стороны бывает просто интересно, сколько ты на самом деле знаешь. Так и мне недавно стало интересно, на сколько хорошо я знаю, такую неотъемлемую и важную для современного web-программиста часть постепенно вытисняющего привычные полу статические страницы принципа web2.0, JavaScript. Всевидящие поисковики послушно выдали мне ряд ссылок на сайты где можно протестировать себя. Честно признаюсь, я опробовал не более 10 тестов, и все они сводились к вопросам базовыx знаний освещаемых в главаx введения в язык почти любого учебника по JavaScript. Но ведь это не правильно. Подтвердив знания за 5 класс нельзя утверждать что ты успешно сдал дипломную работу (соотношение глубины проверки знаний и реальной сложности программирования на JavaScript примерно такое). На одном сайте по прохождении теста мне сказали что теперь я имею право называть себя дипломированным «Специалистом JavaScript» и могу получить соответствующий сертификат. На самом деле, я считаю проверку знаний в области программирования на подобие – «Как правильно описать многострочный комментарий» или «В какой строке синтаксически верно вызывается функция», в корне неправильным подходом. Программисту не нужно помнить, как называется функция добавления данных в буфер обмена, для таких знаний существуют справочники и другая документация, которой не грешно пользоваться. Программист должен понимать фундаментальные основы и принципы разработки на данной технологии. Он должен понимать (не просто знать), как устроен тот или иной интерфейс, что одни методы меняют свойства объектов, другие нет, что объект XMLHttpRequest (так востребованный в современных web-приложениях) имеет много состояний выполнения запроса, ну и так далее. А те тесты, что представлены в интернете, ни коим образом не отображают истинные знания и направлены на людей, позавчера узнавших о предмете рассмотрения. Таким образом, они абсолютно не практичны, и знания свои следует проверять исключительно в разработке реальных приложений, а тестами пользоваться так, ради забавы. Конечно, главным мерилом того, что вы хорошо знаете и свободно ориентируетесь в какой-то технологии, является удовлетворенность заказчика результатом вашей работы.
Thursday, April 27th, 2006
3:10 pm
Стандарты. Размышления на тему.
Великое дело стандарты. Что в изготовлении пакетов для молока, что в web-программировании, что в полетах на луну. Но мне из трех перечисленных занятий ближе второе, потому о нем и поговорим. В последнее время, и это радует, наблюдается все большее и большее осознание массой web-дизайнеров и web-программистов того, что если они не будут считаться со стандартами, их ресурсы могут потерять значительную долю посетителей. Это заявление мало касается отечественного сегмента интернета, где с большим перевесом среди браузеров все еще лидирует не безызвестный Internet Explorer (IE) v6.0. Такое обстоятельство обеспечивается в основном благодаря бесчисленному сонму пользователей либо не знающих про альтернативные браузеры вовсе, потому как в интернет заходят только за чем-то вроде "реферат скачать да на городской форум глянуть", либо их "вполне устраивает IE". Вот это консерватизм ("Работает и хорошо"), во многом влияет на положение.
Но речь все же не о войне браузеров, а о стандартах, хотя вопрос используемого браузера в данной ситуации весьма актуален. Два главных и общеизвестных стандарта это, конечно же, HTML (XHTML) и CSS (про XML, как показывает практика, некоторые web-разработчики знают лишь то, что он есть, а другие и вовсе не слышали). На первый взгляд HTML допускает разметки и без секции HEAD, а META теги вполне жизнеспособны в теле документа и работают как должно (хотя у некоторых поисковых машин и может возникнуть недопонимание с логикой создателя страницы). Но это только на первый взгляд. Стоит браузеру-блюститлю стандартов загрузить текст такой страницы и пользователь тут же увидит сообщение об ошибке. Посмотрит на него, по смотрит, и уйдет дальше бороздить сеть. Это самый простой пример несоответствия стандартам, хотя W3C определила, что в документе должны присутствовать и HEAD и BODY и точно обозначила последовательность и даже указала что можно, а что нельзя помещать в ту или иную секцию. С CSS сейчас ситуация лучше. Начинающие web-разработчики по большей части имеют весьма смутное представление об этой технологии и почти ей не пользуются, а те, кто знают, делают таблицы стилей более мене, или совсем правильно. Правда к первоисточнику тоже стоит иногда обращаться и хоть изредка почитывать, что пишут сами разработчики этой технологии. Так же стоит проверять свои таблицы стилей с помощью CSS-Validator’а , как впрочем, и HTML-код.
Возвращаясь к теме браузеров. Упомянутый IE, являясь продуктом корпорации Microsoft обладает одной присущей многим разработкам детища Билла Гейтса особенностью. Дело в том, что Microsoft почему-то всегда нравилось изобретать собственные стандарты и спецификации. Так и в случае с IE, он поддерживает CSS, но иногда создается впечатление, что этот стандарт там какой-то свой. Один из разработчиков IE в приуроченном к скорому выходу седьмого воплощения этого браузера, интервью сказал, что их браузер очень плохо и не часто правильно обрабатывает CSS, и они приложат все усилия, что бы это исправить. А вскоре появилась информация, что IE7 не будет проходить тест на соответствие стандартам web.
В заключении рассуждений, хочется сказать что соблюдение стандартов облегчает жизнь как разработчикам, так и пользователям. Но многие до сих пор этого не осознали или просто не задумывались. В последнее время в сети появляется все больше и больше ресурсов об авторах которых складывается впечатление, что они HTML до этого вообще в глаза не видели. В таком случае, почему бы не пользоваться специальными программами для визуального создания сайта? Да собственноручно написанный код получается элегантнее, но лишь тогда, когда знаешь что делаешь. А получается как с некоторыми нашими соотечественниками, живущими на не безызвестной улице Брайтон Бич, приехали жить в чужую страну, а ни ее языком, ни тем более историей с культурой, поинтересоваться не удосужились.
About LiveJournal.com