Author Archives: jwblash

MINIX3: Wrapping Up

I haven’t written a blog post for MINIX3 in some time (sorry Professor), and I figured that it would probably be wise to wrap up what I managed to complete this semester after I managed to get past all the stress I was feeling.

About halfway through the semester I started meeting weekly with my professor in order to discuss ways to approach my project. He knew I was pretty darn stressed about it, but was also pleased with how much I had learned about MINIX3 and Operating Systems in general. When we started meeting, I hadn’t done any actual programming in the scheduler, and I was still fuzzy on how the whole scheduler worked as one unit. I had also not realized this at the time, but the scheduling algorithm in the official MINIX3 Book was an older version. It doesn’t reflect the design found in this report, which describes the current scheduling algorithm (found in versions 3.3.0 and newer, I believe). This was adding to the confusion in how to approach the system, because I was getting my information on the implementation of the scheduler from both sources.

I’ve talked about this a bit in my previous blogs, but I figured I’d recap in this one now that I have a better understanding of the system. In the official MINIX3 book, the scheduler is still built into the Kernel. This meant that any scheduling changes that were to be implemented involved editing kernel code, which could end up being pretty complex in the event of errors, etc. What the scheduling report outlines is the move of the scheduler into the user mode level of MINIX’s layered design system. There still is a small default scheduler that had to be implemented, but the main scheduling policy is implemented within the user mode scheduler.

Let’s talk scheduling policies. Both the kernel-level and the user-level schedulers implement a Round Robin scheduling algorithm by default. As outlined in the report, the easiest policies to implement with the user mode scheduler are round robin, priority, staircase, and some other queue-based policies. Whilst I was googling information about implementing priority-based algorithms, I found this wonderful project done by a GitHub user named Akshita Mittel. It includes a few test files and the changes necessary to make to some of MINIX3’s files in order to implement different algorithms. It is very similar to the project I had intended on doing, so whilst I did not copy it directly (licensing and copyright issues and whatnot), I did use it as a resource for implementing my own project.

Since I wanted to deviate my project slightly from the resources I found online, instead of just implementing more than one scheduling policy, I elected to compare the default scheduling policy with a priority scheduling algorithm, and vary the number of queues by +- 25%. This left me with 3 variations of the default Round Robin policy — one with 12 queues, one with the standard 16 queues, and one with 20 queues. It also left me with 3 variants of a scheduler using a priority algorithm, again with 12, 16, and 20 queues. My goal was to run the same test across each of these 6 variations and see if there was some notable runtime difference.

Before I go into the test, I figured I’d explain the difference between Round Robin and Priority style scheduling. Round Robin policies assign each process within the priority queues a time slice, called quantum. As processes run out of quantum, they’re moved to a higher (the higher the number, the lower the priority) priority queue. In MINIX3, after a certain number of ticks, the queues are rebalanced. This means that all processes who have had their priority changed get that priority reset. The difference between round robin and priority scheduling algorithms is fairly simple — round robin policies aim to be fair, which is why they implement queue feedback. Priority policies are designed without fairness in mind. You might want some processes to always have the highest priority. Therefore, it simply disables process feedback from happening. Processes don’t move around between queues. A diagram of the structure of the priority queues are shown below.

Based on an image from Operating Systems: Design and Implementation by Andrew S. Tanenbaum

The test I used was based on Akshita’s that I found on GitHub. The test program would log system time, do some work with a process, then log the system time again, and find the difference between the start and end times. I found the average running time for 100 tests for each of the variations. The results are displayed below.

As you can see, there wasn’t much consistency across the tests. I’m sure that, before I even ran the tests, I could have reasonably come to the conclusion that there wouldn’t have been much of a difference in run times given my particular approach. The test I ran was mostly CPU bound as opposed to I/O bound, which very well could have made a difference. I think CPU bound tests could have made a bigger impact if I had implemented a different policy than priority. On top of designing a better test for what I was doing in particular, I think that theoretically the number of queues within a round robin scheduler wouldn’t make much of a difference unless the processes existed within them for a very long period of time. Also, I think that the number of queues within a priority scheduler wouldn’t make a significant difference either, since processes tend to live where are they spawned. Aside from the crowding of the queues, I don’t see it having a large impact on the overall runtime. Therefore, I think that the results I got make sense.

I’m not upset that my small “research project” didn’t yield great results. The point of this independent study was for me to better understand operating systems, as I felt as though I was seriously lacking in that area. While I know there’s still a tremendous amount of knowledge to be gained in OS’s, I’m happy with the work I did this semester and feel far more confident when discussing OS concepts in general. It was a very stressful project at first, but now that I’ve wrapped it up, I think it was absolutely worth it. Hands-on operating system practice is a great way to go about learning the subject. In fact, this independent study has sparked quite a bit of interest in systems programming for me, and I’m looking forward to continue learning about it in the future!

(Side-note, this is my last school-related blogpost. At first, I felt extremely uncomfortable writing these things. Now, I think it’s something I’d like to do once a week, or at least regularly. I appreciate my professor requiring us to start these blogs — writing is something I never really saw myself doing enjoying, and after doing it for a couple of semesters now, I get it. Who would’ve guessed that recording what you learn is both both enjoyable and rewarding. Thanks, Professor Wurst!)

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

Sprint 6 Retrospective

This last sprint was actually very productive. I feel good about it!

We left off with our form buttons working, however our task was to get the submit button functioning. I believe we had created it already, but it didn’t actually do anything quite yet. We were discussing for some time in a group how we wanted this to work, and I think we ended up struggling for a bit to be able to really understand how to approach the problem. Looking back, this likely came from a lack of really understanding how angular is supposed to function on a webpage.

I believe the majority of us in the group came from the background that our program gave us. That means that we’re used to the object oriented structure that languages like Java use. Java, for example, has classes as the main structure of the program, combined with abstracted classes like Interfaces that all other classes can implement. With Angular we’re using Typescript which is also an object oriented language. We’ve mostly been using components for now, which are essentially classes, and we have yet to use services much in our program, which are essentially interfaces.

In order to implement the functionality for the button, I elected to use a service for it. I did use a youtube video to follow along, but only for understanding where to start. Our group knew we probably needed a click event that created another component, but we didn’t entirely understand how we wanted that to work. Using a service essentially bridges the gap between our form component and our dialog component in this case. Also, by using a service, it creates functionality not only the submit button we were working on, but any future buttons we want to implement that work in a similar way. Services have a decorator, “@Injectable”, which works in a very similar way to Java’s “implements” keyword. By injecting services into your components, you allow any component you want to implement the functions and data present in your service.

We also spent some time yesterday, on the last day of the sprint, merging our branch with the master branch. Some funky things are happening with git currently that I’d like to figure out a little bit better. For example, when pulling the master branch, I got much of the other work that people have been doing. That’s okay and it’s expected, however some of the other components were absolutely riddled with bugs (completely separate from code my group had worked on) that were preventing compilation. I had to spend a large amount of time yesterday fixing and working on the errors in order to even compile and get the angular server running locally, which was quite a hassle. After this, I also had to solve several merge conflicts that arose from pushing our changes to the master branch. These issues were largely found in the app.module.ts imports and everything, and also in files like package-lock.json. Once we resolved this issues, everything seemed to be fine (minus the actual styling of the full application), and we wrapped things up.

All that’s left is to finish our group’s powerpoint presentation and then we’re good to go. It’s been a fun semester, we’ve all learned a lot about the agile workflow, angular, git, and more. Capstone complete!

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

Apprenticeship Patterns: Dig Deeper

For the final reflection of my Apprenticeship Patterns series, I’ve decided to choose Dig Deeper from Chapter 6: Construct Your Curriculum. This pattern suggests that you stay conscious of the fact that, as an engineer, you’ll be forced to learn new concepts at a sometimes alarming rate. As a result of this, you’ll likely only learn things at a relatively shallow level of understanding. That is, you’ll only have time to learn what is necessary in order to complete your current task. While this seems like enough, it often can result in issues (bugs and more) in what you’re working on — and it’s limiting your own potential growth at the same time. The solution is to remain vigilant. Put in the work required in order to fully understand a tool. The system, and you, will benefit in the long run if you put in the effort now to learn things properly. Dig into the depths of every concept you’ll be using so you can use it properly.

I’m graduating this month and that means that I’ll be out of formal education for some time. While I do intend to return for a master’s level degree, that won’t be for some time still. And, while I know I’ll be learning a tremendous amount in the workplace, there is still so much more that I want to learn over the next few years that I may not get on the job. It’s the start of my CS career, and I’d like to hit the ground running. I need to make sure that I dedicate time to learning more theoretical concepts at a deep level.

The book draws a distinction between those programmers who have achieved deep understanding over a concept vs. those who haven’t by identifying those who create piles of rubble, and those who create cathedrals. We have a set of tools at our disposal — it’s really easy to use them to create throw things together and construct something that has functionality that is limited to strictly function. However, it’s the true sign of a craftsmen when one can use those same tools in order to create something beautiful. That is exactly what digging deep into each tool you learn can give you, and it’s something I’m going to focus on going forward into my career as a software craftsman.

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

Apprenticeship Patterns: Use the Source

This week, I’m reflecting on the Use the Source pattern from Chapter 5: Perpetual Learning. We all know the best way to gain expertise in programming is to actually program. However, it’s tough to know what tools are the best ones to learn from. This pattern suggests learning concepts by viewing the works of others — you’ll pick up on tips and tricks and can directly understand how to solve difficult problems if you learn from material from those who are great at solving problems. Even if the work you read isn’t from master software craftsman — just reading code vastly improves your ability to utilize code in your future.

I like this pattern a lot for a few reasons. I have always been timid about contributing to open source projects due to a lack of feeling comfort with handling others’ code. However, recently I started looking at a few open source projects and felt as though I could really contribute to the projects if I wanted to. I get the sense that this comfort has come from me handling and reading code more regularly on a daily basis. Another reason I enjoyed this pattern was reassurance. I’m starting in a Software Engineering position at Stratus Technologies in a month and a half’s time. I’m feeling extremely fortunate that I got hired, and I also know that I have a tremendous amount to learn — both when start the job (about the code they have in place) and beforehand. Their codebase is vast and complex, and in order to be an effective team member, I’m going to need to get used to dealing with large, multilayered, and complex systems.

In the arts, there’s a learning concept where the artist does “Master Studies”. Essentially, the idea is to choose a piece of art from a great artist and try to recreate it from scratch, by using the work as reference. This puts the artist’s skills to the test, but it gives them a framework to work within. I see this pattern and the concept of “Master Studies” as related, in a way. By examining the work of those who have made a name for themselves in the field, we get insight into how their mind works. There are many brilliant “Master” engineers out there, and they’ve written a tremendous amount of code that I can conduct my own “master studies” of. It’s like reading great literature — it will impact your work for the rest of your career.

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

Sprint 5 Retrospective

This past sprint was not quite as productive as we would have liked, although we did manage to start making great progress towards the end. In the beginning we ran into a tremendous amount of roadblocks. Between angular versioning, formatting errors, and more, we were really struggling to get off the ground in terms of productivity. It seemed as though, once one person had the local environment running on their machine, it broke for someone else. It wasn’t just a couple of us having issues, either. Each person in the group seemed to encounter some error at some point in time.

First, one of our members was struggling to build the angular environment at all. A fresh install of angular was required, which seemed to have fixed the issue. After that, I was facing some issues with something called polyfill.js, which was interfering with my ability to get my angular server running at all. Stack overflow wasn’t of much help because most of the issues I found posted were suggesting that I alter package-lock.json files, etc. These were all things that my teammates didn’t have to do in order to get the server running, so I figured that the solution was simpler than that. I was correct in my assumption once I remembered that AMPATH recommends that we run ng serve with the –prod tag as well. Upon doing this, the issue with pollyfill.js resolved and I could run the server perfectly fine.

Not only this, but we seemed to have many issues with git branching for whatever reason. We had previously played around with another group’s branch in order to confirm that we could get styling running at all on our local machines (which is how we realized we needed to ng serve in order to see styling). This ended up being a bit of an issue for a few of our team members, because they were seemingly unable to git checkout back into our branch — git was declaring that they didn’t have permission to join the branch again. In order to fix this, those members decided it was easiest if they just deleted the repository locally and recloned the project. Upon all of these changes, we were finally all caught up and able to ng serve nice and cleanly, without any big red errors.

Once we had fixed angular environment issues, we moved on to development and actually got some design happening. A big issue we were trying to conquer was that our angular form component using the material design “mat-form-field” module wasn’t displaying correctly. It was a standard HTML text field as opposed to the correct Angular Material styled one. Last sprint we discovered that we were being a bit silly with this and that we needed the angular server running for the text boxes to display correctly, but even still, our field component wasn’t functioning how we had anticipated. After playing with some other components (material design checkboxes, etc.) I realized that we foolishly hadn’t important the library for the material input field, which was nested within the form field. Due to this, it was completely un-styling our entire form field. After importing this correctly, it was (and has been) development game 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 Patterns: Confront Your Ignorance

The apprenticeship pattern I’m addressing this week is Confront Your Ignorance from Chapter 2: Emptying the Cup. This pattern follows the previous pattern in the same chapter, Expose Your Ignorance, which I’ve previously written about here. The idea is that, once you’ve identified where your weaknesses are in your area of work, you must confront those weaknesses in order to grow. It’s hard to know where to start. Sometimes you’ve pinpointed weaknesses in areas where it is expected for you to have expertise, and it seems like you’re the only one who actually has those weaknesses. It’s hard to know where to begin. Confront Your Ignorance suggests that you choose one area and start filling in the gaps. Do so in whatever way is most helpful for you — whether it be through introductory guides or through diving right in.

This pattern is actually very helpful for me in this very moment. Over the past few days, I’ve been dwelling extensively on what I do and don’t know. What is expected of me as a software engineer, and what I expect of myself in this discipline. I’ve come to recognize that I have many weaknesses that I’d like to eliminate — things like algorithms, many topics in systems engineering, and so much more. There’s a lot of things I would like to experiment with, and there are also a lot of things I need to understand before I can do that. Frankly, it has been pretty overwhelming to constantly think of all of these things at once, and it’s been fairly discouraging as well.

I’ve exposed my ignorances (or rather, they’ve been exposed for me through the interview process), and now it’s time to work on them. It’s not going to change over night, and it isn’t going to change all at once. However, it will improve through consistent, deliberate work. That involves choosing one topic and chipping away at it over time. The difficult thing for me is likely going to be choosing which topic to work on, because I have so many things I’d like to learn. I suppose I can’t go wrong though, so long as I commit to learning and keep checking new topics off my list.

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

Apprenticeship Patterns: The Deep End

The Deep End in Chapter 2: Emptying the Cup of Apprenticeship Patterns is a pattern that reflects much of how I’m feeling lately. There are several places in life where this pattern pops up — often because you’ve realized that things feel stagnant in your career. Things need to change in order for you to grow and expand your skillset, and your current environment doesn’t reflect one of growth. The solution of this problem is to make a large life change and let the chips fall where they may. It’s scary to do this because you’re so comfortable where you are and with the work you do, but at the same time you’re stuck in a rut and you need some sort of upheaval in order to feel excitement once again.

I’m feeling this pattern quite a bit right now because I’m finishing up my degree at Worcester State. I’m not quite in a rut at the moment, although the next phase of my professional development is going to demand that I move forward at a rapid pace. Going through the interviewing process is tricky, because I feel constantly aware of the areas of knowledge that I lack expertise in. Obviously no one can know everything, and it’s more important that you’re capable of learning and being an essential part of the team. I think that being hired as an entry level developer is going to be interesting because you really do feel as though you’re being thrown into the deep end.

It feels extremely overwhelming to move into a workspace that you have no experience in, especially in my case where I have no current internships. I know what to expect on a general level, however I also know that there will be many things that I won’t fully understand until I’ve worked as a software engineer for some time. In order to learn any of those things, I’m going to have to fail from time to time. That’s exactly the point of “The Deep End”, and that’s exactly what I need to make sure I remember. If you’re never in a place where you’re failing, you’re never in a place where you’re setting and aiming towards goals.

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

Sprint 4 Retrospective

This past sprint flew by. We did manage to get some work done, although perhaps not quite as much as I would have liked. Still, it was a valuable sprint and we learned quite a bit during it.

Since the last review, we solidified the workflow through which we’re going to be contributing to the project. For each task, we’re going to be creating a branch. Then, after committing it the new branch, we’re going to be creating a pull request for it that we’ll use for development. As we commit, the commit history will appear on the pull request in our GitHub repository, and the progress of the component can be commented on and tracked by others. Once the component is done, we’ll leave a comment saying so, and then it will be be reviewed and pulled into the main branch.

There was a bit of a hold up for some time because we are required to use Google’s Angular Material Design were struggling to identify exactly where to find that. We didn’t entirely realize that the Angular Material Design library was exactly that. Once we did though, we updated the master branch so that all future branches would have compatibility with Angular Material. Our group in particular had already made a branch called Questionnaire-Form before we got it working with Material Design, so we elected to delete this branch and create a new one, named Q-Form.

Also, from what I’ve heard, our back-end plan is currently not going as anticipated. In the beginning, we had plans to either use mocking or to create a server with fake information that we could draw upon. Then, last sprint, we had established that we were going to be using mocking and tying that in to different services that our front end components needed to use. However, it seems as though we don’t fully understand how the back end is currently implemented, and it’s something that we’ll likely need our professor to look even further into before we dive in.

If I could change one thing about how this work has been going, it would definitely be to do more work more often. Currently I think it should be entirely possible to be finishing components almost weekly, and it seems as though no one in the class has been doing that. At least, they haven’t been pushed to the master branch if there has been significant work. However, hold ups with sorting out the development environment and getting material design to function have been a major slow-down, so it is understandable that things haven’t been getting done as fast as we had anticipated.

Going forward, we’re looking to make sure that our new form component on our Q-Form branch works exactly how the Angular Material Form component is designed to work. Right now we have it functioning how it should, with an input field and a submit button, however we’re struggling to get it styled in the exact way that Angular Material is meant to be. Once we cross that hurdle, it’ll be far easier to get components finished, committed, and merged into the master branch.

On to the next one!

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

Apprenticeship Patterns: Craft over Art

While forms of craft and art may seem similar to one another, sometimes it is important to note the distinction. This is the exact distinction that Craft over Art outlines in Chapter 3. The point is that crafts have utility, and works of art are made for beauty and reflection. It’s important that, if you’re crafting something, that you treat it that as it is meant to be treated — because it is something that may be used in the future by someone else. Sure, there is room for artistic expression in your craft, but they shouldn’t be anything more than decorative or stylistic touches. As they point out in the book, craftsmanship is built on relationships. It’s about delivering value to a customer and using that to earn your living. Art is usually something that comes from a very personal, self-reflective place that others may connect with. “After all, there’s no such thing as a starving craftsman.”

I like this pattern because it encourages the reader to focus on doing something useful as opposed to something beautiful, as stated in the action paragraph. I feel as though this is important because as of late, I’ve been focusing on this a lot myself in anticipation for upcoming coding interviews. Although I may not be working on things I find myself feeling extremely passionate about, I do feel happy working on what is expanding my skill set. Practicing the language fundamentals of both Java and C, doing interview-style questions, and my independent study have been a blessing in terms of knowledge and learning. They’re all things that will allow me to push the boundaries of my skillset for my future projects.

I will disagree partially with one thing about this pattern, though. I feel as though with the degree that web development, specifically front end, revolves around design choices, that programmers with an artist’s mindset have become extremely valuable. With the amount of emphasis placed on good website and app design, there is absolutely a place for those programmers who seek to make beauty with code where there may have been less of a place for them in the past. Granted, these are UI/UX designers who are partaking in a craft themselves — their art has utility and is meant to be used by others.

Regardless, I found this pattern fairly interesting as a reflection of what programming is and what it is meant to be. Placing yourself in the mindset of a craftsman makes a world of a difference (at least, to my geeky brain) in terms of how you should conduct yourself in the work environment.

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

Sprint 3 Retrospective

This past sprint was a good one, even if we didn’t manage to get a tremendous amount of actual development work done. We divvied work up amongst our different groups and had a lot of discussion regarding how to start our project and what approaches to take while doing so.

We got in contact with Gregory Schmidt, a development lead with the official AMPATH team. Mr. Schmidt provided us with a fantastically detailed outline for the rest of our project. It included an interactive wireframe built using zeplin.io as well as a series of videos describing the project plan and the objectives behind the wireframes. Originally we had intended to clone and develop components as branches on our forks from the original ng2-amrs project. However, once we realized we were essentially making our own small to supplement AMPATH’s, we restarted by making our own repository for a GitHub organization for the whole class. The organization is split up into the different development teams we’ve organized ourselves into as well. Inside of this organization is the repository we’re using now, which contains a small blank angular project, and we intend to use it in the upcoming sprint to build off of.

Not only did we figure out how to host the project we’re working on, but there was a lot of initial discussion regarding how to manage the progression of components during development. For example, we had originally intended to use Trello as a scrum-like “task board”. Although it was later decided that, since we can introduce issues into GitHub’s issue tracking board, we would use that. By using Github’s issue tracker, we can set up an issue for each component, and even have several issues per component for teams to adopt and develop. On top of this, we can more easily display to the class which teams are developing what components, and who is within each team. Having all of this data reside in one place streamlines the development process and makes it significantly easier to determine what has been finished and what needs to be worked on in the future.

Our professor has been doing a lot of work in trying to figure out what the development process will actually look like. The class was trying to discuss how we wanted to handle branching — I proposed the idea that we would have one branch per component being developed that would get merged into the final project once that component was completed. Come tomorrow in class, the professor will tell us exactly how we’re going to start the development, however he has already said that instead of one branch per component, we’re likely going to do one branch per user story. Then, of course, we can branch off of those into sub-branches if need be. I believe there was talk of also using GitHub’s Milestones functionality as “Epics”, which if I’m not mistaken are essentially larger, more broad issues to be completed. For example, if we need a page of our application that has both a menu and a search bar, there might be more than one component that goes into that. This page might be considered an “Epic”, because it would involve many stories being implemented at once. Having Epics would be really helpful to guide the overall development process, so implementing them as Milestones could potentially be very useful.

We’ll have more information regarding what we’re doing in the next sprint come tomorrow, and we’ll be starting some legitimate development this next sprint, which will be great. I’m excited to get started!

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