• Какие можно почитать книги "по самому низкому уровню" компьюетров?

    DexterHD
    @DexterHD
    Software Engineer, Teamlead, CTO
    Сначала читаете
    "Чарльз Петцольд Код - Тайный язык информатики".
    В ней будут даны принципы от изобретения реле до современных процессоров.
    Далее:
    "Э.Таненбаум - Архитектура компьютера"
    "Э.Таненбаум - Современные операционные системы"
    "Э.Таненбаум - Сети"
    Ответ написан
    Комментировать
  • Насколько актуальны данные книги (JavaScript, ООП, Python)?

    rasswet
    @rasswet
    мне понравилась книга Любанович Простой Python
    Ответ написан
    Комментировать
  • Как начать понимать программирование?

    darakanoit
    @darakanoit
    ЯП не является целью, ЯП лишь инструмент как и любой другой язык в мире.(не только it).
    Обычно называют это техническим складом ума - думать по другому.
    Я бы советовал Вам выделить время на логические раздумия над задачами. Когда понимаешь как должно работать это в голове,потом потихоньку переносишь в код.
    Ответ написан
    3 комментария
  • Можете посоветовать книги по IT направлениям?

    peacelovecookies
    @peacelovecookies
    Работаю в команде Hexlet.io
    Начинал читать Кормена, было сложновато, а вот Грокаем алгоритмы хорошо идет. Думаю, стоит с нее начинать и переходить на что-то посложнее.
    Насколько я понял, вы хотите читать литературу, будучи на службе. Так что предполагаю, что практиковаться будет сложно (или невозможно вовсе). Поэтому советую читать литературу больше по базовым понятиям и формировать мышление программиста. От технической информации толку будет не так много, без практики то...

    Вот отличные книги для развития:
    - Джоэл о программировании (Джоэл Х. Спольски)
    - Мифический человеко-месяц, или Как создаются программные системы (Хилл Чапел, Фредерик Брукс)
    - Цель. Процесс непрерывного совершенствования (Элия М. Гольдратт, Джеф Кокс)

    Если все же тянет на техническую литературу, то про сети полезную информацию можно найти в этих книгах:
    - Операционная система UNIX (Андрей Робачевский, Сергей Немнюгин, Ольга Стесик) - глава 6 как раз про сети, если я не ошибаюсь.
    - Руководство администратора Linux (Эви Немет, Гарт Снайдер, Трент Р. Хейн)

    А вообще можете посмотреть список рекомендуемых книг, вдруг что-то понравится.
    Ответ написан
    2 комментария
  • Как правильно использовать строки в плюсах?

    @Mercury13
    Программист на «си с крестами» и не только
    • std::string — как правило, если не указано противное.

    • QString, AnsiString/UnicodeString и прочие — в соответствующих фреймворках, обычно очень близко к интерфейсным функциям.

    • char* — практически не используется в реальном коде. В основном для оптимизации, если есть собственное управление памятью. Довелось как-то в собственном разборщике XML (работает в 2,5 раза медленнее рекордсмена, pugixml. Зато даже это в разы быстрее Excel’я, пространства имён «из коробки», расход памяти мизерный и программирование простейшее.)
    Зато по-чёрному используется его const-аналог.

    • const char*. Это может быть одинокий const char* + нуль-терминированная строка, или указатель+длина, или указатель на начало + указатель за конец.
    1. Если ожидается, что в функцию будем передавать строковый литерал.
    void writeEnum(st::Stream& st, int value, const char* names[]) {}
    
    enum class Letter { A, B, C, …, Z, NN };
    const char* natoNames[static_cast<int>(Letter::NN)] = { "alpha", "bravo", "charlie", … };
    writeEnum(someStream, static_cast<int>(Letter::E), natoName);

    2. Если операцию со строкой можно произвести «на месте», не заводя новую память: (trim, как известно,— обрезка пробелов в начале и конце)
    void trim(const char*& beg, const char*& end);

    3. Если структура данных паразитирует на чужих строках, не заводя своей памяти. Особенно если конструкция строк неизвестна (например, при передаче данных из плагина в плагин).
    struct ParasiteString { const char *beg, *end; };

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

    • char[] — только как оптимизация, когда предельная длина строки известна и невелика.
    wchar_t* myFtos(double value, wchar_t* buf, const FloatFormat& format) {}
    
    wchar_t buf[100];
    myFtos(100.500, buf, FloatFormat::NICE);
    Ответ написан
    Комментировать
  • Какую книгу выбрать?

    @immaculate
    Программист-путешественник
    Думаю, что после первой книги надо начинать что-то делать. Дело в том, что книжные знания, оторванные от реальности ничего не стоят (и моментально забудутся). Только реальный опыт разработки покажет, в какую сторону надо двигаться, и каких знаний не хватает.
    Ответ написан
    1 комментарий
  • Какие книги по сетям передачи данных вы считаете лучшими?

    @zvl
    цикл статей на хабре "сети для самых маленьких"
    а по делу: читайте RFC
    Ответ написан
    Комментировать
  • Как настроить сеть между виртулками в VirtualBox?

    mindtester
    @mindtester
    http://iczin.su/hexagram_48
    и зачем все так сложно?
    вам на хостовой системе, теперь надо добавлять статические маршруты для обеих подсетей
    если хотите предоставить виртуалкам интернет и взаимное общение - проще конфигурировать сетевой мост https://i.imgur.com/r6KJiMl.png
    Ответ написан
    3 комментария
  • Книга о том как правильно должен работать программист?

    nekt
    @nekt
    программист
    1. Самое главное - вовремя ложиться спать, чтобы выспаться и подходить к работе со свежей головой.
    2. Самое главное - фиксить их, когда обнаружили, чтобы в следующий раз не допускать подобных.
    3. Самое главное - в первую очередь делать самое нужное, потому что даже если половина задач не будет сделано, это зачастую не страшно - больше чем можно успеть сделать, все равно не сделать.

    Ну и можно в методологии углубиться, если уж возникают такие вопросы.
    Я бы посоветовал прочитать книжку с описанием XP Кента Бека.
    Ответ написан
    Комментировать
  • Книга о том как правильно должен работать программист?

    un1t
    @un1t
    Чед Фаулер "Программист фанатик"
    Джоэл Спольски "Джоэл о программировании"
    Роберт Мартин "Идеальный программист"
    Том ДеМарко, "Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения"
    Том ДеМарко "Человеческий фактор. Успешные проекты и команды"
    Роберт Гласс "Факты и заблуждения профессионального программирования"
    Игорь Савчук "Отъявленный программист. Лайфхакинг из первых рук"
    Питер Сейбел "Кодеры за работой. Размышления о ремесле программиста"
    Хант Эндрю, Томас Дэвид "Программист прагматик"
    Ответ написан
    1 комментарий
  • Помните сайт - список задач по сетям для Linux?

    @quramolt Автор вопроса
    А всё, сам нашёл. На тостере в похожих вопросах вывелось - nodesquad.blogspot.ru/2013/04/blog-post.html
    Ответ написан
    Комментировать
  • Какие книги по техническому английскому для программирования есть?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    Под "техническим английским" подразумевается достаточный уровень английского, чтобы понимать документацию и уметь загуглить и прочитать ответ на английском.

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

    Просто читайте документацию. Читайте английскую википедию, читайте справку, а английский учите вообще, а не целенаправленно технический.
    Ответ написан
    1 комментарий
  • Нужно Ваше мнение - по какому материалу легче научиться программировать: видео или статьи?

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

    Специалисты, которые так и не удосужились завести привычку быстро читать и понимать прочитанное - это прекрасно. Чем больше их будет, тем выше ценность нас, читающих ;)
    Ответ написан
    6 комментариев
  • Как писать много кода, оставляя его простым, как в начале?

    @dmz9
    не знаю зачем тут пацаны советуют чистый код Р. Мартина
    https://www.ozon.ru/context/detail/id/5011068/
    вот что нужно на замену
    https://www.ozon.ru/context/detail/id/138437220/
    есть обе у меня, но красненькую купил раньше. в ней больше информации как внешне так и по сути.

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

    во многих конвенциях о code-style указываются очень грамотные вещи, и они не просто так там находятся. в общем смысл такой - код должен быть самодокументируемым/самоописательным, а комментарии к коду не должны быть в стиле "моё почтение, капитан!".
    • код должен напоминать хорошую прозу.
    • комменты описывают намерение (зачем?) а не реализацию (как?).
    • прими во внимание время жизни переменной. чем ближе переменная к "месту военных действий" тем лучше. перекликается со временем жизни переменной - чем быстрей "умирает" тем лучше, часто можно даже без переменной обойтись не в убыток читаемости.
    • люди советуют тут ограничиваться конкретным числом строк. имхо - вредный совет. метод не должен ограничиваться. метод должен быть такой длины, которая требуется. иногда без "супер-методов" не обойтись (это не о функциях на 100500 входящих параметров), невозможно просто разбить тяжелую функцию на более мелкие куски, не умножив число запоминаемых переменных/других методов. метод может быть в 3 строки, может быть даже в одну, а может быть в сто-двести строк и более. если из метода ничего нельзя выбросить и нечего добавить - значит он в точности занимает столько сколько нужно.
    • многословие приветствуется но без фанатизма. машине почти всё-равно какой длины у тебя функция (если вы понимаете о чем я), а для тех кому нет - есть минификаторы (для js например)
    • название метода должно однозначно говорить о его назначении. спрашивай себя - зачем этот метод? зачем это свойство? если ты не можешь ответить значит и запомнить/вспомнить не сможешь, значит у метода/свойства нет конкретного предназначения и потом (через какое то время) будет сложно разобраться для чего он вообще нужен.
    • визуально отделяй приватные/публичные методы. это тоже некоторая подсказка которая помогает разбираться в коде.
    • следуй одному стилю как минимум в отдельно-взятом файле. (кемелкейс отдельно, лодаш отдельно).
    • следуй принципу наименьшего удивления (программиста). т.е. поменьше роялей в кустах
    • соблюдай абстракции. если класс это не просто набор статичных методов - значит он описывает какие то действия вполне определенного объекта. не раздувай и не разбивай на несколько классов одну цельную и четкую абстракцию. это поможет сосредоточиться на отдельном куске кода в один момент.
    • старайся не писать рядом в одном классе методы, которые "проникают" во все аспекты приложения (антипаттерн - суперкласс/божественный объект).


    вообще стоит почитать про паттерны и антипатеррны, это конечно не библия но знать хотя бы основные стоит.
    Ответ написан
    2 комментария
  • Книги по электронике с нуля?

    @cap_nemo
    Рудольф Сворень "Электроника. Шаг за шагом". И спать не сможете совсем, так как паяльник врастет в руку :-)
    Ответ написан
    4 комментария
  • Как вы планировали своё учебное время?

    @artemt
    Full-stack developer
    Принципиальная ошибка — не заложено время на повторение. Должно быть каждодневное повторение изученного вчера и более обобщённое через неделю. Желательно ещё и через месяц ещё более общее. Причём именно повторение, основанное прежде всего на попытке вспомнить, а не простом перечитывании заново.

    Ну и да, можно "укрупнить" процесс. В начале больше сосредоточиться на вёрстке, как более простой.

    2-3 часа на книги + блоги слишком много, тем более для начала.
    Ответ написан
    Комментировать
  • Как вы планировали своё учебное время?

    @xfg
    В любом длительном деле главное заинтересованность. Вам нужно начать делать любой интересный для вас проект. В процессе, когда вам требуется сделать то или иное для вашего проекта, вы гуглите, читаете, делаете и даже что-то запоминаете. Изначально по любому вопросу будет требоваться гугл, но очень скоро обнаружите, что уже изучили добрую половину API языка javascript, спроектировали и сверстали несколько UI экранов вашего проекта.

    Радуйтесь маленьким победам. Когда вы делаете интересный лично для вас проект, вы понимаете зачем вы сейчас читаете тот или иной материал. Вы практикуетесь, вы решаете реальные задачи. Я никак не планировал учебное время, я 15 лет назад захотел свой сайт, открыл блокнот, нашел в сети учебник по html читал и сразу делал свой сайт. Потом захотел бекенд и открыл php.net, далее возникло желание, чтобы код был не просто лапшой, а имел какую-то структуру так познакомился с различными фреймворками. Потом захотел, на свой код тесты и так познакомился с TDD/BDD. Далее захотел независимую от фреймворка бизнес-логику и так познакомился с DDD. Ну и так далее.

    Английский учил также. Сразу взял интересную мне статью и запоминал все важные незнакомые в ней слова. Иногда что-то о попадавшихся грамматических конструкциях читал если смысл предложения оставался не понятным зная все слова. Важно то, что я никогда не изучал всё сразу, только то, что нужно мне прямо сейчас, для решения моей задачи.

    Если задуматься, все наши предки делали примерно также. Сначала была задача, а только потом они искали решение этой задачи. Человек захотел подняться в небо и только потом, он искал решение. Не наоборот. И это был не боинг.
    Ответ написан
    Комментировать
  • Как заинтересовать человека(студента) в IT?

    edli007
    @edli007
    full stack, team lead
    Сам не захочет, не начнет. Программирование это ад для обычного человека.
    Ответ написан
    Комментировать
  • Не могу разобраться в книге Герберт Шилдт C++. Ошибка в книге или в VS?

    Это особенность студии. Чтобы окно сразу не закрывалось, нужно добавить в настройках:
    Properties>Configuration Properties>Linker>System=Console
    Отвечая на вопрос, в книге нет ошибки, например, под Линуксом этого нюанса нет.
    Ответ написан
    Комментировать
  • По какой книге учить язык си?

    ThePyzhov
    @ThePyzhov
    iOS Ninja
    The_C_Programming_Language_Book_2th_Ed.j
    Ответ написан
    Комментировать