• С++ Когда можно переходить на изучение?

    Adamos
    @Adamos
    К STL - после того, как освоитесь с шаблонами. Иначе запутаетесь.
    К WinAPI - лучше вообще никогда.
    Ответ написан
    1 комментарий
  • Почему c++ неправильно считает?

    @DeOxygen
    Потому что ты выводишь каждый шаг цикла . Постав std::cout за пределы цикла
    #include <iostream>
    using namespace std;
    int main() {
       int s, i;
       s = 8;
        for (i = 2; i <= 8; i++)
        {
            s = s + 8;  
        }
     cout<<s;
    }
    Ответ написан
    1 комментарий
  • Что такое навыки программирования, "программистские скиллы", и почему они утрачиваются?

    Zifix
    @Zifix
    Barbatum
    Мозги засыхают.

    Вроде задача простая, а начинаешь жестко тупить, и убиваешь на неё времени в разы больше, чем раньше. Я встречал человека, который в разговоре перепутал класс и объект (не оговорка), хотя в своё время был хорошим программистом.

    Вернуть навыки можно, но, в зависимости от длины перерыва, придется практиковаться от месяцев до лет, плюс подтягивать отставание от развития библиотек и языков.
    Ответ написан
    3 комментария
  • Кто работал с two wire interface (I2C), почему так сложно получить подтверждения передачи адреса и данных?

    @vanyamba-electronics
    Почему-то подтяжки, встроенные в ATmega, с интерфейсом TWI не работают. Нужно физические резисторы добавить.
    Ответ написан
    6 комментариев
  • Уехал в Москву, но не тяну по сложности, стоит ли возвращаться домой?

    qlkvg
    @qlkvg
    python backend developer
    Был в похожей ситуации года 3 назад, только без обрубания концов и релокации. Совсем не тянул, спрашивал мелочи у коллег и стыдился, ничего не понимал. Хотелось все бросить и вернуться на прошлое место работы, где можно было спать до обеда. В итоге через 3 месяца ада, ощущения собственной ничтожности и штудирования книг в любой удобный момент, что-то начало получаться. В итоге дорос до человека, у которого джуны спрашивают мелочи.
    Сейчас понимаю, что первые несколько месяцев нужно было просто пережить. Это нормально для зеленого новичка в индустрии. Если вы не устроились на позицию сеньер фул-стека, адекватный работодатель не будет от вас требовать мгновенного результата. Если переживаете, честно поговорите с непосредственным начальником, что не вывозите, нужно время на раскрутиться
    Ответ написан
    4 комментария
  • Какие самые нужные, общие знания в программной инженерии и embedded разработке?

    32bit_me
    @32bit_me
    Программист, встраиваемые системы
    Я занимаюсь эмбеддед-разработкой очень много лет (лет 20 примерно), и если я мог бы выбирать сейчас, я бы выбрал просто программирование. По одной простой причине - больше платят. Раньше я разрабатывал и железо, и схемы, и платы, и вообще делал всё, вплоть до испытаний и документации, но уже много лет я всем этим не занимаюсь, а занимаюсь только кодингом, по той же причине - больше платят.
    В целом, если вы хотите именно в эмбеддинг, начните с микроконтроллеров семейства Stm32, купите недорогую плату Discovery или Nucleo и разбирайтесь. Также необходимо будет знать основы схемотехники. Даже если вы не будете сами разрабатывать схемы, всё равно придётся разбираться с готовыми схемами, и нужно будет полностью понимать, как что работает. Уметь держать паяльник и работать с осциллографом также будет большим плюсом.
    Потом можно будет освоить FPGA и язык Verilog, но это очень на любителя и только при большом желании, потому что с зарплатами тут вообще печаль.
    И да, английский нужен обязательно, без вариантов. Чтение технического текста свободно, быстро и без словаря - в любом случае, разговорный - только для международных компаний или при работе на иностранного заказчика, но это как раз самое вкусное. Так что английский нужен.
    А так, программирование, оно и есть программирование. Языки: С - чаще всего, С++ - иногда, С# и другие - для "верхнего уровня", но тоже не помешают. Алгоритмы могут спросить на собесе, но сильно их заучивать не стоит. Более важен практический опыт, чем теория. Операционные системы - для верхнего уровня - Windows, Linux, для нижнего - различные РТОС или "голое железо". В мощных железках - Linux, так что с ним лучше дружить очень хорошо.
    Ответ написан
    4 комментария
  • Какие самые нужные, общие знания в программной инженерии и embedded разработке?

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

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

    Третье самое важное знание для разработчика - это философия. В любом продукте есть философия. Философ сказал бы, что любой продукт - это просто плод философии разработчика. Apple, Google, Microsoft - это не только разные технологии, но и разные философии. Даже когда они создают свои продукты под одну и ту же технологическую базу, разница в философии разработки делает их продукты настолько непохожими на другие.

    Четвёртое самое важное знание - это физика. Математика, философия - всё это спокойно может работать и на бумаге, но физику не обманешь. Любое устройство - это объект физического мира, и живёт по законам этой Вселенной.

    Пятое самое важное знание - это религия. Как разработчик лично я постоянно сталкиваюсь с тем, что мой проект кто-то может просто объявить аморальным явлением.
    Почему? - спрашиваю я.
    Потому что ты аморальный человек, - отвечают мне, и с этим ничего не поделать - потому что потребитель верит не аморальному мне, а этому святому человеку. Он старушек через дорогу переводит, а у меня очередной дедлайн.

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

    Может сложиться образ эдакого супермена в голове читателя. Но тут важно понимать, что любое явление обладает набором параметров. Допустим по первому свойству у вас 3, по второму 4, зато по 5+. Это делает вас как разработчика непохожим на других разработчиков. И если для какого-то проекта нужно подтянуть английский, например, то приходится подтягивать по ходу.
    Ответ написан
    5 комментариев
  • Как вы читаете литературу по программированию и запоминаете?

    QQQ-RRR
    @QQQ-RRR
    После прочтения применять практику по прочитанному или конспектировать например ручкой на бумагу
    Ответ написан
    Комментировать
  • Почему я должен писать именно так, а не иначе?

    jcmvbkbc
    @jcmvbkbc
    http://dilbert.com/strip/1998-08-24
    Почему я не могу убрать скобки, или ещё что-нибудь, и написать так, как мне хочется. В общем, где все это определено?

    Это определено спецификацией языка на котором вы пишете. Среди прочего она определяет грамматику языка (т.е. как можно писать) и семантику языковых конструкций (т.е. что написанное так или иначе обозначает).
    Ответ написан
    Комментировать
  • Что делать если youtube занимает слишком много времени?

    CityCat4
    @CityCat4
    Жил-был у бабушки серенький троллик...
    Почему прокрастинаторы прокрастинируют...

    Заблокируйте ютуб.
    Заведите девушку :)

    Эти два совета при всей их феноменальной глупости - помогут. Девушки требуют постоянного внимания... и денег :) Здоровый секс требует хорошей физической формы. Все это требует времени, времени и времени - на трубу его просто оставаться не будет. А если будет - не будет оставаться сил :D
    Ответ написан
    8 комментариев
  • Что делать если youtube занимает слишком много времени?

    Kadzi
    @Kadzi
    Ом
    Тут речь о мягких навыках, в частности про управление собой и концентрацию.

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

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

    Вот например, чтобы изучить что-то основательно, нужно курить 3-4 часовые видео + практика, но в реалиях такого энтузиазма мало у кого есть, поэтому, как вариант начать с 5-15 минутных видео. Просто начать.

    У меня была точно такая же история, только вместо ютуба я читал тостер)))) Понимая, что не могу с собой ничего поделать, я начал просматривать по 300-400 советов из разных тематик ежедневно в том числе рубрики в которых я полный ноль. А позже я культивировал полезный поиск + сбор полезных материалов, в том числе из комментариев.

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

    В один момент, я понял, что хочу углубляться по вопросам и перескочил с тостера на видео, книги и практику. Начинал так же, с банальных вещей, которые культивировал. Например, что такое цвет? И по 15-20 мин ежедневно что-то читал, смотрел изучал, пока не захотелось это делать по 30 мин в день. некоторые вещи я хочу делать теперь по 3-4 часа в день.

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

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

    Мягкие навыки 1
    мягкие навыки 2
    40 правил философии ответственности обрати внимание на 2 правило
    теория психики
    рекомендую его заметки

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

    0. Никаких резких перемен не будет.
    1. Почитать про софт скилы и что формирует их.
    2. Продолжить смотреть ютуб, разбавив ежедневной рубрикой "полезные 15 минут"
    3. Окружить себя инфополем текущего уровня, пока не захочется на следующий. А захочется, так как эти 15 минут превратятся рано или поздно в 20, а потом в 30. Культивация полезного действия.
    4. Попав на новый уровень, проделать тоже самое.

    Культ полезного действия применим к любым жизненным ситуациям. Учиться учиться, учиться правильно читать, искать, серфить, смотреть и слушать. Это тоже навык.
    Ответ написан
    Комментировать
  • Есть ли русскоязычный сайт знакомств для удаленщиков?

    PavelK
    @PavelK
    Зачем ещё один? Порнхаб же уже есть, особенно если до комментов пролистать.
    Ответ написан
    Комментировать
  • Объясните алгоритм чисел Фибоначчи?

    hint000
    @hint000
    у админа три руки
    Не зная, что такое рекурсия и как она работает в программировании, вы не сможете понять любой рекурсивный алгоритм, даже такой простой, как этот (проще только рекурсивный алгоритм вычисления факториала). Не зная, как работает стек - в принципе понять рекурсию можно, но не полностью.
    Так что курите рекурсию и стек до просветления.
    Ответ написан
    Комментировать
  • Какой новый полезный язык программирования или технологию изучить?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Самая частая причина снижения когнитивных способностей одновременно самая банальная - недосыпание.
    Ответ написан
    Комментировать
  • Насколько подробно в резюме стоит указывать навыки?

    Madeas
    @Madeas
    UI / UX Designer, Frontend Developer
    Можно написать что-то вроде "Дополнительно владею: ..." или "Изучаю". Лишним точно не будет. Это ваши плюсы, пусть и маленькие.
    Ответ написан
    Комментировать
  • Как логично и структурно именовать переменные?

    dollar
    @dollar
    Делай добро и бросай его в воду.
    В английском языке существительные в начале превращаются в прилагательные, а в конце - существительное, к которому они относятся.
    Сравните: "stone wall" (каменная стена) и "wall stone" (камень из стены).

    То есть первым делом нужно определиться с главным существительным, то есть ЧТО имеется в виду. Если это имя, то название переменной должно оканчиваться на _name (или Name в зависимости от стиля).

    Далее, если не придираться к правилам, то последовательность прилагательных лучше делать так: чем важнее, тем ближе к существительному.
    Шаг первый: product_name
    Шаг второй: homepage_product_name (при этом вам должно быть очевидно, что не home_page)

    Далее, ничего лишнего быть не должно, и должно максимально точно отражать суть. Например, настройка, говорящая о том, что уведомления можно посылать только если приложение неактивно.
    Не правильно: notify_if_inactive (вообще не понятно, не логично)
    Правильно: is_notify_if_inactive_only
    Приставка is_ в данном случае является соглашением в нашей команде, указывающем, что это булева переменная, можно также юзать b_ например для той же цели. Или, скажем, если это константа или меняется очень редко, можно записать капсом или добавить приставку c_

    Вообще дальше уже начинаются тонкости и вкусовщина. Основные принципы изложены выше - это четкий порядок построения и соответствие сути.
    Ответ написан
    Комментировать
  • Стоит ли учить JS или Java если поступаешь на Software Engineering?

    @ikfah012
    Не самый умный парень в этом чате
    Вы если хотите именно на software engineer, то зачем вам веб-разработка? Вы будете заниматься более глубокими и фундаментальными вещами. Языков вам будут преподавать не меньше 5, но как уже выше говорили, более-менее разбираться вы будете только в одном (в зависимости от вуза - c++ или java или python), заодно познакомитесь с лоу-левел разработкой. Вы получите фундаментальные знания по всему, что вам нужно знать о разработке и тогда разобраться за пару месяцев с javascript вам не составит труда.
    Насчёт того, что сложнее - java или js сказать трудно, т.к. это разные языки с разным подходом и разными областями применения. Освоить основы js будет проще, т.к. все скрипты обрабатываются браузером без установки виртуальных машин и т.п. Хотя, я встречал проекты, сервер которых был полностью на нативном js, т.е. при желании этот язык тоже может быть универсальным.
    А так по-хорошему вам бы определиться с тем, что вы хотите делать. Потому что вы скачете от фронтенда с html и css до java и алгоритмов.
    Ответ написан
    Комментировать
  • Каков предпочтительный стиль / оформление исходного кода на C#?

    dmitry_pavlov
    @dmitry_pavlov
    World-class .NET freelance contractor (remotely)
    • Можно многое почерпнуть о правильной организации кода из предупреждений FxCop.
    • Про навигацию - один класс - один файл. Имя файла == название класса.
    • Partial classes меновать следует так чтобы срабатывал File Nesting.
    • Если сильно хочется иметь "table of content" - можно чаще объявлять интерфейсы и ориентироваться по ним.
    • Есть также базовая навигация по коду.
    • Ну и, если пользуетесь, средства навигации по коду от ReSharper.
    Ответ написан
    Комментировать
  • Как вы освоили шаблоны проектирования?

    dmitry_pavlov
    @dmitry_pavlov
    World-class .NET freelance contractor (remotely)
    Когда начался бум и восторг вокруг концепции паттернов проектирования, выкрики "GoF рулит!" и так далее, я озадачился тем, чтобы понять, что за шум?

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

    По аналогии в проектировании софта имееются свои архитектурные вопросы вроде разбиения приложения на компоненты/модули, организации зависимостей между ними, распределение функциональных обязанностей и т.п. Как ловко подметили авторы книжки из этой банды четырех (The "Gang of Four") в нашей индустрии можно также выделить некоторе количество типовых шаблонов, проверенных на практике, чтобы тем самым не наступать на уже обойденные другими грабли.

    Суть постижения паттернов заключается в том, чтобы осознать в каких ситуациях правильно использовать тот или иной шаблон проектирования и правильно его применить. Важно понимать при этом, что формула "чем больше паттернов я придумал засунуть с свое приложение - тем лучше" - неверная. Использовать их следует с умом и только там, где они действительно нужны. Кроме того, патерны устаревают, превращаются в анти-паттерны по мере развития технологий (которые в нашей области делают это более чем стремительно). Ну и, конечно, есть шаблоны общепринятые и есть те, которые успешно используются в узких кругах.
    Тут тоже надо понимать, что это не догма какая-то - типа 10 священных паттернов проектирования :)

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

    К изучению паттернов я дам такие советы:

    1) Прочтите пару книжек, чтобы понять, что это за зверь и с чем его едят. Можно взять одну из вариаций книжки GoF или какие-то производные для вашего стека разработки - познакомиться с основными популярными шаблонами. Сразу после этого я посоветовал бы прочесть книжку "Горький вкус Java" (Брюс Тейт) - она про анти-паттерны. Это чтобы понять обратную сторону их использования. Мне понравилась и уберегла думаю от многих проблем. То что на примере Java - неважно. Речь идет о шаблонах, так что представителям других стеков (к которым отношусь и я) будет просто понять все равно.

    2) Постарайтесь осознать, доводилось ли вам сталкиваться в работе раньше с чем-то, что является или могло бы легко стать одним из шаблонов. Где получалось применить концепт верно, а где из-за этого только проблемы были.

    3) В новых проектах, держите в голове полученные по шаблонам знания - вдруг пригодятся.

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

    Я даже пожалуй посоветовал бы подойти к освоению айтишной архитектурной мудрости с другой стороны - со стороны нефункциональных требований или так называемых "-ilities" - их много. Тут вот описаны 7 штук. А вообще их десятки.

    Среди прочих - такие как maintainability (простая поддержка кода), scalability (масштабируемость), extensibility (расширяемость), availability (устойчивость ) и тп. Если, проектируя свое приложение, вы задумываетесь об этих "илитях" и стараетесь их обеспечить в необходимом проекту объеме, то, как правило, ваше приложение будет иметь отличную архитектуру. При этом шаблоны проектирования в ней появятся лаконично сами собой.

    Поскольку идея использовать шаблоны - это попытка опытных программных инженеров дать десяток готовых рецептов менее опытным, чтобы пока они не научились варить "вкусную кашу", они не варили уж что-то совсем несъедобное. :) Учитесь "готовить", разбирайтесь в -ilites :) и все будет хорошо
    Ответ написан
    6 комментариев