• Как удалить "лишнюю" языковую раскладку в Windows 10?

    @spellbinder
    В powershell
    Set-WinUserLanguageList -LanguageList en-US, ru -Force

    У меня были неизвестные языковые стандарты qab, qac.
    Ответ написан
    8 комментариев
  • Как писать много кода, оставляя его простым, как в начале?

    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 комментариев
  • Flask API и Чат. Как реализовать, куда копать?

    leahch
    @leahch
    3D специалист. Dолго, Dорого, Dерьмово.
    Чтобы сервер выдавал json, а не рендерил темплейты, достаточно просто возвращать через flask jsonify()

    Вот например у меня так
    from flask import jsonify
    
    # Begin AJAX requests
    @cart.route("/api/total")
    def total():
        count = 0
        if "cart" in session:
            cart = session.get("cart")
            l = [int(i) for i in redis.hvals(getCartKey(cart))]
            count = sum(l)
            logger.debug('cart %s : %d', cart, count)
        data = calculateItems()
        data.pop("products")
        return jsonify(dict(count=count, **data))


    Ну и описание jsonify из кода flask.
    """Creates a :class:`~flask.Response` with the JSON representation of
    the given arguments with an `application/json` mimetype. The arguments
    to this function are the same as to the :class:`dict` constructor.

    Example usage::

    from flask import jsonify

    @app.route('/_get_current_user')
    def get_current_user():
    return jsonify(username=g.user.username,
    email=g.user.email,
    id=g.user.id)

    This will send a JSON response like this to the browser::

    {
    "username": "admin",
    "email": "admin@localhost",
    "id": 42
    }

    For security reasons only objects are supported toplevel. For more
    information about this, have a look at :ref:`json-security`.

    This function's response will be pretty printed if it was not requested
    with ``X-Requested-With: XMLHttpRequest`` to simplify debugging unless
    the ``JSONIFY_PRETTYPRINT_REGULAR`` config parameter is set to false.

    .. versionadded:: 0.2
    """


    Что касается сообщений и их ожидания на стороне сервера, есть техника, называется long pooling, или использовать websocket (но к нему все тоже самое относится!"), и для реализации необходимо или запускать flask в режиме тредов app.run(threading=True), или использовать WSGI-враппер на основе gevent.
    Как пример - https://bitbucket.org/jeunice/flask-ws-example/src...
    и
    https://github.com/sigilioso/long_polling_example
    Ответ написан
    23 комментария
  • Уроки Python + django, что посоветуете?

    nikolay_karelin
    @nikolay_karelin
    Ведущий разработчик, пишу на Python, Tcl, Matlab
    Django Girls, есть и по русски. И мальчикам ИМХО тоже подойдет.
    Ответ написан
    Комментировать
  • Как увеличить скорость разработки и внимательность?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Скорость работы штука мутная и неоднозначная. Давно установлено как факт, что мозг может одновременно хранить в сознании 7+-2 объекта, т.е. от 5 до 9, в зависимости от кучи факторов. Все что свыше того, нужно как-то хитро организовать, иначе получится каша. Да и продуктивно напрягать мозг больше 4-5 часов в сутки в совокупности могут только продвинутые джедаи...

    Любая работа любого программиста начинается с построения модели приложения/модуля, над которым предстоит поработать. В этом процессе немаловажным звеном является моделирование потоков входящих и исходящих данных.

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

    В процессе простраивания архитектуры заодно всплывают все сопутствующие технологии, и возможно неоднократное пересматривание как модели так и архитектуры, т.к. это вещи взаимосвязанные.

    Когда модель и архитектура более-менее устаканились, можно начинать что-то планировать по части реализации, обычно начинают с фундамента.

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

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

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

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

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

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

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

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

    Четвертая рекомендация - постоянно прокачивать скиллы, много читать доки, вникать, задавать много вопросов и искать на них ответы, и пробовать все на практике. Критерий истины - практика.

    То, что джун не шибко быстр - это нормально, до 70% времени джун должен штудировать доки, из оставшихся 30%, до 95% времени - это дебаггинг. :) Так-что на реальный дев остается не так много времени, 0.3*0.05...

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

    И, главное, терпение+усидчивость. Путь это нелегкий, не простой, учиться придется постоянно, и постоянно будут критиковать, что мог бы поточнее, побыстрее, побольше и подешевле.... :)
    Ответ написан
    Комментировать
  • Стоит ли поступать в ВУЗ, если есть опыт работы программистом?

    @Alexey_Kutepov
    Разработчик программного обеспечения
    Я считаю что вышка нужна так как:
    - Вы получаете хорошие фундаментальные знания, которые помогут более легко вникать в сложные темы. Например машинное обучение плотно завязано на математике и без знаний математики курить эту тему практически не возможно.
    - Вы систематизируете свои знания и расширите кругозор за счёт непрофильных предметов. Это позволит рассматривать проблемы с разных сторон и научит принимать более правильные решения.
    - В ВУЗе учат учиться. Это тоже важно.
    - Просто огромное количество новых знакомств, которые могут помочь Вам в дальнейшей жизни.
    - Мир меняется и если сейчас дефицит разработчиков ПО и работодатель готов взять человека без вышки, то в будущем такого дефицита уже не будет и при прочих равных выбор падёт на человека с дипломом. Я понимаю что вы сейчас на фрилансе и всё круто, но в жизни разные ситуации бывают.
    Ответ написан
    1 комментарий
  • Стоит ли поступать в ВУЗ, если есть опыт работы программистом?

    saboteur_kiev
    @saboteur_kiev Куратор тега IT-образование
    software engineer
    На вышке можно получить:
    * Диплом (полезен при трудоустройстве зарубежом и госструктуры, да и HR некоторые требуют)
    * На вышке можно получить продвинутые знания по математике и алгоритмике, разобраться с геометрией, иметь базу для работы с физическими движками, 3д и статистикой/мат анализом - если в этом направлении хоть во что-то у вас получится углубиться - перспективы устроиться куда-нить разрабатывать компьютерное зрение, работать с бигдата, нейросетями значительно повышаются.
    * Знакомых и кафедру, где возможно заведутся полезные связи.
    * Надежную отмазу от армии

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

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

    @nozzy
    Symfony, Laravel, SQL
    Как-то так:
    select 
    t1.property_reg_num, 
    t1.property_owner_name_id 
    from property_table t1
    inner join
    (
     select  
     property_reg_num, 
     property_owner_name_id,
     MIN(property_record_on_year) min_year
     from property_table
     group by property_reg_num, 
     property_owner_name_id
    ) t2 on t2.property_reg_num = t1.property_reg_num 
            and t2.property_owner_name_id = t1.property_owner_name_id
            and t1.property_record_on_year in (t2.min_year, t2.min_year+1, t2.min_year+2)
    group by t1.property_reg_num, 
    t1.property_owner_name_id
    Ответ написан
    Комментировать
  • Возможна ли переквалификация в разработчики после 30 без профильного высшего образования?

    fedorez
    @fedorez
    Хатуль мадан
    Если вас это немножко подбодрит, могу сказать что это смог провернуть мой бывший командир корабля (я в прошлом офицер ВМФ, но быстро понял что ступил не на ту дорожку и вернулся к любимым с детства компам), капитан 1-го ранга, хорошо за 50... а командир корабля - это ещё и очень особенный клад и уклад сознания... у нас был старенький комп - селерон под Миллениум, на котором мы в свободное от вахты и печати отчётов время гоняли Диабло. Кэп увлёкся. потом со скуки начал читить - там можно было открывать файлы своего персонажа и что-то накручивать по его параметрам... через это начал ковыряться и изучать. Я ему книжек подкинул. Кэп скучал - за него службу тянул перспективный и роющий землю старпом. Потом я уволился, уехал. Потом сильно удивился узнав, что выйдя на пенсию кэп увлёкся программированием настолько, что купил макбук ретина и что-то разрабатывает под iOS, что-то морское специфичное и за деньги.
    Но правда там очень неслабая подушка безопасности в виде военной и более того, корабельной пенсии была...
    Но если уж человек после 50 смог - вы сможете после 30 однозначно)) вопрос организации.
    Ответ написан
    1 комментарий
  • Возможна ли переквалификация в разработчики после 30 без профильного высшего образования?

    s0ci0pat
    @s0ci0pat
    I'm Awesome
    без потери в заработной плате

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

    Создай себе подушку безопасности на полгода и вперед в джуны.
    Ответ написан
    9 комментариев
  • Как записать результат парсинга на python в бд?

    @balamut108
    Py
    SQlite уже в коробке...
    Ответ написан
    Комментировать
  • Чем отличаются языки программирования PHP, PYTHON, RUBY?

    leahch
    @leahch
    3D специалист. Dолго, Dорого, Dерьмово.
    Еще есть java, go - они тоже очень популярны.

    И на том и на том пишутся замечательные вещи!

    Go очень просто использовать - практически как замена C/C++, только более быстр в разработке. Сильно набирает популярность, достаточно низкоуровневый, чтобы на нем писать системные утилиты и большие распределенные системы. У него есть минусы (дебаггер например), но и плюсов очень много (дебаггер редко нужен).

    Java - отдельный вопрос, на нем очень удобно писать очень большие проекты, но кривая вхождения очень высока. Сам язык достаточно простой, но знание фреймворков (библиотек), как раз и составляет то, за что платит работодатель, и очень достойные деньги. Это, сильно не совру, один из самых высокооплачиваемых и рентабельных языков программирования.

    Что касается PHP - изначально язык создавался для простых проектов для WEB, как замена CGI, но вроде бы как вырос, появились объекты... Но, дальше WEB он не развивается.

    Что касается Ruby - хороший язык, большая инфраструктура (фоеймворки/библиотеки), куча всего понаписано, куча коммерческих сайтов и государственных, типа портала госуслуг Москвы, если не ошибаюсь. Немного медлителен интерпретатор, но это не повод за него не браться. На мой личный взгляд - основное неудобство, постоянный поиск нужной версии библиотеки при пересборке проекта.

    Python - отличный язык, очень богатая инфраструктура, куча коммерческих применений. На нем можно делать большие, очень большие, проекты. Очень легок в освоении. Я предпочитаю что-то быстро напрототипировать в питоне, а потом и переписывать не хочется.

    Сам программирую на Python, C, Java, PHP.
    Относительно неплохо разбираюсь в Ruby и Go, на уровне влесть в чужой проект и поправить ошибку.

    Мои фавориты - Java, Python. Присматриваюсь к Go.
    Ответ написан
    10 комментариев
  • Существует ли задачник к книге "Изучаем Python"?

    @Beltoev
    Живу в своё удовольствие
    По-моему, самый лучший задачник по Python-у только здесь: www.checkio.org
    Перед решением можно обсудить задачу с другими пользователями, после решения - посмотреть, как делали другие, узнать какие-нибудь новые приемы и хитрости
    Ответ написан
  • Помощь в изучении Python. Что дальше?

    @LeonidShifrin
    Разработчик, Wolfram Research Inc. PhD, Physics
    Учиться по книгам можно бесконечно. Судя по Вашим словам, Вы вполне подготовлены, чтобы начать работу над несложным проектом / задачей.

    Изучите какой-нибудь web framework на Python (Django, Flask, ... - лично я предпочитаю Django, но он довольно тяжелый как framework, хотя освоить его на начальном уровне нетрудно), и поднимите на нем простое web-приложение для личного использование (ну скажем, календарь, или планировщик задач, или учет личных финансов). Развивать можно бесконечно, и в процессе сможете самые разные задачи порешать. Чтобы не возиться с сервером дома, очень рекомендую сервис

    https://www.pythonanywhere.com/

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

    Ну и еще несколько советов:

    1. Ползуйтесь хорошим IDE (я использую PyCharm Pro, но в принципе и бесплатный PyCharm community edition прекрасно подойдет). Там можно настроить Python консоль, так что интерактивность не пострадает.
    2. Если возьметесь за что-либо, что можно назвать проектом, пользуйтесь системой контроля версий. Это не так страшно как кажется. Я бы советовал Git. Можно из командной строки (для изучения предпочтительна, лично я предпочитаю и для работы), либо UI клиент (я пользуюсь SourceTree). Изучить Git на начальном этапе можно за полдня. Вот хорошая книжка:

    https://git-scm.com/book/en/v2

    достаточно первые пару глав прочесть для начала

    3. Храните код в каком-нибудь распределенном репозитории (Github, Bitbucket). Если готовы его открыть для всех, то я бы советовал Github, если нет - BitBucket позволяет создавать бесплатно закрытые репозитории.

    4. При разработке в Python, пользуйтесь virtualenv. Это нужно для того, чтобы не замусоривать ваш основной дистрибутив Python установленными сторонними модулями и библиотеками.

    5. Это вопрос личного вкуса и удобства, но лично мне в работе сильно помогают системы project management. Я пользуюсь Blossom.io, но он платный. Из бесплатных, могу порекомендовать Trello.

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

    Собственно по Python, очень рекомендую вот это:

    docs.python-guide.org/en/latest

    куча реально полезной информации. По всем конкретным вопросам нет ничего лучше StackOverflow.

    Ну и уже когда практического опыта на реальном проекте поднаберетесь, вот тогда делайте upgrade, читайте еще книжки, код других проектов, участвуйте в других open source проектах, и т.д. В итоге гораздо быстрее все освоите, чем если прямолинейным чтением книг / прохождением курсов будете заниматься.
    Ответ написан
    4 комментария
  • Как попасть в backend-разработку?

    @IvanOne
    Я Вам советую пройти курсы по html, css, js пригодиться в работе или нет, не известно, но плюсик будет в резюме что есть представление о фронтенде, лучше изучить еще jquery, так как он используется очень во многих конторах. Далее читайте доки по django и пишите тестовое приложение которое там представлена. Ваш опыт плюс эти знания сделают из вас уверенного джуниора, а может даже выше. Основная проблема это конечно зп, ищите условия допустим на подработку, если деньги не главное то можете устроится джуниором, прикладывая усилия за год можно вырасти очень прилично. Конечно это руководство к действию, можно не заниматься фронтендом но тогда и шансы ниже, да и стремиться надо я думаю Full-stack.
    Если начнется изучать фронтенд советую сильно не углубляться, там можно глубоко завязнуть. Потом с опытом придут и более глубинные познания. Не бойтесь писать свои приложения и выложить на гитхаб, это тоже плюс в резюме. Не помешает знание MVC, и хорошее понимание ООП.

    ссылки: https://htmlacademy.ru/ https://www.codecademy.com https://www.codeschool.com/ www.wisdomweb.ru htmlbook.ru

    Ну и желаю удачи)
    Ответ написан
    4 комментария
  • Как правильно оформить "лицензию" на скрипт?

    sim3x
    @sim3x
    Я боюсь, что проще сказать, чтоб тебе заплатили сразу, чем потом доказывать, что ты сделал все за пределами работы.
    Есть не нулевая вероятность, что обращение в суд тебе ничего не даст.

    А юридическую точку зрения лучше спрашивать у юристов
    Ответ написан
    Комментировать
  • Как распарсить строку и построить дерево категорий товаров и услуг?

    orlov0562
    @orlov0562
    I'm cool!
    Я напишу в целом, т.к. это подойдет для любого языка

    Алгоритм работы парсера довольно прост, и по большей части делится на 3и этапа:
    1) Получить данные
    2) Разобрать данные
    3) Сохранить данные

    1) Для того чтобы получить данные, надо изучить стек функций для работы с сетью. Можно гуглить по такому запросу "Как скачать веб-страницу" + твой ЯП (PHP, Java, Python и т.д.). Тут ты должен написать функцию которой на вход передашь url, а на выход получишь данные (html, json, xml и т.д.)

    2) Разобрать данные можно либо с помощью готовых библиотек под нужный формат, либо с помощью регулярных выражений, либо с помощью строковых функций. Тут на помощь придет запрос "Строковые функции" + твой ЯП или "регулярные выражения" + твой ЯП. На этом этапе ты должен написать функцию, которой на вход поступают данные, а на выходе получаешь заранее утвержденную структуру.

    3) Сохранять данные в необходимой структуре можно в файлы или в БД. Опять в гугл с запросом "Работа с бд " + твой ЯП, либо "Работа с файлами" + твой ЯП. Тут твоя задача написать функцию, на вход которой приходит заранее утвержденная структура, а на выходе ты получаешь результат "сохраненные данные"

    Ну, собственно и всё. Идешь в гугл, изучаешь матчасть и пишешь парсер.

    Если же тебя в большей степени интересуют алгоритмы разбора, тогда советую посмотреть код "калькуляторов" на твоем ЯП, погуглить можно по запросу "калькулятор со скобками", "Разбор и вычисление выражений". Это классическая задача, разбор твоего куска будет очень похож.
    Ответ написан
    6 комментариев
  • Как вы решаете вопрос с постоянными правками после сдачи проекта?

    @ColdSpirit
    Анекдот может не жизненный, но в тему =)

    Программист сдает работу. Заказчик удовлетворенно кивает, со всем соглашается. Ну, вроде бы, все принято.
    Программист:
    - Отлично, с Вас 1700.
    Заказчик (отдавая деньги):
    - Ну, я надеюсь, если потом нужно будет что-нибудь переправить, можно будет к Вам обратиться? Это ведь не так, что один раз сделали и забыли?
    Программист:
    - В зависимости от того, что и как переправить.
    Заказчик:
    - Ну, конечно, я не скажу: "Давайте все заново переделаем!"
    Программист:
    - Хорошо, не вопрос. Кстати, еще одно. Можно будет потом, если у меня кончатся вдруг деньги или будут финансовые проблемы, я подойду к Вам насчет немного доплатить? Это мелочь, мне требуется очень редко, Вас это совсем не затруднит.
    Заказчик (удивленно открыв рот):
    - Как это?..
    Программист:
    - Да Вы не переживайте, я же не подойду к Вам, мол, заплатите мне целиком еще раз!
    Ответ написан
    Комментировать
  • Как найти удалённую практику для начинающего python программиста?

    @RadialAdmin
    Могу предложить такую схему работы: работаете бесплатно над интересным проектом по учету времени потраченного на проекты, что-то типа https://toggl.com/ на основе https://odoo.com. Odoo на питоне и его рынок довольно неплохо развивается в России, потом сможете найти ещё клиентов.

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