The frontend code is often treated like a step child and after a while things get messy and complicated. In 2014 there is a lot of things and toys a developer can do and use to avoid dying in 'brownfield hell'. I'd like to share some of my insights
young call girls in Rajiv Chowk🔝 9953056974 🔝 Delhi escort Service
Surviving your frontend (WIP - Sneak Peak)
1. WHAT A MILLIONS LOC OF HTML, JS AND PHP TAUGHT ME
SURVIVING YOUR
FRONT-END
2. WHOIS SEBASTIAN SCHÜRMANN
• Coder for about 15 years
• All things agile since 2004
• Agile Coaching, some consulting and freelance
development
• http://dissident-trainings.de
7. „You don't have to be a genius or a visionary or
even a college graduate to be successful. You just
need a framework and a dream.“
–MICHAEL DELL
8. REALITY IS LIKE …
VENN DIAGRAM OF MY WORK WEEK
http://cssquirrel.com/
9.
10.
11.
12.
13.
14.
15. • Specifications are very roughly prepared for front-ends
• The crafty side of development, modularization and
testing is neglected
• Standards are not set and/or followed
• The fact that a javascript front-end is the client to a
server application is often overlooked
• Front-end code is often thought as throw away.
17. ABRAHAM KAPLAN
TOOLS
„GIVE A SMALL BOY A HAMMER, AND
HE WILL FIND THAT EVERYTHING H E
ENCOUNTERS NEEDS POUNDING. “
18. A INCOMPLETE …..
HISTORY OF JS FRAMEWORKS
jQuery
baconJS
XUL prototype
AngularJS
2002 2014
mootools rxJS
backbone.js
19. I WAS ONCE TOLD JQUERY WAS THE
THING ….. IN 2006
20. BUILD IT
• Repeating tasks by hand is
prone to errors
• Build, test and release is
complex in 2014
• You want to see the „final“
result
• Fast feedback!
• Make the build FAST!
21. TEST IT
• Always be testing
• Using tests is faster than
developing in the browser
• Setup is often a pain
• How many browsers do
you support?
22. MODULARIZE
I T !
• Single responsibility
• Different job, different
behavior
• Build and test for this
component
• CI/CD for this component
• Assets -> Component
23. SCAFFOLD IT!
• You will be creating a lot of
modules/components
• They should follow a
consistent structure
• Creating this by hand is
error prone and waste of
time
24. RECREAT E I T
• A front needs a back(-end)
• I am not a expert in
backends per se
• Especially not in your
backend
• But I needz it for
validation!
25. MEASURE IT
• Analytics is key
• Not only (rendering) speed
• Know your KPI’s
• Is it still working?
• Track errors!
• Can you prove it?
26. CONCLUSION TOOLS
• Hipster frameworks? Cargo cult?
• Learn and use the tools for automation. Create a
„monkey task list“ and automate one task a day
• It’s 2014, you will be testing, get over it!
27. RICHARD SENNETT, THE CRAFTSMAN
CRAFT
“CRAFTSMANSHIP NAMES AN ENDURING,
BASIC HUMAN IMPULSE, THE DESIRE TO
DO A JOB WELL FOR ITS OWN SAKE.”
28. COMPLETENESS
THE STORY OF THE
LOADING INDICATOR!
JIRA #1235
THE LOADING INDICATOR IN THE FRIEND
SEARCH IS NOT GOING AWAY
30. THE FALLACIES OF DISTRIBUTED
COMPUTING
• The network is reliable.
• Latency is zero.
• Bandwidth is infinite.
• The network is secure.
• Topology doesn't change.
• There is one administrator.
• Transport cost is zero.
• The network is homogeneous.
31. THE FALLACIES OF DISTRIBUTED
COMPUTING
• The network is reliable.
• Latency is zero.
• Bandwidth is infinite.
• The network is secure.
• Topology doesn't change.
• There is one administrator.
• Transport cost is zero.
• The network is homogeneous.
1994
32. COMPLETENESS
$.AJAX AND THE FALLACIES OF
DISTRIBUTED COMPUTING
ERROR? WHICH ERROR
TIMEOUT?
EXACTLY?
500 404
34. JIRA #1235
SOLUTION: ON ERRORCODE 500 GO TO
USER HOME (SESSION IS RESTARTED
THERE)
35. NIH - NOT INVENTED HERE
THE STORY OF THE
FORM VALIDATOR
JIRA #1236
IMPLEMENT A VALIDATION IN
REGISTRATION FORM SO THAT USERS
GET FASTER FEEDBACK IF HOME
ADDRESS IS OK
36. Not invented here (NIH) is the philosophy of
social, corporate, or institutional cultures that avoid
using or buying already existing products,
research, standards, or knowledge because of their
external origins and costs. The reasons for not
wanting to use the work of others are varied, but
can include fear through lack of understanding, an
unwillingness to value the work of others, or
forming part of a wider "turf war"
–WIKIPEDIA VIA
HTTP://WWW.WIKIWAND.COM/EN/
NOT_INVENTED_HERE
37. JIRA #1236
IMPLEMENT A VALIDATION IN
REGISTRATION FORM SO THAT USERS
GET FASTER FEEDBACK IF HOME
ADDRESS IS OK
JIRA #1236 COMMENT
IMPLEMENT OWN SOLUTION BASED ON
REGEX TO VALIDATE FORM
38. DEVELOPMENT TAKES 2
WEEKS
ADDING ANOTHE R S T R E E T A/ 1
LIB FOR REGEXP
1 STREET
STREET
X-BROWSER
NO STREET AT ALL
I PAD Y U NO BLUR?
41. A REWRITTEN
MODULE
• Passes all the same unit
tests and then some.
• Is a demonstrably better
solution to the problem
addressed by the original
• Makes the developer of the
original module go "Ooooo,
why didn't I think of that?“
• Has fewer lines.
A REINVENTED
MODULE
• Has different (but maybe
fewer) bugs.
• Behaves differently (but NOT
more correctly) with
boundary cases.
• Had code that does things
differently for stylistic reasons
rather than function.
• May support some lame
excuse to have more lines.
42. QUALITY
THE STORY OF THE
REWRITE
JIRA EPIC #5
REWRITE ADMIN SITE AND APP FOR
SHOP OWNERS
45. WHY?
• Technology changes
• We make mistakes
• We get better & new ideas
• New features (added fast)
• Code rot
• Hurry?
• Wrong specs?
• Saving on QA anyone?
47. BIG BALL OF MUD
THE STORY O F T H E 1 2 0
MEGABYTE CHECKOUT
DAY 1 AT A CUSTOMER PROJECT
48. „Big ball of mud" systems have usually been
developed over a long period of time, with
different individuals working on various pieces
and parts. Systems developed by people with no
formal architecture or programming training often
fall into this pattern“
–CITATION NEEDED
49. „Another reason leading to produce this kind of
system is when managers put pressure on
developers and come with incremental micro
requirements instead of providing a clear
description of the problem to be solved“
–CITATION NEEDED
50. „Foote and Yoder do not universally condemn
"big ball of mud" programming, pointing out that
this pattern is most prevalent because it works —
at least at the moment it is developed.
However, programs of this pattern become
maintenance nightmares“
–CITATION NEEDED
51. „Programmers in control of a big ball of mud
project are strongly encouraged to study it and to
understand what it accomplishes, and to use this
as a loose basis for a formal set of requirements
for a well-designed system that could replace it.
Technology shifts – such as client-server to web-based
or file-based to database-based – may
provide good reasons to start over from
scratch“
–CITATION NEEDED
53. • Javascript / Coffeescript with
close to 0 comments
• JS == no namespaces
(header.js vs. header.js)
• 194 Tests
• > 5K Coding style validations
• lcov only for js
• Setup took a day (from 16
billed)
• Fixing „npm test“ another one
• JS Tests not in CI
• NPM install failed at first
54. DIRTY TRICKS
• Use small components that do
one job
• Decouple the front-end from
backend for development
• keep the integration/master
building
• adhere to your fucking
standards (or you have none at
all)
• Integration and deployment is
part of development
• Let the dev change the build
chain as well
VS
55. RICHARD SENNETT, THE CRAFTSMAN
„… THERE IS TROUBLE CAUSED
BY CONFLICTING MEASURES OF
QUALITY, ONE BASED ON
CORRECTNESS, THE OTHER ON
PRACTICAL EXPERIENCE”
PRACTICES
57. • On every machine
• For every dev
• Build and re-build on CI
• Invest in CI and CD
• Adopt the culture
• This is why a Ops person
IN a team is so important
• checkout, build, code, test,
commit, deploy, validate
(fast)
ONE BUTTON TEST
ONE BUTTON BUILD
ONE BUTTON DEPLOY
60. WHY IS BUG FIXING SO
EXPENSIVE?
• Bugs costs it self
• Other work has to be
delayed
• Many departments in loop
100
75
50
25
• Risk of new bugs 0
Design Implementation Testing Bugfixing
61. THE CHEAPEST
QA TOOLS
• Flipchart / Whiteboard
• Stories / Specs
• Specifications derived
from examples
• QA is part of the whole
development process
62. WHERE IS YOUR BLIND
SPOT?
Testing quadrant - stolen from @lisacrispin
64. FROM DESIGN TO DEPLOYMENT
RESPONSIBILITY FOR
THE WHOLE PROCESS
65. (A EXTREME) DEFINITION OF DONE
• When tests pass
• When integrated
• When deployable build
• When deployed
• When measurably delivering value
http://www.xpdays.de/2014/downloads/002-extreme-continuous-delivery-at-unruly/cd_javaone.pdf
66. FAI L
TDD DEPLOYMENT
FEEDBACK
DE P LOY PAS S R E FACTOR PAS S
http://www.xpdays.de/2014/downloads/002-extreme-continuous-delivery-at-unruly/cd_javaone.pdf