Search This Blog

15 June 2016

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:

02 June 2016

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)

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.