• Браузерные Push-уведомления на Javascript и PHP
    0

    Зачем нужен setTimeout на 10000?

  • TREX: 27-ричная симметричная система счисления
    +2

    Призываю haqreu за экспертным мнением!

  • Wrike уходит от использования языка Dart. Часть 1
    0

    Так всегда, самые ответственные решение приходится принимать в самое не подходящее время.

  • Как я делаю цифровую минигитару. Часть 2
    +3

    Мне нравится ваш проект! Я конечно не гитарист, но как инженер хочется поделиться некоторыми мыслями:


    1. Мне кажется складной механизм лучше сделать так чтобы гитара складывалась внутрь ладами а не наружу. При транспортировке велик шанс поврежения и ладов и струн так как это все торчит наружу. Если же они были бы внуть то шанс повредить гитару в сложенном виде был бы намного ниже. Да, возможно пришлось бы усложнить мехенизм складывания.
    2. По поводу самого механизма складывания, я так понял у вас там используются подпружиненные контакты (поправьте если я не прав) и мне кажется это плохой идеей. Если контакты будут открыты то велика вероятность их окисления и вследствии чего один из контактов иметь плохое соединение. Мне кажется что здесь лучше использовать провода. Есть масса способов как сделать подвижное соединение и чтобы все было полностью закрыто.
    3. Саму гитару оставить по форме как и в первом исполнении в виде прямоугольной палки (без корпуса для удобного расположения на ноге). Лучше предусмотреть возможность отстегивания корпуса чтобы опять же можно было иметь более компактную версию. Если в центральной палке будет предусмотренна продуманная система крепления внешнего корпуса разной формы, то тогда и гита будет компактнее, и корпуса можно будет делать разные.

    Я желаю вам успехов в вашем проекте, он реально крут!

  • Победа над nRF24L01: на три шага ближе
    0

    А подскажите, поможет ли решить данную проблему подключения модуля nRF через кренку?

  • Создание квадратизированной галереи проектов на JS
    0

    А чем bootstrap вас не устроил?

  • Ахтунг: «бесплатный» антивирус от RU-CENTER (NIC.RU)
    0

    Выше написали пару регистраторов у которых цены "за наличие записи в базе данных доменов" в 4-5 раз меньше.

  • Ахтунг: «бесплатный» антивирус от RU-CENTER (NIC.RU)
    +14

    nic.ru — самый ужастный хостинг с которым мне только приходилось работать!


    1. Многие услуги можно отключить только за 2 месяца до их окончания. Подключаешь услугу по кнопке на сайте — отключаешь по официальному письму к ним на почту, отправленому курьерской службой.
    2. Интерфейс админки ну просто как из 90х, я до сих пор не знаю какая версия загрузится при очередном входе.
    3. Постоянно пихают уже включенные в карзину дополнительные услуги: личный менеджер и типо того.
    4. Продление домена 1к р — за что?
    5. Заказал хостинг для сайтов. Установил сайт на водпресе. Решил потетсить битрикс. Поставил на тот же хостинг рядом сайт на битрексе. Сайт на водпресе больше не работает. В саппорте сказали что оказывается при установки битрикса меняются настройки всего виртуального хостинга, так что он становится не пригдным уже для работы с водпресом. Ну почему нельзя было об этом предупредить при создании сайта на битриксе?
    6. Раньше на виртуальном хостинге можно было размещать 15 сайтов — сейчас 2.

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

  • Улучшения нового редактора Razor в Visual Studio
    0

    К сожеленеию пока нет возможности попробывать новый редактор, но проблемы в старом просто как вечная мазоль:
    форматирование Dictionary


    Картинка + Код

    @{
        var attr = new Dictionary<string, string>
    {
    { "", "" },
    { "", "" },
    { "", "" },
    };
    }

    Генерация атрибутов у тегов


    Картинка + Код

    <div @if (ViewBag.A != ViewBag.B) { <text> id="123123" </text>  } else if (ViewBag.A != "sdgkjwektjwkletjlskdgjwelkrtjelkrtj") { <text> id="werw235" </text>  } else { <text> class="qweqwe" </text> }>
    
    </div>

    Как то раз нужно было сделать сложное меню с большим кол-во атрибутов у тегов, которые должны были расставляться по большому кол-ву условий. Я просто не смог это сделать в стандартом редакторе Razor. В итоге психанул, и сделал все на ванильном C# с применением TagBuilder


    Мой лучший способ расстановки атрибутов у тегов
  • История 4го места на Russian AI Cup 2020
    0

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

  • История 4го места на Russian AI Cup 2020
    0

    А лечить лучников не кто не пробывал? И сколько за такт лечит один строить?

  • История 4го места на Russian AI Cup 2020
    +3

    Прочитал на одном дыхание! Спасибо за столь подробный рассказ.
    Узнал об этом соревновании только из вашей статьи. Возник ворпос, инересно, а имеет ли место быть стратегия, когда лучники выстаиваются свиньей.


    Накидал в фотошопе пример

    Как бы лучникам нужно сделать лишний шаг, но зато увеличавается их плотность. Или такая тактика не получилась бы из за слишком быстрого умирания лучников от выстелов?

  • Поведениеметр
    +1

    Если прям совсем начинать сначала то я посоветовал бы книгу если с ребенком трудно Петрановской. До этого читал Гиппенрейтер, Курпатова, Комаровского и еще примерно 30 разных книг.

  • Поведениеметр
    +1

    Я считаю что это временное решение и основную проблему оно не решает. А проблема тут не в ребенка, а в родителях. А если делать поведение метр то тогда нужно было их делать сразу два: один для ребенка, а другой для себя! (и я не один так думаю: eimrine) Чтобы сам ребенок тоже ставил вам оценки за поведение, а то вдруг вы тоже не дотягиваете. Вдруг вам тоже надо что-то в нем подкорректировать.


    Тоже пробывали внеднять подобные методы оценки поведения ребенка. Но и попутно читать литературу, а все ли мы, как родители, делаем правильно. И выяснилось что многое чего делали не правильно. Исправили свое поведение, и о чудо, поведение ребенка тоже изменилось в лучшую сторону.


    А переделывать себя сложно!

  • Делаем схему выбора мест в кинозале на React: о canvas, красивом дизайне и оптимизации
    +3

    За статью конечно спасибо! Давно ждал нечто подобного, что кто-то возьмет, и сделает это: скрестит React и Canvas. В добавок тема отрисовки концертных залов мне знакома (фулстек разработчик Myslo-кассы).


    Года 4 назад нужно было создать инструмент, для продажи билетов. Тоже был выбор SVG или canvas. Делать на чистом HTML не рассматривал как вариант, потому что там ожидали проблема с масштабированием. В тот момент как раз Павел Дуров устраивал как раз конкурс на отрисовку графиков, и там как раз в чатах была борьба, какой механизм отрисовки лучше: SVG или canvas. SVG проиграл. Поэтому я выбрал canvas.


    Я выбрал делать на canvas в нативе (canvas 2D). На тот момент образцом для подражания была афиша яндекса с монстуозной схемой. У нее был только один минус -все очень сильно тормозило. Одним из требований было то что это все должно работать очень быстро. В итоге, выбор сектора были сделан на SVG, а выбор мест на canvas (пример можно посмотреть тут как работает схема зала).


    Нюансы при отрисовки:


    1. Не отрисовывать места которые выходят за пределы области canvas
    2. Не делать лишних перерендеров, перерендер выполняется только по внешнему событию: перемещение схемы, изменение масштаба, изменение размера страницы.
    3. FPS при отрисовки схема должен быть 60 кадров в секунду!

    Пожалуй FPS было самым главным требованием! Да, схема зала получилась очень простой, но отрисовка мест происходит очень быстро.


    Выводы которые сделал я:


    1. SVG — это максимум 1000 элементов в DOM дереве — все остальное медленно.
    2. canvas — отрисовка в 5000 областей за раз не вызывает просидания FPS. Все что больше требует принятия дополнительных мер: дробить цикл на кадры, кеширование областей.
    3. Избегать отрисовки больше 1000 мест на одном экране.

    Я решил посмотреть как это работает на вашем сайте, на примере этого мероприятия. Сразу пройдусь по багам которые заметил:


    1. Шаг изменения масштаба зала происходит очень резко: есть вариант с выводом всего зала и сразу с супер увеличением.
    2. Из 2 вытекает проблема что если нужно выбрать место с краю, нужно drug&drop-ом двигать схему зала. И тут конечно заметно просидание FPS по отрисовки на Core i5! По ощущению, ну кадров 5 в секунду (Firefox, в хроме лучше).
    3. Меняем размер страницы и все зависает, а потом загружается начальная страница.
    4. Запаздывающий эффект наведения.
    5. Возможность выбора мест на начальной схеме зала без увеличения масштаба. Каждое место на экране занимает ровно 3 пикселя. Я не думаю что это удобный способ выбора мест. Тем более в этом режиме однозначно будут просидания в производительности

    Низкий FPS

    Запаздывающий эффект наведения

    Выбор мест на начальной схеме зала

    Выводы:


    1. В целом конечно видно, что все еще очень сырое. Вчера выкатили, а сегодня написали статью. Этот комментарий я хотел написать еще вчера, но я просто не мог не посмотреть как работает схема потому что она просто падала, с ошибкой связаной с booking. Схема зала не работала не в одном из опробованных браузеров.
    2. Мне кажется Pixi нужно менять на что-то другое (возможно свое). Возможно стоит делать отрисовку только на canvas 2D, раз 3D не используется. Canvas отрисовку нужно хорошенько кешировать, тогда она будет работать быстро.
    3. За React нужно конечно тщательно следить, потому что с ним очень просто наделать кучу лишних перерендеров.
    4. На счет максимального кол-ве мест в зале — нужно было выбирать олимпийский — и пытаться отрисовать их 3 на одном экране. Здесь конечно, мне кажется, нужно использовать какой то механизм создания контура секторов исходя из координат мест, и на большой схеме показывать только эти контуры, а при увеличении уже подгружать места для секторов. Тогда не будет проблемы отрисовки больше 1000 мест на одном экране и показ первого экрана станет быстрее. В своей реализации, я пытался тоже сделать механизм автоматического создания контуров, но потом счет это слишком сложной задачей.
  • Анонимный Дед Мороз 2020-2021: пост хвастовства новогодними подарками
    +16

    Первый год участвую анонимным дедом морозом. Очень рад, что присоединился к этой славной традиции. Было даже немного волнительно. А когда я узнал, что мои олени скачут из самой родины деда мороза — Великого Устюга, тут сложно не поверить в новогоднее чудо!


    Самое время заглянуть внутрь

    Дети слопали за раз пол коробки зефира! Я первый раз попробовал зефир с начинкой, в моем городе таких не где не встречал. Свечку сразу жена забрала. Травяные чаи я обожаю! Спасибо тебе Дедушка!


    С наступающим Новым Годом!

  • Service Workers
    0

    Жалко что поддержка SyncManager реализована только в хромо-подобных браузерах.

  • Все ли вы знаете о useCallback
    0

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


    Ну не хотите вы использовать useCallback — ну так и не используйте! Это ваше право, ваш выбор! Я не заставляю вас делать этого в каждом компоненте. React рекомендует использовать useCallback но не заставляет. Дедлайны горят! Больше кода надо писать! Не видите в этом пользы! Ну так и не делайте! Я вас ругать не буду! Правда!


    А кому надо?

    Этот надо мне!


    И зачем?

    Чтобы перерендер работал быстрее!


    Чего вы добились этим кодом?

    Чтобы было легче переиспользовать код! Чаще всего, я сталкиваюсь с задачами, когда я не знаю что там происходить в компонентах ниже/выше по дереву (писал больше пол года назад, либо писал другой человек). А там может быть не только removeEventListener/addEventListener но другие вещи. Моя задача написать такой код, который бы делал минимальное число лишних перерендеров. Поэтому я использую useCallback.

  • Все ли вы знаете о useCallback
    0

    Вот то что было написано в вашем примере:
    const onClick = () => onCarClick(car);
    А вот, так как надо делать с точки зрения React:
    const onClick = useCallback(() => onCarClick(car), [car]);


    При первом рендеренге, в обоих случаях, будет создана ссылка на функцию onClick.
    При повторном рендеренге onClick, созданная без useCallback, будет содержать новую ссылку на анонимную функцию.
    А вот при повторном рендеренге onClick, созданная через useCallback, будет содержать туже ссылку на анонимную функцию. В этом и есть магии функции useCallback! Задача useCallback состоит в том чтобы ссылка на функцию внутри не менялась при отсутствии изменений в deps


    Если при повторном рендеренге реакт видит что ссылка на функцию не поменялась, то он не будет производите перерендер.

  • Все ли вы знаете о useCallback
    0
    Внимание вопрос
    В каком из вариантов написания компонента функция присваемая переменной someFunction создается реже?

    У меня тоже вопрос: зачем все это? Для чего вам уменьшать кол-во присвоений функции?


    Может вы хотите сказать о производительности? Ну так сделайте бенчмарки, можно будет увидеть реальное сравнение в скорости и сделать какие то выводы.


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


    const Cars = ({ cars }) => {
      const onCarClick = (car) => {
        console.log(car.model);
      }
    
      return cars.map((car) => {
        return (
          <Car key={car.id} car={car} onCarClick={onCarClick} />
        )
      });
    }

    можно вообще переписать так:


    const onCarClick = (car) => {
      console.log(car.model);
    }
    const Cars = ({ cars }) => {
      return cars.map((car) => {
        return (
          <Car key={car.id} car={car} onCarClick={onCarClick} />
        )
      });
    }

    Зачем класть функцию onCarClick, внутрь Cars, если ссылка на нее не зависит от props? onCarClick — это чистая функция.


    А ниже вы тоже приводите странный листинг кода:


    const Car = ({ car, onCarClick }) => {
      const onClick = () => onCarClick(car);
    
      return (
        <button onClick={onClick}>{car.model}</button>
      )
    }

    Этот код можно переписать так:


    const Car = ({ car, onCarClick }) => {
      const onClick = useCallback(() => onCarClick(car), [car]);
    
      return (
        <button onClick={onClick}>{car.model}</button>
      )
    }

    Здесь функция onClick явно зависит от props. Чтобы React не делал лишнего рендера нужно чтобы ссылка на функцию onClick не менялась, при передачи одного и того же значения. А добиться этого как раз можно используя useCallback.


    Я переписал окончательный вариант на колбеках:


    const Cars = ({ cars }) => {
      const onCarClick = useCallback((car) => {
        console.log(car.model);
      }, []);
    
      return cars.map((car) => {
        return (
          <Car key={car.id} car={car} onCarClick={onCarClick} />
        )
      });
    }
    
    const Car = ({ car, onCarClick }) => {
      const onClick = useCallback(() => onCarClick(car), [car]);
    
      return (
        <button onClick={onClick}>{car.model}</button>
      )
    }

    В этом случае нет никакой пользы оборачивать метод в useCallback, т.к. нам не важно, ссылка это на функцию с прошлого рендера или с текущего рендера, а useCallback как мы уже знаем не бесплатный.

    В том то и дело что польза есть! Примеры, которые вы приводите, содержат фундаментальные ошибки.


    Я использую VSCode с плагином ESLint на который установлено специальное дополнение по автоисправлению всех зависимостей хуков (link).

  • Как показывать ИБ в 2021 году, чтобы ваш сериал не провалился
    +3
    Если создатели сериалов про хакеров и киберпреступность не прорабатывают детали, перед экраном грустит один кибербезопасник.

    Еще грустит физик.


    Некст не смотрел, но вот по Devs без фейспалмов не обойтись.


    1. Откуда в кубе берется кислород? По летающему лифту доставляется наверно...
    2. Какие должны быть магниты, чтобы создать магнитное поле для удержания огромного куба на расстоянии 7 метров и при этом не как не воздействовать на все остальные металлические предметы, ну даже часы с камерой нового прогера?
    3. Куб висит в вакууме, проводов нет. Внутри куба откуда то берется электричество. Предположим что это индукция. Куда отводить тепло, вырабатываемое квантовым компьютером, находясь в вакууме? На лифте катать?
  • Самодельный гироскутер
    +2

    А что вы имеете против софта на ардуино?

  • Новый сайт для популярного медиа за 2 месяца
    +6

    Жалко что о технических деталях реализации не сказано почти ни слова, а очень хотелось бы.


    Очень большой Time to Interactive — на телефоне, после показа шапки, очень долго ничего не проихсодит. Я вижу секунд 5-10 просто шапку с логотипом и просто чистый лист. По ощущению, идет компиляция страницы для первоначального отображения. Причем нагрузка на трафик не сильная, а вот нагрузка на проц просто чудовищная. Такая же проблема хорошо заметна и на десктопе, если немного опустить скорость работы процессора.


    Определенно стоит провести оптимизацию показа первого экрана. Мне кажется слишком много там сейчас выполняется фоновых действий, которые съедают ресурсы проца, откладывая первый показ.


    По возможности отложить загрузку модулей, которые не нужны для первого показа. Например на главной не обязательно знать как рендерить конкретную новость, а в новости не обязательно знать как рендерить главную. Здесь лучше всего использовать модель загрузки lazy load module


    Пред компиляции готовых HTML страниц нет — это конечно плохо.


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

  • Новый плацкарт в вагоне габарита Т: помните ту обратную связь, что вы давали на 1-ВМ?
    0

    Да, рисовал все в формате Т.


    На счет скорости ничего сказать не могу, в статье было что новые вагоны должны будут так же рассчитаны на стандартные ограничения по скорости в 160км/ч, Значит можно формату Т 160км/ч гонять.


    Считаете, что для более длительных поездок старый добрый плацкарт, с ногами в проходе и новыми знакомыми будет предпочтительнее?

    В одной из статей было первоначальное т.з. и там как раз было написано про это.


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


    На счет двух рядов окон, ну так все уже и так есть в двухэтажных вагонах

    image

  • Новый плацкарт в вагоне габарита Т: помните ту обратную связь, что вы давали на 1-ВМ?
    0

    Комментарии ваши прочитал, все по делу!


    На счет столика можно и стационарный:


    а откидной столик мне уже просто не охота было рисовать (пока все это чертил, видимо запал уже и кончился)


    Программа SketchUp


    Отвечу тут сразу и на нижние вопросы по размерам:
    Ширина внутренняя — 3220мм — не помню уже откуда ее взял, так что может она реально больше того что есть на самом деле. Шаг елочки — 1155мм. Длинна всех девяти купе я где то нашел — 16173 мм. Если 16173 поделить на 14 как раз получится 1155мм. Тут еще нюанс в том, число купе не сходится со старой системой (54 против 56), если делать по одинаковому числу купе на каждой стороне. Угол наклона 35.2 градуса — почти как у вас! Ширина полки 637мм — в самом узком месте 645мм у меня получилось (это с учетом межкупейных стенок по 30мм.).


    Как по мне, данный дизайн устраняет практически все известные недостатки плацкарта — короткие полки, отсутствие частного пространства, расположение боковых мест в проходе. Пространства под нижней полкой (около 400 л) должно быть достаточно для багажа, даже для лыж и, возможно, байдарок. Для велосипедов можно предусмотреть сетчатую полку на уровне 205 см сразу у тамбура.

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


    Мне кажется, вариант елочкой игнорят потому что изначально были большие ограничения по редизайну. Там где то в посте или в комментариях писали, что изначально было условие, что нужно придумать новый дизайн плацкартного вагона не изменяя вагон внешне: окна должны были оставаться на своих местах, система вентиляции не должна была меняться. Отсюда и пошло поехало что практически ничего трогать то и нельзя. Даже этот рундук между полками в купе мешал нормальной работе штатной вентиляции. Поэтому сказали что нужно тогда делать индивидуальную вентиляцию. Ок. Сделали индивидуальную вентиляцию, а потом еще и выяснилось что уж наверно проще и вообще весь вагон тогда переделать, пересчитать все его размеры и характеристики: окна наконец сделать нормальными чтобы на верхней полке можно было в него что-то видеть кроме рельс. В итоге мы получаем совершенно новый вагон, но со всеми старо-новыми идеями, в виде рундука между полками. Ну ведь жалко этот рундук выкидывать на свалку идей! Его вон уже и в реальном вагоне сделали и вроде как норм. Вот видимо и решили что все, ничего менять не будем больше, типо хватит. Но я считаю такой подход в корне не верный — раз есть новые размеры вагона — так надо выкинуть все идем и взглянуть на возможный результат с нуля — с чистого листа! Расписать все за и против каждого возможного варианта ну и какой вариант больше наберет положительных сторон тот и выбрать.


    Для однодневных поездок на одну ночь вариант с елочкой мне кажется более оптимальным. В нем не надо ползать по полке, потому что из положения сидя, в положении лежа оказаться намного проще. Полка на втором ярусе с рундуком подразумевает что у человека должны быть довольно сильные руки чтобы он мог на них не только опираться, но и протаскивать ими собственное тело.

  • Новый плацкарт в вагоне габарита Т: помните ту обратную связь, что вы давали на 1-ВМ?
    +1

    И все таки формат расположения спальных мест елочкой мне понравился больше.
    image Раз уж переходите на новый формат размеров вагонов, то тут просто отличная возможность разгуляться с новыми форматами компоновки спальных мест.


    Посмотрев видео китайского вагона (спасибо Animegravitation), я решил потратить вечерок и нарисовать что-то в этом же стиле.


    Много фото под спойлером:








    Размеры взяты приблизительные из википедии и разных источников. В результате спальное место в самой длинной точке достигает фантастических 2100 мм. Ширина спального места получилась 636мм. На верхней полке осталась лишь одна полка для чемодана. На нижней полка + пространство под кроватью. На нижней полке можно опустить ноги перед окном и смотреть в окно. Длинна всех 9 купе была взята 16173мм. На одной стороне уместилось 14 двухъярусных купе. Итого — 56 мест.

  • Книга «Хороший интерфейс — невидимый интерфейс»
    +1

    Я хочу попить чаю! Мне нужно включить чайник.
    Но погодите, у меня же супер чайник с Bluetooth


    1. Найти телефон, где я последний раз оставил его в квартире;
    2. Нужно аккуратно взять телефон чтобы телефон не упал и не разбился о пол;
    3. Разблокировать телефон;
    4. Свернуть последнее приложение;
    5. Прокрутить экран до иконки с приложением по запуску чайника;
    6. Нажать на него;
    7. Смотрим на заставку приложения 5 секунд;
    8. Смотрим на лоадер загрузки моих домашних устройств еще 5 секунд;
    9. Выбираю чайник из списка устройств;
    10. Идет подключение по блютуз к чайнику — 5 секунд;
    11. Выбираю в меню "кипячение";
    12. Нажимаю на кнопку "включение".

    Вместо того чтобы:


    1. Подойти к чайнику;
    2. Включить чайник.

    Спасибо за ссылку!

  • Старт работы с Excel на C#
    0

    Я использую ClosedXML — бесплатный софт по работе с Excel. В основном Excel используем для генерации отчетов и дальнейшей печати, так как с PDF немного сложнее и дольше работать. По скорости работы замеры не делал.

  • Дерево синтаксиса и альтернатива LINQ при взаимодействии с базами данных SQL
    +1

    Вообще конечно я перед вами снимаю шляпу! Такую крутую библиотеку написали. Самому давно хотелось написать нечто подобное, но к сожалению, не обладаю такими глубокими познаниями в шарпе. Фильтры на выборку данных приходится писать довольно часто, но я до сих пор не нашел ответа на простой вопрос, как в LINQ сделать выборку из таблицы по полю, которое было передано в переменной? (если вы может где видели, был бы рад ссылочки).


    На счет LEFT JOIN это действительно магия какая то, тоже постоянно лезу в гугл.


    Вообще конечно, из личного считаю, считаю LINQ в Entity Framework ужасной штукой. Он как наркотик, подсаживает на быстроту и удобство доставания данных, но когда дело доходит до оптимизаций, или каких то специфических вещей, то тут только понимаешь, что пора с него слезать. Иногда слезать бывает сложно, и дело доходит до подобных вещей. У меня был опыт, когда джун протащил во вьюшку модельку, которую отдал EF, и потом прямо на вьюшке делал циклические подзапросы с помощью lazy loading.


    Другой раз фильтры организовать, как в начале вашей статьи. Сделать что-то универсальное ну практически не возможно. Только копипаст. Ну ведь хочется, сделать красиво, не писать один и тот же код дважды, но нет, тут так нельзя, нужно копипастить.


    Из последнего, есть у меня два больших Select(n => ModelA и Select(n => ModelB.
    ModelA состоит из 50 полей и ModelB состоит из 50 полей и лишь одно поле у них разное. Только одно поле! Но объединить их из под LINQ запрос не как не получится. Тут либо оба поля всегда дергать и не важно, нужно оно там дальше или нет. Либо две разные модели но фактически одного и того же. Если бы я был в мире обычного SQL мне бы удалось достичь подобного парой строк кода, но в мире LINQ over EF, только копипаст. Всерьез уже начинаю задумываться о генераторах кода, которые перед билдом будут создавать нужный код!


    Это была минутка боли и страданий. Так что как будет возможность, обязательно опробую вашу библиотеку.

  • Дерево синтаксиса и альтернатива LINQ при взаимодействии с базами данных SQL
    0

    Ну а разве с помощью LINQKit нельзя сделать выборку из таблицы по полю, переданному в переменной?

  • Динамическое меню c поддержкой touch move и mouse move на RevolveR
    +2

    Слово const используется чтобы самому себе не выстрелить в ногу: не перезаписать переменную и не забыть что надо удалить таймер в случае отмены эффекта.

  • Динамическое меню c поддержкой touch move и mouse move на RevolveR
    +4

    Это называется спагетти код! У меня было пару программистов, которые писали подобные вещи. Они не хотели учиться. Уволены. Мой вам совет, выкиньте на помойку свои знания по Javascript и начните учиться современным методам программирования. То что вы пишите, писали в начале 2000 годов. Сейчас уже есть куча всего готового и удобного. А перед тем как изобретать свой велосипед нужно сначала изучить все остальные велосипеды: Typescript, React, Vue, Angular — список можно продолжать бесконечно.

  • Динамическое меню c поддержкой touch move и mouse move на RevolveR
    +2

    Вы ничего не поняли! Вот такой код:
    void setTimeout(() => {
    это плохо! Нужно писать:
    const timer = setTimeout(() => {
    и где-то должен быть возможен вызов
    clearTimeout(timer)


    Иначе у вас будет бесконечное число сайд эффектов, и вы только и дальше будите их плодить.

  • Динамическое меню c поддержкой touch move и mouse move на RevolveR
    +1

    Ну на словах сложно объяснить. Тут видео нужно записывать экрана. Под рукой такого софта нет.


    Попробую объяснить на словах: сдвигаю меню влево примерно на 100-200px, далее бросаю курсор и снова двигаю меню на столько же, когда я третий раз пытаюсь передвинуть меню, после бросания курсора оно сразу уезжает на начальную позицию. Предполагается что меню не должно езжать пока курсор висит над меню. А если пунктов будет не 5 а 50?


    Но я по стилю кода вижу, что баги будут 100%. Например, если вы создаете setTimeout но не как не используете clearTimeout. Если вы рассчитываете, что проверка if( !RR.menuMove ) спасет от повторного вызова, то вы глубоко ошибаетесь!


    Хороший тон для каждого setTimeout писать где то рядышком clearTimeout чтобы если вдруг нужно отменить действие, это можно было сделать легко быстро!


    Пример из мира React

  • Динамическое меню c поддержкой touch move и mouse move на RevolveR
    +2

    Да тут просто ничего не работает, от слова совсем!


    Сразу вспомнилась история с перезапуском кинопоиска
  • Введение в моделирование динамики квадро-, гекса- и октокоптеров
    0

    Противоречие в том, что путается сила тяги с мощностью. При добавлении второго двигателя мощность возрастет в два раза, а сила тяги — нет.


    Если взять автомобиль с двигателем мощностью в 100л/с то он сможет разогнаться до 200км/ч. то по вашему получается если добавить ему еще одни такой же двигатель, он разгонится до 400км/ч. Максимальная скорость увеличится ну максимум до 280км/ч. Мощность увеличилась в два раза, а скорость нет. Скорость увеличивается не линейно!


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


    Поэтому если вы поставите два соостных винта с одним двигателем то получение 111 условных единиц тяги. А с двумя двигателями 222 условных единицы тяги.

    Если взять один винт с мотором, который поднимает 1кг, и добавить к нему еще один мотор подъемная сила не будет 2кг! Чтобы развить такую подъемную силу, винт должен начать вращаться в 4 раза быстрее.


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

    Если скорость вращения винта с одним мотором 30 000 оборотов в минуту то при добавлении второго мотора, по вашему, он должен вращаться со скоростью 120 000 оборот в минуту. Но винт чисто физически не будет вращаться с такой скоростью! Ну максимум скорость вращения увеличится до 45 000 оборотов в минуту. А это значит что при добавлении второго двигателя сила тяги возрастет всего до 1.2кг максимум! (30К об/м ~ 1 кг, 120К об/м ~ 2 кг, 45К об/м ~ 1.2 кг)


    Возвращаясь к примеру выше с соосной схемой, когда винты были на расстоянии 1 кг друг над другом, сила тяги была 2 кг (по 1 кг на каждый). Когда мы их начали сближать до полного сближения, сила тяги падает до 1.2 кг. Здесь чисто физически не может быть такого положения винтов, при котором они создают тягу 2,22 кг.


    А до момента совпадаения КПД системы постоянно расло за счет уплотнения воздуха в который ввинчиватеся второй винт.

    Если бы такое было бы в действительности, если бы тяга из двух соосных винтов с двумя двигателями возрастала была до 2.2 кг вместо по 1 кг для каждого, мир был бы завален квадрокоптерами, построенными по такой схеме. Но 98% всех выпускаемых на рынке квадракоптеров не имеют соосной схемы. Рынок решает, что работает, а что нет. Значит это не работает. А эффект ввинчивания — ну это просто ваша фантазия.

  • Введение в моделирование динамики квадро-, гекса- и октокоптеров
    0

    Вы же сами пишете в статье:


    Силу тяги ВМГ развивает пропорциональную квадрату угловой скорости

    Получается если с двумя двигателями сила тяги увеличилась в два раза (с 111 до 222) то угловая скорость винта увеличилась в 4 раза?

  • Введение в моделирование динамики квадро-, гекса- и октокоптеров
    0

    Предлагаю снова пофантазировать.


    Представим некоторую модель, состоящую из двух винтов (30 см в диаметре), расположенных по соосной схеме, один над другим, но так что расстояние между этими винтами очень большое (ну скажем 1км). Каждый из винтов будет обладать некоторой подъемной силой, скажем 100 условных единиц. Предположим что винты вращаются в одну и туже сторону и с одинаковой скоростью (все винты и двигатели одинаковые). А поскольку расстояние между ними очень большое, то общее тяговое усилие всей системы будет 200 условных единиц (поток от верхнего винта просто не достает до нижнего).


    Теперь будем сближать эти винты между собой до полного их слияния. Если пренебречь толщиной винтов (взять ее за 0 см) и толщиной двигателя (взять ее за 0 см), то после полного их сближения, получим один винт (поскольку скорости одинаковые).
    А тяговое усилие одного винта мы уже знаем — оно составляет 100 условных единиц тяги.


    Получается некий предел, который от 200 единиц тяги на расстоянии в 1км стремится к некоему значению тяги на расстоянии 0. Здесь нужно учесть тот факт что вращают такой сдвоенный винт два мотора, а не один. Силу тяги ВМГ развивает пропорциональную квадрату угловой скорости. Даже если предположить, что угловая скорость возрастает на 20% от двух моторов, то сила тяги возрастает на корень от этого значения. Т.е. сила тяги такого винта составит порядка 110 единиц тяги.


    Получается так, что сила тяги будет постепенно падать на протяжении сближения винтов с 200 единиц тяги до 110 при полном сближении. Вы же утверждаете, что сила тяги возрастает при соосной схеме и будет даже больше (211 условных единиц) той что номинально выдает каждый из винтов. Если следовать вашим словам, тогда должна находится некоторая точка на расстоянии от 1км до 0, в которой сила тяги будет максимальной.


    Приведу другой пример:


    Представим себе систему координат, состоящую из всего одной оси X. На этой оси расположен мячик для пинбола по которому бьют ракеткой со скоростью 30 км/ч. Допустим, что мячу передалась такая же скорость и он теперь движется вдоль оси со скоростью 30 км/ч. Пусть в системе будет небольшое трение, ну скажем о воздух. На расстоянии 10 метров от начальной точке, скорость мяча будет уже, ну скажем, 25 км/ч. Если в точке, на расстоянии 10 метров, ударить по мячу ракеткой в том же направлении и с такой же скоростью 30 км/ч то мячь пролитит на расстояние, ну скажим 50 метров. Если бы мы не ударяли бы по мячу ракеткой второй раз, то мячь бы пролетел тогда только 40 метров.


    Получается, можно было потратить энергии только на один удар, и мяч бы пролетел бы на 40 метров или сделать два удара потратив в два раза больше энергии и мяч улетит всего на 10 метров дальше. А теперь представим себя, сидящим на мяче, после первого удара о ракетку. В момент совершения второго удара ракетка будет двигаться относительно мяча со скорость всего 5 км/ч! (скорость ракетки минус скорость мяча).


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


    Вот цитата из вашей же статьи:


    Результаты летных испытаний и другие экспериментальные материалы свидетельствуют, что коэффициент полезного действия соосных несущих винтов в среднем в 1,06-1,1 раза (на 6-10%) выше, чем одиночных, что видно на рис.1. Учитывая экономию мощности, идущей на компенсацию реактивного момента (10-12%), получаем, что в целом коэффициент полезного действия соосных вертолетов на 16-22% выше, чем одновинтовых.

    Вот и получается что:


    1. в случае одного винта — тяга 100 условных единиц тяги.
    2. в случае соосной схемы тяга больше на 22% по сравнению с одновинтовой схемой — т.е. 122 условных единицы тяги.
    3. в случае двух винтов в одной плоскости тяга будет 200 условных единиц тяги.

    Получается трикоптер со спаренными винтами будет иметь 366 условных единиц тяги, а гексакоптер с винтами в одной плоскости — 100*6 = 600 условных единиц тяги. Даже если вычесть порядка 10% на пересечение воздушных потоков, останется 540 условных единицы тяги!


    Получается потеря в мощности при соосной схеме 78% а не 50% как я писал выше, для каждой пары винтов. А для всего коптера потеря в тяги составит 32% а не 25% как я писал выше.


    Наверно поэтому так редко встречаются варианты коптеров с соосной схемой.

  • Введение в моделирование динамики квадро-, гекса- и октокоптеров
    0

    Да, с условными единицами вы хорошо придумали, лучше моих процентов. Но вот вопрос — откуда взялись дополнительных 11 условных единиц силы тяги при расположении винтов в соосной схеме?

  • Введение в моделирование динамики квадро-, гекса- и октокоптеров
    0

    Ну вы уклоняетесь от ответа) Вот есть один винт — он создает тягу, условно, 100%. Есть два винта рядом в одной плоскости — они создают тягу ну скажем 200%.


    По вашему два винта в соосной схеме сколько наберут?