Задать вопрос
  • Как урезать свой перфекционизм?

    isqua
    @isqua
    Научу HTML, CSS, JS, BEM и Git
    Чтобы перестать делать лучше то, что ещё не сделано до конца, нужно понять одну простую истину: Запущенный проект лучше, чем не запущенный.

    Давайте потренируемся:
    • Что лучше: запущенный проект с несжатыми стилями или незапущенный со сжатыми?
    • Что лучше: не запущенный проект с десятью страницами или запущенный с тремя?
    • Что лучше: запущенный проект c jQuery или не запущенный без jQuery?


    Надеюсь, вы смогли выбрать! Как узнать, что пора запустить проект? (Под запуском я имею в виду «показать людям». Например, если вы решили написать библиотеку, давайте считать «проект запущенным», если вы выложили её на гитхаб) Нужно прикинуть, сколько времени вам надо на разработку и умножить на два. Если получилось больше двух недель, то стоит разбить проект на части и прикинуть так про каждую часть. Соответственно, ставите дедлайны.

    Промежуточные дедлайны помогают успеть к последнему. Старайтесь сначала реализовать основную функциональность, а потом дополнительную. Если не успеете к дедлайну доделать дополнительное — сначала запустите основное, а потом видно будет, надо ли вообще доделывать дополнительное.

    Ну и не беритесь за каждую идею, а выбирайте самые инетересные. Если вы будете делать пять проектов одновременно, скорее всего ни один не доделаете.

    Удачи!
    Ответ написан
    4 комментария
  • Как контролировать работу удаленного программиста?

    MpaK999
    @MpaK999
    Буду!
    Возьмите стороннего разработчика уровнем выше, на почасовку, чтобы он просто раз в день-два на час-полтора делал код ревью. Думаю через неделю вердикт у вас будет.
    Ответ написан
    Комментировать
  • Как правильней сделать быстрое выкатывание в продакшн?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    конфликты мерджей очень сильно тормозят

    1) Дробите задачи, делайте ветки короткоживущими
    2) Хорошая идея делать ребейз принятых веток
    3) Попробуйте адаптировать под себя git-flow, как альтернатива хорошо себя показывает feature-toggles вместо feature-branches

    Да и бд экспорт/импорт постоянно приходится делать.

    1) Миграции
    2) Старайтесь делать миграции так, что бы они не ломали предыдущие релизы. Ну мол если вам надо добавить колонку, хорошей мыслью будет в первом релизе сделать ее nullable что бы старая версия приложения еще могла работать с новой версией базы, и потом уже следующим релизом добивать этот кусок. Основная идея - желательно что бы две последние версии приложеньки могли работать с последней версией базы данных. Если у вас база нормализована нормально, то проблем с этим быть не должно.

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

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

    При таком сценарии даунтайм будет минимальным.

    вопрос с выкатыванием новых релизов

    Вот вам варианты в порядке сложности и мощности (от простого к сложному).
    - capistrano/capifony
    - ansible/puppet/chief/etc
    - docker + docker-machines + docker-compose

    Ну и да, тесты тесты тесты. Все самое критичное должно быть покрыто хотя бы интеграционными/функциональными тестами. В идеале же вся бизнес логика должна быть покрыта быстрыми юнит тестами и UI/инфраструктура функциональными (читать про пирамиду тестирования).
    Ответ написан
    5 комментариев
  • Есть ли книга (гайд) по введению в разработку 3D игр для бывалых в других сферах программистов?

    Deerenaros
    @Deerenaros
    Программист, математик, задрот и даже чуть инженер
    Товарищ, могу сказать как человек, который чего только не попробовал разрабатывая игру. Началось всё с чистого Си, был и C# (банальная формочка с кучей кнопочек), был и С++ (чистый opengl и box2d для физики), потом XNA - мощный фреймворк для C#, правда умер к сожалению. Был pygame, правда ничего дальше пары хэлоу ворлдов не продвинулось. Вот сейчас ковыряюсь в юнити. Нередко организуюсь с другом на хакатоны - надо заметить, что с каждым разом продвигаемся всё дальше и дальше. Правда каждый раз и начинаем заново.

    В общем, заметил несколько вещей. Во-первых, нужен не программист, а скриптер, по рангу он недалеко ушёл от кодера. То есть он и есть кодер, с тем лишь отличием, что скриптует сцены. Ну и да, было бы не плохо обзавестись другим скриптером, который напишет текст. Сегодня, для разработки игр программисты нужны лишь для ААА-проектов, когда требуется сварганить целый фреймворк и почти с нуля сотворить движок, ну или адаптировать старый к новому железу, что по сути одно и то же. Во-вторых, надо вообще много всякой шпаны - художники, дизайнеры, тестеры, звуковики. В общем, полный набор требуется. Конечно, можно совмещать все должности в одной, но это обычно плохо кончается.
    Алсо, выбрав путь не стоит с него сворачивать. Это я говорю как опытный сворачиватель с путей - код переписывать не стоит, иначе как только он более менее разрастётся только и будете, что переписывать. Рефакторинг тоже делать надо очень осторожно. Чем модульнее тем лучше. И так далее.

    По поводу манов - их дофига. Разной степени упоротости. Например, есть такой неплохой движок, как OGRE, у него на странице куча ссылок на демки, вики, книги, доки. Но это скорее для любителей хардкора. Для любителей велосипедов есть openal + opengl, ну или sdl + opengl. По opengl тоже много литературы, очень много. К тому же есть Unity3D, но программистам с ним, имхо, делать особо нечего - лишь ограничивает, да и по удобству он далеко не самый лучший, а производительность - ужс какой-то, хотя в большинстве задач хватает с головой.

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

    В любом случае, удачи в начинаниях!
    Ответ написан
    4 комментария
  • Доступ к cookies между поддоменами?

    @Power
    Если это сделано кросс-доменно и через XHR (а не JSONP, к примеру), то читайте про CORS. Конкретно, см. заголовок Access-Control-Allow-Credentials.
    Ответ написан
    1 комментарий
  • Чем проверить nginx под нагрузкой?

    alekciy
    @alekciy
    Вёбных дел мастер
    Поддерживаю идею с яндекс танком.
    Сам же использую httperf. У него генерация параллельных коннектов "честнее" (чем в ab). Пример такого тестирования тут: alekciy.livejournal.com/10471.html ("Методика тестирования").
    Ответ написан
    Комментировать
  • Чем проверить nginx под нагрузкой?

    @inkvizitor68sl
    Linux-сисадмин с 8 летним стажем.
    yandex-tank'ом.
    Ответ написан
    Комментировать
  • Создать алгоритм заполнения игрового поля?

    Muff
    @Muff
    Похоже на задачу трассировки печатных плат.
    Ответ написан
    Комментировать
  • Технологию для разработки приложения?

    Тут надо отталкиваться от того, что понимается под «навороченной анимацией».
    Как бы не расхваливали HTML5, Canvas и JS-фреймворки, для них существуют «ограничения» в использовании анимации. Т.е. существуют некоторые виды анимации, которые могут подвесить любой браузер и их практическое использование невозможно.
    Ответ написан
    Комментировать
  • Технологию для разработки приложения?

    alternativshik
    @alternativshik
    Посмотрите в сторону phonegap. Поддержка всех современных платформ + в основе html5, комьюнити достаточно хорошее + есть доки и примеры.
    Ответ написан
    Комментировать
  • Технологию для разработки приложения?

    MastaEx
    @MastaEx
    Flash не поддерживается в iOS, с переносом будут трудности.
    HTML5, canvas, SVG и WebGL, имхо, это будущее. Посмотрите js библиотечки Raphaël и three.js. Примеры three.js помогут вам оценить возможности платформы в целом.
    Лично я не разрабатывал ничего подобного под мобильные платформы, но, мне кажется, с javascript там особых проблем нет.
    Ответ написан
    1 комментарий