Category Archives: Week 6

Apprenticeship Patterns – Craft over Art

The pattern Craft over Art in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye discusses the opposite approaches one can take when writing software…

On one end of the spectrum there is practicality. This would be considered the “craft” portion of this apprenticeship pattern [AP]. The best way I can describe this side of the spectrum is with the idiom “don’t reinvent the wheel”. If a solution is already there, don’t go out of your way to rewrite it. Why would you waist your time? If there is no currently solution, then find the quickest and most efficient way possible that solves the problems and meets the customer’s demands [AP]. Don’t go above and beyond.

On the other end of the spectrum is the “art” portion of this pattern [AP]. This means that your solution should be beautiful and elegant [AP]. It should be a master piece [AP]. The tradeoff here is that creating masterpieces takes both time and money. Although the pattern seems to lean towards favoring the “art” side of things, it does suggest that there are times where you’ll have to find a middle groud between the two [AP].

I’ve mentioned this in the past and I’ll mention it again. If you truly want to be a master software developer, then I feel the advice this pattern gives is worth taking. However, in most cases, following this pattern doesn’t seem realistic. Companies have goals and deadlines that need to be meet. They aren’t going to want you to take a week to complete a task that can be done in a day just so you can make it perfect. Time is expensive, so if you can meet the customers demand in a day rather than a week then they are going to expect you to do so.

The pattern also notes how one should be wary about making something beautiful, yet useless [AP]. If you are going to take weeks to perfect something in which a valid solution could be developed in a few days you better be darn sure it is going to work [AP]. This is something that I agree with. Creating something that is useless isn’t craftsmanship or art. It is a waist of time.

Form an overall perspective I get what both this pattern and book are trying to preach. This pattern is great advice if you can find a place that will let you follow these practices. It just doesn’t seem practical. If you are given the opportunity to actually follow these guidelines I say go for it. I just don’t see it as being realistic for most people in most situations.

 

Link to pattern in book: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch03s02.html

 

 

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

The One Thing All Newcomers Can Offer: Enthusiasm

The one thing that just about any recent college graduate has to offer a prospective employer is enthusiasm. While enthusiasm may help with getting in the door somewhere, once starting out on a new team of experienced developers the newcomer may be less willing to express that same enthusiasm. Although it may sound juvenile, the desire to fit in applies just as much in the workplace. This desire may prevent a newcomer from sharing valuable excitement and new perspectives with the team. Overcoming this fear of and sharing your excitement and creative ideas will be far more beneficial in increasing learning and value throughout your apprenticeship. In Apprenticeship Patterns, Hoover and Oshineye cover this topic under the Unleash Your Enthusiasm pattern.

If there is one thing that I am sure about, it is my desire to make a real difference through software development. I am passionate about making a difference and excited to begin this journey. I will admit, however, that I would be a bit hesitant to express this eagerness if other members of the team seemed to be skeptical of me. It would be far easier to take the conservative approach and try to match the excitement level of the team. Taking this approach is not the most effective strategy in these situations. It would be far more valuable to both the team and to the apprentice to fully embrace that enthusiasm and use it to inspire and motivate the team. Rather than viewing your excitement as an annoyance to the team, you should view it as an asset that will help the team.

When first starting out, it may be difficult to find ways to make any meaningful contributions to the team. You will need to earn the trust of the team before taking on risky tasks that may jeopardize the integrity of the work as a whole. One way to make contributions while also gaining the respect and trust of the team is to ask questions and unleash your enthusiasm. If you’ve found the right mentor, your enthusiasm for the craft of software development will be rewarded. This mentor will guide you, and you will give him or her a renewed excitement for the craft.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Find Mentors

Problem

You’re walking along a path with no idea of what’s around the next corner or how to prepare for it. You need help and guidance.

The solution the book offers is to seek out those who have gone ahead of you and strive to learn from them. Since our field is fairly young, it can be difficult to find someone who is truly a master craftsman. More than likely you will get support from a series a mentors with varying degrees of mastery. Help can come in many forms, you can get help one-to-one with someone or remotely via the internet. While an apprentice is trying to find mentors, we must remember we are all walking “The Long Road” and no one knows everything. More problems you might have is finding a mentor who in interested in mentoring or who isn’t intimidated by the task of being responsible for another persons learning. It may seem risky to ask someone for help and fear rejection but the payoff is worth it if your offer is accepted. Just as people will be ahead of you, there will also be people who are behind you. You are also tasked with finding those who you may offer to help with information you’ve learned. Passing along what you’ve learned in one of the ways you can being the transition into journeymen status.

I think it’s super important to find someone or a group of people to ask to pass on what they know about the current state of our field. I think work is a great place to meet people that can offer you their skills and knowledge, especially because you will be building relationships with these people and seeing them every day. The text advises picking a tool, library, or community that has an active mailing list and learning the values of the community. Learn who the teachers are and seek out those who may be interested in offering help, I would consider this a great idea. I think sharing what we’ve learned if very important, it helps everybody, it helps the world. I would be super grateful for anybody who’s willing to take the time to share what they’ve learned and I know some people enjoy sharing their knowledge and would be flattered if someone asked for their help.

The post Find Mentors appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

Angularjs

I chose this topic because we will be using it for projects. Wanted to know more about it, get some trick and also share it among the pupils. Also i have come to notice most companies in the web development require a potential employee to have this kind of programming language. At least an understanding of it.

AngularJS is a structural framework for dynamic web apps. It lets you use HTML as your template language and lets you extend HTML’s syntax to express your application’s components clearly and succinctly. AngularJS’s data binding and dependency injection eliminate much of the code you would otherwise have to write. And it all happens within the browser, making it an ideal partner with any server technology.

AngularJS is what HTML would have been, had it been designed for applications. HTML is a great declarative language for static documents. It does not contain much in the way of creating applications, and as a result building web applications is an exercise in what do I have to do to trick the browser into doing what I want?

The impedance mismatch between dynamic applications and static documents is often solved with:

  • a library – a collection of functions which are useful when writing web apps. Your code is in charge and it calls into the library when it sees fit. E.g., jQuery.
  • frameworks – a particular implementation of a web application, where your code fills in the details. The framework is in charge and it calls into your code when it needs something app specific. E.g., durandal, ember, etc.

AngularJS takes another approach. It attempts to minimize the impedance mismatch between document centric HTML and what an application needs by creating new HTML constructs. AngularJS teaches the browser new syntax through a construct we call directives. Examples include:

  • Data binding, as in {{}}.
  • DOM control structures for repeating, showing and hiding DOM fragments.
  • Support for forms and form validation.
  • Attaching new behavior to DOM elements, such as DOM event handling.
  • Grouping of HTML into reusable components.

A complete client-side solution

AngularJS is not a single piece in the overall puzzle of building the client-side of a web application. It handles all of the DOM and AJAX glue code you once wrote by hand and puts it in a well-defined structure. This makes AngularJS opinionated about how a CRUD (Create, Read, Update, Delete) application should be built. But while it is opinionated, it also tries to make sure that its opinion is just a starting point you can easily change. AngularJS comes with the following out-of-the-box:

  • Everything you need to build a CRUD app in a cohesive set: Data-binding, basic templating directives, form validation, routing, deep-linking, reusable components and dependency injection.
  • Testability story: Unit-testing, end-to-end testing, mocks and test harnesses.
  • Seed application with directory layout and test scripts as a starting point.

Example ::

<!DOCTYPE html>
<html>
https://ajax.googleapis.com/ajax/libs/angularjs/1.6.4/angular.min.js
<body>

Input something in the input box:

Name:

</body>
</html>

 

preview code:

Input something in the input box:

Name:

so with this example , you input a word or name to the name field and automatically it give you a feed back instantly below the name field. You guys should try it and see what i’m talking about. Very fun..

I have learned a lot about Angularjs. You can do a whole lot just on a single page without refreshing it or changing the page. Which is very efficient. I normally use jquery for my programming in web development but comparing it with Angularjs, i think Anjularjs is far easy, efficient than jquery. I might be wrong since i have not learned into it so deep. but for the small coding i did, was very easy and understandable.

Links::https://docs.angularjs.org/guide/introduction

 

From the blog CS@worcester – Site Title by Derek Odame and used with permission of the author. All other rights reserved by the author.

The Five Principles of Object Oriented Design

So for this week, I have decided to read about “The SOLID principles in real life” from the Infragistics blog. The reason I have chosen this blog is because while I do get the concept for each of them that which will guide me to writing clean code, I need a better grasp to put these principles into practice and not be limited that is just following a set of rules. This relates towards in making design patterns that which by using these practices, design patterns become a lot easier to implement.

For this blog post, it basically goes over the five principles of object oriented programming that which makes the acronym SOLID with real life analogs by the author.  For the first letter of the acronym S, this stands for Single Responsibility Principle. It asserts that a class or module should do one thing only. The purpose with this principle is to fight complexity while developing an application’s logic. For the second of the acronym O, this stands for Open/Closed Principle. It states that code entities should be open for extensions like extending certain behaviors but closed for modifications to achieve a flexible system architecture which is the purpose. The next letter of the acronym, L, stands for Liskov Subsitution Principle. This principle basically asserts that parent instances should be replaceable for the child instance without creating unexpecting behavioral problems. The fourth letter of the acronym, I, stands for Interface Segregation Principle. It states that main instances or classes should be segregated into smaller classes to use methods that is needed.  Lastly but not least, D stands for Dependency Inversion Principle. It encourages user to write code that depends upon abstractions than concrete details to give flexibility in it.

Based on the contents of this blog post, I would say that this was very good to read. Purposes of each principle was straightforward and easy to pick up upon while reading it. That is because the author uses real life analogs to give clear visualizations how the principles work in an effective way.  For my experience with the concepts of SOLID, I would try to use sample design patterns and go by each of the principle to gain a bit of practice in implementing clean codes.

From this blog about the SOLID principles, what I learned is that the Interface Segregation and Dependency Inversion should be the ones to take mostly into account. The ideas that I have been taught is that it will avoid having the code to re-compile with annoying frequency and swapping in anything that conforms to the abstraction will be easier. Learning the ideas from this blog shows me that for future practice, I should be trying to visualize the SOLID principles with real life perspectives as it will help in the logic of building system architecture and design patterns. I hope that with this knowledge, achievement of an extendable codebase is possible.

-Dennis Tran

 

Link to the blog: https://www.infragistics.com/community/blogs/erikdietrich/archive/2016/01/26/the-solid-principles-in-real-life.aspx

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.

CS@Worcester – Fun in Function 2017-10-23 23:56:06

The blog post this is written about can be found here.

I’ve been hearing words like waterfall and agile a lot in the course of researching software development and testing for my classes, so this week I tracked down a simple blog post explaining the difference in the two development methods. The descriptions of the two lined up with the two sides pitted against each other in the time-travel argument I wrote about for the other class.

The earlier method, waterfall, is a sequential scheme in which development is split into eight stages and one stage of development follows the other with no overlap. This is a technique I’d actually heard explained unattached to the name waterfall prior to this year. In other resources, it seems to be mostly referred to in terms of its disadvantages. This post lists some of the advantages of the method. There’s no room for errors or modification when you can’t go back to the previous step without starting the whole process over again. As a consequence, extensive planning and documentation is a requirement. The waterfall methodology can to some extent ensure a very clear picture of the final product, and the documentation serves as a resource for making improvements in the future.

However, there are significant downsides that led to the creation of the agile methodology. The dependence on initial requirements means that if the requirements are incomplete or in error, the resulting software will be too. If the problems with the requirements are discovered, the developers will have to start over. All testing is pushed to the end, which means that if bugs were created early, they could have had an impact on code written later. The whole thing is a recipe for the project taking a very long time.

In contrast, developers using the agile methodology start with a simple design and then begin working on small modules for set intervals of time called sprints. After every sprint, testing is done and priorities are reexamined. Bugs are discovered and fixed quicker in this way, and the method is highly adaptable to changing requirements. This approach tends to be much quicker and is favored in modern development. It allows for adaptation to rapid changes in industry standards, the fast release of a working piece of software, and the ability for a client to give feedback and see immediate changes. The lack of a definitive plan at the beginning can be a drawback.

Having a clear picture of both of these methodologies provides useful context that will enable me to follow more in-depth discussions of software development, and there’s a good chance it will be relevant to my future career.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

10/22/17 Software Development

https://www.artofsoftwaredevelopment.com/art-or-engineering/is-it-art-or-engineering

This blog is on the topic of art of software development. The author believes the software development is like art. He also explains why it matters. Teaching someone about software development with the concepts and technique of programming is similar to teaching someone about art. Both difficult and challenging. The final product depends on the student and mentor. The author compares telling a programer how to write a program to someone telling Van Gough how paint his masterpieces. Both end with negative results. Similar the final product of an artwork depends on the student and mentor’s insight.  The author briefly gives us the definition from engineering and art both which come from Wikipedia. Engineering is “the application of scientific, economic, social and practical knowledge in order o build, invent, maintain, research, and improve structure, machines, devices systems, material and process.” Art is “a diverse range of human activities and the products of those actives usually involving imagination or technical skill.” He then states software development comes from the imagination and technology of humans. Software developers can choose the founding blocks for their programs to make it run. The author concludes that yes software development is in a way a form of art and engineering. Like artists, developers need the freedom  to choose how to code and write the program. They can write a program for a client within a certain parameter, but still need the freedom to do it how they want to. Give the programmer too much of a restriction on the program and they won’t have enough freedom or space to create the program and make it run properly. The author does not fully explain on why it matter, he gives his opinion on what he thinks then leaves the question open ended for reader to decide for themselves.

Again, I liked this blog. I agree with the author of software development being a mix of both art and engineering. You need a creative mind to create a program but you also the technical skills to know how to run the program. Again this gives me an idea of how developers work and what they can do.  I have always seen programming as a type of art. My parents have told me I’m artistic with technology and learning how to write programs. I have always been able to figure out how technology works, and figure out how to fix them if theres is a problem.

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

How to Write Clean JUnit Test Cases!

After learning more about JUnit testing I found this blog that really emphasized what we can do to keep our test code just as clean as our program code. You can find the blog here: https://blog.codecentric.de/en/2016/01/writing-better-tests-junit/

The beginning of the blog goes through the value of testing code and the importance of living documentation to help people that join your team half-way through a project. You should read that part if you want to, but my main focus of this blog is the basis of keeping the testing code clean and understandable so that people can understand what is actually going on.

Behaviors!

One way to write better test cases in JUnit is to test behaviors and not implementation. Writing test cases based on implementations will lead to fragile tests that break easily.  The blog gives the definition of behavior as “the range of actions and mannerisms made by individuals, organisms, systems, or artificial entities in conjunction with themselves or their environment”.  I could not find a better way to word it then what the blog had here:  “”Range of actions and mannerisms” – this explicitly limits our view to what is observable from the outside. If we refrain from disclosing internals, and phrase our tests accordingly, they should become much more flexible, and enable us to refactor, replace and/or rewrite large parts of the production code without additional effort” Essentially, we shouldn’t be testing specific variables but rather the universal behavior of the methods on their environments.

Context Grouping

Another helpful technique to make your tests look as clean and understandable as possible is to group the tests by context. This means that you write your tests in a type of hierarchy.  In the blog they use the form “Given-When-Then”  meaning you should write your tests in a hierarchy like this:

givenwhenthen

This creates a tree of tests in the JUnit Runner window like this:hha.png

This is a huge tip to keeping  testing code clean and easy to read, which I had not known about previously.

Single Assertion Rule

This is another tip that will certainly help me keep my tests cleaner because I had not heard of this before. The single assertion rule is just a way of saying that you should only have a one Assert.assertEquals(). This is because it makes looking for why the test failed that much easier, only looking at one value instead of two or more assert values.

Meaningful Names

This one has always been important. Make sure to use descriptive names rather than generic variable names like “x”, “data”, “input”. For example you could use “inputFromEveryDataFile” to improve on the name “input” if you were actually reading all the data from every file.

There are many more…

There are many tips out there to writing more clean and readable test code for JUnit. I couldn’t possibly document every single one! There is no such thing as code that is “too easy” to read so keep cleaning!

 

 

 

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

2# Software Design and Construction

Coding Blocks – Design Pattern- Episode 2

I think this was one of the podcast episodes I was really excited to see. The topics was design patter so I figured I would hear things and concepts I was familiar with and also serve as a measure for me to test what I knew and how in-depth I could follow the episode. Right off the bat, they begin to talk about the absence of design patterns in their curriculum when they were in school. This made a light bulb go off. Meaning I am technically ahead of that era in terms of the tools I am being provided in school to better succeed in the real software construction and development world. Joe Zack also mentions that he knew the big O notation for the entire basic sorting algorithm, which is something I am also familiar with. I am currently an expert at the shell-sorting algorithm. With all the things they were talking about I was able to face reality that I am not really too far away from being a developer on a software development team. Also it demonstrated how much the field of software engineering has changed. It’s crazy for someone to graduate from computer science and not know what design patterns are in today’s world. All projects and programs   today utilize design patterns to create a hierarchy of classes comprising of parent, children, abstract and class interfaces. This helps organize and makes thing more legible for the next programmer that is hired to “maintain” the program. To become a great programmer, one need to develop great design and organizing skills that can be translated into project design patterns. Again Design pattern can actually be divided into three (3) categories.

 

  1. Creational Patterns. (Factories, Builders, Prototype and Singletons)
  2. Structural Patterns. (Adapter, Bridges, Flyweight, Proxy, etc.)
  3. Behavioral Patterns (Observers, strategy, Chain of responsibilities, etc.)

 

This I did not know!

 

Creational Patterns: They help encapsulate the logic of creating classes in a more separate class where classes are created and represented outside the logic that utilizes the creational pattern.

 

As the discussion got deeper, I noticed that most of these guys recording the podcast have done tons and tons of projects that utilize some of the concepts they are talking about. Right of the bat, I got the initiative to start a project and try to use and implement as many new concepts as I can. Because after all, the best thing you can do for yourself as an upcoming developing in school is to start many projects on your own and try implementing new things you learn and read in school because in the worst case, you familiarize yourself more with topic and concepts that get taught in class.

 

Link

 

https://player.fm/series/coding-blocks-software-and-web-programming-security-best-practices-microsoft-net/episode-11-design-patterns-part-1-you-create-me

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

Software Testing without a Software Tester

Unfortunately, or fortunately, this post is not about automatic testing. According to the author of this interesting post, James Bach, automatic testing is as feasible as automatic programming. That is, not very feasible. Yet, at least.

In a very nice story, James writes a program while his non-programmer and non-tester sister, Erica, stays by his side. He walks through his logic while writing and his sister points out issues while he does so. Despite not having any computer science background, the mere presence of an interested companion leads to better, less issue-ridden programs. This made me remember something from a long time ago, when I was told about the somewhat infamous rubber duck test.

For those that don’t know, the rubber duck test is when a programmer, aloud, describes how his or her program works…to a rubber duck. It sounds ridiculous, but the mere act of trying to explain ones own work in an understandable way can lead to discovering issues that might otherwise be unnoticed. A design fault that seems obvious in hindsight but was looked over as the programmer becomes tunnel focused while in the midst of programming.

This very neatly explains the need for a tester, or at the very least something to get a developer to think in a different way about their work. Along with this, it also demonstrates the natural problem solving nature of a programmer that seems inherent. The need to resolve the conflict of a companion not understanding you is something familiar to me. My middle-school aged brother sometimes asks me about stuff I’m doing, which very many times turns out to be classwork. I have surprised myself with how much I wanted to clear up any looks of confusion I got when attempting to explain a mathematics problem or a program I was having issues with.

This natural motivation of wanting to be understood can lead to much deeper introspection, especially when the other party is not very familiar with the concepts being explained. It often leads to a long series of “Why?” questions. Something James himself calls ‘drilling down’, continuously being asked for more details. Trying to frame key concepts one believes they understand can lead to realizing flaws in ones understanding or incompleteness.

I really enjoyed this article, the story was nice and familiar. It made me realize how basic a necessity a tester, or at least just someone other than the programmer or something else other than the programmer is to creating a program. Or while not a necessity, such an incredible boon to the entire process, that it should be.

Original post: http://www.satisfice.com/blog/archives/852

From the blog CS@Worcester – Fu&#039;s Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.