Pull to refresh
28
0
Миндубаев Андрей @Covex

Разработчик ПО

Send message
нарисовать карты районов для всей России осилит не каждый
Они все уже нарисованы и храняться в wikimapia. Можно подключить слой от WikiMapia в Google Earth и сохранять полигоны в kml-файлы.

Я такое безобразие делал для сервиса частных объявлений о недвижимости. Способ, может быть и не совсем прямой, но для Нижнего его таки можно осилить =)
Обращение к переменной $_smarty_tpl->getVariable('thing')->value['color'] явно медленнее, чем $this->_tpl_vars['color']
В третьей версии смарти всё, что не касается инклюдов медленнее чем во второй.
Надо было придумать пример без дерева — чтобы статья более разоблачительной казалась =)
// блин, текст статьи поменялся =) коммент отменяется
А если до вывода поставить ob_start(); а после вывода — ob_end_clean(); то результаты будут совсем другими =)

php test-xslt.php
— total: 29.31005859375
php test-smarty.php
— total: 713.7099609375
php test-php.php
— total: 18.787841796875

Фактически получается, что в твоих тестах XSLT борется с функцией _smarty_include класса Smarty (если что — я не в курсе часто ли она используется на практике)

ЗЫЖ Смарти — зло! =)
> всегда с интересом брал на себя работу менджмента
Согласен. Это интересно!
Но всё упирается в рамки. Ваши термины «художник» и «таджик» — это описание границ возможного поведения: «Художник» делает что хочет, а «Таджик» то, что ему говорят. «Менеджер среднего звена» — это «СуперТаджик», он отличается от обычного тем, что он начальник. И всё )
Личный опыт.
Сейчас я уверен, что мне лучше либо работать «на дядю» на должности «художника» либо работать на себя. Но уж никак не быть «начальником под управлением дяди».
(сейчас я уже давно не «начальник» =)
> Став начальником, это чувство остается.
Став начальником художник перестаёт быть художником ) А чувство может притупиться до нуля.
> не имею технической возможности протестировать на *nix
Виртуальная машина спасёт отца русской демократии )
А ещё этот код — не рабочий =( С [{}{}] он работает неверно. Вот новый, рекурсивный:
  1. var check = (function(close) {
  2.  var bracket = { }, ch, end;
  3.  for (i in close)
  4.   bracket[close[i]] = (function(i) {
  5.    return function(pos) {
  6.     if (ch[pos+1] == i)
  7.      return pos+2;
  8.     else if (bracket[ch[end = pos+1]])
  9.      while (end = bracket[ch[end]](end))
  10.       if (ch[end] == i)
  11.        return end + 1;
  12.     throw { };
  13.    }
  14.   })(i);
  15.  
  16.  return function(str) {
  17.   try {
  18.    var pos = 0;
  19.    while (pos < str.length)
  20.     pos = bracket[(ch = str)[pos]](pos);
  21.    return true;
  22.   }
  23.   catch (e) {
  24.    return false;
  25.   }
  26.  };
  27. })({ ')':'(', '>':'<', '}':'{', ']':'[' });
  28.  
  29. alert(check("[<>{}]")); // true
  30. alert(check("")); // true
  31. alert(check("[[[]]][][[]][()]{}[]")); // true
  32. alert(check("[[[)]]][][[]][()]{}[]")); // false
  33. alert(check("]")); // false
* This source code was highlighted with Source Code Highlighter.
А ещё мой вариант быстрее в 4 раза.
Понятный алгоритм со стэком уже 1602 выложил =)
JavaScript:
var check = (function(close) {
 var open = { };
 for (i in close)
  open[close[i]] = i;

 return function(str) {
  var first=0, begin = 0, end = 1, len = str.length;
  while (first < len) {
   if (close[str[end]] == str[begin]) {
    if (begin == first)
     begin = first = ++end;
    else
     begin--;
   }
   else if (open[str[end]])
    begin++;
   else
    return false;
   end++;
  }
  return true;
 };
})({ ')':'(', '>':'<', '}':'{', ']':'[' });

alert(check("[[[]]][][[]][()]{}[]")); // true
alert(check("[[[)]]][][[]][()]{}[]")); // false

* This source code was highlighted with Source Code Highlighter.
Без стэка =)
На конференции UserExpiriense 2007 Maria Stone рассказывала о том как менялся внешний вид блока «Возможно вы имели ввиду», и об эффекте от каждого изменения: количество кликов на уточнённую фразу увеличивалось каждый раз то ли в 2 раза, то ли на порядок.

Было бы интересно узнать эффект от и этого улучшения =)
Это труЪ, если шифровать только UserID.
А не обязательно хранить пароль в куках =) Закриптованный UserID в куках, который можно расшифровать на сервере, уже можно считать подтверждённой аутентификацией!
«Нужно ли» и «подходит ли» — зависит задачи и от её реализации. Но я всё же считаю, что экономия серверных ресурсов должна перевесить все остальные аргументы и домыслы.

> как это не аргумент? :)
Скоро будет готов «прототип» подобной системы (правда, пока без кэширования =). И как только придумаю «описание для людей» — можно будет обсудить =)
Ни о каких справочниках и прочей статике речь не идёт. Речь об обычных динамических html-страницах. Фактически в куках нужно будет хранить только информацию об авторизации + какие-то другие некритичные данные.

ЗЫЖ Геморрой — не аргумент! =)
> А смысл?
Смысл в «кэшировании всего» даже для авторизированных пользователей!
Если получится сделать такое кэширование, то серверное приложение требовало бы намного меньше ресурсов. Сервер даже мог бы отдавать 304 Not Modified — а это очень контрастирует с вашим «гонять кучу информации».
На highload++ Марко Кевац в своём докладе привёл очень хороший (и главное — работающий) пример RESTful авторизации: highload.ru/papers2008/7166.html

Information

Rating
Does not participate
Location
Нижний Новгород, Нижегородская обл., Россия
Date of birth
Registered
Activity