For this week, I have finished up Sprint 2 and I would glad to be talking about it.
What I wish I could done throughout this sprint was to finding
Links:
From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.
For this week, I have finished up Sprint 1 and I would glad to be talking about it.
What I wish I could done throughout this sprint was to know what was figuring out my laptop
Link:
From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.
For this week, I have decided to read also “Why Doctors Hate Their Computers” by Atul Gawande. The reason I have chosen to read is because in the world we live in now, we have people that are struggling with the changes towards their job aspects and having to deal with problems that are rather unfavorable to an extent. I believe this article will help me understand from a perspective in making sure the problem is clear and finding out what is the real source of it.
What I think is useful from this article is that the perspective can give a similar scenario that which people can relate to learning and end up become frustrated. So let us say that we have a task that is completely new to our workload and it turns out it is in an another language. It is true that we have just to get some help to translate them, but what if it is another language you must learn prior to that? This is the same from this article when it comes to doctors forced to work with unfriendly software.
What I think is harder from the system is the EMR being reliable with good physician input. Learning what medication to give is easy with enough practice and knowing it is. But getting the records needed is very difficult considering it is just a faxed report. The real customers for this system would be those who need of accommodations. This is because as a community, we tend to have options like sending by email instead of verbally, doing things by paper, giving checklists.
The lessons in this article not only applied to the Electronic Medical Records System but also to all technology that requires records. With the lessons, they should make sure that with whatever technology gives the records as requested instead of being just a general report as part of the system. From reading most of the article, I will say it has definitely changed my way of thinking to the medical record system in hospitals. In the past, I usually think it would be on point with learning what medicine to take and what conditions patients would have but now from this perspective, I can understand why doctors would be frustrated in the updating technology to find records needed.
What I think from this article I will disagree is the purpose of EMR being the best thing to turn to for the sake of getting records. I believe that the EMR is meant for billing instead of medical records since it does feel like it takes the amount of time in seeing the patients, which is important. It could be also medical errors that can lead to false information by the responses the patient gives when diagnosed. For this reading overall, I will say this is a good read in learning the perspective of doctors with technology. This one I believe can be difficult at first to get used to since it is from a perspective, but it provides information that relates to technology that constantly change across.
Link to the blog: https://www.newyorker.com/magazine/2018/11/12/why-doctors-hate-their-computers
From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.
For this week, I have decided to read “Concrete Skills” pattern from the Apprentice Patterns by Adevele Oshineye and Dave Hoover. I have chosen this one since it is a good refresher for understanding that knowledge known is not the same. I believe this will help me in making so that I can be sure to give more demonstration than telling by just writing it out.
This pattern starts with the context of seeking out a role in a group of talented people that will provide better learning opportunities than currently. The problem is that the team, when asked, they can not risk of bringing someone that would not be able to contribute for the intended workload. There is also when thinking further, the possibility of not being able to do even the simplest task when asked. The solution to that problem is concrete skills, acquiring and maintaining them. With these skills, demonstrating and having them will increase the possibility of being trustworthy and be able to reach the goals. Eventually, there will be less dependent on these set of skills as the possibilities increase in being hired for the jobs intended.
From this pattern, what I found useful is the listing for concrete skills as an example to give the point of giving trust to the employer. As we try to give a good impression and trust for the likes of employers, we want to be sure that we at least have a clear understanding and demonstration of the basic things to do like JavaScript and the standard libraries by choice for computing jobs. Skills may require more thoughts to give an even better impression than intended, but it does answer questions to which the employer may ask. This pattern has changed my way of thinking in my profession. As I read the short pattern, it has become clear to me that I should not only directly say as intended but also if needed, demonstrate what I can do even if it is the basic thing. For this pattern overall, there is nothing I don’t disagree upon and this is because the pattern was able to give good perspectives of knowing what to do with this concept.
Based on the content of this pattern, I will say this is a simple but effective one. This pattern has showed good examples of the real-life scenarios. It allows me to be aware in the future of demonstrating than telling by just paper. For practice, I will show some technical work to give good impressions.
Link to the pattern: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch02s04.html
From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.
For this week, I have been tasked to read Apprenticeship Patterns written by Adewale Oshineye and Dave Hoover. What I read from the book was the whole chapter 1 and the introductions of chapter 2-6. They were pleasant to read and they taught a lot of things greatly. Each of the chapters starts with a general scenario that speaks to the subjects discussed.
What I find useful from reading this book are the general advices we usually hear in life that have been rephrased and it works effectively. These advices really helped my perspective of what to do with multiple languages for my career like for example, finding the time to have a moment of reflection. In some time, when there is a point we feel really stuck in our path, maybe it’s time to step back and reflect on what we can do with the languages we gave effort towards. Reflecting might bring new light to which what you want to pursue next and sure, it can be longer to reach goals from it. But the more we learn, the more potentials we will be able to show to others and ourselves.
Reading this book has changed of how I will now work towards my career. Not only I will try to continue on improving the languages I already know from classes and on my own, but also I will find what languages that are new to me and explore what potentials it can bring if I desire it. I don’t disagree with any of the chapters I had to read. This is because they expressed the scenarios and questions that were simple but well thought out in a sense.
To me, the most relevant chapters would be Chapter 3: Walking the Long Road and Chapter 4: Accurate Self-Assessment. For chapter 3, it definitely gives an understandable perspective when it comes to pursuing a career in the world of technology. It is true that awards or certificates show that you come far to make a good starting point. But this is only one of the things you can show easily and it’s not everything you can do just by having it. What we want to do is not only appreciate in doing the steps like training but also continue the journey of the path we chose to walk on. When it comes to Chapter 4, it reminds me of how I tell myself thus far to get where I am today. There is nothing wrong with saying that we want to be better. But comparing ourselves to others, it won’t make a difference unless we put the efforts in and shape our own abilities. What matters is that we show we can improve and become who we want to be.
Link to the book: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/#toc-start
From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.
Hello my name is Dennis Tran. This is my blog for CS-448. Here is my blog for this class and I look forward to an interesting spring semester.
From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.
So for this week, I have decided to read “Introduction to Continuous Integration Testing” from the TestLodge blog. The reason I have chosen to read this is because it is crucial to know the concepts of Continuous Integration and how this practice provides flexibility to development teams. It will help in understanding the workflow and why it helps developers to develop software that is cohesive even at the shortest amount of time.
This blog post goes over what is Continuous Integration, the advantages from it, and concepts before embarking Continuous Integration. Continuous Integration is an approach within software development in which the developer pushes code into a respiratory, such as Git, several times daily during the development phase. There are tools available that developers can use to set up Continuous Integration. They can be both licensed and open source and by using them, simultaneous builds can be run on multiple platforms. Once they are initiated, solutions can be built, run unit as well as functional tests, and automatically deploy to the application worked on to a server. There are some benefits such as ensuring full integrity across code and build before deployment and simple setup and configuration. These tools consist mainly of a build server and build agents. To name a few from the automatic build process, there is the Build Server, Build Configuration, Build Source path, and Build step. Depending on the requirements and size of budget available to the development team, the favoring between open source and license will go in many ways.
What I think is intriguing about this blog is that it goes out of its way to explain the automatic build parts. Usually when it comes to Continuous Integration, there would be some difficulty to have the concepts down at first before making the automatic testing. I do understand that automation does play a critical part in the process, which is why it is appreciated to have the concepts down when explaining it to others. The content of this blog has changed my way of thinking with this practice.
Based on this content of this blog, I would say this blog is a great read to understand the general ideas of Continuous Integration. I do not disagree with this content of this blog since it gives an understanding of the goals in continuous testing. For future practice, I shall try to perform load tests for projects that require response time. That way, finding code or bugs can be much faster to do.
Link to the blog: https://blog.testlodge.com/continuous-integration-testing/
From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.
For this week, I have decided to read “Black box, grey box, white box testing: what differences?” from the NBS System blog. The reason I have chosen to read about this is because while I do understand the basics of what each box does, I have the need to find out more about the benefits and the perspectives of using them. I believe this will help in understanding the purposes of utilizing each one and why do some tend to use them for a certain amount of time.
This blog basically goes over as the title implies what do the boxes do and what do they offer for possibilities. Black box consists of reviewing only the functionalities of an application or rather what it does it is what is supposed to, no matter how it does it. The user needs to know what the role of the system is and its functionalities but does not need to know its inner mechanisms. For white box, it consists in reviewing the functioning of an application and its internal structure. All of the internal components of the software or application are tested through the source code, which is the main work base of the user. Grey box testing complies both of the previous approaches: testing both of the functionalities and functioning of a website. This means that a tester gives an input to the system, checks to see if the result is the expected one, and checks through which process the result was obtained from. It is vital with these kind of tests to make sure the product is complete, secure and efficient.
What I think is useful about this blog is that it provides the benefits and drawbacks for each box like for black box, it has simplicity and redundancy listed down and gives an explanation based on it. There is also the example of penetration testing to give an understanding of each box in a real-life situation. From this blog, it goes from the general definition to the boxes, explaining how the boxes works from one perspective to the next, benefits and drawbacks of the boxes, and finally a penetrating testing example.
Based on the content of this blog, I would say that this blog is a good introduction to knowing the boxes in concept. I do not disagree with this content since it does try to give readers the information needed and provide great examples to get a clear understanding overall. For future practice, I shall try to get familiar with the examples the blog uses for the boxes in real-life situations.
Link to the blog: https://www.nbs-system.com/en/blog/black-box-grey-box-white-box-testing-what-differences/
From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.
For this week, I have decided to read “Differences between the different levels of testing” from the ReqTest blog. The reason I have chosen to read this blog is because it is crucial to understand the basis for each testing level. It will help in understanding the system process in terms of test levels even if it is short and simple.
This blog post basically goes over the four recognized levels of testing. They are unit or component testing, integration testing, system testing, and acceptance testing. Unit or component testing is the most basic type of testing and is performed at the earliest stages of the development process. It aims to verify each part of the software by isolating it and then perform tests for each component. Integration testing is testing that aims to test different parts of the system to access it if they work correctly together. It can be adopted as a bottom up or top down method based on the module. System testing is testing all components of the software to ensure the overall product meets the requirements specified. It is a very important step in the process as the software is almost done and need confirmation. Acceptance testing is the level of testing whether a product is all set or not. It aims to evaluate whether the system compiles with the end-user requirements and if it is ready to be deployed. These four types of testing should not only be a hierarchy but also as a sequence for the development process. From all these testing levels that show the development process, testing early and testing frequently is well worth the effort.
What I think is interesting from this blog is the simplicity of explaining each testing level. Each testing level in the blog has a small definition in what they suppose to do, when they are used, and an example in the process. This content has changed the way I think it would work by giving the explanations in a format that is not too complicated to follow.
Based on the contents of this blog, I would say that this blog is short and very easy to understand. I do not disagree with the content given by this blog because the ideas given for the testing levels do connect for the development process. For future practice, I shall try to adopt a mind of constant alertness to my projects with these four levels. That way, I can be more aware for detecting software errors.
Link to the blog: https://reqtest.com/testing-blog/differences-between-the-different-levels-of-tests/
From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.
So for this week, I have decided to read about “Behavioral-Driven Development” from the Future Processing blog. The reason I have chosen this blog is because usually I hear this development does help with the established practices of Test-Driven Development and make it more accessible and effective. This will help me understand why some have suggested in using this development and see the problems with it that make it difficult to give even an introduction.
For this blog post, it goes over the motivations of introducing Behavioral-Driven Development, why to use it, and the typical problems with it. With the motivations listed, there is public distress, test automation, and better Test-Driven Development. Public distress is from those who want it to be introduced for the sake of introducing it, teat automation is from wanting to automate tests which the development does not require automation, and better test-driven development is from that the development is only understood as a higher layer of requirements. There are many reasons listed in why this development should be used but the main thing is it is a communication tool. This tool for the main reasons listed can help to answer the question of how the problem will be solved, clarifies when we consider that the program solves our problem, and discovers what should happen when an unusual scenario comes. When it comes to typical problems with this development, there are incomprehensible scenarios such as no explicit dictionary, these scenarios becoming an unnecessary overhead, and the use of it in teams. In conclusion, ideological use of this development is demanding and difficult. But it is always worth trying and adapting technics like this communication tool and it might lead to the right software for the needs of a client.
What I think is useful about this blog is it goes all the way to express this development as a communication tool. From this blog, it goes over the way how this development introduced generally, gives lists of the uses of the development and the problems with it, and even has a scenario to show how it works with further explanation. The content of this blog has definitely change my way of thinking with this development.
Based on the content of this blog, I would say that this blog is a little difficult to understand at first if you don’t know about Test-Driven Development. However, I don’t disagree with any of this content because it clarifies some things about Behavioral-Driven Development such as understanding the perspective of a user with this development. For future practice, I will try to use this development with a given when and then template.
Link to the blog: https://www.future-processing.pl/blog/behaviour-driven-development/
From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.