A Tale of Two
Apps
WHY DEVELOPMENT PRACTICES MATTER
1
Who Am I?
 Chris Tankersley
 Been Doing PHP for 9+ Years
 Lots of projects no one uses, and
a few that some do:
 https...
What did we need to do?
“Build an app for agents to quote and
issues new policies online, print ID
cards, and policy docum...
We had this… kinda
 Backend iSeries vendor supplied a „solution‟ for
our Personal Auto policies
 Only worked with Person...
What did we have? 5
We needed a solution
 We needed something that worked with our
existing backend, which had all of our raters and
business...
What we decided to do
 Build one!
7
What we decided to do
 Build one!
 Purchase one!
8
We went with a vendor with a pedigree in insurance. They had a
Tomcat...
Their Solution 9
More on them later though
We finally build our own!
We needed to bring our commercial business online to
help sell it. We had the technology (but no...
Our Solution 11
Why Two Solutions?
Notice how I said that the Tomcat/Postgres app would
be done in 6 months?
12
Yeah…
The app took much mo...
What was different?
 Proper specifications
 Development Lifecycle
 Understanding your stack
 Testing and QA
 Deployme...
Proper Specifications
 Functional and technical specifications are a
must. If you don‟t know what you are
building, how w...
There is a difference
between this
15
And This 16
Development Lifecycle
 Waterfall
 Spiral/Prototype
 Agile (SCRUM, Kanban, etc)
17
They used Waterfall 18
We used Agile-ish-stuff 19
Understanding Your Stack
 If you don‟t know how your stack works, it makes it
really hard to figure out problems with thi...
Their Stack 21
Our Stack 22
Testing and QA
 You do test your code, right?
 How do you prove your code works?
 Can anyone run your tests or are they...
They used only “HP
Functional Testing”
 As the name implies, it just did functional testing.
In the end, it was a very ex...
We used standard PHP
tools
 PHPUnit
 We settled on PHPUnit for unit testing. It was/is
widely documented and we even man...
Unit Testing Works!
 Using unit testing and continuous integration, we
were able to detect test failures right away. Bein...
Deployment Practices
 Continuous Integration Tools (Jenkins, xinc/phing)
 Build file with manual deployment
 Custom dep...
We went the custom route
1. Tagged trunk in SVN
2. Script checked out the build, SCP‟d it to the
iSeries
3. MySQL Updates ...
They went with the last
option
1. The code on the dev server was packaged as a
WAR file
2. The SQL needed for the upgrade ...
Putting it all together
 Auto Quoter
 Originally 6 months to production and small price
tag. Ended up being way over bud...
Questions? 31
Thank You!
 chris@ctankersley.com
 @dragonmantank
 https://joind.in/9070
32
Upcoming SlideShare
Loading in …5
×

A Tale of Two Apps

1,371 views
1,255 views

Published on

This is the Zendcon 2013 version.

At one point in time, I was the technical lead on two different projects. One was an application we were purchasing from a vendor that was being written in Java (and had previously been written in .NET by another vendor, who then switched to Java, and then abandoned the project), and one was being built in-house with PHP on the IBM i. They were the same product for two different product lines that we offered, but time constraints forced us to build two products in tandem. In the end, the PHP application was completed and delivered to end-users in about 7 months from start to finish, while the former project languished. We'll compare the two projects in the tools and technologies that were used to integrated with the IBM i backend as well as programming.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,371
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

A Tale of Two Apps

  1. 1. A Tale of Two Apps WHY DEVELOPMENT PRACTICES MATTER 1
  2. 2. Who Am I?  Chris Tankersley  Been Doing PHP for 9+ Years  Lots of projects no one uses, and a few that some do:  https://github.com/dragonmant ank  Worked in insurance for 4.5 years  I know RPG! 2
  3. 3. What did we need to do? “Build an app for agents to quote and issues new policies online, print ID cards, and policy documents, and all the fun stuff associated with that.” 3 * „Fun Stuff‟ was subjective
  4. 4. We had this… kinda  Backend iSeries vendor supplied a „solution‟ for our Personal Auto policies  Only worked with Personal Auto  After many years, support was dropped 4
  5. 5. What did we have? 5
  6. 6. We needed a solution  We needed something that worked with our existing backend, which had all of our raters and business logic. We didn‟t want to switch processing systems.  Turns out we had two things – a web app and a “RESTful” interface to the iSeries. The interface used ACORD XML, which is a standard XML schema. We could replace the web app with a new one that understood ACORD! 6
  7. 7. What we decided to do  Build one! 7
  8. 8. What we decided to do  Build one!  Purchase one! 8 We went with a vendor with a pedigree in insurance. They had a Tomcat+Postgres solution, and since the magical black box talked XML, they were confident they could swap out their rating system with theirs. We‟d be done in 6 months.
  9. 9. Their Solution 9 More on them later though
  10. 10. We finally build our own! We needed to bring our commercial business online to help sell it. We had the technology (but not $6 million) 10
  11. 11. Our Solution 11
  12. 12. Why Two Solutions? Notice how I said that the Tomcat/Postgres app would be done in 6 months? 12 Yeah… The app took much more time and budget than originally thought. How did we do a PHP app in 7 months and much less money?
  13. 13. What was different?  Proper specifications  Development Lifecycle  Understanding your stack  Testing and QA  Deployment Practices 13
  14. 14. Proper Specifications  Functional and technical specifications are a must. If you don‟t know what you are building, how will you know how to build it? Or when it‟s finished? 14
  15. 15. There is a difference between this 15
  16. 16. And This 16
  17. 17. Development Lifecycle  Waterfall  Spiral/Prototype  Agile (SCRUM, Kanban, etc) 17
  18. 18. They used Waterfall 18
  19. 19. We used Agile-ish-stuff 19
  20. 20. Understanding Your Stack  If you don‟t know how your stack works, it makes it really hard to figure out problems with things go belly up. 20
  21. 21. Their Stack 21
  22. 22. Our Stack 22
  23. 23. Testing and QA  You do test your code, right?  How do you prove your code works?  Can anyone run your tests or are they only accessible to certain people? 23
  24. 24. They used only “HP Functional Testing”  As the name implies, it just did functional testing. In the end, it was a very expensive Selenium.  While they wrote in Java, they did not use (nor understand why anyone would use) JUnit or other unit testing frameworks.  Because it was cost prohibitive, we could not run tests. 24
  25. 25. We used standard PHP tools  PHPUnit  We settled on PHPUnit for unit testing. It was/is widely documented and we even managed to get it to run on the iSeries.  Selenium  We manually ran these tests as we hadn‟t worked out how to get it to run headless. Not a big deal because we had to support IE, which only supported manually running it anyway.  phpUnderControl  This ran PHPUnit automatically for us and built our documentation 25
  26. 26. Unit Testing Works!  Using unit testing and continuous integration, we were able to detect test failures right away. Being able to run PHPUnit on the iSeries helped us identify and fix platform-specific bugs. Since developers could run PHPUnit and Selenium locally, we had less regressions.  Since HP Functional Testing was expensive, only the vendor could run the functional tests so developers (even at the vendor) never knew when the tests broke. Since it was only functional, it didn‟t find subtle bugs in the code. 26
  27. 27. Deployment Practices  Continuous Integration Tools (Jenkins, xinc/phing)  Build file with manual deployment  Custom deployment script  Hope and a Prayer 27
  28. 28. We went the custom route 1. Tagged trunk in SVN 2. Script checked out the build, SCP‟d it to the iSeries 3. MySQL Updates were applied by the script This worked pretty well considering we could tag a revision in SVN that passed tests, which we could check via phpUnderControl. 28
  29. 29. They went with the last option 1. The code on the dev server was packaged as a WAR file 2. The SQL needed for the upgrade was put into a file 1. Sometimes multiple SQL files that would need to be run in order 3. A zip file was created from this 4. It was e-mailed to us 5. We put the WAR file into place and ran the SQL files manually against Postgres 6. Tomcat was restarted tl;dr: Stuff blew up regularly 29
  30. 30. Putting it all together  Auto Quoter  Originally 6 months to production and small price tag. Ended up being way over budget and way over time. When I left, it had just barely gotten to where v1 had originally been. This was due to poor specs, poor QA, and poor development practices.  Artisan Quoter  We ended up 1 month over time, but much cheaper (even when payroll was considered). It ran on existing hardware, so the software cost only ended up being Zend Server. 30
  31. 31. Questions? 31
  32. 32. Thank You!  chris@ctankersley.com  @dragonmantank  https://joind.in/9070 32

×