• Как уйти с распутья технологий?

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

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

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

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

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

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

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

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

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

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

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

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

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

    С третьим - придешь, когда поймешь, что тебе это нужно. Из-под палки не учатся.

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

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

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

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

    Сложность задачи не особо влияет на мотивацию, а вот факт решения/нерешения - влияет сильно. Не решил - значит не осилил, не осилил - значит не достоин, не достоин - значит иди ко дну и не рыпайся. Это как импотенция: импотент - значит не мужик, не мужик - значит никто, ничего не достоин и об тебя можно ноги вытирать. Подсознание портит всю малину, так что не следует давать ему шанса - лучше решить задачу попроще, чем не решить по сложнее.
    Ответ написан
    7 комментариев
  • В чем суть роутера на php?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Встречал "сайты", где весь код упакован в километровую простыню с кучей if/case, внутри которых и обрабатывались те или иные запросы. В целом это плохо по многим причинам, одна из которых - в интерпретатор при каждом запросе вгружается очень много кода, который надо распарсить и пр., и 99% которого не используется принципиально.

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

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

    Для своего движка я сделал предельно простой роутер, который на входе ждет название модуля и его экшена, которому необходимо передать обработку запроса, причем модуль, по сути - это просто папка внутри папки modules, а экшен - это некая папка внутри папки модуля, т.е. modules/[module]/[action]/[action].php, соответственно модуль/экшен добавляется в проект через создание пары папок и файла. Все остальные параметры ЧПУ передаются в экшен в переменной GET.

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

    Если роутер не получил название экшена и.или модуля, то подставляется default, если по указанному пути файл не обнаружен, то выдается 404. Предельно просто и прозрачно, и всегда наверняка знаешь где и что лежит и как называется и почему.

    Подобный подход практикуется в JavaScript фреймворке Ember.JS, под подходом я подразумеваю весьма жесткие соглашения относительно структуры и именования папок, и файлов проектов.

    Шаблоны в моих проектах точно так же находятся в строго определенных местах и подключаются экшенами автоматически, если тип их выдачи HTML, иначе генерится JSON, или что-то еще, имеется несколько конвертеров на выходе, подключается тот, который запросил экшен.
    Ответ написан
    Комментировать
  • В чем суть роутера на php?

    xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.com
    Роутер отвечает за доставку данных к контроллеру/сервису.
    Если нет пути - роутер обычно выдаёт 404 ошибку.
    URI роутером делится на: протокол, домен, сервис и переменные сервиса
    например:
    domain.com/catalog/145 - сервис catalog отображает ветку с ID 145
    роутер - перенаправляет лишь запрос по части URI: /catalog
    сервис catalog - сам берёт нужные ему переменные из запроса.

    Еще примеры:
    domain.com/catalog/145/add - сервис catalog отображает диалог добавления новой категории в существующую категорию с ID 145.
    domain.com/catalog/145/sort/price/09/col/1/2/title - сервис catalog отображает категорию с ID 145 с сортировкой по цене от наименьшей к большей и выводом колонок с ID:1, ID:2, и по названию столбца: title.

    Также, router может быть древовидным и рекурсивным.
    Пример: domain.com/catalog/145/add/prod/24/56/37
    Описание: Добавить в каталог с ID:145 товары с ID:24,56,37
    Вначале, определяется, что категория с ID:145 существует и необходимо добавление, затем снова вызывается роутер с линком: /prod/24/56/37 и уже сервис prod проверяет существование продуктов и добавляет к каждому ID категорию 145 и так же возвращает результат в сервис catalog.
    Шаблон страницы вывода - будет выбран согласно операции: add.

    Таким образом, URI превращается в понятные предложения для общения пользователя/JS (front-end) с сервером через URI-запросы. Router - это как-бы механизм, "понимающий" то, что вы просите от веб-сайта через URI.
    Суммарно: это примитивный язык общения в виде структурированных лексических "предложений" между сайтом и пользователем/JS посредством URI-запросов.
    Ответ написан
    Комментировать
  • В чем суть роутера на php?

    trevoga_su
    @trevoga_su
    Комментировать
  • В чем суть роутера на php?

    onqu
    @onqu
    weasy
    1. Здесь пугают всякими контроллерами, ларавелями. Давайте жить проще. Для начала дадим определение модному слову роутер. Это маршрутизатор. Что делает маршрутизатор? Правильно. Обрабатывает маршруты, являясь связующим звеном. Маршрутом для web сайта принято считать метод запроса [GET, POST, PUT и другие] и компоненты URI.

    например: https://ru.wikipedia.org/wiki/URI?foo=bar#title
    [схема: https] :// [источник: ru.wikipedia.org] [путь: /wiki/URI] [запрос: ?foo=bar] [фрагмент: #title]


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

    Сама работа, как правило проста: от клиента приходит запрос, маршрутизатор перебирает все заданные ему пути до первого совпадения. При совпадении вызывается определенная вами функция, которая возвращает ответ клиенту.

    2. Он необходим, если в приложении одна точка входа, когда любой запрос приходит на один файл.

    3. Простой пример
    // файл index.php
    
    // Маршруты
    // [маршрут => функция которая будет вызвана]
    $routes = [
        // срабатывает при вызове корня или /index.php
        '/' => 'hello',
        // срабатывает при вызове /about или /index.php/about
        '/about' => 'about',
        // динамические страницы
        '/page' => 'page'
    ];
    
    // возвращает путь запроса
    // вырезает index.php из пути
    function getRequestPath() {
        $path = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);
    
        return '/' . ltrim(str_replace('index.php', '', $path), '/');
    }
    
    // наш роутер, в который передаются маршруты и запрашиваемый путь
    // возвращает функцию если маршшрут совпал с путем
    // иначе возвращает функцию notFound
    function getMethod(array $routes, $path) {
        // перебор всех маршрутов
        foreach ($routes as $route => $method) {
            // если маршрут сопадает с путем, возвращаем функцию
            if ($path === $route) {
                return $method;
            }
        }
    
        return 'notFound';
    }
    
    // функция для корня
    function hello() {
        return 'Hello, world!';
    }
    
    // функция для страницы "/about"
    function about() {
        return 'About us.';
    }
    
    // чуть более сложный пример
    // функция отобразит страницу только если
    // в запросе приходит id и этот id равен
    // 33 или 54
    // [/page?id=33]
    function page() {
    
        $pages = [
            33 => 'Сага о хомячках',
            54 => 'Мыши в тумане'
        ];
    
        if (isset($_GET['id']) && isset($pages[$_GET['id']])) {
            return $pages[$_GET['id']];
        }
    
        return notFound();
    }
    
    // метод, который отдает заголовок и содержание для маршрутов,
    // которые не существуют
    function notFound() {
        header("HTTP/1.0 404 Not Found");
    
        return 'Нет такой страницы';
    }
    
    
    // Роутер
    // получаем путь запроса
    $path = getRequestPath();
    // получаем функцию обработчик
    $method = getMethod($routes, $path);
    // отдаем данные клиенту
    echo $method();


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

    4. Обойтись без него можно. Если каждая страница в вашем приложении будет являться отдельным файлом, который отвечает за отдачу информации.
    index.php
    about.php
    contact.php
    ...


    Это олдскульная структура, в новых проектах почти не применяется.
    Ответ написан
    13 комментариев
  • Как наработать портфолио php программисту и стартовать в профессии?

    @HiIamRobot
    Сделай свой сайт визитку. А потом дяде Васе с третьего этажа. А потом маме. Потом свой блог. На своем сайте визитке пилишь раздел "портфолио", куда вставляешь ссылки и примерное описание двух сайтов визитки, мамы и дяди Васи и своего блога. За месяца 2-3 непыльной работы, можно наклепать с десяток мелких сайтов визиток, и бложиков для своих подруг, которые с гордостью и брызгами слюней будут всем рассказывать о том что у них есть блог самописный, а не какой-то там твитер и т.д. Сработает сарафанное радио и тебе даже не прийдется искать работу, она сама тебя найдет.
    И к концу времени у тебя и портфолио и хоть и плохенький скуденький, но все таки опыт.
    Ответ написан
    1 комментарий
  • В чем разница графической подсистемы и встроенной видеокарты?

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

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

    В случае с внутренним видеоядром необходимо, чтобы на материнской плате был соответствующий разъем для подключения монитора.

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

    Здесь монитор подключается в саму видеокарту.

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

    Суть любого робота в автоматизации того, что делать руками не хочется или невыгодно. А что конкретно автоматизировать, это зависит от конкретного случая.

    Примеры:
    • боты для DDOS - см. определение DDOS-атаки
    • боты для сайтов/форумов/чатов - рекламный спам, авторегистрация пользователей; бывают и полезные вещи, например боты-нотификаторы. В ICQ был в своё время популярен бот, отвечающий на ряд запросов - можно было спросить прогноз погоды или рассказать анекдот;
    • боты в MMO-играх: сбор ресурсов, ожидание в очередях и т.п. Также спам в чаты (продажа ресурсов/золота, как легальная так и не очень, рекрутинг в гильдии);
    Ответ написан
    4 комментария
  • Написание первой CMS. Как лучше?

    @RichyNix
    Программирование, Серверное администрирование
    Для начала, можете попробовать писать все в функциональном стиле, это если опыта веб разработки у вас не очень много.

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

    На начальном этапе не стоит сильно беспокоится об оптимизации кода, все приходит со временем.
    Ответ написан
    1 комментарий
  • Написание первой CMS. Как лучше?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Т.е. прежде чем мне написать CMS мне надо "перелопатить" тысячи исходных кодов различных CMS, изучить их, проработать с ними как минимум год чтобы понять как написать правильно свою систему?


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

    Неужели чтобы написать даже самую простую CMS для личных элементарных нужд придется изучать куча всего другого чтобы выстроилась точная картина о ее разработке?


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

    но интерес составляет написать самому

    Начните с фреймворка:

    - библиотека для рендринга шаблонов (буферизация вывода, работа с файловой системой немножко)
    - библиотека для маршрутизации запросов (прошаритесь в регулярках)
    - библиотека для работы с базой данных (не ORM, начните с Table Data Gateway или DAO хотя бы. Прошаритесь в SQL минимально).
    - Ядро, связывающее все это вместе. Желаельно с какой-то концепцией мидлвэров, что бы все остальныекомпоненты ничего не знали о ядре. (прошаритесь в HTTP)

    В целом же писать CMS очень и очень скучно и долго. Вы намного быстрее прошаритесь во всем что надо делая отдельные компоненты. Благо сейчас век composer-а и вы можете крутить и вертеть фреймворками как хотите, подменяя чужие компоненты на свои.
    Ответ написан
    6 комментариев