Jump to content

    

one_eight_seven

Участник*
  • Content Count

    1355
  • Joined

  • Last visited

Community Reputation

0 Обычный

2 Followers

About one_eight_seven

  • Rank
    Профессионал
  • Birthday 11/11/1983

Контакты

  • Сайт
    Array

Информация

  • Город
    Array

Recent Profile Visitors

8339 profile views
  1. Оригинальные работы на русском могут быть хорошими. Хороших переводов я ещё не видел. Читаешь книгу в английском варианте и в русском переводе, и чем дальше от введения, тем чаще книги совсем о разном. Её же не профессионалы из области программирования переводят, а в лучшем случае - профессора наших ВУЗов, которые ни одной собственной программы не написали за всю жизнь - только примеры из самоучителей.
  2. Это, кстати, минус : ) Но книга хороша. Ещё мне понравилась modern c for 21st century. Она проста для чтения, и не особо фундаментальна. Но в ней сказаны очень правильные вещи, "как этим вашим C пользоваться", как себе песочницу построить и т.п.
  3. То же, что и в C. Есть прототип функции, есть вызов, но нет реализации. Функция - конструктор Debounce(...), вызов - инстанциирование объекта Button.
  4. Есть объявление, нет реализации.
  5. Ну питон тем и хорош, что там это можно не делать эти кольцевые буферы, парсеры: оно уже сделано. В C тоже, но почему-то в C главенствует парадигма: "языку уже 50 лет, поэтому всë нужно делать с нуля", - что, конечно же не так : ) 0
  6. С одной стороны вы восхищаетесь питоном, с другой стороны вот это вот. Как это уживается у вас в одной голове? :-D
  7. Парсер - это, как правило, работа с регулярными выражениями. Они не бывают читаемыми. Я бы посоветовал сгенерировать парсер с помощью flex+bison, елси очень уж хочется именно на C.
  8. Для ci комфортно - чтобы тесты проходили минут за 10 (не вся регрессия, разумеется). Иначе, стоит попробовать другие подходы.
  9. Чтобы "сломать" красивую идею CI не обязательно идти так далеко, как в P&R. RTL тоже сам собой не пишется - это человеческий труд. А CI - это то, как его обложить тестами.
  10. На самом деле странный вопрос. А как вы себе представляете раздельную разработку? У тебя вот тут счётчик странный, давай я тебе "впаяю" туда регистров побольше? Или вот тут автомат не концептуальный, давай я на комбинационный дежифратор поменяю? Есть требования, есть интерфейс взаимодействия - каждый работает согласно этих правил. На находите, что смысл никак не меняется?
  11. Так оттуда и берутся. Иногда поблема разделения труда - не решена. Например, оба добавили свои блоки в общий файл сборки, например, в Makefile. Ну, ещё бывают уникальные снежинки, которые узнали о командах, git: rebase, vommit --amend, push --force, но как работает git, и что делают эти команды - не знают, но имеют жгучую потребность ими пользоваться
  12. Маршрут ci напрямую зависит от инструментов. Я использую Jenkins. От классического ci отличие в том, что коонвейер сборки может ломаться, и будет ломаться, особенно на ранних стадиях проекта. Схема ветвления - все пушат в мастер. Локально можно хоть сотней веток обмазатьмя, но я за это бью по рукам, потому что, если это приводит к "окукливанию" инженера в своей ветке, то это приводит к проблемам интеграции этой ветки в общий маршрут, особенно на ранних стадиях, когда многое меняется. Работать разным людям над одним куском кода - нежелательно, если только это не парное программирование (но оно и не приводит к конфликтам), но иногда это необходимо, хоть я всегда воспринимаю это как сигнал о том, что нужно большее дробление.
  13. Ещё может оказаться, что к серверам СХД подключено через гигабитный ethernet, и всё в него упирается.