Author Archives: calebscomputerscienceblog

Apprenticeship Patterns: Confront Your Ignorance

The context for this pattern, as described by the authors, is that you have found gaps in you skill set that are effecting your everyday work. The problem here is that your knowledge of essential tools and concepts is lagging behind that of your coworkers but you are expected to already have this knowledge as a prerequisite for being a productive member of the team. The authors explain that this particular pattern goes hand-in-hand with the “Expose Your Ignorance Pattern.” They stress the importance of adopting both of these patterns simultaneously as just adhering to one or the other can present problems of their own. For instance, by only exposing your ignorance and never confronting it you may end up in a constant state of ignorance and being overly dependent on other team members when it comes to completing essential tasks relating to the project at hand.  On the other hand, if you only confront your ignorance without ever exposing it you may be missing out on valuable insights your team members could provide you not to mention the fact that you may spend too much time trying to learn specific concepts that could have been easily explained to you by a team member who already has the knowledge you are seeking. According to the authors, the solution to this problem is to “strike a delicate balance” between these two patterns in order to ensure you are learning the essential skills necessary for your role without wasting to much time and allowing you to be as productive as possible.

I found this pattern to be quite relatable in my current role as a Security Analyst. When I first joined the team I had very little knowledge when it came to essential information security concepts. For example, in security it is crucial to have a fundamental understanding of how the different layers in the OSI network model function. This can be quite overwhelming at first considering that each of the seven layers have different functionality along with a multitude of associated protocols that they must adhere to. Luckily my team has been really supportive in helping me gain the necessary knowledge and skills by giving me practice problems and either providing me the resources necessary to learn essential skills or pointing me in the right direction to where I can find helpful resources. I think up to this point I’ve been able to maintain a healthy balance of exposing and confronting my ignorance but the advice provided in this pattern will definitely be useful going forward.

 

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective – Research and Design

For this sprint cycle my team and I focused on how we could implement offline capability for the ng2-amrs project. We came up with some designs using balsamiq and researched what tools we could use for the backend and storing data offline. One of the contributors form AMPATH suggested that we look into a tool called PouchDB which is an open-source JavaScript database. What makes PouchDB so useful is that it can be used to store data locally so users have access to application data even when they are offline. After doing some reading and completing the tutorial provided on the PouchDB site, my team members and I decided it would be best to move forward working on the backend of the offline module using PouchDB to store important data which could be accessed offline.

Shane and I worked together last week in doing the PouchDB tutorial. We first had to download the PouchDB codebase which actually proved to be pretty simple. PouchDB can be installed through npm with either of the following commands:

npm install --save pouchdb
npm install --save pouchdb-browser

The second npm install command will only install the browser components of PouchDB. This is probably what my team and I will be focussing on since the ng2-arms application runs in the browser. One possible concern I have moving forward is that in order to keep the data up-to-date, we will have to make sure that our PouchDB database can easily sync-up with AMPATH’s servers when a wifi connection is reestablished. In the documentation, PouchDB mentions that in order implement syncing, the server needs to be compatible with PouchDB. We will need to reach out to AMPATH to ensure their production servers will be able to sync with our PouchDB database.

One of the key features of PouchDB is that it provides an “asynchronous” API. When I first read this I had no idea what it meant as I’m not all that familiar with web-developemt or the DOM design patter. However, after a little reading I started to get the idea. Essentially, the benefit of being asynchronous is that it ensures the user’s experience is not interrupted when calls are being made to the PouchDB database. If this were not the case, database calls in the browser could cause the application to stutter due to the DOM logic being blocked by those calls. The way this works is by utilizing “promise objects” to call database functions. This link provides a really useful reference for how asynchronous code works.

Along with discussing how the backend of our offline module will work, my team and I also tried to figure out how the front end UI should behave when there is no internet connection. Some of the questions we needed to answer were:

  • What type of information should be stored and displayed for individual patients?
    • For this question we want to try and store the least amount of data as possible to optimize storage.
  • What should the UI look like when the user is offline?
  • Should the UI display some sort of notification to the user when they lose their internet connection?
  • Should the user have the option to turn the application to “offline mode” in which they can chose which patients’ data should be stored while the user is offline?

We were able to gain some insight into the first question by referencing the google doc provided by AMPATH. The user stories and requirements describe which data is most important and should therefore be stored locally. For the second question, Fuverion was able to make a couple designs in balsamiq of what the UI might display when there is no intern connection.  As for the last two questions, they are still a work in progress and we will need to consult with the AMPATH developers to determine the best course of action. We will most likely do this in the beginning of our next Sprint Cycle.

 

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: The Deep End

In this apprenticeship pattern, the authors present a problem that I’m sure many rising computer science professionals have encountered early on in their careers. They describe the context of the problem as being when one feels they are stuck in a rut, falling short from their colleagues in terms of knowledge and skill. The authors explain that the only way to address this kind of issue is to dive head first into the “deep end.” What they mean by this is that the only way to advance one’s skill, knowledge and, most importantly, confidence is to take on harder tasks that are more challenging. The authors stress the fact that it is to easy to fall into a pattern of complacency and that it is essential to take risks in order to become a better software professional. One particular quote from this pattern that really stuck with me was the following:

“Risks are opportunities seen through the half-shut eyes of fear.”

I think that fear plays a huge role in decision making when it comes to computer scientists. Most notably, the fear of failure may cause a developer to hesitate in taking on a larger role within a team or committing to working on a difficult project outside of their comfort zone. I think its important to remember that even the most brilliant developers have made their fair share of mistakes and the only way to get better is to continue making mistakes because you are bound to succeed at some point if you keep trying. In this pattern, the authors give a real-life example of how this ideology can serve to benefit a developing professional by providing testimonial from a developer named Enrique Comba Riepenhausen. Enrique found himself taking on a new role at his company that entailed much more work than his previous role. Instead of becoming overwhelmed with fear and hesitation, Enrique rose to the occasion and put his best effort forward. As a result, Enrique excelled at his position and was able to construct a customized platform for his client’s needs.  Since then, Enrique describes having a plethora of opportunities including being able to travel the globe doing what he loves.

After reading this patter I decided to take the advice given by the authors in the Action section by doing the following:

  1. Make a list of the largest successful projects I have contributed to.
  2. Determine the dimensions of complexity as a means of measurement for each project listed in step 1.
  3. Create a chart with the information from steps 1 and 2.
  4. Add any new projects I take on to the chart in order to visualize the trajectory of my career.

 

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Unleash Your Enthusiasm

I thought this section of Apprenticeship Patterns presented a fascinating take on how newcomers might fit in with their more experienced counter parts when entering the professional world of computer science. The authors describe the role an “apprentice” might want to take when working in a team of seasoned computer scientists. They explain that it is common place for newcomers to “fly under the radar” and not speak their ideas due to lack confidence in their ability to be a contributing team member. They point out that while every team may differ, teams typically benefit from having team members of varying skill levels, even “apprentices.” The authors also cite a study involving aircraft carrier crews that showed that it is healthier for teams to consist of people with different degrees of skill and experience and found that newcomers played an integral role in the team dynamic. Finally, the authors propose that newcomers should in fact “unleash their enthusiasm” in hopes that their excitement will rub off on other team members as well as keep other team members on their toes through asking many questions on why things are the way they are as well as presenting fresh ideas.

I honestly found this particular pattern to be extremely relatable as I am currently a newcomer in a security team that is made of individuals who have varying degrees of skill level, experience, and expertise.  When I first started, I admit that I was a little intimidated by all the tools that were being used not to mention all the acronyms being thrown around in meetings that I had never heard of before. However, I feel like that feeling of being overwhelmed pushed me to want to learn more about security and obtain the same kind of knowledge possessed by my coworkers while at the same time applying the knowledge I have acquired throughout the course of my college career. I also feel like I really lucked out because of the willingness of each of my team members to answer my questions and give me advise. After reading this pattern I think I will ask questions and speak up more confidently at work because now I know that it is important to bring a fresh perspective to a team.

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective – Getting Started

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Emptying the Cup (Chapter 2)

The authors began this chapter with a really thought-provoking story of a Zen master and a young philosopher. In this story, the young philosopher sets out to learn the ways of the Zen master but every time the zen master would begin to describe his own practices the young philosopher would cut him short and start talking about how he does things and how it might relate. Essentially, the Zen master is never able to complete any of his thoughts because the young philosopher keeps interrupting and talking about his own experiences. This goes on for a while until the Zen master goes to pour a glass of tea and he keeps pouring until the the cup is overflowing. at this point, the young philosopher tells the zen master to stop pouring to which the zen master replies, “If you come to me with a cup that is already full, how can you expect me to give you something to drink?”

I think that the short story about the Zen master and the philosopher is extremely relatable to learning how to become a software developer. In the field of programming its’s really important to approach problems with an open mind and to not disregard certain techniques or practices due to the fact that they aren’t familiar to you. By emptying your ‘mental’ cup and being upon to new ideas you will inevitably be much more successful in developing and honing down your programming abilities.

The authors go on to describe the best way to get your software development career started. They suggest that you choose one specific programming language and “become fluent in it.” Some of the things they proposed to get help get you started are using that programming language to build a “toy” application, trying to solve real problems using that language, and reading the language’s specification documentation. The authors recommend using tools like git to publish and/or contribute to open source projects. The benefits of contributing to open source projects include the fact that you can get feedback on your code and advice from experienced professionals that already know the language your learning. Overall, I’d have to say that they present some really good advice on how to get your programming career started and I wish that I had read this when I was starting out as it probably would have saved me a lot of headaches.

 

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman – Chapter 1

At first, while reading this chapter of Apprenticeship Patterns I was a little skeptical of how software development could be thought of as a “craft” with some kind of software guild made up of apprentices, journeymen and masters. However, after reading the authors’ own definition of what they believe “software craftsmanship” is I started to agree with what they had to say. I actually found their interpretation of apprentices, journeymen and masters, in the context of software craftsmanship, to be pretty interesting. I think that if all developers took on this way of thinking about software development the software engineering community could benefit immensely. By adhering to an apprentice mindset, software development newcomers might be able to avoid making the same mistakes that past generations of software developers have made.

Another thing I liked about this chapter was the values in which the authors believed every programmer should adopt. I think that adopting these values and committing to the idea that the only way to become a true “master” is through continuous learning though trial and error is the best way to progress your skills and career in the software development field. Among the values laid out by the authors’, I saw a common theme in that they think it is important to be open and transparent when it comes to software development techniques. I feel that competition can sometimes discourage companies and individuals from sharing their ideas and innovations, but this is can be detrimental to the software development community.  If all developers shared their work and development experiences, then software in general could possibly become more reliable and efficient.

This reading definitely made me change the way I think about software development as a whole. One thing it has made me consider is my overall career goals. The book talks about how one of the most important parts of becoming a better developer is finding a position that provides good mentors rather than finding the position that simply has the highest paying salary. This is something I didn’t really think about before and it has made me realize that if I want to enjoy what I do for the rest of my working days I should definitely try to find a place that encourages learning and provides many opportunities for mentors to give me feedback and ideas. Also, I think this reading will change how I work in the sense that I will look at failure in a new light. Instead of being mad that I can’t get something to work the first try I will remember that even the best developer out there has made countless mistakes to get where they currently are.

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.

Introductory Blog Post for CS-448

This is the blog I will be using for Dr. Wurst’s CS-448 Software Development Capstone.

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.

Evaluating Software Testing Strategies

https://www.mitre.org/publications/systems-engineering-guide/se-lifecycle-building-blocks/test-and-evaluation

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.

Software Testing With Security in Mind

For this weeks blog post I wanted to take a look at the security aspect of software testing.  I feel that we have discussed many aspects of software testing in our CS 443 class but one of the aspects we haven’t really gone over is how to determine whether code we write is secure.  Many of us, at some point in our carriers, will probably write software that will be used in a web/ desktop environment. By testing such code for vulnerabilities before it is released we can save ourselves and the companies we work for from falling victim to data breaches and stolen information. I found this article titled, How to Test Application Security – Web and Desktop Application Security Testing Techniques, and it discusses the issues I have just introduced.

The author of the article defines security as meaning “that authorized access is granted to protected data and unauthorized access is restricted.”  They then go on to distinguish between desktop and web-based software and the different security needs for both. Essentially, they suggest that both types of software require similar security measures to protect sensitive data, however, most web based software will require a little extra security measures since this type of software is accessible to anyone on the internet.

In the Article the author brings up a number of interesting points regarding testing how secure a piece of software is but I would like to focus on three of their main points as I feel they are really important. The three points I’d like to focus on are data protection, brut-force attacks, and SQL injections/ XSS.  To test for data protection in your software, the author suggests, you should ensure all passwords in your DB are being encrypted when they are transmitted. Also, if your software is web based, you should be using the HTTPS protocol rather than HTTP and you should test certificate validity on the server side. When it comes to testing whether your software is vulnerable to brut force attacks, the author says you should have some kind include “some mechanism of account suspension” into your software.  Finally, in order to test for SQL injections and XSS attacks we must treat any part of the code that accepts user input as a vulnerability.  The author advises that make sure there is a maximum length of characters for valid input as well as a checking mechanism for basic SQL injection techniques.

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.