Преимущества дивной вёрстки, семантичной разметки и разделения содержимого и дизайна описаны десятки, сотни раз, но все-равно находятся люди, которые не понимают самой идеи html и css, пишут в коде такие ужасные вещи, как

<span style="color:blue">

, когда хотят расскасить текст в синий цвет и искренне считают, что эта запись чем-то лучше, чем

<font color="blue">

, наивно веря в этом деле валидатору. А ведь правильный подход в написании html и css лежит на поверхности. Достаточно просто посмотреть историю развития этого языка, почитать статьи десятилетней давности и проанализировать. Я, при поддержке theshock, постаралась в этот статье упорядоченно и коротко изложить наше видение этого вопроса.

style.css

.habr span
{
    display:block;
    overflow:hidden;
    white-space:nowrap;
    width:100%;
    -moz-binding:url("ellipsisxul.xml#ellipsis");
    text-overflow:ellipsis;
    -o-text-overflow:ellipsis;
}

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

Начальные условия такие: мы рассматриваем примеси, имеющие свое состояние и имеющие доступ ко всем членам класса-агрегатора. Все публичные члены класса примеси становятся частью агрегатора. Мы оставляем за кадром вопрос быстродействия. Вопрос исследуем на примере добавления нового функционала в модель выдуманного ORM.

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

Моя прошлая статья «Обнаженный бизнес» Ричарда Брэнсона (в цитатах), похоже многим была интересна. Что же, не будем останавливаться?

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

Я прочел эту книгу 2 раза. Второй раз (теперь, как всегда) — с маркером, выделяя цитаты. Рад ими поделиться. Уверен, тем кто знаком с книгой, будет интересно и полезно прочесть эти мысли еще раз. А те, кто книгу еще не читал, скорее всего убедятся в том, что это обязательно стоит сделать.

***

Мы тщательно изучили и просеяли компании, которые входили в список Fortune 500 c 1965 по 1999 год. И определили те компании, которым удалось осуществить переход от хороших результатов к выдающимся и сохранять эти высокие результаты в течение, по крайней мере, 15 лет. Затем мы проанализировали те факторы, которые позволили это сделать.

В этой статье я приведу взгляд (отрицательный по большей части) Джоша Беркуса, CEO компании PostgreSQL Experts Inc. на использование суррогатных ключей для таблиц базы данных, тех самых INT NOT NULL AUTO_INCREMENT PRIMARY KEY, к которым мы привыкли. Фактически, это будет вольный, сильно сокращенный перевод его статьи на ittoolbox.

За статьей последует разбор моих собственных ошибок по этой теме, допущенных в одном старом проекте. Я был молод и глуп, но это меня не извиняет.

Честно говоря, прочитав эту статью и не заметив, кто автор, я подумал, что он все же преувеличивает и вообще, я без него как-нибудь разберусь, где и какие ключи мне использовать. Потом я еще немного подумал и полез за дампом структуры базы моего старого проекта. Было интересно.

Если вы опытный DBA, наверное, вам стоит пройти мимо, чтобы не расстраиваться.

Но обо всем по порядку. Сначала ОЧЕНЬ сокращенный перевод:

Всем привет!

Мы, Денис Бесков (beskov) и Илья Поляк (ilyap1) начинаем публикацию цикла статей, посвящённых процессу проектирования веб-сервисов. Цикл построен вокруг 3-хуровневого процесса, в котором явным образом выделяются уровни анализа и проектирования:

1. Бизнеса
2. Продукта
3. Технологий

Здесь, на хабре, достаточно хорошо освещается тема проектирования на уровне технологий. Мы хотим показать взаимосвязь этого уровня, видов работ и проектных решений с вышестоящими уровнями на примере сквозного демо-кейса — проектирования веб-сервиса бронирования билетов в кино, в разработке которого участвовал пару лет назад один из авторов.

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

1. Какими способами можно описывать требования к ПО?
2. Какие из требований к системе обязательно необходимо включать в ТЗ, а без каких можно обойтись?
3. Какие могут быть варианты при выборе форматов описания требований?
4. Как зависит выбор вида описания требований от параметров (продолжительности, рисков и др.) проекта?
5. Какого рода решения помогают принять соответствующие виды требований?

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

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

III. Описание процесса в графической форме

В виде диаграмм бизнес-процесс можно описывать с помощью различных нотаций: ARIS — VAD и EPC, IDEF0, BPMN и др. Нотаций много, у каждой есть свои достоинства и недостатки, в рамках этой статьи эта тема не затрагивается.

Основной плюс использования диаграмм — наглядность. Основные минусы — сложно изображать все возможные варианты ветвлений и долго вносить изменения.

Посещение кинотеатра без предварительного бронирования билетов (в нотации VAD)

Перевод статьи молодого греческого программиста «Why I bill hourly»

Недавно ко мне обратился мой первый потенциальный клиент, который хотел добавить несколько возможностей в небольшое приложение на Django. Я огласил свою часовую ставку, чем крайне его шокировал — он-то хотел услышать фиксированную цену за нужные ему доработки. Что из этого получилось? Мы работаем вместе, он очень доволен как результатами, так и суммами, которые он на них тратит, а я не поступился своими принципами оплаты. Вот аргументы, которые я использовал в защиту мнения о том, почему почасовая ставка лучше для всех заинтересованных сторон — может быть, они помогут кому-то еще.

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

Клиент: Вот участок, на котором мы будем строиться. Вот наброски того, что мы хотим построить. Можете назвать точную стоимость постройки?

Любой инженер-строитель шарахнется от такого предложения, программисты же в своей жажде заключить сделку прикинут смету, удвоят ее, добавят 30% и будут надеяться на лучшее. Как отвечаю на такой вопрос я?

Внимание

Статья содержит информацию об устаревшей версии PHP Console.

О новой версии PHP Console 3.0 читайте тут.

PHP Console 1.0

Речь пойдёт об одном чудном расширении для Google Chrome, которое позволяет проксировать вывод ошибок и дебаг сообщений из PHP в консоль Google Chrome, а также отображать их в виде всплывающих popup-уведомлений.

JavaScript — удивительный язык, с которым порой удаётся вытворять неожиданно классные вещи. Хочу познакомить вас с немножко нестандартным решением одной проблемы быстродействия, с которой я недавно столкнулся. Предупреждение: не для новичков.

Исходные данные: ресурсоёмкая функция, обновляющая определённые элементы на экране по наступлению определённых событий (движение мышки, например).
Проблема: когда события, вызывающие функцию, происходят слишком часто за короткий промежуток времени, интерфейс может начать серьёзно тормозить. Скажем, если событие произойдёт 1000 раз за несколько секунд, то и обновление — столько же. Для интерфейса молниеносная скорость отрисовки изменений может быть не так важна, а вот общее быстродействие, которое в данном случае страдает — очень даже.
Задача: ограничить функцию таким образом, чтобы она исполнялась не чаще, чем раз за определённый промежуток времени. При достаточном малом таком промежутке визуально задержки не будут заметны, зато кол-во вызовов может сократиться в несколько раз, что в свою очередь очень сущесвенно сократит нагрузку и поможет избавиться от торможения.

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



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

Если вы используете JavaScript, но при этом так до конца и не разобрались, что же это за чудная штука такая — замыкания, и зачем она нужна — эта статья для вас.

1 Введение

В своей прошлой заметке я постарался осветить в общих чертах стиль работы с
распределенной системой контроля версий git и указать на отличия по сравнению с
классическими централизованными СКВ. Целью было прежде всего обобщение опыта
работы с системой без упоминания тонкостей синтаксиса отдельных команд.

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

Люди не очень любят регистрироваться. Это же нужно (в общем случае) придумать логин и пароль, зайти в свою почту, дождаться письма, открыть его, перейти по ссылке активации аккаунта, а потом еще этот логин с паролем не забыть. Но ведь уже давно есть способ, с помощью которого все эти шаги не нужны. Более того, не нужно вообще ничего вводить с клавиатуры, 2 щелчка мышью и все, человек зарегистрирован.

Как-то вечером для реализации моделей поведения в ORM в моем велосипеде фреймворке мне понадобилось что-то, ведущее себя как примесь (mixin) в Ruby или как метод расширения (extension method) в C# (или как трейт / графт в будущих версиях PHP) Я решил для интереса посмотреть, как у меня получится реализовать примеси на PHP. Если вы не знаете, что такое примесь, не беда, сейчас все расскажу.

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

Эта статья родилась как ответ на статью Про бесполезность длительного проектирования. Хотелось бы высказать свое мнение на этот счет, поделиться опытом, но уложить все это в комментарии не представляется возможным.

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

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

У регулярной сверхурочной работы множество вредных последствий — как для команды, так и для компании. Давайте их рассмотрим.

Истощение

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

Проблема секьюрности информации, передаваемой в файлообменных сетях, сегодня стоит очень остро. Популярный пиринговый протокол битторрент не дает практически никаких средств защиты от посторонних глаз, выдавая IP всех пиров как на ладони. The Pirate Bay, помнится, обещал разработать свой собственный анонимный протокол, но, видимо, дело заглохло.

Еще одной проблемой битторрента является частичная централизованность. Нет серверов — нет сети (DHT не в счет, т.к. не полностью самостоятелен). Очевидно, будущее за полностью децентрализованными сетями — сетями третьего поколения. Об одной из таких я и хотел бы рассказать.

В краткий обзор вошли веб-приложения на Python с открытым исходным кодом и возможностью расширения: GetPaid, EasyShop, LFS, Satchmo, Perfect Sale.
Материал публикуется с целью привлечь внимание отечественных разработчиков к e-commerce open source решениям на python в продолжение темы Open Source решений для электронной коммерции на PHP: habrahabr.ru/blogs/open_source/101072

Решил посетить сайт (на который не заглядывал уже несколько лет) посвященный внутренностям apache2. Но увидел лишь сообщение от хостера о том, что сайт временно заблокирован. Сделал запрос в яндексе: в кеше у поисковика уже ничего нет. Думаю, что сайт заблокирован давно. С помощью смс я продлил хостинг на один день и увидел, что обновлений не было с декабря 2007 года. Попытался связаться с автором через электронную почту, указанную в контактах домена. Ответа не получил…