Category Archives: books

Sprint 3

During sprint 3, I kept working on the frontend, like the last sprint, I had been stuck trying to get the backend up, while trying to work on the frontend. I had a teammate work with me for this sprint to complete it. We worked on two different branches, mine and Jason’s.  Inside my branch, I was having a problem starting up the frontend through development mode, so I decided to see the original branch and work back into the updates I had made. Jason was able to start the frontend without the backend using dev. This gave me the advantage of designing the frontend and seeing what would work. Working with someone this sprint improved the sprint overall for me because last sprint, everyone else was in the backend while I was working in the frontend. My teammates were helpful, but without working with someone directly in the frontend, it was difficult to get help on exactly what I needed.  

First starting on the design, I had noticed that I had to make the banners and everything the perfect size, or it wouldn’t be eye-appealing. Small things like having the top and bottom borders being same size were important. One of my biggest problems was attempting to make sure the page could fit on one page without having to scroll, because, first, designing the front end, there would be empty white space that wasn’t needed, or having the logos be too small. But I was able to persevere and have a design that I was proud of. I also have to give credit to Byron, who posted his design, which I translated into my design. It helped in choosing what logos should be prioritized and gives the frontend a coherent design.

  For this sprint, I would choose Kindred Spirits as the pattern that most resonated with me. This pattern highlights the importance of working together and working with someone who is like-minded and is determined to learn and accomplish their goals. This is great to have in a team because it allows teammate to grow together while also accomplishing their tasks. Working with a teammate this sprint greatly affected the amount of work I was able to accomplish. I was able to complete more in a shorter amount of time given. Directly working with Jason during this sprint gave me more insight into the issues we faced and helped me grow faster and feel more supported. Before this sprint, as I mentioned, I was isolated, working on the frontend by myself. It was difficult to troubleshoot my work with others because they were working on different aspects of the project, mostly in the backend. My teammates were helpful in what they could help me with, but there was always a disconnect because I didn’t want to slow them down on their work, and they were working on the backend. Working in collaboration with Jason allowed me to exchange ideas and confirm each other’s work. It gave me more confidence to ask questions because we were working in unison on the same problem. If I had been aware of this pattern earlier, I would have gotten a partner sooner because working in isolation isn’t a deterrent to just you but to the whole team.

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – What I Learned

For my capstone course this semester, I was assigned to read and review a book from authors Dave Hoover and Adewale Oshineye, known as Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by our professor, Karl Wurst. The intention of reading this was to ready and prepare myself for the challenge within this course, specifically about my skills in a field and how to cultivate and grow within said field, or “craft” as the book puts it.

To me, the most interesting part about this reading is how they attributed software development to craftsmanship. When I first thought about it initially when it discusses it in the first chapter, I immediately went “yeah that makes sense” but upon reading further and it digging at specific concepts like “what is craft” and “what makes an apprentice an apprentice”, it made me think a lot more about what a “craft” really is. Being an art minor, this definition was one that was important to me, as art in it of itself is synonymous to craft. Being able to compare my work when coding things and my work when I physically create artwork was an interesting turn of events and an epiphany I wasn’t expecting when dropping into this book. The individual breakdowns of each part of what makes craftsmanship what it is was very impressive and made me able to stand in the shoes of the authors.

When reading, I also felt a bit called out on bad habits that I definitely do on a daily basis. For example, the story told in Chapter 2’s introduction, discussing a cup already full, it reminded me of how I tend to get carried away when it comes to discussing what I know and want to share. This comes at, unfortunately, a disregard for the new information I would be trying to learn, much like how the analogy of the story goes. Another thing I felt was important and reflected on my own actions was Chapter 5, discussing how it is important to not use the internet as your only source of learning and information. Initially, I was quick to disagree with this point, as I do NOT enjoy reading in the first place (a.e. look at how long it took me to write this up) but then I sat down and realized that was another bad habit kicking in, as well as my ADHD. While yes, its true that written works contain many important informations regarding to one’s craft, especially in software development, one must also remember that “reading” isn’t the only way to absorb this information, you could find an audio transcript, as an example. Thus did I realize that this point was actually one that was really strong and heavily agreed with.

Overall, I feel further reading may be necessary for me, as this has changed a lot about the way I am thinking not only about this class and working on a development team, but also about myself and habits that I could be working on and improving. If you also would like to read the book, it is hosted here, for free: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch06.html

Until next time! (Which is, soon, because Ill be writing up another post right after this, haha)

From the blog CS@Worcester – You're Telling Me A Shrimp Wrote This Code?! by tempurashrimple and used with permission of the author. All other rights reserved by the author.

The CS Series || Intro V2

Processed with VSCO with hb2 presetHey guys! This site is going to take a slight change in direction for the next few months; it’s my last year of college so your girl is going to feature some CS content for classes.

Stay tuned for more!

Samantha Tran

P.S. Please excuse my double-intro.

 

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

The Little Schemer

Yesterday, I took a trip to the MIT Press Bookstore and picked up a
copy of The Little Schemer. I’ve only spent a few hours reading and
coding along with it, but I’ve had a lot of fun. The following is a
mini-review based on my experience thus far.

"The Little Schemer" teaches you to think recursively using an
interesting and comedic writing style and the Scheme programming
language. While Scheme is the language of choice, the real goal is to
teach you problem solving rather than the details of a specific
language. The book starts off simple, explaining what atoms, lists,
and S-expressions are. Rather than providing the definition and then
showing examples, it first gives examples in the form of a question
and answer.

Example:

Is it true that this an atom?

atom

Yes, because atom is a string of characters beginning with a
letter.

From the examples given, a definition is created. In later examples, a
Scheme procedure is written that produces the correct answers for all
of the questions stated before it. It’s fun to build the procedure,
verify that it works for all cases, and compare your implementation
with the book’s.

"The Little Schemer" defines ten commandments that are essential to
correctly solving the problems in the book. Some commandments are
first given in an incomplete form, and expanded later when a greater
level of understanding has been achieved. The problems that you solve
reinforce the commandments. You might notice that you start writing
procedures without thinking much about it, much like the muscle memory
earned from using Emacs a lot. Gerald J. Sussman was right when he
said that this book "can perform the same service that Hanon’s finger
exercises or Czerny’s piano studies perform for the student of the
piano." I have no idea who Hanon and Czerny are, but I get it. For the
drummers out there, you could liken this book to Stick Control.

The writing style is very informal, comedic, and food themed. Page 13
has a space reserved for jelly stains, and page 52 tells you to "go
cons a piece of cake onto your mouth." I have laughed a number of
times while reading. Oh, and let’s not forget about the cute elephant
drawings. This is definitely not your average boring, dry computer
science book. If you are interested in a unique and enjoyable learning
experience, then I highly recommend reading "The Little Schemer".

From the blog dthompson by David Thompson and used with permission of the author. All other rights reserved by the author.