Category Archives: Week7

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

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…


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 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.

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.

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:

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.


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.




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.

Coding Blocks – Source Control- Episode 3



In this episode of coding blocks Allen Underwood, Michael Outlaw, Joe Zack addressed an issue in software construction that often makes or break a project/Team. Source control and management. I personally found this topic very crucial because of a programming project I was able to contribute to with a couple of my friends. Initially, we were just using Google drive to update and track project chances but as many newer version were created, it became a mess to try and track which update did what and how stable is that version. We eventually resulted to utilizing Gitlab. It was here that I found the importance of source control team working. We were able to section of parts of the project and distribute among ourselves also, it was easy to modify and make changes because we always know a Standard version of the project existed should we break the original pull. In this podcast episode, the authors made known of another major reason why implementing source control was effective. By implementing source control, many branches be worked on at the same time. This way, problems and bugs can be resolved and fixed faster. Also construction was made a little easy as people could work independently on building various parts of the software. Again by pushing after every working build, the programmer is able to leave a stable version with an attached commit message which help the next person to touch the code understand what that build accomplishes or does.

Best Practice Tip: Ensure that you only push back working code that passed the compilation test.

Another topic the authors addressed was the issue of missing path that often occurs with source control software development. They made emphasis that having a consistent naming convention is recommended for best practices because some programs and software requires you to switch between operating system and since that means different file systems, having a standard naming convention for packages and file paths makes it easier on who ever works on the program to make edits and changes as needed.

         While addressing source control, another major topic to talk about is pull requests. It serves as another layer of verification and “code review”. Having push requests allows you to submit to a specific branch and get you work evaluated before pushing back to the main repository. This way leaders and managers can verify that code written is correct and fits the required standards and specifications.



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.

Blog 7: Error reserving enough space for object heap in Java response

In today’s blog, I read the blog by Java2Blog which is a blog about java problems and other java frameworks and techniques. This post by them talks about how you could get an error for not reserving enough space for an object heap in Java.

First they go over a cause of this error, obviously though the first cause is that you ran your Java program without specifying a heap size which will cause you to get an error. The error would say something along the lines of “Could not reserve enough space for object heap”. The blog also tells you that you will encounter this error more in 32 bit JVM (meaning Java Virtual Machine) than in 64 bit JVM. The blog goes over the reason of this error which is 32-bit Java needs contiguous free space in memory to run the program. Then the fix for this problem is by running Java with a lower heap size and then it gives you a line of code you could use.

The next cause of error is specifying too large memory with -Xmx option on 32-bit VM. The fix for this issue is just lowering the heap size with a single line of code said in the blog. Lastly, the last cause of this error is if you specify a large heap size more than physical memory available on either 64-bit or 32-bit. The way you fix this problem is by again running a single line of code provided in the blog post which I will leave a link to at the bottom for you to check out. The last part of the blog covers certain fixes for Linux and Windows and just a conclusion of the whole thing.

The reason I choose this blog is not only because it relates to Java programming but that it also may come up in my future while I’m working in computer science, who knows that if I’m in IT somewhere in the future or some other computer job that has this problem and I’m one of the only people to know how to fix it. That would probably get me a lot of brownie points at my job which is really nice. Also this blog was well written and straight to its point. Gives you three causes for a problem and gives you the solution to each of them which is really helpful to understand. Java is a very vast programming language and remembering everything about it is hard so getting little reminders of how everything works is always nice. They aren’t joking when they say “Java programming language” because it really is like a whole other language and so is the other programming languages, you got to know every little thing about them or you screw up and everything is wrong. That is my little sidetrack on programming languages but back to the blog, I remember hearing about heaps in my intro. to programming class freshman year and I think we did a little thing with them but not much but hey, the more you know can’t hurt when it comes to programming. Thank you for reading this weeks programming talk with me, come back next week for more.


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