• Как поступить с заказчиком который не платит?

    werevolff
    @werevolff
    50% - абстрактная цифра. Необходимо показать менеджеру работу. Но не код. Т.е. на доступном серваке разворачиваете код, кидаете ссылку, сверяете по пулу задач/ТЗ, какие пункты сделаны. Если полноценно ни одного - какие требования оплаты вообще могут быть? Если там реально наберётся процентов 40 сделанных тасков, то можно обсудить условия оплаты и предоставления кода. Но с такими прокатами я бы лично не стал работать дальше в этом проекте. Если только ребята согласятся поднять оплату и заплатить сразу 50% от новой суммы, а не аванс от старой. И дело не в том, что это хорошо или плохо. Просто разработчик и заказчик берут на себя обоюдные обязательства. Искать нового программиста для доделки 60% проекта - это гарантированное увеличение бюджета и трата времени. Если люди реально готовы платить, а не обманывать, они вам предложат такое увеличение при условии адекватной демонстрации с вашей стороны.

    Резюмирую:

    1. Поднимаете проект на своей стороне.
    2. Проводите демонстрацию.
    3. Отмечаете закрытые пункты заказа.
    4. Ставите заказчика перед фактом: "исходник он получает при условии оплаты обещанного аванса, но при таком отношении, после передачи кода вы уходите из проекта". Основание: вы не получили пока ни копейки. Договора нет. Со стороны заказчика устное соглашение не соблюдалось и нет гарантий, что будет соблюдаться. Если заказчик настаивает на исполнении обязанностей, говорите, что отдадите код после подписания договора. Юридически, если нет договора, факт оплаты подтверждает сделку. Т.е. договор или оплата. Предпочтительно - оплата.
    5. Если сошлись на оплате, и заказчик просит пересмотреть ваш уход из проекта, отказываетесь до тех пор, пока заказчик не поднимет ценник. Сами ищите другой проект. Не факт, что заказчик пойдёт на уступки. Если второго проекта не будет, а заказчик согласится поднять цену, пусть доплатит сразу так, чтобы в сумме вышло 50% от общей суммы. Завершаем проект, радуемся.
    Ответ написан
  • Как передать параметр id в контроллер?

    @springimport
    Как на счет этого?

    И вообще.
    Ответ написан
    Комментировать
  • Как деплоются приложения Java EE?

    @bobzer
    Java EE Developer
    нужно обновить частично, только один модуль
    Соответственно, этот модуль должен быть самостоятельным артефактом Maven. Обычно, артефакт для EAR описывает формирование приложения из других модулей и конфигурационных файлов. Следует разбить приложение на артефакты (обычно jar/war), которые входят в состав EAR.

    Вообще, при сборке для промышленной среды надежнее собирать всё приложение (EAR в вашем случае) целиком. А при сборке для окружения разработчика вообще удобнее использовать не сборщик Maven, а среду разработки. Idea, например, прекрасно понимает формат конфигураций Maven и на их основе может создавать свои артефакты (и настоятельно порекомендует это сделать при обнаружении pom.xml). Если собирать артефакты с помощью Idea, то даже при сборке EAR целиком фактически будут обновляться только изменённые файлы, что ускоряет процесс сборки на порядки, в сравнении с Maven. Это достигается за счёт того, что у Idea есть свой контроль версий и она знает что именно следует пересобрать, а что можно оставить как есть. Наибольший выигрыш получается для exploded артефактов (которые не архивируются, а выкладываются в виде структуры папок с файлами), т.к. в таком случае не приходится перепаковывать модули целиком при изменении небольшого количества файлов в них.

    Для каждого артефакта Maven Idea создаст две версии своих артефактов - упакованную и не упакованную (exploded). В случае, если ваше приложение состоит из нескольких модулей, может потребоваться ручное вмешательство в сгенерированные артефакты, т.к. exploded-артефакт верхнего уровня в конфигурации по-умолчанию содержит подчинённые артефакты в упакованном виде. Потребуется удалить вариант в упакованном виде и на его место вставить exploded-вариант. Минус состоит в том, что при изменении артефакта Maven, Idea предложит перегенерировать и свои артефакты, все ручные настройки при этом пропадут. Но настройки топологии проекта меняются нечасто, поэтому лишней минутой работы по ручной реконфигурации обычно можно пренебречь...

    Если Вы только начали экспериментировать с Java EE, то создание EAR может быть неоправданным усложнением, т.к. во многих случаях веб-артефакт более низкого уровня - WAR - прекрасно справляется со всеми задачами Enterprise-приложения. При этом получается более простая структура, соответственно и с настройкой сборки проблем меньше.
    Ответ написан
    4 комментария
  • Как добавить комментарии ВК (Django)?

    ImmortalCAT
    @ImmortalCAT
    C# loving
    Ответ написан
    Комментировать
  • Что нужно знать php разработчику для изучения фреймворка? Ваше мнение?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    За любым фреймворком лежит опыт и мировоззрение его разработчиков. У любого фреймворка есть глубинная философия, его смысл, для чего он создан, какие проблемы решает, в каком контексте. Не смотря на то, что, казалось бы, разные фреймворки решают набор примерно одних и тех же проблем, делают они это очень по разному.

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

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

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

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

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

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

    Я сильно сомневаюсь, что даже многие из тех, кто сегодня зовутся синьорами, в достаточной степени владеют контекстом.

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

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

    В результате я плюнул на тщетные попытки, и просто, из проекта в проект, собрал свой мини фреймворк, который решает задачи в том контексте, который выработался за годы у меня, решает понятным и прозрачным для меня способом, под полным, 100% контролем с моей стороны.

    Сейчас же я взял паузу, и намерен полностью мигрировать с PHP на JavaScript. При всей моей любви и уважении к PHP, в нем определенные вещи даются слишком большими усилиями, так-что игра не стоит свечей.
    Ответ написан
    1 комментарий
  • Тестирование в Django - лучшие практики?

    @marazmiki
    Укротитель питонов
    Насколько я понял, речь не о лучших практиках тестирования как таковых, а именно о заполнении моделей.

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

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

    Через него можно создавать модель, содержащую только нужную информацию. Всё остальное (включая реляции) будет заполнено автоматически, если нужно. Очень удобно и очень просто. И очень гибко.
    Ответ написан
    Комментировать
  • Стоит ли изучать Java после прекращения разработки EE?

    jaxtr
    @jaxtr
    JavaEE/Spring-разработчик
    Для начала: Java != Java EE. Прекращение разработки Java EE со стороны Oracle никак не повлияет на жизнь самого языка программирования. Есть вообще сомнения, что Oracle решится на этот шаг, т.к. у них самих большое количество проектов именно на Java EE разработано.

    Плюс стоит помнить, что Java EE - это набор спецификаций, а не конкретная реализация. Java EE состоит из кучи JSR, которые обсуждаются и принимаются JCP (Java Community Process), то есть сообществом, в котором кроме самих Oracle есть Red Hat, IBM, Spring, Apache и многие другие. Oracle может просто передать управление Java EE сообществу. И да, новые JSR выходят вне зависимости от Java EE.

    И стоит помнить, что на Java EE интерпрайз не кончается, ведь есть ещё Spring, который развивается гораздо быстрее и занимает существенную нишу на рынке.

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

    mahnunchik
    @mahnunchik
    https://about.me/vlasenko
    Сервисы не мои, но меня поразило обилие информации:
    • passports.io - сравнение возможностей проживания и получения гражданства в разных странах
    • incorporations.io - сравнение стран для создания компании, налоги, отчётность, легальность итд
    • bankaccounts.io - сравнение банков для открытия "международных" счетов
    • flagtheory.com - разложенные по полочкам планы как уйти в офшор
    Ответ написан
    Комментировать
  • Как заставить Django запускать Python скрипт через каждые N минут?

    sim3x
    @sim3x
    Прямо из джанги django commands
    Для запуска через промежутки cron
    Для удаления файлов старше х-дней ни джанго, ни питон не нужны
    Ответ написан
    Комментировать
  • Как вывести из mysql адреса на карту яндекс?

    Settler1
    @Settler1
    Правильно написанный вопрос - половина ответа
    По идеи так:
    var myGeocoder = ymaps.geocode("Адрес писать тут");

    Однако я бы все таки вписывал в базу данных координаты, поскольку он не всегда определяет правильно, если у вас опечатка например или адрес без указания города - может запросто не там где надо поставить маркер
    Ответ написан
    Комментировать
  • Как выбрать правильный путь в PHP(Python) фреймоврке/CMS, чтобы не закопаться?

    b0nn1e
    @b0nn1e
    Alcohol & Ruby on Rails
    Сейчас просто php программист, не кому не нужен. Востребован опыт работы с определёнными CMS/Фреймворками. Тут вам нужно выбрать какой фреймворк вам нравится(читай востребован) и набираться опыта с ним.

    Ну а в общем я бы вам порекомендовал не связываться с php.
    Набирайтесь опыта в Ruby/Python, тут минимальный уровень, когда тебя забирают с руками и ногами, на много вышет, но оно того стоит. На php вы рискуете на пару лет застрять на тягивании верстки на wp и подставлении костылей битриксу.
    Ответ написан
    5 комментариев
  • Как выбрать правильный путь в PHP(Python) фреймоврке/CMS, чтобы не закопаться?

    @SharuPoNemnogu
    не язык плохой, программисты такие...
    Если хочешь в разрабы, да в хорошую контору, то учи Symfony. На вакансиях уровня сеньора я других фреймворков не встречал. Да и освоив один фреймворк, другие освоишь без особого напряга.

    Что касается cms, если хочешь работать в какой нибудь студии, на конвейере сайтиков близнецов, то вордпресс, а лучше битрикс, то еще Г, но расплодилось, а спецов мало, т.к. мало кто хочет с ним работать. Без куска хлеба точно не останешься.
    Ответ написан
    Комментировать
  • Действительно ли новая asp.net core 1.0 быстрее в 8 раз Node.js?

    bingo347
    @bingo347 Куратор тега Node.js
    Crazy on performance...
    Во-первых, такие заявления как правило делаются для пиара, а в качестве доказательств предлагаются синтетические тесты, далекие от реальных приложений.
    Во-вторых, разные компиляторы конечно могут по разному оптимизировать Ваш код, кто-то это делает лучше, кто-то хуже, но все же в большей степени производительность зависит непосредственно от кода, одну и ту же задачу можно решить на одном и том же языке и версии компилятора, но разными способами и получить разницу в производительности в несколько раз (лично мне доводилось ускорять серверную часть socket.io в 6-8 раз, без потери функциональности).
    И наконец в-третьих, не ищите серебряную пулю, пишите на том, что лучше знаете
    Ответ написан
    4 комментария
  • ASP.NET MVC, лучшие практики?

    @dmitryKovalskiy
    программист средней руки
    Я конечно не гуру, но попробую озвучить свое мнение.
    1)В общем и целом - да. Но что по вашему - короткий маршрут? короткие слова или малое число слешей? Тут все же качели читабельности неподалеку.
    2)Я считаю да и причина довольно банальна - я не хочу лазить по всему проекту чтобы выяснить почему данный роут свалился в данный контроллер. Но есть исключение - регионы(Areas). У них свой RouteConfig и не исключено что он будет работать отлично от дефолтного.
    3)Это вообще не проблема. Вам никто не запретит писать Javascript-логику, которая потом по ходу дела возьмет еще данных через API и сама нарисует view. Делайте как хотите, но это должно быть читабельно, поддерживаемо и хоть немного соответствовать поставленной задаче( не надо пользовать Angular только чтобы попользовать Angular)
    4) Тут вы все в одну кучу смешали. Максимально короткими? В принципе да, но я хотел бы прочитав название точно угадать что он делает, а не узреть сюрприз в последствии. В остальном тоже соглашусь.
    5) Предположим она нужна. Во первых уберите слово JQuery - сия библиотека к валидации имеет мало отношения. Во вторых на сервере как правило хватает проверок свойств ModelState.isValid и Model.isValid. Разумеется если ваша модель помечена всеми атрибутами, ограничивающими корректные значения. Тут правда есть одна заковыка - предположим у вас меняется логика валидации(поля обновились или еще какие-то телодвижения совершены). На практике вам нужно в двух местах обновлять одну и ту же логику, что не очень правильно(потенциальное дублирование кода, потенциальные ошибки забывчивости).
    6)Может да, а может и нет. Повторюсь - клиентскую сторону можно лепить разными методами. Можно и Javascript-ом. В ASP.NET это не возбраняется. Это вообще нигде не возбраняется.
    UPD:Программировать на C# внутри View не стоит. Тащить доп.данные тоже, хотя изредка такая необходимость возникает(словарь какой-нибудь подтащить). В основном код должен содержать вспомогательные функции- например сформировать какую-нибудь фразочку или проверить состояние объекта по нескольким полям вместо того чтобы писать кучу if в разметке.
    END UPD.
    7)Если честно не понял о чем вы.
    8)Это не костыль, это транспортная система для коротких сообщений и простых типов. Использовать в качестве транспорта для модели тоже можно, но не безопасно с точки зрения приведения типов.
    9) А что вы понимаете под "голый Ajax"? XmlHttpRequest? Да, на мой взгляд лучше его не использовать. Вторую часть вопроса не смогу комментировать без ответа на первую. Вьюшки бывают разные, некоторые подтягивают дополнительные данные по ходу дела. Тут нужно немного конкретики.
    10) Не согласен и уже озвучивал ранее. Razor один из доступных инструментов. Можете использовать его - он хороший, а можете не использовать.
    Ответ написан
    4 комментария
  • Как запретить пользователю добавлять в фоловери более одного раза?

    winordie
    @winordie
    Лучшая документация -- исходники
    templatetags/follow_tags.py
    @register.simple_tag
    def in_follow(user, follower):
        return user.who_follows.filter(follower=follower).exists()

    urls.py
    url(r'^to_follow/(?P<user_id>\d+)/$', follow, name='add_to_follow'),

    template/user_page_blablabla.html
    {% load follow_tags %}
    ...
    {% if messages %}
        <ul class="messages">
            {% for message in messages %}
                <li{% if message.tags %} class="{{ message.tags }}"{% endif %}>{{ message }}</li>
            {% endfor %}
        </ul>
    {% endif %}
    ...
    {% in_follow user current_user as user_in_follow %}
    {% if user_in_follow %}
      <span>{% trans "In follow" %}</span>
    {% else %}
      <a href="{% url "add_to_follow" user_id=current_user.id %}">Add to follow</a>
    {% endif %}

    views.py
    @login_required
    def follow(request,user_id):
        selected_user = User.objects.get(id=user_id)
        _, created = Followship.objects.get_or_create(following=request.user,
                                             follower=selected_user)
        if created:
            messages.success(request, 'ok')
        else:
            messages.error(request, 'User already following')
        return reverse('user_page_blablabla')

    models.py
    class Followship(models.Model):
        following = models.ForeignKey(User, related_name="who_follows")
        follower = models.ForeignKey(User, related_name="who_is_followed")
        class Meta:
            unique_together = ('following', 'follower')
    Ответ написан
    2 комментария
  • На каких IT-специалистов выше спрос за рубежом?

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

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

    dmitriylanets
    @dmitriylanets
    веб-разработчик
    3 мало чем отличается от 2 версии
    Ответ написан
    Комментировать
  • Стоит ли учить flask для back-end разработки?

    @deliro
    Изучал фласку первые пару недель. Она простая, "некомбайн". Разобраться что да как работает - пойдёт (потому что вьюхи и шаблоны у них с джангой похожи).

    Дальше лучше переезжать на джангу. Фласк лучше джанги примерно в 1% всех случаев - это те, когда тебя джанга не устраивает целиком и полностью: ORM не хватает или не подходит, стоковые сессии и юзеры тебя раздражают, контекстные процессоры и мидлвари тратят слишком много ЦП, что лучше бы их на Си переписать. Короче, тогда, когда своё написать быстрее и проще, чем строить костыли поверх джанговских компонентов с сильной связью.

    Плюсом идёт просто огромная куча модулей для джанги (по сравнению с флаской) и бОльший спрос на джангу на рынке труда.
    Ответ написан
    Комментировать
  • На чём лучше вести локальную разработку?

    boramod
    @boramod
    Упрощенно.

    Вагрант — система управлением конфигурацией конкретной машины.
    Докер — запуск изолированных процессов на машине.

    Докер.
    Это не виртуальная машина, а запуск изолированных процессов. Т.е., запущенный процесс думает, что он один единственный, и ничего вокруг нет. Это работает на уровне ядра Linux. Без использования виртуальных машин.

    В терминологии Докера есть Images и Containers.
    Image — образ, шаблон, на основе которого запускается Container.
    Image строится на основе какого-либо базового образа ОС.

    Container — сервис, запущенный и построенный на базе Image.

    Таким образом, вы можете построить несколько образов, например, образ для Nginx, образ для PHP, образ для MySQL. Вдобавок, вы можете построить несколько образо, для каждой желаемой версии PHP, MySQL и т.п.

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

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

    Оба инструмента хороши. Но у каждого свое назначение.

    Vagrant — великолепный инструмент для конфигурации удаленных машин с нуля, VDS/VPS и т.п.
    Docker — великолепный инструмент для быстрого развертывания/переконфигурации рабочего окружения, практически без изменения системы, на которую он устанавливается.
    Ответ написан
    6 комментариев
  • CMS на базе Yii2?

    webinar
    @webinar Куратор тега Yii
    Учим yii: https://youtu.be/-WRMlGHLgRg
    1. Перебрал все магазины на yii2 - все ужасно. Либо крайне не универсально, либо крайне медленно работает.
    2. Не стоит искать cms на yii, надо писать cms на yii
    3. Если нужен хороший магазин на базе framework - есть shop-script, на базе их же framework webasyst. Как cms - намного лучше всего написанyого на yii (имею в виду opensource cms магазинов), как framework - барахло полное. Если надо именно на yii, см. пункт2
    4. Если нужна модульная структура, то не надо искать cms, надо искать набор готовых модулей, совместив которые, получите cms. Модульная структура удобна, и в этом кроется ответ на вопрос "почему нет готовых CMS для магазинов на yii". Они есть, но в виде модулей. Отдельно RBAC, отдельно авторизация, отдельно nestedsets для категорий, отдельно яндекс касса и т.д. Просто совместите их, натяните одинаковый дизайн и все.

    PS: не буду говорить от Вашего имени, но когда я задавался этим вопросом ситуация была в том, что я знал азы yii, но не мог написать магазин. Тогда я задумался, а может взять готовый и моих азов хватит его дорабатывать и видоизменять? Путь в деградацию и гавнокод. Лечится чтением документации и глубоким разбором кода framework, а так же практикой. Теперь я смотрю на проекты типа eximuscommerce и понимаю, что быстрее напишу сам, чем заставлю правильно работать это.
    Ответ написан
    8 комментариев