Theses for Better Mobile and Web Applications

7,638 views

Published on

In this talk, I rant about 3 issues in software engineering, which I repeatedly stumbled over in my career so far:
- Choosing the tools because we like them, not because they are the best for our problems.
- Rewriting software from scratch, not evolving it instead.
- Piling up awesome masses of dependencies.

... and one general recommendation I draw from my experience: Build your applications as a set of APIs.

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

No Downloads
Views
Total views
7,638
On SlideShare
0
From Embeds
0
Number of Embeds
6,747
Actions
Shares
0
Downloads
4
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Theses for Better Mobile and Web Applications

  1. 1. Hi
  2. 2. My name is Benjamin Erhart
  3. 3. I'm here tonight, because I love programming Perl.
  4. 4. But... I actually don't want to talk about Perl, which is, by the way, a great multi-purpose, multi- paradigmatic, community driven, often underestimated, mature programming language usable for all sorts of things and especially great for data centric web applications.
  5. 5. Instead I want to talk about things one level higher.
  6. 6. Theses for Better Mobile and Web Applications Benjamin Erhart berhart@netzarchitekten.com
  7. 7. or: Various Rants about Programming Topics
  8. 8. BTW: If you want to learn about Perl, there's an Austrian Perl Workshop coming up occurring between November 2nd to 3rd at NCMs offices. or just ask me about a training!
  9. 9. whoami Im self employed and partnered with friends at die.netzarchitekten.com I'm a passionate software engineer in the fields of web and mobile with 10+ years experience and had worked my way up to Head of Development of leading SMEs. I'm available for hire to build your next application, consult you and your team in the arts of proper version control and build management, how to program Perl and JavaScript or help with any security issues you might have application-wise!
  10. 10. 1
  11. 11. Choose your tools depending on your problems, do not try to solve your problems with your favorite tools.
  12. 12. Why? Seems obvious when standing in front of a toolbox. In IT, tools are often chosen because of the wrong reasons.
  13. 13. We already know them. Sure, but: The average life of some technology on the internet is shorter than 10 years. So you better move on, if you don't want to fall behind!
  14. 14. We can't find people with knowledge in better ones. So what? Good programmers will program good in any language. Just give them two weeks to have a look around, maybe kickstart them with a little training. Your programmers are not so good, yet? Well, looking beyond one's own nose is the first step to become better. Let them explore new stuff!
  15. 15. It's too expensive to do it with these fancy new technologies. The best fitting new technologies will save you development time, bug fixing time, customer care time and response time . Otherwise, they wouldn't be best fitting. I guess, that will make up for the extra costs...
  16. 16. The others use it, too! Great! Then there's a perfect opportunity to get an advantage. The same tools surely won't buy you that.
  17. 17. 2
  18. 18. Do not rewrite software from scratch, but evolve it constantly!
  19. 19. This lesson is actually 13 years old*, but worth repeating any time! Everybody loves to start fresh, because: It's harder to read code, than to write it. *) www.joelonsoftware.com
  20. 20. Evolve it constantly Environment changes constantly, even if you don't recognize it for a while: Server hardware breaks, old OS versions don't run on new ones. Libraries in use change APIs in new versions. Documentation for old one vanishes. If you stop development for ½ year, chances are, your application will fall behind so much, you can't catch up anymore.
  21. 21. Enhance the old code – Put it in source control immediately if you haven't, yet! – Start versioning, if you haven't, yet! – Add a proper toolchain for continuous integration/deployment. – Add documentation. – Add unit tests. – Add automated interface tests, if the products value allows it. – Refactor, refactor, refactor. – One step at a time, to allow for a continuously working product. – Do not stick to old environments – don't be afraid of building new parts with new technologies.
  22. 22. 3
  23. 23. Avoid dependency hell for all it's worth!
  24. 24. Wealth through self-restraint – Avoid using other libraries in your own, which only “make the language nicer”. – Do not use libraries, which replicate behaviour of another library you already depend on, just because you think it's “cooler”. – If you can't get it into your (and your colleagues) build chain easily, don't use it!
  25. 25. Why? – Keep resource usage low. – Keep needed knowledge for new colleagues low. – Keep build times low. – Keep demands on IDEs and toolchain low. Not everybody loves your fancy editor. – Avoid unnecessary restraints and need to work around stuff which turn out to be not as a good an idea as thought in the first place. – Your going to pile up enough dependencies over time anyway!
  26. 26. 4
  27. 27. API-ize your applications best as you can! – restful
  28. 28. Testing Complex MVC chains responding with HTML are hard to test. Web APIs returning data structures are way easier.
  29. 29. Server off-load Move business logic to the client, render client- side.
  30. 30. Responsiveness Viewer requests with shorter response times obviously feel less sluggish to the user.
  31. 31. Interoperability Reuse your APIs to integrate into other websites or mobile applications.
  32. 32. Thanks for your patience! Benjamin Erhart die.netzarchitekten.com

×