Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Introduction to Software - Coder Forge - John Mulhall


Published on

An introduction to software for Coder Forge on 27th April covering common terms, OOP and programming tips

Published in: Software
  • Be the first to comment

  • Be the first to like this

Introduction to Software - Coder Forge - John Mulhall

  1. 1. An Introduction to Programming by John Mulhall For Coder Forge Meetup Group
  2. 2. johnmhll:~ johnmlhll$ whoami johnmlhll • Whoami? 15 years in Process Management and Backoffice • Transitioned to Software after a Cert in Project Management in 2014. First ever piece of coding in Sept 2014 • Can code (apps/scripts) in Java, C#, Node.js/Javascript, Python, CSS/HTML • Graduated Level 8 year long Course in Advanced Project Management (2014) with 71% and Software & Cloud Technologies in 2015 with 79% • Follow me on on LinkedIn, Google+ and Twitter @johnmlhll • Contact @
  3. 3. Agenda • Definitions/Common Software Terms • Object Orientated Programming (OOP) • OOP V Functional Programming • Software Application Lifecycle • Programming Tips
  4. 4. The States of a Programmer 2% of the time : the other 98%
  5. 5. Definitions/Common Software Terms Letsexploresomeof thecommonterms… • Software Developer V Software Engineer – A Software Developer develops software whereas a Software Engineering applies engineering principles (e.g. OOP) to software creation. Not all Software Engineers are Software Developers and vice versa. • OOP – Object Orientated Programming (OOP) refers to a type of computer programming (software design) in which programmers define not only the data type of a data structure, but also the types of operations (functions) that can be applied to the data structure. (creds: Objects refer to real world component objects in the design logic under OOP. E.g. Java, C#, Python, Javascript • Functional Programming – It is a programming paradigm that preserves immutability in the mathematical design of objects, behaviors and programming flows. It is a pure processing design paradigm. Think railway tracks delivering trains from station a to b to c to its destination d. The stations are objects and the train is the subject data/query process. E.g. Pascal, Scala • Single Inheritance – A design architecture that allows inheritance from a single base class. It’s considered more structured and safer for larger projects. E.g. Java, C# • Multiple Inheritance – An OOP design architecture that solves the “diamond shape problem”. Complexity is increased and error likelihood given the inherited multiple base class relationships an object can have. For discussion: Javascript, Expandos & Mixins… E.g. Python, C++
  6. 6. Definitions/Common Software Terms • RDBMS V DBMS – Relational Database Management System is a database design concept based on tables, schemas, primary keys and foreign keys driving row based data management (ACID transactions = Atomic, Consistent, Isolation, Durability). Think MySQL or SQL-Server databases as RDMBS. Data Base Management Systems refers to a collection of tables, databases and schemas without an existing storage infrastructure. Think RDBMS/NoSQL database in the one storage solution as DBMS. • SQL V NoSQL – SQL is a database manipulation language for RDBMS allowing data to be directly queried against the database tables where NoSQL (aka. Not Only SQL) is a database management system that is a schema flexible, columnar driven database management system that ID’s data by tablet, column, timestamps and row key in some cases (BASE transactions = Basically Available, Soft State, Eventual Consistency). Think “Big Data” Key Value Storage databases being designed in the BASE paradigm • NFS V DFS – Native File Systems are present on the machine or server on which you base your operation on. Distributed file system operates from a single machine across a number of machines called nodes to make up a cluster. The latter increases processing and storage power across several nodes.
  7. 7. Definitions/Common Software Terms • Normal Forms 1 – 7 – These are database table design principles for RDBMS that accommodate the one to one, one to many and many to many relationships to present clear, single data piece per field data storage. The design differences range from Normal Form 1 through to 7. • Separation of Concerns – Application Software Design requires separation of concerns to ensure that if something goes one in in part, it will not adversely affect the other parts of the application. E.G. if data input from application fails, existing data stored will not be affected. Also, if business rules (software layers) change for processing customer data flows on the application layer, the underlying storage layer will not be affected • Strongly Typed – Languages that support defined data typing and compile only if explicit data type rules are defined. E.g. Java, C# • Weakly/Dynamically/Loosely Typed – Languages that support implicit data type conversions. E.g. Javascript, Python
  8. 8. Definitions/Common Software Terms • Reusable Code – An engineering principle that requires code to be engineered into objects that can be reused as they are originally designed • Modular Code – An engineering principle that requires code to be engineered into objects that can be functional as a unit or module. Think assigning a behaviour to a function or method. • Readable Code – A principle that requires code to be written in convention e.g. “public static String iLoveCode(java); {}” and in a manner that tells a story about what the code is doing. e.g. Incorrect practice: “public static String x(y); {}” • Bad Coding Practice - Spaghetti Code – Code that is devoid of good coding practice, is not readable, near modular, unusable and cannot be reused due to its lack of coherence and structure. Beware of “goto” statements.
  9. 9. Definitions/Common Software Terms • Base Classes – This is the base class in OOP that has the base methods associated with the class object. These methods (objects) maybe implemented or could be detailed in the case of an abstract class. All base class methods are inheritable unless they are termed “final”. E.g. “public static final String iLoveCode(java); {}” . In such a case, the method is not available to derived/concrete classes. • Derived/Concrete Classes – These are classes associated with a base class by inheritance. The derived class has the inheritable base class objects available to it and under OPP principles will have an object connection to the base class. E.g. Derived Class “public class Horse extends Animal {}” inherits from “public class Animal {}” (a Horse Is- A Animal) • Static Classes – The same as a normal case making all its members available to all classes with access to it. However static classes cannot have any instantiation. The “new” keyword cannot be used. • Final Classes – These are classes that cannot be inherited/extended
  10. 10. Definitions/Common Software Terms • Abstract Classes – They a first step at defining non implementing class level objects that define members (methods and/or properties) but don’t implement them. They instead make them available for implementation in derived/concrete sub classes. • Interfaces – They are similar to Abstract Classes but are not class level objects. They implement class level objects by ensuring detailed members in the interface are implemented in the associated classes. • Objects – They are code wrapped in a header that has name, access levels, arguments and/or other elements like data type and/or inheritability associated with the code implemented within the class. Objects can be properties, variables, methods, functions, classes, etc.
  11. 11. Definitions/Common Software Terms • Methods – objects within a class that define a behaviour within the program • Functions – objects that define a specific behaviour within a program • Instance Variables – variables that belong to the instantiation of an object • Static Variables – variables are are available to all classes but not available to instances of objects within the program • Class Variables – variables that belong to a class rather then a instance of a class • Local Variables – variables that are declared and accessible within a method or a function object only
  12. 12. Definitions/Common Software Terms • Instance – is the “new” key word creating an object from a class or number of classes that performs a range of programmed behaviours • Properties – the assigning of object properties to a reusable variable field including getter and setter properties to be assigned to the property. E.g. “public int myProperty {get; set;}” (c# example) • Elements – the elements of a given object (class/methods) • Operators – programmatic symbols that perform specific functions, which are most commonly mathematical calculations (normally) e.g. “+-”,”%*/”…. Non mathsey examples…. ”instanceof”, “++”, “+=”
  13. 13. Object Orientated Programming (OOP) • Object Orientated Programming refers to the architecture of coding around real world objects that are related to each other by a “Has-A” or “Is-A” relationship. They are considered to be be relationally linked as a result creating a programming structure based on real world objects that relate to each other within the progams use case. • E.G. – Program Car: • Car => • Engine => Wheels => CabFittings => Windows => Seats • Next level of derived class objects in the OOP design structure
  14. 14. Object Orientated Programming Chart (OOP) Animal Fish Trout Shark Dolphin Mammal Dog Horse
  15. 15. OOP Explained - A.P.I.E. • Abstraction – The concept of creating a layer of functionality that is visually separated from the underlying code which supports it. It creates in essence an outside view of the object where it uses its elements to execute a set of behaviours but cannot see what those elements in the underlying code are. E.g. “Kibi” is a big data tool that is separate from Kibana but developed from it. It’s a new layer of functionality on top of the original product without seeing the original product. • Polymorphism – The use of a method in subclasses for different purposes e.g. “public abstract class Surgeon{}” has a method “public void cut();” Surgeon class has two derived classes “public class Surgery{}” and “public class Barber{}” that have inherited the method “public void cut();”. Surgery class implements the method to cut into patients in surgery and Baber class implements the method to cut the surgeons hair. • Inheritance – The making available of methods and properties in a class to a class at is derived from it. • Encapsulation - When the members of a class are only visible to the other members of a class, this is called encapsulation. Encapsulation leads to “Data Hiding” (i.e. think method calls visible in main class/method & method implementations hidden in a class file)
  16. 16. Abstraction • Very useful for creating new “outside in” functionality on top of existing products/layers. e.g. Meteor.js templates {{{text}}} are a layer of abstraction on top of Meteor.js. • The outside in approach allows objects to be abstracted from underlying software and used in a manner that does not reveal their distinct behaviour e.g. any SaaS Product online such as pic monkey • Abstraction increases efficiency of software whilst hiding the underlying software processes that support it.
  17. 17. Polymorphism • Used to streamline coding, increase efficiency and prevent duplication of code. e.g. method cut() cut’s hair in barber class when overridden and cuts into patients in surgeon class when overridden there but the basic attributes of the method header cut() with implementation for a blade and cutting action is present in the base class version of the method that they both inherit from • Polymorphism also enables good inheritance structure whilst increasing functionality of the code. It also works well when a single element needs to be implemented in a number of classes via an interface: • Interface iCut() • { • Public void cut(): • } • //can be deployed in all classes that implement iCut();
  18. 18. Inheritance • Is-A Relationship – “An Salmon Is-A Fish” • Has-A Relationship – “A Car Has-A Engine” • Class Hierarchies: • Base Class => Abstract Classes => • => Derived Classes=> Interfaces • Provides Access to Methods in Super/Base Classes • Instance Members of Classes V Class Members • Instance Members/Methods good for mutable behaviours • Class Members /Methods good for immutable behaviours
  19. 19. Encapsulation • Encapsulation is about protecting attributes (variables and/or methods) from mutating over many objects or process cycles. • It basically wraps an attribute in a public read only assessor attributes (basically calls (gets) the variable/method) so the private method hidden is not changed in the resulting process. The core variable is basically encapsulated in a getMethod() or get; call to ensure it does not mutate. • This is a key feature in the singleton design pattern where a private static attribute is called by a public static attribute and provided to a single class instance.
  20. 20. Demo • Lets explore APIE….
  21. 21. OOP V Functional Programming • Immutable Functional Programming V Mutable OOP • Design of OOP more for real world content housing processes. An application has weather, calendar and contacts functionality with many API calls, sub classing of distinct sub functionalities in there areas • Design of Functional more for real world processing of content. Process for data is • a) module data ngestion • B) data transformation using set criteria for standard file format • C) Data analysis and processing of data into a dashboard • Functional has less ‘moving parts’ then OOP
  22. 22. Software Application Lifecycle
  23. 23. Software Application Lifecycle • Common Project Management Methodologies: • Agile • Waterfall • A little of both…
  24. 24. Programming Tips • Pomadora Technique – break every 35 mins for 2-5 minutes • Read from Top Down – code compiles from top down • Google is your friend - “issue-year-language” • Breakpoints - Step Through/Step Overs • Unit tests – test key assertions in your code to show behaviours so you know how if its progressing as expected • Inverted Recruiting Principle – 95% of All Junior Software Developers/Engineers are recruited by personal networks where 95% of all Junior Software Developers/Engineers rely on newspapers and recruiters in the search for employment • Zombization - Put the laptop away from time to time and go talk to people
  25. 25. Debugging – Reading stack_trace • Read from top down, identify the error as it progresses through the stack • Know your exceptions/what they mean and how they relate to each other • Code to allow checked exception to be caught • E.g try {} • Catch (Exception e){}
  26. 26. Stack Trace, Lets Practice Java
  27. 27. Now lets do a Python stack trace
  28. 28. Now for the hard one (Data Science Studio | DSS) Python layer on Java
  29. 29. Summary • Write Clean Code • Stick to good coding principles of modular, readable, useable code that performs a single testable behaviour per object • OOP for complexity • Functional Programming paradigm for a linear data type processing challenge • Don’t settle for 90% done, you wont get hired. 100% Always • Continuous improvement, never stop learning • Network as much as you can to build a network that will support your career path and ambitions • Build your portfolio and get it out there, its key to success • Know how to debug your code, get help, take breaks and never give up!