Post #28 – Reflection on the “Practice, Practice, Practice” Pattern

This week, I will be writing a reflection on the “Practice, Practice, Practice” pattern.  This pattern addresses developers who want to get better at programming and to expand your diversity of concrete skills.  I chose to reflect on this pattern because I recently accepted an offer for a summer internship and I intend to put in quite a bit of practice before I begin working in June.   Oshineye and Hoover provide solid advice on how to exercise programming skills for those in the ideal situation of having a mentor and those who are left to their own devices.

They begin by saying “Take the time to practice your craft without interruptions, in an environment where you can feel comfortable making mistakes”.  I think environment is a very important element in getting the most out of practice.  The environment in which you practice should allow you to focus completely on the skill you are trying to improve.  Ideally, this environment would also include a mentor that can help guide your practicing and gauge your progress.  Personally, I think an ideal environment could also include peers who are also developing their programming skills because it would provide more outlets for each individual to discuss their work and mentor one another.

They go on to say that the key to this pattern is finding time to develop software in a stress-free environment with no due dates production issues, or interruptions.  This pattern, like the “Breakable Toys” pattern, also stresses the importance of short feedback loops in practice sessions.  Short feedback loops refer to the cycle of completing exercises and quickly receiving feedback on your performance for the purpose of gauging a person’s progress toward a goal.  Short feedback loops can be found in the form of feedback from a mentor or in your own incremental completion of progressively more difficult tasks.

To implement this pattern, Oshineye and Hoover advise developers to find exercises or create their own, and ensure that those exercises will challenge them to at least some degree higher than what they know they are capable of.  They also advise that you should solve and resolve the same issue over some period of time, so that you can see how your solutions change and progress.  I have been motivated by this pattern and I intend to implement it in the coming weeks as I prepare for my internship.

Advertisements

Post #16

I found an article on SoftwareTestingHelp.com entitled “Web Testing: A Complete guide about testing web applications” and I thought it would be relevant to review and summarize it in a blog post.  I have been working on my first true web application, recently, and realized that I may get to a point in its development where I want to conduct tests on it.  During my search for resources on the subject, I found many articles that covered a good portion of web application testing, but this guide was the most comprehensive and helpful, in my opinion.  Having read it, I feel that I will be able to conduct more inclusive and thorough tests of our application, if necessary.

This guide covers the 6 major web testing methods:

  • Functionality Testing
  • Usability Testing
  • Interface Testing
  • Compatability Testing
  • Performance Testing
  • Security Testing

Functionality Testing
Testing links, forms, cookies, browser optimization, databases, etc.

  • Links – Test for external and internal links, links used to send email/messages from users; Check for unlinked pages, broken links, etc.
  • Forms – Test for validations on each field, default values, wrong inputs, options to create/view/delete/modify forms, etc.
  • Cookies – Test for enabled/disable options, encryption, session cookies storing session information after they end, deletion of cookies, etc.
  • Browser Optimization – Test for syntax errors, crawlability, etc.
  • Databases – Test for data integrity, errors while you edit/delete/modify databases, correct execution of queries,  etc.

Usability Testing
Testing navigation, conent, user assistance, etc.

  • Navigation – Test for ease of use, consistency, etc.
  • Content – Check for spelling errors, broken in-text links, proper format of text and images, etc.
  • User assistance – Check for all links on sitemap, test search options and help files, etc.

Interface Testing
Testing the application server and database server interfaces.

  • Check that interactions between servers are executed properly, what happens if a user interrupts one of these interactions, what happens if a connection to the server is reset during an interaction, etc.

Compatibility Testing

  • Testing the compatibility of the program to different browsers, operating systems, mobile operating systems, and printers.

Performance Testing

  • Testing the performance of the application on different internet connections with different amounts of traffic.

Security Testing
Testing the web security of the application.

  • Test for internal pages opening without being logged in, reaction to invalid login inputs, effective CAPTCHA, all transactions/errors/security breach attempts should get logged in log files somewhere on the web server, etc.

Post #15

We have begun work on the web application for the final assignment, so I wanted to find out what design patterns and principles are most commonly used in the development of web applications.  The result the came up the most, in my search, was the Inversion of Control (IoC) principle, a design principle used to increase the modularity and extensibility of  programs, especially web applications that expect to experience growth.  This principle is also useful in event-driven programs, which is how it relates to a project like ours  While we don’t really need to consider the growth of our application in the context of our class, it could be potentially useful to follow the Inversion of Control principle as much of our application will be event-driven.  I found it incredibly interesting to learn about the IoC principle and knowing how it works will surely benefit me in the development of other web applications in the future.

IoC is a design principle in which most of a program’s flow of control is received from a framework, rather than being directly implemented in the main parts of the program.  In traditional programming, the code that expresses the purpose of the program calls into libaries to perform tasks, but with IoC, it is the framework that calls the task-specific code.  This principle is given its name because adhering to it effectively inverts the control of the program from implementation to frameworks.  Adhering to the IoC principle serves the purposes of decoupling execution of tasks from implementation, focusing a module on task it is designed for, freeing modules from assumptions, and preventing side effects when replacing a module.  Software frameworks, schedulers, event loops, dependency injections, template methods, and callbacks all follow the IoC principle.

The IoC design pattern is, in my opinion, a difficult one to fully grasp.  The most helpful explanation I found about the pattern was in a YouTube video uploaded by Christian Richards, entitled “Programming – What is… Inversion of Control”.  In the video, Christian provides the example of a program that wishes to make a new user; when constructed, an integer variable is passed in, as a parameter, to the User class’s constructor and is used to dictate what kind of SQL Database Access Layer (DAL) will be initialized and stored in the new user.

The fact that the User class is responsible for a new DAL object to store within itself means that the User class is tightly coupled with the creation of new DAL objects. 

In order to improve the modularity and extensibility of the program, Christian knows that he should adhere to the IoC principle, and decouple the creation of DAL objects from the User class.  The User class should not contain code for deciding which kind of DAL should it should use; instead it should simply know how to work with DALs, and let the implementation dictate which DAL to use.  This can be done by creating an interface to represent DAL objects (let’s call it ‘IDAL’), create concrete DAL objects for each different kind of DAL and implement IDAL in each one, modify the User class’s constructor to take objects of IDAL type, and then modify the main implementation of the program to create and pass in a concrete DAL object to the User constructor, upon construction.  Now, the User class is simply responsible for dealing with the DAL object, rather than deciding which kind of DAL object to use and only then working with it.

Here are excerpts of Christian’s program, before and after adherence to the IoC principle:
class Program
{
static void Main(string[] args)
{
User user = new User(1);
}
}
class User
{
IDAL dal;
public User(int IDALtype)
{
if(IDALtype == 1)
{
dal = new MySQLDAL();
}
else
{
dal = new SqlServerDAL();
}
}


class Program
{
static void Main(string[] args)
{
User user = new User(new MySQLDAL());
}
}
class User
{
IDAL dal;
public User(IDAL IDALtype)
{
dal = IDALtype;
}
}
Continue reading “Post #15”