Category Archives: week13

APPRENTICESHIP PATTERN REVIEW #8:Expand Your Bandwidth

Learning about what we don’t know is often more important than doing things we already know how to do. Jim Highsmith, Agile Software Development Ecosystems I wanted to write about this pattern few weeks ago but I don’t know why I was hesitating from writing about it, maybe because the whole concept or idea behind this … Continue reading APPRENTICESHIP PATTERN REVIEW #8:Expand Your Bandwidth →

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.

Post #7: Forcing Users to Update their Apps

Hello and welcome back to benderson’s blog, after a three week hiatus, I’m back to talk about a topic in the applications world of computer science which is if a developer can force users to update their app without their decision. This topic is from a recent report from the blog TechCrunch where they discuss how android developers can now force users to update their apps. The news is that at an Android Dev Summit, Google announced the launch of the In-app updates API, this API update allows developers two new ways to push users to update their apps. The blog talks about how google developers were asking for this for a long time and are excited that it is coming. The news updates API is in early testing with a few partners, according to the blog and should be open to more developers in the future. After the build times in Android Studio have slowed down, the team did some tests and found that Gradle, which apparently is the core of the Android Studio build system, is getting a lot faster. The Google team is building new profiling and analysis tools to allow developers to get more insights in their build times.

I choose this blog to discuss this week because the idea of updating apps is such a cool concept to me. Being able to update your software as it is already out in many people phones, computers, etc. is something that doesn’t feel as easy to me as it sounds. Android now being able to force their users to update their apps can make some people upset though since some apps when they come out with a new update aren’t the cleanest version so people just wait till the bugs are fixed on the update but now android developers can just make their users go to the next update immediately. Anyways though, this gives the developers a lot more power and freedom with their apps which is pretty nice for a developer. Another reason I choose this article for my blog is because they talk a little about how their Android Studio Build System uses Gradle which is what we are using in my software class. It was cool to see that stuff that I’m using in my class today is used for a big part in a big company such as google. That is all for this week on benderson’s blog, Thank you for joining me and hope to see you soon.

Link: https://wordpress.com/read/blogs/136296444/posts/1743246

 

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

Sprint 5 Retrospective

Summary

Once again, i think we had a successful sprint this round. Once again we increased team communications and continued to form better team bonds. This is specifically because this sprints task required us to consult each other for things we have expertise in so we could build together what we needed to build. I this sprint we took upon quite a few tasks to get accomplished. Some of these tasks included taking the offline checking of the current ampath build and moving it to the outside of error checking and by doing that, figure out a way to fix the OnlineTrackerComponent bug we found in the program. Another that that needed to be done was establishing communication mediums with the AMPATH group and addressing some development issues we wanted to discuss with them. We needed to know if we had to worry about storing secondary and additional user login credentials offline. Knowing this would prove pivotal to our developmental Sprint. We were also able to create a backend of the new UI we were implementing using Balsamiq. Another task that was sought out this sprint was to update the HLD with local storage approach and add a checkbox to the user settings page to give option to store credentials locally. This task was taken by one of our teammate and although they were working on it alone, collaboration between the individual groups was needed because there were a lot of dependency issues. 

Reflections 

From this sprint i learnt that sometimes not all the task we seek out to accomplish during the sprint planing is able to make it through the entire sprint. During the initial sprint planning, we had a talk about implementing a local database that would store and keep user credentials so for the few days into the sprint i began building the database base but as the sprint progressed and our team was able to communicate with the Ampath people, we realized that that extraneous part of building the database was not necessary needed. Instead understanding the encryption method of the user credentials would better suit us in our task of creating an offline login. Needless to say, i had to clear the drawing board and start again.

Lesson Learnt

Overall i felt like this was the biggest lesson i could take from this sprint because i started building and spending time on it but since it was ruled out as not necessary, it almost seemed like i had wasted that sprint time. IT made me realize that in this software development industry, the product owner and the businessman have the keys and unless you ask them for it often you will develop and code in a backdoor without even realizing that your design grew old in the specifications. Establish a good and frequent communication method with the people overseeing the demands and design of the project serves as key in become a good program develop. It makes no sense to design and solve a problem with no longer exists in your scope of work. 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

Ministry of Testing Podcast

The Philosopher and the tester

In this episode of the ministry of testing, Israel Alvarez talks about his transition from a philosopher background to becoming a QA tester. He believes there is a lot of positives from his philosophy background that has helped his career as a software context driven tester. Philosopher raises topics and concepts that forces you to think and so does testing so it was fairly relatable and easy to apply his acquired skills from philosophy. Being able to critically think is key to becoming a great QA tester. Knowing what to test for and how to test for makes this arguably one of the hardest things to do. Often as a tester, you have to analyze your own thinking, many times risking the analysis paralysis syndrome. As a math and philosophy major, Israel was always faced with problems that often didn’t have plan cut simple solution so he always had to try and apply what he had learned to get the job done with thinking outside the box. That’s what makes testing so hard. Its easy to come up with some things to test in a code or program but finding out things that need to be tested requires a thorough understanding of the product or software that is being developed. You often need to understand it even more than the creators of the product. They only way you can adequately test a product is to find its boundaries, applications and purposes and see what you can do to challenge these thing or break them. In a start up for instance, there are deadlines, scope changes and many challenges’ that testers have to endure. Proving your value as a tester is very important in the early stages of testing. Learning to articulate and defend ones view, as a tester is an essential skill that every tester needs to have to grow. This is a major challenge because developers often have to prove their point and findings to the programmers. Programmers often have strong views and passion for their work and in order to properly nit pick and criticize defect or bug that is in their work, you need to be able to establish yourself and emphasize overall product quality in your defending’s. As a tester, developers often have stressed feelings towards your work. It’s just the nature of the job as a QA manager or tester. It’s your job to ensure that the developers have put out the best possible product or software they can produce.

 

Source

https://soundcloud.com/ministryoftesting/the-philosopher-and-the-tester-israel-alvarez

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

38. How to be a Programmer: Personal and Team Skills

 

Coding blocks podcast is presented by Joe Zack, Michael outlaw and Allen Underwood. In this podcast episode, the gang talks about what it takes for someone to become a good programmer for his company and his team. One thing that is known to be a problem of the technology world is the lack of people with adequate teamwork and collaboration skills. I picked this particular podcast episode because I felt this would help anyone who reads. They talk about personal skills and practices that just makes one a better programmer in the industry. The main problem that occurs during team tasks is estimating how long a coding task will take. You want to please your boss and he also wants to please his boss so understanding each other and establishing that mutual trust makes it easy to work coherently in the task at hand. One challenge that most programming teams experience with their leaders is scope creeping. Scope creeping is a project management term that refers to changes, continuous or uncontrolled growth in a project’s scope, at any point after the project begins. This can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered harmful. This is because it causes problems and situations that are often not accounted for. Usually with every programming project, specifications are laid out and a timeline estimate is created for people to adhere to but once the scopes begin to change, unaccounted scenarios begin to happen. As a programmer, great communication between team members and leaders brings success to the project. This is because everyone has different level of expertise and often tasks and timelines are drawn based on the programmer’s expertise. Another thing that needs to be accounted for is vacations and sick absences. It’s the task of the programmer and team members to show commitment during tasks. You cannot take a 2 weeks or 1 week vacation when you know that the team is waiting for you to build the baseline site for people to continue developing on. This strings back to the trust issue. Efficient communications has to be open between members of teams to properly resolve issues such as these. Again communication thrives in teams when everyone is on the same level. Usually in teams, everyone has different background and finding that middle ground to communicate effectively helps the team thrive.

 

 

Source

https://player.fm/series/coding-blocks-software-and-web-programming-security-best-practices-microsoft-net/38-how-to-be-a-programmer-personal-and-team-skills

 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

Clean Architecture – Components and Component Cohesion

Episode 71

Coding blocks podcast is presented by Joe Zack, Michael outlaw and Allen Underwood. In this podcast episode, they squad begin by talking about components cohesions in architectural designs. Cohesion in software designing refers to the degree to which the elements inside a module belong together. In one sense, it is a measure of the strength of relationship between the methods and data of a class and some unifying purpose or concept served by that class. In another sense, it is a measure of the strength of relationship between the class’s methods and data themselves. Cohesion is an ordinal type of measurement and is usually classified under two categories, “high cohesion” or “low cohesion”. According to the team, there was a principal known as the fish bowl principal, this was employed in system building and architectural design for so many years. It was believed that the fish would eventually grow to fit the bowl it was placed in. But that has changed over time, with services like AWS and other cloud functionality, developing software of any size is easily manageable. Scalability is often handled by high performance systems that allocate resources to where is it needed most and vise versa when it’s not in demand. A big part of this new trend of software reuse is propelled by the open source project that currently runs the software industry. Building components or software in components also propels this new trend of code reuse. This is because in components, code is built to be self-dependent and sufficient to run on its own. It is viewed as a module that fits a part of the big puzzle. Testing for modules and components do not break the original code as it is tested as a single entity that interacts with the overall project. Another topic that gets discussed by the group is the common closure principal. The common closure principle consists of classes that change for the same reason and at the same time. This is similar to the single responsibility principle. This simply means that if the character of the class is changing, then the component is also gonna change. We need to make sure that the component is only changing for one reason only and if there is more than one reason, then there should be more than one component. Overall, this episode went very in-depth to technical practices and techniques that are used to develop components and architecture in software creation. This level of in-depth was a little too much for what we are studying but I felt it was necessary as it gets us thinking about how to build software in components and parts and start learning how to allocate functionalities to individual components.

 

Link – Episode 71

https://player.fm/series/coding-blocks-software-and-web-programming-security-best-practices-microsoft-net

https://en.wikipedia.org/wiki/Cohesion_(computer_science)#frb-inline

 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

Episode 33 —Testing in Data Science

In this week’s testing podcast episode, Brian explores testing in data science with the famous Katharine Jarmul. Katharine is a expert in data science and machine learning. She mainly uses python to write unite tests for her projects. I picked this podcast because after listening to this, I learned more about how to put together testing teams, how to manage and direct traffic in a testing team and how to be the driving force for success in the team. According to her, no matter how much we know as a team, with each testing project, we need to bring together all our resources and ideas. Testing often goes out of the scope of what is considered the norm. This is because in testing, we normally try to find the boundaries and limits if products and software. As a teacher and owner of a consulting company, Katharine often spends her days developing testing strategies that requires the implementation of new and modern testing technologies such as Integrating QA through agility and TCoE , Higher Automation Levels with a focus on security and Context driven testing.

 

Integrating QA through agility and TCoE

Though agile development teams have been around for a long time, agility in testing is still nascent. With the continuous pressure to quickly deliver software, businesses are investing time and money into setting up a TCoE with the objective of reducing CoQ, increasing test effectiveness and generating more ROI out of testing. From 2011 to 2014, the number of operational TCoEs has increased from 4% to 19% and is expected to increase further in the future.

 

Higher Automation Levels with a focus on security

System robustness and security has always been a top priority but with growth in social media and mobility and need for software that can be integrated to multiple platforms, systems are becoming more vulnerable. There is a pressing need to ensure enhanced security, particularly in applications handling sensitive data. This is causing QA to focus more on security testing.

 

Context driven testing

The challenge for businesses to maintain central hubs of hardware, middleware and test environments necessary to comprehensively test them has caused context driven testing to become more popular as it ensures more testing coverage from diverse angles. It is expected that this will impact skill development among testers, as there will be more demand for testers with exposure to different contexts.

 

Sources

https://testingpodcast.com/33-katharine-jarmul-testing-in-data-science/

http://www.cigniti.com/blog/top-7-trends-in-software-testing/

 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.