Reading List

Hi dear readers. Welcome back/all to my next blog post about the next Pattern. The next Pattern I am going to write today is about ‘Reading List’. Yep you heard it right! Reading List! Just because you are a developer doesn’t mean that you got no more reading to do.

This Pattern in the book talks about how to start with a reading list and how to keep up with it. The authors make very good points when they say that its hard to even start a reading list as you might not be sure what to read first. I like how one of the recommendations is to ask your mentor/professor. They would be the people who know your development level better than anyone and will definitely be a great help. Another point to keep in mind is that the initial Reading List you have created might (probably will) change after you have finished one of them. Having a Reading List is great because it also makes you reflect about what you read previously.

As mentioned in the book, we should always think and analyze about the book we just read and try to figure out on our own on what should be the next book to read. Computer Science is one of these field that new things will  always keep coming up and what better than books will be describing these new innovations. Indeed these new books should be on top of the list.

I believe that there will be cases where you/me as a reader will be disappointed on one or more books. It’s not right that just because one book was not good enough, we should stop reading other books. I think that when you don’t find a book interesting or good enough, it’s a good sign as you are thinking about the book content. This will give you a better understanding on what you would like to read next and what is your favorite area. For example, for my reading lots of books about programming languages wouldn’t be too much interesting. On the other hand there are people who love reading each and every book about programming languages and this is because they’re passionate about it.

I would recommend to just start somewhere, and then you will be able to figure out on what to jump on next.

Advertisements

Familiar Tools

Hi dear readers and welcome back to my blog. Today I am going to talk about another Pattern that I read from the book Apprenticeship Patterns. This blog post will be about familiar tools.

Once we start working or coding on our own we start to like and choose which tools we like and which ones we do not. It is just a matter of time for us to figure it out. Once we do though, its hard to switch. When I started coding, I was only learning tools that were recommended from our professors in school and as I was ‘scared’ to experiment I always choose not to switch even if I didn’t like it. Going to work and school at the same time was amazing as I was facing new tools in both environments and I was able to tell which ones I liked and found more useful and made me more productive. And as the book says, once you find your favorite tools, its hard to switch!!

This chapter talked about how all of us have our own favorite tools and we find it hard to switch even if the productivity sake is in risk. It would be our decision on weather to give up our tools or not but we have to face consequences. At the same time, just because a tool is great for you don’t mean it will  be great for someone else. Something that you might find easy, might be hard for someone else.

There is one example I would like to give for this Pattern. I started to use Eclipse on my second semester of Computer Science and I wasn’t crazy about it, but as we had just transited from BlueJ was very cool. Two semester later is when I started my job and over there the developers were using more advances IDEs and I was very excited to learn and get familiar. Eclipse went out of my list right when I learned about Illuminated Clouds. Very ‘smart’ IDE! However, Eclipse was still the only option in school and I was hating it and started to recommend to other people. Some of my friends found it very useful to use and some others already loved Eclipse for what it was.

Last but not least, I really liked the recommendation from the book that was suggesting to have developers create a list for all familiar tools and keep researching is the list was smaller than 5. All of us will probably change lots of jobs and lots of companies will have their tools, but its always good to have your own area of expertise.

Hope you guys found this blog useful…Stay tuned for the next Pattern from this cool book!

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 🙂

 

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..

 

 

 

REST API

Hello dear reader. This is my last blog for my Software Construction and Design and as a very important part of development I choose to talk in this blog post for REST API.

REST API stands for Representational State Transferee and provides a lighter weight compared to SOAP. Instead of using XML to make a request, REST relies on a simple URL in many cases. In some situations, additional information needs to be provided. Most Web services using REST rely exclusively on obtaining the needed information using the URL approach. REST can use four different HTTP verbs (GET, POST, PUT, and DELETE) to perform tasks.
REST-based Web services output the data in Command Separated Value (CSV), JavaScript Object Notation (JSON) and Really Simple Syndication (RSS). The point is that you can keep the output you need in a form that’s easy to understand and use within the language you are using for your application. The information you receive when using REST is a JSON formatted document containing the information you asked for. You can use your browser to interact with the Web service, which makes it a lot easier to create the right URL and verify the output you need to parse with your application.
In most of the part REST is easier and more flexible to use. To use REST you do not need to purchase any tools, Postman or Insomnia can be downloaded for free. REST though, is efficient as it uses the small message formats and it has a fast process.
There are some very strong reasons that you should be using REST. First, REST is the most popular choice of programmers to build APIs.  Also REST API is great on making the data available as a resource as opposed to service.
To create a REST API, the following six architectural constraints are needed: 1. Uniform interface, which means that the same resource should not have more than one URL; 2. Client-server separating, which means that the client and the server should act independently. 3. Statelessness, which means that there should never be any server-side sessions; 4. Cacheable resources, means that the server responses should contain information even though the data sent might or not be cacheable; 5.Layered system, which means there might be different layers of servers between the client and the server that returns the purpose; 6. Code on demands, which means that the response can contain code that the user can execute.

If I also refer to the previous blog about SOAP API I would say that there are clearly good reasons why REST API is a better choice to use when requesting/ expecting data and when you want to build your own program. However the decision is yours. I hope I have helped your CS journey. Till next time…

https://en.wikipedia.org/wiki/Representational_state_transfer

SOAP API

Hello dear reader. After explaining what API is, now I would like to talk about Architectural Styles for API. One of these styles is called SOAP.

SOAP stands for Simple Object Access Protocol. SOAP is a standard based Web services access protocol that enjoys the benefits of long-term use. SOAP is developed by Microsoft.
SOAP relies exclusively on XML to provide messaging services. Microsoft originally developed SOAP to take the place of older technologies that don’t work well on the Internet. These technologies are bad and fail because they rely on binary messaging; the XML messaging that SOAP employs works better over the Internet. SOAP is designed to support expansion, so it has all sorts of other acronyms and abbreviations associated with it, such as WS-Addressing, WS-ReliableMessaging, WS-Policy, WS-AtomicTransaction, WS-Federation, WS-Coordination, WS-Security, and WS-RemotePortlets. In SOAP you can only choose to use the pieces you need for a particular task.As we know, in some programming languages, you need to build requests manually, which becomes problematic because SOAP is intolerant of errors. However, SOAP provides shortcuts to help in this issue. The difficulty of using SOAP depends on the language you use.
One of the most important SOAP features is built-in error handling. If there’s a problem with your request, the response contains error information that you can use to fix the problem. An interesting SOAP feature is that you don’t necessarily have to use it with the HyperText Transfer Protocol (HTTP) transport. There’s an actual specification for using SOAP over Simple Mail Transfer Protocol (SMTP) and there isn’t any reason you can’t use it over other transports.
As SOAP is an ordinary XML file that consists of the following parts: 1. Envelope, which is the starting and the ending tags; 2. Header, which it allows you to extend the SOAP message in a modular way; 3. Body, which contains XML data that the server send to the receiver; 4. Fault, which carries the information about errors occurring during the process of sending the message.

SOAP is mostly used for enterprise-lever web service because that require high security. Some examples of SOAP that I found online were: financial services, payment gateways, identity management and telecommunication services. Also another feature of SOAP is that the API calls can not be cached. The biggest disadvantage is the poorer performance, more complexity and less flexibility.

I didn’t know SOAP existed until I searched for REST (the next blog). The reason why I choose to write about SOAP is that it is a wide used architectural style for API and it has its own place of use, places or situation where REST can not be used.