Your First Language

Hi dear readers. Welcome back to my blog. From now on I will be writing for different Apprenticeship Patterns that I will find interesting in the book to share with you.

I started computer science with 0 knowledge in coding, programming languages or anything else related to this world that I find beautiful nowadays. My very first programming language was the famous Java and not because it was my choice but because my first contact with coding was in Intro to Programming (CS-140) and the teacher had chosen Java as a language. Now that I think back three years ago, I am happy that I started my software craftsmanship with Java.

A summary of ‘Your First Language’ Apprenticeship Pattern would be that if you start your journey different from me (in the meaning that you can choose your first language), the book recommends you to research about it and try to figure out what is the most suitable language from you. It doesn’t have to be one of the most popular language but as every language has its own characteristics you got to pick the one you find more easy (or hard, if you like to challenge yourself). If you don’t trust your research skills than you can ask your friends who are familiar with programming languages and they will  be able to tell you the differences between a few languages and why they like what they like. Learning the language is not the only step of the process as you will be using this language forever to solve different problems you might come across. Remember, switching is always an option..

Most of my friends had started programming with Python which I have heard is a very easy language to learn and use. I remember when I started to learn Java I used to try and solve other problems (as much as I could) so I would get practice and in my first problems I was not using any other libraries. Practice is the key, believe me! A language is easy to learn but it has a lot of volume. Once my boss said: “Its not the language we should memorize, its the data structure” and I totally agree as in your journey you will work in different companies that will use different languages.

I really like that this is the first pattern included in the book as the first language is the first contact you have with coding. And don’t forget..Practice 🙂

 

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

Apprenticeship Patterns CH 1& CH 2-6 Intro

Hello dear readers. Most of my future blogs, including this one too, will talk about this book that I started to read called Apprenticeship Patterns by Adewale Oshineye and Dave Hoover. In this first blog I will write about the first chapter and the into of chapters 2 to 6. 

When I got the book in my hand I was like: “What is Apprenticeship?” and while I was confused by this term I came across another unknown term called “Software Craftsmanship”. For a second I was thinking we were going to talk about ships. Okay okay, just trying to make it funny. However, let me go ahead and explain what these two terms are about. Software Craftsmanship in this book is used as a distillation of the values of highly skilled individuals that are interviewed in the book. Also, it is used as an expression of the kind of community that would like to be emerged. In my opinion, being a software craftsman is to be in a journey but to always try to do better, learn, seek, dedicate and focus more.

Apprenticeship is considered as the beginning of your journey as a software craftsman. everyone on board..we are leaving the port and this journey will be long! Apprenticeship is known to be as the state or process of evolving and always looking for faster an better way.From my experience at my job, this is one of those things that you would always be valued for.
A good start is half of the journey, my mom used to say. However, you got to maintain these skills by being a journeyman. A journeyman is another focus that will help you keep up with your craft. It is focused o building even larger portfolio of applications that demonstrates your progress in the craft. Failures as a journeyman would cause lots of harm.
Last but not least is master. Master involves performing all roles (apprentice and journeyman) and also focuses on moving the industry forward. Being a master means to have the superior skill as the most important part of being a software craftsman.

While reading the intro of chapters 2, 3, 4, 5 and 6, I realized that this book will help me grow a lot in mindset and understand what the steps of a software developer are. The cycle of software craftsmanship its just like the life cycle: Child – Adult – Old. In every step we will grow and learn even more. The most interesting and relevant chapter I am looking forward to read is Chapter 3. In a world where almost everything is about money, it is hard to choose and value grow opportunities. Most of the people define growing as only financially, but I don’t agree with that. It is indeed going to be a long road ahead of me and there will be wrong turns or several storms but that only gives you experience and makes you a better journeyman.

In my opinion, this book seems to bring some very good thoughts  and explanations about being a software craftsmanship in life. I am so looking forward to read this book and share with you guys author’s and my thoughts about it. Until next time..

 

 

 

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

Sweep the Floor

Hello there! For this week’s blog I have decided to write about the chapter of our textbook called “Sweep the Floor”. The chapter caught my attention because of the small description of it. The description of the chapter was something along the lines of you are a new member of a software development team and you need to gain their trust. This is something that intrigued me because I will be starting in a software development team as a new member at the end of May, and I am not quite sure what to expect. I have never worked in a real-life software development team, let alone develop software full-time 8-10 hours a day 5 days a week. This chapter was something I was hoping would help me when it comes time to integrate myself into my new team come May. So the problem that’s set out in this chapter is basically the same as mentioned above, the team doesn’t know you, you don’t know the team, so how can you find your place and find out how you can contribute best to the team? The solution is somewhat elementary and what some would think of as common sense. The first part of the solution is to volunteer for some small, perhaps even mundane task that either nobody else wants to take on or is too busy to take on. Sure, this isn’t a task you went to college for four years to complete. Maybe the task is transferring some physical data into excel, or updating computer software around the office. It doesn’t matter what the task is, what matters is that by taking the initiative and volunteering yourself for the small day-to-day not so glamorous tasks, you are slowly gaining your teams trust and finding your place on the team. They will appreciate that you are taking a step forward and doing things that need to be done; getting in the trenches (so to say) and eventually this will lead to your team trusting you to take on bigger tasks that are more normal for a software developer like pushing things to production and writing major elements of a program. I hope to use this tactic in my workplace to quickly assimilate into my team and find my place.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Sprint 4 Retrospective

For this sprint, my team and I continued our work on trying to mock the server aspect of the project so as to give other teams a way to test their code. We had followed the tutorials on nock to make sure we understood the way that it worked and how we would have to translate it over. However when we went to the AMRS code to try to find something to try to mock we ran into some problems. Going through the code, there is a lot of moving parts to each element with the program which made mocking just one thing look like it may not be possible. Not only that but almost everything we found looking through the code, returned html responses from the ng-AMRS server they have set up already. For example one of the main things we looking into mocking was the patient-creation-resource part of the simple App, since it seemed to be one of the smaller files and less requirements/calls to other classes. In trying to mock one of the methods from this, this is where we started to feel that this may be a little too high of a task for us without the AMRS server itself. I feel as though if we had access to their already made server and could have just mocked the tests at that point we would have had much better success. There were just too many moving parts to each thing for our current way that we planned on mocking to be realistic. During this sprint though, I feel we were able to work more on the project and were actually making headway till we hit the wall on what we could actually wind up mocking. At the end of this sprint we also started talking about the possibility that we might not be able to achieve what we set out to do originally, so we also started looking at the bottom navigation bar element that still needed to be completed. We chose this as our backup and I had started to get some of the smaller stuff out of the way for that. I have gotten together all of the CSS and HTML components for the bottom navigation bar with what was provided from Greg Schmidt on the Zeplin app. Since this seems to be the direction we will be heading in the next sprint I felt it was smart to try to get ahead on some of the smaller/easier stuff. What I will need to be looking into and finding out how it works is the button elements that Greg Schmidt wants and how I can recreate them.

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

Apprenticeship Patterns – Craft over Art

This pattern is about the conflict between creating software that is beautiful and creating software that is useful. While you may find opportunities to do something truly fantastic, a craftsman should always focus on delivering value to the customer rather than advancing his or her own self-interests. You must find a way to balance the conflicting demands of creating quality software while still putting your customer’s interests first. Software built for customers can be beautiful, but it must always be useful. Following this pattern means that you must be willing to sacrifice beauty in favor of utility when it becomes necessary.

A craftsman must also produce satisfactory quality even if he or she doesn’t feel like it. Craftsmen can’t wait for inspiration to strike before delivering a product. However, it’s not about simply doing what is fastest. A craft artifact should always display at least a minimal level of quality. This means you must always be making trade-offs between beauty and utility, and sometimes you will make the wrong trade-off. However, by fixing these mistakes, you will learn lessons that are impossible to learn in any other way.

I enjoyed reading this pattern. I have always found it interesting how programming is so technical yet can be incredibly artistic at the same time. This pattern brings up a very valid point that even though you may be able to create something artistic, utility will always be a priority when software is made for a customer. I think the following sentence from the pattern sums it up perfectly: “The things we build for customers can be beautiful, but must be useful.”

As a programmer, it is often tough to decide whether to code something that gets the job done but is ugly, or something that takes more time but is beautiful. It is important to analyze the purpose of what you’re creating to decide which direction you should head in. Reading this pattern made me think a lot about utility vs beauty in software development. I do agree with the main point that as a craftsman creating something for a customer, utility should be prioritized. Overall, I thought this was an interesting and useful pattern.

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

Sprint 4

This week wraps up our fourth sprint in our software development capstone class. This sprint saw a lot in the way of front end development. One of the large tasks we were able to complete during this sprint was figuring out how to store the data that was entered in the intake form sheet using a local javascript  server that can be run through the terminal using angular. This was developed by Johnny and was attached to the front end file folder where it now lives. At first we were working in the original repository and had the project all together. This seemed fine at first but we quickly realized that not separating the repository into frontend and backend sections would prove to be a major problem down the line. We ended up having to fight with ourselves every time we wanted to run or even open the project because files were crossed and mixed up because we did not have proper file directory setups. One major problem I found right off the bat was not being able to run the front end of the project because I would get an error message in the terminal saying something to the effect of “You must be in an angular project to use angular commands”. I encountered this error after trying to run ng serve –open to get the project running. I was in the root directory for the project, where I should have been. After doing some extensive trial and error testing my groupmates and I figured out that the terminal had to be run in a subdirectory (in this case intake-form-master) which was below the root, scr, and app folders. While I thought this was strange I didn’t think much of it because it ran and it worked. We should have looked into this more because it turns out we had a massive issue. Though our project was in github and therefore a “git” project, we somehow were lacking a git.ignore file on the very top level of the directory. This went unnoticed, and ended up becoming a massive issue. It seemed like every time I pulled the most recent version of the repository I would have to scrap what I had before otherwise I would get all different kinds of error messages. This was annoying due to the fact I would have to wipe all the project files off my local file directory and then clean install from github just in order to get it to run. After a long discussion with the professor and a good hour of troubleshooting and head-scratching, we figured out that our big issue was coming from this missing git.ignore file. The basic gist of this major file is that since it was in a subdirectory and not on the top level of our repository, every time someone pulled or made a change or did anything to/with github, everybody’s local machine paths were being pulled onto your personal machine with every clone or pull of the repository. Since no two path setups are the same between machines, you would get a – for lack of better words – big spaghetti mess of pathing and branching and basically git would freak out and it would give so many errors because it was having trouble figuring out where to push/pull/do anything. To remedy this, we ended up going with the nuclear option and eradicated the old repository, set up a new one with the most current working version of the project, and had our professor merge our new repository with the parent organization. This time around we have a git.ignore file at the top directory to ignore all those different paths and other things that were confusing our terminals, and we separated the project into frontend and backend folders, which are proving to make the workflow process go much smoother. At the very end of the sprint we had planned a meeting with a food pantry representative, which will occur during sprint 5. Next sprint we hope to see some major advancements.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Sprint Review #4

Hello and welcome back to Bendersons blog! This blog post will not focus on an apprenticeship pattern but will focus on the end of my last sprint with my teammates in my software capstone class. Like my last sprint reviews I will be explaining in depth, the process that my team and I took during this sprint and what tasks we got done and what we didnt finish but are working on finishing on the next sprint so it doesnt stay in the backlog for a long time. We only have about three weeks left in the semester so we are trying to crack down on things and get them done for the deadline that is at the end of the semester.

During this sprint, my team and I set out to complete numerous amounts of tasks. The easiest task that we did was transferring everything that we had in our Trello board to our github board that we created. The reason we did this was for one, to be able to label the specific tasks, as epics, stories or tasks based on how big of an importance and work load they were to the project at hand. The second reason was to have it be able to be seen by the other team in the other class that is working on the Food Pantry as well. Just to make sure we ‘ bumping into each other and doing the same tasks which would be redundant to the project. After transferring and labeling all our tasks that we had, we continued to work on the ones that we had to finish from our backlog from the last sprint. Nick was working on the intake form, making sure that it worked and whenever you ran it, it would go to a server and save what the intake form would say. Nate was working on the CSS of the project, making sure the project had that Worcester State logo and Worcester State blue to it to make it pop and look very nice and neat. Andy was continuing to work on the back end of the project, working diligently and making sure it ran perfectly, he even was communicating with another group member from the other class trying to get it done. Johnny was working on the database side of the project making sure that the intake form had somewhere to store the data once it was completed. I was working on coding mini features in the food pantry like for example, if they wanted to ever categorize their foods in the pantry into different food groups but I didn’t finish it as it wasn’t too important to the project. I also made a mock up for what the employees could see when they login in when they are working.

Next sprint we are going to try to get everything that we have left to do done so we are ready to present our project and hand it over to the food pantry. One problem we ran into last sprint that we hope we don’t run into next sprint is sometime out of the blue, our projects wouldn’t run in webstorm and we would have to restart our projects and reopen them. We basically have this last sprint to go with maybe a little quick sprint at the end to tie everything up. We are in the final stretch of the semester and Im looking forward to see what we come up with in the end.

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.

Sprint Retrospective – Round Four

            A reflection
on what I learned from this week’s sprint is that a poorly managed repository
will create problems for your team and slow down the progress. After translating
the work done in Java to Angular during our restart from last sprint. The initial
IDE used was an online IDE called StackBlitz however this was abandoned for
WebStorm a week later. This is because we weren’t able to successfully connect
it to any repository so that other members could make changes. At this point,
we downloaded a copy and started to transition into WebStorm.

            During this
transition, we decided to get a working copy into the GitHub so that everyone
from both groups can work on it. 
However, we did not make note that a properly structured repository is
important. In this iteration of the repository, the root folder did not include
all the necessary files needed to function correctly. The necessary files were
not exactly missing from the upload but rather located in the only other
subfolder. This subfolder was generated since we downloaded a copy from StackBlitz.
By placing this subfolder into the original root folder, we had plenty of
workarounds to make the project work normally.

            At this
point in time, instead of importing the root folder to start working on the
project, we imported the subfolder. This was a workaround since it treated the
subfolder like the root, so it functioned normally. In this folder, it also
contained a git ignore file that could not be used since it was located in
there. This meant that the node modules folder was also included to be committed
back into the repository. In the majority of cases, it is not recommended to commit
that folder, but little did we know what was happening.

           In the end, the Professor and another member managed to get a working copy sorted and uploaded to the master. Now it is structured with all the necessary files in the root and two other subfolders, one for backend and one for frontend. It is neat and easy to navigate, which meant that we would be able to easily pinpoint where new services and components can go. At this point, we don’t have to worry that making changes would risk breaking the builds that other members spent time working on. In the future, I will not let this situation happen again and will be more careful when structuring a project!

            During this sprint, I focused my efforts on creating a submission service. Currently, the intake form includes a submit button that only returns what the user has inputted in the form into a new page. I started using an Expressjs server, which has allowed me to get use simpler features to connect the main form with a local server. Eventually, the default url address should be directed to an actual server. In this current iteration of the intake form, it sends the array to the localhost at port 3000. By running both the server and the intake form in WebStorm and submitting a completed form. We can see that the array of data is now retrievable on the server, which can be seen in WebStorm’s terminal for the server. If everything goes smoothly we can most likely store the data into some form of non-volatile memory later on.

References:
https://expressjs.com/

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.

Draw Your Own Map || S.S. 9

csseries281829For my second-to-last individual apprenticeship pattern, I have decided to go with something a little more relevant to my current situation–relating to starting my career post-graduation.

The Draw Your Own Map pattern caught my attention right away with “we might come across situations or colleagues or people in the society who will try to prove that programming will become an unsustainable activity as time passes by.” Throughout my job search process, I asked questions and requested advice from all different kinds of people across different fields (and especially within computer science) on how they knew what job they wanted to start with when given opportunities.

In the end, I must choose what I think is best for me in terms of what I’m looking for. I’ve finally came up with a list and that includes:

  • Having solid mentorship
  • Proper training (no room for imposter syndrome)
  • A company that tries to stay on top of new technology
  • Work-life balance that allows me to continue doing all the things I love to do outside of work and travel often

The Draw Your Own map pattern is very encouraging, reminding us that we have options elsewhere if we feel that our current company is hindering our learning and personal growth. I found that this pattern was interesting because I part of my decision-making process was “what if I am ____ amount of time into my first career and realize that I do not like what I am doing?” How would I move on out of that role to figure out what I may like better in terms of my day-to-day tasks?

The activity to list three jobs that I could do following my next was was really helpful to visualize future career possibilities. I know that we can always learn on the job and at new jobs but it is also important to build up your skills that can be transferred in the first place.

The pattern has helped me feel more confident in the decision I made to start out in software engineering. I will build up my skills starting here and then more onward from there!

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Sprint 4 Retrospective Blog

For this sprint, I worked on several different tasks to improve the project. Firstly, we needed to get the project hosted onto Heroku, so I added some of the dependencies that Joshua Farrar had created in order to allow it to be deployed directly from GitHub. There were also some minor bugs that needed to be fixed such as typos, missing new line characters, etc. Next I worked on adding build instructions to the readme by working through installing the project on a clean windows install on a virtual machine in order to figure out every dependency needed to be installed. Then I added a landing page to the project which contained a list of all of the available endpoints, however this was a very bare bones solution as it was just a list of the endpoints with no further information. We decided to integrate Swagger 2 and Swagger UI to automatically create more description documentation containing endpoint descriptions as well as a UI to test the endpoints. There was also a minor issue where the example model of the object returned by the endpoint was showing up as empty. This was due to the way the endpoints were returning objects (showing the model of the “Object” class rather than the actual classes being returned).

From what I understand, Swagger gathers the endpoint data in the same way that I did, however, it’s far more detailed and robust. I think if I were to do something differently in this situation I think definitely I would do more research into the possible alternatives to solving each task in order to figure out what the best solution would be before starting to work on it. Had I initially looked into Swagger prior to starting to work on the landing page, I would have saved a lot of time. This is something that I should take into account for the future as it will be important to avoid wasted time whenever possible.

When making the build instructions, I think using a virtual machine to start from a clean slate was definitely the best course of action, as it’s important to see what it’s like for someone who potentially started from that state to get the project up and running. By doing this, even people who already have some of the dependencies installed will be able to follow through the build instructions by skipping steps that they’ve already installed. Although, I hadn’t considered the difference in the installation process between Windows devices and Mac/Linux devices. This project in particular doesn’t require many dependencies to get started, so it’s not difficult to create combined installation instructions, but I think for larger projects it would be smart to separate them. One of the differences I ran into was including the installation of Git Bash while Mac/Linux devices would be able to just use command line.

For the next sprint I’m hoping to automatically update the version number whenever necessary, as it’s definitely bad practice to have to update it in 4 different locations every time. Also, it would probably be a good idea to add an endpoint that gives you a products maximum shelf life and best storage method, given what the data would probably be used for.

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