• Leaflet 1.x.x vs Openlayers 4.x.x. Часть 2. Как рисуются карты
    0
    Хм, правда? Я понимаю, что задачи разные бывают, но как по мне — это был бы почти блокер. Это ведь означает, что без сервера вы работать не можете. При этом работа без сервера с малыми нагрузками вполне воможна.


    Обычно все популярные открытые тайловые сервисы (OSM и тд) поддерживают cross-origin, а если вы используете какой-то сервис без него, то скорее всего можно нарушить соглашение об использовании, если это ваш сервис, то просто включите на нем cross-origin.

    По поводу SVG, если вы именно хотите загрузить вектор из SVG, то оба фреймворка умеют делать и слои и маркеры из SVG, честно говоря, анимацию проверить не удалось. Leaflet'овые плагины вроде используют родной SVG браузера, а вот OL да, рисует на canvas.
  • Leaflet 1.x.x vs Openlayers 4.x.x. Часть 2. Как рисуются карты
    0
    Да, это как раз один из примеров, автор второго плагина должен был делать расширение к L.TileLayer, а не городить потомка. Что-то типа:
    L.TileLayer.prototype.makeGrayScale = function() {...}
    
  • Социнжиниринг в военной пропаганде
    +2
    Немножко не так, результат будет. Возможно тут не говорится про вариант равного противостояния, или когда идет позиционная война. Вот так вот из своего окопа солдат вряд ли пойдет к противнику. А когда например группу солдат окружили, они отрезаны от своих, так еще и считают например, что их бросили, такие листовочки сыграют свою роль.
  • EntityFramework: (анти)паттерн Repository
    +3
    Поддерживаю вашу борьбу с Repository, при живом EF в проекте. Но вот Specification по-моему, это оверхед, да еще и с переопределением операторов.
  • Стоимость недвижимости на тепловых картах
    0
    В геосервере тоже есть тепловые карты из коробки, почему его не попробовали?
  • Кластеризация маркеров на карте Google Maps API
    0
    Нет, я не говорю, что все должно быть в redux. Просто я вот занимаюсь ГИСами и у меня то, что отображается на карте и есть основная бизнес-логика, а не «изменились какие-то маркеры». Вот мне и интересно было, когда автор сказал про стек react/redux, как он работает со сложными картографическими компонентами, с которыми все общение обычно построено на функциях и событиях, и следование redux при работе с этими компонентами рождает гигантский оверхед. Мои исследовании в итоге привели меня к тому же варианту, который описал автор — чистый react без redux/mobx.
  • Кластеризация маркеров на карте Google Maps API
    0
    Ну, на демке вполне себе SPA )). Мне просто интересно, большинство людей, когда используют сложные компоненты типа картографических фреймворков в связке react/redux, забивают на принципы redux.
  • Кластеризация маркеров на карте Google Maps API
    0
    Я занимаюсь разработкой SPA приложения на стеке react/redux для модерации контента, присылаемого пользователями.


    С реактом понятно, а где redux? Чего это у вас напрямую работа со стейтом?
  • Leaflet 1.x.x vs Openlayers 4.x.x. Часть 1. Исходный код
    +1
    Ну это пока вы в «мейнстриме» держитесь, а как только шаг вправо, шаг влево, начинаются нюансы. Возьмите коническую проекцию, да разных плагинов, которые друг с другом не работают, вот тут Леафлет бибикая уезжает в кювет, но об этом в следующий раз. Так что, не все так однозначно.
  • Leaflet 1.x.x vs Openlayers 4.x.x. Часть 1. Исходный код
    0
    Согласен с вами, но последующие 2 статьи про плагины, фишки и выводы будут объемней, а моя лень затянет написание такой длинной статьи на бесконечное время. Поэтому решил подробить. Сейчас думаю: может еще рассказать как рендеры у них работают.
  • Leaflet 1.x.x vs Openlayers 4.x.x. Часть 1. Исходный код
    0
    Под словом «приватные», я больше имел ввиду не публичные.
    Простой пример по коду Leaflet.
    Есть класс Layer, у него есть свойство _map, судя по "_" оно не публичное.
    Есть класс наследник — LayerGroup, он использует свойство this._map от потомка. Т.е. по сути своей оно защищенное (protected), объявлено как приватное, но фактически оно публичное, т.к. к нему можно обратится извне.
  • Leaflet 1.x.x vs Openlayers 4.x.x. Часть 1. Исходный код
    0
    Вот вы-то мне и нужны ))) Может быть я что-то не понимаю, вам вопрос: могу ли я нормально наследоваться с доступом к членам protected и абстрактным классам, если код уже собран? и работаю я с ним уже после Closure Compiler.
  • Leaflet 1.x.x vs Openlayers 4.x.x. Часть 1. Исходный код
    0
    Из потомков нельзя достучаться даже до членов классов которые помечены как protected, т.е. предполагается доступ к ним.
  • Leaflet 1.x.x vs Openlayers 4.x.x. Часть 1. Исходный код
    +1
    В рамках обычных ООП-шных языков вы будете правы. Но в JS технически все члены класса публичные, и разделение их на приватные, защищенные и публичные условно. В OL у некоторых свойств ( в комментах к ним для jsdoc) стоит модификатор protected — т.е. доступ из потомков предполагается. Я не говорю здесь про доступ из других классов к приватным методам и свойствам, я говорю про доступ из потомков.
  • 40 необычных вопросов, задаваемых на собеседовании в Apple
    +5
    «Если у вас есть 2 яйца, и вы собираетесь выяснить, с какого максимального этажа здания вы можете бросить яйцо, не разбив его, как вы это сделаете? Предложите оптимальное решение»


    В mail.ru на собеседовании яйца заменили на бутылки водки.
  • Переход с ASP.NET на Angular2 с особенностями (личный опыт)
    0
    В продакшене web api и view обычно разделяют, объясню:
    1. Часто разные люди отвечают за backend и front, соответственно удобно когда репозитории разделены, например ветвление по новым фичам, новому дизайну и тд в Git.
    2. Методы доставки и развертывания тоже разные, если backом обычно все сложно ( миграции, настройки, тестовые контуры и тд), то front достаточно доставить на сервер раздающий статику ( кстати он может быть отличен от сервера где сидит web api)
    3. Ну и в принципе смешивать настройки intellisense, сборки и тестирования клиента и сервера в одном workspace как-то не очень. Как вариант: хотя бы выделить клиент в отдельную папку в коде сервера.
  • Переход с ASP.NET на Angular2 с особенностями (личный опыт)
    –1
    Пункт «еще предстоит сделать» я бы немного поправил:

    1. Убрать закомментированный код.
    2. Добавить в gitignore файлы, которые генерируются.
    3. Все остальное…
  • Дзен не позвонит
    0
    Почему нет варианта «использую голый реакт»?
  • Квест от ЕРАМ: пять задач с собеседований по .NET
    0
    С такой логикой, будет сложно найти сотрудника.

    Ну как бы так в жизни и бывает, человек начал работать в бэк-энде банка, вряд ли он придет на геймдева куда-то еще, а если и придет, то только с понижением в ЗП пока до всего не дойдет. Ваш подход подходит для подбора человека «на вырост». Этим приходится заниматься, когда не нашел того, кого нужно сразу, и понимаешь что человечка нужно будет растить =).
    Хотя, мы делаем проще — спрашиваем прямо, что-то вроде: «как работает LINQ», или «как работает yield return» (если не джуниор, конечно).

    Вам когда ремонт в квартире надо сделать, вы рабочих тоже спрашиваете — как шуруповёрт работает?
    Понятно, что нужно знать где применять и во что это обойдется, но вопрос «как» — странный, вы еще может и на бумажке просите написать IL код, в который компилируется например yield?
  • Квест от ЕРАМ: пять задач с собеседований по .NET
    +4
    Да я стараюсь в принципе не напрягаться ))). Насчет баблсорта другой вопрос (хотя тоже спорный), все-таки это алгоритм, вы просите человека написать свое видение этого алгоритма. В обобщенном виде можно даже назвать это тестовым заданием. Здесь же человек просит соискателя поработать компилятором/рантаймом для ужасного, корявого кода. Уходить надо спокойно, без хлопаний дверьми, просто — спасибо, до свидания, я все понял. Показаться кому-то неадекватным — абсолютно не страшно, большинство людей, которые чего-то в этой жизни добились, казались кому-то неадекватными.
  • Квест от ЕРАМ: пять задач с собеседований по .NET
    +8
    И так, человек пришел на собеседование. На собеседованиях логично спрашивать задачи, которыми занимается компания. Ну т.е. пришел человек в геймдев, ему сразу там задачки на векторную алгебру там, пересечения плоскостей векторов в 3D и тд. Пришел человек в dev банка, ему сразу там вопросы про безопасность, транзакции и тд.
    Пришел человек на собеседование и видит вот ЭТО. Да еще и написано уберужасным стилем ( реально увидев такое в продакшене я бы уволил). Реакция нормального человека сказать — досвидания, я пошел.
  • Загрузка реальных ландшафтов в Unity 3D
    0
    Эх, опередили меня, тоже хотел про рельеф из SRTM написать, только с реализацией на WebGL.
  • Моя модернизация Byndyusoft.Infrastructure | DDD + CQRS + WebApi
    0
    Вот простой пример про логирование
  • Моя модернизация Byndyusoft.Infrastructure | DDD + CQRS + WebApi
    +5
    Несколько вопросов:

    1. Объясните смысл конструкции:
                catch (BusinessException be)
                {
                    return JsonError(form, be, logger);
                }
                catch (FormHandlerException fhe)
                {
                    return JsonError(form, fhe, logger);
                }
                catch (Exception e)
                {
                    return JsonError(form, e, logger);
                }
    

    Все три кэтча ведут в одно место, причем последний обобщающий, зачем?

    2. Зачем оборачивать DbContext в IUnitOfWork, он ведь и так им является, и он не привязан к конкретной реализации БД, абстракция ради абстракции?

    3. (это уже моя вкусовщина) Не думали про логирование в аспектом стиле, чтобы не загружать код логированием?

    4. Зачем использовать шаблон MVC, если приложение WebAPI?

    5. Почему не используете для клиентского кода grunt/gulp/webpack?
  • Свой веб-сервер на NodeJS, и ни единого фреймворка. Часть 1
    +3
    Если на автомате, тогда надо наоборот — везде писать const, а там где IDE будет ругаться на повторное присваивание менять на let.
  • Свой веб-сервер на NodeJS, и ни единого фреймворка. Часть 1
    0
    Почему у вас в коде почти везде с единичным присваиванием let вместо const?
  • Визуализация простой геометрии в WPF
    0
    А таблицу и не нужно искать. Просто посмотрите имплементации одного интерфейса и другого.
    public interface ICollection<T> : IEnumerable<T>, IEnumerable
    {
        int Count { get; }
        bool IsReadOnly { get; }
     
        void Add(T item);
        void Clear();
        bool Contains(T item);
        void CopyTo(T[] array, int arrayIndex);
        bool Remove(T item);
    }
    
    
    public interface IList<T> : ICollection<T>, IEnumerable<T>, IEnumerable
    {
        T this[int index] { get; set; }
     
        int IndexOf(T item);
        void Insert(int index, T item);
        void RemoveAt(int index);
    }
    


    IList наследуется от ICollection, и поддерживает все тоже самое + индексация объектов в коллекции. Т.е. если вам важен порядок объектов в коллекции используйте IList, если порядок не важен и вы нигде не обращаетесь по его индексу ( вставляете/удаляете по индексу), то используйте ICollection. Смысл в том, чтобы не использовать, то что не нужно.
  • Введение в React и Redux для бекенд-разработчиков
    +2
    Почем нет ни слова про mobX? Мы же в 2017
  • Функциональный C#
    +1
    ById тоже используем, только у нас в Code First, есть базовый абстрактный класс, от которого остальные наследуются, что-то типа:

        public abstract class Identified
        {
            public long Id { get; set; }
        }
    

    и уже ему пишем расширение:

            public static T ById<T>(this IEnumerable<T> identifies, long id)
            where T : Identified
            {
                return identifies.SingleOrDefault(c=>c.Id.Equals(id));
            }
    


    Кстати, почему у вас расширение только для IQueryable? можно сразу на IEnumerable, это может помочь дальше применять ById, но просто теперь для всех перечислений с этим типом.
  • Чтение конфигурационных файлов без проблем
    +2
    вместо
                string[] items = input.Split(';');
                List<string> result = new List<string>();
    
                result.AddRange(items);
    
                return result;
    


    может лучше
    return input.Split(';').ToList();
    
  • Больше, чем React: Почему не следует использовать ReactJS для сложных интерактивных фронтенд-проектов
    +2
    Сам подход во вью мне понравился больше ( отсутствие jsx, нет необходимости для нормальной разработки использовать еще и редюкс/мобХ ), но не понравились мне вещи, которые для серьезной долгой разработки важнее — иногда неадекватное отношение автора к пулреквестам, комментарии в коде на китайском ( что говорит о том что вью не планировал вырасти в такой серьезный проект) да и общее качество кода и его документирования. Потому выбрали реакт.
  • Больше, чем React: Почему не следует использовать ReactJS для сложных интерактивных фронтенд-проектов
    0
    Минимальным блоком для повторного использования в React является компонент (React.Component). Он более лёгкий, чем Controller и View в AngularJS

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

    Я вот не фанат реакта, но после оценки всего, что сейчас есть, выбрал именно его для создания сложного интерактивного приложения (причем это ГИС).
  • В гостях у Сбертеха: всё для работы, всё для роста. Мы чуть не остались жить
    0
    Прям для всех?
  • В гостях у Сбертеха: всё для работы, всё для роста. Мы чуть не остались жить
    0
    Что с парковкой для сотрудников?
  • Уголовный кодекс разработчика
    0
    Но заявление про функции на один экран без уточнения про руководство здравым смыслом и без учёта инструмента и задачи считаю религиозным экстремизмом.


    Пока так никто и не показал не математическую функцию больше экрана на языке высокого уровня, которую нельзя сократить.
  • Уголовный кодекс разработчика
    +2
    Господа, что-то мы уехали в какие-то литературные примеры. Дайте вариант реального кода, где реально 4 страницы кода нельзя сделать более читаемыми (а возможно даже меньше по размеру), разбив на функции. Вот мой пример, который я приводил ниже. Я утверждаю, что сейчас там почти ничего не понятно, сделав функцию меньше, например выделив результаты промисов ( код который идет внутри then ) в отдельные функции, читаемость повысится в разы. Приведите реальный пример реальной простыни, которую нельзя разбить.
  • Уголовный кодекс разработчика
    +1
    Вот-вот. Буквально на днях сидел разбирался в коде passport-saml, функция SAML.prototype.validatePostResponse меня просто убила
  • Уголовный кодекс разработчика
    0
    Я с вами согласен: любой радикализм — зло. Как я уже писал в статье, сам грешил тем, про что писал. Тут именно вопрос не применения, а оценки, что есть хорошо, а что есть плохо, что есть необходимое (или почти необходимое) зло. Да иногда приходится так делать в каком-то данном конкретном случае, но это в любом случае говорит об ошибке на более высоком уровне, уровне выбора архитектуры, методики разработки, фреймворка или даже языка.
  • Уголовный кодекс разработчика
    +2
    Да с С конечно тяжело, но тоже есть варианты.
    У вас там в switch часто повторяется последовательность действий

    read_vint_block_skip(file);
    MATROSKA_SWITCH_BREAK(code, code_len);
    


    и еще несколько

    их можно в функции,
    а коды в массив

    double someCodes1[] = {MATROSKA_SEGMENT_TRACK_FLAG_LACING, MATROSKA_SEGMENT_TRACK_FLAG_FORCED, ...};

    + функция isCodeInArray

    получится что-то типа

    if (isCodeInArray(code, someCodes1))
    yourFunc

    if (isCodeInArray(code, someCodes2))
    yourFunc2

    я думаю размер функций уменьшится в несколько раз
    P.S. в С не силен
  • Уголовный кодекс разработчика
    +1
    Для методов «делаем раз, делаем два» — уже то же написали несколько «если» другие комментаторы. Я могу добавить ещё. Дробление сложного метода на много коротких повышает понимание, ЧТО делает метод. Но к сожалению, часто уменьшается понимание КАК он это делает. В особенности, если итоговая вложенность методов сильно больше двух.


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