This document provides advice and recommendations from an expert on various topics related to web development and Drupal. Some of the key points covered include: - Testing, especially automated testing, is very important for quality assurance and maintaining reliability. Simplicity is also important for reliability. - Small teams and clients are preferable to large ones, as they have less bureaucracy, noise and agendas interfering with objectives. - Planning is essential, especially software architecture planning, but plans will change over time as the project evolves. - Tools like Ansible, PHPQA tools, Robo, and JetBrains PHPStorm can help with tasks like provisioning, testing, deployment and development. Drupal tools like Drush

1. Big guns for the small guys
(reloaded)
Jorge Lopez-Lago
6 March 2016
Annotated!

2. http://www.wallpaperup.com/150483/transport_military_cargo_A400M_f.html
Engineer
The last airplane I was part of.
Testing the engines!

3. https://www.amazeelabs.com/en/blog/fun-potatoes-other-wallpapers
Drupaleer Not endorsed.
I just like the table :)

4. My company!

5. AT-AT
http://starwars.wikia.com/wiki/All_Terrain_Armored_Transport
Advice and tools.
Repeat.

6. Disclaimer
(*) There is always a disclaimer.
(*)

7. I do not endorse any of the products or
brands mentioned in this talk.
I have used them, I am using them or I am
looking into using them in the near future.

8. This is an opinionated talk.
Some swearing may be featured in it.
***!

9. What have I
learnt?
95% of what we learn happen before the
age of 7 (I heard somewhere).

10. Humans build stuff as badly as possible,
but not worse.
Me Some call it “optimization”.
It is an strategy that works pretty well… until it doesn’t.
When it doesn’t it is usually because we crossed the crap line.
An expert is someone that has failed many times. That helps to
estimate the crap line in projects.

11. Advice
Based on my experience
and preferences. You may
disagree violently...

12. http://nutritiouslife.com/edible-sunscreen-you-need-to-know-about/
Sunscreen
https://en.wikipedia.org/wiki/Wear_Sunscreen
At least you will have a piece of
solid, backed by science, good advice.

13. We are in the business of selling.
There is no other business.
The sooner you get it the better.

14. Do not sell your time!
Sell the product of your work,
not your time.
FYI: this is bad stuff.
Bodyshopping is a form of
modern slavery based on
“employment” ideas of the
18th Century.

15. Small is good.
It is the right thing to do.
Less people = less bullshit, less noise, more clarity.
Cut down the middleman between you and the final client.
Small clients are good for this strategy.
Everyone has his personal agenda, with personal objectives.
Personal agendas interfere with project objectives. Do the math..

16. Luke: Is the dark side stronger?
Yoda: No, no, no. Quicker, easier, more
seductive.
AKA: big corporation teams.

17. Broken telephone effect:
CEO > Marketing > Designer > B. Analyst >
Designer > P. Owner > T. Lead > Developer
Littered with middle
managers as well.

18. Fear is the path to the dark side...
fear leads to anger…
anger leads to hate…
hate leads to suffering.
Yoda
Fear of losing their jobs.
Large companies policies make people to
worry about their jobs, not their work.

19. This industry is cheap.
Code is cheap.
And this is one of the main problems with it. Everyone thinks
that we can keep making changes to code indefinitely because it
has a perceived cost of almost nothing; after all it is
“digital/virtual” and we can rewrite it at no cost…

20. Agile?
Whatever works for you!
For me it is a combination of frozen specifications, architecture
planned in advance (you need overall vision of the project),
prototyping, many checklists and agile Ganttified sprints.
But never “agile planning”, whatever that means.

21. Never start everything at the same time!
Big teams go large here.
I have seen things… whole development teams coding frantically,
directed by the PM, before the architect joins the project.
Someone hired them early and they must work (write code!) as
they are being paid to warm up their chairs.
The train can not stop: timber!

22. First, solve the problem.
Then, write the code.
John Johnson
Practical tip: print this slide and
paste it to your computer screen.

23. But we cost more and take longer than
building a house!
The average time to build a family house is 6 months.
The perception of cheapnes is the origin of our trouble as it provokes multiple
cycles of changes (together with developers reinventing the wheel in each
project). We do not have the restrictions of the physical world: when something
is done it cannot be changed. That helps the house builders.

24. Plain bad planning
It is really difficult to manage and plan projects.
Sometimes I have the impression that…
Those who can, code. Those who can’t, manage.
And that is not a good strategy for success.
A good PM is priceless.
And very rare.

25. Plans are of little importance,
but planning is essential.
Winston Churchill
Do not mistake software planning with project delivery planning.
The first one must be done in advance while the former may be
done in an agile way as the project progresses. I am afraid all
planning is treated in the same fashion by the agile crowds.
Mainly software planning

26. No battle plan survives
contact with the enemy.
Helmuth von Moltke the Elder
Always have a plan B.

27. Use checklists.
For absolutely everything.
The whole aerospace industry is based
around checklists. I am sure we can do
very well with them in our industry...

28. Use Gantt charts.
To control the work allocated to tasks and
the dependencies between them.
I am open for suggestions. And not, I do not trust
developers, or other people for the matter.

29. Development, design and content creation
work planned for one sprint. You only need
colourful post its and a large enough window.

30. The science
behind it
Says who?

31. Parkinson’s bicycle shed effect
Everyone knows better… the simple stuff. And our industry is
perceived as simple (we have been promoting it like that for over
a decade). The larger the team or group of people involved the
more difficult to control. And subordinates will not question their
masters… we are doomed!

32. https://en.wikipedia.org/wiki/Law_of_triviality

33. Pareto principle (80-20)
80% of effects come from 20% of the causes
20% of code has 80% of errors
20% of features provide 80% of functionality
...
20% of staff create 80% of problems
For many events
approximately...

34. https://en.wikipedia.org/wiki/Pareto_principle

35. Metcalfe's law
The cost of interrelated or connected operations increases
exponentially with the number of connections:
- Testing becomes more expensive as the software grows and
relations increase between components.
- Team management gets more complicated fast with the number
of members (meetings, communications between parties, etc).

36. https://en.wikipedia.org/wiki/Metcalfe's_law

37. Parkinson’s law
Work expands so as to fill the time available for its completion.
So if a developer “thinks” that he has a sprint worth of time it will
take him one sprint to deliver. But if he thinks he has three days…
You need a Gantt chart to figure this out.

38. https://en.wikipedia.org/wiki/Parkinson%27s_law

39. What do I
need?And what I do not need

40. You need testing.
Automated testing.
Choose your flavour and tool and master them (TDD, BDD, PHPUnit,
SimpleTests, Selenium, etc). Get used to coding tests as you code
features (or before, up to you). Tests are your QA metric, your
benchmark for improvements, your professional standard seal. And,
for God's sake, test patches and bug fixes. Identify your smoke
tests and keep them updated.

41. The only valid QA measurements are
maintainability and reliability.
No one will care about feature x
if the application or site keeps crashing.
And no one will miss feature x
if the application runs smoothly and costs peanuts to maintain.

42. The central enemy of reliability is complexity.
Geer et al.
Get the idea. It is easier to say than to do.

43. Simplicity is prerequisite for reliability.
Edsger W. Dijkstra
Another way to say it.
It is important, so let's repeat it.

44. Bultaco Sherpa. My father’s motorbike.
Simple, robust, reliable, maintainable. Indestructible.
From 1970 to date (46 years in the family!). https://ca.wikipedia.org/wiki/Bultaco_Sherpa_T

45. Always code as if the guy who ends up
maintaining your code will be a violent
psychopath who knows where you live.
Rick Osborne
In case you didn’t get it.

46. Cost of (unit) testing?
Just a practical trick to
estimate the testing routines
required for your code.

47. N-Path complexity.
Number of unique paths in a routine.
Minimum number of tests required to completely
test a routine.
Got it? Me neither.

48. entity_load()
NPath: 2
http://blog.ircmaxell.com/2013/05/development-by-numbers-slides.html
Great talk. View it.
Great!
Just 2 tests required :)
Use PHPMD (Mess detector) to
calculate it.
(see PHPQA slide for tool info).

49. drupal_http_request()
NPath: 25,303,344,960
http://blog.ircmaxell.com/2013/05/development-by-numbers-slides.html
WTF?
If you like this, you will love CRAP!
(Change Risk Analysis Predictions)

50. You do not need CI.
In essence it is a bunch of scripts
executed automatically on code
commits. You can do it manually on
demand and still be cool.

51. You do not need the cloud.
Local is good (if you can share it).
See DrupalVM later.
But backup your stuff!

52. Good and now is better that
perfect and tomorrow.
In code, testing and love.
Tomorrow never comes.

53. Share your work with other professionals.
We can’t do everything under the sun. Outsource work to professionals:
development work or supporting tasks (accountancy, contracts, etc).
Specialization leads to efficiency. Efficiency leads to profits.

54. If you think it's expensive to hire a
professional to do the job, wait until you
hire an amateur.
Red Adair Whatever you outsource will
affect your delivery with
your client. Find good
collaborators and be fair.
No client is worth few
pennies saved.

55. Prototype in Drupal.
Turn web building process around.
Start with Drupal, then Design and finish
with Drupal.
I have been championing
this for over 7 years.
I am not alone. At last!
See following slides

56. https://www.phase2technology.com/blog/static-prototyping-and-keeping-drupal-
simple-kds/

57. http://pronovix.com/blog/prototyping-drupal

58. Understand the basics
Example: do not misunderstand technical debt with writing bad code
knowingly. Code must be always written as best as we can, with the
best understanding of the project at the point. Debt comes from
partial understanding of what you are coding (the project).

59. https://http2.github.io/
How many web devs do you know that do not understand
the HTTP protocol? And how many are stuck in 1.0?

60. https://en.wikipedia.org/wiki/Web_cache Understanding web caching is paramount.

61. https://en.wikipedia.org/wiki/Technical_debt
Everyone misunderstands
this concept big time.

62. Sell!Do as little development as possible and as much selling as bearable.

63. Find your unfair advantage.
WHat do you do well? What is it that you do much much better than
others? Transform it in an advantage. Find a way of using it to
surpass your competitors, to stand out.
The more unfair (for others) the better (for you).
Go and find it!

64. Every client thinks he is an unique unicorn.
And no one is.
No one.
As small guys we are in a great position to manage their delusional dreams. We
are their experts, so behave as such and guide the client through a doable
plan to succeed. We control the product here. Avoid development spirals.
In big projects with big teams there are too many delusional unicorns to tame.
Not even you, I am afraid.
Be pragmatic here.

65. Manage expectations.
Communication is key.
Better to say anything early than late.
Bad news delivered frequently and with plenty of time are much much
better than saved until the very last minute. Most people are quite
reasonable if given time to react and respond. Don’t be afraid of
delivering bad news. Shit happens. The sooner we find out the better
we are positioned to fix it.

66. Time to market beats features hands down
Now and flawed is much better than never and perfect.
Cut down marginal-benefit features ruthlessly. And ship early.
Focus on the 20% that will give you the 80ish%.

67. Build a streamlined product and sell it
again and again. That is the key to profit.
Companies profit on top of imperfect
products.
The whole planet is doing it.
Why don’t we do it in “digital” industries?
Why can’t we?

68. Ditch your marketing department
Marketing is for when the clients find you. It is lazy selling. It
promises everything at the expense of development costs.
What small guys need is a hardcore salesperson to sell your “product”
to as many clients as possible. They need to be convinced rather than
promised any fancy dreams. Think of profitable actions here..

69. Lie about your professional standards.
Do not let the client to dictate them.
This is the only industry where the client decides about the
professional standards of the suppliers.
If the client or manager knows you will spend time testing your code,
he will try to remove it from the project. Testing is part of your
professional standards and responsibility. They can not be removed.
This is insane, madness!

70. http://www.todayonline.com/world/asia/photos-show-felled-building-taiwan-quake-had-tin-can-fillers
February 2016, Taiwan. A new building
collapsed like an accordion during a
moderate earthquake killing 170 people.
It had “tin reinforced” concrete.
No engineer could have ever agreed to
do that due to professional standards.
Draw your conclusions here.

71. Tools

72. Know your tools well.
The tools you use do not matter. What matters is how good you are
with them. So… use the web server that you know well!
Consider the cost of continuously adopting the “latest buzz thing”:
learning curve, slow development, inefficient development, technical debt,
short shelf life of new rapidly changing technologies.

73. The technology you use doesn’t matter as much as what you can do with it.
Stop running after the best new thing.
https://www.digitalocean.com/community/tutorials/apache-vs-nginx-practical-considerations

74. Miscellaneous tools

75. https://github.com/ansible/ansible Provisioning at its best. Can’t live without it.

76. http://phpqatools.org/ Every PHP developer should know these. And use them.

77. http://robo.li/ Deployment, installation, tests running, home baked CI...

78. https://thephpleague.com/ S-W-E-E-T-!

79. https://www.jetbrains.com/phpstorm/ Bye bye Eclipse. Paid for, but so good.

80. https://bitbucket.org/ Free private repositories. Say no more.

81. https://www.dropbox.com The cheapest and easiest local backup.

82. Drupal development tools

83. http://drushcommands.com/ Easy to read. Great source to explore drush doc.

84. http://www.drush.org/en/master/make/ Just build Drupal sites with make. Now!

85. http://www.drupalvm.com/ Your local VM as 1,2,3! Packed with goodies.

86. https://reload.github.io/deployotron/ Very interesting. Seems abandoned?

87. https://www.drupal.org/project/profiler_builder
A helper for your profiles.
For lazy devs or newbies.

88. https://www.drupal.org/project/master Manage config per environment. Yes!

89. https://www.drupal.org/project/paragraphs
Everyone is doing paragraphs.
Beware of its limitations, by design.

90. Debugging tools

91. https://xdebug.org/ This is a must. Run it from your IDE for maximum gain.

92. http://phpdbg.com/ Were you aware of this?

93. https://addons.mozilla.org/en-US/firefox/addon/firephp/
The most effective debugging tool is still careful thought, coupled with judiciously
placed print statements. Brian W. Kernighan (1979)
In case you are
old fashioned.

94. https://blackfire.io/features My next toy.

95. Paperwork tools

96. https://stuffandnonsense.co.uk/projects/contract-killer/ Check it now. Go, do it!

97. Testing tools

98. https://www.drupal.org/project/drulenium
Wraith in Drupal.
Does it get better than this?

99. https://www.phptesting.org/ If you really need CI in house. DIY. PHP, yeah!

100. https://httpd.apache.org/docs/2.4/programs/ab.html The classic benchmarking tool.

101. https://redmine.lighttpd.net/projects/weighttp/wiki Benchmarking.

102. https://github.com/wg/wrk More benchmarking.

103. Design tools

104. http://styletil.es/
Please, please, please designers: embrace this.
And atomic design.

105. http://pencil.evolus.vn/ My tool of choice for UX mockups, although not perfect.

106. https://www.lucidchart.com/ It just works. Tidy diagrams.

107. http://uxmyths.com/ Fun and very useful.

108. Which Drupal?

109. Hobby Amateur Professional Enterprise
D6
D7
D8
Drupal reach
Will amateurs ever
tinker with Drupal 8?

110. Drupal size
D6
I know it all :)

111. D7
Drupal size
D6 D7
I still know it all :)

112. D8D7
Drupal size
D6 D8D7
WTF? WIll I ever
know enough of it?
The end of
rockstars and solo
heroic devs..

113. D8B1D7
Drupal size
D6 B1D7 D8
This is Backdrop.
There is still hope
to know it all!

114. D6
D7
D8
B1
Drupal size Each “dot” represents a “book of code” of
760 pages, with 72 lines of code per page.
I totally dominate this!
24 volumes of code of 760 pages each! WTF?
How many developers do I need in my team to master it?

115. Drupal size
D 6.37 D 7.42 B 1.3.2 D 8.0.3
Files 500 1,100 2,100 12,300
Folders 60 150 330 3,600
Lines 55,000 177,000 230,000 1,300,000
Pages 760 2,500 3,200 18,000
Volumes 1 3 4 24
Calculated using cloc and tree and rounding the numbers for
clarity. Each page has 72 lines of code.
Drupal 8 includes vendor folder.
988,000 w/o vendor

116. https://backdropcms.org/ The moral is to pick the right tool for your size.
I would rather use Backdrop
than Wordpress…
don’t quote me on this.

117. Server monitoring

118. https://sensuapp.org/

119. https://mmonit.com/monit/

120. Logs aggregators

121. https://www.elastic.co/products/logstash DIY. Complicated but... powerful!

122. https://papertrailapp.com/ Very easy to set up. Good, not great.

123. https://www.graylog.org/ Very interesting. DIY solution.

124. https://www.loggly.com Very easy to set up. Drupal modules to help.

125. Searching

126. https://www.elastic.co/products/elasticsearch
Once you go elastic, there is
no other search so fantastic!

127. Thanksjorge.lopez-lago@onload.uk.com
kurkuma at Drupal.org
Skull icons from http://www.dlanham.com/ui/sticker/