Category Archives: Week 3

The Long Road

Far too often you see individuals seeking a shortcut to something they want whether it be wealth, fame, the perfect body, learning, skills, etc. the list goes on.

The Long Road discusses the problem of you wanting to become a master software craftsman and accept each pay raise but leave behind the long term growth opportunities; sure accepting a higher paying position would be nice but the author tells us why sometimes it is better to focus on your long term journey and the abilities you will unlock if you take your time and not take shortcuts. He discusses the amount of knowledge and appreciate software development much more over time. This pattern is not targeted towards individuals that are aspiring to become CIOs or project managers; more towards those who are passionate about software development and being crafty.

One action that was suggested: “Close your eyes and imagine yourself in 10, 20, 30 and 40 years time.” What experiences do you as an apprentice desire? For me, many came to mind. I am expected to graduate in a few months and when I picture myself a year from now it is to be working as a software developer in a structured company learning and absorbing as much as possible but I do disagree the part where I would not want to move up positions. My goal is to start off as a junior developer and over the years move up to a senior developer and maybe one day just a project manager whose goal is to help the team when necessary. I believe even if you are no longer considered as a developer, your thirst for knowledge will continue. This pattern helps me realize that my journey is just beginning and it will be a very long road to look forward to and I can’t be any more excited for it to start!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

“The Long Road”

In the third chapter “Walking the Long Road”, Dave have a bunch of certificates from his education. Then he starts connect to broader developer, he discover that he had barely scratched the surface of what it meant to be a great software developer. He inspired by the power of these hackers’ abilities. He threw himself into side projects and began to read anything he could get his hands on. The more Dave learned, the more he recognized how far he had to go. This is what I image I will be going though once I get into the work force. I am looking for the motivation to learn and see great things.

Speaking of work force, this is what everyone facing once they are doing job for money. We aspire to become a master software craftsman, yet your aspiration conflicts with what people expect from you. Conventional wisdom tells you to take the highest-paying job and the first promotion you can get your hands on, to stop programming and get onto more important work rather than slowly building up your skills. Everyone have their own road, that why we can not follow the successes step by step. I do believe the shorter road you take, the sooner it will be end road. I am agreeing with imagine my own long-term road. What step we are going to take, what experiences we want to try. We don’t want in the future to look back and wish we could take different road. This is always conflict between job and money, they are connected but also affect each other negatively. We are doing what we love but we also want to be successful. On our road of career, sometimes money and promotion could get you turn to different road. Maybe the road that you weren’t to take, this is difficult decision we will face at some point. I agreed with the chapter, no matter which road are we will take. Make sure that’s the road for long term and keep doing what we love.

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

Apprenticeship Patterns: Be the Worst

Consider yourself in the situation where you’ve joined a company, spent some time there, and learned quite a bit. You’ve climbed the craftsmanship ladder and others recognize your work as that of high quality, maybe even some of the best amongst the developers you work alongside. Your hard work has paid off and you’re a legitimately good developer. This is exactly what the pattern Be the Worst from Chapter 4 focuses on.

The problem with reaching this status is that you’re may likely find yourself at the pinnacle of growth in your work environment. Everyone turns to you for learning opportunities, and you’ve definitively established yourself as a leader in your workspace. However, you’ve found yourself unable to absorb information from your professional environment like you used to. Your rate of learning has stalled, and you’re no longer finding yourself continually developing and expanding your skillset.

The solution is something we’ve all heard before — surround yourself with those more skilled than you. Do so constantly. When you find yourself feeling like your learning has stalled, it may be time to locate another team whose skills outmatch your own (or at least, are in some kind of different field that you have lesser experience with.) Not only this, but keeping yourself in the ‘bottom-tier’ of your coworkers will “unlock” other patterns, which will help you keep yourself in the apprenticeship mindset. This is key because it ensures that, if you’re motivated, you’ll have continuous growth. Now, don’t get this pattern confused — Your goal is not to stay the worst on your team. It is to climb the rungs of the ladder until you’re an absolute coding machine, equipped with a host of skills that you’ve picked up from the time you’ve spent chasing craftsmanship. Then, once you’re at the top of the ladder, find another to climb all over again. Eventually, you’ll find yourself to be a developer skilled enough to guide others through the same process.

What action can you take to push yourself towards this goal? I may have been implying that it’s wise to up and leave every group that is slowing you down, but that’s not entirely what I meant. There’s no reason to forgo professional relationships in the search of career development if you’re happy where you work. Instead, search for elite teams across the world (via the internet) who you can be a part of. Get involved in more communities, different projects, etc. Staying in communities seeking growth will encourage you to do the same.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

MINIX3: Setting up the Environment

Over the past week, I found myself running head-first into a wall with MINIX. I ended up having to do lots of reading before I could even begin with development/tinkering. Having never done a project like this, I found rather quickly that the hardest part is getting started. Persistence is key, though!

In my research, I found that many resources were giving me mixed results. I saw a lot of people cross-compiling from their host machine into their VM, and I also found a lot of resources compiling from within MINIX itself. I really wanted to get a bit more experience with the feeling of low-level programming and using things like vi as an editor, even if it ends up making my life harder than necessary. So as a result, I was pretty set on the idea of compiling and rebuilding from within MINIX itself.

As it turns out, MINIX was originally designed with this type of native development in mind. From 1.0 to 3.2.1, they included the source files along with the install. In following versions, like the stable release of 3.3.0 shown on their download page, the /src directory isn’t even included within /usr. In order to obtain the source code, you need to use the git repository (also found here on Github) to clone the files. I found a section of the MINIX developer’s guide called “Tracking Current“, which explained how to go about using git within MINIX in order to track the most recent stable increments of MINIX’s development. On this page, it explains that the current stable release of 3.3.0 is not compatible with tracking current, as there have been key changes to the system since — the most recent snapshots are on version 3.4.0.

So, after a reinstall using a 3.4.0 snapshot, I finally have the source files included in my VM! I’ll start refactoring and show off what I do in following posts. I already played around a little bit by changing the startup text and rebuilding the system so it displays my name before I log in, just to make sure I actually understand how the “make build” command works. I’ll go more in depth on that subject next time. My task this coming week is to do a lot of reading through source code to understand what functions do what, and thinking about what changes I want to make exactly.

Until next time!

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern – Expose Your Ignorance

The apprenticeship pattern “Expose Your Ignorance” refers to the scenario in which you’re assigned a project but you are unfamiliar with some of the technologies that are required. Under the expectations of your colleagues, you may feel pressured to hide your ignorance so as not to seem incompetent as a developer. The best course of action, however, is to tell people the truth.

I can see why people might be uncomfortable with the idea of exposing their ignorance. However, I think that anyone who is more interested in actually becoming a better developer rather than focusing on what kind of developer they’re perceived as would be able to agree with this pattern. Sure, you could choose to pretend that you have the knowledge to complete any task already and then try to learn those technologies on your own, but there’s no guarantee that you’ll be successful. If you promise to deliver something and then later have to admit that you’re less knowledgeable than you initially let on, then you’re going to end up worse off. By admitting that you’re inexperienced with certain required technologies and asking questions, you’re able to show that you’re capable of learning while also being able to learn much faster with the assistance. One common phrase that I see commonly used is to “fake it till you make it”. I don’t doubt that there are some people who will look down on you for exposing your ignorance, but as long as you continue to focus on learning as effectively as you can, then you’ll be much better off in the long run.

One of the things I found interesting in the excerpt was to write down five things that you really don’t understand about your work and to put it where others can see it. This is definitely an extreme way of exposing your ignorance, but if people who see it are able to answer your questions and cross off an item on the list, then you’ll improve far faster than if you were to try to do the research alone. I’m not saying that you shouldn’t try to solve problems on your own, but it’s in everyone’s best interest to seek advice whenever they feel like they lack knowledge.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

The Long Road

When we start thinking about the future we should know that the journey will be long. In the software development field things are a little bit more challenging. This field is full of information that gets updated frequently and to many technologies to learn. If we want to develop strong skills in software crafts it … Continue reading The Long Road →

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Single Responsibility Principle too much or no?

Have you ever heard of the Single Responsibility Principle? What does it sound like when it comes to mind? To me it kind of sounds like an object is tasked to do one thing.

In Jon Reid’s “Single responsibility Principle: Is it a fundamental mistake?”, he talks about the different problems that arises when applying the SRP. He starts off explaining that in order to apply the principle, we must keep subdividing until the class cannot be subdivided any further. That task sounds like a nightmare right? It gets worse. He goes on talking about classes and an important concept called “Cohesion”. Simply put, cohesion expresses how closely related parts of your code are with one another. For example the more each method uses the same instance variable the more cohesive the class is therefore that class must be narrowed down according to Reid. There is a such thing however as extracting too much from classes but he doesn’t really go into detail describing when you know you’ve narrowed down too far he only states you’ll know when you’re there which doesn’t help much.

I thought this blog was sort of confusing because he didn’t go into detail about how to not make the mistake about breaking down your code too far; I guess he just wants us to learn through trial and error which makes sense over time. I don’t think I will try to change my way of coding because the way he described SRP kind of made me want to sway away from the idea. There just seems to be too much room for error in my opinion. Yes I agree it is good to narrow down your code but you do run into the problems he mentioned.

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

B3: Behavior-Driven Development

https://blog.codeship.com/behavior-driven-development/

          This week, I found a blog post that talked about Behavior-Driven Development and explains how to implement it within Computer Science. The post begins by defining behavior as the way the user wants the application to behave. It explains that you must have a clear idea on the user needs for this implementation to be successful. The implementation of this is done by dividing the user needs into small stories which have selected keywords to help define the behaviors of the application. The post uses examples very well to explain these ideas by highlighting and explaining important phrases. The selected keywords are used to put the stories into a more “readable” format while also creating behaviors based on the user needs. The post gives some advice after this, saying that the most important behavior to the user is the best starting point for these stories. Then you just keep building off that idea to encompass a final product that you can show to a client to make sure that all needed scenarios are covered.

            I chose this article because I was curious as to what Behavior-Driven Development entailed within the computer science world. I had no idea what this term was before reading this article, but I have gained a much better understanding now. I found this content enlightening in the sense that it taught me to think a bit differently. I enjoyed how the post explained the importance and implementation of this development through the use of these stories. I found this way of understanding user needs very helpful and a fresh new perspective compared to other things I’ve tried. I was able to understand how the development process works by starting at the user needs first. This will affect my development process by allowing me the option of working with the user to create better specifications. The most interesting part of this blog was the overall explanations for the development process. It was intriguing and informative while teaching the purpose of properly addressing the clients by starting with their needs first. I found this subject very interesting and this source was a good resource to understand with its use of examples and visuals.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Model-Based Testing

This week’s blog is going to be about “The challenges and benefits of model-based testing” by Greg Sypolt.  In this blog, Greg talked about what model-based testing(MBT) is, how it works, how model-based testing differ from other kinds of testing, the challenges that are faced when using model-based testing, and the benefits of using it. Model-based testing is a kind of test where test cases are automatically generated from models. It focuses on the models based on the system requirements or specifications. The model-based testing works by generating tests automatically from models created by the software developers and testers, then it runs assertions for both generation of tests and execution, and reports the testing results. Model-based testing is different because it is more in the software development process than a scripting task. It focuses more on building a testable application and creating models based on user’s perspectives.  There are many challenges to address before you can use model-based testing to its full benefits. Software developers and testers have to be trained on model-based testing. The tool has to be scalable and be able to handle complex models and provide a reliable test coverage. Fine-tuning the MBT tool could also be challenging. However, it will offset the long-term goal of reduction of test maintenance. Test coverage is guaranteed and there is zero test suite maintenance.

I think this blog post is very helpful in introducing model-based testing. It is fairly brief but still shows you the idea behind model-based testing. This blog post is really interesting since model-based testing is a move away from the traditional testing. Instead of having a set of particular tests with defined test objectives and deliverables that should be achieved, model-based testing is done from models and not from the source code. A thought-provoking section of the blog for me is where he talked about the challenges of model-based testing. Greg said that model-based testing requires a shift in mindset and culture in how to develop and test applications. It made me think of how different it really is from the traditional way of testing. Learning about model-based testing changed the way I think about software testing since it is an approach that I haven’t really seen before. Now, I wonder in the future, what else kind of testing we are going to come up with.

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

Behavior-Driven Development

What is Behavior-Driven Development you ask? To know that you must know what Test-Driven Development (TDD for short) is first. Keeping it short, TDD is a software development methodology that states for each unit of software, the developer must:

  • Add a test
  • Run all tests, see if one fails
  • Write code
  • Run test to implement code again
  • Refactor code to past test
  • Repeat

Knowing what TDD is, Behavior-Driven Development is merely an extension of TDD that makes more specific choices; meaning it focuses on specifying behavior and how the user wants the application to behave.

In Clemens Helm’s blog about Behavior Driven Development, he talks about the initial steps of BDD which starts off with the piece of functionality that is most important to the user; in other words we should develop software by centering our users. The purpose of this is so that developers know where to start and are on the same page in the development process of the project.

Some advantages I see from BDD is that it helps shift the focus to the expected end result and functionality of the program between the developers, QA, project managers, and business team. I found this particularly interesting because I always thought that communication was the utmost important part when it comes to creating anything as a team but I guess in a real work environment that is not always the case. I see that is what we’re learning to do in our Software Quality Assurance and Testing class; working as a team with different roles and I believe this is a very good skill to develop. I think that I will most likely try to incorporate this in the way I work with others in the near future.

 

Share your thoughts in the comments below! ?

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.