Задать вопрос
  • Почему 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 воспользоваться для сервиса прокладки маршрута?

    @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 комментариев
  • Когда в PHP использовать интерфейсы, а когда абстрактные классы?

    miraage
    @miraage
    Старый прогер
    К примеру, нужно написать класс для работы с кэшем.

    У нас есть класс Cache, который будет делать всю грязную работу. Он в свою очередь будет использовать библиотеку под определенный тип кэша (memcached, eaccelerator, ...). Для согласованности, библиотека должна реализовать интерфейс cacheInterface, чтобы класс Cache мог нормально работать. Вот небольшой пример.

    Интерфейс для библиотеки:
    Ответ написан
    3 комментария