Developing Better Software

Since guideline developing better software, in 3 main areas: software security, performance, and self development.

Transcript

1. Developing Better Software Leong Hean Hong Inno Tech Boot Camp 2018
2. Purpose • Define some guideline for best practices • Serve as starting point for exploration and learning • This is not complete, neither is it final!
4. Approach • Focus more on how to think, instead of how to do • Continuous learning from various sources (not just Google) • Share what you learned
6. Guideline • Don’t trust external input • Avoid security by obscurity • Use proven methods/algorithms • Configurable security algorithms • Principle of least privilege
7. Don’t Trust External Input • JS validation can be bypassed • Client (e.g. mobile client, end user) may not provide input as intended/specified • ALWAYS validate all input • Escape data before saving in database • Escape data in display • Minimise dependency on input. Verify with data source, perform calculation.
8. Avoid Security By Obscurity • “Obscurity is fine until it is discovered, but once someone has worked out your particular obscurity, then your system is vulnerable again. Given the persistence of attackers, this equates to no security at all.” - xan on https://stackoverflow.com/a/533997/58542 Google: why security by obscurity is bad (http://bfy.tw/GX6K)
9. Use Proven Methods/Algorithms • Self-inventing “complex” algorithm may not be as secured as you think • Prefer opened, tested methods/algorithms • Recommended encryption algo: AES, RSA • Recommended hash algo: SHA2 family, SHA3 family, bcrypt
10. Configurable Security Algorithms • MD5 was popular, now it is considered insecure. Can you change algorithm without affecting application? Linux shadowed password: $id$rounds$salt$hashed E.g. $5$rounds=80000$wnsT7Yr92oJoP28r$cKhJImk5mfuSKV9b3mumNzlbst FUplKtQXXMo4G6Ep5
11. Principle Of Least Privilege • Give user just enough privileges to get job done. • Not everyone need sudo privilege. • Not everyone need write permission, read-only is sufficient.
12. Challenge • If source code is stolen, is application still secure? • If database access is comprised, is data still secure? • If password is stolen, is account still secure? • If <x> is <y>, is <z> still secure?
13. Developer Experience
14. DX: Problems • You work in a team. • Existing/new developer work on your code. • You work on code written 2 years ago. • Adding new feature without breaking things. • Modify existing features without breaking things.
15. No one wants to pick up your shit!
16. • KISS - Keep It Simple and Stupid • DRY: Don’t Repeat Yourself • UNIX philosophy: Do 1 thing, do it well ◦ Small function/class • Use well-know things e.g. Design Pattern, builtin libraries • Follow conventions (consistency) DX: Guideline (1)
17. • Minimise dependencies among code • Don’t speak. If you need to speak, speak little. If you need to speak a lot, speak loudly. DX: Guideline (2)
18. DX: Documentation • Level 1: Code should be self-explanatory (variable/method/class/package name) • Level 2: Comment, comment comment • Level 3: Wiki, spec documents
19. Hong’s Mistake Rule™ 1. Make is impossible to make mistake. 2. Make it hard to make mistake. 3. Reduce damage of mistake.
20. Performance
21. Popular Techniques (1) • Offload to specialized services/engines E.g. Hadoop, search/indexing engine, mail service, SMS gateway, analytic engine • Do things offline/later. Suggestion: use message queue, preprocessing • Caching Suggestions: Redis
22. Popular Techniques (2) • Use native functions. Don’t implement yourself. • Test app in older phone models. • Test app in slow network condition.
23. DB Performance • There is no need to do everything in single DB query. Consider splitting into 2 queries. Process data using code. • Index, index, index. • Study how DB works. How it perform search. How it insert data. How it index data. How it execute AND/OR/JOIN, .... • RDB is not suitable for all occasions. It is not the only type of DB on earth!
24. Self Improvement
25. • Are I proud of my work? • Can other developers benefit from my work?
26. Automate Automate anything that you need to repeat more than once. Article: http://bit.ly/2H5O62o
27. Work Smart Programmer writes code to solve problems.
28. Sharing Is Caring.
29. Guideline • These is always a better way of doing things. • Learn from the best. E.g. Google, Facebook, Apple, Amazon, … • Try something new in each project. Make your work fun! • Learn a new language. Learn a new framework. • Don’t reinvent the wheel.
30. Tips On Learning • Make it a habit, make it fun. • Learn something that interest you. • Learn it’s pros and cons. • Know when to use it, when NOT to use it. • Think how to modify and adopt it to our existing application/company.
31. Technology Adopted Over The Years • Git • Laravel • Ionic • React Native • Electron • RabbitMQ • Go Programming • Cloud Computing (AWS, Digital Ocean) • What’s next?
32. Challenge
33. A regular palindrome is a string of numbers or letters that is the same forward as backward. For example, the string "ABCDEDCBA" is a palindrome because it is the same when the string is read from left to right as when the string is read from right to left. Write a program that determines if a given word is palindrome. “MADAM” => TRUE “ALEX” => FALSE “REDIVIDER” => TRUE “LINEAR” => FALSE