Pull to refresh
16
Karma
0
Rating

User

  • Followers 7
  • Following 4

Числа, которые должен знать каждый программист

Конкретно этот пример про php не совсем корректен, посмотрите на тему php copy on write. Т.е. что для строки 0 байтов, что для строки 1 Мб при таком присвоении не происходит копирования (копирование будет при изменении значения переменной, а так — два имени имеют ссылку на одно значение). Полезная штука кстати — передача здоровенных массивов аргументами функции будет стоить примерно столько же, сколько передача инта, если массивы не меняются.

Семь заповедей быстрого чтения

Если кто-то дочитает :), для таких в танке, как я, кто через пару дней смотрит топики.

Для быстрого чтения можно читать сразу словами, потом группами слов, потом строками, как говорилось выше. Интересное упражнение для этого - попробуйте перевернуть книжку и почитать к верх ногами. Потом обратно, потом опять, и так там по полстраницы-странице. Интересные ощущения. По себе отмечал, что читать реально начинаешь блоками.

Вежливое обращение на сайтах

Если честно, тема для меня новая, но грамотно писать хочется. На "Вы" всегда заостряется внимание (видимо, большая буква посреди предложения), и как-то слегка некомфортно. С другой стороны - всегда считал это "правильным".

С точки зрения текстов на сайтах всегда это воспринимал, как подчёркивание разницы между "вы" - множественное число, толпа, и "Вы" - конкретный человек, который пришёл и важен. Объясните, где тут подвох? :)

Shlist.ru — списки покупок стали ближе

Спасибо, опечатку поправил.
С разными списками - не думаю, что сразу, но сделаю. Пока можно просто в отдельную категорию в конце складывать, чтобы не мешалось, но в целом это в списке доделок, спасибо за пример с Икеей :).

Shlist.ru — списки покупок стали ближе

Прошу у всех прощения за досадный баг, очищавший все списки при редактировании одного. Много информации потерялось, очень жаль, что только отследил :(.

Shlist.ru — списки покупок стали ближе

В принципе - да, надо будет подумать над этим :). Как быстрое решение - просто не чистить выполненные.

Правда с тэгами всё равно не понял, куда их? Как категоризация бооольшого списка товаров?

Shlist.ru — списки покупок стали ближе

Эта штука была написана в последний момент, чтобы иметь возможность в случае чего. Сами понимаете, напишет там кто-нибудь матом, сделает доступным, Яндекс съест, ну кому это нужно?

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

Shlist.ru — списки покупок стали ближе

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

По Java - понятно.

А по тэгам - приведите use-case, как это можно использовать?

Shlist.ru — списки покупок стали ближе

Хм, к сожалению такие штуки сложно отлаживать :(, попробую помучать WM2003, есть один в сравнительно близкой доступности, но скорее всего не сразу удастся поправить.

Shlist.ru — списки покупок стали ближе

Интеграция с чем?

Shlist.ru — списки покупок стали ближе

С мобильным и смс - да, возможное продолжение, но это определённо будет платная штука просто потому что отправка смс - платная.

Shlist.ru — списки покупок стали ближе

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

Shlist.ru — списки покупок стали ближе

Я подозревал, что что-то не так с этим названием :)

Shlist.ru — списки покупок стали ближе

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

Shlist.ru — списки покупок стали ближе

Спасибо :)
По вёрстке - я долго упирался, чтобы сделать без таблиц, потом пришлось забить - конкретная задача проще решалась таблицами, а я в конце концов больше программист, чем верстальщик.

А по логотипу - есть идеи, куда его улучшать? Ну или просто, за что зацепился глаз?

Версия для телефона - пожалуй не самая простая задача, но вполне реализуемая, если это будет востребовано. Кстати, никто не поделится ссылочками на разработку под J2ME, интересуют: удобная среда разработки, примеры. Инет пока на эту тему предметно не исследовал, просто если у кого был опыт, и есть ссылка под рукой - буду признателен.

Эхо или печать?

Я здесь никак не трогаю массивы :), речь идёт о буфере вывода, это несколько другое, это можно понимать как массив конечно, но в терминах Си, т.е. некоторая область памяти. По поводу "оптимизации под обработку текста" - никто не спорит, просто я рассмотрел то, что делает PHP "за сценой", причём не предполагая что-то, а почитав исходники PHP :), это ли не первоисточник, чтобы понять суть?

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

Ну и ещё раз, это микрооптимизация, этим можно не заниматься и жить нормально, это так, "хозяйке на заметку" :).

Эхо или печать?

В общем ещё можно задуматься про причины наличия разницы, в мануале чётко сказано про то, что echo результат не возвращает, а print возвращает 1, т.е. print = echo + операция по сохранению результата во временную переменную. Это по определению медленее, но не настолько, чтобы обращать на это внимание :).

Более интересна ситуация с echo $a, $b, $c; VS echo $a . $b . $c. А ещё более интересна ситуация с накоплением вывода в $out путём сотни-другой конкатенаций, а потом вывода. Вот здесь разница будет ощутимой.

Дело в том, что echo $a, $b = поместить в буффер вывода сначала $a, потом $b. Теперь учтём, что буффер для этого предназначен, т.е. в нём память выделяется с запасом, это даст то, что такая операция скорее всего не будет приводить к выделению памяти (вернее будет, но редко, когда буффер переполняется и нужен новый большой кусок памяти).

А вот echo $a . $b = провести конкатенацию строк $a, $b (выделить память, скопировать), потом положить в буффер вывода (который также придётся изменять, если он переполнится, или не придётся, если его хватит). Таким образом имеем всегда дополнительное выделение памяти и дополнительное лишнее копирование.

С конкатенацией ещё забавнее - вариант $out .= $a, и т.п., каждая такая операция - это перевыделение памяти, причём под конец накопления страницы достаточно большого объёма. Это объясняется тем, что в zval'е хранится только указатель на строку + длина, т.е. память выделяется ровно на строку. Вообще в PHP довольно хитрый менеджер памяти (сейчас попробовал вчитаться в исходники, что там). Там для этого случая идёт свой realloc, а он как повезёт, либо просто задействует новый кусок памяти за переменной (если он есть), либо, если его нет - выделяет новый большой и копирует туда.

Подводя итог:
ob_start();
// много раз echo
$result = ob_get_clean();
на большом количестве echo быстрее, чем накопление в $result.

А вот обращать на это внимание или нет - дело каждого. Я просто включил все эти мелочи в свой стиль, т.е. пишу так весь код, приятно знать, что он будет изначально работать чуть быстрее. Хотя вылизыванием старого кода так заниматься не стоит - есть куда более действенные способы оптимизации. А так - если есть два варианта сделать одно и то же, и они одинаковы по сложности реализации, то почему не выбрать тот, что работает быстрее? :)

Оптимизация работы с MySQL

Ну к примеру мы считаем статистику, статистика вставляется с ключём "дата", "элемент", статистика за определённый период может пересчитываться (с целью корректировки, скажем, или просто что-то падало и надо восстановить). Соответственно идёт дубликат по первичному ключу, самое простое - REPLACE и не париться. Однако, если в обновлённой статистике элементов стало меньше - то в том, что посчитается будет смесь правильных данных и того, что было. Выход - сначала удалить период за дату, потом вставить - будут чистые данные. Казалось бы, дурацкая ошибка, но я с таким сталкивался.

Оптимизация работы с MySQL

На мой взгляд INSERT IGNORE, также, как REPLACE и ON DUPLICATE KEY UPDATE - порой очень опасные конструкции, т.е. их если применять, то в очень узких местах, когда действительно, лишний запрос недопустим, и полностью осознавая, что делаешь.
За свою практику встречал случаи, когда люди этими конструкциями "затыкали" ошибки в запросах, что приводило потом к очень долгой и проблематичной отладке (т.к. заткнули симптомы, а причина осталась и потом вылезает в самых неожиданных местах).

Одминко: CMS на ExtJS 2.0. Что с ней теперь делать?

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

Кстати, подскажите, у вас на скриншотах редактирование хтмл-я с подсветкой синтаксиса, чем такое делается?
1

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity