• Федеральный судья США: ретвитишь, репостишь? Готовься быть нарушителем авторских прав
    0
    А по этому закону, все поисковые результаты должны быть скрыты. Хотя я поддерживаю эту политику в отношении корпораций. А то получается, у маленьких людей куча проблем из-за одной картинки, просто потому, что денег на адвоката нет. А «поисковые» корпорации воруют петабайтами и ничего. Вот если б законодательно закрепить коммерческое/некоммерческое использование для любых материалов, а еще лучше для поддержки малого бизнеса оценивать полученную выгоду и тоже разрешить, но кто ж такое пролоббирует…
  • Понять Биткойн и будущее. Как то, что вы знаете, будет переосмыслено навсегда
    –4
    Ваша «капитализация» учитывает более 50% потерянных биткоинов, которые нагенерировал Сатоши Накамото, а также первые майнеры. Другая часть биткоинов — хранится на холодных кошельках, и не торгуется нигде на биржах.

    Я не называл конкретных цифр, только порядки. График с одной биржи — не аргумент. Приведите объемы торгов всех бирж за выбранный период.

  • Понять Биткойн и будущее. Как то, что вы знаете, будет переосмыслено навсегда
    –2
    Посмотрите капитализацию биткоина, прежде, чем говорить о 20$ млн, которые что-то могут надуть.
    В целом, история с Tether еще не закончилась, но какие-то сомнительные телодвижения и правда имеют место быть, судя по новостям.
  • Nemesida Scanner — сканер уязвимостей веб-приложений
    0
    А в докер засунуть не возможно?
  • Nemesida Scanner — сканер уязвимостей веб-приложений
    0
    nemesida-security.com/ns/keys/auth_api

    502 Bad Gateway

    Can't connect to Nemesida Scanner API (https://nemesida-security.com/ns/keys/auth_api)
  • Сравнение REST и GraphQL
    0
    Было бы намного практичнее, если бы вы привели пример API, реализованного на GraphQL и документации к нему.

    Я привел пример https://developer.github.com/v4/, ну и https://developer.github.com/v3/
    Гитхаб шли по абсолютно тому же пути, придумывали способы описать запрашиваемые поля, а когда вышла спека GraphQL просто заюзали его.
    По поводу дыр в безопасности — насколько я понимаю на GraphQL довольно сложно реализовать систему ролей пользователей, т.к. существует почти бесконечное множество возможных запросов.

    Нет, это не так, теоретически запросов бесконечное множество, но только благодаря «бесконечной» вложенности. Но из-за строгой типизации любые мета-вопросы, будь то документация, или права доступа, решаются на уровне конкретного типа, а не запроса. GraphQL одновременно и достаточно кастомизируемые запросы и ограниченные типами. И вы правы, не было хотя бы одной составляющей, был бы другой разговор

    posts { comments { posts } } }

    Где, posts Array Of Post, а на Post свои права доступа, а на вложенный Post те же самые права доступа и та же самая документация.

    Но опять же, GraphQL абсолютно не заставляет вас быть настолько гибкими, пожалуйста. реализуйте свои явные точки входа, тогда в виде бонуса будет удобный синтаксис и уменьшенный размер пакета из-за выбора полей.
  • Сравнение REST и GraphQL
    0
    http://facebook.github.io/graphql/#sec-General-Principles
  • Сравнение REST и GraphQL
    0
    Если так, то это не сильно отличается от какого-то простого HTTP/WEB API, и отличие только в том, что в ответ приходит ограниченный набор данных.

    Так GraphQL и есть язык, т.е. синтаксис, не знаю откуда столько мнений, что это какое-то серверное решение. Видимо, желание иметь серебряную пулю затмевает глаза.
  • Сравнение REST и GraphQL
    0
    Зависит от вашей СУБД, в общем случае, смотря, что выгоднее, так же, как и всегда.
    2. делать «оптимизацию», то получим 1 большой запрос и в маппинге просто результаты будем разгребать.
    но в этом случае будет сложный запрос как в случае с комментами, так и без них. Это тоже плохо.

    Если это для вас плохо, а предыдущий вариант, например, медленный, просто не закладывайте в схему GraphQL таких возможностей. Опять же, GraphQL тут не причем, разделение нагрузки между клиентом и сервером задача каждого проекта.
    3. делать «по-умному»,

    Опять же, зависит от схемы, в данном случае схема может плясать от бэкенда, пойти по пути Rails и сделать автоматическую схему из моделей, со всеми методами (createModel1, updateModel1, deleteModel1), универсальными фильтрами (примерно, как в Mongo posts (filter:{ nameLike: «name» }) ), но с иерархической вложенностью. Такая схема не потребует для поддержки ни строчки кода. Только кастомные запросы, типа авторизации, остальное все автоматически, знай, модели добавляй. Тут пока готовых качественных решений нет, однако биндинги ко многим ORM уже существуют.
  • Сравнение REST и GraphQL
    0
    Хабр читают 10 млн человек, демагогию и троллинг нужно изобличать в явном виде.
  • Сравнение REST и GraphQL
    0
    Боже, причем тут HTTP? Как он поможет вам выбрать поля?
    GraphQL приводит к переизобретению REST, позволяя откладывать проектирование ограничений эндпоинтов «на потом».

    «На потом» — это в вашей голове.
    Для тех, кто не осилил REST/HTTP

    Боже…
    всё эти коды ошибок, непонятные заголовки, понятия идемпотентности и прочая ересь

    Ну прям очень сложно, бедные facebook-архитекторы… А идемпотетность вообще только в мечтах и демагогических высказываниях, когда по сути сказать нечего.
    «Мне нужно просто выполнить действие на сервере! Зачем мне отдельный ресурс?»

    Ну да, давайте спор функциональщина/ООП головного мозга ввернем, чо уж там. И да, не хочу я все называть существительными, назовите это «ниасилил» или порогом вхождения, обычно, это называют здравым смыслом. Это в REST пытаются делать все ресурсами, просто подогнать под удобный, элементарный формат, никакого отношения к реальному миру и языку это не имеет, просто 90% случаев выгоднее, чем 10%.
    Вашу точку зрения я понял, вместо аргументов по теме, оскорбления в адрес собеседника, удачи.
  • Сравнение REST и GraphQL
    0
    Т.е. изобрести свой GraphQL, без спецификации, готовых решений и т.д. Можно, наверное, все это делали.
  • Сравнение REST и GraphQL
    0
    Откуда берется идея, что фронтенд что-то диктует? GraphQL абсолютно не об этом, это всего лишь формат передачи данных, все остальное, и вложенность, и сложность, и известность всех таблиц — решается индивидуально! Не выдумывайте проблемы там, где их нет.
    Еще раз, нет никаких проблем в анализе запроса, смотрим, требуется ли клиенту поле «дерево комментариев» и если да, джойним что надо (в вашем случае, запрашиваем второй endpoint, вместо первого). Рассматривайте GraphQL, как возможность не плодя сущности в языке запроса делать то же самое. Т.е. вместо множества endpoint'ов posts и postsWithComments и postsWithAuthors есть
    posts и posts { comments } и posts{ authors }.
    И маппинг нужен только в случае, если у вас уже есть написанный сервер с готовыми обработчиками запросов для REST. Если пишете сервер для GraphQL с нуля — все эти вопросы уже заложены в архитектуру, вплоть до выбора БД. Уже есть и готовые облачные решения, правда не от крупных вендоров, ждем и их. Parse с поддержкой GraphQL — было бы вообще идеально.
  • Сравнение REST и GraphQL
    0
    GraphQL — ради одной точки входа создаём себе кучу проблем вроде непредсказуемого API c потенциальными дырами в безопасности

    Никто не мешает в GraphQL реализовать ресурсы в точность так же для CRUD. Откуда берется непредсказуемость и дыры — не ясно, посмотрите примеры, github, например.
    Можете даже root-объекты назвать по привычке GET DELETE PUT POST
    query{
    GET {
    post(id:1){
    title
    }
    }
    }
  • Сравнение REST и GraphQL
    0
    Все верно, GraphQL — логичное развитие не только REST, но и многих других (и OData и RPC). Здесь есть один нюанс, что промежуточного состояния как бы нет, но за счет графовой структуры мы можем состояние как бы «засунуть» на вершину, а потом по ребрам передать. А сейчас то же самое с последовательными запросами (batch) в рамках одного.
    Главное отличие — велосипед написан, он вполне адекватен, выполняет все, что декларирует, зафиксирован, есть поддержка крупного вендора. Ну и удобный синтаксис, наверное, главное.
  • Сравнение REST и GraphQL
    0
    На самом деле, нет. Фильтрация, группировка и сортировка обычно происходит на верхнем уровне запроса, остальные джойны — по уже выбранным айди. А здесь уже проблем не так много, во-первых, даже дополнительные запросы будут очень легковесны, во-вторых, чаще всего бэкенд, это не просто выборка из реляционной БД и многие вещи лежат в кэше. Это из простых вариантов. А вообще, есть и поинтереснее решение, хотя оно применяются и в любой другой парадигме — это динамический бэкенд, это статистика запросов, на основе которой, определенные джойны выполняются заранее для определенных моделей.
    Да и тема слишком узка, для малых проектов, все это не важно, для крупных, там все равно кэширующие решения будут сложнее, чем джойны.

    Дальше, никто не мешает, в конце концов, обрабатывать на сервере запрос, как единый и знать, какие джойны понадобятся, текущие популярные реализации в виде иерархических подзапросов — всего лишь один из вариантов. Можно маппить весь запрос на SQL, можно хотя бы вычислять джойны, что угодно.
    Потому, что GraphQL не про сервер, а про декларативное представление куска данных, но с описанными типами.
  • Сравнение REST и GraphQL
    0
    GraphQL себя так не позиционирует, откройте документацию http://graphql.org/:
    Ask for what you need, get exactly that

    Точность получаемых данных, т.е. выбор только нужных полей, с точностью до одного.
    Get many resources in a single request

    Представление сложной выборки с помощью одного запроса, с добавлением batch можно получить реально ВСЕ, что нужно одним запросом.
    Describe what’s possible with a type system

    Строгая типизация запроса, фишка именно в том, что типы включены в спецификацию!

    Все сказки про backend — лишь сказки, GraphQL не решает проблем на сервере, но и не создает их, попробуйте и увидите, что ничего не меняется в этом плане. А вот клиент-серверное взаимодействие становится на порядок удобнее. Ну, пока инструменты еще не все готовы, но даже уже с тем, что есть. А уж возможностей понаписать удобств из-за типизации и глубокой интроспекции — сколько угодно, вопрос времени.
  • Белые списки. Хорошее начало — половина дела
    +1
    Если кто не понял, основная задача сейчас — закрыть провайдеров, они же не смогут выполнять эти законы. А когда останется 4 «государственных» — все будет проще.
  • О роли интерфейсов в контексте экзистенциализма
    0
    У человека нет роли быть универсальным, а вот для дизайна глобальных проектов это большая проблема, в итоге все сводится к минимализму, там где для каждой конкретной группы могло бы быть чудом. Причем корпорации опять совершают эту же ошибку наделяя единым именем помощников — Сири не может быть прекрасной для всех, сухая, черствая, бездушная тварь, вот идеальный дизайн для миллиардов.
  • Что же такое RQL
    +1
    Речь о том, что в GraphQL нет ничего громоздкого, скорее наборот, это один из самых минималистичных способов записи запроса данных (или представления данных). Мультидревовидная структура с поддержкой функций и директив покрывает большинство сценариев, как показали дальнейшие исследования, не хватает только последовательных запросов (batching), что легко решается.
    https://dev-blog.apollodata.com/new-features-in-graphql-batch-defer-stream-live-and-subscribe-7585d0c28b07
  • Два аспекта «децентрализованных» одностраничных приложений
    0
    > Однако, сервер оказался просто необходим для реализации следующих возможностей:

    Возможности эти можно реализовать и без сервера, правда соединение клиентов будет происходить, в большинстве случаев, медленнее. Вот только что про ZeroNet писали, например.
  • ZeroNet — По настоящему распределенная сеть: Социальная сеть,Wiki движок (изменения за полгода)
    0
    Ага, уже думали .
    Слишком много в браузере ограничений.
  • ZeroNet — По настоящему распределенная сеть: Социальная сеть,Wiki движок (изменения за полгода)
    0
    Интересно, нельзя ли написать клиент для браузера, используя WebRTC, тогда и шлюзы будут не нужны?
  • ZeroNet — По настоящему распределенная сеть: Социальная сеть,Wiki движок (изменения за полгода)
    0
    Есть контакт http://127.0.0.1:43110/1CU5AzDDXdt8L6wcWyfRC8zkSKPkMBFLK1
  • Тестирование в React
    +2
    > Грубо говоря, первый раз вы запускаете тест, чтобы сформировать такой слепок, проверяете его валидность руками и коммитите его в репозиторий кода.

    Не знаю, как у других, но мы столкнулись с тем, что люди не особо тщательно проверяют такие слепки, в итоге некорректные тесты.
    Вообще получается какая-то инверсия, тест должен проверить что код написан верно, а по факту код и является автоматически сформированным доказательством.
    В итоге, пока отношусь к слепкам скептически и осторожно.
  • Опаньки, я сломал вашу жизнь
    +1
    > На момент написания кода об этой ошибке было не известно.
    Именно поэтому невозможно подстелить солому, как вы хотите, т.е. рассказать что произошло, кроме как технических логов.
    > А абракадабра, зачастую, не понятна и самим программистам
    Причем тут создатели программы, они могут логгировать эти ошибки без показа их пользователям.
    > Падает через пару минут после загрузки. Никаких подсказок не даёт, почему именно на моей системе она падает.
    Не думаю, что куча чужих бектрейсов поможет 9999999 пользователей из 1000000. А последний потратит месяц или отправит багрепорт? И в GeForce (как и в большинстве программ) есть отправка логов.
  • Голуби брутфорсят парадокс Монти Холла лучше людей
    0
    Я думаю, гораздо больше интересного можно получить от психологии и ведущего, чем от математики в данном случае. Так что да, очевидно, я бы занимался его просчетом, а не дверей. Как, впрочем, и большинство.
  • Голуби брутфорсят парадокс Монти Холла лучше людей
    0
    Это в математике оптимальное решение, а не на шоу. Там нет случайности, равномерного распределения и т.д. Все это работает на больших числах, а в шоу единичные случаи.
  • Голуби брутфорсят парадокс Монти Холла лучше людей
    –4
    Почему для первой двери вероятность не изменилась? Почему переходит полностью на оставшуюся? По-моему переходящая вероятность как раз таки делится на выбранную вначале дверь и оставшуюся?
  • Node.js 7.0.0 зарелизился. Встречайте async/await без babel
    0
    Потому что, по сути, это единственный путь рождения и проверки немертворожденных стандартов. А по поводу поддержки, это не обязательно, можно объявить deprecated. Поэтому и запускается не в LTS-версии.
  • 42 строки кода для выхода из лимба
    0
    Ну да, но для получения подробной информации о каждом элементе стека, нужно заменить Error.prepareStackTrace на свою функцию, иначе тут будет уже конкатенированная строка.
  • Серия интерфейсных обновлений «Хабрахабра» и Geektimes
    +2
    А нельзя шапку прикрепить, все равно ведь читаешь посередине экрана? А так быстрый доступ к меню…
  • Министр образования пообещала вернуть астрономию в школьную программу
    +2
    Ну вот, как теперь быть НАСА, их астрологический троллинг пропадет всуе.
  • Жаргон функционального программирования
    0
    Думаю, речь об этом абзаце
    Но тут у вас возникает задача сделать так, чтобы функция fun2, работающая со значениями типа Int, тоже могла работать со значениями Optional Int. И чтобы функция fun3 тоже так могла работать. И fun15. И вот вы пишете функции fun2Optional, fun3Optional… fun15Optional… Можете? Конечно, почему нет?

    Это называется подтасовка, нет, я буду интуитивно использовать функтор, но не знать его определения. Мало того, использовать его или нет зависит от моих умственных способностей, а не от прочитанной книжки. Так что, в одиночку, формулировки не нужны. Вот для совместного программирования (> 1) помогают да, как и любые другие слова.
  • React.js: собираем с нуля изоморфное / универсальное приложение. Часть 2: добавляем bootstrap, страницы и роутинг
    0
    Размер сборки увеличивается. Но главное, что создается бессмысленный God-object в исходном коде. А конкретно main-файл, в котором будет либо 1000 строчек, либо:
    export Grid  from './lib/Grid'
    

    Расскажите, какой вы видите в этом смысл?
  • React.js: собираем с нуля изоморфное / универсальное приложение. Часть 2: добавляем bootstrap, страницы и роутинг
    +1
    Занимается, но не путайте мягкое с теплым. Одно дело — максимально уменьшить размер bundle, там где архитектура пострадала (не разнесли модули по файлам). Другое дело — специально делать плохую архитектуру.
  • Полное практическое руководство по Docker: с нуля до кластера на AWS
    0
    Скорее всего, вы упускаете docker logs и docker attach.
  • Блокировка на Habrahabr или Geektimes
    0
    мне просто лет 7 назад дали пару ссылок на интересные статьи по электронике.

    Которые тоже случайно оказались здесь, как и большинство крутых IT-статей рунета. А разве мало других открытых форумов, с гораздее менее строгими правилами?
  • Блокировка на Habrahabr или Geektimes
    0
    Контент к карме никакого отношения не имеет,

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

    Фраза конечно оригинальная) Но контент и деньги не слова-синонимы. Контент — это капитал на дальнюю дистанцию, когда заходит новый человек и видит тут кроме желтой прессы в разделе «Лучшее» тысячи отличных статей. К тому же, если вы про geektimes, то тут скорее всего влияние кармы не такое сильное и правда, потому что geektimes не профессиональный ресурс, а развлекательный. Но это еще не доказано, так как слишком мало времени прошло.
  • Блокировка на Habrahabr или Geektimes
    0
    Про приоритет кармы речь не идет, зато про приоритет контента еще как идет, и для этого используются все возможные инструменты, в том числе и карма и рейтинг. Даже за последнее время была куча изменений, это говорит о том, что администрация очень даже задумывается над кармой, а какое влияние на контент и соответственно в каком она месте по приоритету, тут нужна инсайдерская информация.