What I’ll do this week (April 9)

--Originally published at Hermes's Blog

I have some things left to work in the api before helping Marco or Francisco with the mobile app and the tests.

Pool owners can specify custom amounts for each user, but they cannot make it automatic, I have to put a flag in the pool creation to set if the users will be charged the same amount, and also update everyones debt if a new user joins (This will only be updated if the pool has not started yet, because then users can start paying).
I need to notify users if they have a debt that have not paid (when the pool end date arrives).
With cash, owners should confirm the amount the users claim to have paid.
Store profile pics somewhere.

That’s what I’ll work this week, even if I don’t finish all of this I’ll start working in the Android app with Marco.

What I did this week (April 1)

--Originally published at Hermes's Blog

This week I worked in the flow logic for cash payments, a user can only pay a pool if it has a debt, but he or she can overpay and then the pool owner has a debt with him. Pool owners can edit the debts and amounts of the users but only if the debt is high enough to surpass the pool’s total. I was working implementing stripe, in fact, we were able to receibe payments from users that registered in stripe (we were missing the frontend that would comunicate with stripe for the registration). Anyway we decided that we don’t have the time to finish this, there are other, more urgent things to do before the final delivery, so we will drop the credit card functionality from the app and focus in making better what we already have.

What I’ll do this week (April 1)

--Originally published at Hermes's Blog

This week I’ll be working on the payment flow.

When a pool is marked as cash, users should say how much they paid and then the administrator should confirm the amount.

When a pool is marked as credit we will have to request the payment from the users and then send the same amount to the admin (we need to check if this is possible with stripe).

If the admin wants to update the amounts that the users have debt, we need to make sure that everything is kept within the limits of the initial costs (right now you can update a user’s dept to whatever amount). And maybe we should not be able to update the already paid amount (at least for credit), what’s already paid should not change.

Another nice to have would be to find friends on Facebook, instead of searching them by name or email.

That’s it.

What I did this week (May 25)

--Originally published at Hermes's Blog

Even though we were on vacations I made a lot of progress. From the Cooper API now we can:

Use another invitation flow: there is an endpoint where we can find the pools that we are invited to, an endpoint to accept invitations, and another one to decline invitations, this way we can make sure that only those who are invited join and that you can also decline invitations.
Disabled sendgrid, we will delete the code that send emails, everything will be done in the app.
Friend requests, now we can have friends, send, accept and decline friend requests.
Login with facebook.
I put a server on Digital Ocean, started using travis for continous integration, everytime we push to the server repository, the app is built and the tests are run, if they pass we can merge, when we create a pull request to master and merge it, the code is deployed automatically to the Digital Ocean Server and restarted.
Now there is an https version of the server on port 3443, altough the http server is still running on 3000, this was because facebook only allows login from an https server. We may need to get a real certificate (I created and signed one by myself and the browser shows a warning).

What I’ll do this week (February 26)

--Originally published at Hermes's Blog

There are a lot of things that I’d like to do, I’ll enumerate them in order of importance.

Search pools and users, that implies that I need to create a way to query a regular expresion or at least the begining of one of their string properties. I also need to filter the pools by its `public` property.
Pool owners need to split the bill, they should be given the options of spliting it evenly or with custom amounts (do we need to make sure that the total of all the custom amounts sum up to the total of the bill?).
Pool needs to specify who you should pay to, how much money do they owe or who payed more than necessary.
The only payment method available right now is cash, the pool owner should be the only one able to change the pool and relation to the pool properties.
Maybe invites should be visible through an interface in the app, I think that the best way to approach this is to create a new relation between the pool node and user node that indicates that he’s been invited. Because otherwise there is no other way to find out who you have invited, the email is send and after that it all depends on the user clicking the link.
We need a Facebook and Google login (I think this will be done by someone else).
User profile images are not critical (because we have default profile gravatars) but would be nice to have, we should store them somewhere outside the database, maybe store the path to the file in the node, or use an external service like Amazon S3.

What I did this week (February 19)

--Originally published at Hermes's Blog

This week I advanced a lot in the relation api for neo4j, altough I’d like to improve it, we can get along with it for whole project. Also, in the Cooper api, we can now create, join pools, users can invite other users and invitation links are sent to them via email. Marco and Poncho managed to have a beta version of the Android app, most of the api functionality is already implemented in the app. It’s been a productive week.

Code reusability: don’t reinvent the wheel

--Originally published at Hermes's Blog

As the title says, it is completely unnecessary to rewrite code that it has already been written, it is, most of the time, a waste of your time and effort. With all the open source code available nowadays, it is really probable that you find whatever you are looking for on sites like github, gitlab, bitbucket or any other site, and if you don’t find it, well, then now you know what’s going to be your next open source contribution. You should really focus on writing building on top of what others have already done, also, it is worth to notice that you should be writing reusable code as well.

Some tips on writing reusable code:

Don’t repeat yourself: if you find yourself writing the same code several times, probably you should move that piece of god to a module or something alike.
Make a class/method do just one thing: remember the Unix philosophy? write programs that do one thing and do it well, also, write these programs to work together, the secret is in writing generic code to accomplish one simple thing, then use the output of that as input of another program to accomplish a more complex task, don’t make code too generic tough, or it will be difficult to find a purpose to it.
Write unit tests for your classes and make it easy to test classes.
Remove the business logic or main code away from any framework code.
Try yo think more abstractly and use Interfaces and Abstract classes.
Write code that can be easily extended in the future, for code leverage of course.
Don’t write code that isn’t needed, if you doubt if the code is needed, then it is not, just leave it out.
Try to reduce coupling, avoid modules/classes depending on each other.
Be more modular, again, the Unix philosophy.
Write code like your code is an External API, write everything modular and do one thing, then make these components work together to accomplish one common objective, by the end of the day you will have nice, modular and reusable code.

Sources:

http://hoskinator.blogspot.mx/2006/06/10-tips-on-writing-reusable-code.html

What’s the use of code reuse?

Software Verification and Validation

--Originally published at Hermes's Blog

Validation and verification are two different concepts in software engineering, each one can be abbreviated to the questions: are we building the right system? and are we building the system right?

Validation is concerned with checking that the software actually satisfies the customer’s needs and its objective is to demostrate that the product fulfills its intended use when placed in its intended enviroment, whereas verification is the process which checks if the software is functioning correctly and its objective is to ensure that work products meet their specified requirements.

Source:

The difference between Verification and Validation

Verification vs Validation

User Interface Design

--Originally published at Hermes's Blog

User Interface Design focuses on anticipating what users might need to do and ensuring that the interface has elements that are easy to access, understand and use to facilitate those actions.

The reaction or the experience of the user when ising software doesn’t only depend on the functionality and the aesthetically design, what more influences the user to feel comfortable or not is the user interface.

Gestalt Design Principles

Similarity: occurs when objects look similar to one another.

Continuation: occurs when the eye is compelled to move through one object and continue to another object.

Closure: occurs when an object is incomplete or a space is not completely enclosed.

Proximity: occurs when elements are placed close together.

Figure and Ground: The eye differentiates an object from its surrounding area. a form, silhouette or shape is naturally perceived as figure, while the surrounding area is perceived as ground.

flickr photo by Isaac Kohane https://www.flickr.com/photos/52786697@N00/15857500937 shared under a Creative Commons (BY-SA) license

Best practices for User Interface Design

Keep the interface simple
Create consistency and use common UI elements
Be puposeful in page layout
Strategically use color and texture
Use typography to create hierarchy and clarity
Make sure the system communucates what’s happening
Think about the defaults

Sources:

https://www.usability.gov/what-and-why/user-interface-design.html

http://graphicdesign.spokanefalls.edu/tutorials/process/gestaltprinciples/gestaltprinc.htm

Software Maintenance

--Originally published at Hermes's Blog

Software maintenance stands for all the modifications done after the delivery of a software product. A software maintenance is needed in order to mantain our software up to date.

Modifications in the software may be required because of changes in the market conditions, changes in the client requirements or even host modifications.

There are some types of maintenances based on their characteristics:

flickr photo by Pia https://www.flickr.com/photos/omgdolls/16382202136 shared under a Creative Commons (BY-SA) license

Corrective Maintenance:

This includes modifications and updates done in order to correct or fix problems, which are either discovered by user or concluded by user error reports.

Adaptative Maintenance:

This includes modifications applied to keep the software product up-to date and tuned to the ever changing world of technology and business environment.

Perfective Maintenance:

This includes updates done in order to keep the software usable over long period of time. It includes new features, new user requirements for refining the software and improve its reliability and performance.

Preventive Maintenance:

It aims to attend problems, which are not significant at this moment but may cause serious issues in future.

Sources:

http://swebokwiki.org/Chapter_5:_Software_Maintenance

https://www.tutorialspoint.com/software_engineering/software_maintenance_overview.htm