• Long polling - готовые решения?

    @Number_11
    1. Ставишь composer, далее переходишь в папку с проектом через командную строку (cd c://bot - пример), выполняешь код:
    "composer require guzzlehttp/guzzle".
    2. Создаешь init.php, в этой папке, с содержимым:
    <?php
    // Инклуды)
    use GuzzleHttp\Client;
    include('vendor/autoload.php');
    include('telegramBot.php');

    //Получаем данные
    $telegramApi = new TelegramBot();

    // Вычный цикл, обработчик
    while (true) {
    sleep(2);
    $updates = $telegramApi->getUpdates(); // Получаем обновление, методом getUpdates
    foreach ($updates as $update){
    if (isset($update->message->text)) { // Проверяем Update, на наличие текста

    $text = $update->message->text; // Переменная с текстом сообщения
    $chat_id = $update->message->chat->id; // Чат ID пользователя
    $first_name = $update->message->chat->first_name; //Имя пользователя
    $username = $update->message->chat->username; //Юзернейм пользователя

    print_r($chat_id);
    print_r($username);

    if ($text == '/start'){ // Если пользователь подключился в первый раз, ему поступит приветствие
    $telegramApi->sendMessage($chat_id, 'Привет'. ' ' . $first_name . '!'); //Приветствует Пользователя
    } else {
    $telegramApi->sendMessage($chat_id, $first_name . '! Как дела?' ); // Спрашивает как дела

    }
    }
    }
    }

    3. Создаешь telegramBot.php, в этой папке, вот содержимое:
    <?php
    // Подключение библиотеки
    use GuzzleHttp\Client;
    use Telegram\Api;

    class TelegramBot
    {
    protected $token = "ТОКЕН_БОТА";
    protected $updateId;
    // Функция собирает URL
    protected function query($method, $params = [])
    {
    $url = "https://api.telegram.org/bot";
    $url .= $this->token;
    $url .= "/" . $method;
    if (!empty($params))
    {
    $url .= "?" . http_build_query($params);
    }

    $client = new Client([
    'base_uri' => $url
    ]);

    $result = $client->request('GET');

    return json_decode($result->getBody());
    }

    // Получаем обновления
    public function getUpdates()
    {
    $response = $this->query('getUpdates', [
    'offset' => $this->updateId + 1
    ]);
    if (!empty($response->result)) {
    $this->updateId = $response->result[count($response->result) -1]->update_id;
    }
    return $response->result;
    }

    // Отправляем сообщения
    public function sendMessage($chat_id, $text)
    {
    $response = $this->query('sendMessage',[
    'chat_id' => $chat_id,
    'text' => $text
    ]);
    return $response;
    }

    }

    4. Что бы запустить его, там же в командной строке запускаешь файл:
    php init.php

    Там же в консоли увидишь Id пользователя и его юзернейм)
    Вот такой не много туповаты пример, но работает.
    Ответ написан
    2 комментария
  • Хорошая ли практика создавать свои классы Exception для отлавливания разных ошибок?

    @galliard
    Практика хорошая. Именно так и стоит делать. В идеале у каждой ошибки должен быть свой уникальный эксепшн. Например, от FileException можно наследовать например NotFoundFileException и AccessFileException. При этом тело классов в большинстве случаев будет пустым.

    А вот то, что ты пытаешься поймать все возможные эксапшны в контроллере - это совсем не хорошо. По хорошему нужен отдельный эксепшн хендлер для этого.
    Ответ написан
    6 комментариев
  • Кто нибудь работал в Webmasters Forge Ltd?

    @Network_SPY
    Сделал ошибку (раньше так никогда не делал, длительное время без поиска новой работы дало о себе знать), не погуглив предварительно о конторе, и не пообщавшись об условиях сотрудничества, выполнил и отправил им "знаменитое" тестовое задание. Назначили собеседование через 2 недели. В течении 2 недель раза 2 переносили время. После все же погуглил в инете, и наткнулся на разные странички с обсуждением данной темы. Подумал что все же пообщаюсь, раз назначили собеседование, послушаю что расскажут, в крайнем случае накидаю им картинок с копрофилами. В наступивший момент истины созвонились в скайпе, на том конце ответил мужской голос, но по неведомой причине стала очень плохая связь, и их не было ни видно, ни слышно, хотя меня они слышали и видели нормально. Сам я нахожусь за пределами СНГ, но работаю удаленно последние 3 года и поддерживаю контакты со всеми благодаря интернету, включая скайп, включая общение по видео, и с таким качеством связи столкнулся впервые. Далее был диалог:

    On 06/12/2015, at 16:34, secretary 911 wrote:
    > Вы можете обеспечить устойчивую аудио и видеосвязь?

    On 06/12/2015, at 16:35, Me wrote:
    > это не от меня зависит, я час назад общался, все нормально было

    On 06/12/2015, at 16:35, Me wrote:
    > можем пообщаться пока только голосом

    On 06/12/2015, at 16:36, secretary 911 wrote:
    > Устойчивая видеосвязь - это условие. Когда будете готовы - отпишите по электронной почте - Вам назначат новую дату.

    On 06/12/2015, at 16:39, Me wrote:
    > мы пока не сотрудничаем, поэтому условия могут быть оглашены позже, пока можете рассказать о себе и чем занимаетесь без видео

    On 06/12/2015, at 16:41, secretary 911 wrote:
    > Устойчивая видеосвязь - это условие проведения собеседования. Разумеется, Вы вправе отказаться от сотрудничества с нами.

    On 06/12/2015, at 16:45, Me wrote:
    > у меня все устойчиво работает, сейчас проверил, возможно проблема на вашей стороне

    On 06/12/2015, at 16:47, secretary 911 wrote:
    > Нет, я заменил компьютер. Вероятно, проблема все-таки на Вашей стороне.

    Сразу видно техническую подкованность интервьюера: если плохая связь - нужно заменить компьютер, а не интернет. Далее он писал, а я говорил, но мне никто и не собирался ничего рассказывать о их конторе и о работе у них, ни по аудио связи, ни в чате. Все общение свелось к тому, что мне пытались доказать что мой интернет плохой, а их интернет хороший. В итоге я им сказал что таких проблем у меня ни разу не случалось, а тянуть кабель в другую страну не собираюсь. И на этом мы распрощались.
    Вывод: при желании тестовое задание можно выполнить новичку, но не ради перспективы комфортного трудоустройства, а ради самообразования, будет полезным. Не найдено ни одного положительного отзыва от реального человека, который бы работал программистом в этой конторе. Судя по найденным комментариям, им нужен не специалист, а аквариумный хомячок, за которым можно наблюдать весь день, эксплуатировать, и вешать лапшу на уши по видеочатику(важнейший критерий!), периодически подкармливая(если захотят).
    Ответ написан
    2 комментария
  • Кто нибудь работал в Webmasters Forge Ltd?

    @Serdonda
    выполнил их тестовое задание, назначили собеседование.
    с первых минут собеседования они мне не понравились - слишком по хамски ведет себя собеседователь.
    Начну с того что первым же вопросом с упреком было почему я не включил видеорежим в скайпе - сразу сказал что это моя приватность хочу показываю свое лицо, хочу нет - тем более что еще не сотрудничаем для того чтобы мне быть в этом плане чем то обязанным.
    Собственно на этом можно было и заканчивать. Но решил послушать что будут спрашивать - спрашивают довольно много и разного. В каждой сфере/технологии пытаются понять понимаешь ли ты суть или просто нахапался поверхностных фраз.
    Как специалисты возможно и не плохие, но как люди - хамлюги и сильно завышенное мнение о собственных знаниях. Исходя из этого уже через полчаса общения я сделал для себя вывод что ни за какие деньги не буду портить себе нервы с такими работодателями.
    Ответ написан
    Комментировать
  • Какой JS фреймворк выбрать для full-stack?

    @xfg
    Лучшее что сейчас есть это koa или express для http протокола и socket.io для websocket протокола. PHP тоже от full-stack фреймворков движется в сторону микрофреймворков. Сегодня современный фреймворк это роутинг запросов реализованный на концепции мидлваров.

    Проблема спагетти-кода решается не фреймворком, а архитектурой. На сервере это обычно multilayered architecture. Бьете приложение на 4 слоя presentation, application, domain и infrastructure (еще могут называть data access layer или persistence layer). Контроллеры фреймворка куда попадает запрос пользователя это будет ваш самый верхний presentation слой. Слой инфраструктуры лучше собирать из отдельных библиотек, чем завязывать его на фреймворк. В таком случае не придется переписывать весь слой инфраструктуры из-за того, что фреймворк больше не развивается. Application и Domain слои используют Infrastructure слой через интерфейсы, тем самым абстрагируясь от конкретных реализаций. Таким образом вы всегда сможете заменить одну реализацию другой (паттерн Strategy) без изменения вышестоящих слоев. Presentation слой просто вызывает сервисы из application слоя и возвращает результат в html/json/xml/etc клиенту.

    Иногда упрощают до 3 или даже 2 слоев. Например если у вас CRUD приложение, тогда application и domain слои не нужны и вы можете оставить только presentation и infrastructure. Также если ваш application слой не делает ничего, кроме вызова domain слоя, то от него также можно избавиться оставив 3 слоя presentation, domain и infrastructure.

    Примеры реализации можно найти здесь и здесь. Они на Java. На javascript пока не встречал.

    Более подробно тему можно изучить взяв любую книгу на эту тему.

    Meteor не советую. Это не будущее. Это костыль. Они хотели сделать фреймворк для real-time приложений. Но фактически получилась просто платформа для стриминга произошедших изменений в mongo прямо на клиент.

    Sails это попытка сделать full-stack фреймворк. Но весь мир движется в обратном направлении.
    Ответ написан
    3 комментария
  • Зачем IT гиганты используют много несвязанных доменов?

    Поместив HTML, XML, SVG и т.д. и т.п. файл на домене usercontent.google.com можно
    манипулировать куками домена google.com и фишить. Поэтому пользовательский контент всегда отдается с отдельных sandbox-доменов.
    Так же с отдельных доменов обычно отдается статический контент, это позволяет использовать CDN и упрощает управление кэшированием.
    Отдельный домен обычно используется для PTR-записей (например 1e100.net). Для PTR часто нужна двойная валидация, т.е. PTR должна разрешаться в имя и имя обратно в тот же IP. При этом на одном IP может хоститься много доменов и быть установлено много сертификатов, включая вайлдкарды. И наоборот, один домен может хоститься на многих IP. Чтобы исключить прямое обращение к хосту по "неожиданному" для него имени в своем домене, обычно используются PTR записи в нейтральном домене. Кстати исторически принято использовать именно домены в .net. Google так же использует 1e100.net как нейтральный домен для подписи транзитных писем, раньше для этого использовался собственно домен google.com и это приводило к забавному багу, позволявшему подделывать подписи на письмах от google.com, я рассказывал о нем на PHDays 2014.
    Географические домены исторически используют для организации региональных датацентов и ускорения доступа, например yahoo.jp физически расположен в Японии.
    Ответ написан
    6 комментариев
  • Разговаривал по телефону, через пару дней вижу рекламу Вконтакте про то о чем говорил, Как так?

    @tallfatgarry
    Очень похоже на Selective perception. Когда-то я видел интересный пример по этому поводу. Историю была про женщину которую хотела выбрать машину максимально неожиданного цвета. И после покупки стала замечать такие же машины повсюду. До момента покупки она просто не обращала на них внимания.
    P.S. А вообще имел похожий опыт. После звонка человеку без общих знакомых фейсбук посоветовал мне его в друзья. Причем у меня он не был установлен, а на той стороне был. Насколько я понимаю такие приложения ориентируются еще и по логу звонков. И для получения такого эффекта достаточно что бы у одной стороны стояло приложение.
    Ответ написан
    Комментировать
  • Где практиковать python?

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

    DollyPapper
    @DollyPapper
    Раз выяснить ничего не удалось, попробуйте эксперементальным путем. Забейтесь с другом на разговор о чем либо. Например о покупке кастрюли. И проделайте те же самые действия, что делали в прошлый раз. С тем же другом по тому же самому телефону. Если вылезет предложение купить кастрюлю, то тут уже дело не чисто. Я конечно не эксперт по таргетированной рекламе и теории вероятности, но совпадение имеет место быть. Шансов очень мало конечно, но исключать не стоит.
    Ответ написан
    Комментировать
  • Go или PHP как язык влияет на развертывание приложения?

    zoonman
    @zoonman
    ⋆⋆⋆⋆⋆
    Язык никак не влияет на развертывание приложения. Влияют зависимости.
    Например, если вы собираетесь создавать Debian-пакет, то вам так или иначе прийдется прописать зависимости от других пакетов. Если какой-то пакет уже установлен, то нет никаких проблем.

    Прописывание в крон или создание vhost для Nginx задачи тривиального характера и не должны вас смущать. Это стандартные вещи, как и настройка ротации логов или синхронизация времени на сервере.

    Как и Go, PHP тоже можно собрать в один файл. Например так работает Composer.

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

    @entermix
    Вы серьезно?

    Есть ли утилита для удаления неиспользуемого css?
    Как удалить не используемые стили из CSS файла?
    Как вычистить css — неиспользуемые классы?
    Есть ли таск на удаление неиспользуемого CSS и JS?
    Как удалить лишние селекторы CSS?
    Как найти и удалить неиспользуемые классы CSS?
    Как можно убрать неиспользуемые css-стили из файла?
    Плагин для Gulp для удаления неиспользуемых стилей CSS, который сканирует не HTML файл а PHP, есть ли такой?
    Как вырезать все неиспользуемые стили из css файла подключив несколько html страниц из общего числа?
    Как быстро удалить не используемый css из проекта?
    Можно ли как-то автоматически удалить неиспользуемый CSS (и JS) код?
    Есть ли сервисы или методы, которые чистят неиспользуемые элементы в CSS?
    Найти не нужные css классы. Как сделать?
    Как сохранить только используемый css на сайте?
    Как упорядочить CSS?
    Как автоматически убрать лишние css стили со страницы и сохранить в отдельный файл только использующиеся ?
    ...
    Ответ написан
    Комментировать
  • Стоит ли использовать Docker на продакшене?

    kumaxim
    @kumaxim
    Web-программист
    Если у Вас один-три сервера, скорей всего, Docker Вам не нужен. В этом случае для управления конфигурацией лучше используйте ansible.

    Потребность в Docker возникает либо в случае когда нужно расшарать одно окружение на множество машин, например, у меня и моих коллег сейчас девелоперское окружение(php + apache + mysql + redis) крутиться на контейнерах. Второй пример - нужно настроить динамическое горизонтальное масштабирование. Этот вариант Вам нужно рассматривать, только если Вы используйте AWS или что-то подобное.

    В целом, docker / ansible / chef / puppet и т.п. Вам нужны только в случае, если нужно шарить одно окружение на разные машины, причем часто, с уверенностью что оно везде одно. Другого примера использования придумать не могу.
    Ответ написан
    1 комментарий
  • Ошибка при попытке вызова php artisan - в чем проблема?

    Decadal
    @Decadal
    Есть две разных версии php: та, которая запускается как модуль Apache, и та, которая в CLI. В CLI, судя по вашему комментарию, версия 5.6, вам нужно апгрейднуть консольный php.
    Версию CLI php можно проверить, набрав в консоли php -v
    Версию php вашего сервера можно проверить по phpinfo или аналогичной функции для вашего фреймворка
    Ответ написан
    Комментировать
  • Как правильно организовать деплой приложения?

    shebanoff
    @shebanoff
    Я увидел в Вашем вопросе две части.

    Как правильно организовать деплой (выкладку работоспособного кода на сервер)?


    В самом простом случае Вам подойдет связка ssh + git pull на сервере. В этом случае на сервер будут доставлены патчи коммитов, которые есть в репозитории, но еще не появились на сервере, т.е. «только обновления файлов, которые сейчас существуют». Этот метод довольно подробно обсудили в ответах на другой вопрос.

    Если хочется автоматизировать процесс, что похвально, то я вижу три доступных инструмента для этого: Capistrano, Mina (мой персональный фаворит) и Vlad the Deployer. Все три проекта схожи по сути. Принцип их работы таков:
    1. Подключиться к целевому серверу.
    2. Залить обновление кода из репозитория.
    3. Выполнить предписанные Вами инструкции (перезапуск демонов, сброс индексов, обновление структуры БД и прочее).
    4. ...
    5. PROFIT!


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

    Как организовать процесс тестирования?


    Если Вы еще не определились с методикой тестирования (Test Driven Development, Behavior Driven Development, Лень-Driven Development), то Вам следует для начала заняться именно этим.

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

    В какой-то момент речь может зайти о Continious Integration. Это возможность иметь стабильный билд в любой отрезок времени, а так же принимать решение о годности каждого отдельного коммита. Сопряжено с деплоем кода на integration-сервер и запуском на нем тестов. Скорее всего, это Вас не интересует, если Вы не работаете в команде. Но, для полноты картины, Вы можете понаблюдать за билдами на Travis CI известных Open Source проектов: Symfony 2 и Ruby on Rails.

    Таким образом


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

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

    panarama360
    @panarama360
    В общем правильно все, если приложению необходима супер защита, то с шифрованием при отправке нету смысла заниматься.

    Насчет того что делать дальше:
    Мое единственное предложение это со стороны сервера генерировать какой нибудь token (ключ), при удачной авторизации, потом этот ключ передавать пользователю на устройство, этот ключ сохранять и все последующие запросы делать с использованием этого ключа. При невалидности этого токена пользователя просо выкидывать.
    Ответ написан
    3 комментария
  • Какие актуальные способы есть автоматического распознавания ReCaptcha2 с выбором картинок в сетке 3на3?

    voan
    @voan
    RPA-разработка и веб-автоматизации
    Rucaptcha и anti-captcha это позволяют: посылаете им текстовое задание и картинку из рекаптчи2,
    обратно вам приходят номера картинок по которым нужно "кликнуть", чтобы пройти рекаптчу2.
    Ответ написан
    Комментировать
  • Какие актуальные способы есть автоматического распознавания ReCaptcha2 с выбором картинок в сетке 3на3?

    samodum
    @samodum
    Какой вопрос - такой и ответ
    Смотря откуда рекапчу берёшь. Можно antigate.com использовать, а можно pixodrom.com
    decaptcher.com ещё, но это американский сайт.
    Они решают антикапчи быстро
    Ответ написан
    Комментировать
  • Как уйти с распутья технологий?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Sanasol
    @Sanasol Куратор тега PHP
    нельзя просто так взять и загуглить ошибку
    Да.

    Нужно все запросы отправлять в index.php.
    На уровне вебсервера.
    Это третий шаг в инструкции этой библиотеки.

    https://github.com/klein/klein.php/wiki/Sub-Direct...
    Ответ написан
    Комментировать