Category Archives: Week 7

The Long Road

This pattern has reopened my mind on how the society expects us to function without taken into consideration what the individual passion is. I kind of knew many point mentioned in this pattern but didn’t know how to deal with them until I read this pattern.  It is true that the community I live in wants me as a young graduate to get a nice reputable job with lucrative sum of money. They would expect me to have solutions to problems at the tips of my hands. But the little I know is that learning is an ongoing process and takes place gradually. Implies I might get my four years college training and graduated alright but my learning doesn’t end there. As an apprentice, I should continue to learn in order to achieve that mantle of the journeyman. Looking up to satisfy the society would do me no good than to draw me back from the long term goals that I have set for myself. Being able to growth in this industry requires me to be patience and stay focus to my long term goals.

One thing that marvels me is promotions. I didn’t see promotion as a detractor until I studied this pattern. I usually would take promotions as a reward for your good and professional word. But after reading this pattern, I have come to realized that not all promotions are worth taken.  For example, as a software developer, taken a promotion to managerial position that has no connection with your previous duties will harm you at the long round. I would rather demand an increase in pay than promotion in order to stay focus on my passion for developing.

Also, it’s a norm, and as society demands, people would always seek a well paying job than seeking to develop their skills. It is quite challenging to work for less money when you know you can get more for the same input. But that notwithstanding, one need to weigh passion and long term ambition for his career against the present even though, I think the long term would pay you than your present.

 

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

Post #22 – Reflection on the “Craft over Art” Pattern

This week, I will be writing a reflection on the “Craft over Art” pattern.  This pattern addresses developers facing the problem of wanting to create something special for the client, but there already exists a proven solution at your disposal.  I chose to reflect on this pattern because I think it’s a pattern that all developers can relate to, at some point in there career, and I liked the quote that Oshineye and Hoover provided to distinguish craft from art: “I would describe programming as a craft, which is a kind of art, but not a fine art.  Craft means making useful objects with perhaps decorative touches.  Fine art means making things purely for their beauty” – (Richard Stallman).

The first piece of advice they provide is that, as a developer, you need to do your best work in ways that place the interests of your customers over your desire to display skill.  This is an act of balance because the things built by software developers must be useful but they may or may not be beautiful.  Creating something that is beautiful but useless is not being a craftsman; because a craftsman always values utility above all else. The general rule of thumb in software development, according to Oshineye and Hoover, is to sacrifice beauty in exchange for utility whenever necessary (which is often).  Your focus should always be to deliver value to the customer, first and foremost.

The second piece of advice they provide is that, as a developer who considers themself a craftsman, you should produce quality work regardless of your personal interests/feelings.  This ensures that the customer is being delivered a piece of software that provides immediate value to them.  This is the part of the pattern that I most agreed with because this is already the kind of work ethic that I bring into both my school and work-life.

Utilizing this pattern means to find the balance between your customer’s desire for an immediate solution and your standards as a software craftsmen.  As a craftsman, you should have an understanding that utility and beauty are not opposed and that it is crucial to hold onto the balance with your customer, even in stressful situations.  If a stressful situation causes you to make a mistake, you are also responsible for knowing how to refactor and repair – often times from the ground up.  Oshineye and Hoover provide another useful quote to conclude the pattern: “it is by fixing things that we often get to understand how they work” – (Sennet).  I found this pattern to be quite useful and, from this point forward, I will carry this concept of balance with me as I move forward as a developer.

From the blog CS@Worcester – by Ryan Marcelonis and used with permission of the author. All other rights reserved by the author.

Share What You Learn

We’re currently in the stage in our capstone where teams are beginning to implement code for the AMPATH project. I’ve been noticing that all of the teams having been making a lot of interesting discoveries in the process. I think I’ve done a good job communicating what I’ve learned with my team so far. But at the same time, I believe communication with all teams as a whole is equally as important.

The “Share What You Learn” apprenticeship pattern concerns primarily what its name suggests. It is asserted that when we learn or discover something new, it ought to be shared with anyone who might benefit from that information. This can be done in a variety of ways. Examples include sharing resources on blogs, relative community platforms, and/or during face-to-face discussions. I feel this is important because even if one person has struggled with something seemingly trivial, chances are there are many others having the same exact problem. For example, a couple of weeks ago, others mentioned that deleting the package-lock.json file (while in WebStorm) before running npm install allowed a successful build of the AMPATH project with no errors. Sharing this information was especially useful to myself, my team, and any of us who had to previously make several manual code edits just to get the app to run.

Lately I feel that as a class, we have been improving in our cross-team communication. We’ve been having more cross-team discussions and sharing of resources, both in-class and on Slack. This is very important; we may be working on different tasks, but ultimately we’re all contributing to the same project. It is certain that we’ll face many of the same obstacles. Thus I believe it is important that we continue to share what we learn. Doing so is a great application of the “Share What You Learn” pattern.

Personally, I’ve been trying to apply this pattern to the best of my ability. For instance, I’ve shared everything I’ve learned about my understanding of the AMPATH app’s processes and procedures. I’ve done this in previous blogs, during class, and on Slack as well. My hope is that sharing what I’ve learned can help others – whether they’re in my capstone course, or someone on the other side of the world searching for information on something even remotely similar.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

Adding Content to the Skeleton, an Adapted Scrum Methodology

This week marks the beginning of adding real content to the skeleton site that I have been developing for Massachusetts HOSA. The content was provided to me in the form of a word document, with titles to differentiate between pages and sections. The first thing I did upon receiving this document was break the document down into individual user stories. I then created a Trello card for each story and placed the cards on the product backlog list. During this process, I was reading and building an understanding of the product owner’s vision for the website, as well as attempting to come up with potential acceptance criteria. I was also informally coming up with estimates for the amount of time and work that each story would take, but decided not to include these as part of the stories as it would offer minimal return on investment with me as the only developer. I looked at this process as a sort of modified Scrum Story Time meeting.

The next step was Sprint Planning, in which I plucked some of the story items that I saw as most important and placed them on the Sprint Backlog list. During my modified Story Time, I had already, for the most part, broken these stories down into small enough pieces to be worked on as tasks. This was the simplest way to handle breaking down the requirements, and is allowable because I’m the only one that is working on these tasks.

Once I felt that I had taken enough stories from the backlog to keep me busy for a week, I began work. This involved adding content in the form of text and images to existing blank pages on the skeleton website, as well as creating new pages as needed. Some of the story items involved formatting things like the footer and sidebar to achieve the desired effect. Throughout development, various questions arose.

Each time that I encountered something that I needed clarification on, I added a comment to the Trello card. For this reason (and many others), I really like using Trello cards to represent user stories and tasks. Using Trello also allowed me to attach images, checklists, tags, and mentions directed at specific users. I like the idea of keeping all of the relevant information about a specific user story in a single place rather than scattering it across email, in-person meetings, and Trello. I’ve been attempting to document any information passed through other communication channels into Trello so as to have a complete log of interactions.

I’m looking forward to getting into some more specific development on the site. Next week’s post will include a review and retrospective for this sprint.

 

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

Sweep The Floor

As a new apprentice and low man on the totem pole you should be ready and willing to do the small unglamorous, but necessary jobs that need to be done on a daily basis.  You need to swallow some of the pride and ego that you may have developed while solving assignments in College and realize that you need to start from the bottom again and that you need to adhere to the team dynamic that you are joining, they already have a working relationship and have already built up trust with each other that they don’t have with you yet.

While this is just an analogy sometimes it is a literal translation, much like it does in the book.  When I was in high school I worked in a woodworking mill making hardwood flooring and wood trim and molding.  So there was always a lot of sawdust and dirt flying around.  Whenever we were swapping out stacks of wood to make more, or changing blades someone was expected to sweep and clean the tables of wood chips.  This wasn’t a glamorous job and no one wanted to start sweeping in the little bit of time that we had to rest in between handling and stacking wood flooring, but it was necessary in order to keep an organized work area.  As both the youngest and newest guy that responsibility usually fell on me.  While most of the time, especially at the beginning, I hated doing it instead of being able to take a full break as time went on it helped integrate me into the team.  I started getting the respect of the other employees and the boss because I had shown that I was there to work and wouldn’t make others pick up my slack.

That helped me form the belief that whenever you go somewhere new, whether it is in a new field or just a transfer to a new location that you should keep your head down and focus mainly on doing your job.  This isn’t to say you shouldn’t socialize and make friends, but you shouldn’t get too relaxed that you fall into some of the bad habits that other team members may have developed and then you start you off on a bad foot.  Be ready to be assigned the worst tasks that the team gets because they still need to be completed, and do them to the best of your ability; even if it is something a tiny as updating or proofreading some documentation.  Some may not seem like it’s going to change the world, but it needs to be done and your quality of work will show through no matter the task.

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

Apprenticeship Patterns – Find Mentors

The pattern Find Mentors in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye discussed one of the key tools any apprentice needs to succeed: a mentor. How is one supposed to become a master at their craft if they have no one to model themselves after and no one to turn to for advice? With no mentor there would be no way to go from an apprentice to a master.

In my opinion, finding a mentor is perhaps one of the most important if not the most important thing an apprentice needs in order to succeed. I speak from personal experience when I say this. When I first started my internship some two years ago one of the senior engineers took me under his wing. Now, I was lucky enough that he took the initiative to show to show me the ropes. The amount of knowledge I have gained from working with him is priceless. I am happy to say we still work closely together to this day. It helps that we have a lot of the same likes and interests too. It makes it easier to have a causal conversation and pick his brain a bit because we have so much on common.

Now that I’ve told you my little story, I wanted to mention that the pattern brings up several valid points. First, it is hard to find masters in the field of software development because the field is so new [AP]. Often times you’ll find yourself taking on multiple people experienced in different areas as your mentors [AP]. I certainly have done this. Another thing to note is it may be challenging to get someone to take you under their wing [AP]. Most people with the level of expertise you are looking for are very busy. They may not want to and/or have the time to show you everything [AP]. That being said, the pattern discussed how you must be a bit bold when trying to find a mentor [AP]. This is something I agree with.  The last important point the pattern brings up is that you should return the favor [AP]. If you get to the point where you feel you know enough to pass knowledge on to someone else, even if you aren’t a master, you should take the time to do so [AP]. Remember how appreciative you were when someone shared some insight with you. The person asking for your help will probably be just as appreciative.

 

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

 

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

Post #21 – Ampath Application Development – Sprint 2 Restrospective

Our second sprint mainly consisted of reviewing the source code of the Ampath application.  The first of our 4 meetings was uneventful, because only 2 of our 5 members were present.  During the other 3 meetings, we worked with one of the other development teams to review the services within the application, reviewed the ReST API, and discussed how we might be able to utilize them in our own work.  Our team then accepted the task of implementing offline encryption for the application, and got in contact with some of the people at Ampath to get their input on their preferred encryption libraries.

Our team members collaborated well with one another and the other development team we worked with.  We were able to gain more of an understanding of how the Ampath application works, through our reviews, and we were able to begin planning our course of action as we head into the coming sprints.  We devoted a majority of this sprint to review and planning, so we have yet to start working on any kind implementation.  We hope to begin coding once we have some more structure and concrete direction, in the next sprint.

Toward the end of the sprint, we began working on the offline encryption task and we found 3 suitable libraries that we could use in our implementation.  We wanted input from the Ampath people before we chose a library to begin working with, so we sent them the 3 that we selected.  In their response, they commented on the fact that the encryption library ‘forge’ seems to be the most popular on GitHub, but stated that we could use whichever one we think would work best.  We will likely make our decision in the next meeting.  In our correspondence with the people at Ampath, we were also provided the main ReST API calls that are used within the application.  This will be extremely useful in the future when we have to begin sending and retrieving medical data in the implementation of the other offline features.

It was, once again, a fairly straight forward sprint.  I think that all of the development teams could use a bit more direction right now, but the coming sprints will certainly be more productive now that we are more familiar with our team members and the application itself.  I have so far been enjoying the Scrum development cycle and I look forward to beginning implementation.

 

From the blog CS@Worcester – by Ryan Marcelonis and used with permission of the author. All other rights reserved by the author.

Software Development as an Art

Hoover and Oshineye make some excellent points that I strongly agree with in the Craft Over Art design pattern in Apprenticeship Patterns. Although I had never thought about software development in terms of art, I found their discussion of art versus fine art to be interesting and well supported. While it is relatively simple to argue that software development is a craft, I would imagine that claiming that it is art would generate a bit more controversy. In my opinion, Hoover and Oshineye do an excellent job of supporting their claims that software development, by nature of being a craft, is also an art – but not a fine art. The distinction that they make between craft and fine art has to do with purpose. Because software development’s purpose is to make a useful product for customers, it can be seen as utilitarian in a sense. The purpose of producing fine art is purely for beauty.

The important caveat that Hoover and Oshineye introduce in the Craft Over Art pattern is that the craft of software development may produce something beautiful, but it must produce something useful. This may mean that craftsmen must choose utility over beauty when it is necessary. Considering the interests of the customer over personal interests and balancing conflicting demands is important in building and maintaining strong relationships with the customer.

This pattern applies in a couple of ways to my current undertakings. The importance of creating software that addresses real problems for real people is something that is somewhat new to me. Writing code for AMPATH Informatics is exciting because of the real-world significance that my contributions have. The other place where this pattern applies is in my independent study web development project for Massachusetts HOSA. While the customer-development relationship is a bit different in both of these cases, many of the same tips from the Craft Over Art pattern apply. While I may not be paid for my services, I still have expectations placed on me by the instructors and organizations involved in these projects. Understanding and carefully considering my responsibility to deliver a product that is first and foremost useful will help me to foster strong relationships with the collaborators on these projects.

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

Practice, Practice, Practice

Problem

The performance of your daily programming activities does not give you room to learn by making mistakes. It’s as if you’re always on stage.

Solution

The book suggests taking the time to practice your craft somewhere without interruptions, in an environment where you can feel comfortable making mistakes. Ideally we would use the technique “deliberate practice”, described in K. Anders Ericsson’s research: a mentor would assign you exercise based on their knowledge of your strengths and weaknesses. The mentor would help you evaluate your work and then you would work together to create the next exercise. The mentor would then use the experience of working with other students to create more challenging exercises that add small chunks of abstract knowledge that allows you to hone your strengths and correct weaknesses. Unfortunately we do not live in an ideal world and a lot of our practice on the job. The first example the text mentions is called “code kata”, which is essentially a practice session that some companies are starting to utilize for their teams. The text mentions another pattern, Breakable Toys, the ability to work on a piece of software in a stress free environment where you have control of everything. Finding new challenges and working on problems that are harder than you’re used to can help keep you master your craft.

The pattern had good advice and good information. The idea of having “code katas” seems like a good way to practice your skill and see what other people are working on. I think most developers do this already but the textbook mentioned the Breakable Toys pattern, where you take time to develop software in a stress-free and playful environment. I think it’s important to get periodic feedback, the text mentioned if you aren’t getting periodic feedback you could be developing bad habits. I think it’s important to always practice and find more challenging problems. I think having unique experiences with developing keeps an interest in the subject and avoids created burn out from seeing the same language or pattern you’re used to working with. Reading about this pattern has reminded me to try to always keep an interest in the subject by creating unique challenges,  practicing, and seeking feedback.

The post Practice, Practice, Practice 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.

TypeScript

I choose this topic because i wanted to know more about it, how it works and why developers choose to follow this style than our normal JavaScript style. Also to help me understand and do the coding for the duck simulator in typescript on design pattern.

TypeScript starts from the same syntax and semantics that millions of JavaScript developers know today. Use existing JavaScript code, incorporate popular JavaScript libraries, and call TypeScript code from JavaScript.

TypeScript compiles to clean, simple JavaScript code which runs on any browser, in Node.js, or in any JavaScript engine that supports ECMAScript 3 (or newer).

Types enable JavaScript developers to use highly-productive development tools and practices like static checking and code refactoring when developing JavaScript applications.

Types are optional, and type inference allows a few type annotations to make a big difference to the static verification of your code. Types let you define interfaces between software components and gain insights into the behavior of existing JavaScript libraries.

TypeScript offers support for the latest and evolving JavaScript features, including those from ECMAScript 2015 and future proposals, like async functions and decorators, to help build robust components.

These features are available at development time for high-confidence app development, but are compiled into simple JavaScript that targets ECMAScript 3 (or newer) environments.

 

Examples of typescript

The global variable foo contains the number of widgets present.

Code

console.log("Half the number of widgets is " + (foo / 2));

Declaration

Use declare var to declare variables. If the variable is read-only, you can use declare const. You can also use declare let if the variable is block-scoped.

/** The number of widgets present */
declare var foo: number;

Global Functions

Documentation

You can call the function greet with a string to show a greeting to the user.

Code

greet("hello, world");

Declaration

Use declare function to declare functions.

declare function greet(greeting: string): void;

Objects with Properties

Documentation

The global variable myLib has a function makeGreeting for creating greetings, and a property numberOfGreetings indicating the number of greetings made so far.

Code

let result = myLib.makeGreeting("hello, world");
console.log("The computed greeting is:" + result);

let count = myLib.numberOfGreetings;

Declaration

Use declare namespace to describe types or values accessed by dotted notation.

declare namespace myLib {
    function makeGreeting(s: string): string;
    let numberOfGreetings: number;
}

 

After learning and observing. I found out that this is way better than then normal javascipting coding. The reason why is say that is because with the typescript , i kind of like dealing with class (objects) like java coding which makes it easier for me. I like how things are organized and it also readable. I guess with this my coding will be javascript/typescript will be fun and cleaned. I really hope pupils enjoy this post and also research more about typescript.

link :: https://www.typescriptlang.org/

https://www.typescriptlang.org/docs/handbook/declaration-files/by-example.html

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