addfs

Баг в NetBeans 7.0 beta

2010-11-19T22:11:00.002+03:00

Буквально вчера вышла бета версия NetBeans 7.0, у меня в принципе она работала довольно безбажно еще и в дев версии, если бы не кодировка большинства проектов в cp1251 :)

В чем его суть — еще с dev версии 7.0 M2, если кодировка проекта в windows-1251, то все html файлы кодируются в utf8, с остальными все ок.

Еще, если создать в том же проекте html файл, то он создается с правильной кодировкой что и проект, но в коде строка с meta тэгом помечается как несоответствующая, указанной кодировке в атрибуте charset и кодировке файла, вообщем выглядит это вот так:

Никто не встречал такого? Думаю запостить баг им в багтрекер.

Ссылки и foreach

2010-08-27T12:02:00.006+04:00

Это перевод статьи которую в написал Johannes Schlüter в своем блоге. Оригинал можно найти перейдя по ссылке References and foreach. Я использовал изображения из его поста, добавив подписью, перевод надписей. На самом деле это вообще мой первый перевод, который я публикую, так что надеюсь что получилось не слишком плохо.

Ссылки в PHP ужасны, как я уже говорил и вы безусловны должны избегать их использование. Так вот, есть один пример, который приводит на первый взгляд к неожиданному поведению, которое я еще не видел, до того как я наткнулся на него в первый раз, но затем было несколько бег-репортов об этом инцеденте, а недавно знакомый спросил меня о нем, итак вот он:

Что выведет этот код?

$a = array('a', 'b', 'c', 'd');
foreach ($a as &$v) { }
foreach ($a as $v) { }
print_r($a);

Мы делаем 2 раза итерацию по массиву, ничего не делая с ним. Так что результат не должен измениться. Правильно? - Не Правильно! На самом деле результат будет таким:

Array
(
    [0] => a
    [1] => b
    [2] => c
    [3] => c
)

Для того чтобы понять, почему так произошло, сделаем шаг назад и посмотрим как реализованы переменные и ссылки в PHP:

Переменные в PHP в основном состоят из двух вещей. Метка (“label”) и контейнер (“container”). Метка это запись в хэш таблице (есть несколько оптимизацонных моментов в движке, поэтому не всегда в хэш-таблице, ну да ладно) которые могут представлять собой таблицу символов функции, массива или таблицу свойств объекта. Итак, у нас есть имя и указатель на контейнер. Внутреннее название контейнера “zval”, он хранит значения и некую мета информацию, этот контейнер также может быть новой хэш-таблицей с набором меток, указывающих на другие контейнеры, если мы сейчас сделаем ссылку на него, то это приведет ко второй метке указывающей на этот контейнер с другой меткой. Обе метки с этих пор имеют те же полномочия что и контейнер.

Теперь давайте посмотри на ситуацию более детально.
Графически это будет выглядеть так:

Глобальная таблица символов (ГТС)

Итак у нас есть 6 контейнеров (глобальная таблица символов вверху, контейнер содержащий массив называющийся $a слева и по одному контейнеру на каждый элемент - справа) Теперь мы начнем первую итерацию. ГТС получает новую запись $v и это делает ссылку на контейнер первого элемента массива.

Новая глобальная перменная v содержащая контейнер с ‘a’

$a[0] и $v находятся в одном контейнере, следовательно при их изменении одной переменной, на другой будет тот же эффект. Когда итерация продолжится, ссылка оказывается сломанной и $v делает ссылку на другой элемент. Так после окончания итераций $v ссылается на последний элемент.

После итерации $v указывает на ‘d’

Запомните: $v ссылка, а значит любые изменения $v, оказывают тот же эффект и на переменные на которые она ссылается, в нашем случае это я$a[3]. До сих пор не произошло ничего особенного , но сейчас рассмотрим второю итерацию. Она присваивает значение текущего элемента переменной $v для каждого шага. Сейчас $v ссылается на элемент $a[3], так что после присваивания значения к $v, $a[3] тоже изменится.

Для первого шага второй итерации значение $a[0] присваивается переменной $v

Это продолжается и для следующих шагов:

И теперь мы легко можем догадаться что будет на последнем шаге: $v присваивается значение последнего элемента $a[3] и так как $a[3] является ссылкой на $v, то следовательно ничего не происходит.

И это результат который мы видели выше. Таким образом чтобы сделать короткий вывод из этой истории с картинками: Будьте осторожны с ссылками! Они могут иметь очень странные эффекты.

T_PAAMAYIM_NEKUDOTAYIM

2010-08-18T10:00:00.000+04:00


Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in /path/to/file/error.php on line 3

Загадочно? По моему достаточно) История T_PAAMAYIM_NEKUDOTAYIM начинается с php 3.0 и использовавшегося там Zend Engine 0.5, разработанного в Израиле. На языке Hebrew, Paamayim Nekudotayim означает "twice colon" (двойное двоеточие ::) и используется в php в качестве scope resolution operator К слову воочию увидеть эту ошибку можно просто выполнив команду


php -r '::'

Предыдущий пост по теме — Регистр имен переменных и функций в php.

Регистр имен переменных и функций в php

2010-08-15T14:27:00.028+04:00

Изначально, тема Strangest language feature была создана на stackoverflow.com и мне показалась она очень интересной, в последствие я решил сделать свой список странных и не очевидных вещей в ЯП, а точнее я решил ограничиться php и javascript, как наиболее близкие мне и те которыми я постоянно пользуюсь. Конечно лучше и вовсе не было бы таких сюрпризов и все было бы всегда просто, логично и прозрачно, но практически это утопия, да и держать все эти причуды в голове, тоже не всегда получится, поэтому лучшим решением для себя я нашел публикацию их у себя в блоге. Надеюсь это окажется полезным не только мне.

Начать я бы хотел с php и регистра переменных и функций. В php функциии регистро-независимы в отличие от переменных:

function add($a, $b)
{
    return $a + $b;
}

$foo = add(1, 2);
$Foo = Add(3, 4);

echo "foo is $foo"; // outputs foo is 3
echo "Foo is $Foo"; // outputs foo is 7

Как мы видим здесь $Foo и $foo разные переменные, а Add() и add() одна и та же функция. Кстати, названия классов тоже не чувствительно к регистру.

Несколько слов о книге Джоэля Спольски.

2010-07-07T17:42:00.009+04:00

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

Ниже я выделил буквально пару моментов которые мне пригодились бы в работе.

1. Установите приоритеты

Что делать, если работы хватит для тысяч программистов на 10 лет, а у вас 3 программиста и следующую версию вы планировали выпустить этой осенью?

Придется расставлять приоритеты. Далее будет приведен пример расстановки приоритетов для коробочной модели разработки.

Каждой функции выделяется карточка.
Собирается команда для совещания, до 20 человек, не только программисты, а как раз все чтобы мнения были различны, тестеры, агенты, клиенты(!)
Каждый приходит с личным списком будущих функций.
Вкратце рассказываем про каждую функцию, чтобы у всех собравшихся было общее представление о каждой из функций и чтобы для каждой функции была заготовлена карточка. Идея в том чтобы не спорить о достоинствах каждой функции и не проектировать ее, а просто составить представление о ее сути.
Голосование за функцию (за или против)
Отсев самых непопулярных
Назначение цены каждой функции, в зависимости от скорости реализации от 1 до 10 (10- функция-монстр)
Каждый разработчик получает составленное меню и 50 очков на расходы, разрешается как угодно потратить очки, купить половину функции или двойную.
Затем анализируем сколько было потрачено.
Делим истраченную сумму на цену
Сортируем по полученному коэффициенту, чтобы определить самые популярные.
Готово. Получен список всех функций, которые можно реализовать примерно в порядке общих представлений.

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

2. Пять почему

Общий смысл в том чтобы каждая проблема прошла 5 вопросов почему.

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

3. Заставляем неправильный код выглядеть неправильно

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

Венгерская нотация, которая позже была не правильно интерпретирована и приобрела смысл типов переменных, хотя изначально задумывалась Чарльзом Симони как смысловое определение (kind, а не type, как по ошибке написал автор нотации).
Тут скорее интересен сам факт искаженного понимания смысла венгерской нотации и скорее совет как не стоит делать, по мнению Джоэла. Он всетаки призывает использовать смысловые префиксы а не указывающие на тип.

P.S. В процессе написания поста нашел статьи Джоэла Спольски, переведенные на различные языки, в том числе и на русский.

Подключение багтрекера mantis к eclipse

2009-09-02T15:11:00.045+04:00

http://sourceforge.net/projects/mylyn-mantis/ - Ссылка на сайт проекта
Недавно обнаружил, что наш багтрекер можно интегрировать в eclipse, что я собственно сразу и сделал.
Теперь у меня всегда под рукой есть список задач.
Очень порадовало, что задачи можно распланировать на всю неделю, жмакнуть Focus on week и получить список работ)

Из недостатков я бы отметил невозможность увидеть иконки к задачам (приоритет, серъезость) если выставлен русский язык в мантисе. Я пробывал изменять на английский, после обновления иконки повлялись, но новые все равно добавляются без. К сожалению так и не разобрался.

Подробнее о системе Mylyn:
Eclipse Mylyn Open Source Project
htt p://www.tasktop.com/mylyn/