Очень сыро и глючно. Попасть в просмотр игры можно далеко не с первого клика (выбрасывает на список). Попробовал войти как игрок, выкинуло на главную. Список игр на главной то пуст, то хаотично обновляется.
Оба участника видят код друг друга? Не круто ж совсем. Подсматривать можно :)
Обязательно добавьте сравнение ещё и по скорости выполнения и по объёму отжираемых ресурсов. И по объёму кода (гольферы порадуются).
На лепре был отличный пост «стукнись башкой об клавиатуру и напиши в комментах что получилось».
Просто сотрудник отдела выпуска патчей получил регу и зашёл его почитать.
Спасибо за ссылку на www.codeproject.com/Articles/6017/QuickFill-An-efficient-flood-fill-algorithm
На мелкой задаче применял заливку через соседние 4 точки. Получилось быстро, но только в силу мизерной области. Посмотреть можно тут github.com/Lexx918/JS.Xonix
А вот на крупной картинке упёрся в производительность. В статье по ссылке построчная заливка. Не стал портировать один-в-один, но применил от части тут github.com/Lexx918/Coloring
Плюс добавил прелоадер — сразу подготовил все строки изображения и сложил в кэш. Плюс каждую замкнутую область сразу пометил своим уникальным номером и это ещё немного ускорило поиск заливаемых строк. Летает!
Ещё раз спасибо.
Кто-нить нашёл алгоритмы пошустрее?
Поддержу. git pull. Но остаётся открытым вопрос миграций в БД. Достаточно делать их обратно совместимыми и тогда нет проблем. Для отката хватает банально checkout'а.
Молодые мамонтята читают такие посты, подрастают и потом мы видим кучу бесполезного УГ, но с очень правильным и красивым бэкэндом. Странно что не упомянули о какой-нибудь модной методологии типа аджайла. Наверное, после постов типа «почему аджайл не работает» это уже не так модно? Видимо, надо написать ещё десяток статей а-ля «почему мой проект плох, ведь я хранил весь код в гите» или «почему товар в моём магазине не покупают, ведь его сайт написан на php версии over 9000».
Скорее всего это уже не актуально в статье шестилетней давности, но не надо ли проверять done после FETCH, а не внутри WHILE?
Если селект нашёл одну строку, while успешно сработает, фетч получит данные, done не изменится, тело цикла отработает и запустится вторая итерация, while снова сработает, фетч ничего не найдёт, изменит done на 1, но цикл не прервётся и переменные со значениями прошлой итерации попадут ниже в логику тела цикла повторно.
pear.php.net/package/Text_Highlighter
4 года жил себе preg_replace и не знал бед. А теперь вне закона! Как в дешёвом плохом кино.
Оба участника видят код друг друга? Не круто ж совсем. Подсматривать можно :)
Обязательно добавьте сравнение ещё и по скорости выполнения и по объёму отжираемых ресурсов. И по объёму кода (гольферы порадуются).
А ваще круто! Спс!
Просто сотрудник отдела выпуска патчей получил регу и зашёл его почитать.
На мелкой задаче применял заливку через соседние 4 точки. Получилось быстро, но только в силу мизерной области. Посмотреть можно тут github.com/Lexx918/JS.Xonix
А вот на крупной картинке упёрся в производительность. В статье по ссылке построчная заливка. Не стал портировать один-в-один, но применил от части тут github.com/Lexx918/Coloring
Плюс добавил прелоадер — сразу подготовил все строки изображения и сложил в кэш. Плюс каждую замкнутую область сразу пометил своим уникальным номером и это ещё немного ускорило поиск заливаемых строк. Летает!
Ещё раз спасибо.
Кто-нить нашёл алгоритмы пошустрее?
Чтоб уж наверняка никто не ошибся.
Если селект нашёл одну строку, while успешно сработает, фетч получит данные, done не изменится, тело цикла отработает и запустится вторая итерация, while снова сработает, фетч ничего не найдёт, изменит done на 1, но цикл не прервётся и переменные со значениями прошлой итерации попадут ниже в логику тела цикла повторно.