• Как привязать footer к низу экрана в Twitter Bootstrap?

    @RomeO_rzn
    Я решил через скрипт, на мой взгляд так проще и не нужно городить враперы и лишние стили, кроме того футер не болтается всё время на экране

    if ($(document).height() <= $(window).height())
    	$("footer.footer").addClass("navbar-fixed-bottom");
    
    Ответ написан
  • Как привязать footer к низу экрана в Twitter Bootstrap?

    Sergei_Erjemin
    @Sergei_Erjemin
    Улыбайся, будь самураем...
    Блин… что за советы… там есть встроенный класс: navbar-fixed-bottom

    <div class="navbar-fixed-bottom row-fluid">
          <div class="navbar-inner">
              <div class="container">
    
    Ответ написан
  • Правда ли, что гарантия на исправление ошибок на год - это стандартная практика?

    Jump
    @Jump
    Системный администратор со стажем.
    Правда ли, что гарантия на исправление ошибок на год — это стандартная практика?
    Что такое стандартная практика? О каких стандартах идет речь? О ГОСТ?

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

    Мне интересно вешают мне лапшу на уши или это действительно распространено?
    При чем тут лапша? Вы договариваетесь, торгуетесь.
    • Заказчику в идеале нужно чтобы вы согласились работать бесплатно и вечно. Это нормально.
    • Исполнителю в идеале нужно чтобы не работать вообще при этом получить пару миллионов сразу, и абонплату в сто тысяч ежемесячно.

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

    Любой каприз за счет клиента.
    Пишите: случае обнаружения недочётов или ошибок, исправляем бесплатно, но не более 100 ч/часов.
    Эти 100 ч/часов включайте в стоимость работ по договору.
    и обычно в договоре пишут порядок приемки и тестирования ПО на соответствие тз. ТЗ соответственно подписано заказчиком.
    Ответ написан
  • Существует ли ограничение по количеству одновременных AJAX запросов из браузера на localhost?

    @SilentFl
    сейчас в хроме лимит в 6 коннектов на один домен (пруф)
    чтобы обойти - делают несколько доменов (domain sharding), либо используют http/2
    Ответ написан
  • Современная соц сеть с помощью JavaScript, какие лучше всего использовать технологии?

    kocherman
    @kocherman
    А зачем вообще что-либо разрабатывать когда всё готово? - Запускайте хоть сегодня!
    Есть такая штука Матрица: https://matrix.org/discover
    Она объединяет в себе множество различных функций, связанных с peer-to-peer-передачей_данных.
    Есть личные сообщения между двумя друзьями.
    Есть возможность подключать к разговорам несколько друзей.
    Есть поддержка открытых комнат(каналов), на которых можно постить новости подключенными ботами, например, из того же телеграмма.
    Есть поддержка прозрачного шифрования peer-to-peer. Необходимо сверять ключи наподобие OTR в Jabber. Также есть поддержка шифрованных комнат, платных комнат и проч.
    Полный список статей от создателей тут: https://matrix.org/docs/develop/
    Подключаемые мосты: https://matrix.org/bridges/
    Описание API: https://matrix.org/docs/spec/
    Исходные коды: https://github.com/matrix-org

    Теперь про клиент к этому хозяйству.
    Клиентов к матрице очень много (официальных только около 20шт): https://matrix.org/clients/
    Один из самых продвинутых клиентов для Desktop - Riot. Как вы и заказывали - вылитый Discord (см. скриншот ниже).
    Сайт проекта: https://riot.im/
    Исходный код: https://github.com/vector-im/riot-web/
    riot-web-large.png
    Ответ написан
  • Современная соц сеть с помощью JavaScript, какие лучше всего использовать технологии?

    @Programmir
    Я тоже делал соцсеть, но на сайт никто не заходил) Пока вам можно не париться. Я использовал просто PHP и jQuery.
    Ответ написан
  • Подключение сторонних разработчиков в стартап?

    apavlyut
    @apavlyut
    www.pavlyut.com
    Микросервисы - многие не в курсе что это не "опимизация технического решения" а оптимизация "управления техническим решением".

    Контроль и управляемость повышается не только на:
    - скорости выкладки
    - безопасности связанности сервисов (один упал - второй работает)
    - скорости (от простоты) разработки и тестирования
    - более точного мониторинга.

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

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

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

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

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

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

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

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

    Решения есть - важно понимать что вы "потяните" сами.

    Если у вас как и говорят "мега идея но вы ничего не можете сами" - вы и не сможете без зависимости от внешних талантов.

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

    Готов ответить детально на каждый вопрос всем желающим в комментариях.
    Ответ написан
  • Подключение сторонних разработчиков в стартап?

    Robur
    @Robur
    Знаю больше чем это необходимо
    Как это вообще по уму делают?

    составляют контракт, дают доступ к коду, получают результат, оплачивают, закрывают доступ к коду.

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

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

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

    inoise
    @inoise
    Solution Architect, AWS Certified, Serverless
    Как уже сказал BasiC2k - модульность проекта спасение в данном случае. Вообще, я большой сторонник предварительного проектирования контрактов. Это совершенно не типичный подход к разработке что сегодня, что 20 лет назад, но при заминке на старте позволяет безболезненно масштабировать команду на дистанции. В этом плане очень хорошо ложится на микросервисную архитектуру и при правильной архитектуре позволяет раздать в разработку разные части системы нескольким командам, которые даже не до конца знают что вы там строите.

    Один нюанс - нужен сильный архитектор из вашего домена)
    Ответ написан
  • Как сегодня писать сайты?

    Epsiloncool
    @Epsiloncool
    Программер, веб-девелопер, гейм-девелопер
    Нормальный вопрос, вспомните себя в молодости: какие были наполеоновские планы по захвату мира? У каждого такие были (а у некоторых даже ещё есть). Но я не буду писать что-то на тему "автор школьник, гыыы", а возьму и отвечу. Потому что я в теме с 2001 года и, кажется, понимаю о чём вопрос.

    Подавляющему количеству бизнесов сегодня не нужен сайт. Инста и фейсбук отлично продают физические товары и услуги. Более половины предпринимателей, тех, которым я лет 5-6 назад делал сайт, сейчас успешно продаются в VK, инсте или FB и ничего не хотят слышать про "свой собственный сайт".

    Большинство из оставшихся не нуждаются в сложных многостраничных сайтах. На самом деле, есть статистика, что простые одностраничные сайты продают в 2-5-10 раз лучше, чем многостраничники. Пользователю просто некуда уходить - там есть самая главная информация о продукте и кнопка "заказать". Он прочитал и заказал. Если пользователь начинает бродить по сайту, он устаёт, его мозг "забивается" и он решает отложить покупку "на потом". Этих предпринимателей успешно закрывают Викс, ЛПгенератор, Тильда и прочие многочисленные "кон стру кторы сайтов". Сделать "сайт" на этих платформах сможет даже школьник (и они делают). Это работа точно не для профессиональной студии разработки сайтов.

    Что делать, если людям нужно продавать больше, чем один товар? Ещё одна требовательная категория - это потенциальные владельцы интернет-магазинов. Раньше был мощный пласт разработки - это как раз таки разработка интернет-магазина. И этот пласт, как вы, наверное, догадались, почти закрыт сервисами.

    И вот сюда, в принципе, вы можете пойти. Ещё не все потребности закрыты. Можно делать модули для OpenCart, допиливать магазы на Woocommerce, есть такой удобный SaaS-сервис Shopify, который тоже имеет API и поддерживает сторонние модули - есть где порезвиться.
    Но опять-таки это не разработка с нуля.

    Многие студии концентрируются на разработке уникального дизайна сайта. Тема интересная и в своё время была довольно прибыльной. Но сегодня в интернетах куча готовых шаблонов, из которых 98% бизнесов выбирают себе дизайн и немножко поднастроив, получают уникальный сайт. Вы можете попробовать зайти сюда, но придётся довольно долго искать хорошего клиента.

    А вот куда можно реально пойти - это разработка больших программных продуктов. Таких заказов мало, куда меньше, чем владельцев микро-бизнесов. Это разработка SaaS, главным образом. Разработка маркетплейсов, сервисов и всё такое прочее, что ещё долго не будет закрыто конструкторами. И вы можете использовать для этого симфони, даже WP и CodeIgniter. Если есть мощь и знание - можете попробовать использовать Nodejs или даже Go.
    Опять-таки скажу ещё раз, что в этой теме не очень много заказов, но все они стоящие. И часто приходится делать не на том, на чём вы привыкли, а на том, что требует сам сервис. Обычно это включает в себя много разных технологий - морда на React, Vue, Angular, основной бэкенд на Nodejs или Go (никаких CMS!), как правило, сразу заказывают и мобильное приложение - так что будьте готовы делать. На первых порах можете проехать на PhoneGap, но часто это решение не годится, заказчики пошли умные, умеют гуглить.

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

    Удачи!
    Ответ написан
  • Разработчик недисциплинированно трекает время. Что делать?

    @0x131315
    Оценивает задачу тот, кто будет её выполнять, с запасом, как ему комфортно, менеджер дополнительно прибавляет процент на риски (исходя из истории и опыта), и резервирует время и бюджет у заказчика.
    Если не получается, чтобы задачу взял тот, кто оценил, тогда особенно важно, чтобы оценка была с запасом. Особенно если задача ушла неопытному разработчику - он её может выполнять вдвое-втрое дольше.

    Разработчики записывают всё время по задаче, как им удобно, в свободной форме, но с привязкой к задаче. Это может быть непосредственно разработка, поддержка, аналитика, консультации - любая полезная деятельность должна быть оплачена.
    Записывают как и когда им удобно, но заранее предупреждаются о сроке закрытия спринта/сделки, чтобы успели проставить время.
    От закрытого времени напрямую зависит их (и не только их) доход, так что если что-то не записали - значит работали бесплатно, мотивация трекать более часто. Опять же нужна прозрачность, чтобы разработчики понимали, что от их записей зависит и их доход и фирмы.

    Систем трекинга много, всяких.
    Но это разработчики - так что в ходу много кастомных, внутренних, даже частных трекеров, которые сливают записи по api в кастомный корпоративный трекер.
    Есть всевозможные клиенты для корпоративного трекера, в т.ч. веб-морда и mobile apps. Разрабатываем сами, кому как удобно, что-то приживается, что-то отмирает - живая экосистема.
    Корпоративный трекер в свою очередь можно синхронизировать с редмайнами. Некоторые клиенты умеют заливать и в трекер и в редмайны, т.к. хранят данные в универсальном формате.

    Оценка по комфортному времени позволяет разработчикам чаще укладываться в оценку, чем не укладываться. Поэтому почти с каждой задачи остаётся какой-то процент неиспользованного времени. Плюс оценка на риски менеджера.
    В конце спринта все неиспользованные часы складываются, и из них покрывается овертайм.
    Овертайм бывает на небольшом проценте задач, но иногда значительный: 200-300%. Не всё можно предусмотреть.
    Почти всегда суммарного запаса часов хватает: например в спринте 10 задач, разработчики оценили их по 5ч каждую, менеджер заложил ещё 5ч на риски, итого 10ч каждая - зарезервировано 100ч на спринт, по итогу 2 задачи уши в большой овертайм, и скушали 30ч, 3 задачи ушли в овертайм, но уложились в риски - ещё 30ч, зато оставшиеся 5 задач уложились в оценку (без рисков), и на них ушло по 5ч - итого зарезервировано 100ч, затрачено 85ч(30+30+5*5), в оценку уложились, заказчик доволен.
    Но так плохо редко бывает, в основном, т.к. разработчики оценивают комфортное время, реально уходит меньше оценки, т.е. оценили в 5ч, сделали за 3-4ч.
    А те часы, что остались после покрытия овертайма, в счёт не выставляются, так что работа обходится как правило дешевле договоренностей. Небольшой приятный бонус для заказчика. Можно смело присваивать эти лишние часы, но долгосрочные отношения на обмане не построить, так что нафиг.
    В случае совсем форс-мажоров, когда выходим за все риски - обсуждаем с заказчиком возможные варианты. Обычно заказчики идут на встречу, и выделяют дополнительные ресурсы.

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

    @SODINNER
    У нас компания достаточно маленькая, но что сделал мой начальник: Он написал простой сайт, куда мы записываем имя компании и потраченное время + проведённую работу. Выполнил задание - добавил на сайт и клиент получает счёт на эти часы. Оплату мы берём за единицы по 15 минут, то есть 3 часа работы это 12 единиц по определённому прайсу, в данном приложении вписываем собственно кол-во единиц.
    Ну и в принципе всё, тут люди говорят что это всё дело на менеджерах, а не на кодерах и нужно дать причину кодерам трекать своё время, но меня с самого начала приучили делать это и я принял это как должное, как одну из обязанностей работы. Но тут всё таки нужно верить каждому на слово, если есть недоверие - этот метод не подойдет. Но он самый простой и легкий, написать такой сайтик вообще труда не составит.
    Но допустим даже работник чуть приувеличил кол-во часов, вписал вместо 4 часа - 5 часов, это разве страшно? Вы же не платите почасово разработчику деньги за проделанную работу, а наоборот, платят вам клиенты. Как дело они не разбираются и такая практика применяется везде, у кого-то меньше, у кого-то больше, но в основном везде. А так в ИТ очень сложно определённо сказать сколько времени займет та или инная задача, ибо уровень квалификации у каждого человека разный, да и мало ли какое рабочее пространство, то никто не будет спорить 4 там часа или 5 часов надо оплатить. Ну это глупость.
    Всё зависит от вашей компании, у нас работает такой метод и весьма успешно.
    Я лично знаю какой прайс выставляется клиентам и когда проделываю работу на определённое кол-во единиц, сразу понимаю что я как минимум заработал для компании больше, чем мне выплатят за этот день и уже могу спокойно выполнять другие задачи, не загоняя себя.
    Ответ написан
  • Разработчик недисциплинированно трекает время. Что делать?

    Robur
    @Robur
    Знаю больше чем это необходимо
    основные вопросы на которые надо найти ответ:

    1. Что думают сами разработчики по этому поводу? Вы с ними общались? какие выводы - что поменяли в основе этого общения?
    2. Зачем самим разработчикам трекать это время? вы на них какие-то ваши менеджерские заморочки перекладываете, им все это не нужно и не должно быть нужно. Зачем им ваша "оценка маржинальности проекта"? У них своей работы хватает.

    Хотите чтобы все трекали время - дайте им внятный повод зачем им это делать и ощущаемую пользу. Например - оплата почасовая.
    "мне нужно чтобы вы это делали" - так себе мотивация. Даже если вы кнута добавите.
    Ответ написан
  • Стоит ли переезжать с Wordpress на статичные сайты (Gatsby, Jekyll, Hugo) и сколько это будет стоить?

    zorca
    @zorca Куратор тега WordPress
    Это просто новомодная фишка. На WordPress аналогичную схему можно организовать, просто отдавая статический кеш страниц напрямую через NGINX. Почитать можно тут: https://github.com/SatelliteWP/rocket-nginx После настройки статическая страница сможет выдержать неограниченную посещаемость и передаваться посетителю неизменно быстро. Стоимость - 4 часа специалиста по настройке вебсервера + лицензия WP-Rocket.
    Ответ написан
  • Какой системой управления проектами Вы пользуетесь?

    Maksclub
    @Maksclub
    maksfedorov.ru
    На работе YouTrack — вполне нравится,
    но ооочень понравился в свое Яндекс.Трекер, когда работал в Яндексе — этот продукт не только внутри, но и на рынке (на 1-го человека вроде бесплатно)
    https://yandex.ru/tracker/
    Ответ написан
  • Что делать, если ServiceWorker застрял в браузерах клиентов?

    evgensenin
    @evgensenin Автор вопроса
    Yii2 || Laravel, vue & nuxt
    Добавил в заголовки ответов АПИ
    clear-site-data: storage
    это сработает только если клиент обновит страницу
    и кэш будет всегда сбрасываться при обновлении страницы (это затрагивает localstorage и потому будет разлогин)
    Ответ написан
  • Граница между front-end и back-end?

    Простой бэк может сделать кто угодно, тем более что в апи можно подставить и статические данные (без БД). Но я так думаю фронтендер не обязан знать как сделать это высокопроизводительным.

    вот простое api, что тут уметь?))

    var express = require('express');
    var app = express();
    
    app.get('/hi', function (req, res) {
      res.json({code:0, message: 'Hello!'});
    });
    
    app.listen(3000, function () {
      console.log('Example app listening on port 3000!');
    });


    get mysite.com:3000/hi
    выдаст {code:0, message: 'Hello!'}
    Ответ написан
  • Граница между front-end и back-end?

    neuotq
    @neuotq
    прокрастинация
    Чтобы там не говорили, бэкэнд может оставаться полностью черным ящиком только для верстальщика, ито с оговорками.
    Фроентэнд разработчик, даже с джун уровня, уже активно работает с получением отправкой данных, интерактивными интерфейсами и тп. Понимать как и почему некоторые штуки там работают нужно. Хорошо даже уметь быстро что-то простое сделать. Я не говорю становится фулстеком в полном смысле этого слова, НО. По хорошему: фронтендер мидл и выше уровня можно с натяжкой назвать фулстеком, просто с большим перекосом на фронт часть.
    Просто даже серверлесс направление, заставляет в той или иной степени понимать процессы происходящие на той стороне.
    Ну и в любом случае, в случае активной практики и развития, вы сами столкнётесь с тем, что иногда нужно даже лезть и писать какие-либо свои простые скрипты.
    Отмечу отдельно, это не значит что нужно с головой падать, пытаться стать фулстеком. знать всё и тп. Нет, я имею ввиду что понимание работы бекенда, а значит и умение делать некоторые вещи, должны будут и прийдут при активной работе и роста вас как специалиста.
    Это же касается тех же софт скилз и менеджерских умений.
    Ответ написан