• Оформление ИП и ведение документации: какие самые главные источники информации?

    www.regberry.ru - бесплатный сервис от 1С для генерации всех документов дле регстрации, там же пошаговая инструкция по процедуре что-кому-куда, с описанием подводных камней. Инфа обновляется регулярно (по крайней мере пару лет назад было так). Не реклама, просто делюсь опытом (сам пользовался, все норм). Это если вопрос про регистрацию и около нее.

    Если про дальнейшую деятельность - мое мнение: бухгалтерия на аутсорсе. Все эти SaaS - хорошо до первых запросов от ФНС по поводу чтото "срочно пояснить, иначе штрафы/блоки и пипец-пипец". А они такие, в любом запросе сразу весь набор ужасов вываливают )))
    Ответ написан
    1 комментарий
  • Как стать хорошим Big Data / Data Scientist'ом в России?

    ZloyHobbit
    @ZloyHobbit
    Смотря что вы понимаете под "хорошим DS специалистом".
    В идеале для этого надо окончить сильный технический вуз, отлично знать матанализ, линейную алгебру (матрицы это туда), дискретную математику, математическую статистику, теорию вероятности, теорию алгоритмов, и.т.д. и.т.п.
    А потом знать R, python, с++ и все используемые в работе библиотеки и инструменты.

    Проблема большей части курсов, от того же ШАДа, что они раситчаны на студентов физтеха, которым уже дана очень серьезная математическая подготовка. Большая часть людей, прослушав эти курсы, научится применять стандартные инструменты в стандартных ситуация, абсолютно не понимая, какая математика за всем этим стоит, и как ее можно модифицировать. Это не специалисты, а ремесленики дата сайна, которых на хайпе расплодилось очень много.
    Хотите быть крутым исследователем - учите математику и становитесь математиком.
    Ответ написан
    10 комментариев
  • Как быстро и эффективно освоить Node.js+Express?

    @skyhead
    Я оказался в такой же ситуации, бро!
    Большинство книг - неочём. Скринкаст Кантора - вообще неочём.
    Из всего, что я на данный момент нашёл толкового это пара курсов с udemy.
    The Complete Node.js Developer Course (2nd Edition)
    The Web Developer Bootcamp
    (они есть на рутрекере)
    Ответ написан
    Комментировать
  • Как построить свой рабочий день фрилансеру?

    SuperPosan
    @SuperPosan
    Бандит
    Какая разница когда работать, главное что бы денег платили, работайте когда хочется, отдыхаете когда хочется. Это и есть смысл фриланса.

    Все надоело - пошел гулять. Встертил старого приятеля, напился с ним, вернулся в 11 вечера, заснул, проснулся в 4 утра, сел поработал 4 часа. Опять спать захотелось, лег поспал. Проснулся в 8 поел. Поработал 3 часа, сходил в бассейн. Вернулся с бассейна поработал еще 2 часа. А время только 4 а уже 8 отработал.
    Силы еще есть, поработал еще пару часов.


    Вот так и живу последние пол года, стал более производительней, стал больше отдыхать, да и вообще все хорошо.
    Может и вам подойдет такой стиль

    Графики - Нах*й
    Режимы - Наx*й
    Делайте то что хочется
    Посылайте всех нах*й
    Меня тоже можете послать
    Ответ написан
    8 комментариев
  • Как построить свой рабочий день фрилансеру?

    iiiBird
    @iiiBird
    Пока ты спишь - твой конкурент совершенствуется
    3 комментария
  • Как вы понимаете (исходя из своего опыта), что на заказ (на фрилансе) откликаться не стоит?

    @ehs
    Architect / 3d designer
    Есть еще хороший маркер - заказчик думает что лучше вас знает как делать работу, как частный случай - "This will take no more than an hour for a good professional"
    Ответ написан
    2 комментария
  • Как писать много кода, оставляя его простым, как в начале?

    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 часов, причём некоторым требуются перерывы каждые пол часа, другому хватит обеденного перерыва, а третьему вообще нельзя сегодня никаких отвлекающих факторов, ибо "волна". На самом деле, человек существо динамичное, так что будут разные дни. Но если не получается сейчас - не бесите самого себя. Отдохните, перекусите, пробежитесь, покурите, проверьте почту, послушайте музыку, почитайте статью. Не тратьте время бездарно и, что интересно, проблемы будут решаться, усилия будут прикладываться аналогичные, но вот ощущения от работы станут совершенно другими.
    Ответ написан
    7 комментариев
  • Где в Европе поднять VPN?

    OxDEAD
    @OxDEAD
    HelloWorld Developer. Chief of Voodoo programming.
    https://www.arubacloud.com
    Полгода полет нормальный. Мне хватает впски за 1 евро.
    Ответ написан
    3 комментария
  • На чем основан принцип обучаемости нейронных сетей?

    @nirvimel
    Нейронная сеть (как природная, так и искусственная) по сути своей представят функцию (да, Y=F(X) только очень сложную), выходом Y которой является некоторое поведение субъекта (или программы), а входом X служит некоторая императивная информация (от органов чувств, например). Суть обучения в поиске оптимального значения F(X), при котором достигается наилучшая приспособленность субъекта/программы к поставленной задаче (для живых существ задача - выживание). Обучение происходит путем мелких итеративных шагов от менее оптимальных вариантов функции F к более оптимальным (а не перебором всех возможных вариантов). Подавая на вход F различные значения X, учитель (или естественный отбор) "поощряет" варианты, при которых F дает на выходе более точные значения Y (лучше соответствующие поставленной задаче) и "наказывает" за худшие (относительно предыдущих достижений) варианты. "Поощрение" и "наказание" происходит путем (нерезкого) усиления/ослабления тех нейронных связей, которые были более других задействованы в ходе последней итерации, то есть внесли в успех/неудачу наибольший вклад. Таким образом в ходе мелких последовательных итераций "интеллект" (возможно даже без кавычек) нейронной сети постепенно затачивается под решаемую задачу (простой перебор не дал бы таких результатов и за 100500 лет).
    Ответ написан
    3 комментария
  • Как работать с новым договором upwork для российского ИП?

    @dmatora
    Сделал вывод 5 октября.
    Деньги пришли от ELANCE ESCROW CORPORATION.
    Отправил суппорту на подпись старый акт.
    Три раза предлагали мне подписать новый акт с Upwork Escrow, судя по скорости и невразумительности сообщений, не понимая смысла диалога и тыкая наугад варианты ответа в шаблонах.
    Три раза пробовал обьяснить им неприемлемость нового акта для старого отправителя.
    То ли у них шаблоны закончились, то ли удалось подобрать убедительную формулировку, но пулемет шаблонов притих и, судя по паузе, пошли советоваться с супервайзером.
    Через несколько часов прислали подписанный старый акт.

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

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

    UPD 07-01-2017: C нового года деньги все-таки начали приходить с Upwork Escrow Inc. Отправил банку подписанные новый акт и новую оферту. Банк поблагодарил за уточнение, но отказался признавать новую оферту новым договором, настаивая на том, что паспорт сделки придется оформлять при достижении $50k по обоим офертам суммарно.

    UPD 04-04-2017: Задал вопрос Правоведу - https://pravoved.ru/question/1597038/ принимаю заявки на уточняющие вопросы.
    Ответ написан
  • Как вырасти из программиста в менеджмент?

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

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

    qonand
    @qonand
    Software Engineer
    Если проект для себя и планируете делать самостоятельно (единолично без команды):
    Сделайте прототип приложения - схематические наброски каждой страницы (хорошо если он будет интерактивный). Это позволит Вам упорядочить мысли и продумать различные аспекты логики приложения. По этому прототипу Вы в дальнейшем сможете разрабатывать приложение. Для прототипирования есть множество готовы решений, например тот же Axure (он платный, но есть и масса бесплатны инстументов).
    Если будете заказывать дизайн у дизайнера, по прототипу ему будет просто разобраться в логике и структуре проекта.

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

    Если проект для клиента:
    Закажите ТЗ у стороннего разработчика - сэкономите кучу времени, сил и нервов.
    Ответ написан
    2 комментария
  • Экспресс обучение frontend разработке. Как подступиться?

    mattedev
    @mattedev
    web developer
    для frontend разработки хватит nodejs, angular или react(по вкусу), mongodb (тоже кому как удобней), ну и bootstrap, html5, css3, и как ни странно javascript :) full stack
    Ответ написан
    Комментировать
  • Как правильно работать с gulp+git если я верстаю, а другой человек натягивает на wordpress?

    Уже отвечал на подобный вопрос, но про Битрикс, а найти не могу. Расскажу как делаем мы.

    Вот структура:
    011d11b1ba03470b865d8d5cd94ba8d7.png
    Как видите сам wordpress в репозитории не хранится, (как и плагины, которые из списка зависимостей ставятся на новой машине в пару кликов).

    Верстка лежит в src (используется scss и jade) и собирается в папку static - из которой вся статика подключается и в вордпрессе. HTML файлы собираются в папку _v.

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

    Если нужно добавить новую страницу - верстальщик верстает в jade, потом программист сольёт его изменения, соберет проект, возьмет из папки _v нужный шаблон и натянет его на wp.

    Очень сильно стараемся изменения в шаблонах переносить в исходники верстки, т.е. сохранять её актуальное состояние на протяжении всего проекта.

    UPD: Про ветки. Всегда есть master и markup (верстка) + могут быть ветки отдельных программистов / фич и т.д. В мастер изменения сливает только тимлид/техлид/самый-главный-программист.
    Ответ написан
    Комментировать
  • Как поднять себе зарплату?

    sim3x
    @sim3x
    Хочешь больше зп?
    Найди новую работу

    АПД
    Теоретически, нужно поговорить с начальством. Да

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

    Даже теоретики в коментах

    АПД2
    У прохождения собеседования есть еще преимущества
    - ты получаешь подтверждение своей квалификации и необходимости тебя на рынке
    - ты получаешь денежный еквивалент своей ценности
    - ты получаешь повышение навыка прохождения собеседований - ето отдельный навык, который не часто пересекается с навыком программирование/разработка/администрирование/...
    - в случае провала собеседования у тебя нет никаких побочных еффектов
    - ты получаешь срез навыков необходимых рынку
    Ответ написан
    36 комментариев