Category Archives: CS@Worcester

The Long Road

Instead of solely focusing on the short run, it’s important to strike a balance between short-term and long-term goals. While it’s essential to plan, it’s also crucial to set achievable goals that can be accomplished in the short term, which will motivate you and keep you focused. Furthermore, the focus should be on continuous learning and growth, rather than just becoming a master at the craft. With the constantly evolving technological landscape, it’s important to keep up with the latest trends and advancements in programming. Additionally, it’s essential to maintain a work-life balance and not let programming consume all your time and energy, and staying motivated at the same time.

As a programmer, it’s easy to become distracted over time. I remind myself to stay focused on my passion and aim to become a master of the craft by balancing my work life and goals. The Long Road pattern taught me to stay motivated towards achieving long-term success in programming reminding me that money is not important at the same time. I believe that having a consistent routine and a long-term outlook is essential for staying motivated in programming. Prioritizing becoming a master of the craft, rather than just making money, is crucial for personal growth. I focus on developing a love for programming and continuously learning to maintain motivation and achieve success over wealth. I have a uncle who works as a software developer, and I have heard him express his dissatisfaction with his job. He mentioned that he is only in it for the money and does not enjoy programming or continuing to learn new skills. This attitude of solely working for financial gain can hinder personal and professional growth in programming. Instead, it’s crucial to prioritize developing a genuine passion for the craft and continuously learning new skills. This approach leads to greater fulfillment in the job and the ability to achieve long-term success.

I honestly agree with this pattern, staying focused on learning programming is crucial. While having additional motivations such as becoming a project manager or CIO is possible, prioritizing a genuine passion for programming is essential for long-term success and fulfillment.

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

Dig Deeper Pattern

Over this spring break, and after the first sprint, I had the realization that although I was able to grasp a lot of things, I felt that I had only a surface level understanding of many things. For better or worse, being thrown into the deep end of a project like Thea’s Pantry has made me come to understand that, although I do know a bit, and I also know that there is plenty I don’t understand, there is still much, much to refine before I truly believe that I can be capable.

The Dig Deeper Pattern seems to reflect my ideas. The Dig Deeper pattern establishes that you should try to become even more intimate and familiar with whatever you are working with. If, like me, you run into the issue where you feel like you have learned a lot, but then when push comes to shove, you become lost, then you should try to dive even deeper into the concepts and code. As it stands, Thea’s Pantry is almost like a trial by fire, and though it is difficult at times, and I feel lost, it is also the perfect time for me to truly learn the ins and outs of a project like this. Not only would it be helpful, for obviously my grade, but having a firm understanding will allow me to use my experience in all kinds of projects for the future.

Although I am still a bit lost, I am hoping to really push myself after this break with a refreshed mind and a motivated focus to dive deep into the code and start expanding my knowledge to the best of my abilities. I would go as far as saying that it is crucial to dig deep! From my experience in other things, the more fully I understand something, the more I will be able to intuitively solve problems. Even if these are problems that I have never dealt with before, if I am capable of understanding how things work, I can slowly track the issue down to the source, and eliminate it there! At least… That’s the hope! So, wish me luck!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Sprint 1 – Retrospective

Greetings everyone, I hope you all had a fantastic spring break. As we begin a new week, I wanted to take a moment to reflect on the recently concluded sprint 1. Undoubtedly, it was a unique experience for all of us as we delved into the real-world work environment. For many of us, including myself, it was a significant learning curve as we navigated the intricacies of our new job. However, I firmly believe that the challenges we faced during sprint 1 provided us with an excellent opportunity to develop our skills and learn from our mistakes.

Personally, I found myself drawing on the knowledge I gained from my computer architecture class in the fall of 2021. Although there was a long gap between that class and my current class, I was able to recap the essential concepts I learned in the CS-343 class, which proved to be incredibly helpful in my work. As we move forward with the next sprint, I am confident that we will continue to learn and grow, both as individuals and as a team. Let’s take the lessons we learned in sprint 1 and use them to make even greater strides in sprint 2.

As a team, we faced challenges during the first sprint, needing more time to learn how things work. However, we did our best to adapt and make progress. Moving forward, we will continue to improve our work process and complete tasks efficiently.  During the first sprint, I faced an initial hurdle with getting visual studio code and docker to work on my new laptop. Fortunately, my Scrum Master and Professor were extremely helpful in guiding me through the process, and I was able to overcome the issue with their assistance.

After resolving the initial challenge, I was able to focus on other aspects of the work, and I quickly identified a pattern that required my attention. I noticed that the variables in the code were being declared with ‘var,’ even though they did not change throughout the program. Thanks to the previous team’s efforts, I was able to change these variables to ‘let’ or ‘const’, in a little amount of time. The second issue that I encountered during the sprint involved removing MongoID from guestinfoAPI. To accomplish this, I had to delete the MongoID schema from the schema folder and remove the schema from the Index.yaml file. With these changes implemented, the guestinfoAPI was updated and functioning as intended. To resolve the third issue, I updated the code in the Dockerfile to replace the existing Swagger CLI image with a multi-architecture version. This was done to ensure that there were no issues running the code on my M1 laptop and to ensure compatibility with other devices. By using a multi-architecture version, the code could run smoothly on different architectures and avoid any potential conflicts or errors.

To improve team performance in the next sprint, dividing the workload efficiently is crucial. This will ensure that tasks are assigned according to each team member’s skills and expertise, leading to a streamlined development process and successful outcomes.

Links to GitLab issues:

  1. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/merge_requests/62  “Change ‘var’ variable declarations to ‘let’ [or to ‘const’ when they don’t ever change]”
  2. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/merge_requests/92 “Remove MongoID schema for GuestInfoAPI”
  3. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/merge_requests/93 “Replace swagger-cli image with multi-architecture version”

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

The Long Road Pattern~

Hello!

Welcome back to the blog. Today I’m discussing The Long Road pattern from the book “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye.

The context of this pattern is that our culture values quick rises to fame and holds material values.

The problem relating to this pattern is that we have a main goal for what we want to become–for example, a master software craftsman–but there are other people and outside factors that expect differently from you. You may be offered a great promotion and are urged by others to go for that rising opportunity, even though it would derail you from your “end goal”.

The pattern brings up as a solution to recognize that it might not seem like you would match with your end goal, and to also keep looking forward to your end goal. You should prioritize learning opportunities and any other growth opportunities that would help in the long-run rather than taking the higher-salary position or a leading position. For people hoping to hone their skills for something specific, they should be prepared for it to be a lengthy process.

For action, the pattern discusses thinking about your future–what role you may have a decade from now, and what experiences you want to have under your belt decades from now. Imagine you have to write about your professional history four decades from now, what would you want to see? Use that to plan out your career path. 

I think this was an interesting pattern to read about. This is meant for someone really dedicated to having a specific range of skill sets rather than someone aiming to quickly get promoted and become managers or someone higher up. I was thinking about what I would do–do I have a specific thing I want to become, like a master software craftsman? Not really. But it was interesting for this pattern to get me thinking. I do agree that if I wanted to become a master software craftsman, it would be important to not take on a role that is unrelated to using skills relevant to programming or being hands-on with software utilization. It could make you stray away from your path too much and could take away major opportunities for your growth for your career goal. If I end up having something in mind that I really want to become, this pattern will surely be on my mind–to make sure I stay on a path that will help me hone my skills and gain experience necessary for my career plans. I don’t disagree with the pattern since it’s meant for a specific end goal in mind.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

Sprint 1 – Retrospective

This week, the first sprint has concluded! And boy, there was a lot to learn and improve upon. For one, within my group, I was the Scrum Master, and it is a bit harder than I anticipated. I had some ideas to organize coming into it already, but sometimes, ideas don’t always meet with reality. At times, things were really effortless, and at others, they were rather difficult.

Some things that worked really well, was the overall organization. As a group, I realized that we were all heading into unknown waters, working with a code base that, though we had some idea of, in reality, we truly had no idea how much of it worked. Because of this uncertainty in many areas, I knew it was crucial to try and share our knowledge with each other as the sprint progressed. Some of the biggest boons, and though it was a bit of luck as well, was splitting our different members into the different portions of our issues.
As an example, we had a cluster of issues in our frontend, backend, and API that dealt with the same thing. Essentially, we had to update/add lots documentation, licenses, etc! This looked very simple at first, but there was some difficulty with clarity, since we simply weren’t familiar with what the specs were. We split three of our members into the three issues, and as we worked on the issues, I made a effort to make sure everyone is keeping each other updated, and this allowed us to realize that despite it being the same issue, we were actually doing things differently from one another. This allowed us to quickly establish what we should do as a group, and from there, we were able to progress forward without additional confusion.

Although things did work well because of our constant sharing of what we learned, not everything went smoothly. Some things that I tried to do as Scrum Master was make sure my group was not overly pressured or crunched for time. In my initial thoughts, I figured that we would have enough ‘brawn’ to sort out the issues with some commitment, and knowing how stressful a time crunch can be, I was very, very lax at times when important issues were being resolved. This relaxed attitude helped with the team morale, but it also did not do much to help with the issues and even stalled some issues. Moving forward, I hope to strike a balance between calming the team when things are not coming to a close, and trying to nudge them forward more when the deadlines are approaching.

As a team, I genuinely believe that we did very well. The biggest flaw in our teamwork, was not actually when we collaborated, but some team members doing things on their own, but these were only very minor issues such as changing issue names without telling anyone, which caused some confusion, as well as encountering a problem and trying to fix it without telling any other group members. Both instances, were very minor at best, and as soon as they were noticed, were stamped out already. Specifically, we know that moving forward, all group members need to try to communicate problems with the team before silently fixing them, and if a issue needs a new name, the new name needs to properly describe what the issue is.

Individually as well, I believe that I was very caught up with making sure that the team functioned, and though that was a great thing, it also negatively impacted my performance as an individual. I oversaw much of the progress, and was kept updated on how various systems worked, so I believe I have a good understanding of how the project works, but I have very little real work to show for it. Moving forward, despite being the Scrum Master, I have to not only manage the group and keep an eye on things, but also use my own abilities to push things forward.

Updating Dev container files
Updating/adding Documentation, licensing, etc

Finally, as much as there was lacking, I believe that moving forward, things will be much smoother. Our group has many great developers, and this was our first time doing a sprint. I already have many ideas on how to improve, and though it might be a bit of trial and error at times, we as a team, have all the ability to clear out our issues!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Find Mentors

Programming can be a daunting task, with many uncertainties and unclear paths to follow. Without guidance, it can be difficult to make progress. That’s where finding a mentor comes in. The “Find Mentors” apprenticeship pattern stresses the importance of seeking out guidance from someone who has more knowledge and experience in a particular programming area.

Finding a mentor can be very challenging in some cases, but it’s worth the effort. It requires actively seeking out someone who is willing to dedicate their time and energy to help you grow as a programmer. The mentor doesn’t have to know everything, but they should have more experience and knowledge than the apprentice. The process of finding a mentor is similar to starting as an apprentice in any other craft. You start small and learn from experienced practitioners, gradually building up your skills over time. The author’s experience of finding a mentor after years of programming demonstrates that it is never too late to seek help from someone who knows more.

This pattern emphasizes the importance of approaching programming as a craft and seeking guidance to make your skill better in programming.  It’s not just about finding a mentor but also about being open and willing to learn. The author’s recommendation to “expose your ignorance” means admitting what you don’t know so that your mentor can provide the necessary guidance putting in mind that no questions are stupid, just be open when you ask for help with the problem. The apprentice can also become a mentor, passing on the knowledge they have gained to someone just starting. This creates a cycle of learning and growth, where everyone benefits from sharing their knowledge and experience.

The “Find Mentors” pattern provides valuable advice on how to approach programming as an apprentice and emphasizes the importance of seeking out guidance. The author’s recommendations and personal experiences are insightful and practical, and they highlight the need for mentorship to develop programming skills. It’s a reminder that programming is not just about technical skills, but also about the community of practitioners who support each other in their growth as programmers. It’s not about just finding a mentor, you can also be a mentor for someone else and still learn new things.

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

Falling Down the Deep End

I’ve always had this feeling of wanting to do more and challenge myself to reach the potential that I so desperately want to reach. In this pattern, the deep end is one that all aspiring craftsmen want to reach, and any apprentice or journeyman needs to gain that experience or take on a project that will finally take them to the next level. I know when I’m faced with a new challenge it can sometimes grow into fear because I’m not going to lie I have a really bad case of Atychiphobia, well it’s not that bad but failing in any task can put me down and so it’s easier for me to take an easier task when I can rather challenging myself in something that will benefit me in the long run. The most reassuring thing that’s even mentioned in the book itself is that when working in the field, taking risks will rarely result in destroying one’s career, especially when it comes to the IT world. So, reading this out loud makes me feel better about failing a task, no matter how I perform, I will still end up learning something in the end and I can take my failures in stride to create better solutions for the next big challenge.

Although taking some risks should be encouraged to take one to the next level, it is important to recognize whether the risk will pay off for the individual, it’s important to communicate with other people or a mentor and get their feedback on whether or not it’s wise to take on the risk and whether the benefits outweigh the disadvantages. The book will emphasize that if the risk and challenges seem to be too out of the ordinary then it’s important to create a “Feedback Loops” the options are laid in from of you when need be. And for me especially, I tend to fall back on this quite often when trying to make big decisions for myself. It’s also important to save yourself once taking the risk. As the book refers to it as “drowning”; being able to bounce back when things don’t work as the plan is important hence why the feedback loop is Important.

Sources:

Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Retrospective Blog

While there were some issues along the way, I feel like the first sprint was a success in the end. I ended up doing three issues with one done, and two issues still having problems and needing to be saved for the next sprint. The links to all three issues can be found below. The first issue I completed was update or add all doc, licensing, lint config, .gitignore, and .gitattribute to General, and I found no issues, so it was pretty easy, and did not take that long. The second issue was updating the pipelines, where I thought I completed it, but there was still more to do, so it was saved for the next sprint. My final issue was the same as the first but for the API, and I managed to finish it, but it had a problem from the pipeline, and needed to be saved for the next sprint as well. This blog will go over my retrospective thoughts of the first sprint now that it is over.

Throughout the sprint, there were many things that worked well. One thing that worked well was how our team developed a genuine camaraderie, which is important when it comes to teamwork. You need to have trust in each other that you will get your work done, and trust that we are there to help each other, and I think our team has developed that. Another thing that worked well was our communication during class hours. During the time we were in class, our communication was great, and we really helped each other out with our problems. Later in the blog, I will mention how we should find time to do more of it after class hours. Having these positives after the first sprint is great, and it can only get better from here.

There were also some things that did not work well throughout the sprint. One thing that did not work well was our time management. Every task we did ended up taking one weight over what we predicted. I think this experience will help this, and it will improve for the next sprint, so it is not too big of an issue. Another thing that did not work well was how one member made a change in the name of an issue, and it confused everyone else. We should be more open to the whole team for any little change made next time. We can definitely improve on these issues for the next sprint.

For our team to improve, there are plenty of changes that we can make. One change is having more communication from Thursday to Tuesday, as it is a long break to have no meeting with the team. We are planning to fix this by finding some time between the days to meet for an hour and check up on each other’s progress. If we have an issue after class Thursday, we won’t need to wait until Tuesday’s meeting to look for a fix, and waste all of the time that is precious in a sprint. Another change we can make to improve as a team is our experience. In the first sprint, we had no experience with sprints before, and it led to our issues. Now that we have the first sprint as experience, I think that will improve our team to better prepare for the next.

There are also many things that I could change to improve individually as well. One huge thing I could change to improve is my knowledge of VSCode and Docker. In the beginning of the sprint, I was having many troubles with the simple parts of VSCode and Docker, as I had not used it since Fall 2021. It got better throughout the sprint, and I am feeling more confident in my abilities now as we start the second sprint. Another change I could make to improve is to more quickly admit when I need help. There were many times during the sprint where I delayed asking for help, so I could try to fix the issues by myself. I think if I tried to come to everyone faster, it could have freed more time to worry about other issues. I think with the experience from the first sprint, I will be better with this in the next sprint. This first sprint started off a little rocky with inexperience showing up, but it ended with the whole team confidently looking ahead to what is next.

Issue Links

  1. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/96
  2. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/98
  3. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingapi/-/issues/8 

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

Trust the process: Sprint Retrospective 1

With our first-ever experience with an agile workflow in the books, my team and I have successfully completed our first ever sprint. As a team, I think we worked wonderfully, especially when considering potential outcomes. Ironically, as the team’s scrum master, I’m glad that we didn’t fall behind on account of me, phew! I do admit that at times I thought I was holding my team back, but my team was very willing to help each other through whatever problems we may have had. As scrum master like to think that it only seemed easy because I had such a great team to work with.

I think each one of us had 4 issues to work on within each of the separate systems. We found that it was easy to split that way and made the overall epic easier to attack.

A major challenge was realizing that I had started doing the work backward. In that, I started with an issue that was dependent on a different issue being completed. I began work with this issue…

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventoryapi/-/issues/4

At some point, I realized that I need to revise the directory structure before doing the documentation as shown in this issue…

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventoryapi/-/issues/5

Unfortunately, after trying to commit those issues I ran into the issue of it not passing the pipeline until these two issues were completed…

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventoryapi/-/issues/6

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventoryapi/-/issues/7

Going into our next sprint planning it was very important to consider what order issues should be completed.

I tried to be a good scrum master to the best of my abilities, more so, to the best of my knowledge of what it is to be scrum master. Yet, I put quite some effort into trying to understand my responsibilities, A big theme for me throughout this sprint was having to research to refresh my memory on things that I should have made sure that I knew before going into the sprint. Various things like maneuvering through git, understanding scrum roles, and evening watching videos on sprint phases, were all things that I had put some time and energy towards.

Most of the improvements that could have been made were personal issues that affected me individually. I was able to partially rest these concerns by trying to talk to other scrum masters and by taking peaks in other teams progress. In particular, I would like to give some credit to Scott for easing some of my tensions regarding holding my team back. Scott offered the advice of “trust the process” when I told him that my group had a shared feeling of not wanting to “break” anything, mind you have yet to read the “Breakable Toys” chapter in the Apprenticeship Patterns book (it will definitely be the topic of an upcoming blog).

One other thing that I wish to improve on is being able to ask better questions and have a better overall line of communication with the product owner. I think it is very valuable to have such immediate access to communicating with the product owner that should definitely be utilized. I think going into my next sprint it would be very advantageous for me to organize whatever good or bad questions I or even my team may have and go to the product owners with the good questions. That way I can have an actual record of questions and even answers. There was a moment where I had also questioned navigating the feeling of the issue of not wanting to “break” anything with Prof. Wurst but he offered similar advice as Scott in that we should “trust the process” but in this case, it was more so “trust in git”. It was that conversation in which I found the value of asking questions.

From the blog CS@Worcester – Sovibol's Glass Case by Sovibol Keo and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective Blog Post

This was my first instance of using and being a part of the scrum workflow. Even though I knew how scrum worked from learning it in a previous class, I was still shocked at how enjoyable and manageable the scrum workflow process was. Our group was assigned the InventorySystem component of Thea’s Pantry. For this sprint, I focused on the CheckInventoryFrontend part of the InventorySystem. Our group did a sprint pre-planning, and we created issues for the “Convert all InventorySystem projects to new project structure” epic. I first made a sub-epic, made each bullet point its own issue, and then linked those issues to CheckInventoryFrontend (Link: https://gitlab.com/groups/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/-/epics/29). I will now go into more detail about what I have accomplished during the sprint. 

Evidence of Activity

Issue #1: Update devcontainer files

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/merge_requests/10/diffs#6e656a06857650151f28f253233ed97584044098

For this issue, both the devcontainer.json and Dockerfile files in the .devcontainer folder were compared and updated to match the same files in the GuestInfoFrontend.

Issue #2: Update Pipeline/CI files

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/merge_requests/9/diffs

For this issue, the .gitlab-ci.yml file, the Dockerfile, package.json, and Header.vue found in ./src were updated to match the already updated and working pipeline found in the GuestInfoFrontend.

Issue #3: All documentation, licensing, linting configuration, .gitignore, .gitattributes files must be updated or added

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/merge_requests/7/diffs

In this issue, docs/developer and linting files were added, and the .gitattributes file was updated.

Issue #4: Revise directory structure:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/merge_requests/8/diffs

For this issue, bin was renamed to commands, files were moved from the top level into src, new commands such as build.sh were added, and some files and folders were deleted to match the GuestInfoFrontend.

I reviewed, approved, and merged the following issues:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/merge_requests/10

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/merge_requests/9

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/merge_requests/17

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/merge_requests/18

What worked well?

Working as a team went really smoothly during this sprint. Our team had three frontends that were very similar, so once one person who was working on a frontend was able to figure out how to solve an issue, they would be able to help the other members working on frontends. Communication between team members was also great. When one member needed help, myself and other members would communicate over discord to discuss and fix the issue.

What didn’t work well?

I feel like there wasn’t much that didn’t work well. Very rarely in class we would get off topic and start a conversation about something else like discussing what computer parts are good. That time could have been better spent working on the issues.

What changes could be made to improve as a team?

We split the work so that basically one person was assigned to a part of the InventorySystem. We could have picked up issues in other parts of the InventorySystem to diversify our knowledge on how the InventorySystem works as a whole.

What changes could be made to improve as an individual?

Changes that I could have made to improve as an individual would be to actively search for a solution to problems that may have arised. When updating the pipeline, the program was giving me an unknown error and the professor said that he would look into the problem. Instead of trying to solve the issue myself, I waited for the professor to figure it out. Instead, I should have been also trying to find the solution to the error.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.