Сразу оговорюсь, это все мое личное мнение. Не навязываю, просто высказываю.

Начать статью я хотел бы с констатации того факта, что прямо за окном находится 2011 год (пруфлинк), середина апреля. Напоминаю я это в первую очередь себе, поскольку меня периодически посещают в этом сомнения. Дело в том, что как по работе, так и ради хобби я часто читаю код на С++, написанный лет 10-20 назад (но поддерживаемый и поныне) или код написанный совсем недавно, но людьми, которые учились программировать на С++ те же 20 лет назад. И вот после этого у меня и возникает ощущение, что никакого прогресса за эти годы не было, ничего не менялось и не развивалось, а по Земле до сих пор бродят мамонты.

Неспособность рассуждать о коде

«Рассуждать о коде» значит понимать порядок исполнения инструкций («исполнять программу в голове»), зная, каково предназначение кода.

Симптомы

• Наличие «волшебного», «вуду» кода или кода, который не имеет никакого отношения к целям программы, но всё равно тщательно поддерживается (например, инициализация переменных, которые никогда не используются, вызов функций, не имеющих отношения к цели, создание выходных данных, которые не используются, и т.д.).
• Многократные вызовы идемпотентных функций (например, вызов save() по нескольку раз, «чтобы уж точно»).
• Исправление ошибок написанием избыточного кода, который замещает данные, полученные при исполнении неисправного кода.
• «Йо-йо код», который конвертирует значения в различные представления, а потом конвертирует их обратно ровно в то же представление, с которого начинали (например, преобразование десятичного числа в строку, а потом обратно в десятичное число, или padding строчки с последующим trim'ом).
• «Бульдозерный код», который создает впечатление рефакторинга посредством разбития кусков кода на процедуры, которые, правда, затем невозможно использовать где-либо еще (высокая когезия).

Если честно, то сайт mashina.org был недоступен под билайном. Проявлялось в том числе у меня (проводной Билайн, Москва) около 13:00. По состоянию на текущее время сайт открывается.
Об этом писали уже написала Lenta.ru, есть записи в twitter и на других сайтах.

Вместо сайта открывалась вот такая заглушка:

Несколько последних лет ознаменовались появлением большого количества новых терминов, понятий, технологий, течений. Также появилось достаточное количество базвордов, которые заполонили медийное пространство. И заполонили до такой степени, что многие айтишники начинают поддаваться на соблазны и искушения рисующихся золотых перспектив. Но не буду говорить загадками — под катом список понятий, с которыми связано большое количество надежд, холиваров и… заблуждений. Давайте немного разберемся, что к чему.

Я когда-то работал в компании, где нельзя было говорить о своей зарплате под страхом… я даже не знаю чего. Как дети испытывают ужас от того, что “взрослые заругают”, так и мы боялись ей делиться. О том, какая кара нас ожидает, приходилось только догадываться.

Ад в представлении Босха.

И все равно все все знали. Почему? Потому что чтобы закон работал, за ним должна стоять идея, которую разделяет большинство. Какая идея стояла за этим законом? Идея скрыть несправедливую оплату труда. Ведь если она справедливая, то зачем скрывать?

Одна из неприятных проблем — при внесении даже простых изменений приходится править код в нескольких местах. Например, если в класс добавляется поле данных, его нужно добавить в объявление класса, инициализировать в конструкторе(ах), а если переопределены операторы копирования или сравнения — то и в них тоже. Это отнимает время и приводит к ошибкам, если забыть про одно из мест (особенно неприятно забыть инициализировать, такие ошибки могут жить годами, и вызывать неожиданные, трудновоспроизводимые проблемы).

В России необходимо построить гражданское общество, и первые ростки начинают появлятся. Основа гражданского общества — контроль гражданами за исполнением своих прав. Сейчас наши граждане терпят различные издевательства над собой, принося лишние документы, платя неправомерные взносы, терпя дез, который не чинит батарею вот уже две зимы, и т.д. и т.п.; естественно и от частных структур люди иногда терпят.

Я считаю, что тому есть несколько причин:

1. Неверие в то, что что-то можно изменить, прищучить гос.орган какой-то;
2. Недостаток информации о том, как это сделать;
3. Отсутствие времени;
4. «Никаких нервов не хватит»!

Иногда программисты изобретают свои «велосипеды», но действительно ли это плохо, особенно если творение не отличимо от оригинала, а автор получает бесценный опыт?

Эта история началась чуть более года назад с появлением у моей супруги современного смартфона. Она попросила найти пасьянс «Косынку», такой же как был когда-то на настольной Windows. Просмотрев десяток программ, я был неприятно удивлен — почти везде было неудобное управление, спорные картинки карт, море дополнительных наворотов вроде 250 пасьянсов в одном, установки фотографии на рубашку и блекджека с блудницами. В результате, выбрали один из более-менее годных вариантов и на какое-то время об этом забыли.
Пролетел год и я начал писать программы для мобильных. При этом ребром стал вопрос кросс-платформенности, отладки in-app покупок, подготовки контента под разные платформы. Была мысль сделать для пробы пера «Тетрис» или очередной калькулятор, но все же в качестве «велосипеда» я выбрал «Косынку». Идейным стрежнем проекта стало максимально точное повторение старого, доброго пасьянса из набора игр Windows.

Миф 1. Университет не должен давать профессию — университет должен учить студента учиться.

Высшее образование — это высшее профессиональное образование, и его цель — дать человеку практические навыки и теоретические знания, для решения задач связанных с его будущей профессиональной деятельностью.

Недаром, когда идет набор абитуриентов, все вузы кричат: «наши выпускники возглавляют банки, заводы и работают на самых престижных должностях», «мы вас научим тому-то и тому-то, да вообще, всему что только может понадобится».

И вот на пятом курсе подходит очередной выпускник к лектору и говорит:
— Профессор, я иду на красный диплом, но не могу найти работу.
— Задача университета — научить человека учится.
— ??

http://pyxeledit.com/



Когда я полгода или чуть больше назад решил ради разнообразия попробовать Flixel и сделать свой платформер, то меня сначало удивило, а потом начало злить отсутствие нормального редактора тайлов. С платформером и флешем я уже наигрался, но наткнувшись на бету не могу не поделиться с хабрасообществом.
Пара роликов c использованием под катом.

Как многие уже догадались из названия, речь пойдет о движке LiveStreet, а вернее о базовом шаблоне Synio, который включается в сборку CMS, и автором которого мне повезло стать.

Сегодня я хотел бы рассказать о процессе его создания и о том, что удалось воплотить.

В этом топике вы найдете немного ностальгии, каплю гнева и килограмм реверс-инжиниринга. Посвящается тем, кто знаком с программой «Звукозапись» не понаслышке :)

Когда небо было голубее, Солнце светило ярче, а Интернет был таким недоступным… Короче, в далеком детстве мне почему-то полюбилась стандартная программа «Звукозапись» из Windows 98. Не глядя на минимальную функциональность, я даже умудрялся делать в ней простейшие «ремиксы» ей же записанных мелодий из игр.

Шли годы. Железо становилось мощнее, а ОС функциональнее. Но «Звукозапись» не менялась. Даже в Windows XP она оставалась такой же, как и тогда. Пришло время обновить железо. 3 гигабайта оперативной памяти — раньше и мечтать о таком не приходилось. Этого уж точно должно хватить всем! Так и было, пока дело не дошло до той самой «Звукозаписи». После попытки записать небольшой звук программа невозмутимо возразила, что ей недостаточно оперативной памяти.

В мире ПО существует огромное количество программ, забытых своими разработчиками. Хорошо, когда уже есть хорошая альтернатива. А если ее нет? В программе может катастрофически не хватать каких-то мелочей, некоторые досадные ошибки могут годами доставлять массу неудобств пользователям, а на новых версиях ОС программа и вовсе может отказаться работать. Далеко не всегда имеются исходные коды, чтобы привести программу в порядок. Если программа простая — не составит труда за короткий срок создать альтернативу. Но если программа большая и сложная, что же делать в таком случае? Не всегда рационально тратить время и деньги на разработку полного аналога, ведь расширить в разумных рамках функциональность и исправить большинство ошибок можно уже в готовом исполняемом файле.
В этой статье будут продемонстрированы методики модификации исполняемых файлов на примере расширения функциональности легендарной игры Age of Empires II (стратегия реального времени).

Данный пост навеян статьей "Я, пользователь!", которая вызвала много споров, и была весьма прохладно встречена сообществом. Обсуждение в комментариях показало, что мысль, которую Автор высказал довольно жестко и агрессивно, была воспринята как призыв вернуться к ветряным мельницам. Однако, на мой взгляд, проблема затронутая автором, гораздо глубже.

Язык PHP очень легок для изучения. Это, а так же обилие литературы «Освой _что_угодно_ за 24 часа» породило большое количество, мягко говоря, некачественного кода. Как следствие, рано или поздно любой программист, который выходит за рамки создания гостевой книги или сайта-визитки сталкивается с вопросом: «а если я здесь немножко добавлю, все остальное не ляжет?» Дать ответ на этот вопрос и на многие другие может юнит-тестирование.

В самом начале хочется оговориться — здесь речь не будет идти о TDD и методологиях разработки ПО. В данной статье я попробую показать начинающему PHP-разработчику основы использования модульного тестирования на базе фреймворка PHPUnit

Недавно пострадал от потери NTUser.dat и с ним всего HKCU под Windows7 да так, что Windows Restore не помог — пришлось подниматься из бакапа месячной давности. В результате сильно озаботился вопросом резервирования реестра. Как выяснилось, Win7/Vista никакого резервирования «чисто» реестра (в отличии от XP) не предлагают. В этом посте расскажу о том, что можно сделать своими руками по этому поводу с помошью утилиты ERUNT и User Profile Hive Cleanup Service (UPHClean). В завершение привожу пример того, как это сделал я.

От переводчика: Это перевод заметки товарища по имени Steve Souders, который очень плотно занимается вопросами производительности веб-сайтов и даже написал пару неплохих книг на эту тему.

Вчера я проводил семинар в Google Ventures для некоторых из инвестируемых ими компаний. Я не знал насколько подготовленной в вопросах производительности будет аудитория, так что я сделал обзор вопросов, связанных с производительностью, начиная с первых моих выступлений в 2007 году. Уже несколько лет я не рассказывал о методах улучшения производительности, описаных в моем блоге "High Performance Web Sites". Я прошелся по таким вещам, как Меньше HTTP-запросов, Добавление заголовка Expires и Gzip.

Но мне надо было вернуться еще дальше. Думая о тех временах, когда еще не существовало конференции Velocity и самого понятия WPO, я решил, что должен пояснить почему я занялся именно клиентской оптимизацией. Я нашел слайды, поясняющие «Золотое правило производительности»: 80-90% времени ожидания пользователем занимает работа браузера.

На слайдах были данные по времени отработки сервера и клиента для популярных сайтов, но данные были устаревшими и ограниченными, так что я решил обновить их. Вот, что получилось.

Добрый день, уважаемые хабрапользователи.
Да-да, заголовок вас не обманул: сегодня мы вспомним про старую добрую консольную игру Road Rash 3.


Думаю, многие из вас с удовольствием вспоминают, как просиживали часами в гордом одиночестве или в шумной компании друзей, наматывая виртуальные километры в этой, без преувеличения, культовой игре. Так же и я в один из вечеров решил вспомнить молодость и пройти пару уровней в любимых гонках. И вот, вооружившись эмулятором и геймпадом, начал восхождение по карьерной лестнице. Все шло замечательно, но в один прекрасный момент у игры что-то перемкнуло и она отказалась переводить меня на новый уровень, хотя все условия для этого были выполнены. Расстраивался я не долго, т.к. знал, что в игре есть своеобразная система паролей для сохранения набранных достижений. Нужно было всего лишь немного «подкрутить» существующий пароль методом тыка, чтобы вручную перевести себя на новый злополучный уровень и с чистой совестью продолжить соревнования.

Но это было слишком просто и, честно говоря, не интересно. У меня сразу промелькнула мысль: «А как оно работает»? И я загорелся идеей узнать сам алгоритм генерации пароля, чтобы иметь возможность в дальнейшем самому его создавать, исходя из конкретных потребностей или просто настроения.

Об ЕГЭ немало копий сломано. При этом, правда, на Хабре в основном был разбор комичных или некорректных заданий и только один взгляд изнутри глазами админа, к которому наблюдался повышенный интерес, что неудивительно. Поскольку наша компания в этом проекте давно, нам тоже есть что рассказать. ABBYY принимала участие:

• в проектировании архитектуры обработки результатов экзамена с использованием продукта ABBYY FormReader Developer Edition (теперь это называется ABBYY FlexiCapture Engine),
• в обучении региональных специалистов,
• во внедрении,
• в технической поддержке.

Итак, продолжим смотреть на ЕГЭ изнутри.