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

В самом Model View Controller шаблоне нет ничего плохого. Он решает ту проблему, для которой его придумали — это разделение логики обработки запроса пользователя и логики представления информации.

Эта статья содержит необходимый минимум тех вещей, которые просто необходимо знать о типизации, чтобы не называть динамическую типизацию злом, Lisp — бестиповым языком, а C — языком со строгой типизацией.

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

Вашему вниманию вольный перевод статьи Джуль Мальца (Jules Maltz) и Даниэла Барни (Daniel Barney), партнеров IVP, которые специализируются на инвестициях поздней стадии в стремительно развивающиеся интернет-стартапы и софт-компании.

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

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

На самом деле, freemium – это всеразрушающая модель, которую необходимо использовать с умом. На основе общения с лидерами компаний Dropbox, Evernote, HootSuite и других были составлены 6 основных постулатов использования такой бизнес-модели.

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

Статья содержит перечень ресурсов для онлайн-обучения, представляющих интерес преимущественно для программистов.

Блог Highload Lab на Хабрахабре обновляется нечасто — интересных DDoS-атак, на примере которых каждый может чему-то научиться, мало, а раздражать читателей бесконечными историями успеха не хочется. Тем ценнее действительно занимательные прецеденты, к числу которых, несомненно, относится нападение на сайты Центрального Выборного Комитета Координационного Совета оппозиции.

В предыдущих выпусках бортового журнала сети фильтрации трафика Qrator (обязательная рекламная ссылка — http://qrator.net/) мы выяснили, что в преддверии серьёзных мероприятий в Рунете лучше заранее озаботиться защитой от атак. Сегодня я расскажу вам, как можно, даже выполнив это требование, заработать себе пару бессонных ночей на рабочем админском месте.

Совсем недавно мы отрелизили на hh.ru зарплатные кластеры, которые помогают оценить свою стоимость как специалиста. Это достаточно интересная и гибкая фича, такая, что с ее помощью даже можно провести небольшое исследование рынка труда, определив своё место в нем:

Стартап Bountify — это нечто среднее между StackOverflow и фриланс-биржей. Принцип работы очень прост — заказчик публикует задачу или вопрос и вносит предоплату от 1 до 250 долларов. В течение недели любой желающий может предложить решение. Вознаграждение достаётся тому, кого выберет заказчик. Если предложено несколько примерно равноценных вариантов, или кто-то сделал ценные замечания и дополнения к решению-победителю, заказчик может дополнительно вознаградить тех, кто внёс свой вклад. Если решения нет, деньги уходят на благотворительность.

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

На сайте моей компании я выложил свой перевод интервью Андре Вейера (Andre Weyher), в прошлом — сотрудника отдела качества поиска в Google, которое он дал австралийскому интернет-маркетологу Джеймсу Норкею (James Norquay). Так как весь текст довольно длинный, здесь я перечислю основные (на мой взгляд, новые) моменты. Если кому-то интересен полный текст перевода — адрес в обсуждении ниже, из скромности. Интервью свежее, 16 октября с.г.

Основная мысль интервью — «если вы хотите, чтобы ваш сайт был повыше в результатах поиска, делайте его так, как будто никакого SEO нет. Этого от вас ждет и пользователь, и Google».

Несколько интересных ответов Андрэ, которые мне (и комментаторам оригинального интервью на сайте Джеймса) показались не столь банальными (простите, если вы это уже знаете, вдруг кто-то еще не знает):

Консилиум врачей в больнице.
Главврач — лечащему врачу:
— Каково состояние больного?
— Состояние больного 2 миллиона!
— Отлично, завтра будем оперировать!

Об отношении к действиям free-lance.ru высказались уже все.
Поэтому очень коротко о состоянии больного на девятый день с момента суицида.

Я работаю программистом уже много лет, на протяжении которых, как это ни странно, я всё время что-то программирую. И вот какую интересную вещь я заметил: в коде, написанном мной месяц назад, всегда хочется что-то чуть-чуть поправить. В код полугодичной давности хочется поменять очень многое, а код, написанный два-три года назад, превращает меня в эмо: хочется заплакать и умереть. В этой статье я опишу два подхода. Благодаря первому архитектура программы получается запутанной, а сопровождение — неоправданно дорогим, а второй — это принцип KISS.

Итак, представим себе, что есть два программиста. Один из них умный, прочёл кучу статей на Хабре, знает каталог GoF наизусть, а Фаулера — в лицо. Другой же делает всё просто. Первого будут звать, например, Борис Н., а второго — Маркус П. Само собой, имена вымышленные, и все совпадения с реальными людьми и программистами случайны.

Итак, к ним обоим приходит проектный менеджер (если в вашей вселенной PM не ходит сам к программистам, назовите его как-то иначе, например BA или lead, сути это не изменит) и говорит:
— Ребята, нам нужно, чтобы делался хлеб.

Именно так, «делался», без уточнения способа производства.

Как же поступят наши программисты?

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

Ошибки серверного софта

… которые программисты не знают как исправить, т.к. «ломается» серверный софт, например связка apache-PHP — а клиент получает в ответ на запрос страницу о регламентных работах. Веб-разработчик часто не обладает глубокими знаниями в программировании на C в unix/linux, а сисадмин нередко, к сожалению, глубже bash в систему не погружается. Настоящий хардкор :-)

Нестабильная работа серверных скриптов

Нередко, определенные страницы веб-проекта начинают сходить с ума. Например выполняться по 15 минут и выяснить, чем же они занимаются, непросто. В прошлом посте на данную тему я описал одну из методик определения, чем занимается PHP-скрипт на боевом сервере, но чувствуется, что нужен более мощный инструмент.

На практике я часто встречаю проекты, которые сталкиваются с подобным классом ошибок «серверного софта», и в команде не всегда знают, что делать. В логе apache часто появляются сообщения о нарушении сегментации (segmentation fault), клиенты получают страницу об ошибке, а веб-разработчик с сисадмином ломают себе голову, играются с разными версиями PHP/apache/прекомпилятора, собирают PHP из исходников с разными опциями снова и снова, пишут о багах, а им доказывают, что это баги не PHP, а их кода и так до бесконечности…

В статье я хочу рассказать как можно просто и быстро найти причину, почему PHP рассыпался на боевом сервере и устранить ее — не погружаясь в прекрасный мир системного программирования на C для unix :-) От вас потребуется желание и одна чашечка кофе.

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

Этот пост — продолжение разбора алгоритмов сортировки (в прошлый раз был Hacker News). В этот раз, мы разберем как работает сортировка постов и комментариев на Reddit. Алгоритмы у Реддита достаточно простые, чтобы понять их и реализовать.

Первая часть этой записи будет сфокусирована на сортировке постов, а вторая на сортировке комментариев. Они довольно сильно различаются, и за идеей способа сортировки комментариев стоит Randall Munroe (автор xkcd).

Разбираем сортировку постов

Реддит open-source-ный проект и его код полностью доступен на гитхабе. Он написан на питоне, исходники вы можете увидеть тут. Их алгоритмы сортировки написаны под Pyrex, для дальнейшей компиляции (трансляции) в C-код. Pyrex был выбран из-за производительности. Я переписал их реализации на чистый питон, чтобы они легче читались.

О чем это

Я долгое время был адептом идей о равенстве, свободе и братстве том, что существует красная таблетка.

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

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

Я не сделаю, возможно, в этом посте никаких открытий. Но сэкономлю вам пару лет, если вы решитесь поверить моему опыту.

Хочу представить хабро-общественности картографический сервис ГИС-ГИД, созданный мной еще 2 года назад и который я пытаюсь постоянно развивать.

В Интернет можно найти множество различающихся реализаций и схем, уже набившего оскомину, паттерна MVC. В разных книгах я также встречал разные схемы. Это порождает некоторую путаницу и комментарии к моей предыдущей статье: "Реализация MVC паттерна на примере создания сайта-визитки на PHP" тому подтверждение. В поисках истины, я попытался расставить все по местам… перечитал некоторую литературу и статьи по паттернам проектирования и написал дополнение к упомянутой статье. Но решил запостить это дополнение, как отдельный топик в надежде на фидбэк. Под катом вы найдете несколько часто встречающихся схем MVC и MVP с описанием жизненного цикла приложения, а также описание менее популярных паттернов HMVC и MVVM. Разумеется, некоторые из перечисленных паттернов применимы не только к веб-приложениям, но в статье они рассматриваются именно в этом контексте.

MVC феноменальная идея. У вас есть модели, самостоятельные кусочки состояний, представления которые самостоятельные кусочки UI, и контроллеры которые самостоятельные кусочки… эм?

Что?

Я конечно не первый кто это замечает, но проблема с MVC в том что в контроллеры пихают слишком много кода.

Чтобы исправить это, я использую новый паттерн: MOVE. Models, Operations, Views и Events.

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

Рост аудитории интернет-пользователей и интернет-проектов выводит геосервисы на новый уровень.
Если раньше большинство проектов с использованием «карт» оперировали с десятками и сотнями точек, то сейчас уже речь идет о сотнях тысяч точек.
В статье будут рассмотрены несколько юзкейсов для геосервисов и способы их реализации для google API 3 и нового yandex API 2.

Прошлая статья привлекла большой интерес. И даже, на некоторое время, стала лучшей за 24 часа. У меня появилось несколько идей и на часть вопросов в комментариях нужно ответить более развернуто.

Написать этот пост меня привлекла эта статья. Многие ее помнят по вот этой картинке.

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