• Какие есть программы для учёта времени работы удалённого программиста?

    @hatman
    Работаю в компании, где порядка 50 сотрудников удаленщики. Учет времени идет по Jira - время ставит сам программист. Учет идет так:

    Приходит готовая таска
    Идет код ревью
    Ревьювер чекает адекватность оценки времени
    Если есть вопросы, то уточняется, в чем была сложность

    За 3 года уволили только одного разраба, который "попал в пустыню печали и скорби", и просто две недели ничего не делал.
    __

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

    dollar
    @dollar
    Делай добро и бросай его в воду.
    Любые варианты снимков экрана. Всё остальное не надёжно.

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

    Как известно, сотрудников лучше не контролировать, а мотивировать.

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

    По сути если программист адекват, то можно смело игнорировать всё, что вы увидите. Если мало работает, можно начать задавать вопросы, возможно у него проблема в жизни, а вы возможно сможете помочь, и тогда он станет более эффективен. И лишь если очевидно, что он вас жестко динамит, тогда можно конфликтовать. Имхо.
    Ответ написан
    7 комментариев
  • Зачем нужен frontend, если всю начинку сайта или проекта можно реализовать с помощью backend'a?

    @nrgian
    1) "Все на сервере" - так уже делали. Начиная с зари эпохи начала доступности компьютеров. Гуглите dumb terminal. И существовали до недавнего времени в широком обиходе кое-где, несмотря на веб-технологии. Например, во Франции.

    2) Вам никто не мешает написать на Python как серверную часть, так и клиентскую часть.

    3) JavaScript, CSS, HTML - это просто потому, что вместо установки на компьютере пользователя отдельной программы для каждого сервера придумали одну общую программу - браузер, внутри которой уже реализуются клиенты для различных серверов. Ну и исторически так сложилось, что внутри браузера поддерживаются только эти 3 языка на сегодня. Если вы не желаете использовать эти языки, не желаете использовать браузер - то см. п. 2)
    Ответ написан
    3 комментария
  • Зачем нужен frontend, если всю начинку сайта или проекта можно реализовать с помощью backend'a?

    profesor08
    @profesor08
    Релизуй реактивность на php. Или давай чего попроще, отобрази в браузере красную кнопку на php без использования HTML и CSS, а изюминкой добавь чтоб при нажатии пользователю выскакивал алерт "Hello world", не используя JavaScript.
    Ответ написан
    5 комментариев
  • Как менять количество точек картинки (resolution)?

    @Kim_Soal
    а разве увеличение Pixels/Inch не влечет за собой увеличения количества пикселей?
    Pixels/Inch нужен же для печатного оттиска. В обычном формате, это просто увеличение картинки.
    Иными словами, считаете сколько пикселей при вашем Pixels/Inch должно быть и увеличиваете картинки, само собой, с потерей качества
    Ответ написан
    Комментировать
  • Правильное хранение изображений на сервере

    afiskon
    @afiskon
    У вас есть множество серверов для хранения картинок. Возможно. тех же самых, на которых работают и скрипты, не важно. Вы на этих серверах держите специальную приложеньку для заливки картинок. Когда приходит картинка, выбираете случайным образом один из серверов (держите список в MySQL/Redis/неважно), заливаете картинку, получаете обратно ссылку. В базу пишите ссылку img123.myproject.com/123/45/38475.jpg.

    Если сервер дохнет, поднимаете новый, присваиваете ему имя img123.myproject.com, восстанавливаетесь из бэкапа, снова все работает. Раздавать картинки, разумеется, нужно не через приложеньку, а напрямую через nginx.

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

    nikel303
    @nikel303
    Можно хранить имя файла (good.jpg) и тип картинки (goods), например картинка товара, на основе этой информации строить путь, так, как вам угодно, например:
    /media/origin/goods/g/go/good.jpg
    /media/origin/goods/t/to/tovar.jpg

    Если нужно сохранить картинку с таким же именем, то в конец дописываем индекс, например:
    /media/origin/goods/g/go/good.jpg
    /media/origin/goods/g/go/good__1.jpg
    /media/origin/goods/g/go/good__2.jpg

    Подпапки после типа картинки /g/go/ нужны, чтобы в одну директорию не сваливалось слишком много файлов.

    Если в качестве имени файла используются цифры (напрмер - это индексы записей в базе), то подпапки лучше формировать с конца имени файла, например:
    125.jpg -> /5/2/125.jpg
    126.jpg -> /6/2/126.jpg
    это позволит более равномерно распределять файлы по папкам.

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

    Закешированые картинки соответственно будут храниться, например, по такому пути /media/cached/goods/<название пресета (200x120r)>/go/g/good.jpg

    Пресет можно формировать, например, на основе ширины, высоты, способа масштабирования, и названия фильтра
    Ответ написан
    Комментировать
  • Как генерировать png на 300 точек в php?

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

    На практике вы можете что то гарантировать, если программное обеспечение (и даже устройство) обеспечение у клиента совпадает с вашими тестовыми стендами, тогда пользуйтесь хоть html или даже ms word (вот уж где геморой).

    Если вы хотите попробовать печать именно изображения, используйте метод GD - setImageResolution. Кажется в jpeg эти данные могут быть сохранены.

    p.s. изображение может состоять хоть из 1 пиксела, но выставив разрешение например 1dpi то этот пиксел на бумаге станет (должен стать) квадратом в 1 дюйм.
    Ответ написан
    1 комментарий
  • Как генерировать png на 300 точек в php?

    ThunderCat
    @ThunderCat Куратор тега PHP
    {PHP, MySql, HTML, JS, CSS} developer
    DPI это условный параметр, который высчитывается в привязке к материальным размерам, реальных же параметров цифровой картинки всего два - ширина и высота в точках. Извращенные штуки а-ля пиксел ратио в расчет не берем. По этому берете ширину/высоту конечного изделия в см, переводите в дюймы и умножаете на 300, получите количество точек по соответствующей стороне.
    Ответ написан
    Комментировать
  • Почему Windows-юзеры обычно держат окна приложений развёрнутыми на весь экран, а пользователи macOS — нет?

    Sanasol
    @Sanasol
    нельзя просто так взять и загуглить ошибку
    Потому что на макоси по другому работает рабочий стол и разворачивание на весь экран.
    И навигация по экранам идёт, а не переключение между активными окнами как на винде.
    Если на макоси развернуть на весь экран(по зеленой кнопке "разворачивания" окна), то работать с двумя окнами уже не получится например, развернутый софт всегда будет на своём экране без всего остального. Никаких окон поверх него нельзя разместить, только если рядом на половину экрана растянуть что-то другое.
    При этом есть второй режим это двойной клик в любом месте по шапке окна, тогда окно как раз развернется как в винде. Но я так и не смог осилить этот вариант т.к. навигация удобнее при использовании нескольких рабочих столов. И получается что режим как в винде вроде бы есть, а вроде бы он вообще здесь не к месту. Хотя иногда он помогает когда всё-таки надо использовать несколько связанных окон(например Chrome + Developer Tools отдельным окном при разработке расширения для хрома это вообще единственный возможный вариант работы).

    Так что просто по разному работает. Причем в винде это местами удобнее чем на маке, но на маке свои плюсы есть.
    Ответ написан
    5 комментариев
  • Быстрый старт в никуда?

    saboteur_kiev
    @saboteur_kiev Куратор тега IT-образование
    software engineer
    Посоветуйте человеку научиться пользоваться поиском.
    Если не осилит работу с поиском и не прокачает навык поиска уже готовых ответов - пусть смело забивает на IT.
    Ответ написан
    Комментировать
  • Можно ли собеседоваться в другие офисы крупной компании (google, amazon, etc.) сразу после отказа?

    inoise
    @inoise Куратор тега Карьера в IT
    Solution Architect, AWS Certified, Serverless
    Все зависит от компании, но вы серьезно считаете что если вам дали отказ то стоит это делать? "Первый признак шизофрении - делать одно и тоже, ожидая разный результат"
    Ответ написан
    5 комментариев
  • Каковы _существенные_ (практически значимые) отличия Symfony от Laravel?

    @EvgeniiR
    https://github.com/EvgeniiR
    Eloquent = Doctrine?)
    Советую вам хоть немного разобраться что это такое, и какие паттерны реализованы в Доктрине, а какие в елоквенте.

    Мне в Laravel понравилась свобода - то есть при желании я могу запросто напихать в шаблоны PHP-код и в запросы к базе - RAW-SQL и запихнуть эти запросы хоть в роутер))))
    Пишите на чем угодно, все равно в помойку отправится, потому что подерживать такое никто не будет.
    Фреймворк для того что вы хотите делать не нужен вообще.

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

    Опять же - вам не нужен фреймворк. Фреймворк это каркас для приложения которое вы будете писать.

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

    @EvgeniiR
    https://github.com/EvgeniiR
    1. PHP умирает на каждый запрос. Это его главное преимущество и особенность. Это допускает очень много вещей, т.е можно не париться закрытием файлов, завершением подключения к БД и т.п. Как только вы захотите писать асинхронно вам про всё это нужно будет помнить.

    2. Итак, плавно переходим к тому что помнить, вобщем то, нужно будет не только вам. 99% всех библиотек/фреймворков etc. для PHP не пригодны к работе асинхронно.

    3. "полностью асинхронным" = отсутствие блокировок? Первое на чем вы споткнетесь - банальные запросы к базе. С дефолтным драйвером они идут синхронно. Точно так же как синхронно работает куча других подключений, и всякие Swoole etc. вынуждены писать над всем этим свои обертки и свои драйвера к БД.

    Вобщем, асинк в PHP это огромное усложнение на пустом месте, и при наличии блокирующих операций не имеет никакого смысла. Сильно проще сменить язык программирования, если вам нужна асинхронщина.
    По описанию вашего вопроса - гляньте RoadRunner, интересная штука. Как раз чтобы сократить оверхед на инициализацию.
    Есть ещё всякие штуки аля https://github.com/php-service-bus/service-bus , но повторюсь, проще подходящий ЯП взять.
    Ответ написан
    6 комментариев
  • Какой js canvas framework подойдёт для решения этой задачи?

    Fzero0
    @Fzero0
    Вечный студент
    Ответ написан
    Комментировать
  • Какие области в веб - разработке осваивать в перспективе?

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

    1. Ваш первый пункт вытекает из второго. Если вы умеете п. 2, то и п. 1 вы сможете научиться (быстро). Уметь только в CMS это примерно как уметь забивать гвозди только одного вида (а ведь могут потребоваться и другие гвозди).
    2. Вам нужно понимать, что есть задача, а есть инструмент. Все что вы перечисляете - это инструменты для решения задач. Какие инструменты изучать? Инструменты, которые подходят под задачи, которые вы решаете. Какие задачи вы решаете или хотите решать? Это основной вопрос.
    3. Не стоит обращать внимания на длительность уроков. Никто не начинает работать только после того, как просидит N часов за теорией и N часов за практикой. Осваиваете базу, начинаете что-то делать на реальных задачах и постепенно учитесь (не в ущерб времени и деньгам клиента конечно же).
    4. Этот пункт - продолжение третьего. Вы смотрели что такое jQuery? Вы пытались им пользоваться? Зная js, приучить себя к jquery можно за 3-4 проекта. Надо просто брать и делать, а не думать: "там по jquery уроков на 300 часов, видимо это слишком сложно для меня". Вам нужно брать и начинать.
    5. Задачи всегда бывают разные, следовательно и подбор инструментов тоже, следовательно нужно знать и jQuery и Vue.js, а не что-то одно. Не всегда же вы пилить SPA будете? Кому-то потребуется сделать простой калькулятор, чтобы человек мог его поправить потом. Будете использовать Vue, который клиент может не знать? Или все же jQuery или нативный js? Ответ очевиден.

    Опишу свою ситуацию:
    1. Начинал с HTML + CSS
    2. Начал учить JS и параллельно Jquery (никогда так не делайте, сначала js, потом jq).
    3. При набранном опыте я смог нормально освоить Vue за 1 проект (объемный).
    4. Так как иногда роюсь в PHP, освоиться в Laravel на уровне: есть проблема - знаю где посмотреть и как ее решить в случае чего, смог за 1 проект длиною в месяц.

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

    Поэтому вам нужно:
    1. Определиться с выбором области работы, судя по вашему вопросу у вас выбор между фронтом (javascript + frameworks) и беком (python, php + frameworks)
    2. Далее загуглить road map по фронту или бекенду (в зависимости от вашего выбора)
    3. Поступательно двигаться и не бояться.
    4. У вас еще хватит времени прожить счастливую и долгую жизнь.

    P.S вся эта арифметика со скоростью изучения фреймворком исключительно мой опыт, у кого-то быстрее, у кого-то медленнее. Дабы внести разъяснения, добавлю: я вполне себя спокойно ощущаю в том или ином фреймворке, однако не являюсь очень серьезным разработчиком.

    P.S.S Отвечая на главный вопрос: "Какие области в веб — разработке осваивать в перспективе?" - в перспективе нужно становиться разработчиком, у которого есть достаточно опыта в смежных областях, есть знания, помогающие решать те или иные задачи (чем сложнее задачи, тем больше ваша зп, тем вы ценнее), и постоянное развитие, так как наука продвигается, задачи и их сложность меняется, инструменты добавляются и так далее. И не забывайте, программирование это не только делать сайты или приложения, если области задач, не связанные с веб разработкой, но которые тоже интересны.
    Ответ написан
    7 комментариев
  • В чем смысл быть гуру тостера?

    sashkets
    @sashkets
    Прекратил отвечать после 24.02.2022
    «ДАРОМ получили — даром давайте» (Матфея 10:8)

    П.С.
    Был случай, когда человек так нуждался в помощи, что рискнул дать рута. Помог. Моральное удовлетворение.
    Ответ написан
    Комментировать
  • Какой наиболее "ремонтопригодный" движок на PHP для интернет-магазина?

    @truegrover
    конечно же https://laravel.com
    Ответ написан
    Комментировать