Category Archives: Computer Science

Working in containers

Today we will be focusing on containers and why containers have become the future of DevOps. For this we will be looking at a blog by Rajeev Gandhi and Peter Szmrecsanyi which highlights the benefits of containerization and what it means for the developers like us.

Containers are isolated unit of software running on top of OS i.e., only applications and their dependencies. Containers do not need to run full operating system; we have been using Linux operating system kernel through docker and using capabilities of our local system hardware and OS (windows or macOS). When we remote accessed SPSS and logic works through virtual machine, VM came loaded with full operating system and its associated libraries which is why they are larger in size and much slower compared to containers that are smaller in size and faster. Containers can also run anywhere since docker (container) engine supports almost all underlying operating systems. Containers can also work consistently across local machines and cloud making containers highly portable.

We have been building containers for our DevOps by building and publishing container (docker) images. We have been working on files like api and backend in development containers preloaded with libraries and extensions like preview swagger. We then make direct changes in the code and push them into containers – this can lead to potential functionality and security risks. Therefore, we can change the docker image itself. Instead of making code changes on backend, we are building image with working backend code and then coding on frontend. This helps us avoid accidental changes to a working backend, but we must reconstruct the container if we are making changes to the container image.

Containers are also highly compatible for deploying and scaling microservices, which are applications broken into small and independent components. When we will be working on Libre food pantry microservices architecture, we will have five to six teams working independently on different components of the microservices in different containers giving us more development freedom. After an image is created, we can also deploy a container in matter of seconds and replicate containers giving developers more experimentation freedom. We can try out minor bug fixes, or new features and even major api changes without the fear of permanent damage on the original code. Moreover, we can also destroy a container in matter of seconds. This results in faster development process which leads to quicker releases and upgrades to fix minor bugs.

Source:

https://www.ibm.com/cloud/blog/the-benefits-of-containerization-and-what-it-means-for-you

https://www.aquasec.com/cloud-native-academy/docker-container/container-devops/

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Microservices Architecture: Uses and Limitations

Using information found by Narcisa Zysman and Claudia Söhlemann we take a closer look at microservices architecture and learn about why it is being widely used and what are its limitations.

Uses:

Better fault isolation: If one microservice fails, others will likely continue to work.

Optimized scaling decisions: Scaling decisions can be made at a more granular level, allowing more efficient system optimization and organization.

Localized complexity: Owners of a service need to understand the complexity of only what is within their service, not the whole system.

Increased business agility: Failure of a microservice affects only that service not the whole application so enterprises can afford to experiment with new processes, algorithms, and business logic.

Increased developer productivity: It’s easier to understand a small, isolated piece of functionality than an entire monolithic application.

Better alignment of developers with business users: Microservice architectures are organized around business capabilities, developers can more easily understand the user perspective and create microservices that are better aligned with the business.

Future-proofed applications: Microservice architectures makes it easier to replace or upgrade the individual services without impacting the whole application.

Smaller and more agile development teams: Teams involve fewer people, and they’re more focused on the part of microservices they work on.

Limitations:

Can be complex: While individual microservices may be easier to understand and manage, the application may have significantly more components involved, which have more interconnections. These interdependencies increase the application’s overall complexity.

Requires careful planning: Because all the microservices in an application must work together, developers and software architects must carefully plan out how to break down all the functionality and dependencies. There can be data challenges when starting an application from scratch or modifying a legacy monolithic application. Also, multiple iterations can be required until it works.

Proper sizing is critical and difficult: If microservices are too big, might have all the drawbacks of monoliths. If it is too small, the complexity of the individual services is moved into the dependency maps, which makes the application harder to understand and manage at scale.

Third-party microservices: Third-party services can change their APIs (or dependencies) at any time and in ways that may break your application.

Downstream dependencies: The application must be able to survive failures of individual microservices, yet downstream problems often happen. Building fault-tolerance into an application built with microservices can be more complex than in a monolithic system.

Security Risks: Microservices growth in popularity, may increase an applications’ vulnerability to hackers and cybercriminals. Because microservice architectures allows the use of multiple operating systems and languages when building an application, there’s the possibility of having more targets for malicious intrusions. We are also unaware of the vulnerabilities of third-party services being used.

When complexity increases, we make sure it is warranted and well understood. Regularly examining interconnected set of microservices so the application does not crash. Learning about limitations helps us come up with such solutions which we can apply in our future work and when we work on LibreFoodPantry system.

Source:

https://www.castsoftware.com/blog/microservices-architecture-a-good-or-bad-approach

https://kruschecompany.com/microservice-architecture-for-future-ready-products/#Microservices_cons

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Object Oriented Programming

OOP is used to structure a software program into simple, reusable pieces of code blueprints (usually called classes), which are used to create individual instances of objects.

Building blocks of OOP:

  • Classes are where we create a blueprint for the structure of methods and attributes. Individual objects are instantiated or created from this blueprint. For example, we can look at Duck class covered in class activity.
  • Objects are instances of classes created with specific data, for example rubber duck is an instance of duck class. It is crucial to remember that class is a template for modeling (a duck in our example), and an object is instantiated from the class representing an individual real-world thing (a rubber duck in our example).
  • Methods perform actions; methods might return information about an object or update an object’s data. The method’s code is defined in the class definition. In simple terms, methods represent behavior. For our Duck example, ducks had methods like fly() and quack(). Duck’s had different behavior. Rubber duck did not fly and did not quack but squeaked. These behaviors are specified in methods.
  • When objects are instantiated, individual objects contain data stored in the Attributes. State of objects depend on data in attribute. For example, Rubber duck is handled differently than a mallard duck based on the information in attributes.

The four principles of OOP:

  • Inheritance allows classes to inherit features of other classes. Basically, child classes inherit data and behaviors from parent class. In our example, Rubber duck inherited display() from duck class.
  • Encapsulation is containing information in an object and exposing only selected information to other classes. Private methods and properties are accessible by other methods of the same class. Public methods and properties are accessible by methods of other classes too.
  • Abstraction is using simple classes to represent complexity. It uses simple things to reduce complexity. Abstraction means that the user interacts with only selected attributes and methods of an object. Abstraction is used in interface. In FlyBehavior we had abstract fly() which was defined in concrete classes as flyWithWings or flyNoWay.
  • Polymorphism uses inheritance. Objects can override shared parent behaviors, with specific child behaviors. In method overriding, a child class can provide a different implementation than its parent class. In method overloading methods or functions may have the same name, but a different number of parameters passed into the method call.

Abstraction reduces complexity and constant overriding of method. Inheritance gives reusable structure across program. Polymorphism allows for class-specific behavior and objects of different types to be passed through the same interface. Encapsulation helps us prevent unwarranted change of important data by developers. Also, Prevents greater security risks like phishing that we face today.Advantages of OOP will never die out. Therefore, I have written this blog explaining OOP and I hope it has been useful.

Sources

https://codecoda.com/en/blog/entry/object-oriented-programming

What is Object-Oriented Programming? OOP Explained

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

About me…

Hi! I am Murtaza. I am a tech nerd. I love to learn and read about new technologies. This is my blog where I hope to share my take on tech today. Thank you!

From the blog CS-WSU – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

WSU x AMPATH || Sprint Retrospective 6

Sams ShipsHey guys, it’s a weird feeling to be wrapping up my last semester in my undergraduate career in computer science (and sociology). For this final installment of my AMPATH sprint series, I will just go over the general overview of what went on for my team.

Most of our updates went onto our PowerPoint presentation, which is going to be presented on May 15th, 2019. My team and I are looking forward to presenting the overall process of our group’s learning and working process, the many lessons we learned, our advice for future students, the work we tried to implement, and various other technical aspects of our project.

We decided that on top of the search bar work, it is also a priority to organize the git repository so it can be better organized and an open work environment for other classes. I think this is important especially when new people come in and cannot efficiently locate and access the files they need. As someone who was once new to an organization that had a lot of different projects and files to sort through, I believe that this is very considerate of the team to go with this.

With some limitations my team had to face, we worked around it to determine how we should move forward. The end result is pretty much a search bar that is attached to the toolbar. It cannot currently be live tested due to there being no backend but it can definitely be done in the future under certain circumstances.

It was interesting being able to observe how much planning you can start with but still end up having to take detours, starting new paths completely, or sometimes even needing to take U-turns.

I thought it would be important to pull some of the advice for future students from our PowerPoint and include them in this wrap-up:

  • Point out and address problems with technology right away because others around you might have the same problem(s) so you can solve them collectively
  • Do all team implementations in a separate component based on what you will be working on
  • Merge your work constantly to the master branch so each team can have the updated changes

A pattern I am noticing in a lot of teams or group projects is that not everything is going to work out in ways that you expected or were hoping for but you learn to move as a shifting team to make progress and continue growth.

Overall, I’d say I learned an important life lesson from this: if I am to contribute extra time on top of my technology career in the future to work on side projects, it will be a challenge to allocate time if it is a group initiative. I also learned that even when we try to communicate everything there is still more room for miscommunication, so there may be no such thing as over-communicating. I am happy to say that we always tried our best to move forward in all ways!

 

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

Find Mentors || S.S. 10

Sams Ships (13)In this final installment of my individual apprenticeship patterns, I think an important one to write about would be Find Mentors. To summarize the main point of this one, I would say that it encourages people to observe their role and their surroundings to see where they can find the most value from learning or use their resources. It encourages you to look at things from one level back instead of blindly jumping into something right away.

Personally, I have been in a role where I had to figure out a lot of things that could have just been taught to me. I quickly learned that I would be able to ask other junior developers how they managed to learn things on their own and it helped me a lot. If other junior developers were not available, then I would work my way up to people who had the most recent on-boarding experience and hope that they could recall the process I was currently going through. For the most part, that worked out well!

Thanks to this pattern, I thought it was useful to think about and remind ourselves that even though our mentors will know a lot more about us, they still do not know everything. They are still continuing to learn as much as we are in their own careers.

I thought I should update this blog to throw in a little hidden announcement if anyone actually reads these that I will be learning at a company with about 100 peers going through the same thing. This makes me feel a lot more confident knowing that I will have a designated support system around me and have mentors around.

Overall, I agreed with the pattern. This is because I can testify with my personal experiences how useful it was to be able to utilize my resources including being able to ask mentors questions or just find my own. A common question I had for my interviewers was, “Will I have a mentor or support system along the way throughout my career progression?” Personally, it is important for me to have a designated place to go for support because it just takes one more worry away about having to ask somebody a question.

It is now time to conclude my individual apprenticeship pattern series! I hope you have at least learned one thing from it because I have learned so many things.

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

WSU x AMPATH || Sprint 5 Retrospective

Sams Ships (14)Over the past two weeks, my team continued to discuss what we are working on as usual. We have come to the conclusion that we will add our Search Bar component once there are updates and more of a base to work off of. This was concluded after we realized that the process would be much more efficient. The parameters and details on the search bar would be harder to figure out without making up a base anyways.

Some advice for others who may be working on the same thing would be to try and collaborate or discuss potential orders between groups if one thing may depend on another. That would make it much simpler from the start if possible so there aren’t any clashes or time wasted on doing extra work that could have just been done by one group or team.

In the meantime, I did a little more research on the AMPATH system out of curiosity since we are going to be building onto their work. I found out that there are 500+ care sites in Kenya! It is interesting to think about the potential impact our work may make on how AMPATH carries out their process. Their initiative reminds me of what Enactus at Worcester State strives for when they work on projects to help people or organizations in the community “sustain their own success, connect them with universal health insurance, train next generation medical professionals, and research new breakthroughs and best practices.” Being able to help a healthcare organization is pretty meaningful, especially as a project through my capstone.

A way to tie our 348 course (Software Process Management) with our 448 (Capstone) course would be through now being able to use Travis CI and Heroku. It was interesting being able to experience using these in class and help our peers use it and now be able to use them in our capstone. I think the practice we got was nice because I found that my peers and I were more comfortable with following steps that were written out and explained to us instead of just “going for it.” I have also noticed that our 348 course helped us pay more attention to how we interact with others, which is very useful for the future when we will be working in teams of developers to create or update new technologies. One more thing which I found useful was seeing Travis CI load, and the race against time when it came to classmates pushing code at the same time; it made me push myself to be a little faster while at the same time not be sloppy about what I was putting into my code.

Overall, we discussed what we will do in these coming weeks as the semester comes to a close. The project we are planning on presenting will feature a search bar which we plan to implement by then. I am excited to see what we end up with in terms of helping AMPATH and their healthcare system!

 

 

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

Draw Your Own Map || S.S. 9

csseries281829For my second-to-last individual apprenticeship pattern, I have decided to go with something a little more relevant to my current situation–relating to starting my career post-graduation.

The Draw Your Own Map pattern caught my attention right away with “we might come across situations or colleagues or people in the society who will try to prove that programming will become an unsustainable activity as time passes by.” Throughout my job search process, I asked questions and requested advice from all different kinds of people across different fields (and especially within computer science) on how they knew what job they wanted to start with when given opportunities.

In the end, I must choose what I think is best for me in terms of what I’m looking for. I’ve finally came up with a list and that includes:

  • Having solid mentorship
  • Proper training (no room for imposter syndrome)
  • A company that tries to stay on top of new technology
  • Work-life balance that allows me to continue doing all the things I love to do outside of work and travel often

The Draw Your Own map pattern is very encouraging, reminding us that we have options elsewhere if we feel that our current company is hindering our learning and personal growth. I found that this pattern was interesting because I part of my decision-making process was “what if I am ____ amount of time into my first career and realize that I do not like what I am doing?” How would I move on out of that role to figure out what I may like better in terms of my day-to-day tasks?

The activity to list three jobs that I could do following my next was was really helpful to visualize future career possibilities. I know that we can always learn on the job and at new jobs but it is also important to build up your skills that can be transferred in the first place.

The pattern has helped me feel more confident in the decision I made to start out in software engineering. I will build up my skills starting here and then more onward from there!

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

WSU x AMPATH || Sprint 4 Retrospective

Sams Ships (12)For this sprint wrap-up, we discussed how we are trying to move on based on our team planning meeting. One of my teammates, Kristi, along with Professor Wurst, tried to check out an idea they had and continued to bounce ideas back and forth with one another until they came to a conclusion.

Overall, I’d say we are continuing to plan out our next steps and work on something new. A new development was a suggestion by one of my teammates based on what we already have to work with. The suggestion was that we should wait for the other group to push what they need and then we can seamlessly build upon it. If the other group (who are working on the sidebar and navigation bar) add their work, it would help us have a better base.

We have to carefully analyze how the components are going to go together and get through to make sure that they are not just getting thrown in. If we plan things out more, it will make the process more efficient. I think taking a step back to look through angular was helpful because it allowed us to learn something new at our own pace. It’s nice to not have to rush on what we are doing; especially when the concepts are newer. This will help us deliver something even greater for our client, who is Greg from AMPATH.

There is also the approaching team presentation that we are going to be focusing on to explain our work and what is happening. I think it will mainly be focused on the search bar and our experience with learning angular or the concepts that introduced us to it.

On top of what we have been doing, I have been continuing looking up resources to learn more for our project. I think Codecademy is a good reference for learning AngularJS, https://www.codecademy.com/learn/learn-angularjs. It is actually one of my preferred sites for reviewing programming languages to sharpen up on things I may have forgotten or for learning new ones in general.

It has been a great experience being able to work with a solid team so far this semester. I wonder how much we will accomplish by the end of it! I think learning about communicating within a team is so important, especially since we will all be graduating very soon and entering roles that require consistent communication.

Overall, the only thing I would say I would have proceeded to do differently is come up with another way to “work smarter not harder” when it came to figuring out the process for the search bar. There were not necessarily any fails because our continued work dealt more with the planning behind the work instead of testing to see what worked for us. I am very excited to continue moving forward with this project in the few weeks we have left!

Some advice for others who are going to work on things includes:

  • Having an open mind on what they would like to do because things are always changing
  • Understanding what the client wants is important because at the end of the day, they will be the ones who need to use this software
  • Try to make sure teammates are on the same page with you on what is happening that week

 

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

WSU x AMPATH || Sprint 3 Retrospective

Sams Ships (11)Hey guys! This sprint retrospective will cover what the WSU Coders Without Borders team has done from the week before spring break and up until this week.

As the project is propelling forward even more than before–due to us having more concrete plans to begin working on the project, it has been an exciting transition. We saw our options from Greg’s wireframes and explanations through his YouTube videos. From there, we created Zeplin accounts so we could visually understand and remember certain parts of the app in progress.

Since it was my first time using Zeplin, I wanted to add a little review of it. As someone who loves to organize things, I found that it is a great tool to have for sorting projects and handing off designs and style-guides to other users. It seems like an effective way to share ideas directly with people.

The overall WSU team now has a GitHub section for dividing up the components and issues we will be working on. So far, my team is going to tackle the search bar and everything else it would entail to create. It was nice being able to collaborate amongst one another to find a component that we agreed to work on (and the fact that a few other components had already been assigned to some teams helped our decision be made faster).

From there, we were figuring out what we need to do and how we can get things done. We discussed some potential ideas with Professor Wurst and from there continued to brainstorm for the search bar. There is nothing that comes to my mind that I would have chose to proceeded differently with if I could go back.

We are continuing our meetings as they have been scheduled and are actively participating in our stand-ups. I like being able to scroll through the log of my team’s answers because it shows our progression throughout the semester as well as serving as a reminder of when we did something specifically. I am happy to say that my team does not seem to have run into any issues or potential miscommunication among one another. It really shows how we are all working to achieve something together and effectively communicate what is happening.

In this sprint retrospective I also wanted to discuss how what we learned may be applied in other situations like in the workforce. We have to make sure we are checking in with teammates to have them understand the project more and be able to express their opinions and concerns when they arise. Similar to the bystander effect in psychology, if there is no direct communication between members when it comes to getting things done, how will there be any progression versus just observing what is happening? All it takes is being comfortable to ask different individuals if they have anything to share or add to the open conversation.

Overall, I am excited to move forward and see what is in store for me and my team during these weeks up until the end of the semester!

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