• С чего начать карьеру, если чувствуешь свою проф непригодность, хотя никогда не пытался устроиться?

    @darksladen
    Какой то вы странный человек.. Мне сейчас тоже 20, работать программистом начал в 19, тоже колледж закончил. Но я настолько хотел устроиться, что я просто вцеплялся зубами в работодателя и пока он меня не брал на работу я его не отспускал и держал его как овчарка =) Помню сказали завтра позвоним, прошла неделя - никто так и позвонил, но потом я сам их набрал и они спросили когда я смогу прийти для трудоустройства.. А не позвонил бы я, я почти уверен что про меня просто забыли бы. И так всюду куда я не приходил меня без проблем брали. Главное зажги свои глаза и покажи их работадателю и у тебя все получится. Джунов сейчас требуется много, ктобы что не говорил, мест свободных куча. А так я тебе честно скажу, если ты не занимаешься разработкой сайтов на заказ, то ты ничему не учишься, хоть и пишешь, что знаешь то и то, но когда устроишься поймешь, что тупо тратил время на обучение непонятно чему! Но единственное настоятельно рекомендую поучить терминал в линуксе, git и composer.. Без этого мне на 1 работе так трудно пришлось, что я даже разочаровался в программировании, уволился и несколько месяцев не прикасался к компу =) Так что изучай их в любом случае, иначе у тебя будет тройное обучение и охеренная нагрузка. Хотя по сути если работал с фреймворками, должен шарить. Также кстати советую купить vps, можно найти за бакс в месяц всего норм сервер и практиковаться тупо удаленно им управлять через консоль. Разверни там веб сервер скажем для php, установи какой нибудь ларавель, перекинь файлы со своего компа на него и обратно, чтобы на работе не было таких глупых вопросов. Хотя глупых вопросов не бывает, точнее все их задают, так что лучше 100 раз спросить чем не до конца понять.

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

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

    platotel
    @platotel
    IT Product Manager, Ведущая шоу ITBizRadio
    selfdestroy, добрый день. Что мне бросилось в глаза:
    - ник про саморазрушение и отсутствие аватарки, что иногда (не всегда) бывает признаком низкой самооценки. Да, есть те, кто по идеологическим или ещё каким-то причинам не хочет афишировать своё лицо, у кого-то просто нет хорошей фотографии, кто-то больше любит какую-то картинку поставить вместо лица, но нет ли именно проблем с восприятием себя?
    - наложение на себя клейма: "проф непригодность", "не обладаю супер знаниями",
    - страх отказа ("никогда не пытался устроиться"),
    - позиция "снизу", демонстрация чувство вины ("извиняюсь"),
    - растерянность ("понятия не имею, как найти", "не знаю, куда плыть дальше"),
    - настрой на провал ("меня просто нигде не возьмут"),
    - "никогда не щупал продакшн в живую" - есть стажировки, Open Source проекты, онлайн-курсы, на которых можно делать свой проект, обучаясь.

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

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

    sim3x
    @sim3x
    Если не ходить на собеседования, то не возьмут
    Гарантирую
    Ответ написан
    Комментировать
  • Как эффективно работать целый день?

    @apletnev
    По своему опыту выделил для себя следующие правила.
    Физика:
    1. Питание. Обрати внимание на сахар и быстрые/медленные углеводы. Например, если утром поесть овсяную кашу то энергии хватит на 4-5 часов, если бутерброды, - часа на два. Так по крайне мере у меня.
    2. Физические нагрузки, спорт отнимает много времени, хотя очень эффективен. Самый простой способ - побольше ходить, если пользуешься общ. транспортом, то выходить на несколько остановок раньше. Еще можно отжиматься, где-то читал что сто отжиманий в день - тонус для всех мышц тела.
    3. Сон. Как и другие рекомендую 7-8 часов, однако нужно обратить внимание на матрас, температуру и влажность в комнате - это намного улучшит качество отдыха.
    4. Жидкости. Я пью обычную воду, стараюсь выпивать 2 литра на работе (у меня есть вот такая фляга )
    5. Свежий воздух в офисе, яркость света. Стараться работать согласно нормам описаным в охране труда, т.е. должно быть много света, должен быть приток свежего воздуха.
    6. Эргономика стола. Обязательно нормальный стул, стол, монитор, клавиатура. Многие пренебрегают этими вопросами, а потом в 30 лет грыжи в позвоночнике, туннельный синдром, линзы/очки и половая дисфункция. (Я понимаю что в 18 лет это звучит как что-то далекое и не про тебя, однако если ты планируешь связать свою жизнь с разработкой, нужно думать о туловище, а не только о мозге)

    Психика:
    1. Будут дни когда работа не прет, абсолютно. Отпустить и забыть, но не увлекаться.
    2. Дисциплина. Так как мозг считай мышца, нужно постоянно тренировать ее; - писать код. В конце концов мозг привыкнет к нагрузке и сможет решать любые задачи и быстро, но будут дни как в первом пункте.
    3. Супер важные ежедневные задачи. Для меня это учеба и английский. Я этим занимаюсь не зависимо от дня недели, праздников, событий. Т.е. даже если я узнаю что через три дня конец света, все равно буду оставшиеся дни делать то что и делал раньше. Можно смеяться и крутить пальцем у виска, но нужно объяснить мозгу, что не может быть никаких проволочек, никаких отмазок. Иными словами “сдохни, но сделай”. Этот навык мне позволяет в случае аврала или какой-то мегалажи не паниковать и планомерно решать задачи. (Лучше начинать потихоньку иначе пункт первый на несколько лет)

    Через пол года у твоего мозга закончится адаптационный период и в этот момент начинай думать о своем туловище, оно не будет тебя отвлекать от решения любых умственных задач.
    Книги:
    https://pragprog.com/book/jkthp/the-healthy-programmer
    www.ozon.ru/context/detail/id/4320305
    Ответ написан
    3 комментария
  • На каких IT-специалистов выше спрос за рубежом?

    trevoga_su
    @trevoga_su
    Делая первые шаги в сфере IT

    На каких IT-специалистов выше спрос за рубежом?
    не рано такие вопросы то задавать?
    Ответ написан
    Комментировать
  • Как вызвать репозиторий в symfony 2?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    1) Что-то мне подсказывает что валится оно на чем-нибудь вроде $product->find() а не на том что вы привели.

    2) Лучше делать так

    $this->get('doctrine.orm.entity_manager')->getRepository(Organization::class)


    3) А еще лучше регистрировать репозитории как сервисы

    4) А еще лучше, не наследоваться от доктриновский репозиториев и использовать свои, которым в конструктор передавать entity manager и там уже делать что душе вздумается. Пример (так как это должно быть, в реальных проектах можно упрощать)

    class DoctrineOrganizationRepository implements OrganizationRepository 
    {
        private $em;
        public function __construct(EntityManagerInterface $em) 
        {
              $this->em = $em;
        }
    
        public function getOrganization(int $id) : Organization
        {
               $organization = $this->em->find(Organization::class, $id);
               if (!$organization) {
                     throw new OrganizationNotFoundException();
               }
     
               return $organization;
        }
    }


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

    services:
         organization_repository:
             class: MyApp\Service\Doctrine\DoctrineOrganizationRepository
             autowire: true


    5) Не дробите приложение на бандлы. Они для того что бы реюзать код. Если вы дробите систему на бандлы с мыслью "может потом реюзаю" - это пример преждевременной оптимизации. Вам нужен только AppBundle и то только ради маленьких шорткатов.

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

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    с самого начала у нас есть более-менее абстрактный класс


    Так не должно быть. "абстрактные" классы это способ устранения дублирования, нам больше важны интерфейсы объектов и полиморфизм. Но конкретно в рассматриваемом примере нам важна только инкапсуляция.

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

    Вот и вся разница. Далее вход идет инкапсуляция. То есть наше состояние должно быть изолировано внутри объекта, и доступ к нему напрямую из внешнего мира должен быть закрыт.

    Если мы хотим создать объект с каким-то состоянием по умолчанию - мы берем первый вариант (либо как в примере прописывваем прямо как значение свойства, либо сэтим в конструкторе).

    Если мы хотим создать "пустой" объект и уже потом определить его состояние - мы выбираем второй вариант. Как правило этот способ создает много побочных эффектов если не контролировать его, да и обычно это делают не потому что так правильно а потому что подругому не умеют (типичный пример - сущности доктрины. Многие просто не представляю себе как с ними работать без сеттеров).

    Если же мы хотим создать объект но он не может быть пустым, объект должен требовать начальное значение в момент создания. Тогда мы просто передаем значение в конструктор. Без этого значения (или с неправильным) мы не сможем создать объект. К примеру если у пользователя обязательно должен быть email и пароль имеет смысл "заставлять" разработчиков явно передавать их в конструктор объекта. Это эдакая вариация.

    А теперь попробуем первый и второй подходы вместе + третий кейс с обязательными параметрами:

    class User {
         private $id;
         private $email;
         private $password;
    
         public function __construct($email, $password) 
         {
               // это ваш первый пример только без наследования, оно не нужно
               // в нашей задаче идентификатор пораждается
               // при создании объекта самим объектом, состояние по умолчанию
               $this->id = Uuid::uuid4(); 
    
               // мы требуем входящие данные что бы задать начальное состояние
               $this->email = $email;
               $this->password = $password;
         }
    
         // мутация состояния, второй вариант.
         public function changePassword($password) 
         {
                $this->password = $password;
         }
    }


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

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

    sim3x
    @sim3x
    В общем случае задача не решается

    Читай статьи про настройку безопасности в дебиановых
    Настраивай новый дроплет
    Пересматривай свой код
    Копируй проект на новый дроплет
    Ответ написан
    Комментировать
  • Как ускорить UPDATE MySQL на 100к строк?

    BuriK666
    @BuriK666
    Компьютерный псих
    Делайте update не по одной записи, а пачками с помощью транзакций. например по 1000 шутк.
    Будет заметно быстрее.
    Ответ написан
    Комментировать
  • Как нужно делать рассылку со своего сайта (сервера)?

    @xtreme
    Снимаю порчу по SSH :)
    1. Изучить рекомендации по рассылкам у крупных почтовых сервисов (Google, Yandex, Mail.ru). При подготовке писем для рассылки строго следовать их рекомендациям.
    2. Зарегистрироваться в postmaster.yandex.ru, postmaster.mail.ru, чтобы следить за ходом рассылки писем.
    3. Отлавливать недоставленные письма, убирать их из листов рассылки, дабы не мусорить.
    4. Сделать механизм отписки от рассылки (это один из критериев пункта 1), причем 100% работающий в один клик.
    5. Мониторить нажатие кнопки "Спам" в вышеуказанных почтовых сервисах, также сразу исключать их из будущих рассылок.

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

    Обязательное условие - соблюдать все почтовые правила и не пренебрегать цифровыми подписями - SPF, DKIM, DMARC, правильные записи в DNS (A, MX, PTR).
    Ответ написан
    10 комментариев
  • Высоконагруженный проект на php без фреймворков?

    OnYourLips
    @OnYourLips
    Абсолютно невозможно.
    Вы все равно напишите в процессе работы свой фреймворк, только у вас будут с ним проблемы, которых не было бы с существующими (часть из которых можно решить, затратив большое количество времени и денег).

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

    К тому же не зная ООП, вы навряд ли сможете написать высоконагруженный проект. Не хватит навыков.
    Ответ написан
    Комментировать
  • Как импортировать DB MySQL 3.23 InnoDB в DB MySQL 5.1 InnoDB?

    Melkij
    @Melkij
    PostgreSQL DBA, contributor
    Задампить
    Посмотреть глазами синтаксис. На память - в те исторические времена был type=(storage_engine) вместо engine=(storage_engine) в create table
    Попытаться записать
    Разбираться с возникающими ошибками.
    Profit
    Ответ написан
    Комментировать
  • Спасет ли меня многопоточность?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    много потоков это хорошо, но с ростом количества потоков производительность будет падать ну то есть 8 потоков будут работать не в два раза быстрее чем 4.

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

    Комбинация нескольких потоков (по количеству ядер процессора) и event loop даст максимальную утилизацию процессора.
    Ответ написан
    5 комментариев
  • Стоит ли вьюхи отучать от методов объектов в пользу ассоц. массивов?

    alexey-m-ukolov
    @alexey-m-ukolov Куратор тега Laravel
    На самом деле, такая оптимизация не будет иметь смысла - если мы между контроллером и вью добавим слой, который будет преобразовывать объект, с которым работал контроллер, в массив, с которым будет работать вью, это только ухудшит производительность. Для оптимизации нужно будет вообще отказаться от объектов и работать только с массивами. И этот шаг ни в коем случае нельзя делать, пока вы не будете на 146% уверены, что он необходим.

    Вдобавок, такая "оптимизация" может даже ухудшить дело, потому что не получится реализовать ленивый подсчет данных. Простой пример - если заказ не подтвержден, то не нужно выводить сумму его товаров, а если подтвержден - нужно. Представим, что сумма нигде не хранится и считается на лету из товаров в корзине заказа. При использовании объекта, подсчет суммы не выполнялся бы вообще для неподтвержденных заказов, потому что метод getTotal() не будет вызван в шаблоне. А при конвертации в массив нужно будет высчитывать всё, ведь неизвестно, что пригодится в шаблоне, а что - нет.

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

    Так я и подумал, может стоит сразу приучать вьюхи использовать только ассоц. массивы?

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

    А так вьюха навязывает логику контроллерам и моделям, что та или другая переменная должна быть именно объектом.

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

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

    Да, можно во все классы запилить поддержку ArrayAccess, но какой в этом смысл? Если вью будет работать с объектом, то это только трата времени. Если вью будет работать с массивом, то ArrayAccess тут ничем не поможет - никакого объекта уже нет. Я не вижу смысла делать такой hot swap.

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

    Гораздо эффективнее сделать минимально необходимый дизайн, а потом, если уж припрет, потратить дополнительное время на перенос. По большому счету, то, что вы предлагаете, это Big Upfront Design и я не сторонник такого подхода. Лучше вносить изменения итеративно, исходя из текущих потребностей бизнеса, оплачивающего работу, и не заглядывать далеко в будущее. Есть ненулевая вероятность, что пока вы будете имплементировать в классах ArrayAccessable Interface, заказчик разорится и ваш красивый, расширяемый, поддерживаемый код окажется никому не нужным.

    Разумеется, я утрирую в данном конкретном случае, но мой опыт показывает, что такое отношение является самым выгодным и для меня и для заказчика.

    P.S. Я это всё написал как альтернативную точку зрения для всех, кто будет читать этот вопрос впоследствии. Используйте whatever floats your boat, как говорится, в вопросах архитектуры нет серебряной пули.
    Ответ написан
  • Как одним запросом mysql убить двух зайцев?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    Если нужно выбирать данные параллельными скриптами, то надёжно работает такой вариант:
    UPDATE `emails` SET `status` = 1 WHERE @id := `id` AND `status` = 0 ORDER BY RAND() LIMIT 1;
    SELECT * FROM `emails` WHERE `id` = @id;

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

    akubintsev
    @akubintsev
    Опытный backend разработчик
    Я не уверен, что вам реально нужно 30(!) потоков. Если вам нужно одновременно обрабатывать 30 подключений по http, то с вероятностью в 90% вас устроит один процесс, работающий в асинхронной модели. Для этого хватит и php. Посмотрите в сторону reactphp или amphp.

    Для оставшихся 10% случаев, а может даже и меньше, вам потребуется действительно многопоточность, чтобы как-то разложить нагрузку на ядра процессора. Но это нужно лишь в том случае, если каждое подключение после получения данных производит какую-то очень ресурсоёмкую операцию, блокирующую всё, что только можно, то есть асинхронная модель уже становится бесполезной. В этом случае тоже можно и на php написать, например с помощью icicleio/concurrent, но наверное проще было бы на Go с точки зрения настройки среды выполнения.
    Ответ написан
    Комментировать
  • Аренда железа для поиграть?

    OnYourLips
    @OnYourLips
    Есть же, наверное, возможность какой-то удалённой аренды?
    Сервисы есть, но в России не распространены (нужно, чтобы были в России, чтобы пинг был небольшой).
    К тому же самый большой игрок OnLive просто ушел с рынка.

    Так что проще компьютер купить, к тому же б/у машина для игр будет явно дешевле подписки на полгода к такому сервису.
    Ответ написан
    Комментировать
  • Как ускорить запрос SELECT count?

    Demetriy
    @Demetriy
    веб и мобильная разработка
    Единственный способ ощутимо ускорить COUNT, это не использовать COUNT, для определенных задач есть альтернативы, например если COUNT нужен вам для постраничной навигации, то можно выбирать число страниц больше нужного в n раз + 1 и на основании этого делать пагинацию.

    Пример:
    В таблице 700000 записей, нам нужно вывести десятую страницу с 10 записями с постраничной навигацией: выбираем не 10, а 41 запись (не забываем про офсет), выводим 10, но благодаря тому, что выбралась 31 запись вперед, мы знаем что еще есть как минимум 4 страницы на которые можно отобразить ссылки.
    Ответ написан
    Комментировать
  • Как ускорить запрос SELECT count?

    @shagguboy
    предрасчитывать всё это при insert/update
    Ответ написан
    1 комментарий