Как стать автором
Обновить
23
0
Лев Рычковский @devlev

web-программист

Отправить сообщение

Вот меня недавно попросили камеры видеонаблюдения подключить: Первый раз это делал. 4 камеры по 20 метров кабеля каждая. Я думал за 2-3 часа упавлюсь. Только когда приехал на объект, и когда забрался на 15 метровую высоту, понял что это не так быстро и не так просто. В итоге 3 часа работы растянулись на 8 и 3 выезда на объект на выходных.

Так что по вашим интерпритации я Ethernet патч-корд подключал 15 дней и для этого потребовалось 3 выезда на объект.

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

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

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

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

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

Идея алгоритма очень проста: сайт должен натренировать ML-систему которая будет оценивать, насколько неожиданно что пользователь проголосовал "за" или "против" определенного комментария.

Я считаю это невыполнимой задачей. На одном из разработаных мною сайтов сейчас больше 5 миллионов комментариев. Мы одно время тоже думали о такой системе умной сортировки. Но к какому либо готовому решению так и не пришли.


Я считаю что в этой задаче нужно понимать к какой цели хочешь стремиться: поднять непопулярное мнение в том, развернуть мнение толпы на противоположное, и от этого уже думать над реализацией. Нечто подобное реализованно у фейсбука правда с постами. Вам нравится сортировка постов на фейсбуке?


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


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


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


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

Мне не понятно одно: как ваша придуманная ML система будет решать описанные вами же проблемы?

Занимаюст веб разработкой со времен 6 осла. Я раньше мечтал пересесть на новый рабочий комп, старому вроде как уже скоро будет 10 лет (по тем временем был топовый ноутбук). 2 ядра 4 потока 2.4ГГц 10 RAM. А сейчас вот желание пропала.


Казалось бы, местами все подтормажимвает, подвисает. Мегабайты JS кода который должен за 2-3 секунды стартануть на клиенте. Когда я нажимаю F5 с открытой дебаг панелью, скорость загрузки просидает примерно так же как если бы я открывал виджет на среднечковом телефоне (вроде той же моторолы о которой вы писали выше). Но зато, я буквально чувствую каждое действие, буквально могу измерить сколько той или иной функция, взгялдом оценить скорость выполениня. Если я написал какой то говнокод, это сразу отразится на производительности. Если меня бесит скорость работы какого то модуля значит это может бесить и еще тысячи пользователей которые пользуются моим продуктом. Но по скольку я сижу на таком же медленном железе, я чувствую себя ближе к нороду, ближе к нашим общим проблемам.


И вот тут я задумался, если я пересяду опять на топовое железо, я потеряю все эти осязательные явления. Ко мне будут приходить люди и говорить что тут вот медленно что-то работает, а я просто не смогу этого заметить,

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

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

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

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


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

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

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

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

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

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


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

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

К сожеленеию пока нет возможности попробывать новый редактор, но проблемы в старом просто как вечная мазоль:
форматирование 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


Мой лучший способ расстановки атрибутов у тегов

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

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

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


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

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

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

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


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


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

За статью конечно спасибо! Давно ждал нечто подобного, что кто-то возьмет, и сделает это: скрестит 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 мест на одном экране и показ первого экрана станет быстрее. В своей реализации, я пытался тоже сделать механизм автоматического создания контуров, но потом счет это слишком сложной задачей.

Информация

В рейтинге
Не участвует
Откуда
Тула, Тульская обл., Россия
Зарегистрирован
Активность