Keep your projects tight

How to manage work with large distributed team regarding code consistency, build process and automation

Transcript

1. Keep your
   projects tight
   @kamilogorek
   

   View Slide

2. ?
   Why bother?
   

   View Slide

3. Your whole project should
   look like it was written
   by a single person
   

   View Slide

4. Keeping your project tight
   IS HARD
   

   View Slide

5. Working with distributed team
   IS HARD
   

   View Slide

6. Switching between projects
   IS HARD
   

   View Slide

7. Back-end developers
   world from my perspective
   

   View Slide

8. Dedicated teams
   

   View Slide

9. Dedicated teams
   Project specific code conventions
   

   View Slide

10. Dedicated teams
    Project specific code conventions
    Detailed code review
    

    View Slide

11. Dedicated teams
    Project specific code conventions
    Detailed code review
    Dedicated teams
    

    View Slide

12. Dedicated teams
    Project specific code conventions
    Detailed code review
    Dedicated teams
    Build and deployment process
    

    View Slide

13. Dedicated teams
    Project specific code conventions
    Detailed code review
    Dedicated teams
    Build and deployment process
    Reliable development stack
    

    View Slide

14. Meanwhile in a front-end
    developers world…
    

    View Slide

15. Style guides?
    

    View Slide

16. Mixed tabs and spaces?
    Missing semi-colon?
    

    View Slide

17. Code review?
    

    View Slide

18. Hey guys! There’s this new,
    cutting-edge thing.
    Let’s use it, even though
    none of us know
    anything about it.
    

    View Slide

19. Development automation?
    No! I’m *front-end developer* and
    i can do this myself!
    

    View Slide

20. It doesn’t have to be that way
    !
    We already have tools that can save
    us a lot of precious time
    and highly speed-up our
    development process
    

    View Slide

21. View Slide

22. Spend some time and think
    twice about your architecture
    and development process
    !
    It’ll help you in a long run
    

    View Slide

23. Style guides
    and coding conventions
    

    View Slide

24. CSS Style guides
    GitHub: https://github.com/styleguide/css
    Idiomatic.css: https://github.com/necolas/idiomatic-css
    Google: http://google-styleguide.googlecode.com/svn/trunk/htmlcssguide.xml
    

    View Slide

25. JS Style guides
    GitHub: https://github.com/styleguide/javascript
    Idiomatic.js: https://github.com/rwaldron/idiomatic.js/
    Google: http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml
    AirBnB: https://github.com/airbnb/javascript/
    

    View Slide

26. JS Coding Conventions
    http://sideeffect.kr/popularconvention/#javascript
    

    View Slide

27. Editor-config
    http://editorconfig.org/
    

    View Slide

28. Code linting
    

    View Slide

29. “modern lint checkers are often used
    to find code that doesn't correspond
    to certain style guidelines.”
    http://en.wikipedia.org/wiki/Lint_(software)
    JSLint: http://www.jslint.com/
    ESLint: https://github.com/nzakas/eslint
    JSHint: http://www.jshint.com/
    

    View Slide

30. If there’s a reason to break those
    rules, do it. But always explain why
    Tip: JS linters respect scope within which you set local changes
    

    View Slide

31. Do we really have to do all
    those things by ourselves?
    

    View Slide

32. Automation
    

    View Slide

33. But wait. Isn’t automation hard?
    ANT? XML? RAKE? anyone?
    

    View Slide

34. GRUNT TO THE RESCUE
    

    View Slide

35. GRUNT TO THE RESCUE
    Easy to configure
    

    View Slide

36. GRUNT TO THE RESCUE
    Easy to configure
    Plenty of plugins
    

    View Slide

37. GRUNT TO THE RESCUE
    Easy to configure
    Plenty of plugins
    Writing your own task with no hassle
    

    View Slide

38. GRUNT TO THE RESCUE
    Easy to configure
    Plenty of plugins
    Writing your own task with no hassle
    It’s still just JavaScript and Node
    

    View Slide

39. Why should i use it?
    

    View Slide

40. Why should i use it?
    Real-time feedback
    

    View Slide

41. Why should i use it?
    Real-time feedback
    Build process
    

    View Slide

42. Why should i use it?
    Real-time feedback
    Build process
    Easy deployment
    

    View Slide

43. Why should i use it?
    Real-time feedback
    Build process
    Easy deployment
    Saves you time
    

    View Slide

44. Real-time feedback
    

    View Slide

45. Real-time feedback
    

    View Slide

46. Build process/Deployment
    

    View Slide

47. how to?
    http://www.integralist.co.uk/posts/grunt-boilerplate/
    https://speakerdeck.com/shaundunne/
    grunt-your-way-to-glory-sideview-2013
    http://merrickchristensen.com/articles/gruntjs-workflow.html
    http://gruntjs.com/getting-started
    

    View Slide

48. Think about your build process before
    starting a project and verify it before
    merging anything to repository
    

    View Slide

49. pre-commit
    !
    pre-push
    !
    post-update
    GitHooks
    

    View Slide

50. `your-repo/.git/hooks/hook-type`
    HOW TO?
    Keep in mind to set executable permissions for hook files:
    `$ chmod +x your-repo/.git/hooks/hook-type`
    

    View Slide

51. Ah, and never tell your
    friends that there’s
    --no-verify flag!
    

    View Slide

52. If you decide to use pre-push hook
    only, learn how to clean up
    after your work
    

    View Slide

53. git commit --amend
    git rebase --interactive
    git cherry-pick
    ARE YOUR FRIENDS
    

    View Slide

54. ▼
    

    View Slide

55. Ok, but what if one of developers
    didn’t set hooks?
    !
    Ask Travis for help
    

    View Slide

56. Travis CI
    Lets you monitor status of your repository
    and run specific tasks for every commit
    !
    It’s fully integrated with GitHub Status API
    

    View Slide

57. Setting up
    Enable travis service hook on GitHub repository:
    https://github.com/your-user/your-repo/settings/hooks
    Create `.travis.yml`
    in project root
    And just add test script
    to package.json
    

    View Slide

58. Yup, that’s it
    3 steps
    

    View Slide

59. And now everyone can see
    instant feedback
    

    View Slide

60. As well as verify whole pull-request
    

    View Slide

61. Keep in mind that still, no matter what,
    people will be still making mistakes
    !
    Minimise the risk by allowing machine
    to do the hard work
    

    View Slide

62. Those are only tools
    They suppose to help you do your
    work, not make it more difficult
    

    View Slide

63. Once written stack can be
    a great codebase for all future
    projects within your company
    if everyone will respect
    settled rules
    

    View Slide

64. Get a plan
    and
    stick to it
    

    View Slide

65. Thank you
    

    View Slide

66. @kamilogorek meet.js
    

    View Slide