• Как развиваться в программировании не привязываясь к языку?

    myjcom
    @myjcom
    Clean Code: A handbook of software craftsmanship / Чистый код: Создание, анализ и рефакторинг
    Год издания: 2013
    Автор: Robert Martin / Роберт Мартин
    ISBN: 978-5-496-00487-9

    The Clean Coder: A Code of Conduct for Professional Programmers / Идеальный программист. Как стать профессионалом разработки ПО
    Год издания: 2012
    Автор: Robert C. Martin / Роберт Мартин
    ISBN: 978-5-459-01044-2

    Алгоритмы. Справочник с примерами на C, C++, Java и Python
    Год издания: 2017
    Автор: Хайнеман Д., Поллис Г., Селков С.
    ISBN: 978-5-9908910-7-4

    Design Patterns. Elements of Reusable Object-Oriented Software/Приемы объектно-ориентированного проектирования. Паттерны проектирования
    Год издания: 2015
    Автор: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides/Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж
    ISBN: 978-5-496-00389-6

    Test-driven development by example / Экстремальное программирование. Разработка через тестирование
    Год издания: 2017
    Автор: Kent Beck / Кент Бек
    ISBN: 978-5-496-02570-6

    Грокаем Алгоритмы. Иллюстрированное пособие для программистов и любопытствущих
    Год издания: 2017
    Автор: Бхаргава А
    ISBN: 978-5-496-02541-6

    Алгоритмы. Теория и практическое применение
    Год издания: 2016
    Автор: Стивенс Род
    ISBN: 978-5-699-81729-0

    прочитать нужно все

    ну и на закуску
    C Unleashed / Искусство программирования на C. Фундаментальные алгоритмы, структуры данных и примеры приложений. Энциклопедия программиста
    Год: 2001
    Автор: Heathfield R., Kirby L. / Хэзфилд Р., Кирби Л.
    ISBN: 0-672-31896-2 / 966-7393-82-8
    Ответ написан
  • Путь в математику. Существует ли аналог Ландсбергу?

    @southsoutheast
    Мне интересно.
    Не поручусь за "общее знание математики" (очень уж абстрактный запрос), но попробуйте посмотреть книги Я. И. Перельмана "Занимательная алгебра", "Занимательная геометрия" (и другие его книги, если понравится).
    Мне лично очень нравился "Удивительный мир чисел" (Кордемский Б.А., Ахадов А.А.).
    Еще отличная серия "Библиотечка «Квант»" (там и физика, и математика), да и сам журнал "Квант" тоже.
    Ответ написан
  • Выбор фреймворка для нового проекта - Angular? React? Vue?

    dom1n1k
    @dom1n1k
    Лично для меня Vue - это такой "фреймворк с человеческим лицом".
    В целом JS-мир похож на поле боевых действий, где постоянно то налеты авиации, то кононада гремит, то хипстерская конница с новым логотипом на знамёнах проскачет.
    А "обычный" человек сидит в подвале, обхватив голову руками, и думает - мама дорогая, куда я попал, и чё ваще вокруг происходит?
    Какие-то новые паттерны, подходы, языки... Раньше, чтобы начать, достаточно было блокнота и браузера. Пишешь hello world и сразу его видишь. Теперь нужно поставить ноду, овер 9000 пакетов, десять транспиляторов, таск-менеджеров и бандлеров. Пока увидишь рабочий результат - поседеешь.
    И вдруг какая-то добрая душа взяла у хипстоты всё самое лучшее и разумное, что та родила, но очистив от лишних абстракций и усложнений - и выкатила велосипед в виде велосипеда, а не турбо-космолета с инструкцией толщиной как "Капитал". И снова можно писать в блокноте и смотреть в браузере. При этом почти не проигрывая в возможностях.
    Ответ написан
  • Что посоветуете почитать для левелапа в JS?

    @AntonDrelin
    Список книг:
    • "ES6 и не только" Кайл Симпсон. - очень хорошая книга, достойна чтобы просто прочитать, переведена достаточно хорошо.
    • Learning JavaScript Design Patterns автор Addy Osmani примеры правда большинство относятся к ES5, что можно подчерпнуть как там выглядить паттерны, ну какой должен быть хороший стиль, очень хорошая книга


    Ещё один способ, берет библиотеку jQuery и разбирайте её на части)) очень интересное штука и занимает многие вечера. Но пользы будет очень много. Ибо когда-то это библиотечка произвела фурор)
    Ответ написан
  • Тупиковое и медленное развитие, лекарство?

    Konstantin18ko
    @Konstantin18ko
    Стоматолог
    Хочешь быстро выкачивать в продакшен? Вруби режим Vanille. Пиши, параллельно свой проект. Зацепись за один язык как основной и дальше учи всё в нем вдоль и поперёк. Затем, как всё выучишь, хватай самый сложный фраемворк и от сложного к простому начинаешь разбирать. Это мой подход.
    Для наглядной статистики: я врач, у меня 8 часовой рабочий день. С сентября 2016 начал изучать PHP и JavaScript. С 1 января по 9 января 2017 пишу програму которая помогала мне писать истории больных. Сейчас программа пользуется популярностью и ей пользуется вся ординаторская. Сейчас проект переписывается на Symfony 3.
    Что мне понадобилось: время после работы, интернет.
    Ответ написан
  • Тупиковое и медленное развитие, лекарство?

    voronkovich
    @voronkovich
    Нужно позволить всякому шлаку проплыть мимо вас. Не нужно вкладывать много времени в изучение того, что завтра изменится. Лучше тратить время на фундаментальные вещи, срок жизни которых больше 5-10 лет.
    Примеры:
    • Реляционные СУБД. Я использую их уже лет 10, и ничего принципиально нового (с точки зрения разработчика) в них не появилось. Я как изучил SQL 10 лет назад, так и пользуюсь им до сих пор. В тоже время, я знаю достаточно хипстеров, которые каждый день пишут на новом фреймворке и при этом не смогут составить запрос с joinами. Изучайте реляционные базы данных и SQL - они будут жить еще лет 20-ть;
    • ООП. У меня на полке лежит книга банды 4-х, которую я купил давно. Мне не нужно каждый год покупать новый экземпляр из-за того, что шаблоны проектирования вдруг взяли и "устарели". Изучайте ООП. Оно будет актуальным еще очень долгое время;
    • Регулярные выражения;
    • Командные оболочки sh/bash;
    • и т.д.

    Короче говоря, не тратьте время на синтаксис, тратьте его на семантику.

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

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    Ну в общем-то ответов много. Могу кое-что добавить от себя.

    Во-первых, голова не бесконечна во всех смыслах. Запихнуть в неё больше чем 10 объектов одновременно вряд ли получится, у многих начинаются огромные проблемы уже с 5. Лично я испытываю ДИКУЮ больше если собственный код становится больше чем большой. Для меня это где-то 15~20 сущностей, причём чем сильнее они связаны, тем сложнее они даются, так как становится сложно абстрагироваться. Что примечательно, при работе с чужим кодом таких проблем практически нет, ну у меня по крайне менее. Всё дело в том, что чужой код изначально воспринимается чёрным ящиком, поэтому если он не представляет из себя дикую лапшу, аккуратная работа с ним с минимальным вмешательством в проект получается легко.

    Во-вторых, не стоит делать код пушистым. Однообразность воспринимается лучше. Массивы некоторых объектов надо называть $названием_объекта + 's'. Классы с большой буквы, любой объект стоит называть так же, как класс, но с маленькой буквы. Конечно, если семантически прям просится по другому, то стоит правило нарушить, но в общем случае никаких выдумок не надо. Временная строка - str, временное число - tmp, временный объект - obj. И пробелов не жалей, внутри файла разделяй разные структуры двумя-тремя пробелами, стоит обособлять регионы, например, "глобальные" функции наверху, по середине структуры, потом классы. В C# есть #region.

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

    В-четвёртых, внутри монолита также надо делать максимально растянуто, никаких супер-синглетонов бдящие за всем и вся. Равно как и с микросервисами, внутренние объекты должны иметь минимум точек входа. Они должны быть просты и понятны. Если какой-то класс выполняет слишком много задач, часть из них надо делегировать другим классам, возможно новым. Это по сути цикломатическая сложность, о которой упомянул Ivan Sokolov, но мне не нравится эта формальность. Да и некоторые вещи сложно формализовать ребром на графе.

    В-пятых, иерархия должна быть логически правильной, наивной, без выпендрёжа. Тоже самое, что и в третьем, плоское лучше объёмного.
    Плохо:
    3dbadffb7d954b2d93a5dfec863289be.png
    Лучше:
    1238e5c4d83340239a250116d4d2fa3a.png
    Пример немного утрирован, но суть, навроде, ясна. Не надо наследовать всё и вся от чего угодно, если есть возможность включить внутрь - включай. Всё остальное от лукавого и только в крайних случаях.

    В-шестых, используй UML, mind maps, блокнот и таск менеджеры. Эти инструменты словно манна небесная спасают дедлайны от полного уничтожения. Хотя UML спорен, им очень удобно следить за структурой проекта, представлять картину с высока, рисовать его стоит самому, учитывая неявные связи и убирая рудиментарные. Mind maps помогут собрать мысли в кучу. Блокнот банально запишит то, что постоянно забывается. Таск менеджеры сформируют привычный график, отобразят прогресс, помогут фокусироваться на текущих задачах, не растекаясь по проекту.

    В-седьмых, изучи декларативное программирование. Шикарная вещь, которая позволяет сконцентрироваться на задаче, а не на решении. Из коробки в функциональных (erlang) и логических (prolog) языках, однако многие элементы существуют и в монстрах вроде C#/Java, Python, особенно JavaScript. Насчёт Go не знаю, но на первый взгляд весьма декларативный.

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

    Ещё пара абзацев. Ну про вредные советы: методы надо делать ровно такими, какие они должны быть. 20 строк - это что-то вроде лакмусовой бумажки, однако это лишь один из параметров. Очень часто требуется сделать громадную функцию для работы со сложным API или подробить много разных чисел в циклах. Поэтому ориентироваться на это плохая идея. Равно как и папки-подпапки-подпапками погоняемы, максимум - два уровня в чрезвычайно сложных проектах. Иначе будет очень сложно ориентироваться. Ещё происходит странный возврат к комментариям. На мой взгляд, если это не продаваемая за большие деньги библиотека - нах*й надо. Документация в комментариях - рудимент кода, он нигде не используется, зато требует поддержки, на что приходится распылять внимание. Если нет условного рефлекса править комментарий после кода - выбрасывайте и не жалейте. Везде! Без исключений. Ещё есть много "архитектурных" паттернов. Снова вред, если вы не работаете в Google, где вашу зарплату надо оправдать умными словами. Самый эффективный способ - программировать наивно. Чем проще для вас сейчас, тем лучше для вас потом. Если думаете больше десяти минут - плохо думаете... Но об этом позже. Паттерны это некая систематизация неких знаний, причём совершенно не понимаю, зачем её вообще сделали. Да, архитектура в некотором роде нужна, но постоянно искать какой паттерн здесь надо использовать, если это не проект на 100500 лет вперёд - нельзя. Почти всегда будет дешевле в случае неуспеха отрефакторить всё и вся, чем переписывать с нуля или тратить месяцы на продумывание архитектуры... В которой также могут быть ошибки.

    И последнее. Отдыхайте. Если чувствуете, что задыхайтесь - пройдитесь, подышите. Если чувствуете, что мозги плывут - отвлекитесь, подумайте о другом. 8 часов в день для программиста - это дикость, но это реальность. Для разных людей наибольшая эффективность поддерживается где-то 3~6 часов, причём некоторым требуются перерывы каждые пол часа, другому хватит обеденного перерыва, а третьему вообще нельзя сегодня никаких отвлекающих факторов, ибо "волна". На самом деле, человек существо динамичное, так что будут разные дни. Но если не получается сейчас - не бесите самого себя. Отдохните, перекусите, пробежитесь, покурите, проверьте почту, послушайте музыку, почитайте статью. Не тратьте время бездарно и, что интересно, проблемы будут решаться, усилия будут прикладываться аналогичные, но вот ощущения от работы станут совершенно другими.
    Ответ написан
  • Как запоминать код, который писал две недели назад?

    @nirvimel
    1. Как писать много кода, оставляя его простым, как в начале?
    2. Также советую прочесть "Совершенный код" С.Макконнелла.
    3. Качественный код не требует того, чтобы его запоминали. Качественный код может быть забыт сразу после того, как он начнет проходить все тесты. Держать в голове нужно только программные интерфейсы, но даже не все, а только, используемые на текущем уровне абстракции.
    Ответ написан
  • Как эффективно развивать себя как разработчика?

    aRegius
    @aRegius
    Python Enthusiast
    Вам будет гораздо легче решать большую часть стоящих перед вами задач (а другим гораздо легче вам в этом помогать), как только вы перестанете описывать их общими фразами (типа "максимально эффективно", "полноценный дев", "хорошим специалистом" и т.п.).

    Будьте конкретны:
    - "Моя цель на ближайшие 6 месяцев - вырасти до позиции XXX в текущей компании". И далее:
    - "Что мне нужно сделать для того, чтобы в течение 6 месяцев в моей компании вырасти до XXX ?"

    С этим уже можно обратиться к людям, обладающим достаточной компетенцией в помощи вам с ответом на этот вопрос: "Для того, чтобы в нашей компании стать XXX, нужно знать ЭТО и уметь ТО".

    - "Что мне нужно для того, чтобы узнать ЭТО и научиться делать ТО ?". Cоставляете план действий (разбиваете необходимые шаги на месяцы, недели, дни) с дежурными сроками (для проверки запланированного и достигнутого, внесения в связи с этим необходимых корректировок и т.п.) - и вперед.

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

    Успехов.
    Ответ написан
  • Разработка web-сервисов – LAMP (Python/Django) vs. MEAN (Node.js)? Или что-то другое?

    sim3x
    @sim3x
    Средний разработчик использует 3 ЯП в день
    На каждом ЯП 3+ технологии

    Нельзя стать высокооплачиваемым разрабом изучив только технологию X на ЯП Y
    Нельзя стать разрабом изучив только область знания Z

    Так что учите все, что видите и пробуйте, то что нравится
    Ответ написан
  • Разработка web-сервисов – LAMP (Python/Django) vs. MEAN (Node.js)? Или что-то другое?

    1) Мой основной язык Python, на JS больших программ почти не писал. Когда писал на нём больше, то ощущал дискомфорт из-за:
    - отсутствия нормального наследования (хотя сейчас, вероятно, это уже исправлено)
    - трудностей с типами данных и неявными преобразованиями (вот вчера буквально был холивар на Тостере о == и ===)
    - списков, реализованных как переодетые объекты
    - отсутствия из коробки структур данных вроде deque.

    Но это были студенческие поделки.

    2) Python предоставляет больше средств борьбы со сложностью. Наследование, система метаклассов, синтаксический сахар. Хотя бы даже такая штука как property. Он даёт больше возможности инкапсулировать сложность внутри. Ну и на нём действительно очень много разнообразных библиотек. Возьмите хотя бы Django: она умеет автоматически генерировать миграции базы данных. Насколько я знаю, это мало кто умеет делать.

    3) Не думаю, что JS - это язык будущего для бэк-енда. Я бы согласился, если бы вы сказали про Scala или Kotlin, которые куда больше подходят для больших и сложных приложений хотя бы потому, что имеют ещё больше средств борьбы со сложностью, чем Python. Поэтому я смотрю скорее в их сторону для своего будущего профессионального развития, не на JS. Он как-то не очень тянет в сравнении.

    4) Ничто не помешает вам изучить платформу А, затем Б, потом В и так далее; от этого только польза. Может быть, вы через десять лет будете на Quipper - диалекте Haskell для квантовых компьютеров - писать. Но начинать посоветую всё же с Python - чтоб меньше заниматься мазохизмом и больше писать кода.)
    Ответ написан
  • Разработка web-сервисов – LAMP (Python/Django) vs. MEAN (Node.js)? Или что-то другое?

    un1t
    @un1t
    Выбор ЯП и стека вещь сугубо субьективная. Параметров слишком много, чтобы можно было объективно сравнить.
    Все перечисленные технологии популярны и в ближайшиее 5 лет будут востребованы. Выбирай то что нравится.

    В пользу Node: всё идет к тому, что js станет стандартом как на фронте, так и на сервере. Через 5 лет серверную часть не на js будут писать только ленивые ретрограды.

    Ну-ну. Или стухнет как руби.

    Приложения получаются быстрее python и др. в 10-15 раз, выдерживают большие нагрузки,

    У JS нет превосходства в производительности над Python. Скорее наоборот. Но в целом я бы не рассматривал производительность как фактор выбора, т.к. в первом приближеннии она одинакова.

    нет задач, которые нельзя было бы реализовать в рамках MEAN-стека.

    Можно так и про ассемблер сказать, но это не делает его удобным для веб разработки.

    Технология в стадии активного развития, через 5 лет сегодняшние её косяки будут исправлены, и она станет стандартом де-факто для web-приложений, как php для web-сайтов когда-то. Нет смысла тратить время и распыляться на морально устаревающие средства.

    Некоторые косяки действительно будут исправлены. С монгой все поигрались и забыли, вернулись к реляционным БД. Express.js это наколенная поделка, которую можно написать за один вечер. Там по сути кроме роутинга ничего нет. Может быть черзе 5 лет на ноде появятся какие-то полноценные фреймворки типа Джанги, Рельсов или Симфони, но на сегодняшний день их нет. Angular это вообще фронтенд, его можно с любым бакендом использовать.

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

    @kn0ckn0ck
    Продюсер
    ООО нужно для ведения хозяйственной деятельности, то есть извлечения прибыли. Если продукта нет, то откуда возьмется прибыль? Доли в ООО нужны для того, чтобы платить дивиденды. Если нет прибыли, откуда возьмутся дивиденды?

    С другой стороны, если среди основателей нет доверия друг другу, откуда возьмется хороший продукт? Я бы предложил думать не о юридической стороне вопроса, а о том, как вы будете оценивать вклад каждого из участников в будущий продукт, соразмерный их будущей доли.
    Ответ написан
  • Где можно найти работу для повышения навыков?

    dmitry_pavlov
    @dmitry_pavlov
    World-class .NET freelance contractor (remotely)
    Удаленно редко кто хочет нанять человека, который учится. Устраивайтесь (по вечерам, на полдня, как попало) в офис аутсорс компании (человек на 50+) на пол/четверь ставки или "за спасибо" джуниором/интерном/практикантом/кем-попало. За полгода/год - подровняете скиллы и технические и проектные (не менее, а то и более важные в нашей индустрии). Это хорошая и быстрая школа.

    P.S. Относительно мотивации. Это обычная лень и отсутствие навыка не начинать ерундовых дел и доводить неерундовые до конца. Читайте книги и статьи. Со временем количество даже не слишком понятной информации перейдет в качественно новое понимание концепций программной инженерии. Законы диалектики никто не отменял :) количество перейдет в качество :) Главное не лениться и уделять своему развитию каждый день не менее 15 минут (больше - лучше) только без пропусков. Еще два правила полезных тут и вообще в целом:
    1) принцип Парето (чтобы эффективно тратить свои ресурсы)
    2) закон Старджона (чтобы не быть слишком серьезным и не перегреваться) :)

    Найти и разобраться что это за такое - домашнее задание :)

    UPDATE: наткнулся вот на статью ain.ua/2016/06/22/656143 - Практическое руководство для тех, кто хочет стать профессиональным веб-разработчиком
    Ответ написан
  • Как подключить socket.io?

    yarkov
    @yarkov
    Проект "Жизнь после смерти" - lifeafterdeath.ru
    var x = require('./x')(io);
    // x.js
    module.exports = function(io){
      io.emit(......);
    }
    Ответ написан
  • Как корректно писать код? Организовать процесс разработки?

    @evgeniy_lm
    Этапы разработки ПО
    1. Изучение заданного процесса или явления
    2. Разработка технического задания
    3. Разработка математической модели по полученному ТЗ
    4. Выбор языка программирования наиболее подходящего для реализации полученной ММ
    5. Запись ММ на выбранном языке программирования
    6. Отладка полученной программы

    PS
    п.1, 2 по идее должен делать заказчик, но это только по идее.
    Большую задачу лучше разделить на несколько меньших и каждую решать отдельно. Возможно даже на разных ЯП, в вашем случае часть на PHP, часть на JS? часть на SQL
    Ответ написан
  • Как корректно писать код? Организовать процесс разработки?

    lxsmkv
    @lxsmkv
    Test automation engineer
    Щас скажу, в качестве "шутки, в которой есть доля шутки"

    Профессионалы пишут код так чтобы они могли его читать

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

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

    Никому не важно красиво ли то, чего не видно, должно быть красиво то, что видно.

    Удачи Вам!
    Ответ написан
  • Зачем прокладывают провода по дну океана?

    Frankenstine
    @Frankenstine
    Сисадмин
    Спутниковая связь в сравнении с кабельной имеет три существенных недостатка:
    1) Очень большое расстояние до орбиты по сравнению с наземными/подводными сетями, как следствие - большая задержка между запросом и ответом (несколько десятых секунды в лучшем случае, чем ниже задержка тем ниже и больше нужно спутников))
    2) Низкая пропускная способность (у кабелей - терабиты в секунду, у спутников - на порядок-другой ниже)
    3) Низкий срок эксплуатации, отсюда дороговизна - через 5-10 лет надо запускать новые спутники.
    Ответ написан