Category Archives: Week7

Dig Deeper Pattern

Over this spring break, and after the first sprint, I had the realization that although I was able to grasp a lot of things, I felt that I had only a surface level understanding of many things. For better or worse, being thrown into the deep end of a project like Thea’s Pantry has made me come to understand that, although I do know a bit, and I also know that there is plenty I don’t understand, there is still much, much to refine before I truly believe that I can be capable.

The Dig Deeper Pattern seems to reflect my ideas. The Dig Deeper pattern establishes that you should try to become even more intimate and familiar with whatever you are working with. If, like me, you run into the issue where you feel like you have learned a lot, but then when push comes to shove, you become lost, then you should try to dive even deeper into the concepts and code. As it stands, Thea’s Pantry is almost like a trial by fire, and though it is difficult at times, and I feel lost, it is also the perfect time for me to truly learn the ins and outs of a project like this. Not only would it be helpful, for obviously my grade, but having a firm understanding will allow me to use my experience in all kinds of projects for the future.

Although I am still a bit lost, I am hoping to really push myself after this break with a refreshed mind and a motivated focus to dive deep into the code and start expanding my knowledge to the best of my abilities. I would go as far as saying that it is crucial to dig deep! From my experience in other things, the more fully I understand something, the more I will be able to intuitively solve problems. Even if these are problems that I have never dealt with before, if I am capable of understanding how things work, I can slowly track the issue down to the source, and eliminate it there! At least… That’s the hope! So, wish me luck!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Breakable Toys Pattern

For my first blog post of the semester (Yeah, it’s a little late), I browsed over the various patterns and right away, the Breakable Toys pattern stuck out to me. Mainly, because the name was very intriguing but also straight forward. I had a feeling that it was the idea of creating projects or things that will allow you to step out of your comfort zone, and more importantly, allow you to mess up without repercussions, and I was just about right!
From my other interest, most notably in gaming, I have also come to a similar conclusion, that is is very important to learn from error and mistakes! Even before reading about the pattern, I had use my observations from gaming and applied it to programming and coding.

Specifically, I had made my own breakable toy! My project was rather simple, but it allowed me to work on things I have never worked on before. In pursuit of developing a web based rock, paper, scissor-like game, I created a safe space for me to expand my horizons, and though I could have easily done it during a different school project, I was much more capable of learning since I had no fear of negative consequences for going out of my comfort zone. I learned about HTML/CSS, node.js, and sockets, and since it was my own area, I had no fear about breaking things or taking the time to figure things out. I think I learned a lot from the experience, and the pattern is very very true.

If I had never taken the chance to make a breakable toy, I think my understanding would still be very limited to the things I learned in school, and though that is not a bad thing, the process of making a breakable toy taught me things that would never be normally taught. Or at least, I don’t think I was really taught it. The biggest thing I learned, on top of more familiarity with JavaScript, was the importance of documentation. During the project, I couldn’t just ask an instructor for how to do something, so I was forced to learn how to sift through documentation, which is invaluable.

Overall, though this is the first pattern I have dived deep into, I think that the breakable toy is something essential. Sometimes, you really do you have to mess up to learn, and I believe this to be true with not just coding, but everything in life!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

You ain’t going to need it? (YAGNI)

For this week, I browsed a few of the different design principles, and though many of them are incredibly relevant and important, one stuck out to me in particular!

YAGNI! You ain’t going to need it!

Now, someone might wonder why that stuck out to me? Well, it’s because of I often tend to have the thoughts to ‘future proof’ things! And, this is in direct contrast with YAGNI. Not only do I try to future proof things in coding, but I tend to do in in a variety of different fields.

Building a new computer? Let’s shell out a few extra dollars to make sure I can upgrade my storage in the future.
Making a new base in Minecraft? I’ll clear out this space so I have room to expand!
Buying groceries? Let’s just pick up this ingredient in case I might need it!

When has that helped me? Well, actually pretty often! But… In the grand scheme of things, the ratio is probably quite small. If I had to put a number to it, I’d say… It’s probably…

1/10

Potentially even less! So why the heck am I still stuck with this idea of future proofing! No idea! But anyways, to get back on topic, YAGNI seemed useful in not just my coding, but everywhere, so I started to look more into it! In my search for a grander understanding, I discovered this post by Martin Fowler. And boy, oh boy, did Martin teach me a lot of things!

Firstly, it makes sense! The concept of future proofing, or preparing for something that you will eventually need seems sound, right? But, things change! Especially when it comes to specifications and needs. Things might seem set in stone one day, but in the next, something might have changed and the requirements become different! Any and all investment and work you put into that ‘feature’ will be wasted, so don’t think about it until you need it!

In my own cases, I can definitely say if I just had a more YAGNI approach, I’d save myself countless hours and at least a small pile of money! Plans are plans are a reason! Just because I think I’ll want it later, doesn’t mean I’ll actually want it when the time comes!

That computer I future proofed? Never did it!
That space I cleared out for an expansion in Minecraft? Never expanded it!
That one ingredient I picked up? Never used it!

These have just been my experiences, but I am certain that at least some people can understand where I’m coming from. It really does seem to make sense to prepare for the future, right? But if you’re really preparing for the future, you better make sure you absolutely are going to use it! This is certainly a lot easier for real life things, but when it comes to coding and meeting specifications, that is just so much harder! You probably have about the same chance of looking into a crystal ball and reading your own future as you do thinking a feature will be needed! So…

Don’t do it! You ain’t going to need it!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Anti-Patterns

Anti-patterns are patterns in software development that are considered bad programming practices. The exact definition is “An Anti-pattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences.” More understandably put, an anti-pattern is a way of not solving a problem. Anti-Patterns are said to be the opposite of Design Patterns, for instance, with Design Patterns, users usually start with a well-defined problem and identify the best path to take to the solution, whereas with Anti-Patterns, they begin with a failed solution, which can be challenging and usually further complicate matters.
(http://antipatterns.com/EdJs_Paper/Antipatterns.html)

I found a video online that I found easy to follow along to by Andy Sterkowitz on 5 programming anti-patterns that was specifically geared towards beginners. The first anti-pattern he spoke about was ambiguous naming; ambiguous naming of variables, functions and classes. He explains that when you’re writing code, your variables should be well named, to make your ( or another’s) comprehension of your code easy. He suggests really thinking about what you’re planning on naming things within your code to simplify things. The second anti-pattern he spoke about was magic strings and numbers.
Example:

if (age > 21) {
// do something
}
By the context of this, obviously you’d be checking for the legal age.. but you can’t assume that this information is known.

The third anti-pattern is called lava flow. He compared this anti-pattern to how lava flows continuously and hardens along the way, saying that as a programmer early on, you think you’re just creating all these small little apps you might need but you’re actually making parts of your application warped or hard to develop. He suggests to use Git to modify and make changes to your code instead of building a whole bunch of different sections. The fourth anti-pattern he talked about was cut and paste. What that means, he says, is when you see a code and there are ten or so different functions that all just say the same thing basically. He suggests to instead make one function that does everything or even one class. Doing this will save you time from having to go back through each and every function and modify one thing. The fifth anti-pattern he talked about is called the poltergeist pattern. Andy explained that this is basically just code that doesn’t serve a true purpose, like a class that just calls upon another class.

Through this video, I learned that the best way to write code is to not have a lot of code and to really make sure you have strict guidelines about when it is appropriate to make a new class, method or function. Andy gave a lot of useful and helpful tips on how to improve my coding skills and what common mistakes I should avoid doing in the future. He used easy to grasp and very relatable metaphors and comparisons to real life that made understanding his explanations of the patterns easy and interesting. While watching this video I had quite a few “wow, that’s really helpful.” moments and I realized there are a few things I should and will be changing from here on out to tidy up my code.

Video used for this entry:
https://www.youtube.com/watch?v=lQ_rGCL17EE

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

The Deep End

Hi dear readers. In this blog post I am going to write about the next Apprenticeship Pattern called ‘The Deep End’. I am sure all of you are wondering now what does that mean?!

This new Pattern talks about how to be able to realize if you can take over different kinds of projects and realize where do you stand in terms of your knowledge and career.

For a lot of developers there comes a phase in the career where you start thinking about how are you doing and where do you stand. Questions like: have I achieved enough, am I in the right position, should I move to another company, is my portfolio where it should be, etc, cross your mind.  I liked the expression the authors used: “Waiting until you’re ready can become a recipe for never doing a thing”. I totally agree with this expression as I personally think you can never be fully ready for any type of job. There are always new things to learn and new technology coming out.

Two years of experience with my company and I have been a witness of people asking these questions to themselves and moving on and out of the company because they didn’t feel right anymore, they did’t see space for growing and said it was hurting the career. Every move you take it has its own risks, some bigger than others but always present. I personally think that risks shouldn’t just be avoided but should really be considered. Moving out of the company you are working or taking over big projects that you know that you can’t handle can fail your career. I believe this is big enough reason to hold back and really think about  this new step you are about to take.

Always challenge yourself with different  bigger and bigger projects, but don’t just climb 5 stairs at a time. ‘You can fall and seriously get injured.’ I like the author’s suggestion about making a list of your all achievements, projects and skills you are at. This list will definitely show you were you stand and give you a better idea on what your next step should be.

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

Apprenticeship Pattern Blog: Find Mentors

Hello and welcome back to benderson’s blog! This week are going to discuss another apprenticeship pattern from the Apprenticeship Pattern book that my classmates and I have been reading and taking notes from. The pattern that I would like to discuss today is “Find Mentors”, which is a kind of a self-explanatory pattern. It follows the rule of “If you hit a roadblock and need help, ask some to be there apprentice and work under them and learn from them”. You’re not a master at the craft yet and at some points you don’t know what to do next, one of the best things you can do is find someone that has already gone through the process and you can ask them questions on what they did and how you should approach your future. I have a friend actually that graduated from Worcester State with a Computer Science degree, where I plan to graduate this coming May and also graduate with a Computer Science degree, and I asked him a bunch of questions regarding what he did after graduating and what are the steps I should take so I can get a well paying job and be able to be successful for the coming years. He gave me some pointers and what I should know for interviews and stuff so he was very helpful in that sense, still finding internships and job opportunities will be a challenge in them selves but I will cross that bridge when they come.

The pattern itself wasn’t really thought provoking because as I said earlier, finding a mentor is kind of self-explanatory. You got there, find someone you consider to be really good at the craft and you ask them if you could learn from them if you aren’t too intimidated by them. If you’re too intimidated by them, just ask them out to lunch or something and generate questions to find out what you can do to better yourself in the craft. This pattern could honestly be used for many different subjects such as business, teaching or being a doctor. All those jobs have people learning under people that have already mastered the craft and are willing to teach them so they can succeed them when they retire. The pattern has not caused me to change the way I think about my major as I know one day, I will have to find a job such as an internship and learn from my experiences there, hopefully from someone really good at computer science and willing to share information with me. Finding a mentor is just one step in the journey to becoming one of the best computer scientists out there as to become the best, you have to learn from the best. Thank you for joining me this week on benderson’s blog!

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.

Post #5: The Difference between Integration and Unit Testing

Hello and welcome back to Benderson’s blog where we talked about computer science related topics. This week I’m pulling a blog posted by STC Admin at Software Testing Class where it discusses the difference between Integration and Unit Testing. The author begins with an analogy where he talks about a Personal Computer with all it’s separate parts and how they all work together but in order for them to see if they will work together, you must do a compatibility test after the integration test. Then it goes into a system test and lastly an acceptance test. This leads into his next paragraph where he discusses how a software application is developed where it goes through the same type of tests that a Personal Computer would go through. The author even has a neat little diagram in the blog showing you a flow chart of how the testing goes. Then the author goes into each of the individual testing that he talked about before: Unit testing, Integration testing, System testing and Acceptance testing. Giving a brief explanation on what each of them do. The next paragraph talks about the advantages of system testing and lastly the differences between Unit Testing and Integration testing to wrap up the blog.

I chose this blog to discuss this week because it has a lot of information jam packed in there about two types of testing that I had little knowledge about. After reading the blog, I like to think I gained a decent amount of knowledge on the topic. Like for example, now I know the order of the system testing approach which begins with unit testing and ends with acceptance testing. I even learned the importance of each of the parts of testing like with unit testing I learned it is also known as white box testing that is carried out by the developer or with System testing it is known as black box testing which tests the overall functionality of the system. I also learned some reasons why it is advantageous to some system testing such mitigating after production go live issues and defects. Lastly, I learned the difference between the Integration and Unit testing such as one is white box and the other is black box, one surfaces from interface specifications and the other is from module specifications and lastly one is conducted by testers and the other is conducted by developers. This blog was very interesting and was a great read.

Link: https://wordpress.com/read/feeds/39452620/posts/2017866494

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.

Pattern : The Long Road

Chapter 3. Walking the Long Road

In this chapter, Adewale Oshineye and Dave Hoover bring light to the life long journey of becoming a master in programming. One cannot expect to become a great programmer after a specific number of years because the concept of mastery in it self is subjective in programing. Its subjective because the better you get, the more you begin to understand how much you actually don’t know.

The author begins by acknowledging the fact that being exceptional in your group just means you need to find new competing and other sources of motivation because like everything in life, there is always someone who will be better at it than you. I agree with the author when it comes to the longitivtiy of programing. I have always known and understood that there will never be a time where i didn’t have anything else to learn in programing, in-fact after taking the software testing class, i realized that far beyond great programing skills is a whole plethora of development that deals with software testing and designing softwares that can be properly tested. The concept of mastery in programing should be facetiously understood as a hoax because no such thing exists. Everyday new technology emerges and with each new technology comes new knowledge and techniques that needs to be learned and implemented. So you can be a very familiar with something today but tomorrows technology will bounce you down from you mastery pedestal. The key to staying relevant is to dedicate yourself to a lifetime of learning and with each step, grow a more yearning character that is always ready to receive and learn new things.

Finally, there was a section in the reading that i don’t think i fully agreed with. It talked about passing up new opportunities to move up into management and elaborated on staying in your path to maximize growth but i disagree with this. There is a saying that goes like “in the land of the blind, the one eyed man is the king”. I don’t understand how it makes sense for a dedicated apprentice programmer to pass up an opportunity to oversee and mentor other programmers just so someone else who is trying to exit the programing world ,take the position to criticize and give instructions on how code should be written. 

 

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.

Sprint 2

Team Retrospective – Sprint 2

I think this was another important sprint. Most of my group members were all new to the technology we are learning so this sprint kind of gave us an opportunity to read more about the programs api’s and how they worked and functioned. We also had a few tasks that could not be completed in the first sprint so we carried them over. For the first sprint we were to complete building the application and setting up the environment.  Some of our members were also able to connect the application to the server but that was officially a task of sprint number 2. After reading many documentations, we all connect to the server this sprint. Some of the other tasks that we were also to accomplished this sprint included checking out balsamiq and coming up with design ideas to implement. The design idea was no simple task because almost everything we thought of was too abstract for our current knowledge or not enough to contribute to the current repo so after sometime of going back and forth with ideas, we realized that on our Trello board, we had various tasks and features that were advertised and needed to be built and implemented in the application. After much discussions, we as a team were able to agree on one task that we felt could be accomplished and completed by us based on our current knowledge as a team. we picked the “offline login and Offline data storage” as the task we wanted to get done. Personally, i have not created any “login” applications but i believe i have the skills and capacity to learn all that i would need in order to be able to contribute my share to the team. After deciding to go this route , we realized that we needed help from other teams depending on what they had selected as their tasks to complete. Since we wanted to do the users offline sign in and data storage, we needed to store the user’s passwords and usernames locally on the device that will be accessed. But since log in credentials are sensitive and needs to be secured, we realized that we needed to implement a decoding and encoding encryption system. This way, all data saved on  the local system could not be accessed by anyone who would come in contact with it. Again the patients data would also have to model the same architectural pattern because patients information are private and thereby needs to be kept safe and secure also. With all these thoughts and approaches in mind, we reached out to a team that was next to us and luckily, they agreed to handle the encryption and decryption side of the design. This brought us to an ease because  it split up the overall tasks that needed to be completed by us but on the flip side, it puts a dependency on their team. We would have to know how the encryption works so that we can code to implement it.  This to some extent makes me worry a little bit because it almost seems as though if the other team encounters issues they are not able to resolve, we will be stuck but again, i know we can use dummy variables to get at least the concept aspect completed. Looking forward to the new sprint. !

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.

AB Testing – Episode 3

 

 

-In this weeks testing episode, Brent and Allen brings new light to the careers in software development with a focus on testing. It seemed that most graduates have developing as their first option and when they cannot do that, they want to fall back to software program management and if all fails, they settle for being a tester. The fact of the matter is that people don’t value the career of testing. But if you are able to be a good tester, you build the skills required to make a great developer. Usually testers have to manager programs and create tests around that schedule. Again students who study big data learn great and valuable skills that are applied in the field of testing. Things such as reading maps, graphs, making analysis and analyzing data input and outputs are all skills that helps make one a great tester.

So why aren’t many students becoming software tester?

Brent and Allen took a survey from a selected number of student and they found out that schools are not teaching testing classes. This could be the reason why many students don’t find value in studying software testing. It is often believe that testing is embedded in software development but the sooner we demystify this the better!. It is been proven that writing tests strategies and plans before writing code often help speed up the software building process. This is because knowing what you code is suppose to do makes it easier to create code to do what its suppose to do. Now how can

 

We use metrics and Data analysis to improve testing?

Data analysis often provides detailed information about page load time, memory usage charts and load balancing metrics. This data allows a tester to identify potential bugs and issues that need to be addressed before the release of a software product. By managing and properly observing the metrics that matter, we are able to produce better data that directly affect the performance of the software. By implementing proper metric techniques, companies and software companies are able to relate marketing to performance and user feedback. By use of metric, Amazon is able to know how much a delay of 1 millisecond affects them in annual revenue. By getting information such as these, companies are able to proper manager their markets and are able to know what their customers expect of them.

 

 

LINK

https://testingpodcast.com/?powerpress_pinw=4534-podcast

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.