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.

Mapping it Out

The next apprenticeship pattern I took on was Draw Your Own Map. The premise is simple: you are the only person who can choose the paths you go down and which roads you travel. You should not leave yourself to the mercy of your situation and those around you to determine the course your future will take. Is is a definitely a pattern of self-determination.

The Draw Your Own Map pattern is absolutely useful. I have always been a person who has difficulty relying on others. Although I acknowledge this as a weakness in most ways, one way it has strengthened me is I usually don’t find myself depending on others for approval or assistance. If I want to do something with my life, or make some future plans, the only person I ask is myself. This independence and selfishness is important, in my opinion. There is only every going to be one person looking out for your best interests: you, and so therefore it is your sole responsibility to map out your future and make the decisions that will lead to your happiness.

Despite this, I do think there are limits to the pattern, even when applied to careers. For example, although your position in a company might not be immediately satisfying, with time there is potential to move throughout the company to a position that is better for your skills and abilities. There are some paths you can only get to by travelling on a bumpy, gravel road first. It’s not optimistic, or ideal, but the text definitely glossed over these potential scenarios where you prioritize long term gains over short term happiness.

Overall, Draw Your Own Map is not an interesting or a surprising apprenticeship pattern, but it is a hugely useful one and one I feel I’ve already been using to make college-related decisions for a long time anyways. Basically, only you can make the choices that will lead your life to happiness, nobody else will do it for it. Just as long as you are making ethical choices that don’t tread on anybody else’s map.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Doctors vs. Computers

The article Why Doctors Hate Their Computers by Atul Gawande discusses the issues many medical professionals have with the use of new and modern Electronic Medical Record (EMR) technology. The premise of the article is that the software used by doctors, surgeons, etc. to record patient medical information, schedule appointments, and pretty much every clerical medical function necessary.

The article gives a healthy dose of reasons why doctors have so many issues with this software. The big issue that many doctors had was ease-of-use. It can be especially intimidating for less tech-savvy doctors to navigate the system and work with the interface to do the things that they were used to doing by pen, paper and phone-call before. In addition, there are a number of quality of life improvements and minor issues with the system that add up and force doctors to spend more time than they’d like working on their computers instead of with their patients.

I consider accessibility to be one of the most important parts of a functional program. It doesn’t matter if your program is capable of doing everything it is supposed to; if it is too challenging to discern how to make the program do what you want, it might as well do nothing. “Accessibility” is a broad category however, and could be affected by user interface, design choices, and certain features. Making a system as accessible to its users as possible should be a priority in every project, as doing so greatly increases the effectiveness of your system.

Something I found frustrating was how important bureaucratic and political details were to the implementation of these systems. I’ve always found that all the regulation and red-tape, while obviously important, distracts from the main goal. The bigger problem is that with every project, so many different departments have different ideas and goals for what they can get out of it. However, compromise does not always lead to the ideal choice. I think it is important to consider the actual goal behind your product and weight every other goal based on how much it lines up with that one.

Interestingly, looking forward, this article has given me a lot to consider when working on the AWS Food Pantry group project this semester. I will definitely be trying to maintain the accessibility of whatever software we end up making, so that everyone who may find themselves needing to use it can. I am also going to try to balance the needs and goals of every facet that affects the project, whether it be regulation/law, customer needs, and the needs of the business. In this way, we can create the best version of the software we are asked to create.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 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.

Why Doctors Hate Their Computers: Thoughts

My blog post will be a bit different from the usual for this week. I recently just listened to the audible of an article titled, “Why Doctors Hate Their Computers” by Atul Gawande. Throughout the whole entire time of listening to this article, a number of thoughts went through my head. The first was how amazed I was by the number of issues from the software that made it harder for the doctors. One of the first examples Gawande used was from his colleague, Sadoughi. Sadoughi is a primary care physician who hoped that with the new changes with the technology would in the long run help her, not hurt her. Sadly, with this new technology, she was spending multiple hours on the computer, even after scheduled work time. Another issue she had was that when she would look a patient’s problem list, it used to be easy to see what was there, for her to change things, whether that be getting rid of something or updating it. Now it had become a hoarding stash where everyone across the organization could edit it, and change it and had now become completely useless. One of the biggest problems and themes that was mentioned throughout this article was the amount of time just spent on the computer compared to before. Before many of the doctors, nurses, clinicians, etc. could spend all of their time on the patient. Now a days man of them spend time writing in useless information that before was not necessary. They have to take more time clicking things, and inputting data that is not useful. This in hand spends less time with the patient and their needs. As it can be seen from the article, the real customers for this new software was not the doctors, and nurses, but the patients. This was discussed heavily with Gregg Meyers. While the doctors may be having trouble figuring out how to use everything, he emphasizes that this new technology is for the patients. This is something that had me thinking a lot, and something I struggle with, especially as I have gotten older. This new software has helped patients in a number of ways, from keeping track of their medicine to their next appointment. Gawande states that it is honestly always been the case, with anything that a new system is always in favor of those receiving it, to better them, while making it even more miserable for those providing it. While it is extremely true that this can help thousands of patients, it is also true what Gawande stated. It is always the case, and in the end makes the one supplying miserable.While this is good, is it morally right? Everything that is decided for a company, is to help the customer, but in a lot of ways ends up hurting the employee. These tasks that are to be expected from colleagues and employees can be strenuous and demanding.While this article focused on doctors, nurses, clinicians, etc., the implementation of this system does not only apply to the Electronic Medical Record systems. Like Gawande mentioned in his article, this happens to scientists, police, sales people and even people like Cameron, who is a construction site supervisor. THe overall topic of this article was something I had never thought about before. What really interested me was the ending of this article. With Gawande’s personal experience with a patient, Cameron. He was stuck between a rock and a hard place when it came to his interaction with Cameron. He wanted to help him, but he had spent so much time on the computer, that when there should have been time for questions, all that was left was stress for Gawande to finish his report and not make his next appointment late. He emphasized the inability to find a equal middle when it comes to technology and human contact. It will never be possible to find that middle, but it is important to acknowledge it and to take steps to better it. Overall, I loved this article, and even shared it with my family members, who I both think would benefit greatly from.

From the blog mrogers4836 by mrogers4836 and used with permission of the author. All other rights reserved by the author.

Unleashing Your Enthusiasm

For this week’s blogpost I will be talking about Unleashing your enthusiasm, a apprenticeship pattern written about in the Apprenticeship Pattern Book. Like the previous blogpost that I had written about, I felt that this was a really informational and useful one to read for when I will be working in the future. When it comes to working on new projects and getting things started I tend to get really excited about what we will be able to do and achieve. Thinking about the new environments I will be in when I start working is very scary and having an idea of what I should be prepared is very useful. The last thing that I really want to do is hold back on the type of person I am too. When I read that I will need to find other ways to nurture my passion, I found it unfair at first for me to find others means or outlets to express my excitement. Just because I like to be excited and everyone else doesn’t, shouldn’t mean that I need to change who I am. After giving it some thought though, I did realize that a lot of my work will consist of projects and working with a wide range of personalities. This means that there will just have to be times where I will need to sit down and consider the team dynamic. There will be groups and projects that I will be involved in that will welcome my enthusiasm and unique thoughts and those will be the ones I know I will really shine. I think that this post is also important for further down the road in my career. When I am on the other end of the spectrum. When the group I am in will be receiving a new apprentice with enthusiasm and unique qualities that I had. It will help me to understand and help the other apprentices feel like they can express themselves in the way they want to. This article was very thought provoking for me and was very helpful for when I start working. It is very insightful and get me to think of things at a more mature and level headed stance.

From the blog mrogers4836 by mrogers4836 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Breakable Toys

Hello and welcome back to benderson’s blog, this week we are going to discuss an apprenticeship pattern discussed in the Apprenticeship Patterns book called “Breakable Toys”. This apprenticeship pattern discusses trying to find ways to learn when your work environment doesn’t allow failure to occur even though failure is key in learning in computer science as we learn from our mistakes most of the time and find solutions to fix them. This environment doesn’t allow the worker to learn which really impedes the knowledge that a computer scientist can gain. The solution that the book provides to fix this problem is doing simple at home projects that will help you learn and keep your brain thinking as a computer scientist would. Some examples of projects that you could do were making your own calendar from scratch, making a wiki, or an address book. They suggest making your project something that is useful to your everyday life and will improve your skills as an apprentice. The reason you want to build something is to learn from it and learn new things while creating your project that will make you a better computer scientist.

I’m glad I picked this apprenticeship pattern first because I can relate to this as one of my biggest fears of when I get a job is “what if I fail at doing something? Am I going to get fired after one mistake?”. Failure is a big part of learning, lots of scientists, especially some computer scientists, have made some mistakes and that has led them to create bigger and better things and makes them better at their profession. No one in this world is perfect and will get something right 100% of the time but that doesn’t mean that you can get a lot things wrong and expect to have a job at the end of the day. Creating projects and working solo on your own objectives will make you learn and influence you to keep going and figure out how to get over certain obstacles. Problem solving skills is huge in work environments as finding the solution as quick as possible is always key in a job and the solutions that the pattern reading provides are great in making you better at that specific trait. “Breakable Toys” is a great title for the pattern as that is exactly how it is, as a child you play with a toy and figure out what it can do and the many ways you can use it and it’s like you grew up and you’re translating that exact principle to computer science and what you can create with your knowledge. Thank you for joining benderson’s blog this week!

From the blog CS@Worcester – Benderson's Blog by Benderson's Blog 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.

Practice, Practice, Practice

Hi everyone and welcome to another blog post for CS 448. Today topic is going to about the first pattern I’m going to discuss from the apprenticeship patterns which is Practice, Practice, Practice. I choose this to be my first pattern to discuss because I feel like this is what I need more than anything to consistently do to become a better my programmer. This pattern makes me think about how I am practicing programming. I feel like I am practicing just to get better at it which feels more like a chore but after reading this I think I must find a way to fall in love with the practice. The pattern talks about that mostly practice is usually done in work and that’s where we make most of our mistake and we should find ways to separate the two. I couldn’t really relate to this because I never work for a company before, but I feel more confident and less scared when thinking about working for a company one day because it seems like many are learning as they are working in the field. I like that they said that beginners learn from doing and not through lecture because I feel like I am still a beginner and I been practicing the wrong way because I would be listening to lectures more than I should be coding. The pattern gave some great tips on how to practice that change the way I perform now. I will now code more and try to find an environment to code more relax so I can get the most benefit from the practice. I agree with mostly with this because when I first started programming most of the problems that I was doing stress me out because I was trying to meet the deadline and I didn’t really feel like I was learning that much. Everything felt like a blur but when I wasn’t in class no more and started to do and read the book in my own free time, everything started to click so I think is somewhat true. I think the problem is for me is that I not choosing interesting problems or project to practice on, and I will now try to find something I passionate and start working on and develop good techniques. I will also after this to code in an environment where I won’t develop bad habits. All in all, this after this pattern, it changes the way I program now. I learn that I should love practice and not just don’t because I must. There’re many projects that I have in mind that would be to work on. I think this was probably the most important pattern to read and understand.

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

Beyond the point of no return?

For the second week of reading, I chose to read the pattern, A Different Road. This is a continuation off of Draw Your Own Map and discusses an issue. The issue is when you have followed your own path as a software developer and hit a road block. This road block is not about whether or not you could become better and rather that of a change in interest. It details the possible outcome of leaving the industry to pursue another interest and what could happen upon returning. There is a chance that the gap from working in different industries could work against you in the end. It is said that some organizations will deem the inactivity from the field as suspicious and will question your return. The risk is big, but it is still important to follow your road map where ever it leads.

What I found useful about this pattern is that it encourages others to follow their hearts or road map that led them up to the decision where they might be leaving the profession. Everyone only has one life, and usually the saying is to do what makes yourself happy. Sometimes, people need a change of pace and it’s important to recognize that. However, I am not surprised that some organizations will question your absence from the profession if you chose to leave for a while. I’m sure many of us who chose to study computer science has realized the type of field we are going to throw ourselves into. Another interesting part of this pattern is about the work experience between two different jobs can sometimes be used effectively. Depending on the context of course, one experience in a separate field may be used to fix or provide a solution to a problem in a different field. This also goes back to the organizations who might disregard any experiences that an individual has that isn’t related to the experience needed to fill the desired position. I feel that the only choice after leaving the long road for a while is to work twice as hard to get back in. Lastly, I do believe there are probably plenty of ways to accomplish that and it’s not a lost cause overall.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.