• 10 принципов объектно-ориентированного программирования, о которых должен знать каждый разработчик
    0
    Пример и правда не лучший — стоило бы убрать сеттеры и передавать параметры в конструктор (Rectangle(int width, int height) и Square(int size), тогда бы было меньше вопросов. Классы не обязаны быть изменяемыми.
  • 10 принципов объектно-ориентированного программирования, о которых должен знать каждый разработчик
    0
    Квадрат — это сын ромба и прямоугольника, и наследует геометрические свойства обоих родителей, являясь при этом внуком четырехугольника и вместе со своими родителями наследуя и его геометрические свойства.
  • Мы на Highload++ в этом ноябре: задай вопрос инженерам Badoo
    +1
    Спасибо большое за ответы, Алексей.
    если вы скажете место в докладе, в котором у слушателя по-вашему создается такое впечатление

    Это не из доклада, это — из общения с различными людьми. Но я понял, что это было ошибочное мнение. В докладе этот момент не был освещён.
    Обычно в командах 3-4 человека еще 50% можно программить, но 7-8 уже почти нереально. Но если человек стремится совмещать — это можно делать и в больших командах, просто в ущерб другим активностям (я бы не рекомендовал, но на вкус и цвет).

    Абсолютно согласен. По личному опыту я сделал точно такие же выводы.
  • Мы на Highload++ в этом ноябре: задай вопрос инженерам Badoo
    +4
    Вопросы Алексею Рыбаку.

    Первый вопрос про ревью и мотивацию. Смотрел в записи ваш доклад о performance review с одного из митапов в Баду, было очень интересно. Насколько я понял, материальные поощрения после review довольно существенные, потому что это хороший инструмент мотивации. Как это сказывается на основной (обязательной) части зарплаты? Пример для наглядности — в одной компании ценят стабильность, и ежемесечная зарплата программиста 180 К (ниже этого он не получит), а ежеквартальные премии могут составлять например 20 К за очень хорошее review — условно говоря на пятёрку по пятибальной шкале, а если сотрудник хорошо работал, но после нормировки оказался ниже середины, то премию он не получит вообще. В другой компании с точно таким же зарплатным фондом обязательная часть зарплаты — это 120 К, но если он постарается, то в конце квартала у него будет премия 200 К (это плюс к обязательной части). Как следует из расчётов, у компании одинаковый зарплатный фонд (оба сотрудника получат по 560 К за три месяца работы, при высшей оценке на ревью). Соответственно в одной компании минус в том, что премия после review слабо мотивирует, а минус второй компании, что хороший, но невыдающийся сотрудник чаще всего будет получать 120 К, что будет его демотивировать так же, как высокая премия мотивирует лучших сотрудников. В каких пределах находится премиальный процент от обязательной части зарплаты, в каких границах находится основная базовая зарплата относительно рыночной зарплаты, и как решаются проблемы демотивации для тех, кто останется недоволен премией?

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

    Третий вопрос про тимлидов. Не секрет, что в разных компаниях очень сильно различаются обязанности тимлидов, а так же различается количество уровней IT-шной иерархии управления. Иногда над тим-лидом уже CEO, а иногда ещё три уровня технических управленцев. Иногда тимлиды програмирут 90% времени и по сути больше похожи на ведущих разработчиков, а иногда совсем не программируют, а управляют командой из 15-20 человек. Например, существует мнение, что при команде в 6-8 человек на программирование времени не остаётся. В некоторых компаниях тимлиды отвечают за продуктовую часть, у них свои бизнесовые KPI, а в других ответственность ограничена исключительно качеством кода команды. В некоторых — у тимлида в подчинении кроссфункциональная команда, состоящая как из серверсайд разработчиков, так и клиентсайд разработчиков, тестеровщиков, админов, техписателей и так далее, в то время как в других компаниях у серверсайд тимлиодов в подчинении исключительно серверсайд разработчики. Расскажите, пожалуйста, какой процент времени тимлиды в Баду тратят на непосредтсвенное программирование, как этот процент времени зависит от размера команды, какие у них KPI и входят ли в них бизнесовые и продуктовые показатели, могут ли быть в одной команде и серверсайд и клиентсайд разработчики в подчинении у одномго тимлида, какого размера команды, и какой дальнейший путь развития тимлидов в Баду, кто ими руководит и за что он отвечает?
  • Сравнение REST и GraphQL
    +2
    Что-то не могу понять, зачем GraphQL сравнивать с REST; было бы логичнее выбрать похожий по смыслу формат, например json-api

    http://jsonapi.org/format/#fetching-sparse-fieldsets (можно указывать, какие поля возвращать)
    http://jsonapi.org/format/#fetching-includes (можно указывать связанные ресурсы, и т.д.)
  • Полное руководство по переходу с HTTP на HTTPS
    0
    В _полном_ руководстве ожидал увидеть подробную информацию про HSTS и инструкции для плавного переезда сайта на HTTPS без потери ранка и индекса в популярных поисковиках.
  • DIYorDIE Meetup 1 июля: выбираем спикеров
    +1
    Ребят, а можно чуть больше информации о самом мероприятии?
  • Куда податься программисту за знаниями в этом году
    +1
    если вдруг вы знаете о каком-нибудь стоящем мероприятии, дополняйте наш список в комментариях.

    Есть ещё одна отличная конференция, которая традиционно проходит в первой половине года — https://dddeurope.com/ К сожалению, она проходит в январе, поэтому попасть на неё можно будет видимо только первой половине следующего года. Уровень конференции довольно высокий, и материал будет полезен широкому спектру разработчиков. Видео материалы всех выступлений выкладывают оперативно, и со всеми ними можно ознакомиться на сайте, чтобы самостоятельно составить впечатление о качестве конференции.
    Рекомендую.
  • Горизонтальное масштабирование. Что, зачем, когда и как?
    0
    Прошу прощения за опечатки, возможность редактирования пропала раньше, чем я успел дочитать :(
    В следующий раз будут готовить и проверять текст комментария отдельно до публикации.

    > а комментарии в tarantool
    читать «а лайки — в tarantool»
  • Горизонтальное масштабирование. Что, зачем, когда и как?
    +4
    В общем случае довольно сложно вывести формальную формулу,
    так как нет абстрактной формулы масштабируемости, а всё
    зависит от конкретной задачи, предметной области,
    безнес-требований, выбранного решения и архитектуры.

    Разделение монолита на части не обязательно будет способствовать
    масштабированию.
    1) И это связано с накладными расходами на взаимодействие между
    получившимися частями. Чем интенсивнее взаимодействие, объём
    трафика, количество запросов, тем медленнее будет работать
    система после разделения на части. Отчасти это зависит от
    архитектуры, которая получится в результате. Тесно связанные
    между собой части будет сложнее разделить на отдельные сервисы.
    2) Так же это связано с потерей возможности низкоуровневых
    оптимизаций. В монолитном решении можно сделать более эффективные
    оптимизации. Например можно сделать JOIN двух больших mysql таблиц,
    вместо того, чтобы делать несколько запросов.
    3) Накладные расходы на межсерверное взаимодействие. Если данные
    лежат на одном сервере, или вообще в оперативной памяти одного и
    того же процесса, то получить такие данные можно быстрее, чем из
    оперативной памяти других серверов, к которым нужно ещё сделать
    сетевые запросы.

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

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

    Например если сервис использует две больших MYSQL таблицы с
    JOIN запросом, и для масштабирования потребуется шардинг, то
    из-за этого JOIN запроса шардить просто так не получится. Можно
    расшардить самую большую таблицу, а таблицу поменьше реплицировать
    на все шарды, чтобы JOIN запрос всё ещё мог выполнятся. Но это
    поможет до тех пор, пока не возникнут проблемы и со второй
    таблицей. Поэтому с точки зрения именно масштабирования имеет
    смысл отказаться от JOIN запроса, и использовать например
    последовательные запросы. В этом случае может появиться
    возможность каждую из двух больших таблиц масштабировать
    отдельно, для каждой сделав шардинг. Одну таблицу
    масштабировать проще, чем две связанных JOIN-ом.

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

    В общем случае решение формализовать довольно сложно, так как
    слишком много будет независимых переменных, и чем сложнее и больше
    сам сервис, тем больше их будет, и тем сложнее сами эти переменные
    выявить. Теоретических методики формальной оценки любого по
    сложности сервиса мне не известны. Но на практике обычно всё
    гораздо проще. Нужно всего-лишь понять архитектуру существующего
    сервиса, нарисовать схему, выделить более менее отдельные и
    независимые внутренние компоненты, понять взаимодействие между
    ними, и какой эффект они оказывают с точки зрения нагрузки на
    процессор, память, нижестоящие внешние сервисы, хранилище, базу
    данных и так далее. Дальше останется понять, как можно разделить
    сервис так, чтобы максимально нагруженные части можно было вынести
    на отдельные сервера, учитывая количество и качество связей между
    составными частями. Чащей всего для этого нужно пересмотреть
    архитектуру всего решения с функциональной точки зрения, чтобы
    получившиеся компоненты были законченными по смыслу и логичными,
    чтобы все тесно связанные между собой данные принадлежали бы
    одному и тому же компоненту, а между разными компонентами связей
    было бы сильно меньше. Для новой же архитектуры нарисовать все
    связи, количество запросов между ними, их типы, объёмы данных и
    так далее. Чем проще будут отдельные и независимые, но законченных
    с точки зрения бизнес-логики компоненты, тем проще будет
    предсказать или посчитать создаваемую ими нагрузку, и тем
    проще будет придумать как их масштабирвоать при необходимости.

    Например если взять сервис, который работает с двумя большими
    таблицами MYSQL и использует JOIN, например модуль комментариев
    к статье на сайте с возможностью лайка и дизлайка каждого комментария,
    то разделив этот сервис на два (один работает непосредственно
    с комментариями, а другой обрабатывает лайки и дизлайки), можно
    каждый из них поместить в своё собственное, более подходящее под
    нагрузку хранилище, например комментарии положить в nosql mongodb
    какой-нибудь, а комментарии в tarantool, прикинув по нагрузке,
    что лайкают и дизлайкают чаще, чем пишут и редактируют комментарии.
  • Роботостроительство – делаем базовую платформу для будущего робота
    0
    Когда-то тоже такую платформу находил, поэтому ссылку сохранил, но не на ALI

    http://www.banggood.com/4WD-WIFI-Crosscountry-Offroad-Robot-Smart-Car-Kit-For-Arduino-p-927973.html
  • Регулярные выражения для простых смертных
    0
    3. В коде АТС 1 не может быть третьей цифрой, если вторая цифра – это 1.
    Ваше регулярное выражение уже соответствует первому правилу, но нарушает второе и третье. Пока давайте разберемся со вторым.

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

    Про третье правило забыли :)
  • Часы на ПЛИС Lattice
    +1
    Разрешите добавить ссылки по теме latice и fpga.

    Я долго искал различные workshop'ы на тему fpga, но реально полезных статей и видео по этой теме в разы меньше, чем по теме микроконтроллеров. Поэтому найденные мной ссылки считаю пригодятся.

    Вот тут небольшой обзор платы latice iCEstick iCE40HX1K (low cost fpga dev board, $22, ~1000 логических элементов), обзор verilog под простую задачу реализации сумматора на этом fpga, и обзор набора opensource инструментов для сборки и прошивки этой платы.

    http://hackaday.com/2015/08/19/learning-verilog-on-a-25-fpga-part-i/
    http://hackaday.com/2015/08/20/learning-verilog-for-fpgas-flip-flops/
    http://hackaday.com/2015/08/27/learning-verilog-for-fpgas-hardware-at-last/

    А так же решение задачи реализации PWM сигнала на этой же плате

    http://hackaday.com/2015/12/16/taking-the-pulse-width-modulation-of-an-fpga/
    http://hackaday.com/2015/12/17/pwm-on-the-lattice-icestick/
  • Зачем и как мы бэкапим github
    0
    В случае persistent-хоста — ваше решение лучше.


    Не совсем так. Вы же в один архив все репозитории складываете? Так вот суть в том, что проще тогда даже в случае динамической машины достать предыдущий архив, и разархивировать его целиком, потом обновить существующие репозитории через remote update, и добавить новые через mirror, удалить ненужные, и опять заархивировать.
  • Зачем и как мы бэкапим github
    +2
    cmd = 'git clone --mirror %s:%s@bitbucket.org/%s/%s.git %s' % (username, password, owner, slug, sub_dir_name)


    Я бы не рекомендовал использовать пароль от аккаунта для этого.
    И в github и bitbucket можно добавить deployment key, который работает для read-only операций с репозиторием. С его помощью можно склонировать репозитории, но нельзя пушить и делать деструктивные действия.

    С другой стороны, если сам список репозиториев в bb нельзя получить без пароля (не знаю, есть ли там oauth и т.п.), тогда это не так важно.

    Ещё я бы рекомендовал хранить локальный кеш репозиториев, тоесть сохранять все репозитории с предыдущего бекапа. Это позволяло бы не делать каждый раз clone --mirror, а делать git remote update. Таким образом выкачивались бы каждый раз только новые коммиты и изменения в репозиториях, а не целиком все репозитории со всеми ветками с нуля. Для крупных репозиториев это работает существевнно быстрее.

    В остальном нормальное решение, сам так делаю.
  • Российские светодиодные лампы Лисма
    0
    Смотря какую проблему вы хотите решить лампами более 8 Вт
    Возможно вам подойдёт адаптер разветвитель на 2 лампочки. Это такой цоколь-переходник с одной дырки например E27 на две дырки E27.
    Можно купить две лампы 8Вт, купить такой перходник, и получить почти что 16Вт лампу.
    Единственный минус этого решения, что оно получится в два раза дороже и не под каждую люстру.
  • Российские светодиодные лампы Лисма
    +1
    Спасибо большое, это очень круто!
  • Российские светодиодные лампы Лисма
    0
    Ещё очень не хватает в таблице такой характеристики как R9 компонент в CRI.
    Я купил как раз Лисму, и удивился, что цвет кожи выглядит неестественно при освещении комнаты этой лампой, именно что белее, чем при других лампочках.
    После этого стал изучать вопрос, и только после этого узнал вообще что такое R9 и что такое CRI.
    На мой субъективный взгляд, это важно.
    Хотя, нужно какое-то время попользоваться такими лампочками, чтобы понять разницу. Возможно это просто дело привычки, и через какое-то время эта проблема перестанет беспокоить.
  • Российские светодиодные лампы Лисма
    +2
    «Упаковку видимо заказывали заранее, поэтому там есть ошибки. На коробках для 6- и 8-ваттных ламп указан световой поток 710 и 850 Лм, а в инструкции и на сайте производителя — 630 и 780 Лм.»
  • Российские светодиодные лампы Лисма
    +1
    Долго выбирал лампы, но не смог понять, какой у них коэффициент пульсации
    lamptest.ru/review/lisma-sdf-8vt
    «измеренный коэффициент пульсации, % Н/Д»
    в таблице же это значение округляется до ноля
    Вы не могли бы прокомментировать или обновить данные?

    Кроме того интересно было бы сравнить с показателями пульсации/цветового_охвата/угла для люминисцентных ламп. Сейчас в таблице таких данных нет. Выбираю замену именно люминисцентным лампам, поэтому и возник такой вопрос.
    lamptest.ru/review/ecola-candle-dimmable-c4dw11ecb
    lamptest.ru/review/ecola-spiral-mini-half-selm-9w-e27-2700k-220-240v-50-60hz
    lamptest.ru/review/ecola-light-spiral-elh-15w-e27-2700k-220-240v-50-60hz
    lamptest.ru/review/navigator-nclp-sf-11-827-e14
  • Учёные подробно разглядели структуру, которой бактерии пользуются для принятия решений
    0
    Не хватает видео. Когда всякие микробиологические процессы показаны с помощью 3d-моделирования, даже для неподготовленных людей становится много понятно. А так вряд ли кто-то будет читать сам отчёт, хотя наверняка он интересный, но боюсь сложноват для понимания обычными людьми :(
  • Еще одни часы или когда обидно за микроконтроллер
    0
    Конечно. Я не сразу заметил внешний кварц.
  • Еще одни часы или когда обидно за микроконтроллер
    0
    Вы правы. Я был не внимателен, и не сразу заметил внешнего часового кварца на вашей схеме.
    Цитата из даташита и весь мой комментарий был не про кварц, а про внутренний RC-генератор.
  • Еще одни часы или когда обидно за микроконтроллер
    0
    Тоже хочу упомянуть про RTC

    В даташите на atmega8 написано про точность внутренних RC часов, что точность у них с учётом программной корректировки — 1%

    «At 5V, 25C and 1.0MHz Oscillator frequency selected, this calibration gives a frequency within ±3% of the nominal frequency.
    Using run-time calibration methods as described in application notes available at www.atmel.com/avr it is possible to achieve ±1% accuracy at any given VCC and Temperature.»

    Это значит, что за сутки такие часы могут давать погрешность в 14 минут.
  • Зачем нужны бои роботов?
    0
    В правилах написано, что да.

    Разрешено ли выбрасывать сеть или цепи на других роботов?
  • Как начать разрабатывать железо, используя ПЛИС — пошаговая инструкция
    0
  • Как начать разрабатывать железо, используя ПЛИС — пошаговая инструкция
    0
    А книжка в итоге вышла? На сайте ничего такого не нашёл.
  • Программирование Arduino в CLion
    0
    Потому что в github.com/queezythegreat/arduino-cmake нет поддержки arduino ide 1.5+
    Пробуйте github.com/altexdim/arduino-cmake
  • MOOC курсы по робототехнике
    0
    Дополню про Control of Mobile Robots

    Практические задания выполняются в симуляторе, который можно подключать и к реальному роботу по wifi.
    Кроме матлаба можно использовать другой симулятор на python — pysimiam.sourceforge.net/coursera.html
    Железная составляющая в последствии была вынесена в отдельный проект o-botics.org
    Оригинальный робот собирается на BBB, но можно попробовать собрать и на Arduino
    github.com/altexdim/arduino-bluetooth-quickbot

    Курс очень понравился, как и практические задания и хардварная часть.
  • Ускоряем MySQL insert/update в 5-10 раз
    0
    Вы какой тип индекса указали, когда MEMORY-таблицу создавали: hash или btree?
  • Программирование Arduino в CLion
    +1
    Добавил экспериментальную поддержку Arduino IDE 1.6, благодаря готовым pull requests из оригинального проекта, и написал README.txt с деталями по установке и настройке github.com/altexdim/arduino-cmake
  • Программирование Arduino в CLion
    +1
    Уточнения и дополнения:

    Проблема в пункте 2.1 решена этим pull request'ом
    github.com/queezythegreat/arduino-cmake/pull/109

    Поддержка 1.5 заявлена в этом pull request'е
    github.com/queezythegreat/arduino-cmake/pull/104

    И форк оригинального arduino-cmake с поддержкой 1.5
    github.com/blemasle/arduino-cmake
  • Программирование Arduino в CLion
    +1
    Расскажу о том, какие могут возникнуть сложности с настройкой JetBrains CLion + Arduino + Windows 7, и как их решать.

    1) CLion под Windows требует выставить правильное окружение в настройках
    File -> Settings => Build, Execudion, Deployment -> Toolchain
    Правильные настройки можно увидеть на скриншоте
    habrastorage.org/files/d67/ba0/bb6/d67ba0bb63a54794abb5ed049a3dc4fb.png
    Так вот там есть две опции MinGW и Cygwin.
    С cygwin ничего не получится, так как при запуске через cywgin пути в системе меняются на /cygdrive/c/…
    и при попытке скомпиллировать ваши исходники avr-g++ сразу же будет жаловаться на то, что файла
    с исходниками она найти не может. Другими словами make из cygwin работает с путями /cygdrive/c/, а
    весь toolkit из Arduino IDE нет, им нужны обычные пути c:\…
    Поэтому нужно поставить MinGW

    1.1) Сначала нужно скачать его по ссылке sourceforge.net/projects/mingw/files/Installer
    Тестировалось на версии mingw-get-0.6.2-mingw32-beta-20131004-1
    Затем установить с дефолтными настройками

    1.2) Запустить MinGW Installation Manager

    1.3) Выбрать пакеты для установки из Basic Setup
    — mingw-developer-toolkit
    — mingw32-base
    — mingw32-gcc-g++
    — msys-base
    и нажать Apply Changes

    2) В переменную окружения Path можно ничего не прописывать (несмотря на инструкцию с github.com/queezythegreat/arduino-cmake)
    И даже более того, возможно потребуется даже убрать лишнее.

    2.1) Есть проблема со сборкой через cmake, если в путях прописана Anaconda (https://store.continuum.io/cshop/anaconda/)
    А по-умолчанию anaconda прописывается в путях, чтобы можно было вызывать python из командной строки.
    Так вот в anaconda есть свой toolkit с make и прочими вещами, поэтому arduino-cmake находит не путь к Arduino SDK, а путь к Anaconda
    По аналогии такие проблемы могут возникнуть с любым другим софтом
    Решается такая проблема исключением из путей (как из переменной windows окружения Path для пользователя так и для системы)
    Но это не всё, после этого нужно почистить кеш cmake
    %USERPROFILE%\.clion10\system\cmake\generated\*

    2.2) В Arduino SDK есть файл sh.exe, о котором может предупредить CLion на той же странице настроек toolchain'а.
    Поэтому и путь к Arduino SDK тоже нужно исключить из путей окружения windows

    После решения этих двух проблем, JetBrains CLion + Arduino нормально работает на Windows 7.
    А для коннекта к COM порту можно использовать PuTTY + Pageant с сохранёнными настройками для используемых COM портов.

    Но так же остаются пока не решённые проблемы.

    3) arduino-cmake не работает с последними версиями Arduino (тестировалось на 1.6.1 и 1.6.3)
    Это можно решить, подправив нужным образом cmake файлы, но пока эта проблема не решена.
    Почему это проблема — в последних версиях Arduino IDE более новый toolkit, и в частности
    некоторые конструкции C++ не работают в Arduino IDE 1.0.6, а в 1.6.1+ работают.

    Так что если кому-то удалось их решить, буду признателен, если поделитесь своим опытом.
  • Собираем Wi-Fi робота
    +1
    А вы не могли бы замерить ток, который потребляет робот в различных режимах работы (езда, видео, стоянка на месте и т.д.)?
  • Собираем Wi-Fi робота
    0
    На сколько хватает одного заряда батареек? По моим расчётам, у вас должно получиться 1.5-3 часа.
  • Быстрый старт ST Nucleo-F401 + краткое руководство
    0
    Если конкретно про помощь в осмыслении, то

    — программатор ST-LINK/V2-1 потребляет около 45-50мА — это я замерил
    — USB устройства без драйверов могут потреблять не более 100мА — это стандарт USB
    — после загрузки драйверов USB устройства могут потреблять полную мощность порта, до 500мА USB2.0 и до 900мА USB3.0, но STM32 Nucleo запрашивает только 300мА на этапе подключения к USB, поэтому 300мА — это максимально разрешённый ток для всего устройства на базе STM32 Nucleo.
    — STM32 Nucleo не будет работать без драйверов, так как питание на сам микроконтроллер не будет поступать до полного подключения к USB, тоесть до согласования с USB-хостом и загрузки драйвера. Несмотря на то, что 100мА хватит на питание как программатора, так и микроконтроллера вместе взятых.
    — Если хочется всё же запустить STM32 Nucleo без драйверов, то нужно просто поставить перемычку JP1. Питание работать будет, перепрограммировать контроллер вы не сможете.
  • Быстрый старт ST Nucleo-F401 + краткое руководство
    0
    ST-LINK/V2-1 поддерживает управление питанием через USB, позволяя запрашивать более 100мА.
    Все части платы STM32 Nucleo и шилдов могут питаться от USB разъёма ST-LINK CN1 (U5V или VBUS).
    Заметьте, что программатор ST-LINK — это единственная часть платы, которая питается до того, как плата выполнит согласование с USB-хостом (другими словами до того, как загрузится драйвер USB устройства).
    Во время согласования с USB-хостом STM32 Nucleo запрашивает 300мА.
    Если компьютер способен предоставить запрашиваемую мощность, тогда питание поступает на сам микроконтроллер STM32 и загорается красный светодиод LD3, таким образом STM32 Nucleo и шилды могут потреблять не более 300мА.
  • Espruino Pico: миниатюрная плата разработчика с JavaScript поможет быстро освоиться в мире электроники
    +1
    Если у неё будет поддержка онлайн редактора MBED, и можно будет не использовать JS и штатную IDE, а для заливки использовать копирование на фейковую флешку, то получится аналог nucleo f401re, только в миниатюрном корпусе и на несколько долларов дешевле, так что можно и купить.
  • ZeroNights 2014 — hackquest
    0
    Задания по типу распределились в следующем порядке: 1 — Alighieri (reverse), 2 — Chip-in-the-middle (misc), 3 — InfectedTerminal (reverse), 4 — Yolochka (pentest), 5 — M-Nature (reverse), 6 — Kyrai (web, networking), 7 — private bank haxing (misc).


    А Kyrai не будет?
  • ZeroNights 2014 — hackquest
    0
    После подсказки стало понятно, спасибо