Category Archives: Week 7

week-7

Hello, final week (seventh). It is spring break week is almost over, even with the book. I got a comment about needing clarification on the chapter 2 blog; I needed to have understood the number of pattern selections as I chose more than one pattern. So I went back to week-1 (chapter 2) for a quick review; I chose one of the topics. It is “The Deep End.”

This pattern connected with me by feeling stuck and needing to challenge myself with more significant projects to grow my skills, confidence, and even a portfolio. By jumping in at the deep end to take on challenging jobs and doing things that push over the limits. It highlights that taking risks is an opportunity seen through anxiety and responsibility to counteract the threats by finding mentors and creating feedback loops. Yet, I agree with aspects of that technique. It shows taking the list of your projects to measure project complexity and other proportions while using this idea to see where your career is heading and make choices based on it.

Have you noticed that the practice has changed how you consider the type of work you want to undertake or your desired career path?

This practice allowed me to jump at the deep end and take on challenging projects for future careers in tech companies. I have developed various skills highly valued in the tech industry of experience in different areas like project management, problem-solving, and cross-functional collaboration. This can help me become more flexible and better equipped to handle different roles and responsibilities in the future. I am then building a solid portfolio that showcases my skills and experience to possible companies. It tracks projects and provides results to help people stand out and increase their chances of getting hired or promoted. Lastly, taking on challenging projects and pushing to become more confident and stable for tech companies operating and looking for individuals who are fast-paced and rapidly changing environments can settle on challenges and work under pressure. Also, I can become better prepared to guide the injunctions of the tech industry and succeed in my career.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

week-7

Have you noticed that the practice has changed how you consider the type of work you want to undertake or your desired career path?

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

week-7

Have you noticed that the practice has changed how you consider the type of work you want to undertake or your desired career path?

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

week-7

Have you noticed that the practice has changed how you consider the type of work you want to undertake or your desired career path?

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

week-7

Have you noticed that the practice has changed how you consider the type of work you want to undertake or your desired career path?

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

week-7

Have you noticed that the practice has changed how you consider the type of work you want to undertake or your desired career path?

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

week-7

Have you noticed that the practice has changed how you consider the type of work you want to undertake or your desired career path?

From the blog Andrew Lam’s little blog by Andrew Lam 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.

Gluing functions together in F#

Often when writing a function, we want it to be generic enough that it can operate in different ways for different inputs. Different languages will provide different ways to do this. Object-oriented solutions might include interfaces and polymorphism. Procedural languages might suggest template specialization or function pointers.

I’m going to talk about how functional programming languages use first-class functions to solve this problem in a satisfying way without any pointer syntax. Here’s some F#:

let rec filter fn lst =
    match lst with
        | [] -> []
        | head::tail -> 
            if fn head then [head] @ filter fn tail
            else filter fn tail

We’re defining a function named filter here which takes a boolean function and a list. The filter function will pass each element of the list to the function and eventually return a list of the elements for which the boolean function returns true. Let’s look at the result of passing some simple arguments.

let numbers = [0; 1; 2; 3; 4; 5; 6; 7; 8; 9]

let isEven i = 
    i % 2 = 0

filter isEven numbers
[0; 2; 4; 6; 8]

Usually when we see functions in the argument lists of other functions, we expect them to be glorified values. But in this case, isEven is not returning some value that gets glued to a parameter of filter. When a language has first-class functions, it’s perfectly fine to have functions themselves be the inputs or outputs of other functions. Here, isEven is itself an argument, and it operates on the head of each sub-list as we recursively cut our list down to one with zero elements.

In functional programming languages, it’s harder to write programs that aren’t reusable. If we want our filter to cut out any numbers that aren’t part of the Fibonacci sequence, we just write another boolean function and pass it instead.

let rec isFibHelper n x y = 
    if n = x then true 
    else if (y < 0) || (x > n) then false
    else isFibHelper n y (x+y)

let isFib n =
    if n < 0 then false
    else isFibHelper n 0 1

filter isFib numbers
[0; 1; 2; 3; 5; 8]

filter isFib (filter isEven numbers)
[0; 2; 8]

Because filter operates on a list, to filter a list of some other type we can just steal some documentation code for another boolean function.

let strings = ["abc"; "DEF"; "gHi"; "jkl"]

open System

let allLower s =
    s |> String.forall Char.IsLower

filter allLower strings
["abc"; "jkl"]

Functional programming is all about composition and modularity. You start with tiny Lego pieces and need to attach them until you have a gigantic ninja castle. In its most dogmatic form, that means sacrificing creature comforts like loops and mutable data that we use to quickly slap together solutions that can never be reused.

If you learned to write procedures or call constructors, I recommend giving one of these languages a try. It even makes recursion fun, so what’s not to like?

From the blog CS@Worcester – Tasteful Glues by tastefulglues and used with permission of the author. All other rights reserved by the author.

The Great Observer Pattern

The Observer Pattern is a design pattern that allows objects to react to changes in another object’s data while maintaining loose coupling. Loose coupling, for a reminder, is a system in which components are weakly associated with each other. The pattern as described in Ilyana’s blog “The Observer Pattern” is a pattern that can decide at runtime whether to receive data from the subject-object.

The blog goes on to say that it is not uncommon for object-oriented programming to run into a situation where you have an object in your code that collects/outputs data and other objects that care about that data. Some objects might care about certain data that the programmer might throw at them, such as measurements or certain temperatures. These objects are the observers. The observers do not care what class gives them the data, only that they receive the data as it changes. Signs that your code might need to be refactored to utilize the Observer Pattern include an object that is dependent on another object or a change to one object that requires a change to many others.

The Observer Pattern defines a one-to-many relationship between a set of objects. The Observer Pattern defined one subject’s relationship with its many observers. The Observer Pattern will separate the subject from its observers while still allowing the observer to react to changes in the subject’s data. The observers provide a method that allows the subject to inform them of the updates. This pattern allows for loose coupling once again between subjects and observers. As explained in the blog they can interact but don’t know that each other exists, they basically know nothing about each other.

The pattern is usually implemented using an abstract subject class and an abstract observer class, which a concrete subject and some concrete observers inherit. This pattern would be very useful if I ever needed the objects to receive an update when one object changes. It’s very intriguing to hear the terminology they use within the blog. The subject acts as a publisher which sends out the information and the observer, which acts like a subscriber, basically takes in the information it wants to receive. Obviously with I can see the subject sending information that the observer might not want to receive or have on them. Non the less it’s a very interesting pattern that shows the process of what a loose coupling might look like in a coding environment.

Link to Blog “The Observer Pattern” by Ilyana: https://ilyana.dev/blog/2020-08-07-observer-pattern/

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

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this: