• Почему Json не распарсивается дважды?

    Faraday
    @Faraday
    Возможно у вас неверно составлен JSON на серверной стороне, сделайте после парсинга console.log и посмотрите корректно ли все.
    Ответ написан
    5 комментариев
  • Почему не видит GetRespons приложение windows phone?

    aush
    @aush
    Под windows phone (изначально, так сделали под silverlight) нет синхнонного GetResponse, вместо него следует использовать асинхронные операции, например, BeginGetResponse или GetResponseAsync.
    Ответ написан
    Комментировать
  • Почему не видит GetRespons приложение windows phone?

    @follow39
    Потому что для телефона другое API.
    Ответ написан
    Комментировать
  • Как распарсить socket?

    используйте тот инструмент, который подходит к вашим полученным данным.
    html - DOM
    json - json_decode
    xml - SimpleXML
    итд
    Ответ написан
    3 комментария
  • Где найти хороший туториал по связке angular node mongo?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Для начала упростим задачу поиска. angular + node = angular + rest. Ангуляру без разницы на чем реализован backend если там православный rest.

    Итого имеем angular + rest и node.js + mongo. Далее, для node.js обычно используют штуки типа express.js или основанные на нем фреймворки. По монге стоит почитать отдельно, ибо проектировать базу на монге не так то уж и просто как может показаться на первый взгляд. Нужно проникнуться идеологией.

    Резюмирую: учимся писать на angular.js без сервера, учимся писать rest api на node.js, учимся работать с mongodb, связываем все вместе.
    Ответ написан
    Комментировать
  • Что за ошибка l buffersmall?

    EvgenijDv
    @EvgenijDv
    C/C++ programmer
    У вас где-то слишком маленький буфер. Зайдите под отладкой и посмотрите в каком именно месте вашего кода возникает данная ошибка. Скорее всего это в одном из strcpy_s.
    Ответ написан
    Комментировать
  • Есть ли аналоги coffescripta для php?

    @maxyc_webber
    Web-программист
    нахрена писать на 1 языке чтоб скомпилить в другой чтоб скомпилился третий и отработал.
    Ответ написан
    7 комментариев
  • Какие технологии, библиотеки, фреймворки нужны, чтобы создавать такие сайты?

    baskerville42
    @baskerville42
    Учусь работать (Junior)
    CSS, HTML, JavaScript
    А библиотеки есть разные и для разных потребностей. Вот когда выучите первые три вещи, остальные вопросы отпадут сами по себе.
    По html и сss не подскажу ничего лучше чем htmlbook.ru и заглядывать переодически сюда и на стаковерфлоу. А вот по джаваскрипту однозначно фленеган, знаменитая книга с носорогом. Хотя для новичка она может быть довольно сложная, так как в большинстве расчитана на человека с каким либо опытом в програмировании.
    Ответ написан
    Комментировать
  • Каким api воспользоваться для сервиса прокладки маршрута?

    syschel
    @syschel
    freelance/python/django/backend
    А АПИ яндекс карт не даёт такие возможности? Или там есть какие-то свои нюансы?
    Ответ написан
    2 комментария
  • Каким api воспользоваться для сервиса прокладки маршрута?

    @maxyc_webber
    Web-программист
    автокомплит dadata.ru
    либо basicdata.ru - база фиас

    для россии лучше использовать яндекс
    Ответ написан
    4 комментария
  • Как правильно настроить PHPStorm7 для PHPUnit?

    janson
    @janson
    PHP-разработчик
    Действительно - проще всего с .phar файлом в конкретном проекте.

    Версию PHPUnit ставьте 3.7.XX. С четвёртой версией в PHPStorm 7 пока что баг с запуском тестов (в PHPStorm 8 EAP вроде починили). Вручную из консоли всё работает, а вот из PHPStorm - ругается.

    Как запустить:
    1. Создаём структуру проекта, как по данной вами ссылке:

    |-src
    |   |-autoload.php
    |   |-Money.php
    |
    |-tests
        |-MoneyTest.php


    В файле autoload.php нужно подключить файлы, которые вы собираетесь тестировать.

    <?php
    require_once __DIR__ . '/Money.php';


    2. Настраиваем конфигурацию PHPUnit:
    Run -> Edit Configurations...
    В левой верхней части появившегося окна жмём зелёный плюс и настраиваем конфигурацию:
    - устанавливаем Test Scope на 'Directory' и указываем путь к папке tests
    88950935cf654d2d9913317a82873cc6.png
    - жмём на гаечный ключ и настраиваем путь к phpunit.phar (если у вас локально используется папка с PHPUnit - то подключаете её в File -> Settings -> ProjectSettings -> PHP ... Include Paths, и затем в настройках PHPUnit переключаем на Load From Include Path).
    73258cc7bdf54d138d5cf60708810d02.png
    - также указываем default bootstrap file на наш autoload.php, где подключаем классы, которые собственно будем тестировать (где лежат сами тесты мы указали для PHPUnit в начале).
    - Жмём Apply -> Apply -> OK

    Всё, теперь рядом с созданой конфигурации на панели PHPStorm появилась зелёная стрелка для запуска тестов. Жмём, и если всё правильно - получаем зелёную полосу.
    c3371b9827824186b099c19932bbfac7.png

    Т.е. процесс настройки - это три шага:
    1. указываем где лежит PHPUnit
    2. указываем где лежат тесты
    3. указываем где лежит загрузчик тестируемых классов.

    Вроде всё.
    Ответ написан
    1 комментарий
  • Закон Деметры. Нужен ли?

    NightTiger
    @NightTiger
    Попробую и я ответить. Закон применять надо всегда, если есть возможность его применить.

    Немного лирики: та тонна бизнес-кода 20-30 разработчиков, которая прошла через меня позволила познать тот самый дзен Clean Code, не могу сказать, что у нас все везде хорошо, но за последние несколько лет мы так улучшили его общее состояние, что с ним становится приятно работать — и это передается от разработчика к разработчику, вселяя уверенность, понимание и осознание каждого участка кода.

    При чем здесь правило Деметры? Оно и дает эти возможности. Как вы думаете, почему так популярен IoC и DIC Symfony2 на его основе? Своей популярностью он как раз обязан тем, что использует неявно правило Деметры для всех создаваемых сервисов: каждый сервис в контейнере получает только свои зависимости и не лезет через них к другим, более того, сам контейнер зависимостей — отражение правила Деметры, потому что он пользуется исключительно своими методами для создания инстансов сервисов, обращению к параметрам.

    Идем дальше, слои приложения. Если кто не знает — учите мат.часть. Но если кратко, то слой данных не должен содержать бизнес-логики и взаимодействует с уровнем сервисов. Уровень сервисов содержит необходимую логику и предоставляет API наружу для контроллеров, веб-сервисов и других, но не отвечает за поддержку различных форматов запросов/ответов. Уровень контроллеров позволяет распаковывать запросы/упаковывать ответы, работая только с уровнем сервисов, не делая никаких предположений об источнике данных. Где здесь правило Деметры? Ответ очевиден: везде. Если мы соблюдаем это правило, то мы можем независимо менять реализацию кажого из слоев, не волнуясь о том, что сломается что-то в слое, который мы не трогаем сейчас.

    Следующий пункт: уровень детализации участка кода. Если вы проводили ревью кода, то как часто вам приходилось думать о том, что делает конкретный участок кода с этой цепью вызовов внутри? Есть простой факт, что мы можем держать в голове эффективно около 7 объектов, когда идет ревью кода, то каждый уровень цепочки обязует загрузить себе в память лишний класс, потому что только так вы поймете что происходит в конечном счете. Проведем легкую арифметику: если у нас есть класс, он же сервис, в который инжектятся три других сервиса, то у нас пока в памяти 4 сущности, которые мы легко понимаем. Дальше идет вызов метода с аргументами, если этот метод принимает три параметра и работает только с прямыми зависимостями на один уровень, то все хорошо: 7 объектов, но все еще понятно, как оно работает. Но как только начинаются запросы вида $this->service->createResult($request)->translate($mapping); приходится материться, так как такой код не помещается со всеми зависимостями в наше ОЗУ — мозг эффективно. Отсюда вывод — каждый участок кода отвечает за свой уровень детализации, позволяя более низким сервисам раскрывать детали. Если мне понадобятся детали — я дойду до них, но они не должны мне мешать понимать текущий код уровнем выше, а для этого надо вызывать только свои соседей, делегируя детали все ниже и ниже.

    Надеюсь, мои мысли подтолкнут вас к добрым намерениями )
    Ответ написан
    2 комментария
  • Закон Деметры. Нужен ли?

    everzet
    @everzet
    Допустим вы хотите купить молоко:

    дом->лестница->машина_Opel->магазин->кассир_Люба->купить_молоко();

    Так как вы уважающий себя software developer который не видит смысла в законе Деметры, вы это скорее всего напишете в 10 разных местах системы.

    2 недели назад вы продали свой Opel и купили BMW. Вы теперь должны в 10 разных местах поменять код на:

    дом->лестница->машина_BMW->магазин->кассир_Люба->купить_молоко();

    Теперь, допустим вы начали переживать об экологии и хотите ездить за молоком не на машине, а на велосипеде. Вы теперь должны в 10 разных местах поменять код на:

    дом->лестница->велосипед->магазин->кассир_Люба->купить_молоко();

    Через пару дней Любу уволили и на работу взяли нового кассира Клаву? Меняем в 10 разных местах код на:

    дом->лестница->велосипед->магазин->кассир_Клава->купить_молоко();

    Через другую пару дней в вашем доме поставили лифт и вы не хотите бегать по лестнице за молоком? Меняем в 10 разных местах код на:

    дом->лифт->велосипед->магазин->кассир_Клава->купить_молоко();

    Мораль: этих всех замен можно мыло бы избежать, если бы для покупки молока вы использовали абстракцию:

    магазин->купить_молоко();
    Ответ написан
    8 комментариев
  • Когда в PHP использовать интерфейсы, а когда абстрактные классы?

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

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

    соответственно нужно учитывать, что при добавлении новой сигнатуры метода в интерфейс, его придется реализовать во всех классах, которые используют данный интерфейс. в абстрактном классе можно реализовать общее поведение по умолчанию для дочерних классов.
    Ответ написан
    1 комментарий
  • Когда в PHP использовать интерфейсы, а когда абстрактные классы?

    Damaskus
    @Damaskus
    Интерфейс не представляет из себя некую самостоятельную сущность. Как пульт от телевизора, например.
    Ответ написан
    Комментировать
  • Когда в PHP использовать интерфейсы, а когда абстрактные классы?

    @resurection
    Я бы сказал так:
    Интерфейс — это возможность задать жёсткую семантику.
    Абстрактный класс — это возможность вынести дублирующийся код и явно это отметить в иерархии.
    Ответ написан
    Комментировать
  • Когда в PHP использовать интерфейсы, а когда абстрактные классы?

    sainnr
    @sainnr
    Как пишут умные люди (Шилдт, Троелсен) в своих умных книжках, интерфейс определяет функциональные возможности, поведение — «что именно следует делать, но не как это делать» (Г.Шилдт, Полное руководство C#). В абстрактном классе «определяется лишь самая общая форма для всех его производных классов, а наполнение ее деталями предоставляется каждому из этих классов» (там же).

    Простой пример, в контексте графического редактора можно определить:
    Абстрактный класс — Figure (геометрическая фигура), от него могут быть образованы классы конкретных фигур — например, Rectangle, Circle и т.д.
    Интерфейс — Drawable (то, что можно нарисовать). Он может быть реализован как во всех классах конкретных фигур (Circle, Rectangle), так и в других классах, не образованных от абстрактного Figure.
    Ответ написан
    Комментировать
  • Когда в PHP использовать интерфейсы, а когда абстрактные классы?

    @Ano
    Интерфейсы надо использовать, когда классы, которые должны предоставлять один и тот же интерфейс, не должны быть (или не могут быть) связаны иерархически.
    Кроме того, если нужно предоставить несколько интерфейсов, а множественного наследования нет (как в PHP), то интерфейсы — единственный выход.
    Ответ написан
    1 комментарий
  • Когда в PHP использовать интерфейсы, а когда абстрактные классы?

    try4tune
    @try4tune
    С точки зрения архитектуры:

    Интерфейс описывает свойства. Обратите внимание на классические названия интерфейсов: Throwable, Countable, Comparable, Iterable и т.д. Возьмем, к примеру, интерфейс Rollable (катящийся), и Foldable (складывающийся).

    Абстрактный класс же описывает сущность. Например, стол: Table_Abstract. Стол может быть деревянным, тогда будет Table_Wood extends Table_Abstract. Также стол может быть хирургическим: Table_Surgical extends Table_Abstract. В таком случае Table_Abstract объединяет общий свойства всех столов (скажем, площадь поверхности, наличие ножек и т.п.). А конкретный класс описывает сущность определенного типа столов.

    Связью же интерфейсов и классов Вы описываете свойства. Например, стол можно катить: Table_Abstract implements Rollable. Деревянный стол, например, можно сложить: Table_Wood implements Foldable.
    Ответ написан
    5 комментариев