Java reference notes

    The other day I saw the notes of a Junior Java web developer and it looked like a textbook. Well may be not like textbook, but at least a good quick reference guide. So I asked to photocopy them and here they are for everyone that may need it:

http://dox.bg/files/dw?a=11fc2241e0

Java WeakReference counterpart

We have all heard of different reference types - weak, strong, soft. We think that the WeakReference class is very useful. But we noticed the lack of StrongReference class and we think it can be useful as well. So here is our implementation of StrongReference:

1:  public class StrongReference<T> {  
2:    
3:      private T mType;  
4:        
5:      public StrongReference()  
6:      {  
7:          super();  
8:      }  
9:        
10:      public StrongReference(T aType)  
11:      {  
12:          super();  
13:          mType = aType;  
14:      }  
15:        
16:      public synchronized T get() {return mType;}  
17:      public synchronized void set(T aType) {mType = aType;}  
18:  }  

We are using synchronzed on the get and set methods, because we use the StrongReference concurently, and this was the use case we had in mind when creating it in the first place. But if your use case is different you can remove them.

Validating an expected JSON

    Let's say we are getting a JSON from a service and we want to know if it is following the contract that this service has promised. When we use the JSON we would handle cases of missing keys, but we have to look at the actual response to see if everything is OK with it, and that takes time. What if we want an indication prior to that, that there is something wrong with the data of the JSON. We have implemented a few short methods that take as arguments the JSON that we intend to use and a JSON that is a model of the data that we expect to get. The method traverses the model and checks to see if the JSON that we are going to use matches it.
    We can also use it as part of our automation test for our service.
    How does it work. We have two JSON strings. One is a response that we get from a service and the other is a model of the JSON structure that we expect the service to return - the contract of the service to the clients/users. We check that the response corresponds to the model - if all the keys and structure of the model are present in the response, then it is valid.
Here is a short description of the algorithm:

Validate JSON

Does the key from the model exist in the response:

    No - response is not valid

    Yes:

        is the value a JSON object:

            Yes -> validate JSON object

        is the value a JSON array:

            Yes -> validate JSON array

                    else continue to next key.

    The repository for the project is at GitHub and contains implementation for Objective-C, Java and Go:

https://github.com/ektodorov/JsonValidation

List with sticky headers and List with sticky headers and expandable items

    Here is a project that implement a list with sticky headers - list that has two types of list items (lets say sections and items in each section), when scrolled to the top the header sticks to the top of the list.
    The other project builds on the same implementation, but we can collapse and expand the sections of the list.


The project is at GitHub:

https://github.com/ektodorov/ListStickyHeadersExpandable

Remote work

    It means your office can be anywhere. It saves time and money. It is beneficial for the employee and the employer. And now working remote has an anthem:

(Fifth Harmony - Work from Home ft. Ty Dolla $ign)

https://www.youtube.com/watch?v=5GL9JoH4Sws

Task tracking with shared spreadsheets

    We would describe how we can use a simple spreadsheet to assign and track new task - requirements, change requests, bugs, chores, etc.

    We would need some kind of could solution like Google apps or Office 365 where we can share documents between team mates who can edit them.

    We have a directory holding our tasks. In this directory there is a spreadsheet file for each task we have. Let’s say our project is called Rap. We would have a directory called RAP and inside it we would have files called Rap1, Rap2, Rap3, … with the number of the tasks.

In the spreadsheet we have a few columns:

   Number - which is the same as the filename, so we can decide to omit this column

   Description - description of the task. If it is a new functionality it would be a description of what we want that functionality to be. If it is a change request it would be a description of what we want to change and how. If it is a bug it would be a description of the incorrect behaviour and what is the correct behaviour that we want.

   Status - it is an indication of the position of the task in our workflow. In the example spreadsheet our workflow is:

       -ToDo - the task is in a list of task is sitting and waiting to be picked up.

       -In Progress - someone is currently performing work on the task. It can be that someone is defining the task, and filling in the fields of the task - it is being created. It can be that QA is performing work, or that the task is being implemented - developed.

       -QA - the task is ready for QA.

       -Reopened - the task has been to QA and it has not passed successfully, or that the task has been closed, but it has been reopened again.

       -Done - The task has been completed successfully.

       -Closed - The task has not been completed, but of some reason we have decided to not complete it (we don’t need that work done anymore), so we just close the task, but still keep it around for accounting purposes.

   Assignee - the person that the task is currently assigned to.

   We can have a comments section after the end of the description or we can have the comments as a separate sheet in the spreadsheet, it is up to us.

   It is popular to use Agile software development process, for example Scrum. When we plan a spring we would have a directory for each sprint and the tasks that go in that sprint will be moved in the sprint directory.

   In our example Rap project in the Rap directory we would have a RapSprint1, RapSprint2, … directories. We could also have directories: Backlog for all the task that are not completed, and not in an active sprint; Completed for all the completed tasks. After a sprint is completed we would move the completed tasks in the “Completed” directory and the ones that are not we would move to the “Backlog” directory. In the finished sprint directory we can place a file with statistical data what was done, which tasks, were in the sprint, which ones we completed, which ones we didn’t, hours spend for the sprint and whatever else we want to keep track of.  

   By using a simple shared spreadsheet we showed that we can manage our tasks and even have some functionality that is not available in some of the dedicated software solutions for task tracking. Here Here are screenshots of an example spreadsheet created with Google Sheets:

Good code organization

    We all have read code organization rules or the so called - coding style guidelines. The better ones have an explanation behind every rule. Otherwise it is just a dictatorship of personal preferences. And even not that much personal preferences, because a person would have a reason for the preference, so more appropriate to say would be personal habits and we can only hope they are good and not bad habits.

    In our opinion a good starting point for a rule is to forget of all the fancy features of the IDE we are using all the coloring schemes and imagine we can only use a file listing and a simple text editor without any markup highlighting. Then the decision of using one convention over another becomes apparent.