https://www.qualitylogic.com/2018/01/11/closer-look-integration-testing/

Integration testing is the process of assembling various code modules to preform very specific tasks in a software system that uses them in a more generalized application. The article gives the example of using a module that stores and retreives files with another that displays their names in a list and another that reads keystrokes as well as one that that recognizes mouse clicks, all together it is a file manaement application. Each module is usually created and tested seperately using unit tests before being added to the code control system. After in the management system they are subjected to integration tests which tests them in conjunction with other modules. This usually uncovers issues with data formats, operation timing, API calls, database access and user interface operation.

There are four parts of integration testing that are critical. The first one is software integration which means in part that everything fuctions the way the user commands. For example, with interface operations it is important that when a user does something unexpected by the systems design the application does not simply crash but produces an error message. Next, the modules must continually exchange data as the overall system functions. This is often performed by a data or command bus that facilitates module communication. These buses are often the most stressed component of the system and integration tests should test them under various amounts of load to ensure that the individual modules are working together properly. Third are the API calls which are the most common channel by which the system communicates with third party services and has become a tool for connecting modules together within the system. This allows data and commands to be separated into different function calls making the exchange easier to debug. One of the main issues with API calls for integration testing is that each one needs to be tested separately, through the entire set of data and inside and outside the acceptable range. Then API calls must be tested in functional groups. Finally there is End-To-End testing which is a big priority for integration testing. The test sets up a system called a sandbox environment and then creates tests for every use the application would go through in real world use. User inputs simulate the front end with data and requests which are then communicated to the middleware to work with the backend of API calls to third parties and database manipulations. All of this is carefully monitored for accuracy and run time.

From the blog CS-443 – Timothy Montague Blog by Timothy Montague and used with permission of the author. All other rights reserved by the author.

When someone relies on you in a project, for work or in any other situation, sometimes you realize you do not know how to use a particular tool or technology required. Your coworkers or manager need to have confidence when you are assigned a task, but if you tell them you are unfamiliar with the technology required to do the job, would they not lose that confidence in you? But you can not lie either, of course. What do you do?

Tell them anyway, show them that learning is an unavoidable part of software development and no one can be familiar with every piece of technology out there. If you have to reassure them that you can complete what is needed of you, do so with your ability to learn. Let them see your growth throughout your career. There is an ingrained instinct in most people to appear competent, and to do otherwise goes against that instinct. It can also be a matter of pride, not wanting to look ignorant.

But it has to be done. Exposing ones ignorance and marching on is part of the process and leads to much more growth overall. It allows others to aid you as well and lets the team act as a team. I myself have trouble doing this, so this pattern was an important and difficult one for me to read. I have had trouble admitting ignorance in the past, and while it has not hurt me, it definitely did not result in me learning anything new or fixing my ignorance.

While I have not taken the exact actions described in this pattern, I have made an effort the last year or so to ask questions when someone mentions something I am ignorant of. Instead of going with the flow and letting my ignorance pass by undetected, I try and use it as a moment to learn something new. Exposing my ignorance publicly as the pattern suggests is a bit more daunting. I already do that somewhat implicitly in my blog posts, but I guess I should start doing it explicitly as well. Wish me luck.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

In this Apprenticeship Pattern “Nurture Your Passion”, it explains the the importance of your passion as a software developer and how it can be exposed to situations or circumstances that can affect to maintain that passion. This pattern illustrates various ways to protect and keep that passion healthy as possible in order to prolong the enjoyment of being a software developer such as:

1. Work on what you like.
2. Join a local or study group that enjoys and focuses on the same things that you enjoy or want to learn more about.
3. Read books that can expand your view of the field.
4. Create your own path or move into an organization where your needs, asprirations, and goals can come to fruition.

“Paul Graham said, “The key to being a great hacker may be to work on what you like…. To do something well you have to love it. So to the extent that you can preserve hacking as something you love, you’re likely to do it well.”

This statement by Paul Graham was very interesting and useful to me because for me as an individual, I produce the best work when I love and enjoy what I do. There have been some instances of my life where I would not produce my best work where my state of mind does not like what I am currently doing, whether it be a class that I am taking at school or a part time job.

“To become a journeyman, you will need to have a passion for software craftsmanship. Unfortunately, your daily activities often work to diminish this passion. You might be faced with demoralizing corporate hierarchies, project death marches, abusive managers, or cynical colleagues. It’s hard for your passion to grow when exposed to such hostile conditions, but there are some basic actions you can take to sustain it.”

This is another statement that I found useful and will help me in my intended career because I understand at the end of the day, work is work, and there will always be times where deadlines, corporate needs, managers and co-workers will stress me out, which will lead to a decrease in my passion for software development, particularly video game development. However, the actions that I’ll take will help reinforce my passion to sustain the harsh natures of the work environment and to prolong my love to hone my craft.

From the blog CS@Worcester – Ricky Phan by Ricky Phan CS Worcester and used with permission of the author. All other rights reserved by the author.

For this weeks pattern I wanted to understand and analyze “Retreat into Competence.” This pattern addresses the issues of an individual feeling overwhelmed about not having enough knowledge or experience to tackle a project. In my experience in computer science, this happens almost every time I am introduced to a new project or concept. In… Continue reading Apprenticeship Patterns: Retreat into Competence →

From the blog CS@Worcester – BenLag's Blog by benlagblog and used with permission of the author. All other rights reserved by the author.

This pattern relates to my situation almost perfectly. The authors assume that you are an undergraduate who has knowledge of one or more languages. However, the way we learn to use tools is not always the best way to get a deep knowledge of the tools we are using. The authors say that this knowledge is superficial. It is superficial because you have to look up what to do every time a new bug arises. This line sums it up pretty well, “what’s even worse is that because your knowledge is so superficial, you’re not even aware of how little you know until something or someone puts you to the test.” (Oshineye, Hoover)

I am a little different than the people they are directing this pattern to because I am aware of how little I know in the grand scheme of things. Besides that, the solution to this problem is not cutting corners. Don’t take those shortcuts that will help you finish the project 15 minutes quicker, learn to grind through the hard work and come out with the rewards of Deep Knowledge of tools, technologies, and techniques. I have spent a lot of time being frustrated with my own programs and this pattern helps open my eyes to how many shortcuts I must have taken. To truly understand everything about what your working on you need to develop the deep knowledge and the work ethic needed to get there.

My favorite part of this pattern was some of the advice the authors give. “Find out who first came up with the ideas and understand the problems they were trying to solve.” (Oshineye, Hoover) This has never really crossed my mind (I know, sad). I never thought to go all the way back to the origins of the problem. This will definitely be useful to me in the future. Another piece of advice that I always fail to follow is “when you read a tutorial, you should not be looking for code to copy but for a mental structure in which to place your new knowledge.” (Oshineye, Hoover) I find that sometimes when on a time schedule or you are picking certain things from a tutorial, you feel like you don’t have time to fully go through tutorials and learn everything about the guide. While sometimes this is true, it’s more than likely an excuse to get the project done quicker. I will be diving more into tutorials rather than taking them at face value for their code.

Overall, I think this pattern is great for apprentices. It goes to show that many people take shortcuts and if you do the same, you aren’t building your knowledge the way you should.

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

This pattern is one among the entire patterns that I am not surprise of the ideas discussed in it even though I might not have thought of them as something important if I had not read this pattern. It is quite obvious that as a newcomer to an industry with more experience craftsmen, I will be thinking of how to contribute to my team and also to get the trust of my employer. It won’t be surprising that my employer or team members are wondering how I would fit in the team and be productive to them; but with the ideas from this pattern, that is the least to think of. For instance, there are so many ways that as a newcomer, I can contribute to my team. As the writer rightly said, volunteering for simple and smaller task within the team will enable me to grow with confidence and self respect. With the ideas of this pattern at the back of my mind, I would be coming forward to volunteer for tasks that looks small and could be achieve with or without little effort. I believed this would help deepen my knowledge as I go as well as help me built a reputation for myself. I also think as a newcomer, even if you have the experience that is required to do major tasks, you would still need to humbly start from sweeping the floor whiles trying to tackle the bigger ones. My reason for saying this is that, team members might think you want to show off and you might end up losing the needed support from them.

The pattern also discussed the issues of being condemned to do the minor tasks but I wouldn’t see this as a condemnation provided they are not too much for me to handle; what I would need to is to keep a close eye on what the team is doing regarding the major works making sure I understands what they does and if there are unclear stuffs, then I would ask questions. Also, I won’t be intimidated to sweeping just the floor but would be taking challenging task as well. In fact, I would try to make time to sweep the floor which would serve as something that interest me in the team just to have the passion for it.

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

This week, I read the apprenticeship pattern “Read Constantly”. Out of all the patterns that I’ve read so far, this is the one that will be most difficult for me to implement. Although this pattern will not be the easiest to implement, I think that I will be worth all of the effort because how much it will really increase your market value. The industry is always changing, and it is essentially impossible to keep up with all of it. There are new technologies coming up, old technologies changing and other technologies becoming obsolete, the most valuable engineer is the one who is aware of most of these changes.

Constantly reading has both immediate and long term impacts on your career. In the short-term you can choose to read material pertinent to you current line of work. This might involve deepening your knowledge of a concept that you’re somewhat familiar with. This reading if done consistently can lead to one becoming knowledgeable of how multiple components come together and interact. If the reading you choose to do is focused on the short term, you may find yourself being recognized by your team as the “go to” guy for a wide variety of question and once that occurs, your value as an employee has rocketed. In the long term, constantly reading makes you extremely marketable. This pattern applied with even a tiny bit of consistency will lead you to having a great understanding of the ENTIRE industry as a whole. Having this general knowledge is already a leg up on the competition, but if you choose to apply and experiment with what you’ve read, you may find yourself comfortable with many different programming languages, frameworks, operating systems, etc. Armed with this acquired knowledge and skill, you now have a solid foundation that can be build on going forward in your career.

The value that this pattern has is evident, there really are no drawbacks to this one at all. The one difficulty with this pattern may be time. It is possible that you find yourself having barely enough time to handle the work that you have, never mind having time to do some extra reading. Even with the time constraint, I still intend to apply this even if I am not reading “constantly’.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

This week, I will be writing a reflection on the “Your First Language” pattern.  This pattern addresses those are seeking a job in software development but obtaining said job requires a proficiency in a specific language and/or developers who feel comfortable in one or two languages but are expected to maintain the same standard of quality as their teammates/coworkers.  I chose to reflect on this pattern because I am currently trying to obtain a software development internship and most, if not all, of them require proficiency in at least one or two languages.  I do feel as though I am proficient in Java and C, but I am unsure how my skills compare to those that I might work with in one of the internships I am applying for.  I found this pattern particularly helpful in my current situation.

To deal with this problem, Oshineye and Hoover recommend picking one language and becoming a master of it.  They advise developers to spend a few years solving problems in a single language while honing their abilities.  I found this to be useful because I have had the idea, for the past few years, that employers would look for a diverse skillset in novice developers, but Oshineye and Hoover believe that being a master of one language is more useful than being sufficient in many.

To help improve your experience while learning your first language, Oshineye and Hoover believe that it is incredibly helpful to have an actual problem to solve.  I was at this point last year, which is when I decided to join a website that offers free coding challenges that deal with both real world issues and the type of work you might do in school like programming functions in a specific data structure.  They go on to suggest that, in addition to spending a lot of your own time practicing a language, novice developers should find also experienced mentors to aid in their learning.

Oshineye and Hoover conclude the pattern by describing ways to create short feedback loops and use testing frameworks so that novice software developers can easily track their progress as they learn a language.  This pattern has inspired me to ‘master’ a language, find a mentor, and begin creating feedback loops (such as testing) to track my progress.  I think all of these things will give me a sturdier foundation when I enter the field.

From the blog CS@Worcester – by Ryan Marcelonis and used with permission of the author. All other rights reserved by the author.