Сергей Протько

Обычный старый добрый ID (число с автоинкриментом) + перевод в другую систему счисления. 62-ичной более чем хватит, как вам и предлагалось выше.

Я лично заказал бы только под мои требования CMS (а точнее в моем случае потратил бы пару недель и написал бы сам).

Но если выбирать между этими двумя… пройдемся по пунктам:

1) Тут выигрывает x-cart (хотя опять же смотря в какой редакции, но даже в самое дешевой — выигрывает, хоть и не сильно)
2) Тут уже сложнее, насколько я помню из коробки этого нету. Да и для x-cart вроде бы тоже не видел, а для магенту есть точно. Но быть может моя информация устарела. Я x-cart ресерчил где-то пол года назад.
3) Из коробки в дорогих редакциях x-cart или же модули для магенту. Но если брать модули то возможностей больше.
4) тут сказать ничего не могу.
5) есть вроде бы в обеих. Явного лидера назвать не могу
6) Модули
7) X-CART примитивнее, но с другой стороны с разработчиками под magento намного более приятная ситуация. Да и сама структура непривычна только первое время.
8) ERP — интеграции есть. Для x-cart знаю что некоторые конторки предоставляют возможность интеграции в обе стороны для множества ERP систем. Но точно ничего сказать не могу ибо с этим никогда не сталкивался. Мод магенту же с этим проще. Есть как бесплатные так и платные решения.
9) если судить объективно — и то и то выглядит ущербно. Из коробки покрайнемере. По поводу костомизации в этом вопросе ничего сказать не могу, ибо не занимался. Хотя с другой стороны ничего лучше особо и нету… и это печально
10) тут обе системы вроде подходят
11) нифига админы не в грязных свиторах… Ну да несуть. По поводу x-cart честно не знаю в этом плане, но допилить какие-то механизмы для более шустрого поиска можно. Так же как и для магенту использовать для поиска сфинкс/монго. При небольшой заточке напильником, исходя из возможностей вашего сервера, нагрузки они оба будут выдерживать примерно одинаково.
12) Тут однозначно лидер магенту. Потому то он и стал так быстро набирать обороты в самом начале.

Такие дела.

api.jquery.com/jQuery.ajaxSetup/

Вопервых это слишком специфичная оптимизация. Я допустим ни разу не встречал необходимости в подобном. Это все же не оптимизация даже, а способ агрегации данных.

Во вторых — да, это экономия на спичках. Даже если у вас этих данных мегабайт, то вы еще должны будете на клиенте/сервере данные обработать. Я бы лучше поэкономил процессорное время.

Если у вас есть опыт работы с C# было бы логично попробовать .NET ASP MVC, думаю освоение оного проблем у вас не составит. Работа с базами — различные ORM (от стандартного Entities Manager до Hibernate и прочее). Если говорить о бэкэнде то даже не вижу смысла использовать еще что-то такое эдакое. Разве что для задач реализации REST API и прочего. Фронтенд — тут уже чуть сложнее. HTML5/CSS верстка довольно простая штука, но тут опыт нужен. Знал много верстальщиков которые хорошо знали и особенности поведения тегов и свойств, но не понимали концепции (у них разметка зачастую была привязана к оформлению страницы, а это уже плохо). Но в целом это много легче чем C++/Boost/SPL. Javascript — тут стоит владеть функциональным программированием.

Вообще, разница между программированием для десктопов и для WEB (если касаться серверной части и реализовывать на C#, PHP или Java) не сильно различается. Знать огромное количество фреймворков не обязательно, достаточно выбрать какой-то один. А потом взять другой будет все же достаточно просто.

Удачи в ваших начинаниях.

code.google.com/p/pyv8/downloads/detail?name=PyV8-1.0-preview-r446.win-amd64-py2.7.exe&can=2&q=

Нет?

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

Не оно?

1) определить в пикселях поле где расположен граффик
2) задать масштаб (сколько пикселей приходится на одну еденицу значения)
3) идем по полю и ищем зеленую или синию линии (пиксели) и помечаем координаты в массив (идти только нужно по вертикали, при поиске точек на графике)

Это можно реализовать и на JavaScript, при желании.

Задача распознавания никак не привязывается к языку. Готовых решений — масса. Мне к сожалению (или к счастью) с распознаванием текста сталкиваться не приходилось, только образы. Но вы можете поискать даже тут, на хабре, пример реализации распознавания капчей. На этом принципе можно реализовать.

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

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

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

dev версия сайта обычно клонится с master, в редких случаях создается ветка dev (хотя на моей памяти никогда это не нужно было).

А дальше, если работаете итерациями и у вас несколько версий должно быть задеплоено — все разносится по своим веткам. На сервере же делается просто checkout нужной ветки.

То бишь доделали фичу — смерджили в мастер. Прогнали тесты. Если все хорошо — пушим. Если нужно выкатить на лайв или куда еще — мерджим фичу/master в нужную ветку. После изменений в ветках отличных от master все должно быть замерджено в него, ибо ветки с фичами делаются от мастера.

Все зависит от задачи на самом деле. Костали имеют место быть везде и всюду, особенно в ситуациях с постоянно меняющимися требованиями. При желании и на HTML5 интерфейс можно сделать без особых кастылей.

А почему вы не используете готовые фреймворки (тот же Yii, Symfony2) где эта проблема решена уже?

Не проще ли записывать логи в YML скажем (реализовать в таком случае перечисленные методы труда не составит, а приличные текстовые редакторы умеют сворачивать ветки).

Готового решения не припомню.

Смотря какого рода поиск вы хотите организовать.

Если вы хотите организовать поиск непосредственно по какому-то массиву данных, то есть underscore.js. Есть так же имплементации .NET-овского LINQ под js. Вобщем штук таких много, уточните что именно вам нужно.

Насколько мне известо в сафари и хроме есть различия в рендринге (несмотря на то что оба работают на WebKit), да и движки JavaScript у них тоже абсолютно разные.