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

Наверняка, многие веб-программисты изучали и, может быть, даже использовали такой замечательный фреймворк как CodeIgniter. Мой выбор пал на него ввиду того, что у него самый низкий порог вхождения, он наиболее прост в изучении, хорошая документация, быстрый и т.д. и т.п. Для простых проектов самое «оно», чтоб попробовать свои силы именно как разработчик. Само собой, для более серьезных проектов лучше использовать более функциональные и навороченные фреймворки.

Далее буду описывать, как я «апгрейдил» CodeIgniter, чтобы использовать этот каркас для разных проектов, т.к. базовый его функционал и примеры из документации, мягко говоря, очень простые, а в жизни всё гораздо сложнее. Итак, начнем-с.

Данная статья посвящена практическому использованию библиотеки Migraton, появившейся в обновлении CodeIgniter версии 2.1.0. Настоятельно рекомендую вам перед ознакомлением с данным материалом прочесть первую часть статьи, в которой говорится непосредственно о создании миграций.

В предыдущей заметке я сделал вывод о том, что разработка ПО настолько уникальная область что говорить о «схожих областях» человеческой деятельности можно лишь только лишь в целях упрощения понимания некоторых терминов, связанных со стадиями разработки и управления ей.



Странно, но методики, которые родились непосредственно в области разработки ПО совсем не похожи на пришедшие извне.

Например достаточно простой SCRUM, описание которого вполне можно уместить на листок A4, но которым пользуется CERN. Или Agile, который можно описать десятом абзацев где содержатся весьма общие и идеалистические принципы в соответствии с которой был сделан GitHub и много других клевых штук. Можно ли их использовать в строительстве? А при создании самолетов?

Нет, подождите, а как же декомпозиция и формализация бизнес-процессов, без которых невозможно было бы автоматизировать, ну тот же процесс строительного проектирования. А как же планирование работ, без которых никак не получилось бы организованно создать тысячу таблиц, логических структур и интерфейсов для подобного проекта?

(в качестве иллюстрации лицо типичной универсальной методики авторства RuxxSilver, которое на первый взгляд выглядит весьма привлекательно и правдоподобно)

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



Если искать аналогии в плане управления, то весьма схожем с производством ПО может показаться строительство. Мало того, менеджеров по разработке ПО нередко знакомят с управлением проектированием и строительством зданий и инженерных сооружений.

Однако, происходит некоторая подмена причин этого знакомства. Да, эта область в чем-то похожа, в первую очередь наличием понятий “требования”, “проектирование”, “проект”, “строительство” (construction), “контроль качества”, “человеко-часы”, “работы”, “сроки”, а сам процесс развивается от экономической потребности и идеи до некого конечного продукта. Но основная причина того, что строительство является хорошей аналогией в том, что это наглядная аналогия.

(В качестве иллюстрации фотография проекта А.Гауди «Sagrada Familia», степень выхода которого за сроки и бюджет до сих пор не могут даже приблизительно оценить)

Архипенков Сергей — эксперт в управлении разработкой ПО, более 30 лет в разработке ПО, PMP® PMI, вице-президент Гильдии менеджеров программных проектов. Активный «продвигатор» и «задвигатор» теории и практики управления проектами и людьми в проектах по разработке ПО. Активный заседатель программных комитетов. Из последнего — председатель программного комитета конференции «Software Project Managment Conference» (ноябрь, Санкт-Петербург).

Ниже опубликован доклад Сергея с конференции CodeFest, на тему «Теория и практика адаптивного управления проектом».

Битва закончена, люди много говорят о том, какой методикой они руководствовались, когда принимали свои решения, но вообще-то всегда бывает чертовски много того, к чему приходят на ощупь.
Адмирал Ф.Д.Флетчер



Несколько дней назад я размышлял, почему так получилось, что тщательно прописанный и формализованный проект в очередной раз со свистом вылетел из сроков и бюджета, превысив их в разы. Иногда бывает, что проекты ведут себя по другому, но чаще происходит именно так. И это мало зависит от того, какую методику я использую для оценки объема работ и самой разработки. Даже McConnell, которого я считаю серьезным авторитетом в области разработки ПО, в начале книги Software Estimation: Demystifying the Black Art констатирует то, что простые методики оценки размера проекта удивительным образом оказывается ничуть не хуже сложных и испытывают те же самые проблемы. Возможно этот вывод можно распространить не только на методики оценки.

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

Речь пойдет о достаточно простых вещах, но я неоднократно замечал, что в научных исследованиях прогресс или тупик возникает, когда простая и очевидная вещь оказывается не тем, чем она кажется, или дефект в программе внезапно обнаруживается в модуле, который “не может” содержать ошибку.

(на иллюстрации персонаж фильма «Железный человек 2» Иван Ванко в момент произнесения фразы «Ваш софт — говно»)

1. Индустрия на стероидах

Хабраприветствую всех, кому интересна эта тема.

Конечно же, микроменеджмент встречается не только в IT, но именно в этой сфере указанный черный ритуал может принести значительный вред процессу разработки и конечному результату, не говоря уже о профессиональном развитии сотрудников.

Исторически сложилось так, что Firefox пользуется широкой популярностью среди веб-разработчиков благодаря его расширяемости через подключение всевозможных плагинов и дополнений, написанных сторонними разработчиками. Идея выделения функционала в расширения позволила решать массу всевозможных задач прямо в браузере, не прибегая к внешним инструментам.

Безусловно в этом списке вы обязательно найдёте уже знакомые расширения, однако огромный пласт полезных расширений всегда остаётся в стороне. Так что приготовьтесь установить ещё парочку расширений! :)

Встроенные инструменты разработки в Firefox

Перед началом списка было бы неправильно не упомянуть об инструментах, уже встроенных в Firefox. Здесь речь идёт о тех самых инструментах разработки в Firefox Aurora 10 и том функционале, который сегодня можно найти в любом современном браузере.

При разработке интерфейса этих инструментов было перепробовано множество подходов и решений. В результате получился довольно приятный интерфейс, который любой желающий может испробовать, установив Firefox Aurora (хм, вы ещё его не поставили?)



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

Как вы уже могли прочесть, недавно вышла новая версия CodeIgniter, одним из нововведений которого является библиотека Migration. Один из главных ее разработчиков, Phil Sturgeon был настолько воодушевлен удобством управления версиями баз данных для Rails, что решил создать аналог такого метода для CodeIgniter, и вот, в конце-концов вы можете видеть эту библиотеку в официальной поставке.
Из этой статьи вы получите общее представление о миграциях, а также научитесь их создавать. Во второй же части, мы с вами увидим, как легко они могут быть интегрированы в ваше приложение.
Данная статья будет полезна начинающим пользователям CodeIgniter, но я надеюсь что и более продвинутые коллеги узнают об этой чудесной библиотеке и подчерпнут для себя что-нибудь новое.

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

Вы наконец-то можете сделать кое-что со своим старым LCD монитором, который завалялся у Вас в гараже. Превратите его в шпионский монитор! Для всех вокруг он будет выглядеть просто белым экраном, но не для Вас, потому что у Вас будут специальные «волшебные» очки.

Всё что Вам нужно – это пара старых очков, нож для бумаги и растворитель для краски.

Сейчас работаю над доработкой/переписыванием проекта, который был написан, ну скажем так, «не совсем грамотно». По ходу есть задача оптимизировать работу, т.к. код изначально был написан крайне неоптимально. Среди работ по оптимизации прикручивается кэш.

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

$query = "Select something";
$result = $cache->get($query, $tag);
if (!$result) {
    $result = $db->queryAll($query);
    $cache->set($query, $tag);
}

И хочется чего-то другого. Конечно, код можно вынести в отдельную функцию или метод, но это как-то скучно и к тому же, для каждого разного вызова (а там есть не только $db->queryAll, а несколько разных вариантов) нужен будет свой код и своя функция/метод.

С другой стороны, добавлять код кэширования непосредственно в источники данных тоже не очень правильно — в конце концов, они этим не должны заниматься (именно поэтому Трейты тоже не подходят). Создавать отдельный класс кэша тоже не очень удобно.

В общем, хотелось единого, универсального решения, которое бы подошло для разных источников данных, с разными интерфейсами, но в то же время было единообразным. Было решено сделать «волшебный» декоратор.

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

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

Я попытаюсь просто объяснить, как работают замыкания в Javascript, как работает this, как создавать конструкторы для своих классов и чем различаются различные подходы к их созданию.
Статья не претендует на новаторство, но достаточно доступные объяснения how it works для новичков я не видел, и на мой взгляд — это три самых узких места в Javascript (не привязанному к какому либо контексту, серверу или браузеру, например).

Как-то незаметно для себя, я решил отойти от возни с классами и паттернами, и разобраться с самыми обычными Js функциями. Думал, что будет достаточно скучно, но ошибся — оказалось очень даже интересно.

В этой статье я расскажу об особенностях объявления функций, и некоторых полезных паттернах (кхе-хе, да, они есть и тут)

Для одного личного проекта (да и давно просто хотелось попробовать) решил использовать в качестве шаблонизатора — XSLT. Все вроде бы чудесно: для xsl-преобразований требуется объект SimpleXml, из базы возвращается тоже объект, казалось бы в чем проблема, почему нельзя передавать объект из базы напрямую в шаблонизатор?

Несмотря на то, что четвертая версия каркаса ExtJS вышла уже достаточно давно, материалов по этой версии на хабре не слишком много. А если учесть, что в четвертой версии существенно переработан API, структура классов и предлагаемая архитектура приложения, то, как мне кажется, тут есть, о чем поговорить.

В данной статье я попробую рассказать свои впечатления от фреймворка в контексте портирования существующей кодовой базы на новую версию; постараюсь так же не забыть о подводных камнях и ссылках на полезные (и не очень) страницы справки.

Бытует мнение, что программные системы, будучи объектом не совсем материальным, не поддаются старению. И если говорить о старении физическом, то действительно, шансы на то, что буковка “o” в имени класса вдруг от старости ссохнется и превратится в букву “c” – действительно малы. Но вместо старения физического, программные системы стареют морально.  Со временем накапливается груз ошибок за счет неточностей в исходных требованиях, непонимания требований самим заказчиком, архитектурных ошибок или неудачных компромиссных решений; да и ошибки поменьше, типа слабопонятного кода, его высокой связности, отсутствия юнит-тестов и комментариев делают свое черное дело. Все это приводит к накоплению технического долга (о котором шла речь в прошлый раз), из-за которого при добавлении новой возможности в систему приходиться платить «проценты» в виде более высокой стоимости реализации и более низкого качества получаемого результата.

Будь вы простым программистом, матерым лидом, архитектором или даже ПМ-ом, вы наверняка в своей нелегкой работе сталкивались с проблемой выбора при добавлении в систему новой возможности. Одно решение гораздо проще реализовать в сжатые сроки и успеть к очередному очень важному релизу, однако оно будет более затратное в сопровождении, менее расширяемое или менее надежное. Другое решение может не обладать всеми этими недостатками, однако обладать другим, в некоторых случаях более важным недостатком – на его реализацию потребуется значительно больше времени.

Часть читателей заметила в заголовке опечатку. Часть заметила обе. Часть не заметила вообще. Если вы из третьей группы, то с большой вероятностью вы — дислексик.

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

Конечно, Интернет стремительными шагами движется ко всё большему проценту медиа в воспринимаемом потоке информации. Тем не менее, текст был, есть и остаётся средством передачи огромной части знаний, получаемых из Сети.

Другой важный тренд — всё чаще уделяют внимание проблемам юзабилити для людей с ограниченными способностями. В то же время, о проблемах дислексиков почти не говорят, и это недоразумение стоит исправить. Недаром, по разнообразным статистикам, в развитых странах можно говорить о 5—15 % дислексиков в популяции (хотя в России подобной статистики не существует).