Hello my readers and welcome back to my blog. Today I am going to write about another Apprenticeship Pattern called Expose Your Ignorance. I totally agree that it might sounds weird when you hear it but you will change your mind by the end of this blog post.

You have just started working for a company, its your first job and everyone expects a lot from you. You are now a Software Developer and its time to show your skills. Too much pressure I know!!

This chapter of the book talks about how you should not hide what you don’t know as that will make you more ignorant. Everyday of the job and everyday of our life is a learning process for everyone and you don’t make an exception. The authors strongly encourage every software developer out there (especially the inexperienced ones) to expose their ignorance by asking questions. By asking questions you are letting your team know that you want to learn and lower the level of ignorance.

Pride! Ahh pride, this is what holds most of the people back. I totally get it that it’s easier said than done, but you should really leave your pride aside when learning. Yes its true, you can go and do your own research about the matter but that it going to take you a bigger amount of time compared to the situation where you can just ask your teammate or your manager.

If my close friends were to read this blog post would say: “Look who’s talking!”. Yep I got the same issue, I am very afraid to the idea that my teammates will think how inexperienced or ignorant I am so I just keep going on my own and stress myself until I find the answers of my questions. However I have realized that working in a team with a great environment makes it way easier to address to your teammates or manager for questions you might have.

So yeah..long story short: Ask questions about what you don’t know or need to know! But keep in mind to try to shorten the list of the things you don’t know soon. There will be times where the list will get longer than usual and sometimes shorter but as you choose the shortest path to expose your ignorance, you will notice that by the end on the trip you will be an expert. Don’t get discouraged, ASK!

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

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.

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

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!

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

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.

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

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