Новая версия phpMyAdmin 3.0.1

Буквально четыре дня назад (19 октября 2008 года) вышел первый релиз кандидат phpMyAdmin 3.0.1, а сегодня уже вышел полноценный релиз phpMyAdmin 3.0.1.

Разработчики скромно указывают: эта версия всего лишь исправление ошибок.

Все подробности в вики проекта.

Серия 3.0 требует PHP 5.2+ и MySQL 5.0+.

Скачать версию 3.0.1 и темы для неё можно с phpmyadmin.net или Sourceforge.net


Новая версия phpMyAdmin 3.0.0

27 сентября 2008 года вышла новая версия самого популярного web-интерфейса для управления базами данных MySQL – phpMyAdmin 3.0.0.

Официальное сообщение о выходе очень скромное и содержит довольно скупую информацию:

Добро пожаловать в phpMyAdmin 3.0.0. Эта версия поддерживает множество возможностей MySQL 5.1 и систем хранения данных Maria и PBXT.

Серия 3.0 требует PHP 5.2+ и MySQL 5.0+.

Скачать верию 3.0.0 и темы для неё можно с Sourceforge.net


PHP 4.4.9

По сообщению официального блога вышла новая версия PHP 4.х ветки разработки – 4.4.9.
Версия 4.4.9 станет последней – больше ветка 4.х поддерживаться не будет.

Изменения:

  • Обновление PCRE до версии 7.7.
  • Исправлено переполнение в memnstr().
  • Исправлена ошибка в imageloadfont при передаче некорректного шрифта.
  • Исправлена потеря обработки open_basedir в расширении curl.
  • Исправлено: настройка mbstring.func_overload в .htaccess становилась глобальной.

Весь список изменений ветки 4.х.

Всем рекомендуется обновляться до PHP 5. Последняя стабильная версия имеет номер 5.2.6 и скачать её можно здесь.


Техническое задание – To be or not to be?

Прочитал статью Станислава Малкина – Для заказчиков: если нет ТЗ.

Вообщем-то написано всё грамотно, последовательно и понятно.
Сделан напрашивающийся вывод – техническому заданию быть – to be! (Однозначно! Я сказал! © Жириновский)

И быть ему, по мнению Станислава, следует по трем вариантам:

  1. ТЗ написано самим заказчиком.
  2. ТЗ написано разработчиком заказанной системы.
  3. ТЗ написано профессиональным составителем ТЗ.

Я думаю что первый вариант имеет право на жизнь только если у заказчика уже имеется опыт написания ТЗ, основанный на втором и/или третьем варианте.
Пока пропустим второй вариант и обратимся сразу к третьему. Насколько можно судить по статье – Станислав считает этот вариант самым приемлимым, особенно для начинающих заказчиков. Однако я вижу гораздо больше минусов чем указано в статье (собственно единственный указанный минус – дополнительные расходы на написание технического задания):

  • Качество.
    На основании чего заказчик сможет судить насколько качественно написано техническое задание. Четких критериев оценки нет. Да, существуют всяческие ГОСТ-ы по написанию технических заданий, но они очень быстро устаревают, да и для интернет технологий могут нести разве что лишь рекомендательный характер. Но ГОСТ-ы не позволяют определить качество написанного технического задания.
  • Время.
    Чтобы написать качественное техническое задание технический писатель должен в достаточной мере изучить предметную область. В чём же здесь минус спросите вы – а минус в том – что насколько бы ни было качественно, точнее подробно, написано техническое задание – конечному разработчику придется потратить тоже самое время на изучение.
  • Стандарты.
    Общих стандартов нет. ГОСТ-ы есть, никто не спорит, но ГОСТ-ы скорее определяют формат документа, а не содержание и форму.
    Представим ситуацию – заказчик приходит к разработчику с ТЗ, написанным третьей стороной. Если разработчик не новичек – у него уже должен быть свой внутрикорпоративный стандарт написания ТЗ. Естественно принесенное ТЗ ему не будет соответствовать и, скорее всего, разработчик начнет настаивать не переписывании ТЗ под свой стандарт, под свои привычки. Наверняка принесенное ТЗ будет дополнено и расширено для того, чтобы оно было понятно конечному разработчику.
    Итого – на этом этапе заказчик потеряет время, деньги и нервы.
  • Большой Брат.
    Как вести себя заказчику если, принеся написанное кем-то ТЗ, конечный разработчик скажет – “Кто вам написал это фуфло? Это бред! Вот как мы это видим…” Эффект от такого варианта написания ТЗ может быть обратный – заказчик не только не съэкономит свои нервы, время и вообщем-то деньги (наличие хорошего ТЗ экономит деньги – поверьте на слово 🙂 ), но и может серьезно ухудшить отношения с разработчиком.

Итак исходя из написанного напрашивается вывод – самый правильный способ написать ТЗ – создать тройку: разработчик – заказчик – техписатель (профессионал по составлению ТЗ). В таком случае, скорее всего, все будут довольны. Хотя практика показывает, что разработчики исключают третью сторону (техписателя) и составляют ТЗ самостоятельно, ну естественно при участии заказчика.

Ну и напоследок несколько ссылок:
HabraHabr
ТЗ: макеты или текст?
ТЗ для web-разработчика
Про ГОСТ-ы
Как писать техническое задание?!
Классика
Юрий Шиляев – Что такое хорошее ТЗ на сайт?



Финишная прямая CSS Color Module Level 3

На сайте W3C появилась информация о том, что работы над “цветной” частью спецификации CSS 3 практически завершены. CSS Color Module Level 3 отправляется на предпоследнюю остановку в своём долгом пути совершенствования – Last Call Station.

Группа в составе редакторов Tantek Celik, Chris Lilley, David Baron и авторов Steven Pemberton, Brad Pettit наконец-то представила предварительную версию CSS Color Module Level 3. Работа над ней, судя по датам драфтов велась на протяжении более пяти лет: с 14 мая 2003 года по 21 июля 2008.

Все замечания и комментарии по данному релизу будут приниматься до 1-го сентября 2008 года, затем этот модуль получит статус Candidate Recommendation и будет включён без изменений в готовящуюся спецификацию CSS 3.

Если я внимательно прочитал – то единственное стоящее изменение – это добавление свойства opacity – прозрачность.

Если есть ещё что-то напишите в комментариях – не дайте помереть идиотом 🙂


“Коллеги – 1000 IT-блогов” === “IT-Nation”

Как-то упустил я момент кардинального обновления ресурса Владимира Жилинского – Коллеги – 1000 IT-блогов. Так вот… самих коллег больше нет, но…

Встречаем
It-Nation logo

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

Вообщем – добро пожаловать!
На момент написания статьи – занято 649 из 1000 ячеек, так что спешите присоединится к дружной компании техноблогеров.

Кстати, т.к. матрица блогов уже заполнена на 65%, то в ней нашлись ещё интересные моменты, кроме уже упомятнутого царя 🙂

Пока кто-то ещё только идёт на вершину,
путь на вершину

кто-то уже носит медали
медаль

а кому-то уже хана!
хана

Пока кто-то ловит манну небесную (она же халява),
манна

кто-то тяжким трудом ловит баги.
баг

Ну и напоследок – “Отпусти меня, чудо трава!”
Отпусти меня чудо трава



Рисуем вместе

Совсем недавно стартовали два гениальных (без шуток) проекта двух гениальных (без шуток) человек.
Всегда завидовал таким людям:
– во-первых – за гениальные идеи – мне почему-то такие в голову не приходят 🙁 ;
– во-вторых – за решимость их воплотить в жизнь – у меня обычно не хватает терпения воплощать идеи в жизнь.

Итак встречайте двух гениев – Миша Квакин и Антон Лобовкин и их два проекта – “Два листа” и “coDraw” (совместное рисование).

Проекты дают возможность двум (“Два листа”) и более (“coDraw”) пользователям совместно рисовать на двух или одном листе соответственно.

Проект “coDraw” более продвинут чем “Два листа”. В нём существует возможность использовать некоторые простые примитивы, а так же вводить текст.

Подробнее можно узнать на сайтах авторов.
Блог Миши Квакина – про “coDraw”
Блог Антона Лобовкина – “Два листа”


Переход на WordPress 2.6 Lecactus Edition

Вчера (в воскресенье) перевёл свой блог на рельсы (нет не Rubi on Rails 🙂 ) движка WordPress 2.6.

Переход произошёл абсолютно безболезненно, ну т.е. совсем безболезненно.

Особая благодарность за русскую версию Lecactus-у (он же Кактус Кактусович Кактусов) – спасибо всё подробно и досконально описано, хотя с проблемами я не столкнулся вообще.
Подробная и обстоятельная инструкция по переходу на WordPress 2.6.

Странно как это я до сих пор не был подписан на его блог – только что исправил это упущение.

P.S. Ещё раз спасибо Кактусу за проделанную работу!