Задать вопрос
  • Настройка полей в LaTeX

    @Eddy_Em
    > Пишу диплом в латексе

    BDSM? Или специально слова коверкаешь?

    А с печатью проблема именно в принтере.
    Кстати, а что будет если не pdf генерировать, а dvi (и dvi же печатать командой dvips)?
    Ответ написан
    1 комментарий
  • Есть у кого-нибудь опыт использования хостинга от host4geeks?

    AmonGeeks
    @AmonGeeks
    И, кстати, индийцы!
    Дую вонт шеирд?
    Ответ написан
    Комментировать
  • Есть у кого-нибудь опыт использования хостинга от host4geeks?

    AmonGeeks
    @AmonGeeks
    Реселлер GoDaddy.
    А что может быть хуже GoDaddy? )
    Ответ написан
    Комментировать
  • Коммерческий closed-source интерфейс к консольной утилите под лицензией LGPL?

    @PavelKrishtalskiy
    Насчет GPL посмотрите faq на сайте gnu.org: на английском и в переводе на русском.

    В частности, вы можете использовать ПО, лицензируемое по GNU, в коммерческом продукте, однако в таком случае ваше ПО должно распространяться по такой же лицензии (http://www.gnu.org/licenses/gpl-faq.ru.html#GPLCommercially):

    Если я пользуюсь программой, которая получена на условиях GNU GPL, могу ли я видоизменить первоначальный исходный текст в новую программу, а затем распространять и продавать эту новую программу за деньги?

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

    Эти требования — условия включения частей программ под GPL, которые вы получили, в свою собственную программу.


    Если вопрос состоит в том, возможно ли использовать ПО, лицензируемое по GPL, в коммерческом продукте, при этом оставляя продукт закрытым, то тут не всё однозначно.
    Во-первых, вы не можете включать GPL ПО в поставку своего продукта. Это ограничение можно обойти, дав рекомендацию конечному пользователю самостоятельно скачать и установить необходимое ПО.
    Во-вторых, вы можете использовать открытое ПО только «at arms length». Вот здесь есть пояснения на этот счет: www.gnu.org/licenses/gpl-faq.ru.html#GPLInProprietarySystem

    Мне хотелось бы включить программу, распространяемую по GPL, в свою несвободную систему. Можно мне это делать?

    Вы не можете включать программы, распространяемые по GPL, в несвободную систему. Цель GPL — предоставить каждому свободу копировать, передавать, понимать и изменять программу. Если бы вы могли включать программы, распространяемые по GPL, в несвободную систему, это привело бы к тому, что такие программы тоже стали бы несвободными.

    Система, включающая программу, распространяемую по GPL, является расширенным вариантом этой программы. В GPL сказано, что расширенная версия программы должна выпускаться под GPL, если она вообще выпускается. Это делается по двум причинам: во-первых, чтобы гарантировать, что пользователи, которые получают программу, получают свободу, которая у них должна быть, а во-вторых, чтобы поощрить людей возвращать улучшения, которые они делают.

    Однако во многих случаях вы можете распространять программы под GPL вместе со своей несвободной системой. Чтобы делать это правильно, вы должны удостовериться, что свободные и несвободные программы общаются на расстоянии вытянутой руки, что они не сочетаются настолько тесно, что это делает их фактически единой программой.

    Разница между этим и “включением” программ под GPL частично состоит в сущности, а частично — в форме взаимодействия. Часть, которая касается сущности, такова: если две программы сочетаются так, что фактически становятся двумя частями одной программы, то вы не можете рассматривать их как раздельные программы. Таким образом, GPL должна распространяться на все это.

    Если две программы остаются как следует разделенными, как компилятор и ядро или как редактор и командный интерпретатор, то вы можете относиться к ним как к двум раздельным программам — но вы должны делать это соответствующим образом. Здесь дело просто в форме: как вы описываете то, что вы делаете. Почему для нас это не безразлично? Потому что мы хотим гарантировать, что пользователи ясно осознают свободный статус программ под GPL в сборнике.

    Если бы люди собирались распространять программы под GPL, называя их “частью” системы, о которой пользователи знают, что она частично несвободна, то у пользователей могла бы возникнуть неуверенность в своих правах по отношению к программам под GPL. Но если они будут знать, что то, что они получили — это свободная программа плюс другая программа, бок о бок, то их права будут ясны.


    LGPL не такая вирусная, как GPL, и с ней ситуация проще: вы можете использовать такое ПО при условии, что вы линукете свой продукт с открытым ПО (http://ru.wikipedia.org/wiki/GNU_Lesser_General_Public_License):

    GNU LGPL позволяет линковать с данной библиотекой или программой программы под любой лицензией, несовместимой с GNU GPL, при условии, что такая программа не является производной от объекта, распространяемого под (L)GPL, кроме как путём линкования.

    Главное различие между GPL и LGPL в том, что последняя позволяет и такое линкование с данным объектом других, которое создаёт производную от данного работу, если лицензия слинкованных объектов позволяет «модификации для внутреннего использования потребителем и обратную разработку для отладки таких модификаций».


    На всякий случай добавлю, что это всё моё имхо, основанное на изучении FAQов и форумов в сети. В любом случае, ссылки я выше привел, уверен, ответ вы там найдете :)
    Ответ написан
    3 комментария
  • Коммерческий closed-source интерфейс к консольной утилите под лицензией LGPL?

    script88
    @script88
    По поводу GPL отвечу: саму утилиту в поставку в ключать нельзя. это нарушение.
    P.S. что может получится из этого :)
    www.opennet.ru/opennews/art.shtml?num=34854
    Ответ написан
    3 комментария
  • Яндекс.Деньги — оспаривание переводов

    Tenkoff
    @Tenkoff Автор вопроса
    Сценарий!
    Мерем много много яд счетов, которые пока еще безстрашные люди не перевели на про аккаунт и не скрыли от глаз любого на своих говнобложиках и сайтах магазинчиках.
    Шлем каждому 10 рублей.
    Ждем пару дней.
    Опротестовываем все.
    Ждем шквал говна в сторону яндекса.

    p.s. мне вот и нафиг ненадо и лень этим заниматься, а ведь кто-то же не обломается однажды
    Ответ написан
    Комментировать
  • Как правильно спроектировать протокол обмена данными между клиентом и веб-сервисом?

    karenishe
    @karenishe
    Исходя из моего опыта, порядок действий должен быть такой:
    1. Попробовать разные API как «юзер» (facebook, twitter, vkontakte, soundcloud, youtube);
    2. Понять, что нравится, а что нет (опять же, как «юзеру»);
    3. Делать свой API исходя из первых двух пунктов.

    На мой взгляд, необходимо придерживаться идеологии REST (с возможностью обходиться и без нее), а по форматам допускать как xml, так и json.
    Ответ написан
    Комментировать
  • Как правильно спроектировать протокол обмена данными между клиентом и веб-сервисом?

    charon
    @charon
    сам сталкивался с такой задачей — она не так уж и проста. С большинством советов выше я согласен.
    1) Используйте json-encode — очень распространённое и проверенное решение. Значительно проще xml.
    2) Разделение типов запросов на HTTP-методы GET, POST, PUT, DELETE лучше не делать, хотя это и правильно. Ограничьтесь GET и POST. Это связано с тем, что многие клиенты не смогут использовать тот же DELETE — ну вот хотя бы флэш.
    3) Сразу предусмотрите версии вашего API. То есть в запросе обязательно должен быть параметр типа v=1. В будущем это вам очень пригодится.
    Ответ написан
    2 комментария
  • Как правильно спроектировать протокол обмена данными между клиентом и веб-сервисом?

    @MikhailEdoshin
    Часто выбор формата делают либо через «расширение файла» (domain.com/method.xml vs method.json), либо через HTTP-заголовок Accept.
    Ответ написан
    Комментировать
  • Как правильно спроектировать протокол обмена данными между клиентом и веб-сервисом?

    vanxant
    @vanxant
    Во-первых, забудьте про XML, его придумали бюрократы. Вот пусть они его и используют в своих банках и налоговых. Для парсинга и кодирования JSON достаточно пары функций по 10 строк каждая. Для парсинга XML, даже если в нем пару значений, нужно подгружать монструозные библиотеки.

    Во-вторых, раз уж вы делаете веб-приложение, используйте возможности протокола HTTP. Это значит идеология REST, а не RPC. То есть вместо каких-то там «процедур» или «функций», вы пляшете от объектов и стандартных действий.
    Например, у вас есть объект с идентификатором obj_id. Для любого доступа к нему используется URL вида

    example.com/path/to/obj_id

    Далее по этому URL-у возможны 4 действия (http verb):
    GET example.com/path/to/obj_id — получить данные объекта
    PUT example.com/path/to/obj_id — изменить объект
    DELETE example.com/path/to/obj_id — удалить объект
    POST example.com/path/to/ — создать новый объект в папке /path/to
    GET example.com/path/to/ — получить все объекты в папке /path/to

    В зависимости от результата операции, вы должны возвращать правильные коды ошибок (200 OK, 404 Not Found, 403 Forbidden и т.п.).

    Параметры более сложных запросов идут как get-параметры, ну например
    GET example.com/path/to/?search=blabla
    — искать объекты
    Или можно часть параметров перенести в урл:
    GET example.com/my/report/01.01.2011-31.12.2011/
    Ответ написан
    4 комментария
  • Как правильно спроектировать протокол обмена данными между клиентом и веб-сервисом?

    @AlexNomad
    XML все-таки тормознутее.
    Я в похожей ситуации выбрал JSON из-за его скорости.
    Нужно оценить везде ли вы сможете применять JSON.
    Если нет, то иных вариантов кроме XML нет.
    Ответ написан
    2 комментария
  • Как правильно спроектировать протокол обмена данными между клиентом и веб-сервисом?

    @Fortop
    Tech/Team lead
    Я бы предложил не изобретать велосипед, а воспользоваться RPC/SOAP
    Ответ написан
    8 комментариев
  • Как правильно спроектировать протокол обмена данными между клиентом и веб-сервисом?

    @Moxa
    добавьте параметр format к запросу и, в зависимости от его значения, отдавайте json/xml/csv…
    Ответ написан
    3 комментария
  • Материалы по MVC и MVVM?

    @egorinsk
    Во-первых, вы вряд ли поймете, что такое MVC, не написав что-нибудь с его ипользованием, или хотя бы не поковырявшись в кем-то написанном коде.

    Во-вторых, с MVC как с ООП — выгоду использования этого паттерна можно увидеть только на среднем или крупном проекте. То есть, если вы, к примеру, пишете веб-приложение-блог или десктопное приложение с единственной формой с 3 кнопками, и попытаетесь использовать MVC и ООП (и вы начинающий разработчик), у вас возникнут вопросы, а зачем это вообще надо? Неужели нельзя по-простому сделать?

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

    Тогда-то и становится понятно, зачем (были) нужны пространства имен, инкапсуляция, разделение логики управления/хранения данных/обработки данных/отображения данных, почему яваскрипт должен быть в отдельных файлах, зачем придумали DI/MVC/ORM/DSL/Object factory/Observer pattern и прочие популярные аббревиатуры.
    Ответ написан
    1 комментарий
  • Материалы по MVC и MVVM?

    gouranga
    @gouranga
    Advanced MVVM от Джоша Смита, весьма не плохо написано.
    Ответ написан
    Комментировать
  • Материалы по MVC и MVVM?

    taliban
    @taliban
    php программист
    ru.wikipedia.org/wiki/Model-View-Controller#.D0.A1.D1.81.D1.8B.D0.BB.D0.BA.D0.B8
    ru.wikipedia.org/wiki/MVVM#.D0.A1.D1.81.D1.8B.D0.BB.D0.BA.D0.B8

    Вообще это очень простые паттерны, но у них есть один недостаток — популярность. Именно из-за него реализаций этих паттернов очень много, и каждый говорит и расскаызвает по своему, поэтому запутаться можно, особенно в начале.
    Ответ написан
    Комментировать
  • Tornado.database асинхронный или нет?

    StraNNikk
    @StraNNikk Автор вопроса
    Проблема решена, вот что ответили на stackoverflow.com:
    stackoverflow.com/questions/9800483/is-tornado-database-asynchronous-or-not

    tornado.database и правда не асинхронна — эта прослойка делалась специально под нужды FriendFeed, и ребята из Tornado решили, что в рамках этого проекта ограничатся простыми и быстрыми запросами, и не стали делать асинхронность для tornado.database
    Ответ написан
    Комментировать