• Как сделать "наложение " газеты в руки человека на фото?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    > Фото должно быть оригинальным, без сжатия или другой обработки в графических редакторах, сделанным на цифровой фотоаппарат.

    Берешь девушку, даешь ей газету, фоткаешь на фотоаппарат и получаешь то, что требуется.

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

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    Смотря зачем)). Я когда делаю Code Review критерии следующие:

    * Безопасность:
    - Каждый аргумент метода простого типа должен проверяться на тип в случае его проксирования и на граничные значения в случае обработки. Чуть что не так - бросается исключение. Если метод с кучкой аргументов на 80% состоит из поверки из аргументов - это вполне норм))
    - Никаких trigger_error, только исключения.
    - Исключения ДОЛЖНЫ быть человеко-понятны, всякие "Something went wrong" можно отдавать пользователю, но в лог должно попасть исключение со стектрейсом и человеко-понятным описанием, что же там пошло не так.
    - Каждый аргумент (объект) метода должен быть с тайпхинтингом на этот его класс, или интерфейс.
    - За eval как правило шлю на **й.
    - @ допускается только в безвыходных ситуациях, например проверка json_last_error.
    - Перед работой с БД - обязательная проверка данных.
    - Никаких == и !=. Со swtich - единственное исключение, по ситуации.
    - Если метод возвращает не только bool, а еще что-то - жесткая проверка с ===, или !== обязательна.
    - Никаких условий с присваиваниями внутри. while($row = ...) - тоже идет лесом.
    - Магические геттеры/сеттеры разрешаются только в безвыходных ситуациях, в остальном - запрещены.
    - Конкатенации в sql - только в безвыходных ситуациях.
    - Параметры в sql - ТОЛЬКО через плейсхолдеры.
    - Никаких глобальных переменных.
    - Даты в виде строки разрешаются только в шаблонах и в БД, в пхп коде сразу преобразуется в \DateTimeImmutable (в безвыходных ситуациях разрешено \DateTime)
    - Конечно зависит от проекта, но как приавло должно быть всего две точки входа: index.php для web и console(или как-то по другому назваться) - для консоли.

    * Кодстайл PSR-2 + PSR-5 как минимум, + еще куча более жестких требований (для начала все то что в PSR помечено как SHOULD - становится MUST)
    - В PhpStorm ни одна строчка не должна подсвечиваться (исключением является typo ошибки, например словарик не знает какой-то из аббревиатур, принятых в вашем проекте). При этом разрешается использовать /** @noinspection *** */ для безвыходных ситуаций.
    - Если кто-то говорит, что пишет в другом редакторе и у него не подсвечивается, на эти отговорки кладется ВОТ ТАКЕЕЕНЫЙ мужской половой **й и отправляется на доработку)).

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

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

    * Принципы MVC:
    - Никаких обработок пользовательского ввода в моделях, от слова совсем.
    - Никаких ***ть запросов в БД из шаблонов.
    - Никаких верстки/js/css/sql-ин в контроллерах.
    - В моделях НИКАКОЙ МАГИИ, только приватные свойства + геттеры с сеттерами.
    - В моделях разрешено использовать метод save(при наличии такого разумеется) только в исключительных ситуациях. Во всех остальных - либо insert, либо update.

    * Принципы SOLD:
    - Никаких божественных объектов умеющих во все.
    - Если метод для внутреннего пользования - private, никаких public.
    - Статические методы разрешаются только в случае безвыходности.

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

    * Работа с БД:
    - Запрос в цикле должен быть РЕАЛЬНО обоснован.
    - За ORDER BY RAND() - шлю на***й.
    - Поиск не по ключам (конечно если таблица НЕ на 5 строк) запрещен.
    - Поиск без LIMIT (опять же если таблица НЕ на 5 строк) запрещен.
    - SELECT * - запрещен.
    - Денормализация БД должна быть обоснована.
    - MyISAM не используется (так уж)) )
    - Множественные операции обязательно в транзакции, с откатом если чо пошло не так.
    - БД не должна содержать бизнес логики, только данные в целостном виде.
    - Не должно быть нецелесообразного дерганья БД там, где без этого можно обойтись.

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

    * О людях:
    - "Я привык писать так и буду дальше" - не вопрос, ревью пройдешь только когда поменяешь свое мнение.
    - "Я пишу в vim-е и мне так удобно" - здорово, код консолью я тоже в нем пишу)) но есть требования к коду, если в них не сможешь - не пройдешь ревью.
    - "Я скопировал этот страшный метод и поменял 2 строчки" - это конечно замечательно, но по блейму автор всего этого метода ты, так что давай без говняшек, хорошо?
    - "Оно же работает!" - вот эта фраза переводится примерно так: "да, я понимаю, что пишу полную хрень, но не могу писать нормально потому, что руки из жо", я правильно тебя понял?))
    - "У меня все работает!" - рад за тебя, а как на счет продакшна?
    - "Там все просто" - не используй слово "просто", от слова "совсем". Вот тебе кусок кода (первого попавшегося с сложной бизнес логикой), где там ошибка (не важно есть она, или нет)? Ты смотришь его уже 2 минуты, в чем проблема, там же все "просто"))

    * Всякое:
    ActiveRecord (это я вам как в прошлом фанат Yii говорю) - полное говно, примите за исходную. По факту у вас бесконтрольно по проекту гуляют модельки с подключением к БД. Не раз натыкался на то, что в тех же шаблонах вызывают save, или update (за такое надо сжигать).
    То, что используется Laravel - это печально((. Что бы выполнить требования приведенные выше, приходится "воевать" с фреймворком.

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

    UPD

    Формализировал данные критерии по ссылочке: https://github.com/index0h/php-conventions
    Ответ написан
    55 комментариев
  • Как организовать план дальнейшего развития front-end разработчика?

    L0k1
    @L0k1
    на рынке вебдева всегда был, есть и будет кадровый голод.
    если ты не можешь никуда устроиться - либо очень много просишь, либо себя переоцениваешь и "довольно неплохой" не соответствует действительности.

    в любом случае это полотно текста ("Доогой дневник ... ") не для тостера
    Ответ написан
    1 комментарий
  • Какие существуют практики показа проекта заказчику при разработке?

    saboteur_kiev
    @saboteur_kiev Куратор тега Веб-разработка
    software engineer
    Поднимите сайт на нестандартном порту.
    Ответ написан
    Комментировать
  • Какие существуют практики показа проекта заказчику при разработке?

    magalex
    @magalex
    Архитектор распределённых систем управления
    Сделайте авторизацию по паролю с помощью .htaccess и .htpasswd
    Ответ написан
    Комментировать
  • Какие существуют практики показа проекта заказчику при разработке?

    webirus
    @webirus
    Тыжверстальщик! Наверстай мне упущенное...
    Установка HTACCESS пароля на вход полностью
    https://htmlweb.ru/service/htpasswd.php
    Запрет индексации через роботс, достаточно
    yapro.ru/web-master/xhtml/kak-zapretiti-indeksaciy...
    Ответ написан
    Комментировать
  • Области применения JS в современном IT?

    @nirvimel
    Кроме js вы пробовали только php, и этот горький опыт заставил вас остановить свой выбор на js? Не стоит на таком примере делать выводы обо всех других языках. В сфере профессионалов принято не подыскивать новые задачи под единственный известный язык, но, наоборот, подбирать (и изучать при необходимости) язык исходя из стоящих задач. Прежде чем останавливать свой выбор на каком-то конкретном языке или стеке технологий вам нужно сначала определиться с тем кругом задач, о области которых вам интересно работать, и потом подходить к выбору инструментов для решения этих задач. Все зависит от того что вас интересует: web-разработка, фронтэнд, бекэнд, десктопные приложения или мобильные, разработка игр, больше/меньше заниматься пользовательским интерфейсом, может быть, системное программирования?
    Ответ написан
    7 комментариев
  • Нужно ли тратить кучу времени на задачу, которую знаешь как можно решить, но не до конца получается самому реализовать решение?

    saboteur_kiev
    @saboteur_kiev Куратор тега Программирование
    software engineer
    Сохраняй написанные тобой скриптики в какую-то папку.
    И подсматривай в них, если нужно написать банальные циклы.
    Иногда можно найти новый алгоритм в инете и сравнить у тебя так же или что-то новое.

    А на самом деле, 2 месяца - ОЧЕНЬ МАЛО. Копи опыт и примеры своих рабочих скриптов. Каждый программист юзает свои шпаргалки
    Ответ написан
    Комментировать
  • Стоит ли работать программистом?

    akubintsev
    @akubintsev
    Опытный backend разработчик
    Каково быть программистом?
    Я не стану писать про идейно-мотивационную часть, этого всегда хватает в ответах на такие вопросы. Только прагматичный взгляд.
    Да всего хватает. И мартышкиного труда, и действительно интересных задач, связанных с проектированием. Много зависит от того, какой проект и на какой фазе своего существования. Поэтому вы и увидели частые смены работ у наших коллег.

    Немного могу ободрить на тему начальных зарплат в веб-деве. 25-30к - это для студентов. С ходу же можно найти место за 50-60к, но конечно должна быть хоть какая-то минимальная база знаний, чтобы пройти собеседование. Надо только понимать, что в одной конторе за зарплату X рублей будут искать чуть ли не тимлида, а в другой - джуниора. Немного терпения или везения и найдёте, что желаете. Главный вопрос задайте только себе "чему я смогу тут научиться (и у кого)?", иначе в пустую потеряете время и нервы.

    Но в работе стажировщика-студента есть плюс - дадут реально фундаментальную базу и прыгнуть потом можно спокойно уже на уровень 80к (вы только не сознавайтесь, если спросят, сколько платили на прошлом месте :)))

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

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

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

    sim3x
    @sim3x
    Да
    Ответ написан
    Комментировать
  • Что сделать что бы работало?

    profesor08
    @profesor08 Куратор тега JavaScript
    Все просто. Можно заморочиться с таймаутами и рекурсиями как в примерах выше. А можно сделать логически правильно - интервалом, как в этом примере:
    var counter = 4;
    var inter = setInterval(function() {
      a.innerHTML = counter--;
      if (!counter) clearInterval(inter);
    }, 2000);
    Ответ написан
    2 комментария
  • Как лучше всего организовать методы?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    Почитайте о стилях программирования. Почитайте о соглашениях именования имен переменных и методов. Почитайте для чего это нужно.
    Неважно насколько длиннее код в бэкенде, если он легче читается. пару байт туда-сюда, зато если вы проект на месяц отложите а потом надо будет поковырять, не будете вспоминать что это за get а что то за get.
    Ответ написан
    3 комментария
  • Как суммировать тысячные в javascript?

    Shutik
    @Shutik
    Погромист халявщик
    замените parseInt на parseFloat:
    var value1 = parseFloat($(".value").text())
    Ответ написан
    1 комментарий
  • Как осознать что требуется и понять суть происходящего по "придумыванию интерфейса"?

    pozZzitiv
    @pozZzitiv Куратор тега Дизайн
    Дизайнер и перфекционист
    Если это дословное задание, а не вольный пересказ, то четко написано: необходимо придумать интерфейс.

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

    Ronnie_Gardocki
    @Ronnie_Gardocki
    Я у мамы фронтендщик.
    Как уже написал другой человек - сидите на работе, пока не найдете альтернативы. Безвыходных ситуаций не бывает. Ищите по удаленке, ищите фриланс, просто ищите как угодно. Когда дело доходит до горящей ситуации, внезапно выясняется что искать новую работу намного проще, чем казалось, пока вы сидели на пригретом месте.
    Ответ написан
    Комментировать
  • Стоит ли уходить с работы?

    @EvgeniyKonstantinov
    "Приходите завтра и остаетесь" ровно до того момента пока не найдете себе комфортную работу.
    Ответ написан
    7 комментариев
  • Как запустить скрипт с условием, что на страницу зашли с другого сайта?

    In4in
    @In4in
    °•× JavaScript Developer ^_^ ו°
    document.referrer содержит адрес, с которого был совершен переход на текущую страницу. Проверяйте его на несоответствие текущему домену и делайте, что нужно.
    Ответ написан
    3 комментария
  • Стоит ли работать программистом?

    @RadmirZ
    Делаем интернет-магазины на движке minicart.su
    Занимайтесь тем что вам нравится. Вот и весь секрет, нравиться кодить - ктож будет мешать. Хотите денег - это уже другой вопрос. Но могу сказать точно что многие знакомые ушли в IT в реальный бизнес (купил-продал, услуги оказал), то есть в какой то бизнес в реальности, так чтобы было наоборот я редко вижу.
    Ответ написан
    Комментировать