Денис Пушкарев

вам бы на фриланс-биржу с такими вопросами.... или на форум какой...

apt-get remove / purge не подходят?
Я не извращененц, но опишите позы, пожалуйста. Может вы к ней, просто, не стой стороны зашли?

Если у вас это нативный forEach, то он в качестве второго аргумента может принимать контекст. Т.е. просто

arr.forEach(function(elm){... this.F2(); ... }, this);

Если ненативная функция, то надо смотреть детали ее реализации.

эм.... почитайте про $provider и как регистрировать сервисы.

.factory('projects', function($scope,$http) {
        
    return {
        all: function () {
              return $http({
                    url: "api/companies/",
                    method: "GET"//,
                    //data: {"foo":"bar"}
              }).success(function(data, status, headers, config) {
                    return data;
              }).error(function(data, status, headers, config) {
                   $scope.status = status;
              });
        }
    };
});

использовать так:

.controller('MyCtrl', 
    function ($scope, Projects) {
        projects.all().then(function (list) {
             $scope.list = list; // или что вам там надо...
        }
    }
);

Жутко.

эм... что?

конкатенация стилей/скриптов и их последующая минификация - это нормальная практика. Для этого ненужно никаких стандартов. Делайте хоть на лету, хоть собирайте один раз при деплое (что было бы логично) а еще лучше сразу же ложите рядом уже сжатый в gzip вариант ваших скомпиленых файлов. Опять же смысла сделать из двух файлов один я не вижу как минимум по следующей причине: стили должны загрузиться раньше скриптов. Во всяком случае в большинстве случаев. Загрузка скриптов не должна блокировать загрузку страницы.

Что касается SPDY - то тут вы вообще ни капельки не попали. Там профит в том что используется одно tcp-соединение с сервером и мультиплексирование данных. Это позволяет снизить нагрузку на сервер, не тратить время на подключение к серверу по новой для загрузки следующих файлов и т.д. По сути при использовании этого протокола конкатенация файлов стилей и скриптов не должна приносить существенного профита, ибо соединение все равно будет одно и то же.

p.s. приведенная вами статья не даром находится в хабе "ненормальное программирование".

wiki

А маркетологи и не работают. Они делают деньги. Из чужой работы, например. А для этого они должны уметь делать вид. Делать вид, что сервис работает как надо. Делать вид, что за него стоит платить. Если вы не можете сделать вид, что ваша деятельность стоит оплаты, то какой вы, к чертям, маркетолог? Делитесь.

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

Они вообще не предназначены для асинхронных веб-приложений

Присоединяюсь к рекомендациям попробовать Node.js, аргументом в пользу которого является то обстоятельство, что веборазработчику при его изучении не приходится изучать заодно новый язык: в Node используется JavaScript, на котором и без того работает клиентская часть сайтов.

Таким образом для перехода на Node достаточно изучить API Node и освоить выбор нужных готовых модулей с открытым исходным кодом, разработанных сообществом. Модули можно находить по списку в вики или искать по ключевым словам на сайте npm.

В частности, готовых NoSQL-модулей там дофигищща. (Есть даже NoSQL-средства, специально разработанные для Node — в частности, NeDB.)

и в это время срабатывает событие javascript однопоточный, по этому в «это время» ничего не может произойти снаружи (то-есть только внутри цикла).

Вам не проще как то этот вопрос обсудить с работодателем и не с хаброюзерами?
Сказать так и так не хочу подписывать такой договор.

Сами таблицы не плохо. Тут как уже говорилось выше вопрос семантики.
Но по сути просто плохо, когда то, как страница должна отображаться, влияет на разметку. Да, оно всегда влияет, но по мелочи. А тут у вас заведомо ограничения по разметке. Плохо влияет на расширяемость и поддержку кода.

Так ведь есть стек C# для web. ASP там всякое.

Могу предположить, что Opera поддерживает CORS только с 12-й версии — developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS
Поэтому Socket.IO переходит к JSONP.