Going Back To Square One

Good my fellow readers!

Today I will be discussing an individual Apprenticeship Pattern from the book, Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. The pattern I would like to discuss today is naturally the first one, Your First Language, because where else is there to start but at the beginning?

The pattern starts by defining itself as a pattern for those who have surface knowledge of a couple of languages. It suggests that this particular pattern is for those who need to learn a language to solve a problem at work for example, or need to know a language for a job interview. It then launches into the solution, through execution of the pattern. To put it plainly the pattern is to pick a language and learn it. Having a problem to solve helps the process by giving you a goal to work towards and a drive to keep learning. It is also advised to take things slow and in small steps. It is also suggested to find a community and learn from its members as some methods or teachings may only be spread by word of mouth. It ends by reminding the reader to not get stuck with one language and to spread out into other languages.

I will admit, with this being the first pattern in the book I expected it to be for total beginners but it is aimed at just about everyone. What I find interesting about this pattern is that it seems to cater well to those who have never really picked up coding before or someone who, like myself, have had years of high school and college education in coding. I will admit that the amount I know about all the languages I have learned about is somewhat shallow. Some go deeper but many are probably not that far off from just surface knowledge. I might just try following this pattern after graduation. At first, I would have only recommended this pattern for only beginners who haven’t had formal schooling but after reconsidering, I think even those like myself who have had formal schooling can benefit from this pattern.

That’s all I have to draw from this first pattern and I hope to get more from future patterns. Until next time readers!

 

Software Architecture Patterns: Building Better Software

Hello again, readers! Today I dove into an article by Peter Wayner detailing 5 different design architecture patterns for software design and their benefits and weaknesses.

The first is Layered architecture. This is where data enters the top layer and as it passes through each layer, the layer performs a specific task. A major benefit is that each layer is maintainable, testable, can easily be assigned roles, and are easy to update and enhance. However, this can result in the source code being very messy, the code can be slow, the whole program can be hard to understand, and changing a small part could be impossible as you may need to change the whole program.

The second is Event-driven architecture. A central unit is built that accepts all data and then delegates task to separate modules to ensure that your program isn’t just waiting around for something to happen. This allows for the program to be scalable, adaptable, and easily extendable. This can lead to complexity when testing and error handling can cause troubles in development. Essentially, the more each module is dependant on the others, the more troublesome the entire program becomes.

The third architecture is Microkernel architecture. This architecture uses a set of core operations that are repeated over and over again in different patterns depending on the data given. If needed, different modules can be tacked on to allow the program to perform different functions and patterns. The difficulty with this architecture is that getting the plug-ins and microkernels to cooperate can be tricky. There is also the trouble of not being able to modify the microkernel once plug-ins start to depend on the microkernel.

The fourth architecture is Microservices Architecture. The main idea here is to build a number of different tiny programs that will handle one specific task instead of having one big program do everything. This also allows some individual programs to be scalable up to a large size while others are kept small. Some downsides are that some tasks can’t be easily split up into a single microservice. Each microservice must also be independent or the cloud can become unbalanced. Lastly, if tasks are split up amongst several microservices, the communication costs can begin to skyrocket.

The final architecture is Space Based architecture. This architecture is designed to split up processing and storage between multiple servers. This protects against collapse under a great load. Data is stored across the nodes and information stored in RAM. This does make many simple tasks quicker but can also slow down computational tasks. This architecture can also be referred to as Cloud Architecture. The main drawback with this is that with RAM databases, transactional support is difficult. Testing the entire system can be difficult as well.

This was an interesting read as it went one step higher than what we learned in class so far. This covered the upper level where multiple programs come together while in class we cover designing a single program. The Space Base architecture was quite familiar as I learned about it in a Cloud Computing course I took earlier in the year that dealt with Hadoop. The Microkernel architecture was cool as well as I personally use Eclipse to work on in-class projects and learning more about its overall architecture is something I thought I would never dive into. The Event-Driven Architecture has given me an idea for a way to work on the final project that was recently assigned to us in class. Hopefully, it works out as putting something you learned to use is always a rewarding experience.

Until next time readers. Have a wonderful day and see you next week!