Category Archives: Week 3

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.

Software Development Trends

Today I read an article titled “Software Development Trends in 2018 That Will Dominate in 2019” This was a very interesting article that talks about the current trends involved in software development and how they will continue to be a force to be reckoned with in 2019. The article talks about 5 different trends that will be huge in 2019: Artificial Intelligence (AI), Progressive Web Apps, Blockchain Technology, Cybersecurity, and Low-code Development.

I chose to write about this article because I already knew that AI is one of the biggest current trends in software development, but I thought it would be interesting to read up on other trends in the world of software development. This article did not disappoint as I was able to learn more about Blockchain technology. I personally never heard of that before reading this article. I read that it was being used in the medical field, and it was being applied to the medical data in order to store it safely within a network. This appealed to me because my sister, and mother both work in the medical field, and I am sure that this could be useful in their line of work.

Although, I knew that AI was going to continue to be a huge trend in Software Development, I learned that AI will be used by “more than 40% of the organizations to automate their business in 2019” (Williams).

This article didn’t elaborate on low-code development too much unfortunately, but basically, it allows developers to build software without much expertise in coding. This part actually brings up an intriguing thought. While it does help people without expertise code more, could this be a bad thing for other developers? If everyone is given the opportunity to easily learn code, will that possibly take away opportunities from the extremely hard working developers? I don’t believe that will actually happen because the software development field is constantly evolving, so those with expertise in the field will continue to thrive.

Cybersecurity was the last trend that will continue into 2019, and I do feel like this is a given. The article mentions that 18% of companies did report at least one security incident in 2018. This is still an alarming number because some companies have a lot of important information that shouldn’t be leaked or taken. The trend that will continue is that these companies will look for Cybersecurity developers and thus, better programs will constantly be developed to virtually guarantee complete protection for any company’s data.

 

Article: https://medium.com/@Jessicawlm/software-development-trends-in-2018-that-will-dominate-2019-db1a1681c84d

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

The two ways of testing

So for this week, I have decided to read about “Pros and Cons of Dynamic Testing and Static Testing” from the testbytes blog. The reason I have chosen to read this blog is because I only have heard bits of both testing methods and I want to understand the advantages behind them. This will help me in seeing how they work and be able to use them in an expected way.

This blog post basically goes over as the title says the differences between static and dynamic testing. Both have their own purposes in making sure the software runs functionally. The blog post provides the techniques used and what are the benefits overall in both testing.  Static testing is an early stage of development and can be done manually or with a set of tools. It is useful in seeing the code flaws and giving documents to review the overall software. Another name for this test is verification testing.  With dynamic testing, the code is used to check how well it will perform in a run-time environment. It is to ensure that the end product is designed with the requirements given by the business clients. Another name for this test is execution testing. This one can be used in any levels of development. With both of these methods by their meanings, development companies can use them in to design flawless products in concept.

What I think is useful about this content is the way the ordering goes. From the blog, the definition is explained first to get the basic idea of the testing, then the techniques mentioned get broken down, and finally the pros and cons. The content has changed my way of thinking in how both the testing works. When I first heard about both the testing, I was briefly told that both can be used to find the errors and review coding in the software. However, one can be used faster while the other can be used around the end so that the product can be all set for the client. This was a misinterpretation in quite a time for me before finding the blog.

Based on the content of this blog, I would say this is informal and easy to understand when following along the order of it. I do not disagree with this content given by this blog because it helped me understand the ideas of the testing methods even without needing to see it in action. For future practice, I shall try to refer both testing advantages as reference for software testing.

 

Link to the blog: https://www.testbytes.net/blog/dynamic-testing-and-static-testing/

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.